Basic Software Module Description Template

AUTOSAR CP R23-11

Basic Software Module

Document Title Description Template
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 89

Document Status published

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

Document Change History

Date Release Changed by Description
AUTOSAR • Added BswInterruptEvent class
2023-11-23 R23-11 Release
Management • Editorial changes
• Added constraints for Lower Multiplicity

AUTOSAR • Modified compatibility for client server

Release entries
2022-11-24 R22-11
Management • Minor corrections

• Editorial changes
• Modified compiler abstraction
AUTOSAR
2021-11-25 R21-11 Release • Minor corrections
Management
• Editorial changes
AUTOSAR • Added Use-Cases
2020-11-30 R20-11 Release
Management • Editorial changes
• Added constraint for the use task or
cat2Isr
AUTOSAR
2019-11-28 R19-11 Release • Editorial changes
Management
• Changed Document Status from Final to
published
5

1 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
• Added support for Structuring of
Measurement and Calibration

AUTOSAR • Added Use-Case description for Upload

Release and download of data
2018-10-31 4.4.0
Management • Added Use-Case description for
Hardware Test Manager

• Editorial changes
• Added Use-Case description for OBD
services
AUTOSAR
2017-12-08 4.3.1 Release • Extended Use-Case descriptions for
Management BSW modules

• Editorial changes
• Standardization of Rapid Prototyping
Support
AUTOSAR • Improve Callout handling
2016-11-30 4.3.0 Release
Management • Extended Use-Case descriptions for
BSW modules

• Editorial changes
AUTOSAR • Minor corrections / clarifications /
2015-07-31 4.2.2 Release editorial changes; For details please
Management refer to the ChangeDocumentation
• Extended splittables for BSW
AUTOSAR
• Added Use-Case descriptions for BSW
2014-10-31 4.2.1 Release
modules
Management
• Editorial changes
AUTOSAR • Extended Upstream mapping for BSW
2014-03-31 4.1.3 Release
Management • Editorial changes
• Added support for indexing of array
AUTOSAR elements
2013-10-31 4.1.2 Release
• Various fixes and clarifications
Management
• Editorial changes
5

2 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
• Meta-model extensions for multicore use
cases

• Meta-model extensions for functional

modeling of measurement and
calibration

• Meta-model extensions for rapid

prototyping use cases
AUTOSAR
2013-03-15 4.1.1 • Improved support for production error
Administration
modeling

• Added several clarifications,

explanations and model attributes

• Added hyper-links to requirements and

model elements

• Added appendix E on Upstream

Mapping
• Introduced formal specification items
and Constraint and Specification History

• Added several clarifications, examples

and constraints
AUTOSAR
2011-12-22 4.0.3 • Improved support for AUTOSAR
Administration
Services, memory mapping and
calibration

• New attributes in various parts of the

model
• Reworked description of Memory
AUTOSAR Section
2009-12-18 4.0.1
Administration • Added chapter on Implementation
Conformance Statement
5

3 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
• Harmonized with SW Component
Template (triggers, events, local data
etc.)

• Harmonized with Generic Structure

Template

• Revision of data types concept

AUTOSAR
2009-12-04 3.1.4
Administration • Added variant handling

• Added debugging support

• Added support for measurement and

calibration

• General rework of implementation

description
AUTOSAR
2008-08-13 3.1.1 • Added OBD Features
Administration
AUTOSAR
2008-02-01 3.0.2 • Layout adaptations
Administration
AUTOSAR
2007-12-21 3.0.1 • Initial Release
Administration

4 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Disclaimer

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

5 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Contents
1 General Information 14
1.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Input Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Imposition Times of Constraints . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Use Cases and Modeling Approach 18
2.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Three Layer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Several Implementations of the same BSW Module or BSW Cluster . . 21
2.4 Relation to SwComponentType . . . . . . . . . . . . . . . . . . . . . . 21
3 BSW Module Description Overview 23

4 BSW Interface 30
4.1 BSW Module Entry . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 30
4.2 BSW Mode Declaration . . . . . . . . . . . . . . . . . . . . .
. . . . . 41
4.3 BSW Trigger Declaration . . . . . . . . . . . . . . . . . . . . .
. . . . . 45
4.4 BSW Module Dependency . . . . . . . . . . . . . . . . . . . .
. . . . . 46
4.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 46
4.4.2 Dependency and Packages . . . . . . . . . . . . . .
. . . . . 48
4.4.3 Dependency: Examples and Constraints . . . . . .
. . . . . 49
4.5 BswModuleEntry Relationship Set . . . . . . . . . . . . . .
. . . . . 50
4.6 BSW Inter-Partition Interface . . . . . . . . . . . . . . . . . .
. . . . . 52
4.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 52
4.6.2 Client-Server . . . . . . . . . . . . . . . . . . . . . .
. . . . . 53
4.6.3 Sender-Receiver . . . . . . . . . . . . . . . . . . . .
. . . . . 55
4.7 Count Value Sets . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 56
4.7.1 Background . . . . . . . . . . . . . . . . . . . . . .
. . . . . 56
4.7.2 AccessCountSets . . . . . . . . . . . . . . . . . . .
. . . . . 56
4.7.3 Definition of countProfile: DISTIN-
GUISH_SINGULAR_ACCESSES . . . . . . . . . . . . . . . 59
4.7.4 Structuring of AccessCountSets . . . . . . . . . . . . . . . . 60
5 BSW Behavior 62
5.1 BSW Behavior Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 BSW Module Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.2 BSW Module Entity Attributes . . . . . . . . . . . . . . . . . 72
5.2.3 BSW Module Entity Constraints . . . . . . . . . . . . . . . . 73
5.2.4 BswCalledEntity . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.5 BswSchedulableEntity . . . . . . . . . . . . . . . . . . . . . . 75
5.2.6 BswInterruptEntity . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 BSW Module Call Point . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

5.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3.2 Direct Call Points . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.3.3 Client-Server Call Points . . . . . . . . . . . . . . . . . . . . 79
5.4 BSW Sender-Receiver Data Access . . . . . . . . . . . . . . . . . . . 81
5.5 BSW Exclusive Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6 BSW Scheduler Name Prefix . . . . . . . . . . . . . . . . . . . . . . . 85
5.7 BSW Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.7.2 Timing and Background Events . . . . . . . . . . . . . . . . . 88
5.7.3 Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.7.4 Mode Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.7.5 BSW Events for Client-Server Communication . . . . . . . . 96
5.7.6 BSW Events for Sender-Receiver Communication . . . . . . 98
5.8 Activation Reason of a BSW Module Entity . . . . . . . . . . . . . . . . 99
5.9 BSW Communication Policy . . . . . . . . . . . . . . . . . . . . . . . . 101
5.10 BSW Local Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.11 Synchronization with a Corresponding SWC . . . . . . . . . . . . . . . 108
5.12 BSW Behavior Distributed over Partitions . . . . . . . . . . . . . . . . 115
6 BSW Implementation 119
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2 Configuration Parameter Definitions and Values as Part of a BSWMD . 122
7 Implementation 125
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.2 Implementation Description Overview . . . . . . . . . . . . . . . . . . . 125
7.3 Assertions and Requirements . . . . . . . . . . . . . . . . . . . . . . . 128
7.4 Implementation of a Software Component . . . . . . . . . . . . . . . . 128
7.5 Linking to Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.6 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.7 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.8 Linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.9 Build Action Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8 ResourceConsumption 136
8.1 Static and Dynamic Resources . . . . . . . . . . . . . . . . . . . . . . 136
8.2 Resource consumption overview . . . . . . . . . . . . . . . . . . . . . 136
8.3 Static Memory Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.3.2 Memory Sections . . . . . . . . . . . . . . . . . . . . . . . . 139
8.4 Dynamic Memory Needs . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.2 Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.3 Heap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.5 Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8.5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8.5.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

7 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

8.5.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

8.5.3.1 Assertions Versus Requirements . . . . . . . . . . . 154
8.5.3.2 In Scope . . . . . . . . . . . . . . . . . . . . . . . . . 154
8.5.3.3 Out of Scope . . . . . . . . . . . . . . . . . . . . . . 155
8.5.4 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.5.4.1 Dependency of the Execution Time on Hardware . . 155
8.5.4.2 Dependency on Hardware State . . . . . . . . . . . 156
8.5.4.3 Dependency on Logical Context . . . . . . . . . . . . 157
8.5.4.4 Dependency on External Code . . . . . . . . . . . . 157
8.5.5 Description-Model for the Execution Time . . . . . . . . . . . 158
8.5.5.1 Detailed Structure of an Execution-Time Description 158
8.5.5.2 ExecutionTime References an "ECU" . . . . . . . . . 160
8.5.5.3 ExecutionTime Includes a HW-Configuration . . . . . 160
8.5.5.4 ExecutionTime Includes a MemorySectionLocation . 161
8.5.5.5 ExecutionTime Includes a SoftwareContext . . . . . 162
8.5.5.6 Dependency on External Libraries . . . . . . . . . . 163
8.5.5.7 Several Qualities of Execution Times . . . . . . . . . 163
9 Measurement and Calibration Support 169
9.1 Overview on McSupportData . . . . . . . . . . . . . . . . . . . . . . . 169
9.2 Attributes for McSupportData . . . . . . . . . . . . . . . . . . . . . . . 175
9.3 Support for Software Emulation of Calibration Data . . . . . . . . . . . 179
9.4 Support for Functional Modeling of Measurement and Calibration . . . 185
9.5 Support for Structuring of Measurement and Calibration . . . . . . . . 189
9.6 McSupportData for Rapid Prototyping . . . . . . . . . . . . . . . . . . 193
9.7 Rapid Prototyping support data . . . . . . . . . . . . . . . . . . . . . . 198
9.7.1 Rapid Prototyping support for software components or basic
software modules . . . . . . . . . . . . . . . . . . . . . . . . 198
9.7.2 Differentiation of execution contexts . . . . . . . . . . . . . . 204
10 BSW Variant Handling 211
10.1 BSW Interface Variation Points . . . . . . . . . . . . . . . . . . . . . . 211
10.2 BSW Behavior Variation Points . . . . . . . . . . . . . . . . . . . . . . 214
10.3 BSW Implementation Variation Points . . . . . . . . . . . . . . . . . . . 216
11 Implementation Conformance Statement 218
11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
11.2 Interface Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
11.3 Internal Behavior Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
11.4 Implementation Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
11.5 Configuration and Variants . . . . . . . . . . . . . . . . . . . . . . . . . 221
12 BSW Service Needs 223
12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
12.2 Specific Service Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
12.2.1 NvM Service Dependencies . . . . . . . . . . . . . . . . . . 237
12.2.1.1 Nvm Use Case: Permanent RAM Block . . . . . . . . 237

8 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.2.1.2 Nvm Use Case: Temporary RAM Block . . . . . . 239

12.2.1.3 Nvm Use Case: RAM Block with explicit synchro-
nization . . . . . . . . . . . . . . . . . . . . . . . . . 240
12.2.2 Diagnostic Service Dependency . . . . . . . . . . . . . . . . 242
12.2.2.1 Function Inhibition Needs . . . . . . . . . . . . . . . 242
12.2.2.2 Diagnostic Event Needs . . . . . . . . . . . . . . . . 243
12.2.2.3 Diagnostic Communication Needs . . . . . . . . . . 245
12.2.2.4 OBD Service Needs . . . . . . . . . . . . . . . . . . 252
12.2.3 Watchdog Service Dependencies . . . . . . . . . . . . . . . 253
12.2.4 Watchdog Service use Case: Local Supervision . . . . . . . 253
12.2.5 Watchdog Service use Case: Control global supervision or
get global supervision status . . . . . . . . . . . . . . . . . . 255
12.2.6 ECU State Manager Service Needs . . . . . . . . . . . . . . 256
12.2.6.1 EcuM Flex Use Case: select Shutdown Target . . . . 256
12.2.6.2 EcuM Flex Use Case: select Boot Target . . . . . . . 257
12.2.6.3 EcuM Flex Use Case: use Alarm Clock . . . . . . . 257
12.3 Basic Software Production Errors . . . . . . . . . . . . . . . . . . . . . 258
12.4 Error Tracer Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
12.4.1 Default Error Tracer Service use Case: report failure . . . . . 264
12.5 Hardware Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 264
12.5.1 HtssM Service Use Case: Query results of hardware tests . 265
A Reference Material 266
A.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
A.2 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 266
B Glossary 271

C Constraint and Specification History 275

C.1 Constraint History of this Document according to AUTOSAR R4.0.1 . . 275
C.1.1 Changed Constraints in R4.0.1 . . . . . . . . . . . . . . . . . 275
C.1.2 Added Constraints in R4.0.1 . . . . . . . . . . . . . . . . . . 275
C.1.3 Deleted Constraints . . . . . . . . . . . . . . . . . . . . . . . 276
C.2 Constraint History of this Document according to AUTOSAR R4.0.2 . . 276
C.2.1 Changed Constraints in R4.0.2 . . . . . . . . . . . . . . . . . 276
C.2.2 Added Constraints in R4.0.2 . . . . . . . . . . . . . . . . . . 276
C.2.3 Deleted Constraints in R4.0.2 . . . . . . . . . . . . . . . . . . 276
C.3 Constraint History of this Document according to AUTOSAR R4.0.3 . . 276
C.3.1 Changed Constraints in R4.0.3 . . . . . . . . . . . . . . . . . 276
C.3.2 Added Specification Items in R4.0.3 . . . . . . . . . . . . . . 276
C.3.3 Added Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 278
C.3.4 Deleted Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 278
C.4 Constraint History of this Document according to AUTOSAR R4.1.1 . . 278
C.4.1 Changed Specification Items in R4.1.1 . . . . . . . . . . . . 278
C.4.2 Changed Constraints in R4.1.1 . . . . . . . . . . . . . . . . . 279
C.4.3 Added Specification Items in R4.1.1 . . . . . . . . . . . . . . 279
C.4.4 Added Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 280

9 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.4.5 Deleted Specification Items in R4.1.1 . . . . . . . . . . . . . 280

C.4.6 Deleted Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 280
C.5 Constraint History of this Document according to AUTOSAR R4.2.1 . . 281
C.5.1 Changed Constraints in R4.2.1 . . . . . . . . . . . . . . . . . 281
C.5.2 Added Constraints in R4.2.1 . . . . . . . . . . . . . . . . . . 281
C.5.3 Deleted Constraints in R4.2.1 . . . . . . . . . . . . . . . . . . 281
C.5.4 Changed Specification Items in R4.2.1 . . . . . . . . . . . . 281
C.5.5 Added Specification Items in R4.2.1 . . . . . . . . . . . . . . 281
C.5.6 Deleted Specification Items in R4.2.1 . . . . . . . . . . . . . 282
C.6 Constraint History of this Document according to AUTOSAR R4.2.2 . . 282
C.6.1 Added Specification Items in 4.2.2 . . . . . . . . . . . . . . . 282
C.6.2 Changed Specification Items in 4.2.2 . . . . . . . . . . . . . 282
C.6.3 Deleted Specification Items in 4.2.2 . . . . . . . . . . . . . . 282
C.6.4 Added Constraints in 4.2.2 . . . . . . . . . . . . . . . . . . . 283
C.6.5 Changed Constraints in 4.2.2 . . . . . . . . . . . . . . . . . . 283
C.6.6 Deleted Constraints in 4.2.2 . . . . . . . . . . . . . . . . . . 283
C.7 Constraint History of this Document according to AUTOSAR R4.3.0 . . 283
C.7.1 Added Specification Items in 4.3.0 . . . . . . . . . . . . . . . 283
C.7.2 Changed Specification Items in 4.3.0 . . . . . . . . . . . . . 284
C.7.3 Deleted Specification Items in 4.3.0 . . . . . . . . . . . . . . 285
C.7.4 Added Constraints in 4.3.0 . . . . . . . . . . . . . . . . . . . 285
C.7.5 Changed Constraints in 4.3.0 . . . . . . . . . . . . . . . . . . 285
C.7.6 Deleted Constraints in 4.3.0 . . . . . . . . . . . . . . . . . . 285
C.8 Constraint History of this Document according to AUTOSAR R4.3.1 . . 286
C.8.1 Added Specification Items in 4.3.1 . . . . . . . . . . . . . . . 286
C.8.2 Changed Specification Items in 4.3.1 . . . . . . . . . . . . . 286
C.8.3 Deleted Specification Items in 4.3.1 . . . . . . . . . . . . . . 286
C.8.4 Added Constraints in 4.3.1 . . . . . . . . . . . . . . . . . . . 286
C.8.5 Changed Constraints in 4.3.1 . . . . . . . . . . . . . . . . . . 287
C.8.6 Deleted Constraints in 4.3.1 . . . . . . . . . . . . . . . . . . 287
C.9 Constraint History of this Document according to AUTOSAR R4.4.0 . . 287
C.9.1 Added Specification Items in 4.4.0 . . . . . . . . . . . . . . . 287
C.9.2 Changed Specification Items in 4.4.0 . . . . . . . . . . . . . 287
C.9.3 Deleted Specification Items in 4.4.0 . . . . . . . . . . . . . . 288
C.9.4 Added Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . . 288
C.9.5 Changed Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . 288
C.9.6 Deleted Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . 288
C.10 Constraint History of this Document according to AUTOSAR R19-11 . 289
C.10.1 Added Specification Items in 19-11 . . . . . . . . . . . . . . 289
C.10.2 Changed Specification Items in 19-11 . . . . . . . . . . . . . 289
C.10.3 Deleted Specification Items in 19-11 . . . . . . . . . . . . . . 289
C.10.4 Added Constraints in 19-11 . . . . . . . . . . . . . . . . . . . 289
C.10.5 Changed Constraints in 19-11 . . . . . . . . . . . . . . . . . 290
C.10.6 Deleted Constraints in 19-11 . . . . . . . . . . . . . . . . . . 291
C.11 Constraint History of this Document according to AUTOSAR R20-11 . 291
C.11.1 Added Specification Items in R20-11 . . . . . . . . . . . . . . 291

10 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.11.2 Changed Specification Items in R20-11 . . . . . . . . . . . . 291

C.11.3 Deleted Specification Items in R20-11 . . . . . . . . . . . . . 291
C.11.4 Added Constraints in R20-11 . . . . . . . . . . . . . . . . . . 292
C.11.5 Changed Constraints in R20-11 . . . . . . . . . . . . . . . . 292
C.11.6 Deleted Constraints in R20-11 . . . . . . . . . . . . . . . . . 292
C.12 Constraint History of this Document according to AUTOSAR R21-11 . 292
C.12.1 Added Specification Items in R21-11 . . . . . . . . . . . . . . 292
C.12.2 Changed Specification Items in R21-11 . . . . . . . . . . . . 292
C.12.3 Deleted Specification Items in R21-11 . . . . . . . . . . . . . 293
C.12.4 Added Constraints in R21-11 . . . . . . . . . . . . . . . . . . 293
C.12.5 Changed Constraints in R21-11 . . . . . . . . . . . . . . . . 293
C.12.6 Deleted Constraints in R21-11 . . . . . . . . . . . . . . . . . 294
C.13 Constraint History of this Document according to AUTOSAR R22-11 . 294
C.13.1 Added Specification Items in R22-11 . . . . . . . . . . . . . . 294
C.13.2 Changed Specification Items in R22-11 . . . . . . . . . . . . 294
C.13.3 Deleted Specification Items in R22-11 . . . . . . . . . . . . . 294
C.13.4 Added Constraints in R22-11 . . . . . . . . . . . . . . . . . . 295
C.13.5 Changed Constraints in R22-11 . . . . . . . . . . . . . . . . 298
C.13.6 Deleted Constraints in R22-11 . . . . . . . . . . . . . . . . . 298
C.14 Constraint History of this Document according to AUTOSAR R23-11 . 299
C.14.1 Added Specification Items in R23-11 . . . . . . . . . . . . . . 299
C.14.2 Changed Specification Items in R23-11 . . . . . . . . . . . . 299
C.14.3 Deleted Specification Items in R23-11 . . . . . . . . . . . . . 299
C.14.4 Added Constraints in R23-11 . . . . . . . . . . . . . . . . . . 299
C.14.5 Changed Constraints in R23-11 . . . . . . . . . . . . . . . . 299
C.14.6 Deleted Constraints in R23-11 . . . . . . . . . . . . . . . . . 299
D Mentioned Class Tables 300

E Upstream Mapping 352

E.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
E.2 ComM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
E.3 Dcm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
E.4 Dem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
E.5 EcuC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
E.6 FiM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
E.7 NvM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
E.8 Rte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
E.9 StbM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
E.10 WdgM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
E.11 Xfrm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
F Splitable Elements in the Scope of this Document 375

G Variation Points in the Scope of this Document 379

11 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

References
[1] Generic Structure Template
AUTOSAR_FO_TPS_GenericStructureTemplate
[2] Requirements on Basic Software Module Description Template
AUTOSAR_CP_RS_BSWModuleDescriptionTemplate
[3] General Requirements on Basic Software Modules
AUTOSAR_CP_SRS_BSWGeneral
[4] Methodology for Classic Platform
AUTOSAR_CP_TR_Methodology
[5] Glossary
AUTOSAR_FO_TR_Glossary
[6] Software Component Template
AUTOSAR_CP_TPS_SoftwareComponentTemplate
[7] System Template
AUTOSAR_CP_TPS_SystemTemplate
[8] AUTOSAR XML Schema Production Rules
AUTOSAR_FO_TPS_XMLSchemaProductionRules
[9] Standardization Template
AUTOSAR_FO_TPS_StandardizationTemplate
[10] Specification of RTE Software
AUTOSAR_CP_SWS_RTE
[11] List of Basic Software Modules
AUTOSAR_CP_TR_BSWModuleList
[12] Meta Data Exchange Format for Software Module Sharing V1.0 (MDX V1.0)
http://www.asam.net
ASAM-AE-MDX-V1_0_0.pdf
[13] Guide to BSW Distribution
AUTOSAR_CP_EXP_BSWDistributionGuide
[14] Virtual Functional Bus
AUTOSAR_CP_EXP_VFB
[15] Specification of Operating System
AUTOSAR_CP_SWS_OS
[16] Specification of ECU Configuration
AUTOSAR_CP_TPS_ECUConfiguration
[17] Specification of Memory Mapping
AUTOSAR_CP_SWS_MemoryMapping

12 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[18] Specification of Timing Extensions for Classic Platform

AUTOSAR_CP_TPS_TimingExtensions
[19] Specification of ECU Resource Template
AUTOSAR_CP_TPS_ECUResourceTemplate
[20] ASAM MCD-2 MC (ASAP2 / A2L)
http://www.asam.net
ASAM_AE_MCD-2_MC_BS_V1-7-1.pdf
[21] Collection of blueprints for AUTOSAR M1 models
AUTOSAR_FO_MOD_GeneralBlueprints
[22] Specification of Function Inhibition Manager
AUTOSAR_CP_SWS_FunctionInhibitionManager
[23] Specification of Diagnostic Event Manager
AUTOSAR_CP_SWS_DiagnosticEventManager
[24] Specification of Watchdog Manager
AUTOSAR_CP_SWS_WatchdogManager
[25] Specification of ECU State Manager
AUTOSAR_CP_SWS_ECUStateManager
[26] General Specification of Basic Software Modules
AUTOSAR_CP_SWS_BSWGeneral
[27] Specification of Default Error Tracer
AUTOSAR_CP_SWS_DefaultErrorTracer
[28] Basic Software Module Description Template
AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate
[29] Software Process Engineering Meta-Model Specification
http://www.omg.org/spec/SPEM/2.0/

13 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

1 General Information

1.1 Document Scope

This is the documentation of the template for the Basic Software Module Description
(BSWMDT).
The BSWMD is a formal notation of all information belonging to a certain BSW artifact
(BSW module or BSW cluster) in addition to the implementation of that artifact. There
are several possible use cases for such a description, see 2.1 for details.
The BSWMDT - the template to be used for the BSWMD - is the standardized format
which has to be used for this description in AUTOSAR. The template is represented
in UML as part of the overall AUTOSAR meta-model and is part of the XML schema
generated out of this meta-model. This document describes all the elements which
belong to this template. These elements are maintained in two different packages of
the AUTOSR meta-model:
• The package BswModuleTemplate contains all elements which are used exclu-
sively by the BSWMDT.
• Some elements of the BSWMDT, for example for the description of implementa-
tion aspects and resource consumption, are used also within the Software Com-
ponent Template (SWCT). These elements belong to the CommonStructure
package of the meta-model and are also described within this document.
For clarification, please note that the GenericStructure package of the meta-model
contains some fundamental infrastructure meta-classes and common patterns that are
described in [1]. These elements are also used within the BswModuleTemplate but
for details refer to [1].
Generic Structure provides details about
• AUTOSAR top level structure
• Commonly used meta-classes and primitives
• Variant handling
• Documentation
This document addresses people who need to have a deeper understanding of the
BSWMDT part of the meta-model, for example tool developers and those who maintain
the meta-model. It is not intended as a guideline for the BSW developers who will have
to provide the actual BSWMD, i.e. who have to "fill out" the template.
For further information on the overall goal of this document refer to the related require-
ments document, see [2].

14 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Due to the complexity of the meta-model, the text in some class-diagrams in this docu-
ment is too small to be read on printed paper of normal size. It is recommended to use
the electronic document and enlarge these diagrams on a computer screen if required.

1.2 Input Documents

The following input documents have been used to develop the BSWMDT:
• Generic Structure Template [1]
• Requirements on BSW Module Description Template [2]
• General Requirements on Basic Software Modules [3]
• AUTOSAR Methodology [4]
• AUTOSAR Glossary [5]
• Software Component Template [6]
• System Template [7]
• XML Schema Production Rules [8]

1.3 Imposition Times of Constraints

In the context of this document, only a single imposition time applies: “at the time
when the configuration of the BSW module is finished”.

1.4 Document Conventions

Technical terms are typeset in mono spaced font, e.g. PortPrototype. As a general
rule, plural forms of technical terms are created by adding "s" to the singular form, e.g.
PortPrototypes. By this means the document resembles terminology used in the
AUTOSAR XML Schema.
This document contains constraints in textual form that are distinguished from the rest
of the text by a unique numerical constraint ID, a headline, and the actual constraint
text starting after the d character and terminated by the c character.
The purpose of these constraints is to literally constrain the interpretation of the
AUTOSAR meta-model such that it is possible to detect violations of the standardized
behavior implemented in an instance of the meta-model (i.e. on M1 level).
Makers of AUTOSAR tools are encouraged to add the numerical ID of a constraint that
corresponds to an M1 modeling issue as part of the diagnostic message issued by the
tool.

15 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

The attributes of the classes introduced in this document are listed in form of class
tables. They have the form shown in the example of the top-level element AUTOSAR:
Please note that constraints are not supposed to be enforceable at any given time in an
AUTOSAR workflow. During the development of a model, constraints may legitimately
be violated because an incomplete model will obviously show inconsistencies.
However, at specific points in the workflow, constraints shall be enforced as a safeguard
against misconfiguration.
The points in the workflow where constraints shall be enforced, sometimes also known
as the "binding time" of the constraint, are different for each model category, e.g. on the
classic platform, the constraints defined for software-components are typically enforced
prior to the generation of the RTE while the constraints against the definition of an Ecu
extract shall be applied when the Ecu configuration for the Com stack is created.
For each document, possible binding times of constraints are defined and the binding
times are typically mentioned in the constraint themselves to give a proper orientation
for implementers of AUTOSAR authoring tools.
Let AUTOSAR be an example of a typical class table. The first rows in the table have
the following meaning:
Class: The name of the class as defined in the UML model.
Package: The UML package the class is defined in. This is only listed to help locating
the class in the overall meta model.
Note: The comment the modeler gave for the class (class note). Stereotypes and UML
tags of the class are also denoted here.
Base Classes: If applicable, the list of direct base classes.
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

16 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

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

17 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

2 Use Cases and Modeling Approach

2.1 Use Cases

There are several possible use cases for the BSWMDT. The following uses cases can
be applied for BSW modules (ICC3 conformance class) or for BSW clusters (ICC2
conformance class) and for libraries. For convenience we often use the word "module"
in this document as a synonym for all three types of artifacts.
A library can be seen as a special kind of module which provides services to be used
within the basic or application software and which are accessed via direct function calls.
Thus the following use cases can also be applied to a library. The main difference
between a library and a "normal" BSW module is, that library services can directly be
called from application SWCs without going via the RTE. As a consequence, there will
be certain restrictions on the model elements which can be used for libraries, e.g. a
library should not have scheduled functions. However, these restrictions are currently
not formalized.
• The BSWMDT can be used to specify a BSW module or cluster (or a set of those)
in terms of interfaces and dependencies before it is actually implemented. Details
of the internal behavior and implementation are not filled out for this use case.
Since the BSWMDT includes variation points, several variants of a BSW module
or cluster can be described by a single specification (for details see chapter 10).
According to the Methodology [4], artifacts on this level are delivered as BSW
Design Bundle as a result of the activity Design Basic Software.
• The BSWMDT can be used as input for a conformance test which tests the
conformance of the product (a module, cluster or library) with respect to the
AUTOSAR standard. In other words this means that for a conformance test the
BSWMD shall be usable as an ICS (implementation conformance statement).
See 11 for details. According to the Methodology, artifacts on this level are de-
livered as BSW Module ICS Bundle. Note that this delivery has to be distin-
guished from the following one (the BSW Module Delivered Bundle) because
conformance tests require completely configured software.
• The BSWMDT can be used to describe an actually implemented BSW module or
cluster delivered to the integrator of an AUTOSAR ECU. It will contain details of
the internal behavior, the implementation and constraints w.r.t. the specification.
Especially, there may be more than one implementation (for example for different
processors) which have the same specification. According to the Methodology,
artifacts on this level are part of a BSW Module Delivered Bundle as a result of
the activity Develop BSW Module (the same delivery also contains the code, as
far it is not generated during integration).
• The BSWMDT does not only serve as an "upstream" template - i.e. as a for-
mat for information provided prior to ECU configuration time - but certain parts
of the BSWMD can be used by the integrator to add further information or ad-
just information which was not available at the delivery time of the module. In

18 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

the Methodology, artifacts on this level are part of the BSW Module Integration
Bundle and they are created or refined during the activity Integrate Software
for ECU.
This use case includes for example adding documentation about the actual re-
source consumption and adding information in response to the needs of software
components and other BSW modules integrated on the ECU (see chapter 4.4).
• Similar to the last case, the BSWMDT allows to add data which are generated
from the ‘upstream” descriptions in order to support measurement and calibration
tools (see chapter 9).
• The source code which implements the RTE and the BSW Scheduler is typi-
cally generated completely during ECU integration. Therefore the parts of the
BSWMD which documents the implementation of this code (e.g. version informa-
tion, memory sections, data structures for calibration support), shall be generated
or updated by the RTE generator (see [10] for mandatory parts to be generated).
Details of the work flow for the different use cases are not in the scope of this document
(please refer to [4]), but the information to be provided in these various steps influences
the meta-model of the BSWMDT.
There is only limited use for the BSWMDT to describe software according to ICC1
conformance class, because in this case the complete BSW (including RTE) on an
ECU consists of one single cluster, so that no interfaces or dependencies within the
BSW can be described by this template, which means that the relevant parts of the
template will be empty. However, even in this case the BSWMDT may be used to
document implementation aspects (e.g. the required compiler, resource consumption
or vendor specific configuration parameters).

2.2 Three Layer Approach

The meta-model of the BSWMDT consists of three abstraction layers similar to the
SWCT. This approach allows for a better reuse of the more abstract parts of the de-
scription. An overview is shown in Figure 2.1.

19 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
AtpBlueprint
AtpBlueprintable
AtpStructureElement
BswModuleDescription

+ moduleId: PositiveInteger [0..1]

«atpSplitable»

+internalBehavior 0..*

InternalBehavior
BswInternalBehavior

+behavior 0..1

Implementation
BswImplementation

+ arReleaseVersion: RevisionLabelString [0..1]

+ vendorApiInfix: Identifier [0..1]

Figure 2.1: Three Layers of the BSW Module Description

The upper layer, the BswModuleDescription, contains the specification of all the
provided and required interfaces including the dependencies to other modules.
The middle layer, the BswInternalBehavior, contains a model of some basic ac-
tivity inside the module. This model defines the requirements of the module for the
configuration of the OS and the BSW Scheduler. There may be several different in-
stances of BswInternalBehavior based on the same BswModuleDescription
(even on the same CPU, for example several drivers adhering to the same BswMod-
uleDescription). The term "behavior" has been chosen in analogy to a similar term
in the SWCT. Note that it is restricted only to the scheduling behavior here and does
not describe the algorithmic behavior of the module or cluster.
The bottom layer, the BswImplementation contains information on the individual
code. Again, there may be several instances of BswImplementation for the same
BswInternalBehavior.
The usage of splitable aggregations resp. references between these layers instead
of “ordinary” aggregations allows for more flexibility in the XML artifacts: If for exam-
ple the BswInternalBehavior would aggregate BswImplementation, a concrete
XML artifact of a BswInternalBehavior would have to be duplicated for every in-
stance of BswImplementation. By using splitable aggregations and references,
the layers may be kept in separate files and also the lower layers can be modified in
later project phases. This is analog to the inclusion of header files in a C-source file:
Several implementation files can share the same header file which typically declares
more abstract things as function prototypes and the like. The relation from BswMod-
uleDescription to BswInternalBehavior is a splitable aggregation instead
of a reference for semantical reasons and in analogy to the SWCT.

20 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

2.3 Several Implementations of the same BSW Module or BSW

Cluster
According to the three layer approach, the meta-class BswModuleDescription and
an aggregated BswInternalBehavior describe a type of a BSW module or clus-
ter, for which different implementations may exist which are represented by different
BswImplementations (note that the name of the meta-class BswModuleDescrip-
tion is misleading here, because this meta-class does not contain the complete de-
scription of a module or cluster).
In case the different implementations of a BSW module or cluster are compiled for
different CPUs, the corresponding BSWMDs can be treated as separate artifacts which
may share the BswModuleDescription and/or BswInternalBehavior.
In case the implementations are compiled for the same CPU, i.e. are integrated on
the same ECU and same address space (for example CAN drivers for several CAN
channels), their BSWMDs still should share the BswModuleDescription and (in
case it is equal) the BswInternalBehavior, but there has to be a mechanism to
ensure, that the globally visible C symbols derived from the BswModuleDescription
and BswInternalBehavior are unique. This is handled with infixes defined in the
implementation part of the BSWMDT (see chapters 4.1 and 6).

2.4 Relation to SwComponentType

Some BSW modules or clusters not only have interfaces to other BSW modules or
clusters, but have also more abstract interfaces accessed from Application SW-Cs via
the RTE. These BSW modules or clusters can be AUTOSAR Services, part of the ECU
Abstraction, or Complex Drivers.
The more abstract interfaces required here are called AUTOSAR Interfaces (see [6]
and [5]).
These AUTOSAR Interfaces are described by means of the Software Component Tem-
plate (SWCT), they consist of ports, port interfaces and their further detailing. The root
classes of the SWCT used to describe these elements for BSW modules are Ser-
viceSwComponentType, EcuAbstractionSwComponentType and ComplexDe-
viceDriverSwComponentType (see [6]) which all are derived from AtomicSwCom-
ponentType.
In addition, the function calls from the RTE into these BSW module shall be modeled
as RunnableEntity-s which are also contained in the SWCT. The root class of the
SWCT used to describe the RunnableEntity-s (and a few other things) is called
SwcInternalBehavior.
[TPS_BSWMDT_04000] BSW modules with AUTOSAR Interfaces dThus for BSW
modules or clusters which can be accessed via AUTOSAR Interfaces there shall be

21 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

an XML-artifact defining an AtomicSwComponentType and an SwcInternalBe-

havior in addition to the BSWMD.c(RS_BSWMD_00001, RS_BSWMD_00039, RS_-
BSWMD_00055, RS_BSWMD_00058)
These additional descriptions are required to generate the RTE. Note that in the case
of AUTOSAR Services the content of these additional descriptions can vary between
different ECUs (for example due to the number of ports the RTE has to create for
an AUTOSAR Service) and thus have to be created per ECU. The detailed steps for
creating these artifacts are described in [6].
In order to trace the dependencies between these additional SWCT descriptions and
the associated BSWMD, there is a mapping between the classes SwcInternalBe-
havior and BswInternalBehavior, see chapter 5.11 for details.
Due to the usage of two different templates for the description of modules mentioned
above (i.e. those which have ports for connection to the application software) there is a
certain ambiguity how to described the scheduling: With the help of an event model de-
fined in the BSWMDT (see chapter 5 in this document) or with an event model defined
in the SwcInternalBehavior of the SWCT. The two different event models result in
different interfaces toward the RTE (the BSW-Scheduler-style C-interfaces resp. the
SWC-style C-interfaces which are both generated during RTE contract phase). For
the standardized AUTOSAR Services defined up to now the SWC-style interfaces are
only used for function calls directly related to communication via ports, whereas for
e.g. cyclic events the BSW-Scheduler interfaces shall be used. Note, that there is no
such rule for the BSW parts which are not standardized (ECU Abstraction and Complex
Drivers).
Another special case arises when the BSW Scheduler or an interrupt routine triggers a
cyclic function which then has to call into the RTE in order to access an SWC. In order
to generate the RTE API with the means of the current SWCT, it is required to specify
a RunnableEntity in this case even if it is not triggered by an RTE event.

22 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

3 BSW Module Description Overview

Figure 3.1 and the following class table show all the relations of the BSWMDT top layer,
the BswModuleDescription.
ARElement
+bswModuleDocumentation SwComponentDocumentation
AtpBlueprint
AtpBlueprintable «atpVariation,atpSplitable» 0..1
AtpStructureElement A
BswModuleDescription

+ moduleId: PositiveInteger [0..1] +implementedEntry ARElement

AtpBlueprint
«atpVariation,atpSplitable» 0..* AtpBlueprintable
+expectedEntry BswModuleEntry

«atpVariation,atpSplitable» 0..*

+bswModuleDependency Identifiable
BswModuleDependency
«atpVariation,atpSplitable» 0..*
+targetModuleRef + targetModuleId: PositiveInteger [0..1]

0..1 «atpUriDef,atpVariation,atpSplitable»

AtpPrototype
+providedModeGroup ModeDeclarationGroupPrototype

«atpVariation,atpSplitable» 0..* + swCalibrationAccess:

SwCalibrationAccessEnum [0..1]
+requiredModeGroup

«atpVariation,atpSplitable» 0..*

+releasedTrigger AtpStructureElement
Identifiable
«atpVariation,atpSplitable» 0..* Trigger

+requiredTrigger + swImplPolicy: SwImplPolicyEnum [0..1]

«atpVariation,atpSplitable» 0..*

+providedClientServerEntry
Referrable
«atpVariation,atpSplitable» 0..* BswModuleClientServerEntry
+requiredClientServerEntry + isReentrant: Boolean [0..1]
«atpVariation,atpSplitable» + isSynchronous: Boolean [0..1]
0..*

+requiredData AutosarDataPrototype
«atpVariation,atpSplitable» 0..* VariableDataPrototype
+providedData

«atpVariation,atpSplitable» 0..*

«atpSplitable»

+internalBehavior 0..*

InternalBehavior
+arTypedPerInstanceMemory
BswInternalBehavior
«atpVariation,atpSplitable» 0..*

Figure 3.1: BSW Module Description Overview

[TPS_BSWMDT_04079] Usage of module shortName dFor a standardized module

of ICC3 conformance class the BswModuleDescription.shortName shall be cho-
sen identical to the module abbreviation (resp. library abbreviation) defined in [11].c
(RS_BSWMD_00001)
In addition, the BswModuleDescription contains an attribute moduleId:

23 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_4019] BSW module identifier dBswModuleDescription.moduleId shall

refer to the identifier of the standardized AUTOSAR modules according to [11], if appli-
cable1 . Otherwise (e.g. for ICC2 clusters) the identifier shall either be empty or chosen
differently from the ones given in [11].c()
[TPS_BSWMDT_04071] Usage of module identifier and category dIn any case, this
identifier in the BSWMD shall be used to document the relation of an artifact to the
standard and thus is a useful information for the conformance test. In addition to this,
the generic category attribute (inherited from Identifiable) shall be used for a
general classification of a BswModuleDescription as shown in the following table.
This allows to check for constraints.c(RS_BSWMD_00001, RS_BSWMD_00014, RS_-
BSWMD_00051)
[constr_4020] Allowed categories of BswModuleDescription d

category Explanation
BSW_MODULE Specifies a single BSW module (ICC3 granularity).
BSW_CLUSTER Specifies a BSW module cluster (ICC2 granularity).
LIBRARY Specifies a Library (not restricted to be used within the BSW).

c()
Note that other values or an empty value are not allowed for BswModuleDescrip-
tion.
[TPS_BSWMDT_04001] Attaching SwComponentDocumentation to a BSWMD dIt
is possible to attach documentation to a BswModuleDescription by using the meta-
class SwComponentDocumentation. This uses the same concept as the documen-
tation for software components and is described in detail in [6].c(RS_BSWMD_00001,
RS_BSWMD_00025)
The meta-class BswModuleEntry describes a single C-function prototype (see chap-
ter 4.1) and is used here as follows:
[TPS_BSWMDT_04002] Provision of BswModuleEntry dThe interface exported by
a BswModuleDescription is the set of implementedEntry-s provided for the us-
age by other modules (including "main"-functions called by the BSW Scheduler).c(RS_-
BSWMD_00039, RS_BSWMD_00041)
[TPS_BSWMDT_04153] Usage of BswModuleEntry dThe interface required by a
BswModuleDescription is the set of expectedEntry-s implemented by other
modules.c(RS_BSWMD_00039, RS_BSWMD_00041)
[TPS_BSWMDT_04130] Linkage of BswModuleEntry dBswModuleEntry refer-
enced as implementedEntry by one BswModuleDescription and a BswMod-
uleEntry referenced as expectedEntry by another BswModuleDescription are
matching if one of the following applies:
• The identical BswModuleEntry is referenced
1
Note that there may be more than one module in an ECU software with the same identifier, e.g.
according to the standard Complex Drivers all have the same identifier.

24 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

or
• the 2 BswModuleEntry.shortNames are identical.
c(RS_BSWMD_00039, RS_BSWMD_00041)
[constr_4093] Entries linked to BswModuleEntrys shall have compatible signa-
ture dMatching BswModuleEntrys according to [TPS_BSWMDT_04130] are compat-
ible if the following condtions are fullfilled:
• both or neither of them define a returnType
• when the returnTypes are defined, the SwServiceArgs in the role return-
Type shall be compatible
• both define the same number of compatible arguments in same order
c()
[constr_4094] compatibility of SwServiceArg in role returnType dSwSer-
viceArg in role returnType are compatible if they are identically typedc()
[constr_4095] Compatibility of SwServiceArg in role argument dSwServiceArg
in role returnType are compatible if:
• they are identically typed
and
• if both do have the same shortName
c()

[constr_4096] Matching BswModuleEntrys should have compatible attributes

dMatching BswModuleEntrys according to [TPS_BSWMDT_04130] should be de-
fined with identical values of the attributes
• callType
• executionContext
• isReentrant
• isSynchronous
• serviceId
• swServiceImplPolicy
• bswEntryKind
c()

25 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04004] BswModuleDescription.providedModeGroup dWith the

optional attribute providedModeGroup a BSW module can provide a set of modes
(mode group) in order to control other BSW modules which in turn have to declare a
corresponding requiredModeGroup.c(RS_BSWMD_00054, RS_BSWMD_00056)
[TPS_BSWMDT_04005] BswModuleDescription.releasedTrigger dWith the
optional attribute releasedTrigger a BSW module can declare a trigger which it
releases. A trigger is used to raise events in other BSW modules which in turn have to
declare a corresponding requiredTrigger.c(RS_BSWMD_00057)
[TPS_BSWMDT_04006] BswModuleDescription.internalBehavior dBy the
aggregation of class BswInternalBehavior in BswModuleDescription it is
possible to add scheduling aspects to the description.c(RS_BSWMD_00030, RS_-
BSWMD_00046)
The declaration of function calls, dependencies, triggers and modes make up the inter-
face of a module or cluster to be used for communication among modules on the same
memory and processor core. The details are described in chapter 4.
For communication between partition and/or core boundaries, additional declarations
are required, see chapter 4.6
For BswInternalBehavior see chapter 5.
Class BswModuleDescription
Package M2::AUTOSARTemplates::BswModuleTemplate::BswOverview
Note Root element for the description of a single BSW module or BSW cluster. In case it describes a BSW
module, the short name of this element equals the name of the BSW module.
Tags: atp.recommendedPackage=BswModuleDescriptions
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpFeature, AtpStructureElement,
CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Aggregated by ARPackage.element, AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
bswModule BswModuleDependency * aggr Describes the dependency to another BSW module.
Dependency
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=bswModuleDependency.shortName, bsw
ModuleDependency.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=20
bswModule SwComponent 0..1 aggr This adds a documentation to the BSW module.
Documentation Documentation
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=bswModuleDocumentation, bswModule
Documentation.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=6
5

26 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleDescription
expectedEntry BswModuleEntry * ref Indicates an entry which is required by this module.
Replacement of outgoingCallback / requiredEntry.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=expectedEntry.bswModuleEntry, expected
Entry.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
implemented BswModuleEntry * ref Specifies an entry provided by this module which can be
Entry called by other modules. This includes "main" functions,
interrupt routines, and callbacks. Replacement of
providedEntry / expectedCallback.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=implementedEntry.bswModuleEntry,
implementedEntry.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
internalBehavior BswInternalBehavior * aggr The various BswInternalBehaviors associated with a Bsw
ModuleDescription can be distributed over several
physical files. Therefore the aggregation is <<atp
Splitable>>.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=internalBehavior.shortName
xml.sequenceOffset=65
moduleId PositiveInteger 0..1 attr Refers to the BSW Module Identifier defined by the
AUTOSAR standard. For non-standardized modules, a
proprietary identifier can be optionally chosen.
Tags: xml.sequenceOffset=5
providedClient BswModuleClientServer * aggr Specifies that this module provides a client server entry
ServerEntry Entry which can be called from another partition or core.This
entry is declared locally to this context and will be
connected to the requiredClientServerEntry of another or
the same module via the configuration of the BSW
Scheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=providedClientServerEntry.shortName,
providedClientServerEntry.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=45
providedData VariableDataPrototype * aggr Specifies a data prototype provided by this module in
order to be read from another partition or core.The
providedData is declared locally to this context and will be
connected to the requiredData of another or the same
module via the configuration of the BSW Scheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=providedData.shortName, provided
Data.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=55
5

27 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleDescription
providedMode ModeDeclarationGroup * aggr A set of modes which is owned and provided by this
Group Prototype module or cluster. It can be connected to the required
ModeGroups of other modules or clusters via the
configuration of the BswScheduler. It can also be
synchronized with modes provided via ports by an
associated ServiceSwComponentType, EcuAbstraction
SwComponentType or ComplexDeviceDriverSw
ComponentType.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=providedModeGroup.shortName, provided
ModeGroup.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=25
releasedTrigger Trigger * aggr A Trigger released by this module or cluster. It can be
connected to the requiredTriggers of other modules or
clusters via the configuration of the BswScheduler. It can
also be synchronized with Triggers provided via ports by
an associated ServiceSwComponentType, Ecu
AbstractionSwComponentType or ComplexDeviceDriver
SwComponentType.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=releasedTrigger.shortName, released
Trigger.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=35
requiredClient BswModuleClientServer * aggr Specifies that this module requires a client server entry
ServerEntry Entry which can be implemented on another partition or
core.This entry is declared locally to this context and will
be connected to the providedClientServerEntry of another
or the same module via the configuration of the BSW
Scheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=requiredClientServerEntry.shortName,
requiredClientServerEntry.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=50
requiredData VariableDataPrototype * aggr Specifies a data prototype required by this module in oder
to be provided from another partition or core.The required
Data is declared locally to this context and will be
connected to the providedData of another or the same
module via the configuration of the BswScheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=requiredData.shortName, required
Data.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=60
5

28 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleDescription
requiredMode ModeDeclarationGroup * aggr Specifies that this module or cluster depends on a certain
Group Prototype mode group. The requiredModeGroup is local to this
context and will be connected to the providedModeGroup
of another module or cluster via the configuration of the
BswScheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=requiredModeGroup.shortName, required
ModeGroup.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=30
requiredTrigger Trigger * aggr Specifies that this module or cluster reacts upon an
external trigger.This requiredTrigger is declared locally to
this context and will be connected to the providedTrigger
of another module or cluster via the configuration of the
BswScheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=requiredTrigger.shortName, required
Trigger.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=40

Table 3.1: BswModuleDescription

29 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4 BSW Interface
This chapter describes the meta-model elements which are used to define the interface
level of a BSW module: The description of implementedEntry-s, expectedEn-
try-s, declaration of mode groups, declaration of triggers, dependencies from other
modules and the interfaces for inter-partition communication.

4.1 BSW Module Entry

[TPS_BSWMDT_04007] BswModuleEntry dThe meta-class BswModuleEntry is
used to model the signature of a C-function callc(RS_BSWMD_00011, RS_BSWMD_-
00038, RS_BSWMD_00041, RS_BSWMD_00042), see figure 4.1.

30 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement +argument Identifiable

AtpBlueprint SwServiceArg
AtpBlueprintable «atpVariation,atpSplitable»0..* {ordered}
BswModuleEntry + direction:
+returnType ArgumentDirectionEnum
+ bswEntryKind: BswEntryKindEnum [0..1] [0..1]
+ callType: BswCallType [0..1] 0..1
+ executionContext: BswExecutionContext [0..1]
+ functionPrototypeEmitter: NameToken [0..1]
+ isReentrant: Boolean [0..1]
+ isSynchronous: Boolean [0..1] +functionPointerSignature
+ role: Identifier [0..1]
0..1
+ serviceId: PositiveInteger [0..1]
+ swServiceImplPolicy: SwServiceImplPolicyEnum [0..1]

«enumeration» «enumeration» «enumeration»

BswExecutionContext BswCallType SwServiceImplPolicyEnum «atpSplitable»

task regular standard

interruptCat1 callback inline
interruptCat2 interrupt macro
hook scheduled inlineConditional
unspecified callout
+swDataDefProps
0..1

«atpVariation»
SwPointerTargetProps +swPointerTargetProps SwDataDefProps
0..1 «atpSplitable»
+ targetCategory: Identifier [0..1] + additionalNativeTypeQualifier: NativeDeclarationString
+swDataDefProps [0..1]
+ displayFormat: DisplayFormatString [0..1]
«atpSplitable» 0..1 + displayPresentation: DisplayPresentationEnum [0..1]
AtpBlueprint + stepSize: Float [0..1]
AtpBlueprintable +baseType + swAlignment: AlignmentType [0..1]
BaseType + swCalibrationAccess: SwCalibrationAccessEnum [0..1]
+ swImplPolicy: SwImplPolicyEnum [0..1]
SwBaseType 0..1
+ swIntendedResolution: Numerical [0..1]
+ swInterpolationMethod: Identifier [0..1]
+ swIsVirtual: Boolean [0..1]
AbstractImplementationDataType «atpVariation»
+ swValueBlockSize: Numerical [0..1]
ImplementationDataType
+ swValueBlockSizeMult: Numerical [0..*] {ordered}
+ dynamicArraySizeProfile: String [0..1]
+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]

«atpVariation,atpSplitable»
0..1
+swDataDefProps
0..* «atpSplitable»
+subElement {ordered}
AbstractImplementationDataTypeElement +subElement 0..*
{ordered}
ImplementationDataTypeElement

+ arrayImplPolicy: ArrayImplPolicyEnum [0..1]

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

Figure 4.1: Details of meta-class BswModuleEntry

The attributes of meta-class BswModuleEntry are shown in the following table. The
attribute serviceId is used to identify the C-function and thus is an important infor-
mation for an AUTOSAR conformance test.
[constr_4013] BSW service identifier dFor Standardized Interfaces, this identifier is
defined in the AUTOSAR Software Specification (SWS) of the module. In case the
C-function prototype represented by the entry is not standardized, it still can be used
optionally, but its value shall differ from the standardized ones.c()
[TPS_BSWMDT_04156] Usage of functionPrototypeEmitter dIf attribute
functionPrototypeEmitter is set to "RTE" the RTE shall generate the function
prototypes in the Module Interlink Header File. If the attribute is set to any other

31 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

value or does not exist, the BSW module shall generate and provide the prototype
in its header file(s).c(RS_BSWMD_00011, RS_BSWMD_00038, RS_BSWMD_00041,
RS_BSWMD_00042)
Class BswModuleEntry
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note This class represents a single API entry (C-function prototype) into the BSW module or cluster.
The name of the C-function is equal to the short name of this element with one exception: In case of
multiple instances of a module on the same CPU, special rules for "infixes" apply, see description of class
BswImplementation.
Tags: atp.recommendedPackage=BswModuleEntrys
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
argument SwServiceArg * aggr An argument belonging to this BswModuleEntry.
(ordered)
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=argument.shortName, argument.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
xml.sequenceOffset=45
bswEntryKind BswEntryKindEnum 0..1 attr This describes whether the entry is concrete or abstract.
If the attribute is missing the entry is considered as
concrete.
Tags: xml.sequenceOffset=40
callType BswCallType 0..1 attr The type of call associated with this service.
Tags: xml.sequenceOffset=25
execution BswExecutionContext 0..1 attr Specifies the execution context which is required (in case
Context of entries into this module) or guaranteed (in case of
entries called from this module) for this service.
Tags: xml.sequenceOffset=30
function NameToken 0..1 attr This attribute is used to control the generation of function
Prototype prototypes. If set to "RTE", the RTE generates the
Emitter function prototypes in the Module Interlink Header File.
isReentrant Boolean 0..1 attr Reentrancy from the viewpoint of function callers:
• true: Enables the service to be invoked again, before
the service has finished.
• false: It is prohibited to invoke the service again before
is has finished.
Tags: xml.sequenceOffset=15
isSynchronous Boolean 0..1 attr Synchronicity from the viewpoint of function callers:
• true: This calls a synchronous service, i.e. the service
is completed when the call returns.
• false: The service (on semantical level) may not be
complete when the call returns.
Tags: xml.sequenceOffset=20
returnType SwServiceArg 0..1 aggr The return type belonging to this bswModuleEntry.
Tags: xml.sequenceOffset=40
5

32 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleEntry
role Identifier 0..1 attr Specifies the role of the entry in the given context. It shall
be equal to the standardized name of the service call,
especially in cases where no ServiceIdentifier is specified,
e.g. for callbacks. Note that the ShortName is not always
sufficient because it maybe vendor specific (e.g. for
callbacks which can have more than one instance).
Tags: xml.sequenceOffset=10
serviceId PositiveInteger 0..1 attr Refers to the service identifier of the Standardized
Interfaces of AUTOSAR basic software. For
non-standardized interfaces, it can optionally be used for
proprietary identification.
Tags: xml.sequenceOffset=5
swServiceImpl SwServiceImplPolicy 0..1 attr Denotes the implementation policy as a standard function
Policy Enum call, inline function or macro. This has to be specified on
interface level because it determines the signature of the
call.
Tags: xml.sequenceOffset=35

Table 4.1: BswModuleEntry

[constr_10260] Existence of attribute BswModuleEntry.callType dFor each

BswModuleEntry, the attribute callType shall exist at the time when the
configuration of the BSW module is finished.c()
[constr_10261] Existence of attribute BswModuleEntry.executionContext dFor
each BswModuleEntry, the attribute executionContext shall exist at the time
when the configuration of the BSW module is finished.c()
[constr_10262] Existence of attribute BswModuleEntry.isReentrant dFor each
BswModuleEntry, the attribute isReentrant shall exist at the time when the
configuration of the BSW module is finished.c()
[constr_10263] Existence of attribute BswModuleEntry.isSynchronous dFor
each BswModuleEntry, the attribute isSynchronous shall exist at the time
when the configuration of the BSW module is finished.c()
[constr_10264] Existence of attribute BswModuleEntry.swServiceImplPol-
icy dFor each BswModuleEntry, the attribute swServiceImplPolicy shall ex-
ist at the time when the configuration of the BSW module is fin-
ished.c()
Enumeration BswEntryKindEnum
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note Denotes the mechanism by which the entry into the Bsw module shall be called.
Aggregated by BswModuleEntry.bswEntryKind
Literal Description
5

33 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Enumeration BswEntryKindEnum
abstract This BswModuleEntry specifies an abstract signature of C-functions. The signature needs to be
implemented by concrete BswModuleEntrys
Tags: atp.EnumerationLiteralIndex=0
concrete This BswModuleEntry specifies a concrete C-function with its signature.
Tags: atp.EnumerationLiteralIndex=1

Table 4.2: BswEntryKindEnum

Enumeration BswExecutionContext
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note Specifies the execution context required or guaranteed for the call associated with this service.
Aggregated by BswModuleEntry.executionContext
Literal Description
hook Context of an OS "hook" routine always
Tags: atp.EnumerationLiteralIndex=0
interruptCat1 CAT1 interrupt context always
Tags: atp.EnumerationLiteralIndex=1
interruptCat2 CAT2 interrupt context always
Tags: atp.EnumerationLiteralIndex=2
task Task context always
Tags: atp.EnumerationLiteralIndex=3
unspecified The execution context is not specified by the API
Tags: atp.EnumerationLiteralIndex=4

Table 4.3: BswExecutionContext

The RTE and Basic Software Scheduler do support the invocation of triggered Ex-
ecutableEntity via direct function call in some special cases. Nevertheless it shall
be prevented that an ExecutableEntity from a particular execution context calls
a triggered ExecutableEntity which requires an execution context with more
permissions. [TPS_BSWMDT_04179] lists the supported combinations.

34 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04179] Possible invocation of ExecutableEntitys by direct

function call dependent from BswExecutionContext d

caller’s callee’s BswExecutionContext

BswExecutionContext
task interruptCat2 interruptCat1 hook unspecified
task Supported Supported Supported Supported
interruptCat2 Supported Supported Supported
interruptCat1 Supported Supported
hook
unspecified Supported Supported

The execution context of a RunnableEntity is considered as task.

c()
[constr_4086] invocation of ExecutableEntitys by direct function call depen-
dent from BswExecutionContext d
The invocation of an ExecutableEntity with an interruptCat1 can be imple-
mented with a direct function call if the BswExecutionContext of the caller BswMod-
uleEntry is set to task, interruptCat2 or interruptCat1.
This applies to the invocation of a triggered ExecutableEntity by the
SchM_Trigger, SchM_ActMain or Rte_Trigger APIs, or to the invocation of
an OnEntry ExecutableEntity, OnTransition ExecutableEntity, OnExit
ExecutableEntity or mode switch acknowledge ExecutableEntity by the
SchM_Switch or Rte_Switch APIs. For more information about the technical terms
refer to [10]
c()

35 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration BswCallType
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note Denotes the mechanism by which the entry into the Bsw module shall be called.
Aggregated by BswModuleEntry.callType
Literal Description
callback Callback (i.e. the caller specifies the signature)
Tags: atp.EnumerationLiteralIndex=0
callout Callout - provide defined means to extend the functionality of an existing module. In this case caller
specifies the signature.
Tags: atp.EnumerationLiteralIndex=4
interrupt Interrupt routine
Tags: atp.EnumerationLiteralIndex=1
regular Regular API call
Tags: atp.EnumerationLiteralIndex=2
scheduled Called by the scheduler
Tags: atp.EnumerationLiteralIndex=3

Table 4.4: BswCallType

Enumeration SwServiceImplPolicyEnum
Package M2::MSR::DataDictionary::ServiceProcessTask
Note This specifies the legal values for the implementation policies for services (in AUTOSAR: BswModule
Entry-s).
Aggregated by BswModuleEntry.swServiceImplPolicy
Literal Description
inline inline service definition.
Tags: atp.EnumerationLiteralIndex=0
inlineConditional The service (in AUTOSAR: BswModuleEntry) is implemented in a way that it either resolves to an
inline function or to a standard function depending on conditions set at a later point in time.
The following two values are standardized (to be used for code sections only and exclusively to each
other):
• INLINE - The code section is declared with the keyword "inline".
• LOCAL_INLINE - The code section is declared with the keyword "static inline".
In both cases (INLINE and LOCAL_INLINE) the inline expansion depends on the compiler.
Depending on this, the code section either corresponds to an actual section in memory or is put into
the section of the caller.
Tags: atp.EnumerationLiteralIndex=1
macro macro service definition.
Tags: atp.EnumerationLiteralIndex=2
standard Standard service and default value, if nothing is defined.
Tags: atp.EnumerationLiteralIndex=3

Table 4.5: SwServiceImplPolicyEnum

[constr_4014] Call type and execution context dWithin a given BswModuleEntry,

the following constraint holds for its attributes:
• callType==’interrupt’ is not allowed together with
executionContext==’task’ or ==’hook’

36 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• callType==’scheduled’ is not allowed together with

executionContext==’interruptCat1’ or ==’interruptCat2’
• other combinations of these two enums are allowed
c()
[TPS_BSWMDT_04008] C-symbol of BswModuleEntry dThe shortName of a
BswModuleEntry shall be equal to the name of the C-function implementing it, with
one exception: In case of several instances of the same module (e.g. several CAN
drivers) on a single CPU, the C-function names shall be made unique by inserting ad-
ditional characters called "infixes". Since each BSW module instance is implemented
by a separate piece of code, the infixes are defined as part of each single BswImple-
mentation of the providing module.c(RS_BSWMD_00039, RS_BSWMD_00040) For
details see 6.
As a result, also the code of a module requiring a BswModuleEntry with infixes needs
some adjustment, but this adjustment can be made only at integration time. Currently
there is no standardized mechanisms for this task in AUTOSAR, but it can be solved
with vendor specific configuration parameters (of the requiring modules) whose values
are set at integration time according to the infixes of the actually providing modules.
[TPS_BSWMDT_04009] Usage of SwServiceArg dClass SwServiceArg 1 is used
to declare the properties of the function arguments as well as of the return type.c(RS_-
BSWMD_00039, RS_BSWMD_00040, RS_BSWMD_00041, RS_BSWMD_00042)
[constr_4106] Restriction for the value of SwServiceArg.swImplPolicy dThe
attribute SwServiceArg.swImplPolicy shall only have one of the following values:
• SwImplPolicyEnum.const
• SwImplPolicyEnum.standard
c()
[constr_4107] swImplPolicy for SwServiceArg dThe overriding value of at-
tribute swImplPolicy of a SwServiceArg shall be standard or const. This rule
shall be imposed at the time when the configuration of the BSW mod-
ule is finished.c()
[constr_4108] Restriction regarding the value of SwServiceArg.category dThe
attribute SwServiceArg.category shall only have the following values:
• VALUE2
• DATA_REFERENCE

1
SwServiceArg and its attributes belong to the meta-model part re-engineered from MSR-SW. This
subset of MSR-SW is defined by the AUTOSAR meta-model and the XML schema published as part of
an AUTOSAR release. The relevant classes are shown as green in the class diagrams. See [6] and [12]
for more explanation.
2
This option has very few valid use cases, e.g. for defining a function pointer in native C notation, for
example: int (*SwCluC_BManif_VoidFncPtrType)(void);

37 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• FUNCTION_REFERENCE
• TYPE_REFERENCE
• MACRO
c()
Please note that some regulation for the usage of SwServiceArg exist in the context
of the TPS Software Component Template [6].
Class SwServiceArg
Package M2::MSR::DataDictionary::ServiceProcessTask
Note Specifies the properties of a data object exchanged during the call of an SwService, e.g. an argument or
a return value.
The SwServiceArg can also be used in the argument list of a C-macro. For this purpose the category
shall be set to "MACRO". A reference to implementationDataType can optional be added if the actual
argument has an implementationDataType.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswModuleEntry.argument, BswModuleEntry.returnType
Attribute Type Mult. Kind Note
direction ArgumentDirection 0..1 attr Specifies the direction of the data transfer. The direction
Enum shall indicate the direction of the actual information that is
being consumed by the caller and/or the callee, not the
direction of formal arguments in C.
The attribute is optional for backwards compatibility
reasons. For example, if a pointer is used to pass a
memory address for the expected result, the direction
shall be "out". If a pointer is used to pass a memory
address with content to be read by the callee, its direction
shall be "in".
Tags: xml.sequenceOffset=10
swArraysize ValueList 0..1 aggr This turns the argument of the service to an array.
Tags: xml.sequenceOffset=20
swDataDef SwDataDefProps 0..1 aggr Data properties of this SwServiceArg.
Props
Stereotypes: atpSplitable
Tags:
atp.Splitkey=swDataDefProps
xml.sequenceOffset=30

Table 4.6: SwServiceArg

[TPS_BSWMDT_04010] SwServiceArg.swDataDefProps.implementation-
DataType d shall be used to relate the data definition to a reusable type definition
(corresponds to a C typedef). Because ImplementationDataType is an AREle-
ment and itself contains SwDataDefProps, it is possible to declare the required data
properties as part of an ImplementationDataType and reuse it as a data type by
referring to it.c(RS_BSWMD_00041, RS_BSWMD_00042)
ImplementationDataTypeElement within an ImplementationDataType allows
to declare composite types (corresponding to C-structs or -arrays).
[TPS_BSWMDT_04011] SwServiceArg.swDataDefProps.swPointerTarget-
Props d together with its category (see [6]) is used to declare an argument or return

38 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

type as a pointer to either another data object or to a function:c(RS_BSWMD_00041,

RS_BSWMD_00042)
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
Aggregated by SwDataDefProps.swPointerTargetProps
Attribute Type Mult. 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
Stereotypes: atpSplitable
Tags:
atp.Splitkey=swDataDefProps
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 BswModuleEntry.
Tags: xml.sequenceOffset=5

Table 4.7: SwPointerTargetProps

[constr_4021] Implementation policy of function pointer target d

A BswModuleEntry can only be used as target of a function pointer (SwPoint-
erTargetProps.functionPointerSignature), if its swServiceImplPolicy is
’standard’.c()
For more information on ImplementationDataType, SwBaseType and the usage
of SwServiceArg.category in relation to SwDataDefProps see [6]. This includes
the usage of category VALUE for SwServiceArg.category which supports to model
C-signatures using C-build in data types or function pointers to C-signatures using C-
build in data types. For instance: int (*SwCluC_BManif_VoidFncPtrType)(void).
Please note that for AUTOSAR Basic Software this is seen as an exceptional case
since regularly such types are abstracted via the Platform Types.
Function signatures containing the keyword void in C deserve special attention:
[constr_4056] BswModuleEntry with no returnType d
In case of an empty return type (“void” in C) the reference BswModuleEntry.return-
Type shall not be set.c()

39 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_4057] BswModuleEntry with no argument d

In case of an empty argument list (“void” in C) no reference BswModuleEntry.argu-
ment shall be set.c()
Note that nonetheless a SwBaseType exists which represents the void type as a
pointer target.
[constr_4087] Usage of category "MACRO" d
It is only allowed to use the category "MACRO" for SwServiceArg if the owning
BswModuleEntry has its swServiceImplPolicy attribute set to macro.c()
Furthermore the usage of category "MACRO" defined in chapter "Data Categories" in
[6] is restricted to SwServiceArg like defined in [constr_4087]. It is still supported that
BswModuleEntry being a macro describes its SwServiceArg with other categories
defined in table 5.7 in [6] in order to express the assumed type of the return value and
macro argument.
[TPS_BSWMDT_04012] SwServiceArg.direction d allows to declare the direction
of data flowc(RS_BSWMD_00041, RS_BSWMD_00042) (the attribute was introduced
in R4.0.3 and is optional for backwards compatibility reasons):
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.
Aggregated by ArgumentDataPrototype.direction, SwServiceArg.direction
Literal Description
in The argument value is passed to the callee.
Tags: atp.EnumerationLiteralIndex=0
inout The argument value is passed to the callee but also passed back from the callee to the caller.
Tags: atp.EnumerationLiteralIndex=1
out The argument value is passed from the callee to the caller.
Tags: atp.EnumerationLiteralIndex=2

Table 4.8: ArgumentDirectionEnum

This value shall be chosen compatible to the role and the formal signature of the
SwServiceArg instance:
[constr_4052] BswModuleEntry returnType direction d
BswModuleEntry.returnType.direction shall not have the value in or inout.c()
[constr_4053] BswModuleEntry argument direction d
If BswModuleEntry.argument.direction has the value out or inout, the corre-
sponding BswModuleEntry.argument.swDataDefProps plus eventually referred
ImplementationDataType shall be such that they result in a pointer declaration.c()

40 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

It is also possible to specify function signatures containing the keyword enum in C3 :

[TPS_BSWMDT_04091] Function signature containing the keyword enum in C
dThe respective ImplementationDataType or ImplementationDataTypeEle-
ment has to include the string “enum” in the associated SwDataDefProps.addi-
tionalNativeTypeQualifier and use an associated CompuMethod with category
TEXTTABLE.
Hints: This information can be used by a code generator to create the correct signa-
ture. In case this method is applied to generate C-style enums it should be avoided
to use the same CompuMethod as input to a generator (for example the RTE genera-
tor) that produces preprocessor literals instead. Otherwise, the enum-literals and the
preprocessor-literals might get in conflict.c(RS_BSWMD_00041, RS_BSWMD_00042)

4.2 BSW Mode Declaration

[TPS_BSWMDT_04013] Usage of BswModuleDescription.providedMode-
Group dWith the optional attribute providedModeGroup a BSW module can declare
one or more ModeDeclarationGroupPrototypes, each defining a set of modes
(mode group) which is used to control the activity of other BSW modules. Those other
modules which require to be controlled by the mode group, shall declare a compati-
ble ModeDeclarationGroupPrototype as attribute requiredModeGroup.c(RS_-
BSWMD_00054, RS_BSWMD_00056) For more information see figure 4.2.
ARElement +requiredModeGroup AtpPrototype
AtpBlueprint ModeDeclarationGroupPrototype
«atpVariation,atpSplitable» 0..*
AtpBlueprintable
AtpStructureElement + swCalibrationAccess: SwCalibrationAccessEnum [0..1]
BswModuleDescription +providedModeGroup

+ moduleId: PositiveInteger [0..1] «atpVariation,atpSplitable» 0..*

«isOfType»

0..1
{redefines
+type atpType}

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
UploadableDesignElement
ModeDeclarationGroup

+ onTransitionValue: PositiveInteger [0..1]

+modeUserErrorBehavior 0..1 +modeManagerErrorBehavior 0..1

«enumeration» ModeErrorBehavior
ModeErrorReactionPolicyEnum
+ errorReactionPolicy: ModeErrorReactionPolicyEnum [0..1]
lastMode
defaultMode

Figure 4.2: Details of BSW Interfaces for modes

For the compatibility of ModeDeclarationGroupPrototypes see [6] [constr_1074].

These declarations allow for the appropriate API generation and coordination of mode

3
Note that the usage of C-enum types is not allowed for signatures created by the RTE generator.

41 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

switches by the BSW Scheduler. Note that the configuration of the BSW Scheduler
actually determines which provided mode group is connected to which required one.
This makes the specification of the individual module independent of the overall BSW
setup.
A ModeDeclarationGroupPrototype is based on a type definition by meta-class
ModeDeclarationGroup. It is possible to use the same ModeDeclarationGroup
within the basic software and for software components above the RTE as well, there-
fore ModeDeclarationGroupPrototype and ModeDeclarationGroup are part
of the CommonStructure package of the meta-model. For more information on the
semantics of modes see [6].
By aggregation of ModeErrorBehavior a ModeDeclarationGroup can define the
behavior of mode managers and/or mode users in case of errors. This is further ex-
plained in [6], chapter “Mode Error Behavior”.
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.
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, BswModuleDescription.providedModeGroup, BswModuleDescription.required
ModeGroup, FirewallStateSwitchInterface.firewallStateMachine, FunctionGroupSet.functionGroup, Mode
SwitchInterface.modeGroup, Process.processStateMachine, StateManagementStateNotification.state
Machine
Attribute Type Mult. 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 0..1 tref The "collection of ModeDeclarations" ( = ModeDeclaration
Group) supported by a component
Stereotypes: isOfType

Table 4.9: ModeDeclarationGroupPrototype

Note that by aggregating SwCalibrationAccessEnum in the role swCalibra-

tionAccess ModeDeclarationGroupPrototype gains the ability to become mea-
surable. For the constraint on the possible values of swCalibrationAccess please
refer to [6].
Class ModeDeclarationGroup
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note A collection of Mode Declarations. Also, the initial mode is explicitly identified.
Tags: atp.recommendedPackage=ModeDeclarationGroups
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, UploadableDesignElement,
UploadablePackageElement
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
5

42 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ModeDeclarationGroup
initialMode ModeDeclaration 0..1 ref The initial mode of the ModeDeclarationGroup. This
mode is active before any mode switches occurred.
mode ModeDeclaration * aggr The ModeDeclarations collected in this ModeDeclaration
Declaration Group.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=modeDeclaration.shortName, mode
Declaration.variationPoint.shortLabel
vh.latestBindingTime=blueprintDerivationTime
modeManager ModeErrorBehavior 0..1 aggr This represents the ability to define the error behavior
ErrorBehavior expected by the mode manager in case of errors on the
mode user side (e.g. terminated mode user).
modeTransition ModeTransition * aggr This represents the avaliable ModeTransitions of the
ModeDeclarationGroup
modeUserError ModeErrorBehavior 0..1 aggr This represents the definition of the error behavior
Behavior expected by the mode user in case of errors on the mode
manager side (e.g. terminated mode manager).
onTransition PositiveInteger 0..1 attr The value of this attribute shall be taken into account by
Value the RTE generator for programmatically representing a
value used for the transition between two statuses.
Table 4.10: ModeDeclarationGroup

Class ModeDeclaration
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note Declaration of one Mode. The name and semantics of a specific mode is not defined in the meta-model.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by AtpClassifier .atpFeature, ModeDeclarationGroup.modeDeclaration
Attribute Type Mult. Kind Note
value PositiveInteger 0..1 attr The RTE shall take the value of this attribute for
generating the source code representation of this Mode
Declaration.
Table 4.11: ModeDeclaration

Class ModeTransition
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note This meta-class represents the ability to describe possible ModeTransitions in the context of a Mode
DeclarationGroup.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by AtpClassifier .atpFeature, ModeDeclarationGroup.modeTransition
Attribute Type Mult. Kind Note
enteredMode ModeDeclaration 0..1 ref This represents the entered model of the ModeTransition.
exitedMode ModeDeclaration 0..1 ref This represents the exited mode of the ModeTransition

Table 4.12: ModeTransition

43 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ModeErrorBehavior
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note This represents the ability to define the error behavior in the context of mode handling.
Base ARObject
Aggregated by ModeDeclarationGroup.modeManagerErrorBehavior, ModeDeclarationGroup.modeUserErrorBehavior
Attribute Type Mult. Kind Note
defaultMode ModeDeclaration 0..1 ref This represents the ModeDeclaration that is considered
the error mode in the context of the enclosing Mode
DeclarationGroup.
errorReaction ModeErrorReaction 0..1 attr This represents the ability to define the policy in terms of
Policy PolicyEnum which default model shall apply in case an error occurs.

Table 4.13: ModeErrorBehavior

Enumeration ModeErrorReactionPolicyEnum
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note This represents the ability to specify the reaction on a mode error.
Aggregated by ModeErrorBehavior.errorReactionPolicy
Literal Description
defaultMode This represents the ability to switch to the defaultMode in case of a mode error.
Tags: atp.EnumerationLiteralIndex=0
lastMode This represents the ability to keep the last mode in case of a mode error.
Tags: atp.EnumerationLiteralIndex=1

Table 4.14: ModeErrorReactionPolicyEnum

In order to avoid conflicts in generated header files which might be included in the same
C-file, the following constraint holds:
[constr_4059] Different mode groups referred by a BSWM shall have differ-
ent names dA BswModuleDescription may not refer to different ModeDeclara-
tionGroups (via requiredModeGroup and/or providedModeGroup) having the
same shortName but different elements.c()
The attributes ModeDeclaration.value and ModeDeclarationGroup.onTran-
sitionValue and the category of ModeDeclarationGroup allow to determine
the generation of source code from the formal definition. For constraints on these
attributes refer to [6].
[TPS_BSWMDT_04014] ModeRequestTypeMap in BSW dFurthermore, it is required
to define a ModeRequestTypeMap in order to explicitly specify by which data type a
ModeDeclarationGroup is implemented:c(RS_BSWMD_00056)
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
5

44 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ModeRequestTypeMap
Aggregated by DataTypeMappingSet.modeRequestTypeMap
Attribute Type Mult. Kind Note
implementation AbstractImplementation 0..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 0..1 ref This is the corresponding ModeDeclarationGroup.

Table 4.15: ModeRequestTypeMap

[constr_4063] Restrictions of ModeRequestTypeMap in BSW dFor every Mod-

eDeclarationGroup referenced by a ModeDeclarationGroupPrototype used
in a BswModuleDescription a ModeRequestTypeMap shall exist that points to the
ModeDeclarationGroup and also to an eligible ImplementationDataType.
The ModeRequestTypeMap shall be aggregated by a DataTypeMappingSet which
is referenced from the BswInternalBehavior that is aggregated by the BswMod-
uleDescription.c()
Refer to [6] for restrictions on the ImplementationDataType that can be used for
such a mapping. Since provided and required modes are connected via ECU config-
uration, it is not possible to check constraints on these ImplementationDataTypes
on the level of BSWMDs only.

4.3 BSW Trigger Declaration

[TPS_BSWMDT_04015] Usage of Trigger in BSW dWith the optional attribute
releasedTrigger a BSW module can declare that it releases one or more Trig-
gers which are used to trigger events across BSW modules. Other modules which
want to react on such a trigger, shall declare a compatible Trigger as attribute
requiredTrigger (for the compatibility of Triggers refer to [6] [constr_1038]).
These declarations together with the associated event model allow for the appropriate
API generation and coordination by the BSW Scheduler.c(RS_BSWMD_00057, RS_-
BSWMD_00059) For details see chapter 5.7.
Note that the configuration of the BSW Scheduler actually determines which released
trigger is connected to which required one. This makes the specification of the individ-
ual module independent of the overall BSW setup.
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
5

45 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class Trigger
Aggregated by AtpClassifier .atpFeature, BswModuleDescription.releasedTrigger, BswModuleDescription.required
Trigger, ServiceInterface.trigger, TriggerInterface.trigger
Attribute Type Mult. 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.16: Trigger

A Trigger declaration can optionally set an attribute to define its queuing behavior.
This is in more detail explained in [6]. The usage of the enumeration type SwImplPol-
icyEnum in Trigger.swImplPolicy is restricted in the following way:
[constr_4060] Allowed values of Trigger.swImplPolicy for BSW dThe only al-
lowed values 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()

4.4 BSW Module Dependency

4.4.1 General

Figure 4.3 and the following table show the details of class BswModuleDependency.
This class represents the expectations of one BSW module or cluster on another BSW
module or cluster.
It should be noted, that in order to define a dependency it is not required to have a
complete model of the the targeted BswModuleDescription. This allows to main-
tain each BSWMD separately. Nonetheless, the target module needs to be identified
by the attribute BswModuleDependency.targetModuleId and/or the «atpUriDef»
reference BswModuleDependency.targetModuleRef. Of course, if both attributes
are used their values shall be consistent.
Because the module identifier is not always sufficient to identify the target module (e.g.
Complex Drivers all have the same module ID), the usage of targetModuleRef is
recommended.
A module cannot state a dependency to itself:

[constr_4038] bswModuleDependency shall refer to a different module d

• BswModuleDescription.bswModuleDependency.targetModuleId (if
given) shall differ from BswModuleDescription.moduleId. This does not
hold if the value is 254 (used for IO Hardware Abstraction modules) or 255 (used
for Complex Driver modules).

46 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• BswModuleDependency.targetModuleRef (if given) shall differ from the

package location of the BswModuleDescription that owns the BswMod-
uleDependency.
c()
ARElement ARElement
AtpBlueprint AtpBlueprint
AtpBlueprintable AtpBlueprintable
AtpStructureElement +implementedEntry BswModuleEntry
BswModuleDescription «atpVariation,atpSplitable» 0..* + bswEntryKind: BswEntryKindEnum [0..1]
+ moduleId: PositiveInteger [0..1] + callType: BswCallType [0..1]
+ executionContext: BswExecutionContext [0..1]
+ functionPrototypeEmitter: NameToken [0..1]
+expectedEntry + isReentrant: Boolean [0..1]
«atpVariation,atpSplitable» 0..* + isSynchronous: Boolean [0..1]
+ role: Identifier [0..1]
+ serviceId: PositiveInteger [0..1]
+ swServiceImplPolicy: SwServiceImplPolicyEnum
[0..1]

Identifiable
+bswModuleDependency BswModuleDependency

«atpVariation,atpSplitable» 0..* + targetModuleId: PositiveInteger [0..1]

+targetModuleRef 0..1

«atpUriDef,atpVariation,atpSplitable»

Identifiable
ServiceNeeds

Figure 4.3: Details of class BswModuleDependency

Class BswModuleDependency
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note This class collects the dependencies of a BSW module or cluster on a certain other BSW module.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswModuleDescription.bswModuleDependency
Attribute Type Mult. Kind Note
targetModuleId PositiveInteger 0..1 attr AUTOSAR identifier of the target module of which the
dependencies are defined.
This information is optional, because the target module
may also be identified by targetModuleRef.
Tags: xml.sequenceOffset=5
5

47 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleDependency
targetModule BswModuleDescription 0..1 ref Reference to the target module. It is an <<atpUriDef>>
Ref because the reference shall be used to identify the target
module without actually needing the description of that
target module.
Stereotypes: atpSplitable; atpUriDef; atpVariation
Tags:
atp.Splitkey=targetModuleRef.bswModuleDescription,
targetModuleRef.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=7

Table 4.17: BswModuleDependency

The set of expectedEntry-s represent the interface imported from another module
in terms of function calls.

4.4.2 Dependency and Packages

It is important to note that via BswModuleDependency the module description that

owns the dependency refers to model elements which are also referred by the de-
scription of the module it depends on. This holds especially for instances of BswMod-
uleEntry but also for other ARElements like data types referred from there. In order
to avoid inconsistencies, one should put such mutually used M1 elements under a well
defined location in terms of ARPackages.
Rules for the package location of standardized M1 model elements are given in [1],
chapter Identifying M1 elements in packages. As a consequence we can state:
[TPS_BSWMDT_04016] Location of standardized BswModuleEntry-s dInstances
of standardized BswModuleEntrys defined for an AUTOSAR module <module>4
shall be located under a package AUTOSAR_<module>/BswModuleEntrys/c(RS_-
BSWMD_00001, RS_BSWMD_00028)
for example
AUTOSAR_Can/BswModuleEntrys/Can_SetControllerMode

[TPS_BSWMDT_04017] Reference to standardized BswModuleEntry-s dIf a

BSWMD refers to a standardized BswModuleEntry via implementedEntry or ex-
pectedEntry it shall also use the path AUTOSAR_<module>/BswModuleEntrys/-
thus indicating that it relies on the AUTOSAR compliant implementation of the referred
API functions.c(RS_BSWMD_00001, RS_BSWMD_00028)

4
Here <module> is the module abbreviation of the standardized ICC3 module to which the API is
belongs.

48 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

It is highly recommended to follow an analog pattern (but not starting with AUTOSAR)
for the package names of non-standardized ARElements too.5 If a BSWMD refers in
its dependency to a path like
<vendor_specific_prefix>_<module>/BswModuleEntrys/

for example
VendorX_Can/BswModuleEntrys/Can_SpecialFunction

this would indicate that the BSWMD relies on a vendor specific function resp. callback
of the referred module (for example Can).
In addition, the value of targetModuleRef should be set to
VendorX_Can/BswModuleDescriptions/Can

In this example, we would instead of Can use a non-standardized module name if the
referred module is a Complex Driver. In this case, the module name would be equal to
the BswModuleDescription.shortName of the BSWMD of that Complex Driver.

4.4.3 Dependency: Examples and Constraints

Note that expectedEntry-s do also include calls in interrupt context. An example

could be as follows:
Consider we want to describe the callback-dependencies of an external EEPROM
driver module from the (standardized) AUTOSAR SPI module. Consider the SPI driver
offers an outgoing callback "EndJobNotification" always called in interrupt context. To
describe the dependency we would have to create an instance BswModuleDescrip-
tion.bswModuleDependency and do the following assignments:

• bswModuleDependency.targetModuleId = module identifier of the SPI

driver (alternatively, we could use bswModuleDependency.targetMod-
uleRef)
Figure 4.4 shows another example for an M1 model of a dependency between two hy-
pothetical BSW modules. The dependency includes one regular function implemented
by the lower layer module “Any” (which could stand for an MCAL module) and two
callbacks implemented by the upper layer Module “MyComplexDriver”6 .

5
The recommended name of the package that should be the immediate container of instances of a
given meta-class derived from ARElement is defined as an UML-tag and can be seen in the respective
class table.
6
The AUTOSAR BSW architecture distinguishes the semantics of callback and callout: Whereas a
callback notifies something to an upper layer module, a callout is used to add functionality to the calling
module. Within the BSWMD, these two mechanisms can be described in the same way.

49 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

:BswModuleDependency :BswModuleDescription
+bswModuleDependency
targetModuleId = 42 shortName = MyComplexDriver
shortName = MyDependency

+implementedEntry
+expectedEntry +implementedEntry

:BswModuleEntry :BswModuleEntry :BswModuleEntry

serviceId = 111 callType = callback callType = callback

callType = regular shortName = Any_Job1Done shortName = Any_Job2Done
shortName = Any_DoJob

+implementedEntry +expectedEntry +expectedEntry

+targetModuleRef :BswModuleDescription

moduleId = 42
shortName = Any

Figure 4.4: Example for an M1 model of a dependency between two modules

Note that the model of the outgoing callbacks can (in general) only be completed at
configuration time, because the number and names of the BswModuleEntrys used
as callbacks might be unknown at the time the BSWMD of the lower level module is
delivered. However at that point in time it is still possible to describe the signature of
the callback function by using an AtpBlueprint of the intended BswModuleEntry
and to deliver this description together with the BSWMD of the lower level module. For
more details on the blueprint concept refer to [9].
In addition to direct function calls, two BSW modules can also be connected via trig-
gers or modes declared in their interfaces. This does not show up as a dependency,
because the actual connection is created by the configuration of the BSW Scheduler.
Note that a BswModuleDependency can also contain ServiceNeeds. However, this
is a deprecated relationship (only allowed for backwards compatibility) since the decla-
ration of ServiceNeeds has been moved to the internal behavior level, see chapter
12.

4.5 BswModuleEntry Relationship Set

The BswEntryRelationshipSet describes a collection of BswEntryRelation-
ships. A BswEntryRelationship describes a relationship between two BswMod-
uleEntrys and the type of relationship. This is typically used to express that a con-
crete BswModuleEntry is derived from an abstract BswModuleEntry. In this case
the bswEntryRelationshipType is set to drivedFrom, the BswEntryRelationship.
from references the abstract BswModuleEntry and the BswEntryRelationship.
to references the concrete BswModuleEntry.

50 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
BswEntryRelationship
AtpBlueprint
+bswEntryRelationship
AtpBlueprintable + bswEntryRelationshipType: BswEntryRelationshipEnum [0..1]
BswEntryRelationshipSet 0..*

+from 0..1 +to 0..1

«enumeration» ARElement
BswEntryRelationshipEnum AtpBlueprint
AtpBlueprintable
derivedFrom BswModuleEntry

+ bswEntryKind: BswEntryKindEnum [0..1]

+ callType: BswCallType [0..1]
+ executionContext: BswExecutionContext [0..1]
+ functionPrototypeEmitter: NameToken [0..1]
«enumeration» + isReentrant: Boolean [0..1]
BswEntryKindEnum + isSynchronous: Boolean [0..1]
+ role: Identifier [0..1]
abstract
+ serviceId: PositiveInteger [0..1]
concrete
+ swServiceImplPolicy: SwServiceImplPolicyEnum [0..1]

Figure 4.5: BswEntryRelationshipSet

Class BswEntryRelationshipSet
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note Describes a set of relationships between two BswModuleEntrys.
Tags: atp.recommendedPackage=BswEntryRelationshipSets
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
bswEntry BswEntryRelationship * aggr Relationship between two BswModuleEntrys.
Relationship

Table 4.18: BswEntryRelationshipSet

[constr_10265] Existence of attribute BswEntryRelationshipSet.bswEn-

tryRelationship dFor each BswEntryRelationshipSet, the attribute bswEn-
tryRelationship shall exist at least once at the time when the configu-
ration of the BSW module is finished.c()
Class BswEntryRelationship
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note Describes a relationship between two BswModuleEntrys and the type of relationship.
Base ARObject
Aggregated by BswEntryRelationshipSet.bswEntryRelationship
Attribute Type Mult. Kind Note
bswEntry BswEntryRelationship 0..1 attr Denotes the type of the relationship.
Relationship Enum
Tags: xml.sequenceOffset=5
Type
from BswModuleEntry 0..1 ref Type of relationship that refers to the abstract BswModule
Entry. Please notice that in this case the bswEntry
RelationshipType shall be set to drivedFrom.
to BswModuleEntry 0..1 ref Type of relationship that refers to the concrete Bsw
ModuleEntry

Table 4.19: BswEntryRelationship

51 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10266] Existence of attribute BswEntryRelationship.bswEntryRela-

tionshipType dFor each BswEntryRelationship, the attribute bswEntryRe-
lationshipType shall exist at the time when the configuration of the
BSW module is finished.c()
[constr_10267] Existence of reference in the role BswEntryRelation-
ship.from dFor each BswEntryRelationship, the reference in the role from
shall exist at the time when the configuration of the BSW module is
finished.c()
[constr_10268] Existence of reference in the role BswEntryRelationship.to
dFor each BswEntryRelationship, the reference in the role to shall exist at the
time when the configuration of the BSW module is finished.c()
Enumeration BswEntryRelationshipEnum
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note Define the type of relationship between two BswModuleEntrys.
Aggregated by BswEntryRelationship.bswEntryRelationshipType
Literal Description
derivedFrom Describes that the BswModuleEntry referenced as "to" needs to have the same signature as the
"abstract" BswModuleEntry referenced as "from".
Tags: atp.EnumerationLiteralIndex=0

Table 4.20: BswEntryRelationshipEnum

4.6 BSW Inter-Partition Interface

4.6.1 Overview

AUTOSAR BSW has the ability to communicate across partition boundaries which in-
cludes communication across processor core boundaries.
While this is in general possible over the RTE by using Ports and Software Compo-
nents (e.g. Complex Drivers) on top of the BSW modules, there exist more efficient
mechanisms of doing this with the help of “glue code” provided by the BSW Scheduler
part of the RTE. See [13] for a detailed guideline.
These mechanisms follow the Client-Server communication pattern or the Sender-
Receiver communication pattern of the VFB - see [14] - but cannot be used for inter-
ECU communication.
The required meta-model part is shown in Figure 4.6.

52 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement ARElement
AtpBlueprint AtpBlueprint
AtpBlueprintable AtpBlueprintable
AtpStructureElement
+expectedEntry BswModuleEntry
BswModuleDescription
«atpVariation,atpSplitable» 0..* + bswEntryKind: BswEntryKindEnum [0..1]
+ moduleId: PositiveInteger [0..1] + callType: BswCallType [0..1]
+ executionContext: BswExecutionContext [0..1]
+ functionPrototypeEmitter: NameToken [0..1]
+ isReentrant: Boolean [0..1]
+implementedEntry + isSynchronous: Boolean [0..1]
+ role: Identifier [0..1]
«atpVariation,atpSplitable» 0..* + serviceId: PositiveInteger [0..1]
+ swServiceImplPolicy: SwServiceImplPolicyEnum [0..1]

+encapsulatedEntry 0..1

+providedClientServerEntry Referrable
BswModuleClientServerEntry
«atpVariation,atpSplitable» 0..*
+ isReentrant: Boolean [0..1]
+ isSynchronous: Boolean [0..1]
+requiredClientServerEntry

«atpVariation,atpSplitable» 0..*

AutosarDataPrototype
+providedData
VariableDataPrototype
«atpVariation,atpSplitable» 0..*

+requiredData

«atpVariation,atpSplitable» 0..*

Figure 4.6: BSW Interfaces for inter-partition and multicore communication

4.6.2 Client-Server

Class BswModuleClientServerEntry
Package M2::AUTOSARTemplates::BswModuleTemplate::BswInterfaces
Note This meta-class represents a single API entry into the BSW module or cluster that has the ability to be
called in client-server fashion via the BSW Scheduler.
In this regard it is more special than BswModuleEntry and can be seen as a wrapper around the Bsw
ModuleEntry to which it refers (property encapsulatedEntry).
Tags: atp.recommendedPackage=BswModuleEntrys
Base ARObject, Referrable
Aggregated by BswModuleDescription.providedClientServerEntry, BswModuleDescription.requiredClientServerEntry
Attribute Type Mult. Kind Note
encapsulated BswModuleEntry 0..1 ref The underlying BswModuleEntry.
Entry
Tags: xml.sequenceOffset=5
isReentrant Boolean 0..1 attr Reentrancy from the viewpoint of clients invoking the
service via the BSW Scheduler:
• true: Enables the service to be invoked again, before
the service has finished.
• false: It is prohibited to invoke the service again before
is has finished.
Tags: xml.sequenceOffset=10
5

53 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleClientServerEntry
isSynchronous Boolean 0..1 attr Synchronicity from the viewpoint of clients invoking the
service via the BSW Scheduler:
• true: This calls a synchronous service, i.e. the service
is completed when the call returns.
• false: The service (on semantical level) may not be
complete when the call returns.
Tags: xml.sequenceOffset=15

Table 4.21: BswModuleClientServerEntry

[constr_10269] Existence of the reference in the role BswModuleClientServer-

Entry.encapsulatedEntry dFor each BswModuleClientServerEntry, the the
reference in the role encapsulatedEntry shall exist at the time when the
configuration of the BSW module is finished.c()
[TPS_BSWMDT_04098] Declaration of BswModuleClientServerEntry dWith the
optional attribute providedClientServerEntry a BSW module can declare that it
provides a BswModuleClientServerEntry that can be used in the server role for
client-server communication across partition boundaries.7 . The client module (which
may be a different or the same module) shall declare a compatible BswModule-
ClientServerEntry as attribute requiredClientServerEntry. These decla-
rations together with the associated event model allow for the appropriate API gener-
ation and coordination by the BSW Scheduler.c(RS_BSWMD_00066) For details see
chapter 5.7.
[constr_4074] Compatibility of BswModuleClientServerEntry-s dTwo BswMod-
uleClientServerEntry-s are compatible if and only if all of the following conditions
hold:
• Their synchronicity values are identical. These values are taken from the attribute
isSynchronous or, if this is undefined, from encapsulatedEntry.isSyn-
chronous.
• The two BswModuleEntry-s referred as encapsulatedEntry have SwSer-
viceArg, returnType, serviceId and swServiceImplPolicy identical.
c()
Notice that executionContext shall always follow [TPS_BSWMDT_04179].
The configuration of the BSW Scheduler determines which provided-
ClientServerEntry is actually connected to which requiredClientServerEn-
try. This makes the specification of the individual module independent of the overall
BSW setup.

[TPS_BSWMDT_04099] Semantics of BswModuleClientServerEntry attributes

dThe optional attributes BswModuleClientServerEntry.isReentrant and
7
This does not exclude configurations where client and server are executed in the same partition.

54 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BswModuleClientServerEntry.isSynchronous can have different values than

the corresponding attributes of the referred BswModuleClientServerEntry.en-
capsulatedEntry, because the first two attributes describe properties seen by a
client calling via the BSW Scheduler wheres the latter contains the properties seen by
direct callers.
If one of these attributes is undefined, its value is considered as equal to the respective
attribute of the referred encapsulatedEntry.c(RS_BSWMD_00066)

[TPS_BSWMDT_04100] Different ways of referring BswModuleEntry dIn a given

BSWMD a BswModuleEntry, i.e. the declaration of a function signature, can be
referred in two different ways:
1. as part of the “direct” module interface, namely as implementedEntry or ex-
pectedEntry
2. as part of the client-server “remote” interface via BswModuleClientServer-
Entry.encapsulatedEntry
The two possibilities may be combined for one BswModuleEntry in the same BSWMD
if the entry is called directly and via client-server as well. However, if the BswMod-
uleEntry is only used in client-server manner it is recommended not to use the first
possibility in addition.
Especially, it is not required to state a bswModuleDependency in this case, since
the actual connection is done at configuration time and the two module environments
need not to exchange header files.c(RS_BSWMD_00066)

Client-Server communication via the BSW Scheduler implies some constraints on the
nature of the function call on the server side:
[constr_4076] Constraints on BswModuleEntry used for Client-Server dA
BswModuleEntry used in the role BswModuleClientServerEntry.encapsu-
latedEntry shall have attribute values as follows:
• callType shall be regular or callback.
• executionContext shall be task.
c()

4.6.3 Sender-Receiver

[TPS_BSWMDT_04101] Declaration of providedData and requiredData dWith

the optional attribute providedData a BSW module can declare that it provides a
VariableDataPrototype that can be used in the sender role for sender-server

55 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

communication across partition boundaries.8 The receiver module (which may be a

different or the same module) shall declare a compatible VariableDataPrototype
as attribute requiredData (for the compatibility of VariableDataPrototypes re-
fer to [6] [constr_1068]). These declarations together with the associated event model
and ECU configuration allow for the appropriate API generation and coordination by
the BSW Scheduler.c(RS_BSWMD_00067) For details see chapter 5.7.
[constr_4075] Constraints for providedData and requiredData dSender-
Receiver communication in BSW is restricted to the pattern of so-called explicit com-
munication (in the same way as described for software components in [6]) with queued
behavior. This leads to some constraints for the VariableDataPrototype referred
in the role BswModuleDescription.providedData or BswModuleDescription.
requiredData:
• It shall not have an initValue.
• Its swDataDefProps.swImplPolicy shall be set to queued.
• Its swDataDefProps.swCalibrationAccess shall be set to notAccessi-
ble.
There are no further formal constraints on the attributes of the VariableDataPro-
totype to be used in these roles or on the underlying AutosarDataPrototype.c
()
Note that the ECU configuration of the BSW Scheduler determines which provided-
Data is actually connected to which requiredData. This makes the specification of
the individual module independent of the overall BSW setup.

4.7 Count Value Sets

4.7.1 Background

When a high number of software components are integrated on an ECU the allocation
of the RTE communication buffers (e.g. for implicit communication) or allocation of
specific functions is getting a crucial performance factor. With the knowledge how
often RTE API is invoked and consequential how often accesses to data are executed
it is possible to optimize the implementation. For instance buffers with a high access
frequency are put to a memory with low latency.

4.7.2 AccessCountSets

The meta-class AccessCountSet provides a collection of count values how often

an implementation invokes RTE / SchM APIs provided for certain AbstractAccess-
Point of a specific ExecutableEntity.
8
This does not exclude configurations where sender and receiver are executed in the same partition.

56 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class AccessCountSet
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::AccessCount
Note This meta-class provides a set of count values evaluated according to the rules of a specific countProfile.
Base ARObject
Aggregated by ResourceConsumption.accessCountSet
Attribute Type Mult. Kind Note
accessCount AccessCount * aggr Count value for a AbstractAccessPoint.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=accessCount, accessCount.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
countProfile NameToken 0..1 attr This attribute defines the name of the count profile used
to determine the AccessCount.value numbers.

Table 4.22: AccessCountSet

[constr_10270] Existence of attribute AccessCountSet.countProfile dFor each

AccessCountSet, the attribute countProfile shall exist at the time when
the configuration of the BSW module is finished.c()
Class AccessCount
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::AccessCount
Note This meta-class provides one count value for a AbstractAccessPoint.
Base ARObject
Aggregated by AccessCountSet.accessCount
Attribute Type Mult. Kind Note
accessPoint AbstractAccessPoint 0..1 ref AbstractAccessPoint for which the count value is
applicable.
value PositiveInteger 0..1 attr This attribute represents the number of determined
accesses
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.23: AccessCount

[constr_10271] Existence of attribute AccessCount.value dFor each Access-

Count, the attribute value shall exist at the time when the configuration
of the BSW module is finished.c()
Class AbstractAccessPoint (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::AccessCount
Note Abstract class indicating an access point from an ExecutableEntity.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Subclasses AsynchronousServerCallResultPoint, ExternalTriggeringPointIdent, InternalTriggeringPoint, ModeAccess
PointIdent, ModeSwitchPoint, ParameterAccess, ServerCallPoint, VariableAccess
Aggregated by AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
returnValue RteApiReturnValue 0..1 attr This attribute controls the provision of return values for
Provision ProvisionEnum RTE APIs that correspond to the enclosing access point.

Table 4.24: AbstractAccessPoint

57 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04140] AccessCount.value describes an intrinsic property

dThe AccessCount.values in an AccessCountSet are statements about the im-
plementation of single ExecutableEntitys with respect to RTE/SchM API usage
when the code is executed. Those values are independent from the later integration of
the respective AbstractAccessPoint of a specific ExecutableEntitys.c()
This means, that the numbers are a characteristic of a single AbstractAccessPoint
of a specific ExecutableEntity and depending on the resulting call graph it might
be required to calculate the consolidated numbers of accesses as the basis for the
integration decisions. For instance if a server runnable is called 5 times in a loop by
direct function call from a periodically scheduled runnable, the intrinsic count values for
the data accesses in the server runnable needs to multiplied by 5 in order to get the
consolidated effective number of access per time period.
Identifiable
AccessCountSet
+accessCountSet «atpVariation,atpSplitable» ResourceConsumption
+ countProfile: NameToken [0..1]
0..*

  

      
 
   
    
«atpVariation,atpSplitable»  
+accessCount 0..*

AtpStructureElement
AccessCount
+accessPoint AbstractAccessPoint
«atpVariation»
0..1 + returnValueProvision: RteApiReturnValueProvisionEnum [0..1]
+ value: PositiveInteger [0..1]

AtpStructureElement AtpStructureElement AtpStructureElement AtpStructureElement

Identifiable Identifiable Identifiable Identifiable
ParameterAccess AsynchronousServerCallResultPoint ServerCallPoint ModeSwitchPoint

+ timeout: TimeValue [0..1]

AtpStructureElement IdentCaption IdentCaption AtpStructureElement

Identifiable ModeAccessPointIdent ExternalTriggeringPointIdent Identifiable
VariableAccess InternalTriggeringPoint

+ scope: VariableAccessScopeEnum [0..1] + swImplPolicy: SwImplPolicyEnum [0..1]

Figure 4.7: Overview AccessCountSet

In general the provider of the count values and the consumer of the count values need
a common understanding how the values are determined in order to consider them
appropriately for the optimization. Since the topic of optimizations may be a subject of
further enhancements the AccessCountSet provides information about the counting
strategy with the attribute countProfile.
[TPS_BSWMDT_04141] The attribute countProfile denotes the counting rules
dThe attribute countProfile denotes the set of applicable counting rules used to
determine the AccessCount.values.c()
[TPS_BSWMDT_04142] Standardized values of attribute countProfile
dAUTOSAR defines following standardized values of the attribute countProfile:
• DISTINGUISH_SINGULAR_ACCESSES
c()

58 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Please note that further count profiles might be defined in future.

4.7.3 Definition of countProfile: DISTINGUISH_SINGULAR_ACCESSES

The purpose of the countProfile DISTINGUISH_SINGULAR_ACCESSES is to de-

termine on one hand the typical frequentness of RTE API invocation supporting the
adjustment of the memory allocation. On the other hand it shall be information rich
enough to provide precise information about the maximum number of access to data
via implicit communication pattern which can also be used to optimize the memory al-
location or even to question the existence of buffers at all. The AccessCountSets
provide a collection of count values how often an implementation invokes RTE / SchM
APIs provided for certain AbstractAccessPoint of a specific ExecutableEntity.
In case of implicit communication accesses to data the RTE API may return data ref-
erences to the location in memory where the data can be accessed. For that kind of
AbstractAccessPoint the counting of the API invocations would not be sufficient
but rather the number of implemented access to composite data elements via the data
reference is important.
[TPS_BSWMDT_04143] countProfile DISTINGUISH_SINGULAR_ACCESSES,
Explicit Communication, single access dThe AccessCount.value applied to a
VariableAccess in role dataReceivePointByArgument, dataReceivePoint-
ByValue, dataSendPoint or a VariableAccess in role writtenLocalVari-
able / readLocalVariable referencing an explicitInterRunnableVariable
shall be given as 1, if the according implementation of the RunnableEntity invokes
the according RTE API at most once per execution of the RunnableEntity in any
condition.c()
[TPS_BSWMDT_04144] countProfile DISTINGUISH_SINGULAR_ACCESSES,
Explicit Communication, multiple accesses dThe AccessCount.value applied
to a VariableAccess in role dataReceivePointByArgument, dataReceive-
PointByValue, dataSendPoint or a VariableAccess in role writtenLo-
calVariable / readLocalVariable referencing an explicitInterRunnabl-
eVariable shall be given greater than 1, if the according implementation of the
RunnableEntity may invoke the according RTE API multiple times per execution
of the RunnableEntity. Thereby the AccessCount.value shall state the number
of invocations in typically execution conditions.c()
[TPS_BSWMDT_04145] countProfile DISTINGUISH_SINGULAR_ACCESSES,
Implicit Communication and parameter accesses, single access dThe Access-
Count.value applied to a ParameterAccess or a VariableAccess in role
dataWriteAccess, dataReadAccess or a VariableAccess in role writtenLo-
calVariable or readLocalVariable referencing an implicitInterRunnabl-
eVariable shall be given as 1, if the according implementation of the Exe-
cutableEntity access at most one-time one primitive data or at most one-time one
primitive composite data element per execution of the RunnableEntity in any con-
dition.c()

59 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04146] countProfile DISTINGUISH_SINGULAR_ACCESSES,

Implicit Communication and parameter accesses, multiple accesses dThe Ac-
cessCount.value applied to a ParameterAccess or a VariableAccess in role
dataWriteAccess, dataReadAccess or a VariableAccess in role writtenLo-
calVariable or readLocalVariable referencing an implicitInterRunnabl-
eVariable shall be given greater than 1, if the according implementation of the
RunnableEntity may access primitive data multiple times or multiple primitive com-
posite data element per execution of the RunnableEntity. Thereby the Access-
Count.value shall state the number of accesses to primitive data or accesses to
primitive composite data elements in typically execution conditions.c()
For instance accessing a structure with 3 elements of type uint8, uint16 and uint64 in
a loop executed 5 times counts a 15.
For instance a RunnableEntity accesses an array of size 42 in a way, that for each
execution of the RunnableEntity exactly one element of this array is read by implicit
access. This counts as 1.
[TPS_BSWMDT_04147] countProfile DISTINGUISH_SINGULAR_ACCESSES,
Server calls, issued Triggers, Mode Switch Notifications, single access dThe
AccessCount.value applied to a ServerCallPoint, AsynchronousServer-
CallResultPoint, InternalTriggeringPoint, ExternalTriggeringPoint,
ModeSwitchPoint, ModeAccessPoint shall be given as 1, if the according imple-
mentation of the ExecutableEntity invokes the according RTE API at most once
per execution of the ExecutableEntity in any condition.c()
[TPS_BSWMDT_04148] countProfile DISTINGUISH_SINGULAR_ACCESSES,
Server calls, issued Triggers, Mode Switch Notifications, multiple accesses dThe
AccessCount.value applied to a ServerCallPoint, AsynchronousServer-
CallResultPoint, InternalTriggeringPoint, ExternalTriggeringPoint,
ModeSwitchPoint, ModeAccessPoint shall be given greater than 1, if the accord-
ing implementation of the ExecutableEntity invokes the according RTE API mul-
tiple times per execution of the ExecutableEntity. Thereby the AccessCount.
value shall state the number of invocations in typically execution conditions.c()
For instance if a server is invoked in a loop the AccessCount.value is set to the
number of typical loop iterations.

4.7.4 Structuring of AccessCountSets

In general the detailed usage how AccessCountSets are used to structure a M1

model is not standardized. Nevertheless this section provides some hints how it might
be applied for different use cases. Regardless how the AccessCountSets are sub-
structured in detail a valid AUTOSAR model can only provide at most one value accord-
ing a specific countProfile for a particular AbstractAccessPoint. Otherwise the
count values would be ambiguous since multiple values would be stated for one kind
of access.

60 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_4091] AccessCount.value needs to be unambiguous dAUTOSAR model

shall define at most one AccessCount.value per countProfile for a specific Ab-
stractAccessPoint.c()
[TPS_BSWMDT_04149] Structuring according ExecutableEntitys dThe meta-
class AccessCountSet should be used to group the AccessCount.values for one
particular ExecutableEntity.c()
[TPS_BSWMDT_04150] Structuring according Variants dThe meta-class Access-
CountSet should be used to group the AccessCount.values which are valid for one
particular variant of the software. The grouping might be used if the AccessCount.
values are evaluated by code parsing since the parsing might be done for a specific
variant of the C-implementation.c()
[TPS_BSWMDT_04151] Structuring according different countProfile defini-
tions dThe meta-class AccessCountSet should be used to group the AccessCount.
values which are valid for one particular countProfile value.c()

61 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

5 BSW Behavior

5.1 BSW Behavior Overview

Figure 5.1 and the following class table show the attributes and description of class
BswInternalBehavior. Since several attributes on this level are the same for BSW
modules and SWCs, these are aggregated by the abstract class InternalBehavior
which is shown in the same figure and in a separate class table.
The following subsections give a more detailed explanation of the various attributes.

62 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

AtpStructureElement +exclusiveArea Identifiable

InternalBehavior
«atpVariation,atpSplitable» 0..* ExclusiveArea

Referrable
+exclusiveAreaNestingOrder
ExclusiveAreaNestingOrder
«atpVariation,atpSplitable» 0..*

+staticMemory AutosarDataPrototype
VariableDataPrototype
«atpVariation,atpSplitable» 0..*

+constantMemory AutosarDataPrototype

«atpVariation,atpSplitable» 0..* ParameterDataPrototype

+perInstanceParameter 0..*

«atpVariation,atpSplitable»
BswInternalBehavior

+entity ExecutableEntity
BswModuleEntity
«atpVariation,atpSplitable» 0..*

+startsOnEvent 0..1

AbstractEvent
+event BswEvent

«atpVariation,atpSplitable» 0..*

BswTriggerDirectImplementation
+triggerDirectImplementation
«atpVariation,atpSplitable» 0..*

+modeSenderPolicy BswModeSenderPolicy

«atpVariation,atpSplitable» 0..*

BswModeReceiverPolicy
+modeReceiverPolicy

«atpVariation,atpSplitable» 0..*

ServiceDependency
+serviceDependency BswServiceDependency

«atpVariation,atpSplitable»
0..*

BswApiOptions
+receptionPolicy
BswDataReceptionPolicy
«atpVariation,atpSplitable» 0..*

Identifiable
+internalTriggeringPoint
BswInternalTriggeringPoint
«atpVariation,atpSplitable» 0..*

+distinguishedPartition Referrable
«atpVariation,atpSplitable» 0..* BswDistinguishedPartition

Figure 5.1: Overview of meta-class BswInternalBehavior

63 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class InternalBehavior (abstract)

Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note Common base class (abstract) for the internal behavior of both software components and basic software
modules/clusters.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Subclasses BswInternalBehavior, SwcInternalBehavior
Aggregated by AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
constant ParameterData * aggr Describes a read only memory object containing
Memory Prototype characteristic value(s) implemented by this Internal
Behavior.
The shortName of ParameterDataPrototype has to be
equal to the ”C’ identifier of the described constant.
The characteristic value(s) might be shared between Sw
ComponentPrototypes of the same SwComponentType.
The aggregation of constantMemory is subject to
variability with the purpose to support variability in the
software component or module implementations.
Typically different algorithms in the implementation are
requiring different number of memory objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=constantMemory.shortName, constant
Memory.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
constantValue ConstantSpecification * ref Reference to the ConstantSpecificationMapping to be
Mapping MappingSet applied for the particular InternalBehavior
Stereotypes: atpSplitable
Tags: atp.Splitkey=constantValueMapping
dataType DataTypeMappingSet * ref Reference to the DataTypeMapping to be applied for the
Mapping particular InternalBehavior
Stereotypes: atpSplitable
Tags: atp.Splitkey=dataTypeMapping
exclusiveArea ExclusiveArea * aggr This specifies an ExclusiveArea for this InternalBehavior.
The exclusiveArea is local to the component resp.
module. The aggregation of ExclusiveAreas is subject to
variability. Note: the number of ExclusiveAreas might vary
due to the conditional existence of RunnableEntities or
BswModuleEntities.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=exclusiveArea.shortName, exclusive
Area.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
exclusiveArea ExclusiveAreaNesting * aggr This represents the set of ExclusiveAreaNestingOrder
NestingOrder Order owned by the InternalBehavior.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=exclusiveAreaNestingOrder.shortName,
exclusiveAreaNestingOrder.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
5

64 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class InternalBehavior (abstract)
staticMemory VariableDataPrototype * aggr Describes a read and writeable static memory object
representing measurerment variables implemented by
this software component. The term "static" is used in the
meaning of "non-temporary" and does not necessarily
specify a linker encapsulation. This kind of memory is
only supported if supportsMultipleInstantiation is FALSE.
The shortName of the VariableDataPrototype has to be
equal with the ”C’ identifier of the described variable.
The aggregation of staticMemory is subject to variability
with the purpose to support variability in the software
component’s implementations.
Typically different algorithms in the implementation are
requiring different number of memory objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=staticMemory.shortName, static
Memory.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 5.1: InternalBehavior

Class BswInternalBehavior
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specifies the behavior of a BSW module or a BSW cluster w.r.t. the code entities visible by the BSW
Scheduler. It is possible to have several different BswInternalBehaviors referring to the same BswModule
Description.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, InternalBehavior , Multilanguage
Referrable, Referrable
Aggregated by AtpClassifier .atpFeature, BswModuleDescription.internalBehavior
Attribute Type Mult. Kind Note
arTypedPer VariableDataPrototype * aggr Defines an AUTOSAR typed memory-block that needs to
Instance be available for each instance of the Basic Software
Memory Module. The aggregation of arTypedPerInstanceMemory
is subject to variability with the purpose to support
variability in the Basic Software Module’s
implementations. Typically different algorithms in the
implementation are requiring different number of memory
objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=arTypedPerInstanceMemory.shortName, ar
TypedPerInstanceMemory.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
bswPerInstance BswPerInstance * aggr Policy for a arTypedPerInstanceMemory The policy
MemoryPolicy MemoryPolicy selects the options of the Schedule Manager API
generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=bswPerInstanceMemoryPolicy, bswPer
InstanceMemoryPolicy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
5

65 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswInternalBehavior
clientPolicy BswClientPolicy * aggr Policy for a requiredClientServerEntry. The policy selects
the options of the Schedule Manager API generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=clientPolicy, clientPolicy.variationPoint.short
Label
vh.latestBindingTime=preCompileTime
distinguished BswDistinguished * aggr Indicates an abstract partition context in which the
Partition Partition enclosing BswModuleEntity can be executed.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=distinguishedPartition.shortName,
distinguishedPartition.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=60
entity BswModuleEntity * aggr A code entity for which the behavior is described
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=entity.shortName, entity.variationPoint.short
Label
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=5
event BswEvent * aggr An event required by this module behavior.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=event.shortName, event.variationPoint.short
Label
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=10
exclusiveArea BswExclusiveArea * aggr Policy for an ExclusiveArea in this BswInternalBehavior.
Policy Policy The policy selects the options of the Schedule Manager
API generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=exclusiveAreaPolicy, exclusiveArea
Policy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
includedData IncludedDataTypeSet * aggr The includedDataTypeSet is used by a basic software
TypeSet module for its implementation.
Stereotypes: atpSplitable
Tags: atp.Splitkey=includedDataTypeSet
includedMode IncludedMode * aggr This aggregation represents the included Mode
Declaration DeclarationGroupSet DeclarationGroups
GroupSet
Stereotypes: atpSplitable
Tags: atp.Splitkey=includedModeDeclarationGroupSet
internal BswInternalTriggering * aggr An internal triggering point.
TriggeringPoint Point
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=internalTriggeringPoint.shortName, internal
TriggeringPoint.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=2
5

66 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswInternalBehavior
internal BswInternalTriggering * aggr Policy for an internalTriggeringPoint in this BswInternal
TriggeringPoint PointPolicy Behavior.. The policy selects the options of the Schedule
Policy Manager API generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=internalTriggeringPointPolicy, internal
TriggeringPointPolicy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
modeReceiver BswModeReceiver * aggr Implementation policy for the reception of mode switches.
Policy Policy
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=modeReceiverPolicy, modeReceiver
Policy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=25
modeSender BswModeSenderPolicy * aggr Implementation policy for providing a mode group.
Policy
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=modeSenderPolicy, modeSender
Policy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=20
parameterPolicy BswParameterPolicy * aggr Policy for a perInstanceParameter in this BswInternal
Behavior. The policy selects the options of the Schedule
Manager API generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=parameterPolicy, parameterPolicy.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
perInstance ParameterData * aggr Describes a read only memory object containing
Parameter Prototype characteristic value(s) needed by this BswInternal
Behavior. The role name perInstanceParameter is chosen
in analogy to the similar role in the context of SwcInternal
Behavior.
In contrast to constantMemory, this object is not allocated
locally by the module’s code, but by the BSW Scheduler
and it is accessed from the BSW module via the BSW
Scheduler API. The main use case is the support of
software emulation of calibration data.
The aggregation is subject to variability with the purpose
to support implementation variants.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=perInstanceParameter.shortName, per
InstanceParameter.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=45
receptionPolicy BswDataReception * aggr Data reception policy for inter-partition and/or inter-core
Policy communication.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=receptionPolicy, receptionPolicy.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=55
5

67 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswInternalBehavior
releasedTrigger BswReleasedTrigger * aggr Policy for a releasedTrigger. The policy selects the
Policy Policy options of the Schedule Manager API generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=releasedTriggerPolicy, releasedTrigger
Policy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
schedulerName BswSchedulerName * aggr Optional definition of one or more prefixes to be used for
Prefix Prefix the BswScheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=schedulerNamePrefix.shortName, scheduler
NamePrefix.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=50
sendPolicy BswDataSendPolicy * aggr Policy for a providedData. The policy selects the options
of the Schedule Manager API generation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=sendPolicy, sendPolicy.variationPoint.short
Label
vh.latestBindingTime=preCompileTime
service BswService * aggr Defines the requirements on AUTOSAR Services for a
Dependency Dependency particular item.
The aggregation is subject to variability with the purpose
to support the conditional existence of ServiceNeeds.
The aggregation is splitable in order to support that
ServiceNeeds might be provided in later development
steps.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=serviceDependency.ident.shortName,
serviceDependency.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=40
triggerDirect BswTriggerDirect * aggr Specifies a trigger to be directly implemented via OS
Implementation Implementation calls.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=triggerDirectImplementation, triggerDirect
Implementation.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=15
variationPoint VariationPointProxy * aggr Proxy of a variation points in the C/C++ implementation.
Proxy
Stereotypes: atpSplitable
Tags: atp.Splitkey=variationPointProxy.shortName

Table 5.2: BswInternalBehavior

68 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

5.2 BSW Module Entity

5.2.1 Overview

Figure 5.2 and the next class tables shows the attributes of BswModuleEntity, its
base class ExecutableEntity and its specializations for called, scheduled and in-
terrupt entities. These attributes are mainly required to configure the BSW Scheduler.
It is important to understand the difference between BswModuleEntity and BswMod-
uleEntry: The first one describes properties of a code fragment whereas the second
one describes only the interface (i.e. the signature) used to invoke a code fragment.
Identifiable «enumeration»
AtpStructureElement
ExecutableEntity ReentrancyLevelEnum
InternalBehavior
+ minimumStartInterval: TimeValue [0..1] multicoreReentrant
+ reentrancyLevel: ReentrancyLevelEnum [0..1] singleCoreReentrant
nonReentrant

Referrable
BswModuleEntity +callPoint
BswInternalBehavior BswModuleCallPoint
«atpVariation,atpSplitable»0..*

ARElement
+implementedEntry AtpBlueprint
AtpBlueprintable
0..1 BswModuleEntry

+entity AtpStructureElement
+issuedTrigger Identifiable
«atpVariation,atpSplitable» 0..* Trigger
«atpVariation,atpSplitable» 0..*
+ swImplPolicy: SwImplPolicyEnum [0..1]

+managedModeGroup
AtpPrototype
«atpVariation,atpSplitable» 0..*
ModeDeclarationGroupPrototype

+accessedModeGroup + swCalibrationAccess:
SwCalibrationAccessEnum [0..1]
«atpVariation,atpSplitable» 0..*

+dataReceivePoint
Referrable
«atpVariation,atpSplitable» BswVariableAccess
0..*

+dataSendPoint
«atpVariation,atpSplitable» 0..*

«enumeration»
BswInterruptCategory

cat1
cat2

BswCalledEntity BswSchedulableEntity BswInterruptEntity

+ interruptCategory: BswInterruptCategory [0..1]

+ interruptSource: String [0..1]

Figure 5.2: Relationships of meta-class BswModuleEntity

[TPS_BSWMDT_04072] Executable entity in BSW dThe abstract meta-class Exe-

cutableEntity is not specific for the Basic Software, it is imported from the Com-
monStructure package of the meta-model and is defined as follows:c(RS_BSWMD_-
00030, RS_BSWMD_00046)

69 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ExecutableEntity (abstract)

Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note Abstraction of executable code.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses BswModuleEntity , RunnableEntity
Attribute Type Mult. Kind Note
activation ExecutableEntity * aggr If the ExecutableEntity provides at least one activation
Reason ActivationReason Reason element the RTE resp. BSW Scheduler shall
provide means to read the activation vector of this
executable entity execution.
If no activationReason element is provided the feature of
being able to determine the activating RTEEvent is
disabled for this ExecutableEntity.
canEnter ExclusiveArea * ref This means that the executable entity can enter/leave the
referenced exclusive area through explicit API calls.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=canEnter.exclusiveArea, canEnter.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
exclusiveArea ExclusiveAreaNesting * ref This represents the set of ExclusiveAreaNestingOrders
NestingOrder Order recognized by this ExecutableEntity.
minimumStart TimeValue 0..1 attr Specifies the time in seconds by which two consecutive
Interval starts of an ExecutableEntity are guaranteed to be
separated.
reentrancyLevel ReentrancyLevelEnum 0..1 attr The reentrancy level of this ExecutableEntity. See the
documentation of the enumeration type ReentrancyLevel
Enum for details.
Please note that nonReentrant interfaces can have also
reentrant or multicoreReentrant implementations, and
reentrant interfaces can also have multicoreReentrant
implementations.
runsInside ExclusiveArea * ref The executable entity runs completely inside the
referenced exclusive area.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=runsInside.exclusiveArea, runs
Inside.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
swAddrMethod SwAddrMethod 0..1 ref Addressing method related to this code entity. Via an
association to the same SwAddrMethod, it can be
specified that several code entities (even of different
modules or components) shall be located in the same
memory without already specifying the memory section
itself.
Table 5.3: ExecutableEntity

Class BswModuleEntity (abstract)

Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specifies the smallest code fragment which can be described for a BSW module or cluster within
AUTOSAR.
Base ARObject, ExecutableEntity , Identifiable, MultilanguageReferrable, Referrable
Subclasses BswCalledEntity, BswInterruptEntity, BswSchedulableEntity
Aggregated by BswInternalBehavior.entity
5

70 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleEntity (abstract)
Attribute Type Mult. Kind Note
accessedMode ModeDeclarationGroup * ref A mode group which is accessed via API call by this
Group Prototype entity. It shall be a ModeDeclarationGroupPrototype
required by this module or cluster.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=accessedModeGroup.modeDeclaration
GroupPrototype, accessedModeGroup.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
activationPoint BswInternalTriggering * ref Activation point used by the module entity to activate one
Point or more internal triggers.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=activationPoint.bswInternalTriggeringPoint,
activationPoint.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
callPoint BswModuleCallPoint * aggr A call point used in the code of this entity.
The variability of this association is especially targeted at
debug scenarios: It is possible to have one variant calling
into the AUTOSAR debug module and another one which
doesn’t.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=callPoint.shortName, callPoint.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
dataReceive BswVariableAccess * aggr The data is received via the BSW Scheduler.
Point
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataReceivePoint.shortName, dataReceive
Point.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
dataSendPoint BswVariableAccess * aggr The data is sent via the BSW Scheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataSendPoint.shortName, dataSend
Point.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
implemented BswModuleEntry 0..1 ref The entry which is implemented by this module entity.
Entry
issuedTrigger Trigger * ref A trigger issued by this entity via BSW Scheduler API call.
It shall be a BswTrigger released (i.e. owned) by this
module or cluster.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=issuedTrigger.trigger, issuedTrigger.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
5

71 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModuleEntity (abstract)
managedMode ModeDeclarationGroup * ref A mode group which is managed by this entity. It shall be
Group Prototype a ModeDeclarationGroupPrototype provided by this
module or cluster.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=managedModeGroup.modeDeclaration
GroupPrototype, managedModeGroup.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
schedulerName BswSchedulerName 0..1 ref A prefix to be used in generated names for the Bsw
Prefix Prefix ModuleScheduler in the context of this BswModuleEntity,
for example entry point prototypes, macros for dealing
with exclusive areas, header file names.
Details are defined in the SWS RTE.
The prefix supersedes default rules for the prefix of those
names.
Table 5.4: BswModuleEntity

[constr_10272] Existence of the reference in the role BswModuleEntity.im-

plementedEntry dFor each BswModuleEntity, the reference in the role im-
plementedEntry shall exist at the time when the configuration of the
BSW module is finished.c()

5.2.2 BSW Module Entity Attributes

[TPS_BSWMDT_04019] BswModuleEntity attributes for exchange of modes and

triggers dThe attributes BswModuleEntity.managedModeGroup, BswModuleEn-
tity.accessedModeGroup and BswModuleEntity.issuedTrigger specify, that
this BswModuleEntity initiates resp. receives mode switches or activates triggers
for other modules by using the BSW Scheduler API. This is mandatory information
to configure the BSW Scheduler.c(RS_BSWMD_00030, RS_BSWMD_00056, RS_-
BSWMD_00059)
For an explanation of the attribute callPoint see chapter 5.3
For an explanation of the attributes dataSendPoint and dataReceivePoint see
chapter 5.4.
[TPS_BSWMDT_04103] BswModuleEntity reentrancy level dWith the optional at-
tribute reentrancyLevel a BswModuleEntity can state its implemented reen-
trancy level within the limits given by its interface (see [constr_4077]). This attribute
is especially targeted at multicore scenarios.
If this attribute is omitted, reentrancy is assumed to be implemented as defined by
the attribute BswModuleEntity.implementedEntry.isReentrant, in which case
true means single core reentrancy.c(RS_BSWMD_00066)

72 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration ReentrancyLevelEnum
Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note Specifies if and in which kinds of environments an entity is reentrant.
Aggregated by ExecutableEntity .reentrancyLevel
Literal Description
multicoreReentrant Unlimited concurrent execution of this entity is possible, including preemption and parallel execution
on multi core systems.
Tags: atp.EnumerationLiteralIndex=0
nonReentrant Concurrent execution of this entity is not possible.
Tags: atp.EnumerationLiteralIndex=1
singleCore Pseudo-concurrent execution (i.e. preemption) of this entity is possible on single core systems.
Reentrant
Tags: atp.EnumerationLiteralIndex=2

Table 5.5: ReentrancyLevelEnum

5.2.3 BSW Module Entity Constraints

The actually implemented reentrancy level can only be “better” than stated on the in-
terface level, as the following constraint says:
[constr_4077] Constraints for BswModuleEntity.reentrancyLevel d
• If the attribute isReentrant of a BswModuleEntry referred by an BswMod-
uleEntity in the role implementedEntry has the value true, then the at-
tribute reentrancyLevel of the same BswModuleEntity (if it exists) can only
have the values singleCoreReentrant or multicoreReentrant.
• If the attribute isReentrant of a BswModuleEntry referred by an BswMod-
uleEntity in the role implementedEntry has the values false, then there
are no restrictions for the values of the attribute reentrancyLevel of the same
BswModuleEntity (if it exists).
c()
A BswModuleEntity can only implement resp. use elements which have been de-
clared on the interface level of the respective module or cluster, in other words:
[constr_4022] BswModuleEntity only uses the module’s interface d
• BswModuleEntity.implementedEntry shall refer to an element declared as
implementedEntry of the enclosing BswModuleDescription
• BswModuleEntity.callPoint.calledEntry - where callPoint is instan-
tiated from BswDirectCallPoint - shall refer to an element declared as ex-
pectedEntry or implementedEntry of the enclosing BswModuleDescrip-
tion.

73 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• BswModuleEntity.callPoint.calledEntry - where callPoint is

instantiated from BswSynchronousServerCallPoint or BswAsyn-
chronousServerCallPoint - shall refer to an element declared as
requiredClientServerEntry of the enclosing BswModuleDescription.
• BswModuleEntity.callPoint - where callPoint is instantiated from
BswAsynchronousServerCallResultPoint - shall refer to an BswAsyn-
chronousServerCallPoint declared in turn as callPoint of the same
BswModuleEntity.
• BswModuleEntity.issuedTrigger shall refer to an element declared as re-
leasedTrigger of the enclosing BswModuleDescription
• BswModuleEntity.managedModeGroup shall refer to an element declared as
providedModeGroup of the enclosing BswModuleDescription
• BswModuleEntity.accessedModeGroup shall refer to an element declared
as requiredModeGroup of the enclosing BswModuleDescription
• BswModuleEntity.dataSendPoint.accessedVariable shall refer to an el-
ement declared as providedData of the enclosing BswModuleDescription
• BswModuleEntity.dataReceivePoint.accessedVariable shall refer to
an element declared as requiredData of the enclosing BswModuleDescrip-
tion
• an accessedModeGroup should be allowed to refer to an element declared as
providedModeGroup
c()

5.2.4 BswCalledEntity

Class BswCalledEntity
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note BSW module entity which is designed to be called from another BSW module or cluster.
Base ARObject, BswModuleEntity , ExecutableEntity , Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswInternalBehavior.entity
Attribute Type Mult. Kind Note
– – – – –
Table 5.6: BswCalledEntity

BswCalledEntity represents an “ordinary” function call for which the following con-
straints apply:
[constr_4016] BswCalledEntity constraints d
• BswCalledEntity.implementedEntry.callType shall be ’regular’ or
’callback’

74 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• BswCalledEntity.implementedEntry.executionContext is in general
not restricted, but see [constr_4076] for constraints on the server side of a Client-
Server communication.
• A BswInterruptEvent shall only trigger a BswInterruptEntity where at-
tribute interruptCategory is set to BswInterruptCategory.cat2.
c()

5.2.5 BswSchedulableEntity

Class BswSchedulableEntity
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note BSW module entity, which is designed for control by the BSW Scheduler. It may for example implement a
so-called "main" function.
Base ARObject, BswModuleEntity , ExecutableEntity , Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswInternalBehavior.entity
Attribute Type Mult. Kind Note
– – – – –
Table 5.7: BswSchedulableEntity

BswSchedulableEntity represents a scheduled function call for which the following

constraints apply:
[constr_4017] BswSchedulableEntity constraints d
• BswModuleEntity.implementedEntry.callType shall be ’scheduled’
• BswModuleEntity.implementedEntry.executionContext shall be
’task’
c()

5.2.6 BswInterruptEntity

Class BswInterruptEntity
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note BSW module entity, which is designed to be triggered by an interrupt.
Base ARObject, BswModuleEntity , ExecutableEntity , Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswInternalBehavior.entity
Attribute Type Mult. Kind Note
interrupt BswInterruptCategory 0..1 attr Category of the interrupt
Category
interruptSource String 0..1 attr Allows a textual documentation of the intended interrupt
source.
Table 5.8: BswInterruptEntity

75 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10273] Existence of attribute BswInterruptEntity.interruptCat-

egory dFor each BswInterruptEntity, the attribute interruptCategory
shall exist at the time when the configuration of the BSW module is
finished.c()
[constr_10274] Existence of attribute BswInterruptEntity.interrupt-
Source dFor each BswInterruptEntity, the attribute interruptSource
shall exist at the time when the configuration of the BSW module is
finished.c()
Enumeration BswInterruptCategory
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Category of the interrupt service
Aggregated by BswInterruptEntity.interruptCategory
Literal Description
cat1 Cat1 interrupt routines are not controlled by the OS and are only allowed to make a very limited
selection of OS calls to enable and disable all interrupts. The BswInterruptEntity is implemented by
the interrupt service routine, which is directly called from the interrupt vector (not via the OS).
Tags: atp.EnumerationLiteralIndex=0
cat2 Cat2 interrupt routines are controlled by the OS and they are allowed to make OS calls. The Bsw
InterruptEntity is implemented by the interrupt handler, which is called from the OS.
Tags: atp.EnumerationLiteralIndex=1

Table 5.9: BswInterruptCategory

BswInterruptEntity represents an interrupt routine for which the following con-

straints apply:
[constr_4018] BswInterruptEntity constraints d
• BswInterruptEntity.implementedEntry.callType shall be ’inter-
rupt’
• BswInterruptEntity.implementedEntry.executionContext shall be
’interruptCat1’ if and only if BswInterruptEntity.interruptCate-
gory is ’Cat1’
• BswInterruptEntity.implementedEntry.executionContext shall be
’interruptCat2’ if and only if BswInterruptEntity.interruptCate-
gory is ’Cat2’
c()

5.3 BSW Module Call Point

5.3.1 Overview

By aggregation of BswModuleCallPoints a BswModuleEntity defines how it uses

BswModuleEntry-s in order to call into other (or the same) BSW module.

76 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Referrable ARElement
BswDirectCallPoint
BswModuleCallPoint +calledEntry AtpBlueprint
AtpBlueprintable
0..1 BswInterfaces::BswModuleEntry

+encapsulatedEntry 0..1

BswSynchronousServerCallPoint Referrable
+calledEntry
BswInterfaces::
0..1 BswModuleClientServerEntry

+calledEntry
BswAsynchronousServerCallPoint

0..1

+asynchronousServerCallPoint 0..1

BswAsynchronousServerCallResultPoint

Figure 5.3: Details of BswModuleCallPoint

Class BswModuleCallPoint (abstract)

Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Represents a point at which a BswModuleEntity handles a procedure call into a BswModuleEntry, either
directly or via the BSW Scheduler.
Base ARObject, Referrable
Subclasses BswAsynchronousServerCallPoint, BswAsynchronousServerCallResultPoint, BswDirectCallPoint, Bsw
SynchronousServerCallPoint
Aggregated by BswModuleEntity .callPoint
Attribute Type Mult. Kind Note
context BswDistinguished * ref The existence of this reference indicates that the call
Limitation Partition point is used only in the context of the referred Bsw
DistinguishedPartitions.

Table 5.10: BswModuleCallPoint

5.3.2 Direct Call Points

[TPS_BSWMDT_04018] Usage of BswDirectCallPoint dThe meta-class BswDi-

rectCallPoint aggregated in the role callPoint in a BswModuleEntity al-
lows to declare which entry of another module (or the same module) is called in the
code of the given BswModuleEntity directly, i.e. not via the BSW Scheduler.c(RS_-
BSWMD_00047)

77 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class BswDirectCallPoint
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Represents a concrete point in the code from where a BswModuleEntry is called directly, i.e. not via the
BSW Scheduler.
This information can be used to analyze call tree and resource locking scenarios. It is not needed to
configure the BSW Scheduler.
Base ARObject, BswModuleCallPoint, Referrable
Aggregated by BswModuleEntity .callPoint
Attribute Type Mult. Kind Note
calledEntry BswModuleEntry 0..1 ref The BswModuleEntry called at this point.
calledFrom ExclusiveAreaNesting 0..1 ref This indicates that the call point is located at the deepest
WithinExclusive Order level inside one or more ExclusiveAreas that are nested
Area in the given order.

Table 5.11: BswDirectCallPoint

[constr_10275] Existence of the reference in the role BswDirectCall-

Point.calledEntry dFor each BswDirectCallPoint, the reference in the
role calledEntry shall exist at the time when the configuration of the
BSW module is finished.c()
Note that this is not a mandatory information in order to be able to integrate a mod-
ule, but it is a very important information if an integrator wants to analyze a call chain
among several modules in order to setup a proper scheduling. It is further important
to note that this attribute contains additional information in comparison to BswMod-
uleDescription.bswModuleDependency, because the latter only denotes the de-
pendencies between the module interfaces whereas calledEntry shows from which
code fragment a call is actually invoked.
In addition, a BswDirectCallPoint contains information about resource locking see
5.5.
Of course, the execution context (like task, interrupt, etc.) is preserved during a direct
call:
[constr_4015] calledEntry constraints for direct calls dThe following holds if
callPoint is aggregated as an instance of BswDirectCallPoint:
• BswModuleEntity.callPoint.calledEntry.executionContext shall be
identical to BswModuleEntity.implementedEntry.executionContext
• BswModuleEntity.callPoint.calledEntry.callType shall have the value
’regular’ or ’callback’
c()

78 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

5.3.3 Client-Server Call Points

[TPS_BSWMDT_04102] Usage of BswSynchronousServerCallPoint dThe

meta-class BswSynchronousServerCallPoint aggregated in the role callPoint
in a BswModuleEntity allows to declare which entry of another module (or the same
module) is called synchronously in the code of the client-side BswModuleEntity via
the BSW Scheduler.
The intended use case is inter-partition or inter-core communication.1 Note that it is a
valid use case for a given BswInternalBehavior to have two different BswMod-
uleEntity-s which eventually run on different partitions and/or processor cores.c
(RS_BSWMD_00066)
Class BswSynchronousServerCallPoint
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Represents a synchronous procedure call point via the BSW Scheduler.
Base ARObject, BswModuleCallPoint, Referrable
Aggregated by BswModuleEntity .callPoint
Attribute Type Mult. Kind Note
calledEntry BswModuleClientServer 0..1 ref The entry to be called.
Entry
calledFrom ExclusiveAreaNesting 0..1 ref This indicates that the call point is located at the deepest
WithinExclusive Order level inside one or more ExclusiveAreas that are nested
Area in the given order.

Table 5.12: BswSynchronousServerCallPoint

[constr_10276] Existence of the reference in the role BswSynchronousServer-

CallPoint.calledEntry dFor each BswSynchronousServerCallPoint, the
reference in the role calledEntry shall exist at the time when the configu-
ration of the BSW module is finished.c()
In the same way as a BswDirectCallPoint also a BswSynchronousServer-
CallPoint contains information about resource locking see 5.5.

[TPS_BSWMDT_04104] Usage of BswAsynchronousServerCallPoint dThe

meta-class BswAsynchronousServerCallPoint aggregated in the role call-
Point in a BswModuleEntity allows to declare which entry of another module (or
the same module) is called asynchronously in the code of the client-side BswMod-
uleEntity via the BSW Scheduler.
The intended use case is inter-partition or inter-core communication. Note that it is a
valid use case for a given BswInternalBehavior to have two different BswMod-
uleEntity-s which eventually run on different partitions and/or processor cores.c
(RS_BSWMD_00066)

1
This does not exclude configurations where client and server are executed in the same partition
within the limits defined by contextLimitation.

79 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class BswAsynchronousServerCallPoint
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Represents an asynchronous procedure call point via the BSW Scheduler.
Base ARObject, BswModuleCallPoint, Referrable
Aggregated by BswModuleEntity .callPoint
Attribute Type Mult. Kind Note
calledEntry BswModuleClientServer 0..1 ref The entry to be called.
Entry

Table 5.13: BswAsynchronousServerCallPoint

[constr_10277] Existence of the reference in the role BswAsynchronousServer-

CallPoint.calledEntry dFor each BswAsynchronousServerCallPoint, the
reference in the role calledEntry shall exist at the time when the configu-
ration of the BSW module is finished.c()
[TPS_BSWMDT_04105] Usage of BswAsynchronousServerCallResultPoint
dThe meta-class BswAsynchronousServerCallResultPoint aggregated in the
role callPoint in a BswModuleEntity indicates that the client-side BswMod-
uleEntity has the possibility to retrieve the results (return value and arguments)
of a former asynchronous call done via the associated BswAsynchronousServer-
CallPoint.c(RS_BSWMD_00066)
Class BswAsynchronousServerCallResultPoint
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note The callback point for an BswAsynchronousServerCallPoint i.e. the point at which the result can be
retrieved from the BSW Scheduler.
Base ARObject, BswModuleCallPoint, Referrable
Aggregated by BswModuleEntity .callPoint
Attribute Type Mult. Kind Note
asynchronous BswAsynchronous 0..1 ref The call point invoking the call to which the result belongs.
ServerCallPoint ServerCallPoint

Table 5.14: BswAsynchronousServerCallResultPoint

[constr_10278] Existence of the reference in the role BswAsynchronousServer-

CallResultPoint.asynchronousServerCallPoint dFor each BswAsyn-
chronousServerCallResultPoint, the reference in the role asyn-
chronousServerCallPoint shall exist at the time when the configu-
ration of the BSW module is finished.c()
Note that the BswModuleEntity that retrieves such a result may be scheduled in dif-
ferent ways: It may be started via a BswAsynchronousServerCallReturnsEvent
and/or by other kind of BswEvents.

[constr_4079] calledEntry constraints for client-server calls d

• The BswModuleClientServerEntry aggregated as calledEntry in a
BswSynchronousServerCallPoint shall have the attribute isSynchronous
= true.

80 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• The BswModuleClientServerEntry aggregated as calledEntry in

a BswAsynchronousServerCallPoint shall have the attribute isSyn-
chronous = false.
c()

5.4 BSW Sender-Receiver Data Access

By aggregation of meta-class BswVariableAccess a BswModuleEntity defines
how it accesses data for (potential) inter-partition communication with another (or the
same) BSW module.
ARElement
+providedData AutosarDataPrototype
AtpBlueprint
AtpBlueprintable VariableDataPrototype
«atpVariation,atpSplitable» 0..*
AtpStructureElement
BswModuleDescription
+requiredData

«atpVariation,atpSplitable» 0..*

+accessedVariable 0..1
«atpSplitable»

+internalBehavior 0..*

InternalBehavior
BswInternalBehavior

«atpVariation,atpSplitable»

+entity 0..*
Referrable
ExecutableEntity +dataSendPoint BswVariableAccess
BswModuleEntity «atpVariation,atpSplitable» 0..*

+dataReceivePoint
«atpVariation,atpSplitable»
0..*

Figure 5.4: Usage of BswVariableAccess

Class BswVariableAccess
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note The presence of a BswVariableAccess implies that a BswModuleEntity needs access to a VariableData
Prototype via the BSW Scheduler.
The kind of access is specified by the role in which the class is used.
Base ARObject, Referrable
Aggregated by BswModuleEntity .dataReceivePoint, BswModuleEntity .dataSendPoint
Attribute Type Mult. Kind Note
accessed VariableDataPrototype 0..1 ref The data accessed via the BSW Scheduler.
Variable
context BswDistinguished * ref The existence of this reference indicates that the variable
Limitation Partition is received resp. sent only in the context of the referred
BswDistinguishedPartitions.

Table 5.15: BswVariableAccess

81 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10279] Existence of the reference in the role BswVariableAccess.ac-

cessedVariable dFor each BswVariableAccess, the reference in the role ac-
cessedVariable shall exist at the time when the configuration of the
BSW module is finished.c()
[TPS_BSWMDT_04106] BswModuleEntity attributes for sender-receiver data
exchange dThe attributes BswModuleEntity.dataSendPoint and BswModuleEn-
tity.dataReceivePoint specify, that this BswModuleEntity has access to the
BSW Scheduler in order to send resp. receive the data declared in the referred Vari-
ableDataPrototype. This is targeted at inter-partition and/or multicore communica-
tion scenarios.2 c(RS_BSWMD_00067)

5.5 BSW Exclusive Areas

[TPS_BSWMDT_04073] Exclusive area in BSW dThe meta-class ExclusiveArea
(including the associations from ExecutableEntity) is not specific for the Basic
Software, is is imported from the CommonStructure package of the meta-model and
is defined as follows:c(RS_BSWMD_00060)
Class ExclusiveArea
Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note Prevents an executable entity running in the area from being preempted.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by InternalBehavior .exclusiveArea
Attribute Type Mult. Kind Note
– – – – –
Table 5.16: ExclusiveArea

For certain implementations of the ExclusiveArea mechanisms it is advantageous

if each BswModuleEntity uses a distinct set of enter and exit APIs. This distinct
set of APIs support ExclusiveArea implementations where for the highest prior
RunnableEntity(s) the lock is omitted. This is possible when the highest prior
BswModuleEntity(s) cannot get interrupted by BswModuleEntitys scheduled with
lower priority in any circumstance. To support this kind of implementations the software
component description has to state that it requests APIs individually for each BswMod-
uleEntity accessing an ExclusiveArea with the canEnterExclusiveArea manner.
Class BswExclusiveAreaPolicy
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note The ExclusiveArea for which the BSW Scheduler using this policy.
Base ARObject, BswApiOptions
5

2
This does not exclude configurations where sender and receiver are executed in the same partition
within the limits defined by contextLimitation.

82 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswExclusiveAreaPolicy
Aggregated by BswInternalBehavior.exclusiveAreaPolicy
Attribute Type Mult. Kind Note
apiPrinciple ApiPrincipleEnum 0..1 attr Specifies for this ExclusiveArea if either one common set
of Enter and Exit APIs for the whole BSW module is
requested from the SchM or if the set of Enter and Exit
APIs is expected per BswModuleEntity. The default value
is "common".
exclusiveArea ExclusiveArea 0..1 ref The ExclusiveArea for which the BSW Scheduler using
this policy.

Table 5.17: BswExclusiveAreaPolicy

[constr_10280] Existence of the reference in the role BswExclusiveAreaPol-

icy.exclusiveArea dFor each BswExclusiveAreaPolicy, the reference in the
role exclusiveArea shall exist at the time when the configuration of
the BSW module is finished.c()
Enumeration ApiPrincipleEnum
Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note This enumeration represents the ability to control the granularity of API generation.
Aggregated by BswExclusiveAreaPolicy.apiPrinciple, SwcExclusiveAreaPolicy.apiPrinciple
Literal Description
common The Rte or SchM API is provided for the whole software component / BSW Module
Tags: atp.EnumerationLiteralIndex=0
perExecutable The Rte or SchM API is provided for a specific ExecutableEntity of a software component / BSW
Module
Tags: atp.EnumerationLiteralIndex=1

Table 5.18: ApiPrincipleEnum

[TPS_BSWMDT_04154] ExclusiveArea is entered and exit by common set

of API dIf the BswExclusiveAreaPolicy.apiPrinciple is set to "common" the
SchM provides one sets of enter and exit APIs for the whole BSW module.c(RS_-
BSWMD_00064)
In this case the same enter and exit code is executed by all affected BswModuleEn-
titys and there is no way to have a special treatment for the BswModuleEntitys
executed in the highest prior context.
[TPS_BSWMDT_04155] ExclusiveArea is entered and exit by individual set of
API dIf the BswExclusiveAreaPolicy.apiPrinciple is set to "perExecutable" the
SchM provides individual sets of enter and exit APIs for each affected BswModuleEn-
tity.c(RS_BSWMD_00064)
In this case enter and exit code for the BswModuleEntity executed in the highest
priority context can be left empty.
To avoid contradicting settings of BswExclusiveAreaPolicys for one Exclu-
siveArea [constr_4097] applies.

83 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_4097] Limitation on the number of BswExclusiveAreaPolicys dAn Ex-

clusiveArea can only be referenced by at most one BswExclusiveAreaPolicy.c
()
Figure 5.5 shows the detailed meta-model of exclusive areas in BSW.
AtpStructureElement Referrable
+exclusiveAreaNestingOrder
InternalBehavior ExclusiveAreaNestingOrder
«atpVariation,atpSplitable» 0..*

«atpVariation,atpSplitable»
0..* 0..1 0..1
+exclusiveArea 0..*

+calledFromWithinExclusiveArea

+calledFromWithinExclusiveArea
+exclusiveAreaNestingOrder
+exclusiveArea
Identifiable
ExclusiveArea 0..*
{ordered}

+canEnter 0..* +runsInside 0..*

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

Identifiable
ExecutableEntity

BswInternalBehavior BswModuleEntity
+entity

«atpVariation,atpSplitable»0..*

«atpVariation,atpSplitable»

+callPoint 0..*

Referrable
BswDirectCallPoint
BswModuleCallPoint

BswSynchronousServerCallPoint

Figure 5.5: Details of defining ExclusiveAreas in BSWMDT

In addition to defining that a BswModuleEntity can enter an exclusive area or com-

pletely runs in an exclusive area, it is possible to define possible nesting orders of
exclusive areas. Furthermore one can define at which level of a nesting order function
calls are invoked from the BswModuleEntity. The information on nesting orders can
be used to analyze the call tree with respect to resource locking scenarios.
Class ExclusiveAreaNestingOrder
Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note This meta-class represents the ability to define a nesting order of ExclusiveAreas. A nesting order (that
may occur in the executable code) is formally defined to be able to analyze the resource locking behavior.
Base ARObject, Referrable
Aggregated by InternalBehavior .exclusiveAreaNestingOrder
Attribute Type Mult. Kind Note
exclusiveArea ExclusiveArea * ref This represents a specific scenario of how Exclusive
(ordered) Areas can be used in terms of the nesting order.

Table 5.19: ExclusiveAreaNestingOrder

84 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04081] ExclusiveAreaNestingOrder dThe optional Exclu-

siveAreaNestingOrders shall (if used at all) describe possible nesting orders (in-
cluding single ExclusiveAreas) which can occur in the BswModuleEntity. Each
possible locking situation requires its own ExclusiveAreaNestingOrder.c(RS_-
BSWMD_00064)
[TPS_BSWMDT_04082] Indicate that the locking behavior is fully described for
BswModuleEntity dAll ExclusiveAreas which are configured in the Internal-
Behavior should be referenced by an ExclusiveAreaNestingOrder to indicate
that the locking behavior is fully described for the corresponding BswModuleEntity-
s.c(RS_BSWMD_00064)
[TPS_BSWMDT_04083] Locking behavior is not described for BswModuleEn-
tity-s dIf ExclusiveAreas are not referenced by any ExclusiveAreaNestin-
gOrder (this is the default scenario), this means that the locking behavior is not
described for the corresponding BswModuleEntity-s and the provided information
might be incomplete and cannot be used for a global offline analysis of locking behav-
ior.c(RS_BSWMD_00064)
[TPS_BSWMDT_04084] Relation of BswModuleCallPoint to ExclusiveAre-
aNestingOrder dIn case other BswModuleEntitys are called from within the
BswModuleEntity the ExclusiveAreaNestingOrder can then be referenced by
one or several BswModuleCallPoints to specify the calling environment of the in-
voked function with regard to ExclusiveAreas.c(RS_BSWMD_00064)

5.6 BSW Scheduler Name Prefix

[TPS_BSWMDT_04020] Usage of BswSchedulerNamePrefix dThe Basic Software
Scheduler API defines several generated artifacts (macro code and header file names)
containing a so-called module prefix. This is by default derived from the attribute
BswModuleDescription.shortName.
However in order to allow a more fine granular definition of these artifacts, it is pos-
sible to specify own prefixes within a BswInternalBehavior and assign them indi-
vidually to each BswSchedulableEntity. Such an assignment will supersede the
prefix given by BswModuleDescription.shortName. This is especially useful if the
BSWMD in questions represents a cluster of several other modules.c(RS_BSWMD_-
00014, RS_BSWMD_00030)
Note that this prefix cannot be used to modify any names visible in the module’s inter-
face to other modules, namely module abbreviations being part of BswModuleEntry.
shortName cannot be superseded by it.
Figure 5.6 and the following class table show how the meta-class BswScheduler-
NamePrefix is placed in the meta-model. Refer to [10] for the details how this infor-
mation is used by the RTE generator.

85 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

InternalBehavior ExecutableEntity
+entity BswModuleEntity
BswInternalBehavior
«atpVariation,atpSplitable» 0..*

«atpVariation,atpSplitable»

+schedulerNamePrefix +schedulerNamePrefix
0..* 0..1

ImplementationProps
BswSchedulerNamePrefix

Figure 5.6: Name Prefix for BSW Scheduler artifacts

Class BswSchedulerNamePrefix
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note A prefix to be used in names of generated code artifacts which make up the interface of a BSW module
to the BswScheduler.
Base ARObject, ImplementationProps, Referrable
Aggregated by BswInternalBehavior.schedulerNamePrefix
Attribute Type Mult. Kind Note
– – – – –
Table 5.20: BswSchedulerNamePrefix

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 Mult. Kind Note
symbol CIdentifier 0..1 attr The symbol to be used as (depending on the concrete
case) either a complete replacement or a prefix.

Table 5.21: ImplementationProps

5.7 BSW Event

5.7.1 Overview

[TPS_BSWMDT_04021] Usage of BswEvent dThe abstract class BswEvent is

used as base class for all kinds of events which can start a BswModuleEntity
(which means it does not include direct function calls that are not visible to the BSW
Scheduler).c(RS_BSWMD_00053, RS_BSWMD_00054, RS_BSWMD_00057) Figure
5.7 gives an overview on these events and their association to the different kinds of
BswModuleEntity.

86 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

InternalBehavior
BswInternalBehavior

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

+event 0..* +entity 0..*

AbstractEvent +startsOnEvent ExecutableEntity

BswEvent BswModuleEntity
0..1

BswOperationInvokedEvent BswScheduleEvent BswInterruptEvent BswCalledEntity BswSchedulableEntity

BswBackgroundEvent BswTimingEvent

+ period: TimeValue [0..1]

BswExternalTriggerOccurredEvent BswInternalTriggerOccurredEvent

BswModeSwitchedAckEvent BswModeSwitchEvent

+ activation: ModeActivationKind [0..1]

BswModeManagerErrorEvent BswDataReceivedEvent

BswOsTaskExecutionEvent BswAsynchronousServerCallReturnsEvent

Figure 5.7: Overview on BswEvents

Class BswEvent (abstract)

Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Base class of various kinds of events which are used to trigger a BswModuleEntity of this BSW module or
cluster. The event is local to the BSW module or cluster. The short name of the meta-class instance is
intended as an input to configure the required API of the BSW Scheduler.
Base ARObject, AbstractEvent, Identifiable, MultilanguageReferrable, Referrable
Subclasses BswInterruptEvent, BswOperationInvokedEvent, BswScheduleEvent
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
context BswDistinguished * ref The existence of this reference indicates that the usage of
Limitation Partition the event is limited to the context of the referred Bsw
DistinguishedPartitions.
disabledInMode ModeDeclaration * iref The modes, in which this event is disabled.
Stereotypes: atpSplitable
Tags: atp.Splitkey=disabledInMode.contextMode
DeclarationGroup, disabledInMode.targetMode
InstanceRef implemented by: ModeInBswModule
DescriptionInstanceRef
startsOnEvent BswModuleEntity 0..1 ref The entity which is started by the event.

Table 5.22: BswEvent

87 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10328] Existence of the reference in the role BswEvent.startsOnEvent

dFor each BswEvent, the reference in the role startsOnEvent shall exist at the
time when the configuration of the BSW module is finished.c()
Class BswScheduleEvent (abstract)
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note BswEvent that is able to start a BswSchedulabeEntity.
Base ARObject, AbstractEvent, BswEvent, Identifiable, MultilanguageReferrable, Referrable
Subclasses BswAsynchronousServerCallReturnsEvent, BswBackgroundEvent, BswDataReceivedEvent, Bsw
ExternalTriggerOccurredEvent, BswInternalTriggerOccurredEvent, BswModeManagerErrorEvent, Bsw
ModeSwitchEvent, BswModeSwitchedAckEvent, BswOsTaskExecutionEvent, BswTimingEvent
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
– – – – –
Table 5.23: BswScheduleEvent

[constr_1275] Applicability of reference startsOnEvent for BswSched-

uleEvent dThe reference BswScheduleEvent.startsOnEvent shall only refer to
a BswSchedulableEntity.c()
[constr_1276] Applicability of reference startsOnEvent for BswOperationIn-
vokedEvent dThe reference BswOperationInvokedEvent.startsOnEvent shall
only refer to a BswCalledEntity.c()
Class BswInterruptEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This meta-class represents an event triggered by an interrupt.
Base ARObject, AbstractEvent, BswEvent, Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
– – – – –
Table 5.24: BswInterruptEvent

5.7.2 Timing and Background Events

[TPS_BSWMDT_04022] Timing and background events for BSW dA

BswTimingEvent and BswBackgroundEvent are directly driven by the Scheduler
resp. OS without external sources.c(RS_BSWMD_00053)
Class BswTimingEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note A recurring BswEvent driven by a time period.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
5

88 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswTimingEvent
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
period TimeValue 0..1 attr Requirement for the time period (in seconds) by which
this event is triggered.

Table 5.25: BswTimingEvent

[constr_10281] Existence of attribute BswTimingEvent.period dFor each

BswTimingEvent, the attribute period shall exist at the time when the con-
figuration of the BSW module is finished.c()
[constr_4043] Period of BswTimingEvent dBswTimingEvent.period shall be
greater than 0.c()
Class BswBackgroundEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note A recurring BswEvent which is used to perform background activities. It is similar to a BswTimingEvent
but has no fixed time period and is activated only with low priority.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
– – – – –
Table 5.26: BswBackgroundEvent

Class BswOsTaskExecutionEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This BswEvent is supposed to execute BswSchedulableEntitys which have to react on the execution of
specific OsTasks. Therefore, this event is unconditionally raised whenever the OsTask on which it is
mapped is executed. The main use case for this event is scheduling of Runnables of Complex Drivers
which have to react on task executions.
Tags: atp.Status=draft
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
– – – – –
Table 5.27: BswOsTaskExecutionEvent

5.7.3 Trigger Events

Figure 5.8 and the following tables give a more detailed picture on the events driven by
internal or external triggers.
Note the difference in the activation of internally triggered events and timing events:

89 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04023] Internal trigger and timing events for BSW dA BswMod-

uleEntity can trigger a BswInternalTriggerOccurredEvent (of the same
module) with the help of an API generated by the BSW Scheduler, whereas a
BswTimingEvent is triggered by the BswScheduler via the OS timer.c(RS_BSWMD_-
00053, RS_BSWMD_00057) Further information can be found in [10].
[TPS_BSWMDT_04024] External trigger event for BSW dThe BswExternalTrig-
gerOccurredEvent specifies the fact that the event is raised in response to a trig-
ger issued by another BSW module. This can for example be used to communicate
ECU-external events, like wakeup-events or crank-shaft-events directly between BSW
modules.c(RS_BSWMD_00057)
[constr_4023] External trigger shall belong to the interface dA BswExternal-
TriggerOccurredEvent shall refer to a Trigger that is declared via BswMod-
uleDescription.requiredTrigger for the same module.c()
ARElement
AtpBlueprint
AtpStructureElement
AtpBlueprintable
+requiredTrigger Identifiable
AtpStructureElement +trigger
Trigger
BswModuleDescription «atpVariation,atpSplitable» 0..*
0..1
+ swImplPolicy: SwImplPolicyEnum [0..1]

«atpSplitable»

+internalBehavior 0..*

InternalBehavior +entity ExecutableEntity

BswInternalBehavior «atpVariation,atpSplitable» 0..* BswModuleEntity

+startsOnEvent 0..1

BswSchedulableEntity

«atpVariation,atpSplitable»

AbstractEvent
+event
BswEvent
«atpVariation,atpSplitable» 0..*

BswScheduleEvent
«atpVariation,atpSplitable»

+internalTriggeringPoint 0..*

Identifiable +activationPoint
BswInternalTriggeringPoint 0..* BswInternalTriggerOccurredEvent BswExternalTriggerOccurredEvent
+ swImplPolicy: SwImplPolicyEnum [0..1]
+eventSource

0..1

Figure 5.8: Details on BSW Trigger Events

90 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class BswInternalTriggeringPoint
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Represents the activation point for one or more BswInternalTriggerOccurredEvents.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswInternalBehavior.internalTriggeringPoint
Attribute Type Mult. Kind Note
swImplPolicy SwImplPolicyEnum 0..1 attr This attribute, when set to value queued, specifies a
queued processing of the internal trigger event.

Table 5.28: BswInternalTriggeringPoint

In a similar way as for external triggers, the BswInternalTriggeringPoint can set

an attribute to define its queuing behavior:
[constr_4065] Allowed values of BswInternalTriggeringPoint.swImplPol-
icy dThe only allowed values for the attribute BswInternalTriggeringPoint.
swImplPolicy are either STANDARD (in which case the internal trigger processing
does not use a queue) or QUEUED (in which case the internal trigger processing uses
a queue).c()
Class BswInternalTriggerOccurredEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note A BswEvent, which can happen sporadically. The event is activated by explicit calls from the module to
the BSW Scheduler. The main purpose for such an event is to cause a context switch, e.g. from an ISR
context into a task context. Activation and switching are handled within the same module or cluster only.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
eventSource BswInternalTriggering 0..1 ref The activation point is the source of this event.
Point
Table 5.29: BswInternalTriggerOccurredEvent

[constr_10282] Existence of the reference in the role BswInternalTriggerOc-

curredEvent.eventSource dFor each BswInternalTriggerOccurredEvent,
the reference in the role eventSource shall exist at the time when the con-
figuration of the BSW module is finished.c()
Class BswExternalTriggerOccurredEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note A BswEvent resulting from a trigger released by another module or cluster.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
trigger Trigger 0..1 ref The trigger associated with this event. The trigger is
external to this module.
Table 5.30: BswExternalTriggerOccurredEvent

91 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10283] Existence of the reference in the role BswExternalTriggerOc-

curredEvent.trigger dFor each BswExternalTriggerOccurredEvent, the
reference in the role trigger shall exist at the time when the configura-
tion of the BSW module is finished.c()
In addition to these mechanisms, external events can directly trigger a BswInter-
ruptEntity by the means of an interrupt. This situation is not part of the event model,
because it is not handled via the BSW Scheduler and is local to a BSW module.

5.7.4 Mode Events

Figure 5.9 and the following tables give a more detailed picture on the events and
further classes related to mode switches.
Mode switches can influence the activation of BswEvents by different mechanisms:
[TPS_BSWMDT_04025] Mode switches and events in BSW d
• Via the optional attribute disabledInMode a BswEvent can specify, that it has
to be suppressed in a certain mode.
• A special kind of event, the BswModeSwitchEvent can be used to start a
BswModuleEntity at the entry or exit of a specific mode.
• At the sender side of a mode switch (i.e. in the module managing the mode
group), a BswModeSwitchedAckEvent can be used to start a BswModuleEn-
tity after a mode switch has been acknowledged by the BSW Scheduler.
• At the sender side of a mode switch (i.e. in the module managing the mode
group), a BswModeManagerErrorEvent can be used to start a BswMod-
uleEntity after an error has been announced. This event will be thrown by
the BSW Scheduler after an error that lead to the termination of one of the parti-
tions involved. This could be the partition in which the mode switch was managed
or the partition in which it was used.
c(RS_BSWMD_00054, RS_BSWMD_00056)
The referred ModeDeclaration and the enumeration ModeActivationKind are
both imported from the CommonStructure package of the meta-model.
[constr_4024] Semantics of BSW mode switch event dIf BswModeSwitchEvent.
activation has the value onTransition BswModeSwitchEvent shall refer to two
different modes belonging to the same instance of ModeDeclarationGroup, their order
defining the direction of the transition. In all other cases, BswModeSwitchEvent shall
refer to exactly one mode.c()
[constr_4066] BswModeSwitchEvent and the definition of ModeTransition dFor
each pair of ModeDeclarations referenced by a BswModeSwitchEvent with at-
tribute activation set to onTransition a ModeTransition shall be defined in
the corresponding direction (i.e. from exitedMode to enteredMode). This constraint

92 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

shall only apply if the respective ModeDeclarationGroup defines at least one mod-
eTransition.c()
[constr_4025] Modes used by BSW mode switch event dThe ModeDeclaration
used by BswModeSwitchEvent shall belong to the ModeDeclarationGroupPro-
totype referred as BswInternalBehavior.entity.accessedModeGroup of the
enclosing BswInternalBehavior.c()
[constr_4026] Mode group used by BSW mode switch acknowledge event dThe
ModeDeclarationGroupPrototype used by BswModeSwitchedAckEvent shall
be referred as BswModuleDescription.providedModeGroup by the same mod-
ule.c()
[constr_4081] Mode group used by BSW mode manager error event dThe Mod-
eDeclarationGroupPrototype used by BswModeManagerErrorEvent shall be
referred as BswModuleDescription.providedModeGroup by the same module.c
()

93 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement AtpPrototype
AtpBlueprint +requiredModeGroup
ModeDeclarationGroupPrototype
AtpBlueprintable
«atpVariation,atpSplitable» 0..*
AtpStructureElement + swCalibrationAccess: SwCalibrationAccessEnum [0..1]
BswModuleDescription
+providedModeGroup

«atpVariation,atpSplitable» 0..*

+accessedModeGroup 0..* 0..1

0..1
«atpSplitable»
«atpVariation,atpSplitable»
+internalBehavior 0..*
+modeGroup +modeGroup
InternalBehavior
BswInternalBehavior ExecutableEntity
+entity BswModuleEntity
«atpVariation,atpSplitable»
0..*
+startsOnEvent
0..1

BswSchedulableEntity

«atpVariation,atpSplitable»

+event 0..*

AbstractEvent
BswEvent BswScheduleEvent
BswModeSwitchedAckEvent

«isOfType»

BswModeManagerErrorEvent

«enumeration»
ModeActivationKind

onEntry
BswModeSwitchEvent
onExit
onTransition + activation:
ModeActivationKind [0..1]

«instanceRef,atpSplitable» «instanceRef»

0..2
+mode
{ordered}

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

+ onTransitionValue: PositiveInteger [0..1]

+modeUserErrorBehavior 0..1 +modeManagerErrorBehavior

0..1

«enumeration» ModeErrorBehavior
ModeErrorReactionPolicyEnum
+ errorReactionPolicy: ModeErrorReactionPolicyEnum [0..1]
lastMode
defaultMode

Figure 5.9: Details on BSW Events related to Mode Switches

Class BswModeSwitchEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note A BswEvent resulting from a mode switch.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
5

94 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModeSwitchEvent
Attribute Type Mult. Kind Note
activation ModeActivationKind 0..1 attr Kind of activation w.r.t. to the referred mode.
mode (ordered) ModeDeclaration 0..2 iref Reference to one or two Modes that initiate the Mode
Switch Event.
InstanceRef implemented by: ModeInBswModule
DescriptionInstanceRef

Table 5.31: BswModeSwitchEvent

[constr_10284] Existence of attribute BswModeSwitchEvent.activation dFor

each BswModeSwitchEvent, the attribute activation shall exist at the time
when the configuration of the BSW module is finished.c()
Class BswModeSwitchedAckEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note The event is raised after a switch of the referenced mode group has been acknowledged or an error
occurs. The referenced mode group shall be provided by this module.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
modeGroup ModeDeclarationGroup 0..1 ref A mode group provided by this module. The
Prototype acknowledgement of a switch of this group raises this
event.
Table 5.32: BswModeSwitchedAckEvent

[constr_10285] Existence of the reference in the role BswModeSwitchedAck-

Event.modeGroup dFor each BswModeSwitchedAckEvent, the reference in the
role modeGroup shall exist at the time when the configuration of the
BSW module is finished.c()
Class BswModeManagerErrorEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This represents the ability to react on errors occurring during mode handling.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
modeGroup ModeDeclarationGroup 0..1 ref This represents the ModeDeclarationGroupPrototype for
Prototype which the error behavior of the mode manager applies.

Table 5.33: BswModeManagerErrorEvent

[constr_10286] Existence of the reference in the role BswModeManager-

ErrorEvent.modeGroup dFor each BswModeManagerErrorEvent, the reference
in the role modeGroup shall exist at the time when the configuration of
the BSW module is finished.c()

95 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration ModeActivationKind
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note Kind of mode switch condition used for activation of an event, as further described for each
enumeration field.
Aggregated by BswModeSwitchEvent.activation, SwcModeSwitchEvent.activation
Literal Description
onEntry On entering the referred mode.
Tags: atp.EnumerationLiteralIndex=0
onExit On exiting the referred mode.
Tags: atp.EnumerationLiteralIndex=1
onTransition On transition of the 1st referred mode to the 2nd referred mode.
Tags: atp.EnumerationLiteralIndex=2

Table 5.34: ModeActivationKind

5.7.5 BSW Events for Client-Server Communication

Figure 5.10 and the following tables give a more detailed picture on the events driven
by client-server calls. The intended use case is inter-partition and/or inter-core com-
munication.3

3
This does not exclude configurations where client and server are executed in the same partition.

96 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement +requiredClientServerEntry Referrable

AtpBlueprint
BswModuleClientServerEntry
AtpBlueprintable «atpVariation,atpSplitable» 0..*
AtpStructureElement + isReentrant: Boolean [0..1]
BswModuleDescription + isSynchronous: Boolean [0..1]
+providedClientServerEntry
+ moduleId: PositiveInteger [0..1]
«atpVariation,atpSplitable» 0..*

+entry 0..1
«atpSplitable»

+internalBehavior 0..*

InternalBehavior ExecutableEntity
+entity
BswInternalBehavior BswModuleEntity
0..*
«atpVariation,atpSplitable»

+startsOnEvent 0..1

BswSchedulableEntity BswCalledEntity

AbstractEvent BswOperationInvokedEvent
+event
BswEvent
«atpVariation,atpSplitable» 0..*

BswScheduleEvent

BswModuleCallPoint BswAsynchronousServerCallReturnsEvent
BswAsynchronousServerCallResultPoint +eventSource

0..1

Figure 5.10: Details on BSW Events related to Client-Server Communication

Class BswOperationInvokedEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This event is thrown on operation invocation in Client-Server-Communication via the BSW Scheduler. Its
"entry" reference provides the BswClientServerEntry that is called subsequently.
Note this event is not needed in case of direct function calls.
Base ARObject, AbstractEvent, BswEvent, Identifiable, MultilanguageReferrable, Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
entry BswModuleClientServer 0..1 ref The providedClientServerEntry invoked by this event.
Entry

Table 5.35: BswOperationInvokedEvent

[constr_10287] Existence of the reference in the role BswOperationInvokedE-

vent.entry dFor each BswOperationInvokedEvent, the reference in the role en-
try shall exist at the time when the configuration of the BSW module
is finished.c()

97 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_4078] Consistent usage of BswOperationInvokedEvent dThe

BswCalledEntity referred by the attribute BswOperationInvokedEvent.start-
sOnEvent shall refer to the same BswModuleEntry (via its attribute implemente-
dEntry) as the BswOperationInvokedEvent (via its attribute entry.encapsu-
latedEntry.c()
[constr_4098] No mode disabling for BswOperationInvokedEvent dA BswOp-
erationInvokedEvent shall not have a reference to a ModeDeclaration in the
role disabledInMode.c()
Class BswAsynchronousServerCallReturnsEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This is the "callback" event for asynchronous Client-Server-Communication via the BSW Scheduler
which is thrown after completion of the asynchronous Client-Server call.
Its eventSource specifies the call point to be used for retrieving the result.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
eventSource BswAsynchronous 0..1 ref The call point to be used for retrieving the result.
ServerCallResultPoint

Table 5.36: BswAsynchronousServerCallReturnsEvent

[constr_10288] Existence of the reference in the role BswAsynchronousServer-

CallReturnsEvent.eventSource dFor each BswAsynchronousServerCall-
ReturnsEvent, the reference in the role eventSource shall exist at the time
when the configuration of the BSW module is finished.c()

5.7.6 BSW Events for Sender-Receiver Communication

Figure 5.11 and the following table give a more detailed picture on the events driven
by sender-receiver calls. The intended use case is inter-partition and/or inter-core
communication.4

4
This does not exclude configurations where sender and receiver are executed in the same partition.

98 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
AtpBlueprint +providedData AutosarDataPrototype
AtpBlueprintable
«atpVariation,atpSplitable» 0..* VariableDataPrototype
AtpStructureElement
BswModuleDescription
+requiredData

«atpVariation,atpSplitable» 0..*
+data 0..1

«atpSplitable»

+internalBehavior 0..*

InternalBehavior ExecutableEntity
+entity
BswInternalBehavior BswModuleEntity
0..*
«atpVariation,atpSplitable»

+startsOnEvent 0..1

BswSchedulableEntity BswScheduleEvent

AbstractEvent
+event BswDataReceivedEvent
BswEvent
«atpVariation,atpSplitable» 0..*

Figure 5.11: Details on BSW Events related to Sender-Receiver Communication

Class BswDataReceivedEvent
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This event is thrown on reception of the referenced data via Sender-Receiver-Communication over the
BSW Scheduler.
Base ARObject, AbstractEvent, BswEvent, BswScheduleEvent, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by BswInternalBehavior.event
Attribute Type Mult. Kind Note
data VariableDataPrototype 0..1 ref The received data.

Table 5.37: BswDataReceivedEvent

[constr_10289] Existence of the reference in the role BswDataReceivedE-

vent.data dFor each BswDataReceivedEvent, the reference in the role data
shall exist at the time when the configuration of the BSW module is
finished.c()

5.8 Activation Reason of a BSW Module Entity

It is feasible to activate a given BswModuleEntity by means of several BswEvents.
In many cases, it is therefore necessary to retrieve the information about the activating
BswEvent from within the implementation of the BswModuleEntity.
As a typical use case, consider a BswSchedulableEntity that is cyclically activated
(by means of a BswTimingEvent) and in addition it shall also be executed sporadi-
cally, e.g. in response to mode switch (BswModeSwitchEvent).

99 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

By using the meta-model extract shown in Figure 5.12 (which is further explained in [6])
it is possible to generate the RTE in a way that it provides a bit vector representing the
activation reason to the BswModuleEntity.
Referrable
ImplementationProps

+ symbol: CIdentifier [0..1]

ExecutableEntityActivationReason

+ bitPosition: PositiveInteger [0..1]

0..1 +activationReasonRepresentation 0..* +activationReason

Identifiable Identifiable
AbstractEvent ExecutableEntity

BswModuleEntity

+startsOnEvent 0..1

BswSchedulableEntity

BswScheduleEvent

BswEvent

Figure 5.12: BswModuleEntity and activation reason

[TPS_BSWMDT_04089] Access to activation reason dThe same mechanism is

available for both application software and basic software, therefore the following spec-
ification items and constraints defined in [6] also hold for the BSWMDT:
• [TPS_SWCT_01469]
• [constr_1226]
• [constr_1227]
c(RS_BSWMD_00063)
An activation reason can only be provided to those BswModuleEntity-s that are
potentially triggered by BswEvents and thus are handled by the RTE. As a further
restriction, the current RTE Specification [10] does not support retrieving the activation

100 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

reason for BswCalledEntitys even if they are triggered via the BSW Scheduler. This
leads to the following constraint:
[constr_4070] Applicability of BswModuleEntity.activationReason dAn ac-
tivationReason shall not be set
• for instances of BswInterruptEntity
• for instances of BswCalledEntity
c()

5.9 BSW Communication Policy

The implementation of triggers, mode switches and sender-receiver-communication
can follow various policies which have to be known by the generator of the RTE resp.
BSW Scheduler in order to generate the correct "glue" code. The required attributes
are shown in Figures 5.13 and 5.14 and are explained in the class tables below.
This kind of information is similar to what is represented by the so-called ComSpecs
for VFB communication, see [6].
ARElement +providedModeGroup
AtpPrototype
AtpBlueprint «atpVariation,atpSplitable» 0..* ModeDeclarationGroupPrototype
AtpBlueprintable
AtpStructureElement +requiredModeGroup + swCalibrationAccess: SwCalibrationAccessEnum
BswModuleDescription [0..1]
«atpVariation,atpSplitable» 0..*

+providedModeGroup 0..1 +requiredModeGroup 0..1

AtpStructureElement
+releasedTrigger Identifiable
«atpVariation,atpSplitable»0..* Trigger

+ swImplPolicy: SwImplPolicyEnum [0..1]

+masteredTrigger 0..1

«atpSplitable»
+internalBehavior 0..*

InternalBehavior BswTriggerDirectImplementation
BswInternalBehavior
+triggerDirectImplementation + cat2Isr: Identifier [0..1]
+ task: Identifier [0..1]
«atpVariation,atpSplitable» 0..*

+modeSenderPolicy BswModeSenderPolicy

«atpVariation,atpSplitable» 0..* + enhancedModeApi: Boolean [0..1]

+ackRequest + queueLength: PositiveInteger [0..1]

BswModeSwitchAckRequest 0..1

+ timeout: TimeValue [0..1]

BswModeReceiverPolicy

+modeReceiverPolicy + enhancedModeApi: Boolean [0..1]

+ supportsAsynchronousModeSwitch: Boolean [0..1]
«atpVariation,atpSplitable» 0..*

Figure 5.13: Special Implementation Policy for Modes and Triggers

101 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class BswTriggerDirectImplementation
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specifies a released trigger to be directly implemented via OS calls, for example in a Complex Driver
module.
Base ARObject
Aggregated by BswInternalBehavior.triggerDirectImplementation
Attribute Type Mult. Kind Note
cat2Isr Identifier 0..1 attr The name of the OS category 2 ISR, which is controlled
by the referred trigger. This means, that the module
manages the category 2 ISR (e.g. according hardware
initialization and enabling of ISR). Instead of calling an
RTE / SchM API to raise the appropriate events in
components or modules receiving the trigger, this ISR
directly schedules the triggered ExecutableEntitys. The
ISR name is required by the integrator to map the Bsw
Events and RTEEvents to this ISR.
masteredTrigger Trigger 0..1 ref The trigger which is directly mastered by this module.
There may be several different BswTriggerDirect
Implementations mastering the same Trigger. This may
be required e.g. due to memory partitioning.
task Identifier 0..1 attr The name of the OS task, which is controlled by the
referred trigger. This means, that the module uses the
trigger condition to directly activate an OS task instead of
calling an API of the BswScheduler. The task name is
required by the RTE generator resp. BswScheduler to
raise the appropriate events in components or modules
receiving the trigger.

Table 5.38: BswTriggerDirectImplementation

[constr_10290] Existence of the reference in the role BswTriggerDirectImple-

mentation.masteredTrigger dFor each BswTriggerDirectImplementation,
the reference in the role masteredTrigger shall exist at the time when the
configuration of the BSW module is finished.c()
[constr_4105] Use of attribute task or cat2Isr dOnly one of the attributes is
allowed to exist. Either task or cat2Isr should be configured.c()

Class BswModeSenderPolicy
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specifies the details for the sending of a mode switch for the referred mode group.
Base ARObject
Aggregated by BswInternalBehavior.modeSenderPolicy
Attribute Type Mult. Kind Note
ackRequest BswModeSwitchAck 0..1 aggr Request for acknowledgement
Request
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.
providedMode ModeDeclarationGroup 0..1 ref The provided mode group for which the policy is specified.
Group Prototype
5

102 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswModeSenderPolicy
queueLength PositiveInteger 0..1 attr Length of call queue on the sender side. The queue is
implemented by the RTE resp.BswScheduler. The value
shall be greater or equal to 0. Setting the value of queue
Length to 0 implies non-queued communication.

Table 5.39: BswModeSenderPolicy

[constr_10291] Existence of the reference in the role BswModeSenderPolicy.

providedModeGroup dFor each BswModeSenderPolicy, the reference in the role
providedModeGroup shall exist at the time when the configuration of
the BSW module is finished.c()
[constr_10292] Existence of attribute BswModeSenderPolicy.queueLength dFor
each BswModeSenderPolicy, the attribute queueLength shall exist at the time
when the configuration of the BSW module is finished.c()
Class BswModeSwitchAckRequest
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Requests acknowledgements that a mode switch has been processed successfully
Base ARObject
Aggregated by BswModeSenderPolicy.ackRequest
Attribute Type Mult. Kind Note
timeout TimeValue 0..1 attr Number of seconds before an error is reported.

Table 5.40: BswModeSwitchAckRequest

[constr_10293] Existence of attribute BswModeSwitchAckRequest.timeout dFor

each BswModeSwitchAckRequest, the attribute timeout shall exist at the time
when the configuration of the BSW module is finished.c()
Class BswModeReceiverPolicy
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specifies the details for the reception of a mode switch for the referred mode group.
Base ARObject
Aggregated by BswInternalBehavior.modeReceiverPolicy
Attribute Type Mult. 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.
requiredMode ModeDeclarationGroup 0..1 ref The required mode group for which the policy is specified.
Group Prototype
supports Boolean 0..1 attr Specifies whether the module can handle the reception of
Asynchronous an asynchronous mode switch (true) or not (false).
ModeSwitch

Table 5.41: BswModeReceiverPolicy

103 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10294] Existence of the reference in the role BswModeReceiverPolicy.

requiredModeGroup dFor each BswModeReceiverPolicy, the reference in the
role requiredModeGroup shall exist at the time when the configuration
of the BSW module is finished.c()
[constr_10295] Existence of attribute BswModeReceiverPolicy.support-
sAsynchronousModeSwitch dFor each BswModeReceiverPolicy, the attribute
supportsAsynchronousModeSwitch shall exist at the time when the con-
figuration of the BSW module is finished.c()
[TPS_BSWMDT_04107] Data reception policy dBy aggregating a BswDataRecep-
tionPolicy a BswInternalBehavior specifies the detailed reception policy of the
referred VariableDataPrototype. Note the reception policy is the same for all
reception points - defined via BswModuleEntity.dataReceivePoint - of the re-
spective VariableDataPrototype in this module.c(RS_BSWMD_00067)
Note that due to limitations of the sender-receiver communication mechanism in BSW
(in contrast to VFB communication) it is only possible to specify queued reception.
Furthermore, there are no communication attributes on the sender side.
ARElement AutosarDataPrototype
AtpBlueprint VariableDataPrototype
AtpBlueprintable
AtpStructureElement
+requiredData
BswModuleDescription
«atpVariation,atpSplitable» 0..*

+receivedData 0..1

«atpSplitable»
+internalBehavior 0..*

InternalBehavior BswApiOptions
+receptionPolicy
BswInternalBehavior BswDataReceptionPolicy
«atpVariation,atpSplitable» 0..*

BswQueuedDataReceptionPolicy

+ queueLength: PositiveInteger
[0..1]

Figure 5.14: Implementation Policy for BSW Sender-Receiver Communication

Class BswDataReceptionPolicy (abstract)

Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specifies the reception policy for the referred data in sender-receiver communication over the BSW
Scheduler. To be used for inter-partition and/or inter-core communication.
Base ARObject, BswApiOptions
Subclasses BswQueuedDataReceptionPolicy
Aggregated by BswInternalBehavior.receptionPolicy
5

104 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BswDataReceptionPolicy (abstract)
Attribute Type Mult. Kind Note
receivedData VariableDataPrototype 0..1 ref The data received over the BSW Scheduler using this
policy.

Table 5.42: BswDataReceptionPolicy

[constr_10296] Existence of reference in the role BswDataReceptionPolicy.

receivedData dFor each BswDataReceptionPolicy, the reference in the role re-
ceivedData shall exist at the time when the configuration of the BSW
module is finished.c()
Class BswQueuedDataReceptionPolicy
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Reception policy attributes specific for queued receiving.
Base ARObject, BswApiOptions, BswDataReceptionPolicy
Aggregated by BswInternalBehavior.receptionPolicy
Attribute Type Mult. Kind Note
queueLength PositiveInteger 0..1 attr Length of queue for received events.

Table 5.43: BswQueuedDataReceptionPolicy

[constr_10297] Existence of attribute BswQueuedDataReceptionPolicy.

queueLength dFor each BswQueuedDataReceptionPolicy, the attribute
queueLength shall exist at the time when the configuration of the
BSW module is finished.c()
[constr_4080] Existence of reception policy dIf a VariableDataPrototype is re-
ferred from a dataReceivePoint of any BswModuleEntity in a given BswInter-
nalBehavior, then exactly one corresponding BswDataReceptionPolicy shall by
aggregated by this BswInternalBehavior.c()

5.10 BSW Local Data

A BSW module (or cluster) needs the ability to declare data in its BSWMD, for example
• in order to make them available for measurement and calibration tools (see chap-
ter 9)
• in order to declare these data in relation to ServiceNeeds, e.g. as NvM blocks
(see chapter 12)
[TPS_BSWMDT_04026] Local BSW data without RTE or BSW Scheduler support
dIn many cases such data in the context of a module (or cluster) do not need any
support by the RTE resp. BSW Scheduler. They are simply allocated by the module’s
code but they still may be accessed from outside of the module for measurement,
calibration or as NvM mirrors. These data are described by the following roles:

105 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• BswInternalBehavior.staticMemory for variable data

• BswInternalBehavior.constantMemory for constant data
c(RS_BSWMD_00045, RS_BSWMD_00052, RS_BSWMD_00062)
[TPS_BSWMDT_04027] Local BSW data accessed via BSW Scheduler API
dHowever it is also possible to have local data allocated by the BSW Scheduler. This
is especially required in the case of calibration with software emulation. These kind of
data are declared by:
• BswInternalBehavior.perInstanceParameter
c(RS_BSWMD_00030, RS_BSWMD_00062)
For compatibility reasons with the SWCT these various data are declared on the be-
havior level using the abstract class InternalBehavior as shown in figure 5.15. The
class table for InternalBehavior has already been listed in chapter 5.1.
AtpStructureElement +staticMemory AutosarDataPrototype
InternalBehavior VariableDataPrototype
«atpVariation,atpSplitable» 0..*

AutosarDataPrototype
+constantMemory
ParameterDataPrototype
«atpVariation,atpSplitable» 0..*

+perInstanceParameter 0..*

BswInternalBehavior

«atpVariation,atpSplitable»

Figure 5.15: BSW Local Data

[TPS_BSWMDT_04128] BSW measurement data accessed via BSW Scheduler

API dBSW measurement data accessed via BSW Scheduler API It is also possible to
have local data allocated by the BSW Scheduler. This kind of data is declared by
• BswInternalBehavior.arTypedPerInstanceMemory
c(RS_BSWMD_00030, RS_BSWMD_00062)

106 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

AtpStructureElement
InternalBehavior

BswInternalBehavior

«atpVariation,atpSplitable» «atpVariation,atpSplitable»
+arTypedPerInstanceMemory 0..* +bswPerInstanceMemoryPolicy 0..*

AutosarDataPrototype
BswPerInstanceMemoryPolicy
VariableDataPrototype
+arTypedPerInstanceMemory

0..1

BswApiOptions

+ enableTakeAddress: Boolean [0..1]

Figure 5.16: BSW Measurement Data

These data use the type system of AutosarDataPrototypes which is explained in

more detail in [6]:
Class ParameterDataPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note A ParameterDataPrototype represents a formalized generic piece of information that is typically
immutable by the application software layer, but mutable by measurement and calibration tools.
ParameterDataPrototype is used in various contexts and the specific context gives the otherwise generic
ParameterDataPrototype a dedicated semantics.
Base ARObject, AtpFeature, AtpPrototype, AutosarDataPrototype, DataPrototype, Identifiable, Multilanguage
Referrable, Referrable
Aggregated by AtpClassifier .atpFeature, BswInternalBehavior.perInstanceParameter, InternalBehavior .constant
Memory, NvBlockDescriptor.romBlock, ParameterInterface.parameter, SwcInternalBehavior.perInstance
Parameter, SwcInternalBehavior.sharedParameter
Attribute Type Mult. Kind Note
initValue ValueSpecification 0..1 aggr Specifies initial value(s) of the ParameterDataPrototype

Table 5.44: ParameterDataPrototype

Class VariableDataPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note A VariableDataPrototype represents a formalized generic piece of information that is typically mutable by
the application software layer. VariableDataPrototype is used in various contexts and the specific context
gives the otherwise generic VariableDataPrototype a dedicated semantics.
Base ARObject, AtpFeature, AtpPrototype, AutosarDataPrototype, DataPrototype, Identifiable, Multilanguage
Referrable, Referrable
5

107 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class VariableDataPrototype
Aggregated by ApplicationInterface.indication, AtpClassifier .atpFeature, BswInternalBehavior.arTypedPerInstance
Memory, BswModuleDescription.providedData, BswModuleDescription.requiredData, BulkNvData
Descriptor.bulkNvBlock, InternalBehavior .staticMemory, NvBlockDescriptor.ramBlock, NvDataInterface.
nvData, SenderReceiverInterface.dataElement, ServiceInterface.event, SwcInternalBehavior.arTypedPer
InstanceMemory, SwcInternalBehavior.explicitInterRunnableVariable, SwcInternalBehavior.implicitInter
RunnableVariable
Attribute Type Mult. Kind Note
initValue ValueSpecification 0..1 aggr Specifies initial value(s) of the VariableDataPrototype

Table 5.45: VariableDataPrototype

5.11 Synchronization with a Corresponding SWC

BSW modules which implement a ServiceSwComponentType, EcuAbstraction-
SwComponentType or ComplexDeviceDriverSwComponentType require several
mappings between their SWC description and BSWM description in order to generate
the RTE resp. the BSW Scheduler.
One use case is as follows:
[TPS_BSWMDT_04074] Synchronization of mode switches or triggers dA BSW
module which communicates via the RTE is able to provide triggers and mode switches
within the basic software and toward SWCs above the RTE as well (for example a BSW
module implementing an EcuAbstractionSwComponentType). It may happen, that
a module wants to issue a mode switch or a trigger to both BSW and to SWCs "above
the RTE" , i.e. a call via the BSW Scheduler API shall result in the same trigger resp.
mode switch as a call via the RTE port-API (details are specified in [10]). In this case
the Trigger resp. ModeDeclarationGroupPrototype provided within the BSW
shall be mapped to the Trigger resp. ModeDeclarationGroupPrototype pro-
vided by the port interface. This information is an input to configure the RTE accord-
ingly.c(RS_BSWMD_00055, RS_BSWMD_00058)
Another use case is the specification of a RunnableEntity in a BSW module in order
to allow calls to or from the RTE via ports:
[TPS_BSWMDT_04075] RunnableEntity in BSW for RTE access dIn this case,
a BswModuleEntity should be specified in addition to allow for the BSW specific
descriptions and the two elements have to be associated. This is e.g. required, if the
RTE needs to find out whether a RunnableEntity runs in interrupt context.c()

108 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
Implementation
      
   

+swcBswMapping 0..1

ARElement InternalBehavior +internalBehavior SwComponentType

AtpStructureElement +swcBehavior
SwcInternalBehavior AtomicSwComponentType
SwcBswMapping 0..1 0..1 «atpVariation,atpSplitable»

InternalBehavior ARElement
+bswBehavior BswInternalBehavior +internalBehavior AtpBlueprint
AtpBlueprintable
0..1 0..* «atpSplitable» AtpStructureElement
BswModuleDescription

«atpVariation,atpSplitable»

      
   


     
!    
 


«atpVariation,atpSplitable»

«atpVariation,atpSplitable»
+runnable 0..* +entity 0..*

AtpStructureElement ExecutableEntity
ExecutableEntity BswModuleEntity
RunnableEntity
PortInterface

+swcRunnable 0..1 +bswEntity 0..1 «atpVariation,atpSplitable» ModeSwitchInterface

+accessedModeGroup

+providedModeGroup

SwcBswRunnableMapping
0..* 0..*
AtpPrototype
ModeDeclarationGroupPrototype +modeGroup
0..* +runnableMapping 0..1

«atpVariation,atpSplitable»
+swcModeGroup +bswModeGroup 0..1
0..1

       «instanceRef»

     «atpVariation,atpSplitable»
!     

+synchronizedModeGroup SwcBswSynchronizedModeGroupPrototype
PortInterface
«atpVariation,atpSplitable» 0..* TriggerInterface

      
   

!    


0..* +releasedTrigger +trigger 0..*

+swcTrigger AtpStructureElement
SwcBswSynchronizedTrigger Identifiable
«instanceRef» 0..1
«atpVariation,atpSplitable» 0..*
Trigger
+synchronizedTrigger +bswTrigger

0..1

Figure 5.17: Mapping between an SWC and a BSW module.

109 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class SwcBswMapping
Package M2::AUTOSARTemplates::CommonStructure::SwcBswMapping
Note Maps an SwcInternalBehavior to an BswInternalBehavior. This is required to coordinate the API
generation and the scheduling for AUTOSAR Service Components, ECU Abstraction Components and
Complex Driver Components by the RTE and the BSW scheduling mechanisms.
Tags: atp.recommendedPackage=SwcBswMappings
Base ARElement, ARObject, AtpClassifier , AtpFeature, AtpStructureElement, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Aggregated by ARPackage.element, AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
bswBehavior BswInternalBehavior 0..1 ref The mapped BswInternalBehavior
runnable SwcBswRunnable * aggr A mapping between a pair of SWC and BSW runnables.
Mapping Mapping
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=runnableMapping, runnable
Mapping.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
swcBehavior SwcInternalBehavior 0..1 ref The mapped SwcInternalBehavior.
synchronized SwcBswSynchronized * aggr A pair of SWC and BSW mode group prototypes to be
ModeGroup ModeGroupPrototype synchronized by the scheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=synchronizedModeGroup, synchronized
ModeGroup.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
synchronized SwcBswSynchronized * aggr A pair of SWC and BSW Triggers to be synchronized by
Trigger Trigger the scheduler.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=synchronizedTrigger, synchronized
Trigger.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 5.46: SwcBswMapping

Class SwcBswRunnableMapping
Package M2::AUTOSARTemplates::CommonStructure::SwcBswMapping
Note Maps a BswModuleEntity to a RunnableEntity if it is implemented as part of a BSW module (in the case of
an AUTOSAR Service, a Complex Driver or an ECU Abstraction). The mapping can be used by a tool to
find relevant information on the behavior, e.g. whether the bswEntity shall be running in interrupt context.
Base ARObject
Aggregated by SwcBswMapping.runnableMapping
Attribute Type Mult. Kind Note
bswEntity BswModuleEntity 0..1 ref The mapped BswModuleEntity
swcRunnable RunnableEntity 0..1 ref The mapped SWC runnable.

Table 5.47: SwcBswRunnableMapping

[constr_10298] Existence of the reference in the role SwcBswRunnableMapping.

bswEntity dFor each SwcBswRunnableMapping, the reference in the role bswEn-
tity shall exist at the time when the configuration of the BSW mod-
ule is finished.c()

110 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10299] Existence of the reference in the role SwcBswRunnableMap-

ping.swcRunnable dFor each SwcBswRunnableMapping, the reference in the
role swcRunnable shall exist at the time when the configuration of the
BSW module is finished.c()
Class SwcBswSynchronizedModeGroupPrototype
Package M2::AUTOSARTemplates::CommonStructure::SwcBswMapping
Note Synchronizes a mode group provided by a component via a port with a mode group provided by a BSW
module or cluster.
Base ARObject
Aggregated by SwcBswMapping.synchronizedModeGroup
Attribute Type Mult. Kind Note
bswModeGroup ModeDeclarationGroup 0..1 ref The BSW mode group prototype.
Prototype
swcModeGroup ModeDeclarationGroup 0..1 iref The SWC mode group prototype provided by a particular
Prototype port.
InstanceRef implemented by: PModeGroupInAtomic
SwcInstanceRef

Table 5.48: SwcBswSynchronizedModeGroupPrototype

[constr_10336] Existence of the reference in the role SwcBswSynchronized-

ModeGroupPrototype.bswModeGroup dFor each SwcBswSynchronizedMode-
GroupPrototype, the reference in the role bswModeGroup shall exist at the time
when the configuration of the BSW module is finished.c()
[constr_10337] Existence of the instanceRef in the role SwcBswSynchronized-
ModeGroupPrototype.swcModeGroup dFor each SwcBswSynchronizedMode-
GroupPrototype, the instanceRef in the role swcModeGroup shall exist at the
time when the configuration of the BSW module is finished.c()
Class SwcBswSynchronizedTrigger
Package M2::AUTOSARTemplates::CommonStructure::SwcBswMapping
Note Synchronizes a Trigger provided by a component via a port with a Trigger provided by a BSW module or
cluster.
Base ARObject
Aggregated by SwcBswMapping.synchronizedTrigger
Attribute Type Mult. Kind Note
bswTrigger Trigger 0..1 ref The BSW Trigger.
swcTrigger Trigger 0..1 iref The SWC Trigger provided by a particular port.
InstanceRef implemented by: PTriggerInAtomicSwc
TypeInstanceRef

Table 5.49: SwcBswSynchronizedTrigger

[constr_10300] Existence of the reference in the role SwcBswSynchro-

nizedTrigger.bswTrigger dFor each SwcBswSynchronizedTrigger, the ref-
erence in the role bswTrigger shall exist at the time when the configura-
tion of the BSW module is finished.c()

111 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10301] Existence of the instanceRef in the role SwcBswSynchro-

nizedTrigger.swcTrigger dFor each SwcBswSynchronizedTrigger, the in-
stanceRef in the role swcTrigger shall exist at the time when the config-
uration of the BSW module is finished.c()
[TPS_BSWMDT_04028] Determination of argument names for BSW functions
called via ports dIn the case of functions calls via ports over the RTE, the RTE API
generator shall determine the name of function arguments (for declaration purposes
only) from the signature of the BswModuleEntry referred via the mapping.
The rule is:
The name of the function arguments shall be taken (in the given order) from
- the shortNames of the
- SwServiceArgs (according to the given order) defined in the
- BswModuleEntry referenced by the
- BswModuleEntity mapped in the
- SwcBswRunnableMapping to the
- RunnableEntity referenced by the
- OperationInvokedEvent that in turn references the
- ClientServerOperation that belongs to the
- ClientServerInterface that types the
- PortPrototype in question.
This rule applies to PortDefinedArgumentValue and “ordinary” port operation ar-
guments as well.
If a SwcBswRunnableMapping exists, the above rule supersedes the definition
of any argument identifiers by the attribute(s) RunnableEntity.argument.c(RS_-
BSWMD_00039)
The meta-model elements involved in this rule are shown in the following diagram.

112 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

SwcBswRunnableMapping

+swcRunnable 0..1 +bswEntity 0..1

ClientServerInterface RunnableEntity BswModuleEntity

+startOnEvent 0..1

PortInterface
RTEEvent

+providedInterface 0..1
{redefines atpType}

«isOfType»
«atpVariation,atpSplitable»
OperationInvokedEvent

PPortPrototype

«instanceRef»

+operation 0..* +operation 0..1 +implementedEntry 0..1

AbstractProvidedPortPrototype ClientServerOperation BswModuleEntry

«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
+argument 0..* {ordered} +argument 0..* {ordered}

PortPrototype ArgumentDataPrototype SwServiceArg

+port 0..1

  

  

PortAPIOption

+portArgValue 0..* {ordered}

PortDefinedArgumentValue

Figure 5.18: Mapping of function arguments between an SWC and a BSW module.

All mappings for one component/module are aggregated in SwcBswMapping which

belongs to the CommonStructure of the meta-model. The mapping is considered as
an add-on to the internal behavior (because it is mainly required to set up the RTE) but
can be specified as a separate artifact which can be referred by the Implementation
of the module. Therefore SwcBswMapping is derived from ARElement.
[TPS_BSWMDT_04138] Determination of the BswModuleEntry sym-
bol dThe symbol of the BswModuleEntry is composed as following:
<bsnp>[_<vi>_<ai>]_<name> where:
<bsnp> the BswModuleDescription shortName if no BswSchedulerNamePre-
fix is defined or the value of the symbol attribute of the BswSchedulerNamePrefix
of the BswModuleEntity if a BswSchedulerNamePrefix is defined,
<vi> is the vendorId of the BSW module,
<ai> is the vendorApiInfix of the BSW module,
<name> is the substring after "<bsnp>_" of the BswModuleEntry shortName re-
ferred as implementedEntry.

113 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

However if <bsnp>_ is not the prefix of the related BswModuleEntry shortName

then <name> is identical to BswModuleEntry.shortName.
Please note also the SWS_RTE for further details.c()
This synchronization mechanism between software components and BSW modules is
limited to the relevant parts of the basic software:
[constr_4039] Semantics of SwcBswMapping dAn SwcBswMapping is only valid,
if the referred SwcInternalBehavior is aggregated by a ServiceSwComponent-
Type, EcuAbstractionSwComponentType or ComplexDeviceDriverSwCompo-
nentType.c()
[constr_4084] Consistency of references of InternalBehavior dThe SwcIn-
ternalBehavior referenced by SwcBswMapping.swcBehavior in the SwcB-
swMapping determined by SwcImplementation.swcBswMapping shall be identical
to the SwcInternalBehavior referenced by SwcImplementation.behavior.c()
[constr_4085] Consistency of references of InternalBehavior dThe BswIn-
ternalBehavior referenced by SwcBswMapping.bswBehavior in the SwcB-
swMapping determined by BswImplementation.swcBswMapping shall be identical
to the BswInternalBehavior referenced by BswImplementation.behavior.c()
Further constraints are:
[constr_4071] Synchronized runnables and schedulable entities shall be consis-
tent dIn the case that a RunnableEntity is mapped to a BswCalledEntity or
BswSchedulableEntity the RTE Generator emits an Entry Point Prototype only for
the BswCalledEntity or the BswSchedulableEntity (depending on the speci-
fied events for SWC resp. BSW). The SwcBswRunnableMapping instance control-
ling this case is only valid if several attributes of the mapped RunnableEntity and
BswSchedulableEntity are consistent, especially all of the following constraints
apply to the attributes of the given instance of SwcBswRunnableMapping:
• swcRunnable.symbol shall be identical to the symbol of bswEntity as defined
in [TPS_BSWMDT_04138].
• swcRunnable.minimumStartInterval shall be identical to bswEntity.
minimumStartInterval.
• swcRunnable.canBeInvokedConcurrently shall be identical to bswEn-
tity.implementedEntry.isReentrant.
• swcRunnable.swAddrMethod shall either be empty or shall have identical at-
tributes as the SwAddrMethod defined via bswEntity.swAddrMethod. This is
required to ensure a unique configuration for the memory segment of the under-
lying code entity.
• swcRunnable.activationReason and bswEntity.activationReason
shall have identical shortName if they define the same bitPosition and shall
have identical bitPosition if they define the same shortName

114 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Please note also the SWS_RTE for further details.c()

[constr_4040] Synchronized mode groups shall have same type dSwcBswSyn-
chronizedModeGroupPrototype can only refer to equally typed ModeDeclara-
tionGroupPrototypes, i.e. which have identical ModeDeclarationGroups.c()
[constr_4041] Synchronized mode groups shall have same context dThe mapping
defined by SwcBswSynchronizedModeGroupPrototype implies that the compo-
nent providing the one mode group prototype is also mapped to the module which
provides the other mode group prototype by means of synchronizing their respective
behaviors in SwcBswMapping.c()
[constr_4042] Synchronized triggers shall have same context dThe mapping de-
fined by SwcBswSynchronizedTrigger implies that the component providing the
one trigger is also mapped to the module which provides the other trigger by means of
synchronizing their respective behaviors in SwcBswMapping.c()
[constr_4064] Synchronized triggers shall implement same policy dThe mapping
defined by SwcBswSynchronizedTrigger is only valid if the attribute SwcBswSyn-
chronizedTrigger.swcTrigger.swImplPolicy has the same value as the at-
tribute SwcBswSynchronizedTrigger.bswTrigger.swImplPolicy.c()
The next constraint is to avoid conflicts in generated header files for the same reason
as constraint [constr_4059] does within one module (see 4.2):
[constr_4058] Different mode groups in mapped BSWM and SWC shall have dif-
ferent names dIf an SwcInternalBehavior is mapped to a BswInternalBehav-
ior the corresponding SWC and BSW module descriptions may not refer to different
ModeDeclarationGroups having the same shortName but different elements. This
holds especially if these mode groups are not synchronized but used independently.c()

5.12 BSW Behavior Distributed over Partitions

There a valid use cases in which parts of a given BSW module are ex-
ecuted on different partitions related to different processor cores within one
ECU (see [RS_BSWMD_00068] and [13]). This includes the case, that on a given
ECU different services of the same module run within different partitions and also the
case, that on the same ECU the same service is available within different partitions.
In a BSWMD there is no strict information on the association of software entities to
partitions or processor cores. This information is added later in the ECU configuration
phase through the mapping of BswEvents to OS tasks which in turn are mapped to
OsApplications which are assigned to a partition and/or processor core (see [15]).
The BswModuleEntity-s that are driven by these BswEvents are then indirectly
mapped to partitions and cores.
Note that under certain circumstances (e.g. no memory protection, reentrancy) it is
possible to use BswModuleEntity-s and BswOperationInvokedEvents that are

115 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

not mapped to tasks but still can be accessed from several partitions (see [13] for
details).
Likewise, the information whether a service is potentially called across partition bound-
aries is added via ECU configuration of the BSW Scheduler (in case of BSW communi-
cation) or via port connectors created at ECU configuration time (in case of AUTOSAR
Services).
Nonetheless the BswInternalBehavior shall be prepared for such a configuration
because pieces of a module’s code that potentially will run in different partitions and
shall be explicitly mapped to different tasks have to be driven by separate BswEvents.
In addition, it is useful to distinguish the communication behavior of a BswModuleEn-
tity per partition, for example if it sends out data when running on one processor core
and receives them when running on another core. Such information may be needed
for the fine grained configuration of the RTE and IOC as well as for documentation,
timing and call tree analysis.5
In particular, the following rules can be stated:

[TPS_BSWMDT_04108] BswInternalBehavior containing BswModuleEntity-

s executed on different partitions dIf a module is designed to let the same code
entities (after proper ECU configuration) run in different partitions, each code entity
shall be described by only one BswModuleEntity. In other words, for a given code
there shall be no separate BswModuleEntity-s per partition.
Furthermore, in case the behavior per partition shall be distinguished, the following
elements shall be provided in the module’s BswInternalBehavior:
• Each potential partition context in which some of the contained BswModuleEn-
tity-s are able to run shall be modeled by an aggregation of an instance of
meta-class BswDistinguishedPartition, see figure below. Note that this is
an abstract notation and the concrete partition shall be defined later in the pro-
cess as part of the configuration of the “virtual” module EcuC, see [16].
• The BswEvents starting the BswModuleEntitys of this BswInternalBehav-
ior shall be separate per potential partition and - in case there are limitations -
shall indicate by the reference BswEvent.contextLimitation to which parti-
tion they are allowed to be mapped.
• The BswModuleCallPoints of this BswInternalBehavior shall - in case
there are limitations - indicate by the reference BswModuleCallPoint.con-
textLimitation in which partitions they are used.
• The BswVariableAccess elements of this BswInternalBehavior shall -
in case there are limitations - indicate by the reference BswVariableAccess.
contextLimitation in which partitions they are accessed.

5
The code has the possibility to retrieve information on which processor core it is running - see [13]
and/or by which event it was started, see 5.8.

116 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Note that no BswOperationInvokedEvent and no BswModuleClientServerEn-

try are needed for a function that is provided only for callers within one partition.
Furthermore, this rule is not applicable for BswCalledEntity-s that shall always run
in the task context of the caller.c(RS_BSWMD_00068)

InternalBehavior
BswInternalBehavior

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

+entity 0..* +event 0..* +distinguishedPartition 0..*

ExecutableEntity AbstractEvent Referrable

BswModuleEntity +startsOnEvent BswEvent BswDistinguishedPartition
+contextLimitation
0..1
0..*

Referrable
+callPoint +contextLimitation
BswModuleCallPoint
«atpVariation,atpSplitable» 0..* 0..*

+dataReceivePoint Referrable
BswVariableAccess
«atpVariation,atpSplitable»
0..* +contextLimitation

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

Figure 5.19: Usage of BswDistinguishedPartition.

[TPS_BSWMDT_04109] BswInternalBehavior for the same AUTOSAR Service

provided on different partitions dIf a module is designed to implement an AUTOSAR
Service - represented as a particular ServiceSwComponentType - which shall run
(after proper ECU configuration) by the same code on several different BSW parti-
tions in explicitly mapped tasks, then it is enough to define for each RunnableEntity
one SwcBswRunnableMapping and one mapped BswModuleEntity. However, the
necessary RTEEvents shall be different for each potential partition.
This rule does not apply for those RTEEvents and their corresponding RunnableEn-
tity-s and BswModuleEntity-s which shall not be mapped to tasks.
Rule [TPS_BSWMDT_04108] applies in addition, if the behavior of the involved
BswModuleEntity-s shall be distinguished per partition.c(RS_BSWMD_00068)

117 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class BswDistinguishedPartition
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Each instance of this meta-class represents an abstract partition in which context the code of the
enclosing BswModuleBehavior can be executed.
The intended use case is to distinguish between several partitions in order to implement different
behavior per partition, for example to behave either as a master or satellite in a multicore ECU with
shared BSW code.
Base ARObject, Referrable
Aggregated by BswInternalBehavior.distinguishedPartition
Attribute Type Mult. Kind Note
– – – – –
Table 5.50: BswDistinguishedPartition

[constr_4083] BswDistinguishedPartition shall be used only in the context

of a particular BswInternalBehavior dAll instances of BswEvent, BswModule-
CallPoint and BswVariableAccess which refer to a BswDistinguishedPar-
tition shall belong to the same BswInternalBehavior that also aggregates the
referred BswDistinguishedPartition.c()

118 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

6 BSW Implementation

6.1 Overview
The template elements to be used by the developer in order to document the actual
implementation of a BSW module or cluster are very similar to what is needed for the
same purpose in the case of SWCs. Therefore it is based on the CommonStructure
part or the meta-model. This includes also the documentation of resource consump-
tion. The generic classes of the meta-model used to document implementation and
resource consumption are described in chapter 7 and chapter 8 in this document.
There are however some special features in describing the implementation of BSW.
This is the purpose of the meta-class BswImplementation (see Figure 6.1 and the
following class table).
ARElement
Implementation::Implementation
ARElement
+ programmingLanguage: +hwElement HwDescriptionEntity
ProgramminglanguageEnum [0..1]
EcuResourceTemplate::HwElement
+ swVersion: RevisionLabelString [0..1] *
+ usedCodeGenerator: String [0..1]
+ vendorId: PositiveInteger [0..1]

InternalBehavior
BswImplementation
+behavior BswBehavior::BswInternalBehavior
+ arReleaseVersion: RevisionLabelString [0..1]
+ vendorApiInfix: Identifier [0..1] 0..1

«atpUriDef»
+refinedModuleDef 0..1

ARElement
AtpBlueprint
+vendorSpecificModuleDef AtpBlueprintable
EcucDefinitionElement
0..*
ECUCParameterDefTemplate::EcucModuleDef

+definition 0..1

+moduleDescription ARElement

0..1 ECUCDescriptionTemplate::
EcucModuleConfigurationValues
+preconfiguredConfiguration + ecucDefEdition: RevisionLabelString [0..1]
0..* + implementationConfigVariant:
EcucConfigurationVariantEnum [0..1]
+ postBuildVariantUsed: Boolean [0..1]
+recommendedConfiguration

0..*

Figure 6.1: Overview of class BswImplementation

119 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class BswImplementation
Package M2::AUTOSARTemplates::BswModuleTemplate::BswImplementation
Note Contains the implementation specific information in addition to the generic specification (BswModule
Description and BswBehavior). It is possible to have several different BswImplementations referring to
the same BswBehavior.
Tags: atp.recommendedPackage=BswImplementations
Base ARElement, ARObject, CollectableElement, Identifiable, Implementation, MultilanguageReferrable,
PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
arRelease RevisionLabelString 0..1 attr Version of the AUTOSAR Release on which this
Version implementation is based. The numbering contains three
levels (major, minor, revision) which are defined by
AUTOSAR.
behavior BswInternalBehavior 0..1 ref The behavior of this implementation.
This relation is made as an association because
• it follows the pattern of the SWCT
• since ARElement cannot be splitted, but we want
supply the implementation later, the Bsw
Implementation is not aggregated in BswBehavior
preconfigured EcucModule * ref Reference to the set of preconfigured (i.e. fixed)
Configuration ConfigurationValues configuration values for this BswImplementation.
If the BswImplementation represents a cluster of several
modules, more than one EcucModuleConfigurationValues
element can be referred (at most one per module),
otherwise at most one such element can be referred.
Tags: xml.roleWrapperElement=true
recommended EcucModule * ref Reference to one or more sets of recommended
Configuration ConfigurationValues configuration values for this module or module cluster.
vendorApiInfix Identifier 0..1 attr In driver modules which can be instantiated several times
on a single ECU, SRS_BSW_00347 requires that the
names of files, APIs, published parameters and memory
allocation keywords are extended by the vendorId and a
vendor specific name. This parameter is used to specify
the vendor specific name. In total, the implementation
specific API name is generated as follows: <Module
Name>_<vendorId>_ <vendorApiInfix>_<API name from
SWS>.
E.g. assuming that the vendorId of the implementer is
123 and the implementer chose a vendorApiInfix of
"v11r456" an API name Can_Write defined in the SWS
will translate to Can_123_v11r456_Write.
This attribute is mandatory for all modules with upper
multiplicity > 1. It shall not be used for modules with
upper multiplicity =1.
See also SWS_BSW_00102.
vendorSpecific EcucModuleDef * ref Reference to
ModuleDef
• the vendor specific EcucModuleDef used in this Bsw
Implementation if it represents a single module
• several EcucModuleDefs used in this Bsw
Implementation if it represents a cluster of modules
• one or no EcucModuleDefs used in this Bsw
Implementation if it represents a library
Tags: xml.roleWrapperElement=true

Table 6.1: BswImplementation

120 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10302] Existence of attribute BswImplementation.arReleaseV-

ersion dFor each BswImplementation, the attribute arReleaseVersion
shall exist at the time when the configuration of the BSW module is
finished.c()
[constr_10303] Existence of the reference in the role BswImplementation.
behavior dFor each BswImplementation, the reference in the role behavior
shall exist at the time when the configuration of the BSW module is
finished.c()
[TPS_BSWMDT_04030] BswImplementation.arReleaseVersion dThe inclusion
of the AUTOSAR version information arReleaseVersion is specific for AUTOSAR
BSW and specified per instance of BswImplementation.c(RS_BSWMD_00001,
RS_BSWMD_00025, RS_BSWMD_00043)
[TPS_BSWMDT_04031] Instances of BswImplementation dNote that in case a
BSW module can potentially be used in multiple implementations on the same ECU
(which means, that the code has to be there multiple times with the exception of shared
libraries), for each module implementation there has to be a separate instance of
BswImplementation. This allows to define name expansions required for global
symbols via the attribute vendorApiInfix.c(RS_BSWMD_00001, RS_BSWMD_-
00025, RS_BSWMD_00043)
[constr_4099] Support of multiple instantiation dIf a BSW Module supports multiple
instantiation the attribute vendorApiInfix is mandatory.c()
Note: If a standardized BSW Module shall support multiple instantiation is defined by
AUTOSAR and described in the according STMD. For more information see [16]. It is
the responsibility of a BSW Module vendor to apply unique vendorApiInfix values
for its delivered modules.
[constr_4100] Uniqueness of module implementation prefixes dInside one ECU
the Module implementation prefixes (Mip) of BSW Modules shall be unique.c()
Note: The definition of Mip is given in [SWS_BSW_00102]
The mechanism of vendorApiInfixes can be seen as a special method of resolving
name conflicts. This aspect is further explained in [4] [TR_METH_03010].
The notation “Wayx” in Figure 6.2 and Figure 6.3 describes that a different HW mecha-
nism (e.g. register set) can be used to achieve the same functionality (e.g. calculation
of a PWM output).
Use-case for vendorApiInfixes would be that the microcontroller on chip and an
off chip device provide the same functionality like e.g. CanDriver capabilities. Here the
abstraction shall be done via the vendorApiInfixes.

121 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Figure 6.2: Example of a use case for vendorApiInfix

Non use-case for vendorApiInfixes would be that the microcontroller provides on chip
for the calculation of a PWM different mechanisms for different channels. Here the
abstraction shall be done via the handled ChannelNumber of the PWM.

Figure 6.3: Example of a none use case for vendorApiInfix

[TPS_BSWMDT_04032] Implementation.hwElement dThe attribute hwElement

allows to document special hardware dependencies of a BSW module or cluster in
addition to what can be expressed by the generic attribute Implementation.re-
sourceConsumptionc(RS_BSWMD_00009, RS_BSWMD_00026) (see also chap-
ter 8). The intended use case of this attribute is to document hardware dependencies
of BSW modules or clusters namely in the layers MCAL, ECU Abstraction or Complex
Drivers.
Finally it is possible to specify vendor specific configuration parameter definitions and
predefined or recommended configuration parameter values within the scope of a BSW
implementation and deliver them as part of a BSWMD. This is further explained in the
next chapter.

6.2 Configuration Parameter Definitions and Values as Part of a

BSWMD
[TPS_BSWMDT_04033] Reference to vendor specific configuration parameters
dVendor specific configuration parameters are expressed by an association from
BswImplementation to EcucModuleDef.c(RS_BSWMD_00007, RS_BSWMD_-
00027, RS_BSWMD_00035, RS_BSWMD_00050)
[TPS_BSWMDT_04034] Reference to predefined or recommended configuration
values dPredefined or recommended configuration parameter values are expressed by

122 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

associations from BswImplementation to EcucModuleConfigurationValues.c

(RS_BSWMD_00007, RS_BSWMD_00032, RS_BSWMD_00033)
The meta-classes EcucModuleDef and EcucModuleConfigurationValues are
specified in the ECU Configuration Specification document [16].
Note that different implementations of the same BswModuleDescription can have
different predefined or recommended parameter values and different sets of vendor
specific configuration parameters. Of course it is also possible that different implemen-
tations of the same module refer to the same configuration parameter definitions resp.
to the same predefined or recommended configuration parameter values.
A BswImplementation can either represent the implementation of a single module
(or library) or the implementation of a cluster of modules. Therefore the following con-
straints hold for the multiplicities of the vendor specific configuration parameters and
predefined configuration values:
[constr_4047] Multiplicity of vendor specific configuration parameters dThe asso-
ciation BswImplementation.vendorSpecificModuleDef shall be implemented
as reference to one or more instances of EcucModuleDef if the underlying BswMod-
uleDescription has the category BSW_CLUSTER. In all other cases, it shall
refer to exactly one instance of EcucModuleDef (the one belonging to this module).c
()
[constr_4048] Multiplicity of preconfigured values dThe association BswImple-
mentation.preconfiguredConfiguration shall be implemented as reference to
zero or more different instances of EcucModuleConfigurationValues if the un-
derlying BswModuleDescription has the category BSW_CLUSTER. In all other
cases, it shall refer to at most one instance of EcucModuleConfigurationValues
(the one belonging to this module).c()
In order to specify the roles of predefined or recommended parameter values and dis-
tinguish them from the parameter value sets used finally in the ECU configuration,
the following constraints hold for the enumeration attribute EcucModuleConfigura-
tionValues.implementationConfigVariant (see [16] for definition and further
usage of this attribute in the ECU configuration):
[constr_4045] implementationConfigVariant of preconfigured configuration
dAn EcucModuleConfigurationValues element with the implementationCon-
figVariant set to the value PreconfiguredConfiguration shall only be refer-
enced in the role preconfiguredConfiguration and no other value for imple-
mentationConfigVariant is allowed in this role.c()
[constr_4046] implementationConfigVariant of recommended configuration
dAn EcucModuleConfigurationValues element with the implementationCon-
figVariant set to the value RecommendedConfiguration shall only be refer-
enced in the role recommendedConfiguration and no other value for implemen-
tationConfigVariant is allowed in this role.c()

123 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04035] Published parameter values dSome AUTOSAR modules

define so-called published parameters. A value of a published parameter cannot be
set by the integrator, but has to be known. Thus the existence of published parameters
always requires that their values have to be given as part of the preconfiguredCon-
figuration.c(RS_BSWMD_00024, RS_BSWMD_00033, RS_BSWMD_00043)
[TPS_BSWMDT_04036] Back-reference from EcucModuleConfigurationVal-
ues dIn addition the EcucModuleConfigurationValues from the ECU Configura-
tion Template can refer to the BswImplementation for which it defines the config-
uration parameters. This relation is intended to be used by the integrator or tester to
indicate for which BswImplementation an actual ECU configuration has been set
up.c(RS_BSWMD_00001)

124 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

7 Implementation

7.1 Introduction
This chapter explains, how the implementation details of AUTOSAR Software Compo-
nents and Basic Software can be described. While AUTOSAR contains various com-
ponent types, only Atomic Software Components and Basic Software Modules
possess an Implementation. In the meta model this means that Implementation
can be provided for AtomicSwComponentType or its derived classes and BswMod-
uleDescription only.
On the other hand, compositions simply structure and encapsulate their contained
components in a hierarchical manner, without adding any implementation relevant be-
havior or functionality. So they cannot be implemented directly. Instead, the leaf com-
ponents in such a composition tree which by definition are again atomic, are imple-
mented.

7.2 Implementation Description Overview

The Implementation class shown in Figure 7.1 serves the following main purposes:
• provide information about the resource consumption (chapter 8)
• link to code (source code, object code) (chapter 7.5)
• specify required and generated artifacts (chapter 7.6)
• specify the compiler (chapter 7.7)
• specify the linker (chapter 7.8)
• specify data to support measurement and calibration tools (chapter 9)

125 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Identifiable +codeDescriptor ARElement +resourceConsumption Identifiable

Code Implementation «atpSplitable» ResourceConsumption
0..* 0..1
+ programmingLanguage:
ProgramminglanguageEnum [0..1] «enumeration»
McSupportData +mcSupport + swVersion: RevisionLabelString [0..1] ProgramminglanguageEnum
+ usedCodeGenerator: String [0..1]
  
0..1«atpSplitable»
+ vendorId: PositiveInteger [0..1] c    
cpp  
java     
ARElement +swcBswMapping
AtpStructureElement
0..1
SwcBswMapping +requiredArtifact Identifiable

ARElement +hwElement «atpVariation,atpSplitable» 0..* DependencyOnArtifact

HwDescriptionEntity +generatedArtifact
*
HwElement «atpVariation,atpSplitable» 0..*
+requiredGeneratorTool
Identifiable
Linker «atpVariation,atpSplitable» 0..*
+linker
+ name: String [0..1] Identifiable
+ options: String [0..1] 0..* +compiler Compiler
+ vendor: String [0..1]
+ version: String [0..1] 0..* + name: String [0..1]
+ options: String [0..1]

   + vendor: String [0..1]
    + version: String [0..1]
  
     ARElement
AtpBlueprint
AtpBlueprintable
+buildActionManifest
BuildActionManifest
«atpVariation,atpSplitable» 0..1

Figure 7.1: Overview of implementation description

As the figure shows, Implementation is derived from ARElement, i.e. it may be

shipped as a separate engineering artifact, e.g. independent of the description of
interfaces, ports and the component type.
The following table lists all attributes shown in Figure 7.1, thereby explaining the mean-
ing of the remaining simple assertions and requirements of class Implementation.
Class Implementation (abstract)
Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note Description of an implementation a single software component or module.
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses BswImplementation, SwcImplementation
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
buildAction BuildActionManifest 0..1 ref A manifest specifying the intended build actions for the
Manifest software delivered with this implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=buildActionManifest.buildActionManifest,
buildActionManifest.variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime
codeDescriptor Code * aggr Specifies the provided implementation code.
compiler Compiler * aggr Specifies the compiler for which this implementation has
been released
5

126 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class Implementation (abstract)
generated DependencyOnArtifact * aggr Relates to an artifact that will be generated during the
Artifact integration of this Implementation by an associated
generator tool. Note that this is an optional information
since it might not always be in the scope of a single
module or component to provide this information.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=generatedArtifact.shortName, generated
Artifact.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
hwElement HwElement * ref The hardware elements (e.g. the processor) required for
this implementation.
linker Linker * aggr Specifies the linker for which this implementation has
been released.
mcSupport McSupportData 0..1 aggr The measurement & calibration support data belonging to
this implementation. The aggregtion is <<atpSplitable>>
because in case of an already exisiting BSW
Implementation model, this description will be added later
in the process, namely at code generation time.
Stereotypes: atpSplitable
Tags: atp.Splitkey=mcSupport
programming Programminglanguage 0..1 attr Programming language the implementation was created
Language Enum in.
requiredArtifact DependencyOnArtifact * aggr Specifies that this Implementation depends on the
existance of another artifact (e.g. a library). This
aggregation of DependencyOnArtifact is subject to
variability with the purpose to support variability in the
implementations. Different algorithms in the
implementation might cause different dependencies, e.g.
the number of used libraries.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=requiredArtifact.shortName, required
Artifact.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
required DependencyOnArtifact * aggr Relates this Implementation to a generator tool in order to
GeneratorTool generate additional artifacts during integration.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=requiredGeneratorTool.shortName, required
GeneratorTool.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
resource ResourceConsumption 0..1 aggr All static and dynamic resources for each implementation
Consumption are described within the ResourceConsumption class.
Stereotypes: atpSplitable
Tags: atp.Splitkey=resourceConsumption.shortName
swcBsw SwcBswMapping 0..1 ref This allows a mapping between an SWC and a BSW
Mapping behavior to be attached to an implementation description
(for AUTOSAR Service, ECU Abstraction and Complex
Driver Components). It is up to the methodology to define
whether this reference has to be set for the Swc- or Bsw
Implementtion or for both.
swVersion RevisionLabelString 0..1 attr Software version of this implementation. The numbering
contains three levels (like major, minor, patch), its values
are vendor specific.
usedCode String 0..1 attr Optional: code generator used.
Generator
5

127 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class Implementation (abstract)
vendorId PositiveInteger 0..1 attr Vendor ID of this Implementation according to the
AUTOSAR vendor list

Table 7.1: Implementation

7.3 Assertions and Requirements

For some of the attributes mentioned below it is ambiguous whether they describe a
requirement on the target environment or whether they are assertions made by the par-
ticular component implementation. The Implementation description’s compiler
attribute is an example for this: does it describe a requirement for source code to be
compiled with the named compiler, or is this simply information which compiler was
used in the process of creating an object file? The simple answer is: if possible, this
is derived from the context. Otherwise the attribute needs to have proper documenta-
tion. For the compiler example just mentioned, the situation is straightforward: for
source code, the attribute describes a requirement, for object code it is documented
information. The same needs to be applied to all attributes in this section.

7.4 Implementation of a Software Component

[TPS_BSWMDT_04039] Association of an Implementation with a component
or module dProbably the most important information in Implementation is which
Atomic Software Component or BSW Module is actually implemented. Implemen-
tations are actually given for a particular component behavior, specified through the
class SwcInternalBehavior respectively BswInternalBehavior. The contents
of such a behavior are not of interest here, but it in turn is associated with a single
AtomicSwComponentType or BswModuleDescription.c(RS_BSWMD_00001)

128 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
Implementation

SwcImplementation BswImplementation

AtpStructureElement
InternalBehavior

+behavior 0..1 +behavior 0..1

SwcInternalBehavior BswInternalBehavior

   +internalBehavior 0..*

+internalBehavior 0..1
   
 
«atpVariation,atpSplitable»
«atpSplitable»

SwComponentType ARElement
AtomicSwComponentType AtpBlueprint
AtpBlueprintable
AtpStructureElement
BswModuleDescription

Figure 7.2: An implementation is associated with a single software component or mod-

ule

7.5 Linking to Code

When a component is released the descriptions are accompanied by actual implemen-
tation code. This code can come in different ways: Source code in C, C++ or Java,
object code or even executable code1 .
Figure 7.3 shows how an Implementation is linked to Code.
[TPS_BSWMDT_04040] Implementation.codeDescriptor dFor each available
form of component code a Code element is used. For each codeDescriptor, all rel-
evant artifacts are then referenced through the attribute artifactDescriptor (class
AutosarEngineeringObject) which in turn references to a catalog of available files
through a set of attributes as shown below. If for instance a component implementa-
tion is given as source code only, then the respective Implementation would contain
exactly one codeDescriptor, whose artifactDescriptor.category attribute
would denote the files to be source files.c(RS_BSWMD_00001, RS_BSWMD_00025)

1
Delivery of executable code is currently not supported by AUTOSAR.

129 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
Implementation

+codeDescriptor 0..*

Identifiable
Code

+artifactDescriptor 0..*

AutosarEngineeringObject

EngineeringObject

+ category: NameToken
+ domain: NameToken [0..1]
+ revisionLabel: RevisionLabelString [0..*]
+ shortLabel: NameToken

Figure 7.3: An Implementation references the code artifacts through the Code class

Class Code
Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note A generic code descriptor. The type of the code (source or object) is defined via the category attribute of
the associated engineering object.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by Implementation.codeDescriptor
Attribute Type Mult. Kind Note
artifact AutosarEngineering * aggr Refers to the artifact belonging to this code descriptor.
Descriptor Object
callbackHeader ServiceNeeds * ref The association callbackHeader describes in which
header files the function declarations of callback functions
are provided to a service module. With this information
the service module can include the appropriate header
files in its configuration files.

Table 7.2: Code

7.6 Dependencies
An implementation can generally depend on other artifacts, e.g. files. Such files could
for example be required header, configuration or library files.
[TPS_BSWMDT_04041] DependencyOnArtifact dThis is described by the
class DependencyOnArtifact which relates to meta-information via the class
AutosarEngineeringObject.c(RS_BSWMD_00034, RS_BSWMD_00037, RS_-
BSWMD_00044)
This is shown in Figure 7.4.

130 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Identifiable
EngineeringObject
DependencyOnArtifact
+ category: NameToken
+ usage: DependencyUsageEnum [0..*] + domain: NameToken [0..1]
+ revisionLabel: RevisionLabelString [0..*]
+ shortLabel: NameToken

+artifactDescriptor 0..1

AutosarEngineeringObject

«enumeration»
DependencyUsageEnum

codegeneration
compile
link
build
execute

Figure 7.4: Dependencies of an Implementation

[TPS_BSWMDT_04042] Usage of DependencyOnArtifact dThe class Depen-

dencyOnArtifact can be aggregated by Implementation in several different
roles. By this it can also be used to specify that a certain generator tool is required
to integrate a module and/or that a certain artifact is generated.
For libraries, like e.g. a math.lib, the desired version numbers can be specified via
the attribute revisionLabel, therefore trying to ensure compatibility. Note that the
specification of version numbers and other attributes is a meta-information about cer-
tain artifacts which shall refer to a concrete catalog description.c(RS_BSWMD_00034,
RS_BSWMD_00037, RS_BSWMD_00044)This mechanism is described in more detail
in the AUTOSAR Methodology, see [4].
Class DependencyOnArtifact
Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note Dependency on the existence of another artifact, e.g. a library.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by Implementation.generatedArtifact, Implementation.requiredArtifact, Implementation.requiredGenerator
Tool
Attribute Type Mult. Kind Note
artifact AutosarEngineering 0..1 aggr The specified artifact needs to exist.
Descriptor Object
usage DependencyUsage * attr Specification for which process step(s) this dependency is
Enum required.

Table 7.3: DependencyOnArtifact

[constr_10304] Existence of attribute DependencyOnArtifact.usage dFor each

DependencyOnArtifact, the attribute usage shall exist at least once at the
time when the configuration of the BSW module is finished.c()

131 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration DependencyUsageEnum
Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note Enumeration describing the process steps a dependency is valid in.
Aggregated by DependencyOnArtifact.usage
Literal Description
build The object referred by the dependency is required during the build process.
Tags: atp.EnumerationLiteralIndex=0
codegeneration The object referred by the dependency is required during code generation
Tags: atp.EnumerationLiteralIndex=1
compile The object referred by the dependency is required during compilation.
Tags: atp.EnumerationLiteralIndex=2
execute The object referred by the dependency is required at execution time.
Tags: atp.EnumerationLiteralIndex=3
link The object referred by the dependency is required during linking.
Tags: atp.EnumerationLiteralIndex=4

Table 7.4: DependencyUsageEnum

Class AutosarEngineeringObject
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::EngineeringObject
Note This denotes an engineering object being part of the process. It is a specialization of the abstract class
EngineeringObject for usage within AUTOSAR.
Base ARObject, EngineeringObject
Aggregated by AclObjectSet.engineeringObject, BuildActionEntity .deliveryArtifact, Code.artifactDescriptor, Dependency
OnArtifact.artifactDescriptor
Attribute Type Mult. Kind Note
– – – – –
Table 7.5: AutosarEngineeringObject

Class EngineeringObject (abstract)

Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::EngineeringObject
Note This class specifies an engineering object. Usually such an object is represented by a file artifact. The
properties of engineering object are such that the artifact can be found by querying an ASAM catalog file.
The engineering object is uniquely identified by domain+category+shortLabel+revisionLabel.
Base ARObject
Subclasses AutosarEngineeringObject, BuildEngineeringObject, Graphic
Attribute Type Mult. Kind Note
category NameToken 1 attr This denotes the role of the engineering object in the
development cycle. Categories are such as
• SWSRC for source code
• SWOBJ for object code
• SWHDR for a C-header file
Further roles need to be defined via Methodology.
Tags: xml.sequenceOffset=20
5

132 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class EngineeringObject (abstract)
domain NameToken 0..1 attr This denotes the domain in which the engineering object
is stored. This allows to indicate various segments in the
repository keeping the engineering objects. The domain
may segregate companies, as well as automotive
domains. Details need to be defined by the Methodology.
Attribute is optional to support a default domain.
Tags: xml.sequenceOffset=40
revisionLabel RevisionLabelString * attr This is a revision label denoting a particular version of the
engineering object.
Tags: xml.sequenceOffset=30
shortLabel NameToken 1 attr This is the short name of the engineering object. Note
that it is modeled as NameToken and not as Identifier
since in ASAM-CC it is also a NameToken.
Tags: xml.sequenceOffset=10

Table 7.6: EngineeringObject

7.7 Compiler
[TPS_BSWMDT_04043] Compiler dFor the specification of the used (or to be used)
compiler the Compiler element shall be used:c(RS_BSWMD_00010)
Class Compiler
Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note Specifies the compiler attributes. In case of source code this specifies requirements how the compiler
shall be invoked. In case of object code this documents the used compiler settings.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by Implementation.compiler
Attribute Type Mult. Kind Note
name String 0..1 attr Compiler name (like gcc).
options String 0..1 attr Specifies the compiler options.
vendor String 0..1 attr Vendor of compiler.
version String 0..1 attr Exact version of compiler executable.

Table 7.7: Compiler

7.8 Linker
[TPS_BSWMDT_04044] Linker dFor the specification of the to be used linker the
Linker element shall be used:c()

133 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class Linker
Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note Specifies the linker attributes used to describe how the linker shall be invoked.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by Implementation.linker
Attribute Type Mult. Kind Note
name String 0..1 attr Linker name.
options String 0..1 attr Specifies the linker options.
vendor String 0..1 attr Vendor of linker.
version String 0..1 attr Exact version of linker executable.

Table 7.8: Linker

7.9 Build Action Manifest

[TPS_BSWMDT_04085] Implementation refers to a BuildActionManifest dAn
Implementation can optionally be linked to a BuildActionManifest in order to
specify the intended build actions for the software delivered with this implementation.c
(RS_BSWMD_00001, RS_BSWMD_00025)
Class BuildActionManifest
Package M2::AUTOSARTemplates::GenericStructure::BuildActionManifest
Note This meta-class represents the ability to specify a manifest for processing artifacts. An example use case
is the processing of ECUC parameter values.
Tags:
atp.recommendedPackage=BuildActionManifests
xml.globalElement=false
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
buildAction BuildAction * aggr This represents a particular action in the build chain.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=buildAction.shortName, buildAction.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
buildAction BuildActionEnvironment * aggr This represents a build action environment.
Environment
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=buildActionEnvironment.shortName, build
ActionEnvironment.variationPoint.shortLabel
vh.latestBindingTime=blueprintDerivationTime
dynamicAction BuildAction * ref This denotes an Action which is to be executed as part of
the dynamic action set.
startAction BuildAction * ref This specifies the list of actions to be performed at the
beginning of the process.
Tags: xml.sequenceOffset=-90
5

134 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class BuildActionManifest
tearDownAction BuildAction * ref This specifies the set of action which shall be performed
after all other actions in the manifest were performed.
Tags: xml.sequenceOffset=-80

Table 7.9: BuildActionManifest

The setup of such a manifest is further explained in [1], see [TPS_GST_00294].

[TPS_BSWMDT_04086] Artifacts referred in Implementation and/or BuildAc-
tionManifest dIt should be noted that the Implementation instance as well as the
BuildActionManifest instance can aggregate descriptive elements derived from
meta-class EngineeringObject which eventually represent file artifacts to be used
by the integrator. These two sets of artifacts may differ but are not necessarily exclu-
sive, i.e. it shall be allowed to describe the same artifact under Implementation and
under BuildActionManifest as well (of course not in contradiction).
Especially, the element Implementation.codeDescriptor is mandatory, so this
element cannot be omitted even if an equivalent EngineeringObject describing
the code file is part of the BuildActionManifest.c(RS_BSWMD_00001, RS_-
BSWMD_00025)

135 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

8 ResourceConsumption
AUTOSAR software needs to be mapped on ECUs at some point during the develop-
ment. Application Software Components can be basically mapped to any ECU avail-
able within the car. The mapping freedom is limited by the System Constraints [7] and
the available resources on each ECU. BSW Modules are present in each ECU which
provides the corresponding service. The ResourceConsumption element provides
information about the needed resources concerning memory and execution time for
each SwcImplementation or BswImplementation.

8.1 Static and Dynamic Resources

Resources can be divided into static and dynamic resources.
Static resources can only be allocated by one entity and stay with this entity. If the
required amount of resources is bigger than the available resources the mapping does
not fit physically. ROM is an example of a spare resource where obviously only the
amount of data can be stored that is provided by the storage capacity.
Dynamic resources are shared and therefore can be allocated dynamically to different
control threads over time. Processing time is a good example, where different tasks are
given the processor for some time. If some runnable entity uses more processing time
than originally planned, it can lead to functional failure. Also some sections of RAM can
be seen as dynamic resources (e.g. stack, heap which grow and shrink dynamically).

8.2 Resource consumption overview

In Figure 8.1, the meta-model of the ResourceConsumption description is depicted.
[TPS_BSWMDT_04045] Implementation.resourceConsumption dThe Re-
sourceConsumption is attached to an Implementation. For each Implementa-
tion, there is one ResourceConsumption description.c(RS_BSWMD_00001, RS_-
BSWMD_00005)

136 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement
Implementation

«atpSplitable»
+resourceConsumption 0..1

Identifiable
ResourceConsumption

«atpVariation,atpSplitable»

  
Identifiable +stackUsage 0..*   
  
ExecutableEntity Identifiable   
+executableEntity   
StackUsage

0..1 A
«atpVariation,atpSplitable»

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

Identifiable
+executableEntity
ExecutionTime
0..1 +memorySection 0..* +heapUsage 0..*

Identifiable Identifiable
+executableEntity MemorySection HeapUsage

0..*

Figure 8.1: Resource consumption overview

As depicted by Figure 8.1, all resources are described within the ResourceConsump-
tion meta-class.
ExecutionTime (chapter 8.5) and StackUsage (chapter 8.4.2) are used to provide
information on the implementation specific resource usage of the ExecutableEntity
defined in the InternalBehavior of SW-Component respectively in the BswInter-
nalBehavior of BSW Module.
MemorySection (chapter 8.3.2) documents the resources needed to load the object
file containing the implementation on the ECU.
HeapUsage (chapter 8.4.3) describes the dynamic memory usage of the software.
Class ResourceConsumption
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption
Note Description of consumed resources by one implementation of a software.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by EcuResourceEstimation.bswResourceEstimation, EcuResourceEstimation.rteResourceEstimation,
Implementation.resourceConsumption, StateDependentStartupConfig.resourceConsumption
Attribute Type Mult. Kind Note
accessCount AccessCountSet * aggr Set of access count values
Set
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=accessCountSet, accessCountSet.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
5

137 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ResourceConsumption
executionTime ExecutionTime * aggr Collection of the execution time descriptions for this
implementation. The aggregation of executionTime is
subject to variability with the purpose to support the
conditional existence of runnable entities.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=executionTime.shortName, execution
Time.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
heapUsage HeapUsage * aggr Collection of the heap memory allocated by this
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=heapUsage.shortName, heap
Usage.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
memorySection MemorySection * aggr An abstract memory section required by this
Implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=memorySection.shortName, memory
Section.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
sectionName SectionNamePrefix * aggr A prefix to be used for the memory section symbol in the
Prefix code.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=sectionNamePrefix.shortName, section
NamePrefix.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
stackUsage StackUsage * aggr Collection of the stack memory usage for each runnable
entity of this implementation. The aggregation of Stack
Usage is subject to variability with the purpose to support
the conditional existence of runnable entities.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=stackUsage.shortName, stack
Usage.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 8.1: ResourceConsumption

138 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

8.3 Static Memory Needs

8.3.1 General

This sub-chapter describes how the static memory needs for the Implementation
are specified. This includes all memory needs of software for code or data both at the
class and at the instance level except for:
• stack space needed in the task that activates an ExecutableEntity of the
implementation (see chapter 8.4.2 )
• dynamic heap-behavior of the software (in case the software uses malloc/free
to get/free buffers from the heap, see chapter 8.4.31 )

8.3.2 Memory Sections

Memory will be needed to load the object-file containing an implementation of the soft-
ware on an ECU. In which kind of memory the code and data of the software have to
be allocated has to be defined in an abstract (i.e. platform and compiler independent)
way in the source code of the software according to [17].
To support the integration and configuration of the software component or module the
used (abstract) memory sections and their attributes have to be described also in XML
via the MemorySection element from figure 8.2.

1
This is often problematic in embedded and real-time systems: most software will only need static
memory blocks and stack-size but will not require dynamic memory allocation

139 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

+requiredArtifact
Identifiable ARElement «enumeration»
DependencyOnArtifact 0..* «atpVariation,atpSplitable» Implementation MemoryAllocationKeywordPolicyType

+generatedArtifact addrMethodShortName
addrMethodShortNameAndAlignment
0..* «atpVariation,atpSplitable»
0..1 +implementedIn

«atpSplitable» «enumeration»
+resourceConsumption 0..1 MemorySectionType

Identifiable var
ResourceConsumption code
const
calprm
configData
excludeFromFlash

   calibrationVariables
   
  
       
         

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

+sectionNamePrefix 0..* +memorySection 0..*

ImplementationProps Identifiable +swAddrmethod ARElement

SectionNamePrefix +prefix MemorySection AtpBlueprint
AtpBlueprintable
0..1 + alignment: AlignmentType 0..1
SwAddrMethod
[0..1]
+ option: Identifier [0..*] + memoryAllocationKeywordPolicy:
«atpVariati...
+ size: PositiveInteger [0..1] +swAddrMethod MemoryAllocationKeywordPolicyType
SwDataDefProps
+ symbol: Identifier [0..1] [0..1]
0..1 + option: Identifier [0..*]
+ sectionInitializationPolicy:
SectionInitializationPolicyType [0..1]
+ sectionType: MemorySectionType [0..1]
0..* +executableEntity

Identifiable
+swAddrMethod
ExecutableEntity
0..1

Figure 8.2: Meta-model related to the MemorySection

[TPS_BSWMDT_04046] Memory section name d The actual section name is given by

the MemorySection.symbol, if this attribute is missing the MemorySection.short-
Name is taken as default (this is for backwards compatibility reasons). The section
name of each MemorySection instance shall be a part of the so-called memory al-
location keyword used in preprocessor statements in the actual code.c(RS_BSWMD_-
00005, RS_BSWMD_00031)
For example for a memory section entered by the macro
RTE_START_SEC_VAR_FAST_8 the MemorySection.symbol shall be
VAR_FAST_8.
The preprocessor macros contain in addition so-called prefixes which set up a kind of
name space and by default are equal to the shortName of the enclosing BswMod-
uleDescription or the AtomicSwComponentType (in the above example, the pre-
fix is RTE).
[TPS_BSWMDT_04047] Memory section prefix dIt is possible to supersede these
prefixes by more fine granular values using the meta-class SectionNamePrefix.c
(RS_BSWMD_00031, RS_BSWMD_00014)
There are basically two use cases to supersede the prefix of a memory allocation key
word:
• A Basic Software Module Description provides the description for a ICC1 or ICC2
cluster which still has a sub granularity in its memory allocation implemented.

140 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• A BSW module or software component is split into in allocatable memory parts.

These memory parts are used to assign the sections (CODE, CONST, VAR) be-
longing to a certain functionality to a set of physical controller memories. For
instance the interface code is put to memory which is rather fast accessibly from
all interface users whereas the inner functionality is mapped to memory where
the used hard ware can be accessed with less overhead.
[constr_4103] Name convention for SectionNamePrefix.symbol dIn case
a BSW module is split into allocatable memory parts the existing (according
to [SWS_MemMap_00041]) SectionNamePrefix.symbol shall be set in the
<MIP>_<FEATURE> form, where:
• <MIP> : is the capitalized module implementation prefix
• <FEATURE> : is the name of the sub-feature in the BSW module denoting the
allocatable memory part
c()
[constr_4104] Referencing of MemorySections to SectionNamePrefix dIn case
a BSW module or Software Component is split into allocatable memory parts all Memo-
rySections belonging to the same allocatable memory part shall reference the iden-
tical SectionNamePrefix representing the allocatable memory part.c()
The mapping of the allocation keywords to the compiler specific code is done via
header files. It is possible to generate these header files from an ECU configuration de-
scription, which in turn is constrained by the MemorySections and SwAddrMethods
used in the “upstream” descriptions of modules and components.
[TPS_BSWMDT_04092] Provide memory mapping header file names dAs a default
rule, there is one memory mapping header file per BSW module or per SWC and the
name of this file includes the shortName of the BswModuleDescription resp. the
AtomicSwComponentType as a prefix.
However, for BSW modules or clusters it is possible to supersede the default rule by
explicit reference to one or more files with specific names and granularity. This is
specified by defining one or more DependencyOnArtifact elements aggregated by
BswImplementation in the role requiredArtifact and with DependencyOnAr-
tifact.category set to the value MEMMAP.
The detailed rules on how these header file names are derived are given in [17]:
[SWS_MemMap_00028], [SWS_MemMap_00029], [SWS_MemMap_00032], [SWS_-
MemMap_00035]c(RS_BSWMD_00025)2
[TPS_BSWMDT_04097] Assigning different header files per section prefix dIn
case more than one memory mapping header is referred by one BswImplemen-
tation according to [TPS_BSWMDT_04092], the different header files have to be
2
Note that in any case the AUTOSAR memory mapping header files are considered as implementa-
tion of an own virtual BSW module MemMap, therefore other modules need to refer to these headers via
the role requiredArtifact. In contrast, a BswImplementation representing the implementation of
module MemMap would refer to these files via the role generatedArtifact.

141 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

assigned to individual memory section prefixes by setting the references Section-

NamePrefix.implementedIn.c(RS_BSWMD_00025)
[constr_4072] Constraints of SectionNamePrefix.implementedIn d
• The SectionNamePrefix and the DependencyOnArtifact connected via
this link shall belong to the same BswImplementation.
• The DependencyOnArtifact referred by this link shall be aggregated by
BswImplementation in the role requiredArtifact.
• The DependencyOnArtifact referred by this link shall have the category
value set to MEMMAP.
c()
For a list of standardized allocation keywords, further explanation of the memory map-
ping header files and their configuration parameters see [17].
[TPS_BSWMDT_04048] Scope of declared memory sections dIt is further important
to note, that a BSW module or an SWC shall declare only those sections which are
actually part of its implemented code.c(RS_BSWMD_00005, RS_BSWMD_00052)
That means in particular, if an SWC requires some data to be allocated by the RTE,
for example shared calibration parameters or buffers for communication via ports, the
memory sections of these data have to be declared via an BswImplementation
which is generated by the RTE and represents the implementation of the module RTE.
Several different instances of MemorySection (also across module or component
boundaries) can refer to the same SwAddrMethod, indicating that these abstract sec-
tions share a common means of being handled which is further characterized by SwAd-
drMethod.sectionType.
The attributes of SwAddrMethod (namely sectionType, memoryAllocationKey-
wordPolicy ,option and sectionInitializationPolicy) as well as Memory-
Section.alignment put constraints on the selection of appropriate allocation key-
words resp. their configuration values. This is further explained in [17].
Note that the shortName of SwAddrMethod also has some relationship to the alloca-
tion keyword and thus to the section name defined by MemorySection, which is an
intended redundancy.
SwAddrMethod is also referred by the “upstream” specifications of the data or exe-
cutable entities belonging to these sections, so that the section type can be predefined
early in the process.
The attributes of MemorySection and SwAddrMethod are shown below:

142 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class MemorySection
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::MemorySectionUsage
Note Provides a description of an abstract memory section used in the Implementation for code or data. It shall
be declared by the Implementation Description of the module or component, which actually allocates the
memory in its code. This means in case of data prototypes which are allocated by the RTE, that the
generated Implementation Description of the RTE shall contain the corresponding MemorySections.
The attribute "symbol" (if symbol is missing: "shortName") defines the module or component specific
section name used in the code. For details see the document "Specification of Memory Mapping".
Typically the section name is build according the pattern:
<SwAddrMethod shortName>[_<further specialization nominator>][_<alignment>]
where
• [<SwAddrMethod shortName>] is the shortName of the referenced SwAddrMethod
• [_<further specialization nominator>] is an optional infix to indicate the specialization in the case
that several MemorySections for different purpose of the same Implementation Description referring to
the same or equally named SwAddrMethods.
• [_<alignment>] is the alignment attributes value and is only applicable in the case that the memory
AllocationKeywordPolicy value of the referenced SwAddrMethod is set to addrMethodShortNameAnd
Alignment
MemorySection used to Implement the code of RunnableEntitys and BswSchedulableEntitys shall have a
symbol (if missing: shortName) identical to the referred SwAddrMethod to conform to the generated RTE
header files.
In addition to the section name described above, a prefix is used in the corresponding macro code in
order to define a name space. This prefix is by default given by the shortName of the BswModule
Description resp. the SwComponentType. It can be superseded by the prefix attribute.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.memorySection
Attribute Type Mult. Kind Note
alignment AlignmentType 0..1 attr The attribute describes the typical alignment of objects
within this memory section.
executableEntity ExecutableEntity * ref Reference to the ExecutableEntitites located in this
section. This allows to locate different Executable
Entitities in different sections even if the associated Sw
Addrmethod is the same.
This is applicable to code sections only.
option Identifier * attr The service (in AUTOSAR: BswModuleEntry) is
implemented in a way that it either resolves to aninline
function or to a standard function depending on
conditions set at a later point in time.
The following two values are standardized (to be used for
code sections only and exclusively to each other):
• INLINE - The code section is declared with the keyword
"inline".
• LOCAL_INLINE - The code section is declared with the
keyword "static inline".
In both cases (INLINE and LOCAL_INLINE) the inline
expansion depends on the compiler. Depending on this,
the code section either corresponds to an actual section
in memory or is put into the section of the caller.
prefix SectionNamePrefix 0..1 ref The prefix used to set the memory section’s namespace
in the code. The existence of a prefix element
supersedes rules for a default prefix (such as the Bsw
ModuleDescription’s shortName). This allows the user to
define several name spaces for memory sections within
the scope of one module, cluster or SWC.
size PositiveInteger 0..1 attr The size in bytes of the section.
5

143 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class MemorySection
swAddrmethod SwAddrMethod 0..1 ref This association indicates that this module specific
(abstract) memory section is part of an overall SwAddr
Method, referred by the upstream declarations (e.g.
calibration parameters, data element prototypes, code
entities) which share a common addressing strategy. This
can be evaluated for the ECU configuration of the build
support.
This association shall always be declared by the
Implementation description of the module or component,
which allocates the memory in its code. This means in
case of data prototypes which are allocated by the RTE,
that the software components only declare the grouping
of its data prototypes to SwAddrMethods, and the
generated Implementation Description of the RTE actually
sets up this association.
symbol Identifier 0..1 attr Defines the section name as explained in the main
description. By using this attribute for code generation
(instead of the shortName) it is possible to define several
different MemorySections having the same name - e.g.
symbol = CODE - but using different sectionName
Prefixes.
Table 8.2: MemorySection

Primitive AlignmentType
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This primitive represents the alignment of objects within a memory section. The value is in number of bits
or UNKNOWN (deprecated), 8 , 16, 32, 64 UNSPECIFIED, BOOLEAN, or PTR. Typical values for
numbers are 8, 16, 32, 64.
Tags:
xml.xsd.customType=ALIGNMENT-TYPE
xml.xsd.pattern=[1-9][0-9]*|0[xX][0-9a-fA-F]*|0[bB]
[0-1]+|0[0-7]*|UNSPECIFIED|UNKNOWN|BOOLEAN|PTR
xml.xsd.type=string

Table 8.3: AlignmentType

Class SwAddrMethod
Package M2::MSR::DataDictionary::AuxillaryObjects
Note Used to assign a common addressing method, e.g. common memory section, to data or code objects.
These objects could actually live in different modules or components.
Tags: atp.recommendedPackage=SwAddrMethods
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
memory MemoryAllocation 0..1 attr Enumeration to specify the name pattern of the Memory
Allocation KeywordPolicyType Allocation Keyword.
KeywordPolicy
5

144 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwAddrMethod
option Identifier * attr This attribute introduces the ability to specify further
intended properties of the MemorySection in with the
related objects shall be placed.
These properties are handled as to be selected. The
intended options are mentioned in the list.
In the Memory Mapping configuration, this option list is
used to determine an appropriate MemMapAddressing
ModeSet.
section SectionInitialization 0..1 attr Specifies the expected initialization of the variables
Initialization PolicyType (inclusive those which are implementing VariableData
Policy Prototypes). Therefore this is an implementation
constraint for initialization code of BSW modules
(especially RTE) as well as the start-up code which
initializes the memory segment to which the AutosarData
Prototypes referring to the SwAddrMethod’s are later on
mapped.
If the attribute is not defined it has the identical semantic
as the attribute value "INIT"
sectionType MemorySectionType 0..1 attr Defines the type of memory sections which can be
associated with this addressing method.

Table 8.4: SwAddrMethod

Enumeration MemoryAllocationKeywordPolicyType
Package M2::MSR::DataDictionary::AuxillaryObjects
Note Enumeration to specify the name pattern of the Memory Allocation Keyword.
Aggregated by SwAddrMethod.memoryAllocationKeywordPolicy
Literal Description
addrMethodShort The MemorySection shortNames of referring MemorySections and therefore the belonging Memory
Name Allocation Keywords in the code are build with the shortName of the SwAddrMethod. This is the
default value if the attribute does not exist.
Tags: atp.EnumerationLiteralIndex=0
addrMethodShort The MemorySection shortNames of referring MemorySections and therefore the belonging Memory
NameAndAlignment Allocation Keywords in the code are build with the shortName of the SwAddrMethod and a variable
alignment postfix.
Thereby the alignment postfix needs to be consistent with the alignment attribute of the related
MemorySection.
Tags: atp.EnumerationLiteralIndex=1

Table 8.5: MemoryAllocationKeywordPolicyType

145 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Primitive SectionInitializationPolicyType
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note SectionInitializationPolicyType describes the intended initialization of MemorySections. The following
values are standardized in AUTOSAR Methodology:
• INIT: To be used for (explicitly or not explicitly) initialized variables.
• CLEARED: To be used for not explicitly initialized variables.
• POWER-ON-CLEARED: To be used for variables that are not explicitly initialized (cleared) during
normal start-up. Instead these are cleared only after power on reset.
Please note that the values are defined similar to the representation of enumeration types in the XML
schema to ensure backward compatibility.
Tags:
xml.xsd.customType=SECTION-INITIALIZATION-POLICY-TYPE
xml.xsd.type=NMTOKEN

Table 8.6: SectionInitializationPolicyType

Enumeration MemorySectionType
Package M2::MSR::DataDictionary::AuxillaryObjects
Note Enumeration to specify the essential nature of the data which can be allocated in a common memory
class by the means of the AUTOSAR Memory Mapping.
Aggregated by SwAddrMethod.sectionType
Literal Description
calibrationVariables This memory section is reserved for "virtual variables" that are computed by an MCD system during a
measurement session but do not exist in the ECU memory.
Tags: atp.EnumerationLiteralIndex=2
calprm To be used for calibratable constants of ECU-functions.
Tags: atp.EnumerationLiteralIndex=3
code To be used for mapping code to application block, boot block, external flash etc.
Tags: atp.EnumerationLiteralIndex=4
configData Constants with attributes that show that they reside in one segment for module configuration.
Tags: atp.EnumerationLiteralIndex=5
const To be used for global or static constants.
Tags: atp.EnumerationLiteralIndex=6
excludeFromFlash This memory section is reserved for "virtual parameters" that are taken for computing the values of
so-called dependent parameter of an MCD system. Dependent Parameters that are not at the same
time "virtual parameters" are allocated in the ECU memory.
Virtual parameters, on the other hand, are not allocated in the ECU memory. Virtual parameters exist
in the ECU Hex file for the purpose of being considered (for computing the values of dependent
parameters) during an offline-calibration session.
Tags: atp.EnumerationLiteralIndex=7
var To be used for global or static variables. The expected initialization is specified with the attribute
sectionInitializationPolicy.
Tags: atp.EnumerationLiteralIndex=9

Table 8.7: MemorySectionType

146 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class SectionNamePrefix
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::MemorySectionUsage
Note A prefix to be used for generated code artifacts defining a memory section name in the source code of
the using module or SWC.
Base ARObject, ImplementationProps, Referrable
Aggregated by ResourceConsumption.sectionNamePrefix
Attribute Type Mult. Kind Note
implementedIn DependencyOnArtifact 0..1 ref Optional reference that allows to Indicate the code artifact
(header file) containing the preprocessor implementation
of memory sections with this prefix.
The usage of this link supersedes the usage of a memory
mapping header with the default name (derived from the
BswModuleDescription’s shortName).

Table 8.8: SectionNamePrefix

[constr_4028] Semantics of memory section type dsectionType shall be seman-

tically compatible to the usage of the enclosing SwAddrMethod, this means especially
that if SwAddrMethod is associated by ExecutableEntity-s, the sectionType
shall be usable as code section, if it is associated by SwDataDefProps, section-
Type shall be usable as data section.c()
In case sectionType has the value userDefined, additional documentation is
needed to support the integrator in selecting the proper memory segment from the
ECU.
Note: The section type userDefined is deprecated. Instead of this, user defined
selection criteria shall be given by the attribute SwAddrMethod.option. This allows a
more formal support for selecting the memory segment during integration. (see [17]).
Several values that can be used both for SwAddrMethod.option and MemorySec-
tion.option are predefined by AUTOSAR, see [TPS_SWCT_01456] in [6]. In addi-
tion to this, the following two values are standardized:
[TPS_BSWMDT_04080] Options for inline code sections dFor code sections the
following two values of MemorySection.option are standardized (to be used exclu-
sively to each other):
• INLINE - The code section is declared with the keyword inline.
• LOCAL_INLINE - The code section is declared with the keywords static in-
line
In both cases INLINE and LOCAL_INLINE the inline expansion depends on the com-
piler. Depending on this, the code section either corresponds to an actual section in
memory or is put into the section of the caller.c(RS_BSWMD_00005, RS_BSWMD_-
00031)
[constr_4054] Unambiguous links to addressing method dMemorySection.ex-
ecutableEntity shall not be defined, if MemorySection.swAddrMethod repre-
sents a data section. MemorySection.executableEntity shall not refer to an

147 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ExecutableEntity which is linked to a different SwAddrMethod than MemorySec-

tion.swAddrMethod.c()
[TPS_BSWMDT_04049] Usage of MemorySection.executableEntity dIt is in
general not mandatory to define the relation MemorySection.executableEntity
for code sections because this relationship might be sufficiently determined via the
SwAddrMethod referred by both MemorySection and ExecutableEntity. How-
ever, if explicit name spaces are defined using the MemorySection.prefix attribute
and if MemorySection.sectionType defines a code section, it is mandatory to as-
sign all ExecutableEntity-s running in this section explicitly via MemorySection.
executableEntity. Note that this is not a constraint that can be checked on ARXML
level.c(RS_BSWMD_00005, RS_BSWMD_00014, RS_BSWMD_00031)

8.4 Dynamic Memory Needs

8.4.1 General

The dynamic memory is mainly divided into two categories, the stack and the heap.
While the stack is almost always used in embedded software, the heap is avoided as
much as possible due to the complexity of its implementation, and fragmentation is-
sues. The dynamic memory consumption of software has a much different quality than
the static memory consumption. The amount of the static memory consumption can
be retrieved from the compiler and is only dependent on the compiler and processor
used as well as on the number of instances.
Dynamic memory consumption is heavily dependent on the actual code being executed
which is dependent on the state of the software and the parameters. With the introduc-
tion of recursive concepts the uncertainty is even higher. Therefore the approach for
dynamic memory consumption is far more related to the description of the execution
time introduced in chapter 8.5.

8.4.2 Stack

The stack is an area in memory that is used to store temporary information like parame-
ters and local variables of function calls. Therefore the stack usage is highly dependent
on the calling hierarchy and the nesting level of function calls. The stack is organized in
a LIFO (last in first out) manner. So each time a function is called the necessary stack
memory is occupied. After leaving the function also the associated memory area is
freed again and can be used for the next function call. Among tasks, that do not inter-
rupt each other, fragmentation is not a problem for a stack. Only the available amount
of stack memory is relevant from the software point of view. However, there can be
several stacks in a concurrent task environment. Note that it is not in the scope of a
module or component to define the number of stacks, only the amount of used stack
memory can be given.

148 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Different mechanisms can be used to describe the stack memory needs of software.
Needed stack size can either be calculated, measured or estimated. This is shown in
Figure 8.3.
Identifiable Identifiable ARElement
ResourceConsumption +stackUsage StackUsage +hwElement HwDescriptionEntity

0..1 HwElement
«atpVariation,atpSplitable» 0..*

SoftwareContext
+softwareContext
+ input: String [0..1]
0..1 + state: String [0..1]

HardwareConfiguration
Identifiable +hardwareConfiguration
+executableEntity + additionalInformation: String [0..1]
ExecutableEntity 0..1 + processorMode: String [0..1]
0..1 A
+ processorSpeed: String [0..1]

WorstCaseStackUsage MeasuredStackUsage RoughEstimateStackUsage

+ memoryConsumption: PositiveInteger [0..1] + averageMemoryConsumption: PositiveInteger [0..1] + memoryConsumption: PositiveInteger [0..1]

+ maximumMemoryConsumption: PositiveInteger [0..1]
+ minimumMemoryConsumption: PositiveInteger [0..1]
+ testPattern: String [0..1]

Figure 8.3: Stack Memory Consumption

The given stack memory consumption is dependent on the ECU, the software context
and maybe also on the hardware configuration. The software context and the hard-
ware configuration describe the state of the software and hardware under which the
given stack usage was gathered. So for each given stack memory consumption these
environmental descriptions have to be provided.
Class StackUsage (abstract)
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::StackUsage
Note Describes the stack memory usage of a software.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses MeasuredStackUsage, RoughEstimateStackUsage, WorstCaseStackUsage
Aggregated by ResourceConsumption.stackUsage
Attribute Type Mult. Kind Note
executableEntity ExecutableEntity 0..1 ref The executable entity for which this stack usage is
described.
hardware HardwareConfiguration 0..1 aggr Contains information about the hardware context this
Configuration stack usage is describing.
hwElement HwElement 0..1 ref Specifies for which hardware element (e.g. ECU) this
stack usage is given.
softwareContext SoftwareContext 0..1 aggr Contains details about the software context this stack
usage is provided for.

Table 8.9: StackUsage

149 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class WorstCaseStackUsage
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::StackUsage
Note Provides a formal worst case stack usage.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, StackUsage
Aggregated by ResourceConsumption.stackUsage
Attribute Type Mult. Kind Note
memory PositiveInteger 0..1 attr Worst case stack consumption. Unit: byte.
Consumption

Table 8.10: WorstCaseStackUsage

[constr_10305] Existence of attribute WorstCaseStackUsage.memoryCon-

sumption dFor each WorstCaseStackUsage, the attribute memoryConsumption
shall exist at the time when the configuration of the BSW module is
finished.c()
Class MeasuredStackUsage
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::StackUsage
Note The stack usage has been measured.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, StackUsage
Aggregated by ResourceConsumption.stackUsage
Attribute Type Mult. Kind Note
averageMemory PositiveInteger 0..1 attr The average stack usage measured. Unit: byte.
Consumption
maximum PositiveInteger 0..1 attr The maximum stack usage measured. Unit: byte.
Memory
Consumption
minimum PositiveInteger 0..1 attr The minimum stack usage measured. Unit: byte.
Memory
Consumption
testPattern String 0..1 attr Description of the test pattern used to acquire the
measured values.
Table 8.11: MeasuredStackUsage

[constr_10306] Existence of attribute MeasuredStackUsage.averageMemo-

ryConsumption dFor each MeasuredStackUsage, the attribute averageMemo-
ryConsumption shall exist at the time when the configuration of the
BSW module is finished.c()
[constr_10307] Existence of attribute MeasuredStackUsage.maximumMemo-
ryConsumption dFor each MeasuredStackUsage, the attribute maximumMemo-
ryConsumption shall exist at the time when the configuration of the
BSW module is finished.c()
[constr_4029] Measured stack usage dThe attribute values of Measured-
StackUsage shall fulfill:
minimumMemoryConsumption <= averageMemoryConsumption <= maximum-
MemoryConsumptionc()

150 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RoughEstimateStackUsage
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::StackUsage
Note Rough estimation of the stack usage.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, StackUsage
Aggregated by ResourceConsumption.stackUsage
Attribute Type Mult. Kind Note
memory PositiveInteger 0..1 attr Rough estimate of the stack usage. Unit: byte.
Consumption

Table 8.12: RoughEstimateStackUsage

[constr_10308] Existence of attribute RoughEstimateStackUsage.memoryCon-

sumption dFor each RoughEstimateStackUsage, the attribute memoryConsump-
tion shall exist at the time when the configuration of the BSW mod-
ule is finished.c()

8.4.3 Heap

Heap is the memory segment that is used to cover dynamic memory needs with explicit
memory allocation and de-allocation. Since the allocation of the memory is controlled
by the application program it also survives changes in the context of invocation from
entering a function nesting level and leaving it again. So a memory block allocated
in the subroutine can be used in the calling routine after the subroutine has returned.
Also the allocated memory can be freed again in a different context.
Because of the independence of the heap consumption from processes and tasks only
the whole software component or BSW Module heap consumption is provided in the
description. The meta-model is shown in Figure 8.4.
Identifiable ARElement
+hwElement
HeapUsage HwDescriptionEntity
0..1 HwElement

+softwareContext SoftwareContext
Identifiable +heapUsage
ResourceConsumption 0..1 + input: String [0..1]
«atpVariation,atpSplitable» 0..* + state: String [0..1]

HardwareConfiguration

   +hardwareConfiguration + additionalInformation: String [0..1]
   
+ processorMode: String [0..1]
  0..1
+ processorSpeed: String [0..1]
  
  

WorstCaseHeapUsage MeasuredHeapUsage RoughEstimateHeapUsage

+ memoryConsumption: PositiveInteger [0..1] + averageMemoryConsumption: PositiveInteger [0..1] + memoryConsumption: PositiveInteger [0..1]

+ maximumMemoryConsumption: PositiveInteger [0..1]
+ minimumMemoryConsumption: PositiveInteger [0..1]
+ testPattern: String [0..1]

Figure 8.4: Heap Memory Consumption

The heap memory consumption also depends on the ECU, the software context and
the hardware configuration.

151 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Due to the highly dynamic nature of heap memory one problem is the fragmentation
of the available memory area. So in some cases there can be not enough memory
allocated, even though the total amount of free heap memory is big enough, because
the available memory space is not available contiguously.
Class HeapUsage (abstract)
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::HeapUsage
Note Describes the heap memory usage of a SW-Component.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses MeasuredHeapUsage, RoughEstimateHeapUsage, WorstCaseHeapUsage
Aggregated by ResourceConsumption.heapUsage
Attribute Type Mult. Kind Note
hardware HardwareConfiguration 0..1 aggr Contains information about the hardware context this
Configuration heap usage is describing.
hwElement HwElement 0..1 ref Specifies for which hardware element (e.g. ECU) this
heap usage usage is given.
softwareContext SoftwareContext 0..1 aggr Contains details about the software context this heap
usage is provided for.

Table 8.13: HeapUsage

Class WorstCaseHeapUsage
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::HeapUsage
Note Provides a formal worst case heap usage.
Base ARObject, HeapUsage, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.heapUsage
Attribute Type Mult. Kind Note
memory PositiveInteger 0..1 attr Worst case heap consumption. Unit: byte.
Consumption

Table 8.14: WorstCaseHeapUsage

[constr_10309] Existence of attribute WorstCaseHeapUsage.memoryConsump-

tion dFor each WorstCaseHeapUsage, the attribute memoryConsumption
shall exist at the time when the configuration of the BSW module is
finished.c()
Class MeasuredHeapUsage
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::HeapUsage
Note The heap usage has been measured.
Base ARObject, HeapUsage, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.heapUsage
Attribute Type Mult. Kind Note
averageMemory PositiveInteger 0..1 attr The average heap usage measured. Unit: byte.
Consumption
maximum PositiveInteger 0..1 attr The maximum heap usage measured. Unit: byte.
Memory
Consumption
5

152 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class MeasuredHeapUsage
minimum PositiveInteger 0..1 attr The minimum heap usage measured. Unit: byte.
Memory
Consumption
testPattern String 0..1 attr Description of the test pattern used to acquire the
measured values.
Table 8.15: MeasuredHeapUsage

[constr_10310] Existence of attribute MeasuredHeapUsage.averageMemo-

ryConsumption dFor each MeasuredHeapUsage, the attribute averageMemo-
ryConsumption shall exist at the time when the configuration of the
BSW module is finished.c()
[constr_10311] Existence of attribute MeasuredHeapUsage.maximumMemo-
ryConsumption dFor each MeasuredHeapUsage, the attribute maximumMemo-
ryConsumption shall exist at the time when the configuration of the
BSW module is finished.c()
[constr_4030] Measured heap usage dThe attribute values of MeasuredHeapUsage
shall fulfill:
minimumMemoryConsumption <= averageMemoryConsumption <= maximum-
MemoryConsumptionc()
Class RoughEstimateHeapUsage
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::HeapUsage
Note Rough estimation of the heap usage.
Base ARObject, HeapUsage, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.heapUsage
Attribute Type Mult. Kind Note
memory PositiveInteger 0..1 attr Rough estimate of the heap usage. Unit: byte.
Consumption

Table 8.16: RoughEstimateHeapUsage

[constr_10312] Existence of attribute RoughEstimateHeapUsage.memoryCon-

sumption dFor each RoughEstimateHeapUsage, the attribute memoryConsump-
tion shall exist at the time when the configuration of the BSW mod-
ule is finished.c()

8.5 Execution Time

8.5.1 General

This subsection defines a model to describe the ExecutionTime of a specific Exe-

cutableEntity of a specific Implementation.

153 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Chapter 8.5.3 describes the goals and scope of the ExecutionTime description pro-
posed.
Chapter 8.5.4 lists all the thoughts and observations that lead to the actual model which
is described in chapter 8.5.5.

8.5.2 Preliminaries

This subsection assumes that the reader is familiar with the definition of the following
terminology (please see the AUTOSAR Glossary [5] for details):
• task
• thread
• process
• executable entity
• (worst case) execution time
• (worst case) response time

8.5.3 Scope

8.5.3.1 Assertions Versus Requirements

The ExecutionTime is an ASSERTION: a statement about the duration of the exe-

cution of a piece of code in a given situation. The execution time is NOT a REQUIRE-
MENT on the software, on the hardware or on the scheduling policy.

8.5.3.2 In Scope

This section proposes a description of the ExecutionTime of an ExecutableEn-

tity of an Implementation. Very roughly, this description includes:
• the nominal execution time ("0.000137 s") or a range of times
• a description of the entire context in which the execution time measurement or
analysis has been made
• some indication of the quality of this measurement or estimation
The goal is to find a good compromise between flexibility and precision. The description
has to be flexible enough so that the entire range between analytic results ("worst-
case execution time") and rough estimates can be described. The description should
be precise enough so that it is entirely clear what the relevance or meaning of the
stated execution time is. This implies that a large amount of context information needs

154 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

to be provided. The following sections analyze what this context is and provide an
appropriate structure for this information.

8.5.3.3 Out of Scope

It is however not in the scope of this section to specify how the execution time of a
runnable entity can be or should be measured or analyzed. We will not discuss what
tools or techniques can be used to find the execution time or worst-case execution time
of a piece of software.
It also is not in the scope of this section to define how information about execution
times is used when integrating various software onto one ECU. Similarly this section
does not deal with the response time of the system to certain events. The response
time does not only depend on the execution times of the involved software but also on
the infrastructure overhead and on the scheduling policies which are used.
The focus also is on the description of the execution time of assembly instructions
(typically generated out of compiled C or C++ code). The execution time of e.g. Java
byte-code on a virtual machine has not been explicitly considered.

8.5.4 Background

This section provides some background to the proposed solution. Readers who want
to skip to the result should go to chapter 8.5.5. The execution time can be described
for a specific sequence of assembly instructions. It does not make sense to describe
the execution time of a runnable provided as source-code unless a precise compiler
(and compiler options) are also provided so that a unique set of assembly instructions
can be generated out of the source-code. In addition, the execution time of such a
sequence of assembly instructions depends on:
1. the hardware-platform
2. the hardware state
3. the logical (software) context
4. execution time of external pieces of code called from the software
These dependencies are discussed in detail in the following sections.

8.5.4.1 Dependency of the Execution Time on Hardware

The execution time depends both on the CPU-hardware and on certain parts of the
peripheral hardware:

155 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• The execution time depends on a complete description of the processor, includ-

ing:
– kind of processor (e.g. "PPC603")
– the internal Processor frequency ("100 MHz")
– amount of processor cache
– configuration of CPU (e.g. power-mode)
• Aspects of the periphery that need to be described include:
– external bus-speed
– MMU (memory management unit)
– configuration of the MMU (data-cache, code-cache, write-back,...)
– external cache
– memory (kind of RAM, RAM speed)
In addition, when other devices (I/O) are eventually accessed as memory by the I/O
Hardware Abstraction, the speed of those devices potentially has a large influence on
the execution time of software.
On top of this, the ECU might provide several ways to store the code and data that
needs to be executed. This might also have a large influence on the execution time.
For example:
• execution of assembly instructions stored in RAM versus execution out of ROM
might have very different execution times
• when caching is present, the relative physical location of data accessed in mem-
ory might also influence the execution time

8.5.4.2 Dependency on Hardware State

In addition to the static configuration of the hardware and location of the code and data
on this hardware, the dynamically changing state of the hardware might have a large
influence on the execution time of a piece of code : some examples of this hardware
state are:
• which parts of the code are available in the execution cache and what parts will
need to be read from external RAM
• what part of the data is stored in data cache versus has to be fetched from RAM
• potentially, the state of the processor pipeline
Although this influence is not relevant on simple or deterministic processors (without
cache), the influence of the cache state on modern processors can be enormous (an

156 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

order of magnitude difference is not impossible). Despite the potential importance of

this initial hardware-state when caching is present, it is almost impossible and definitely
impractical to describe this hardware state. Therefore it is important and clear that we
will not provide explicit attributes for this purpose.

8.5.4.3 Dependency on Logical Context

This logical context includes:

1. the input parameters with which the runnable is called
2. also the logical "state" of the component to which the runnable belongs (or more
precisely: the contents of all the memory that is used by the runnable)
While a description of the input-parameters is relatively straight-forward to specify, it
might be very hard to describe the entire logical state that the software depends on.
In addition, in certain cases, one wants to provide a specific (e.g. measured or sim-
ulated) execution time for a very specific logical context; whereas in other cases, one
wants to describe a worst-case execution time over all valid logical contexts or over a
subset of logical contexts.

8.5.4.4 Dependency on External Code

Things get very complex when the piece of code whose execution time is described
makes calls into ("jumps into") external libraries. To deal with this problem, we could
take one of the following approaches:
1. Do not support this case at all: only code that does not rely on external libraries
can be given an execution time
2. Support a description of the execution time for a very specific version (again at
object-code level) of the libraries. The exact versions of external libraries used
would be described together with the execution time. In addition, the relative
location in memory of the runnable and the library, the HW-state with respect to
the library (e.g. whether this code is in cache or not) and the logical state of the
library might have an influence.
3. Conceptually, it might be possible to support a description of the software which
explicitly describes the dependency on the execution times of the library. This
description would include:
(a) the execution time of the code provided by the software itself
(b) a specification of which external library-calls are made (with what parame-
ters, how often, in what order, ...)

157 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Option 3 is deemed unrealistic and impractical and is not supported. Option 2 however
is important as many software might depend on very simple but very common external
libraries (like a math-library that provides floating-point capability in software). Option
2 will therefore be supported for the case that the external library does not have an
additional logical context which influences its execution time.

8.5.5 Description-Model for the Execution Time

8.5.5.1 Detailed Structure of an Execution-Time Description

Figure 8.5 shows how the ExecutionTime is part of the overall description of the
Implementation and how it relates to various other model elements.
[TPS_BSWMDT_04050] ExecutionTime dTo each ExecutableEntity (of a spe-
cific Implementation) an arbitrary number of ExecutionTime descriptions can be
related. Thereby this ExecutionTime description may also depend on code or data
variant of the Implementation.c(RS_BSWMD_00016)
Identifiable Identifiable +softwareMemorySection
ResourceConsumption +memorySection MemorySection
0..1
«atpVariation,atpSplitable» 0..* + alignment: AlignmentType [0..1]
+ option: Identifier [0..*]
+ size: PositiveInteger [0..1] MemorySectionLocation
+ symbol: Identifier [0..1]

+executionTime
Identifiable
«atpVariation,atpSplitable» 0..* ExecutionTime
0..1 +resourceConsumption +memorySectionLocation *
+executableEntity 0..*

Identifiable +executableEntity
«atpSplitable» ExecutableEntity 0..1 +providedMemory 0..1

+ minimumStartInterval: TimeValue [0..1] ARElement

+ reentrancyLevel: ReentrancyLevelEnum [0..1] +hwElement HwDescriptionEntity

0..1 HwElement
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»

+canEnter 0..* +runsInside 0..*

Identifiable +hardwareConfiguration 0..1

+exclusiveArea
ExclusiveArea
0..1 HardwareConfiguration

+ additionalInformation:
String [0..1]
+ processorMode: String
ARElement +requiredGeneratorTool Identifiable [0..1]
Implementation + processorSpeed: String
«atpVariation,atpSplitable» 0..* DependencyOnArtifact
[0..1]
+requiredArtifact +includedLibrary

«atpVariation,atpSplitable» 0..* 0..* SoftwareContext

+softwareContext
+generatedArtifact + input: String [0..1]
0..1 + state: String [0..1]
«atpVariation,atpSplitable» 0..*

Figure 8.5: Detailed relations of an ExecutionTime description

It is expected that many ExecutableEntity-s will not have an associated Execu-

tionTime description. For ExecutableEntity-s that do have ExecutionTime
descriptions, the software-implementor can provide several such descriptions with dif-
ferent scope: For example one per specific ECU on which the Implementation can

158 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

run and on which the time was measured or estimated. Furthermore, even in a given
ECU context it is possible to specify several different types of execution times, as will
be explained below.
If an ExecutableEntity is defined to be running completely in an ExclusiveArea
the related ExecutionTime can be considered as a constraint for configuring the data
consistency mechanism in the RTE.
If an ExecutableEntity is defined to be able to enter an ExclusiveArea the
ExecutionTime can be specified for each area. The time provided is the time con-
sumed AFTER the call to enter the ExclusiveArea and BEFORE the call to leave
the ExclusiveArea.
Figure 8.6 shows the various sub-classes of ExecutionTime. The following para-
graphs describe the aspects of this model in more detail. For the definition of class
TimeValue refer to the timing specification ( [18]).
Identifiable
ExecutionTime

MeasuredExecutionTime RoughEstimateOfExecutionTime

+ additionalInformation: String [0..1]

+minimumExecutionTime 0..1 0..1 +maximumExecutionTime 0..1 +nominalExecutionTime 0..1 +estimatedExecutionTime

MultidimensionalTime

+ cseCode: CseCodeType [0..1]

+ cseCodeFactor: Integer [0..1]
+worstCaseExecutionTime

+minimumExecutionTime
+bestCaseExecutionTime

+nominalExecutionTime

+maximumExecutionTime

0..1 0..1 0..1 0..1 0..1

AnalyzedExecutionTime SimulatedExecutionTime

Figure 8.6: Sub-classes of ExecutionTime and their usage of TimeValue

The following shows the attributes of the ExecutionTime in tabular form:

Class ExecutionTime (abstract)
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::ExecutionTime
Note Base class for several means how to describe the ExecutionTime of software. The required context
information is provided through this class.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
5

159 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ExecutionTime (abstract)
Subclasses AnalyzedExecutionTime, MeasuredExecutionTime, RoughEstimateOfExecutionTime, Simulated
ExecutionTime
Aggregated by ResourceConsumption.executionTime
Attribute Type Mult. Kind Note
exclusiveArea ExclusiveArea 0..1 ref Reference to the ExclusiveArea this execution time is
provided for.
executableEntity ExecutableEntity 0..1 ref The executable entity for which this execution time is
described.
hardware HardwareConfiguration 0..1 aggr Provides information on the HardwareConfiguration used
Configuration to specify this ExecutionTime.
hwElement HwElement 0..1 ref The hardware element (e.g. type of ECU) for which the
execution time is specified.
includedLibrary DependencyOnArtifact * ref If this dependency is specified, the execution time of the
library code is included in the execution time data for the
runnable.
memorySection MemorySectionLocation * aggr Provides information on the MemorySectionLocation
Location which is involved in the ExecutionTime description.
softwareContext SoftwareContext 0..1 aggr Provides information on the detailed SoftwareContext
used to provide the ExecutionTime description.

Table 8.17: ExecutionTime

[constr_10313] Existence of attribute ExecutionTime.hardwareConfigu-

ration dFor each ExecutionTime, the attribute hardwareConfiguration
shall exist at the time when the configuration of the BSW module is
finished.c()
[constr_10314] Existence of attribute ExecutionTime.softwareContext dFor
each ExecutionTime, the attribute softwareContext shall exist at the time
when the configuration of the BSW module is finished.c()

8.5.5.2 ExecutionTime References an "ECU"

[TPS_BSWMDT_04051] ExecutionTime references an ECU dThe Execution-

Time references an ECU (the concept ECU is defined by the ECU-Resource-
Template [19]) via the attribute hwElement. This reference uniquely describes the
hardware for which the ExecutionTime is provided.c(RS_BSWMD_00016) This in-
cludes: the kind of processor, the type of MMU, the type of caches, type of memory
available and so on.

8.5.5.3 ExecutionTime Includes a HW-Configuration

[TPS_BSWMDT_04052] ExecutionTime.hardwareConfiguration dThe ECU

described through the hwElement attribute can still run in several HW-modes. For
example, many ECUs can run in several "speed"-modes (for example a normal fast-
mode and a low-power slow mode). The goal of the HardwareConfiguration is to

160 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

describe this. The attributes processorSpeed and processorMode should describe

the specific mode of the ECU.
Because of the potential dependency on many other HW-Configuration settings (such
as caching policy, MMU-settings, ...), a generic attribute additionalInformation
is provided. Because the exact structure of the information seems to depend so much
on the specific case, all attributes are unstructured text.c(RS_BSWMD_00016)
Class HardwareConfiguration
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption
Note Describes in which mode the hardware is operating while needing this resource consumption.
Base ARObject
Aggregated by ExecutionTime.hardwareConfiguration, HeapUsage.hardwareConfiguration, StackUsage.hardware
Configuration
Attribute Type Mult. Kind Note
additional String 0..1 attr Specifies additional information on the Hardware
Information Configuration.
processorMode String 0..1 attr Specifies in which mode the processor is operating.
processor String 0..1 attr Specifies the speed the processor is operating.
Speed

Table 8.18: HardwareConfiguration

[constr_10315] Existence of attribute HardwareConfiguration.additional-

Information dFor each HardwareConfiguration, the attribute additionalIn-
formation shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10316] Existence of attribute HardwareConfiguration.proces-
sorMode dFor each HardwareConfiguration, the attribute processorMode
shall exist at the time when the configuration of the BSW module is
finished.c()
[constr_10317] Existence of attribute HardwareConfiguration.processor-
Speed dFor each HardwareConfiguration, the attribute processorSpeed
shall exist at the time when the configuration of the BSW module is
finished.c()

8.5.5.4 ExecutionTime Includes a MemorySectionLocation

[TPS_BSWMDT_04053] ExecutionTime.memorySectionLocation dFor each

memorySection of the Implementation, the ExecutionTime shall specify where
this section was located on the physical memory of the ECU. The memorySections of
the software are described in the resourceConsumption of the Implementation.
The available memory-regions on the hardware are described inside the description
of the ECU. The ExecutionTime contains descriptions of the location of the mem-
ory sections MemorySectionLocation which link a software memory section to a
hardware memory section on the ECU.c(RS_BSWMD_00016)

161 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class MemorySectionLocation
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::ExecutionTime
Note Specifies in which hardware ProvidedMemorySegment the softwareMemorySection is located.
Base ARObject
Aggregated by ExecutionTime.memorySectionLocation
Attribute Type Mult. Kind Note
provided HwElement 0..1 ref Reference to the hardware ProvidedMemorySegment.
Memory
software MemorySection 0..1 ref Reference to the MemorySection which is mapped on a
MemorySection certain hardware memory segment.

Table 8.19: MemorySectionLocation

[constr_10318] Existence of reference MemorySectionLocation.provided-

Memory dFor each MemorySectionLocation, the reference in the role provid-
edMemory shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10319] Existence of reference MemorySectionLocation.software-
MemorySection dFor each MemorySectionLocation, the reference in the role
softwareMemorySection shall exist at the time when the configuration
of the BSW module is finished.c()

8.5.5.5 ExecutionTime Includes a SoftwareContext

[TPS_BSWMDT_04054] ExecutionTime.softwareContext dThe Software-

Context is the logical context for which the ExecutionTime is given. This includes
two aspects:
1. the values of the input-parameters to the software
2. the state the logic of the runnable depends on
In the current form, both attributes are of type String and can contain free-form text
describing this state.c(RS_BSWMD_00016)
For the attribute input, it might be appropriate to refine this into a more formal de-
scription of the values of the parameters. For the attribute state, it is difficult to go
beyond an informal text-field, because the state is a private matter of the component
and there currently is no explicit mechanism in AUTOSAR to describe the value of this
state.
Further, it is possible to provide several execution times of a runnable entity, for exam-
ple, in case of different values of the input-parameters. This is one of the reasons why
the template supports an arbitrary number of ExecutionTimes.

162 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class SoftwareContext
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption
Note Specifies the context of the software for this resource consumption.
Base ARObject
Aggregated by ExecutionTime.softwareContext, HeapUsage.softwareContext, StackUsage.softwareContext
Attribute Type Mult. Kind Note
input String 0..1 attr Specifies the input vector which is used to provide the
ExecutionTime.
state String 0..1 attr Specifies the state the software is in when the Execution
Time is provided.

Table 8.20: SoftwareContext

[constr_10320] Existence of attribute SoftwareContext.input dFor each Soft-

wareContext, the attribute input shall exist at the time when the configu-
ration of the BSW module is finished.c()
[constr_10321] Existence of attribute SoftwareContext.state dFor each Soft-
wareContext, the attribute state shall exist at the time when the configu-
ration of the BSW module is finished.c()

8.5.5.6 Dependency on External Libraries

[TPS_BSWMDT_04055] ExecutionTime.includedLibrary d The Execution-

Time measurements can depend on the precise version of external libraries (such
as a math-emulation library) that have been used. This information can be included
by adding a reference to an object of type DependencyOnArtifact which shall be
aggregated by the corresponding Implementation.
If such a reference is specified, the ExecutionTime includes the execution time of
that specific library version.
In case the Implementation aggregates attributes of type DependencyOnArti-
fact, to which the ExecutionTime does not refer, it means that the execution time
of the library code is NOT included in the execution time of the ExecutableEntity.c
(RS_BSWMD_00016)

8.5.5.7 Several Qualities of Execution Times

8.5.5.7.1 AnalyzedExecutionTime

The AnalyzedExecutionTime means that an “analytic” method was used to find

guaranteed boundaries. These boundaries have a lower-limit (best case) and an
upper-limit (worst case).

163 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Considering the cache processor ECU, an execution time could be computed, and
it depends on cache level. A bestCaseExecutionTime and a bestCaseExecu-
tionTime have to be filled.
Class AnalyzedExecutionTime
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::ExecutionTime
Note AnalyzedExecutionTime provides an analytic method for specifying the best and worst case execution
time.
Base ARObject, ExecutionTime, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.executionTime
Attribute Type Mult. Kind Note
bestCase MultidimensionalTime 0..1 aggr The best case execution time (BCET) defines the
ExecutionTime minimum amount of time the related executable entity
requires for its execution.
worstCase MultidimensionalTime 0..1 aggr The worst case execution time (WCET) defines the
ExecutionTime maximum amount of time the related executable entity
requires for its execution.

Table 8.21: AnalyzedExecutionTime

[constr_10323] Existence of attribute AnalyzedExecutionTime.bestCaseEx-

ecutionTime dFor each AnalyzedExecutionTime, the attribute bestCaseExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10324] Existence of attribute AnalyzedExecutionTime.worstCaseEx-
ecutionTime dFor each AnalyzedExecutionTime, the attribute worstCaseExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_4031] Analyzed execution time dThe attribute values of AnalyzedExecu-
tionTime shall fulfill:
bestCaseExecutionTime <= bestCaseExecutionTimec()
Class MultidimensionalTime
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::MultidimensionalTime
Note Specifies a time value based on [20] see [TPS_GST_00354].
Base ARObject
5

164 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class MultidimensionalTime
Aggregated by AgeConstraint.maximum, AgeConstraint.minimum, AnalyzedExecutionTime.bestCaseExecutionTime,
AnalyzedExecutionTime.worstCaseExecutionTime, ArbitraryEventTriggering.maximumDistance,
ArbitraryEventTriggering.minimumDistance, BurstPatternEventTriggering.minimumInterArrivalTime, Burst
PatternEventTriggering.patternJitter, BurstPatternEventTriggering.patternLength, BurstPatternEvent
Triggering.patternPeriod, ConcretePatternEventTriggering.offset, ConcretePatternEventTriggering.pattern
Jitter, ConcretePatternEventTriggering.patternLength, ConcretePatternEventTriggering.patternPeriod,
ConfidenceInterval.lowerBound, ConfidenceInterval.upperBound, ExecutionTimeConstraint.maximum,
ExecutionTimeConstraint.minimum, IoHwAbstractionServerAnnotation.age, LatencyTimingConstraint.
maximum, LatencyTimingConstraint.minimum, LatencyTimingConstraint.nominal, MeasuredExecution
Time.maximumExecutionTime, MeasuredExecutionTime.minimumExecutionTime, MeasuredExecution
Time.nominalExecutionTime, OffsetTimingConstraint.maximum, OffsetTimingConstraint.minimum,
PeriodicEventTriggering.jitter, PeriodicEventTriggering.minimumInterArrivalTime, PeriodicEvent
Triggering.period, ReceiverAnnotation.signalAge, RoughEstimateOfExecutionTime.estimatedExecution
Time, SimulatedExecutionTime.maximumExecutionTime, SimulatedExecutionTime.minimumExecution
Time, SimulatedExecutionTime.nominalExecutionTime, SporadicEventTriggering.jitter, SporadicEvent
Triggering.maximumInterArrivalTime, SporadicEventTriggering.minimumInterArrivalTime, SporadicEvent
Triggering.period, SwDataDefProps.swRefreshTiming, SynchronizationTimingConstraint.tolerance, TDLE
TZoneClock.accuracyExt, TDLETZoneClock.accuracyInt, TimingClockSyncAccuracy.accuracy, Trigger.
triggerPeriod
Attribute Type Mult. Kind Note
cseCode CseCodeType 0..1 attr Specifies the time base by means of CSE codes.
cseCodeFactor Integer 0..1 attr The scaling factor for the time value based on the
specified CSE code.

Table 8.22: MultidimensionalTime

[constr_10338] Existence of attribute MultidimensionalTime.cseCode dFor

each MultidimensionalTime, the attribute cseCode shall exist at the time
when the configuration of the BSW module is finished.c()
[constr_10339] Existence of attribute MultidimensionalTime.cseCode-
Factor dFor each MultidimensionalTime, the attribute cseCodeFactor
shall exist at the time when the configuration of the BSW module is
finished.c()

8.5.5.7.2 MeasuredExecutionTime

The MeasuredExecutionTime describes the ExecutableEntity runtime on an

ECU.

165 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class MeasuredExecutionTime
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::ExecutionTime
Note Specifies the ExecutionTime which has been gathered using measurement means.
Base ARObject, ExecutionTime, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.executionTime
Attribute Type Mult. Kind Note
maximum MultidimensionalTime 0..1 aggr The maximum measured execution time.
ExecutionTime
minimum MultidimensionalTime 0..1 aggr The minimum measured execution time.
ExecutionTime
nominal MultidimensionalTime 0..1 aggr The nominal measured execution time.
ExecutionTime
Table 8.23: MeasuredExecutionTime

[constr_10325] Existence of attribute MeasuredExecutionTime.maximumEx-

ecutionTime dFor each MeasuredExecutionTime, the attribute maximumExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10326] Existence of attribute MeasuredExecutionTime.minimumEx-
ecutionTime dFor each MeasuredExecutionTime, the attribute minimumExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10327] Existence of attribute MeasuredExecutionTime.nominalEx-
ecutionTime dFor each MeasuredExecutionTime, the attribute nominalExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_4032] Measured execution time dThe attribute values of MeasuredExecu-
tionTime shall fulfill:
minimumExecutionTime <= nominalExecutionTime <= maximumExecution-
Timec()

8.5.5.7.3 SimulatedExecutionTime

A SimulatedExecutionTime describes the time information which are coming from

a simulation. Simulation could be based on:
• ExecutableEntity model on specific hardware with time weighting to simulate
processor time behavior
• ExecutableEntity model before generation code

166 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class SimulatedExecutionTime
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::ExecutionTime
Note Specifies the ExecutionTime which has been gathered using simulation means.
Base ARObject, ExecutionTime, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.executionTime
Attribute Type Mult. Kind Note
maximum MultidimensionalTime 0..1 aggr The maximum simulated execution time.
ExecutionTime
minimum MultidimensionalTime 0..1 aggr The minimum simulated execution time.
ExecutionTime
nominal MultidimensionalTime 0..1 aggr The nominal simulated execution time.
ExecutionTime
Table 8.24: SimulatedExecutionTime

[constr_10331] Existence of attribute SimulatedExecutionTime.maximumEx-

ecutionTime dFor each SimulatedExecutionTime, the attribute maximumExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10332] Existence of attribute SimulatedExecutionTime.minimumEx-
ecutionTime dFor each SimulatedExecutionTime, the attribute minimumExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_10333] Existence of attribute SimulatedExecutionTime.nominalEx-
ecutionTime dFor each SimulatedExecutionTime, the attribute nominalExe-
cutionTime shall exist at the time when the configuration of the BSW
module is finished.c()
[constr_4033] Simulated execution time dThe attribute values of SimulatedExe-
cutionTime shall fulfill:
minimumExecutionTime <= nominalExecutionTime <= maximumExecution-
Timec()

8.5.5.7.4 RoughEstimateOfExecutionTime

A RoughEstimateOfExecutionTime describes the time information which are

based on some estimation.
Class RoughEstimateOfExecutionTime
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption::ExecutionTime
Note Provides a description of a rough estimate on the ExecutionTime.
Base ARObject, ExecutionTime, Identifiable, MultilanguageReferrable, Referrable
Aggregated by ResourceConsumption.executionTime
Attribute Type Mult. Kind Note
5

167 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class RoughEstimateOfExecutionTime
additional String 0..1 attr Provides description on the rough estimate of the
Information ExecutionTime.
estimated MultidimensionalTime 0..1 aggr The estimated execution time.
ExecutionTime
Table 8.25: RoughEstimateOfExecutionTime

[constr_10334] Existence of attribute RoughEstimateOfExecutionTime.addi-

tionalInformation dFor each RoughEstimateOfExecutionTime, the attribute
additionalInformation shall exist at the time when the configuration
of the BSW module is finished.c()
[constr_10335] Existence of attribute RoughEstimateOfExecutionTime.es-
timatedExecutionTime dFor each RoughEstimateOfExecutionTime, the at-
tribute estimatedExecutionTime shall exist at the time when the config-
uration of the BSW module is finished.c()

168 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

9 Measurement and Calibration Support

9.1 Overview on McSupportData

AUTOSAR allows to declare data for measurement and calibration (MC-data) in the
description of software components as a well as for basic software. Software compo-
nents can declare MC-data which are handled locally, as well as MC-data for which the
location and access (during normal execution) is implemented by the RTE, for example
data elements in ports, data shared between instances or data requiring software em-
ulation support. BSW modules usually have only local data, but for software emulation
support they also may declare calibration data that are handled by the RTE (see also
chapter 5.10 for the various data roles).
For the final configuration of the measurement and calibration tools another represen-
tation is needed (so-called “A2L”-file) which is not part of AUTOSAR (see [20]).
For a given RTE generator and ECU configuration, the data description part of the
A2L-file could in principle be generated out of the “upstream” AUTOSAR descriptions
of all involved components and modules (with additional address information from the
linker). However, instead of this it has been decided for the AUTOSAR methodology
to provide an additional intermediate ARXML work product, the so-called MC Support
Data which is produced rather late in the ECU configuration process, out of which (with
additional address information from the linker) the final A2L-file can be generated. The
reasons for this approach are:
• For the MC data coded by the RTE generator, the actual C-symbols - which are
needed to find the memory addresses - depend on the RTE implementation and
are not available in the “upstream” descriptions.
• The names used for the data in the BSWM- and SWC-descriptions are not neces-
sarily unique, due to the distributed development in AUTOSAR. In order to define
unique names for display in the MC system (and also for other use cases) a so-
called ECU Flat Map is provided (see [4] [TR_METH_03008] and [TR_METH_-
02003] for the method and [7] for the meta-model). These names shall be made
available to the MC tools through the MC-support-data.
• The definition of data attributes - namely SwDataDefProps - is subject to ad-
ditions or redefinitions in several artifacts which could be produced in different
process steps (for more on this see [6]). In many cases this finally has to be eval-
uated by the RTE generator, therefore it is convenient, that the RTE generator
also puts these final decisions on the SwDataDefProps into a generated set of
MC support data.
• Information on the so-called calibration method has to be provided which is cur-
rently only available in the ECU configuration of the RTE.
• By making use of a dedicated support format, an external tool is less dependent
on the overall AUTOSAR meta-model.

169 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• By making use of a dedicated support format, it is possible to restrict the informa-

tion given to the operator of the final A2L generation to what is actually required
in this step.
It has further been decided, that the MC support format (i.e. its part of the meta-model)
reuses already existing concepts of the meta-model like categories and SwDataDef-
Props, because these concepts are close to the “upstream” descriptions and to “A2L”
concepts as well.
The resulting model is shown in an overview in figure 9.1, which illustrates also the
placement in the context of an ECU configuration. As the figure shows, the root ele-
ment of the MC support McSupportData is aggregated as splitable in an Imple-
mentation. This means, that one such element describes the calibration support for
all data located in this implementation which could be a BSW module/cluster/library or
an SWC as well. The splitable-stereotype allows, that the data can be defined as
a separate artifact and at another point in time, than the Implementation itself. Es-
pecially, the support data for all calibration data located in the RTE shall be generated
as part of the RTE’s own BswImplementation.
In addition to the support for external MCD-tools, the MC-support-data produced by the
RTE generator also can contain information which is needed to support the software
emulation of calibration data inside the ECU. This is explained in more detail in chapter
9.3.
Furthermore, the MC-support-data produced by the RTE generator or a proprietary tool
can contain information which is needed to support rapid prototyping. This is explained
in chapter 9.6.

170 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ARElement +ecucValue ARElement

«atpVariation,atpSplitable»
EcucModuleConfigurationValues EcucValueCollection
0..*
0..1
+moduleDescription

BswImplementation
  
   
 
   +ecuExtract 0..1

ARElement
AtpStructureElement
ARElement ARElement UploadableDesignElement
Implementation SwSystemconstantValueSet System

+measurableSystemConstantValues 0..*

   «atpVariation,atpSplitable»
   
«atpSplitable» +rootSoftwareComposition 0..1
 

+mcSupport 0..1 AtpPrototype

Identifiable
McSupportData RootSwCompositionPrototype

«atpSplitable»

+flatMap 0..1

  
    «atpVariation,atpSplitable» ARElement
  AtpBlueprint
AtpBlueprintable

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

+emulationSupport 0..* +mcParameterInstance 0..* 0..* +mcVariableInstance +instance 0..*

Identifiable Identifiable
McSwEmulationMethodSupport
McDataInstance FlatInstanceDescriptor
+ category: Identifier [0..1] +flatMapEntry
+ shortLabel: Identifier [0..1] + arraySize: PositiveInteger [0..1] + role: Identifier [0..1]
+ displayIdentifier: McdIdentifier [0..1] 0..1
+ role: Identifier [0..1]
«atpSplitable»
«atpVariation,atpSplitable» + symbol: SymbolString [0..1] +mcDataAssignment
RoleBasedMcDataAssignment
0..*
+subElement +mcDataInstance + role: Identifier [0..1]
0..* {ordered}
0..*

«atpSplitable»
0..1
+resultingProperties 0..1
+resultingRptSwPrototypingAccess
«atpVariation»
SwDataDefProps RptSwPrototypingAccess

+ additionalNativeTypeQualifier: NativeDeclarationString [0..1] + rptHookAccess: RptAccessEnum [0..1]

+ displayFormat: DisplayFormatString [0..1] + rptReadAccess: RptAccessEnum [0..1]
+ displayPresentation: DisplayPresentationEnum [0..1] + rptWriteAccess: RptAccessEnum [0..1]
+ stepSize: Float [0..1]
+ swAlignment: AlignmentType [0..1]
«enumeration» «enumeration»
+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]
RptAccessEnum SwCalibrationAccessEnum
+ swImplPolicy: SwImplPolicyEnum [0..1]
+ swIntendedResolution: Numerical [0..1] none readOnly
+ swInterpolationMethod: Identifier [0..1] protected notAccessible
+ swIsVirtual: Boolean [0..1] enabled readWrite
«atpVariation»
+ swValueBlockSize: Numerical [0..1]
+ swValueBlockSizeMult: Numerical [0..*] {ordered} «enumeration» «enumeration»
RptPreparationEnum RptEnablerImplTypeEnum

none none
rptLevel1 rptEnablerRam
rptLevel2 rptEnablerRom
rptLevel3 rptEnablerRamAndRom

Figure 9.1: Calibration Support Data attached to Implementation

In general, MC support data shall be generated for all data with measurement or cali-
bration access in modules or components. For the methodology, we have to distinguish
two cases:

171 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• MC support data is generated by the RTE generator for those data, which are
allocated also by the RTE (resp. the BSW Scheduler). For BSW modules,
this means that those data need to be declared as BswInternalBehavior.
arTypedPerInstanceMemory. This is mandatory if calibration data need em-
ulation support - note that for measurement data within basic software there is no
use case requiring BSW data allocation by the RTE resp. the BSW Scheduler.
• MC support data are generated by any other tool if the data are allocated by the
module or component itself, i.e. for InternalBehavior.staticMemory and
InternalBehavior.constantMemory
[TPS_BSWMDT_04056] Multiplicity of McSupportData dThus in an ECU there will
be at most one (generated) instance of McSupportData for each Implementation
instance:c(RS_BSWMD_00062)
Class McSupportData
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note Root element for all measurement and calibration support data related to one Implementation artifact on
an ECU. There shall be one such element related to the RTE implementation (if it owns MC data) and a
separate one for each module or component, which owns private MC data.
Base ARObject
Aggregated by Implementation.mcSupport
Attribute Type Mult. Kind Note
emulation McSwEmulationMethod * aggr Describes the calibration method used by the RTE. This
Support Support information is not needed for A2L generation, but to setup
software emulation in the ECU.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=emulationSupport, emulation
Support.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
mcParameter McDataInstance * aggr A data instance to be used for calibration.
Instance
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=mcParameterInstance.shortName, mc
ParameterInstance.variationPoint.shortLabel
vh.latestBindingTime=postBuild
mcVariable McDataInstance * aggr A data instance to be used for measurement.
Instance
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=mcVariableInstance.shortName, mcVariable
Instance.variationPoint.shortLabel
vh.latestBindingTime=postBuild
measurable SwSystemconstant * ref Sets of system constant values to be transferred to the
System ValueSet MCD system, because the system constants have been
ConstantValues specified with "swCalibrationAccess" = readonly.
rptSupportData RptSupportData 0..1 aggr The rapid prototyping support data belonging to this
implementation. The aggregtion is <<atpSplitable>>
because in case of an already exisiting BSW
Implementation model, this description will be added later
in the process, namely at code generation time.
Stereotypes: atpSplitable
Tags: atp.Splitkey=rptSupportData

Table 9.1: McSupportData

172 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04057] Self-contained MC support artifact dIt is important to un-

derstand, that the M1 model of an McSupportData element shall be a self-contained
tree of XML elements witch can be given to an external tool without needing all the
“upstream” descriptions. This rule cannot be expressed by the meta-model, it is part
of the methodology. This means that all XML elements which are taken over from
SWC and BSWM descriptions without change (e.g. data types) still have to be copied
into an own artifact. Especially, the links to input variables of axis definitions shall
be modified as to point to the corresponding elements within the McSupportData.c
(RS_BSWMD_00062)
There are several exceptions from this rule:
• [TPS_BSWMDT_04174] Association to FlatMap dThe association to FlatMap
shall be handled in a way that it points to the actual ECU Flat Map, in order
to provide a backward link to the actual sources of the data for documentation
purposes.c(RS_BSWMD_00062)
• [TPS_BSWMDT_04175] Support software emulation dIn order to support soft-
ware emulation of calibration data, a special reference to the description of the
actual data in memory is needed. However, this is not relevant for A2L genera-
tion.c(RS_BSWMD_00062) For more information see chapter 9.3.
• [TPS_BSWMDT_04176] Self-contained MC support artifact dThe elements
under McSupportData can still contain compile-time variation points. These
need to be resolved in sync with the variants selected before compilation of the
software, so that the generated A2L content corresponds to the actual code.
Therefore, as long as the variants are not resolved, the variation points in the
MC support artifact will depend on the system constants needed to resolve these
variants.c(RS_BSWMD_00062) Please refer to figure 9.1.
• [TPS_BSWMDT_04177] Support of functional modeling dIn order to support
the functional modeling of measurement and calibration data, additional artifacts
(based on meta-class McFunction) are (optionally) needed as input to the A2L
generator.c(RS_BSWMD_00062) For more information see chapter 9.4.
• [TPS_BSWMDT_04178] Support of rapid prototyping dIn order to support par-
ticular rapid prototyping solutions, references to the description of communica-
tion behavior of the involved software components are required.c(RS_BSWMD_-
00062) For more information see chapter 9.6.
[TPS_BSWMDT_04058] McSupportData.measurableSystemConstantValues
dIn addition to variables and parameters, also names and values of system constants
may need to be transferred to an MCD tool in order to be displayed. These are mod-
eled by the role McSupportData.measurableSystemConstantValues. Note that
the values of system constants are also possibly subject to compile-time variation (not
visible in the figure).c(RS_BSWMD_00062)
For details on variant handling refer to [1].

173 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

The final A2L-generation is not part of AUTOSAR, but in order to get the complete
picture, it should be mentioned, that in addition to the MC support data some further
information is required (see also [4]) :
• Output from the linker to find the actual memory addresses, as the MC support
data will only contain the C-symbols. In addition, the actual (physical) memory
segments shall be found from the linker output in cases where the address is not
global. Note that the abstract sections defined by MemorySection do not deliver
this information.
• Driver specific access information (so called IF-DATA sections) needed by the
MC system as part of the A2L-file. These are described in a special non-
AUTOSAR data format and shall be generated by the driver modules, e.g. XCP.
• Via the AUTOSAR meta-class AliasNameSet (see [7]) one can provide alterna-
tive names as identifiers for the A2L data which could be used by the A2L gener-
ator to supersede names given by the MC support data. One possible use case
is to resolve name conflicts of system constants which may happen if SwSys-
temconst names are to be copied to the A2L file out of different ARPackages
(this kind of name conflict cannot be resolved by a FlatMap).
• Administrative data for the A2L-File which are nor delivered by AUTOSAR.
• It is up to the A2L generator (and possibly project specific configuration) how data
types are converted into A2L which are coded as C-enums.1
Class AliasNameSet
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note This meta-class represents a set of AliasNames. The AliasNameSet can for example be an input to the
A2L-Generator.
Tags: atp.recommendedPackage=AliasNameSets
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
aliasName AliasNameAssignment * aggr AliasNames contained in the AliasNameSet.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=aliasName.shortLabel, aliasName.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime

Table 9.2: AliasNameSet

[constr_10362] Existence of attribute AliasNameSet.aliasName dFor each

AliasNameSet, the attribute aliasName shall exist at least once at the time
when the configuration of the BSW module is finished.c()

1
This is indicated by the string “enum” as part of the McDataInstance.resultingProperties.
additionalNativeTypeQualifier.

174 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class AliasNameAssignment
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note This meta-class represents the ability to associate an alternative name to a flat representations or an
Identifiable.
The usage of this name is defined outside of AUTOSAR. For example this name can be used by MCD
tools or as a name for component instances in the ECU extract.
Note that flatInstance and identifiable are mutually exclusive.
Base ARObject
Aggregated by AliasNameSet.aliasName
Attribute Type Mult. Kind Note
flatInstance FlatInstanceDescriptor 0..1 ref Assignment of a unique name to a flat representation.
Tags: xml.sequenceOffset=60
identifiable Identifiable 0..1 ref Assignment of a unique name to an Identifiable.
Tags: xml.sequenceOffset=50
label MultilanguageLong 0..1 aggr This represents an "Alias LongName".
Name
Tags: xml.sequenceOffset=20
shortLabel String 0..1 attr This attribute represents the alias name. It is modeled as
string because the alias name is used outside of
AUTOSAR and therefore no naming conventions can be
applied within AUTOSAR.
Stereotypes: atpIdentityContributor
Tags: xml.sequenceOffset=10

Table 9.3: AliasNameAssignment

[constr_10363] Existence of attribute AliasNameAssignment.shortLabel dFor

each AliasNameAssignment, the attribute shortLabel shall exist at the time
when the configuration of the BSW module is finished.c()

9.2 Attributes for McSupportData

Figure 9.2 and the following class tables show the attributes which are to be attached
to the McSupportData in order to support measurement and calibration by external
tools.

175 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

McSupportData

  
   

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

+mcParameterInstance 0..* 0..* +mcVariableInstance

Identifiable
Identifiable
McDataInstance
+flatMapEntry FlatInstanceDescriptor
+ arraySize: PositiveInteger [0..1]
0..1 + role: Identifier [0..1]
+ displayIdentifier: McdIdentifier [0..1]
+ role: Identifier [0..1]
«atpSplitable»
«atpVariation,atpSplitable» + symbol: SymbolString [0..1] «enumeration»
SwCalibrationAccessEnum
+subElement
0..* {ordered} readOnly
notAccessible
«atpSplitable» readWrite
+resultingProperties 0..1

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

ARElement
+swCalprmAxisSet SwCalprmAxisSet
SwRecordLayout +swRecordLayout
0..1
0..1

Figure 9.2: Attributes of MC Support Data

Note that McSupportData is a list of calibration elements (parameters) and measure-

ment elements (variables) in which the component hierarchy has been removed. All
elements of the list are described by meta-class McDataInstance. This meta-class
allows to define arrays and structures, but is does not need a type-prototype-pattern,
because it is not designed for reuse on M1:

176 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class McDataInstance
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note Describes the specific properties of one data instance in order to support measurement and/or
calibration of this data instance.
The most important attributes are:
• Its shortName is copied from the ECU Flat map (if applicable) and will be used as identifier and for
display by the MC system.
• The category is copied from the corresponding data type (ApplicationDataType if defined, otherwise
ImplementationDataType) as far as applicable.
• The symbol is the one used in the programming language. It will be used to find out the actual memory
address by the final generation tool with the help of linker generated information.
It is assumed that in the M1 model this part and all the aggregated and referred elements (with the
exception of the Flat Map and the references from ImplementationElementInParameterInstanceRef and
McAccessDetails) are completely generated from "upstream" information. This means, that even if an
element like e.g. a CompuMethod is only used via reference here, it will be copied into the M1 artifact
which holds the complete McSupportData for a given Implementation.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by McDataInstance.subElement, McSupportData.mcParameterInstance, McSupportData.mcVariable
Instance
Attribute Type Mult. Kind Note
arraySize PositiveInteger 0..1 attr The existence of this attribute turns the data instance into
an array of data. The attribute determines the size of the
array in terms of number of elements.
displayIdentifier McdIdentifier 0..1 attr An optional attribute to be used to set the ASAM ASAP2
DISPLAY_IDENTIFIER attribute.
flatMapEntry FlatInstanceDescriptor 0..1 ref Reference to the corresponding entry in the ECU Flat
Map. This allows to trace back to the original specification
of the generated data instance. This link shall be added
by the RTE generator mainly for documentation purposes.
The reference is optional because
• The McDataInstance may represent an array or struct
in which only the subElements correspond to FlatMap
entries.
• The McDataInstance may represent a task local buffer
for rapid prototyping access which is different from the
"main instance" used for measurement access.
instanceIn ImplementationElement 0..1 aggr Reference to the corresponding data instance in the
Memory InParameterInstance description of calibration data structures published by the
Ref RTE generator. This is used to support emulation
methods inside the ECU, it is not required for A2L
generation.
mcDataAccess McDataAccessDetails 0..1 aggr Refers to "upstream" information on how the RTE uses
Details this data instance. Use Case: Rapid Prototyping
mcData RoleBasedMcData * aggr An assignment between McDataInstances. This supports
Assignment Assignment the indication of related McDataElement implementing
the of "RP global buffer", "RP global measurement
buffer", "RP enabler flag".
resulting SwDataDefProps 0..1 aggr These are the generated properties resulting from
Properties decisions taken by the RTE generator for the actually
implemented data instance. Only those properties are
relevant here, which are needed for the measurement
and calibration system.
Stereotypes: atpSplitable
Tags: atp.Splitkey=resultingProperties
resultingRptSw RptSwPrototyping 0..1 aggr Describes the implemented accessibility of data and
Prototyping Access modes by the rapid prototyping tooling.
Access
5

177 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class McDataInstance
role Identifier 0..1 attr An optional attribute to be used for additional information
on the role of this data instance, for example in the
context of rapid prototyping.
rptImplPolicy RptImplPolicy 0..1 aggr Describes the implemented code preparation for rapid
prototyping at data accesses for a hook based bypassing.
subElement McDataInstance * aggr This relation indicates, that the target element is part of a
(ordered) "struct" which is given by the source element. This
information will be used by the final generator to set up
the correct addressing scheme.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=subElement.shortName, sub
Element.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
symbol SymbolString 0..1 attr This String is used to determine the memory address
during final generation of the MC configuration data (e.g.
"A2L" file) . It shall be the name of the element in the
programming language such that it can be identified in
linker generated information.
In case the McDataInstance is part of composite data in
the programming language, the symbol String may
include parts denoting the element context, unless the
context is given by the symbol attribute of an enclosing
McDataInstance. This means in particular for the C
language that the "." character shall be used as a
separator between the name of a "struct" variable the
name of one of its elements.
The symbol can differ from the shortName in case of
generated C data declarations.
It is an optional attribute since it may be missing in case
the instance represents an element (e.g. a single array
element) which has no name in the linker map.
Stereotypes: atpSplitable
Tags: atp.Splitkey=symbol

Table 9.4: McDataInstance

An McDataInstance may represent the root of a nested composite of arrays and/or

structs. This is modeled by adding appropriate subElements. In this case, the at-
tribute McDataInstance.symbol shall be set only for those elements which actually
are visible in the linker map. This should be always the case for the the root element of
such a composite (otherwise its address cannot be assigned via the linker map):
[constr_4062] Mandatory symbol for McDataInstance root dMcDataInstances
directly aggregated in McSupportData shall have a valid McDataInstance.sym-
bol.c()
[TPS_BSWMDT_04059] Granularity of McDataInstance.subElements dNote that
it is possible to e.g. define single array elements or struct elements as to be measured
or calibrated (the referencing mechanism used in the FlatInstanceDescriptor is
capable of stating array indexes). In this case one needs to define one McDataIn-
stance representing the globally visible C-array or -struct (and stating its symbol) and
appropriate subElements for the nested elements to be measured and link these el-
ements to the individual FlatInstanceDescriptors.c(RS_BSWMD_00062)

178 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04060] McDataInstance.resultingProperties dThe figure

also shows the meta-classes of the typical elements which might be attached to an
McDataInstance via its SwDataDefProps. These elements (and their further de-
tailing, which is not shown here) are used in the same way as in the SWCT (see [6])
though, as already mentioned, it is expected that the support data will contain copies
of the elements found in the SWC- and BSWM-descriptions which refer to each other
in a self-contained manner.c(RS_BSWMD_00062)
[TPS_BSWMDT_04114] Using the hierarchical structuring of McDataInstance.
subElements dThe structure of the subElements shall follow the structure of the cor-
responding ApplicationDataType respectively ImplementationDataType. The
value of the symbol attribute of the subElements shall exist and it shall reflect the
symbol of the subElement only (as opposed to reflecting the full combined symbol
starting from the root element).c(RS_BSWMD_00062)
[TPS_BSWMDT_04115] Use of indexing for array element of subElements dMc-
DataInstances have to be created for those array elements that are accessed by
MCD in separate and these have to be put as subElements under an McDataIn-
stance representing the whole array. The symbol of the subElement shall contain
the array index in the C-notation, e.g [4].c(RS_BSWMD_00062)

9.3 Support for Software Emulation of Calibration Data

The RTE generator provides several methods to allocate calibration data in a way, that
they can be emulated by software on the ECU during an online calibration procedure,
see [10] for a more detailed description. If such an emulation is configured, the calibra-
tion data changed during online calibration are “emulated” by e.g. a Complex Driver,
but the access to these data by the functional software is still handled by the RTE. In
order to generate or configure the emulation code of e.g. the Complex Driver, the RTE
generator has to publish a detailed description of the data structure of the calibration
data and supporting elements which directly correspond to its C-code. This informa-
tion is created by the RTE generator as part the BswInternalBehavior of its own
BSWMD, namely by defining local data descriptions as had been shown earlier.
(Note: These local data descriptions should not be mixed up with the input defining
the calibration data from the perspective of the module or component using the data.
These are for example given as BswInternalBehavior.arTypedPerInstance-
Memory in the BSWMD of the using module, see figure 5.15.)
The generated data descriptions of the RTE are an M1 model of DataPrototypes
based on ImplementationDataTypes using the “normal” meta-model elements.
But in addition the RTE generator has to provide an information on the so-called cali-
bration method which it actually uses and how this relates to the generated data struc-
tures (see [10] for details).

179 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

This is expressed by the meta-class McSwEmulationMethodSupport which for con-

venience is attached to the McSupportData as shown in figure 9.3 and the next two
class tables.
AtpStructureElement ARElement
InternalBehavior Implementation

«atpVariation,atpSplitable» «atpSplitable»
+mcSupport 0..1

  
McSupportData
   
 

  
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»    
+staticMemory 0..* +emulationSupport 0..*  
AutosarDataPrototype +baseReference
McSwEmulationMethodSupport
VariableDataPrototype 0..1
+ category: Identifier [0..1]
+referenceTable + shortLabel: Identifier [0..1]
0..1

+elementGroup 0..*
+ramLocation
McParameterElementGroup
0..1
+ shortLabel: Identifier [0..1]
0..* AutosarDataPrototype
+romLocation
+constantMemory ParameterDataPrototype
0..1

Figure 9.3: Describing the Software Emulation Method for Calibration Data

Class McSwEmulationMethodSupport
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note This denotes the method used by the RTE to handle the calibration data. It is published by the RTE
generator and can be used e.g. to generate the corresponding emulation method in a Complex Driver.
According to the actual method given by the category attribute, not all attributes are always needed:
• double pointered method: only baseReference is mandatory
• single pointered method: only referenceTable is mandatory
• initRam method: only elementGroup(s) are mandatory
Note: For single/double pointered method the group locations are implicitly accessed via the reference
table and their location can be found from the initial values in the M1 model of the respective pointers.
Therefore, the description of elementGroups is not needed in these cases. Likewise, for double pointered
method the reference table description can be accessed via the M1 model under baseReference.
Base ARObject
Aggregated by McSupportData.emulationSupport
Attribute Type Mult. Kind Note
baseReference VariableDataPrototype 0..1 ref Refers to the base pointer in case of the double-pointered
method.
category Identifier 0..1 attr Identifies the actual method. The possible names shall
correspond to the symbols of the ECU configuration
parameter for the calibration method of the RTE, and can
include vendor specific methods.
Tags: xml.sequenceOffset=-90
elementGroup McParameterElement * aggr Denotes the grouping of calibration parameters in the
Group actual RTE code. Depending on the category, this
information maybe required to set up the emulation code.
referenceTable VariableDataPrototype 0..1 ref Refers to the pointer table in case of the single-pointered
method.
shortLabel Identifier 0..1 attr Assigns a name to this element.
Tags: xml.sequenceOffset=-100

Table 9.5: McSwEmulationMethodSupport

180 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10340] Existence of attribute McSwEmulationMethodSupport.cat-

egory dFor each McSwEmulationMethodSupport, the attribute category
shall exist at the time when the configuration of the BSW module is
finished.c()
[constr_10341] Existence of attribute McSwEmulationMethodSupport.short-
Label dFor each McSwEmulationMethodSupport, the attribute shortLabel
shall exist at the time when the configuration of the BSW module is
finished.c()
Class McParameterElementGroup
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note Denotes a group of calibration parameters which are handled by the RTE as one data structure.
Base ARObject
Aggregated by McSwEmulationMethodSupport.elementGroup
Attribute Type Mult. Kind Note
ramLocation VariableDataPrototype 0..1 ref Refers to the RAM location of this parameter group. To be
used for the init-RAM method.
romLocation ParameterData 0..1 ref Refers to the ROM location of this parameter group. To
Prototype be used for the init-RAM method.
shortLabel Identifier 0..1 attr Assigns a name to this element.
Tags: xml.sequenceOffset=-100

Table 9.6: McParameterElementGroup

[constr_10342] Existence of the reference in the role McParameterElement-

Group.ramLocation dFor each McParameterElementGroup, the reference in the
role ramLocation shall exist at the time when the configuration of the BSW mod-
ule is finished.c()
[constr_10343] Existence of the reference in the role McParameterElement-
Group.romLocation dFor each McParameterElementGroup, the reference in the
role romLocation shall exist at the time when the configuration of the BSW mod-
ule is finished.c()
[constr_10344] Existence of attribute McParameterElementGroup.shortLabel
dFor each McParameterElementGroup, the attribute shortLabel shall exist at the
time when the configuration of the BSW module is finished.c()
[TPS_BSWMDT_04061] McSwEmulationMethodSupport.category dThe value of
McSwEmulationMethodSupport.category can either correspond to the enumera-
tion value of the RTE configuration parameter RteCalibrationSupport (namely
DOUBLE_POINTERED, SINGLE_POINTERED or INITIALIZED_RAM, see [10]), or it
can be chosen differently in order to denote a vendor specific method.c(RS_BSWMD_-
00062)
[constr_4044] Content of McSwEmulationMethodSupport dThe following con-
straints hold for the attributes of McSwEmulationMethodSupport:
• If category is DOUBLE_POINTERED, a baseReference shall exist.

181 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• If category is SINGLE_POINTERED, a referenceTable shall exist.

• If category is INITIALIZED_RAM, one or more elementGroups shall exist.
c()
[TPS_BSWMDT_04062] Upstream reference for emulation support dFor a full sup-
port of software emulation, we also need a relation between the “upstream” parameter
description (represented by an entry in the ECU Flat Map) and the actually imple-
mented code element. The required reference ImplementationElementInParam-
eterInstanceRef is attached to McDataInstance. This is mainly done for con-
venience, as McDataInstance is generated in the same step and already refers to
the Flat Map. This part of the meta-model assumes, that the RTE generator uses
ImplementationDataTypes to describe the implemented data structures and that
each implemented parameter element is part of a group, thus resulting in a Imple-
mentationDataTypeElement as the target of the reference.c(RS_BSWMD_00062)
Figure 9.4 shows the relation between the “upstream” parameter description and the
actually implemented code element.

182 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BswInternalBehavior +behavior BswImplementation

0..1

AtpStructureElement ARElement
InternalBehavior Implementation

«atpSplitable»
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
+mcSupport 0..1

  
    McSupportData
 

+constantMemory 0..* +perInstanceParameter 0..*

ParameterDataPrototype
  
   
 
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
+context 0..1
+emulationSupport 0..* +mcParameterInstance 0..*

DataPrototype Identifiable
McSwEmulationMethodSupport
AutosarDataPrototype McDataInstance
+ category: Identifier [0..1]
+ shortLabel: Identifier [0..1] + arraySize: PositiveInteger [0..1]
+ displayIdentifier: McdIdentifier [0..1]
+ role: Identifier [0..1]
«atpVariation,atpSplitable» «atpSplitable»
«isOfType» + symbol: SymbolString [0..1]

  
   
  +subElement
0..1 0..* {ordered}
{redefines
+type atpType}
+instanceInMemory 0..1
ARElement
AtpType
ImplementationElementInParameterInstanceRef
AutosarDataType

+target 0..1

AtpStructureElement

   Identifiable
    AbstractImplementationDataTypeElement
 

+subElement
0..* {ordered}
AbstractImplementationDataType
ImplementationDataTypeElement
ImplementationDataType
+subElement «atpVariation,atpSplitable»
+ dynamicArraySizeProfile: String [0..1]
+ isStructWithOptionalElement: Boolean [0..1] «atpVariation,atpSplitable» 0..*
+ typeEmitter: NameToken [0..1] {ordered}

Figure 9.4: Reference to the Implemented Data needed for Emulation

183 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ImplementationElementInParameterInstanceRef
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note Describes a reference to a particular ImplementationDataTypeElement instance in the context of a given
ParameterDataPrototype. Thus it refers to a particular element in the implementation description of a
software data structure.
Use Case: The RTE generator publishes its generated structure of calibration parameters in its BSW
module description using the "constantMemory" role of ParameterDataPrototypes. Each ParameterData
Prototype describes a group of single calibration parameters. In order to point to these single
parameters, this "instance ref" is needed.
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
Aggregated by McDataInstance.instanceInMemory
Attribute Type Mult. Kind Note
context ParameterData 0..1 ref The context for the referred element.
Prototype
Tags: xml.sequenceOffset=20
target AbstractImplementation 0..1 ref The referred data element.
DataTypeElement
Tags: xml.sequenceOffset=30

Table 9.7: ImplementationElementInParameterInstanceRef

[constr_10345] Existence of the reference in the role ImplementationEle-

mentInParameterInstanceRef.context dFor each ImplementationEle-
mentInParameterInstanceRef, the reference in the role context shall exist at
the time when the configuration of the BSW module is finished.c()
[constr_10346] Existence of the reference in the role ImplementationEle-
mentInParameterInstanceRef.target dFor each ImplementationEle-
mentInParameterInstanceRef, the reference in the role target shall exist at
the time when the configuration of the BSW module is finished.c()
[constr_4034] Target and context of MC emulation reference dWithin one Imple-
mentationElementInParameterInstanceRef, the target shall refer to a sub-
element of the ParameterDataPrototype which is referred as context.c()
If the elements to be measured or calibrated are part of arrays or structs, it is important
to define the references in a consistent and complete way for all sub-elements in-
volved in order to avoid ambiguities. Since the ImplementationElementInParam-
eterInstanceRef allows to define only one context element, we need the following
constraint:
[constr_4061] Completeness of MC emulation reference dIf an McDataInstance
in the role of a subElement of another McDataInstance specifies an instanceIn-
Memory, then the containing McDataInstance shall also specify an instanceIn-
Memory. The target of the latter (i.e. upper level) instanceInMemory shall be
identical (including array index, if defined) to the context of the first (i.e. lower level)
instanceInMemory.c()
Without this constraint, it would be possible to define a reference to an inner element
of nested arrays/structs without that the corresponding global C variable could be iden-
tified.

184 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

9.4 Support for Functional Modeling of Measurement and Calibra-

tion
The “A2L” description format for measurement and calibration data allows to associate
the data with so-called functions in order to guide the calibration engineer in handling
a large number of such data (see description of the keyword FUNCTION in [20]).
Such functions are mainly logical constructs and do not necessarily match to software
objects like modules or components in the sense of AUTOSAR. However, since it is
the goal of measurement and calibration support of AUTOSAR to be able to generate
A2L descriptions from AUTOSAR XML descriptions, the AUTOSAR meta-model also
provides the means to define such functions in the sense of A2L.
[TPS_BSWMDT_04078] Semantics of McFunction dThe meta-class McFunction
together with associated McFunctionDataRefSets can be used to define the asso-
ciation of measurement and/or calibration data in a software system to a logical func-
tion in various roles. In addition, it allows to structure such functions hierarchically.c
(RS_BSWMD_00062)
Note that McFunction is an ARElement so it can be used to define standalone arti-
facts which strictly speaking do not belong to any particular BSWMD. Nonetheless this
part of the meta-model is described in this document because it belongs to the overall
support for measurement and calibration.
«atpSplitable»

+subFunction 0..*

ARElement
McFunction

«atpSplitable» «atpSplitable» «atpSplitable» «atpSplitable» «atpSplitable»

+defCalprmSet 0..1 +refCalprmSet 0..1 +inMeasurementSet 0..1 +outMeasurementSet 0..1 +locMeasurementSet 0..1

«atpVariation»
McFunctionDataRefSet

«atpSplitable» «atpSplitable»
0..*
+flatMapEntry +mcDataInstance 0..*

Identifiable Identifiable


FlatInstanceDescriptor     
  McDataInstance
+flatMapEntry
 

+ role: Identifier [0..1] + arraySize: PositiveInteger [0..1]
0..1 + displayIdentifier: McdIdentifier [0..1]
+ role: Identifier [0..1]
+instance 0..*
«atpSplitable»
   
 + symbol: SymbolString [0..1]
«atpVariation,atpSplitable»
    
 
   +mcParameterInstance 0..* 0..* +mcVariableInstance
ARElement
AtpBlueprint «atpVariation,atpSplitable»
AtpBlueprintable «atpVariation,atpSplitable»
FlatMap

McSupportData

Figure 9.5: Meta-model for McFunction

185 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class McFunction
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note Represents a functional element to be used as input to support measurement and calibration. It is used to
• assign calibration parameters to a logical function
• assign measurement variables to a logical function
• structure functions hierarchically
Tags: atp.recommendedPackage=McFunctions
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
defCalprmSet McFunctionDataRefSet 0..1 aggr Refers to the set of adjustable data (= calibration
parameters) defined in this function.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=defCalprmSet
xml.sequenceOffset=10
inMeasurement McFunctionDataRefSet 0..1 aggr Refers to the set of measurable input data for this
Set function.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=inMeasurementSet
xml.sequenceOffset=30
loc McFunctionDataRefSet 0..1 aggr Refers to the set of measurable local data in this function.
Measurement
Stereotypes: atpSplitable
Set
Tags:
atp.Splitkey=locMeasurementSet
xml.sequenceOffset=50
out McFunctionDataRefSet 0..1 aggr Refers to the set of measurable output data from this
Measurement function.
Set
Stereotypes: atpSplitable
Tags:
atp.Splitkey=outMeasurementSet
xml.sequenceOffset=60
refCalprmSet McFunctionDataRefSet 0..1 aggr Refers to the set of adjustable data (= calibration
parameters) referred by this function.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=refCalprmSet
xml.sequenceOffset=20
subFunction McFunction * ref A sub-function that is seen as part of the enclosing
function.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=subFunction
xml.sequenceOffset=70

Table 9.8: McFunction

186 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class <<atpVariation>> McFunctionDataRefSet

Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Refers to a set of data assigned to an McFunction in a particular role. The data are given
• either by entries in a FlatMap
• or by data instances that are part of MC support data.
These two possibilities are exclusive within a given McFunctionDataRefSet. Which one to use depends
on the process and tool environment.
The set is subject to variability because the same functional model may be used with various
representation of the data.
Tags: vh.latestBindingTime=preCompileTime
Base ARObject
Aggregated by McFunction.defCalprmSet, McFunction.inMeasurementSet, McFunction.locMeasurementSet, Mc
Function.outMeasurementSet, McFunction.refCalprmSet
Attribute Type Mult. Kind Note
flatMapEntry FlatInstanceDescriptor * ref Refers to an entry in a FlatMap that is part of the set, for
example a calibration parameter or measured variable.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable
Tags: xml.sequenceOffset=10
mcDataInstance McDataInstance * ref Refers to a data instance within MC support data that is
part of the set, i.e. a calibration parameter or measured
variable.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable
Tags: xml.sequenceOffset=20

Table 9.9: McFunctionDataRefSet

[TPS_BSWMDT_04087] Scope of McFunctionDataRefSets dIt should be noted

that McFunctionDataRefSets can refer to the data either via instances of FlatIn-
stanceDescriptor or McDataInstance:
• The first possibility, i.e. the association via a FlatMap allows to define McFunc-
tions rather early in the project on ECU or even System level before the actual
McSupport has been generated.
• The second possibility, the association to McDataInstances allows to define (or
transform) McFunctions for usage in a self-contained manner together with the
McSupport data for A2L generation.
c(RS_BSWMD_00062)
[TPS_BSWMDT_04088] Usage of McFunction dSince the use cases for McFunc-
tion are considered as rather project specific and the specification how to generate
A2L does not belong to AUTOSAR, not all possible constraints on the attributes and
association owned by McFunction are specified in this document. Especially it is not
standardized, how instances of McFunctions have to be derived from an M1 model
of AUTOSAR software components or modules.c(RS_BSWMD_00062)
Still some constraints are considered as mandatory:

187 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_4068] McFunctionDataRefSet.flatMapEntry’s semantic d

• An McFunctionDataRefSet aggregated in the role of McFunction.de-
fCalprmSet or McFunction.refCalprmSet shall only refer to FlatIn-
stanceDescriptors that
– either can be traced down to a ParameterDataPrototype
– or can be traced down to a VariableDataPrototype of category
COM_AXIS, RES_AXIS, CURVE, MAP, CUBOID, CUBE_4, CUBE_5 or
VAL_BLK
and which are declared for calibration access i.e. have an associated Sw-
DataDefProps.swCalibrationAccess set to readWrite or readOnly.
• An McFunctionDataRefSet aggregated in the role of McFunction.inMea-
surementSet, McFunction.outMeasurementSet or McFunction.locMea-
surementSet shall only refer to FlatInstanceDescriptors that can be
traced down to either a VariableDataPrototype, an ArgumentDataPro-
totype or a ModeDeclarationGroupPrototype and are declared as mea-
surable i.e. have an associated SwDataDefProps.swCalibrationAccess set
to readOnly.
c()
[constr_4069] McFunctionDataRefSet.mcDataInstance’s semantic d
• An McFunctionDataRefSet aggregated in the role of McFunction.defCal-
prmSet or McFunction.refCalprmSet shall only refer to McDataInstances
that are declared for calibration access i.e. are aggregated in the role Mc-
SupportData.mcParameterInstance or McSupportData.mcVariableIn-
stance of category COM_AXIS, RES_AXIS, CURVE, MAP, CUBOID, CUBE_4,
CUBE_5 or VAL_BLK.
• An McFunctionDataRefSet aggregated in the role of McFunction.inMea-
surementSet, McFunction.outMeasurementSet or McFunction.locMea-
surementSet shall only refer to McDataInstances that are declared as
measurable i.e. are aggregated in the role McSupportData.mcVariableIn-
stance.
c()
Please note, that VariableDataPrototypes - end corresponding McDataInstances
- of category of category COM_AXIS, RES_AXIS, CURVE, MAP, CUBOID, CUBE_4,
CUBE_5 or VAL_BLK are describing so called adaptive characteristics. Those are
modifiable during the ECU run-time and therefore described as VariableDataPro-
totypes but are CHARACTERISTICs in the sense of A2L.
Older versions of the meta-model didn’t contain the meta-class McFunction but there
was already the possibility to specify the name of a function associated with a data
object by the attribute SwDataDefProps.McFunction. This had serious limitations
as is was neither possible to define input data to a function, nor to define more than

188 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

one function associated with some data, nor to define sub-functions. For backward
compatibility reasons this possibility still exists but the attribute has been tagged as
obsolete.

9.5 Support for Structuring of Measurement and Calibration

The “A2L” description format for measurement and calibration data allows to associate
the data with so-called groups in order to support structuring of projects involving a
very large number measurement and calibration data (see description of the keyword
GROUP in [20]).
Such groups are used to structure measurement and calibration data as well as func-
tions according user specific criteria, e.g. a structuring according the C file assignment
or calibration components which describe the calibration engineers viewpoint. Therefor
groups are mainly logical constructs and do not necessarily match to software objects
like modules or components in the sense of AUTOSAR. However, since it is the goal
of measurement and calibration support of AUTOSAR to be able to generate A2L de-
scriptions from AUTOSAR XML descriptions, the AUTOSAR meta-model also provides
the means to define such groups in the sense of A2L.
[TPS_BSWMDT_04168] Semantics of McGroup dThe meta-class McGroup together
with associated McGroupDataRefSets can be used to define the association of mea-
surement and/or calibration data and/or functions in a software system to a logical
structure in various roles. In addition, it allows to structure such groups hierarchically.c
(RS_BSWMD_00062)
Similar as McFunction the McGroup is an ARElement so it can be used to define
standalone artifacts which strictly speaking do not belong to any particular BSWMD.
Nonetheless this part of the meta-model is described in this document because it be-
longs to the overall support for measurement and calibration.

189 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

«atpSplitable»

+subGroup 0..*

ARElement
McGroup

«atpSplitable» «atpSplitable»

+refCalprmSet 0..1 +refMeasurementSet 0..1

«atpVariation»
McGroupDataRefSet «atpSplitable»

«atpSplitable» «atpSplitable»
+flatMapEntry 0..* +mcDataInstance 0..* +mcFunction 0..*
Identifiable Identifiable ARElement
FlatInstanceDescriptor McDataInstance McFunction
+flatMapEntry
+ role: Identifier [0..1] + arraySize: PositiveInteger [0..1]
0..1 + displayIdentifier: McdIdentifier [0..1]
+subFunction 0..*
+ role: Identifier [0..1]
«atpSplitable» «atpSplitable»
+ symbol: SymbolString [0..1]
+instance 0..* +mcParameterInstance 0..* 0..* +mcVariableInstance
«atpVariation,atpSplitable»

  
«atpVariation,atpSplitable»     «atpVariation,atpSplitable»


ARElement McSupportData
AtpBlueprint
AtpBlueprintable
FlatMap

Figure 9.6: Meta-model for McGroup

Class McGroup
Package M2::AUTOSARTemplates::CommonStructure::McGroups
Note Represents a group element to be used as input to support measurement and calibration. It is used to
provide selection lists (groups) of calibration parameters, measurement variables, and functions in a
hierarchical manner (subGroups).
Tags: atp.recommendedPackage=McFunctions
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
mcFunction McFunction * ref A McFunction that is seen as part of the enclosing group.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=mcFunction
xml.sequenceOffset=40
refCalprmSet McGroupDataRefSet 0..1 aggr Refers to the set of adjustable data (= calibration
parameters) referred by this McGroup.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=refCalprmSet
xml.sequenceOffset=20
5

190 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class McGroup
ref McGroupDataRefSet 0..1 aggr Refers to the set of measurable belonging to this Mc
Measurement Group.
Set
Stereotypes: atpSplitable
Tags:
atp.Splitkey=refMeasurementSet
xml.sequenceOffset=30
subGroup McGroup * ref A sub-group that is seen as part of the enclosing group.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=subGroup
xml.sequenceOffset=10

Table 9.10: McGroup

Class <<atpVariation>> McGroupDataRefSet

Package M2::AUTOSARTemplates::CommonStructure::McGroups
Note Refers to a set of data assigned to an McGroup in a particular role. The data are given
• either by entries in a FlatMap
• or by data instances that are part of MC support data.
These two possibilities can be mixed within a given McGroupDataRefSet. Which one to use depends on
the process and tool environment.
The set is subject to variability because the same functional model may be used with various
representation of the data.
Tags: vh.latestBindingTime=preCompileTime
Base ARObject
Aggregated by McGroup.refCalprmSet, McGroup.refMeasurementSet
Attribute Type Mult. Kind Note
flatMapEntry FlatInstanceDescriptor * ref Refers to an entry in a FlatMap that is part of the set, for
example a calibration parameter or measured variable.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable
Tags: xml.sequenceOffset=50
mcDataInstance McDataInstance * ref Refers to a data instance within MC support data that is
part of the set, i.e. a calibration parameter or measured
variable.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable
Tags: xml.sequenceOffset=60

Table 9.11: McGroupDataRefSet

[TPS_BSWMDT_04169] Scope of McGroupDataRefSets dMcGroupDataRefSets

can refer to the data either via instances of FlatInstanceDescriptor or Mc-
DataInstance:
• The first possibility, i.e. the association via a FlatMap allows to define McGroups
rather early in the project on ECU or even System level before the actual McSup-
port has been generated.

191 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• The second possibility, the association to McDataInstances allows to define

(or transform) McGroups for usage in a self-contained manner together with the
McSupport data for A2L generation.
c(RS_BSWMD_00062)
[TPS_BSWMDT_04170] Usage of McGroup dSince the use cases for McGroup are
considered as rather project specific and the specification how to generate A2L does
not belong to AUTOSAR, not all possible constraints on the attributes and association
owned by McGroup are specified in this document. Especially it is not standardized,
how instances of McGroups have to be derived from an M1 model of AUTOSAR soft-
ware components or modules.c(RS_BSWMD_00062)
Still some constraints are considered as mandatory:
[constr_4101] Semantics of McGroupDataRefSet.flatMapEntry d
• An McGroupDataRefSet aggregated in the role of McGroup.refCalprm-
Set or McGroup.refCalprmSet shall only refer to FlatInstanceDescrip-
tors that can either be traced down to a ParameterDataPrototype or
can be traced down to a VariableDataPrototype of category COM_AXIS,
RES_AXIS, CURVE, MAP, CUBOID, CUBE_4, CUBE_5 or VAL_BLK and which
are declared for calibration access i.e. have an associated SwDataDefProps.
swCalibrationAccess set to readWrite or readOnly.
• An McGroupDataRefSet aggregated in the role of McGroup.refMeasure-
mentSet shall only refer to FlatInstanceDescriptors that can be traced
down to either a VariableDataPrototype, an ArgumentDataPrototype or
a ModeDeclarationGroupPrototype and are declared as measurable i.e.
have an associated SwDataDefProps.swCalibrationAccess set to read-
Only.
c()
[constr_4102] Semantics of McGroupDataRefSet.mcDataInstance d
• An McGroupDataRefSet aggregated in the role of McGroup.refCalprmSet
shall only refer to McDataInstances that are declared for calibration access
i.e. are aggregated in the role McSupportData.mcParameterInstance or
McSupportData.mcParameterInstance of category COM_AXIS, RES_AXIS,
CURVE, MAP, CUBOID, CUBE_4, CUBE_5 or VAL_BLK.
• An McGroupDataRefSet aggregated in the role of McGroup.refMeasure-
mentSet shall only refer to McDataInstances that are declared as measurable
i.e. are aggregated in the role McSupportData.mcVariableInstance.
c()
Please note, that VariableDataPrototypes - end corresponding McDataInstances
- of category of category COM_AXIS, RES_AXIS, CURVE, MAP, CUBOID, CUBE_4,
CUBE_5 or VAL_BLK are describing so called adaptive characteristics. Those are

192 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

modifiable during the ECU run-time and therefore described as VariableDataPro-

totypes but are CHARACTERISTICs in the sense of A2L.

9.6 McSupportData for Rapid Prototyping

The AUTOSAR meta-model supports the description of a software system that include
rapid prototyping scenarios of Application Software Components. The high level part of
such a description is done with the help of the meta-class RapidPrototypingSce-
nario, see [6] for documentation.
So far this “high level” description of rapid prototyping is not a topic for the BSWMDT.
However some special solutions for rapid prototyping require a direct access to RTE
internal data buffers that are used to hold the data for communication between software
components:
• The rapid prototyping implementation (which could run on an external ECU or as
a Complex Driver on the same ECU) may directly2 access the RTE data buffers
in a similar way as it is done from an MCD system (e.g. via an XCP driver)
• The rapid prototyping functionality may be embedded in the RTE itself. In this
case, external data access is needed to monitor the data as well as to switch
between the “prototyping” and the “original” behavior of the RTE for a particular
data access point.
In order to configure a rapid prototyping system that works according to the solutions
outlined above, some knowledge on the RTE internal data buffers has to be provided
to external tools in a similar way as for MCD access. Therefore the meta-classes
below McSupportData are used for this purpose too. Several extensions to these
meta-classes are needed for these use cases.

2
“directly” means not via an RTE API or an RTE hook function

193 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

McSupportData

«atpSplitable»

+rptSupportData 0..1

RptSupportData

«atpVariation,atpSplitable»
«atpVariation,atpSplitable»

«atpVariation,atpSplitable»
+rptServicePoint 0..* +rptComponent 0..*
RoleBasedMcDataAssignment
Identifiable Identifiable
RptServicePoint RptComponent + role: Identifier [0..1]
+mcDataAssignment
+ serviceId: PositiveInteger [0..1] 0..*
+ symbol: CIdentifier [0..1]

0..* 0..* +mcDataAssignment

+rptServicePointPost
+rptServicePointPre

0..*

+mcDataAssignment 0..*
+rptRead * +rptWrite *
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
+rptExecutableEntity 0..*

Identifiable
RptExecutableEntity

+mcVariableInstance
+ symbol: CIdentifier [0..1]

+mcDataInstance
«atpVariation,atpSplitable»

0..*
+rptExecutableEntityEvent 0..*

0..*
Identifiable
Identifiable
RptExecutableEntityEvent
McDataInstance
+ rptEventId: PositiveInteger [0..1]
+ arraySize: PositiveInteger [0..1]
+ displayIdentifier: McdIdentifier [0..1]
+ role: Identifier [0..1]
«atpSplitable»
+ symbol: SymbolString [0..1]

+rptExecutableEntityProperties 0..1 +rptImplPolicy 0..1 +rptImplPolicy 0..1 +subElement

0..* {ordered}
RptExecutableEntityProperties RptImplPolicy
+ maxRptEventId: PositiveInteger [0..1] + rptEnablerImplType: RptEnablerImplTypeEnum [0..1]
+ minRptEventId: PositiveInteger [0..1] + rptPreparationLevel: RptPreparationEnum [0..1]
+ rptExecutionControl: RptExecutionControlEnum [0..1] «atpVariation,atpSplitable»
+ rptServicePoint: RptServicePointEnum [0..1]

+resultingRptSwPrototypingAccess 0..1

«enumeration» RptSwPrototypingAccess
RptServicePointEnum
+ rptHookAccess: RptAccessEnum [0..1]
none + rptReadAccess: RptAccessEnum [0..1]
enabled + rptWriteAccess: RptAccessEnum [0..1]

«enumeration» «enumeration» «enumeration» «enumeration»

RptAccessEnum RptPreparationEnum RptEnablerImplTypeEnum RptExecutionControlEnum
none none none none
protected rptLevel1 rptEnablerRam conditional
enabled rptLevel2 rptEnablerRom
rptLevel3 rptEnablerRamAndRom

Figure 9.7: Extension of McSupportData for Rapid Prototyping

[TPS_BSWMDT_04094] Details of McDataInstance for rapid prototyping

dEspecially for the prototyping of a RunnableEntity with implicit communication,
typically more than one RTE internal buffer needs to be accessed and it needs to be
described what kind of data access and what RTE event is associated with each buffer.
This information can be provided (for example generated) by setting the references in
McDataInstance.mcDataAccessDetails. The base of these references shall be

194 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

the ECU Extract to which also the RTE implementation belongs for which the McSup-
portData is meant (see also constraint below).
In addition to this, the attribute McDataInstance.role may be used to add more
information on the particular role of this data instance. Note the the content of this
attribute is not standardized.c(RS_BSWMD_00065)
[constr_4073] McDataAccessDetails shall refer to one ECU Extract dWithin one
given McDataAccessDetails, all instances of System referenced as the base of
any McDataAccessDetails.variableAccess or as the base of any McDataAc-
cessDetails.rteEvent shall be identical and of category ECU_EXTRACT.c()
Class McDataAccessDetails
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note This meta-class allows to attach detailed information about the usage of a data buffer by the RTE to a
corresponding McDataInstance.
Use Case: Direct memory access to RTE internal buffers for rapid prototyping. In case of implicit
communication, the various task local buffers need to be identified in relation to RTE events and variable
access points.
Note that the SwComponentPrototype, the RunnableEntity and the VariableDataPrototype are implicitly
given be the referred instances of RTEEvent and VariableAccess.
Base ARObject
Aggregated by McDataInstance.mcDataAccessDetails
Attribute Type Mult. Kind Note
rteEvent RTEEvent * iref The RTE event used to receive the data via this buffer.
InstanceRef implemented by: RteEventInEcuInstance
Ref
variableAccess VariableAccess * iref The VariableAccess for which the data buffer is used.
InstanceRef implemented by: VariableAccessInEcu
InstanceRef
Table 9.12: McDataAccessDetails

[constr_10347] Existence of the instanceRef in the role McDataAccessDetails.

rteEvent dFor each McDataAccessDetails, the instanceRef in the role rteEvent
shall exist at least once at the time when the configuration of the BSW module is
finished.c()
[constr_10329] Existence of the instanceRef in the role McDataAccessDetails.
variableAccess dFor each McDataAccessDetails, the instanceRef in the role
variableAccess shall exist at least once at the time when the configuration of
the BSW module is finished.c()
[TPS_BSWMDT_04095] Relationships between McDataInstances dIn the case
that rapid prototyping is embedded in the RTE, several McDataInstances are needed
which have relationships to each other. For example, there could be a buffer holding
the “original” data, a buffer holding the “replacement” data coming from a prototype
implementation and a data instance holding the “switch” for switching between normal
and replacement functionality.
The meta-class RoleBasedMcDataAssignment offers the possibility to express the
relationships between such associated RTE data formally and use them as input to

195 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

configure external software. Note that the meta-model is rather generic at this point
in order to allow project specific use cases. Therefore the values of the attribute
RoleBasedMcDataAssignment.role are not standardized except one:
• The value mainInstance of this attribute shall be used to characterize the rela-
tion to that particular McDataInstance that represent the main instance of this
data buffer - i.e. the one that would be normally displayed in an MCD system.
c(RS_BSWMD_00065)
[TPS_BSWMDT_04096] Split between different use cases of McSupportData dIt
should be noted that the aggregation of McDataInstance by McSupportData is
splitable. This allows to keep the data description for MCD use cases and rapid
prototyping use cases in separate artifacts and also to generate them at a different
points in time.c(RS_BSWMD_00065)
In the case that rapid prototyping is embedded in the RTE, different kinds of Mc-
DataInstances are needed. To describe the kind of the memory to which the
McDataInstance relates, the attribute role is used. To describe the relationships
between different kinds of McDataInstances or other elements the RoleBasedM-
cDataAssignment.role attribute is used. Basically the role values can be defined
project specific but for the use case of rapid prototyping several role values and the
according semantic are standardized.
For the use case of rapid prototyping several role values and the according semantic
are standardized and described in [TPS_BSWMDT_04159].
[TPS_BSWMDT_04159] Standardized values of attribute RoleBasedMcDataAs-
signment.role d

Role Explanation
Specifies the relationship between a global buffer holding the data
RptGlobalMeasurement- value used by ECU SW and the memory location which used by the
Buffer MCD System to access the value for subsequent measurement
purposes before replacement by the RP generated value.
Specifies the relationship between a global buffer holding a inout
RptGlobalMeasurement- argument of a ClientServerOperation and the data value
BufferIn used by ECU SW and the memory location which used by the RP
tool or MCD System to access the originally IN value.
Specifies the relationship between a global buffer holding a inout
RptGlobalMeasure- argument of a ClientServerOperation and the data value
mentBufferOut used by ECU SW and the memory location which used by the RP
tool or MCD System to access the originally OUT value.
Specifies the relationship between a rapid prototyping global buffer
holding the data value written / read by the RP tool and the memory
RptGlobalBuffer
location which used by the RTE holding the value used for
communication from/to other software component instances.
5

196 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Specifies the relationship between a rapid prototyping global buffer
holding the data value for a inout argument of a
ClientServerOperation written / read by the RP tool for the IN
RptGlobalBufferIn
direction and the memory location which used by the RTE holding
the value used for communication from/to other software
component instances.
Specifies the relationship between a rapid prototyping global buffer
holding the data value for a inout argument of a
ClientServerOperation written / read by the RP tool for the
RptGlobalBufferOut
OUT direction and the memory location which used by the RTE
holding the value used for communication from/to other software
component instances.
Specifies the relationship to the memory location implementing a
RptRomEnablerFlag rapid prototyping enabler flag in ROM. This is used for run-time
enabling/disabling the bypass.
Specifies the relationship to the memory location implementing a
rapid prototyping enabler flag in ROM for the IN direction of an
RptRomEnablerFlagIn
inout argument of a ClientServerOperation. This is used
for runtime enabling/disabling the bypass.
Specifies the relationship to the memory location implementing a
rapid prototyping enabler flag in ROM for the OUT direction of an
RptRomEnablerFlagOut
inout argument of a ClientServerOperation. This is used
for runtime enabling/disabling the bypass.
Specifies the relationship to the memory location implementing a
RptRamEnablerFlag rapid prototyping enabler flag in RAM. This is used for run-time
enabling/disabling the bypass.
Specifies the relationship to the memory location implementing a
rapid prototyping enabler flag in RAM for the IN direction of an
RptRamEnablerFlagIn
inout argument of a ClientServerOperation. This is used
for runtime enabling/disabling the bypass.
Specifies the relationship to the memory location implementing a
rapid prototyping enabler flag in RAM for the OUT direction of an
RptRamEnablerFlagOut
inout argument of a ClientServerOperation. This is used
for runtime enabling/disabling the bypass.
Specifies the relationship to the memory location implementing a
RptRunnableDisabler-
rapid prototyping enabler flag controlling the execution of
Flag
ExecutableEntitys.
Specifies the relationship to the memory location implementing the
RptStimEnabler service point stimulation enabler flag. This is used for run-time
enabling/disabling the stimulation by the service point.
Specifies the relationship from a McDataInstance describing a
ImplicitBuffer implicit communication buffer to the McDataInstance describing a
global buffer.

c(RS_BSWMD_00065)

197 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

9.7 Rapid Prototyping support data

9.7.1 Rapid Prototyping support for software components or basic software

modules

The meta class RptSupportData provides the infrastructure to describe the imple-
mented Rapid Prototyping support in a software component or basic software mod-
ule(s). Thereby it is possible, that the Rapid Prototyping is locally implemented in a
software component or basic software module for the software entity itself or in case of
RTE that the Rapid Prototyping support is implemented on the demand of the Rapid-
PrototypingScenario for the integration of the respective software components or
basic software modules.
Class RptSupportData
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Root element for rapid prototyping support data related to one Implementation artifact on an ECU, in
particular the RTE. The rapid prototyping support data may reference to elements provided for Mc
SupportData.
Base ARObject
Aggregated by McSupportData.rptSupportData
Attribute Type Mult. Kind Note
execution RptExecutionContext * aggr Defines an environment for the execution of Executable
Context Entites.
rptComponent RptComponent * aggr Description of components for which rapid prototyping
support is implemented.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptComponent.shortName, rpt
Component.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
rptServicePoint RptServicePoint * aggr This aggregation represents the collection of service
points associated with the enclosing RptSuportData
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptServicePoint.shortName, rptService
Point.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 9.13: RptSupportData

[constr_10349] Existence of attribute RptSupportData.executionContext dFor

each RptSupportData, the attribute executionContext shall exist at least once at
the time when the configuration of the BSW module is finished.c()
[constr_10350] Existence of attribute RptSupportData.rptComponent dFor each
RptSupportData, the attribute rptComponent shall exist at least once at the time
when the configuration of the BSW module is finished.c()
[constr_10351] Existence of attribute RptSupportData.rptServicePoint dFor
each RptSupportData, the attribute rptServicePoint shall exist at least once at
the time when the configuration of the BSW module is finished.c()

198 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RptSwPrototypingAccess
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Describes the accessibility of data and modes by the rapid prototyping tooling.
Base ARObject
Aggregated by McDataInstance.resultingRptSwPrototypingAccess, RptContainer.rptSwPrototypingAccess
Attribute Type Mult. Kind Note
rptHookAccess RptAccessEnum 0..1 attr The related data element can be modified using a
post-build hooking tool. An ENABLED VariableData
Prototype is implicitly READABLE/WRITABLE.
rptReadAccess RptAccessEnum 0..1 attr The related data element can be used as input for bypass
functionality by RP tool. If rptImplPolicy is not specified
then RTE generation shall ensure at least suitable MC
read points are created.
rptWriteAccess RptAccessEnum 0..1 attr The related data element can be used as output for
bypass functionality by RP tool. The data element shall
be prepared to rptLevel2 and related write service points
are present.

Table 9.14: RptSwPrototypingAccess

Class RptComponent
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Description of component instance for which rapid prototyping support is implemented.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by RptSupportData.rptComponent
Attribute Type Mult. Kind Note
mcData RoleBasedMcData * aggr Reference to related McDataElement describing the
Assignment Assignment implementation of "RP global buffer", "RP global
measurement buffer", "RP enabler flag" and the "RP
runnable disabler flag".
rpImplPolicy RptImplPolicy 0..1 aggr Describes the implemented code preparation for rapid
prototyping at data accesses.
rptExecutable RptExecutableEntity * aggr ExecutableEntity instance which can be bypassed.
Entity
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptExecutableEntity.shortName, rpt
ExecutableEntity.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 9.15: RptComponent

[constr_10352] Existence of attribute RptComponent.rptExecutableEntity

dFor each RptComponent, the attribute rptExecutableEntity shall exist at least
once at the time when the configuration of the BSW module is finished.c()
[TPS_BSWMDT_04160] RptComponent represents a software component or ba-
sic software module dRptComponent describes a software component or basic soft-
ware module (e.g. a CDD) for which rapid prototyping support is implemented.c(RS_-
BSWMD_00065)

199 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Identifiable
RptExecutableEntity
  
   
+ symbol: CIdentifier [0..1]  

«atpVariation,atpSplitable»

+rptExecutableEntityEvent 0..*

Identifiable
RoleBasedMcDataAssignment
RptExecutableEntityEvent +mcDataAssignment
+ role: Identifier [0..1]
+ rptEventId: PositiveInteger [0..1] 0..*

+rptServicePointPre 0..* +rptServicePointPost 0..* +mcDataInstance 0..*

Identifiable Identifiable
RptServicePoint McDataInstance

+ serviceId: PositiveInteger [0..1] + arraySize: PositiveInteger [0..1]

+ symbol: CIdentifier [0..1] + displayIdentifier: McdIdentifier [0..1]
+ role: Identifier [0..1]
«atpSplitable»
+ symbol: SymbolString [0..1]

Figure 9.8: Meta-model for the usage of RptServicePoint

[TPS_BSWMDT_04161] RptExecutableEntity represents a ExecutableEn-

tity with rapid prototyping support dThe RptExecutableEntity describes
a ExecutableEntity for which rapid prototyping support is implemented.c(RS_-
BSWMD_00065)
Class RptExecutableEntity
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note This describes a ExecutableEntity instance which can be bypassed.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by RptComponent.rptExecutableEntity
Attribute Type Mult. Kind Note
rptExecutable RptExecutableEntity * aggr ExecutableEntity event instance activation the owning Rpt
EntityEvent Event ExecutableEntity.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptExecutableEntityEvent.shortName, rpt
ExecutableEntityEvent.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
rptRead RoleBasedMcData * aggr read access to a variable
Assignment
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptRead, rptRead.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
rptWrite RoleBasedMcData * aggr write access to a variable
Assignment
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptWrite, rptWrite.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
symbol CIdentifier 0..1 attr The symbol describing this ExecutableEntity’s entry point.

Table 9.16: RptExecutableEntity

200 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10353] Existence of attribute RptExecutableEntity.rptExe-

cutableEntityEvent dFor each RptExecutableEntity, the attribute rp-
tExecutableEntityEvent shall exist at least once at the time when the
configuration of the BSW module is finished.c()
[constr_10354] Existence of attribute RptExecutableEntity.symbol dFor each
RptExecutableEntity, the attribute symbol shall exist at the time when the con-
figuration of the BSW module is finished.c()
[TPS_BSWMDT_04162] RptExecutableEntityEvent represents a RTEEvent or
BswEvent for with rapid prototyping support dThe RptExecutableEntityEvent
describes a instance of a RTEEvent or BswEvent for which rapid prototyping support
is implemented. This means typically that Service Function calls before and after the
call of the ExecutableEntity implementing the activation by the RTEEvent or Bsw-
Event.c(RS_BSWMD_00065)
Class RptExecutableEntityEvent
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note This describes an ExecutableEntity event instance which can be bypassed.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by RptExecutableEntity.rptExecutableEntityEvent
Attribute Type Mult. Kind Note
execution RptExecutionContext * ref This describes the context in which the event of the
Context executable entity is executed.
mcData RoleBasedMcData * aggr Reference to related McDataElements describing the
Assignment Assignment implementation of "RP runnable disabler flag" and
"stimulation enabler flag"
The possible roles of the RoleBasedMcData
Assignment.role attribute are:
• RpRunnableDisablerFlag"
rptEventId PositiveInteger 0..1 attr RPT event id used for service points call.
rptExecutable RptExecutableEntity 0..1 aggr Describes the implemented code preparation for rapid
EntityProperties Properties prototyping at ExecutableEntity invocation.
rptImplPolicy RptImplPolicy 0..1 aggr Describes the RptImplPolicy of a RptExecutableEvent for
service based bypassing.
rptServicePoint RptServicePoint * ref This describes the applicable Post Service Points for a
Post RTEEvent / BswEvent of a bypassed ExecutableEntity.
rptServicePoint RptServicePoint * ref This describes the applicable Pre Service Points for a
Pre RTEEvent / BswEvent of a bypassed ExecutableEntity.

Table 9.17: RptExecutableEntityEvent

[constr_10355] Existence of the reference in the role RptExecutableEnti-

tyEvent.executionContext dFor each RptExecutableEntityEvent, the ref-
erence in the role executionContext shall exist at least once at the time when the
configuration of the BSW module is finished.c()
[constr_10356] Existence of attribute RptExecutableEntityEvent.rptEven-
tId dFor each RptExecutableEntityEvent, the attribute rptEventId shall exist
at the time when the configuration of the BSW module is finished.c()

201 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10357] Existence of attribute RptExecutableEntityEvent.rptExe-

cutableEntityProperties dFor each RptExecutableEntityEvent, the at-
tribute rptExecutableEntityProperties shall exist at the time when the con-
figuration of the BSW module is finished.c()
[constr_10358] Existence of the reference in the role RptExecutableEnti-
tyEvent.rptServicePointPost dFor each RptExecutableEntityEvent, the
reference in the role rptServicePointPost shall exist at least once at the time
when the configuration of the BSW module is finished.c()
[constr_10359] Existence of the reference in the role RptExecutableEnti-
tyEvent.rptServicePointPre dFor each RptExecutableEntityEvent, the
reference in the role rptServicePointPre shall exist at least once at the time when
the configuration of the BSW module is finished.c()
Class RptImplPolicy
Package M2::AUTOSARTemplates::SWComponentTemplate::RPTScenario
Note Describes the code preparation for rapid prototyping at data accesses.
Base ARObject
Aggregated by McDataInstance.rptImplPolicy, RptComponent.rpImplPolicy, RptContainer.rptImplPolicy, RptExecutable
EntityEvent.rptImplPolicy
Attribute Type Mult. Kind Note
rptEnablerImpl RptEnablerImplType 0..1 attr For Level 2 or Level3 this property determines how the
Type Enum RTE implements the additional "RP enabler" flag.
rptPreparation RptPreparationEnum 0..1 attr Mandates RP preparation level for access to VariableData
Level Prototype within generated RTE implementation.

Table 9.18: RptImplPolicy

Enumeration RptEnablerImplTypeEnum
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Describes the required / implemented usage of enabler flags for data access in the code.
Aggregated by RptImplPolicy.rptEnablerImplType, RptProfile.stimEnabler
Literal Description
none No "RP enabler" is implemented.
Tags: atp.EnumerationLiteralIndex=0
rptEnablerRam "RP enabler" is implemented as a RAM variable
Tags: atp.EnumerationLiteralIndex=1
rptEnablerRamAnd The RTE generator implements both the RAM and ROM "RP enabler".
Rom
Tags: atp.EnumerationLiteralIndex=3
rptEnablerRom "RP enabler" is implemented as a calibrateable ROM variable.
Tags: atp.EnumerationLiteralIndex=2

Table 9.19: RptEnablerImplTypeEnum

202 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration RptPreparationEnum
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Determines the RP preparation level for access to VariableDataPrototypes within the generated RTE
implementation.
Aggregated by RptImplPolicy.rptPreparationLevel
Literal Description
none No RP preparation for VariableDataPrototype.
Tags: atp.EnumerationLiteralIndex=0
rptLevel1 The RTE implementation uses an "RP global buffer" for measurement and post-build hooking
purposes.
Tags: atp.EnumerationLiteralIndex=1
rptLevel2 As rpLevel1 but the RTE implementation also uses both "RP enabler flag" to permit RP overwrite at
run-time.
Tags: atp.EnumerationLiteralIndex=2
rptLevel3 As rpLevel2 but the RTE implementation also uses "RP global measurement buffer" to record the
original ECU-generated value in addition to the RP value.
Tags: atp.EnumerationLiteralIndex=3

Table 9.20: RptPreparationEnum

Class RptExecutableEntityProperties
Package M2::AUTOSARTemplates::SWComponentTemplate::RPTScenario
Note Describes the code preparation for rapid prototyping at ExecutableEntity invocation.
Base ARObject
Aggregated by RptContainer.rptExecutableEntityProperties, RptExecutableEntityEvent.rptExecutableEntityProperties
Attribute Type Mult. Kind Note
maxRptEventId PositiveInteger 0..1 attr Highest RPT event id usable for RTE generated service
points. This attribute is relevant, if dedicated id range
shall be applied to the ExecutableEntitys of a software
component or specific ExecutableEntitys.
minRptEventId PositiveInteger 0..1 attr Lowest RPT event id usable for RTE generated service
points. This attribute is relevant, if dedicated id range
shall be applied to the ExecutableEntitys of a software
component or specific ExecutableEntitys.
rptExecution RptExecutionControl 0..1 attr This attribute specifies the rapid prototyping control of the
Control Enum executable
rptServicePoint RptServicePointEnum 0..1 attr Enables generation of service points by the RTE
generator.

Table 9.21: RptExecutableEntityProperties

Enumeration RptExecutionControlEnum
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Determines rapid prototyping preparation of an ExecutableEntity.
Aggregated by RptExecutableEntityProperties.rptExecutionControl
Literal Description
conditional The ExecutableEntity is only executed when the rapid prototyping disable flag is NOT set.
Tags: atp.EnumerationLiteralIndex=0
none The ExecutableEntity is executed without specific rapid prototyping condition.
Tags: atp.EnumerationLiteralIndex=1

Table 9.22: RptExecutionControlEnum

203 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration RptServicePointEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::RPTScenario
Note Specifies whether the invocation of ExecutableEntitys due to activation of specific RteEvents/Bsw
Events requires the insertion of Service Points.
Aggregated by RptExecutableEntityProperties.rptServicePoint
Literal Description
enabled Enables generation of service points by the RTE generator.
Tags: atp.EnumerationLiteralIndex=0
none No Service Points are requested.
Tags: atp.EnumerationLiteralIndex=1

Table 9.23: RptServicePointEnum

9.7.2 Differentiation of execution contexts

McSupportData

«atpVariation,atpSplitable»
«atpSplitable»

  
   
 +mcVariableInstance 0..* +rptSupportData 0..1

Identifiable
RptSupportData
McDataInstance
«atpVariation,atpSplitable» + arraySize: PositiveInteger [0..1]
+ displayIdentifier: McdIdentifier [0..1]
+ role: Identifier [0..1]
«atpSplitable»
+subElement + symbol: SymbolString [0..1]
0..* {ordered}
+mcDataInstance 0..*

+mcDataAssignment 0..* +executionContext 0..*

Identifiable
RoleBasedMcDataAssignment +executionContext
RptExecutionContext

   + role: Identifier [0..1] 0..*
   
 

+executionContext 0..*

+mcDataAssignment 0..*

Identifiable
RptExecutableEntityEvent

+ rptEventId: PositiveInteger [0..1]

Figure 9.9: Meta-model for RptExecutionContext

[TPS_BSWMDT_04163] RptExecutionContext represents a common environ-

ment for a set of RptExecutableEntitys or McDataInstances dThe RptExe-
cutionContext represents a common environment for a set of RptExecutableEn-
titys or McDataInstances. This common environment is qualified by the identical
OSTask context and a identical set of implicit communication buffers.c(RS_BSWMD_-
00065)

204 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RptExecutionContext
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Defines an environment for the execution of ExecutableEntites which is qualified by
• OSTask
• communication buffer usage
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by RptSupportData.executionContext
Attribute Type Mult. Kind Note
– – – – –
Table 9.24: RptExecutionContext

With the means of RptExecutionContexts its possible to denote the temporary

validity of McDataInstances describing implicit communication buffers. This is im-
portant if the identical implicit communication buffer is reused during a sequence of
RunnableEntitys. In this case the McDataInstances describing implicit commu-
nication buffers holds the value of different global buffers at different point of times. For
example the same OSTask can be split into several sub-sequences where the usage
of the implicit communication buffers changes between the sub-sequences. This is the
case when the content of the implicit buffer (previously used by a RunnableEntity is
written back to the global buffer and after wards fill by the value of an other global buffer
in order to be used by a successor RunnableEntity. Please note that the validity of
RptExecutionContexts can even overlap (with respect to execution time) since not
necessarily the whole implicit communication buffers set used for sub-sequence in a
OSTask changes at such a point.
[TPS_BSWMDT_04164] Description of implicit communication buffers dThe Mc-
DataInstance describing a implicit communication buffers shall reference the Mc-
DataInstance describing the global buffer with a RoleBasedMcDataAssignment
where the role attribute is set to ImplicitBuffer.c(RS_BSWMD_00065)
Enumeration RptAccessEnum
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Determines the access rights to a data object with respect to rapid prototyping.
Aggregated by RptSwPrototypingAccess.rptHookAccess, RptSwPrototypingAccess.rptReadAccess, RptSw
PrototypingAccess.rptWriteAccess
Literal Description
enabled The related data element is accessible by RP tool.
Tags: atp.EnumerationLiteralIndex=0
none The related data element is not accessible by RP tool.
Tags: atp.EnumerationLiteralIndex=1
protected The data element is known to the RP tool however its usage for RP can be restricted. Use case:
limitation based on access rights
Tags: atp.EnumerationLiteralIndex=2

Table 9.25: RptAccessEnum

205 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RptServicePoint
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport::RptSupport
Note Description of a Service Point implemented for rapid prototyping.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by RptSupportData.rptServicePoint
Attribute Type Mult. Kind Note
serviceId PositiveInteger 0..1 attr Unique ID (Range: 0 ... 65535) representing the service
point.
symbol CIdentifier 0..1 attr Complete symbol of the function implementing the
service point. This symbol is used for post-build hooking
purposes.

Table 9.26: RptServicePoint

[constr_10360] Existence of attribute RptServicePoint.serviceId dFor each

RptServicePoint, the attribute serviceId shall exist at the time when the con-
figuration of the BSW module is finished.c()
[constr_10330] Existence of attribute RptServicePoint.symbol dFor each Rpt-
ServicePoint, the attribute symbol shall exist at the time when the configuration
of the BSW module is finished.c()
The following examples illustrate the usage of the McDataInstances and
the RoleBasedMcDataAssignments with the role attribute values according
[TPS_BSWMDT_04159] to describe the different locations in memory with their re-
lationships and specific meaning for an rapid prototyping tooling.

globalDataA:    

Comp2_Run1:
McDataInstance


RptExecutableEntity      
    
+mcDataInstance

:RoleBasedMcDataAssignment

role = RpGlobalBuffer

+mcDataAssignment
+rptExecutableEntityEvent

Comp2_Run1_Ev1: Comp2_Bypass_pA_dA:
RptExecutableEntityEvent McDataInstance
    
    

+mcDataInstance +mcDataInstance
+executionContext

ContextTaskA:
RptExecutionContext +executionContext :RoleBasedMcDataAssignment :RoleBasedMcDataAssignment

role = ImplicitBuffer role = RpGlobalMeasurementBuffer

+mcDataAssignment +mcDataAssignment

   

       Rte_Buf_TaskA_DataA:
   pA_dA_Original:
McDataInstance
     McDataInstance
 
 

        

    

Figure 9.10: Example about Level3 RPT support implementation

206 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Figure 9.10 shows the description of the rapid prototyping support created for the
RunnableEntity "‘Comp2_Run1"’ which had original a dataReadAccess and a
dataWriteAccess to dataElement "‘dA"’ in PRPortPrototype "‘pA"’. The re-
quested rapid prototype support was rptLevel3. For the communication of the
data value to other components the RTE implements the variable "‘globalDataA"’
and describes it as McDataInstance. Typically this is also the normal buffer used
for measurement. The RunnableEntity is described by RptExecutableEntity
Comp2_Run1 and this references the McDataInstance "‘globalDataA"’ in the roles
rptRead and rptWrite to document the dataReadAccess and dataWriteAc-
cess of the original RunnableEntity.
The access for the rapid prototype tooling is provided by the RP global buffer "‘
Comp2_Bypass_pA_dA"’ which his as well described as McDataInstance referenc-
ing the McDataInstance "‘globalDataA"’ with the RoleBasedMcDataAssign-
ment.role = RptGlobalBuffer.
In this example the RTE uses distinct implicit communication buffers and the accord-
ing buffer is described as well by an McDataInstance "‘Rte_Buf_TaskA_DataA"’
with the RoleBasedMcDataAssignment.role = ImplicitBuffer to indicate that
this buffer the RP global buffer. For the rptLevel3 support it’s required that
the RTE provides an additional location in memory, where the original value pro-
duced by the RunnableEntity can be accessed. This RP global measure-
ment buffer is described by a McDataInstance pA_dA_Original and linked by
RoleBasedMcDataAssignment.role = RpGlobalMeasurementBuffer to the RP
global buffer.

207 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

:McSupportData

+mcVariableInstance +mcVariableInstance +mcParameterInstance

Comp2_Run1_Ev1_Disabler: Comp2_Bypass_pA_dA_EnableRam: Comp2_Bypass_pA_dA_EnableRom:

McDataInstance McDataInstance McDataInstance

+mcDataInstance +mcDataInstance +mcDataInstance

  
  
  

     

:RoleBasedMcDataAssignment :RoleBasedMcDataAssignment :RoleBasedMcDataAssignment

role = RpRunnableDisablerFlag role = RpRamEnablerFlag role = RpRomEnablerFlag

+mcVariableInstance
+mcDataAssignment +mcDataAssignment
+mcDataAssignment

Comp2_Bypass_pA_dA: McDataInstance

Comp2_Run1_Ev1:
    

RptExecutableEntityEvent
    

+rptExecutableEntityEvent

Comp2_Run1: RptExecutableEntity

Figure 9.11: Example about Level3 enabler

Figure 9.11 shows the according enabler flags required for the rptLevel3 rapid
prototyping support. Thereby the the McDataInstance describing the RP global
buffer is referencing the

208 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

+rptWrite
Comp2_Run1: globalDataA:
RptExecutableEntity +rptRead McDataInstance

+mcDataInstance

+rptExecutableEntityEvent

Comp2_Run1_Ev1:      
RptExecutableEntityEvent  
    
   

+executionContext

ContextTaskA: +executionContext :RoleBasedMcDataAssignment

RptExecutionContext
role = RpGlobalBuffer

+mcDataAssignment

  Comp2_Bypass_pA_dA_TaskA:

     McDataInstance
      
+mcDataInstance

:RoleBasedMcDataAssignment

role = RpGlobalMeasurementBuffer

+mcDataAssignment

   pA_dA_Original:

        McDataInstance

Figure 9.12: Example about optimized RPT support implementation

209 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

+rptSupportData
:McSupportData :RptSupportData

Comp2:
+mcParameterInstance Comp2_Bypass_pA_dA_EnableRom: +mcDataInstance +mcDataAssignment
RptComponent
:RoleBasedMcDataAssignment
McDataInstance
role = RptRomEnablerFlag

+mcVariableInstance Comp2_Bypass_pA_dA_EnableRam: +mcDataInstance :McDataInstance +mcDataAssignment

McDataInstance
role = RptRamEnablerFlag

+mcVariableInstance Comp2_Run1_Ev1_Disabler: +mcDataInstance :RoleBasedMcDataAssignment +mcDataAssignment

McDataInstance
role = RptRunnableDisablerFlag

+mcVariableInstance Comp2_Bypass_pA_dA: +mcDataInstance :RoleBasedMcDataAssignment +mcDataAssignment

McDataInstance
+mcDataInstance role = RptGlobalBuffer

+mcVariableInstance Rte_Buf_TaskA_DataA: +mcDataAssignment :RoleBasedMcDataAssignment

McDataInstance
role = ImplicitBuffer

+mcVariableInstance pA_dA_Original: +mcDataInstance :RoleBasedMcDataAssignment +mcDataAssignment

McDataInstance
role = RptGlobalMeasurementBuffer

+rptExecutableEntity
globalDataA: +mcDataInstance :RoleBasedMcDataAssignment +rptWrite
McDataInstance Comp2_Run1:
+mcVariableInstance RptExecutableEntity

+mcDataInstance +rptRead
:RoleBasedMcDataAssignment

+rptExecutableEntityEvent

Comp2_Run1_Ev1:
RptExecutableEntityEvent

Figure 9.13: Example about RptComponent usage

210 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

10 BSW Variant Handling

The BSWMDT includes variation points which allow to describe a set of variants of
a BSW module or cluster by a single XML artifact (for general information on variant
handling in AUTOSAR see [1]).
Variation points are provided at all three levels of the template.

10.1 BSW Interface Variation Points

[TPS_BSWMDT_04063] BSW Interface Variation Points dThe variation points in the
scope of BswModuleDescription with latestBindingTime = preCompileTime
allow to declare variable sets of optional documentation, communication interfaces,
dependencies, triggers and mode groups as part of one BSW module description.
Further variation points in this hierarchy with can be bound at compile-time are not
allowed in order to keep the meta-model and the resulting M1 models maintainable.c
(RS_BSWMD_00049) For detail refer to figures 10.1 and 10.2.
If for example one wants to specify two variants of a module which handles a cer-
tain C-function argument either as a 16 bit or as a 32 bit type respectively and this
needs to be bound at compile-time, this is possible by variation of the associations to
BswModuleEntry, but is is not possible to declare a single BswModuleEntry with
two compile-time variants just for a single argument.
However, at an earlier stage of development it is possible to include this kind of addi-
tional variability into Blueprints of BswModuleEntry-s (see [9]). This is especially
useful if a BSWMD is used to represent an SWS of the AUTOSAR standard, since
interfaces are specified here on the level of Blueprints, i.e. they still contain optional
or alternative function arguments:
[TPS_BSWMDT_04090] Variation Points for BswModuleEntry arguments dIt is
possible to declare a BswModuleEntry.argument as a variation point but its binding
time shall not be later than blueprintDerivationTime.c(RS_BSWMD_00049) See
figure 10.1.

211 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

  
Identifiable
      
SwComponentDocumentation      SwServiceArg

+ direction:
ArgumentDirectionEnum [0..1]
A
0..* {ordered} 0..1
0..1
!"   +argument
      +returnType
+bswModuleDocumentation
    

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

ARElement ARElement
AtpBlueprint AtpBlueprint
AtpBlueprintable +implementedEntry AtpBlueprintable
AtpStructureElement «atpVariation,atpSplitable» BswModuleEntry
0..*
BswModuleDescription

+ moduleId: PositiveInteger [0..1] +expectedEntry

«atpVariation,atpSplitable» 0..*

+bswModuleDependency Identifiable
«atpVariation,atpSplitable» 0..* BswModuleDependency

+ targetModuleId: PositiveInteger [0..1]

+targetModuleRef

0..1 «atpUriDef,atpVariation,atpSplitable»

+providedModeGroup AtpPrototype

«atpVariation,atpSplitable» ModeDeclarationGroupPrototype
0..*
+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]
+requiredModeGroup

«atpVariation,atpSplitable» 0..*

+releasedTrigger
AtpStructureElement
0..* Identifiable
«atpVariation,atpSplitable»
Trigger
+requiredTrigger + swImplPolicy: SwImplPolicyEnum [0..1]
0..*
«atpVariation,atpSplitable»

Figure 10.1: Variation points under BswModuleDescription, Part 1

212 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

  
   
 
    

ARElement
AtpBlueprint
AtpBlueprintable
AtpStructureElement
BswModuleDescription
+providedClientServerEntry Referrable
+ moduleId: PositiveInteger [0..1] BswModuleClientServerEntry
«atpVariation,atpSplitable» 0..*
+ isReentrant: Boolean [0..1]
+ isSynchronous: Boolean [0..1]
+requiredClientServerEntry

«atpVariation,atpSplitable» 0..*

+providedData AutosarDataPrototype
«atpVariation,atpSplitable» 0..* VariableDataPrototype

+requiredData
0..*
«atpVariation,atpSplitable»

Figure 10.2: Variation points under BswModuleDescription, Part 2

One use case is to maintain a specification which includes optional or alternative inter-
faces/dependencies for a module at design time. For example, as already mentioned
above, it is possible to provide one BSWMD (as an XML artifact) which describes the
AUTOSAR standard for the C-interfaces of a standardized AUTOSAR module includ-
ing specification of the optional parts as variants. These variants will be selected in the
BSWMD of a module which is actually implemented against such a specification.
Another use case is to deliver a BSWMD still including some variation points to the
integrator, which means in this case the variants will be selected by the integrator.
Since most of the variation points described in this section influence the executable
code, this use case requires that the relevant parts of the code are regenerated and/or
recompiled at integration time. Due to this reason, the latest possible binding time of
most variation points described here is set to to preCompileTime.
The second use case may require that the actual selection of a variation points will
constraint the ECU configuration parameter values of the module (for example, if a
configuration parameter configures the existence/non-existence of a callback function
this will be constrained by deselecting a variant of the attributes expectedEntry or
implementedEntry. This could simply be done by delivering sets of preconfigured
parameter values which obey to the same variant conditions as the corresponding el-
ements referred/aggregated by BswModuleDescription. However, a more elegant
solution will be to derive the parameter definition in question "automatically" (.e. via
its definition) from the condition which is implicitly defined in the M1 model with each
variant selection (see [1]).

213 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

10.2 BSW Behavior Variation Points

[TPS_BSWMDT_04064] BSW Behavior Variation Points dIn a similar way, variation
points underneath BswInternalBehavior allow to declare variants in the aggrega-
tion of BswModuleEntity-s, BswEvents and further elements.
Likewise, several references and aggregations owned by BswModuleEntity are vari-
ation points. There is Variation point in the aggregation of local data for calibration and
measurement and of ExclusiveArea by the base class InternalBehavior too .c
(RS_BSWMD_00049) For more details on Variation Points see figure 10.4 and figure
10.3.
The use cases are similar to the ones described above (chapter 10.1). For the same
reasons, the latest possible binding time for these variation points is defined as pre-
CompileTime.

214 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

AtpStructureElement +exclusiveArea Identifiable

InternalBehavior ExclusiveArea
«atpVariation,atpSplitable» 0..*

+exclusiveAreaNestingOrder Referrable
ExclusiveAreaNestingOrder
«atpVariation,atpSplitable» 0..*

+staticMemory AutosarDataPrototype
VariableDataPrototype
«atpVariation,atpSplitable» 0..*

+constantMemory AutosarDataPrototype
ParameterDataPrototype
«atpVariation,atpSplitable» 0..*

+perInstanceParameter 0..*

«atpVariation,atpSplitable»

  
     
BswInternalBehavior
ExecutableEntity
+entity BswModuleEntity
«atpVariation,atpSplitable»
0..*

+startsOnEvent 0..1

Identifiable
+internalTriggeringPoint
BswInternalTriggeringPoint
«atpVariation,atpSplitable» 0..*

AbstractEvent
+event
BswEvent
«atpVariation,atpSplitable» 0..*

+triggerDirectImplementation BswTriggerDirectImplementation

«atpVariation,atpSplitable» 0..*

+modeSenderPolicy BswModeSenderPolicy

«atpVariation,atpSplitable» 0..*

+modeReceiverPolicy
BswModeReceiverPolicy
«atpVariation,atpSplitable» 0..*

+receptionPolicy BswApiOptions
BswDataReceptionPolicy
«atpVariation,atpSplitable» 0..*

Referrable
+distinguishedPartition
BswDistinguishedPartition
«atpVariation,atpSplitable» 0..*

+serviceDependency ServiceDependency
BswServiceDependency
«atpVariation,atpSplitable» 0..*

ImplementationProps
+schedulerNamePrefix BswSchedulerNamePrefix

«atpVariation,atpSplitable»0..*

Figure 10.3: Variation points under BswInternalBehavior

215 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ExecutableEntity ARElement
BswModuleEntity AtpBlueprint
AtpBlueprintable
BswModuleEntry

+callPoint Referrable
«atpVariation,atpSplitable» BswModuleCallPoint
0..*

+issuedTrigger AtpStructureElement
«atpVariation,atpSplitable» Identifiable
0..*
Trigger

+activationPoint Identifiable
0..* BswInternalTriggeringPoint
«atpVariation,atpSplitable»

+managedModeGroup AtpPrototype
ModeDeclarationGroupPrototype
«atpVariation,atpSplitable» 0..*

+accessedModeGroup
«atpVariation,atpSplitable» 0..*

+dataSendPoint Referrable

«atpVariation,atpSplitable» BswVariableAccess
0..*

+dataReceivePoint
«atpVariation,atpSplitable»
0..*

  
     

Figure 10.4: Variation points under BswModuleEntity

10.3 BSW Implementation Variation Points

[TPS_BSWMDT_04065] BSW Implementation Variation Points dThere are several
variation points in the base class Implementation and the elements aggregated
from there. They are usable for BSW and SWC descriptions as well. They all support
the use case, that a module or component is delivered as source code leading to
several implementation variants.
Furthermore, if an Implementation contains McSupportData, these can also have
variation points.c(RS_BSWMD_00049)
Variation points in the base class Implementation and the elements aggregated
from there are visible in the respective figures of chapter 7. Figure 10.5 shows the only
variation point below BswImplementation.
Chapter 9.1 gives an explanation for implementation containing McSupportData.

216 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

The associations to vendorSpecificModuleDef and preconfiguredConfigu-

ration are not considered as variation points, since they correspond to artifacts which
are supposed to be fixed at the time a module is delivered. Also recommendedCon-
figuration corresponds to a fixed set of artifacts at delivery time.
Implementation
BswImplementation

+ arReleaseVersion: RevisionLabelString [0..1]

+ vendorApiInfix: Identifier [0..1]

«atpUriDef»
+refinedModuleDef 0..1

ARElement
AtpBlueprint
+vendorSpecificModuleDef AtpBlueprintable
0..* EcucDefinitionElement
EcucModuleDef

+definition 0..1

+moduleDescription ARElement
EcucModuleConfigurationValues
0..1
+ ecucDefEdition: RevisionLabelString [0..1]
+preconfiguredConfiguration + implementationConfigVariant: EcucConfigurationVariantEnum [0..1]
+ postBuildVariantUsed: Boolean [0..1]
0..*

+recommendedConfiguration

0..*

Figure 10.5: Variation points under BswImplementation

217 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

11 Implementation Conformance Statement

11.1 Background
This chapter describes, which elements of the BSWMDT have to be used to specify
the delivery of a BSW module for the purpose of an AUTOSAR conformance test.
The use case assumed in this chapter is as follows:
• The test is done for an ICC3 module.
• The code to be tested is delivered as fully configured object code. Note that this
could be more than one file, e.g. core code + separately compiled configuration
data.
• The tester has no means to change the configuration. This implies that, if
AUTOSAR has specified tests for several different sets of configuration values,
corresponding sets of object code files shall be delivered.
• In addition to the object code, header files and ARXML-descriptions are delivered
as far as needed to declare the conformity and to set up the test.
Especially, the BSWMD (and the attached configuration parameter definitions and con-
figuration values) shall contain the Implementation Conformance Statement (ICS). The
purpose of the ICS is to declare the extent to which the module covers the relevant
AUTOSAR specification. See also [5] for the overall definition of the ICS.
The ARXML model elements that form an Implementation Conformance Statement
shall be aggregated under a ARPackage with the category ICS. It is not required (but
possible) that sub-packages below this package also have the category ICS, but they
may not have the category BLUEPRINT. See [1] for formal constraints on the package
categories.
Note that in the current AUTOSAR release, the standardized specification elements
(i.e. the content of an SWS) for an ICC3 module are published by AUTOASAR not in
the format of ARXML, but as pdf-Document. Therefore, the mechanism how to trace
between a given BSWMD and the corresponding SWS is currently not standardized.

11.2 Interface Level

[TPS_BSWMDT_04066] Relevant elements for ICS on Interface level dOn the In-
terface level of the BSWMDT, the following elements are relevant for the Conformance
Test:
• BswModuleDescription.moduleId
This identifies the ICC3 module and its specification.

218 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• BswModuleDescription.implementedEntry
BswModuleDescription.expectedEntry
These elements are required to describe the name and signature of standard-
ized provided functions resp. outgoing callbacks which are actually present in the
tested code (mandatory as well as optional ones). Vendor specific functions/call-
backs shall not be included.
Note: If the names of callbacks are configurable, the respective configuration
values shall also be delivered.
• BswModuleDescription.bswModuleDependency.targetModuleId
These elements are required as far as they describe the dependency on stan-
dardized elements of other standardized ICC3 modules (identified by the tar-
getModuleId).
Note: Conformance test cases on standardized functions shall be executable
without any dependency on non-standardized functions/modules. Therefore the
test setup shall be possible by knowing only the dependencies of the module on
other standardized elements.
• BswModuleEntry.shortName
BswModuleEntry. - all attributes of this meta-class
BswModuleEntry.argument.swDataDefProps
BswModuleEntry.returnType.swDataDefProps
Here, BswModuleEntry stands for the root element for a function signature re-
ferred by the function declarations - e.g. implementedEntry - listed above. The
major amount of the aggregated or referred elements below SwDataDefProps
are not required for the ICS. Only those parts of SwDataDefProps are needed,
which uniquely specify the C data type of the arguments and the returnType.
Please refer to chapter “Implementation Data Type” of [6] for example how to
describe C data types in this way.
c(RS_BSWMD_00039, RS_BSWMD_00040, RS_BSWMD_00041, RS_BSWMD_-
00042)
The rest of the elements on the Interface level of the BSWMDT are not relevant for the
conformance test. They are listed here for completeness:
• BswModuleDescription.providedModeGroup
BswModuleDescription.requiredModeGroup
BswModuleDescription.releasedTrigger
BswModuleDescription.requiredTrigger
These elements are used to support the delegation of mode switching or trigger-
ing to the BSW Scheduler. These mechanisms are currently not referred by any
standardized ICC3 specification; they are mainly targeted at Complex Drivers or
IO HW Abstraction. Therefore is its currently not required to use these elements
within the ICS.

219 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

11.3 Internal Behavior Level

[TPS_BSWMDT_04067] No relevant elements for ICS on Internal Behavior level
dOn the Internal Behavior level of the BSWMDT, there are no elements relevant for the
conformance testc(RS_BSWMD_00030) as the following overview shows:
• BswInternalBehavior.entity
BswInternalBehavior.event
BswInternalBehavior.internalTriggeringPoint
BswInternalBehavior.triggerDirectImplementation
BswInternalBehavior.modeSenderPolicy
The main use case of these elements is to provide input for configuring the Basic
Software Scheduler (part of the RTE). In addition, they provide information for
timing or call-chain analysis. These elements are neither relevant for the ICS nor
otherwise needed for the conformance test, since the conformance test does not
need this information to call single C-functions.
• BswInternalBehavior.constantMemory
BswInternalBehavior.staticMemory
These elements are used to declare data that are local to the module, main use
case is for measurement and calibration and for data needed to set up the con-
figuration of the NVRAM Manager. They need not to be declared for the confor-
mance test.
• BswInternalBehavior.serviceDependency
This element (and further elements aggregated by it) are used to declare require-
ments on the configuration of other standardized service modules like NVRAM
Manager or DEM. It is not considered as relevant for the conformance test, since
the conformance test environment does not have to simulate the behavior of
these service modules in such detail, that is needs to be configured in response
to ServiceNeeds (see chapter 12).

11.4 Implementation Level

[TPS_BSWMDT_04068] Relevant elements for ICS on Implementation level dOn
the Implementation level of the BSWMDT, a couple of elements are relevant for the
Conformance Test. Though not part of the ICS in a strict sense, they are required for
administrative reasons and to set up the test environment. The following Elements are
relevant on the implementation level of the BSWMDT:
• BswImplementation.programmingLanguage
BswImplementation.swVersion
BswImplementation.arReleaseVersion
BswImplementation.vendorId
BswImplementation.vendorApiInfix

220 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BswImplementation.codeDescriptor
BswImplementation.compiler
BswImplementation.linker
Defining the programming language, version information, identifiers to expand the
API names (in case of multiple instantiation), code files attached to the delivery,
compiler and linker settings.
• BswImplementation.hwElement
This may be added in case there is a formal description of hardware depen-
dency, especially for MCAL modules. However, the details and the amount of
this information are not standardized.

c(RS_BSWMD_00010, RS_BSWMD_00025, RS_BSWMD_00026)

For details see chapters 6 and 7.
The rest of the elements on the Implementation level of the BSWMDT are not relevant
for the conformance test. They are listed here for completeness:
• BswImplementation.usedCodeGenerator
BswImplementation.requiredArtifact
BswImplementation.requiredGeneratorTool
BswImplementation.generatedArtifact
Since only object code is delivered, information on code generation is not needed.
Also as far as the test cases is concerned, there should be no dependencies on
other artifacts except on other ICC3 modules, but the latter are already defined
via bswModuleDependency on the interface level.
• BswImplementation.resourceConsumption
BswImplementation.mcSupport Information about resource consumption,
measurement, calibration and data for debugging is not relevant for the confor-
mance test.
• BswImplementation.swcBswMapping
This is not relevant to test the conformity of the "naked" ICC3 module. The addi-
tional specification of Ports on top of a BSW module does not change its code.
They are relevant to generate the RTE but not to set up the test environment

11.5 Configuration and Variants

[TPS_BSWMDT_04069] Configuration in ICS dConfiguration parameters and con-
figuration values also form part of the ICS. They shall be attached to the BSWMD as
follows:
• BswImplementation.vendorSpecificModuleDef

221 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

This is needed for two reasons:

1. It shall be possible to run the ICC3 test cases without knowledge of non-
standardized vendor specific configuration parameters. However, copies of
the supported standardized parameter definitions is also part of the ven-
dorSpecificModuleDef (as usual) and is needed here, because the
preconfiguredConfiguration references them.
2. Vendor specific parameter definitions which are "derived" from standardized
ones have to be included for static test (i.e. whether they are derived ac-
cording to the standard). Parameters should also declare the value range
that is supported by the given release of the module - even if only some of
the values are actually pre-configured and tested (see below).
However, it is not required to include completely new vendor specific parameter
definitions (no "origin" in the standardized configuration parameters), because in
this case there is nothing to be tested for conformity.
• BswImplementation.preconfiguredConfiguration
Since each delivered implementation is a fully configured object code, for each
such implementation a complete set of pre-configured values (i.e. values for all
of the parameters given in the above vendorSpecificModuleDef) shall be
attached. Of course, if more than one configuration set shall be tested, there
will be several such preconfiguredConfigurations (and likewise several
BswImplementations and object files) but only one vendorSpecificMod-
uleDef (the one belonging to the release of this module).

c(RS_BSWMD_00024, RS_BSWMD_00027, RS_BSWMD_00035)

The following is obviously not relevant for the conformance test, because the tester
cannot change the configuration:
• BswImplementation.recommendedConfiguration
[TPS_BSWMDT_04070] No variants in ICS dA BSWMD that describes an actual
product can contain variation points. But since the conformance tester gets fully con-
figured object code, this means also, that the ICS-version of a BSWMD shall be free of
any variation points, because the tester has no means to resolve the variants.
If several variants of such a module shall be tested for conformance, for each variant
a separate extract of the BSWMD (representing the ICS) plus object code shall be
delivered to the testerc(RS_BSWMD_00049).
For more details see chapter 10.

222 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12 BSW Service Needs

12.1 Overview
The mechanism of so-called Service Dependencies and Service Needs is used by
Software Components above the RTE to express their needs on the configuration of
AUTOSAR Services. The same mechanism can be used also in the basic software in
order to have a uniform approach, if an AUTOSAR Service has to be configured per
ECU for the needs of both BSW and SWCs.
Figure 12.1 shows the various meta-classes which can be used on the behavior level
of BSW modules and SWCs in order to express these dependencies.
ImplementationProps
+symbolicNameProps ServiceDependency
SymbolicNameProps
0..1 + diagnosticRelevance: ServiceDiagnosticRelevanceEnum [0..1]

AtpStructureElement
BswServiceDependency
Identifiable
SwcServiceDependency

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

«atpVariation,atpSplitable»
+assignedPort 0..* 0..* +assignedData +assignedData 0..* +assignedEntryRole 0..*

RoleBasedPortAssignment RoleBasedDataAssignment RoleBasedBswModuleEntryAssignment

+ role: Identifier [0..1] + role: Identifier [0..1] + role: Identifier [0..1]

+representedPortGroup 0..1 0..1 +serviceNeeds +serviceNeeds 0..1

AtpStructureElement Identifiable +callbackHeader Identifiable

Identifiable ServiceNeeds Code
PortGroup 0..*

Figure 12.1: Concept of ServiceDependency for BSW and SWC

[TPS_BSWMDT_04029] Usage of BswServiceDependency d There is a set of

BswServiceDependency-s that represents the requirements of the module or clus-
ter on the configuration of AUTOSAR Services like NVRAM Manager or Watchdog
Manager. These requirements include not only the specific ServiceNeeds attributes,
but can optionally include references to local data (for example to declare RAM mirror
or ROM default data for the NVRAM Manager) or to BswModuleEntry-s (for example
to declare which expected callbacks belong to a specific NvM block).c(RS_BSWMD_-
00045) The set of BswServiceDependency-s are shown in figure 12.2.
Further explanation could be found in the class tables below.
[TPS_BSWMDT_04127] Callback header declarations dWhen a service configures
callback functions the header files providing the callback function declarations needs
to be identified. The reference callbackHeader describes in which header files the
function declarations of callback functions are provided for the AUTOSAR service im-
plementing the ServiceNeeds.c(RS_BSWMD_00045)
[constr_4089] Association callbackHeader is only applicable for BSW mod-
ules dThe association callbackHeader is only supported for codeDescriptors

223 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

of BswImplementation and only permitted to reference ServiceNeeds owned by

BswServiceDependency.c()
[constr_4090] The callbackHeader reference has to be consistent with behav-
ior reference dThe reference callbackHeader is only allowed to reference Ser-
viceNeeds in the context of the BswServiceDependency which in turn is refer-
enced by the BswImplementation behavior of the BswImplementation owning
the codeDescriptor.c()
ServiceDependency

+ diagnosticRelevance: ServiceDiagnosticRelevanceEnum [0..1]

BswInternalBehavior

«atpVariation,atpSplitable» «atpVariation,atpSplitable»
+assignedDataType

+serviceDependency 0..* 0..1

BswServiceDependency RoleBasedDataTypeAssignment

+ role: Identifier [0..1]

  
   
 
AtpStructureElement
InternalBehavior «atpVariation,atpSplitable»
«atpVariation,atpSplitable» +assignedEntryRole
+serviceNeeds +assignedData
0..1 0..* 0..*

Identifiable
RoleBasedDataAssignment RoleBasedBswModuleEntryAssignment
«atpVariation,atpSplitable» ServiceNeeds
+ role: Identifier [0..1] + role: Identifier [0..1]

«atpVariation,atpSplitable»

«atpVariation,atpSplitable»

0..*
0..1 +assignedEntry 0..1
+staticMemory
+usedDataElement
ARElement
VariableDataPrototype +localVariable AtpBlueprint
AutosarVariableRef
0..1 AtpBlueprintable
BswModuleEntry

+perInstanceParameter +constantMemory
0..* 0..* +usedParameterElement 0..1

ParameterDataPrototype AutosarParameterRef

«instanceRef»

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

AutosarDataPrototype AtpPrototype
DataPrototype

Figure 12.2: BswServiceDependency attached to a BswInternalBehavior

224 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ServiceDependency (abstract)

Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Collects all dependencies of a software module or component on an AUTOSAR Service related to a
specific item (e.g. an NVRAM Block, a diagnostic event etc.). It defines the quality of service (Service
Needs) of this item as well as (optionally) references to additional elements.
This information is required for tools in order to generate the related basic software configuration and
ServiceSwComponentTypes.
Base ARObject
Subclasses BswServiceDependency, SwcServiceDependency
Attribute Type Mult. Kind Note
assignedData RoleBasedDataType 0..1 aggr This is the role of the assignment data type in the given
Type Assignment context.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=assignedDataType, assignedData
Type.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
diagnostic ServiceDiagnostic 0..1 attr If this attribute indicates a relevance for diagnostics then
Relevance RelevanceEnum the integrator has a much easier time identifying the
candidates for the configuration of the diagnostic stack.
Example: identification of mode conditions (e.g.
communication between application and BswM) relevant
for the Dcm.
symbolicName SymbolicNameProps 0..1 aggr This attribute can be taken to contribute to the creation of
Props symbolic name values.

Table 12.1: ServiceDependency

Class BswServiceDependency
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note Specialization of ServiceDependency in the context of an BswInternalBehavior. It allows to associate
BswModuleEntries and data defined for a BSW module or cluster to a given ServiceNeeds element.
Base ARObject, ServiceDependency
Aggregated by BswInternalBehavior.serviceDependency
Attribute Type Mult. Kind Note
assignedData RoleBasedData * aggr Defines the role of an associated data object (owned by
Assignment this module or cluster) in the context of the ServiceNeeds
element.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=assignedData, assignedData.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
assignedEntry RoleBasedBswModule * aggr Defines the role of an associated BswModuleEntry in the
Role EntryAssignment context of the ServiceNeeds element.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=assignedEntryRole, assignedEntry
Role.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
ident BswService 0..1 aggr This adds the ability to become referrable to BswService
DependencyIdent Dependency.
Stereotypes: atpIdentityContributor
Tags: xml.sequenceOffset=-100
serviceNeeds ServiceNeeds 0..1 aggr The associated ServiceNeeds.

Table 12.2: BswServiceDependency

225 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[constr_10257] Existence of attribute BswServiceDependency.serviceNeeds

dFor each BswServiceDependency, the attribute serviceNeeds shall ex-
ist at the time when the configuration of the BSW module is fin-
ished.c()
Class RoleBasedBswModuleEntryAssignment
Package M2::AUTOSARTemplates::BswModuleTemplate::BswBehavior
Note This class specifies an assignment of a role to a particular BswModuleEntry (usually a configurable
callback).
With this assignment, the role of the callback is mapped to a specific ServiceNeeds element, so that a
tool is able to create appropriate configuration values for the module that implements the AUTOSAR
Service.
Base ARObject
Aggregated by BswServiceDependency.assignedEntryRole
Attribute Type Mult. Kind Note
assignedEntry BswModuleEntry 0..1 ref The assigned entry. It should be an implementedEntry or
expectedEntry of the module or cluster that requires the
ServiceNeeds.
role Identifier 0..1 attr This is the role of the assigned BswModuleEntry in the
given context. The attribute is required (for example)
because different kind of callbacks may be associated
with the same ServiceNeeds (e.g. end-notification vs.
error-notification).
The value shall be the role name of a configurable
function call (usually a callback) as standardized in the
Software Specification of the related AUTOSAR Service.

Table 12.3: RoleBasedBswModuleEntryAssignment

[constr_10258] Existence of the reference in the role RoleBasedBswModuleEn-

tryAssignment.assignedEntry dFor each RoleBasedBswModuleEntryAs-
signment, the reference in the role assignedEntry shall exist at the time when
the configuration of the BSW module is finished.c()
[constr_10259] Existence of attribute RoleBasedBswModuleEntryAssignment.
role dFor each RoleBasedBswModuleEntryAssignment, the attribute role
shall exist at the time when the configuration of the BSW module is
finished.c()
Class RoleBasedDataAssignment
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This class specifies an assignment of a role to a particular data object in either
• the SwcInternalBehavior of a software component (or in the BswInternalBehavior of a BSW module or
BSW cluster) in the context of an AUTOSAR Service or
• an NvBlockDescriptor to sort out the assignment of event-based writing strategies to data elements in
a PortPrototype.
With this assignment, the role of the data can be mapped to a DataPrototype that is used in the context
of the definition of a specific ServiceNeeds or NvBlockDescriptor, so that a tool is able to create the
correct access or writing strategy.
Base ARObject
5

226 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class RoleBasedDataAssignment
Aggregated by BswServiceDependency.assignedData, NvBlockDescriptor.writingStrategy, SwcServiceDependency.
assignedData
Attribute Type Mult. Kind Note
role Identifier 0..1 attr This is the role of the assigned data in the given context.
Possible values need to be specified on M1 level.
Additionally the TPS Software Component Template
provides a list of applicable roles for various service
dependencies and service use cases in chapter 13
"Service Dependencies and Service Use Cases" (e.g.,
ramBlock in case of the needs for a permanent RAM
block).
usedData AutosarVariableRef 0..1 aggr The VariableDataPrototype used in this role, e.g.
Element
• Permanent RAM Block of an NVRAM Block which shall
belong to the same SwcInternalBehavior or Bsw
InternalBehavior.
• In the role signalBasedDiagnostics it has to refer to a
VariableDataPrototype in a SenderReceiverInterface or
a NvDataInterface.
usedParameter AutosarParameterRef 0..1 aggr The ParameterDataPrototype used in this role, e.g.
Element
• ROM Block of an NVRAM Block. It shall belong to the
same SwcInternalBehavior or BswInternalbehavior.
• In the role signalBasedDiagnostics it has to refer to a
ParameterDataPrototype in a ParameterInterface.
usedPim PerInstanceMemory 0..1 ref The (untyped) PerInstanceMemory used in this role (e.g.
as a Permanent RAM Block for an NVRAM Block).

Table 12.4: RoleBasedDataAssignment

Class RoleBasedDataTypeAssignment
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::ServiceMapping
Note This class specifies an assignment of a role to a particular data type of a software component (or in the
BswModuleBehavior of a module or cluster) in the context of an AUTOSAR Service.
With this assignment, the role of the data type can be mapped to a specific ServiceNeeds element, so
that a tool is able to create the correct access.
Base ARObject
Aggregated by ServiceDependency .assignedDataType
Attribute Type Mult. Kind Note
role Identifier 0..1 attr This is the role of the associated data type in the given
context.
used ImplementationData 0..1 ref This represents the associated ImplementationDataType.
Implementation Type
DataType

Table 12.5: RoleBasedDataTypeAssignment

Class ServiceNeeds (abstract)

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

227 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ServiceNeeds (abstract)
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses BswMgrNeeds, ComMgrUserNeeds, CryptoKeyManagementNeeds, CryptoServiceJobNeeds, Crypto
ServiceNeeds, DiagnosticCapabilityElement, DltUserNeeds, DoIpServiceNeeds, EcuStateMgrUser
Needs, ErrorTracerNeeds, FunctionInhibitionAvailabilityNeeds, FunctionInhibitionNeeds, Global
SupervisionNeeds, HardwareTestNeeds, IdsMgrCustomTimestampNeeds, IdsMgrNeeds, IndicatorStatus
Needs, J1939DcmDm19Support, J1939RmIncomingRequestServiceNeeds, J1939RmOutgoingRequest
ServiceNeeds, NvBlockNeeds, SecureOnBoardCommunicationNeeds, SupervisedEntityCheckpoint
Needs, SupervisedEntityNeeds, SyncTimeBaseMgrUserNeeds, V2xDataManagerNeeds, V2xFacUser
Needs, V2xMUserNeeds, VendorSpecificServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.6: ServiceNeeds

Note that several kinds of data assignments are restricted to be used within an SWC
because they need RTE support:
RoleBasedDataTypeAssignment
This denotes the type of a temporary Ram Block and used internal data struc-
ture in case of explicit synchronization with NvMReadRamBlockFromNvM and
NvMWriteRamBlockToNvM interface respectively. The type information can be
used to calculate the NvBlock size and minimum Ram Mirror size.
• temporaryRamBlock [0..1]
[constr_4051] RoleBasedDataAssignment in BSW dWhen used in the context of
BswServiceDependency, the following restriction hold for date references described
by RoleBasedDataAssignment:
• Within RoleBasedDataAssignment.usedDataElement, only the reference
AutosarVariableRef.localVariable is applicable.
• Within RoleBasedDataAssignment.usedParameterElement, only the ref-
erence AutosarParameterRef.localParameter is applicable.
• The reference RoleBasedDataAssignment.usedPim shall not be set.
c()
[TPS_BSWMDT_04113] Rule for setting RoleBasedBswModuleEntryAssign-
ment.role dThe value of RoleBasedBswModuleEntryAssignment.role cannot
arbitrarily set but shall to equal to the shortName of the applicable BswModuleEntry
taken from the standardized AUTOSAR BswModuleEntry model (this implies that the
category of the ARPackage that owns the BswModuleEntry is set to BLUEPRINT1
and the top-most ARPackage.shortName is set to AUTOSAR, see also [21]).c(RS_-
BSWMD_00045)

1
see [TPS_STDT_00033]

228 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.2 Specific Service Needs

The abstract meta-class ServiceNeeds and its more specific child classes are de-
fined in the CommonStructure package of the meta-model. This class hierarchy is
shown in the three figures (12.3, 12.4 and 12.5).
The subsequent tables show those specialized ServiceNeeds which are of interest
for the basic software.
Note that several detailed meta-classes for diagnostic capabilities (derived from Di-
agnosticCapabilityElement) and for diagnostic over IP (derived from DoIpSer-
viceNeeds) are not shown here, because they are mainly of interest for application
software. For a detailed description of those refer to [6].
Note that the ServiceNeeds describes only the source data of an abstract depen-
dency. How this is actually traced down to the configuration parameters is specified
by the configuration parameters of the dependent modules itself. For a description of
this mechanism see [TPS_ECUC_02047] under topic "Derived Parameter Definition"
in [16]. To get the complete picture, it should be noted that also other templates can
define source data for dependencies, for example the configuration of the COM stack
depends on information defined via the AUTOSAR System Template.
This information as defined by AUTOSAR for standardized configuration parameters
is also called “Upstream Mapping”. The Upstream Mapping relevant for BSWMDT is
listed in this document in appendix E.
If a BSW module implements an AUTOSAR Service, it is possible that parts of its
own ServiceNeeds are in turn influenced by the ServiceNeeds of the SWCs and
BSW modules integrated on an ECU. In this case, the ServiceNeeds of that module
shall be adjusted at ECU integration time before the initial ECU configuration is set up.
For example, the NvBlockNeeds of the Diagnostic Event Manager will be determined
in response to the number of diagnostic events on an ECU which are given by the
DiagnosticEventNeeds of all integrated SWCs and BSW modules. Since parts of
the XML-description of AUTOSAR Services (namely the SWC-part) are generated at
integration time anyway, the adjustment of ServiceNeeds can be done in the same
step.

229 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Identifiable
CryptoServiceJobNeeds GlobalSupervisionNeeds
ServiceNeeds

DltUserNeeds SupervisedEntityNeeds

+ activateAtStart: Boolean [0..1]

+ enableDeactivation: Boolean [0..1]
+ expectedAliveCycle: TimeValue [0..1]
SyncTimeBaseMgrUserNeeds
+ maxAliveCycle: TimeValue [0..1]
+ minAliveCycle: TimeValue [0..1]
+ toleratedFailedCycles: PositiveInteger [0..1]

BswMgrNeeds
EcuStateMgrUserNeeds

VendorSpecificServiceNeeds
CryptoServiceNeeds

+ algorithmFamily: String [0..1]

+ algorithmMode: String [0..1]
DoIpServiceNeeds + cryptoKeyDescription: String [0..1]
+ maximumKeyLength: PositiveInteger [0..1]

SecureOnBoardCommunicationNeeds ComMgrUserNeeds
+ verificationStatusIndicationMode: + maxCommMode: MaxCommModeEnum [0..1]
VerificationStatusIndicationModeEnum [0..1]

«enumeration» «enumeration»
VerificationStatusIndicationModeEnum MaxCommModeEnum

failureOnly none
failureAndSuccess silent
full

Figure 12.3: Class ServiceNeeds from CommonStructure and some derived classes

«enumeration» Identifiable +serviceNeeds AtpStructureElement «enumeration»

DiagnosticServiceRequestCallbackTypeEnum ServiceNeeds 0..1 Identifiable ObdRatioConnectionKindEnum
ServiceDependency
requestCallbackTypeManufacturer SwcServiceDependency apiUse
requestCallbackTypeSupplier observer

DiagnosticComponentNeeds DiagnosticCapabilityElement DiagnosticCommunicationManagerNeeds

+ audience: + serviceRequestCallbackType:
DiagnosticAudienceEnum [0..*] DiagnosticServiceRequestCallbackTypeEnum [0..1]
DiagnosticControlNeeds + diagRequirement:
DiagRequirementIdString [0..1]
+ securityAccessLevel: DiagnosticValueNeeds
PositiveInteger [0..1]
+ dataLength: PositiveInteger [0..1]
DiagnosticRequestFileTransferNeeds
+ diagnosticValueAccess: DiagnosticValueAccessEnum [0..1]
+ fixedLength: Boolean [0..1]
+ processingStyle: DiagnosticProcessingStyleEnum [0..1]
DiagnosticsCommunicationSecurityNeeds
0..1
DiagnosticRoutineNeeds +currentValue

+ diagRoutineType:
DiagnosticRoutineTypeEnum [0..1]
«enumeration»
DiagnosticAudienceEnum

development DiagnosticIoControlNeeds
manufacturing
afterSales + freezeCurrentStateSupported: Boolean [0..1]
supplier + resetToDefaultSupported: Boolean [0..1]
aftermarket + shortTermAdjustmentSupported: Boolean [0..1]

«enumeration» «enumeration» «enumeration»

DiagnosticRoutineTypeEnum DiagnosticValueAccessEnum DiagnosticProcessingStyleEnum

synchronous readOnly processingStyleSynchronous

asynchronous readWrite processingStyleAsynchronous
writeOnly processingStyleAsynchronousWithError

Figure 12.4: Class ServiceNeeds from CommonStructure and derived classes for di-
agnosis use cases

230 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

AtpStructureElement Identifiable
«enumeration» FunctionInhibitionNeeds
Identifiable +serviceNeeds ServiceNeeds
OperationCycleTypeEnum ServiceDependency
ignition SwcServiceDependency 0..1
obdDcy

+deferringFid
+inhibitingFid
warmup +inhibitingSecondaryFid 0..* 0..1 0..*
power
time
other

DiagnosticEventManagerNeeds DiagnosticCapabilityElement DiagnosticEventNeeds

+ audience: + prestoredFreezeframeStoredInNvm:
DiagnosticAudienceEnum [0..*] Boolean [0..1]
DiagnosticEnableConditionNeeds + diagRequirement: + usesMonitorData: Boolean [0..1]
DiagRequirementIdString [0..1]
+ initialStatus: EventAcceptanceStatusEnum [0..1] + securityAccessLevel: PositiveInteger
[0..1]
DiagnosticStorageConditionNeeds

+ initialStatus: StorageConditionStatusEnum [0..1]

DtcStatusChangeNotificationNeeds

+ notificationTime: DiagnosticEventInfoNeeds
DiagnosticClearDtcNotificationEnum [0..1] + obdDtcNumber: PositiveInteger [0..1]
+ udsDtcNumber: PositiveInteger [0..1]

DiagnosticOperationCycleNeeds

+ operationCycle: OperationCycleTypeEnum [0..1]

WarningIndicatorRequestedBitNeeds

«enumeration» «enumeration» «enumeration»

DiagnosticClearDtcNotificationEnum EventAcceptanceStatusEnum StorageConditionStatusEnum

start eventAcceptanceEnabled eventStorageEnabled

finish eventAcceptanceDisabled eventStorageDisabled

Figure 12.5: Class ServiceNeeds from CommonStructure and derived classes for di-
agnosis use cases

Class NvBlockNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of a single NVRAM Block.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, NvBlockDescriptor.nvBlockNeeds, SwcServiceDependency.
serviceNeeds
Attribute Type Mult. Kind Note
calcRamBlock Boolean 0..1 attr Defines if CRC (re)calculation for the permanent RAM
Crc Block is required.
checkStatic Boolean 0..1 attr Defines if the Static Block Id check shall be enabled.
BlockId
cyclicWriting TimeValue 0..1 attr This represents the period for cyclic writing of NvData to
Period store the associated RAM Block.
nDataSets PositiveInteger 0..1 attr Number of data sets to be provided by the NVRAM
manager for this block. This is the total number of ROM
Blocks and RAM Blocks.
nRomBlocks PositiveInteger 0..1 attr Number of ROM Blocks to be provided by the NVRAM
manager for this block. Please note that these multiple
ROM Blocks are given in a contiguous area.
ramBlockStatus RamBlockStatusControl 0..1 attr This attribute defines how the management of the RAM
Control Enum Block status is controlled.
readonly Boolean 0..1 attr true: data of this NVRAM Block are write protected for
normal operation (but protection can be disabled)
false: no restriction
5

231 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class NvBlockNeeds
reliability NvBlockNeeds 0..1 attr Reliability against data loss on the non-volatile medium.
ReliabilityEnum
resistantTo Boolean 0..1 attr Defines whether an NVRAM Block shall be treated
ChangedSw resistant to configuration changes (true) or not (false). For
details how to handle initialization in the latter case,
please refer to the NVRAM specification.
restoreAtStart Boolean 0..1 attr Defines whether the associated RAM Block shall be
implicitly restored during startup by the basic software.
selectBlockFor Boolean 0..1 attr If this attribute is set to true the NvM shall process this
FirstInitAll block in the NvM_FirstInitAll() function.
storeAt Boolean 0..1 attr Defines whether or not the associated RAM Block shall be
Shutdown implicitly stored during shutdown by the basic software.
storeCyclic Boolean 0..1 attr Defines whether or not the associated RAM Block shall
be implicitly stored periodically by the basic software.
store Boolean 0..1 attr Defines whether or not the associated RAM Block shall
Emergency be implicitly stored in case of ECU failure (e.g. loss of
power) by the basic software. If the attribute store
Emergency is set to true the associated RAM Block shall
be configured to have immediate priority.
storeImmediate Boolean 0..1 attr Defines whether or not the associated RAM Block shall
be implicitly stored immediately during or after execution
of the according SW-C RunnableEntity by the basic
software.
storeOnChange Boolean 0..1 attr This attribute defines whether the associated RAM Block
shall be stored immediately if the written value is different
to the value stored in the associated RAM Block(s) during
or after execution of the according SW-C RunnableEntity.
useAuto Boolean 0..1 attr If set to true the RAM Block shall be auto validated during
ValidationAt shutdown phase.
ShutDown
useCRCComp Boolean 0..1 attr If set to true the CRC of the RAM Block shall be
Mechanism compared during a write job with the CRC which was
calculated during the last successful read or write job in
order to skip unnecessary NVRAM writings.
writeOnlyOnce Boolean 0..1 attr Defines write protection after first write:
true: This block is prevented from being changed/erased
or being replaced with the default ROM data after first
initialization by the software-component.
false: No such restriction.
writeVerification Boolean 0..1 attr Defines if Write Verification shall be enabled for this
NVRAM Block.
writing PositiveInteger 0..1 attr Provides the amount of updates to this block from the
Frequency application point of view. It has to be provided in "number
of write access per year".
writingPriority NvBlockNeedsWriting 0..1 attr Requires the priority of writing this block in case of
PriorityEnum concurrent requests to write other blocks.

Table 12.7: NvBlockNeeds

232 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Enumeration NvBlockNeedsReliabilityEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Reliability against data loss on the non-volatile medium. These requirements give only a relative
indication, for example on the required degree of redundancy for storage.
They do, however, not specify by which means (e.g. software or hardware) the reliability is actually
achieved.
Aggregated by NvBlockNeeds.reliability
Literal Description
errorCorrection Errors shall be corrected
Tags: atp.EnumerationLiteralIndex=0
errorDetection Errors shall be detected
Tags: atp.EnumerationLiteralIndex=1
noProtection Data need not to be handled with protection
Tags: atp.EnumerationLiteralIndex=2

Table 12.8: NvBlockNeedsReliabilityEnum

Enumeration NvBlockNeedsWritingPriorityEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the priority of writing this block in case of concurrent requests to write other blocks.
Aggregated by NvBlockNeeds.writingPriority
Literal Description
high Writing priority is high.
Tags: atp.EnumerationLiteralIndex=0
low Writing priority is low.
Tags: atp.EnumerationLiteralIndex=1
medium Writing priority is medium.
Tags: atp.EnumerationLiteralIndex=2

Table 12.9: NvBlockNeedsWritingPriorityEnum

Enumeration RamBlockStatusControlEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::NvBlockComponent
Note This enumeration type defines options for how the management of the ramBlock status is controlled.
Aggregated by NvBlockNeeds.ramBlockStatusControl
Literal Description
api The ramBlock status is controlled via service interface by usage of the SetRamBlockStatus operation.
Tags: atp.EnumerationLiteralIndex=0
nvRamManager The ramBlock status is controlled exclusively by the Nv Ram Manager.
Tags: atp.EnumerationLiteralIndex=1

Table 12.10: RamBlockStatusControlEnum

Enumeration MaxCommModeEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Maximum bus communication mode required by a user of the Communication Manager Service.
Aggregated by ComMgrUserNeeds.maxCommMode
5

233 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Enumeration MaxCommModeEnum
Literal Description
full Full communication is requested.
Tags: atp.EnumerationLiteralIndex=0
none No communication is requested.
Tags: atp.EnumerationLiteralIndex=1
silent Silent communication is requested: Only listening but not "talking".
Tags: atp.EnumerationLiteralIndex=2

Table 12.11: MaxCommModeEnum

Class SupervisedEntityNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Watchdog Manager for one specific Supervised
Entity.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
activateAtStart Boolean 0..1 attr true/false: supervision activation status of Supervised
Entity shall be enabled/disabled at start.
checkpoints SupervisedEntity * ref This reference indicates the checkpoints belonging to the
CheckpointNeeds Supervised Entity.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=checkpoints.supervisedEntityCheckpoint
Needs, checkpoints.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
enable Boolean 0..1 attr true: software-component shall be allowed to deactivate
Deactivation supervision of this SupervisedEntity
false: software-component shall be not allowed to
deactivate supervision of this SupervisedEntity
expectedAlive TimeValue 0..1 attr Expected cycle time of alive trigger of this Supervised
Cycle Entity (in seconds).
maxAliveCycle TimeValue 0..1 attr Maximum cycle time of alive trigger of this Supervised
Entity (in seconds).
minAliveCycle TimeValue 0..1 attr Minimum cycle time of alive trigger of this Supervised
Entity (in seconds).
toleratedFailed PositiveInteger 0..1 attr Number of consecutive failed alive cycles for this
Cycles SupervisedEntity which shall be tolerated until the
supervision status of the SupervisedEntity is set to
WDGM_ALIVE_EXPIRED (see SWS WdgM for more
details).
Note that this value has to be recalculated with respect to
the WdgM’s own cycle time for ECU configuration.

Table 12.12: SupervisedEntityNeeds

234 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ComMgrUserNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Communication Manager for one "user".
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
maxComm MaxCommModeEnum 0..1 attr Maximum communication mode requested by this ComM
Mode user.
Table 12.13: ComMgrUserNeeds

Class EcuStateMgrUserNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the ECU State Manager for one "user". This class
currently contains no attributes. Its name can be regarded as a symbol identifying the user from the
viewpoint of the component or module which owns this class.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.14: EcuStateMgrUserNeeds

Class CryptoServiceNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the needs on the configuration of the CryptoServiceManager for one ConfigID (see
Specification AUTOSAR_SWS_CSM.doc). An instance of this class is used to find out which ports of a
software-component belong to this ConfigID.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
algorithmFamily String 0..1 attr This attribute represents a description of the family (e.g.
AES) of crypto algorithm implemented by the crypto
service use case.
algorithmMode String 0..1 attr This meta-class has the ability to represent a crypto
service use case.
cryptoKey String 0..1 attr This attribute allows for a verbal description of the
Description applicable cryptographic key. The goal is to pass a hint for
the integrator about how to treat the corresponding
service use case.
maximumKey PositiveInteger 0..1 attr The maximum length of a cryptographic key, that is used
Length by the software-component or module for this
configuration. Unit: bit.

Table 12.15: CryptoServiceNeeds

235 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class DltUserNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class specifies the needs on the configuration of the Diagnostic Log and Trace module for one
SessionId.
This class currently contains no attributes.
An instance of this class is used to find out which PortPrototypes of an AtomicSwComponentType belong
to this SessionId in order to group the request and response PortPrototypes of the same SessionId.
The actual SessionId value is stored in the PortDefinedArgumentValue of the respective PortPrototype
specification.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.16: DltUserNeeds

Class SyncTimeBaseMgrUserNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the needs on the configuration of the Synchronized Time-base Manager for one time-base.
This class currently contains no attributes. An instance of this class is used to find out which ports of a
software-component belong to this time-base in order to group the request and response ports of the
same time-base. The actual time-base value is stored in the PortDefinedArgumentValue of the respective
port specification.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.17: SyncTimeBaseMgrUserNeeds

Class DiagnosticCapabilityElement (abstract)

Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This class identifies the capability to provide generic information about diagnostic capabilities
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Subclasses DiagnosticCommunicationManagerNeeds, DiagnosticComponentNeeds, DiagnosticControlNeeds,
DiagnosticEnableConditionNeeds, DiagnosticEventInfoNeeds, DiagnosticEventManagerNeeds,
DiagnosticEventNeeds, DiagnosticIoControlNeeds, DiagnosticOperationCycleNeeds, DiagnosticRequest
FileTransferNeeds, DiagnosticRoutineNeeds, DiagnosticStorageConditionNeeds, DiagnosticUpload
DownloadNeeds, DiagnosticValueNeeds, DiagnosticsCommunicationSecurityNeeds, DtcStatusChange
NotificationNeeds, ObdControlServiceNeeds, ObdInfoServiceNeeds, ObdMonitorServiceNeeds, ObdPid
ServiceNeeds, ObdRatioDenominatorNeeds, ObdRatioServiceNeeds, WarningIndicatorRequestedBit
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
audience DiagnosticAudience * attr This specifies the intended audience for the diagnostic
Enum object. Note that this is not only for the documentation but
also subsequent audience specific implementation.
diag DiagRequirementId 0..1 attr This denotes the requirement identifier to which the object
Requirement String can be linked to.
Note that with the implementation of a generic tracing
concept in AUTOSAR this attribute might become
obsolete.
5

236 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class DiagnosticCapabilityElement (abstract)
securityAccess PositiveInteger 0..1 attr This attribute denotes the level of security which is
Level touched by the diagnostic object. The higher the level the
more relevance for the security exists.
This level shall be mapped to the security level in the
ECU.

Table 12.18: DiagnosticCapabilityElement

Class FunctionInhibitionNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Function Inhibition Manager for one Function
Identifier (FID). This class currently contains no attributes. Its name can be regarded as a symbol
identifying the FID from the viewpoint of the component or module which owns this class.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.19: FunctionInhibitionNeeds

Class DoIpServiceNeeds (abstract)

Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This represents an abstract base class for ServiceNeeds related to DoIP.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Subclasses DoIpActivationLineNeeds, DoIpGidNeeds, DoIpGidSynchronizationNeeds, DoIpPowerModeStatus
Needs, DoIpRoutingActivationAuthenticationNeeds, DoIpRoutingActivationConfirmationNeeds, Further
ActionByteNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.20: DoIpServiceNeeds

12.2.1 NvM Service Dependencies

This chapter describes the usage of the specific meta-classes derived from Service-
Needs within a Basic Software Module. The meta-class NvBlockNeeds is used
to define requirements to configure the NVRAM Manager Service. There are several
use cases how a Basic Software Module can interact with the NVRAM Manager
service. Each use case is discussed in a separate sub-chapter.

12.2.1.1 Nvm Use Case: Permanent RAM Block

Scenario: a Basic Software Module is using an an NvBlock with a Permanent

RAM Block.

237 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04116] Setup for Nvm Use Case: Permanent RAM Block d

ServiceNeeds kind NvBlockNeeds
RoleBasedBswModuleEntryAssignment
For every used BswModuleEntry provided by the NvM it is necessary to create
a RoleBasedBswModuleEntryAssignment and set the value of the attribute
role of the RoleBasedBswModuleEntryAssignment to the name of the used
standardized BswModuleEntry. The following BswModuleEntrys shall (i.e.
lower multiplicity > 0) or can (lower multiplicity = 0) be used in this context:
• NvM_ReadBlock [0..1]
• NvM_WriteBlock [0..1]
• NvM_RestoreBlockDefaults [0..1]
• NvM_EraseNvBlock [0..1]
• NvM_InvalidateNvBlock [0..1]
• NvM_ReadPRAMBlock [0..1]
• NvM_WritePRAMBlock [0..1]
• NvM_RestorePRAMBlockDefaults [0..1]
• NvM_SetDataIndex [0..1]
• NvM_GetDataIndex [0..1]
• NvM_SetBlockProtection [0..1]
• NvM_GetErrorStatus [0..1]
• NvM_SetRamBlockStatus [0..1]
• NvM_SetBlockLockStatus [0..1]
• NvM_CancelJobs [0..1]
• NvM_SingleBlockCallbackFunction [0..1]
• InitBlockCallbackFunction [0..1]

RoleBasedDataAssignment
RoleBasedDataAssignment shall be created that refers to the Variable-
DataPrototype in the role usedDataElement. The value of the attribute
role of the RoleBasedDataAssignment shall be set to ramBlock.
Optionally, it is possible to create an additional RoleBasedDataAssignment
to a ParameterDataPrototype in the role usedParameterElement. The
value of the ParameterDataPrototype is then taken as the initial or default

238 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

value for the NvBlock. In this case the value of the attribute role of the Role-
BasedDataAssignment shall be set to defaultValue.
Therefore, the following roles are applicable:
• ramBlock [1]
• defaultValue [0 .. 1]
RoleBasedDataTypeAssignment
N/A
c()
For more information please refer to [SWS_NvM_00734], [SWS_NvM_00735], [SWS_-
NvM_00736], and [SWS_NvM_00737].

12.2.1.2 Nvm Use Case: Temporary RAM Block

Scenario: a Basic Software Module is using some NV blocks with a Tempo-

rary RAM Block.
[TPS_BSWMDT_04117] Setup for Nvm Use Case: Temporary RAM Block d
ServiceNeeds kind NvBlockNeeds

RoleBasedBswModuleEntryAssignment valid roles:

For every used BswModuleEntry provided by the NvM it is necessary to create
a RoleBasedBswModuleEntryAssignment and set the value of the attribute
role of the RoleBasedBswModuleEntryAssignment to the name of the used
standardized BswModuleEntry. The following BswModuleEntrys shall (i.e.
lower multiplicity > 0) or can (lower multiplicity = 0) be used in this context:
• NvM_ReadBlock [0..1]
• NvM_WriteBlock [0..1]
• NvM_RestoreBlockDefaults [0..1]
• NvM_EraseNvBlock [0..1]
• NvM_InvalidateNvBlock [0..1]
• NvM_SetDataIndex [0..1]
• NvM_GetDataIndex [0..1]
• NvM_SetBlockProtection [0..1]
• NvM_GetErrorStatus [0..1]
• NvM_SetRamBlockStatus [0..1]
• NvM_SetBlockLockStatus [0..1]

239 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• NvM_CancelJobs [0..1]
• NvM_SingleBlockCallbackFunction [0..1]
• InitBlockCallbackFunction [0..1]

RoleBasedDataAssignment
RoleBasedDataAssignment may be created that refers to a ParameterDat-
aPrototype in the role usedParameterElement. The value of the Parame-
terDataPrototype is then taken as the initial or default value for the NvBlock.
In this case the value of the attribute role of the RoleBasedDataAssignment
shall be set to defaultValue.
Therefore, the following roles are applicable:
• defaultValue [0 .. 1]
RoleBasedDataTypeAssignment
This denotes the type of the temporary Ram Block. The type information can be
used to calculate the NVRAM block. [constr_4088] applies.
• temporaryRamBlock [0 .. 1]
c()

[constr_4088] Existence of RoleBasedDataTypeAssignment.role vs. Role-

BasedDataAssignment.role dThe usage of a RoleBasedDataTypeAssignment
with attribute role set to the value temporaryRamBlock is only allowed if no Role-
BasedDataAssignment defined with attribute role set to value defaultValue ex-
ists in the owning BswServiceDependency.c()
The rationale for [constr_4088] is that the existence of a RoleBasedDataAssign-
ment would already provide sufficient information for the intended purpose. The paral-
lel existence of a RoleBasedDataTypeAssignment is therefore fully redundant and
could only lead to potential inconsistencies.

12.2.1.3 Nvm Use Case: RAM Block with explicit synchronization

Scenario: a Basic Software Module is using some NV blocks where the RAM
Block is synchronized by means of explicit synchronizatin using the mirror interfaces.
[TPS_BSWMDT_04118] Setup for Nvm Use Case: RAM Block synchronised with
explicit synchronization d
RoleBasedBswModuleEntryAssignment valid roles:
For every used BswModuleEntry provided by the NvM it is necessary to create
a RoleBasedBswModuleEntryAssignment and set the value of the attribute
role of the RoleBasedBswModuleEntryAssignment to the name of the used

240 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

standardized BswModuleEntry. The following BswModuleEntrys shall (i.e.

lower multiplicity > 0) or can (lower multiplicity = 0) be used in this context:
• NvM_ReadBlock [0..1]
• NvM_WriteBlock [0..1]
• NvM_RestoreBlockDefaults [0..1]
• NvM_EraseNvBlock [0..1]
• NvM_InvalidateNvBlock [0..1]
• NvM_ReadPRAMBlock [0..1]
• NvM_WritePRAMBlock [0..1]
• NvM_RestorePRAMBlockDefaults [0..1]
• NvM_SetDataIndex [0..1]
• NvM_GetDataIndex [0..1]
• NvM_SetBlockProtection [0..1]
• NvM_GetErrorStatus [0..1]
• NvM_SetRamBlockStatus [0..1]
• NvM_SetBlockLockStatus [0..1]
• NvM_CancelJobs [0..1]
• NvM_SingleBlockCallbackFunction [0..1]
• InitBlockCallbackFunction [0..1]
• NvM_ReadRamBlockFromNvm [1]
• NvM_WriteRamBlockToNvm [1]

RoleBasedDataAssignment
RoleBasedDataAssignment may be created that refers to a ParameterDat-
aPrototype in the role usedParameterElement. The value of the Parame-
terDataPrototype is then taken as the initial or default value for the NvBlock.
In this case the value of the attribute role of the RoleBasedDataAssignment
shall be set to defaultValue.
Therefore, the following roles are applicable:
• defaultValue [0 .. 1]

241 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

RoleBasedDataTypeAssignment
This denotes the type of the internal data structure synchronized with NvMRead-
RamBlockFromNvM and NvMWriteRamBlockToNvM interface. The type infor-
mation can be used to calculate the NVRAM block size and minimum RAM Mir-
ror size. [constr_4088] applies.
• temporaryRamBlock [0 .. 1]
c()

12.2.2 Diagnostic Service Dependency

This chapter describes the usage of the specific diagnostic meta-classes derived from
ServiceNeeds within a Basic Software Module.

12.2.2.1 Function Inhibition Needs

The meta-class FunctionInhibitionNeeds is used to define requirements in order

to configure the Function Inhibition Manager.
A BswInternalBehavior may provide several FunctionInhibitionNeeds ele-
ments, each defines the requirements related to one function inhibition ID (for the terms
related to the AUTOSAR Function Inhibition Manager, see [22]).

12.2.2.1.1 Function Inhibition Manager Service use Case: read function permis-
sion

[TPS_BSWMDT_04119] Setup for Function Inhibition Manager Service use Case:

read function permission d
Scenario: a Basic Software Module reads the function permission from FiM in
order to enable or disable a functionality. In this case the following setup apply:
ServiceNeeds kind FunctionInhibitionNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• FiM_GetFunctionPermission [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

242 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.2.2.1.2 Function Inhibition Manager Service use Case: react on suppressed

or unavailable events

[TPS_BSWMDT_04167] Setup for Function Inhibition Manager Service use Case:

read function permission d
Scenario: a Basic Software Module wants to react on suppressed or unavailable
events and disable the permission to run for a FID. In this case, the following setup
applies:
ServiceNeeds kind FunctionInhibitionAvailabilityNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• FiM_SetFunctionAvailable [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()
Note: for variant coding ClientServerInterface, ControlFunctionAvail-
able is used to deactivate a certain functionality (e.g. to set the FID to not available).
For more information please refer to [SWS_Fim_00106].

12.2.2.2 Diagnostic Event Needs

The meta-classes DiagnosticEventNeeds is used to define requirements in order

to configure the Diagnostic Event Manager Service.
An BswInternalBehavior may provide several DiagnosticEventNeeds ele-
ments that each defines the requirements related to one diagnostic monitor. (For the
terms related to the AUTOSAR Diagnostic Event Manager see [23]).

12.2.2.2.1 Dem Service Use Case: diagnostic monitor, debouncing by Dem

Scenario: a Basic Software Module implements a Diagnostic Monitor. The de-

bouncing of the failure condition shall be configured and processed by the Dem. In this
case the following setup apply:
[TPS_BSWMDT_04120] Dem Service Use Case: Basic Software Module im-
plements a Diagnostic Monitor d
ServiceNeeds kind DiagnosticEventNeeds
RoleBasedBswModuleEntryAssignment valid roles:

243 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• Dem_SetEventStatus [1]
• Dem_ResetEventDebounceStatus [0..1]
• Dem_GetEventStatus [0..1]
• Dem_GetEventFailed [0..1]
• Dem_GetEventTested [0..1]
• Dem_GetDTCOfEvent [0..1]
• Dem_SetEventDisabled [0..1]
• InitMonitorForEvent [0..1]
• DemTriggerOnEventStatus [0..1]
• DemClearEventAllowed [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.2.2.2 Dem Service Use Case: Basic Software Module implements a

Hardware Shutdown

Scenario: when a hardware component is detected as being defective, the Dem shall
inform the Basic Software Module which is responsible for executing a hardware-
shutdown.
[TPS_BSWMDT_04139] Dem Service Use Case: Basic Software Module im-
plements a hardware shutdown d
ServiceNeeds kind DiagnosticComponentNeeds
RoleBasedPortAssignment valid roles:
• DemTriggerOnComponentStatus [1]
RoleBasedDataAssignment
N/A
RepresentedPortGroups
N/A
c()

244 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.2.2.2.3 Dem Service Use Case: Basic Software Module checks whether
an event is suppressed

Scenario: a Basic Software Module needs to check for the availability of the event
in order to decide whether reporting of that event is cleared by the Dem. For this pur-
pose the Basic Software Module exposes a BswModuleEntry towards the Dem.
[TPS_BSWMDT_04173] Dem Service Use Case: Basic Software Module
checks whether an event is suppressed d
ServiceNeeds kind DiagnosticEventInfoNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Dem_GetEventAvailable [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
RepresentedPortGroups
N/A
c()

12.2.2.3 Diagnostic Communication Needs

The meta-class DiagnosticValueNeeds is used to define requirements in order to

configure the Diagnostic Communication Manager Service as well as the Diagnostic
Event Manager Service. The DcM and Dem can access local values via callback func-
tions.
The attribute DiagnosticValueNeeds.diagnosticValueAccess of type Diag-
nosticValueAccessEnum allows for distinguishing between current values to read
diagnostic information (readOnly) and data elements which are additionally classified
as configurable (readWrite).
Class DiagnosticValueNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the general needs on the configuration of the Diagnostic Communication Manager (DCM)
which are not related to a particular item (e.g. a PID). The main use case is the mapping of service ports
to the DCM which are not related to a particular item.
In the case of using a sender receiver communicated value, the related value shall be taken via assigned
Data in the role "signalBasedDiagnostics".
In case of using a client/server communicated value, the related value shall be communicated via the
port referenced by assignedPort. The details of this communication (e.g. appropriate naming
conventions) are specified in the related software specifications (SWS).
5

245 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class DiagnosticValueNeeds
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
dataLength PositiveInteger 0..1 attr This attribute is applicable only if the DiagnosticValue
Needs is aggregated within a BswModuleDependency.
This attribute represents the length of data (in bytes)
provided for this particular PID signal.
diagnosticValue DiagnosticValueAccess 0..1 attr This attribute is applicable only if the DiagnosticValue
Access Enum Needs is aggregated within a BswModuleDependency.
This attribute controls whether the data can be read and
written or whether it is to be handled read-only.
fixedLength Boolean 0..1 attr This attribute is applicable only if the DiagnosticValue
Needs is aggregated within a BswModuleDependency.
This attribute controls whether the data length of the data
is fixed.
processingStyle DiagnosticProcessing 0..1 attr This attribute controls whether interaction requires the
StyleEnum software-component to react synchronously on a request
or whether it processes the request in background but still
the DCM has to issue the call again to eventually obtain
the result of the request.

Table 12.21: DiagnosticValueNeeds

Enumeration DiagnosticValueAccessEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Defines the access of the configured diagnostic current values which will be used by the Dem or Dcm
module.
Aggregated by DiagnosticValueNeeds.diagnosticValueAccess
Literal Description
readOnly The access to the data element is limited to read-only. This is typically used to read-out diagnostic
information (e.g. current values).
Tags: atp.EnumerationLiteralIndex=0
readWrite The value of the diagnostic data element is classified as configurable (read and write access is
possible).
Tags: atp.EnumerationLiteralIndex=1
writeOnly The access to the data element is limited to write-only. This supports the use case where the Dcm
just writes data to the application software without the intention to read it back,
Tags: atp.EnumerationLiteralIndex=2

Table 12.22: DiagnosticValueAccessEnum

Enumeration DiagnosticProcessingStyleEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to define the processing style of diagnostic requests.
Aggregated by DiagnosticValueNeeds.processingStyle
Literal Description
5

246 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Enumeration DiagnosticProcessingStyleEnum
processingStyle The software-component processes the request in background but still the Dcm has to issue the call
Asynchronous again to eventually obtain the result of the request.
Tags: atp.EnumerationLiteralIndex=0
processingStyle The software-component processes the request in background but still the Dcm has to issue the call
AsynchronousWith again to eventually obtain the result of the request or handle error code.
Error
Tags: atp.EnumerationLiteralIndex=1
processingStyle The software-component is supposed to react synchronously on the request.
Synchronous
Tags: atp.EnumerationLiteralIndex=2

Table 12.23: DiagnosticProcessingStyleEnum

The meta-class DiagnosticRoutineNeeds is used to define requirements to con-

figure the Diagnostic Communication Manager Service. A Basic Software Mod-
ule may provide BswModuleEntrys (for example, “start”, “stop”, and “RequestRe-
sults”). The BswModuleEntrys correspond to the diagnostic service RoutineControl
for one routine identifier. The enumeration parameter DiagnosticRoutineType-
Enum is used to define whether the diagnostic server or client is responsible for stop-
ping the routine.
Class DiagnosticRoutineNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the general needs on the configuration of the Diagnostic Communication Manager (Dcm) which
are not related to a particular item (e.g. a PID). The main use case is the mapping of service ports to the
Dcm which are not related to a particular item.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
diagRoutine DiagnosticRoutineType 0..1 attr This denotes the type of diagnostic routine which is
Type Enum implemented by the referenced server port.

Table 12.24: DiagnosticRoutineNeeds

Enumeration DiagnosticRoutineTypeEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This enumerator specifies the different types of diagnostic routines.
Aggregated by DiagnosticRoutineNeeds.diagRoutineType
Literal Description
asynchronous This indicates that the diagnostic server is not blocked while the diagnostic routine is running.
Tags: atp.EnumerationLiteralIndex=0
synchronous This indicates that the diagnostic routine blocks the diagnostic server in the ECU while the routine is
running.
Tags: atp.EnumerationLiteralIndex=1

Table 12.25: DiagnosticRoutineTypeEnum

The meta-class DiagnosticIoControlNeeds is used to define requirements to con-

figure the Diagnostic Communication Manager Service.

247 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class DiagnosticIoControlNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the general needs on the configuration of the Diagnostic Communication Manager (DCM)
which are not related to a particular item (e.g. a PID). The main use case is the mapping of service ports
to the Dcm which are not related to a particular item.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
currentValue DiagnosticValueNeeds 0..1 ref Reference to the DiagnosticValueNeeds indicating the
access to the current value via signalBasedDiagnostics.
freezeCurrent Boolean 0..1 attr This attribute determines, if the referenced port supports
StateSupported temporary freezing of I/O value.
The temporary freeze is not supported if the enclosing
DiagnosticIoControlNeeds is aggregated by a Swc
ServiceDependency, see [constr_1364].
resetToDefault Boolean 0..1 attr This represents a flag for the existence of the ResetTo
Supported Default operation in the service interface.
shortTerm Boolean 0..1 attr This attribute determines, if the referenced port supports
Adjustment temporarily setting of I/O value to a specific value
Supported provided by the diagnostic tester.
The short term adjustment is not supported if the
enclosing DiagnosticIoControlNeeds is aggregated by a
SwcServiceDependency, see [constr_1364].

Table 12.26: DiagnosticIoControlNeeds

Class DiagnosticsCommunicationSecurityNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the needs of a software-component to verify the access to security level via
diagnostic services.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.27: DiagnosticsCommunicationSecurityNeeds

Class DiagnosticCommunicationManagerNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the general needs on the configuration of the Diagnostic Communication Manager (Dcm) which
are not related to a particular item (e.g. a PID or DiagnosticRoutineNeeds). The main use case is the
mapping of service ports to the Dcm which are not related to a particular item.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
serviceRequest DiagnosticService 0..1 attr This represents the ability to define whether the usage of
CallbackType RequestCallbackType PortInterface ServiceRequestNotification has the
Enum characteristics of being initiated by a manufacturer or by a
supplier.

Table 12.28: DiagnosticCommunicationManagerNeeds

248 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.2.2.3.1 Dcm Service Use Case: read/write current values by BswModuleEn-

trys

Scenario: a Basic Software Module offers a BswModuleEntrys to read/write

current value via diagnostic services.
[TPS_BSWMDT_04121] Basic Software Module offers BswModuleEntrys to
read/write current value via diagnostic services d
ServiceNeeds kind DiagnosticValueNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Xxx_ReadData [0..1] (1 in case read is supported)
• Xxx_WriteData [0..1] (1 in case write is supported)
• Xxx_ReadDataLength [0..1] (1 in case of variable length)
• Xxx_ConditionCheckRead [0..1] ](1 in case the read condition is provided
by the BSW module)
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.2.3.2 Dcm Service Use Case: start/stop or request routine results

Scenario: a Basic Software Module offers a BswModuleEntrys to start/stop or

request routines via diagnostic services.
[TPS_BSWMDT_04122] Basic Software Module offers BswModuleEntrys to
start/stop or request routines via diagnostic services d
ServiceNeeds kind DiagnosticRoutineNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Xxx_Start [1]
• Xxx_Stop [0..1]
• Xxx_RequestResults [0..1]
• Xxx_StartConfirmation [0..1]
• Xxx_StopConfirmation [0..1]
• Xxx_RequestResultsConfirmation [0..1]

249 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.2.3.3 Dcm Service Use Case: IO control

Scenario: a Basic Software Module offers a BswModuleEntrys BswModuleEn-

trys to adjust the IO signal via diagnostic services.
[TPS_BSWMDT_04123] Basic Software Module offers BswModuleEntrys to
adjust the IO signal via diagnostic services d
ServiceNeeds kind DiagnosticIoControlNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Xxx_ReadData [1]
• Xxx_ReturnControlToECU [0..1]
• Xxx_ResetToDefault [0..1]
• Xxx_FreezeCurrentState [0..1]
• Xxx_ShortTermAdjustment [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.2.3.4 Dcm Service Use Case: Access to protocol, session and security
Information

Scenario: a Basic Software Module offers a BswModuleEntrys to access pro-

tocol, session and security information.
[TPS_BSWMDT_04124] Basic Software Module offers BswModuleEntrys to
access protocol, session and security information d
ServiceNeeds kind DiagnosticCommunicationManagerNeeds
RoleBasedBswModuleEntryAssignment valid roles:

250 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• Dcm_ResetToDefaultSession [0..1]
• Dcm_GetSecurityLevel [0..1]
• Dcm_GetSesCtrlTypel [0..1]
• Dcm_GetActiveProtocol [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.2.3.5 Dcm Service Use Case: Seed / Key handling for security level access
and the optional security attempt counter handling

Scenario: a Basic Software Module offers BswModuleEntrys for the Seed and
Key handling for security level access and the optional security attempt counter han-
dling.
[TPS_BSWMDT_04125] Basic Software Module offers BswModuleEntrys for
the Seed adn Key handling for security level access and the optional security
attempt counter handling d
ServiceNeeds kind DiagnosticsCommunicationSecurityNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Xxx_CompareKey [1]
• Xxx_GetSeed [1]
• Xxx_GetSecurityAttemptCounter [0..1]
• Xxx_SetSecurityAttemptCounter [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

251 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.2.2.3.6 Dcm Service Use Case: Upload and download of data

Scenario: a Basic Software Module implements the ability to accept data for up-
load and/or provide data for download. For this purpose the Basic Software Mod-
ule provides a BswModuleEntry that connects to the Dcm service component.
[TPS_BSWMDT_04172] Basic Software Module implements the ability to ac-
cept data for upload and/or provide data for download. For this purpose the Ba-
sic Software Module provides a BswModuleEntry that connects to the Dcm
service component. d
ServiceNeeds kind DiagnosticUploadDownloadNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• UploadDownloadServices [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()
Class DiagnosticUploadDownloadNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to specify needs regarding upload and download by means of
diagnostic services.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.29: DiagnosticUploadDownloadNeeds

12.2.2.4 OBD Service Needs

The meta-class ObdPidServiceNeeds is used to define requirements to configure

OBD Services in relation to a particular PID (parameter identifier).

12.2.2.4.1 OBD Service Use Case: Read value via OBD services

Scenario: a Basic Software Module offers a BswModuleEntrys BswModuleEn-

trys to read value via OBD services.
[TPS_BSWMDT_04165] Basic Software Module offers BswModuleEntrys to
read value via OBD services d

252 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

ServiceNeeds kind ObdPidServiceNeeds

RoleBasedBswModuleEntryAssignment valid roles:
• Xxx_ReadData [1] (1 in case read is supported)
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()
The meta-class ObdInfoServiceNeeds is used to define requirements to configure
OBD Services in relation to a given InfoType (OBD Service 09).

12.2.2.4.2 OBD Service Use Case: Read vehicle information via OBD services

Scenario: a Basic Software Module offers a BswModuleEntrys BswModuleEn-

trys to read vehicle information via OBD services.
[TPS_BSWMDT_04166] Basic Software Module offers BswModuleEntrys to
read vehicle information via OBD services d
ServiceNeeds kind ObdInfoServiceNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Xxx_GetInfoTypeValueData [1] (1 in case read is supported)
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.3 Watchdog Service Dependencies

The meta-class SupervisedEntityNeeds is used to define requirements to config-

ure the Watchdog Service. For the terms related to the AUTOSAR Watchdog Manager
see [24].

12.2.4 Watchdog Service use Case: Local Supervision

The service interaction with the Watchdog Manager consists of two aspects:

253 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• supervised entity
• checkpoint
For each of the two aspects a separated ServiceNeeds is defined. However, the
BswServiceDependencys that own these ServiceNeeds are semantically bound
and cannot be used independently of each other.
In other words, the usage of two kinds of BswServiceDependency in concert creates
a higher-level semantics. Of course, in order to express this higher-level semantics a
reference between the BswServiceDependencys has to be available.
However, since the BswServiceDependency represents a generic concept the ac-
tual reference needs to be implemented on the level of specific subclass of Service-
Needs, in this case the SupervisedEntityNeeds and the SupervisedEntity-
CheckpointNeeds.
The former refers to the latter in order to express the relation of a supervised entity to
its checkpoints.
Class SupervisedEntityCheckpointNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Watchdog Manager to support a Checkpoint for a
Supervised Entity.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.30: SupervisedEntityCheckpointNeeds

[TPS_BSWMDT_04129] Definition a Supervised Entity in a Basic Software

Module d
ServiceNeeds kind : SupervisedEntityNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• WdgM_GetLocalStatus [0..1]
• WdgM_LocalMode [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()
For more information please refer to [SWS_WdgM_00333], and [SWS_WdgM_00335].

254 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Please note that an BswInternalBehavior may provide several SupervisedEn-

tityNeeds elements where each defines the requirements in relation to one super-
vised entity.
[TPS_BSWMDT_04157] Definition of Checkpoints for a Supervised Entity in a
Basic Software Module d
ServiceNeeds kind : SupervisedEntityCheckpointNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• WdgM_CheckpointReached [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()
For more information please refer to [SWS_WdgM_00333], and [SWS_WdgM_00335].
Please note that an BswInternalBehavior may provide several SupervisedEn-
tityCheckpointNeeds elements where each defines the relation to one Super-
visedEntityNeeds .

12.2.5 Watchdog Service use Case: Control global supervision or get global
supervision status

Scenario: a Basic Software Module either controls the global operation of the
watchdog manager or gets information about the current operations status requiring at
least one of the following use cases:
• Sets the current mode of Watchdog Manager
• Gets the current mode of the Watchdog Manager
• Gets the global supervision status of the Watchdog Manager
• Identifier of the supervised entity that first reached the expired state
• Instructs the Watchdog Manager to cause a watchdog reset

For instance the Basic Software Module sets the current mode of the Watchdog
Manager according the operational state of the ECU or polls the global supervision
status.
In this case the following setup applies:

255 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04158] Setup for a Basic Software Module which sets or gets

Global Supervision Status d
ServiceNeeds kind : GlobalSupervisionNeeds
RoleBasedPortAssignment valid roles:
• WdgM_GetFirstExpiredSEID [0..1]
• WdgM_GetGlobalStatus [0..1]
• WdgM_GetLocalStatus [0..1]
• WdgM_GetMode [0..1]
• WdgM_PerformReset [0..1]
• WdgM_SetMode [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.6 ECU State Manager Service Needs

The meta-class EcuStateMgrUserNeeds is used to define the requirements to con-

figure the ECU State Manager Service. There are actually two variants of AUTOSAR
ECU management: flexible and fixed. An BswInternalBehavior may provide sev-
eral EcuStateMgrUserNeeds elements where each defines the requirements from
one “user” of the EcuM Service (for the terms related to the AUTOSAR ECU State
Manager see [25]).

12.2.6.1 EcuM Flex Use Case: select Shutdown Target

Scenario: a Basic Software Module wants to select a shutdown target. This cor-
responds to the “select shutdown target” use case of the fix EcuM.
In this case the following rules apply:
[TPS_BSWMDT_04135] Basic Software Module wants to select a shutdown
target (flexible variant) d
RoleBasedBswModuleEntryAssignment valid roles:
• EcuM_GetShutdownTarget [1]
• EcuM_SelectShutdownTarget [1]

256 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• EcuM_GetLastShutdownTarget [1]
• EcuM_GetShutdownCause [1]
• EcuM_SelectShutdownCause [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.6.2 EcuM Flex Use Case: select Boot Target

Scenario: a Basic Software Module wants to select a boot target.

In this case the following rules apply:
[TPS_BSWMDT_04136] Basic Software Module wants to select a boot target
(flexible variant) d
RoleBasedBswModuleEntryAssignment valid roles:
• EcuM_GetBootTarget [1]
• EcuM_SelectBootTarget [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.2.6.3 EcuM Flex Use Case: use Alarm Clock

Scenario: a Basic Software Module wants to use an alarm clock.

In this case the following rules apply:
[TPS_BSWMDT_04137] Basic Software Module wants to use an alarm clock
(flexible variant) d
RoleBasedBswModuleEntryAssignment valid roles:
• EcuM_SetRelWakeupAlarm [1]
• EcuM_SetAbsWakeupAlarm [1]

257 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

• EcuM_AbortWakeupAlarm [1]
• EcuM_SetClock [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.3 Basic Software Production Errors

The meta-class DiagnosticEventNeeds is used to specify production errors in a
BSWMD.
Class DiagnosticEventNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Diagnostic Event Manager for one diagnostic
event. Its shortName can be regarded as a symbol identifying the diagnostic event from the viewpoint of
the component or module which owns this element.
In case the diagnostic event specifies a production error, the shortName shall be the name of the
production error.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
deferringFid FunctionInhibitionNeeds * ref This reference contains the link to a function identifier
within the FiM which is used by the monitor before
delivering a result.
diagEvent DiagEventDebounce 0..1 aggr Specifies the abstract need on the Debounce Algorithm
Debounce Algorithm applied by the Diagnostic Event Manager.
Algorithm
inhibitingFid FunctionInhibitionNeeds 0..1 ref This represents the primary Function Inhibition Identifier
used for inhibition of the diagnostic monitor. The FID
might either inhibit the monitoring of a symptom or the
reporting of detected faults.
inhibiting FunctionInhibitionNeeds * ref This represents the secondary Function Inhibition
SecondaryFid Identifier used for inhibition of the diagnostic monitor. Any
of the FID inhibitions leads to an inhibition of the
monitoring of a symptom or the reporting of detected
faults.
prestored Boolean 0..1 attr If the Event uses a prestored freeze-frame (using the
Freezeframe operations PrestoreFreezeFrame and ClearPrestored
StoredInNvm FreezeFrame of the service interface DiagnosticMonitor)
this attribute indicates if the Event requires the data to be
stored in non-volatile memory. TRUE = Dem shall store
the prestored data in non-volatile memory, FALSE = Data
can be lost at shutdown (not stored in Nvm).
usesMonitor Boolean 0..1 attr This attribute defines whether additional monitor data
Data shall be added to the reporting of events.

Table 12.31: DiagnosticEventNeeds

258 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class DiagEventDebounceAlgorithm (abstract)

Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This class represents the ability to specify the pre-debounce algorithm which is selected and/or required
by the particular monitor.
This class inherits from Identifiable in order to allow further documentation of the expected or
implemented debouncing and to use the category for the identification of the expected / implemented
debouncing.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses DiagEventDebounceCounterBased, DiagEventDebounceMonitorInternal, DiagEventDebounceTime
Based
Aggregated by DiagnosticDebounceAlgorithmProps.debounceAlgorithm, DiagnosticEventNeeds.diagEventDebounce
Algorithm
Attribute Type Mult. Kind Note
– – – – –
Table 12.32: DiagEventDebounceAlgorithm

Class DiagEventDebounceCounterBased
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to indicate that the counter-based debounce algorithm shall be
used by the DEM for this diagnostic monitor.
This is related to set the ECUC choice container DemDebounceAlgorithmClass to DemDebounce
CounterBased.
Base ARObject, DiagEventDebounceAlgorithm, Identifiable, MultilanguageReferrable, Referrable
Aggregated by DiagnosticDebounceAlgorithmProps.debounceAlgorithm, DiagnosticEventNeeds.diagEventDebounce
Algorithm
Attribute Type Mult. Kind Note
counterBased Integer 0..1 attr Threshold to allocate an event memory entry and to
FdcThreshold capture the Freeze Frame.
StorageValue
counter Integer 0..1 attr This value shall be taken to decrement the internal
DecrementStep debounce counter.
Size
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
counterFailed Integer 0..1 attr This value defines the event-specific limit that indicates
Threshold the "failed" counter status.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
counter Integer 0..1 attr This value shall be taken to increment the internal
IncrementStep debounce counter.
Size
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
counterJump Boolean 0..1 attr This value activates or deactivates the counter
Down jump-down behavior.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
counterJump Integer 0..1 attr This value represents the initial value of the internal
DownValue debounce counter if the counting direction changes from
incrementing to decrementing.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
5

259 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class DiagEventDebounceCounterBased
counterJumpUp Boolean 0..1 attr This value activates or deactivates the counter jump-up
behavior.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
counterJumpUp Integer 0..1 attr This value represents the initial value of the internal
Value debounce counter if the counting direction changes from
decrementing to incrementing.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
counterPassed Integer 0..1 attr This value defines the event-specific limit that indicates
Threshold the "passed" counter status.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 12.33: DiagEventDebounceCounterBased

Class DiagEventDebounceTimeBased
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to indicate that the time-based pre-debounce algorithm shall be
used by the Dem for this diagnostic monitor.
This is related to set the EcuC choice container DemDebounceAlgorithmClass to DemDebounceTime
Base.
Base ARObject, DiagEventDebounceAlgorithm, Identifiable, MultilanguageReferrable, Referrable
Aggregated by DiagnosticDebounceAlgorithmProps.debounceAlgorithm, DiagnosticEventNeeds.diagEventDebounce
Algorithm
Attribute Type Mult. Kind Note
timeBasedFdc TimeValue 0..1 attr Threshold to allocate an event memory entry and to
Threshold capture the Freeze Frame.
StorageValue
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
timeFailed TimeValue 0..1 attr This value represents the event-specific delay indicating
Threshold the "failed" status.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
timePassed TimeValue 0..1 attr This value represents the event-specific delay indicating
Threshold the "passed" status.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 12.34: DiagEventDebounceTimeBased

Class DiagEventDebounceMonitorInternal
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to indicate that no Dem pre-debounce algorithm shall be used for
this diagnostic monitor. The SWC might implement an internal debouncing algorithm and report qualified
(debounced) results to the Dem/DM.
Base ARObject, DiagEventDebounceAlgorithm, Identifiable, MultilanguageReferrable, Referrable
Aggregated by DiagnosticDebounceAlgorithmProps.debounceAlgorithm, DiagnosticEventNeeds.diagEventDebounce
Algorithm
Attribute Type Mult. Kind Note
– – – – –
Table 12.35: DiagEventDebounceMonitorInternal

260 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04110] Declaration of production errors dIf a BSW module re-

ports diagnostic events to the module DEM (= Diagnostic Event Manager ,see [23]),
its BswInternalBehavior shall contain for each kind of diagnostic event one Ser-
viceDependency element in the role serviceDependency.
This diagnostic event is further characterized by the element ServiceDependency.
serviceNeeds which shall be an instance of meta-class DiagnosticEventNeeds.
If the diagnostic event describes a production error, its DiagnosticEventNeeds.
category attribute shall have one of the following values:
• PRODUCTION_ERROR if it represents a production error.
• EXTENDED_PRODUCTION_ERROR if it represents an extended production er-
ror.
Its DiagnosticEventNeeds.shortName shall be equal to the error symbol defined
in the AUTOSAR SWS of the respective module if the production error is standardized.c
(RS_BSWMD_00045, RS_BSWMD_00069)
For further information on production error reporting refer to [26].

Production errors and extended production errors are reported to the DEM via the C-
function Dem_SetEventStatus(). This scenario shall be specified in the following
way:
[TPS_BSWMDT_04111] BswServiceDependency refers to
Dem_SetEventStatus() dA BswModuleEntry representing the signature of
the C-function Dem_SetEventStatus() shall be specified. According to the rules
[TPS_BSWMDT_04008] and [TPS_BSWMDT_04016] defined earlier in this docu-
ment, its shortName shall have the value Dem_SetEventStatus and the package
location in XML shall be:
AUTOSAR_Dem/BswModuleEntrys/

Each BswServiceDependency representing a production error in a BSDWMD shall

refer to this BswModuleEntry via an aggregated assignedEntryRole which has
its role attribute set to the value ReportErrorStatus.c(RS_BSWMD_00045, RS_-
BSWMD_00069)
Note that in order to model the complete picture, the module in question should also
have a BswModuleDescription.bswModuleDependency.expectedEntry2 refer-
ring to
AUTOSAR_Dem/BswModuleEntrys/Dem_SetEventStatus

and one more BswModuleCallPoints representing the calls into

Dem_SetEventStatus(). This additional information is not mandatory to con-
figure the DEM, but it can be used for documentation and call tree or timing analysis.

2
This shall be modeled differently, if the call crosses partition boundaries, see 4.6.2

261 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

If the diagnostic event is associated with a callback routine to be called by the DEM
and implemented by the module in question, this shall also be modeled by a BswMod-
uleEntry which is referred as BswServiceDependency.assignedEntryRole.
This holds namely for the standardized callback InitMonitorForEvent specified
in [SWS_Dem_00256]:
[TPS_BSWMDT_04112] BswServiceDependency refers to InitMonitor-
ForEvent dIf a module implements the callback InitMonitorForEvent, a
BswModuleEntry shall be defined with
• shortName = Service name as defined in [SWS_Dem_00256]
The BswServiceDependency representing this diagnostic event shall refer to this
BswModuleEntry via its assignedEntry and its assignedEntryRole shall have
the value InitMonitorForEvent.c(RS_BSWMD_00045, RS_BSWMD_00069)
Note that in order to model the complete picture for such a callback, the module
in question should also have a BswModuleDescription.bswModuleDependency.
implementedEntry3 referring to the BswModuleEntry that describes the callback
signature and a BswModuleEntity representing the implementation of the callback.
This additional information is not mandatory to configure the DEM, but it can be used
for documentation and call tree or timing analysis.

12.4 Error Tracer Needs

The meta-class ErrorTracerNeeds is used to define requirements in order to con-
figure the Default Error Tracer and to implement the according transient fault handler.
Identifiable +tracedFailure ServiceNeeds
TracedFailure ErrorTracerNeeds
0..* «atpVariation,atpSplitable»
+ id: PositiveInteger [0..1]

  
     

DevelopmentError RuntimeError

Figure 12.6: Modeling of ErrorTracerNeeds

[constr_4092] Number of ErrorTracerNeeds in BswInternalBehavior dA

BswInternalBehavior shall provide at most one ErrorTracerNeeds element.c()
This ErrorTracerNeeds element provides the exhaustive list of all tracedFail-
ures implemented in the BSW module. Each tracedFailure relates to one ID. For
more suggestion see Specification of Default Error Tracer [27].

3
This shall be modeled differently, if the call crosses partition boundaries, see 4.6.2

262 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ErrorTracerNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the need to report failures to the error tracer.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
tracedFailure TracedFailure * aggr list of traced failures
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=tracedFailure.shortName, traced
Failure.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 12.36: ErrorTracerNeeds

Class TracedFailure (abstract)

Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the ability to report a specific failure to the error tracer. The short name specifies the literal
applicable for the Default Error Tracer.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses DevelopmentError, RuntimeError, TransientFault
Aggregated by ErrorTracerNeeds.tracedFailure
Attribute Type Mult. Kind Note
id PositiveInteger 0..1 attr ID of detected failure used in reporting API as error or
fault id.
Table 12.37: TracedFailure

Class DevelopmentError
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note The reported failure is classified as development error.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, TracedFailure
Aggregated by ErrorTracerNeeds.tracedFailure
Attribute Type Mult. Kind Note
– – – – –
Table 12.38: DevelopmentError

Class RuntimeError
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note The reported failure is classified as runtime error.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, TracedFailure
Aggregated by ErrorTracerNeeds.tracedFailure
Attribute Type Mult. Kind Note
– – – – –
Table 12.39: RuntimeError

263 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.4.1 Default Error Tracer Service use Case: report failure

[TPS_BSWMDT_04152] Setup for Default Error Tracer Service use Case: report
failure: d Scenario: a Basic Software Module reports a failure to the Default Error
Tracer. In this case the following setup apply:
ServiceNeeds kind ErrorTracerNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• Det_ReportError [0..1]
• Det_ReportRuntimeError [0..1]
• Det_ReportTransientFault [0..1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

12.5 Hardware Test Manager

This meta-class represents the ability to indicate that a Basic Software Module is
interested in the results of the hardware test and will establish a BswModuleEntry to
query the hardware test manager HtssM.
Identifiable
ServiceNeeds

HardwareTestNeeds

Figure 12.7: Modeling of HardwareTestNeeds

Class HardwareTestNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to indicate that a software-component is interested in the results of
the hardware test and will establish a PortPrototype to query the hardware test manager.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table 12.40: HardwareTestNeeds

264 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

12.5.1 HtssM Service Use Case: Query results of hardware tests

Scenario: a Basic Software Module offers a BswModuleEntry to query the re-

sults of hardware tests conducted by the HtssM.
[TPS_BSWMDT_04171] HtssM Service Use Case: Query results of hardware tests
d
ServiceNeeds kind : HardwareTestNeeds
RoleBasedBswModuleEntryAssignment valid roles:
• GetTestStatus [1]
RoleBasedDataAssignment
N/A
RoleBasedDataTypeAssignment
N/A
c()

265 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

A Reference Material

A.1 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
BSW Basic Software
BSWMD Basic Software Module Description
BSWMDT Basic Software Module Description Template
DEM Diagnostic Event Manager
ECU Electronic Control Unit
ECUC ECU Configuration
ICC1, ICC2, ICC3 AUTOSAR Implementation Conformance Class 1...3
ISR Interrupt Service Routine
ICS Implementation Conformance Statement
IOC Inter OS-Application Communication
MC Measurement and Calibration
MSR Manufacturer Supplier Relationship
NvM Non Volatile Memory
NVRAM Non Volatile RAM
OS Operating System
RAM Random Access Memory
ROM Read-only Memory
SWC Software Component
SWS Software Specification
SWCT Software Component Template
UML Unified Modeling Language
ARXML AUTOSAR XML
XML Extensible Markup Language

Table A.1: Abbreviations used in the scope of this Document

A.2 Requirements Traceability

The following table references the requirements specified in [28] and denotes how they
are satisfied in this document.
Requirement Description Satisfied by
[RS_BSWMD_00001] Main source of information on BSW [TPS_BSWMDT_04000] [TPS_BSWMDT_04001]
Module ECU Configuration activity [TPS_BSWMDT_04016] [TPS_BSWMDT_04017]
and integration [TPS_BSWMDT_04030] [TPS_BSWMDT_04031]
[TPS_BSWMDT_04036] [TPS_BSWMDT_04039]
[TPS_BSWMDT_04040] [TPS_BSWMDT_04045]
[TPS_BSWMDT_04071] [TPS_BSWMDT_04079]
[TPS_BSWMDT_04085] [TPS_BSWMDT_04086]
5

266 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Requirement Description Satisfied by
[RS_BSWMD_00005] Description of the memory needs of [TPS_BSWMDT_04045] [TPS_BSWMDT_04046]
the software implementation [TPS_BSWMDT_04048] [TPS_BSWMDT_04049]
[TPS_BSWMDT_04080]
[RS_BSWMD_00007] Provide vendor-specific published [TPS_BSWMDT_04033] [TPS_BSWMDT_04034]
information
[RS_BSWMD_00008] BSW Module Description SHALL be [TPS_BSWMDT_04126]
tool processable
[RS_BSWMD_00009] Description of peripheral register [TPS_BSWMDT_04032]
usage
[RS_BSWMD_00010] Compiler version and settings [TPS_BSWMDT_04043] [TPS_BSWMDT_04068]
[RS_BSWMD_00011] Guaranteed execution context of API [TPS_BSWMDT_04007] [TPS_BSWMDT_04156]
calls
[RS_BSWMD_00013] Describe configuration class of ECU [TPS_BSWMDT_04076]
Configuration Parameters
[RS_BSWMD_00014] Support of BSW Module clusters [TPS_BSWMDT_04020] [TPS_BSWMDT_04047]
[TPS_BSWMDT_04049] [TPS_BSWMDT_04071]
[RS_BSWMD_00015] Timing requirements [TPS_BSWMDT_04077]
[RS_BSWMD_00016] Timing guarantees [TPS_BSWMDT_04050] [TPS_BSWMDT_04051]
[TPS_BSWMDT_04052] [TPS_BSWMDT_04053]
[TPS_BSWMDT_04054] [TPS_BSWMDT_04055]
[TPS_BSWMDT_04077]
[RS_BSWMD_00024] Support description of module [TPS_BSWMDT_04035] [TPS_BSWMDT_04069]
specific published information
[RS_BSWMD_00025] Support for shipment information [TPS_BSWMDT_04001] [TPS_BSWMDT_04030]
[TPS_BSWMDT_04031] [TPS_BSWMDT_04040]
[TPS_BSWMDT_04068] [TPS_BSWMDT_04085]
[TPS_BSWMDT_04086] [TPS_BSWMDT_04092]
[TPS_BSWMDT_04097]
[RS_BSWMD_00026] Description of supported hardware [TPS_BSWMDT_04032] [TPS_BSWMDT_04068]
[RS_BSWMD_00027] Provide Vendor-Specific Module [TPS_BSWMDT_04033] [TPS_BSWMDT_04069]
Definition
[RS_BSWMD_00028] Development according to the [TPS_BSWMDT_04016] [TPS_BSWMDT_04017]
AUTOSAR Generic Structure [TPS_BSWMDT_04126]
Template document
[RS_BSWMD_00029] Transformation of BSWMD template [TPS_BSWMDT_04126]
modeling according to the AUTOSAR
XML Schema Production Rules
[RS_BSWMD_00030] Publish resource needs for the BSW [TPS_BSWMDT_04006] [TPS_BSWMDT_04019]
Scheduler [TPS_BSWMDT_04020] [TPS_BSWMDT_04027]
[TPS_BSWMDT_04067] [TPS_BSWMDT_04072]
[TPS_BSWMDT_04128]
[RS_BSWMD_00031] Description of used memory section [TPS_BSWMDT_04046] [TPS_BSWMDT_04047]
names [TPS_BSWMDT_04049] [TPS_BSWMDT_04080]
[RS_BSWMD_00032] Recommended ECU Configuration [TPS_BSWMDT_04034]
Values
[RS_BSWMD_00033] Pre-configured ECU Configuration [TPS_BSWMDT_04034] [TPS_BSWMDT_04035]
Values
[RS_BSWMD_00034] ECU Configuration Editor and [TPS_BSWMDT_04041] [TPS_BSWMDT_04042]
Generation supported tool version
information
[RS_BSWMD_00035] Provide Standardized Module [TPS_BSWMDT_04033] [TPS_BSWMDT_04069]
Definition
[RS_BSWMD_00037] Needed libraries [TPS_BSWMDT_04041] [TPS_BSWMDT_04042]
5

267 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Requirement Description Satisfied by
[RS_BSWMD_00038] Required execution context of API [TPS_BSWMDT_04007] [TPS_BSWMDT_04156]
calls
[RS_BSWMD_00039] Identification of implemented API and [TPS_BSWMDT_04000] [TPS_BSWMDT_04002]
functions [TPS_BSWMDT_04008] [TPS_BSWMDT_04009]
[TPS_BSWMDT_04028] [TPS_BSWMDT_04066]
[TPS_BSWMDT_04130] [TPS_BSWMDT_04153]
[RS_BSWMD_00040] Identification of required API and [TPS_BSWMDT_04008] [TPS_BSWMDT_04009]
functions [TPS_BSWMDT_04066]
[RS_BSWMD_00041] Declaration of the provided API [TPS_BSWMDT_04002] [TPS_BSWMDT_04007]
argument data types [TPS_BSWMDT_04009] [TPS_BSWMDT_04010]
[TPS_BSWMDT_04011] [TPS_BSWMDT_04012]
[TPS_BSWMDT_04066] [TPS_BSWMDT_04091]
[TPS_BSWMDT_04130] [TPS_BSWMDT_04153]
[TPS_BSWMDT_04156]
[RS_BSWMD_00042] Description of the required API [TPS_BSWMDT_04007] [TPS_BSWMDT_04009]
argument data types [TPS_BSWMDT_04010] [TPS_BSWMDT_04011]
[TPS_BSWMDT_04012] [TPS_BSWMDT_04066]
[TPS_BSWMDT_04091] [TPS_BSWMDT_04156]
[RS_BSWMD_00043] Support description of common [TPS_BSWMDT_04030] [TPS_BSWMDT_04031]
published information [TPS_BSWMDT_04035]
[RS_BSWMD_00044] Description of generated artifacts [TPS_BSWMDT_04041] [TPS_BSWMDT_04042]
[RS_BSWMD_00045] Publish resources needed from [TPS_BSWMDT_04026] [TPS_BSWMDT_04029]
AUTOSAR Services [TPS_BSWMDT_04110] [TPS_BSWMDT_04111]
[TPS_BSWMDT_04112] [TPS_BSWMDT_04113]
[TPS_BSWMDT_04127]
[RS_BSWMD_00046] Publish OS resource usage [TPS_BSWMDT_04006] [TPS_BSWMDT_04072]
[RS_BSWMD_00047] Modeling of call-chain dependencies [TPS_BSWMDT_04018]
between BSW Modules
[RS_BSWMD_00048] Tagging of Vendor-Specific Module [TPS_BSWMDT_04076]
Definition
[RS_BSWMD_00049] Describe optional and required [TPS_BSWMDT_04063] [TPS_BSWMDT_04064]
elements [TPS_BSWMDT_04065] [TPS_BSWMDT_04070]
[TPS_BSWMDT_04090]
[RS_BSWMD_00050] Allow vendor-specific modification of [TPS_BSWMDT_04033]
Standardized Module Definition
[RS_BSWMD_00051] Description of libraries [TPS_BSWMDT_04071]
[RS_BSWMD_00052] Description of the generated RTE [TPS_BSWMDT_04026] [TPS_BSWMDT_04048]
[RS_BSWMD_00053] Cyclic time based scheduling of BSW [TPS_BSWMDT_04021] [TPS_BSWMDT_04022]
Main Functions [TPS_BSWMDT_04023]
[RS_BSWMD_00054] Mode Switches for BSW modules [TPS_BSWMDT_04004] [TPS_BSWMDT_04013]
shall be supported [TPS_BSWMDT_04021] [TPS_BSWMDT_04025]
[RS_BSWMD_00055] Simultaneous Mode transitions [TPS_BSWMDT_04000] [TPS_BSWMDT_04074]
[RS_BSWMD_00056] API for Mode switch notification of [TPS_BSWMDT_04004] [TPS_BSWMDT_04013]
BSW modules [TPS_BSWMDT_04014] [TPS_BSWMDT_04019]
[TPS_BSWMDT_04025]
[RS_BSWMD_00057] Triggering of BSW Main Functions by [TPS_BSWMDT_04005] [TPS_BSWMDT_04015]
Triggered Events [TPS_BSWMDT_04021] [TPS_BSWMDT_04023]
[TPS_BSWMDT_04024]
[RS_BSWMD_00058] Simultaneous Triggering by Triggered [TPS_BSWMDT_04000] [TPS_BSWMDT_04074]
Events
[RS_BSWMD_00059] API for Triggering BSW modules by [TPS_BSWMDT_04015] [TPS_BSWMDT_04019]
Triggered Events
5

268 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Requirement Description Satisfied by
[RS_BSWMD_00060] Support exclusive areas in BSW [TPS_BSWMDT_04073]
Modules and Application Software
Components
[RS_BSWMD_00062] Provide Measurement and [TPS_BSWMDT_04026] [TPS_BSWMDT_04027]
Calibration Support [TPS_BSWMDT_04056] [TPS_BSWMDT_04057]
[TPS_BSWMDT_04058] [TPS_BSWMDT_04059]
[TPS_BSWMDT_04060] [TPS_BSWMDT_04061]
[TPS_BSWMDT_04062] [TPS_BSWMDT_04078]
[TPS_BSWMDT_04087] [TPS_BSWMDT_04088]
[TPS_BSWMDT_04114] [TPS_BSWMDT_04115]
[TPS_BSWMDT_04128] [TPS_BSWMDT_04168]
[TPS_BSWMDT_04169] [TPS_BSWMDT_04170]
[TPS_BSWMDT_04174] [TPS_BSWMDT_04175]
[TPS_BSWMDT_04176] [TPS_BSWMDT_04177]
[TPS_BSWMDT_04178]
[RS_BSWMD_00063] Allow enabling of providing Activating [TPS_BSWMDT_04089]
Bsw Event API
[RS_BSWMD_00064] Support optional configuration of [TPS_BSWMDT_04081] [TPS_BSWMDT_04082]
ExclusiveArea usage within [TPS_BSWMDT_04083] [TPS_BSWMDT_04084]
BSWModuleEntities [TPS_BSWMDT_04154] [TPS_BSWMDT_04155]
[RS_BSWMD_00065] Provide Rapid Prototyping Support [TPS_BSWMDT_04094] [TPS_BSWMDT_04095]
[TPS_BSWMDT_04096] [TPS_BSWMDT_04159]
[TPS_BSWMDT_04160] [TPS_BSWMDT_04161]
[TPS_BSWMDT_04162] [TPS_BSWMDT_04163]
[TPS_BSWMDT_04164]
[RS_BSWMD_00066] BSW inter-partition client-server [TPS_BSWMDT_04098] [TPS_BSWMDT_04099]
communication [TPS_BSWMDT_04100] [TPS_BSWMDT_04102]
[TPS_BSWMDT_04103] [TPS_BSWMDT_04104]
[TPS_BSWMDT_04105]
[RS_BSWMD_00067] BSW inter-partition sender-receiver [TPS_BSWMDT_04101] [TPS_BSWMDT_04106]
communication [TPS_BSWMDT_04107]
[RS_BSWMD_00068] BSW Service Execution on Local or [TPS_BSWMDT_04108] [TPS_BSWMDT_04109]
Remote Partition
[RS_BSWMD_00069] Configuration for production errors [TPS_BSWMDT_04110] [TPS_BSWMDT_04111]
and extended production errors [TPS_BSWMDT_04112]

Table A.2: RequirementsTracing

Some input requirements cannot (or not completely) be traced down to single specifi-
cation items found in this document. They are satisfied by BSWMDT in a general way
together with other documents as listed in the following:
[TPS_BSWMDT_04126] General meta-model methodology dThese requirements
are implicitly fulfilled because the BSWMDT follows the general methodology of the
AUTOSAR meta-model defined in [1] and [8].c(RS_BSWMD_00008, RS_BSWMD_-
00028, RS_BSWMD_00029)
[TPS_BSWMDT_04076] ECUC features dThese requirements are fulfilled by
BSWMDT in general due to the possibility of linking ECU configuration artifacts with
a BSWMD. For the specific features see [16].c(RS_BSWMD_00013, RS_BSWMD_-
00048)
[TPS_BSWMDT_04077] Timing requirements and guarantees dThese require-
ments are fulfilled by the Specification of Timing Extensions, see [18] due to the fact,
that timing models can be linked to a BSWMD. The BSWMDT supports this by the

269 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

specification of meta-model elements for execution time values.c(RS_BSWMD_00015,

RS_BSWMD_00016)

270 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

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

271 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

AUTOSAR Partial Model In AUTOSAR, the possible partitioning of models is marked

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

272 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

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

273 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

This is implemented by vh.LatestBindingtime at the related properties.

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

274 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C Constraint and Specification History

C.1 Constraint History of this Document according to AUTOSAR

R4.0.1

C.1.1 Changed Constraints in R4.0.1

N/A

C.1.2 Added Constraints in R4.0.1

Number Heading
[constr_4013] BSW service identifier
[constr_4014] Call type and execution context
[constr_4015] calledEntry constraints
[constr_4016] BswCalledEntity constraints
[constr_4017] BswSchedulableEntity constraints
[constr_4018] BswInterruptEntity constraints
[constr_4019] BSW module identifier
[constr_4020] Categories of BswModuleDescription
[constr_4021] Implementation policy of function pointer target1
[constr_4022] BswModuleEntry only uses the module’s interface
[constr_4023] External trigger shall belong to the interface
[constr_4024] Semantics of BSW mode switch event
[constr_4025] Modes used by BSW mode switch event
[constr_4026] Mode group used by BSW mode switch acknowledge event
[constr_4028] Semantics of memory section type
[constr_4029] Measured stack usage
[constr_4030] Measured heap usage
[constr_4031] Analyzed execution time
[constr_4032] Measured execution time
[constr_4033] Simulated execution time
[constr_4034] Target and context of MC emulation reference
[constr_4036] Entries linked to BswModuleDescription
[constr_4037] Entries linked to BswModuleDependency
[constr_4038] bswModuleDependency shall refer to a different module
[constr_4039] Semantics of SwcBswMapping
[constr_4040] Synchronized mode groups shall have same type
[constr_4041] Synchronized mode groups shall have same context
[constr_4042] Synchronized triggers shall have same context
[constr_4043] Period of BswTimingEvent
[constr_4044] Content of McSwEmulationMethodSupport
[constr_4045] implementationConfigVariant of preconfigured configuration
[constr_4046] implementationConfigVariant of recommended configuration

Table C.1: Added Constraints in R4.0.1

1
this constraint was by mistake named Bsw service identifier in R4.0.1 and R4.0.2

275 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.1.3 Deleted Constraints

N/A

C.2 Constraint History of this Document according to AUTOSAR

R4.0.2

C.2.1 Changed Constraints in R4.0.2

N/A

C.2.2 Added Constraints in R4.0.2

Number Heading
[constr_4047] Multiplicity of vendor specific configuration parameters
[constr_4048] Multiplicity of preconfigured values

Table C.2: Added Constraints in R4.0.2

C.2.3 Deleted Constraints in R4.0.2

N/A

C.3 Constraint History of this Document according to AUTOSAR

R4.0.3

C.3.1 Changed Constraints in R4.0.3

N/A

C.3.2 Added Specification Items in R4.0.3

Number Heading
[TPS_BSWMDT_04000] BSW modules with AUTOSAR Interfaces
[TPS_BSWMDT_04001] Attaching SwComponentDocumentation to a BSWMD
[TPS_BSWMDT_04002] Usage of BswModuleEntry
[TPS_BSWMDT_04003] BswModuleDependency
[TPS_BSWMDT_04004] BswModuleDescription.providedModeGroup
[TPS_BSWMDT_04005] BswModuleDescription.releasedTrigger
[TPS_BSWMDT_04006] BswModuleDescription.internalBehavior
[TPS_BSWMDT_04007] BswModuleEntry

276 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04008] C-symbol of BswModuleEntry

[TPS_BSWMDT_04009] Usage of SwServiceArg
[TPS_BSWMDT_04010]
SwServiceArg.swDataDefProps.implementationDataType
[TPS_BSWMDT_04011]
SwServiceArg.swDataDefProps.swPointerTargetProps
[TPS_BSWMDT_04012] SwServiceArg.direction
[TPS_BSWMDT_04014] ModeRequestTypeMap in BSW
[TPS_BSWMDT_04015] Usage of Trigger in BSW
[TPS_BSWMDT_04016] Location of standardized BswModuleEntrys
[TPS_BSWMDT_04017] Reference to standardized BswModuleEntry-s
[TPS_BSWMDT_04018] BswDirectCallPoint.calledEntry
[TPS_BSWMDT_04019] BswModuleEntity attributes
[TPS_BSWMDT_04020] Usage of BswSchedulerNamePrefix
[TPS_BSWMDT_04021] Usage of BswEvent
[TPS_BSWMDT_04022] Timing and background events for BSW
[TPS_BSWMDT_04023] Internal trigger and timing events for BSW
[TPS_BSWMDT_04024] External trigger event for BSW
[TPS_BSWMDT_04025] Mode switches and events in BSW
[TPS_BSWMDT_04026] Local BSW data without RTE or BSW Scheduler support
[TPS_BSWMDT_04027] Local BSW data accessed via BSW Scheduler API
[TPS_BSWMDT_04028] Determination of argument names for BSW functions called via ports
[TPS_BSWMDT_04029] Usage of BswServiceDependency
[TPS_BSWMDT_04030] BswImplementation.arReleaseVersion
[TPS_BSWMDT_04031] Instances of BswImplementation
[TPS_BSWMDT_04032] Implementation.hwElement
[TPS_BSWMDT_04033] Reference to vendor specific configuration parameters
[TPS_BSWMDT_04034] Reference to predefined or recommended configuration values
[TPS_BSWMDT_04035] Published parameter values
[TPS_BSWMDT_04036] Back-reference from EcucModuleConfigurationValues
[TPS_BSWMDT_04039] Association of an Implementation with a component or module
[TPS_BSWMDT_04040] Implementation.codeDescriptor
[TPS_BSWMDT_04041] DependencyOnArtifact
[TPS_BSWMDT_04042] Usage of DependencyOnArtifact
[TPS_BSWMDT_04043] Compiler
[TPS_BSWMDT_04044] Linker
[TPS_BSWMDT_04045] Implementation.resourceConsumption
[TPS_BSWMDT_04046] Memory section name
[TPS_BSWMDT_04047] Memory section prefix
[TPS_BSWMDT_04048] Scope of declared memory sections
[TPS_BSWMDT_04049] Usage of MemorySection.executableEntity
[TPS_BSWMDT_04050] ExecutionTime
[TPS_BSWMDT_04051] ExecutionTime references an ECU
[TPS_BSWMDT_04052] ExecutionTime.hardwareConfiguration
[TPS_BSWMDT_04053] ExecutionTime.memorySectionLocation
[TPS_BSWMDT_04054] ExecutionTime.softwareContext
[TPS_BSWMDT_04055] ExecutionTime.includedLibrary
[TPS_BSWMDT_04056] Multiplicity of McSupportData
[TPS_BSWMDT_04057] Self-contained MC support artifact
[TPS_BSWMDT_04058] McSupportData.measurableSystemConstantValues
[TPS_BSWMDT_04059] Granularity of McDataInstance.subElements
[TPS_BSWMDT_04060] McDataInstance.resultingProperties
[TPS_BSWMDT_04061] McSwEmulationMethodSupport.category

277 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04062] Upstream reference for emulation support

[TPS_BSWMDT_04063] BSW Interface Variation Points
[TPS_BSWMDT_04064] BSW Behavior Variation Points
[TPS_BSWMDT_04065] BSW Implementation Variation Points
[TPS_BSWMDT_04066] Relevant elements for ICS on Interface level
[TPS_BSWMDT_04067] No relevant elements for ICS on Internal Behavior level
[TPS_BSWMDT_04068] Relevant elements for ICS on Implementation level
[TPS_BSWMDT_04069] Configuration in ICS
[TPS_BSWMDT_04070] No variants in ICS

Table C.3: Added Specification Items in 4.0.3

C.3.3 Added Constraints in R4.0.3

Number Heading
[constr_4051] RoleBasedDataAssignment in BSW
[constr_4052] BswModuleEntry returnType direction
[constr_4053] BswModuleEntry argument direction
[constr_4054] Unambiguous links to addressing method
[constr_4056] BswModuleEntry with no returnType
[constr_4057] BswModuleEntry with no argument
[constr_4058] Different mode groups in mapped BSWM and SWC shall have different names
[constr_4059] Different mode groups referred by a BSWM shall have different names
[constr_4060] Allowed values of Trigger.swImplPolicy for BSW
[constr_4061] Completeness of MC emulation reference
[constr_4062] Mandatory symbol for McDataInstance root
[constr_4063] Restrictions of ModeRequestTypeMap in BSW
[constr_4064] Synchronized triggers shall implement same policy
[constr_4065] Allowed values of BswInternalTriggeringPoint.swImplPolicy

Table C.4: Added Constraints in R4.0.3

C.3.4 Deleted Constraints in R4.0.3

N/A

C.4 Constraint History of this Document according to AUTOSAR

R4.1.1

C.4.1 Changed Specification Items in R4.1.1

Number Heading
[TPS_BSWMDT_04021] Usage of BswEvent
[TPS_BSWMDT_04025] Mode switches and events in BSW
[TPS_BSWMDT_04057] Self-contained MC support artifact
[TPS_BSWMDT_04063] BSW Interface Variation Points
[TPS_BSWMDT_04064] BSW Behavior Variation Points

Table C.5: Changed Specification Items in 4.1.1

278 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.4.2 Changed Constraints in R4.1.1

Number Heading
[constr_4015] calledEntry constraints for direct calls
[constr_4022] BswModuleEntry only uses the module’s interface

Table C.6: Changed Constraints in R4.1.1

C.4.3 Added Specification Items in R4.1.1

Number Heading
[TPS_BSWMDT_04071] Usage of module identifier and category
[TPS_BSWMDT_04072] Executable entity in BSW
[TPS_BSWMDT_04073] Exclusive area in BSW
[TPS_BSWMDT_04074] Synchronization of mode switches or triggers
[TPS_BSWMDT_04075] RunnableEntity in BSW for RTE access
[TPS_BSWMDT_04126] General meta-model methodology
[TPS_BSWMDT_04076] ECUC features
[TPS_BSWMDT_04077] Timing requirements and guarantees
[TPS_BSWMDT_04078] Semantics of McFunction
[TPS_BSWMDT_04079] Usage of module shortName
[TPS_BSWMDT_04080] Options for inline code sections
[TPS_BSWMDT_04081] ExclusiveAreaNestingOrder
[TPS_BSWMDT_04082] Indicate that the locking behavior is fully described for BswModuleEn-
tity
[TPS_BSWMDT_04083] Locking behavior is not described for BswModuleEntity-s
[TPS_BSWMDT_04084] Relation of BswModuleCallPoint to ExclusiveAreaNestin-
gOrder
[TPS_BSWMDT_04085] Implementation refers to a BuildActionManifest
[TPS_BSWMDT_04086] Artifacts referred in Implementation and/or BuildActionMani-
fest
[TPS_BSWMDT_04087] Scope of McFunctionDataRefSets
[TPS_BSWMDT_04088] Usage of McFunction
[TPS_BSWMDT_04089] Access to activation reason
[TPS_BSWMDT_04090] Variation Points for BswModuleEntry arguments
[TPS_BSWMDT_04091] Function signature containing the keyword enum in C
[TPS_BSWMDT_04092] Provide memory mapping header file names
[TPS_BSWMDT_04093] Memory classes for compiler abstraction
[TPS_BSWMDT_04094] Details of McDataInstance for rapid prototyping
[TPS_BSWMDT_04095] Relationships between McDataInstances
[TPS_BSWMDT_04096] Split between different use cases of McSupportData
[TPS_BSWMDT_04097] Assigning different header files per section prefix
[TPS_BSWMDT_04098] Declaration of BswModuleClientServerEntry
[TPS_BSWMDT_04099] Semantics of BswModuleClientServerEntry attributes
[TPS_BSWMDT_04100] Different ways of referring BswModuleEntry
[TPS_BSWMDT_04101] Declaration of providedData and requiredData
[TPS_BSWMDT_04102] Usage of BswSynchronousServerCallPoint
[TPS_BSWMDT_04103] BswModuleEntity reentrancy level
[TPS_BSWMDT_04104] Usage of BswAsynchronousServerCallPoint
[TPS_BSWMDT_04105] Usage of BswAsynchronousServerCallResultPoint
[TPS_BSWMDT_04106] BswModuleEntity attributes for sender-receiver data exchange
[TPS_BSWMDT_04107] Data reception policy

279 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04108] BswInternalBehavior containing BswModuleEntity-s executed

on different partitions
[TPS_BSWMDT_04109] BswInternalBehavior for the same AUTOSAR Service provided
on different partitions
[TPS_BSWMDT_04110] Declaration of production errors
[TPS_BSWMDT_04111] BswServiceDependency refers to Dem_SetEventStatus()
[TPS_BSWMDT_04112] BswServiceDependency refers to InitMonitorForEvent
[TPS_BSWMDT_04113] Rule for setting RoleBasedPortAssignment.role
[TPS_BSWMDT_04114] Use the hierarchical structuring of McDataInstance.subElements
[TPS_BSWMDT_04115] Use of indexing for array element of subElements

Table C.7: Added Specification Items in 4.1.1

C.4.4 Added Constraints in R4.1.1

Number Heading
[constr_1275] Applicability of reference startsOnEvent for BswScheduleEvent
[constr_1276] Applicability of reference startsOnEvent for BswOperationInvokedEvent
[constr_4066] BswModeSwitchEvent and the definition of ModeTransition
[constr_4067] Exclusive usage of data references in McFunctionDataRefSet
[constr_4068] Semantics of McFunctionDataRefSet.flatMapEntry
[constr_4069] Semantics of McFunctionDataRefSet.mcDataInstance
[constr_4070] Applicability of BswModuleEntity.activationReason
[constr_4071] Synchronized runnables and schedulable entities shall be consistent
[constr_4072] Constraints of SectionNamePrefix.implementedIn
[constr_4073] McDataAccessDetails shall refer to one ECU Extract
[constr_4074] Compatibility of BswModuleClientServerEntry-s
[constr_4075] Constraints for providedData and requiredData
[constr_4076] Constraints on BswModuleEntry used for Client-Server
[constr_4077] Constraints for BswModuleEntity.reentrancyLevel
[constr_4078] Consistent usage of BswOperationInvokedEvent
[constr_4079] calledEntry constraints for client-server calls
[constr_4080] Existence of reception policy
[constr_4081] Mode group used by BSW mode manager error event
[constr_4083] BswDistinguishedPartition shall be used only in the context of a particular
BswInternalBehavior
[constr_4084] Consistency of references of InternalBehavior
[constr_4085] Consistency of references of InternalBehavior

Table C.8: Added Constraints in R4.1.1

C.4.5 Deleted Specification Items in R4.1.1

N/A

C.4.6 Deleted Constraints in R4.1.1

N/A

280 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.5 Constraint History of this Document according to AUTOSAR

R4.2.1

C.5.1 Changed Constraints in R4.2.1

N/A

C.5.2 Added Constraints in R4.2.1

Number Heading
[constr_4086] invocation of ExecutableEntitys by direct function call dependent from BswExe-
cutionContext
[constr_4087] Usage of category "MACRO"
[constr_4088] Existence of RoleBasedDataTypeAssignment.role vs. RoleBasedDataAs-
signment.role

Table C.9: Added Constraints in R4.2.1

C.5.3 Deleted Constraints in R4.2.1

N/A

C.5.4 Changed Specification Items in R4.2.1

Number Heading
[TPS_BSWMDT_04113] Rule for setting RoleBasedBswModuleEntryAssignment.role

Table C.10: Changed Specification Items in 4.2.1

C.5.5 Added Specification Items in R4.2.1

Number Heading
[TPS_BSWMDT_04116] Setup for Nvm Use Case: Permanent RAM Block
[TPS_BSWMDT_04117] Setup for Nvm Use Case: Temporary RAM Block
[TPS_BSWMDT_04118] Setup for Nvm Use Case: RAM Block synchronised with explicit syn-
chronisation
[TPS_BSWMDT_04119] Setup for Function Inhibition Manager Service use Case: read function
permission
[TPS_BSWMDT_04120] Basic Software Module implements a Diagnostic Monitor
[TPS_BSWMDT_04121] Basic Software Module offers BswModuleEntrys to read/write
current value via diagnostic services
[TPS_BSWMDT_04122] Basic Software Module offers BswModuleEntrys to start/stop
or request routines via diagnostic services
[TPS_BSWMDT_04123] Basic Software Module offers BswModuleEntrys BswMod-
uleEntrys to adjust the IO signal via diagnostic services

281 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04124] Basic Software Module offers BswModuleEntrys to access

protocol, session and security information
[TPS_BSWMDT_04125] Basic Software Module offers BswModuleEntrys for the Seed
adn Key handling for security level access

Table C.11: Added Specification Items in 4.2.1

C.5.6 Deleted Specification Items in R4.2.1

N/A

C.6 Constraint History of this Document according to AUTOSAR

R4.2.2

C.6.1 Added Specification Items in 4.2.2

Id Heading
[TPS_BSWMDT_04076] ECUC features
[TPS_BSWMDT_04077] Timing requirements and guarantees
[TPS_BSWMDT_04116] Setup for Nvm Use Case: Permanent RAM Block
[TPS_BSWMDT_04117] Setup for Nvm Use Case: Temporary RAM Block
[TPS_BSWMDT_04118] Setup for Nvm Use Case: RAM Block synchronised with explicit syn-
chronization
[TPS_BSWMDT_04126] General meta-model methodology
[TPS_BSWMDT_04127] Callback header declarations
[TPS_BSWMDT_04128] BSW measurement data accessed via BSW Scheduler API

Table C.12: Added Traceables in 4.2.2

C.6.2 Changed Specification Items in 4.2.2

Id Heading
[TPS_BSWMDT_04027] Local BSW data accessed via BSW Scheduler API

Table C.13: Changed Traceables in 4.2.2

C.6.3 Deleted Specification Items in 4.2.2

Id Heading
[TPS_BSWMDT_04116] Setup for Nvm Use Case: Permanent RAM Block
[TPS_BSWMDT_04117] Setup for Nvm Use Case: Temporary RAM Block
[TPS_BSWMDT_04118] Setup for Nvm Use Case: RAM Block synchronised with explicit syn-
chronization
[TPS_BSWMDT_GEN] General meta-model methodology
[TPS_BSWMDT_GEN_- ECUC features
04076]

282 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_GEN_- Timing requirements and guarantees

04077]

Table C.14: Deleted Traceables in 4.2.2

C.6.4 Added Constraints in 4.2.2

Id Heading
[constr_4089] Association callbackHeader is only applicable for BSW modules
[constr_4090] The callbackHeader reference has to be consistent with behavior reference

Table C.15: Added Constraints in 4.2.2

C.6.5 Changed Constraints in 4.2.2

none

C.6.6 Deleted Constraints in 4.2.2

none

C.7 Constraint History of this Document according to AUTOSAR

R4.3.0

C.7.1 Added Specification Items in 4.3.0

Id Heading
[TPS_BSWMDT_04129] Definition a Supervised Entity in a Basic Software Module
[TPS_BSWMDT_04130] Linkage of BswModuleEntry
[TPS_BSWMDT_04131] Basic Software Module reads the current ECU mode (fixed vari-
ant)
[TPS_BSWMDT_04132] Basic Software Module shall keep the ECU alive (fixed variant)
[TPS_BSWMDT_04133] Basic Software Module wants to select a shutdown target (fixed
variant)
[TPS_BSWMDT_04134] Basic Software Module wants to select a boot target (fixed vari-
ant)
[TPS_BSWMDT_04135] Basic Software Module wants to select a shutdown target (flexi-
ble variant)
[TPS_BSWMDT_04136] Basic Software Module wants to select a boot target (flexible vari-
ant)
[TPS_BSWMDT_04137] Basic Software Module wants to use an alarm clock (flexible vari-
ant)
[TPS_BSWMDT_04138] Determination of the BswModuleEntry symbol
[TPS_BSWMDT_04139] Dem Use Case: Bsw Module implements a hardware shutdown
[TPS_BSWMDT_04140] AccessCount.value describes an intrinsic property
[TPS_BSWMDT_04141] The attribute countProfile denotes the counting rules

283 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04142] Standardized values of attribute countProfile

[TPS_BSWMDT_04143] countProfile DISTINGUISH_SINGULAR_ACCESSES, Explicit
Communication, single access
[TPS_BSWMDT_04144] countProfile DISTINGUISH_SINGULAR_ACCESSES, Explicit
Communication, multiple accesses
[TPS_BSWMDT_04145] countProfile DISTINGUISH_SINGULAR_ACCESSES, Implicit
Communication and parameter accesses, single access
[TPS_BSWMDT_04146] countProfile DISTINGUISH_SINGULAR_ACCESSES, Implicit
Communication and parameter accesses, multiple accesses
[TPS_BSWMDT_04147] countProfile DISTINGUISH_SINGULAR_ACCESSES, Server
calls, issued Triggers, Mode Switch Notifications, single access
[TPS_BSWMDT_04148] countProfile DISTINGUISH_SINGULAR_ACCESSES, Server
calls, issued Triggers, Mode Switch Notifications, multiple accesses
[TPS_BSWMDT_04149] Structuring according ExecutableEntitys
[TPS_BSWMDT_04150] Structuring according Variants
[TPS_BSWMDT_04151] Structuring according different countProfile definitions
[TPS_BSWMDT_04152] Setup for Default Error Tracer Service use Case: report failure:
[TPS_BSWMDT_04153] Usage of BswModuleEntry
[TPS_BSWMDT_04154] ExclusiveArea is entered and exit by common set of API
[TPS_BSWMDT_04155] ExclusiveArea is entered and exit by individual set of API
[TPS_BSWMDT_04156] Usage of functionPrototypeEmitter
[TPS_BSWMDT_04157] Definition of Checkpoints for a Supervised Entity in a Basic Soft-
ware Module
[TPS_BSWMDT_04158] Setup for a Basic Software Module which sets or gets Global Su-
pervision Status
[TPS_BSWMDT_04159] Standardized values of attribute RoleBasedMcDataAssignment.
role
[TPS_BSWMDT_04160] RptComponent represents a software component or basic software
module
[TPS_BSWMDT_04161] RptExecutableEntity represents a ExecutableEntity with
rapid prototyping support
[TPS_BSWMDT_04162] RptExecutableEntityEvent represents a RTEEvent or Bsw-
Event for with rapid prototyping support
[TPS_BSWMDT_04163] RptExecutionContext represents a common environment for a set
of RptExecutableEntitys or McDataInstances
[TPS_BSWMDT_04164] Description of implicit communication buffers

Table C.16: Added Traceables in 4.3.0

C.7.2 Changed Specification Items in 4.3.0

Id Heading
[TPS_BSWMDT_04002] Provision of BswModuleEntry
[TPS_BSWMDT_04010] SwServiceArg.swDataDefProps.implementationDataType
[TPS_BSWMDT_04011] SwServiceArg.swDataDefProps.swPointerTargetProps
[TPS_BSWMDT_04016] Location of standardized BswModuleEntry-s
[TPS_BSWMDT_04017] Reference to standardized BswModuleEntry-s
[TPS_BSWMDT_04025] Mode switches and events in BSW
[TPS_BSWMDT_04026] Local BSW data without RTE or BSW Scheduler support
[TPS_BSWMDT_04066] Relevant elements for ICS on Interface level
[TPS_BSWMDT_04087] Scope of McFunctionDataRefSets
[TPS_BSWMDT_04100] Different ways of referring BswModuleEntry
[TPS_BSWMDT_04111] BswServiceDependency refers to Dem_SetEventStatus()

284 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

[TPS_BSWMDT_04120] Basic Software Module implements a Diagnostic Monitor

[TPS_BSWMDT_04122] Basic Software Module offers BswModuleEntrys to start/stop
or request routines via diagnostic services
[TPS_BSWMDT_04128] BSW measurement data accessed via BSW Scheduler API

Table C.17: Changed Traceables in 4.3.0

C.7.3 Deleted Specification Items in 4.3.0

Id Heading
[TPS_BSWMDT_04003] BswModuleDependency
[TPS_BSWMDT_04037] BswDebugInfo
[TPS_BSWMDT_04038] Data types for debug data

Table C.18: Deleted Traceables in 4.3.0

C.7.4 Added Constraints in 4.3.0

Id Heading
[constr_4091] AccessCount.value needs to be unambiguous
[constr_4092] Number of ErrorTracerNeeds in BswInternalBehavior
[constr_4093] Entries linked to BswModuleEntrys shall have compatible signature
[constr_4094] compatibility of SwServiceArg in role returnType
[constr_4095] Compatibility of SwServiceArg in role argument
[constr_4096] Matching BswModuleEntrys should have compatible attributes
[constr_4097] Limitation on the number of BswExclusiveAreaPolicys

Table C.19: Added Constraints in 4.3.0

C.7.5 Changed Constraints in 4.3.0

Id Heading
[constr_4015] calledEntry constraints for direct calls
[constr_4020] Categories of BswModuleDescription
[constr_4021] Implementation policy of function pointer target
[constr_4022] BswModuleEntity only uses the module’s interface
[constr_4071] Synchronized runnables and schedulable entities must be consistent
[constr_4077] Constraints for BswModuleEntity.reentrancyLevel
[constr_4079] calledEntry constraints for client-server calls
[constr_4086] invocation of ExecutableEntitys by direct function call dependent from BswEx-
ecutionContext

Table C.20: Changed Constraints in 4.3.0

C.7.6 Deleted Constraints in 4.3.0

Id Heading
[constr_4036] Entries linked to BswModuleDescription
[constr_4037] Entries linked to BswModuleDependency

285 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Table C.21: Deleted Constraints in 4.3.0

C.8 Constraint History of this Document according to AUTOSAR

R4.3.1

C.8.1 Added Specification Items in 4.3.1

Number Heading
Basic Software Module offers BswModuleEntrys to read value
[TPS_BSWMDT_04165]
via OBD services
Basic Software Module offers BswModuleEntrys to read vehi-
[TPS_BSWMDT_04166]
cle information via OBD services
Setup for Function Inhibition Manager Service use Case: read function
[TPS_BSWMDT_04167]
permission
Table C.22: Added Specification Items in 4.3.1

C.8.2 Changed Specification Items in 4.3.1

Number Heading
Basic Software Module offers BswModuleEntrys for the Seed
[TPS_BSWMDT_04125] adn Key handling for security level access and the optional security
attempt counter handling
Table C.23: Changed Specification Items in 4.3.1

C.8.3 Deleted Specification Items in 4.3.1

none

C.8.4 Added Constraints in 4.3.1

Number Heading
[constr_4098] No mode disabling for BswOperationInvokedEvent
Table C.24: Added Constraints in 4.3.1

286 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.8.5 Changed Constraints in 4.3.1

none

C.8.6 Deleted Constraints in 4.3.1

none

C.9 Constraint History of this Document according to AUTOSAR

R4.4.0

C.9.1 Added Specification Items in 4.4.0

Number Heading
[TPS_BSWMDT_04168] Semantics of McGroup
[TPS_BSWMDT_04169] Scope of McGroupDataRefSets
[TPS_BSWMDT_04170] Usage of McGroup
[TPS_BSWMDT_04171] HtssM Service Use Case: Query results of hardware tests
Basic Software Module implements the ability to accept data for
upload and/or provide data for download. For this purpose the Basic
[TPS_BSWMDT_04172]
Software Module provides a BswModuleEntry that connects to
the Dcm service component.
Table C.25: Added Specification Items in 4.4.0

C.9.2 Changed Specification Items in 4.4.0

Number Heading
[TPS_BSWMDT_04032] Implementation.hwElement
Table C.26: Changed Specification Items in 4.4.0

287 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.9.3 Deleted Specification Items in 4.4.0

Number Heading
Basic Software Module reads the current ECU mode (fixed vari-
[TPS_BSWMDT_04131]
ant)
[TPS_BSWMDT_04132] Basic Software Module shall keep the ECU alive (fixed variant)
Basic Software Module wants to select a shutdown target (fixed
[TPS_BSWMDT_04133]
variant)
Basic Software Module wants to select a boot target (fixed vari-
[TPS_BSWMDT_04134]
ant)
Table C.27: Deleted Specification Items in 4.4.0

C.9.4 Added Constraints in 4.4.0

Number Heading
[constr_4099] Support of multiple instantiation
[constr_4100] Uniqueness of module implementation prefixes
[constr_4101] Semantics of McGroupDataRefSet.flatMapEntry
[constr_4102] Semantics of McGroupDataRefSet.mcDataInstance
[constr_4103] Name convention for SectionNamePrefix
[constr_4104] Referencing of MemorySections to SectionNamePrefix
Table C.28: Added Constraints in 4.4.0

C.9.5 Changed Constraints in 4.4.0

Number Heading
[constr_4068] McFunctionDataRefSet.flatMapEntry’s semantic
[constr_4069] McFunctionDataRefSet.mcDataInstance’s semantic
[constr_4071] Synchronized runnables and schedulable entities must be consistent
Table C.29: Changed Constraints in 4.4.0

C.9.6 Deleted Constraints in 4.4.0

Number Heading
[constr_4067] Exclusive usage of data references in McFunctionDataRefSet
Table C.30: Deleted Constraints in 4.4.0

288 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.10 Constraint History of this Document according to AUTOSAR

R19-11

C.10.1 Added Specification Items in 19-11

none

C.10.2 Changed Specification Items in 19-11

Number Heading
[TPS_BSWMDT_04000] BSW modules with AUTOSAR Interfaces
[TPS_BSWMDT_04013] Usage of BswModuleDescription.providedModeGroup
[TPS_BSWMDT_04021] Usage of BswEvent
[TPS_BSWMDT_04057] Self-contained MC support artifact
[TPS_BSWMDT_04074] Synchronization of mode switches or triggers
[TPS_BSWMDT_04098] Declaration of BswModuleClientServerEntry
[TPS_BSWMDT_04101] Declaration of providedData and requiredData
BswInternalBehavior containing BswModuleEntity-s executed
[TPS_BSWMDT_04108]
on different partitions
BswInternalBehavior for the same AUTOSAR Service provided
[TPS_BSWMDT_04109]
on different partitions
Dem Service Use Case: Basic Software Module implements a
[TPS_BSWMDT_04120]
Diagnostic Monitor
Dem Service Use Case: Basic Software Module implements a
[TPS_BSWMDT_04139]
hardware shutdown
RptExecutionContext represents a common environment for a set
[TPS_BSWMDT_04163]
of RptExecutableEntitys or McDataInstances
[TPS_BSWMDT_04169] Scope of McGroupDataRefSets
Table C.31: Changed Specification Items in 19-11

C.10.3 Deleted Specification Items in 19-11

none

C.10.4 Added Constraints in 19-11

Number Heading
[constr_4105] Use of attribute task or cat2Isr
Table C.32: Added Constraints in 19-11

289 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.10.5 Changed Constraints in 19-11

Number Heading
[constr_4013] BSW service identifier
[constr_4015] calledEntry constraints for direct calls
[constr_4016] BswCalledEntity constraints
[constr_4017] BswSchedulableEntity constraints
[constr_4018] BswInterruptEntity constraints
[constr_4019] BSW module identifier
[constr_4022] BswModuleEntity only uses the module’s interface
[constr_4023] External trigger shall belong to the interface
[constr_4025] Modes used by BSW mode switch event
[constr_4026] Mode group used by BSW mode switch acknowledge event
[constr_4028] Semantics of memory section type
[constr_4029] Measured stack usage
[constr_4030] Measured heap usage
[constr_4031] Analyzed execution time
[constr_4032] Measured execution time
[constr_4033] Simulated execution time
[constr_4034] Target and context of MC emulation reference
[constr_4038] bswModuleDependency shall refer to a different module
[constr_4040] Synchronized mode groups shall have same type
[constr_4041] Synchronized mode groups shall have same context
[constr_4042] Synchronized triggers shall have same context
[constr_4044] Content of McSwEmulationMethodSupport
[constr_4052] BswModuleEntry returnType direction
[constr_4053] BswModuleEntry argument direction
[constr_4054] Unambiguous links to addressing method
[constr_4058] Different mode groups in mapped BSWM and SWC shall have different names
[constr_4059] Different mode groups referred by a BSWM shall have different names
[constr_4061] Completeness of MC emulation reference
[constr_4062] Mandatory symbol for McDataInstance root
[constr_4064] Synchronized triggers shall implement same policy
[constr_4071] Synchronized runnables and schedulable entities shall be consistent
[constr_4072] Constraints of SectionNamePrefix.implementedIn
[constr_4073] McDataAccessDetails shall refer to one ECU Extract
[constr_4076] Constraints on BswModuleEntry used for Client-Server
[constr_4079] calledEntry constraints for client-server calls
[constr_4080] Existence of reception policy
5

290 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number Heading
[constr_4081] Mode group used by BSW mode manager error event
Table C.33: Changed Constraints in 19-11

C.10.6 Deleted Constraints in 19-11

none

C.11 Constraint History of this Document according to AUTOSAR

R20-11

C.11.1 Added Specification Items in R20-11

Number Heading
Dem Service Use Case: Basic Software Module checks whether
[TPS_BSWMDT_04173]
an event is suppressed
[TPS_BSWMDT_04174] Association to FlatMap
[TPS_BSWMDT_04175] Support software emulation
[TPS_BSWMDT_04176] Self-contained MC support artifact
[TPS_BSWMDT_04177] Support of functional modeling
[TPS_BSWMDT_04178] Support of rapid prototyping
Table C.34: Added Specification Items in R20-11

C.11.2 Changed Specification Items in R20-11

Number Heading
[TPS_BSWMDT_04057] Self-contained MC support artifact
Table C.35: Changed Specification Items in R20-11

C.11.3 Deleted Specification Items in R20-11

none

291 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.11.4 Added Constraints in R20-11

none

C.11.5 Changed Constraints in R20-11

Number Heading
[constr_4071] Synchronized runnables and schedulable entities shall be consistent
Table C.36: Changed Constraints in R20-11

C.11.6 Deleted Constraints in R20-11

none

C.12 Constraint History of this Document according to AUTOSAR

R21-11

C.12.1 Added Specification Items in R21-11

none

C.12.2 Changed Specification Items in R21-11

Number Heading
[TPS_BSWMDT_-
Local BSW data accessed via BSW Scheduler API
04027]
[TPS_BSWMDT_-
Determination of argument names for BSW functions called via ports
04028]
[TPS_BSWMDT_-
Usage of MemorySection.executableEntity
04049]
[TPS_BSWMDT_-
Provide memory mapping header file names
04092]
[TPS_BSWMDT_-
BswModuleEntity reentrancy level
04103]
[TPS_BSWMDT_-
Declaration of production errors
04110]
5

292 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number Heading
[TPS_BSWMDT_-
BswServiceDependency refers to Dem_SetEventStatus()
04111]
[TPS_BSWMDT_-
BswServiceDependency refers to InitMonitorForEvent
04112]
[TPS_BSWMDT_-
BSW measurement data accessed via BSW Scheduler API
04128]
[TPS_BSWMDT_- Dem Service Use Case: Basic Software Module checks whether an
04173] event is suppressed
Table C.37: Changed Specification Items in R21-11

C.12.3 Deleted Specification Items in R21-11

Number Heading
[TPS_BSWMDT_-
Memory classes for compiler abstraction
04093]
Table C.38: Deleted Specification Items in R21-11

C.12.4 Added Constraints in R21-11

none

C.12.5 Changed Constraints in R21-11

Number Heading
[constr_4014] Call type and execution context
[constr_4015] calledEntry constraints for direct calls
[constr_4022] BswModuleEntity only uses the module’s interface
[constr_4028] Semantics of memory section type
[constr_4051] RoleBasedDataAssignment in BSW
[constr_4054] Unambiguous links to addressing method
[constr_4066] BswModeSwitchEvent and the definition of ModeTransition
[constr_4068] McFunctionDataRefSet.flatMapEntry’s semantic
[constr_4073] McDataAccessDetails shall refer to one ECU Extract
[constr_4074] Compatibility of BswModuleClientServerEntry-s
5

293 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number Heading
[constr_4075] Constraints for providedData and requiredData
[constr_4076] Constraints on BswModuleEntry used for Client-Server
[constr_4077] Constraints for BswModuleEntity.reentrancyLevel
[constr_4078] Consistent usage of BswOperationInvokedEvent
[constr_4079] calledEntry constraints for client-server calls
[constr_4084] Consistency of references of InternalBehavior

[constr_4086] invocation of ExecutableEntitys by direct function call dependent from

BswExecutionContext
[constr_4101] Semantics of McGroupDataRefSet.flatMapEntry
[constr_4105] Use of attribute task or cat2Isr
Table C.39: Changed Constraints in R21-11

C.12.6 Deleted Constraints in R21-11

none

C.13 Constraint History of this Document according to AUTOSAR

R22-11

C.13.1 Added Specification Items in R22-11

none

C.13.2 Changed Specification Items in R22-11

none

C.13.3 Deleted Specification Items in R22-11

none

294 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.13.4 Added Constraints in R22-11

Number Heading
[constr_4106] Restriction for the value of SwServiceArg.swImplPolicy
[constr_4107] swImplPolicy for SwServiceArg
[constr_4108] Restriction regarding the value of SwServiceArg.category
[constr_10257] Existence of attribute BswServiceDependency.serviceNeeds
Existence of the reference in the role RoleBasedBswModuleEntryAssignment.
[constr_10258]
assignedEntry
[constr_10259] Existence of attribute RoleBasedBswModuleEntryAssignment.role
[constr_10260] Existence of attribute BswModuleEntry.callType
[constr_10261] Existence of attribute BswModuleEntry.executionContext
[constr_10262] Existence of attribute BswModuleEntry.isReentrant
[constr_10263] Existence of attribute BswModuleEntry.isSynchronous
[constr_10264] Existence of attribute BswModuleEntry.swServiceImplPolicy
[constr_10265] Existence of attribute BswEntryRelationshipSet.bswEntryRelationship
[constr_10266] Existence of attribute BswEntryRelationship.bswEntryRelationshipType
[constr_10267] Existence of reference in the role BswEntryRelationship.from
[constr_10268] Existence of reference in the role BswEntryRelationship.to
Existence of the reference in the role BswModuleClientServerEntry.
[constr_10269]
encapsulatedEntry
[constr_10270] Existence of attribute AccessCountSet.countProfile
[constr_10271] Existence of attribute AccessCount.value
[constr_10272] Existence of the reference in the role BswModuleEntity.implementedEntry
[constr_10273] Existence of attribute BswInterruptEntity.interruptCategory
[constr_10274] Existence of attribute BswInterruptEntity.interruptSource
[constr_10275] Existence of the reference in the role BswDirectCallPoint.calledEntry
Existence of the reference in the role BswSynchronousServerCallPoint.
[constr_10276]
calledEntry
Existence of the reference in the role BswAsynchronousServerCallPoint.
[constr_10277]
calledEntry
Existence of the reference in the role
[constr_10278] BswAsynchronousServerCallResultPoint.
asynchronousServerCallPoint
[constr_10279] Existence of the reference in the role BswVariableAccess.accessedVariable
[constr_10280] Existence of the reference in the role BswExclusiveAreaPolicy.
exclusiveArea
[constr_10281] Existence of attribute BswTimingEvent.period

[constr_10282] Existence of the reference in the role BswInternalTriggerOccurredEvent.

eventSource
Existence of the reference in the role BswExternalTriggerOccurredEvent.
[constr_10283]
trigger
5

295 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number Heading
[constr_10284] Existence of attribute BswModeSwitchEvent.activation
[constr_10285] Existence of the reference in the role BswModeSwitchedAckEvent.modeGroup
[constr_10286] Existence of the reference in the role BswModeManagerErrorEvent.modeGroup
[constr_10287] Existence of the reference in the role BswOperationInvokedEvent.entry
Existence of the reference in the role
[constr_10288]
BswAsynchronousServerCallReturnsEvent.eventSource
[constr_10289] Existence of the reference in the role BswDataReceivedEvent.data
Existence of the reference in the role BswTriggerDirectImplementation.
[constr_10290]
masteredTrigger
Existence of the reference in the role BswModeSenderPolicy.
[constr_10291]
providedModeGroup
[constr_10292] Existence of attribute BswModeSenderPolicy.queueLength
[constr_10293] Existence of attribute BswModeSwitchAckRequest.timeout
Existence of the reference in the role BswModeReceiverPolicy.
[constr_10294]
requiredModeGroup
Existence of attribute BswModeReceiverPolicy.
[constr_10295]
supportsAsynchronousModeSwitch
[constr_10296] Existence of reference in the role BswDataReceptionPolicy.receivedData
[constr_10297] Existence of attribute BswQueuedDataReceptionPolicy.queueLength
[constr_10298] Existence of the reference in the role SwcBswRunnableMapping.bswEntity
[constr_10299] Existence of the reference in the role SwcBswRunnableMapping.swcRunnable
Existence of the reference in the role SwcBswSynchronizedTrigger.
[constr_10300]
bswTrigger
Existence of the instanceRef in the role SwcBswSynchronizedTrigger.
[constr_10301]
swcTrigger
[constr_10302] Existence of attribute BswImplementation.arReleaseVersion
[constr_10303] Existence of the reference in the role BswImplementation.behavior
[constr_10304] Existence of attribute DependencyOnArtifact.usage
[constr_10305] Existence of attribute WorstCaseStackUsage.memoryConsumption
[constr_10306] Existence of attribute MeasuredStackUsage.averageMemoryConsumption
[constr_10307] Existence of attribute MeasuredStackUsage.maximumMemoryConsumption
[constr_10308] Existence of attribute RoughEstimateStackUsage.memoryConsumption
[constr_10309] Existence of attribute WorstCaseHeapUsage.memoryConsumption
[constr_10310] Existence of attribute MeasuredHeapUsage.averageMemoryConsumption
[constr_10311] Existence of attribute MeasuredHeapUsage.maximumMemoryConsumption
[constr_10312] Existence of attribute RoughEstimateHeapUsage.memoryConsumption
[constr_10313] Existence of attribute ExecutionTime.hardwareConfiguration
[constr_10314] Existence of attribute ExecutionTime.softwareContext
[constr_10315] Existence of attribute HardwareConfiguration.additionalInformation
[constr_10316] Existence of attribute HardwareConfiguration.processorMode
[constr_10317] Existence of attribute HardwareConfiguration.processorSpeed
5

296 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number Heading
[constr_10318] Existence of reference MemorySectionLocation.providedMemory
[constr_10319] Existence of reference MemorySectionLocation.softwareMemorySection
[constr_10320] Existence of attribute SoftwareContext.input
[constr_10321] Existence of attribute SoftwareContext.state
[constr_10323] Existence of attribute AnalyzedExecutionTime.bestCaseExecutionTime
[constr_10324] Existence of attribute AnalyzedExecutionTime.worstCaseExecutionTime
[constr_10325] Existence of attribute MeasuredExecutionTime.maximumExecutionTime
[constr_10326] Existence of attribute MeasuredExecutionTime.minimumExecutionTime
[constr_10327] Existence of attribute MeasuredExecutionTime.nominalExecutionTime
[constr_10328] Existence of the reference in the role BswEvent.startsOnEvent
[constr_10329] Existence of the instanceRef in the role McDataAccessDetails.
variableAccess
[constr_10330] Existence of attribute RptServicePoint.symbol
[constr_10331] Existence of attribute SimulatedExecutionTime.maximumExecutionTime
[constr_10332] Existence of attribute SimulatedExecutionTime.minimumExecutionTime
[constr_10333] Existence of attribute SimulatedExecutionTime.nominalExecutionTime
[constr_10334] Existence of attribute RoughEstimateOfExecutionTime.
additionalInformation
[constr_10335] Existence of attribute RoughEstimateOfExecutionTime.
estimatedExecutionTime
Existence of the reference in the role
[constr_10336]
SwcBswSynchronizedModeGroupPrototype.bswModeGroup
Existence of the instanceRef in the role
[constr_10337]
SwcBswSynchronizedModeGroupPrototype.swcModeGroup
[constr_10338] Existence of attribute MultidimensionalTime.cseCode
[constr_10339] Existence of attribute MultidimensionalTime.cseCodeFactor
[constr_10340] Existence of attribute McSwEmulationMethodSupport.category
[constr_10341] Existence of attribute McSwEmulationMethodSupport.shortLabel

[constr_10342] Existence of the reference in the role McParameterElementGroup.

ramLocation
[constr_10343] Existence of the reference in the role McParameterElementGroup.
romLocation
[constr_10344] Existence of attribute McParameterElementGroup.shortLabel
Existence of the reference in the role
[constr_10345]
ImplementationElementInParameterInstanceRef.context
Existence of the reference in the role
[constr_10346]
ImplementationElementInParameterInstanceRef.target
[constr_10347] Existence of the instanceRef in the role McDataAccessDetails.rteEvent
[constr_10349] Existence of attribute RptSupportData.executionContext
[constr_10350] Existence of attribute RptSupportData.rptComponent
[constr_10351] Existence of attribute RptSupportData.rptServicePoint
[constr_10352] Existence of attribute RptComponent.rptExecutableEntity
5

297 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number Heading
[constr_10353] Existence of attribute RptExecutableEntity.rptExecutableEntityEvent
[constr_10354] Existence of attribute RptExecutableEntity.symbol

[constr_10355] Existence of the reference in the role RptExecutableEntityEvent.

executionContext
[constr_10356] Existence of attribute RptExecutableEntityEvent.rptEventId
Existence of attribute RptExecutableEntityEvent.
[constr_10357]
rptExecutableEntityProperties
Existence of the reference in the role RptExecutableEntityEvent.
[constr_10358]
rptServicePointPost
Existence of the reference in the role RptExecutableEntityEvent.
[constr_10359]
rptServicePointPre
[constr_10360] Existence of attribute RptServicePoint.serviceId
[constr_10362] Existence of attribute AliasNameSet.aliasName
[constr_10363] Existence of attribute AliasNameAssignment.shortLabel
Table C.40: Added Constraints in R22-11

C.13.5 Changed Constraints in R22-11

Number Heading
[constr_4020] Allowed categories of BswModuleDescription
[constr_4068] McFunctionDataRefSet.flatMapEntry’s semantic
[constr_4069] McFunctionDataRefSet.mcDataInstance’s semantic
[constr_4074] Compatibility of BswModuleClientServerEntry-s

[constr_4086] invocation of ExecutableEntitys by direct function call dependent from

BswExecutionContext
[constr_4101] Semantics of McGroupDataRefSet.flatMapEntry
[constr_4102] Semantics of McGroupDataRefSet.mcDataInstance
[constr_4103] Name convention for SectionNamePrefix.symbol
Table C.41: Changed Constraints in R22-11

C.13.6 Deleted Constraints in R22-11

none

298 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

C.14 Constraint History of this Document according to AUTOSAR

R23-11

C.14.1 Added Specification Items in R23-11

Number Heading
Possible invocation of ExecutableEntitys by direct function call
[TPS_BSWMDT_04179]
dependent from BswExecutionContext
Table C.42: Added Specification Items in R23-11

C.14.2 Changed Specification Items in R23-11

Number Heading
Standardized values of attribute RoleBasedMcDataAssignment.
[TPS_BSWMDT_04159]
role
Table C.43: Changed Specification Items in R23-11

C.14.3 Deleted Specification Items in R23-11

none

C.14.4 Added Constraints in R23-11

none

C.14.5 Changed Constraints in R23-11

Number Heading
[constr_4016] BswCalledEntity constraints
Table C.44: Changed Constraints in R23-11

C.14.6 Deleted Constraints in R23-11

none

299 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

D Mentioned Class Tables

For the sake of completeness, this chapter contains a set of class tables representing
meta-classes mentioned in the context of this document but which are not contained
directly in the scope of describing specific meta-model semantics.
Class ARElement (abstract)
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::ARPackage
Note An element that can be defined stand-alone, i.e. without being part of another element (except for
packages of course).
Base ARObject, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Subclasses AclObjectSet, AclOperation, AclPermission, AclRole, AliasNameSet, ApplicabilityInfoSet, Application
Partition, AutosarDataType, BaseType, BlueprintMappingSet, BswEntryRelationshipSet, BswModule
Description, BswModuleEntry, BuildActionManifest, CalibrationParameterValueSet, ClientIdDefinitionSet,
ClientServerInterfaceToBswModuleEntryBlueprintMapping, Collection, CompuMethod, Consistency
NeedsBlueprintSet, ConstantSpecification, ConstantSpecificationMappingSet, CpSoftwareCluster, Cp
SoftwareClusterBinaryManifestDescriptor, CpSoftwareClusterMappingSet, CpSoftwareClusterResource
Pool, CryptoEllipticCurveProps, CryptoServiceCertificate, CryptoServiceKey, CryptoServicePrimitive,
CryptoServiceQueue, CryptoSignatureScheme, DataConstr, DataExchangePoint, DataTransformation
Set, DataTypeMappingSet, DdsCpConfig, DiagnosticCommonElement, DiagnosticConnection,
DiagnosticContributionSet, DltContext, DltEcu, Documentation, E2EProfileCompatibilityProps, Ecuc
DefinitionCollection, EcucDestinationUriDefSet, EcucModuleConfigurationValues, EcucModuleDef, Ecuc
ValueCollection, EndToEndProtectionSet, EthIpProps, EthTcpIpIcmpProps, EthTcpIpProps, Evaluated
VariantSet, FMFeature, FMFeatureMap, FMFeatureModel, FMFeatureSelectionSet, FirewallRule, Flat
Map, GeneralPurposeConnection, HwCategory, HwElement, HwType, IEEE1722TpConnection, IPSec
ConfigProps, IPv6ExtHeaderFilterSet, IdsCommonElement, IdsDesign, Implementation, ImpositionTime
DefinitionGroup, InterpolationRoutineMappingSet, J1939ControllerApplication, KeywordSet, LifeCycle
InfoSet, LifeCycleStateDefinitionGroup, LogAndTraceMessageCollectionSet, MacSecGlobalKayProps,
MacSecParticipantSet, McFunction, McGroup, ModeDeclarationGroup, ModeDeclarationMappingSet, Os
TaskProxy, PhysicalDimension, PhysicalDimensionMappingSet, PortInterface, PortInterfaceMappingSet,
PortPrototypeBlueprint, PostBuildVariantCriterion, PostBuildVariantCriterionValueSet, PredefinedVariant,
RapidPrototypingScenario, SdgDef, SignalServiceTranslationPropsSet, SomeipSdClientEventGroup
TimingConfig, SomeipSdClientServiceInstanceConfig, SomeipSdServerEventGroupTimingConfig,
SomeipSdServerServiceInstanceConfig, SwAddrMethod, SwAxisType, SwComponentMapping
Constraints, SwComponentType, SwRecordLayout, SwSystemconst, SwSystemconstantValueSet, Swc
BswMapping, System, SystemSignal, SystemSignalGroup, TDCpSoftwareClusterMappingSet, Tcp
OptionFilterSet, TimingExtension, TlsConnectionGroup, TlvDataIdDefinitionSet, TransformationProps
Set, Unit, UnitGroup, UploadablePackageElement, ViewMapSet
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
– – – – –
Table D.1: ARElement

Class ARPackage
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::ARPackage
Note AUTOSAR package, allowing to create top level packages to structure the contained ARElements.
ARPackages are open sets. This means that in a file based description system multiple files can be used
to partially describe the contents of a package.
This is an extended version of MSR’s SW-SYSTEM.
Base ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by ARPackage.arPackage, AUTOSAR.arPackage
Attribute Type Mult. Kind Note
5

300 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ARPackage
arPackage ARPackage * aggr This represents a sub package within an ARPackage,
thus allowing for an unlimited package hierarchy.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=arPackage.shortName, arPackage.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
xml.sequenceOffset=30
element PackageableElement * aggr Elements that are part of this package
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=element.shortName, element.variation
Point.shortLabel
vh.latestBindingTime=systemDesignTime
xml.sequenceOffset=20
referenceBase ReferenceBase * aggr This denotes the reference bases for the package. This is
the basis for all relative references within the package.
The base needs to be selected according to the base
attribute within the references.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=referenceBase.shortLabel
xml.sequenceOffset=10

Table D.2: ARPackage

Class AUTOSAR
Package M2::AUTOSARTemplates::AutosarTopLevelStructure
Note Root element of an AUTOSAR description, also the root element in corresponding XML documents.
Tags: xml.globalElement=true
Base ARObject
Attribute Type Mult. Kind Note
adminData AdminData 0..1 aggr This represents the administrative data of an Autosar file.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=adminData
xml.sequenceOffset=10
arPackage ARPackage * aggr This is the top level package in an AUTOSAR model.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=arPackage.shortName, arPackage.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
xml.sequenceOffset=30
fileInfo FileInfoComment 0..1 aggr This represents a possibility to provide a structured
Comment comment in an AUTOSAR file.
Stereotypes: atpStructuredComment
Tags:
xml.roleElement=true
xml.sequenceOffset=-10
xml.typeElement=false
5

301 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class AUTOSAR
introduction DocumentationBlock 0..1 aggr This represents an introduction on the Autosar file. It is
intended for example to represent disclaimers and legal
notes.
Tags: xml.sequenceOffset=20

Table D.3: AUTOSAR

Enumeration AdditionalBindingTimeEnum
Package M2::AUTOSARTemplates::GenericStructure::VariantHandling
Note This enumeration specifies the additional binding times applicable for vh.latestBindingTime of
variation points.
Literal Description
blueprintDerivation The point in time when an object is created from a blueprint.
Time
Tags: atp.EnumerationLiteralIndex=0
postBuild After the executable has been built.
Tags: atp.EnumerationLiteralIndex=1

Table D.4: AdditionalBindingTimeEnum

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
Subclasses ApplicationCompositeDataType, ApplicationPrimitiveDataType
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
– – – – –
Table D.5: ApplicationDataType

Class ApplicationRuleBasedValueSpecification
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note This meta-class represents rule based values for DataPrototypes typed by ApplicationDataTypes
(ApplicationArrayDataType or a compound ApplicationPrimitiveDataType which also boils down to an
array-nature).
Base ARObject, AbstractRuleBasedValueSpecification, CompositeRuleBasedValueArgument, Value
Specification
5

302 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ApplicationRuleBasedValueSpecification
Aggregated by ApplicationAssocMapElementValueSpecification.key, ApplicationAssocMapElementValueSpecification.
value, ArrayValueSpecification.element, CalibrationParameterValue.applInitValue, CalibrationParameter
Value.implInitValue, CompositeRuleBasedValueSpecification.compoundPrimitiveArgument, Constant
Specification.valueSpec, CryptoServiceKey.developmentValue, DiagnosticEnvDataCondition.compare
Value, DiagnosticEnvDataElementCondition.compareValue, FieldSenderComSpec.initValue, ISignal.init
Value, ISignal.timeoutSubstitutionValue, NonqueuedReceiverComSpec.initValue, NonqueuedReceiver
ComSpec.timeoutSubstitutionValue, NonqueuedSenderComSpec.initValue, NvProvideComSpec.ram
BlockInitValue, NvProvideComSpec.romBlockInitValue, NvRequireComSpec.initValue, ParameterData
Prototype.initValue, ParameterProvideComSpec.initValue, ParameterRequireComSpec.initValue,
PersistencyDataRequiredComSpec.initValue, PersistencyKeyValuePair.initValue, PortDefinedArgument
Value.value, PortPrototypeBlueprintInitValue.value, RecordValueSpecification.field, SomeipEvent
Deployment.eventReceptionDefaultValue, StateManagementCompareCondition.compareValue, SwData
DefProps.invalidValue, VariableDataPrototype.initValue
Attribute Type Mult. Kind Note
category Identifier 0..1 attr This represents the category of the RuleBasedValue
Specification
Tags: xml.sequenceOffset=-20
swAxisCont RuleBasedAxisCont * aggr This represents the axis values of a Compound Primitive
(ordered) Data Type (curve or map).
The first swAxisCont describes the x-axis, the second sw
AxisCont describes the y-axis, the third swAxisCont
describes the z-axis. In addition to this, the axis can be
denoted in swAxisIndex.
swValueCont RuleBasedValueCont 0..1 aggr This represents the values of an array or Compound
Primitive Data Type.
Stereotypes: atpSplitable
Tags: atp.Splitkey=swValueCont

Table D.6: ApplicationRuleBasedValueSpecification

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
Aggregated by AtpClassifier .atpFeature, ClientServerOperation.argument
Attribute Type Mult. Kind Note
direction ArgumentDirection 0..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 D.7: ArgumentDataPrototype

Class ArrayValueSpecification
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note Specifies the values for an array.
Base ARObject, CompositeValueSpecification, ValueSpecification
5

303 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ArrayValueSpecification
Aggregated by ApplicationAssocMapElementValueSpecification.key, ApplicationAssocMapElementValueSpecification.
value, ArrayValueSpecification.element, CalibrationParameterValue.applInitValue, CalibrationParameter
Value.implInitValue, CompositeRuleBasedValueSpecification.argument, ConstantSpecification.value
Spec, CryptoServiceKey.developmentValue, DiagnosticEnvDataCondition.compareValue, DiagnosticEnv
DataElementCondition.compareValue, FieldSenderComSpec.initValue, ISignal.initValue, ISignal.timeout
SubstitutionValue, NonqueuedReceiverComSpec.initValue, NonqueuedReceiverComSpec.timeout
SubstitutionValue, NonqueuedSenderComSpec.initValue, NvProvideComSpec.ramBlockInitValue, Nv
ProvideComSpec.romBlockInitValue, NvRequireComSpec.initValue, ParameterDataPrototype.initValue,
ParameterProvideComSpec.initValue, ParameterRequireComSpec.initValue, PersistencyDataRequired
ComSpec.initValue, PersistencyKeyValuePair.initValue, PortDefinedArgumentValue.value, PortPrototype
BlueprintInitValue.value, RecordValueSpecification.field, SomeipEventDeployment.eventReception
DefaultValue, StateManagementCompareCondition.compareValue, SwDataDefProps.invalidValue,
VariableDataPrototype.initValue
Attribute Type Mult. Kind Note
element ValueSpecification * aggr The value for a single array element. All Value
(ordered) Specifications aggregated by ArrayValueSpecification
shall have the same structure.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=element, element.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
intendedPartial PositiveInteger 0..1 attr This attribute shall only have a meaning for dynamic
Initialization arrays and shall be taken as a sanity check: the number
Count filled in the attribute shall be identical to the number of
ArrayValueSpecification.element.
If the attribute does not exist it means that no partial
initialization is intended.
Table D.8: ArrayValueSpecification

Class AsynchronousServerCallResultPoint
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::ServerCall
Note If a RunnableEntity owns a AsynchronousServerCallResultPoint it is entitled to get the result of the
referenced AsynchronousServerCallPoint. If it is associated with AsynchronousServerCallReturnsEvent,
this RTEEvent notifies the completion of the required ClientServerOperation or a timeout. The
occurrence of this event can either unblock a WaitPoint or can lead to the invocation of a RunnableEntity.
Base ARObject, AbstractAccessPoint, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable,
MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, RunnableEntity.asynchronousServerCallResultPoint
Attribute Type Mult. Kind Note
asynchronous AsynchronousServer 0..1 ref The referenced Asynchronous Server Call Point defines
ServerCallPoint CallPoint the asynchronous server call from which the results are
returned.
Table D.9: AsynchronousServerCallResultPoint

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
5

304 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class AtomicSwComponentType (abstract)
Subclasses ApplicationSwComponentType, ComplexDeviceDriverSwComponentType, EcuAbstractionSwComponent
Type, NvBlockSwComponentType, SensorActuatorSwComponentType, ServiceProxySwComponent
Type, ServiceSwComponentType
Aggregated by ARPackage.element
Attribute Type Mult. 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.shortName, internal
Behavior.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
symbolProps SymbolProps 0..1 aggr This represents the SymbolProps for the AtomicSw
ComponentType.
Stereotypes: atpSplitable
Tags: atp.Splitkey=symbolProps.shortName

Table D.10: AtomicSwComponentType

Class AtpBlueprint (abstract)

Package M2::AUTOSARTemplates::CommonStructure::StandardizationTemplate::AbstractBlueprintStructure
Note This meta-class represents the ability to act as a Blueprint. As this class is an abstract one, particular
blueprint meta-classes inherit from this one.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses ARPackage, AbstractImplementationDataType, AclObjectSet, AclOperation, AclPermission, AclRole,
AliasNameSet, ApplicationDataType, BswEntryRelationshipSet, BswModuleDescription, BswModule
Entry, BuildActionEntity , BuildActionEnvironment, BuildActionManifest, ClientServerInterfaceToBsw
ModuleEntryBlueprintMapping, CompuMethod, ConsistencyNeeds, DataConstr, DataTypeMappingSet,
EcucDefinitionCollection, EcucDestinationUriDefSet, EcucModuleDef, FlatMap, ImpositionTime,
ImpositionTimeDefinitionGroup, KeywordSet, LifeCycleState, LifeCycleStateDefinitionGroup, Mode
DeclarationGroup, PortInterface, PortInterfaceMapping, PortInterfaceMappingSet, PortPrototype
Blueprint, SwAddrMethod, SwBaseType, SwComponentType, VfbTiming
Attribute Type Mult. Kind Note
blueprintPolicy BlueprintPolicy * aggr This role indicates whether the blueprintable element will
be modifiable or not modifiable.
Table D.11: AtpBlueprint

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
Aggregated by AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
type AutosarDataType 0..1 tref This represents the corresponding data type.
Stereotypes: isOfType

Table D.12: AutosarDataPrototype

305 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class AutosarDataType (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note Abstract base class for user defined AUTOSAR data types for software.
Base ARElement, ARObject, AtpClassifier , AtpType, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Subclasses AbstractImplementationDataType, ApplicationDataType
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
swDataDef SwDataDefProps 0..1 aggr The properties of this AutosarDataType.
Props
Stereotypes: atpSplitable
Tags: atp.Splitkey=swDataDefProps

Table D.13: AutosarDataType

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 Implementation
Datatype
Base ARObject
Aggregated by InstantiationDataDefProps.parameterInstance, ParameterAccess.accessedParameter, RoleBasedData
Assignment.usedParameterElement, SwCalprmRefProxy.arParameter
Attribute Type Mult. Kind Note
autosar DataPrototype 0..1 iref This instance reference is used if the calibration
Parameter parameter is either imported via a port or is part of a
composite data structure.
InstanceRef implemented by: ParameterInAtomicSWC
TypeInstanceRef
5

306 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class AutosarParameterRef
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 D.14: AutosarParameterRef

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. nvramData
mapping)
• an element inside of a composite variable provided via Port and typed by ImplementationDatatype
(e.g. inputValue for a curve)
Base ARObject
Aggregated by InstantiationDataDefProps.variableInstance, NvBlockDataMapping.nvRamBlockElement, NvBlockData
Mapping.readNvData, NvBlockDataMapping.writtenNvData, NvBlockDataMapping.writtenReadNvData,
RoleBasedDataAssignment.usedDataElement, SwVariableRefProxy.autosarVariable, VariableAccess.
accessedVariable
Attribute Type Mult. 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.
InstanceRef implemented by: VariableInAtomicSWC
TypeInstanceRef
autosarVariable ArVariableIn 0..1 aggr This is used if the target variable is inside of variableData
InImplDatatype ImplementationData Prototype typed by an ImplementationDataType.
InstanceRef
5

307 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class AutosarVariableRef
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 explicit reference is
provided for this case.

Table D.15: AutosarVariableRef

Enumeration BindingTimeEnum
Package M2::AUTOSARTemplates::GenericStructure::VariantHandling
Note This enumerator specifies the applicable binding times for the pre build variation points.
Aggregated by AttributeValueVariationPoint.bindingTime, ConditionByFormula.bindingTime, FMFeature.maximum
IntendedBindingTime, FMFeature.minimumIntendedBindingTime, FMFeatureSelection.maximum
SelectedBindingTime, FMFeatureSelection.minimumSelectedBindingTime
Literal Description
codeGeneration • Coding by hand, based on requirements document.
Time
• Tool based code generation, e.g. from a model.
• The model may contain variants.
• Only code for the selected variant(s) is actually generated.
Tags: atp.EnumerationLiteralIndex=0
linkTime Configure what is included in object code, and what is omitted Based on which variant(s) are selected
E.g. for modules that are delivered as object code (as opposed to those that are delivered as source
code)
Tags: atp.EnumerationLiteralIndex=1
preCompileTime This is typically the C-Preprocessor. Exclude parts of the code from the compilation process, e.g.,
because they are not required for the selected variant, because they are incompatible with the
selected variant, because they require resources that are not present in the selected variant. Object
code is only generated for the selected variant(s). The code that is excluded at this stage code will
not be available at later stages.
Tags: atp.EnumerationLiteralIndex=2
systemDesignTime • Designing the VFB.
• Software Component types (PortInterfaces).
• SWC Prototypes and the Connections between SWCprototypes.
• Designing the Topology
• ECUs and interconnecting Networks
• Designing the Communication Matrix and Data Mapping
Tags: atp.EnumerationLiteralIndex=3

Table D.16: BindingTimeEnum

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
5

308 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ClientServerInterface
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
operation ClientServerOperation * aggr ClientServerOperation(s) of this ClientServerInterface.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=operation.shortName, operation.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
possibleError ApplicationError * aggr Application errors that are defined as part of this interface.

Table D.17: ClientServerInterface

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
Aggregated by ApplicationInterface.command, AtpClassifier .atpFeature, ClientServerInterface.operation, Diagnostic
DataElementInterface.read, DiagnosticDataIdentifierInterface.read, DiagnosticDataIdentifierInterface.
write, DiagnosticRoutineInterface.requestResult, DiagnosticRoutineInterface.start, DiagnosticRoutine
Interface.stop, PhmRecoveryActionInterface.recovery, ServiceInterface.method
Attribute Type Mult. Kind Note
argument ArgumentDataPrototype * aggr An argument of this ClientServerOperation
(ordered)
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=argument.shortName, argument.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
diagArgIntegrity Boolean 0..1 attr This attribute shall only be used in the implementation of
diagnostic routines to support the case where input and
output arguments are allocated in a shared buffer and
might unintentionally overwrite input arguments by
tentative write operations to output arguments.
This situation can happen during sliced execution or while
output parameters are arrays (call by reference). The
value true means that the ClientServerOperation is aware
of the usage of a shared buffer and takes precautions to
avoid unintentional overwrite of input arguments.
If the attribute does not exist or is set to false the Client
ServerOperation does not have to consider the usage of a
shared buffer.
possibleError ApplicationError * ref Possible errors that may by raised by the referring
operation.

Table D.18: ClientServerOperation

309 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ComplexDeviceDriverSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note The ComplexDeviceDriverSwComponentType is a special AtomicSwComponentType that has direct
access to hardware on an ECU and which is therefore linked to a specific ECU or specific hardware. The
ComplexDeviceDriverSwComponentType introduces the possibility to link from the software
representation to its hardware description provided by the ECU Resource Template.
Tags: atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtomicSwComponentType, AtpBlueprint, AtpBlueprintable, AtpClassifier , Atp
Type, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable, Sw
ComponentType
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
hardware HwDescriptionEntity * ref Reference from the ComplexDeviceDriverSwComponent
Element Type to the description of the used HwElements.

Table D.19: ComplexDeviceDriverSwComponentType

Class CompuMethod
Package M2::MSR::AsamHdo::ComputationMethod
Note This meta-class represents the ability to express the relationship between a physical value and the
mathematical representation.
Note that this is still independent of the technical implementation in data types. It only specifies the
formula how the internal value corresponds to its physical pendant.
Tags: atp.recommendedPackage=CompuMethods
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
compuInternal Compu 0..1 aggr This specifies the computation from internal values to
ToPhys physical values.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=compuInternalToPhys
xml.sequenceOffset=80
compuPhysTo Compu 0..1 aggr This represents the computation from physical values to
Internal the internal values.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=compuPhysToInternal
xml.sequenceOffset=90
displayFormat DisplayFormatString 0..1 attr This property specifies, how the physical value shall be
displayed e.g. in documents or measurement and
calibration tools.
Tags: xml.sequenceOffset=20
unit Unit 0..1 ref This is the physical unit of the Physical values for which
the CompuMethod applies.
Tags: xml.sequenceOffset=30

Table D.20: CompuMethod

310 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ConstantSpecification
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note Specification of a constant that can be part of a package, i.e. it can be defined stand-alone.
Tags: atp.recommendedPackage=ConstantSpecifications
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
valueSpec ValueSpecification 0..1 aggr Specification of an expression leading to a value for this
constant.
Stereotypes: atpSplitable
Tags: atp.Splitkey=valueSpec

Table D.21: ConstantSpecification

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
Aggregated by AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
swDataDef SwDataDefProps 0..1 aggr This property allows to specify data definition properties
Props which apply on data prototype level.
Stereotypes: atpSplitable
Tags: atp.Splitkey=swDataDefProps

Table D.22: DataPrototype

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
Aggregated by ARPackage.element
Attribute Type Mult. 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 D.23: DataTypeMappingSet

311 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class Describable (abstract)

Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable
Note This meta-class represents the ability to add a descriptive documentation to non identifiable elements.
Base ARObject
Subclasses CyclicTiming, EventControlledTiming, HwElementConnector, HwPinConnector, HwPinGroupConnector, I
PduTiming, Ipv4DhcpServerConfiguration, Ipv6DhcpServerConfiguration, PncMapping, Socket
Connection, TransformationComSpecProps, TransformationDescription, TransformationISignalProps
Attribute Type Mult. Kind Note
adminData AdminData 0..1 aggr This represents the administrative data for the
describable object.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=adminData
xml.sequenceOffset=-20
category CategoryString 0..1 attr The category is a keyword that specializes the semantics
of the Describable. It affects the expected existence of
attributes and the applicability of constraints.
Tags: xml.sequenceOffset=-50
desc MultiLanguageOverview 0..1 aggr This represents a general but brief (one paragraph)
Paragraph description what the object in question is about. It is only
one paragraph! Desc is intended to be collected into
overview tables. This property helps a human reader to
identify the object in question.
More elaborate documentation, (in particular how the
object is built or used) should go to "introduction".
Tags: xml.sequenceOffset=-60
introduction DocumentationBlock 0..1 aggr This represents more information about how the object in
question is built or is used. Therefore it is a
DocumentationBlock.
Tags: xml.sequenceOffset=-30

Table D.24: Describable

Class DiagnosticComponentNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the ability to specify the service needs for the configuration of component
events.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table D.25: DiagnosticComponentNeeds

Class DiagnosticEventInfoNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This meta-class represents the needs of a software-component interested to get information regarding
specific DTCs.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
5

312 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class DiagnosticEventInfoNeeds
Attribute Type Mult. Kind Note
obdDtcNumber PositiveInteger 0..1 attr This represents a reasonable Diagnostic Trouble Code.
This allows to predefine the Diagnostic Trouble Code, e.g.
if the function developer has received a particular
requirement from the OEM or from a standardization
body.
This attribute applies for the OBD diagnostics use case.
udsDtcNumber PositiveInteger 0..1 attr This represents a reasonable Diagnostic Trouble Code.
This allows to predefine the Diagnostic Trouble Code, e.g.
if the function developer has received a particular
requirement from the OEM or from a standardization
body.
This attribute applies for the UDS diagnostics use case.

Table D.26: DiagnosticEventInfoNeeds

Class EcuAbstractionSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note The ECUAbstraction is a special AtomicSwComponentType that resides between a software-component
that wants to access ECU periphery and the Microcontroller Abstraction. The EcuAbstractionSw
ComponentType introduces the possibility to link from the software representation to its hardware
description provided by the ECU Resource Template.
Tags: atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtomicSwComponentType, AtpBlueprint, AtpBlueprintable, AtpClassifier , Atp
Type, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable, Sw
ComponentType
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
hardware HwDescriptionEntity * ref Reference from the EcuAbstractionComponentType to the
Element description of the used HwElements.

Table D.27: EcuAbstractionSwComponentType

Class EcucModuleConfigurationValues
Package M2::AUTOSARTemplates::ECUCDescriptionTemplate
Note Head of the configuration of one Module. A Module can be a BSW module as well as the RTE and ECU
Infrastructure.
As part of the BSW module description, the EcucModuleConfigurationValues element has two different
roles:
The recommendedConfiguration contains parameter values recommended by the BSW module vendor.
The preconfiguredConfiguration contains values for those parameters which are fixed by the
implementation and cannot be changed.
These two EcucModuleConfigurationValues are used when the base EcucModuleConfigurationValues
(as part of the base ECU configuration) is created to fill parameters with initial values.
Tags: atp.recommendedPackage=EcucModuleConfigurationValuess
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
5

313 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

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

Class EcucModuleDef
Package M2::AUTOSARTemplates::ECUCParameterDefTemplate
Note Used as the top-level element for configuration definition for Software Modules, including BSW and RTE
as well as ECU Infrastructure.
Tags: atp.recommendedPackage=EcucModuleDefs
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpDefinition, CollectableElement, Ecuc
DefinitionElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
5

314 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class EcucModuleDef
apiServicePrefix CIdentifier 0..1 attr For modules where several instances of the VSMD can
be defined the apiServicePrefix defines the API
namespace of the derived instances, e.g. Cdd, Xfrm
(ComXf, SomeIpXf, E2EXf).
container EcucContainerDef * aggr Aggregates the top-level container definitions of this
specific module definition.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=container.shortName
xml.sequenceOffset=11
postBuildVariant Boolean 0..1 attr Indicates if a module supports different post-build variants
Support (previously known as post-build selectable configuration
sets). TRUE means yes, FALSE means no.
refinedModule EcucModuleDef 0..1 ref Optional reference from the Vendor Specific Module
Def Definition to the Standardized Module Definition it refines.
In case this EcucModuleDef has the category
STANDARDIZED_MODULE_DEFINITION this reference
shall not be provided. In case this EcucModuleDef has
the category VENDOR_SPECIFIC_MODULE_
DEFINITION this reference is mandatory.
Stereotypes: atpUriDef
supported EcucConfiguration * attr Specifies which ConfigurationVariants are supported by
ConfigVariant VariantEnum this software module. This attribute is optional if the Ecuc
ModuleDef has the category STANDARDIZED_
MODULE_DEFINITION. If the category attribute of the
EcucModuleDef is set to VENDOR_SPECIFIC_
MODULE_DEFINITION then this attribute is mandatory.

Table D.29: EcucModuleDef

Class ExecutableEntityActivationReason
Package M2::AUTOSARTemplates::CommonStructure::InternalBehavior
Note This meta-class represents the ability to define the reason for the activation of the enclosing Executable
Entity.
Base ARObject, ImplementationProps, Referrable
Aggregated by ExecutableEntity .activationReason
Attribute Type Mult. Kind Note
bitPosition PositiveInteger 0..1 attr This attribute allows for defining the position of the
enclosing ExecutableEntityActivationReason in the
activation vector.
Table D.30: ExecutableEntityActivationReason

Class ExternalTriggeringPoint
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::Trigger
Note If a RunnableEntity owns an ExternalTriggeringPoint it is entitled to raise an ExternalTriggerOccurred
Event.
Base ARObject
Aggregated by RunnableEntity.externalTriggeringPoint
Attribute Type Mult. Kind Note
5

315 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ExternalTriggeringPoint
ident ExternalTriggeringPoint 0..1 aggr The aggregation in the role ident provides the ability to
Ident make the ExternalTriggeringPoint identifiable.
From the semantical point of view, the ExternalTriggering
Point is considered a first-class Identifiable and therefore
the aggregation in the role ident shall always exist (until it
may be possible to let ModeAccessPoint directly inherit
from Identifiable).
Stereotypes: atpIdentityContributor
Tags: xml.sequenceOffset=-100
trigger Trigger 0..1 iref The trigger taken for the ExternalTriggeringPoint.
Tags:
xml.namePlural=TRIGGER-IREF
xml.roleElement=false
xml.roleWrapperElement=true
xml.typeElement=true
xml.typeWrapperElement=false
InstanceRef implemented by: PTriggerInAtomicSwc
TypeInstanceRef

Table D.31: ExternalTriggeringPoint

Class FlatInstanceDescriptor
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note Represents exactly one node (e.g. a component instance or data element) of the instance tree of a
software system. The purpose of this element is to map the various nested representations of this
instance to a flat representation and assign a unique name (shortName) to it.
Use cases:
• Specify unique names of measurable data to be used by MCD tools
• Specify unique names of calibration data to be used by MCD tool
• Specify a unique name for an instance of a component prototype in the ECU extract of the system
description
Note that in addition it is possible to assign alias names via AliasNameAssignment.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by FlatMap.instance
Attribute Type Mult. Kind Note
ecuExtract AtpFeature 0..1 iref Refers to the instance in the ECU extract. This is valid
Reference only, if the FlatMap is used in the context of an ECU
extract.
The reference shall be such that it uniquely defines the
object instance. For example, if a data prototype is
declared as a role within an SwcInternalBehavior, it is not
enough to state the SwcInternalBehavior as context and
the aggregated data prototype as target. In addition, the
reference shall also include the complete path identifying
instance of the component prototype and the Atomic
SoftwareComponentType, which is refered by the
particular SwcInternalBehavior.
Tags: xml.sequenceOffset=40
InstanceRef implemented by: AnyInstanceRef
5

316 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class FlatInstanceDescriptor
role Identifier 0..1 attr The role denotes the particular role of the downstream
memory location described by this FlatInstanceDescriptor.
It applies to use case where one upstream object results
in multiple downstream objects, e.g. ModeDeclaration
GroupPrototypes which are measurable. In this case the
RTE will provide locations for current mode, previous
mode and next mode.
rtePluginProps RtePluginProps 0..1 aggr The properties of a communication graph with respect to
the utilization of RTE Implementation Plug-in.
Stereotypes: atpSplitable
Tags: atp.Splitkey=rtePluginProps
swDataDef SwDataDefProps 0..1 aggr The properties of this FlatInstanceDescriptor.
Props
Stereotypes: atpSplitable
Tags: atp.Splitkey=swDataDefProps
upstream AtpFeature 0..1 iref Refers to the instance in the context of an "upstream"
Reference description, which could be: the SYSTEM_
DESCRIPTION, or SYSTEM_EXTRACT, or ECU_
SYSTEM_DESCRIPTION, or SW_CLUSTER_SYSTEM_
DESCRIPTION, or the basic software module description
(in this case only the target reference of the AnyInstance
Ref is needed), or (if a flat map is used in preliminary
context) a description of an atomic component or
composition.
This reference is optional in case the flat map is used in
ECU context. The reference shall be such that it uniquely
defines the object instance in the given context. For
example, if a data prototype is declared as a role within
an SwcInternal Behavior, it is not enough to state the Swc
Internal Behavior as context and the aggregated data
prototype as target. In addition, the reference shall also
include the complete path identifying the instance of the
component prototype that contains the particular instance
of Swc InternalBehavior.
Tags: xml.sequenceOffset=20
InstanceRef implemented by: AnyInstanceRef

Table D.32: FlatInstanceDescriptor

Class FlatMap
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note Contains a flat list of references to software objects. This list is used to identify instances and to resolve
name conflicts. The scope is given by the RootSwCompositionPrototype for which it is used, i.e. it can be
applied to a system, system extract or ECU-extract.
An instance of FlatMap may also be used in a preliminary context, e.g. in the scope of a software
component before integration into a system. In this case it is not referred by a RootSwComposition
Prototype.
Tags: atp.recommendedPackage=FlatMaps
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
5

317 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class FlatMap
instance FlatInstanceDescriptor * aggr A descriptor instance aggregated in the flat map.
The variation point accounts for the fact, that the system
in scope can be subject to variability, and thus the
existence of some instances is variable.
The aggregation has been made splitable because the
content might be contributed by different stakeholders at
different times in the workflow. Plus, the overall size might
be so big that eventually it becomes more manageable if
it is distributed over several files.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=instance.shortName, instance.variation
Point.shortLabel
vh.latestBindingTime=postBuild

Table D.33: FlatMap

Class FunctionInhibitionAvailabilityNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Function Inhibition Manager to provide the
control function for one Function Identifier (FID).
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
controlledFid FunctionInhibitionNeeds 0..1 ref This reference represents the controlled FID

Table D.34: FunctionInhibitionAvailabilityNeeds

Class GlobalSupervisionNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs on the configuration of the Watchdog Manager to get access on the Global
Supervision control and status interface.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, ServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table D.35: GlobalSupervisionNeeds

Class Identifiable (abstract)

Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable
Note Instances of this class can be referred to by their identifier (within the namespace borders). In addition to
this, Identifiables are objects which contribute significantly to the overall structure of an AUTOSAR
description. In particular, Identifiables might contain Identifiables.
Base ARObject, MultilanguageReferrable, Referrable
5

318 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class Identifiable (abstract)
Subclasses ARPackage, AbstractDoIpLogicAddressProps, AbstractEvent, AbstractImplementationDataTypeElement,
AbstractSecurityEventFilter , AbstractSecurityIdsmInstanceFilter , AbstractServiceInstance, AppOsTask
ProxyToEcuTaskProxyMapping, ApplicationEndpoint, ApplicationError, ApplicationPartitionToEcuPartition
Mapping, AppliedStandard, AsynchronousServerCallResultPoint, AtpBlueprint, AtpBlueprintable, Atp
Classifier , AtpFeature, AutosarOperationArgumentInstance, AutosarVariableInstance, BinaryManifest
AddressableObject, BinaryManifestItemDefinition, BinaryManifestResource, BinaryManifestResource
Definition, BlockState, BswInternalTriggeringPoint, BswModuleDependency, BuildActionEntity , Build
ActionEnvironment, CanTpAddress, CanTpChannel, CanTpNode, Chapter, ClassContentConditional,
ClientIdDefinition, ClientServerOperation, Code, CollectableElement, ComManagementMapping, Comm
ConnectorPort, CommunicationConnector , CommunicationController , Compiler, ConsistencyNeeds,
ConsumedEventGroup, CouplingElementAbstractDetails, CouplingPort, CouplingPortAbstractShaper ,
CouplingPortStructuralElement, CpSoftwareClusterResource, CpSoftwareClusterResourceToApplication
PartitionMapping, CpSoftwareClusterToApplicationPartitionMapping, CpSoftwareClusterToEcuInstance
Mapping, CpSoftwareClusterToResourceMapping, CryptoServiceMapping, DataPrototypeGroup, Data
Transformation, DdsCpDomain, DdsCpPartition, DdsCpQosProfile, DdsCpTopic, DependencyOnArtifact,
DiagEventDebounceAlgorithm, DiagnosticAuthTransmitCertificateEvaluation, DiagnosticConnected
Indicator, DiagnosticDataElement, DiagnosticDebounceAlgorithmProps, DiagnosticFunctionInhibit
Source, DiagnosticParameterElement, DiagnosticRoutineSubfunction, DltApplication, DltArgument, Dlt
LogChannel, DltMessage, DoIpInterface, DoIpLogicAddress, DoIpRoutingActivation, ECUMapping, EOC
ExecutableEntityRefAbstract, EcuPartition, EcucContainerValue, EcucDefinitionElement, Ecuc
DestinationUriDef, EcucEnumerationLiteralDef, EcucQuery, EcucValidationCondition, EndToEnd
Protection, EthernetWakeupSleepOnDatalineConfig, EventHandler, ExclusiveArea, ExecutableEntity ,
ExecutionTime, FMAttributeDef, FMFeatureMapAssertion, FMFeatureMapCondition, FMFeatureMap
Element, FMFeatureRelation, FMFeatureRestriction, FMFeatureSelection, FlatInstanceDescriptor,
FlexrayArTpNode, FlexrayTpConnectionControl, FlexrayTpNode, FlexrayTpPduPool, FrameTriggering,
GeneralParameter, GlobalTimeGateway, GlobalTimeMaster , GlobalTimeSlave, HeapUsage, HwAttribute
Def, HwAttributeLiteralDef, HwPin, HwPinGroup, IEEE1722TpAcfBus, IEEE1722TpAcfBusPart, IPSec
Rule, IPv6ExtHeaderFilterList, ISignalToIPduMapping, ISignalTriggering, IdentCaption, ImpositionTime,
InternalTriggeringPoint, J1939SharedAddressCluster, J1939TpNode, Keyword, LifeCycleState, Lin
ScheduleTable, LinTpNode, Linker, MacMulticastGroup, MacSecKayParticipant, McDataInstance,
MemorySection, ModeDeclaration, ModeDeclarationMapping, ModeSwitchPoint, NetworkEndpoint, Nm
Cluster , NmEcu, NmNode, NvBlockDescriptor, PackageableElement, ParameterAccess, PduActivation
RoutingGroup, PduToFrameMapping, PduTriggering, PerInstanceMemory, PhysicalChannel, Port
ElementToCommunicationResourceMapping, PortGroup, PortInterfaceMapping, PossibleErrorReaction,
ResourceConsumption, RootSwCompositionPrototype, RptComponent, RptContainer, RptExecutable
Entity, RptExecutableEntityEvent, RptExecutionContext, RptProfile, RptServicePoint, RteEventIn
CompositionSeparation, RteEventInCompositionToOsTaskProxyMapping, RteEventInSystemSeparation,
RteEventInSystemToOsTaskProxyMapping, RunnableEntityGroup, SdgAttribute, SdgClass, Secure
CommunicationAuthenticationProps, SecureCommunicationFreshnessProps, SecurityEventContext
Props, ServerCallPoint, ServiceNeeds, SignalServiceTranslationElementProps, SignalServiceTranslation
EventProps, SignalServiceTranslationProps, SocketAddress, SomeipTpChannel, SpecElement
Reference, StackUsage, StaticSocketConnection, StructuredReq, SwGenericAxisParamType, SwService
Arg, SwcServiceDependency, SwcToApplicationPartitionMapping, SwcToEcuMapping, SwcToImpl
Mapping, SwitchAsynchronousTrafficShaperGroupEntry, SwitchFlowMeteringEntry, SwitchStreamFilter
ActionDestPortModification, SwitchStreamFilterEntry, SwitchStreamFilterRule, SwitchStreamGateEntry,
SwitchStreamIdentification, SystemMapping, SystemSignalGroupToCommunicationResourceMapping,
SystemSignalToCommunicationResourceMapping, TDCpSoftwareClusterMapping, TDCpSoftware
ClusterResourceMapping, TcpOptionFilterList, TimingClock , TimingClockSyncAccuracy, Timing
Condition, TimingConstraint, TimingDescription, TimingExtensionResource, TimingModeInstance, Tls
CryptoCipherSuite, TlsCryptoCipherSuiteProps, Topic1, TpAddress, TraceableTable, TraceableText,
TracedFailure, TransformationProps, TransformationTechnology, Trigger, VariableAccess, VariationPoint
Proxy, ViewMap, VlanConfig, WaitPoint
Attribute Type Mult. Kind Note
adminData AdminData 0..1 aggr This represents the administrative data for the identifiable
object.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=adminData
xml.sequenceOffset=-40
5

319 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class Identifiable (abstract)
annotation Annotation * aggr Possibility to provide additional notes while defining a
model element (e.g. the ECU Configuration Parameter
Values). These are not intended as documentation but
are mere design notes.
Tags: xml.sequenceOffset=-25
category CategoryString 0..1 attr The category is a keyword that specializes the semantics
of the Identifiable. It affects the expected existence of
attributes and the applicability of constraints.
Tags: xml.sequenceOffset=-50
desc MultiLanguageOverview 0..1 aggr This represents a general but brief (one paragraph)
Paragraph description what the object in question is about. It is only
one paragraph! Desc is intended to be collected into
overview tables. This property helps a human reader to
identify the object in question.
More elaborate documentation, (in particular how the
object is built or used) should go to "introduction".
Tags: xml.sequenceOffset=-60
introduction DocumentationBlock 0..1 aggr This represents more information about how the object in
question is built or is used. Therefore it is a
DocumentationBlock.
Tags: xml.sequenceOffset=-30
uuid String 0..1 attr The purpose of this attribute is to provide a globally
unique identifier for an instance of a meta-class. The
values of this attribute should be globally unique strings
prefixed by the type of identifier. For example, to include a
DCE UUID as defined by The Open Group, the UUID
would be preceded by "DCE:". The values of this attribute
may be used to support merging of different AUTOSAR
models. The form of the UUID (Universally Unique
Identifier) is taken from a standard defined by the Open
Group (was Open Software Foundation). This standard is
widely used, including by Microsoft for COM (GUIDs) and
by many companies for DCE, which is based on CORBA.
The method for generating these 128-bit IDs is published
in the standard and the effectiveness and uniqueness of
the IDs is not in practice disputed. If the id namespace is
omitted, DCE is assumed. An example is
"DCE:2fac1234-31f8-11b4-a222-08002b34c003". The
uuid attribute has no semantic meaning for an AUTOSAR
model and there is no requirement for AUTOSAR tools to
manage the timestamp.
Tags: xml.attribute=true

Table D.36: Identifiable

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
Aggregated by ARPackage.element
5

320 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ImplementationDataType
Attribute Type Mult. 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.
subElement ImplementationData * aggr Specifies an element of an array, struct, or union data
(ordered) TypeElement type.
The aggregation of ImplementionDataTypeElement is
subject to variability with the purpose to support the
conditional existence of elements inside a Implementation
DataType representing a structure.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=subElement.shortName, sub
Element.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
symbolProps SymbolProps 0..1 aggr This represents the SymbolProps for the Implementation
DataType.
Stereotypes: atpSplitable
Tags: atp.Splitkey=symbolProps.shortName
typeEmitter NameToken 0..1 attr This attribute is used to control which part of the
AUTOSAR toolchain is supposed to trigger data type
definitions.
Table D.37: ImplementationDataType

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
Aggregated by AtpClassifier .atpFeature, ImplementationDataType.subElement, ImplementationDataTypeElement.sub
Element
Attribute Type Mult. Kind Note
arrayImplPolicy ArrayImplPolicyEnum 0..1 attr This attribute controls the implementation of the payload
of an array. It shall only be used if the enclosing
ImplementationDataType constitutes an array.
5

321 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ImplementationDataTypeElement
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.
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.
subElement ImplementationData * aggr Element of an array, struct, or union in case of a nested
(ordered) 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: atpSplitable; atpVariation
Tags:
atp.Splitkey=subElement.shortName, sub
Element.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
swDataDef SwDataDefProps 0..1 aggr The properties of this ImplementationDataTypeElement.
Props
Stereotypes: atpSplitable
Tags: atp.Splitkey=swDataDefProps

Table D.38: ImplementationDataTypeElement

Class InternalTriggeringPoint
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::Trigger
Note If a RunnableEntity owns an InternalTriggeringPoint it is entitled to trigger the execution of Runnable
Entities of the corresponding software-component.
Base ARObject, AbstractAccessPoint, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable,
MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, RunnableEntity.internalTriggeringPoint
Attribute Type Mult. Kind Note
swImplPolicy SwImplPolicyEnum 0..1 attr This attribute, when set to value queued, allows for a
queued processing of Triggers.

Table D.39: InternalTriggeringPoint

322 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ModeAccessPoint
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::ModeDeclarationGroup
Note A ModeAccessPoint is required by a RunnableEntity owned by a Mode Manager or Mode User. Its
semantics implies the ability to access the current mode (provided by the RTE) of a ModeDeclaration
GroupPrototype’s ModeDeclarationGroup.
Base ARObject
Aggregated by RunnableEntity.modeAccessPoint
Attribute Type Mult. Kind Note
ident ModeAccessPointIdent 0..1 aggr The aggregation in the role ident provides the ability to
make the ModeAccessPoint identifiable.
From the semantical point of view, the ModeAccessPoint
is considered a first-class Identifiable and therefore the
aggregation in the role ident shall always exist (until it
may be possible to let ModeAccessPoint directly inherit
from Identifiable).
Stereotypes: atpIdentityContributor
Tags: xml.sequenceOffset=-100
modeGroup ModeDeclarationGroup 0..1 iref The mode declaration group that is accessed by this
Prototype runnable.
Tags: xml.typeElement=true
InstanceRef implemented by: ModeGroupInAtomicSwc
InstanceRef
Table D.40: ModeAccessPoint

Class ModeSwitchPoint
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::ModeDeclarationGroup
Note A ModeSwitchPoint is required by a RunnableEntity owned a Mode Manager. Its semantics implies the
ability to initiate a mode switch.
Base ARObject, AbstractAccessPoint, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable,
MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, RunnableEntity.modeSwitchPoint
Attribute Type Mult. Kind Note
modeGroup ModeDeclarationGroup 0..1 iref The mode declaration group that is switched by this
Prototype runnable.
InstanceRef implemented by: PModeGroupInAtomic
SwcInstanceRef

Table D.41: ModeSwitchPoint

Class NumericalOrText
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note This meta-class represents the ability to yield either a numerical or a string. A typical use case is that two
or more instances of this meta-class are aggregated with a VariationPoint where some instances yield
strings while other instances yield numerical depending on the resolution of the binding expression.
Base ARObject
Aggregated by RuleArguments.vtf, SwValues.vtf
Attribute Type Mult. Kind Note
5

323 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class NumericalOrText
vf Numerical 0..1 attr This attribute represents the ability to provide a numerical
value. The latest binding time of the VariationPoint shall
be preCompileTime.
Stereotypes: atpVariation
Tags:
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=10
vt String 0..1 attr This attribute represents the ability to provide a textual
value.
Tags: xml.sequenceOffset=20

Table D.42: NumericalOrText

Class NumericalValueSpecification
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note 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.
Base ARObject, ValueSpecification
Aggregated by ApplicationAssocMapElementValueSpecification.key, ApplicationAssocMapElementValueSpecification.
value, ArrayValueSpecification.element, CalibrationParameterValue.applInitValue, CalibrationParameter
Value.implInitValue, ConstantSpecification.valueSpec, CryptoServiceKey.developmentValue, Diagnostic
EnvDataCondition.compareValue, DiagnosticEnvDataElementCondition.compareValue, FieldSenderCom
Spec.initValue, ISignal.initValue, ISignal.timeoutSubstitutionValue, NonqueuedReceiverComSpec.init
Value, NonqueuedReceiverComSpec.timeoutSubstitutionValue, NonqueuedSenderComSpec.initValue,
NvProvideComSpec.ramBlockInitValue, NvProvideComSpec.romBlockInitValue, NvRequireComSpec.init
Value, ParameterDataPrototype.initValue, ParameterProvideComSpec.initValue, ParameterRequireCom
Spec.initValue, PersistencyDataRequiredComSpec.initValue, PersistencyKeyValuePair.initValue, Port
DefinedArgumentValue.value, PortPrototypeBlueprintInitValue.value, RecordValueSpecification.field,
SomeipEventDeployment.eventReceptionDefaultValue, StateManagementCompareCondition.compare
Value, SwDataDefProps.invalidValue, VariableDataPrototype.initValue
Attribute Type Mult. Kind Note
value Numerical 0..1 attr This is the value itself.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table D.43: NumericalValueSpecification

Class ObdInfoServiceNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs of a component or module on the configuration of OBD Services in relation
to a given InfoType (OBD Service 09) which is supported by this component or module.
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table D.44: ObdInfoServiceNeeds

324 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ObdPidServiceNeeds
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note Specifies the abstract needs of a component or module on the configuration of OBD Services in relation
to a particular PID (parameter identifier) which is supported by this component or module.
In case of using a client/server communicated value, the related value shall be communicated via the
port referenced by assignedPort. The details of this communication (e.g. appropriate naming
conventions) are specified in the related software specifications (SWS).
Base ARObject, DiagnosticCapabilityElement, Identifiable, MultilanguageReferrable, Referrable, Service
Needs
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
Attribute Type Mult. Kind Note
– – – – –
Table D.45: ObdPidServiceNeeds

Class OperationInvokedEvent
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::RTEEvents
Note This event is raised when the ClientServerOperation referenced in OperationInvokedEvent.operation
shall be invoked.
Base ARObject, AbstractEvent, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, Multilanguage
Referrable, RTEEvent, Referrable
Aggregated by AtpClassifier .atpFeature, SwcInternalBehavior.event
Attribute Type Mult. Kind Note
operation ClientServerOperation 0..1 iref This represents the ClientServerOperation which shall be
invoked.
InstanceRef implemented by: POperationInAtomicSwc
InstanceRef
Table D.46: OperationInvokedEvent

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
Aggregated by AtpClassifier .atpFeature, SwComponentType.port
Attribute Type Mult. Kind Note
provided PortInterface 0..1 tref This represents the PortInterface used to type the PRPort
Required Prototype
Interface
Stereotypes: isOfType

Table D.47: PRPortPrototype

Class ParameterAccess
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::DataElements
Note The presence of a ParameterAccess implies that a RunnableEntity needs access to a ParameterData
Prototype.
Base ARObject, AbstractAccessPoint, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable,
MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, RunnableEntity.parameterAccess
5

325 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class ParameterAccess
Attribute Type Mult. Kind Note
accessed AutosarParameterRef 0..1 aggr Reference to the accessed calibration parameter.
Parameter
swDataDef SwDataDefProps 0..1 aggr This allows denote instance and access specific
Props properties, mainly input values and common axis.
Stereotypes: atpSplitable
Tags: atp.Splitkey=swDataDefProps

Table D.48: ParameterAccess

Class PortDefinedArgumentValue
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::PortAPIOptions
Note A PortDefinedArgumentValue is passed to a RunnableEntity dealing with the ClientServerOperations
provided by a given PortPrototype. Note that this is restricted to PPortPrototypes of a ClientServer
Interface.
Base ARObject
Aggregated by PortAPIOption.portArgValue
Attribute Type Mult. Kind Note
value ValueSpecification 0..1 aggr Specifies the actual value.
valueType ImplementationData 0..1 tref The implementation type of this argument value. It should
Type not be composite type or a pointer.
Stereotypes: isOfType

Table D.49: PortDefinedArgumentValue

Class PortPrototype (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Base class for the ports of an AUTOSAR software component.
The aggregation of PortPrototypes is subject to variability with the purpose to support the conditional
existence of ports.
Base ARObject, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Subclasses AbstractProvidedPortPrototype, AbstractRequiredPortPrototype
Aggregated by AtpClassifier .atpFeature, SwComponentType.port
Attribute Type Mult. Kind Note
clientServer ClientServerAnnotation * aggr Annotation of this PortPrototype with respect to client/
Annotation server communication.
delegatedPort DelegatedPort 0..1 aggr Annotations on this delegated port.
Annotation Annotation
ioHwAbstraction IoHwAbstractionServer * aggr Annotations on this IO Hardware Abstraction port.
Server Annotation
Annotation
modePort ModePortAnnotation * aggr Annotations on this mode port.
Annotation
nvDataPort NvDataPortAnnotation * aggr Annotations on this non voilatile data port.
Annotation
parameterPort ParameterPort * aggr Annotations on this parameter port.
Annotation Annotation
senderReceiver SenderReceiver * aggr Collection of annotations of this ports sender/receiver
Annotation Annotation communication.
triggerPort TriggerPortAnnotation * aggr Annotations on this trigger port.
Annotation
Table D.50: PortPrototype

326 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RTEEvent (abstract)

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

Table D.51: RTEEvent

Class RapidPrototypingScenario
Package M2::AUTOSARTemplates::SWComponentTemplate::RPTScenario
Note This meta-class provides the ability to describe a Rapid Prototyping Scenario. Such a Rapid Prototyping
Scenario consist out of two main aspects, the description of the byPassPoints and the relation to an rpt
Hook.
Tags: atp.recommendedPackage=RapidPrototypingScenarios
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
hostSystem System 0..1 ref System which describes the software components of the
host ECU.
rptContainer RptContainer * aggr Top-level rptContainer definitions of this specific rapid
prototyping scenario.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rptContainer.shortName, rpt
Container.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
rptProfile RptProfile * aggr Defiens the applicable Rapid Prototyping profils which are
especially defining the smbol of the service functions and
the valid id range. The order of the RptProfiles determines
the order of the service function invocation by RTE.
Stereotypes: atpSplitable
Tags: atp.Splitkey=rptProfile.shortName
rptSystem System 0..1 ref System which describes the rapid prototyping algorithm in
the format of AUTOSAR Software Components.
Stereotypes: atpSplitable
Tags: atp.Splitkey=rptSystem

Table D.52: RapidPrototypingScenario

327 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RecordValueSpecification
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note Specifies the values for a record.
Base ARObject, CompositeValueSpecification, ValueSpecification
Aggregated by ApplicationAssocMapElementValueSpecification.key, ApplicationAssocMapElementValueSpecification.
value, ArrayValueSpecification.element, CalibrationParameterValue.applInitValue, CalibrationParameter
Value.implInitValue, CompositeRuleBasedValueSpecification.argument, ConstantSpecification.value
Spec, CryptoServiceKey.developmentValue, DiagnosticEnvDataCondition.compareValue, DiagnosticEnv
DataElementCondition.compareValue, FieldSenderComSpec.initValue, ISignal.initValue, ISignal.timeout
SubstitutionValue, NonqueuedReceiverComSpec.initValue, NonqueuedReceiverComSpec.timeout
SubstitutionValue, NonqueuedSenderComSpec.initValue, NvProvideComSpec.ramBlockInitValue, Nv
ProvideComSpec.romBlockInitValue, NvRequireComSpec.initValue, ParameterDataPrototype.initValue,
ParameterProvideComSpec.initValue, ParameterRequireComSpec.initValue, PersistencyDataRequired
ComSpec.initValue, PersistencyKeyValuePair.initValue, PortDefinedArgumentValue.value, PortPrototype
BlueprintInitValue.value, RecordValueSpecification.field, SomeipEventDeployment.eventReception
DefaultValue, StateManagementCompareCondition.compareValue, SwDataDefProps.invalidValue,
VariableDataPrototype.initValue
Attribute Type Mult. Kind Note
field (ordered) ValueSpecification * aggr The value for a single record field. This could also be
mapped explicitly to a record element of the data type
using the shortName of the ValueSpecification. But this
would introduce a relationship to the data type that is too
strong. As of now, it is only important that the structure of
the data type matches the structure of the Value
Specification independently of the shortNames.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=field, field.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table D.53: RecordValueSpecification

Class Referrable (abstract)

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

Table D.54: Referrable

328 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RoleBasedMcDataAssignment
Package M2::AUTOSARTemplates::CommonStructure::MeasurementCalibrationSupport
Note This meta-class allows to define links that specify logical relationships between single McDataInstances.
The details on the existence and semantics of such links are not standardized.
Possible Use Case: Rapid Prototyping solutions in which additional communication buffers and switches
are implemented in the RTE that allow to switch between the usage of the original and the bypass
buffers. The different buffers and the switch can be represented by McDataInstances (in order to be
accessed by MC tools) which have relationships to each other.
Base ARObject
Aggregated by McDataInstance.mcDataAssignment, RptComponent.mcDataAssignment, RptExecutableEntity.rptRead,
RptExecutableEntity.rptWrite, RptExecutableEntityEvent.mcDataAssignment
Attribute Type Mult. Kind Note
execution RptExecutionContext * ref Determines the executionContext in which the McData
Context Instance describing a local (e.g Task-Local) buffer of a
global buffer is valid.
mcDataInstance McDataInstance * ref The target of the assignment.
role Identifier 0..1 attr Shall be used to specify the role of the assigned data
instance in relation to the instance that owns the
assignment.
The standardized roles of the RoleBasedMcData
Assignment.role attribute are:
• GlobalMeasurementBuffer
• RpEnablerFlag
• RpRunnableDisablerFlag
• BufferOf

Table D.55: RoleBasedMcDataAssignment

Class RoleBasedPortAssignment
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::ServiceMapping
Note This class specifies an assignment of a role to a particular service port (RPortPrototype or PPort
Prototype) of an AtomicSwComponentType. With this assignment, the role of the service port can be
mapped to a specific ServiceNeeds element, so that a tool is able to create the correct connector.
Base ARObject
Aggregated by NvBlockDescriptor.clientServerPort, SwcServiceDependency.assignedPort
Attribute Type Mult. Kind Note
portPrototype PortPrototype 0..1 ref Service PortPrototype used in the assigned role. This
PortPrototype shall either belong to the same AtomicSw
ComponentType as the SwcInternalBehavior which owns
the ServiceDependency or to the same NvBlockSw
ComponentType as the NvBlockDescriptor.
role Identifier 0..1 attr This is the role of the assigned Port in the given context.
The value shall be a shortName of the Blueprint of a Port
Interface as standardized in the Software Specification of
the related AUTOSAR Service.

Table D.56: RoleBasedPortAssignment

Class <<atpMixed>> RuleArguments

Package M2::AUTOSARTemplates::CommonStructure::Constants
Note This represents the arguments for a rule-based value specification.
Base ARObject
5

329 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class <<atpMixed>> RuleArguments
Aggregated by RuleBasedValueSpecification.arguments
Attribute Type Mult. Kind Note
v Numerical 0..1 attr This represents a numerical value for the RuleBased
ValueSpecification.
vf Numerical 0..1 attr This represents a numerical value for the RuleBased
ValueSpecification which may subject to variability. The
latest binding time of the VariationPoint shall be pre
CompileTime.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
vt VerbatimString 0..1 attr This represents a textual value for the RuleBasedValue
Specification.
vtf NumericalOrText 0..1 aggr This aggregation represents the ability to provide a value
that is either numerical or text which existence is subject
to variability.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=vtf, vtf.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table D.57: RuleArguments

Class RuleBasedValueCont
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note This represents the values of a compound primitive (CURVE, MAP, CUBOID, CUBE_4, CUBE_5, VAL_
BLK) or an array.
Base ARObject
Aggregated by ApplicationRuleBasedValueSpecification.swValueCont
Attribute Type Mult. Kind Note
ruleBased RuleBasedValue 0..1 aggr This represents the rule based value specification for the
Values Specification array or compound primitive (CURVE, MAP, CUBOID,
CUBE_4, CUBE_5, VAL_BLK).
Stereotypes: atpSplitable
Tags:
atp.Splitkey=ruleBasedValues
xml.roleElement=true
xml.roleWrapperElement=false
xml.sequenceOffset=80
xml.typeWrapperElement=false
swArraysize ValueList 0..1 aggr This attribute defines the size of each dimension for
compound primitives CURVE, MAP, CUBOID, CUBE_4,
CUBE_5, COM_AXIS, RES_AXIS, VAL_BLK.
For each dimension one value has to be defined, e.g. one
in case of COM_AXIS and two or more in case of MAP.
Tags: xml.sequenceOffset=40
unit Unit 0..1 ref This represents the physical unit of the provided values.
Tags: xml.sequenceOffset=30

Table D.58: RuleBasedValueCont

330 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class RuleBasedValueSpecification
Package M2::AUTOSARTemplates::CommonStructure::Constants
Note This meta-class is used to support a rule-based initialization approach for data types with an array-nature
(ApplicationArrayDataType and ImplementationDataType of category ARRAY) or a compound Application
PrimitiveDataType (which also boils down to an array-nature).
Base ARObject
Aggregated by NumericalRuleBasedValueSpecification.ruleBasedValues, RuleBasedAxisCont.ruleBasedValues, Rule
BasedValueCont.ruleBasedValues
Attribute Type Mult. Kind Note
arguments RuleArguments 0..1 aggr This represents the arguments for the RuleBasedValue
Specification.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=arguments, arguments.variationPoint.short
Label
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=30
maxSizeToFill Integer 0..1 attr If a rule is chosen which does not fill until the end, this
determines until which size the rule shall fill the values.
Tags: xml.sequenceOffset=40
rule Identifier 0..1 attr This denotes the name of the rule of the RuleBasedValue
Specification. The rule determines the calculation
specification according which the arguments are used to
calculated the values.
Tags: xml.sequenceOffset=20

Table D.59: RuleBasedValueSpecification

Class RunnableEntity
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior
Note A RunnableEntity represents the smallest code-fragment that is provided by an AtomicSwComponent
Type and are executed under control of the RTE. RunnableEntities are for instance set up to respond to
data reception or operation invocation on a server.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, ExecutableEntity , Identifiable, Multilanguage
Referrable, Referrable
Aggregated by AtpClassifier .atpFeature, SwcInternalBehavior.runnable
Attribute Type Mult. Kind Note
argument RunnableEntity * aggr This represents the formal definition of a an argument to
(ordered) Argument a RunnableEntity.
asynchronous AsynchronousServer * aggr The server call result point admits a runnable to fetch the
ServerCall CallResultPoint result of an asynchronous server call.
ResultPoint
The aggregation of AsynchronousServerCallResultPoint
is subject to variability with the purpose to support the
conditional existence of client server PortPrototypes and
the variant existence of server call result points in the
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=asynchronousServerCallResultPoint.short
Name, asynchronousServerCallResultPoint.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
5

331 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class RunnableEntity
canBeInvoked Boolean 0..1 attr If the value of this attribute is set to "true" the enclosing
Concurrently RunnableEntity can be invoked concurrently (even for one
instance of the corresponding AtomicSwComponent
Type). This implies that it is the responsibility of the
implementation of the RunnableEntity to take care of this
form of concurrency.
dataRead VariableAccess * aggr RunnableEntity has implicit read access to dataElement
Access of a sender-receiver PortPrototype or nv data of a nv data
PortPrototype.
The aggregation of dataReadAccess is subject to
variability with the purpose to support the conditional
existence of sender receiver ports or the variant existence
of dataReadAccess in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataReadAccess.shortName, dataRead
Access.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
dataReceive VariableAccess * aggr RunnableEntity has explicit read access to dataElement
PointBy of a sender-receiver PortPrototype or nv data of a nv data
Argument PortPrototype. The result is passed back to the
application by means of an argument in the function
signature.
The aggregation of dataReceivePointByArgument is
subject to variability with the purpose to support the
conditional existence of sender receiver PortPrototype or
the variant existence of data receive points in the
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataReceivePointByArgument.shortName,
dataReceivePointByArgument.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
dataReceive VariableAccess * aggr RunnableEntity has explicit read access to dataElement
PointByValue of a sender-receiver PortPrototype or nv data of a nv data
PortPrototype.
The result is passed back to the application by means of
the return value. The aggregation of dataReceivePointBy
Value is subject to variability with the purpose to support
the conditional existence of sender receiver ports or the
variant existence of data receive points in the
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataReceivePointByValue.shortName, data
ReceivePointByValue.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
5

332 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class RunnableEntity
dataSendPoint VariableAccess * aggr RunnableEntity has explicit write access to dataElement
of a sender-receiver PortPrototype or nv data of a nv data
PortPrototype.
The aggregation of dataSendPoint is subject to variability
with the purpose to support the conditional existence of
sender receiver PortPrototype or the variant existence of
data send points in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataSendPoint.shortName, dataSend
Point.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
dataWrite VariableAccess * aggr RunnableEntity has implicit write access to dataElement
Access of a sender-receiver PortPrototype or nv data of a nv data
PortPrototype.
The aggregation of dataWriteAccess is subject to
variability with the purpose to support the conditional
existence of sender receiver ports or the variant existence
of dataWriteAccess in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataWriteAccess.shortName, dataWrite
Access.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
external ExternalTriggeringPoint * aggr The aggregation of ExternalTriggeringPoint is subject to
TriggeringPoint variability with the purpose to support the conditional
existence of trigger ports or the variant existence of
external triggering points in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=externalTriggeringPoint.ident.shortName,
externalTriggeringPoint.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
internal InternalTriggeringPoint * aggr The aggregation of InternalTriggeringPoint is subject to
TriggeringPoint variability with the purpose to support the variant
existence of internal triggering points in the
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=internalTriggeringPoint.shortName, internal
TriggeringPoint.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
modeAccess ModeAccessPoint * aggr The runnable has a mode access point. The aggregation
Point of ModeAccessPoint is subject to variability with the
purpose to support the conditional existence of mode
ports or the variant existence of mode access points in
the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=modeAccessPoint.ident.shortName, mode
AccessPoint.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
5

333 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class RunnableEntity
modeSwitch ModeSwitchPoint * aggr The runnable has a mode switch point. The aggregation
Point of ModeSwitchPoint is subject to variability with the
purpose to support the conditional existence of mode
ports or the variant existence of mode switch points in the
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=modeSwitchPoint.shortName, modeSwitch
Point.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
parameter ParameterAccess * aggr The presence of a ParameterAccess implies that a
Access RunnableEntity needs read only access to a Parameter
DataPrototype which may either be local or within a Port
Prototype.
The aggregation of ParameterAccess is subject to
variability with the purpose to support the conditional
existence of parameter ports and component local
parameters as well as the variant existence of Parameter
Access (points) in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=parameterAccess.shortName, parameter
Access.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
readLocal VariableAccess * aggr The presence of a readLocalVariable implies that a
Variable RunnableEntity needs read access to a VariableData
Prototype in the role of implicitInterRunnableVariable or
explicitInterRunnableVariable.
The aggregation of readLocalVariable is subject to
variability with the purpose to support the conditional
existence of implicitInterRunnableVariable and explicit
InterRunnableVariable or the variant existence of read
LocalVariable (points) in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=readLocalVariable.shortName, readLocal
Variable.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
serverCallPoint ServerCallPoint * aggr The RunnableEntity has a ServerCallPoint. The
aggregation of ServerCallPoint is subject to variability with
the purpose to support the conditional existence of client
server PortPrototypes or the variant existence of server
call points in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=serverCallPoint.shortName, serverCall
Point.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
symbol CIdentifier 0..1 attr The symbol describing this RunnableEntity’s entry point.
This is considered the API of the RunnableEntity and is
required during the RTE contract phase.
waitPoint WaitPoint * aggr The WaitPoint associated with the RunnableEntity.
5

334 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class RunnableEntity
writtenLocal VariableAccess * aggr The presence of a writtenLocalVariable implies that a
Variable RunnableEntity needs write access to a VariableData
Prototype in the role of implicitInterRunnableVariable or
explicitInterRunnableVariable.
The aggregation of writtenLocalVariable is subject to
variability with the purpose to support the conditional
existence of implicitInterRunnableVariable and explicit
InterRunnableVariable or the variant existence of written
LocalVariable (points) in the implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=writtenLocalVariable.shortName, written
LocalVariable.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table D.60: RunnableEntity

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
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
dataElement VariableDataPrototype * aggr The data elements of this SenderReceiverInterface.
invalidation InvalidationPolicy * aggr InvalidationPolicy for a particular dataElement
Policy
metaDataItem MetaDataItemSet * aggr This aggregation defines fixed sets of meta-data items
Set associated with dataElements of the enclosing Sender
ReceiverInterface
Table D.61: SenderReceiverInterface

Class ServerCallPoint (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::ServerCall
Note If a RunnableEntity owns a ServerCallPoint it is entitled to invoke a particular ClientServerOperation of a
specific RPortPrototype of the corresponding AtomicSwComponentType
Base ARObject, AbstractAccessPoint, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable,
MultilanguageReferrable, Referrable
Subclasses AsynchronousServerCallPoint, SynchronousServerCallPoint
Aggregated by AtpClassifier .atpFeature, RunnableEntity.serverCallPoint
Attribute Type Mult. Kind Note
operation ClientServerOperation 0..1 iref The operation that is called by this runnable.
InstanceRef implemented by: ROperationInAtomicSwc
InstanceRef
timeout TimeValue 0..1 attr Time in seconds before the server call times out and
returns with an error message. It depends on the call type
(synchronous or asynchronous) how this is reported.

Table D.62: ServerCallPoint

335 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class ServiceSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note ServiceSwComponentType is used for configuring services for a given ECU. Instances of this class are
only to be created in ECU Configuration phase for the specific purpose of the service configuration.
Tags: atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtomicSwComponentType, AtpBlueprint, AtpBlueprintable, AtpClassifier , Atp
Type, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable, Sw
ComponentType
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
– – – – –
Table D.63: ServiceSwComponentType

Class SignalServiceTranslationProps
Package M2::AUTOSARTemplates::CommonStructure::SignalServiceTranslation
Note This element allows to define the properties which are applicable for the signal/service translation
service.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by SignalServiceTranslationPropsSet.signalServiceTranslationProps
Attribute Type Mult. Kind Note
control ConsumedEventGroup * ref Reference to the EventGroup which encapsulates the
Consumed signal-based payload.
EventGroup
controlPnc PncMappingIdent * ref Reference to the PNCs which control the offer/subscribe
behavior of the translated service instance.
Stereotypes: atpSplitable
Tags: atp.Splitkey=controlPnc
controlProvided EventHandler * ref Reference to the provided event group (aka Event
EventGroup Handler) which is automatically available when service
Control equals translationStart.
serviceControl SignalService 0..1 attr Defines how the service instance control shall behave.
TranslationControlEnum
signalService SignalService * aggr Defines properties for a single translated event.
Translation TranslationEventProps
EventProps

Table D.64: SignalServiceTranslationProps

Primitive String
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This represents a String in which white-space shall be normalized before processing. For example: in
order to compare two Strings:
• leading and trailing white-space needs to be removed
• consecutive white-space (blank, cr, lf, tab) needs to be replaced by one blank.
Tags:
xml.xsd.customType=STRING
xml.xsd.type=string

Table D.65: String

336 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

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
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
– – – – –
Table D.66: SwBaseType

Enumeration SwCalibrationAccessEnum
Package M2::MSR::DataDictionary::DataDefProperties
Note Determines the access rights to a data object w.r.t. measurement and calibration.
Aggregated by ModeDeclarationGroupPrototype.swCalibrationAccess, SwCalprmAxis.swCalibrationAccess, SwData
DefProps.swCalibrationAccess
Literal Description
notAccessible The element will not be accessible via MCD tools, i.e. will not appear in the ASAP file.
Tags: atp.EnumerationLiteralIndex=0
readOnly The element will only appear as read-only in an ASAP file.
Tags: atp.EnumerationLiteralIndex=1
readWrite The element will appear in the ASAP file with both read and write access.
Tags: atp.EnumerationLiteralIndex=2

Table D.67: SwCalibrationAccessEnum

Class SwComponentDocumentation
Package M2::AUTOSARTemplates::SWComponentTemplate::SoftwareComponentDocumentation
Note This class specifies the ability to write dedicated documentation to a component type according to ASAM
FSX.
Base ARObject
Aggregated by BswModuleDescription.bswModuleDocumentation, SwComponentType.swComponentDocumentation
Attribute Type Mult. Kind Note
chapter Chapter * aggr These chapters provide additional information about the
software component that do not fit in the other chapters.
Note that this is subject to variation because Chapter
aggregations in the role chapter are variant within the
documentation in general.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=chapter.shortName, chapter.variation
Point.shortLabel
vh.latestBindingTime=postBuild
xml.roleElement=true
xml.roleWrapperElement=false
xml.sequenceOffset=100
xml.typeElement=false
5

337 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwComponentDocumentation
swCalibration Chapter 0..1 aggr This element contains calibration instructions and hints
Notes for a calibration engineer.
Tags:
xml.roleElement=true
xml.sequenceOffset=60
xml.typeElement=false
swCarbDoc Chapter 0..1 aggr This element records the documentation requested by
CARB.
Tags:
xml.roleElement=true
xml.sequenceOffset=80
xml.typeElement=false
swDiagnostics Chapter 0..1 aggr This element contains general information about
Notes diagnostics issues within the component.
Tags:
xml.roleElement=true
xml.sequenceOffset=75
xml.typeElement=false
swFeatureDef Chapter 0..1 aggr This element contains the definition of the physical
functionality of this software component. This definition is
more or less formal and is intended to be delivered from
modeling tools.
Tags:
xml.roleElement=true
xml.sequenceOffset=20
xml.typeElement=false
swFeatureDesc Chapter 0..1 aggr This element contains the textual description of the
software functionality of this software component. Expert
should write this description.
Tags:
xml.roleElement=true
xml.sequenceOffset=30
xml.typeElement=false
swMaintenance Chapter 0..1 aggr This element contains information regarding the software
Notes maintenance of the component.
Tags:
xml.roleElement=true
xml.sequenceOffset=70
xml.typeElement=false
swTestDesc Chapter 0..1 aggr This element contains suggestions and hints for the test
of the software functionality of this software component.
Tags:
xml.roleElement=true
xml.sequenceOffset=50
xml.typeElement=false

Table D.68: SwComponentDocumentation

338 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

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 DataTypes in the
programming language (or in AUTOSAR). This is mainly expressed by properties like swRecordLayout
and swCalprmAxisSet
• Implementation aspects, mainly expressed by swImplPolicy, swVariableAccessImplPolicy, swAddr
Method, swPointerTagetProps, baseType, implementationDataType and additionalNativeTypeQualifier
• Access policy for the MCD system, mainly expressed by swCalibrationAccess
• Semantics of the data element, mainly expressed by compuMethod and/or unit, dataConstr, invalid
Value
• Code generation policy provided by swRecordLayout
Tags: vh.latestBindingTime=codeGenerationTime
Base ARObject
Aggregated by AutosarDataType.swDataDefProps, CompositeNetworkRepresentation.networkRepresentation, Data
Prototype.swDataDefProps, DataPrototypeTransformationProps.networkRepresentationProps,
DiagnosticDataElement.swDataDefProps, DiagnosticEnvDataElementCondition.swDataDefProps, Dlt
Argument.networkRepresentation, FlatInstanceDescriptor.swDataDefProps, ImplementationDataType
Element.swDataDefProps, InstantiationDataDefProps.swDataDefProps, ISignal.networkRepresentation
Props, McDataInstance.resultingProperties, ParameterAccess.swDataDefProps, PerInstanceMemory.sw
DataDefProps, ReceiverComSpec.networkRepresentation, SenderComSpec.networkRepresentation,
SomeipDataPrototypeTransformationProps.networkRepresentation, SwPointerTargetProps.swDataDef
Props, SwServiceArg.swDataDefProps, SwSystemconst.swDataDefProps, SystemSignal.physicalProps
Attribute Type Mult. Kind Note
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
5

339 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class <<atpVariation>> SwDataDefProps
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
swAlignment AlignmentType 0..1 attr The attribute describes the intended typical alignment of
the DataPrototype. If the attribute is not defined the
alignment is determined by the swBaseType size and the
memoryAllocationKeywordPolicy of the referenced Sw
AddrMethod.
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
5

340 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class <<atpVariation>> SwDataDefProps
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
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.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable
Tags: xml.sequenceOffset=280
swRecord SwRecordLayout 0..1 ref Record layout for this data object.
Layout
Tags: xml.sequenceOffset=290
5

341 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class <<atpVariation>> SwDataDefProps
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
SizeMult block (VAL_BLK) for the case that that value block has
(ordered) more than one dimension.
The dimensions given in this attribute are ordered such
that the first entry represents the first dimension, the
second entry represents the second dimension, and so
on.
For one-dimensional value blocks the attribute swValue
BlockSize shall be used and this attribute shall not exist.
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 D.69: SwDataDefProps

Enumeration SwImplPolicyEnum
Package M2::MSR::DataDictionary::DataDefProperties
Note Specifies the implementation strategy with respect to consistency mechanisms of variables.
Aggregated by BswInternalTriggeringPoint.swImplPolicy, InternalTriggeringPoint.swImplPolicy, SwDataDefProps.sw
ImplPolicy, Trigger.swImplPolicy
Literal Description
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.EnumerationLiteralIndex=0
5

342 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Enumeration SwImplPolicyEnum
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.EnumerationLiteralIndex=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.EnumerationLiteralIndex=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.EnumerationLiteralIndex=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.EnumerationLiteralIndex=4

Table D.70: SwImplPolicyEnum

Class SwSystemconst
Package M2::MSR::DataDictionary::SystemConstant
Note This element defines a system constant which serves an input to select a particular variation point. In
particular a system constant serves as an operand of the binding function (swSyscond) in a Variation
point.
Note that the binding process can only happen if a value was assigned to to the referenced system
constants.
Tags: atp.recommendedPackage=SwSystemconsts
Base ARElement, ARObject, AtpDefinition, CollectableElement, Identifiable, MultilanguageReferrable,
PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
swDataDef SwDataDefProps 0..1 aggr This denotes the data definition properties of the system
Props constant. This supports to express the limits and
optionally a conversion within the internal to physical
values by a compu method.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=swDataDefProps
xml.sequenceOffset=40

Table D.71: SwSystemconst

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

343 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwTextProps
arraySize ArraySizeSemantics 0..1 attr This attribute controls the semantics of the arraysize for
Semantics Enum the array representing the string in an Implementation
DataType.
It is there to support a safe conversion between
ApplicationDatatype and ImplementationDatatype, even
for variable length strings as required e.g. for Support of
SAE J1939.
baseType SwBaseType 0..1 ref This is the base type of one character in the string. In
particular this baseType denotes the intended encoding of
the characters in the string on level of ApplicationData
Type.
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 0..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 D.72: SwTextProps

Class SwcImplementation
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcImplementation
Note This meta-class represents a specialization of the general Implementation meta-class with respect to the
usage in application software.
Tags: atp.recommendedPackage=SwcImplementations
Base ARElement, ARObject, CollectableElement, Identifiable, Implementation, MultilanguageReferrable,
PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
behavior SwcInternalBehavior 0..1 ref The internal behavior implemented by this
Implementation.
5

344 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwcImplementation
perInstance PerInstanceMemory * aggr Allows a definition of the size of the per-instance memory
MemorySize Size for this implementation. The aggregation of PerInstance
MemorySize is subject to variability with the purpose to
support variability in the software components
implementations. Typically different algorithms in the
implementation are requiring different number of memory
objects, in this case PerInstanceMemory.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=perInstanceMemorySize, perInstance
MemorySize.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
required String 0..1 attr Identify a specific RTE vendor. This information is
RTEVendor potentially important at the time of integrating (in
particular: linking) the application code with the RTE. The
semantics is that (if the association exists) the
corresponding code has been created to fit to the
vendor-mode RTE provided by this specific vendor.
Attempting to integrate the code with another RTE
generated in vendor mode is in general not possible.

Table D.73: SwcImplementation

Class SwcInternalBehavior
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior
Note The SwcInternalBehavior of an AtomicSwComponentType describes the relevant aspects of the
software-component with respect to the RTE, i.e. the RunnableEntities and the RTEEvents they respond
to.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, InternalBehavior , Multilanguage
Referrable, Referrable
Aggregated by AtomicSwComponentType.internalBehavior, AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
arTypedPer VariableDataPrototype * aggr Defines an AUTOSAR typed memory-block that needs to
Instance be available for each instance of the SW-component.
Memory
This is typically only useful if supportsMultipleInstantiation
is set to "true" or if the component defines NVRAM
access via permanent blocks.
The aggregation of arTypedPerInstanceMemory is subject
to variability with the purpose to support variability in the
software component’s implementations. Typically different
algorithms in the implementation are requiring different
number of memory objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=arTypedPerInstanceMemory.shortName, ar
TypedPerInstanceMemory.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
5

345 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwcInternalBehavior
event RTEEvent * aggr This is a RTEEvent specified for the particular Swc
InternalBehavior.
The aggregation of RTEEvent is subject to variability with
the purpose to support the conditional existence of RTE
events. Note: the number of RTE events might vary due
to the conditional existence of PortPrototypes using Data
ReceivedEvents or due to different scheduling needs of
algorithms.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=event.shortName, event.variationPoint.short
Label
vh.latestBindingTime=preCompileTime
exclusiveArea SwcExclusiveArea * aggr Options how to generate the ExclusiveArea related APIs.
Policy Policy When no SwcExclusiveAreaPolicy is specified for an
ExclusiveArea the default values apply.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=exclusiveAreaPolicy, exclusiveArea
Policy.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
explicitInter VariableDataPrototype * aggr Implement state message semantics for establishing
Runnable communication among runnables of the same
Variable component. The aggregation of explicitInterRunnable
Variable is subject to variability with the purpose to
support variability in the software components
implementations. Typically different algorithms in the
implementation are requiring different number of memory
objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=explicitInterRunnableVariable.shortName,
explicitInterRunnableVariable.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
implicitInter VariableDataPrototype * aggr Implement state message semantics for establishing
Runnable communication among runnables of the same
Variable component. The aggregation of implicitInterRunnable
Variable is subject to variability with the purpose to
support variability in the software components
implementations. Typically different algorithms in the
implementation are requiring different number of memory
objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=implicitInterRunnableVariable.shortName,
implicitInterRunnableVariable.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
includedData IncludedDataTypeSet * aggr The includedDataTypeSet is used by a software
TypeSet component for its implementation.
Stereotypes: atpSplitable
Tags: atp.Splitkey=includedDataTypeSet
includedMode IncludedMode * aggr This aggregation represents the included Mode
Declaration DeclarationGroupSet DeclarationGroups
GroupSet
Stereotypes: atpSplitable
Tags: atp.Splitkey=includedModeDeclarationGroupSet
5

346 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwcInternalBehavior
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 Port
Prototypes and component local memories like "per
InstanceParameter" or "arTypedPerInstanceMemory".
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=instantiationDataDefProps, instantiationData
DefProps.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
perInstance PerInstanceMemory * aggr Defines a per-instance memory object needed by this
Memory software component. The aggregation of PerInstance
Memory is subject to variability with the purpose to
support variability in the software components
implementations. Typically different algorithms in the
implementation are requiring different number of memory
objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=perInstanceMemory.shortName, perInstance
Memory.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
perInstance ParameterData * aggr Defines parameter(s) or characteristic value(s) that needs
Parameter Prototype to be available for each instance of the
software-component. This is typically only useful if
supportsMultipleInstantiation is set to "true". The
aggregation of perInstanceParameter is subject to
variability with the purpose to support variability in the
software components implementations. Typically different
algorithms in the implementation are requiring different
number of memory objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=perInstanceParameter.shortName, per
InstanceParameter.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
portAPIOption PortAPIOption * aggr Options for generating the signature of port-related calls
from a runnable to the RTE and vice versa. The
aggregation of PortPrototypes is subject to variability with
the purpose to support the conditional existence of ports.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=portAPIOption, portAPIOption.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
5

347 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class SwcInternalBehavior
runnable RunnableEntity * aggr This is a RunnableEntity specified for the particular Swc
InternalBehavior.
The aggregation of RunnableEntity is subject to variability
with the purpose to support the conditional existence of
RunnableEntities. Note: the number of RunnableEntities
might vary due to the conditional existence of Port
Prototypes using DataReceivedEvents or due to different
scheduling needs of algorithms.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=runnable.shortName, runnable.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
service SwcService * aggr Defines the requirements on AUTOSAR Services for a
Dependency Dependency particular item.
The aggregation of SwcServiceDependency is subject to
variability with the purpose to support the conditional
existence of ports as well as the conditional existence of
ServiceNeeds.
The SwcServiceDependency owned by an SwcInternal
Behavior can be located in a different physical file in order
to support that SwcServiceDependency might be
provided in later development steps or even by different
expert domain (e.g OBD expert for Obd related Service
Needs) tools. Therefore the aggregation is <<atp
Splitable>>.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=serviceDependency.shortName, service
Dependency.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
shared ParameterData * aggr Defines parameter(s) or characteristic value(s) shared
Parameter Prototype between SwComponentPrototypes of the same Sw
ComponentType The aggregation of sharedParameter is
subject to variability with the purpose to support variability
in the software components implementations. Typically
different algorithms in the implementation are requiring
different number of memory objects.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=sharedParameter.shortName, shared
Parameter.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
supports Boolean 0..1 attr Indicate whether the corresponding software-component
Multiple can be multiply instantiated on one ECU. In this case the
Instantiation attribute will result in an appropriate component API on
programming language level (with or without instance
handle).
variationPoint VariationPointProxy * aggr Proxy of a variation points in the C/C++ implementation.
Proxy
Stereotypes: atpSplitable
Tags: atp.Splitkey=variationPointProxy.shortName

Table D.74: SwcInternalBehavior

348 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

Class System
Package M2::AUTOSARTemplates::SystemTemplate
Note The top level element of the System Description. The System description defines five major elements:
Topology, Software, Communication, Mapping and Mapping Constraints.
The System element directly aggregates the elements describing the Software, Mapping and Mapping
Constraints; it contains a reference to an ASAM FIBEX description specifying Communication and
Topology.
Tags: atp.recommendedPackage=Systems
Base ARElement, ARObject, AtpClassifier , AtpFeature, AtpStructureElement, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, UploadableDesignElement,
UploadablePackageElement
Aggregated by ARPackage.element, AtpClassifier .atpFeature
Attribute Type Mult. Kind Note
clientId ClientIdDefinitionSet * ref Set of Client Identifiers that are used for inter-ECU
DefinitionSet client-server communication in the System.
containerIPdu ByteOrderEnum 0..1 attr Defines the byteOrder of the header in ContainerIPdus.
HeaderByte
Order
ecuExtract RevisionLabelString 0..1 attr Version number of the Ecu Extract.
Version
fibexElement FibexElement * ref Reference to ASAM FIBEX elements specifying
Communication and Topology.
All Fibex Elements used within a System Description shall
be referenced from the System Element.
atpVariation: In order to describe a product-line, all Fibex
Elements can be optional.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=fibexElement.fibexElement, fibex
Element.variationPoint.shortLabel
vh.latestBindingTime=postBuild
interpolation InterpolationRoutine * ref This reference identifies the InterpolationRoutineMapping
Routine MappingSet Sets that are relevant in the context of the enclosing
MappingSet System.
j1939Shared J1939SharedAddress * aggr Collection of J1939Clusters that share a common
AddressCluster Cluster address space for the routing of messages.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=j1939SharedAddressCluster.shortName,
j1939SharedAddressCluster.variationPoint.shortLabel
vh.latestBindingTime=postBuild
mapping SystemMapping * aggr Aggregation of all mapping aspects (mapping of SW
components to ECUs, mapping of data elements to
signals, and mapping constraints).
In order to support OEM / Tier 1 interaction and shared
development for one common System this aggregation is
atpSplitable and atpVariation. The content of System
Mapping can be provided by several parties using
different names for the SystemMapping.
This element is not required when the System description
is used for a network-only use-case.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=mapping.shortName, mapping.variation
Point.shortLabel
vh.latestBindingTime=postBuild
5

349 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class System
pncVector PositiveInteger 0..1 attr Length of the partial networking request release
Length information vector (in bytes).
pncVectorOffset PositiveInteger 0..1 attr Absolute offset (with respect to the NM-PDU) of the
partial networking request release information vector that
is defined in bytes as an index starting with 0.
rootSoftware RootSwComposition 0..1 aggr Aggregation of the root software composition, containing
Composition Prototype all software components in the System in a hierarchical
structure. This element is not required when the System
description is used for a network-only use-case.
atpVariation: The RootSwCompositionPrototype can vary.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rootSoftwareComposition.shortName, root
SoftwareComposition.variationPoint.shortLabel
vh.latestBindingTime=systemDesignTime
swCluster CpSoftwareCluster * ref CP Software Clusters of this System
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=swCluster.cpSoftwareCluster, sw
Cluster.variationPoint.shortLabel
vh.latestBindingTime=systemDesignTime
system Chapter * aggr Possibility to provide additional documentation while
Documentation defining the System. The System documentation can be
composed of several chapters.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=systemDocumentation.shortName, system
Documentation.variationPoint.shortLabel
vh.latestBindingTime=systemDesignTime
xml.sequenceOffset=-10
systemVersion RevisionLabelString 0..1 attr Version number of the System Description.

Table D.75: System

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 D.76: TimeValue

Class <<atpMixed>> ValueList

Package M2::MSR::DataDictionary::DataDefProperties
Note This is a generic list of numerical values.
Base ARObject
Aggregated by RuleBasedAxisCont.swArraysize, RuleBasedValueCont.swArraysize, SwAxisCont.swArraysize, Sw
ServiceArg.swArraysize, SwValueCont.swArraysize
Attribute Type Mult. Kind Note
5

350 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Class <<atpMixed>> ValueList
v Numerical 0..1 attr This is a particular numerical value without variation.
Tags: xml.sequenceOffset=30
vf (ordered) Numerical * attr This is one entry in the list of numerical values
Stereotypes: atpVariation
Tags:
vh.latestBindingTime=preCompileTime
xml.roleElement=true
xml.roleWrapperElement=false
xml.typeElement=false
xml.typeWrapperElement=false

Table D.77: ValueList

Class VariableAccess
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::DataElements
Note The presence of a VariableAccess implies that a RunnableEntity needs access to a VariableData
Prototype.
The kind of access is specified by the role in which the class is used.
Base ARObject, AbstractAccessPoint, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable,
MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, ReceiverComSpec.replaceWith, RunnableEntity.dataReadAccess, Runnable
Entity.dataReceivePointByArgument, RunnableEntity.dataReceivePointByValue, RunnableEntity.data
SendPoint, RunnableEntity.dataWriteAccess, RunnableEntity.readLocalVariable, RunnableEntity.written
LocalVariable
Attribute Type Mult. Kind Note
accessed AutosarVariableRef 0..1 aggr This denotes the accessed variable.
Variable
scope VariableAccessScope 0..1 attr This attribute allows for constraining the scope of the
Enum corresponding communication. For example, it possible to
express whether the communication is intended to cross
the boundary of an ECU or whether it is intended not to
cross the boundary of a single partition.

Table D.78: VariableAccess

351 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

E Upstream Mapping

E.1 Introduction
This chapter describes the mapping of the ECU Configuration parameters (M1 model)
onto the meta-classes and attributes of the BSWMDT.
The relationships between BSWMDT and ECU Configuration are described in order to
answer typical questions like:
• How shall a supplier use the information in a System Description in order to fulfill
the needs defined by the systems engineer?
• How is a tool vendor supposed to generate an ECU Configuration Description out
of an ECU Extract of System Description and BSWMDs delivered for an ECU?
Please note that the tables contain the following columns:
BSW Module: Name of BSW module
BSW Context: Reference to parameter container
BSW Parameter: Name of the BSW parameter
BSW Type: Type of parameter
BSW Description: Description from the configuration document
M2 Template: The upstream templates
M2 Description: Description from the upstream template definition
M2 Parameter: Name of the upstream template parameter
Mapping Rule: Textual description on how to transform between M2 and BSW do-
mains
Mapping Type:
• local: no mapping needed since parameter local to BSW
• partial: some data can be automatically mapped but not all
• full: all data can be automatically mapped

352 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

E.2 ComM

BSW Module BSW Context

ComM ComM/ComMConfigSet
BSW Parameter BSW Type
ComMUser ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains a list of identifiers that are needed to refer to a user in the system which is designated to request
Communication modes.
Template Description
Specifies the abstract needs on the configuration of the Communication Manager for one "user".
M2 Parameter
CommonStructure::ServiceNeeds::ComMgrUserNeeds
Mapping Rule Mapping Type
In case the owner of the ComMgrUserNeeds is a BSW module then the ComMUser.shortName = full
{capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00653]

E.3 Dcm

BSW Module BSW Context

Dcm Dcm/DcmConfigSet/DcmDsp/DcmDspData
BSW Parameter BSW Type
DcmDspDataFreezeCurrentStateFnc ECUC-FUNCTION-NAME-DEF
BSW Description
Function name to request to application to freeze the current state of an IOControl. (FreezeCurrentState-function).
This parameter is related to the interface Xxx_FreezeCurrentState.
Template Description
DiagnosticIoControlNeeds.freezeCurrentStateSupported:
This attribute determines, if the referenced port supports temporary freezing of I/O value.
The temporary freeze is not supported if the enclosing DiagnosticIoControlNeeds is aggregated by a SwcService
Dependency, see [constr_1364].
DiagnosticServiceSwMapping.mappedBswServiceDependency:
This is supposed to represent a reference to a BswServiceDependency. the latter is not derived from Referrable and
therefore this detour needs to be implemented to still let BswServiceDependency become the target of a reference.
M2 Parameter
CommonStructure::ServiceNeeds::DiagnosticIoControlNeeds.freezeCurrentStateSupported, Diagnostic
Extract::DiagnosticMapping::ServiceMapping::DiagnosticServiceSwMapping.mappedBswServiceDependency
Mapping Rule Mapping Type
It could be possible to get the FNC name via BswServiceDependency full
Mapping Status ECUC Parameter ID
valid [ECUC_Dcm_00674]

353 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BSW Module BSW Context

Dcm Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUsePort
BSW Parameter BSW Type
USE_DATA_ASYNCH_FNC ECUC-ENUMERATION-LITERAL-DEF
BSW Description
The DCM will access the Data using the functions that are defined in parameters of type EcucFunctionNameDef (but without
DcmDspDataReadDataLengthFnc) in the DcmDspData container. DCM_E_PENDING return is allowed. OpStatus is existing
as IN parameter.
Template Description
The software-component processes the request in background but still the Dcm has to issue the call again to eventually
obtain the result of the request.
M2 Parameter
CommonStructure::ServiceNeeds::DiagnosticProcessingStyleEnum.processingStyleAsynchronous
Mapping Rule Mapping Type
DiagnosticServiceSwMapping is having a BswServiceDependency and ServiceNeeds::Diagnostic full
ProcessingStyleEnum is equal to processingStyleAsynchronous
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

Dcm Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUsePort
BSW Parameter BSW Type
USE_DATA_ASYNCH_FNC_ERROR ECUC-ENUMERATION-LITERAL-DEF
BSW Description
The DCM will access the Data using the functions that are defined in parameters of type EcucFunctionNameDef (but without
DcmDspDataReadDataLengthFnc) in the DcmDspData container. DCM_E_PENDING return is allowed. OpStatus is existing
as IN parameter. The parameter ErrorCode can be returned to allow the application to trigger a negative response during the
operation.
Template Description
The software-component processes the request in background but still the Dcm has to issue the call again to eventually
obtain the result of the request or handle error code.
M2 Parameter
CommonStructure::ServiceNeeds::DiagnosticProcessingStyleEnum.processingStyleAsynchronousWithError
Mapping Rule Mapping Type
DiagnosticServiceSwMapping is having a BswServiceDependency and ServiceNeeds::Diagnostic full
ProcessingStyleEnum is equal to processingStyleAsynchronousWithError
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

Dcm Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUsePort
BSW Parameter BSW Type
USE_DATA_SYNCH_FNC ECUC-ENUMERATION-LITERAL-DEF
BSW Description
The DCM will access the Data using the functions that are defined in parameters of type EcucFunctionNameDef (but without
DcmDspDataReadDataLengthFnc) in the DcmDspData container. DCM_E_PENDING return value is not allowed and Op
Status parameter is not existing in the prototype.
Template Description
5

354 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
The software-component is supposed to react synchronously on the request.
M2 Parameter
CommonStructure::ServiceNeeds::DiagnosticProcessingStyleEnum.processingStyleSynchronous
Mapping Rule Mapping Type
DiagnosticServiceSwMapping is having a BswServiceDependency and ServiceNeeds::Diagnostic full
ProcessingStyleEnum is equal to processingStyleSynchronous
Mapping Status ECUC Parameter ID
valid

E.4 Dem

BSW Module BSW Context

Dem Dem/DemConfigSet
BSW Parameter BSW Type
DemEventParameter ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration (parameters) for events.
Template Description
DiagnosticEventNeeds:
Specifies the abstract needs on the configuration of the Diagnostic Event Manager for one diagnostic event. Its shortName
can be regarded as a symbol identifying the diagnostic event from the viewpoint of the component or module which owns this
element.
In case the diagnostic event specifies a production error, the shortName shall be the name of the production error.
DiagnosticEvent:
This element is used to configure DiagnosticEvents.
M2 Parameter
CommonStructure::ServiceNeeds::DiagnosticEventNeeds, DiagnosticExtract::Dem::DiagnosticEvent::
DiagnosticEvent
Mapping Rule Mapping Type
In case the owner of the DiagnosticEventNeeds is a BSW module then the DemEvent full
Parameter.shortName = {capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
For DiagnosticEvent: 1:1
Mapping Status ECUC Parameter ID
valid [ECUC_Dem_00661]

BSW Module BSW Context

Dem Dem/DemGeneral
BSW Parameter BSW Type
DemRatio ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the OBD-specific in-use-monitor performance ratio configuration. It is related to a specific event, a
FID, and an IUMPR group.
Template Description
5

355 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
ObdRatioServiceNeeds:
Specifies the abstract needs of a component or module on the configuration of OBD Services in relation to a particular "ratio
monitoring" which is supported by this component or module.
DiagnosticIumprGroup:
This meta-class represents the ability to model a IUMPR groups.
M2 Parameter
CommonStructure::ServiceNeeds::ObdRatioServiceNeeds, DiagnosticExtract::Dem::DiagnosticEvent::
DiagnosticIumprGroup
Mapping Rule Mapping Type
In case the owner of the ObdRatioServiceNeeds is a BSW module then the DemRatio.shortName full
= {capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
For the DiagnosticIumprGroup the mapping rule is 1:1
Mapping Status ECUC Parameter ID
valid [ECUC_Dem_00734]

E.5 EcuC

BSW Module BSW Context

EcuC EcuC/EcucPartitionCollection/EcucPartition
BSW Parameter BSW Type
EcucPartitionBswModuleDistinguishedPartition ECUC-FOREIGN-REFERENCE-DEF
BSW Description
This maps the abstract partition of the Bsw Module to a concrete Partition existing in the ECU.
Template Description
Each instance of this meta-class represents an abstract partition in which context the code of the enclosing BswModule
Behavior can be executed.
The intended use case is to distinguish between several partitions in order to implement different behavior per partition, for
example to behave either as a master or satellite in a multicore ECU with shared BSW code.
M2 Parameter
BswModuleTemplate::BswBehavior::BswDistinguishedPartition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00068]

BSW Module BSW Context

EcuC EcuC/EcucUnitGroupAssignment
BSW Parameter BSW Type
EcucUnitGroupRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Optional reference to the UnitGroup to support the generation of ASAM MCD file. These UnitGroups are selecting a set of
units for a specific country.
Template Description
5

356 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
This meta-class represents the ability to specify a logical grouping of units.The category denotes the unit system that the
referenced units are associated to.
In this way, e.g. country-specific unit systems (CATEGORY="COUNTRY") can be defined as well as specific unit systems for
certain application domains.
In the same way a group of equivalent units, can be defined which are used in different countries, by setting
CATEGORY="EQUIV_UNITS". KmPerHour and MilesPerHour could such be combined to one group named "vehicle_speed".
The unit MeterPerSec would not belong to this group because it is normally not used for vehicle speed. But all of the
mentioned units could be combined to one group named "speed".
Note that the UnitGroup does not ensure the physical compliance of the units. This is maintained by the physical dimension.
M2 Parameter
AsamHdo::Units::UnitGroup
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00062]

E.6 FiM

BSW Module BSW Context

FiM FiM/FiMConfigSet
BSW Parameter BSW Type
FiMFID ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container includes symbolic names of all FIDs.
Template Description
FunctionInhibitionNeeds:
Specifies the abstract needs on the configuration of the Function Inhibition Manager for one Function Identifier (FID). This
class currently contains no attributes. Its name can be regarded as a symbol identifying the FID from the viewpoint of the
component or module which owns this class.
DiagnosticFunctionIdentifier:
This meta-class represents a diagnostic function identifier (a.k.a. FID).
M2 Parameter
CommonStructure::ServiceNeeds::FunctionInhibitionNeeds, DiagnosticExtract::Fim::
DiagnosticFunctionIdentifier
Mapping Rule Mapping Type
In case the owner of the FunctionInhibitionNeeds is a BSW module then the FiMFID.shortName= full
{capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
Mapping Status ECUC Parameter ID
valid [ECUC_FiM_00039]

357 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

E.7 NvM

BSW Module BSW Context

NvM NvM
BSW Parameter BSW Type
NvMBlockDescriptor ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container for a management structure to configure the composition of a given NVRAM Block Management Type. Its
multiplicity describes the number of configured NVRAM blocks, one block is required to be configured. The NVRAM block
descriptors are condensed in the NVRAM block descriptor table.
Template Description
Specifies the abstract needs on the configuration of a single NVRAM Block.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds
Mapping Rule Mapping Type
In case the owner of the NvBlockNeeds is a BSW module then the NvMBlockDescriptor.short full
Name = {capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00061]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockJobPriority ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the job priority for a NVRAM block (0 = Immediate priority).
Template Description
NvBlockNeeds.writingPriority:
Requires the priority of writing this block in case of concurrent requests to write other blocks.
NvBlockNeeds.storeEmergency:
Defines whether or not the associated RAM Block shall be implicitly stored in case of ECU failure (e.g. loss of power) by the
basic software. If the attribute storeEmergency is set to true the associated RAM Block shall be configured to have immediate
priority.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.writingPriority, CommonStructure::ServiceNeeds::NvBlockNeeds.
storeEmergency
Mapping Rule Mapping Type
It is the integrators job to secure the value-monotonic assignment of writingPriority to NvMBlock full
JobPriority. This means that the lowest assigned value of writingPriority=MEDIUM shall be greater
than highest assigned value of writingPriority=HIGH etc.If NvBlockNeeds.storeEmergency is set to
true, then NvMBlockJobPriority shall be 0 (Immediate priority). If NvBlockNeeds.storeEmergency
is set to false, then the value of NvMBlockJobPriority depends on the value of NvBlock
Needs.writingPriority.
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00477]

358 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockManagementType ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines the block management type for the NVRAM block.[SWS_NvM_00137]
Template Description
Reliability against data loss on the non-volatile medium.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.reliability
Mapping Rule Mapping Type
if (reliability == errorDetection | noProtection) && nDataSets==0 then NvmBlockManagementType full
= NVM_BLOCK_NATIVE. if reliability == errorCorrection then NvmBlockManagementType = NVM_
BLOCK_REDUNDANT. [constr_1095] applies.
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00062]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockUseAutoValidation ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines whether the RAM Block shall be auto validated during shutdown phase.
true: if auto validation mechanism is used, false: otherwise
Template Description
If set to true the RAM Block shall be auto validated during shutdown phase.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.useAutoValidationAtShutDown
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00557]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockUseCRCCompMechanism ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines whether the CRC of the RAM Block shall be compared during a write job with the CRC which was calculated during
the last successful read or write job.
true: if compare mechanism is used, false: otherwise
Template Description
If set to true the CRC of the RAM Block shall be compared during a write job with the CRC which was calculated during the
last successful read or write job in order to skip unnecessary NVRAM writings.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.useCRCCompMechanism
5

359 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00556]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockUseCrc ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines CRC usage for the NVRAM block, i.e. memory space for CRC is reserved in RAM and NV memory.
true: CRC will be used for this NVRAM block. false: CRC will not be used for this NVRAM block.
Note: Configuring CRC for a block with immediate priority is not recommended, since the CRC calculation may extend over
more than one NvM main function and this could increase the time of writing the immediate data significantly, thus defeating
the purpose of immediate priority.
Template Description
Reliability against data loss on the non-volatile medium.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.reliability
Mapping Rule Mapping Type
reliability == errorCorrection | errorDetection means that NvmBlockUseCrc shall bet set to true, full
else NvmBlockUseCrc = false
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00036]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockUseSetRamBlockStatus ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines if NvMSetRamBlockStatusApi shall be used for this block or not.
Note: If NvMSetRamBlockStatusApi is disabled this configuration parameter shall be ignored.
true: calling of NvMSetRamBlockStatus for this RAM block shall set the status of the RAM block.
false: calling of NvMSetRamBlockStatus for this RAM block shall be ignored.
Template Description
This attribute defines how the management of the RAM Block status is controlled.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.ramBlockStatusControl
Mapping Rule Mapping Type
If the value of NvBlockNeeds.ramBlockStatusControl is set to RamBlockStatusControlEnum.api full
the parameter shall be set to true. If the value of NvBlockNeeds.ramBlockStatusControl is set to
RamBlockStatusControlEnum.nvRamManager it shall be set to false.
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00552]

360 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMBlockWriteProt ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines an initial write protection of the NV block
true: Initial block write protection is enabled. false: Initial block write protection is disabled.
Template Description
true: data of this NVRAM Block are write protected for normal operation (but protection can be disabled)
false: no restriction
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.readonly
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00033]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMCalcRamBlockCrc ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines CRC (re)calculation for the permanent RAM block or NVRAM blocks which are configured to use explicit
synchronization mechanism.
true: CRC will be (re)calculated for this permanent RAM block. false: CRC will not be (re)calculated for this permanent RAM
block.
Template Description
Defines if CRC (re)calculation for the permanent RAM Block is required.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.calcRamBlockCrc
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00119]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMNvBlockNum ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the number of multiple NV blocks in a contiguous area according to the given block management type.
1-255 For NVRAM blocks to be configured of block management type NVM_BLOCK_DATASET. The actual range is limited
according to SWS_NvM_00444.
1 For NVRAM blocks to be configured of block management type NVM_BLOCK_NATIVE
2 For NVRAM blocks to be configured of block management type NVM_BLOCK_REDUNDANT
5

361 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Template Description
NvBlockNeeds.nDataSets:
Number of data sets to be provided by the NVRAM manager for this block. This is the total number of ROM Blocks and RAM
Blocks.
NvBlockNeeds.reliability:
Reliability against data loss on the non-volatile medium.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.nDataSets, CommonStructure::ServiceNeeds::NvBlockNeeds.
reliability
Mapping Rule Mapping Type
if (nDataSets == 0 && reliability ==noProtection | errorDetection) then NvMNvBlockNum = 1. if (n full
DataSets >0 && reliability ==noProtection | errorDetection) then NvMNvBlockNum = nDataSets.
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00480]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMResistantToChangedSw ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines whether a NVRAM block shall be treated resistant to configuration changes or not. If there is no default data available
at configuration time then the application shall be responsible for providing the default initialization data. In this case the
application has to use NvM_GetErrorStatus()to be able to distinguish between first initialization and corrupted data.
true: NVRAM block is resistant to changed software. false: NVRAM block is not resistant to changed software.
Template Description
Defines whether an NVRAM Block shall be treated resistant to configuration changes (true) or not (false). For details how to
handle initialization in the latter case, please refer to the NVRAM specification.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.resistantToChangedSw
Mapping Rule Mapping Type
1:1 Mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00483]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMRomBlockNum ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the number of multiple ROM blocks in a contiguous area according to the given block management type.
0-254 For NVRAM blocks to be configured of block management type NVM_BLOCK_DATASET. The actual range is limited
according to SWS_NvM_00444.
0-1 For NVRAM blocks to be configured of block management type NVM_BLOCK_NATIVE
0-1 For NVRAM blocks to be configured of block management type NVM_BLOCK_REDUNDANT
Template Description
5

362 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Number of ROM Blocks to be provided by the NVRAM manager for this block. Please note that these multiple ROM Blocks
are given in a contiguous area.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.nRomBlocks
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00485]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMSelectBlockForReadAll ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines whether a NVRAM block shall be processed during NvM_ReadAll or not. This configuration parameter has only
influence on those NVRAM blocks which are configured to have a permanent RAM block or which are configured to use
explicit synchronization mechanism.
true: NVRAM block shall be processed by NvM_ReadAll false: NVRAM block shall not be processed by NvM_ReadAll
Template Description
Defines whether the associated RAM Block shall be implicitly restored during startup by the basic software.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.restoreAtStart
Mapping Rule Mapping Type
1:1 Mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00117]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMSelectBlockForWriteAll ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines whether a NVRAM block shall be processed during NvM_WriteAll or not. This configuration parameter has only
influence on those NVRAM blocks which are configured to have a permanent RAM block or which are configured to use
explicit synchronization mechanism.
true: NVRAM block shall be processed by NvM_WriteAll false: NVRAM block shall not be processed by NvM_WriteAll
Template Description
Defines whether or not the associated RAM Block shall be implicitly stored during shutdown by the basic software.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.storeAtShutdown
Mapping Rule Mapping Type
1:1 Mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00549]

363 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMStaticBlockIDCheck ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines if the Static Block ID check is enabled.
false: Static Block ID check is disabled. true: Static Block ID check is enabled.
Template Description
Defines if the Static Block Id check shall be enabled.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.checkStaticBlockId
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00532]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMWriteBlockOnce ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines write protection after first write. The NVRAM manager sets the write protection bit either after the NV block was
written the first time or if the block was already written and it is detected as valid and consistent during a read for it.
true: Defines write protection after first write is enabled.
false: Defines write protection after first write is disabled.
Template Description
Defines write protection after first write:
true: This block is prevented from being changed/erased or being replaced with the default ROM data after first initialization
by the software-component.
false: No such restriction.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.writeOnlyOnce
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00072]

BSW Module BSW Context

NvM NvM/NvMBlockDescriptor
BSW Parameter BSW Type
NvMWriteVerification ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines if Write Verification is enabled.
false: Write verification is disabled. true: Write Verification is enabled.
Template Description
5

364 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Defines if Write Verification shall be enabled for this NVRAM Block.
M2 Parameter
CommonStructure::ServiceNeeds::NvBlockNeeds.writeVerification
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_NvM_00534]

E.8 Rte

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswEventToIsrMapping
BSW Parameter BSW Type
RteBswIsrEventRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the BswEvent.
Template Description
Base class of various kinds of events which are used to trigger a BswModuleEntity of this BSW module or cluster. The event
is local to the BSW module or cluster. The short name of the meta-class instance is intended as an input to configure the
required API of the BSW Scheduler.
M2 Parameter
BswModuleTemplate::BswBehavior::BswEvent
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09159]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswEventToTaskMapping
BSW Parameter BSW Type
RteBswEventRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the BswEvent.
Template Description
Base class of various kinds of events which are used to trigger a BswModuleEntity of this BSW module or cluster. The event
is local to the BSW module or cluster. The short name of the meta-class instance is intended as an input to configure the
required API of the BSW Scheduler.
M2 Parameter
BswModuleTemplate::BswBehavior::BswEvent
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09064]

365 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswExclusiveAreaImpl
BSW Parameter BSW Type
RteBswExclusiveAreaRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the ExclusiveArea for which the implementation mechanism shall be specified.
Template Description
Prevents an executable entity running in the area from being preempted.
M2 Parameter
CommonStructure::InternalBehavior::ExclusiveArea
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09074]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswExternalTriggerConfig
BSW Parameter BSW Type
RteBswTriggerSourceRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to a Trigger instance in the role releasedTrigger of the related BSW Module instance.
The referenced Trigger has to belong to the same BSW Module instance as the RteBswModuleInstance owning this
parameter configures.
Template Description
A trigger which is provided (i.e. released) or required (i.e. used to activate something) in the given context.
M2 Parameter
CommonStructure::TriggerDeclaration::Trigger
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09100]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance
BSW Parameter BSW Type
RteBswImplementationRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the BswImplementation for which the Rte /SchM is configured.
Template Description
Contains the implementation specific information in addition to the generic specification (BswModuleDescription and Bsw
Behavior). It is possible to have several different BswImplementations referring to the same BswBehavior.
M2 Parameter
BswModuleTemplate::BswImplementation::BswImplementation
Mapping Rule Mapping Type
1:1 mapping full
5

366 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09066]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswInternalTriggerConfig
BSW Parameter BSW Type
RteBswTriggerSourceRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to a BswInternalTriggeringPoint of the related BSW Module instance.
The referenced BswInternalTriggeringPoint has to belong to the same BSW Module instance as the RteBswModuleInstance
owning this parameter configures.
Template Description
Represents the activation point for one or more BswInternalTriggerOccurredEvents.
M2 Parameter
BswModuleTemplate::BswBehavior::BswInternalTriggeringPoint
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09103]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswModeMachineInstanceConfig
BSW Parameter BSW Type
RteBswModeManagerRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to a ModeDeclarationGroupPrototype of the related BSW Module instance.
The referenced ModeDeclarationGroupPrototype has to belong to the same BSW Module instance as the RteBswModule
Instance owning this parameter configures.
Template Description
Represents the activation point for one or more BswInternalTriggerOccurredEvents.
M2 Parameter
BswModuleTemplate::BswBehavior::BswInternalTriggeringPoint
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09149]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredClientServerConnection
BSW Parameter BSW Type
RteBswProvidedClientServerEntryRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference the providedClientServerEntry for this connection.
5

367 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Template Description
This meta-class represents a single API entry into the BSW module or cluster that has the ability to be called in client-server
fashion via the BSW Scheduler.
In this regard it is more special than BswModuleEntry and can be seen as a wrapper around the BswModuleEntry to which it
refers (property encapsulatedEntry).
M2 Parameter
BswModuleTemplate::BswInterfaces::BswModuleClientServerEntry
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09119]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredClientServerConnection
BSW Parameter BSW Type
RteBswRequiredClientServerEntryRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference the requiredClientServerEntry for this connection.
Template Description
This meta-class represents a single API entry into the BSW module or cluster that has the ability to be called in client-server
fashion via the BSW Scheduler.
In this regard it is more special than BswModuleEntry and can be seen as a wrapper around the BswModuleEntry to which it
refers (property encapsulatedEntry).
M2 Parameter
BswModuleTemplate::BswInterfaces::BswModuleClientServerEntry
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09118]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredModeGroupConnection
BSW Parameter BSW Type
RteBswProvidedModeGroupRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
References the providedModeGroupPrototype to which this requiredModeGroup shall be connected.
Template Description
The ModeDeclarationGroupPrototype specifies a set of Modes (ModeDeclarationGroup) which is provided or required in the
given context.
M2 Parameter
CommonStructure::ModeDeclaration::ModeDeclarationGroupPrototype
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09079]

368 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredModeGroupConnection
BSW Parameter BSW Type
RteBswRequiredModeGroupRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
References requiredModeGroupPrototype which shall be connected to the providedModeGroupPrototype.
Template Description
The ModeDeclarationGroupPrototype specifies a set of Modes (ModeDeclarationGroup) which is provided or required in the
given context.
M2 Parameter
CommonStructure::ModeDeclaration::ModeDeclarationGroupPrototype
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09082]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredModeGroupConnection
BSW Parameter BSW Type
RteModeDeclarationMappingSetRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
This defines the effective ModeDeclarationMappingSet in the case that the provided ModeDeclarationGroupPrototype and
the required ModeDeclarationGroupPrototype are not compatible.
Template Description
This meta-class implements a container for ModeDeclarationGroupMappings
M2 Parameter
SWComponentTemplate::PortInterface::ModeDeclarationMappingSet
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09125]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredSenderReceiverConnection
BSW Parameter BSW Type
RteBswProvidedVariableDataPrototypeRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference the providedData for this connection.
Template Description
A VariableDataPrototype represents a formalized generic piece of information that is typically mutable by the application
software layer. VariableDataPrototype is used in various contexts and the specific context gives the otherwise generic
VariableDataPrototype a dedicated semantics.
M2 Parameter
SWComponentTemplate::Datatype::DataPrototypes::VariableDataPrototype
Mapping Rule Mapping Type
5

369 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09122]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredSenderReceiverConnection
BSW Parameter BSW Type
RteBswRequiredVariableDataPrototypeRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference the requiredData for this connection.
Template Description
A VariableDataPrototype represents a formalized generic piece of information that is typically mutable by the application
software layer. VariableDataPrototype is used in various contexts and the specific context gives the otherwise generic
VariableDataPrototype a dedicated semantics.
M2 Parameter
SWComponentTemplate::Datatype::DataPrototypes::VariableDataPrototype
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09121]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredTriggerConnection
BSW Parameter BSW Type
RteBswReleasedTriggerRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
References the releasedTrigger to which this requiredTrigger shall be connected.
Template Description
A trigger which is provided (i.e. released) or required (i.e. used to activate something) in the given context.
M2 Parameter
CommonStructure::TriggerDeclaration::Trigger
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09076]

BSW Module BSW Context

Rte Rte/RteBswModuleInstance/RteBswRequiredTriggerConnection
BSW Parameter BSW Type
RteBswRequiredTriggerRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
References one requiredTrigger which shall be connected to the releasedTrigger.
Template Description
5

370 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
A trigger which is provided (i.e. released) or required (i.e. used to activate something) in the given context.
M2 Parameter
CommonStructure::TriggerDeclaration::Trigger
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09078]

BSW Module BSW Context

Rte Rte/RteOsInteraction/RteModeToScheduleTableMapping/RteModeSchtblMapBsw
BSW Parameter BSW Type
RteModeSchtblMapBswProvidedModeGroupRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to an instance of a ModeDeclarationGroupPrototype of a Bsw-Module.
Template Description
The ModeDeclarationGroupPrototype specifies a set of Modes (ModeDeclarationGroup) which is provided or required in the
given context.
M2 Parameter
CommonStructure::ModeDeclaration::ModeDeclarationGroupPrototype
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09053]

BSW Module BSW Context

Rte Rte/RteOsInteraction/RteModeToScheduleTableMapping
BSW Parameter BSW Type
RteModeSchtblMapModeDeclarationRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the ModeDeclarations.
Template Description
Declaration of one Mode. The name and semantics of a specific mode is not defined in the meta-model.
M2 Parameter
CommonStructure::ModeDeclaration::ModeDeclaration
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09054]

BSW Module BSW Context

Rte Rte/RteOsInteraction/RteModeToScheduleTableMapping/RteModeSchtblMapSwc
BSW Parameter BSW Type
RteModeSchtblMapSwcPortRef ECUC-FOREIGN-REFERENCE-DEF
5

371 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
BSW Description
Reference to the PPortPrototype of a SwComponentPrototype.
Template Description
Component port providing a certain port interface.
M2 Parameter
SWComponentTemplate::Components::PPortPrototype
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Rte_09057]

E.9 StbM

BSW Module BSW Context

StbM StbM
BSW Parameter BSW Type
StbMSynchronizedTimeBase ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Synchronized time.base collects the information about a specific time-base provider within the system.
Template Description
This represents the ability to define a global time domain.
M2 Parameter
SystemTemplate::GlobalTime::GlobalTimeDomain
Mapping Rule Mapping Type
For each GlobalTimeDomain where - the configured Ecu is connected to as slave or - the full
configured Ecu is connected to as master if the Ecu is not in the role of a GlobalTimeGateway for
this GlobalTimeDomain
an instance of StbMSynchronizedTimeBase shall be created.
Mapping Status ECUC Parameter ID
valid [ECUC_StbM_00003]

E.10 WdgM

BSW Module BSW Context

WdgM WdgM/WdgMConfigSet/WdgMMode/WdgMLocalStatusParams
BSW Parameter BSW Type
WdgMFailedAliveSupervisionRefCycleTol ECUC-INTEGER-PARAM-DEF
BSW Description
5

372 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
This parameter shall contain the acceptable amount of reference cycles with incorrect/failed alive supervisions for this
Supervised Entity.
Template Description
Number of consecutive failed alive cycles for this SupervisedEntity which shall be tolerated until the supervision status of the
SupervisedEntity is set to WDGM_ALIVE_EXPIRED (see SWS WdgM for more details).
Note that this value has to be recalculated with respect to the WdgM’s own cycle time for ECU configuration.
M2 Parameter
CommonStructure::ServiceNeeds::SupervisedEntityNeeds.toleratedFailedCycles
Mapping Rule Mapping Type
1:1 full
Mapping Status ECUC Parameter ID
valid [ECUC_WdgM_-
00327]

BSW Module BSW Context

WdgM WdgM/WdgMGeneral
BSW Parameter BSW Type
WdgMSupervisedEntity ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container collects all common (mode-independent) parameters of a Supervised Entity to be supervised by the Watchdog
Manager.
Template Description
Specifies the abstract needs on the configuration of the Watchdog Manager for one specific Supervised Entity.
M2 Parameter
CommonStructure::ServiceNeeds::SupervisedEntityNeeds
Mapping Rule Mapping Type
In case the owner of the SupervisedEntityNeeds is a BSW module then the WdgMSupervised full
Entity.shortName = {capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
Mapping Status ECUC Parameter ID
valid [ECUC_WdgM_-
00303]

BSW Module BSW Context

WdgM WdgM/WdgMGeneral/WdgMSupervisedEntity
BSW Parameter BSW Type
WdgMCheckpoint ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container collects all Checkpoints of this Supervised Entity. Each Supervised Entity has at least one Checkpoint.
Template Description
Specifies the abstract needs on the configuration of the Watchdog Manager to support a Checkpoint for a Supervised Entity.
M2 Parameter
CommonStructure::ServiceNeeds::SupervisedEntityCheckpointNeeds
Mapping Rule Mapping Type
In case the owner of the SupervisedEntityCheckpointNeeds is a BSW module then the Wdg full
MCheckpoint.shortName = {capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
Mapping Status ECUC Parameter ID
valid [ECUC_WdgM_-
00305]

373 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

E.11 Xfrm

BSW Module BSW Context

Xfrm Xfrm/XfrmImplementationMapping
BSW Parameter BSW Type
XfrmInvTransformerBswModuleEntryRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the BswModuleEntry which implements the referenced inverse transformer on the receiving/called side.
Template Description
This class represents a single API entry (C-function prototype) into the BSW module or cluster.
The name of the C-function is equal to the short name of this element with one exception: In case of multiple instances of a
module on the same CPU, special rules for "infixes" apply, see description of class BswImplementation.
M2 Parameter
BswModuleTemplate::BswInterfaces::BswModuleEntry
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Xfrm_00005]

BSW Module BSW Context

Xfrm Xfrm/XfrmImplementationMapping
BSW Parameter BSW Type
XfrmTransformerBswModuleEntryRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the BswModuleEntry which implements the referenced transformer on the sending/calling side.
Template Description
This class represents a single API entry (C-function prototype) into the BSW module or cluster.
The name of the C-function is equal to the short name of this element with one exception: In case of multiple instances of a
module on the same CPU, special rules for "infixes" apply, see description of class BswImplementation.
M2 Parameter
BswModuleTemplate::BswInterfaces::BswModuleEntry
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Xfrm_00018]

374 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

F Splitable Elements in the Scope of this Document

This chapter contains a table of all model elements stereotyped atpSplitable
in the scope of this document.
Each entry in the table consists of the identification of the specific model element itself
and the applicable value of the tagged value atp.Splitkey.
For more information about the concept of splitable model elements and how these
shall be treated please refer to [1].
Name of splitable element Splitkey
AccessCountSet.accessCount accessCount, accessCount.variationPoint.short
Label
ApplicationRuleBasedValueSpecification.swValueCont swValueCont
ARPackage.arPackage arPackage.shortName, arPackage.variation
Point.shortLabel
ARPackage.element element.shortName, element.variationPoint.short
Label
ARPackage.referenceBase referenceBase.shortLabel
ArrayValueSpecification.element element, element.variationPoint.shortLabel
BswEvent.disabledInMode disabledInMode.contextModeDeclarationGroup,
disabledInMode.targetMode
BswInternalBehavior.arTypedPerInstanceMemory arTypedPerInstanceMemory.shortName, arTypedPer
InstanceMemory.variationPoint.shortLabel
BswInternalBehavior.bswPerInstanceMemoryPolicy bswPerInstanceMemoryPolicy, bswPerInstance
MemoryPolicy.variationPoint.shortLabel
BswInternalBehavior.clientPolicy clientPolicy, clientPolicy.variationPoint.shortLabel
BswInternalBehavior.distinguishedPartition distinguishedPartition.shortName, distinguished
Partition.variationPoint.shortLabel
BswInternalBehavior.entity entity.shortName, entity.variationPoint.shortLabel
BswInternalBehavior.event event.shortName, event.variationPoint.shortLabel
BswInternalBehavior.exclusiveAreaPolicy exclusiveAreaPolicy, exclusiveAreaPolicy.variation
Point.shortLabel
BswInternalBehavior.includedDataTypeSet includedDataTypeSet
BswInternalBehavior.includedModeDeclarationGroupSet includedModeDeclarationGroupSet
BswInternalBehavior.internalTriggeringPoint internalTriggeringPoint.shortName, internal
TriggeringPoint.variationPoint.shortLabel
BswInternalBehavior.internalTriggeringPointPolicy internalTriggeringPointPolicy, internalTriggeringPoint
Policy.variationPoint.shortLabel
BswInternalBehavior.modeReceiverPolicy modeReceiverPolicy, modeReceiverPolicy.variation
Point.shortLabel
BswInternalBehavior.modeSenderPolicy modeSenderPolicy, modeSenderPolicy.variation
Point.shortLabel
BswInternalBehavior.parameterPolicy parameterPolicy, parameterPolicy.variation
Point.shortLabel
BswInternalBehavior.perInstanceParameter perInstanceParameter.shortName, perInstance
Parameter.variationPoint.shortLabel
BswInternalBehavior.receptionPolicy receptionPolicy, receptionPolicy.variationPoint.short
Label
BswInternalBehavior.releasedTriggerPolicy releasedTriggerPolicy, releasedTrigger
Policy.variationPoint.shortLabel
BswInternalBehavior.schedulerNamePrefix schedulerNamePrefix.shortName, schedulerName
Prefix.variationPoint.shortLabel
5

375 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Name of splitable element Splitkey
BswInternalBehavior.sendPolicy sendPolicy, sendPolicy.variationPoint.shortLabel
BswInternalBehavior.serviceDependency serviceDependency.ident.shortName, service
Dependency.variationPoint.shortLabel
BswInternalBehavior.triggerDirectImplementation triggerDirectImplementation, triggerDirect
Implementation.variationPoint.shortLabel
BswInternalBehavior.variationPointProxy variationPointProxy.shortName
BswModuleDependency.targetModuleRef targetModuleRef.bswModuleDescription, target
ModuleRef.variationPoint.shortLabel
BswModuleDescription.bswModuleDependency bswModuleDependency.shortName, bswModule
Dependency.variationPoint.shortLabel
BswModuleDescription.bswModuleDocumentation bswModuleDocumentation, bswModule
Documentation.variationPoint.shortLabel
BswModuleDescription.expectedEntry expectedEntry.bswModuleEntry, expected
Entry.variationPoint.shortLabel
BswModuleDescription.implementedEntry implementedEntry.bswModuleEntry, implemented
Entry.variationPoint.shortLabel
BswModuleDescription.internalBehavior internalBehavior.shortName
BswModuleDescription.providedClientServerEntry providedClientServerEntry.shortName, provided
ClientServerEntry.variationPoint.shortLabel
BswModuleDescription.providedData providedData.shortName, providedData.variation
Point.shortLabel
BswModuleDescription.providedModeGroup providedModeGroup.shortName, providedMode
Group.variationPoint.shortLabel
BswModuleDescription.releasedTrigger releasedTrigger.shortName, released
Trigger.variationPoint.shortLabel
BswModuleDescription.requiredClientServerEntry requiredClientServerEntry.shortName, required
ClientServerEntry.variationPoint.shortLabel
BswModuleDescription.requiredData requiredData.shortName, requiredData.variation
Point.shortLabel
BswModuleDescription.requiredModeGroup requiredModeGroup.shortName, requiredMode
Group.variationPoint.shortLabel
BswModuleDescription.requiredTrigger requiredTrigger.shortName, requiredTrigger.variation
Point.shortLabel
BswModuleEntity.accessedModeGroup accessedModeGroup.modeDeclarationGroup
Prototype, accessedModeGroup.variationPoint.short
Label
BswModuleEntity.activationPoint activationPoint.bswInternalTriggeringPoint, activation
Point.variationPoint.shortLabel
BswModuleEntity.callPoint callPoint.shortName, callPoint.variationPoint.short
Label
BswModuleEntity.dataReceivePoint dataReceivePoint.shortName, dataReceive
Point.variationPoint.shortLabel
BswModuleEntity.dataSendPoint dataSendPoint.shortName, dataSendPoint.variation
Point.shortLabel
BswModuleEntity.issuedTrigger issuedTrigger.trigger, issuedTrigger.variation
Point.shortLabel
BswModuleEntity.managedModeGroup managedModeGroup.modeDeclarationGroup
Prototype, managedModeGroup.variationPoint.short
Label
BswModuleEntry.argument argument.shortName, argument.variationPoint.short
Label
BswServiceDependency.assignedData assignedData, assignedData.variationPoint.short
Label
5

376 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Name of splitable element Splitkey
BswServiceDependency.assignedEntryRole assignedEntryRole, assignedEntryRole.variation
Point.shortLabel
ConstantSpecification.valueSpec valueSpec
Describable.adminData adminData
ErrorTracerNeeds.tracedFailure tracedFailure.shortName, tracedFailure.variation
Point.shortLabel
ExecutableEntity.canEnter canEnter.exclusiveArea, canEnter.variation
Point.shortLabel
ExecutableEntity.runsInside runsInside.exclusiveArea, runsInside.variation
Point.shortLabel
Identifiable.adminData adminData
Implementation.buildActionManifest buildActionManifest.buildActionManifest, buildAction
Manifest.variationPoint.shortLabel
Implementation.generatedArtifact generatedArtifact.shortName, generated
Artifact.variationPoint.shortLabel
Implementation.mcSupport mcSupport
Implementation.requiredArtifact requiredArtifact.shortName, required
Artifact.variationPoint.shortLabel
Implementation.requiredGeneratorTool requiredGeneratorTool.shortName, required
GeneratorTool.variationPoint.shortLabel
Implementation.resourceConsumption resourceConsumption.shortName
ImplementationDataType.subElement subElement.shortName, subElement.variation
Point.shortLabel
ImplementationDataType.symbolProps symbolProps.shortName
ImplementationDataTypeElement.subElement subElement.shortName, subElement.variation
Point.shortLabel
ImplementationDataTypeElement.swDataDefProps swDataDefProps
InternalBehavior.constantMemory constantMemory.shortName, constant
Memory.variationPoint.shortLabel
InternalBehavior.constantValueMapping constantValueMapping
InternalBehavior.dataTypeMapping dataTypeMapping
InternalBehavior.exclusiveArea exclusiveArea.shortName, exclusiveArea.variation
Point.shortLabel
InternalBehavior.exclusiveAreaNestingOrder exclusiveAreaNestingOrder.shortName, exclusive
AreaNestingOrder.variationPoint.shortLabel
InternalBehavior.staticMemory staticMemory.shortName, staticMemory.variation
Point.shortLabel
McDataInstance.resultingProperties resultingProperties
McDataInstance.subElement subElement.shortName, subElement.variation
Point.shortLabel
McDataInstance.symbol symbol
McFunction.defCalprmSet defCalprmSet
McFunction.inMeasurementSet inMeasurementSet
McFunction.locMeasurementSet locMeasurementSet
McFunction.outMeasurementSet outMeasurementSet
McFunction.refCalprmSet refCalprmSet
McFunction.subFunction subFunction
McFunctionDataRefSet.flatMapEntry <Not applicable due to atpVariation (PropertySet
Pattern)>
McFunctionDataRefSet.mcDataInstance <Not applicable due to atpVariation (PropertySet
Pattern)>
McSupportData.emulationSupport emulationSupport, emulationSupport.variation
Point.shortLabel
5

377 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Name of splitable element Splitkey
McSupportData.mcParameterInstance mcParameterInstance.shortName, mcParameter
Instance.variationPoint.shortLabel
McSupportData.mcVariableInstance mcVariableInstance.shortName, mcVariable
Instance.variationPoint.shortLabel
McSupportData.rptSupportData rptSupportData
ModeDeclarationGroup.modeDeclaration modeDeclaration.shortName, mode
Declaration.variationPoint.shortLabel
RecordValueSpecification.field field, field.variationPoint.shortLabel
ResourceConsumption.accessCountSet accessCountSet, accessCountSet.variation
Point.shortLabel
ResourceConsumption.executionTime executionTime.shortName, executionTime.variation
Point.shortLabel
ResourceConsumption.heapUsage heapUsage.shortName, heapUsage.variation
Point.shortLabel
ResourceConsumption.memorySection memorySection.shortName, memory
Section.variationPoint.shortLabel
ResourceConsumption.sectionNamePrefix sectionNamePrefix.shortName, sectionName
Prefix.variationPoint.shortLabel
ResourceConsumption.stackUsage stackUsage.shortName, stackUsage.variation
Point.shortLabel
RptComponent.rptExecutableEntity rptExecutableEntity.shortName, rptExecutable
Entity.variationPoint.shortLabel
RptExecutableEntity.rptExecutableEntityEvent rptExecutableEntityEvent.shortName, rptExecutable
EntityEvent.variationPoint.shortLabel
RptExecutableEntity.rptRead rptRead, rptRead.variationPoint.shortLabel
RptExecutableEntity.rptWrite rptWrite, rptWrite.variationPoint.shortLabel
RptSupportData.rptComponent rptComponent.shortName, rptComponent.variation
Point.shortLabel
RptSupportData.rptServicePoint rptServicePoint.shortName, rptService
Point.variationPoint.shortLabel
RuleArguments.vtf vtf, vtf.variationPoint.shortLabel
RuleBasedValueCont.ruleBasedValues ruleBasedValues
RuleBasedValueSpecification.arguments arguments, arguments.variationPoint.shortLabel
ServiceDependency.assignedDataType assignedDataType, assignedDataType.variation
Point.shortLabel
SignalServiceTranslationProps.controlPnc controlPnc
SupervisedEntityNeeds.checkpoints checkpoints.supervisedEntityCheckpointNeeds,
checkpoints.variationPoint.shortLabel
SwcBswMapping.runnableMapping runnableMapping, runnableMapping.variation
Point.shortLabel
SwcBswMapping.synchronizedModeGroup synchronizedModeGroup, synchronizedMode
Group.variationPoint.shortLabel
SwcBswMapping.synchronizedTrigger synchronizedTrigger, synchronizedTrigger.variation
Point.shortLabel
SwDataDefProps.swPointerTargetProps <Not applicable due to atpVariation (PropertySet
Pattern)>
SwPointerTargetProps.swDataDefProps swDataDefProps
SwServiceArg.swDataDefProps swDataDefProps
SwSystemconst.swDataDefProps swDataDefProps

Table F.1: Usage of splitable elements

378 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

G Variation Points in the Scope of this Document

This chapter contains a table of all model elements stereotyped atpVariation
in the scope of this document.
Each entry in the table consists of the identification of the model element itself and the
applicable value of the tagged value vh.latestBindingTime.
For more information about the concept of variation points and how model elements
that contain variation points shall be treated please refer to [1].
Variation Point Latest Binding Time
AccessCount.value preCompileTime
AccessCountSet.accessCount preCompileTime
ARPackage.arPackage blueprintDerivationTime
ARPackage.element systemDesignTime
ArrayValueSpecification.element preCompileTime
BswInternalBehavior.arTypedPerInstanceMemory preCompileTime
BswInternalBehavior.bswPerInstanceMemoryPolicy preCompileTime
BswInternalBehavior.clientPolicy preCompileTime
BswInternalBehavior.distinguishedPartition preCompileTime
BswInternalBehavior.entity preCompileTime
BswInternalBehavior.event preCompileTime
BswInternalBehavior.exclusiveAreaPolicy preCompileTime
BswInternalBehavior.internalTriggeringPoint preCompileTime
BswInternalBehavior.internalTriggeringPointPolicy preCompileTime
BswInternalBehavior.modeReceiverPolicy preCompileTime
BswInternalBehavior.modeSenderPolicy preCompileTime
BswInternalBehavior.parameterPolicy preCompileTime
BswInternalBehavior.perInstanceParameter preCompileTime
BswInternalBehavior.receptionPolicy preCompileTime
BswInternalBehavior.releasedTriggerPolicy preCompileTime
BswInternalBehavior.schedulerNamePrefix preCompileTime
BswInternalBehavior.sendPolicy preCompileTime
BswInternalBehavior.serviceDependency preCompileTime
BswInternalBehavior.triggerDirectImplementation preCompileTime
BswModuleDependency.targetModuleRef preCompileTime
BswModuleDescription.bswModuleDependency preCompileTime
BswModuleDescription.bswModuleDocumentation preCompileTime
BswModuleDescription.expectedEntry preCompileTime
BswModuleDescription.implementedEntry preCompileTime
BswModuleDescription.providedClientServerEntry preCompileTime
BswModuleDescription.providedData preCompileTime
BswModuleDescription.providedModeGroup preCompileTime
BswModuleDescription.releasedTrigger preCompileTime
BswModuleDescription.requiredClientServerEntry preCompileTime
BswModuleDescription.requiredData preCompileTime
5

379 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Variation Point Latest Binding Time
BswModuleDescription.requiredModeGroup preCompileTime
BswModuleDescription.requiredTrigger preCompileTime
BswModuleEntity.accessedModeGroup preCompileTime
BswModuleEntity.activationPoint preCompileTime
BswModuleEntity.callPoint preCompileTime
BswModuleEntity.dataReceivePoint preCompileTime
BswModuleEntity.dataSendPoint preCompileTime
BswModuleEntity.issuedTrigger preCompileTime
BswModuleEntity.managedModeGroup preCompileTime
BswModuleEntry.argument blueprintDerivationTime
BswServiceDependency.assignedData preCompileTime
BswServiceDependency.assignedEntryRole preCompileTime
DiagEventDebounceCounterBased.counterDecrementStepSize preCompileTime
DiagEventDebounceCounterBased.counterFailedThreshold preCompileTime
DiagEventDebounceCounterBased.counterIncrementStepSize preCompileTime
DiagEventDebounceCounterBased.counterJumpDown preCompileTime
DiagEventDebounceCounterBased.counterJumpDownValue preCompileTime
DiagEventDebounceCounterBased.counterJumpUp preCompileTime
DiagEventDebounceCounterBased.counterJumpUpValue preCompileTime
DiagEventDebounceCounterBased.counterPassedThreshold preCompileTime
DiagEventDebounceTimeBased.timeBasedFdcThresholdStorageValue preCompileTime
DiagEventDebounceTimeBased.timeFailedThreshold preCompileTime
DiagEventDebounceTimeBased.timePassedThreshold preCompileTime
ErrorTracerNeeds.tracedFailure preCompileTime
ExecutableEntity.canEnter preCompileTime
ExecutableEntity.runsInside preCompileTime
Implementation.buildActionManifest codeGenerationTime
Implementation.generatedArtifact preCompileTime
Implementation.requiredArtifact preCompileTime
Implementation.requiredGeneratorTool preCompileTime
ImplementationDataType.subElement preCompileTime
ImplementationDataTypeElement.arraySize preCompileTime
ImplementationDataTypeElement.subElement preCompileTime
InternalBehavior.constantMemory preCompileTime
InternalBehavior.exclusiveArea preCompileTime
InternalBehavior.exclusiveAreaNestingOrder preCompileTime
InternalBehavior.staticMemory preCompileTime
McDataInstance.subElement preCompileTime
McFunctionDataRefSet preCompileTime
McSupportData.emulationSupport preCompileTime
McSupportData.mcParameterInstance postBuild
McSupportData.mcVariableInstance postBuild
ModeDeclarationGroup.modeDeclaration blueprintDerivationTime
NumericalOrText.vf preCompileTime
5

380 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate

 Basic Software Module Description Template
AUTOSAR CP R23-11

4
Variation Point Latest Binding Time
NumericalValueSpecification.value preCompileTime
RecordValueSpecification.field preCompileTime
ResourceConsumption.accessCountSet preCompileTime
ResourceConsumption.executionTime preCompileTime
ResourceConsumption.heapUsage preCompileTime
ResourceConsumption.memorySection preCompileTime
ResourceConsumption.sectionNamePrefix preCompileTime
ResourceConsumption.stackUsage preCompileTime
RptComponent.rptExecutableEntity preCompileTime
RptExecutableEntity.rptExecutableEntityEvent preCompileTime
RptExecutableEntity.rptRead preCompileTime
RptExecutableEntity.rptWrite preCompileTime
RptSupportData.rptComponent preCompileTime
RptSupportData.rptServicePoint preCompileTime
RuleArguments.vf preCompileTime
RuleArguments.vtf preCompileTime
RuleBasedValueSpecification.arguments preCompileTime
ServiceDependency.assignedDataType preCompileTime
SupervisedEntityNeeds.checkpoints preCompileTime
SwcBswMapping.runnableMapping preCompileTime
SwcBswMapping.synchronizedModeGroup preCompileTime
SwcBswMapping.synchronizedTrigger preCompileTime
SwDataDefProps codeGenerationTime
SwDataDefProps.swValueBlockSize preCompileTime
SwDataDefProps.swValueBlockSizeMult preCompileTime
SwTextProps.swMaxTextSize preCompileTime
ValueList.vf preCompileTime

Table G.1: Usage of variation points

381 of 381 Document ID 89: AUTOSAR_CP_TPS_BSWModuleDescriptionTemplate