Ing Guidelines Of Basic Software EA UML AUTOSAR TR BSWUML Guide

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 51

Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Document Title Modeling Guidelines of Basic
Software EA UML Model
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 117
Document Status Final
Part of AUTOSAR Standard Classic Platform
Part of Standard Release 4.4.0
Document Change History
Date Release Changed by Description
2018-10-31 4.4.0
AUTOSAR
Release
Management
•minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
2017-12-08 4.3.1
AUTOSAR
Release
Management
•minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
2018-04-17 4.4.0 AUTOSAR
Technical Office •Removed obsolete elements.
2016-11-30 4.3.0
AUTOSAR
Release
Management
•Editorial changes
2014-10-31 4.2.1 AUTOSAR
Administration •Editorial changes
2013-03-15 4.1.1 AUTOSAR
Administration •Finalized for Release 4.1
2010-02-02 3.1.4 AUTOSAR
Administration
•Modeling of header files has been
revised
•Description of parameter modeling
has been reworked
•Legal disclaimer revised
2008-08-13 3.1.1 AUTOSAR
Administration •Legal disclaimer revised
1 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2007-12-21 3.0.1 AUTOSAR
Administration
•Added description for range
stereotype
•Change Requirements for function
parameter and structure attributes
•Document meta information
extended
•Small layout adaptations made
2006-11-28 2.1.1 AUTOSAR
Administration
•Usage of packages clarified
•Sequence diagram modeling clarified
•Legal disclaimer revised
2006-05-16 2.0 AUTOSAR
Administration •Initial release
2 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
3 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Disclaimer
This work (specification and/or software implementation) and the material contained in
it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the work.
The material contained in this work is protected by copyright and other types of intel-
lectual property rights. The commercial exploitation of the material contained in this
work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the work
may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
4 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Table of Contents
1 Introduction 8
1.1 Artifacts ................................... 8
1.1.1 Header Files ........................... 8
1.1.2 Imported Type Definitions .................... 8
1.1.3 Type Definitions ......................... 8
1.1.4 Function Definitions ....................... 8
1.1.5 Callback Notifications ...................... 9
1.1.6 Scheduled Functions ...................... 9
1.1.7 Mandatory Interfaces ...................... 9
1.1.8 Optional Interfaces ........................ 9
1.1.9 Configurable Interfaces ..................... 9
1.1.10 Sequence Diagrams ....................... 10
1.1.11 Various Diagrams ........................ 10
1.1.12 Modeling of services ....................... 10
2 Modeling Guide 11
2.1 Terminology ................................. 11
2.2 Model Structure ............................... 11
2.3 Modeling of BSW Modules ......................... 12
2.3.1 Modules ............................. 12
2.3.1.1 Packages ........................ 12
2.3.1.2 Components ...................... 12
2.3.1.3 Component Diagrams ................. 13
2.3.1.4 Type Diagrams ..................... 14
2.3.2 Function interfaces ....................... 14
2.3.3 API Functions .......................... 15
2.3.3.1 Scheduled Functions .................. 16
2.3.4 API Function Parameters .................... 17
2.3.5 Module Dependencies ...................... 19
2.3.5.1 Virtual Interfaces .................... 19
2.3.5.2 Mandatory Interfaces .................. 21
2.3.5.3 Optional Interfaces ................... 21
2.3.6 Generic Interface ........................ 21
2.3.7 Callback Notifications ...................... 22
2.3.7.1 Callback definition and usage (non Configurable
Callback) ........................ 23
2.3.7.2 Configurable Callback definition and usage ..... 24
2.3.7.3 Callback Generic Interfaces .............. 25
2.3.8 Data Type Definitions ...................... 26
2.3.8.1 Simple Types ...................... 26
2.3.8.2 Enumerations ...................... 27
2.3.8.3 Std_ReturnType Extensions .............. 28
2.3.8.4 Structures ........................ 29
2.3.8.5 Bitfields ......................... 30
5 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.8.6 Modeling of variability in data types .......... 33
2.3.9 Modeling of services (MoS) ................... 35
2.3.9.1 Modeling of Client Server Interfaces ......... 35
2.3.9.2 Modeling of Mode Switch Interfaces ......... 40
2.3.9.3 Modeling of Sender Receiver Interfaces ....... 42
2.3.9.4 Modeling of special Types in Service Interfaces . . . 44
2.3.9.5 Modeling of variability of service interfaces ...... 45
2.3.9.6 Modeling of PortAPIOptions and PortDefinedArgu-
mentValues ....................... 48
2.4 Diagrams .................................. 49
2.4.1 Header File Modeling ...................... 49
2.4.2 Sequence Diagrams ....................... 50
2.4.3 State Machine Diagrams .................... 50
2.5 Support for Life Cycle concept in BSW Model .............. 50
6 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
References
[1] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[2] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList
[3] Glossary
AUTOSAR_TR_Glossary
[4] Specification of Standard Types
AUTOSAR_SWS_StandardTypes
[5] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[6] Standardized M1 Models used for the Definition of AUTOSAR
AUTOSAR_MOD_GeneralDefinitions
7 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
1 Introduction
This modeling guide describes the applied modeling techniques and rules, used to
specify the AUTOSAR Basic Software within a UML model.
The information contained in the BSW model is processed by the AUTOSAR Meta
Model Tool (MMT) and provides a major input of the several Software Specifications
(SWS) defined by AUTOSAR. In order to make the BSW model accessible by the MMT,
it is essential that the model observes the rules described in this document.
1.1 Artifacts
The main purpose of the AUTOSAR BSW UML model is keeping the 99+ documents
synchronous with respect to file structure, provided and required interfaces, sequence
diagrams, state machines etc. Therefore, all the relevant information is kept in the
BSW model according to the modeling rules specified in chapter 2, Modeling Guide.
The following artifacts are contributed to the SWS documents by the BSW UML model:
1.1.1 Header Files
Chapter 5.1 of each SWS document contains the BSW module’s file structure, in par-
ticular its file inclusion structure. Most modules’ include file relationships have a similar
structure, in fact some parts are actually identically modeled. Therefore, the Header
File structure is being modeled using a class diagram, with stereotyped classes repre-
senting the source code- and header files; see section 2.4.1.
1.1.2 Imported Type Definitions
SWS chapter 8.1 contains a tabular list of imported types. This table is automatically
generated from the module dependency as explained in section 2.3.5.
1.1.3 Type Definitions
SWS chapter 8.2 contains detailed descriptions of all types defined within a given BSW
module. For details on the modeling of type definitions refer to section 2.3.8.
1.1.4 Function Definitions
SWS chapter 8.3 contains a detailed description for each function provided by the
BSW module. The description is presented in form of a table with a specific layout.
8 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
The individual fields of the table are filled from the API function definitions according to
section 2.3.3.
1.1.5 Callback Notifications
Very similar to the Function Definitions, SWS chapter 8.4 contains the callback defi-
nitions the BSW module provides. These are callbacks which will be called by other
BSW modules, where the lower layer module is typically the caller. A table for each
callback notification will be generated for a module’s specified callbacks according to
section 2.3.7.
1.1.6 Scheduled Functions
Scheduled Functions are described in SWS chapter 8.5. The definition of scheduled
functions in the BSW UML model is described in section 2.3.3.1.
1.1.7 Mandatory Interfaces
SWS chapter 8.6.1 contains a list of “mandatory interfaces” expected by the module.
The list is generated from the BSW UML model according to the mandatory dependen-
cies as described in section 2.3.5.2.
1.1.8 Optional Interfaces
Similarly, the list of “optional interfaces” contained in SWS chapter 8.6.2 is generated
from the BSW UML model according to the optional dependencies as described in
section 2.3.5.3.
1.1.9 Configurable Interfaces
SWS Chapter 8.6.3 contains a BSW module’s “Configurable Interfaces”. These are
interfaces whose called function name can be configured using ECU configuration pa-
rameters. In AUTOSAR, these are typically used for issuing callback notifications, i.e.
the module owning the configurable interface uses it to notify a (configurable) upper
layer module’s callback. In other words the module defining a “Configurable Inter-
face” calls an other module that implements these interface definition. A table for each
callback notification will be generated for a module’s specified callbacks according to
section 2.3.7.2.
9 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
1.1.10 Sequence Diagrams
In order to visualize the interaction of a BSW module with other modules, SWS Chap-
ter 9 contains UML Sequence Diagrams for the module’s typical use cases. In or-
der to keep such Sequence Diagrams consistent between different modules within the
AUTOSAR BSW stack, they are also modeled within the BSW UML model. The dia-
grams are being exported to image files by the mmt tool; they are then being included
by the SWS document files. For the detailed modeling guidelines see section 2.4.2
1.1.11 Various Diagrams
The SWS documents of various BSW modules use additional UML diagrams e.g. for
either specifying core functionality, or for additionally illustrating dependencies between
modules. Some concrete examples are the various state machines used throughout
the AUTOSAR BSW stack, for example in the CAN State Manager or in COM manager.
Whenever possible, such diagrams should also be modeled in the BSW UML model.
This ensures that the sources of the document diagrams will not get lost, and also
facilitates their maintenance and keeping a uniform modeling style.
1.1.12 Modeling of services
BSW Modules belonging to the Service Layer of the AUTOSAR Basic Software Archi-
tecture may offer their services in the form of AUTOSAR Service Interfaces. AUTOSAR
Service Interfaces are described in terms of the Software Component Template rather
than C-language interfaces, and they come in different flavors, e.g. ClientServer-
Interface, SenderReceiverInterface, ModeSwitchInterface. Consequently, their prop-
erties require a different style of modeling than the standard BSW API functions. Mod-
eling of AUTOSAR services is described in section 2.3.9
10 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2 Modeling Guide
This Chapter contains the modeling rules that shall be followed when modeling
AUTOSAR BSW artifacts within the BSW UML model. It is important that these rules
are used consistently throught the model for the following reasons: The model stays
readable, additions and modifications are done in a reproducible way preventing the
duplication of elements, and most importantly, the automated artifact generation using
the MMT tool depends on nonambiguous modeling conventions.
2.1 Terminology
The agreed tool for UML modeling in AUTOSAR is Enterprise Architect by Sparx Sys-
tems. Accordingly the BSW model is being maintained using Enterprise Architect ver-
sion 7.5 and above. This guide focusses on modeling techniques rather than tools,
therefore this document strives to describe the concepts in terms of UML. Neverthe-
less, in order to be precise, sometimes terms specific to Enterprise Architect are used.
2.2 Model Structure
The root structure of the BSW UML model consists of the following packages:
ReadMe: Contains diagrams providing version number, known limitations and dis-
claimer.
Interaction Views: Contains sequence charts for modeling interactions of different
modules. Only sequence diagrams shall be placed into this packages. The modules
are arranged by stack vertically.
SoftwarePackages: Contains the BSW modules definitions including interfaces and
type definitions. Moreover state and header diagrams are modelled here. The modules
are arranged by layer horizontally.
Generic Elements: Contains common interface definitions e.g. configurable callback
definitions.
11 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3 Modeling of BSW Modules
2.3.1 Modules
2.3.1.1 Packages
[TR_BSWMG_00001] BSW Module Packages dFor each basic software module a
UML package (the “module package”) shall be placed within the package structure
according to the module’s role in the Layered Software Architecture[1]. c()
[TR_BSWMG_00002] Naming of BSW Module Packages dThe name of the module
package shall be the ‘module abbreviation’ as specified in the List of Basic Software
Modules[2]. c()
Figure 2.1: Example of a module package
2.3.1.2 Components
[TR_BSWMG_00003] BSW Module Components dEach basic software module shall
be modeled as an UML component with stereotype «module» (the “module compo-
nent”). c()
12 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00004] Naming of BSW Module components dThe name of the mod-
ule component shall be the ‘module abbreviation’[2]. c()
[TR_BSWMG_00036] BSW Module ID dThe tagged value “bsw.moduleId" shall be
set to the module ID as specified in the List of Basic Software Modules[2]. c()
[TR_BSWMG_00005] Location of BSW Module components dEach module com-
ponent shall be modeled as a top-level element of its containing module package. c
()
[TR_BSWMG_00094] SWS Item ID of the Mandatory Interfaces table of the mod-
ule dThe tagged value “bsw.mandatory.swsItemId” is used to specify the SWS Item ID
of a API function. c()
[TR_BSWMG_00095] Up-traces of the Mandatory Interfaces table of the module
dThe tagged value “bsw.mandatory.traceRefs” is used to specify up-traces to require-
ments. Multiple requirement IDs have to be separated by a comma. c()
[TR_BSWMG_00096] SWS Item ID of the Optional Interfaces table of the module
dThe tagged value “bsw.optional.swsItemId” is used to specify the SWS Item ID of a
API function. c()
[TR_BSWMG_00097] Up-traces of the Optional Interfaces table of the module d
The tagged value “bsw.optional.traceRefs” is used to specify up-traces to requirements.
Multiple requirement IDs have to be separated by a comma. c()
[TR_BSWMG_00098] SWS Item ID of the Imported Types table of the module d
The tagged value “bsw.importedTypes.swsItemId” is used to specify the SWS Item ID
of a API function. c()
[TR_BSWMG_00099] Up-traces of the Imported Types table of the module dThe
tagged value “bsw.importedTypes.traceRefs” is used to specify up-traces to require-
ments. Multiple requirement IDs have to be separated by a comma. c()
2.3.1.3 Component Diagrams
[TR_BSWMG_00006] Component Diagrams dThe module package shall contain a
“component diagram” (Enterprise Architect: UML Component Diagram). c()
[TR_BSWMG_00007] Naming of Component Diagrams dThe name of the compo-
nent diagram shall be identical to the name of the module component (module abbre-
viation). c()
[TR_BSWMG_00008] Content of Component Diagrams dThe component diagram
contains the module component as well as all of the module’s interface relationships. c
()
13 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.1.4 Type Diagrams
[TR_BSWMG_00009] Type Diagram dIf a BSW module defines data types, its module
package shall contain a “types diagram” (Enterprise Architect: UML Class Diagram). c
()
[TR_BSWMG_00010] Naming of Types Diagram dThe name of the types diagram
shall be the name of the module component followed by a space character followed by
Types, e.g. FrTp Types.c()
[TR_BSWMG_00011] Content of Types Diagram dThe types diagram shall contain
all types defined by the BSW module. c()
2.3.2 Function interfaces
An AUTOSAR BSW modules provides services to other BSW modules in the form of C-
syntax functions. These functions are also the underlying implementation of AUTOSAR
Services accessed by Software Components over the RTE.
This section explains how each such function is modeled in the form of an UML opera-
tion. Each operation is placed in an UML interface owned by the BSW module realizing
the service. This UML interface is hereinafter called Function interface.
[TR_BSWMG_00012] Function interfaces dFor each function to be provided by a
BSW module, an UML interface (the “function interface”) shall be created in its module
package. The stereotype of the interface shall be “interface”. c()
[TR_BSWMG_00013] Naming of function interfaces dThe function interface shall
have the same name as the actual function. (depends on TR_BSWMG_00017, TR_BSWMG_00030) c()
Figure 2.2: Naming example of a function interface
[TR_BSWMG_00014] API functions in component diagrams dAPI functions shall
be visible in the providing BSW module’s component diagram. c()
Note: The easiest way to achieve this is to drag the new Interface directly into the
providing module’s component diagram when creating the interface.
[TR_BSWMG_00015] Realization relationships dThe BSW module providing the
service shall have a directed “Realization” association to the interface. The association
shall be stereotyped «realize». c()
Note: To differ associations from explanatory diagrams from generation relevant asso-
ciations the stereotype «realize» has to be added to each generation relevant realize
association.
14 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.3: Realization example of an interface
2.3.3 API Functions
[TR_BSWMG_00016] API Functions dThe function itself shall be modeled as an
UML operation (the “operation”) having one of the following stereotypes: «function»,
«scheduled_function», «callout», «callback». c()
[TR_BSWMG_00017] Naming of API Functions dThe name of the operation shall
be the API function name. c()
[TR_BSWMG_00030] Name prefixes dThe name of the operation shall be prefixed
with the name of the realizing module (module abbreviation) followed by an underscore,
i.e.: <Ma>_<operation_name> (Ma = Module Abbreviation)c()
[TR_BSWMG_00018] Location of Operations dThe operation shall be placed into
its corresponding provider’s realized interface. c()
[TR_BSWMG_00019] API Function documentation dEach API function shall pro-
vide a short description. c()
Note: EA provides a text-field called ‘Notes’ to take the operation’s description.
[TR_BSWMG_00034] “Return Type” field in operation dThe operation’s “Return
Type” field shall be left empty. See TR_BSWMG_00023 for modeling return parame-
ters. c()
[TR_BSWMG_00024] Service ID dThe tagged value “ServiceID” shall contain a ser-
vice identifier (the ‘Service ID’) which shall be unique within the BSW module. The
parameter is specified in hexadecimal notation using lowercase characters and shall
be padded to two hexadecimal digits, e.g. 0x0d c()
[TR_BSWMG_00025] Reentrancy dThe tagged value “Reentrant” shall determine
whether the function needs to be implemented as reentrant or not. Allowed values are
“Reentrant”, “Non Reentrant”, “Conditionally Reentrant”. Reentrancy conditions shall
not be in the scope of the BSW UML model; instead, they shall be moved into individual
SWS items (i.e.: “Non Reentrant for the same device.”) c()
15 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00026] Synchronicity dThe tagged value “Synchronous” shall be set
either to “Synchronous” or “Asynchronous”. Some modules may specify additional
clauses. c()
[TR_BSWMG_00031] Alternative Anchor Name dThe optional tagged value
“aName” is used to specify an alternative anchor name for the operation to be used
when generating html-references within the BSW artifacts. This alternative anchor
name shall be used in cases where the default anchor name is not suitable for usage,
i.e. because it exceeds the length limit for links in Word or it includes non-standard
characters. c()
[TR_BSWMG_00150] SWS Item ID of a API function dThe tagged value
“bsw.swsItemId” is used to specify the SWS Item ID of a API function. c()
[TR_BSWMG_00151] Up-traces of a API function dThe tagged value
“bsw.traceRefs” is used to specify up-traces to requirements. Multiple requirement
IDs have to be separated by a comma. c()
[TR_BSWMG_00140] Header File Reference of a API function dThe tagged value
“bsw.headerFile” is used to specify the header file where the API function is provided.
c()
Figure 2.4: TaggedValues example of a API function
2.3.3.1 Scheduled Functions
[TR_BSWMG_00037] Stereotype for Scheduled Functions dScheduled Functions
shall be modeled by setting the operation’s stereotype to «scheduled_function». c()
Note: The Schedule attribute of a Scheduled Function is not used in any artifact any
more.
16 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.4 API Function Parameters
[TR_BSWMG_00020] Function Parameters dThe function parameters shall have
mandatory entries for “Name”, “Type”, “Direction” and “Notes”. c()
[TR_BSWMG_00032] Parameter types dThe parameter “Type” shall be one of the
existing types defined in the BSW model. c()
[TR_BSWMG_00033] C-Style Pointers dParameters may be modeled as C-Style
pointers by appending * to the parameter type, e.g. PduInfoType*c()
[TR_BSWMG_00027] Mandatory pointers for output parameters dParameters
must be modeled as pointers if their “Direction” attribute is set to out or inout.c
()
[TR_BSWMG_00035] Mandatory constant types for pointers of input parameters
dPointer-type parameters of direction type “in", i.e. parameters that represent read-
only structures or arrays, may prepend the parameter type with the const keyword.
This enforces that the data pointed to by the parameter is read-only and will not be
altered by the function. Example: const FrIf_ConfigType*c()
[TR_BSWMG_00021] Parameter Direction dThe parameter’s direction type attribute
shall be set to one of the values in,out,inout,return.c()
[TR_BSWMG_00022] Parameter Description dEach parameter shall provide a short
description about its purpose. c()
Note: EA provides a textfield called ‘Notes’ to take the parameters description.
[TR_BSWMG_00023] Return Parameter dIf the function’s return type is not equal to
void, the return value shall be modeled like an operation parameter with the following
exceptions: It shall be the first parameter in the list. Additionally, it shall be the only
parameter to have its “Direction” set to “return”. The notes field shall concisely describe
the possible return values. c()
17 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.5: Parameter example of a API function
[TR_BSWMG_00129] Optional Parameters dThe existence of a parameter may de-
pend on the module configuration. In this case, the parameter shall have the stereotype
«optional». c()
[TR_BSWMG_00130] Multiplicity of Parameters dA parameter with a given type may
occur several times, where the multiplicity is specified by configuration. In this case,
the parameter shall have the stereotype «multiple». c()
Hint: Don’t use the multiplicity button in the parameter edit mask to configure the mul-
tiplicity.
[TR_BSWMG_00131] Mutual Exclusive Variants of Parameters dA parameter may
appear in different variants within the same position of the function signature, where
one specific variant will be selected by configuration. In this case, the parameter shall
be modeled several times in all its possible variants and each variant of the parameter
shall have the stereotype «mutualexcl». c()
Example: The parameter “buffer” of the Xfrm function “<Mip>_<transformerId>” can
be configured either as “inout” or “out”. It therefore shall be modeled two times, one
time with Direction “inout” and the second time with Direction “out”. Since Enterprise
Architect requires parameter names to be unique, the first parameter variant may be
named “buffer{inout}” and the second one “buffer{out}”.
Hint: All variants of a mutual exclusive parameter shall have the same name; the name
without the curly brackets (including the text) have to be the same.
18 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.6: Mutual Exclusive Parameter example of a API function
2.3.5 Module Dependencies
2.3.5.1 Virtual Interfaces
In general AUTOSAR BSW modules require functions from the APIs of other BSW
modules in order to fulfill their own functionality. The general modeling pattern of de-
pendencies between one BSW module and another uses so called function interfaces
and virtual interfaces.
First, due to the fact that dependencies between APIs sometimes have to be expressed
on a single API level of detail, each API function requires a representation on module
level. For this purpose, the function interfaces have been introduced. (see 2.3.2)
Second, in order to further enhance the expressiveness of the BSW module, the con-
cept of function interfaces is extended by virtual interfaces.Virtual interfaces are
derived from function interfaces to merge a certain set of API functions. Recursive
structures of virtual interfaces are also allowed, so a virtual interface is allowed to be
derived from other virtual interfaces. This concept basically allows to reduce the num-
ber of module dependencies on the ’client’ side, by providing a single virtual interface
per providing module, collecting all functions required by this module.
[TR_BSWMG_00028] Virtual Interfaces dAvirtual interface shall be modeled as an
interface with the stereotype «interface» (just like a normal interface). c()
[TR_BSWMG_00029] Naming of Virtual Interface dThe name of a virtual interface
shall consist of the name of the depending BSW module, the name of the providing
module and the kind of dependency, each part separated by an underscore.
19 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
<NameOfDependingModule>_<NameOfProvidingModule>_<KindOfRelation>
c()
[TR_BSWMG_00039] Virtual Interface Multiplicity dOne virtual interface refers to
exactly one pair of modules of realizing and depending modules. c()
[TR_BSWMG_00040] Virtual Interface Location dAvirtual interface shall be placed
in the module package of the depending BSW module. c()
[TR_BSWMG_00041] Virtual Interface Contents dAvirtual interface shall inherit its
functions from the realizer’s function interfaces. c()
[TR_BSWMG_00042] No Mixed Usage of Function Interfaces and Virtual Inter-
faces dDepending modules shall either directly depend on another module’s function
interfaces approach or depend on a virtual interface towards the other module. The
two approaches shall not be mixed. c()
Figure 2.7: Virtual interfaces example for defining optional interfaces
20 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.5.2 Mandatory Interfaces
[TR_BSWMG_00043] Stereotype for Mandatory Dependencies on Interfaces d
The user module shall have dependencies with stereotype «mandatory» to all its
mandatory interfaces. c()
[TR_BSWMG_00044] Mandatory Dependencies dAll mandatory dependencies held
by a user module onto a provider module shall be modeled as exactly one virtual inter-
face. c()
[TR_BSWMG_00045] Naming of Mandatory Usage Collections dThe virtual inter-
face shall have the name <user_module>_<provider_module>_Mandatory. c()
2.3.5.3 Optional Interfaces
[TR_BSWMG_00046] Stereotypes for Optional Dependencies on Interfaces dThe
user module shall have dependencies with stereotype «optional» to all its optional in-
terfaces. c()
[TR_BSWMG_00047] Optional Dependencies dAll optional dependencies held by a
user module onto a provider module shall be modeled as exactly one virtual interface.
c()
[TR_BSWMG_00048] Naming of Optional Usage Collections dThe virtual interface
shall have the name <user_module>_<provider_module>_Optional. c()
2.3.6 Generic Interface
In some occasions the AUTOSAR BSW stack defines a number of interfaces which
have basically the same function signature but slightly differ with regards to a module-
specific naming. In these cases, redundant definitions of interfaces shall be prevented
by usage of only one interface definition. To define a specific naming, a “Custom
Interface” shall be used. A “Custom Interface” inherits from the interface definition and
can override the naming rules.
The following modeling pattern shall be used for defining “Generic Interfaces”:
[TR_BSWMG_00061] Generic Interface Definition dThe function definition shall be
placed into an UML interface having the stereotype «generic_interface». c()
[TR_BSWMG_00132] Generic Interface Definition dThis “generic interface” defini-
tion shall be considered abstract and not directly be referenced by any module. c()
[TR_BSWMG_00133] Generic Interface Definition dA Generic Interface Definition
shall contain ONE operation with stereotype «function_blueprint». c()
21 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00134] Custom Interface dIn order to assign a “Custom Interface” to
a “Generic Interface Definition”, a generalization association shall be modeled (target
“Generic Interface Definition”). c()
[TR_BSWMG_00062] Custom Interface dIn order to assign a concrete naming pat-
tern to a function defined within a generic interface, another interface shall be defined
having the same stereotype «generic_interface». c()
Note: Due to prevent reworking of the existing model and the generator tooling the in-
terface of “Generic Interface Definition” and “Custom Interface” uses the same stereo-
type.
[TR_BSWMG_00156] Custom Interface dA Custom Interface shall not contain a
function definition. c()
[TR_BSWMG_00063] Provider Naming Scheme dThe naming pattern for a provider
association («realize») of a module on a custom interface shall be configured using the
tagged value “naming_provider”. c()
[TR_BSWMG_00064] User Naming Scheme dThe naming pattern for a user de-
pendency («mandatory» or «optional») of a module on a custom interface shall be
configured using the tagged value “naming_user”. c()
[TR_BSWMG_00065] User-Configurable Naming Scheme dThe naming pattern for
a «configurable» dependency of a module on a custom interface shall be configured
using the tagged value “naming_configurable”. c()
Figure 2.8: Generic Interface/Custom Interface example
2.3.7 Callback Notifications
In AUTOSAR, a “callback” is defined as functionality in an upper-layer BSW module
that is called by a lower-layer module in order to provide notification as required[3].
22 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.9: Difference between a callback and a regular function call
2.3.7.1 Callback definition and usage (non Configurable Callback)
[TR_BSWMG_00157] Callback definition dCallback definitions shall be modeled as
UML operations and shall use the stereotype «callback». c()
[TR_BSWMG_00158] Callback interface dFor each callback to be called by a BSW
module, an UML interface (the “function interface”) shall be created in its module pack-
age. The stereotype of the interface shall be «interface». c()
[TR_BSWMG_00159] Naming of callback interfaces dThe callback interface shall
have the same name as the actual function. (depends on TR_BSWMG_00017, TR_BSWMG_00030) c()
[TR_BSWMG_00161] Callback function definition dThe callback interface shall con-
tain one function with stereotype «callback». The modeling of the function shall be as
described in 2.3.3.c()
[TR_BSWMG_00162] Callback function usage/call dFor all callbacks a lower mod-
ule can call, a dependency of stereotype «mandatory» or «optional» (target callback
interfaces) shall be modeled, see chapter 2.3.5.2 and 2.3.5.3.c()
[TR_BSWMG_00163] Callback function realization/implementation dFor all call-
backs a upper module implements, a realization of stereotype «realize» (target callback
interfaces) shall be modeled. c()
[TR_BSWMG_00164] Callback function realization/implementation dEach call-
back interface shall be referenced by exactly ONE dependency of stereotype «manda-
tory» or «optional» or «configurable» (There is only one caller, but multiple implemen-
tation can exit and will be assigned by configuration). c()
23 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.10: Example of a Callback definition and usage
2.3.7.2 Configurable Callback definition and usage
Lower-layer modules are caller of callbacks. Often, these modules can configure which
actual instance of a callback definition will be called, i.e. which upper layer will be called
in the callback situation. In the SWS the configurability of a callback is described in
two parts: An API table for the configurable callback function including details like
the callback signature and arguments, and the actual ECU configuration parameters
described in chapter 10.
Figure 2.11: Configurable Callback: The lower module have to be configured which im-
plementation of an upper module will be called.
24 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00059] Configurable Dependency dA lower-layer module shall have
dependencies with stereotype «configurable» to each of its configurable callback defi-
nitions. c()
[TR_BSWMG_00060] Target of a Configurable Dependency is a Generic Defini-
tion dA lower-layer module shall have a generic callback definition as target of the
configurable dependency. c()
The naming of callback functions currently differs between BSW modules, and in par-
ticular between BSW stacks. Therefore, no definitive rules for naming patterns of call-
backs can be stated here. However, as a guideline for adding new callback functions,
either one of the following patterns should be followed:
(1) Module abbreviation, followed by an underscore, followed by the callback function
name. When used in connection with generic callback definitions, the UML interfaces
should get the tagged value naming_configurable = [user]_[name].
(2) The literal string “User”, followed by an underscore, followed by the callback function
name. Additionally, the whole function name is put in angular brackets “<>” in order to
emphasize that this is just a placeholder for the real, configurable name. When used in
connection with generic callback definitions, the UML interfaces should get the tagged
value naming_configurable = <User_[name]>.
2.3.7.3 Callback Generic Interfaces
Similar to the definition of Generic Interfaces, it is possible to define Generic Interfaces
for Callbacks. The purpose of a Callback Generic Interface is to serve as a one-time
definition of a callback. The callback may then be referenced in different contexts, using
differently constructed names in the contexts of different modules, and also varying in
attributes like Service ID.
[TR_BSWMG_00049] Callback Generic Interface Definitions dCallback definitions
shall be modeled as UML operations and shall use the stereotype «callback» and
«function_blueprint». c()
[TR_BSWMG_00050] Callback Generic Interface Name dThe Callback definition
name shall just be the name part describing the actual functionality. In particular, it
shall not contain the name of the provider or user, or literal “<User>” string etc. c()
[TR_BSWMG_00051] Callback Blueprint Interface placement dEach callback
blueprint definition shall be placed inside an UML interface having the same name
as the contained operation with stereotype «generic_interface». c()
[TR_BSWMG_00052] Callback Blueprint interface model location dThe generic
interface definition shall be located within the top-level package “Generic Elements”. c
()
25 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00053] Callback Blueprint interface subpackage location dWithin
package “Generic Elements” the Callback Blueprint interface shall be placed in a sub
package representing the BSW stack associated with the interface:
•ComStack
•IoStack
•MemoryStack
c()
Figure 2.12: Example of Configurable Callback realized with Generic Interfaces
2.3.8 Data Type Definitions
2.3.8.1 Simple Types
[TR_BSWMG_00066] Simple Type Definition dEach simple type definition, i.e. a
type definition which is directly derived from another type or which defines a basic type
like ‘int’ shall be modeled as an UML Class with stereotype «type». c()
[TR_BSWMG_00067] Base Types vs. Derived Types dA simple type definitions shall
either define a base type or be derived from another data type definition. c()
[TR_BSWMG_00068] Base Type Dependencies dA base type shall not derive from
another data type. c()
[TR_BSWMG_00069] Derived Types Dependencies dNormally, a derived type shall
be derived from exactly only one other data type. However, if the type depends on
platform or is configuration specific, it may be derived from more than one type. c()
[TR_BSWMG_00071] Range dIf a simple type has a restricted set of ranges, an
attribute with stereotype «range» has to be created for each such range. The name
of the attribute specifies the range label and the notes field describes the range. c()
Example: Name: “0..2^16-1”
26 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Hint: “Name” is the name of the editing field in the EA edit mask.
[TR_BSWMG_00152] SWS Item ID of a type dThe tagged value “bsw.swsItemId” is
used to specify the SWS Item ID of a API function. c()
[TR_BSWMG_00153] Up-traces of a type dThe tagged value “bsw.traceRefs” is used
to specify up-traces to requirements. Multiple requirement IDs have to be separated by
a comma. c()
[TR_BSWMG_00141] Header File Reference of a type dThe tagged value
“bsw.headerFile” is used to specify the header file where the type is provided. c()
Figure 2.13: Simple type example
2.3.8.2 Enumerations
[TR_BSWMG_00072] Enumeration Definition dEach type definition representing an
enumeration shall be modeled as UML Class with stereotype «enumeration». It shall
be placed inside the interface specifying it. c()
[TR_BSWMG_00073] Enumeration Literal Definition dAll possible literals of the
enumeration shall be modeled as attributes of this class. The order of the attributes
from top to bottom shall represent the order of the enumeration specified. c()
[TR_BSWMG_00074] Enumeration Literal Details dThe following shall be respected
for attributes:
•The Name field shall contain the literal name.
•The field “Type” shall be empty.
•The field “Stereotype” shall be empty.
•The field “Scope” shall be “Public”.
•The flag “Is Literal” shall be set.
•The field “Notes” shall contain the literal description.
c()
[TR_BSWMG_00075] Enumeration Literal Value dLiterals may have a specified
value; in this case it shall be placed in the field “Initial Value”. c()
27 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.14: Enumeration example
2.3.8.3 Std_ReturnType Extensions
AUTOSAR defines a standard API return type that is being used throughout the BSW
stack. It is also the only return type that can be used in ClientServer type Service
Interface Operations.
“Std_ReturnType” is being defined in the SWS Standard Types [4]
([SRS_BSW_00377]). Additionally, two standard values E_OK and E_NOT_OK
are defined which should normally be used with Std_ReturnType.
If these two return values are not sufficient, a BSW module is allowed to define addi-
tional return values to be used with Std_ReturnType. Such user defined values shall
be prefixed with the module prefix and can be in the range 0x02–0x3f.
[TR_BSWMG_00089] Std_ReturnType Extension Definition dThe definition of a
BSW module specific Std_ReturnType extension shall be modeled as an UML Class
with stereotype «extra_literals». c()
[TR_BSWMG_00090] Std_ReturnType Extension Name dThe UML Class contain-
ing the Std_ReturnType extensions shall be named <Ma>_ReturnType (Ma = Module
Abbreviation). c()
[TR_BSWMG_00091] Std_ReturnType Extension Literal Definition dAll BSW mod-
ule specific possible return type extension literals shall be modeled as attributes of this
class. The order of the attributes from top to bottom shall represent the order of the
enumeration specified. c()
[TR_BSWMG_00092] Std_ReturnType Extension Literal Details dThe following
fields shall be used for specifying the return type extension literals:
•The “Name” field shall contain the Std_ReturnType extension literal name.
•The field “Type” shall be empty.
•The field “Stereotype” shall be empty.
•The field “Scope” shall be “Public”.
•The flag “Is Literal” shall be set.
•The field “Notes” shall contain the description of the custom return value.
28 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
c()
[TR_BSWMG_00093] Std_ReturnType Extension Literal Value dCustom
Std_ReturnType values shall always be defined with a specified unsigned inte-
ger value larger than 1(i.e. E_NOT_OK). The integral value shall be placed in the field
“Initial Value”. c()
Figure 2.15: Std_ReturnType Extensions example
2.3.8.4 Structures
[TR_BSWMG_00076] Structure Type Definition dEach type definition representing a
structure declaration shall be modeled as a UML Class with the stereotype «structure».
c()
[TR_BSWMG_00077] Structure Member Definition dAll members of a structure shall
be defined as attributes of this class. The ordering of the attributes shall be the same
as expected in the generated table. c()
[TR_BSWMG_00078] Structure Member Details dThe following shall be respected
for attributes:
•The “Name” field shall contain the name of the attribute.
•The field “Type” shall select the existing type.
•The field “Scope” shall be “Public”.
•The “Containtment” shall be “Not Specified”.
c()
29 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.16: Structure example
2.3.8.5 Bitfields
Bitfield types represent an efficient way of encoding a number of independent variables
within one type. This is done by breaking down the bitfield type into compartments of
individual bit flags or bit ranges containing a series of bits.
One typical application is the implementation of independent boolean variables or “bit
flags” (i.e. binary flags); each of these flags takes up one bit in the bitfield, and can be
set to true or false independently of all other flags contained in the type.
However, Bitfields are not limited to bit flags: They can also contain one or more
groups of bits that can be interpreted as a small-range enumeration type per group
(“bit range”).
Both use cases can be mixed and implemented in several instances within the same
bitfield type. The definition of the bitfield compartments is done using bitmasks.
The bitfield type can additionally define value literals in order to assign concrete mean-
ing to the masked values.
[TR_BSWMG_00079] Bitfield Type Definition dEach type definition representing a
bitfield declaration shall be modeled as a UML Class with the stereotype «bitfield». c()
[TR_BSWMG_00080] Bitfield: Bit Flag Definitions dBinary “bit flags” shall be mod-
eled as attributes of the bitfield type using the stereotype «bitflag». c()
[TR_BSWMG_00081] Bitfield: Bit Flag Value interpretation dThe two possible val-
ues of “bit flags” shall always be interpreted as “TRUE” and “FALSE”. In case a binary
value shall be interpreted differently, it shall be modeled as a Bit Range (see below). c
()
[TR_BSWMG_00082] Bitfield: Bit Flag Details dThe following shall be respected for
Bit Flag attributes:
•The “Name” field shall contain the name of the bit flag. (ARXML: Short-Label of
CompuScale)
•The field “Type” shall be empty.
•The field “Initial Value” shall contain the bit flag value either in hexadecimal (e.g.
0x10) or in binary (e.g. 0b00010000) representation.
30 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
•The field “Stereotype” shall be «bitflag».
•The field “Alias” shall be empty.
•The field “Scope” shall be “Public”.
•The flag “Is Literal” shall not be set.
•The field “Notes” shall describe the meaning of the bit flag.
c()
Figure 2.17: Bitfield bitflag example
[TR_BSWMG_00083] Bitfield: Bit Range Definitions dBit Ranges are continuous
bit regions containing one or more bits. Bit Ranges shall be modeled as attributes of
the bitfiled type using the stereotype «bitrange>. c()
[TR_BSWMG_00084] Bitfield: Bit Range Details dThe following shall be respected
for Bit Range attributes:
•The “Name” field shall contain the name of the bit range. (ARXML: Short-Label)
•The field “Type” shall be empty.
•The field “Initial Value” shall contain a bit mask representing the bit range, see
below.
•The field “Stereotype” shall be «bitrange».
•The field “Alias” shall be empty.
•The field “Scope” shall be “Public”.
•The flag “Is Literal” shall not be set.
•The field “Notes” shall describe the meaning of the bit range.
c()
[TR_BSWMG_00085] Bitfield: Bit Range Mask Value dThe size and location of the
bits used for the bit range shall be specified as a bitmask using either hexadecimal
(e.g. 0x1c) or GCC binary notation, e.g. 0b00011100. This mask value shall be placed
in the field “Initial Value”. c()
31 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00086] Bitfield: Bit Mask and Bit Range Order dThe order of the
attributes from top to bottom shall be increasing with bit flag or bit mask values (i.e. the
value specified in field “Initial Value”. c()
[TR_BSWMG_00087] Bitfield: Bit Range Value Definition dA bit range can assume
a number of different values. The meaning of these values shall be specified using
tagged values on the bitfield type’s attributes. c()
[TR_BSWMG_00088] Bitfield: Bit Range Value Details dEach bit range value spec-
ification consists of a group up to three tagged values.
Each group starts with the keyword “value.”, followed by a number starting from ‘0’,
followed by one of three keywords.
•“name” (e.g.: value.0.name): Name of the value. Example: “PHYS_REQ”
•“value” (e.g.: value.0.value): Hexadecimal or binary value; this shall lie within the
range of one of the bit masks. Example: 0b00010000
•“description” (e.g.: value.0.description): Optional description of the value. Exam-
ple: “physical request”
c()
Figure 2.18: Bitfield Bitflag and Bitrange combined example
Figure 2.19: Taggedvalues of the Bitrange “DTC_CLASS”
32 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.8.6 Modeling of variability in data types
Many data types are configurable since they depend on the configuration of the basis
software. Therefore so called “blueprint conditions” have been introduced into BSW
model to express e.g. configurable inheritance.
[TR_BSWMG_00070] Derived Types Blueprint Conditions dIf a type is derived from
more than one other data type, the generalization dependency shall have a tagged
value “Vh.BlueprintCondition” which specifies the exact conditions for selecting the as-
sociated data type. (e.g., Vh.BlueprintCondition = platform dependend) c()
[TR_BSWMG_00503] Blueprint Policies for CompuMethods dTo de-
fine blueprint policies for a type’s compu method the tagged value
“Vh.compuMethod.BlueprintPolicy” with the legal values “not-modifiable”, “list”, or
“single” shall be used.
The blueprint derivation guide shall be described by the tagged value
“Vh.compuMethod.BlueprintPolicy.DerivationGuide” or for multi-line guides by
•“Vh.compuMethod.BlueprintPolicy.DerivationGuide.1”
•“Vh.compuMethod.BlueprintPolicy.DerivationGuide.2”
•...
It is not applicable for blueprint policy not-modifiable.
To explicitly set the maximal and minimal number of elements for a blueprint
policy list the tagged values “Vh.compuMethod.BlueprintPolicy.maxElements” and
“Vh.compuMethod.BlueprintPolicy.minElements” shall be used. c()
1Vh.compuMethod.BlueprintPolicy:
2list
3Vh.compuMethod.BlueprintPolicy.maxElements:
43
5Vh.compuMethod.BlueprintPolicy.minElements:
61
7Vh.compuMethod.BlueprintPolicy.DerivationGuide.1:
80x00 is locked
9Vh.compuMethod.BlueprintPolicy.DerivationGuide.2:
10 0x01...0x3F is configuration dependent
11 Vh.compuMethod.BlueprintPolicy.DerivationGuide.3:
12 0x40...0xFF is Reserved by Document
[TR_BSWMG_00504] Blueprint Policies for DataContraints dTo
define blueprint policies for a type’s data constr the tagged value
“Vh.dataConstr.lowerLimit.BlueprintPolicy.DerivationGuide” for the lower limit and
the tagged value “Vh.dataConstr.upperLimit.BlueprintPolicy.DerivationGuide” for the
upper limit shall be used. c()
[TR_BSWMG_00505] Blueprint Policies for DataContraints explicit limits dTo ex-
plicitly set the lower and upper limit the tagged values “Vh.dataConstr.lowerLimit.value”
and “Vh.dataConstr.upperLimit.value” shall be used. c()
33 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00506] Blueprint Policies for DataContraints explicit
blueprintValues dTo explicitly set the lower and upper blueprint-
Value the tagged values “Vh.dataConstr.lowerLimit.blueprintValue” and
“Vh.dataConstr.upperLimit.blueprintValue” shall be used. c()
1Vh.dataConstr.lowerLimit.BlueprintPolicy.DerivationGuide:
2For each user, a unique value must be defined at system
generation time. Maximum number of users is 255. Legal user
IDs are in the range 0 .. 254;
3Vh.dataConstr.lowerLimit.blueprintValue:
4min 0
5Vh.dataConstr.lowerLimit.value:
6undefined
7
8Vh.dataConstr.upperLimit.BlueprintPolicy.DerivationGuide:
9For each user, a unique value must be defined at system
generation time. Maximum number of users is 255. Legal user
IDs are in the range 0 .. 254;
10 Vh.dataConstr.upperLimit.blueprintValue:
11 max 254
12 Vh.dataConstr.upperLimit.value:
13 undefined
[TR_BSWMG_00411] Configurable literals for Enumeration Types dFor each
BlueprintCondition delivering names of literals an attribute have to be defined. The
name of the attribute have to be the namepattern e.g. ResetMode. c()
[TR_BSWMG_00412] Configurable literals for Enumeration Types dThe Blueprint-
Condition delivering names of literals an attribute have to be defined on the attribute
using the tagged value “Vh.BlueprintCondition”. c()
[TR_BSWMG_00413] Configurable literals for Enumeration Types dThe value
of configurable literals shall be defined on the attribute using the tagged value
“Vh.BlueprintValue”. The value field shall be set to the variable used in tagged value
“Vh.BlueprintValue”. c()
Example of configurable literals for an enumeration type (EcuM_ShutdownModeType):
The literals of this data type is a union of configured EcuMResetModes and EcuM-
SleepModes. Therefor two attribute have to be modeled containing the condition to get
the literals names and the condition to get the IDs for the literals.
1Attribute name: {ResetMode}
2Attribute value: {ResetModeId}
3
4Vh.BlueprintCondition:
5ResetMode = {ecuc(EcuM/EcuMConfiguration/EcuMFlexConfiguration/
EcuMResetMode.SHORT-NAME)}
6Vh.BlueprintValue:
7ResetModeId = {256 + ecuc(EcuM/EcuMConfiguration/
EcuMFlexConfiguration/EcuMResetMode.EcuMResetModeId)}
1Attribute name: {SleepMode}
2Attribute value : {SleepModeId}
3
34 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
4Vh.BlueprintCondition:
5SleepMode = {ecuc(EcuM/EcuMConfiguration/
EcuMCommonConfiguration/EcuMSleepMode.SHORT-NAME)}
6Vh.BlueprintValue:
7SleepModeId = {ecuc(EcuM/EcuMConfiguration/
EcuMCommonConfiguration/EcuMSleepMode.EcuMSleepModeId)}
2.3.9 Modeling of services (MoS)
Services are provided through ports. A port implements a port interface. A
port interface can be a ClientServerInterface, a SenderReceiverInterface or a
ModeSwitchInterface.
A ClientServerInterface defines the available service operations. A service operation
defines return, input and output parameters. Each service operation has a relation-
ship to an existing api function (c function). Blueprints allow to configure things like
parameters, services, ...
A SenderReceiverInterface defines DataElements. Each data element have to be
linked to a data type.
A ModeSwitchInterface defines modes within a ModeDeclarationGroup.
Note: To get a better understanding of the modeling, listing examples of the informal
textual definition of service interfaces in AUTOSAR R4.0.3 SWS documents are used.
If you are not familiar with this old definition, please ignore these listings.
2.3.9.1 Modeling of Client Server Interfaces
The following listing shows the old syntax of modeling / defining ClientServerInterface
in AUTOSAR R4.0.3 SWS documents.
1ClientServerInterface Csm_Hash {
2
3// errors assisioated with the ProtInterface
4PossibleErrors {
5CSM_E_NOT_OK = 1
6CSM_E_BUSY = 2
7CSM_E_SMALL_BUFFER = 3
8};
9
10
11 //containing operations
12
13 //parameter kinds can be IN, OUT and INOUT
14 //
15 //ERR is not a parameter
16 // -> should be a associated error to an operation
17 HashStart (
18 ERR(CSM_E_NOT_OK, CSM_E_BUSY)
35 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
19 );
20
21 HashUpdate (
22 IN HashDataBuffer dataBuffer,
23 IN uint32 dataLength,
24 ERR(CSM_E_NOT_OK, CSM_E_BUSY)
25 );
26
27 HashFinish (
28 OUT HashResultBuffer resultBuffer,
29 INOUT HashLengthBuffer resultLength,
30 IN boolean TruncationIsAllowed,
31 ERR(CSM_E_NOT_OK, CSM_E_BUSY, CSM_E_SMALL_BUFFER)
32 );
33 };
Figure 2.20: Schematic overview of Client Server Interfaces
[TR_BSWMG_00160] MoS dAll additional elements of service modeling shall be
placed in a package “ARInterfaces”. This packages shall be a child package of the
module package. c()
[TR_BSWMG_00100] MoS Port dA port shall be modeled as an UML port having one
of the following stereotype «RPortPrototype», «PPortPrototype», «PRPortPrototype».
The port shall be provided by the module component. c()
[TR_BSWMG_00101] MoS Port dThe port interface, that the port implements, shall be
modeled as a dependency of stereotype «abswRequires» to a ClientServerInterface,
a SenderReceiverInterface or a ModeSwitchInterface. c()
36 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00102] MoS Port Interface dA port interface shall be modeled as
a class of stereotype «ClientServerInterface», a «SenderReceiverInterface» or a
«ModeSwitchInterface». The stereotype «ClientServerInterface» shall be used to
model a Client Server Interface. The stereotype «SenderReceiverInterface» shall be
used to model a Sender Receiver Interface. The stereotype «ModeSwitchInterface»
shall be used to model a Mode Switch Interface. c()
[TR_BSWMG_00154] MoS Port Interface isService attribute dThe value of the
isService attribute of an interface is true by default. To set the attribute to false the
tagged value “bsw.isService” shall be used. The value of the tagged value shall be
“false”. c()
[TR_BSWMG_00103] MoS ClientServerInterface dThe operations defined
through a Client Server Interface shall be modeled as a class of stereotype
«ClientServerOperation» per operation (for each operation a separate class). c()
[TR_BSWMG_00104] MoS ClientServerInterface dThe relationship between
ClientServerInterface and ClientServerOperation shall be modeled as an aggregation
of stereotype «abswOperation» (target ClientServerOperation). c()
[TR_BSWMG_00105] MoS ClientServerOperation dEach class of stereotype
«ClientServerOperation» shall contain one operation with the same name as the class.
c()
[TR_BSWMG_00106] MoS ClientServerOperation dThe parameters of an operation
shall be modeled as parameters of the UML operation. «ClientServerOperation» Class
-> Operation -> Parameter c()
[TR_BSWMG_00107] MoS ClientServerOperation dThe parameter’s “Kind” attribute
shall be set to one of the values ‘in’, ‘out’, ‘inout’. c()
[TR_BSWMG_00108] MoS ClientServerInterface dFor each possible error a class
of stereotype «ApplicationError» shall be created. The name of the class shall be the
error abbreviation (e.g. E_FORCE_RCRRP). The error code shall be modeled as a
public attribute. The name shall be ErrorCode and the error code shall be modeled as
initial value. c()
[TR_BSWMG_00109] MoS ClientServerInterface dAll possible errors of a
Client Server Interface shall be referenced by an aggregation of stereotype
«abswPossibleError» (target ApplicationError). c()
[TR_BSWMG_00110] MoS ClientServerOperation dAll possible errors of a Client
Server Interface Operation shall be referenced by a dependency of stereotype
«abswPossibleErrorRef» (target ApplicationError). c()
[TR_BSWMG_00111] MoS ClientServerOperation dEach ClientServerOperation
shall have a relationship to the corresponding bsw api function. So the relationship
between ClientServerOperation and bsw api function (interface of the function) shall
be modeled as a dependency of stereotype «abswMapping» (target bsw api function).
c()
37 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.21: Example ClientServerInterface diagamm (CSI diagram)
[TR_BSWMG_00112] MoS ClientServerInterface dFor each Client Server Interface
a class diagram (CSI diagram) shall be created. The name of the diagramm shall be
the name of the Client Server Interface. c()
[TR_BSWMG_00113] MoS ClientServerInterface dA CSI diagram shall contain the
module, the ClientServerInterface, the Application Errors of the ClientServerInterface
and the ClientServerOperations of the ClientServerInterface. c()
38 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.22: Example ClientServerInterface errors diagram (CSI errors diagram)
[TR_BSWMG_00114] MoS ClientServerInterface dFor each Client Server Interface
a class diagram (CSI errors diagram) shall be created. The name of the diagram shall
be the name of the Client Server Interface concatenated with “_Error”. c()
[TR_BSWMG_00115] MoS ClientServerInterface dA CSI errors diagram shall con-
tain the Application Errors of the ClientServerInterface and the ClientServerOperations
of the ClientServerInterface. c()
Figure 2.23: Example ClientServerInterface BSW mapping diagamm (CSI bsw mapping
diagram)
[TR_BSWMG_00116] MoS ClientServerInterface dFor each Client Server Interface
a class diagram (CSI mapping diagram) shall be created. The name of the diagram
shall be the name of the Client Server Interface concatenated with “_BSWMapping”. c
()
[TR_BSWMG_00117] MoS ClientServerInterface dA CSI errors diagram shall con-
tain the ClientServerOperations of the ClientServerInterface and the corresponding
bsw api interfaces. c()
39 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.9.2 Modeling of Mode Switch Interfaces
The following listing shows the old syntax of modeling / defining ModeSwitchInterfaces
in AUTOSAR R4.0.3 SWS documents.
1ModeSwitchInterface WdgM_IndividualMode {
2isService = true;
3WdgMMode currentMode;
4};
Corresponding ModeDeclarationGroup:
1ModeDeclarationGroup WdgMMode {
2{ SUPERVISION_OK,
3SUPERVISION_FAILED,
4SUPERVISION_EXPIRED,
5SUPERVISION_STOPPED,
6SUPERVISION_DEACTIVATED
7}
8initialMode = SUPERVISION_OK
9};
Figure 2.24: Schematic overview of a Mode Switch Interfaces
[TR_BSWMG_00203] MoS ModeDeclarationGroup dFor each
ModeDeclarationGroup a class of stereotype «ModeDeclarationGroup» shall be
created. c()
[TR_BSWMG_00209] MoS ModeDeclarationGroup initialMode dThe initial mode
of the ModeDeclarationGroup shall be modeled as a public attribute of the
ModeDeclarationGroup class. The attribute’s name shall be “initialMode”, its initial
value shall be set to one of the ModeDeclarationGroup’s defined modes. c()
40 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00210] MoS ModeDeclarationGroup onTransitionValue dA
ModeDeclarationGroup’s optional “onTransitionValue" shall be modeled as a pub-
lic attribute of the ModeDeclarationGroup class. The attribute’s name shall be
“onTransitionValue”, its initial value shall be set to a positive integer. c()
[TR_BSWMG_00204] MoS ModeDeclarationGroup Mode declarations dThe
modes of a ModeDeclarationGroup (e.g. SUPERVISION_OK, SUPERVI-
SION_FAILED, ...) shall be modeled as a UML class of stereotype «ModeDeclaration».
Each mode shall be the name of a public attribute. c()
[TR_BSWMG_00211] MoS ModeDeclarationGroup Mode declaration integers dIt
is possible to assign concrete integer values to ModeDeclarations. In this case, the
mode attribute’s initial value shall be set to a positive integer. c()
[TR_BSWMG_00212] MoS ModeDeclarationGroup category dThe category of the
ModeDeclarationGroup shall be inferred from the existing information in the following
way:
•EXPLICIT_ORDER if all of its associated ModeDeclaration attributes have a nu-
merical value assigned to them.
•ALPHABETIC_ORDER otherwise.
c()
[TR_BSWMG_00205] MoS ModeSwitchInterface dThe relationship between
ModeDeclarationGroup and the enumeration of modes shall be modeled as aggre-
gation of stereotype «abswModeType» (target enumeration). c()
[TR_BSWMG_00206] MoS ModeSwitchInterface dThe ModeSwitchInterface class
shall be containing a public attribute with a reference name to the current
ModeDeclarationGroup (e.g. currentMode). The type of the attribute shall be the
ModeDeclarationGroup. c()
41 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.25: Example of a Mode Switch Interface
[TR_BSWMG_00207] MoS ClientServerInterface dFor each Mode Switch Interface
a class diagram shall be created. The name of the diagramm shall be the name of the
Mode Switch Interface. c()
[TR_BSWMG_00208] MoS ClientServerInterface dA Mode Switch Interface diagram
shall contain the module, the ModeSwitchInterface, the ModeDeclarationGroup and the
enumeration of the modes. c()
2.3.9.3 Modeling of Sender Receiver Interfaces
The following listing shows the old syntax of modeling / defining
SenderReceiverInterface in AUTOSAR R4.0.3 SWS documents.
1SenderReceiverInterface AppModeRequestInterface {
2isService = true;
3AppModeRequestType requestedMode;
4};
Corresponding Type:
1ImplementationDataType AppModeRequestType {
2lowerLimit = 0;
3upperLimit = 2;
42 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
4};
Figure 2.26: Schematic overview of a Sender Receiver Interfaces
[TR_BSWMG_00301] MoS SenderReceiverInterface dType of the sending/receiving
data shall be modeled as a bsw api type or as a MoS type, see chapter 2.3.8.c()
[TR_BSWMG_00302] MoS SenderReceiverInterface dThe SenderReceiverInterface
class shall contain a public attribute with a reference name to the current send-
ing/receiving Type (e.g. data). The type of the attribute shall be a valid type, see
TR_BSWMG_00301. c()
Figure 2.27: Example of a Sender Receiver Interface
[TR_BSWMG_00307] MoS SenderReceiverInterface dFor each Sender Receiver
Interface a class diagram shall be created. The name of the diagram shall be the
name of the Mode Switch Interface. c()
43 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_0308] MoS SenderReceiverInterface dA Sender Receiver Interface
diagram shall contain the module, the SenderReceiverInterface and the Type of the
sending/receiving data. c()
2.3.9.4 Modeling of special Types in Service Interfaces
The following listing shows examples of type definitions in the old syntax of modeling /
defining types in AUTOSAR R4.0.3 SWS documents.
Definition of arrays on arguments of ClientServerOperations:
1ClientServerInterface Dcm_RequestControlServices
2{
3PossibleErrors {
4E_NOT_OK = 1,
5};
6RequestControl(
7OUT uint8 OutBuffer[<DcmDspRequestControlOutBufferSize>],
8IN uint8 InBuffer[<DcmDspRequestControlInBufferSize>],
9ERR{E_NOT_OK });
10 }
Definition of pointer types:
1//The data type DataPtr refers to an address and is defined as follows:
2uint32*DataLengthPtr;
Definition of DataConstraints for simple types:
1ImplementationDataType Dem_DTCStatusMaskType {
2LOWER-LIMIT = 0;
3UPPER-LIMIT = 255;
4}
[TR_BSWMG_00400] Mos Types dValid stereotypes of types are «type», «array»,
«pointer», «structure» and «eumeration». c()
[TR_BSWMG_00401] MoS Simple Types dA simple type shall be modeled as de-
scribed in 2.3.8.1.c()
[TR_BSWMG_00403] MoS Array Types dAn array type shall be modeled as a class
of stereotype «array». To define the type of the array elements, a generalization rela-
tionship to the type shall be created. c()
[TR_BSWMG_00409] MoS Array Types dThe array size shall optionally be specified
using the tagged value “Vh.ArraySize". c()
[TR_BSWMG_00404] MoS Pointer Types dA pointer type shall be modeled as a class
of stereotype «pointer». To define the type of the referenced data, a generalization
relationship to the type shall be created. c()
[TR_BSWMG_00405] MoS Structure Types dA structure type shall be modeled as
described in 2.3.8.4.c()
44 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00407] MoS Enumeration Types dAn enumeration type shall be mod-
eled as described in 2.3.8.2.c()
Figure 2.28: Schematic overview of type definitions
2.3.9.5 Modeling of variability of service interfaces
Many service interfaces are configurable since they depend on the configuration of the
basis software. Therefore so called “blueprint conditions” have been introduced into
BSW model to express e.g. that the existence of ports depends on the existence of
specific EcuC parameters.
2.3.9.5.1 Examples of defining of variability in AUTOSAR R4.0.3 SWS docu-
ments
The following listing shows examples of the old syntax of modeling / defining of vari-
ability in AUTOSAR R4.0.3 SWS documents. The variability was defined informal as
comments.
45 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Variability in Ports:
1Service ComM
2{
3...
4// port present for each channel
5// if ComMModeLimitationEnabled (see ECUC_ComM_00560);
6// there are NC channels;
7ProvidePort ComM_ChannelLimitation CL000;
8...
9ProvidePort ComM_ChannelLimitation CL<NC-1>;
10 ...
11 }
Variability in provided client server operations:
1ClientServerInterface Dcm_SecurityAccess
2{
3...
4//Request to application for synchronous comparing key
5//(DcmDspSecurityUsePort = USE_SYNCH_CLIENT_SERVER)
6CompareKey(IN uint8 Key[<DcmDspSecurityKeySize>],
7ERR{E_NOT_OK, E_COMPARE_KEY_FAILED});
8
9//Request to application for asynchronous comparing key
10 //(DcmDspSecurityUsePort = USE_ASYNCH_CLIENT_SERVER)
11 CompareKey(IN uint8 Key[<DcmDspSecurityKeySize>],
12 IN Dcm_OpStatusType OpStatus,
13 ERR{E_NOT_OK, E_PENDING, E_COMPARE_KEY_FAILED});
14 }
Variability in provided client server operations parameters and types:
1// ProtInterface type and name
2ClientServerInterface Dcm_RoutineServices {
3...
4// <datatype> dataIn1,..., defines multiple parameters of
5// a parameterized type
6// uint8*dataInN for the last parameter is a concrete
7// type defined (not parameterized)
8
9StartFlex(
10 IN <datatype> dataIn1,..., IN uint8 dataInN[( <
DcmDspRoutineSignalLength of
DcmDspStartRoutineInSignal> +7)/8],
11 IN Dcm_OpStatusType OpStatus,
12 OUT <datatype> dataOut1,..., OUT uint8 dataOutN[( <
DcmDspRoutineSignalLength of
DcmDspStartRoutineOutSignal> +7)/8],
13 INOUT uint16 currentDataLength,
14 OUT Dcm_NegativeResponseCodeType ErrorCode,
15 ERR{E_NOT_OK, DCM_E_PENDING, E_FORCE_RCRRP });
16 ...
17 };
Variability in provided interface type:
46 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
1ClientServerInterface DataServices:
2
3Using the concepts of the SW-C template, the interface is defined as
follows if ClientServer interface is used (DcmDspDataUsePort set to
USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER):
1SenderReceiver DataServices:
2
3Using the concepts of the SW-C template, the interface is defined as
follows if SenderReceiver interface is used (DcmDspDataUsePort set
to USE_DATA_SENDER_RECEIVER):
2.3.9.5.2 Modeling of variability in BSW UML model
[TR_BSWMG_00500] MoS Variability NamePattern (number of occurrences)
dIf the number of occurrences of e.g. a port is depending on a the
occurrences of EcuC containers, the condition shall defined in tagged value
“Vh.NamePattern.BlueprintPolicy.DerivationGuide” and the Namepattern shall be de-
fined in tagged value “Vh.NamePattern”. c()
[TR_BSWMG_00501] MoS Variability (existence) dTo define variability of e.g. a port
the tagged value “Vh.BlueprintCondition” shall be used. c()
[TR_BSWMG_00502] MoS Variability multiple conditions dTo define multiple con-
ditions on e.g. a port, ’.’ + number shall be append to the tagged value name e.g.
“Vh.BlueprintCondition.1”. c()
Variability example of a port:
1Vh.BlueprintCondition:
2{ecuc(ComM/ComMGeneral.ComMModeLimitationEnabled)} == true
3Vh.NamePattern.BlueprintPolicy.DerivationGuide:
4Name = {ecuc(ComM/ComMConfigSet/ComMChannel)}
5Vh.NamePattern:
6CL_{Name}
[TR_BSWMG_00507] MoS port interface reference is configurable dIf the
reference to a port interface is configurable by EcuC the tagged value
“Vh.InterfaceRef.BlueprintPolicy.DerivationGuide” shall be used. c()
Configurable interface reference of a port (BswM modeNotificationPort):
1Vh.InterfaceRef.BlueprintPolicy.DerivationGuide:
2{ecuc(BswM/BswMConfig/BswMArbitration/BswMModeRequestPort/
BswMModeRequestSource/BswMSwcModeNotification.
BswMSwcModeNotificationModeDeclarationGroupPrototypeRef)}.
parent
[TR_BSWMG_00155] MoS Port Interface configurable isService attribute dIf the
value of the isService attribute depends on a EcuC parameter the tagged value
“Vh.isService.BlueprintPolicy.DerivationGuide” shall be used. The value of the tagged
value shall be set to the blueprint condition referencing the EcuC parameter. c()
47 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
2.3.9.6 Modeling of PortAPIOptions and PortDefinedArgumentValues
[TR_BSWMG_00118] MoS PortAPIOption dA PortAPIOption shall be modeled as an
UML class of stereotype «PortAPIOption». The class shall be placed in the package
<module>/ARInterfaces/<affected interfaces>. c()
[TR_BSWMG_00119] MoS PortAPIOption Name dThe name of the PortAPIOption
class shall be composed of the port name followed by underscore followed by literal
string “PortAPIOption”, e.g. “Func_PortAPIOption” for a port named “Func”. c()
[TR_BSWMG_00120] MoS PortAPIOption reference to Port dThe «PortAPIOp-
tion» class shall reference its affected port using a dependency with stereotype
«abswPortRef». c()
[TR_BSWMG_00121] MoS PortDefinedArgumentValue dPort Defined Argument
Values shall be modeled as attributes of a «PortAPIOption» class. c()
[TR_BSWMG_00122] MoS PortDefinedArgumentValue Stereotype dThe attribute
representing the Port Defined Argument Value shall have the stereotype «PDAV». c()
[TR_BSWMG_00123] MoS PortDefinedArgumentValue Order dIf a port uses more
than one Port Defined Argument Values, the attribute order within the «PortAPIOption»
class shall reflect the argument order in the BSW functions associated with the port’s
provided ClientServerInterface operations. c()
[TR_BSWMG_00124] MoS PortDefinedArgumentValue Name dThe Port Defined
Argument Value attribute’s ‘Name’ field shall match the corresponding BSW-functions’
parameter name. c()
[TR_BSWMG_00125] MoS PortDefinedArgumentValue fixed Type (non-
configurable) dIf the Port Defined Argument Value is of a fixed type, i.e. it is
not configurable by an EcuC parameter, the attribute’s ‘Type’ field shall reference a
valid type that is either modeled as a BSW API type or as an MoS type. c()
[TR_BSWMG_00126] MoS PortDefinedArgumentValue configurable Type dIf the
Port Defined Argument Value’s type is configurable by an EcuC parameter, the ‘Type’
field shall be set to the literal string {DataType}. The curly braces indicate that
“DataType” is treated as a place holder for the EcuC-configured type rather than a
valid data type itself. c()
[TR_BSWMG_00127] MoS PortDefinedArgumentValue Type Configuration by
EcuC dIf the Port Defined Argument Value’s type is configurable by an
EcuC parameter, the EcuC configuration dependency shall be expressed by a
tagged value attached to the attribute: Tag “TypeRef”, Value: “DataType =
{ecuc(some/ecuc/param/dataTypeRef)}” c()
[TR_BSWMG_00128] MoS PortDefinedArgumentValue Value Configuration by
EcuC dIf the Port Defined Argument Value’s “value” is configurable by an EcuC pa-
rameter, the EcuC configuration dependency shall be expressed by a tagged value
attached to the attribute: Tag: “Vh.Value.BlueprintPolicy.DerivationGuide”, Value:
“{ecuc(some/ecuc/param/value)}”. c()
48 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
Figure 2.29: PortAPIOption example for module Fim ClientServerInterface ControlFunc-
tionAvailable
2.4 Diagrams
2.4.1 Header File Modeling
[TR_BSWMG_00600] Header File Diagram dThe module package shall contain a
header file diagram (Enterprise Architect: UML Component Diagram). c()
[TR_BSWMG_00601] Naming of Header File Diagram dThe name of the header
file diagram shall be the name of the module component followed by _header, e.g.
FrTp_header.c()
[TR_BSWMG_00602] Header and Source Code Artifacts dDocument artifacts shall
be declared either as header or source file using the stereotypes «header» and
«source». c()
[TR_BSWMG_00603] Document Artifact Location dDocument artifacts shall be
placed in the module package of the defining BSW module. c()
49 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
[TR_BSWMG_00604] Include Dependency dDocument artifacts can include other
artifacts using a dependency with stereotype «include». With the additional stereotype
«optional», optional inclusion can be expressed. c()
[TR_BSWMG_00605] Optional Include Dependency dOptional inclusion can be ex-
pressed by specifying the additional stereotype «optional» on an include dependency.
c()
2.4.2 Sequence Diagrams
[TR_BSWMG_00901] Usage of Sequence Diagrams dFor modeling interactions of
different modules, sequence diagrams shall be used. c()
[TR_BSWMG_00902] Location of Sequence Diagrams dAll sequence diagrams
shall be placed within the “Interaction Views Package” package. c()
2.4.3 State Machine Diagrams
[TR_BSWMG_00801] Usage of State Machine Diagrams dFor modeling state de-
pendencies within and between elements, state machine diagrams shall be used. c
()
2.5 Support for Life Cycle concept in BSW Model
AUTOSAR introduced the possibility to attach life-cycle-related information to all
(Referable) specification elements with the Life Cycle Concept in R4.1.1. In a nut-
shell, a LifeCycleInfo element can be created for a specification element to document
its life cycle state - see [5], chapter 11.3.2.
[TR_BSWMG_00700] Model elements that support life cycle information dIn the
BSW model the following modeling elements shall be able to have life cycle information:
•Type definitions
•API Functions
•Services
c()
[TR_BSWMG_00701] LifeCycleInfo information in model elements dLife cycle in-
formation is represented by tagged values on the model element. c()
[TR_BSWMG_00702] Valid tagged values for life cycle information on model ele-
ments dThe following tagged values can be used to document life cycle information:
atp.Status A value from the official WP-M lifecycle definitions [6]
50 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide
Modeling Guidelines of Basic Software EA UML
Model
AUTOSAR CP Release 4.4.0
atp.StatusComment (optional) Explanatory comment
atp.StatusRevisionBegin Beginning of applicability of LifeCycleInfo
atp.StatusRevisionEnd (optional) End of applicability of LifeCycleInfo
atp.StatusUseInstead (optional) The element that replaces an “obsolete” or a “re-
moved” model element
c()
51 of 51
— AUTOSAR CONFIDENTIAL —
Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide

Navigation menu