Transcript
Page 1: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Document Title MethodologyDocument Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identification No 068

Document Classification Auxiliary

Document Status Final

Part of AUTOSAR Release 4.2.2

Document Change HistoryRelease Changed by Description

4.2.2AUTOSARReleaseManagement

• Minor corrections and editorial changes

4.2.1AUTOSARReleaseManagement

• Support for Safety Extensions added• Support for Diagnostic Extract added• Support for Rapid Prototyping added• Support for Sender Receiver Serialization added

4.1.3AUTOSARReleaseManagement

• Alignment of the AUTOSAR Methodology to theSystem Description categories• Editorial changes

4.1.2AUTOSARReleaseManagement

• Harmonization between ECU Configurationspecification and AUTOSAR Methodology

4.1.1 AUTOSARAdministration

• Allow the usage of requirement ID definition andtracing for specification items• Updated chapter 3.6 Ecu Integration and

Configuration with support for A2L function• Added chapter 2.14 How to resolve Name Conflicts• Added sections 3.4.1.15 Define Consistency Needs

and 3.4.2.17 Consistency Needs• Refine definition of Binding Times

1 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 2: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

4.0.3 AUTOSARAdministration

• Simplification of use case diagrams by removingtask use and introducing deliverables on use caseslevel (see Methodology Concept chapter)• Readability improvement by generation of tables

with navigable links• Introduction of Variant Handling, E2E support,

System Constraints Description• Refinement of Methodology Library, including the

extension of deliverables in different use cases

4.0.1 AUTOSARAdministration

• Changed tool platform for the SPEM model• Publish as pdf file instead of html• Used new table format for the model elements• Added SPEM diagrams• Methodology Concept chapter detailed• Memory Mapping use case added• Reworked and restructured use cases for more

readability• Direct references to meta-model elements in

figures and tables

3.1.1 AUTOSARAdministration

• Legal Disclaimer revised

3.0.1 AUTOSARAdministration

• Subchapter limitations of the current versionenhanced• Document meta information extended• Small layout adaptations made

2.1.15 AUTOSARAdministration

• Updated chapter 5 ECU-Design• Updated chapter 6.1 Relationship with Services• Legal disclaimer revised• Release Notes added• Advice for users revised• Revision Information added

2.0 AUTOSARAdministration • Initial release

2 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 3: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Disclaimer

This specification and the material contained in it, as released by AUTOSAR, is for thepurpose of information only. AUTOSAR and the companies that have contributed to itshall not be liable for any use of the specification.

The material contained in this specification is protected by copyright and other types ofIntellectual Property Rights. The commercial exploitation of the material contained inthis specification requires a license to such Intellectual Property Rights.

This specification may be utilized or reproduced without any modification, in any formor by any means, for informational purposes only. For any other purpose, no part ofthe specification may be utilized or reproduced, in any form or by any means, withoutpermission in writing from the publisher.

The AUTOSAR specifications have been developed for automotive applications only.They have neither been developed, nor tested for non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference models,"use cases", and/or references to exemplary technical solutions, devices, processes orsoftware).

Any such exemplary items are contained in the specifications for illustration purposesonly, and they themselves are not part of the AUTOSAR Standard. Neither their pres-ence in such specifications, nor any later documentation of AUTOSAR conformance ofproducts actually implementing such exemplary items, imply that intellectual propertyrights covering such exemplary items are licensed under the same rules as applicableto the AUTOSAR Standard.

3 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 4: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Table of Contents

1 Introduction 17

1.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.5 Methodology Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.5.1 Method Library (Method Content) . . . . . . . . . . . . . . . 191.5.1.1 Task Definition . . . . . . . . . . . . . . . . . . . . . 201.5.1.2 Work Product Definition . . . . . . . . . . . . . . . . 211.5.1.3 Role Definition . . . . . . . . . . . . . . . . . . . . . 231.5.1.4 Tool Definition . . . . . . . . . . . . . . . . . . . . . . 241.5.1.5 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 241.5.1.6 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.5.2 Capability Patterns (Use Case Elements) . . . . . . . . . . . 281.5.2.1 Activity . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.6 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 32

2 Use Cases 40

2.1 Overall View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.1.2.1 Views on the System . . . . . . . . . . . . . . . . . . 402.1.2.2 Overall Workflow . . . . . . . . . . . . . . . . . . . . 40

2.1.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2 Develop an Abstract System Description . . . . . . . . . . . . . . . . . 44

2.2.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.2.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.3 Develop a VFB System Description . . . . . . . . . . . . . . . . . . . . 472.3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.3.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.4 Develop Software Components . . . . . . . . . . . . . . . . . . . . . . 542.4.1 Develop an Atomic Software Component . . . . . . . . . . . 54

2.4.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 552.4.1.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 55

2.4.2 Develop Application Software . . . . . . . . . . . . . . . . . . 612.4.2.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 612.4.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 612.4.2.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 61

2.4.3 Uses Cases for more Specialized Software Components . . 622.4.3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 622.4.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 62

4 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 5: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.4.3.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 622.5 Develop System and Subsystems . . . . . . . . . . . . . . . . . . . . . 68

2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682.5.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 682.5.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 68

2.5.2 Design System . . . . . . . . . . . . . . . . . . . . . . . . . . 722.5.2.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 722.5.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 722.5.2.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 73

2.5.3 Generate System Extract . . . . . . . . . . . . . . . . . . . . 782.5.3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 782.5.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 782.5.3.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 78

2.5.4 Create ECU System Description . . . . . . . . . . . . . . . . 782.5.4.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 782.5.4.2 Description . . . . . . . . . . . . . . . . . . . . . . . 792.5.4.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 79

2.5.5 Design Sub-System . . . . . . . . . . . . . . . . . . . . . . . 802.5.5.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 802.5.5.2 Description . . . . . . . . . . . . . . . . . . . . . . . 802.5.5.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 82

2.5.6 Generate ECU Extract . . . . . . . . . . . . . . . . . . . . . . 822.5.6.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 822.5.6.2 Description . . . . . . . . . . . . . . . . . . . . . . . 832.5.6.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 83

2.5.7 Design Transformer . . . . . . . . . . . . . . . . . . . . . . . 842.5.7.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 842.5.7.2 Description . . . . . . . . . . . . . . . . . . . . . . . 842.5.7.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 85

2.5.8 Define System Safety Information . . . . . . . . . . . . . . . 862.5.8.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 862.5.8.2 Description . . . . . . . . . . . . . . . . . . . . . . . 862.5.8.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 87

2.6 Develop Basic Software . . . . . . . . . . . . . . . . . . . . . . . . . . 882.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

2.6.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 882.6.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 882.6.1.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 88

2.6.2 Design BSW . . . . . . . . . . . . . . . . . . . . . . . . . . . 892.6.2.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 892.6.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 892.6.2.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 90

2.6.3 Develop BSW Module . . . . . . . . . . . . . . . . . . . . . . 922.6.3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 922.6.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 922.6.3.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 93

5 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 6: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7 Integrate Software for ECU . . . . . . . . . . . . . . . . . . . . . . . . 952.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952.7.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

2.7.2.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 962.7.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 962.7.2.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 99

2.7.3 Prepare ECU Configuration . . . . . . . . . . . . . . . . . . . 1002.7.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 1002.7.3.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 101

2.7.4 Configure BSW and RTE . . . . . . . . . . . . . . . . . . . . 1022.7.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 1022.7.4.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 103

2.7.5 Update ECU Configuration . . . . . . . . . . . . . . . . . . . 1042.7.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . 1042.7.5.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 105

2.7.6 Model ECU Timing . . . . . . . . . . . . . . . . . . . . . . . . 1062.7.6.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 106

2.7.7 Generate BSW and RTE . . . . . . . . . . . . . . . . . . . . 1062.7.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . 1062.7.7.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 107

2.7.8 Build Executable . . . . . . . . . . . . . . . . . . . . . . . . . 1102.7.8.1 Description . . . . . . . . . . . . . . . . . . . . . . . 1102.7.8.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . 111

2.7.9 Configuration Classes . . . . . . . . . . . . . . . . . . . . . . 1122.7.9.1 Configuration Class: Pre-compile Time . . . . . . . . 1132.7.9.2 Configuration Class: Link Time . . . . . . . . . . . . 1172.7.9.3 Configuration Class: Post-build Time . . . . . . . . . 1192.7.9.4 Handling of different post-build variants in configura-

tion classes . . . . . . . . . . . . . . . . . . . . . . . 1232.8 Components and Services . . . . . . . . . . . . . . . . . . . . . . . . . 124

2.8.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242.8.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242.8.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

2.9 Calibration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302.9.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302.9.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302.9.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

2.10 Memory Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352.10.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352.10.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362.10.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

2.11 E2E Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402.11.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402.11.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402.11.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

2.12 Diagnostic Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 7: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.12.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412.12.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412.12.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

2.13 Rapid Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492.13.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492.13.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492.13.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

2.14 Safety Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532.14.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532.14.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532.14.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

2.15 Variant Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572.15.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572.15.2 Binding Times . . . . . . . . . . . . . . . . . . . . . . . . . . 157

2.15.2.1 Latest Binding Time . . . . . . . . . . . . . . . . . . 1582.15.2.2 Actual Binding Time . . . . . . . . . . . . . . . . . . 158

2.15.3 Defining Variants . . . . . . . . . . . . . . . . . . . . . . . . . 1592.15.4 Choosing Variants . . . . . . . . . . . . . . . . . . . . . . . . 159

2.16 Definition of Binding Times . . . . . . . . . . . . . . . . . . . . . . . . . 1602.16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602.16.2 A Classification of Artifacts with respect to Binding Times . . 1632.16.3 Classification of Binding Times . . . . . . . . . . . . . . . . . 163

2.16.3.1 BlueprintDerivationTime . . . . . . . . . . . . 1642.16.3.2 FunctionDesignTime . . . . . . . . . . . . . . . . 1642.16.3.3 InitialBindingTime . . . . . . . . . . . . . . . . 1652.16.3.4 SystemDesignTime . . . . . . . . . . . . . . . . . 1652.16.3.5 CodeGenerationTime . . . . . . . . . . . . . . . . 1652.16.3.6 PreCompileTime . . . . . . . . . . . . . . . . . . . 1662.16.3.7 CompileTime . . . . . . . . . . . . . . . . . . . . . 1662.16.3.8 LinkTime . . . . . . . . . . . . . . . . . . . . . . . . 1662.16.3.9 PostBuild . . . . . . . . . . . . . . . . . . . . . . . 1672.16.3.10 Runtime . . . . . . . . . . . . . . . . . . . . . . . . 167

2.17 How to resolve Name Conflicts . . . . . . . . . . . . . . . . . . . . . . 1672.17.1 Reasons for Name Conflicts . . . . . . . . . . . . . . . . . . 1672.17.2 Points in the Methodology where Name Conflicts are resolved 1682.17.3 Mechanisms for resolving Name Conflicts . . . . . . . . . . . 169

3 Methodology Library 172

3.1 Common Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723.1.1 Work Product Kinds . . . . . . . . . . . . . . . . . . . . . . . 1723.1.2 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

3.1.2.1 Add General Documentation . . . . . . . . . . . . . 1743.1.2.2 Define Admin Data . . . . . . . . . . . . . . . . . . . 1743.1.2.3 Define Alias Names . . . . . . . . . . . . . . . . . . 1753.1.2.4 Evaluate Variant . . . . . . . . . . . . . . . . . . . . 1773.1.2.5 Define Memory Addressing Modes . . . . . . . . . . 178

7 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 8: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.6 Configure Memmap Allocation . . . . . . . . . . . . 1793.1.2.7 Generate BSW Memory Mapping Header . . . . . . 1813.1.2.8 Generate SWC Memory Mapping Header . . . . . . 1843.1.2.9 Configure Compiler Memory Classes . . . . . . . . . 1863.1.2.10 Generate Compiler Configuration . . . . . . . . . . . 188

3.1.3 Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . 1893.1.3.1 General Documentation . . . . . . . . . . . . . . . . 1893.1.3.2 Alias Name Set . . . . . . . . . . . . . . . . . . . . . 1903.1.3.3 Evaluated Variant Set . . . . . . . . . . . . . . . . . 1903.1.3.4 General Autosar Artifact . . . . . . . . . . . . . . . . 1923.1.3.5 General Deliverable . . . . . . . . . . . . . . . . . . 1933.1.3.6 General Non-Autosar Artifact . . . . . . . . . . . . . 1933.1.3.7 Postbuild Variant Set . . . . . . . . . . . . . . . . . . 1943.1.3.8 Predefined Variant . . . . . . . . . . . . . . . . . . . 1953.1.3.9 Standard Header Files . . . . . . . . . . . . . . . . . 1963.1.3.10 System Constant Value Set . . . . . . . . . . . . . . 198

3.1.4 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1993.1.5 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

3.1.5.1 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . 2093.1.5.2 Linker . . . . . . . . . . . . . . . . . . . . . . . . . . 210

3.1.6 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2103.1.6.1 Work Products . . . . . . . . . . . . . . . . . . . . . 210

3.1.7 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2123.1.7.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 2123.1.7.2 Work Products . . . . . . . . . . . . . . . . . . . . . 221

3.2 Virtual Functional Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243.2.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

3.2.1.1 Define VFB Top Level . . . . . . . . . . . . . . . . . 2253.2.1.2 Define VFB Composition Component . . . . . . . . . 2263.2.1.3 Extend Composition . . . . . . . . . . . . . . . . . . 2273.2.1.4 Define VFB Component Constraints . . . . . . . . . 2293.2.1.5 Define VFB Application Software Component . . . . 2303.2.1.6 Define VFB Sensor or Actuator Component . . . . . 2313.2.1.7 Define VFB Parameter Component . . . . . . . . . . 2323.2.1.8 Define ECU Abstraction Component . . . . . . . . . 2333.2.1.9 Define Complex Driver Component . . . . . . . . . . 2343.2.1.10 Define VFB NvBlock Software Component . . . . . . 2353.2.1.11 Define Wrapper Components to Integrate Legacy

Software . . . . . . . . . . . . . . . . . . . . . . . . . 2363.2.1.12 Define VFB Interfaces . . . . . . . . . . . . . . . . . 2373.2.1.13 Define VFB Types . . . . . . . . . . . . . . . . . . . 2383.2.1.14 Define VFB Modes . . . . . . . . . . . . . . . . . . . 2393.2.1.15 Define VFB Constants . . . . . . . . . . . . . . . . . 2403.2.1.16 Define VFB Timing . . . . . . . . . . . . . . . . . . . 2413.2.1.17 Define VFB Variants . . . . . . . . . . . . . . . . . . 2423.2.1.18 Define VFB Integration Connector . . . . . . . . . . 243

8 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 9: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.19 Translate Non-AUTOSAR Description to AUTOSARDescription . . . . . . . . . . . . . . . . . . . . . . . 245

3.2.2 Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . 2463.2.2.1 VFB System . . . . . . . . . . . . . . . . . . . . . . . 2463.2.2.2 Overall VFB System . . . . . . . . . . . . . . . . . . 2493.2.2.3 VFB System Extract . . . . . . . . . . . . . . . . . . 2503.2.2.4 VFB Top Level System Composition . . . . . . . . . 2513.2.2.5 VFB Composition Component . . . . . . . . . . . . . 2513.2.2.6 VFB AUTOSAR Standard Package . . . . . . . . . . 2533.2.2.7 AUTOSAR Specification of Application Interfaces . . 2553.2.2.8 VFB Atomic Software Component . . . . . . . . . . 2563.2.2.9 VFB Atomic Application Software Component . . . . 2583.2.2.10 Complex Driver Component . . . . . . . . . . . . . . 2583.2.2.11 ECU Abstraction Software Component . . . . . . . . 2593.2.2.12 VFB Parameter Component . . . . . . . . . . . . . . 2593.2.2.13 VFB Sensor Actuator Component . . . . . . . . . . . 2603.2.2.14 VFB NvBlock Software Component . . . . . . . . . . 2613.2.2.15 VFB Non AUTOSAR Component . . . . . . . . . . . 2623.2.2.16 VFB Interfaces . . . . . . . . . . . . . . . . . . . . . 2623.2.2.17 VFB Types . . . . . . . . . . . . . . . . . . . . . . . 2643.2.2.18 VFB Data Type Mapping Set . . . . . . . . . . . . . 2663.2.2.19 VFB Modes . . . . . . . . . . . . . . . . . . . . . . . 2673.2.2.20 VFB Constants . . . . . . . . . . . . . . . . . . . . . 2683.2.2.21 VFB Software Component Mapping Constraints . . . 2683.2.2.22 VFB Timing . . . . . . . . . . . . . . . . . . . . . . . 2693.2.2.23 Description of a Non-AUTOSAR System . . . . . . . 2693.2.2.24 Integration Connector . . . . . . . . . . . . . . . . . 270

3.3 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2713.3.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

3.3.1.1 Set System Root . . . . . . . . . . . . . . . . . . . . 2723.3.1.2 Assign Top Level Composition . . . . . . . . . . . . . 2733.3.1.3 Define ECU Description . . . . . . . . . . . . . . . . 2743.3.1.4 Define System Topology . . . . . . . . . . . . . . . . 2753.3.1.5 Define Software Component Mapping Constraints . 2753.3.1.6 Deploy Software Component . . . . . . . . . . . . . 2773.3.1.7 Generate or Adjust System Flat Map . . . . . . . . . 2783.3.1.8 Derive Communication Needs . . . . . . . . . . . . . 2793.3.1.9 Define Signal Path Constraints . . . . . . . . . . . . 2803.3.1.10 Define System Variants . . . . . . . . . . . . . . . . 2813.3.1.11 Define System Timing . . . . . . . . . . . . . . . . . 2833.3.1.12 Extend Topology . . . . . . . . . . . . . . . . . . . . 2843.3.1.13 Select Software Component Implementation . . . . . 2853.3.1.14 Select Design Time Variant . . . . . . . . . . . . . . 2863.3.1.15 Define System View Mapping . . . . . . . . . . . . . 2873.3.1.16 Create Transformer Specification . . . . . . . . . . . 2883.3.1.17 Define Rapid Prototyping Scenario . . . . . . . . . . 289

9 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 10: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.2 Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . 2903.3.2.1 System Description . . . . . . . . . . . . . . . . . . . 2903.3.2.2 Abstract System Description . . . . . . . . . . . . . . 2943.3.2.3 Complete ECU Description . . . . . . . . . . . . . . 2963.3.2.4 System Description Root Element . . . . . . . . . . 2963.3.2.5 System Mapping Overview . . . . . . . . . . . . . . 2973.3.2.6 Software Component Mapping Contraints . . . . . . 2983.3.2.7 Data Mapping . . . . . . . . . . . . . . . . . . . . . . 3003.3.2.8 Mapping of Software Components to ECUs . . . . . 3003.3.2.9 Mapping of Software Components to Implementations 3013.3.2.10 Signal Path Constraints . . . . . . . . . . . . . . . . 3013.3.2.11 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 3023.3.2.12 Ecu Resources Description . . . . . . . . . . . . . . 3033.3.2.13 System Signal . . . . . . . . . . . . . . . . . . . . . 3043.3.2.14 System Signal Group . . . . . . . . . . . . . . . . . . 3053.3.2.15 System Flat Map . . . . . . . . . . . . . . . . . . . . 3063.3.2.16 System Timing . . . . . . . . . . . . . . . . . . . . . 3073.3.2.17 System View Mapping . . . . . . . . . . . . . . . . . 3083.3.2.18 Transformer Design Bundle . . . . . . . . . . . . . . 3093.3.2.19 Transformer Specification . . . . . . . . . . . . . . . 3093.3.2.20 Rapid Prototyping Scenario . . . . . . . . . . . . . . 310

3.3.3 Communication Matrix and Communication Layers . . . . . . 3103.3.3.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 3113.3.3.2 Work Products . . . . . . . . . . . . . . . . . . . . . 320

3.3.4 ECU Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . 3253.3.4.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 3253.3.4.2 Work Products . . . . . . . . . . . . . . . . . . . . . 333

3.4 Software Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3403.4.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

3.4.1.1 Define Software Component Internal Behavior . . . 3413.4.1.2 Define Partial Flat Map . . . . . . . . . . . . . . . . . 3423.4.1.3 Define Software Component Timing . . . . . . . . . 3433.4.1.4 Define SymbolProps for Types . . . . . . . . . . . . 3443.4.1.5 Add Documentation to the Software Component . . 3453.4.1.6 Generate Atomic Software Component Contract

Header Files . . . . . . . . . . . . . . . . . . . . . . 3463.4.1.7 Generate Component Header File in Vendor Mode . 3483.4.1.8 Generate Component Prebuild Data Set . . . . . . . 3503.4.1.9 Implement Atomic Software Component . . . . . . . 3513.4.1.10 Compile Atomic Software Component . . . . . . . . 3533.4.1.11 Map Software Component to BSW . . . . . . . . . . 3543.4.1.12 Measure Component Resources . . . . . . . . . . . 3563.4.1.13 Recompile Component in ECU Context . . . . . . . 3573.4.1.14 Define Consistency Needs . . . . . . . . . . . . . . . 3583.4.1.15 Generate Rapid Prototyping Wrapper . . . . . . . . 359

3.4.2 Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . 361

10 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 11: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.2.1 Delivered Atomic Software Components . . . . . . . 3613.4.2.2 Software Component Internal Behavior . . . . . . . . 3643.4.2.3 Atomic Software Component Implementation . . . . 3653.4.2.4 Software Component Documentation . . . . . . . . . 3673.4.2.5 Software Component Timing . . . . . . . . . . . . . 3683.4.2.6 Software Component to BSW Mapping . . . . . . . . 3683.4.2.7 Partial Flat Map . . . . . . . . . . . . . . . . . . . . . 3693.4.2.8 Application Header File . . . . . . . . . . . . . . . . 3713.4.2.9 Software Component Data Types Header . . . . . . 3713.4.2.10 Component RTE Prebuild Configuration Header . . . 3723.4.2.11 Atomic Software Component Source Code . . . . . 3723.4.2.12 Atomic Software Component Object Code . . . . . . 3733.4.2.13 Optimized Application Header File . . . . . . . . . . 3733.4.2.14 Optimized Software Component Object Code . . . . 3743.4.2.15 Consistency Needs . . . . . . . . . . . . . . . . . . . 3743.4.2.16 Rapid Prototyping Wrapper Header File . . . . . . . 3753.4.2.17 Rapid Prototyping Wrapper Source Code . . . . . . 376

3.4.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3763.4.3.1 Component API Generator Tool . . . . . . . . . . . . 376

3.5 Basic Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3773.5.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

3.5.1.1 Define BSW Types . . . . . . . . . . . . . . . . . . . 3783.5.1.2 Define BSW Entries . . . . . . . . . . . . . . . . . . 3793.5.1.3 Define BSW Interfaces . . . . . . . . . . . . . . . . . 3803.5.1.4 Define Vendor Specific Module Definition . . . . . . 3813.5.1.5 Define BSW Behavior . . . . . . . . . . . . . . . . . 3823.5.1.6 Define BSW Module Timing . . . . . . . . . . . . . . 3833.5.1.7 Generate BSW Contract Header Files . . . . . . . . 3843.5.1.8 Implement a BSW Module . . . . . . . . . . . . . . . 3853.5.1.9 Develop BSW Module Generator . . . . . . . . . . . 3873.5.1.10 Create Library . . . . . . . . . . . . . . . . . . . . . . 3883.5.1.11 Compile BSW Core Code . . . . . . . . . . . . . . . 3893.5.1.12 Generate BSW Module Prebuild Dataset . . . . . . . 391

3.5.2 Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . 3923.5.2.1 BSW Standard Package . . . . . . . . . . . . . . . . 3923.5.2.2 BSW Module Bundle . . . . . . . . . . . . . . . . . . 3943.5.2.3 BSW Design Bundle . . . . . . . . . . . . . . . . . . 3953.5.2.4 BSW Module ICS Bundle . . . . . . . . . . . . . . . 3963.5.2.5 BSW Module Delivered Bundle . . . . . . . . . . . . 3973.5.2.6 AUTOSAR Software Module Specification . . . . . . 3993.5.2.7 AUTOSAR Standard Types . . . . . . . . . . . . . . 4003.5.2.8 AUTOSAR Platform Types . . . . . . . . . . . . . . . 4003.5.2.9 BSW Module Generator . . . . . . . . . . . . . . . . 4013.5.2.10 AUTOSAR Standardized ECU Configuration Param-

eter Definition . . . . . . . . . . . . . . . . . . . . . . 4013.5.2.11 BSW Module Preconfigured Configuration . . . . . . 402

11 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 12: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.2.12 BSW Module Recommended Configuration . . . . . 4033.5.2.13 BSW Module Vendor Specific Configuration Param-

eter Definition . . . . . . . . . . . . . . . . . . . . . . 4043.5.2.14 BSW Types . . . . . . . . . . . . . . . . . . . . . . . 4053.5.2.15 Basic Software Entries . . . . . . . . . . . . . . . . . 4053.5.2.16 Basic Software Module Description . . . . . . . . . . 4053.5.2.17 Basic Software Module Internal Behavior . . . . . . 4063.5.2.18 Basic Software Module Implementation Description . 4073.5.2.19 Build Action Manifest . . . . . . . . . . . . . . . . . . 4083.5.2.20 Basic Software Module Timing . . . . . . . . . . . . 4093.5.2.21 Basic Software Module Core Header . . . . . . . . . 4103.5.2.22 Basic Software Module Core Source Code . . . . . . 4103.5.2.23 Basic Software Interlink Header . . . . . . . . . . . . 4113.5.2.24 Basic Software Interlink Types Header . . . . . . . . 4123.5.2.25 BSW RTE Prebuild Configuration Header . . . . . . 4123.5.2.26 Basic Software Module Object Code . . . . . . . . . 4133.5.2.27 Library Description . . . . . . . . . . . . . . . . . . . 4133.5.2.28 Library Header Files . . . . . . . . . . . . . . . . . . 4143.5.2.29 Library Object Code . . . . . . . . . . . . . . . . . . 415

3.6 ECU Integration and Configuration . . . . . . . . . . . . . . . . . . . . 4153.6.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

3.6.1.1 Provide RTE Calibration Dataset . . . . . . . . . . . 4153.6.1.2 Define Integration Variant . . . . . . . . . . . . . . . 4163.6.1.3 Generate Base ECU Configuration . . . . . . . . . . 4183.6.1.4 Generate Updated ECU Configuration . . . . . . . . 4193.6.1.5 Define ECU Timing . . . . . . . . . . . . . . . . . . . 4203.6.1.6 Configure EcuC . . . . . . . . . . . . . . . . . . . . . 4213.6.1.7 Configure OS . . . . . . . . . . . . . . . . . . . . . . 4233.6.1.8 Configure RTE . . . . . . . . . . . . . . . . . . . . . 4253.6.1.9 Configure Watchdog Manager . . . . . . . . . . . . . 4273.6.1.10 Configure Mode Management . . . . . . . . . . . . . 4283.6.1.11 Configure NvM . . . . . . . . . . . . . . . . . . . . . 4293.6.1.12 Configure Diagnostics . . . . . . . . . . . . . . . . . 4313.6.1.13 Create Service Component . . . . . . . . . . . . . . 4323.6.1.14 Connect Service Component . . . . . . . . . . . . . 4363.6.1.15 Configure COM . . . . . . . . . . . . . . . . . . . . . 4373.6.1.16 Configure IO Hardware Abstraction . . . . . . . . . . 4393.6.1.17 Configure MCAL . . . . . . . . . . . . . . . . . . . . 4403.6.1.18 Configure Debug . . . . . . . . . . . . . . . . . . . . 4413.6.1.19 Configure Transformer . . . . . . . . . . . . . . . . . 4443.6.1.20 Generate BSW Configuration Code and Model Ex-

tensions . . . . . . . . . . . . . . . . . . . . . . . . . 4453.6.1.21 Generate Local MC Data Support . . . . . . . . . . . 4473.6.1.22 Create MC Function Model . . . . . . . . . . . . . . 4483.6.1.23 Generate RTE . . . . . . . . . . . . . . . . . . . . . 4503.6.1.24 Generate Scheduler . . . . . . . . . . . . . . . . . . 453

12 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 13: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.6.1.25 Generate OS . . . . . . . . . . . . . . . . . . . . . . 4543.6.1.26 Generate RTE Prebuild Dataset . . . . . . . . . . . . 4553.6.1.27 Compile ECU Source Code . . . . . . . . . . . . . . 4563.6.1.28 Generate ECU Executable . . . . . . . . . . . . . . . 4583.6.1.29 Generate RTE Postbuild Dataset . . . . . . . . . . . 4603.6.1.30 Generate A2L . . . . . . . . . . . . . . . . . . . . . . 4613.6.1.31 Measure Resources . . . . . . . . . . . . . . . . . . 4633.6.1.32 Refine Rapid Prototyping Scenario . . . . . . . . . . 464

3.6.2 Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . 4653.6.2.1 BSW Module Integration Bundle . . . . . . . . . . . 4653.6.2.2 ECU Software Delivered . . . . . . . . . . . . . . . . 4663.6.2.3 Service Component Description . . . . . . . . . . . . 4673.6.2.4 ECU Service Connectors . . . . . . . . . . . . . . . 4683.6.2.5 ECU Timing . . . . . . . . . . . . . . . . . . . . . . . 4683.6.2.6 BSW Module Interface Extension . . . . . . . . . . . 4693.6.2.7 BSW Module Behavior Extension . . . . . . . . . . . 4693.6.2.8 BSW Module Implementation Extension . . . . . . . 4703.6.2.9 ECU Configuration Values . . . . . . . . . . . . . . . 4703.6.2.10 RTE Implementation Description . . . . . . . . . . . 4733.6.2.11 RTE Prebuild Configuration Header . . . . . . . . . . 4743.6.2.12 Calibration Parameter Value Set . . . . . . . . . . . 4743.6.2.13 MC Function Model . . . . . . . . . . . . . . . . . . . 4753.6.2.14 Local Measurement and Calibration Support Data . 4763.6.2.15 RTE Measurement and Calibration Support Data . . 4773.6.2.16 RTE Source Code . . . . . . . . . . . . . . . . . . . 4793.6.2.17 BSW Scheduler Code . . . . . . . . . . . . . . . . . 4793.6.2.18 OS Generated Code . . . . . . . . . . . . . . . . . . 4803.6.2.19 RTE Postbuild Variants Dataset . . . . . . . . . . . . 4803.6.2.20 ECU Object Code . . . . . . . . . . . . . . . . . . . 4803.6.2.21 ECU Executable . . . . . . . . . . . . . . . . . . . . 4813.6.2.22 Map of the ECU Executable . . . . . . . . . . . . . . 4813.6.2.23 A2L File . . . . . . . . . . . . . . . . . . . . . . . . . 4823.6.2.24 MC Driver Support Data . . . . . . . . . . . . . . . . 4823.6.2.25 MC Additional Config . . . . . . . . . . . . . . . . . . 483

3.6.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4833.6.3.1 RTE Generator . . . . . . . . . . . . . . . . . . . . . 4833.6.3.2 BSW Generator Framework . . . . . . . . . . . . . . 484

3.6.4 ECU Config Classes . . . . . . . . . . . . . . . . . . . . . . . 4843.6.4.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 4843.6.4.2 Work Products . . . . . . . . . . . . . . . . . . . . . 494

A History of Constraints and Specification Items 498

A.1 Constraint History of this Document according to AUTOSAR R4.1.1 . . 498A.1.1 Added Specification Items in R4.1.1 . . . . . . . . . . . . . . 498

A.2 Constraint History of this Document according to AUTOSAR R4.1.2 . . 501A.2.1 Added Specification Items in R4.1.2 . . . . . . . . . . . . . . 501

13 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 14: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

A.3 Constraint History of this Document according to AUTOSAR R4.1.3 . . 501A.3.1 Added Specification Items in R4.1.3 . . . . . . . . . . . . . . 501A.3.2 Changed Specification Items in R4.1.3 . . . . . . . . . . . . 501

A.4 Constraint History of this Document according to AUTOSAR R4.2.1 . . 502A.4.1 Added Specification Items in R4.2.1 . . . . . . . . . . . . . . 502A.4.2 Changed Specification Items in R4.2.1 . . . . . . . . . . . . 502A.4.3 Deleted Specification Items in R4.2.1 . . . . . . . . . . . . . 503

A.5 Constraint History of this Document according to AUTOSAR R4.2.2 . . 503

14 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 15: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Bibliography

[1] Requirements on MethodologyAUTOSAR_RS_Methodology

[2] Software Process Engineering Meta-Model Specificationhttp://www.omg.org/spec/SPEM/2.0/

[3] Integration of Franca IDL Software Component DescriptionsAUTOSAR_TR_FrancaIntegration

[4] Virtual Functional BusAUTOSAR_EXP_VFB

[5] Software Component TemplateAUTOSAR_TPS_SoftwareComponentTemplate

[6] General Specification of Basic Software ModulesAUTOSAR_SWS_BSWGeneral

[7] General Specification on TransformersAUTOSAR_ASWS_TransformerGeneral

[8] Basic Software Module Description TemplateAUTOSAR_TPS_BSWModuleDescriptionTemplate

[9] System TemplateAUTOSAR_TPS_SystemTemplate

[10] Specification of ECU ConfigurationAUTOSAR_TPS_ECUConfiguration

[11] Specification of Memory MappingAUTOSAR_SWS_MemoryMapping

[12] Specification of Compiler AbstractionAUTOSAR_SWS_CompilerAbstraction

[13] Specification of Module E2E TransformerAUTOSAR_SWS_E2ETransformer

[14] Diagnostic Extract TemplateAUTOSAR_TPS_DiagnosticExtractTemplate

[15] Specification of RTE SoftwareAUTOSAR_SWS_RTE

[16] Specifications of Safety ExtensionsAUTOSAR_TPS_SafetyExtensions

[17] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First editionhttp://www.iso.org

15 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 16: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[18] Generic Structure TemplateAUTOSAR_TPS_GenericStructureTemplate

[19] Standardization TemplateAUTOSAR_TPS_StandardizationTemplate

[20] Specification of ECU Resource TemplateAUTOSAR_TPS_ECUResourceTemplate

16 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 17: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

1 Introduction

1.1 Objective

AUTOSAR requires a common technical approach for some steps of system develop-ment. This approach is called the AUTOSAR methodology. This document definesand describes this AUTOSAR methodology. It covers all major steps of the develop-ment of a system with AUTOSAR: from the definition of the Virtual FunctionalBus to the generation of an ECU executable.

The requirements for the methodology are defined in the document [1].

1.2 Overview

[TR_METH_01000] Domains of the AUTOSAR methodology d The AUTOSARmethodology is structured into several domains of development:

• Virtual Functional Bus

• System

• Software Component

• Basic Software

• ECU

c(RS_METH_00018, RS_METH_00032)

[TR_METH_01001] AUTOSAR methodology assets d For each domain, rele-vant Work Product, Task, Role, and Tool elements are defined (see chap-ter 3). In addition, there are elements that are common for all domains (see 3.1).c(RS_METH_00025, RS_METH_00028, RS_METH_00009)

[TR_METH_01002] AUTOSAR methodology use cases d Use cases (see chapter 2)show how these standard reusable elements are applied to support real-world devel-opment. The Overall View (see chapter 2.1) provides an end to end view on the typicaluse cases of all domains. c(RS_METH_00018, RS_METH_00056, RS_METH_00009)

1.3 Known Limitations

Work products and tasks for End to End communication safety are not completelydescribed in the methodology.

17 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 18: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

1.4 Scope

[TR_METH_01003] Scope of the AUTOSAR methodology d The AUTOSAR method-ology is not a complete process description, but rather aggregates the various elementsof AUTOSAR and shows how they are brought together to develop a complete system.Sample aggregations are provided as Use Cases in Chapter 2. c(RS_METH_00006)

[TR_METH_01004] Support for various stakeholders by the AUTOSAR method-ology d The structure of the methodology was designed to help cover the needs ofvarious AUTOSAR stakeholders:

• Organizations: Methodology is modeled in a modular format to allow organiza-tions to tailor it and combine the Methodology within their own internal processes,while identifying points where they interact with other organizations.

• Engineers: Methodology is scoped to allow engineers of various roles quickly findAUTOSAR information that is relevant to their specific needs.

• Tool Vendors: Methodology provides a common language to share among allAUTOSAR members and a common expectation of what capabilities tools shouldsupport.

c(RS_METH_00018, RS_METH_00056, RS_METH_00009)

[TR_METH_01005] Restrictions of AUTOSAR methodology d Furthermore, themethodology does not prescribe a precise order in which activities should be carriedout. The methodology is a mere work-product flow: it defines the dependencies ofactivities on work-products. This means that when the information specified in themethodology is available, an activity can be carried out to produce the output work-products. The set of activities is described in Chapter 3.

This restriction implies that the AUTOSAR methodology does not define an overall time-line and does not define how and when iterations are carried out. For example duringsystem and design, the same activity (namely configuring the system) will be carriedout repeatedly with various levels of precision. There will be a first ”rough” configurationand a final ”precise” configuration which might depend on the feedback from the actualconfiguration or even implementation of ECUs. How and when such refinement stepsare to be carried out is NOT defined in the methodology. c(RS_METH_00047)

1.5 Methodology Concepts

[TR_METH_01006] General AUTOSAR methodology concepts d The AUTOSARmethodology defines activities performed by roles that create work products as gen-eral reusable method patterns1. The reusable method pattern elements are describedin the method library section (cf. Section 1.5.1). The methodology also describes

1The RS_Methodology document uses the term “Activity” when addressing process elements in gen-eral. In the SPEM model the atomic process elements are called “Tasks”, whereas an “Activity” is usedto organize tasks and to define processes.

18 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 19: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

sample process patterns of typical use cases considered for the creation of AUTOSARwork products. The patterns use process elements that are described in the use casesection (cf. Section 1.5.2).

The definitions and the figures are made according to the Software Process Engi-neering Meta-Model Specification [2]. The symbols are taken from the EnterpriseArchitect modeling tool. c(RS_METH_00018, RS_METH_00021, RS_METH_00047,RS_METH_00048, RS_METH_00025, RS_METH_00061, RS_METH_00028,RS_METH_00056)

1.5.1 Method Library (Method Content)

[TR_METH_01007] Method Library d The Method Library defines theMethod Library Elements of every method pattern such as Roles, Tasks,and Work Product Definitions. c(RS_METH_00018, RS_METH_00021,RS_METH_00025, RS_METH_00028)

[TR_METH_01008] Method Library Element d A Method Library Elementcontains a description of the element to define its purpose in the methodology and thusprovides the basic contents of the AUTOSAR methodology. The Method LibraryElements are used for the description of the related development processes. TheseMethod Library Elements can been seen as a standard. c(RS_METH_00017,RS_METH_00043, RS_METH_00050, RS_METH_00064)

[TR_METH_01009] Relation of Method Library and Method Library Ele-ment to the SPEM meta model d The Method Library and the Method LibraryElements correspond to the Method Content and Method Content Elementsin the SPEM meta model [2]. c(RS_METH_00009)

[TR_METH_01010] Overview of Method Library Elements d Method LibraryElements comprise:

• Task Definition (section 1.5.1.1)

• Work Product Definition (section 1.5.1.2)

• Role Definition (section 1.5.1.3)

• Tool Definition (section 1.5.1.4)

• Guidance (section 1.5.1.5)2

c(RS_METH_00021, RS_METH_00025, RS_METH_00027, RS_METH_00042,RS_METH_00028)

The element symbols are shown in Figure 1.1.2The Guidance is currently not used in the AUTOSAR Methodology. It may be used in future docu-

ments.

19 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 20: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Role Definition

Tool Definition

Task Definition

Work Product Definition (Artifact)

Deliverable1 Guidance

Figure 1.1: Symbols of AUTOSAR Method Content Elements

1.5.1.1 Task Definition

[TR_METH_01011] Task Definition d According to the SPEM meta model, aTask Definition is an assignable unit of work that is being performed by specificRoles. The duration of a task is generally a few hours to a few days. Tasks usuallygenerate one or more work products. Each Task is associated to input and outputWork Products. Inputs are differentiated in mandatory and optional inputs. A Taskis used as one element among others to define a Process. c(RS_METH_00021)

[TR_METH_01012] Task semantics d A Task has a clear purpose in which the per-forming roles achieve a well defined goal. It provides complete step-by-step explana-tions of doing all the work that needs to be done to achieve this goal. This descriptionis completely independent of when in a process lifecycle the work would actually bedone. It does not describe when what work is being done, but describes all the workthat gets done. c(RS_METH_00021, RS_METH_00056)

[TR_METH_01013] Task usage dWhen a Task is used in a process (cf. Task Use),it provides the information of which pieces of the Task will actually be performed at anyparticular point in time. This assumes that the Task will be performed in the processover and over again, but each time with a slightly different emphasis on different stepsor aspects of the task description [2].

For the AUTOSAR Methodology, a Task is a reusable element that is used acrossmultiple methodology use cases. A Task is associated to at least one performingRole and may have several additional performers. Tasks use Tools to achieve theiroutputs. Optional performers and optional input and outputs to the task are describedby the relationship’s multiplicity. c(RS_METH_00021, RS_METH_00042)

20 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 21: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

An overview of the Task as it is used in this document is given in Figure 1.2.

Task DefinitionWork Product 2

Role Definition

Tool Definition

Work Product 1

0..* «input»

«used tool» «performs»

«output»0..*

Figure 1.2: Task Definition Overview

1.5.1.2 Work Product Definition

[TR_METH_01014] Work Product Definition d According to the SPEM metamodel, a Work Product Definition is used, modified, and produced by Tasks(i.e. a task input and output). Work Products are in most cases tangible work prod-ucts consumed, produced, or modified by Tasks. They may serve as a basis for defin-ing reusable assets. A Work Product can be related to other work products by a kindof nesting relationship. c(RS_METH_00046, RS_METH_00047, RS_METH_00025,RS_METH_00052, RS_METH_00061, RS_METH_00054)

[TR_METH_01015] Relationship between Roles and Work Products d Rolesuse Work Products to perform Tasks and produce Work Products in the courseof performing the Tasks. Work Products are in the responsibility of the associatedRoles, thereby also defining a set of skills the performing Role should have. Eventhough one Role might own a specific type of Work Product, other Roles can stilluse the Work Product for their work, and update them [2]. c(RS_METH_00052,RS_METH_00061)

A Work Product can be of type Artifact or Deliverable:

• [TR_METH_01017] Artifact Definition d Artifact: A tangible Work Prod-uct that is consumed, produced, or modified by one or more Tasks. Artifactsmay be composed of other Artifacts and may serve as a basis for definingreusable assets [2]. c(RS_METH_00052, RS_METH_00061, RS_METH_00054)

[TR_METH_01018] Kinds of Artifacts d For the AUTOSAR Methodology, typ-ical kinds of artifacts are:

– AUTOSAR XML

– Source Code

21 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 22: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

– Object Code

– Executable

– Text

For more details see chapter 3.1.1. c(RS_METH_00063, RS_METH_00015,RS_METH_00057)

[TR_METH_01019] Properties of Artifacts d At a high level, an artifact is rep-resented as a single conceptual file. As a rule of thumb, the AUTOSAR Method-ology will distinguish artifacts that have most of the following properties:

– Separate versioning is needed

– A dedicated life cycle has to be cared for

– Different exchange requirements need to be fulfilled

– Change in responsible roles

– Change in multiplicities

– Change in physical representation or format

– One of the products may be a separate deliverable to another party

– Separation of standardized from non-standardized parts

c(RS_METH_00063, RS_METH_00017, RS_METH_00016)

[TR_METH_01020] Relationship between Artifacts and meta-model ele-ments d To express a relationship between artifacts of the methodology modeland any AUTOSAR meta-model element, a relationship with the stereotype «at-pUseMetaModelElement» is used to express this ”dependency”. For AUTOSARmeta-model elements that are not directly related to methodology elements,there is usually an indirect relationship via a related meta-model element.The methodology can thus focus on the main elements of the meta-model.c(RS_METH_00051)

• [TR_METH_01021] Deliverable Definition d Deliverable: Used to pre-define typical or recommended content in the form of Work Products thatwould be packaged for delivery. Deliverables are used to represent an outputfrom a process that has value, material or otherwise, to a client, customer, orother stakeholder. c(RS_METH_00025, RS_METH_00018, RS_METH_00054)

[TR_METH_01022] Aggregation of Work Products d A Deliverable is aWork Product that aggregates other Work Products. The Method Con-tent maintains pre-configured potential Deliverables [2]. For the AUTOSARMethodology, the aggregation relationship is used to indicate which Work Prod-ucts are contained in a deliverable. c(RS_METH_00025, RS_METH_00018,RS_METH_00054)

22 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 23: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Work Product Definition

Deliverable2Artifact

PackageableElement

ARPackage::ARElement

«AtpUseMetaModelElement»

0..*

«SPEM_Aggregation»

Figure 1.3: Work Product Definition Overview

1.5.1.3 Role Definition

[TR_METH_01023] Role Definition d According to the SPEM meta model, RoleDefinitions define responsibilities of an individual or a set of individuals and therebydefine a set of related skills, competencies, and qualifications needed to perform aTask. A Role can be filled by one person or multiple people, one person may fillseveral Roles. Each Role performs Tasks. c(RS_METH_00028)

[TR_METH_01024] Role assignment d Roles are not individuals or resources. In-dividual members of the development organization will wear different hats, or performdifferent Roles. The mapping from individual to Role, usually performed by the projectmanager when planning and staffing a project, allows different individuals to act as sev-eral different Roles, and for a Role to be taken by several individuals [2].

In the AUTOSAR Methodology, a Role also assigns the responsibility of a Taskand defines optional performers. Performers that are responsible for e.g. a Taskhave a multiplicity of 1 for the relationship to the Task, optional performers have op-tional multiplicity assigned. Role Definitions are usually generic and still providesufficient level of detail for managers to organize a team. Examples of Roles are”System Engineer”, ”Safety Engineer”, or ”Software Developer”. c(RS_METH_00028,RS_METH_00056)

23 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 24: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

RoleDefinition

Task Definition

RoleDefinition (optional performer) «performs»

0..*

«performs»

1

Figure 1.4: Role Definition Overview

1.5.1.4 Tool Definition

[TR_METH_01025] Tool Definition d According to the SPEM meta model, ToolDefinitions can be used to specify a tool’s participation in a Task. A Tool Defi-nition describes the capabilities of a CASE tool, general purpose tool, or any otherautomation unit that supports the associated Roles in performing the work defined bya Task. A Tool can identify a resource as useful, recommended, or necessary for atask’s completion. A Tool can also be used to manage one or more Work Products[2].

The AUTOSAR Methodology uses the Tool Definition to describe AUTOSAR spe-cific (e.g. Software Component Contract Generator) and other general Tools (e.g.Compilers). The relationship of a Tool to a Task shows which Tools a Role willneed to perform the Task. c(RS_METH_00066, RS_METH_00042)

Tool Definition

Task Definition «used tool»

Figure 1.5: Tool Definition Overview

1.5.1.5 Guidance

[TR_METH_01026] Guidance definition d According to the SPEM meta model, aGuidance provides additional information related to e.g. Roles, Work Products,and Tasks. A Guidance is classified to indicate a specific type for which perhaps aspecific structure and type of content is assumed [2]. c(RS_METH_00027)

24 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 25: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01027] Guidance kinds d A Guidance can be a

• Supporting Material: Supporting Material is a catch-all for other typesof guidance not specifically defined elsewhere. It can be related to all kindsof Content Elements, i.e., including other guidance elements. The AUTOSARMethodology uses the Supporting Material Guidance type to define titlepages, change histories, disclaimers etc.

• Tool Mentor: A Tool Mentor shows how to use a specific Tool to accom-plish some piece of work either in the context of or independent from a Task orActivity. In the context of the AUTOSAR Methodology, a Tool Mentor isused in the same way as the Tool element.

• White Paper: White Papers are concept guidances that have been exter-nally reviewed or published and can be read and understood in isolation fromother Method Content. AUTOSAR documents are examples of White Pa-pers.

Other Guidances such as Checklists, Concepts, Estimates, Guidelines, Practices,Reports, Reusable Assets, Roadmaps, or Templates as defined in [2] are not usedwithin the AUTOSAR Methodology. c(RS_METH_00027)

Guidance (Supporting Material,Tool Mentor, White Paper)

Role Definition

Task Definition

Work Product Definition

«refersTo»

«refersTo»

«refersTo»

Figure 1.6: Guidance Overview

1.5.1.6 Tables

[TR_METH_01028] Usage of tables d Beside the graphical visualization of the differ-ent SPEM diagrams, tables are used to specify and describe the model elements indetail. c(RS_METH_00050, RS_METH_00064)

[TR_METH_01113] Usage of hyperlinks d Beside the conventional references tochapters, figures and sections the AUTOSAR methodology document utilizes hyper-links to the used SPEM elements. These hyperlinks are used across the text andwithin the tables. Using the hyperlinks the reader can quickly navigate to the re-lated elements such as Tasks, Activities, Roles, Work Products and Tools.c(RS_METH_00067)

In the Methodology library the following tables are used :

25 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 26: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

1.5.1.6.1 Work Product Kind Tables

Category(Work Product Kind)

Work Product Kind

Package Location in the MetaModel packageBrief Description Short DescriptionDescription Detailed Description

Table 1.1: Work Product Kind

1.5.1.6.2 Task Definition Tables

Task Definition TaskPackage Location in the MetaModel packageBrief Description Short descriptionDescription Detailed descriptionRelation Type Related Element Mul. NotePerformed by Which Roles Per-

form the TaskOptornot

Description of the specific role needed

Consumes What is Consumedby the Task

Mult Explanation on why this Element isneeded.

Produces What is producedby the Task

Mult Explanation on why this Element isneeded.

In/out What is producedand consumed bythe Task

Mult Explanation on why this Element isneeded.

Used tool Tool used for thatTask

Mult

Table 1.2: Task

1.5.1.6.3 Work Product Definition Tables

Artifact Work ProductPackage Location in the MetaModel packageBrief Description Short Description.Description Detailed DescriptionKind Work Product KindExtended by Artifacts which extend this ArtifactExtends Artifacts which are extended by this ArtifactRelation Type Related Element Mul. NoteAggregated by To which Deliver-

able is it aggre-gated By

Mult Description of the context of theAggregation.

26 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 27: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteIn/out Which task is pro-

ducing and con-suming the WorkProduct

Mult Description of the context of the WorkProduct production and consumption.

Produced by Which task is pro-ducing the WorkProduct

Mult Description of the context of the WorkProduct production.

Consumed by Which task is con-suming the WorkProduct

Mult Description of the context of the WorkProduct consumption.

Use meta model element MetamodelElementRelationship

Mult

Table 1.3: Work Product

1.5.1.6.4 Deliverable Definition Tables

It is the same structure of table as the Work Product, only the Aggregation is not thesame as it can aggregate other Work Products or Deliverables.

Deliverable DeliverablePackage Location in the MetaModel packageBrief Description Short Description.Description Detailed DescriptionKind Work Product KindExtended by Deliverables which extend this DeliverableExtends Deliverables which are extended by this DeliverableRelation Type Related Element Mul. NoteAggregates Which Work

Products areaggregated to it

Mult

Aggregated by To which Deliver-able is it aggre-gated By

Mult Description of the context of theAggregation.

In/out Which task is pro-ducing and con-suming the Deliv-erable

Mult Description of the Context of productionand consumption.

Produced by Which task is pro-ducing the Deliver-able

Mult Description of the context of theproduction.

Consumed by Which task is con-suming the Deliv-erable

Mult Description of the context of theconsumption.

Use meta model element MetamodelElementRelationship

Mult

Table 1.4: Deliverable

27 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 28: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

1.5.1.6.5 Roles Definition Tables

Role RolePackage Meta-model Package NameBrief Description Short Description.Description Detailed Description.Relation Type Related Element Mul. NotePerforms In which task the

performer is actingMult

Table 1.5: Role

1.5.1.6.6 Tools Tables

Tool ToolPackage Meta-model Package nameBrief Description Short DescriptionDescription Detailed DescriptionKindRelation Type Related Element Mul. NoteUsed Task where the tool

is usedMult

Table 1.6: Tool

1.5.2 Capability Patterns (Use Case Elements)

The method content (cf. Section 1.5.1) is referenced in section 2.1.2 to describe so-called Capability Patterns.

[TR_METH_01029] Capability Patterns definition d A CapabilityPattern3 is a process pattern that contains a reusable set of activities.c(RS_METH_00018)

[TR_METH_01030] Composition of Capability Patterns d Capability Pat-terns can be assembled to larger Capability Patterns that describe devel-opment processes or parts of a development process including typical use cases.c(RS_METH_00018, RS_METH_00056)

[TR_METH_01031] Adaptability of the AUTOSAR methodology d The main focus ofthis section is merely to provide a use case process flow that can be supported by anAUTOSAR tool chain rather than to define a complete process description. One reasonfor doing this is that the AUTOSAR methodology should be adaptable to developmentprocesses of different organizations. c(RS_METH_00056)

[TR_METH_01032] Use case elements d This section describes the use case ele-ments. The SPEM meta model defines the Role Use , the Work Product Use and

3In Enterprise Architect a SPEM “Capability Pattern” is called “Process Pattern”.

28 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 29: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

the Task Use elements in addition. Whereas these are important elements whenapplying SPEM in an organization, the AUTOSAR methodology does not necessar-ily need these elements since no instantiation of the Enterprise Architect model isintended. The elements are thus not used to enhance readability and ease the de-scription. Instead, Roles, Work Products, Deliverables and Tasks are useddirectly to describe the details of an Activity.

The element symbols are shown in Figure 1.7. c()

Capabil i ty PatternActivity1

Figure 1.7: Symbols of AUTOSAR Use Case Process Elements

1.5.2.1 Activity

[TR_METH_01033] Definition of Activities d In the SPEM meta model, an Ac-tivity is the main building block to define a process. An Activity is usuallya defined task or work to be done that is commonly executed in one sequence.c(RS_METH_00021)

[TR_METH_01034] Composition of Activities d Activities can include otherActivities and thereby often decompose a flow of work and show which Activityprecedes other Activities [2]. At the lowest level, Activities are collectionsof work breakdown elements which in AUTOSAR methodology are Tasks , Roles, and Work Products. c(RS_METH_00048, RS_METH_00046, RS_METH_00047,RS_METH_00066)

[TR_METH_01035] Definition of Processes d A Process is a special Activityin the SPEM meta model that describes a typical structure of development projectsor parts of them. A Process focuses on the lifecycle and the sequencing of work inbreakdown structures. Processes contain sequences of Task and Activities andthereby express a lifecycle of the product under development. Processes also definehow to get from one milestone to the next by defining sequences of work, operations,or events [2]. c(RS_METH_00056)

For the AUTOSAR Methodology, the main Use Cases are described with 3 types ofdiagrams.

[TR_METH_01036] Description of overall Use Cases d In the first diagram,the Capability Patterns, Activities and Deliverables are used to de-scribe the overall Use Case, sequence of Activities and their main out-

29 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 30: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

puts(Deliverables). In these diagrams, the predecessor relationship can be skippedand Deliverables can be extended by other Deliverables (see Figure 1.8). c()

Activity 1 Activity 2

Capabil ity Pattern

Deliverable1Deliverable2

Deliverable3

«output»

«nesting»

«input»

«extends»

«nesting»

Figure 1.8: Activity Overview

The diagram is followed by its corresponding table as detailed hereunder:

Process Pattern Capability PatternPackage Meta-model Package nameBrief Description Short DescriptionDescription Detailed Description.Relation Type Related Element Mul. NoteAggregates Activity nested to

the Capability Pat-tern or to anotherActivity

Mult Context explanation

Consumes Deliverable con-sumed by theActivity

Mult Why this Activity needs to consume thisDeliverable

Produces Deliverable pro-duced by theActivity

Mult Why this Activity is producing thisDeliverable

Table 1.7: Capability Pattern

30 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 31: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01037] Precise description of Use Cases d The second type of dia-gram are Activities and Task Definition diagrams which precise the mainTasks and Work Products used for the Use Cases but are not as detailed as inthe Methodology Library (see Figure 1.9). The task usage in these diagrams will beexpressed by the role and in the note at the aggregation. This information will be alsovisible in the generated table. The Work Products consumed or produced in the usecases will be not integrated in the table for readability. c()

Activity 1

TaskDefinition1

Task Definition

Work Product

Work Product 1

«extends»

«output»1

+The task usage can beexpressed by the roleand the note of theaggregation

«nesting»

+The task usage can beexpressed by the role andthe note of theaggregation

«nesting»

1

«input»

Figure 1.9: Activity and Tasks Overview

The diagram is followed by its corresponding table as detailed hereunder:

Activity ActivityPackage Meta-model Package NameBrief Description Short DescriptionDescription Detailed DescriptionExtended by Activities which extend this ActivityExtends Activities which are extended by this ActivityRelation Type Related Element Mul. NoteAggregates Nested task defini-

tionMult Task usage description if needed

Consumes What is Consumedby the Activity

Mult Explanation on why this Element isneeded.

Produces What is producedby the Activity

Mult Explanation on why this Element isneeded.

In/out What is producedand consumed bythe Activity

Mult Explanation on why this Element isneeded.

Predecessor Predecessor of theActivity

Mult Explanation on why the Predecessor isneeded.

Table 1.8: Activity

31 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 32: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01038] Detailed description of the work flow d The third type of diagramcontains the Tasks and Work Products used by an Activity in order to show thedetailed work flow but not the structure of Activities as seen in Section 1.5.1.1. Asan example take Figure 2.9. The table generation is not done for this type of diagram.c()

1.6 Requirements Traceability

This section states the response of this specification to the corresponding requirementsdocument[1].

Requirement Description Satisfied by[RS_METH_00002] Methodology shall explain the

typical usage of SW-C template[TR_METH_01044][TR_METH_01047][TR_METH_01048][TR_METH_01050][TR_METH_01051][TR_METH_01052][TR_METH_01053][TR_METH_01054][TR_METH_01055][TR_METH_01056][TR_METH_01057][TR_METH_01058][TR_METH_01059][TR_METH_01060][TR_METH_01061][TR_METH_01065][TR_METH_01066][TR_METH_01067][TR_METH_01068][TR_METH_01071][TR_METH_01075][TR_METH_01076][TR_METH_01077][TR_METH_01078]

32 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 33: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01079][TR_METH_01080][TR_METH_01081][TR_METH_01082][TR_METH_01087][TR_METH_01088][TR_METH_01090][TR_METH_01091][TR_METH_01110][TR_METH_01112][TR_METH_01125][TR_METH_01126][TR_METH_01127][TR_METH_01132][TR_METH_01133][TR_METH_02000][TR_METH_02001][TR_METH_02002][TR_METH_02005][TR_METH_03000][TR_METH_03005][TR_METH_03006][TR_METH_03007]

[RS_METH_00003] Methodology shall explain thetypical usage of BSW ModuleTemplate

[TR_METH_01083][TR_METH_01084][TR_METH_01085][TR_METH_01087][TR_METH_01088][TR_METH_01089][TR_METH_01090][TR_METH_01091][TR_METH_01092][TR_METH_01111][TR_METH_01112][TR_METH_01114][TR_METH_01115][TR_METH_01117][TR_METH_02002][TR_METH_02005][TR_METH_03000][TR_METH_03010]

33 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 34: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[RS_METH_00004] Methodology shall explain thetypical usage of the ECUConfiguration template

[TR_METH_01083][TR_METH_01086][TR_METH_01087][TR_METH_01088][TR_METH_01089][TR_METH_01090][TR_METH_01091][TR_METH_01092][TR_METH_01095][TR_METH_01098][TR_METH_01103][TR_METH_01104][TR_METH_01112][TR_METH_01114][TR_METH_01115][TR_METH_01116][TR_METH_01117][TR_METH_01151][TR_METH_02005][TR_METH_03000]

[RS_METH_00005] Methodology shall explain thetypical usage of the SystemTemplate

[TR_METH_01046][TR_METH_01047][TR_METH_01048][TR_METH_01053][TR_METH_01065][TR_METH_01066][TR_METH_01067][TR_METH_01068][TR_METH_01070][TR_METH_01071][TR_METH_01075][TR_METH_01076][TR_METH_01077][TR_METH_01078][TR_METH_01079][TR_METH_01080][TR_METH_01081][TR_METH_01082][TR_METH_01087][TR_METH_01088][TR_METH_01090][TR_METH_01091][TR_METH_01092][TR_METH_01109]

34 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 35: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01112][TR_METH_01114][TR_METH_01125][TR_METH_01126][TR_METH_01127][TR_METH_01130][TR_METH_01153][TR_METH_01154][TR_METH_02003][TR_METH_02006][TR_METH_02015][TR_METH_02016][TR_METH_02017][TR_METH_02018][TR_METH_03000][TR_METH_03008]

[RS_METH_00006] Methodology shall explain howAutosar system is built

[TR_METH_01003][TR_METH_01039][TR_METH_01044][TR_METH_01045][TR_METH_01046][TR_METH_01047][TR_METH_01048][TR_METH_01049][TR_METH_01061][TR_METH_01085][TR_METH_01087][TR_METH_01092][TR_METH_01093][TR_METH_01109][TR_METH_01110][TR_METH_01111][TR_METH_01112][TR_METH_01114][TR_METH_01134][TR_METH_01135][TR_METH_03002][TR_METH_03003][TR_METH_03004]

[RS_METH_00009] Methodology should be modeled [TR_METH_01001][TR_METH_01002][TR_METH_01004][TR_METH_01009]

[RS_METH_00010] Methodology should define rulesto translate methodology modelinto a document

[TR_METH_01121]

[RS_METH_00015] Methodology shall beindependent of programminglanguage

[TR_METH_01018]

[RS_METH_00016] Methodology shall supportbuilding a system of bothAutosar and Non-Autosar ECUs

[TR_METH_01019][TR_METH_01128][TR_METH_01129]

[RS_METH_00017] Methodology shall clearly definewhat is standardized and what isnot standardized

[TR_METH_01008][TR_METH_01019]

35 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 36: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[RS_METH_00018] Methodology shall be modular [TR_METH_01000][TR_METH_01002][TR_METH_01004][TR_METH_01006][TR_METH_01007][TR_METH_01021][TR_METH_01022][TR_METH_01029][TR_METH_01030][TR_METH_01084][TR_METH_01110]

[RS_METH_00020] Methodology shall supportiterations

[TR_METH_01071][TR_METH_01089][TR_METH_02004]

[RS_METH_00021] Methodology shall defineActivities

[TR_METH_01006][TR_METH_01007][TR_METH_01010][TR_METH_01011][TR_METH_01012][TR_METH_01013][TR_METH_01033]

[RS_METH_00025] Methodology shall define Workproducts

[TR_METH_01001][TR_METH_01006][TR_METH_01007][TR_METH_01010][TR_METH_01014][TR_METH_01021][TR_METH_01022]

[RS_METH_00027] Methodology shall defineunambiguous guidanceterminology

[TR_METH_01010][TR_METH_01026][TR_METH_01027]

[RS_METH_00028] Methodology shall define Roles [TR_METH_01001][TR_METH_01006][TR_METH_01007][TR_METH_01010][TR_METH_01023][TR_METH_01024]

[RS_METH_00032] The methodology shall respectthe different levels ofAbstractions

[TR_METH_01000][TR_METH_01040]

[RS_METH_00033] Methodology should supportVFB concept

[TR_METH_01039][TR_METH_01045][TR_METH_01054][TR_METH_02000]

[RS_METH_00038] Methodology shall support the Cprogramming language

[TR_METH_01060][TR_METH_01085][TR_METH_01093][TR_METH_02005][TR_METH_03001]

[RS_METH_00041] Methodology shall supportBottom/Up Approach

[TR_METH_01071]

36 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 37: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[RS_METH_00042] Methodology shall incorporatethe usage of industry standardtools

[TR_METH_01010][TR_METH_01013][TR_METH_01025][TR_METH_01093]

[RS_METH_00043] Activities shall have a purpose [TR_METH_01008][RS_METH_00046] Activities shall have input work

products[TR_METH_01014][TR_METH_01034]

[RS_METH_00047] Activities shall have output workproducts

[TR_METH_01005][TR_METH_01006][TR_METH_01014][TR_METH_01034]

[RS_METH_00048] Activities shall include roles [TR_METH_01006][TR_METH_01034]

[RS_METH_00050] Work products shall have adescription

[TR_METH_01008][TR_METH_01028]

[RS_METH_00051] Work products shall have areference(s) to metaclass(es) inthe Autosar Metamodel.

[TR_METH_01020]

[RS_METH_00052] It must be possible to avoidduplication of data in WorkProducts

[TR_METH_01014][TR_METH_01015][TR_METH_01017]

[RS_METH_00054] Work Products shall not havecircular references with otherwork products

[TR_METH_01014][TR_METH_01017][TR_METH_01021][TR_METH_01022][TR_METH_01122]

[RS_METH_00056] AUTOSAR methodology shallnot be bound to a particularlifecycle model

[TR_METH_01002][TR_METH_01004][TR_METH_01006][TR_METH_01012][TR_METH_01024][TR_METH_01030][TR_METH_01031][TR_METH_01035]

[RS_METH_00057] AUTOSAR methodology shallsupport traceability to externalartifacts

[TR_METH_01018][TR_METH_01123]

[RS_METH_00061] Methodology shall describe thechange of existing workproducts.

[TR_METH_01006][TR_METH_01014][TR_METH_01015][TR_METH_01017]

[RS_METH_00062] Methodology shall supportconfiguration of parameters withdifferent binding time.

[TR_METH_01086][TR_METH_01095][TR_METH_01098][TR_METH_01104][TR_METH_01108][TR_METH_01150][TR_METH_01151]

[RS_METH_00063] Work Products shall be capableto be version controlled

[TR_METH_01018][TR_METH_01019]

[RS_METH_00064] Roles shall have a description [TR_METH_01008][TR_METH_01028]

[RS_METH_00066] Activities shall include tools [TR_METH_01025][TR_METH_01034]

37 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 38: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[RS_METH_00067] Methodology document shallinclude hyperlinks betweenActivities, Roles, Work Products,and Guidance.

[TR_METH_01113]

[RS_METH_00069] It shall be possible to addprecise and human readabledocumentation to each workproduct.

[TR_METH_01123][TR_METH_01124]

[RS_METH_00074] Methodology shall specifyBinding times

[TR_METH_00001][TR_METH_00002][TR_METH_00003][TR_METH_02011][TR_METH_02012][TR_METH_02013][TR_METH_02014][TR_METH_02020]

[RS_METH_00075] Methodology shall specify thetasks of resolving variant

[TR_METH_00001][TR_METH_02016]

[RS_METH_00076] Methodology shall specify awork product for values ofvariant selectors

[TR_METH_02016][TR_METH_02017]

[RS_METH_00077] Methodology shall explain thetypical interaction betweenOEMs and suppliers

[TR_METH_01049][TR_METH_01076][TR_METH_01079][TR_METH_01080][TR_METH_01081][TR_METH_01082][TR_METH_01125][TR_METH_01126][TR_METH_01127][TR_METH_01130][TR_METH_01131]

[RS_METH_00078] Methodology shall explain thetypical usage of different viewson the system of the OEM

[TR_METH_01044][TR_METH_01050][TR_METH_01068]

[RS_METH_00079] Methodology shall explain thetypical usage of different viewson the system of the Supplier

[TR_METH_01068][TR_METH_01079][TR_METH_01080][TR_METH_01081][TR_METH_01082]

[RS_METH_00080] Exchange of ImplicitCommunication BehaviorDescription

[TR_METH_01120]

[RS_METH_00081] Methodology shall explain thetypical usage of SafetyExtensions

[TR_METH_01144][TR_METH_01145][TR_METH_01146][TR_METH_01147][TR_METH_01148][TR_METH_01149]

38 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 39: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[RS_METH_00082] Methodology shall explain thetypical usage of DiagnosticExtract Template

[TR_METH_01136][TR_METH_01137][TR_METH_01138][TR_METH_01139][TR_METH_01140][TR_METH_01141][TR_METH_01142][TR_METH_01143]

Some input requirements cannot (or not completely) be traced down to single specifi-cation items found in this document. They are satisfied by the AUTOSAR methodologyin a general way together with other documents as listed in the following:

[TR_METH_01120] Definition of Consistency Needs d The AUTOSAR methodol-ogy supports the exchange of implicit communication behavior description. Chapters3.4.1.14 and 3.4.2.15 depict the task and the artifact which allow to define the corre-sponding consistency needs. c(RS_METH_00080)

[TR_METH_01121] Building the AUTOSAR methodology document d AllAUTOSAR methodology related model elements (see 1.5) are consumed by an in-ternal AUTOSAR tool that automatically produces the corresponding text, tables, anddiagrams. These artifacts are included into a document which is automatically trans-formed into the final PDF file. c(RS_METH_00010)

[TR_METH_01122] Relations between AUTOSAR Work Products d Work Prod-ucts (Deliverables and Artifacts) are designed in such a way that no circularreferences with other Work Products exist. c(RS_METH_00054)

[TR_METH_01123] Traceability to external artifacts d Artifacts considered in theMethodology model include external artifacts like c-code, libraries, documentation andgenerated artifacts (see e.g. 3.5.2.22, 3.4.2.4). General Non Autosar Artifactis a generic representation of non AUTOSAR artifacts. It is aggregated by the GeneralDeliverable and allows linking and tracing of non AUTOSAR artifacts within theAUTOSAR context. Furthermore, several specific artifacts represent non AUTOSARelements or allow referring to them. The A2L File artifact is a representation ofthe measurement and calibration format that is defined by the ASAM and thereforeout of scope of AUTOSAR. The description of the Atomic Software ComponentImplementation artifact explains how external artifacts can be referred from thisARXML artifact. c(RS_METH_00057, RS_METH_00069)

[TR_METH_01124] Documentation of Work Products d In order to document de-sign decisions or restrictions during the development process each Work Prod-uct can aggregate the corresponding documentation which is represented by theGeneral Documentation artifact. The General Documentation artifact isadded to Work Products by processing the task Add General Documentation.c(RS_METH_00069)

39 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 40: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2 Use Cases

2.1 Overall View

2.1.1 Purpose

This pattern provides a rough outline of the design steps to build a system and resultantof this the ECUs and the topology with the AUTOSAR methodology. The main activitiesare depicted in Figure 2.1.

2.1.2 Description

2.1.2.1 Views on the System

[TR_METH_01039] AUTOSAR System development overview d The development ofan AUTOSAR System is based on the definition of the Virtual Functional Bus(VFB). The VFB is the communication mechanism that allows a composition of inter-connected software components to interact. Based on the VFB the system is designed.c(RS_METH_00006, RS_METH_00033)

[TR_METH_01040] Support of different system views d During the overall develop-ment of the system, different views on the system can exist (e.g. functional architecture,or software architecture). These views are described explicitely, whereas a mappingmechanism is used to express the relation between them. c(RS_METH_00032)

In the following three different views on the system are distinguished:

• [TR_METH_01041] Abstract system d The abstract system abstracts from theconcrete software architecture and describes e.g. the functional view on the sys-tem. c()

• [TR_METH_01042] Overall technical system d The overall technical system isorganized from the software architecture perspective. c()

• [TR_METH_01043] Sub-System d The Sub-System is a reduced part of theoverall technical System and describes relevant aspects for a dedicated subsys-tem. c()

2.1.2.2 Overall Workflow

[TR_METH_01044] Development of a functional view on the system d The overallworkflow (see Figure 2.2) starts with an optional activity. In this activity, the AbstractSystem Description is developed in advance, which represents the overall systemfrom a functional or abstract view (functional architecture). This Abstract System

40 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 41: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Description is then the basis for the development of the concrete System De-scription. c(RS_METH_00006, RS_METH_00002, RS_METH_00078)

[TR_METH_01045] Development of the Overall VFB System d In case of omit-ting the optional first step, the development directly starts with the definition of theOverall VFB System. The VFB provides a software architecture oriented view ofall the functions the system supports, independent of any ECUs and networks. Seechapter 2.3 for more details. c(RS_METH_00006, RS_METH_00033)

[TR_METH_01046] Development of the system d The VFB is refined into a sys-tem by defining a topology of ECUs and Networks, deploying software components tothe ECUs, and deriving the communication matrices required to interconnect the dis-tributed features. As a part of the communication development, a custom transforma-tion technology can be specified. This specification is the basis for the implementationof the corresponding basic software module. The development of the system can beachieved directly in one phase or in several phases (the use case shows a single phaseand a two phase approach). c(RS_METH_00006, RS_METH_00005)

[TR_METH_01047] Two phase development approach d The two phase approach isused when there is an organizational separation of responsibility where the primary or-ganization defines the overall system in the first phase, and several other organizationsdefine the sub-systems in parallel during the second phase. In this case, the primaryorganization hands over System Extracts, which represent subsystem parts of thewhole system. These subsystems contain Subsystem VFBs which are reduced overallVFBs. c(RS_METH_00006, RS_METH_00002, RS_METH_00005)

[TR_METH_01048] The overall system d The overall system defines the majorpublic ECUs and topologies, and the subsystem design contributes by adding pri-vate ECUs and networks to the system. Please note that portions defined within asubsystem are not directly visible to any other subsystem or to the overall system.c(RS_METH_00006, RS_METH_00005, RS_METH_00002)

[TR_METH_01049] Interaction between organizations d Additionally, the softwarecomponent structure of the System Extracts, delivered by the primary organiza-tion can be transformed into a different structure by the receiving organization (ECUSystem Description). In this case the System Extract of the primary organi-zation can be considered as a requirement and the subsystem of the receiving or-ganization represented by one or more ECU System Descriptions can be seenas a solution which has to fulfill the delivered requirements. c(RS_METH_00006,RS_METH_00077)

[TR_METH_01109] Producing ECU-specific deliverables d After the system de-sign is complete, the portions that are related to a specific ECU are extractedproducing a deliverable for each ECU. This is elaborated further in chapter 2.5.c(RS_METH_00006, RS_METH_00005)

[TR_METH_01110] Development of Software Components d In parallel to thesystem design, the software components (Delivered Atomic Software Compo-

41 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 42: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

nents) are implemented according to the definitions required by the abstract VFB,the VFB or the subsystem VFB. These are delivered to be integrated in the ECUswhere they are deployed. Please note that the implementation of a software compo-nent is more or less independent from ECU configuration. This is a key feature ofthe AUTOSAR methodology. See chapter 2.4 for more details. c(RS_METH_00006,RS_METH_00002, RS_METH_00018)

[TR_METH_01111] Development of Basic Software modules d Since the BasicSoftware modules are independent of the VFB, they can be developed at any timebefore ECU integration. See chapter 2.6 for more details. c(RS_METH_00006,RS_METH_00003)

[TR_METH_01112] Integration of AUTOSAR ECUs d The integration for anAUTOSAR ECU commences when the BSW Module Delivered Bundles, ECUExtract, and the implementation of all Delivered Atomic Software Compo-nents are available. At this stage, the ECU is configured by creating tasks, schedul-ing Software Component Runnables, configuring the Basic Software Mod-ules, etc. The complete code is compiled and linked into an executable. This iselaborated in chapter 2.7. c(RS_METH_00006, RS_METH_00002, RS_METH_00003,RS_METH_00004, RS_METH_00005)

2.1.3 Workflow

Methodology Overview

Develop a VFB System Description

Develop Application Software

Integrate Software for ECU

Develop Basic Software

Develop System

Develop Sub-System

Develop an AbstractSystem Description

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

«nesting»

Figure 2.1: Methodology Overview: Overall Structure

42 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 43: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Develop a VFB System Description

Develop Application Software

Integrate Software for ECU

Develop Basic Software

ECU Software Delivered

BSW Module Delivered Bundle

ECU Extract

Delivered Atomic Software Components

BSW Standard Package

Overall VFB System

VFB AUTOSAR Standard Package

System Constraint Description

System Extract

Develop System

Develop Sub-System

Develop an AbstractSystem Description

Abstract SystemDescription

Transformer Design Bundle

«output»

1

«output»

0..*

«output»

1..*

«output»

1..*

0..*

«input»

1..*

«input»

«output»

1..*

«output»

1

1

«input»

1..*

«input»

1..* «input»

1

«input»

«output»

0..*

0..*

«input»

1

«input» 0..1

«input»

0..*

«input»0..1

«input»

1 «input»

1..*

«input»

0..1 «input»

«output»

1..*

«output»

1..*

Figure 2.2: Methodology Overview: Work Flow

43 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 44: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Process Pattern Methodology OverviewPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Methodology OverviewBrief Description High level view of the AUTOSAR MethodologyDescription This Process Patterns contains the typical activities to develop an

AUTOSAR system.Relation Type Related Element Mul. NoteAggregates Develop Applica-

tion Software1

Aggregates Develop BasicSoftware

1

Aggregates Develop Sub-Sys-tem

1

Aggregates Develop System 1Aggregates Develop a VFB

System Descrip-tion

1

Aggregates Develop an Ab-stract SystemDescription

1

Aggregates Integrate Softwarefor ECU

1

Table 2.1: Methodology Overview

2.2 Develop an Abstract System Description

2.2.1 Purpose

This Activity provides a rough outline of the creation of the Abstract SystemDescription.

2.2.2 Description

[TR_METH_01050] Abstract System Description activity d Due to the fact thatthe overall view on vehicle functions can differ from the actual technical definition ofthe software architectures of individual ECUs, the optional activity Develop an Ab-stract System Description allows to define a view on the overall system froman abstract or functional perspective. This view describes a dedicated abstract VFB.During the further activities this abstract view is refactored into a technical view of thesoftware architecture. c(RS_METH_00002, RS_METH_00078)

For the purpose of this use case, this activity is split into sub-activities and tasks (seeFigure 2.3) that are in detail described in Chapter 2.3 and 2.5.2:

• Data Model Development

44 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 45: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

• Component Model Development

• VFB Timing Development

• Define VFB Top Level

• Define VFB Component Constraints

• Design System

• Integrate Non AUTOSAR System at VFB level

In the Data Model Development activity, the set of VFB Interfaces, VFB Modes,and VFB Types that are used throughout the abstract VFB are defined. Please note,that these objects can be used in later steps by the VFB and the subsystem VFB aswell.

[TR_METH_01051] Creation of an overall abstract system d In the ComponentModel Development activity, a component model is created which represents theoverall system from a functional point of view, e.g. from a customer related perspec-tive of vehicle functions, independent of a concrete vehicle platform design. During thisprocess compositions might be modeled, which are not further refined into Atomic Soft-ware Components. However it is also possible to define atomic software componentsas well in this abstract VFB view. c(RS_METH_00002)

[TR_METH_01052] Definition of a constraints in the context of an abstract sys-tem d In the context of the abstract VFB, the task Define VFB Component Con-straints defines constraints w.r.t. software components of the abstract VFB. Theseconstraints have to be considered when the abstract VFB is transformed into the con-crete, technical VFB. c(RS_METH_00002)

[TR_METH_01128] Integration of Non AUTOSAR Systems in the context of anabstract system d In parallel with the development of the Abstract System De-scription within an AUTOSAR process there may be functions that are developedbased on another approach. The functionality of in-vehicle infotainment systems forinstance is usually not covered in an AUTOSAR development process. Rather, devel-opment methods and platforms such as GENIVI (http://www.genivi.org/) for instanceare employed that address the specific needs and conditions of infotainment systemdevelopment. The integration of these functions into the overall system should be ad-dressed as early as possible. For that purpose first a description of the non-AUTOSARfunctionality (Description of a Non-AUTOSAR System) is needed, which mustbe provided by the non-AUTOSAR approach. Within the development of the AbstractSystem Description the functional interaction of the non-AUTOSAR functions andthe AUTOSAR functions has to be specified that is based on the given descriptions ofboth parts. Since the non-AUTOSAR part is typically specified in a non-AUTOSARformat it must be translated to the corresponding AUTOSAR format (task Trans-late Non-Autosar Description to Autosar Description). Moreover, theinformation on the functional interaction must be incorporated in order to obtain onecommon view of the integrated system. The "Integration of Franca IDL Software Com-ponent Descriptions" document ([3]) defines a format for a VFB Integration Con-

45 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 46: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

nector and a translation of Franca Interface Definitions - that are used in GENIVI- to AUTOSAR. It can be used for the development of an abstract description of anintegrated AUTOSAR and GENIVI system. c(RS_METH_00016)

[TR_METH_01053] Definition of a System Description in the context of an ab-stract system d Additionally to the definition of the abstract VFB, parts of the SystemDescription can already be defined in the Design System activity, e.g. the topol-ogy and ECUs where SWCs of the abstract VFB are mapped to. This SW-C mappingfrom the abstract VFB to ECUs can be used as a methodological step to the defini-tion of the concrete VFB. Please note that not all tasks of the Design System ac-tivity have to be performed in the context of an abstract system. c(RS_METH_00002,RS_METH_00005)

2.2.3 Workflow

Develop an AbstractSystem Description

VFB AUTOSAR Standard Package

Abstract SystemDescription

Data Model Development

Component Model Development

VFB Timing Development

Define VFB Top Level

Define VFB ComponentConstraints

Design System

System Constraint Description

Integrate Non AUTOSAR System at VFB level

«predecessor»

«predecessor»

«output»

1..*

«nesting»

1..*

«input»

«nesting»

«nesting»

«nesting»

0..1

«input»

«nesting»

«nesting»

«nesting»

Figure 2.3: Develop an Abstract System Description

Activity Develop an Abstract System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Develop SystemBrief Description Develop an abstract or functional view on the system.Description This activity defines an abstract view on the overall system from an

abstract or functional point of view. This activity is optional.Relation Type Related Element Mul. Note

46 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 47: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes System Constraint

Description0..1 In the context of the "Develop an

Abstract System Description" activity, theconstraints for the abstract or functionalview on the system can be provided bythe "System Constraint Description".

Consumes VFB AUTOSARStandard Package

1..*

Produces Abstract SystemDescription

1..*

Aggregates Component ModelDevelopment

1

Aggregates Data Model Devel-opment

1

Aggregates Define VFB Com-ponent Constraints

1

Aggregates Define VFB TopLevel

1

Aggregates Design System 1 In the context of the Develop an AbstractSystem Description activity, not all taskshave to be performed.

Aggregates Integrate Non AUTOSAR System at VFB level

1

Aggregates VFB Timing Devel-opment

1

Table 2.2: Develop an Abstract System Description

2.3 Develop a VFB System Description

2.3.1 Purpose

This Activity provides a rough outline of the creation of a Virtual FunctionalBus view of a System. [2]

2.3.2 Description

[TR_METH_01054] Virtual Functional Bus d The Virtual FunctionalBus (VFB) view of a System shows how the Systems software functions interact in-dependently of any network topology or deployment of features across multiple ECUs.c(RS_METH_00033, RS_METH_00002)

For more information on the VFB concept see [4]. For detailed information on themeta-model parts relevant for the VFB see [5].

For the purpose of this use case, this Activity is split into the following sub-activities:

47 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 48: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

• Data Model Development

• Component Model Development

• VFB Timing Development

• Integrate Non AUTOSAR System at VFB level

• Define VFB Safety Information

[TR_METH_01055] Data Model Development activity d In the Data Model De-velopment, the set of VFB Interfaces, VFB Modes, and VFB Types that areused throughout the VFB are defined. Some of these have already been pre-definedby AUTOSAR (so-called “blueprints”), see 3.2.2.7 c(RS_METH_00002)

[TR_METH_01056] Definition of the VFB d In the Component Model Develop-ment activity, the VFB is defined. This can either be done by the use of the abstractVFB as a basis, or is done directly by defining the software components. In case ofusing the abstract VFB as a basis, a mapping between the abstract and the concreteVFB can be established by performing the tasks Define System View Mapping(see Section 3.3.1.15 for more details). c(RS_METH_00002)

Two general approaches can be separated:

• [TR_METH_01057] Top-Down approach d Following a Top-Down approach, thehighest level VFB Composition Components are created, and these are itera-tively broken down to smaller components. At the leaves of the hierarchy the VFBAtomic Software Component are defined. Note that the activity can be evenfinished with empty VFB Composition Components, allowing the detailing ofthe further structure at a later stage. c(RS_METH_00002)

• [TR_METH_01058] Bottom-Up approach d If a Bottom-Up approach is used,then the VFB Atomic Software Components are first defined, and aggre-gated into VFB Composition Components. c(RS_METH_00002)

[TR_METH_01059] Kinds of VFB Atomic Software Components d Several spe-cial kinds of VFB Atomic Software Components can be modeled in this activity:

• VFB Atomic Application Software Components are the core elements.They are used to implement the feature algorithms.

• VFB Parameter Component are used to provide characteristic values, suchas calibration parameters, to software components.

• VFB Sensor Actuator Components provide the connection between phys-ical sensors/actuators and the VFB Atomic Application Software Com-ponents.

• ECU Abstraction Software Components can be modeled at this level aswell in oder to model the ECU input and output interfaces which are used bysensors and actuators.

48 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 49: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

• Complex Driver Components also have to be modeled here, though theirimplementation is ECU specific, because their ports need to be connected at theVFB level.

• VFB NvBlock Software Component can be modeled at this level if applica-tion software accesses non-volatile data via ports.

• Empty VFB Composition Components can be provided in case the detailedstructure of the desired solution is not in the scope of this activity and will be leftopen to a later stage in the development.

c(RS_METH_00002)

[TR_METH_01129] Integrate Non AUTOSAR System at VFB level activity dIn addition to the components that are specified with an AUTOSAR SwComponentDescription there may be application components that are specified in other formatsbecause they are developed within another application domain. In-vehicle infotain-ment components for instance are usually not developed with AUTOSAR means.Rather, development methods and platforms such as GENIVI (http://www.genivi.org/)are employed that address the specific needs and conditions of infotainment sys-tem development. The integration of these components into the overall systemshould be addressed as early as possible. For that purpose the Descriptionof a Non-AUTOSAR System must be incorporated into the VFB system descrip-tion (VFB System). Since the non-AUTOSAR components are typically specified ina non-AUTOSAR format their descriptions must be translated to the correspondingAUTOSAR format (Task Translate Non-Autosar Description to AutosarDescription). Moreover, the information on the interconnection of the componentsmust be incorporated in order to obtain one common view of the integrated system.The document "Integration of Franca IDL Software Component Descriptions" ([3]) de-fines a format for a VFB Integration Connector and a translation of Franca In-terface Definitions - that are used in GENIVI - to AUTOSAR. It can be used for thedevelopment of a VFB description of an integrated AUTOSAR-and-GENIVI system.c(RS_METH_00016)

[TR_METH_01149] Definition of VFB relevant safety information d In the optionalactivity Define VFB Safety Information the VFB relevant safety information isdefined. Safety requirements and safety measures created at this development stagemay be detailed (refined, decomposed, allocated, mapped, etc.) later on in the process(See chapter 2.14). c(RS_METH_00081)

After these activities are completed, the Virtual Functional Bus view of the Sys-tem is defined. At this point, some VFB Software Component Mapping Con-straints may already be known by design, or based on an analysis such as De-fine VFB Timing. These can be described to provide guidance to the downstreamactivities.

49 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 50: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.3.3 Workflow

Component Model Development

Data Model Development

VFB Timing Development

Develop a VFB System Description

Overall VFB System

VFB AUTOSAR Standard Package Define VFB Modes

Define VFB Interfaces

Define VFB Types

Define VFB Constants

Define VFB Composition Component

Define VFB Application SoftwareComponent

Define VFB Sensor or Actuator Component

Define VFB Parameter Component

Define Wrapper Components to IntegLegacy Software

Define Complex DriveComponent

Define ECU Abstraction Component

Define VFB Variants

Define VFB ComponentConstraints

Define VFB Timing

Define VFB Top Level

Define System View Mapping

Abstract SystemDescription

Define VFB NvBlock Software Component

Integrate Non AUTOSAR System at VFB level

Define VFB Safety Information

«nesting»

0..*

«input» «nesting»

1..*

«input»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«predecessor»

«nesting»

«nesting»

«nesting»

«nesting»

«predecessor»

«nesting»

«nesting»

«nesting»

«nesting»

«output»1

«nesting»

«nesting»

«nesting»

Figure 2.4: Develop a VFB System Description

50 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 51: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Integrate Non AUTOSAR System at VFB level

Define VFB Integration Connector

Translate Non-Autosar Description to Autosar Description

«predecessor»

«nesting» «nesting»

Figure 2.5: Integrate Non AUTOSAR System at VFB level

Define Safety Information

VFB System VFB Safety ExtensionsDefine VFB Safety Information

«input» «output»

Figure 2.6: Define VFB Safety Information

Activity Develop a VFB System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::

Develop VFBBrief Description This pattern describes the methodology to develop the Virtual

Functional Bus view of the System.Description The Virtual Functional Bus (VFB) view of a System shows how the

Systems software and hardware functions interact independent of anynetwork topology or deployment of features across muliple ECUs. ThisActivity is split into three sub-activities:

• Data Model Development

• Component Model Development

• Timing Model Development

• Integrate Non AUTOSAR System at VFB level

• Define VFB Safety Information.

Relation Type Related Element Mul. Note

51 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 52: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Abstract System

Description0..* The abstract System Description is an

optional input for the activity "Develop aVFB System Description". TheVFB-related part of the Abstract SystemDescription can be than refined to theconcrete "Overall VFB System".Additionally, a mapping between thosetwo views can be established.

Consumes VFB AUTOSARStandard Package

1..*

Produces Overall VFB Sys-tem

1

Aggregates Component ModelDevelopment

1

Aggregates Data Model Devel-opment

1

Aggregates Define SystemView Mapping

1

Aggregates Define VFB Com-ponent Constraints

1

Aggregates Define VFB SafetyInformation

1

Aggregates Define VFB TopLevel

1

Aggregates Integrate Non AUTOSAR System at VFB level

1

Aggregates VFB Timing Devel-opment

1

Table 2.3: Develop a VFB System Description

Activity Data Model DevelopmentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::

Develop VFBBrief DescriptionDescriptionRelation Type Related Element Mul. NoteAggregates Define VFB Con-

stants1

Aggregates Define VFB Inter-faces

1

Aggregates Define VFB Modes 1Aggregates Define VFB Types 1

Table 2.4: Data Model Development

52 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 53: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Component Model DevelopmentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::

Develop VFBBrief DescriptionDescriptionRelation Type Related Element Mul. NoteAggregates Define Complex

Driver Component1

Aggregates Define ECUAbstraction Com-ponent

1

Aggregates Define VFB Ap-plication SoftwareComponent

1

Aggregates Define VFB Com-position Compo-nent

1

Aggregates Define VFB NvBlock SoftwareComponent

1

Aggregates Define VFB Pa-rameter Compo-nent

1

Aggregates Define VFB Sen-sor or ActuatorComponent

1

Aggregates Define VFB Vari-ants

1

Aggregates Define WrapperComponents toIntegrate LegacySoftware

1

Table 2.5: Component Model Development

Activity VFB Timing DevelopmentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::

Develop VFBBrief DescriptionDescriptionRelation Type Related Element Mul. NoteAggregates Define VFB Timing 1Predecessor Component Model

Development1

Predecessor Data Model Devel-opment

1

Table 2.6: VFB Timing Development

53 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 54: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Integrate Non AUTOSAR System at VFB levelPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::

Develop VFBBrief Description Incorporate the description of the non-AUTOSAR system and its

connection with the AUTOSAR system into the AUTOSARmethodology activities.

Description Based on the description of the non-AUTOSAR system its connectionwith the AUTOSAR system is defined and specified using the VFBIntegration Connector format. This is translated into an AUTOSARdescription that becomes part of the VFB system description.

Relation Type Related Element Mul. NoteAggregates Define VFB Inte-

gration Connector1

Aggregates Translate Non-Autosar Descrip-tion to AutosarDescription

1

Table 2.7: Integrate Non AUTOSAR System at VFB level

Activity Define VFB Safety InformationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::

Develop VFBBrief Description Defines all required safety information at VFB level.Description In this activity, the safety information at VFB level is defined. The safety

information can be refined or completed in further development phases.Extends Define Safety InformationRelation Type Related Element Mul. NoteConsumes VFB System 1Produces VFB Safety Exten-

sions1

Table 2.8: Define VFB Safety Information

2.4 Develop Software Components

2.4.1 Develop an Atomic Software Component

2.4.1.1 Purpose

This Activity provides a rough outline of the creation of an Atomic SoftwareComponent.

54 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 55: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.4.1.2 Description

[TR_METH_01060] Develop an Atomic Software Component activity d This isthe generic Activity valid for several kinds of Atomic Software Components. Thefirst step is to create design, including the runnables, events, interrunnable variables,etc. Once this is complete, the contract header files can be created and the softwarecomponent can be implemented.

Optionally, the safety relevant information for the software component and all containedelements can be defined (See chapter 2.14). If the software component is developedas a SEooC (Safety Element out of Context) and the safety requirements are not fullyknown at development time, the ASIL attribute can be set to indicate the integrity levelthe component was developed for, i.e. in the development process all developmentprocess related requirements of ISO 26262 for the specified ASIL have been applied.c(RS_METH_00002, RS_METH_00038)

Note that the method of implementation, quality, testing, etc. are beyond the scope ofthis activity.

After the component is implemented and successfully compiled, its resources are mea-sured and stored as part of the software component description for further usage bydownstream processes.

The pattern also includes the optional tasks of creating a timing model, binding pre-build-variants and evaluating variants, all in the scope of the atomic software compo-nent. Note that the sequence of these optional tasks within the Activity is only onepossible example.

2.4.1.3 Workflow

Figure 2.7 shows the work breakdown assumed for this use case. The next two fig-ures 2.9 and 2.10 show all the tasks and work products of the method library involvedin this use case.

55 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 56: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Develop an Atomic Software Component

Evaluate Variant

Measure Component Resources

Compile Atomic Software Component

Implement Atomic Software Component

Define Software Component Timing

Generate Component Prebuild Data Set

Generate Atomic Software Component Contract Header Files

Define Atomic Software Component Internal Behavior

Define SymbolProps for Types

Define Consistency Needs

Define Software Component Safety Information

«nesting»

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

Figure 2.7: Develop an Atomic Software Component

Define Safety Information

Overall VFB System

VFB Safety Extensions

Software Component Internal Behavior

Software Component Safety ExtensionsDefine Software

Component Safety Information

«input»

«input»

«input»

«output»

Figure 2.8: Define Software Component Safety Information

56 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 57: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop an Atomic Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop Atomic SWCBrief DescriptionDescription This is the generic pattern valid for several kinds of Atomic Software

Components. The first step is to create design, including therunnables, events, interrunnable variables, etc. Once this is complete,the contract header files can be created and the software componentcan be implemented.

Note that the method of implementation, quality, testing, etc. arebeyond the scope of this capability pattern.

After the component is implemented and successfully compiled, itsresources are measured and stored as part of the software componentfor further usage by downstream processes.

The pattern also includes the optional tasks of creating a timing model,defining safety relevant information, binding prebuild-variants andevaluating variants, all in the scope of the Atomic SoftwareComponent. Note that the sequence of these optional tasks within thecapability pattern is only one possible example.

Extended by Develop Application Software, Develop a Complex Driver Component,Develop a Sensor Actuator Component, Develop an ECU AbstractionComponent, Develop an NvBlock Software Component, Optimize aSoftware Component for a Specific Target

Relation Type Related Element Mul. NoteAggregates Compile Atomic

Software Compo-nent

1

Aggregates Define AtomicSoftware Com-ponent InternalBehavior

1

Aggregates Define Consis-tency Needs

1 Used for defining the consistencyrelations between a group ofRunnableEntitys and a group ofDataPrototypes.

Aggregates Define SoftwareComponent SafetyInformation

1

Aggregates Define SoftwareComponent Timing

1

Aggregates Define SymbolProps for Types

1 Used for solving name conflicts on thelevel of component or data types.

Aggregates Evaluate Variant 1Aggregates Generate Atomic

Software Com-ponent ContractHeader Files

1

Aggregates Generate Compo-nent Prebuild DataSet

1

57 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 58: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Implement Atomic

Software Compo-nent

1

Aggregates Measure Compo-nent Resources

1

Table 2.9: Develop an Atomic Software Component

Activity Define Software Component Safety InformationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop Atomic SWCBrief Description Defines all required safety information for a software component.DescriptionExtends Define Safety InformationRelation Type Related Element Mul. NoteConsumes Overall VFB Sys-

tem1

Consumes Software Compo-nent Internal Be-havior

1

Consumes VFB Safety Exten-sions

1

Produces Software Compo-nent Safety Exten-sions

1

Table 2.10: Define Software Component Safety Information

58 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 59: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Define Atomic Software Component InternalBehavior

Define Software Component Timing

Generate Atomic Software Component Contract Header Files

Generate Component Prebuild Data Set

Predefined Variant

System Constant Value Set

Postbuild Variant Set

VFB Atomic Software Component

VFB Types

VFB Modes

VFB AUTOSAR Standard Package

VFB Interfaces

VFB Data Type Mapping Set

Software Component Internal Behavior

Software Component Data TyHeader

Application Header File

Component RTE Prebuild Configuration Header

Software Component Timing

Define SymbolProps for Types

0..1

«input»

«output»

1

0..* «input»

0..*

«input»

1

«input»

0..*

«input»

0..1 «input»

1..*

«input»

1 «input»

0..* «input»

0..1 «input»

0..1

«input»

0..1 «input»

«output»

1

1

«input» «output»

+symbolProps 0..*

0..1

«input»

1

«input»

0..*

«input»

0..1

«input»

0..*

«input»

1 «input»

«output»

+symbolProps 0..*

«output»

1

0..1 «input»

1

«input»

«output»

1

«output» 1

0..* «input»

Figure 2.9: Develop an Atomic Software Component - Detailed view with work products(1)

59 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 60: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Implement Atomic Software Component

Compile Atomic Software Component

Measure Component Resources

Evaluate VariantGeneral Autosar Artifact

Predefined Variant

System Constant Value Set

Postbuild Variant Set

Evaluated Variant Set

Library Description

Library Header Files

Software Component Internal Behavior

Software Component Data Types Header

Application Header File

Component RTE Prebuild Configuration Header

Software Component Timing

Atomic Software Component SourceCode

Atomic Software Component Implementation

Atomic Software Component ObjectCode

Standard Header Files

1

«input»

«input»

0..1

«input»

0..*

«input»

0..*

«input»0..1

1 «input»

«output»

1

«inoutput»

1

«input»

1..*

«input»0..*

1

«input»

«output»

1

1

«input»

0..1

«input»

0..1

«input»

1

«input»

«output» 1

«output»

1

0..*

«input»

0..1

«input»

0..*

«input»

1

«input»

1

«input»

1 «input»

0..*

«input»

Figure 2.10: Develop an Atomic Software Component - Detailed view with work products(2)

60 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 61: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.4.2 Develop Application Software

2.4.2.1 Purpose

This Activity provides a rough outline of the creation of one or more ApplicationSoftware Components.

2.4.2.2 Description

[TR_METH_01061] Develop Application Software activity d This Activitydescribes the work flow and the necessary activities in terms of the AUTOSAR method-ology to develop one or more Application Software Components. The workflow shall allow a more or less independent development of the software compo-nents core functionality. These activities have to be performed for each ApplicationSoftware Component. c(RS_METH_00002, RS_METH_00006)

2.4.2.3 Workflow

The detailed work flow can be derived from the generic activity Develop an AtomicSoftware Component.

Develop ApplicationSoftware

Develop an Atomic Software Component

Delivered Atomic Software Components

Overall VFB System

«output» 1..*

«extends»

1 «input»

Figure 2.11: Develop Application Software

61 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 62: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop Application SoftwarePackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop Application SWCBrief DescriptionDescription This pattern describes the workflow and the necessary activities in

terms of the AUTOSAR methodology for the development ofapplication software components.

The workflow shall allow a more or less independent development ofthe software component core functionality. These activities have to beperformed for every application software component.

Extends Develop an Atomic Software ComponentRelation Type Related Element Mul. NoteConsumes Diagnostic System

Extract0..*

Consumes Overall VFB Sys-tem

1 The application software needs to referto the relevant elements of the overallVFB system such as SoftwareComponent Types, Port Interfaces andData Types.

Produces Delivered AtomicSoftware Compo-nents

1..*

Produces Diagnostic SystemExtract

0..*

Table 2.11: Develop Application Software

2.4.3 Uses Cases for more Specialized Software Components

2.4.3.1 Purpose

These Activities provides a rough outline of the creation of more specialized com-ponents and of the ECU specific optimization of a software component.

2.4.3.2 Description

These Activities describe the work flow and the necessary activities in terms ofthe AUTOSAR methodology to develop more specialized components, which could bepartially hardware or ECU dependent.

2.4.3.3 Workflow

These work flows are for the most part derived from the generic activity Develop anAtomic Software Component. The diagrams show the required extensions.

62 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 63: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Note the development of a Service Component does not fall into this category of usecases, because it is for the most part generated during integration time.

For the development of a VFB Parameter Component refer to the calibration usecase 2.9.

Develop an Atomic Software Component

Develop a Sensor Actuator Component

«extends»

Figure 2.12: Develop a Sensor or Actuator Component

Activity Develop a Sensor Actuator ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop Sensor-Actuator ComponentBrief Description Show how to develop a Sensor Actuator ComponentDescription Activities to develop a VFB Sensor Actuator Component, i.e.

component that represents a physical sensor or actuator.Extends Develop an Atomic Software ComponentRelation Type Related Element Mul. Note

Table 2.12: Develop a Sensor Actuator Component

Develop an Atomic Software Component

Develop an ECU Abstraction Component

Define BSW ModuleTiming

Map Software Componentto BSW

«extends» «nesting»

«nesting»

Figure 2.13: Develop an ECU Abstraction Component

63 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 64: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop an ECU Abstraction ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop Ecuabs ComponentBrief Description Show how to develop an ECU Abstraction Component.Description Activities to develop an ECU Abstraction Software Component, i.e. a

component that implements an ECU Abstraction..Extends Develop an Atomic Software ComponentRelation Type Related Element Mul. NoteAggregates Define BSW Mod-

ule Timing1

Aggregates Map SoftwareComponent to BSW

1

Table 2.13: Develop an ECU Abstraction Component

Develop an Atomic Software Component

Develop a Complex Driver Component

Map Software Componentto BSW

«nesting» «extends»

Figure 2.14: Develop a Complex Driver Component

Activity Develop a Complex Driver ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop CDD ComponentBrief Description Show how to develop a Complex Driver ComponentDescription Show how to develop a Complex Driver ComponentExtends Develop an Atomic Software ComponentRelation Type Related Element Mul. NoteAggregates Map Software

Component to BSW

1

Table 2.14: Develop a Complex Driver Component

64 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 65: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Develop an NvBlock Software Component

Develop an Atomic Software Component

«extends»

Figure 2.15: Develop an NvBlock Software Component

65 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 66: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop an NvBlock Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Develop NvBlock Software ComponentBrief DescriptionDescription Activities to develop an NvBlock Software Component. An

NvBlockSoftwareComponentType (designed as part of activityComponent Model Development) allows the application software toaccess non-volatile data in a convenient way via ports. The NvBlockSoftware Component takes over the management and buffering of datawithin blocks including data exchange with the underlying basicsoftware (NvM). Optionally, it implements special writing strategies(e.g. cyclic writing). The development activities are similar to thegeneric activity Develop an Atomic Software Component with thefollowing differences:

• The description of the NvBlockNeeds within aNvBlockSoftwareComponentType is done in response torequirements given by the application software as part of theirown NvBlockNeeds. These are part of their SoftwareComponent Internal Behavior which means that this level mustbe available when the NvBlockSoftwareComponentType isfinally designed.

• The creation of an Software Component Internal Behavior withinNvBlockSoftwareComponentType is optional. This artifact isonly needed if special writing strategies have to implemented bythe RTE or if the application software needs a direct access (viaclient-server ports) to the NvM.

• The source code of an NvBlockSoftwareComponentType will begenerated during integration as part of the artifact RTE SourceCode. Therefore no source code and no Atomic SoftwareComponent Implementation needs to be created during thisactivity.

Note that if non-volatile data are accessed by the application softwarevia an NvBlockSoftwareComponentType, it is not required to define aServiceComponentType for this use case.

Extends Develop an Atomic Software ComponentRelation Type Related Element Mul. Note

Table 2.15: Develop an NvBlock Software Component

66 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 67: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Develop an Atomic Software Component

Optimize a Software Component for a Specific Target

Re-compile Component in ECU context

Generate Component Header File in Vendor Mode

Generate Base Ecu Configuration

Create Service Component

«extends»

«nesting»

«nesting»

+Compile AtomicSWC ECUSpecific

«nesting»

«nesting»

Figure 2.16: Optimize Software Component

Activity Optimize a Software Component for a Specific TargetPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::Software

Component::Optimize Software ComponentBrief Description Show how to optimize a software component for a specific target.Description In practice the integration of an application software component has to

consider some optimizations to meet performance or resourcerequirements. The Component API might be much more efficient, if itwill be generated particularly adapted to the concrete ECUconfiguration, e.g. via using macro definitions instead of function callsfor some RTE interaction. In fact this should not change theComponent Implementation (i.e. the C-sources).

That means now we have a different set of component headers, whichinclude the ECU-configuration-specific optimizations.

Note: This use case shows the typical steps needed until therecompilation with the optimized header file can be done. It does notshow all the other steps needed for the ECU build.

Extends Develop an Atomic Software ComponentRelation Type Related Element Mul. NoteAggregates Create Service

Component1

Aggregates Generate BaseEcu Configuration

1

Aggregates Generate Compo-nent Header File inVendor Mode

1

67 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 68: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Re-compile Com-

ponent in ECUcontext

1 Compile Atomic SWC ECU Specific:

Table 2.16: Optimize a Software Component for a Specific Target

2.5 Develop System and Subsystems

2.5.1 Overview

2.5.1.1 Purpose

The Activities to develop the artifacts on the system level include the optionaldevelopment of the abstract system (see Chapter 2.2), the development of an overall(technical) system and optionally the refinement into one or more subsystems. Thereason for this split is, that the latter may be done by another organization, as hasalready been pointed out in 2.1.2.

2.5.1.2 Description

[TR_METH_01065] Develop System and Develop Sub-System activities d Fig-ures 2.17 and 2.18 show the main inputs and outputs of these two major activitiesand how they are refined into sub-activities. Note that the activity Generate ECUExtract and Define System Safety Information can be performed as partof Develop System and Develop Sub-System as well. Optionally a mapping be-tween two different system views represented by different System Descriptionscan be added (see Section 3.3.1.15) and a specification of the transformer technologyfor the communication can be defined. c(RS_METH_00005, RS_METH_00002)

[TR_METH_01066] Creation of a System Extract and an ECU Extract d De-pending on the intended work split, the System Configuration Descriptionproduced during this activity can be used as a basis

1. to create one or more so-called System Extracts as a basis for further refine-ment as sub-systems (see 2.5.5)

2. or to generate ECU Extracts which directly contain all relevant information tobe integrated on an ECU (see 2.5.6)

In the first case, only an outer system is defined. Based on the outer sys-tem, one or more System Extracts can be delivered. The System Extract isnot fully decomposed and still needs to be refined before it forms the basis for theECU configuration. In order to distinguish between the delivered System Ex-tracts and the refined sub-system, one or more ECU System Descriptions arecreated as a basis for further refinement (See activity Create ECU System De-

68 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 69: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

scription). Atomic Software Components, additional ECUs, Networks andthe resulting communication will be added during the refinement step in the activityDesign Sub-System. c(RS_METH_00005, RS_METH_00002)

Generate System Extract

Develop System

Design System

Generate ECU Extract

System Constraint Description

System Extract

ECU ExtractOverall VFB System

Abstract SystemDescription

Define System View Mapping

System ConfigurationDescription

Design Transformer

Transformer Design Bundle

Define System Safety Information

1..*

«nesting»

0..*

«nesting»

0..*

«input»

0..1

«input»

0..1

«input»

0..*

«nesting»

0..1

«nesting»

«output»

1..*

0..1

«nesting»

«output»

0..*

«output»

1..*

«output»0..*

1

«nesting»

Figure 2.17: Structure of Activity: Develop System

Design Sub-System

Develop Sub-System

System Extract ECU Extract

Generate ECU Extract

Create ECU System Description

Define System Safety Information

«output» 1..*

1

«nesting»

1..*

«nesting»

1 «input»

1..*

«nesting»

0..1

«nesting»

Figure 2.18: Structure of Activity: Develop Subsystem

Figure 2.19 shows how the major deliverables produced during these activities arerelated and how they refer to artifacts describing the software.

[TR_METH_01067] Abstract System Description deliverable d The Ab-stract System Description extends the general System Description. TheSystem View Mapping maps the different views on the system together, e.g. dif-ferent overall VFB systems (e.g. Abstract System Description with System

69 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 70: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Configuration Description), or the overall VFB system with the VFB SystemExtract description. c(RS_METH_00005, RS_METH_00002)

System

Software

System Description

System Constraint Description

System Configuration Description System Extract ECU Extract

ECU Extract of VFB System

Overall VFB System

VFB System Extract

System Flat MapECU Flat Map

Abstract SystemDescription

System View Mapping

ECU System Description

0..1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

«extends»

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..1«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

0..1«SPEM_Aggregation»

«extends» «extends» «extends» «extends»

0..1

«SPEM_Aggregation»

Figure 2.19: Overview on the different roles of deliverables based on System Description

Note that all the deliverables based on the generic deliverable System Descriptionas well as the ECU Extract consist of ARXML files that are using the meta-modelelement System as the root element, from where the other information can be traceddown.

Activity Develop SystemPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Develop SystemBrief DescriptionDescription Develop the description of an overall AUTOSAR System as a basis to

deliver System and/or ECU extracts.Relation Type Related Element Mul. NoteConsumes Abstract System

Description0..* The abstract System Description is an

optional input for the activity "DevelopSystem". Please note, that in this stepthe Abstract System Description isrefined to a System Description.

70 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 71: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Overall VFB Sys-

tem0..1 Usually the System refers to elements of

an overall VFB descriptions. But for thedescription of a legacy system, this inputmight be empty.

Consumes System ConstraintDescription

0..1

Produces ECU Extract 1..*Produces System Configura-

tion Description1..*

Produces System Extract 0..*Produces Transformer De-

sign Bundle0..*

Aggregates Define SystemSafety Information

0..1

Aggregates Define SystemView Mapping

0..1

Aggregates Design System 1Aggregates Design Trans-

former0..*

Aggregates Generate ECU Ex-tract

1..*

Aggregates Generate SystemExtract

0..*

Table 2.17: Develop System

Activity Develop Sub-SystemPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Develop SystemBrief DescriptionDescription Develop the description of a sub-system based on a given System

Extract.Relation Type Related Element Mul. NoteConsumes System Extract 1Produces ECU Extract 1..*Aggregates Create ECU Sys-

tem Description1

Aggregates Define SystemSafety Information

0..1

Aggregates Design Sub-Sys-tem

1..*

Aggregates Generate ECU Ex-tract

1..*

Table 2.18: Develop Sub-System

71 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 72: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.2 Design System

2.5.2.1 Purpose

This Activity provides a rough outline of the design steps leading to an AUTOSARSystem Configuration Description and the system-specific part of the Ab-stract System Description, including its topology, deployment, communicationmatrix, etc.

2.5.2.2 Description

[TR_METH_01068] Inputs and Output of the Design System activity d The designof an AUTOSAR System Configuration Description and the system-specificpart of the Abstract System Description uses input information from a Sys-tem Constraint Description and is based on an Overall VFB System forthe software part. Optionally, the Abstract System Description that representsthe functional view on the system can be used as an input. Please note that the inputsand output are depicted in the top-level activities which aggregates the activity DesignSystem.

The activity involves the creation of a Topology, ECU Resources Descrip-tions, and the interconnection between ECU instances. c(RS_METH_00005,RS_METH_00002, RS_METH_00078, RS_METH_00079)

[TR_METH_01069] Deployment of AUTOSAR Software Components d TheAUTOSAR Software Components defined within the VFB Top Level System Com-position are then deployed to the ECU instances. c()

[TR_METH_01070] Description of network signals d The required network signalsare identified and a mapping is done to System Signals to implement the VFB.System Signal Groups, are defined to keep certain signals grouped together forconsistent transmission. System Signals are then defined and form the initial inputto design the Communication. c(RS_METH_00005)

[TR_METH_01071] Description of design constraints d During this stage,design constraints can also be defined Mapping of Software Componentsto Implementations, Mapping of Software Components to ECUs, Sig-nal Path Constraints, and Software Component Mapping Constraints.These constraints serve many purposes including the ability for tools to use themto optimization a system, to interface with legacy ECUs, and to ”lock” design deci-sion between iterations. c(RS_METH_00005, RS_METH_00002, RS_METH_00041,RS_METH_00020)

Note: The mapping of software components to implementations is optional and neededonly if those components are specifically required to be used in an ECU.

72 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 73: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.2.3 Workflow

Design System

Design Communication

«nesting»

Figure 2.20: Structure overview: Design System

73 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 74: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Design System

Set System RootDefine Software Component Mapping Constraints

Assign Top Level Composition

Define ECU Description

Define System Topology

Deploy Software Component

Generate or Adjust System Flat Map

Derive CommunicationNeeds

Define Signal Path Constraints

Define System Variants

Define System Timing

Define Communication Matrix

Select Software Component Implementation

Design Communication

Define Frames

Define Signal PDUs

Define TP

Define PDU Gateway Define RTE Fan-outDefine Network Management

Define Signal Gateway Define Transformation Technology

Define Secured PDUs

Define E2E Transformer Technology

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.21: Nesting relationship: Design System

74 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 75: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Set System Root

System Description Root Element

Assign Top Level Composition

Define ECU Description

ECU Resources Description

Define System Topology

Define Software Component Mapping Constraints

Software Component Mapping Constraints

Topology

Generate or Adjust System Flat Map System Flat

Map

Deploy Software Component

Mapping of Software Components to ECUs

Derive CommunicationNeeds

System Signal

Data Mapping

Define Signal Path Constraints

Signal Path Constraints

Communication Layers

VFB Top Level System Composition

1

1

1

1

1

1..*

1

1

1

1

1..*1

1

1..*

1

1

1 1

1

0..1

1

1

1..*

1

1

1..*

Figure 2.22: Detailed work flow for: Design System

75 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 76: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Design SystemPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Design SystemBrief Description Initial work to create a topology, map a VFB onto that topology and

determine the ECU resources each ECU needs.Description The design of an AUTOSAR System involves the creation of a

Topology, ECU Resources Descriptions, and the interconnectionbetween ECU instances.

The software components defined within the VFB Top Level SystemComposition are then deployed to the ECU instances.

The required network signals are identified and a mapping is done toSystem Signals to implement the VFB. System Signal Groups, aredefined to keep certain signals grouped together for atomictransmission. System Signals are then defined and form the initial inputto design the Communication Matrix.

During this stage, design constraints can also be defined (Mapping ofSoftware Components to Implementations, Mapping of SoftwareComponents to ECUs, Signal Path Constraint, and SoftwareComponent Mapping Constraint ). These constraints serve manypurposes including the ability for tools to use them to optimization asystem, to interface with legacy ECUs, and to "lock" design decisionbetween iterations.

Notes: The mapping of software components to implementations isoptional and needed only if those components are specifically requiredto be used in an ECU.

Relation Type Related Element Mul. NoteAggregates Assign Top Level

Composition1

Aggregates Define ECU De-scription

1

Aggregates Define Signal PathConstraints

1

Aggregates Define SoftwareComponent Map-ping Constraints

1

Aggregates Define SystemTiming

1

Aggregates Define SystemTopology

1

Aggregates Define SystemVariants

1

Aggregates Deploy SoftwareComponent

1

Aggregates Derive Communi-cation Needs

1

Aggregates Design Communi-cation

1

76 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 77: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Generate or Adjust

System Flat Map1

Aggregates Select SoftwareComponent Imple-mentation

1

Aggregates Set System Root 1

Table 2.19: Design System

Activity Design CommunicationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Design SystemBrief DescriptionDescription Describe all communication layers. and define the mapping of the

triggering elements within the Physical Channels to the communicationconnector ports for the individual ECUs.

Because the triggering elements are aggregated as splitable elementswithin the Physical Channels it is possible to define them in an artifactseparated from the Topology.

Relation Type Related Element Mul. NoteAggregates Define Communi-

cation Matrix1

Aggregates Define E2E Trans-former Technology

1

Aggregates Define Frames 1Aggregates Define Network

Management1

Aggregates Define PDU Gate-way

1

Aggregates Define RTE Fan-out

1

Aggregates Define Secured PDUs

1

Aggregates Define SignalGateway

1

Aggregates Define Signal PDUs

1

Aggregates Define TP 1Aggregates Define Transforma-

tion Technology1

Table 2.20: Design Communication

77 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 78: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.3 Generate System Extract

2.5.3.1 Purpose

This Activity provides an extract of the system description for a specific sub-system.

2.5.3.2 Description

Generate a System Extract which is a basis to develop a sub-system.

2.5.3.3 Workflow

Generate System ExtractSystem ConfigurationDescription

System Extract

Detailed tasks are not modeled.

1 «input» «output» 0..*

Figure 2.23: Generate the System Extract

The detailed tasks of Generate System Extract are not modeled since they areconsidered as trivial - it just means to reduce the content of the input description to thesubsystem in question.

Activity Generate System ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Generate System ExtractBrief DescriptionDescription Generate for further development, a System Extract which represents

the description of a part of the system (sub-system). This allows a startof work on ECU’s even if the system is not completely described.

Relation Type Related Element Mul. NoteConsumes System Configura-

tion Description1

Produces System Extract 0..*

Table 2.21: Generate System Extract

2.5.4 Create ECU System Description

2.5.4.1 Purpose

Based on a System Extract, this Activity creates ECU System Descrip-tions which are refined during the design of the sub-system.

78 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 79: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.4.2 Description

[TR_METH_01125] Create ECU System Description activity d Based on thedelivered System Extract, the receiving organization creates one or more ECU De-scriptions. The ECU Descriptions are used for designing the sub-system arti-facts (See activity Design Sub-System). c(RS_METH_00002, RS_METH_00005,RS_METH_00077)

From the methodological point of view there are two choices for creating the ECU Sys-tem Description.

[TR_METH_01126] Using the System Extract as the structural basis for theECU development d The System Extract is taken as the structural basis for theECU development. In this case the System Extract becomes an ECU SystemDescription. c(RS_METH_00002, RS_METH_00005, RS_METH_00077)

[TR_METH_01127] Creating a new structure for the ECU development d A newstructure is created as a basis for the ECU development. The newly created ECUSystem Description is mapped to the initial System Extract. For this purposethe task Define System View Mapping creates the initial System View Map-ping artifact which is refined during the sub-system design. c(RS_METH_00002,RS_METH_00005, RS_METH_00077)

2.5.4.3 Workflow

System Extract ECU System Description

Define System View Mapping

Create ECU System Description

1

«input»

0..*

«nesting»

«output»

1..*

Figure 2.24: Create ECU System Description

79 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 80: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Create ECU System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Create ECU System DescriptionBrief DescriptionDescription During the Develop Sub-System activity the supplier refines the

received System Extract so that valid ECU Extracts can be generated.The refinement of the System Extract is done using the ECU SystemDescription. Therefore, this activity creates one or more ECU SystemDescriptions based on the System Extract. The sub-system artifactsare designed in the ECU System Description during the activity"Design Sub-System".

From the methodological point of view there are two choices forcreating the ECU System Description.

1) The System Extract is taken as the structural basis for the ECUdevelopment. In this case the System Extract becomes an ECUSystem Description.

2) A new structure is created as a basis for the ECU development. Thenewly created ECU System Description is mapped to the initial SystemExtract. For this purpose the task "Define System View Mapping" isperformed.

Relation Type Related Element Mul. NoteConsumes System Extract 1Produces ECU System De-

scription1..*

Aggregates Define SystemView Mapping

0..*

Table 2.22: Create ECU System Description

2.5.5 Design Sub-System

2.5.5.1 Purpose

This Activity details a given ECU System Description (previously created fromthe delivered System Extract) with additional ECUs and networks.

2.5.5.2 Description

[TR_METH_01075] Design Sub-System activity d Based on the ECU SystemDescription, the description of a sub-system is defined. c(RS_METH_00002,RS_METH_00005)

[TR_METH_01076] Collaboration between different organizations d Additionally,the software component structure of the System Extracts, delivered by the primaryorganization can be transformed into a different structure by the receiving organization

80 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 81: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

(ECU System Description). In this case the System Extract of the primary or-ganization can be considered as a requirement and the sub-system of the receivingorganization can be seen as a solution which has to fulfill the delivered requirements.Thus here again a mapping activity can be defined which maps the newly introducedsolution sub-system to the provided requirement sub-system from the primary organi-zation. c(RS_METH_00002, RS_METH_00005, RS_METH_00077)

[TR_METH_01077] Transformation changes during the Design Sub-System ac-tivity d During this transformation the hierarchical SWC-structure can be changed,some SWCs can be replaced by other SWCs, some can remain in the resulting view.c(RS_METH_00002, RS_METH_00005)

[TR_METH_01078] Mapping of different views d The different views are mapped bythe System View Mapping. c(RS_METH_00002, RS_METH_00005)

Typical use-cases for this transformation steps are:

• [TR_METH_01079] Use Case: Substitution of existing components d Thesecondary organization has an existing software architecture. By software shar-ing some of the existing components are substituted by the delivered soft-ware components. c(RS_METH_00002, RS_METH_00005, RS_METH_00077,RS_METH_00079)

• [TR_METH_01080] Use Case: Mapping of requirements to the solution dThe secondary organization develops one ECU for different primary organiza-tions and therefore has to map the requirements of different primary organiza-tions to its solution. c(RS_METH_00002, RS_METH_00005, RS_METH_00077,RS_METH_00079)

• [TR_METH_01081] Use Case: Reorganization of the software structured The primary organization delivers a sub-system description which definesone ECU. The secondary organization decides to use two ECUs. There-fore the software structure has to be reorganized by the second organization.c(RS_METH_00002, RS_METH_00005, RS_METH_00077, RS_METH_00079)

• [TR_METH_01082] Use Case: Description of changes between different ver-sions of System Descriptions d Additionally the mapping can be used to for-mally describe changes between different versions of System Descriptions.c(RS_METH_00002, RS_METH_00005, RS_METH_00077, RS_METH_00079)

Finally all Atomic Software Components in the resulting sub-system scope areincluded in this sub-system description.

81 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 82: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.5.3 Workflow

Design Sub-System

ECU System Description

1

«input» «output»

1

Figure 2.25: Overview: Design Sub-System

Note that the ECU System Description appears as input and output of this Activitybecause it is refined.

As the detailed work flow for this Activity uses the same elements from the methodologylibrary as the one described in 2.5.2.3, the breakdown into tasks is not modeled here.

Activity Design Sub-SystemPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Design Sub-SystemBrief DescriptionDescription Design the sub-system artifacts based on an ECU System Description

which was previously created from the delivered ECU Extract. Itconsists of the same tasks as the activity Design System.

The description must be completed down to the ECU level, so that validECU extracts can be generated.

Relation Type Related Element Mul. NoteConsumes ECU System De-

scription1 System Extract as generated from the

outer system.Produces ECU System De-

scription1 System Extract refined during design of

the corresponding sub-system withelements needed to generate ECUExtract(s).

Table 2.23: Design Sub-System

2.5.6 Generate ECU Extract

2.5.6.1 Purpose

This Activity provides an extract of the System description for setting up an ECUConfiguration for specific ECU.

82 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 83: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.6.2 Description

Generate an ECU Extract basis for setting up the ECU configuration and furtherdevelopment on ECU level.

2.5.6.3 Workflow

Generate ECU Extract

Extract ECU Topology

Generate or Adjust ECU Flat Map

ECU Flat Map

Flatten Software Composition

ECU Extract of Topology

Extract the ECUCommunication

ECU Extract

ECU Extract for Communication

System ConfigurationDescription System Extract

ECU Extract of Data Mapping

ECU Extract of VFB System

ECU System Description

Extract ECU Rapid Prototyping Scenario

ECU Extract of Rapid Prototyping Scenario

1

«input»

«output» 1..*

0..1

«input»

0..1

«input»

«nesting»

«nesting»

0..1

«input»

«nesting»

«nesting»

«nesting»

«output»1

1

«inoutput»1

«output»

1

«output»

1

«output»

1

«output»

1..*

Figure 2.26: Generate the ECU Extract

Activity Generate ECU ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Generate Ecu ExtractBrief Description Generate the ECU Extract out of the System Description in order to be

delivered for integration for further development on ECU level.Description Generate the ECU extract which is a basis for setting up the ECU

configuration and further development on ECU level.

It can be generated either from a full system (System ConfigurationDescription), a System Extract or a ECU System Description.

Relation Type Related Element Mul. Note

83 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 84: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes ECU System De-

scription0..1

Consumes System Configura-tion Description

0..1

Consumes System Extract 0..1Produces ECU Extract 1Aggregates Extract ECU Rapid

Prototyping Sce-nario

1

Aggregates Extract ECU Topol-ogy

1

Aggregates Extract the ECUCommunication

1

Aggregates Flatten SoftwareComposition

1

Aggregates Generate or AdjustECU Flat Map

1

Predecessor Define Rapid Pro-totyping Scenario

1

Table 2.24: Generate ECU Extract

2.5.7 Design Transformer

2.5.7.1 Purpose

This Activity specifies the functional aspects of a transformation technology usedfor the serialization of selected system signals.

2.5.7.2 Description

Transformer enable AUTOSAR systems to use a data transformation mechanism tolinearize and transform data. They can be concatenated to transformer chains andare executed by the RTE for inter-ECU communication which is configured to be trans-formed.

The transformation technology (which transformer should be used for which commu-nication) is defined in the context of the Design Communication activity (task De-fine Transformation Technology). For the transformation of communicationdata standardized transformers (e.g. SOME/IP transformer) or custom transformerscan be used.

[TR_METH_01130] Design Transformer activity d In case of custom transformersthe Design Transformer activity has to be performed to define the functional spec-ification of the custom transformation mechanism (Transformer Specification)and the corresponding configuration parameters (BSW Module Vendor- Specific

84 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 85: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Configuration Parameter Definition). The Design Transformer activityis done during the Develop System activity because it produces a definition what atransformer does and therefore significantly affects the corresponding communication.c(RS_METH_00005, RS_METH_00077)

The specified transformer is then implemented (Develop Basic Software) andcan be used in the Design Communication activity. There, inter-ECU communi-cation can be marked for being transformed.

[TR_METH_01131] Output of Design Transformer activity d The DesignTransformer activity shall result in a set of complete and unambiguous writtenTransformer Specifications and the corresponding BSW Module Vendor-Specific Configuration Parameter Definition. A specification of a spe-cific transformer shall adhere to [6, SWS BSW General] and [7, ASWS TransformerGeneral].

A specification of a transformer shall contain:

• Functional specification of the transformer. See [7, ASWS Transformer General]for details. The most important issue are:

– Specification of the transformers output

– Transformer class

– Transformer errors

• Definition of Development Errors, Production Errors and Extended ProductionErrors.

• Transformer APIs

• Extension of the transformer EcuC if necessary for the specific transformer

c(RS_METH_00077)

2.5.7.3 Workflow

Design Transformer

Create Transformer SpecificationDefine Vendor Specific Module Definition

Transformer Design Bundle

«nesting» «nesting»

«output» 1

Figure 2.27: Design Transformer activity

85 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 86: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Design TransformerPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Design TransformerBrief DescriptionDescription In this activity the functional specification of the custom transformer

module is created and the corresponding parameter definition isspecified. The creation of the functional specification of theTransformer can be seen as a part of the communication design.

This activity is performed only if a custom transformer for thecommunication is required.

Relation Type Related Element Mul. NoteProduces Transformer De-

sign Bundle1

Aggregates Create Trans-former Specifica-tion

1

Aggregates Define VendorSpecific ModuleDefinition

1

Table 2.25: Design Transformer

2.5.8 Define System Safety Information

2.5.8.1 Purpose

This Activity allows specifying safety information at system level.

2.5.8.2 Description

In this activity, the safety information at system or sub-system level is defined. Obvi-ously, the safety information defined in previous development stages is detailed. (Fordetailed tasks see chapter 2.14).

86 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 87: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.5.8.3 Workflow

Define System Safety Information

Define Safety Information

System Description

VFB Safety Extensions

Software Component Safety Extensions

System Safety Extensions

«output»

«input»

«input»

«input»

Figure 2.28: Define System Safety Information

Activity Define System Safety InformationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::

Develop SystemBrief Description Defines all required safety information at system level.Description In this activity, the safety information at system level is defined. The

safety information can be refined or completed in further developmentphases.

Extends Define Safety InformationRelation Type Related Element Mul. NoteConsumes Software Compo-

nent Safety Exten-sions

1

Consumes System Descrip-tion

1

Consumes VFB Safety Exten-sions

1

Produces System Safety Ex-tensions

1

Table 2.26: Define System Safety Information

87 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 88: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.6 Develop Basic Software

2.6.1 Overview

2.6.1.1 Purpose

This Activity provides an overall use case how to the develop AUTOSAR BasicSoftware.

2.6.1.2 Description

2.6.1.3 Workflow

Design Basic Software

Develop BSW Module

Develop Basic Software

Define BSW Types

Define BSW Entries

Define BSW Interfaces

Define BSW Behavior

Generate BSWM Contract Header Files

Implement a BSW Module

Define BSW Module Timing

Compile BSW Core Code

Generate BSW Module Prebuild Data Set

Define Vendor Specific Module Definition

Develop BSW Module Generator

BSW Module Delivered Bundle

BSW Standard Package

Transformer Design Bundle

«nesting»1

«input»

0..*

«input»

1

«nesting»

«output»

1..*

1..*

«nesting»

«nesting»

«nesting»

«predecessor»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.29: Nesting relationship: Develop Basic Software

88 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 89: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop Basic SoftwarePackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::BS

W::develop_bswBrief DescriptionDescription Describes the overall activities to develop Basic Software, starting from

the design down to delivery of modules.

In case of custom transformer module development, the TransformerDesign Bundle containing the functional specification and theparameter definition is taken as a basis for all required activities.

Relation Type Related Element Mul. NoteConsumes BSW Standard

Package1

Consumes Diagnostic SystemExtract

0..*

Consumes Transformer De-sign Bundle

0..*

Produces BSW Module De-livered Bundle

1..*

Produces Diagnostic SystemExtract

0..*

Aggregates Design Basic Soft-ware

1

Aggregates Develop BSWModule

1..*

Table 2.27: Develop Basic Software

It consists of two parts:

• Design Basic Software

• Develop BSW Module

2.6.2 Design BSW

2.6.2.1 Purpose

This Activity provides a rough outline for the Basic Software design for an ECU ora set of ECUs.

2.6.2.2 Description

[TR_METH_01083] Design Basic Software activity d Design the Basic Soft-ware for an ECU or a set of ECUs. This shall result in a set of complete andunambiguous Basic Software Module Descriptions. c(RS_METH_00003,RS_METH_00004)

89 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 90: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Note that existing descriptions, especially standardized ones, can be reused, eventu-ally setting only optional elements or user specific extension.

[TR_METH_01084] Separation of design and development of basic software dThis Activity is conceptually separated from Develop BSW Module, because itmight be performed by a Basic Software Designer responsible for the com-plete Basic Software Design on a given ECU, which may be different in general fromthe Basic Software Module Developer who develops or delivers the single modules.c(RS_METH_00003, RS_METH_00018)

2.6.2.3 Workflow

Design Basic Software

Define BSW Types

Define BSW Entries Define BSW InterfacesDefine Vendor Specific Module Definition

BSW Standard Package

BSW Design Bundle

«output» 1..*1 «input»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.30: Nesting Relationship : Design Basic Software

90 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 91: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Define BSWTypes

Define BSW Entries

Define BSW Interfaces

Basic SoftwareEntries

BSW Types

Basic Software Module Description

ECU Resources Description

Define Vendor Specific Module Definition

BSW Module Vendor- Specific Configuration Parameter Definition

AUTOSAR Standardized ECU Configuration Parameter Definition

BSW Standard Package

«output» 1

1

«SPEM_Aggregation»

«input»

0..1

«input»

0..1

«input»

0..1

«inoutput»

«input»

1

«input»

1

«output» 1

«input»0..1

1 «input»

«output» 1

«input»

1

Figure 2.31: Design Basic Software

Activity Design Basic SoftwarePackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::BS

W::develop_bswBrief Description Design the Basic Software for an ECU or a set of ECUs.Description Design the Basic Software for an ECU or a set of ECUs. This shall

result in a set of complete and unambiguous Basic Software ModuleDescription. Note that existing descriptions, especially standardizedones, can be reused, eventually setting only optional elements or userspecific extension.

This activity is conceptually separated from the activity Develop BasicSoftware Module, because it might be performed by a Basic SoftwareDesigner responsible for the complete Basic Software Design on agiven ECU, which may be different (in general) from the Basic SoftwareModule Developer who develops and/or delivers the single modules.

Relation Type Related Element Mul. NoteConsumes BSW Standard

Package1

Produces BSW Design Bun-dle

1..*

Aggregates Define BSW En-tries

1

Aggregates Define BSW Inter-faces

1

91 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 92: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Define BSW Types 1Aggregates Define Vendor

Specific ModuleDefinition

1

Table 2.28: Design Basic Software

2.6.3 Develop BSW Module

2.6.3.1 Purpose

This Activity provides a rough outline for a single Basic Software module or clusterdevelopment prior to an ECU integration.

2.6.3.2 Description

[TR_METH_01085] Develop BSW Module activity d To develop the core code (i.e.the code not generated during integration) of a single BSW module or cluster priorto ECU integration. This Activity focuses on the tasks which are common formost BSW modules. It is not valid for those modules (RTE, BSW Scheduler) whichare completely generated at integration time. c(RS_METH_00003, RS_METH_00006,RS_METH_00038)

92 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 93: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.6.3.3 Workflow

Develop BSW Module

Define BSW Behavior

Define BSW Module Timing

Generate BSWM Contract Header Files Implement a BSW

Module

Compile BSW Core Code

Generate BSW Module Prebuild Data Set

Develop BSW Module Generator

BSW Standard Package

BSW Design Bundle

BSW Module Delivered Bundle

«nesting» «nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

1 «input»

1..*

«input»

«output» 1

Figure 2.32: Nesting relationship : Develop Basic Software Module

93 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 94: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Define BSW Behavior

Define BSW Module Timing

Generate BSWM Contract Header Files

Implement a BSW Module

Compile BSW Core Code

Generate BSW Module Prebuild Data Set

Basic Software Module Internal Behavior

Basic Software Module Core Header

Basic Software Module Core Source Code

Basic Software Module Object Code

Basic Software Module Interl ink Header

BSW RTE Prebuild ConfigurationHeader

Basic Software Module Implementation Description

Basic Software Module Description

Basic Software Module Timing

Develop BSW Module Generator

BSW Module Generator

BSW Standard Package

BSW Module Vendor- Specific Configuration Parameter Definition

Build Action Manifest

0..1

1

«output»

1

1

1

«input»1

1

«output»

0..1

«output»

1

«output»

1

1

«input»1

1

1

1

1

0..1

1

1

1

1

0..1 «input»

«input»

«output»

1

0..* «input»

1

«output»1

«input»

0..1

«input»

0..1

«input»

0..1

«input»

0..1

«output» 1

1

«input»

Figure 2.33: Develop Basic Software Module

94 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 95: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop BSW ModulePackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::BS

W::develop_bswBrief Description Develop a single BSW module or cluster prior to ECU integration.Description Develop a single BSW module or cluster prior to ECU integration.

To develop the core code (i.e. the code not generated duringintegration) of a single BSW module or cluster prior to ECU integrationincluding vendor specific configuration parameters and modulegenerators. This activity focuses on the tasks which are common formost BSW modules. It is not valid for those modules (RTE, BSWScheduler) which are completely generated at integration time.

Relation Type Related Element Mul. NoteConsumes BSW Design Bun-

dle1..*

Consumes BSW StandardPackage

1

Produces BSW Module De-livered Bundle

1

Aggregates Compile BSWCore Code

1

Aggregates Define BSW Be-havior

1

Aggregates Define BSW Mod-ule Timing

1

Aggregates Develop BSWModule Generator

1

Aggregates Generate BSWModule PrebuildData Set

1

Aggregates Generate BSWMContract HeaderFiles

1

Aggregates Implement a BSWModule

1

Predecessor Design Basic Soft-ware

1

Predecessor Design Basic Soft-ware

1

Table 2.29: Develop BSW Module

2.7 Integrate Software for ECU

2.7.1 Description

In this chapter, the integration for an AUTOSAR ECU is described. In the AUTOSARsense an ECU means a microcontroller plus peripherals and the according software/-configuration. Therefore, each microcontroller requires its own ECU Configuration.

95 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 96: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01086] Integrate Software for ECU activity d The main activitiesinclude configuring and/or generating the BSW modules (including the RTE) and build-ing the executable. The BSW configuration can be done during different steps of devel-opment. The detailed use cases for these different ways of configuration are introducedlater in the chapter, thanks to the Configuration Classes definition :

• Pre-compile time

• Link time

• Post-build time

c(RS_METH_00004, RS_METH_00062)

2.7.2 Overview

2.7.2.1 Purpose

This Activity is showing the high level view how to integrate AUTOSAR Software foran ECU.

2.7.2.2 Description

[TR_METH_01087] Scope of Integrate Software for ECU activity d The de-velopment of an AUTOSAR ECU consists of four main activities:

• Prepare ECU Configuration

• Configure BSW and RTE

• Generate BSW and RTE

• Build Executable

In addition, the optional activity Model ECU Timing is shown. The ECU timingmodel depends on ECU configuration details (BSW and RTE), but the results shallhelp to optimize the configuration in an iterative approach. c(RS_METH_00005,RS_METH_00003, RS_METH_00004, RS_METH_00002, RS_METH_00006)

The ECU configuration plays a significant role during the integration of the soft-ware for an ECU. The relevant workflow is depicted in figure 2.351. All three activi-ties (Prepare ECU Configuration, Configure BSW and RTE, Generate BSWand RTE) use the work product ECU Configuration Values which contains (i.e.references) all the configuration information for all BSW modules on the ECU. In or-der to better understand the three different activities an introduction to configurationclasses is given in chapter 2.7.9.

1In order to be more comprehensible, this figure hides some outputs of the activity Generate BSWand RTE. For more details see the outputs of all aggregated tasks.

96 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 97: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

One can measure resources used by the various BSW modules and applications andsave that information within the Basic Software Module Implementation De-scription or Atomic Software Component Implementation.

One can also generate an A2L File processing the Generate A2L task at this point.

2.7.2.2.1 Inputs to ECU Configuration

[TR_METH_01114] Input sources for ECU Configuration d ECU Configuration hastwo input sources (see figure 2.35). First of all, all configuration that must be agreedacross ECUs is defined in the System Configuration, which results in a SystemConfiguration Description (and the resulting ECU Extract for the individualECUs).

Secondly, the ECU BSW is built using BSW modules. The specifics of these module im-plementation are defined in the BSW Module descriptions covered by the BSW ModuleDelivered Bundle. c(RS_METH_00003, RS_METH_00004, RS_METH_00005,RS_METH_00006)

The latter is described in [8] in more detail. The concept of the ECU Extract isdepicted below:

ECU Extract

ECU Configuration can only be started once a plausible System ConfigurationDescription and the corresponding ECU Extract has been generated (see fig-ure 2.35). Details on the System Configuration Description can be foundin [9].

The System Configuration Description contains all relevant system-wide con-figuration, such as

• ECUs present in the system

• Communication systems interconnecting those ECUs and their configuration

• Communication matrices (frames sent and received) for those communicationsystems

• Definition of Software Components with their ports and interfaces and connec-tions (defined in the SWC Description and referenced in the System Configu-ration Description).

• Mapping of SWCs to ECUs

The ECU Extract is a description in the same format as the System Configura-tion Description, but with only those elements included that are relevant for theconfiguration of one specific ECU.

97 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 98: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.2.2.2 ECU Configuration Value description

The ECU Extract only defines the configuration elements that must be agreed be-tween ECUs. In order to generate a working executable that runs on the ECU, muchmore configuration information must be provided.

The remaining part of the configuration is about configuring all BSW modules within theECU. Typical BSW modules within an ECU can be: RTE, Com, Can, OS, NVRAM etc.There are also dependencies between BSW modules to consider when configuring theECU.

When the configuration is done, the generation of configuration data takes place. I.e.there are both configuration editors and configuration generators involved in the pro-cess.

In order to obtain consistency within the overall configuration of the ECU, AUTOSARhas defined a single format, the ECU Configuration Value description to be used forall BSW modules within an ECU. Both configuration editors and configuration gen-erators are working toward ECU Configuration Value descriptions. In the AUTOSARMethodology the ECU Configuration Value descriptions is represented by the artifactECU Configuration Values.

[TR_METH_01116] ECU Configuration Value description contains the configura-tion of all BSW modules in a single ECU d This one description (ECU Configura-tion Values) collects the complete configuration of BSW modules in a single ECU.Each module generator may then extract the subset of configuration data it needs fromthat single format. c(RS_METH_00004)

98 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 99: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.2.3 Workflow

Integrate Software for ECU

Prepare ECU Configuration

Configure BSW and RTE

Model ECU Timing

Generate BSW and RTE

Build Executable

ECU Software Delivered

ECU ExtractDelivered Atomic Software Components

BSW Module Delivered Bundle

Diagnostic ECU Extract

Update ECU Configuration

«nesting»

«nesting»

«nesting»

0..1

«input»

1..*

«input»

«nesting»

«nesting»

«nesting»

1..*

«input»

«output»

1

1

«input»

Figure 2.34: Integrate Software for ECU Overview

ECU Extract Prepare ECU Configuration

Generate BSW and RTE

Configure BSW and RTE

BSW Module Delivered Bundle

ECU Configuration Values

BSW Module Configuration Data Source Code

BSW Module Configuration Header File

RTE Source Code

«output»

1

«output»

1

«output»

1

«inoutput»

1

1

«input»1..*

«input»

1 «input»

«output»

1

Figure 2.35: ECU Configuration Overview

99 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 100: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Integrate Software for ECUPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief DescriptionDescription This activity contains all typical sub-activities required to integrate the

software components and modules on an AUTOSAR ECU.

ECU in this context means processor, so if an electronic control unitconsists of several processors, one "ECU Delivered" will be needed foreach processor.

Relation Type Related Element Mul. NoteConsumes BSW Module De-

livered Bundle1..*

Consumes Delivered AtomicSoftware Compo-nents

1..*

Consumes Diagnostic ECUExtract

0..1 complete DE:

Consumes ECU Extract 1Produces ECU Software De-

livered1

Aggregates Build Executable 1Aggregates Configure BSW

and RTE1

Aggregates Generate BSWand RTE

1

Aggregates Model ECU Timing 1Aggregates Prepare ECU Con-

figuration1

Aggregates Update ECU Con-figuration

1

Table 2.30: Integrate Software for ECU

2.7.3 Prepare ECU Configuration

2.7.3.1 Description

[TR_METH_01088] Prepare ECU Configuration activity d During the PrepareECU Configuration activity, the information available in ECU Extract for the spe-cific ECU is extended by implementing the Service Needs required by the Soft-ware Components and BSW Modules and by including their initial configurations asprovided in the BSW Module Preconfigured Configuration or BSW ModuleRecommended Configuration. The result of this activity is the base ECU Con-figuration.

In addition, the BSW Module Vendor- Specific Configuration ParameterDefinition, which defines all possible configuration parameters and their struc-ture, is incorporated into the ECU Configuration. This is necessary because the

100 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 101: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

output ECU Configuration has a flexible structure which does not define a fixednumber of configuration parameters a priori. c(RS_METH_00005, RS_METH_00003,RS_METH_00004, RS_METH_00002)

[TR_METH_01117] BSW implementation shall be chosen for each BSW modulethat is present in the ECU d For each BSW module that shall be present in theECU, the implementation must be chosen. This is done by referencing the BSW Mod-ule description delivered with the BSW module (BSW Module Delivered Bundle).c(RS_METH_00003, RS_METH_00004)

The rules that must be followed when building the base ECU Configuration Valuedescription are available in [10] chapter 4.2.

2.7.3.2 Workflow

Prepare ECU Configuration

Define Integration Variant

Generate Base Ecu Configuration

ECU Configuration Values

ECU Extract

Evaluated Variant Set

Postbuild Variant Set

Predefined Variant

Diagnostic ECU Extract

1

«input»

0..1

«input»

1 «input»

«nesting»

«nesting»

«output»

1

0..1

«input»

1

«input»

«inoutput»

0..*

«output»

1

«output»

0..1

Figure 2.36: Prepare ECU Configuration

Activity Prepare ECU ConfigurationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief DescriptionDescription Initial actions required to create the initial ECU Configuration.Relation Type Related Element Mul. NoteConsumes BSW Module De-

livered Bundle1..*

101 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 102: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Diagnostic ECU

Extract0..1

Consumes ECU Extract 1Produces ECU Configuration

Values1

Aggregates Define IntegrationVariant

1

Aggregates Generate BaseEcu Configuration

1

Predecessor Refine Rapid Pro-totyping Scenario

1

Table 2.31: Prepare ECU Configuration

2.7.4 Configure BSW and RTE

2.7.4.1 Description

[TR_METH_01089] Configure BSW and RTE activity d Once there is a base ECUConfiguration, the complete configuration can be performed. This is mainly editingwork on the ECU Configuration which is typically supported by an editing tool. Inpractice this will require iterations and/or parallel work to configure the RTE and all par-ticipating BSW modules. c(RS_METH_00003, RS_METH_00004, RS_METH_00020)

The methodology does not prescribe a certain order of these configuration steps. TheECU Configuration description (e.g. ECU Configuration Values) which wasproduced by one activity can be read by another activity (e.g. Configure RTE gener-ates a description and Configure Com reads this). Usually the configuration activitiesfor the BSW modules (e.g. COM and OS) read and write the ECU Configuration.

[TR_METH_01090] Configure RTE task d The Configure RTE task is more com-plex as this additionally needs all the Atomic Software Component Implemen-tations required for that ECU. Whenever these change, e.g. because softwarecomponents have been moved to or from other ECUs, or simply another implemen-tation of a software component has been selected, the Configure RTE task mustbe repeated as well. c(RS_METH_00005, RS_METH_00003, RS_METH_00004,RS_METH_00002)

[TR_METH_01091] Configure Debug task d Finally the Configure Debug taskcan be completed. Since this configuration depends on previous configura-tion results, it should be completed last. c(RS_METH_00005, RS_METH_00003,RS_METH_00004, RS_METH_00002)

102 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 103: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.4.2 Workflow

Configure BSW and RTE

Configure ECUC

Configure OS

Configure RTE

Configure Watchdog Manager

Configure Mode Management

Configure NvMConfigure Diagnostics

Create Service Component

Configure Com

Configure IO Hardware abstraction

Configure MCAL

Configure Debug

Configure Memmap Allocation

Connect Service Component

Configure Transformer

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.37: Configure BSW and RTE

Activity Configure BSW and RTEPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief DescriptionDescription All the tasks used to configure the Basic Software Modules on an ECU.Relation Type Related Element Mul. NoteAggregates Configure Com 1Aggregates Configure Debug 1Aggregates Configure Diag-

nostics1

Aggregates Configure ECUC 1Aggregates Configure IO Hard-

ware abstraction1

Aggregates Configure MCAL 1

103 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 104: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Configure

Memmap Allo-cation

1

Aggregates Configure ModeManagement

1

Aggregates Configure NvM 1 Since the configuration of the DEMusually has impact on the data to bestored in NvM, the task ConfigureDiagnostics is assumed to precede thetask Configure NvM.

Aggregates Configure OS 1Aggregates Configure RTE 1Aggregates Configure Trans-

former1

Aggregates Configure Watch-dog Manager

1

Aggregates Connect ServiceComponent

1

Aggregates Create ServiceComponent

1

Predecessor Prepare ECU Con-figuration

1

In/out ECU ConfigurationValues

1

Table 2.32: Configure BSW and RTE

2.7.5 Update ECU Configuration

2.7.5.1 Description

In a post-build scenario, there are two loadable files generated in the end - one ofthem containing the application software, basic software and the pre-compile and linktime configuration of the basic software (referred to as ECU Executable) and theother one containing only the post-build time configuration of the basic software (BSWModule Configuration Data Loadable to ECU Memory). These two load-able files represent the initial configuration. This initial configuration can be updatedin post-build time by generating two new loadable files. In this update, the ECU Exe-cutable is not modified.

[TR_METH_01151] Update ECU Configuration activity d The update of the BSWModule Configuration Data Loadable to ECU Memory is usually done byimporting the updated EcuExtract containing the needed post-build updates to theECU configuration tool which already contains the initial ECU configuration. Basedon these updates in the EcuExtract and everything else from the initial ECU configura-tion, an updated ECU configuration shall be created (therefore we have both input and

104 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 105: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

output relations between the ECU Configuration Values and the Update ECUConfiguration activity). c(RS_METH_00004, RS_METH_00062)

2.7.5.2 Workflow

Generate Updated ECU Configuration

Update ECU Configuration

Define Integration Variant

Evaluated Variant Set

Postbuild Variant Set

Predefined Variant

ECU Extract

Diagnostic ECU Extract

ECU Configuration Values

«inoutput»

1

«output»

1

«inoutput»

0..*

«output»

0..1

1

«input»

1

«input» «nesting»

0..1

«input»

«nesting»

0..1 «input»

1 «input»

Figure 2.38: Update ECU Configuration

Activity Update ECU ConfigurationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief Description Tasks required to create the updated ECU Configuration.Description Tasks required to create the updated ECU Configuration.Relation Type Related Element Mul. NoteConsumes Diagnostic ECU

Extract0..1

Consumes ECU Extract 1Aggregates Define Integration

Variant1

Aggregates Generate UpdatedECU Configuration

1

Table 2.33: Update ECU Configuration

105 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 106: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.6 Model ECU Timing

2.7.6.1 Workflow

Model ECU Timing

Define ECU Timing

ECU Timing

ECU Extract

Basic Software Module Timing

ECU Service Connectors

ECU Extract of System Timing

«nesting»

0..1

«SPEM_Aggregation»

0..1

«input»

0..1

«input»

0..1

«input»

1..*

«input»

«output»1

Figure 2.39: Model ECU Timing

Activity Model ECU TimingPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief DescriptionDescription ECU timing model depends on ECU configuration data (BSW and

RTE) but the result of the ECU timing model shall help to optimize ECUconfiguration. The relation between "Configure BSW and RTE" and"Model ECU Timing" must be seen as an iterative work.

Relation Type Related Element Mul. NoteAggregates Define ECU Tim-

ing1

Predecessor Configure BSWand RTE

1

Table 2.34: Model ECU Timing

2.7.7 Generate BSW and RTE

2.7.7.1 Description

[TR_METH_01092] Generating BSW modules, RTE, and OS source files d Afterthe ECU Configuration is completed, the BSW modules, RTE, and OS source

106 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 107: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

files are generated. c(RS_METH_00005, RS_METH_00003, RS_METH_00004,RS_METH_00006)

Generation is the process of applying the tailored ECU Configuration Value de-scription to the software modules. This can be performed in different ways, and isdependent on the configuration classes chosen for the different modules (see 2.7.9),and on implementers choices.

For each BSW module, a generator reads the relevant parameters from the ECU Con-figuration Value description and creates code that implements the specifiedconfiguration.

In this generation step, the abstract parameters of the ECU Configuration Valuedescription are translated to hardware and implementation-specific data structuresthat fit to the implementation of the corresponding software module. The AUTOSARMethodology specification does not specify the generator tools in detail.

It is assumed however that generators perform error, consistency and completenesschecks on the part of the configuration they require for generation.

There are some alternative approaches when it comes to generation of configurationdata. See chapter A.1.2 in [10] for more details.

2.7.7.2 Workflow

Generate BSW and RTE

Generate RTE

Generate OS

Generate RTE Prebuild Dataset

Generate Local MCData Support

Generate SWC Memory Mapping Header

Generate BSW Memory Mapping Header

Generate BSW Configuration Code

Generate Compiler Configuration

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.40: Generate BSW and RTE

107 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 108: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Generate BSW Configuration Code

Generate BSW Memory Mapping Header

Generate SWC Memory Mapping Header

ECU Configuration Values

Atomic Software Component Implementation

BSW Module Configuration Data Source Code

BSW Module Configuration Header File

Standard Header Files

BSW Module Behavior Extension

BSW Module Interface Extension

BSW Module ImplementationExtension

BSW Module Vendor- Specific Configuration Parameter Definition

BSW Module Generator

BSW Module PreconfiguredConfiguration

VFB Types

Basic Software Module Implementation Description

Build Action Manifest

Generate Compiler Configuration

Figure 2.41: Generate BSW and RTE (Part 1)

108 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 109: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Generate RTE

Generate OSGenerate RTE Prebuild Dataset

Generate Local MCData Support

ECU Configuration Values

Software Component Internal Behavior

Basic Software Module InternalBehavior

Delivered Atomic Software Components

ECU Extract

RTE Source Code

RTE Prebuild Configuration Header

OS Generated Code

BSW Module Behavior Extension

BSW Module Integration Bundle

Local Measurement and Calibration SupportData

RTE Implementation Description

RTE Measurement and Calibration Support Data

BSW Scheduler Code

ECU Service Connectors

Service ComponentDescription

Calibration Parameter Value Set

1

0..*

0..*

1

1

0..*

1

1

0..1

1

1

0..1

1

1

0..*

0..*

1..*

0..1

1

1

0..*

0..1

0..1

0..1

0..*

Figure 2.42: Generate BSW and RTE(Part 2)

109 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 110: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Generate BSW and RTEPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief Description High Level view showing how to build an AUTOSAR ECU software.Description There are many possibilities how to run the configuration of the

different modules in detail (see the detailed use cases for theconfiguration classes).

This overall use case shows the generation of RTE, OS and MemoryMapping explicitly, for the other modules it shows as an example thegeneric task required for link time configuration of the modules plus thegeneric task to generate local calibration support data.

Relation Type Related Element Mul. NoteConsumes ECU Configuration

Values1

Produces BSW Module Con-figuration DataSource Code

1

Produces BSW Module Con-figuration HeaderFile

1

Produces RTE Source Code 1Aggregates Generate BS

W ConfigurationCode

1

Aggregates Generate BSWMemory MappingHeader

1

Aggregates Generate CompilerConfiguration

1

Aggregates Generate Local MC Data Support

1

Aggregates Generate OS 1Aggregates Generate RTE 1Aggregates Generate RTE

Prebuild Dataset1

Aggregates Generate SWCMemory MappingHeader

1

Predecessor Configure BSWand RTE

1

Table 2.35: Generate BSW and RTE

2.7.8 Build Executable

2.7.8.1 Description

[TR_METH_01093] Building ECU Executable d These are compiled and linkedalong with all the applications, libraries, etc. to build the ECU Executable. The

110 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 111: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

details of the various compiling and linking options are explained in the chap-ters 2.7.9.1, 2.7.9.2, 2.7.9.3 and 2.7.9.4. c(RS_METH_00006, RS_METH_00042,RS_METH_00038)

2.7.8.2 Workflow

Compile ECU Source Code Generate

ECU Executable

Generate RTE Postbuild Dataset

Measure Resources

Generate A2L

ECU Object Code ECU Executable

Map of the ECU Executable

RTE Postbuild Variants Dataset

Atomic Software Component Implementation

A2L File

ECU Configuration Values

Generation of the executable for Postbuild Configuration Data is not modeled here.

BSW Module Implementation Extension

Build Action Manifest

«output» 1

0..1

«input»

1

«input»

0..1

«input»

1

«input»

1

«input»

0..1

«input»

«output»

1

«output» 1..*

0..1

«input»

0..1

«input»

1..* «input»

0..1

«input»

«output»

0..*

«output» 1

«output» 1

«output»0..*

Figure 2.43: Build Executable

111 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 112: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Build ExecutablePackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Integrate Software for ECUBrief DescriptionDescription Describes how to build one executable and related artifacts (A2L file)

starting from the source code (and delivered object code).Relation Type Related Element Mul. NoteAggregates Compile ECU

Source Code1

Aggregates Generate A2L 1Aggregates Generate ECU Ex-

ecutable1

Aggregates Generate RTEPostbuild Dataset

1

Aggregates Measure Re-sources

1

Predecessor Generate BSWand RTE

1

Table 2.36: Build Executable

2.7.9 Configuration Classes

The development of BSW modules involve the following development cycles: com-piling, linking and downloading of the executable to ECU memory. Configuration ofparameters can be done in any of these process-steps: pre-compile time, link time oreven post-build time.

According to the process-step that does the configuration of parameters, the configu-ration classes are categorized as below

• pre-compile time

• link time

• post-build time

The configuration in different process-steps has some consequences for the handlingof ECU configuration parameters. If a configuration parameter is defined as pre-compile time, after compilation this configuration parameter can not be changed anymore.

Or if a configuration parameter is defined at post-build time the configuration parameterhas to be stored at a known memory location. Also, the format in which the BSWmodule is delivered determines in what way parameters are changeable. A sourcecode delivery or an object code delivery of a BSW module has different degrees offreedom regarding the configuration.

The configuration class of a parameter depends on the chosen implementation vari-ants of the BSW module it belongs to. However once the module is implemented, the

112 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 113: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

configuration class for each of the parameters is fixed. Choosing the right implementa-tion variant for a module depends on the type of application and the design decisionstaken by the module implementer.

Different configuration classes can be combined within one module. For example, forpost-build time configurable BSW implementations only a subset of the parametersmight be configurable post-build time. Some parameters might be configured as pre-compile time or link time.

File formats used for describing the configuration classes:

• .arxml (An xml file standardized by AUTOSAR.)

• .exe (An executable that can be downloaded to an ECU.)

• .hex (A binary file that can be downloaded to an ECU , but it can not execute byits own.)

• .c (A C-source file containing either source code or configuration data.)

• .h (A header file for either source code or configuration data.)

• .obj (A object file for either source code or configuration data.)

[TR_METH_01115] A mix of parameters with different configuration classeswithin a BSW module is allowed d In a real implementation of a BSW module allconfiguration parameters are most likely not in the same configuration class. I.e itwill be a mix of parameters with different configuration classes within a BSW module.c(RS_METH_00003, RS_METH_00004)

2.7.9.1 Configuration Class: Pre-compile Time

[TR_METH_01095] Configuration Class: Pre-compile Time d([TPS_ECUC_01031], see [10]) This type of configuration is a standalone con-figuration done before compiling the source code. That means parameter valuesfor those configurable elements are selected before compiling and will be effectiveafter compilation time. The value of the configurable parameter is decided in earlierstage of software development process and any changes in the parameter valuecalls for a re-compilation. The contents of pre-compile time parameters can notbe changed at the subsequent development steps like link time or post-build time.c(RS_METH_00004, RS_METH_00062)

2.7.9.1.1 Description

The work breakdown structure shows two approaches:

[TR_METH_01096] Generating header files only d The first approach is to generate aBSW Module Configuration Header File, then compile the module core code

113 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 114: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

using this header file. In this case the module core code is not touched by the BSWConfiguration Generator. c()

[TR_METH_01097] Generating header and source files d An alternative ap-proach, in which the BSW Configuration Generator generates the com-plete, configuration-specific BSW Module Configuration Header Files plusBSW Module Completely Generated Source Code. In this case, no core codeexist. c()

Both approaches are equally valid.

Whenever the decision of parameter value must be taken before the selection of otherdependable parameters, pre-compile time configuration is the right choice. For exam-ple, the algorithm choice for CRC initial checksum parameter is based on the selectionof CRC type (CRC16 or CRC32). When CRC16 is selected, there will be increase inprocessing time but reduction in memory usage. Whereas when CRC32 is selected,there will be decrease in processing time but increase in memory usage. The correctchoice should be made by the implementer before compilation of source code basedon the requirement and resource availability.

Sample cases where pre-compile time configuration can be adopted are:

• Configure the number of memory tables and block descriptor table of NVRAMmanager.

• Enable the macro for the development error tracing of the software modules.

114 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 115: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.9.1.2 Workflow

ECU ConfigurationValues

Basic Software Module Object Code

BSW Module Completely Generated Source Code

BSW Module Configuration Header File

Generate BSW Source Code

Generate BSW Precompile Configuration Header

Compile Configured BSW

Compile Generated BSW

Basic Software Module Core Source Code

ECU Executable

Source code is completely generated

Only Configuration header is generated

Link ECU Code after Precompile Configuration

Possible existence of unbound Pre-Compile time variation points.

All Pre-compile time variation points are bound.

No existence of unbound Pre-Compile time variation points. Link-time and post-build variation points may sti ll be unbound.

Possible existence of unbound Pre-Compile time variation points.

1

«input»

«output»

1

«output»

1

1

«input»

1

«input»

1

«input»

1

«input»

1

«input»

«output»

1

«output»

1

1..*

«input»

«output»

1

«output»

1

Figure 2.44: Pre-compile time configuration overview

Further description of the PreCompile binding time can be found in Section 2.16.3.6.

115 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 116: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Do Pre Compile Configuration

Compile Configured BSW

Generate BSW Source Code

Compile Generated BSW

Link ECU Code after Precompile Configuration

Generate BSW Precompile Configuration Header

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.45: Pre compile time configuration activities

Activity Do Pre Compile ConfigurationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Pre Compile ConfBrief DescriptionDescription [from ecuc sws 1031] This type of configuration is a standalone

configuration done before compiling the source code. That meansparameter values for those configurable elements are defined beforecompiling and will be effective after compilation time. The value of theconfigurable parameter is decided in an earlier stage of softwaredevelopment process and any changes in the parameter value calls fora re-compilation. The contents of pre-compile time parameters cannotbe changed at the subsequent development steps like link time orpost-build time.

Relation Type Related Element Mul. NoteAggregates Compile Config-

ured BSW1

Aggregates Compile Gener-ated BSW

1

Aggregates Generate BSWPrecompile Con-figuration Header

1

Aggregates Generate BSWSource Code

1

Aggregates Link ECU Codeafter PrecompileConfiguration

1

Table 2.37: Do Pre Compile Configuration

116 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 117: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.9.2 Configuration Class: Link Time

[TR_METH_01098] Configuration Class: Link Time d ([TPS_ECUC_01032],see [10]) This type of configuration is done for the BSW module during link time.That means the object code of the BSW module receives parts of its configurationfrom another object code file or it is defined by linker options. Link time parametersare typically used when delivering object code to the integrator. c(RS_METH_00004,RS_METH_00062)

2.7.9.2.1 Description

This configuration class provides a modular approach to the configuration process. Aseparate module will handle the configuration details and those parameter values willbe made available to the other modules during the linking process.

[TR_METH_01099] Generation and compilation of BSW Configuration Code dThe first step is to Generate BSW Configuration Code, which produces the BSWModule Configuration Data Source Code and the BSW Module Configu-ration Header File. These are compiled along with the Basic Software Mod-ule Core Header into the BSW Module Configuration Data Object Code.c()

[TR_METH_01100] Definition of configuration data d The configuration parameterdata is defined in a common header file Basic Software Module Core Headerand included by both Basic Software Module Core Source Code and BSWModule Configuration Data Source Code. The module source file needs thisheader file to resolve the references and module configuration source file will need it inorder to cross check the declaration of data type against the definition. c()

[TR_METH_01101] Separate compilation of module source and configuration filed Both module source file and module configuration source file are compiled separatelyto generate Basic Software Module Object Code and BSW Module Config-uration Data Object Code respectively. c()

[TR_METH_01102] Linking process d During the linking process, the configurationdata will be available to Basic Software Module Object Code by resolving theexternal references. c()

[TR_METH_01103] Re-generation in case of configuration value changes dWhenthe values of configuration parameters change the Basic Software Module Ob-ject Code needs to be re-generated. c(RS_METH_00004)

Sample cases where Link time configuration can be adopted are:

• Initial value and invalid value of signal

• Unique channel identifier configured for the respective instance of the NetworkManagement.

117 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 118: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

• Logical handle of CAN network.

• Identifier and type of Hardware Reception Handle and Hardware Transmission

• Handle for CAN interface.

• Definition of ComFilterAlgorithm.

• COM callback function to indicate RTE about the reception of an invalidated sig-nal.

2.7.9.2.2 Workflow

ECU Configuration Values

Basic Software Module Object Code

ECU Executable

Generate BSW Configuration Code

Basic Software Module Core Header

Compile Unconfigured BSW

Basic Software Module Core Source Code

BSW Module Configuration Header File

BSW Module Configuration Data Source Code

Compile BSW Configuration Data

BSW Module Configuration Data Object Code

Link ECU Code duringLink Time Configuration

Possible existence of unbound Link time variation points.

No existence of unbound Link time variation points. Unbound Post-build variation points may stil l exist.

All Link time variation points are bound.

No existence of unbound Link time variation points. Post-build variation points may sti l l be unbound.

1 «input»

1..*

«input»

1..*

«input»

«output» 1

«output»

1

«output» 1

1

«input»

1

«input»

1 «input» «output» 1

1 «input»

1

«input»

«output»

1

Figure 2.46: Overview Link Time Configuration

Further description of the LinkTime binding time can be found in Section 2.16.3.8.

118 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 119: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Do Link Time Configuration

Compile Unconfigured BSW

Link ECU Code duringLink Time Configuration

Compile BSW Configuration Data

Generate BSW Configuration Code

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.47: Link time configuration

Activity Do Link Time ConfigurationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Link Time ConfBrief DescriptionDescription [from ecuc sws 1032] This type of configuration is done for the BSW

module during link time. That means the object code of the BSWmodule receives parts of its configuration from another object code fileor it is defined by linker options. Link time parameters are typicallyused when delivering object code to the integrator.

Relation Type Related Element Mul. NoteAggregates Compile BSW

Configuration Data1

Aggregates Compile Unconfig-ured BSW

1

Aggregates Generate BSW ConfigurationCode

1

Aggregates Link ECU Codeduring Link TimeConfiguration

1

Table 2.38: Do Link Time Configuration

2.7.9.3 Configuration Class: Post-build Time

[TR_METH_01104] Configuration Class: Post-build Time d ([TPS_ECUC_04006],see [10]) This type of configuration is possible after building the BSW module or theECU software. The BSW module gets the parameters of its configuration by download-

119 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 120: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

ing a separate file to the ECU memory, avoiding a re-compilation and re-build of theBSW module. c(RS_METH_00004, RS_METH_00062)

2.7.9.3.1 Description

[TR_METH_01105] Generate BSW Postbuild Configuration Code d In order to makethe post-build time re-configuration possible, the re-configurable parameters shall bestored at a known memory location of the ECU memory. In this approach the BasicSoftware Module Core Source Code is compiled and linked independently of itsconfiguration data. The BSW Configuration Generator generates the configura-tion data as BSW Module Configuration Data Source Code that is compiledand linked independently of the core source code. c()

The generation of the post-build configuration is a process that can be done multi-ple times. The first time it is done during the creation of the initial ECU configurationwhich includes the generation of both ECU Executable and BSW Module Config-uration Data Loadable to ECU Memory binary files. This approach is shownin Figure 2.48. After this, the post-build configuration may be updated (the updatesusually originate from the ECU Extract) separately from the ECU Executable asmany times as needed according to the process shown in Figure 2.49.

Sample cases where post-build time configuration can be adopted are:

• Identifiers of the CAN frames

• CAN driver baudrate and propagation delay

• COM transmission mode, transmission mode time offset and time period

• Enabling/disabling signal transmission

• Frame packing

• Signal gateway

• LIN/FlexRay schedule

120 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 121: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.7.9.3.2 Workflow

ECU ConfigurationValues

Generate BSW Postbuild Configuration Code BSW Module

Configuration Header File

BSW Module Configuration Data Source Code

Compile BSW Configuration Data

BSW Module Configuration Data Object Code

Link ECU Code during Post-Build Time

BSW Module Configuration Data Loadable to ECU Memory

Compile Unconfigured BSW

Basic Software Module Core Header

Basic Software Module Core Source Code

Basic Software Module Object Code

Generate ECU Executable ECU Executable

Possible existence of unbound Post-build time variation points.

1..*

«input»

0..*

«input»

«output»

1

«output»1

1 «input» «output» 1

1

«input»

«output» 1

«output»

1

1

«input»

1 «input»

«output» 1

1 «input»

1

«input»

Figure 2.48: Overview of initial Post-Build Configuration

121 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 122: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

ECU ConfigurationValues

Generate BSW Postbuild Configuration Code BSW Module

Configuration Header File

BSW Module Configuration Data Source Code

Compile BSW Configuration Data

BSW Module Configuration Data Object Code

Link ECU Code during Post-Build Time

BSW Module Configuration Data Loadable to ECU Memory

Basic Software Module Core Header

Possible existence of unbound Post-build time variation points.

«output»

1

1..*

«input»

«output» 1

«output»

1

«output» 11 «input» 1 «input»

1

«input»

1

«input»

Figure 2.49: Update of the Post-Build Configuration

Further description of the PostBuild binding time can be found in Section 2.16.3.9.

Do Post Build Configuration

Link ECU Code during Post-Build Time

Generate ECU Executable

Compile Unconfigured BSW

Compile BSW Configuration Data

Generate BSW Postbuild Configuration Code

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

Figure 2.50: Work Flow for Post-Build Configuration

122 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 123: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Do Post Build ConfigurationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::ECU::

Post Build ConfBrief DescriptionDescription [from ecuc sws 4006] This type of configuration is possible after

building the BSW module or the ECU software. The BSW module getsthe parameters of its configuration by downloading a separate file tothe ECU memory, avoiding a re-compilation and re-build of the BSWmodule.

Relation Type Related Element Mul. NoteAggregates Compile BSW

Configuration Data1

Aggregates Compile Unconfig-ured BSW

1

Aggregates Generate BSWPostbuild Configu-ration Code

1

Aggregates Generate ECU Ex-ecutable

1

Aggregates Link ECU Codeduring Post-BuildTime

1

Table 2.39: Do Post Build Configuration

2.7.9.4 Handling of different post-build variants in configuration classes

2.7.9.4.1 Description

[TR_METH_01108] Generating multiple post-build configuration variants d In thisuse case, the BSW Configuration Generator generates two or more variantsof configuration parameters within BSW Module Configuration Header Filesand BSW Module Configuration Data Source Code. The configuration datais compiled and linked together with the Basic Software Module Core SourceCode. The resulting ECU Executable includes all configuration variants as well as thesource code of the BSW module. I.e. it is not possible to exchange the configurationdata without re-building the entire executable. c(RS_METH_00062)

[TR_METH_01150] Including different post-build variants dDifferent post-build vari-ants are included in the configuration by specifying different variation points which shallbe bound at post-build time. This can be done regardless of the configuration class, asshown in the notes of 2.44, Figure 2.46 and Figure 2.48. c(RS_METH_00062)

123 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 124: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.8 Components and Services

2.8.1 Purpose

This use case focuses on the activities required to use and configure AUTOSAR Ser-vices. It is therefore a subset of the overall use case (see 2.1).

2.8.2 Description

[TR_METH_02000] Use of AUTOSAR Services dAtomic Software Components canuse AUTOSAR Services. In order to do so, two things have to be defined on the VFBand Software Component level:

• The ports which are to be connected to the Service during ECU integration (this isa sub-task of Define VFB Application Software Component). The portinterfaces used for service ports should be standardized.

• The needs to configure the Service (for example NvM blocks or symbolic namesfor diagnostic events) from the perspective of the single Software Compo-nent (this is a sub-task of Define Atomic Software Component Inter-nal Behavior.)

c(RS_METH_00002, RS_METH_00033)

The service ports have impact on the component API just like any other port, so there isno difference between service ports and "normal" ports with respect to API generation.

When the Application Software Components are mapped to an ECU their descriptionis put into the corresponding ECU Extract. These activities belong to the Systemdomain (see 2.5.6) and are not explicitly shown in this use case.

As part of the ECU integration, additional artifacts are generated to connect the serviceports over the RTE: Service Component Descriptions, including their mappingto the Basic Software Modules, and the connectors between their ports and the serviceports of the Application Software Components.

The use case shows also the creation of ECU configuration of the corresponding BasicSoftware Module (e.g. DEM, DCM, Watchdog Manager etc.). This must be done withrespect to the service ports and the Service Needs of all Application SoftwareComponents connected to the corresponding Service Component (the diagram showsonly the configuration activity of diagnostics as an example).

2.8.3 Workflow

Figure 2.51 shows the work sequence assumed for this use case. The next two fig-ures 2.52 and 2.53 show the tasks and work products of the method library involved inthe activities on the VFB and Component resp. the ECU level.

124 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 125: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Components and Services

Add Service Ports and Service Needs

Connect and Configure Service Module on ECU

Define VFB Application Software Component

Define Atomic Software ComponentInternal Behavior

Generate Atomic Software Component Contract Header Files

Implement Atomic Software Component

Generate Base Ecu Configuration

Generate BSW Source Code

Create Service Component

Generate RTE

«predecessor»

+Add Service Needs toAtomic Component

«nesting»

+Re-Implement AtomicSoftware Component withService Ports

«nesting»

+Add Service Ports toAtomic SoftwareComponent

«nesting»

+Re-generate ContractHeader Files withService Intefaces

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.51: Use Case: Components and Services

125 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 126: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Process Pattern Components and ServicesPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Components and ServicesBrief Description This use case focuses on the activities required to use and configure

AUTOSAR Services. It is therefore a subset of the overall use case(Methodology Overview).

Description Atomic Software Components can use AUTOSAR Services. In order todo so, two things have to be defined: The ports which are to beconnected to the Service during ECU integration and in addition theneeds to configure the Service (for example NvM blocks or symbolicnames for diagnostic events) from the perspecive of the singleSoftware Component.

The service ports have impact on the component API just like anyother port, so there is no difference between service ports and"normal" ports with respect to API generation.

Afterwards the Application Software Components are mapped to anECU and their description is put into the corresponding ECU extract(deliverable Complete ECU Description). These activities belong to thesystem domain and are not explictly shown in this use case (seeMethodology Overview).

As part of the ECU integration, additional artifacts are generated toconnect the service ports over the RTE: Service ComponentDescriptions, including their mapping to the Basic Software Modules,and the connectors between their ports and the service ports of theAppplication Software Components.

The ECU configuration of the Basic Software Module (e.g. DEM, DCM,Watchdog Manager etc.) is then created with respect to the serviceports and the SeviceNeeds of the Application Software Componentsconnected to that Service.

Relation Type Related Element Mul. NoteAggregates Add Service Ports

and Service Needs1

Aggregates Connect and Con-figure ServiceModule on ECU

1

Table 2.40: Components and Services

126 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 127: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Define VFB Application Software Component

VFB Atomic Application Software Component

VFB Atomic Software Component

Define Atomic SoftwareComponent Internal Behavior

Generate Atomic Software Component Contract Header FilesSoftware Component Internal

Behavior

Application Header File

Implement Atomic Software Component

Atomic Software Component Source Code

«output»

1

«output»

1

1

«input»

1 «input»

1 «input»

1

«input»

«output»

1

«extends»

«output»

1

1

«input»

Figure 2.52: Add Service Ports and Service Needs - Detailed view with work products

127 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 128: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Add Service Ports and Service NeedsPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Components and ServicesBrief DescriptionDescription Atomic Software Components can use AUTOSAR Services. In order to

do so, two things have to be defined:

• The ports which are to be connected to the Service during ECUintegration (this is a sub-task of Define VFB ApplicationSoftware Component). The port interfaces used for service portsshould be standardized.

• The needs to configure the Service (for example NvM blocks orsymbolic names for diagnostic events) from the perspecive ofthe single Software Component (this is a sub-task of DefineAtomic Software Component Internal Behavior)

The service ports have impact on the component API just like anyother port, so there is no difference between service ports and"normal" ports with respect to API generation.

Relation Type Related Element Mul. NoteAggregates Define Atomic

Software Com-ponent InternalBehavior

1 Add Service Needs to AtomicComponent:

Aggregates Define VFB Ap-plication SoftwareComponent

1 Add Service Ports to Atomic SoftwareComponent:

Aggregates Generate AtomicSoftware Com-ponent ContractHeader Files

1 Re-generate Contract Header Files withService Intefaces:

Aggregates Implement AtomicSoftware Compo-nent

1 Re-Implement Atomic SoftwareComponent with Service Ports:

Table 2.41: Add Service Ports and Service Needs

128 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 129: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Create Service Component

Generate Base Ecu Configuration

Generate RTE

ECU Service Connectors

ECU Extract

Service Component Description

Generate BSW Source Code

ECU Configuration Values

Configure Diagnostics

Diagnosis is used as an example here.

Connect Service Component

«output»

1

1

«input»

1

«input»

0..*

«input»

«output»

1..*

1

«input»

1 «input»

0..*

«input»

1

«input»

«output»

1

1

«input»

0..1

«input»0..1 «input»

«inoutput» 1

«output»

0..1

«output»

1

1

«input»

Figure 2.53: Connect and Configure Service Module on ECU - Detailed view with workproducts

Activity Connect and Configure Service Module on ECUPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Components and ServicesBrief DescriptionDescription As part of the ECU integration, additional artifacts are generated to

connect the service ports over the RTE: Service ComponentDescriptions, including their mapping to the Basic Software Modules,and the connectors between their ports and the service ports of theAppplication Software Components.

The ECU configuration of the Basic Software Module (e.g. DEM, DCM,Watchdog Manager etc.) is then created with respect to the serviceports and the SeviceNeeds of the Application Software Componentsconnected to that Service (the diagram shows only the configurationactivity of diagnostics as an example). The code gneration of theservice module (e.g. DEM, DCM) and of the RTE is shown forcompleteness.

Relation Type Related Element Mul. Note

129 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 130: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Create Service

Component1

Aggregates Generate BSWSource Code

1

Aggregates Generate BaseEcu Configuration

1

Aggregates Generate RTE 1Predecessor Add Service Ports

and Service Needs1

Table 2.42: Connect and Configure Service Module on ECU

2.9 Calibration Overview

2.9.1 Purpose

This use case describes the typical activities required from the creation or update ofcalibration parameters down to the creation or update of the A2L Files.

2.9.2 Description

The use cases assumes, that calibration parameters are changed in an already existingsystem, thus the tasks required to define and build a new system are omitted, only thecalibration relevant steps are shown.

In addition, the use case includes the (optional) task of updating a set of calibrationparameter values as input for the RTE.

As far as AUTOSAR artifacts are involved, this use case can be divided into four majoractivities:

[TR_METH_02001] Define Cross-component Calibration Parametersactivity d Define Cross-component Calibration Parameters: Containsthe tasks used to define or update cross-component calibration parameters.These parameters have to be provided via ports by Parameter Components.c(RS_METH_00002)

[TR_METH_02002] Define Local Calibration Parameters activity d De-fine Local Calibration Parameters: Contains the tasks used to define or up-date component-local calibration parameters or calibration parameters defined withina BSW module. These parameters are declared within the Internal Behaviorof the component (or the BSW module) which uses them. c(RS_METH_00002,RS_METH_00003)

[TR_METH_02003] Provide Unique Parameter Names activity d ProvideUnique Parameter Names: Contains the tasks used to provide unique names for

130 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 131: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

calibration parameters. A Flat Map is used to provide unique names for MCD tools.An Alias Name Set can be provided additionally in cases, where this is not suffi-cient. c(RS_METH_00005)

[TR_METH_02004] Re-generate RTE and Calibration Support activity dRe-generate RTE and Calibration Support: Contains the tasks used to re-generate relevant artifacts during ECU integration (before the final build) after an up-date of calibration parameters. c(RS_METH_00020)

2.9.3 Workflow

Figure 2.54 shows the work sequence assumed for this use case.

131 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 132: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Calibration Overview

Define Cross-component Calibration Parameters

Define Local Calibration Parameters

Provide Unique Parameter Names

Re-generate RTE and Calibration Support

Generate ECU Extract

Define VFB Interfaces

Define VFB Types

Define VFB Parameter Component

Define VFB Composition Component

Define Atomic Software ComponentInternal Behavior

Define Partial Flat Map

Define Alias Names

Generate or Adjust System Flat Map

Generate ECU Executable

Generate A2L Generate RTE

Provide RTE Calibration Dataset

Generate Local MCData Support

Define BSW Behavior

Generate BSW Configuration Code

Create MC Function Model

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

+Define VFB Types forParameter Interfaces

«nesting»

«predecessor»

«nesting»

«nesting»

«predecessor»

«nesting»

«nesting»

«nesting»

+Define localCalibrationParameters inBSW

«nesting»

+Define VFB typesfor LocalCalibration

«nesting»

«nesting»

«predecessor»

+Define CalibrationParameters inInternal Behavior

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.54: Use Case: Calibration Overview

132 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 133: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Process Pattern Calibration OverviewPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Calibration OverviewBrief Description Describe the required steps to update the calibrations data down to an

update of the A2L files.Description This use case shows the typical steps required from an updated design

of calibration data down to an update of the A2L file. The use casesassumes, that calibration parameters are changed in an alreadyexisting system, thus the steps required to define and build a newsystem are omitted, only the calibration relevant steps are shown.

In addition, the use case includes the (optional) task of updating a setof calibration parameter values as input for the RTE.

Relation Type Related Element Mul. NoteAggregates Define Cross-

component Cali-bration Parameters

1

Aggregates Define Local Cali-bration Parameters

1

Aggregates Generate A2L 1Aggregates Generate ECU Ex-

ecutable1

Aggregates Provide UniqueParameter Names

1

Aggregates Re-generate RTE and CalibrationSupport

1

Table 2.43: Calibration Overview

Activity Define Cross-component Calibration ParametersPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Calibration OverviewBrief DescriptionDescription Contains the tasks used to define or update cross-component

calibration parameters. These parameters are provided by ParameterComponents.

Relation Type Related Element Mul. NoteAggregates Define VFB Com-

position Compo-nent

1

Aggregates Define VFB Inter-faces

1

Aggregates Define VFB Pa-rameter Compo-nent

1

Aggregates Define VFB Types 1 Define VFB Types for ParameterInterfaces: Use this task to define VFBTypes for Parameter Interfaces

Table 2.44: Define Cross-component Calibration Parameters

133 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 134: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Define Local Calibration ParametersPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Calibration OverviewBrief DescriptionDescription Contains the tasks used to define or update component-local (or

module-local) calibration parameters. These parameters are declaredwithin the Internal Behavior of the component (or BSW module) whichuses them.

Relation Type Related Element Mul. NoteAggregates Define Atomic

Software Com-ponent InternalBehavior

1 Define Calibration Parameters in InternalBehavior: Use this task to define localcalibration parameters as part of theInternal Behavior of a softwarecomponent.

Aggregates Define BSW Be-havior

1 Define local Calibration Parameters inBSW: Use this task to define localcalibration parameters as part of theInternal Behavior of a BSW module.

Aggregates Define Partial FlatMap

1 Define (optionally) a Partial Flat Map forone or more delivered components.

Aggregates Define VFB Types 1 Define VFB types for Local Calibration:Use this task to define VFB types forLocal Calibration.

Table 2.45: Define Local Calibration Parameters

Activity Provide Unique Parameter NamesPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Calibration OverviewBrief DescriptionDescription Contains the tasks used to provide unique names for calibration

parameters. A Flat Map is used to provide unique names for MCDtools. An Alias Name Set can be provided in cases, where this is notsufficient.

Relation Type Related Element Mul. NoteAggregates Define Alias

Names1

Aggregates Generate ECU Ex-tract

1 Use this activity to update the ECUExtract. This includes updating the ECUFlat Map if parameter names on ECUlevel have changed.

Aggregates Generate or AdjustSystem Flat Map

1 Use this task if parameter names aredefined on system level.

Predecessor Define Cross-component Cali-bration Parameters

1

Predecessor Define Local Cali-bration Parameters

1

Table 2.46: Provide Unique Parameter Names

134 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 135: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Re-generate RTE and Calibration SupportPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Calibration OverviewBrief DescriptionDescription Contains the tasks used to re-generate relevant artifacts during ECU

integration (before the final build) after an update of calibrationparameters.

Relation Type Related Element Mul. NoteAggregates Create MC Func-

tion Model1 This use case shows the creation of an

MC Function Model as part of the activitythat generates also the RTE andcalibration support data.

This is only one possibility. It is alsopossible to create an MC Function Modelearlier in the process (as part of thedesign activities) or later (shortly beforethe A2L is generated).

Aggregates Generate BSW ConfigurationCode

1 Use this task to generate the descriptionof calibration parameters in BSW that area result of ECU configuration.

Such parameters will be described withinthe artifact BSW Module BehaviorExtension.

Aggregates Generate Local MC Data Support

1 Use this task to generate support forcalibration data that are not handled viathe RTE.

Aggregates Generate RTE 1 Use this task to generate support forcalibration data that are handled over theRTE.

This includes cross-componentcalibration as well as local calibration (inSWC and BSW) that needs emulationsupport by the RTE.

Aggregates Provide RTE Cali-bration Dataset

1

Predecessor Provide UniqueParameter Names

1

Table 2.47: Re-generate RTE and Calibration Support

2.10 Memory Mapping

2.10.1 Purpose

This use case gives a comprehensive view on the tasks required to define, configureand generate header files for memory mapping and for the compiler abstraction relatedto memory aspects. The underlying concepts are specified in [11] and [12].

135 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 136: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.10.2 Description

[TR_METH_02005] Memory sections for data and code d AUTOSAR basic softwareas well as application software use a standardized preprocessor mechanism in order todefine memory sections for their data and code as well as compiler memory classes2

defined globally or per section. The goal of this mechanism is to maintain the compilerspecific statements and the ECU specific mappings separately from the main code.c(RS_METH_00002, RS_METH_00003, RS_METH_00004, RS_METH_00038)

With AUTOSAR it is possible to derive (i.e. generate) the content of these headerfiles from XML artifacts. This use case shows how the required artifacts and tasks arerelated.

2.10.3 Workflow

Figure 2.55 shows the work sequence assumed for this use case. The next figures 2.56and 2.57 show the involved tasks and work products of the method library.

Note that this use case ends with compilation of the code. The assignment of memorysections to the actual hardware (which is typically done by the configuration of thelinker) is currently not considered to be part of the AUTOSAR methodology.

2This determines far and near addressing on certain platforms.

136 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 137: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Memory Mapping Overview

Configure Memmap Allocation

Define Memory Addressing Modes

Generate BSW Memory Mapping Header

Compile BSW Core Code

Compile Atomic Software Component

Generate SWC Memory Mapping Header

Compile ECU Source Code

Configure Compiler Memory Classes

Generate Compiler Configuration

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.55: Use Case: Memory Mapping

137 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 138: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Define Memory Addressing Modes

Configure Memmap Allocation

Generate BSW Memory Mapping Header

Generate SWC Memory Mapping Header

BSW Module Preconfigured Configuration

ECU Configuration Values

VFB Types

Basic Software Module Implementation Description

Standard Header Files

Compile Atomic Software Component

Compile BSW Core Code

Compile ECU Source Code

Per compiler platform

Per BSW module/cluster and build environment.

Per component and build environment.

Per build environment.

Atomic Software Component Implementation

+SwAddrMethod

1..*

«input»

+MemMapAddressingModeSet

1..*

«input»

+MemorySections

0..*

«input»

+MemorySections

0..*

«input»

«output»

+MemMapAllocation1

«input»

1

«output»

+BSW_MemMap1

«output»

+SWC_MemMap

1

+MemMapAddressingModeSet

1..*

«input»

+moduleDescription

0..1

«input»

+DependencyOnArtifact

1

«input»

+SwAddrMethods

0..*

«input»

+MemMapAllocation

1

«input»

«output»

+MemMapAddressingModeSet 1..*

+MemorySections1

«input»

+MemMapAddressingModeSet

1..*

«input»

+MemorySections

1

«input»

+RteImplementationRef0..1

«input»

+MemMapAllocation

1

«input»

+SwAddrMethod

1..*

«input»

1 «input»

1

«input»

Figure 2.56: Memory Mapping - Detailed view with work products

138 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 139: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

BSW Module Preconfigured Configuration

Configure Compiler Memory Classes

Per compiler platform

ECU Configuration Values

Basic Software Module Implementation Description

VFB Types

Generate Compiler Configuration

Standard Header Files

Compile Atomic Software Component

Compile BSW Core Code

Compile ECU Source Code

Per build environment.

Atomic Software Component Implementation

1 «input»

1

«input»

«output»

+Compiler_Cfg

«input»

1

+MemorySections1..*

«input»

+RteImplementationRef0..1

«input»

+CompilerMemClassConfiguration

1..*

«input»

+MemorySections 0..*

«input»

+ModuleDescription0..1

«input»+SwAddrMethod

1..*

«input»

«output»

+MemMap config forcompiler memclasses

1..*

Figure 2.57: Compiler Configuration - Detailed view with work products

Activity Memory Mapping OverviewPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Memory Mapping OverviewBrief DescriptionDescription Overview of the work sequence for defining and configuration of

memory sections.Relation Type Related Element Mul. NoteAggregates Compile Atomic

Software Compo-nent

1

Aggregates Compile BSWCore Code

1

139 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 140: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Compile ECU

Source Code1

Aggregates Configure Com-piler MemoryClasses

1

Aggregates ConfigureMemmap Allo-cation

1

Aggregates Define MemoryAddressing Modes

1

Aggregates Generate BSWMemory MappingHeader

1

Aggregates Generate CompilerConfiguration

1

Aggregates Generate SWCMemory MappingHeader

1

Table 2.48: Memory Mapping Overview

2.11 E2E Protection

2.11.1 Purpose

This Activity provides a rough outline of the creation of E2E Protection to securecommunication flow in an AUTOSAR Architecture. [13]

2.11.2 Description

E2E Protection mechanisms are needed when safety related data exchanges needto be protected at runtime against communication link faults.

[TR_METH_02006] E2E Protection d The E2E Protection in AUTOSAR is real-ized as an E2E Transformer Module [13] which is invoked by the RTE. First of all, theSerializer Transformer serializes the data and then the RTE invokes E2E Transformerto protect the communication. The software component communicates through RTEusing the plain RTE API. c(RS_METH_00005)

[TR_METH_01153] Configuration and Generation of the E2E Transformer d Ac-cording to the generic transformer approach, the E2E Transformer can be configuredat the system level (Inter-ECU communication). The generation of the E2E Transformermodule is done based on the System Description. No ECU configuration is needed.c(RS_METH_00005)

140 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 141: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01154] Define E2E Transformer Technology Task d The task De-fine E2E Transformer Technology is needed to define all information requiredfor the generation of the E2E transformer module like pre-defined Profiles and statemachine configuration. c(RS_METH_00005)

2.11.3 Workflow

Figure 2.58 shows the Define E2E Transformer Technology task which ismainly processed in the activity Design Communication.

Define E2E Transformer Technology

System Engineer

Interaction Layer

«output»

+E2E Transformer Technology

1

+ISignals

1

«input»

1

«performs»

Figure 2.58: Task Define E2E Transformer Technology

2.12 Diagnostic Extract

2.12.1 Purpose

This use case provides a rough outline of the diagnostics configuration using the Di-agnostic Extract Template [14]. The involved activities and deliverables will be refinedbased on the experience in the field in next AUTOSAR releases.

2.12.2 Description

The distributed nature of an AUTOSAR ECU development requires an optimized cap-turing of information. In particular, diagnostic information (i.e. DEM and DCM configu-ration) shall be captured only once by the person with the best knowledge and thereforebeing able to take responsibility better than one centralized individual. ECU configura-tion is not suitable to be exchanged between partners in an ECU development project.Therefore, AUTOSAR defines the Diagnostic Extract Template that represents a stan-dardized exchange format on diagnostic functionality. The Diagnostic Extract Templateallows the decentralized configuration of diagnostic aspects. The basic usage of theDiagnostic Extract Template is the exchange of diagnostic data between the different

141 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 142: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

parties involved in the diagnostic development process to allow the configuration of theDCM and the DEM and to provide the description of corresponding application inter-faces to implement diagnostic services and fault handling. In the AUTOSAR Method-ology the Diagnostic Extract is represented by the deliverable Diagnostic Extractand its sub-deliverables.

[TR_METH_01136] Content of Diagnostic Extract d The deliverable Diagnos-tic Extract contains all relevant diagnostics aspects.

• Diagnostic Services (e.g. IOControl, MemoryByAddress)

• Diagnostic Event Handling (e.g. events, trouble codes, conditions)

• Mappings (Service Mappings, Diagnostic Mappings, etc.)

c(RS_METH_00082)

[TR_METH_01137] Diagnostic Extract category d Depending on the phase inthe process, the Diagnostic Extract can have several categories that are repre-sented as specialized deliverables:

• Diagnostic Abstract System Description: This deliverable representsa high-level definition that can be taken as a template for creating concrete Di-agnostic System Extracts or Diagnostic ECU Extracts.

• Diagnostic System Extract: This deliverable represents the diagnostic as-pects for several ECUs.

• Diagnostic ECU Extract: This deliverable represents the diagnostic as-pects for a single ECUs.

c(RS_METH_00082)

[TR_METH_01138] Decentralized configuration d The timing and frequency of ex-changes and the content in each of these exchanged files is highly dependent on theindividual project setup and situation. The Diagnostic Extract Template has been de-signed to support the decentralized and independent definition of diagnostic require-ments that can be linked together at a late point during the development process.The approach of decentralized configuration is met in the Diagnostic Extract Templatemainly in two ways:

• Separation of elements over several physical files: Most elements of the Diag-nostic Extract template can be split over several physical files. Therefore, parts ofthese elements (e.g. certain attributes) can be defined by, for example, an OEMand other parts of these elements by, for example, an ECU supplier.

• Usage of self-contained mappings: Many diagnostic requirements are estab-lished by mappings between diagnostic elements (e.g., DTC to DemEvent map-ping). However, the "‘decentralized configuration"’ approach requires that thesemappings can be flexibly defined at almost any time within the ECU developmentprocess and by any of the involved companies respectively roles. Therefore, theDiagnostic Extract Template defines self-contained mapping elements that have

142 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 143: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

references to two (or potentially more) diagnostic elements to define a mapping.The usage of the Diagnostic Extract Template will be restricted by the appropriateapplication of the "‘roles and rights"’ concepts in next AUTOSAR releases.

c(RS_METH_00082)

[TR_METH_01139] Roles d The relevant activities of the Diagnostic Extract use caseare logically grouped to the following roles (see diagram 2.60): Diagnostic Requester,Software Developer and Diagnostic Integrator. Obviously, the OEM acts as a diag-nostic requester and the ECU supplier as the diagnostic integrator. Nevertheless, inseveral situations (e.g. in-house development of application software components), theOEM may act as the diagnostic integrator and performs collecting and merging tasks.c(RS_METH_00082)

[TR_METH_01140] Develop Diagnostic Abstract System Descriptionactivity d The basic workflow for the configuration of the diagnostic aspects may startwith the optional activity Develop Diagnostic Abstract System Descrip-tion. This activity defines diagnostic requirements at abstract level. The resultingDiagnostic Abstract System Description may be used by the followingactivity as a basis for the Diagnostic System Extract or the Diagnostic ECUExtract. c(RS_METH_00082)

[TR_METH_01141] Development of diagnostic requirements d In the activity De-velop Diagnostic Requirements the requester of diagnostic data defines thediagnostic interfaces of one or multiple ECUs. The following tasks may be performed:

• Define the values of the DTCs

• Define the UDS services and sub-services supported by the ECUs

• Define the required events needed by a specific composition implemented by anApplication Developer

During this activity, several Develop Diagnostic Requirements from differentparties may be collected and merged. c(RS_METH_00082)

[TR_METH_01142] Diagnostic information in the context of SW-C development dThe purpose of the Diagnostic Extract during the development of software com-ponents is basically twofold: On the one side the Diagnostic System Extractmay serve as a requirement for the software developer. The diagnostic requester canspecify e.g. the following issues:

• Definition of the content of a specific ReadDataByIdentifier which has to be im-plemented by a specific SW-C

• Definition of the events needed for a certain SW-C

On the other side the application developer has the possibility to provide diagnosticinformation relevant to the SW-Cs as a part of the Diagnostic System Extractand/or using Service Needs. The Service Needs within the SW-C Description are stillto be used along with the Diagnostic System Extract in order to annotate the

143 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 144: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

SW-C ports which are relevant for further mapping and handling as defined by theDiagnostic System Extract. c(RS_METH_00082)

[TR_METH_01143] Integration of diagnostic information d In activity IntegrateDiagnostic Information, the integrator receives one or several DiagnosticSystem Extracts (or Diagnostic ECU Extracts) from the diagnostic requesterand from multiple application software or basic software developers. The main goal ofthe integration activity is to integrate and merge all delivered Diagnostic Extractsso that the configuration of the corresponding basic software modules (DCM, DEM)can be generated (activity Integrate Software for ECU).

Since the AUTOSAR Methodology does not restrict the definition of elements like DIDs,parameters of a UDS service, Events, Sessions, etc. in activity Integrate Diag-nostic Information the integrator has to ensure that the complete information isstill valid after merging it. Usually, the following task may be performed:

• Mapping of DTCs (Diagnostic Trouble Code) to events

• Merge of events

• Mapping of services

During the integration activity the following issues and conflicts may be considered:

• Some DTCs may already be mapped to events - especially in cases where bothcome from the same party. But if the DTCs are defined by the OEM and thesoftware components are implemented by other supplier acting as an applicationdeveloper the integrator has to ensure that both are mapped together.

• In some cases, an diagnostic event may be defined multiple times. An diagnos-tic requester defines the events which shall be implemented by an applicationdeveloper. A supplier implements a software component which will be used inmultiple projects and which also detects this type of error and also defines thissame event. Both events may have different naming but the same meaning. Theintegrator has to detect this redundancy during the integration and merge themtogether.

• The diagnostic requester requires a specific ReadDataByIdentifier and an appli-cation developer implements it. If the implementation is performed for one spe-cific project only, the application developer may map the DID from the diagnosticrequester to the already defined job in their software component. In other casesin which the application developer implements a generic diagnostic job, it will bea task of the diagnostic integrator to merge this information and to map the jobsto the corresponding DID.

c(RS_METH_00082)

After all issues and conflicts are resolved and the inputs are merged, the final com-plete Diagnostic ECU Extract is produced. Based on this deliverable, the initialconfiguration of the relevant basic software modules is generated (activity IntegrateSoftware for ECU).

144 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 145: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.12.3 Workflow

Diagnostic Extract Overview

Develop Diagnostic Abstract System Description

Develop Diagnostic Requirements

Develop Application Software

Integrate Diagnostic Information

Integrate Software for ECU

Develop Basic Software

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

Figure 2.59: Diagnostic Extract Overview

145 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 146: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Diagnostics Integrator

Software DeveloperDiagnostic Requester

Develop Diagnostic Abstract System Description

Develop Diagnostic Requirements

Integrate Diagnostic Information

Develop Application Software

Integrate Software for ECU

Diagnostic ECU Extract

Diagnostic Abstract System Description

Diagnostic System Extract

Develop Basic Software

0..*

«input»

«output» 0..* «output»

0..*

«output»

0..*

«output»

1

«output»

0..* «output»+complete DE

1..*

+complete DE 0..1

«input»

0..* «input»

0..*

«input»

+partial ly fi lled DE

0..* «input»

0..*

0..* «input»

Figure 2.60: Diagnostic Extract Workflow

Diagnostic Extract

Diagnostic Abstract System Description

Diagnostic System Extract

Diagnostic ECU Extract

Figure 2.61: Diagnostic Extract Deliverables

146 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 147: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Process Pattern Diagnostic Extract OverviewPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Diagnostic Extract OverviewBrief DescriptionDescriptionRelation Type Related Element Mul. NoteAggregates Develop Applica-

tion Software1

Aggregates Develop BasicSoftware

1

Aggregates Develop Diagnos-tic Abstract SystemDescription

1

Aggregates Develop Diagnos-tic Requirements

1

Aggregates Integrate Diagnos-tic Information

1

Aggregates Integrate Softwarefor ECU

1

Table 2.49: Diagnostic Extract Overview

Activity Develop Diagnostic Abstract System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Diagnostic Extract OverviewBrief DescriptionDescription This activity defines diagnostic requirements at functional/abstract

level. The resulting Diagnostic Abstract System Description may beused by the following activity as a basis for the Diagnostic SystemExtract or the Diagnostic ECU Extract.

Relation Type Related Element Mul. NoteProduces Diagnostic Ab-

stract SystemDescription

1

Table 2.50: Develop Diagnostic Abstract System Description

147 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 148: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Activity Develop Diagnostic RequirementsPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Diagnostic Extract OverviewBrief DescriptionDescription In this activity the OEM or diagnostic requirer defines the diagnostic

interfaces of one or multiple ECUs. It may also define someInternalBehaviors as requirements for the ECU-Supplier or applicationdeveloper.

The following tasks may be relevant:

• Define the values of the DTCs

• Define the UDS services and sub-services supported by theECUs

• Define the required events needed by a specific composition

Additionally, the OEM may also collect Diagnostic Extracts fromdifferent departments as well as from SW-C developers and merge theinformation into one Diagnostic Extract.

Relation Type Related Element Mul. NoteDiagnostic Ab-stract SystemDescription

0..*

Consumes Diagnostic SystemExtract

0..*

Produces Diagnostic ECUExtract

0..*

Produces Diagnostic SystemExtract

0..*

Table 2.51: Develop Diagnostic Requirements

Activity Integrate Diagnostic InformationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Diagnostic Extract OverviewBrief DescriptionDescription The main goal of this activity is to integrate all parts of the Diagnostic

Description received from the OEM and from the application developer.Based on the complete Diagnostic Extract the initial ECUC can begenerated.

Relation Type Related Element Mul. NoteConsumes Diagnostic ECU

Extract0..* partially filled DE:

Consumes Diagnostic SystemExtract

0..*

Produces Diagnostic ECUExtract

1..* complete DE:

Table 2.52: Integrate Diagnostic Information

148 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 149: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.13 Rapid Prototyping

2.13.1 Purpose

This use case describes usual activities to enable rapid prototyping in AUTOSAR.

2.13.2 Description

Rapid prototyping can be used during electronic control unit development to evaluateand test new software control algorithms for various functions.

With Fullpass technology the original ECU is totally replaced by a Rapid PrototypingUnit (RPU). With Bypass technology the original ECU and software stays in the con-trol loop to supports the majority of the control algorithms and interface with sensors,actuators and communication buses: only the specific control algorithm that shall beprototyped is deported into the RPU (external bypass) or even directly executed in theoriginal ECU (internal bypass). Bypass mainly consists in replacing at run time inputsand/or outputs of the original software algorithms by value computed by the prototypealgorithm under test.

[TR_METH_01132] Definition of a Rapid Prototyping Scenario d In order toenable rapid prototyping, first of all the initial Rapid Prototyping Scenario is de-fined (task Define Rapid Prototyping Scenario). After the generation of theECU Extract the ECU Extract of Rapid Prototyping Scenario should berefined to achieve a complete rapid prototyping scenario (task Refine Rapid Pro-totyping Scenario). c(RS_METH_00002)

[TR_METH_01133] Content of Rapid Prototyping Scenario artifact d A RPTScenario consist out of two main aspects: The description of the bypass points and therelation to a hook. A bypass point describes the required preparation of the host ECU.At a bypass point the host ECU shall be capable to communicate with a RPT system inorder to support the execution of the rapid prototyping algorithms with the original datacalculated by the host system and to replace dedicated results of the host system bythe results of the rapid prototyping algorithm. The hook represents the link between abypass point and the rapid prototyping algorithm.

Obviously, the bypass point and the hook reference aspects like parameterAc-cess (dataWriteAccess, dataReadAccess, dataSendPoint, dataReceivePointByValue,dataReceivePointByArgument, writtenLocalVariable, readLocalVariable). For more de-tails see SW-C Template [5] (constr_2055). c(RS_METH_00002)

Currently, AUTOSAR supports two approaches for Rapid Prototyping: Componentwrapper method and direct buffer access method.

[TR_METH_01134] Component wrapper method d The component wrapper methodconsists in wrapping the original software component implementation with an integra-tion code (Rapid Prototyping Wrapper Header File and Rapid Prototyp-ing Wrapper Source Code) that implements the bypass. With this method the in-

149 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 150: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

tegration code is able to take the control of the AUTOSAR interfaces of the softwarecomponent because there is no more direct call between RTE and the SW-C but ev-erything go through the integration code.

In order to use this method, the RTE has to be configured properly (task ConfigureRTE, for configuration details see AUTOSAR_SWS_RTE [15], section 4.9.2). Further-more, based on the complete ECU Extract of Rapid Prototyping Scenarioartifact the corresponding wrapper code has to be generated and compiled (activityEncapsulate SW-C). Depending on the development strategy the wrapper code gen-eration may be processed in different stages of the development process.

The RTE supports the component wrapper method by generating the SW-C inter-faces with a c-namespace including an additional [Byps_] infix for the bypassed SW-C (task Generate RTE, for details see AUTOSAR_SWS_RTE [15], section 4.9.2).c(RS_METH_00006)

[TR_METH_01135] Direct buffer access method d The direct buffer access methodprovides runtime direct read and write access to the RTE buffers that implement theECU communication infrastructure. If the direct buffer access method for bypass sup-port is enabled for a software component type, the Generate RTE task produces RTEMeasurement and Calibration Support Data with mcDataAccessDetails foreach preemption area specific buffer that implements the implicit communication forthis software component type (For details see AUTOSAR_SWS_RTE [15], section4.9.3). For this method no wrapper code has to be generated. c(RS_METH_00006)

2.13.3 Workflow

Figure 2.62 shows the work sequence for this use case.

150 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 151: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Rapid Prototyping Overview

Define Rapid Prototyping Scenario

Generate ECU Extract

Extract ECU Rapid Prototyping Scenario

Generate BSW and RTE

Generate RTE

Configure BSW and RTE

Prepare ECU Configuration

Configure RTE

Generate ECU Executable

Encapsulate SW-C

Generate Rapid Prototyping Wrapper

Compile Atomic Software Component

Generate A2L

Refine Rapid Prototyping Scenario

«nesting»

«predecessor»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«predecessor»

«predecessor»

«predecessor»

«nesting»

«predecessor»

«nesting»

«nesting»

«predecessor»

«predecessor»

«nesting»

Figure 2.62: Rapid Prototyping Overview

151 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 152: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Process Pattern Rapid Prototyping OverviewPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Rapid Prototyping OverviewBrief DescriptionDescription This use case shows the typical steps required from an updated rapid

prototyping scenario down to an update of the generated RTE and theproduced A2L file. The use cases assumes, that rapid prototypingscenario is changed in an already existing system, thus the stepsrequired to define and build a new system are omitted, only thecalibration relevant steps are shown.

In addition, the use case includes the (optional) task of updating a setof calibration parameter values as input for the RTE.

Relation Type Related Element Mul. NoteAggregates Configure BSW

and RTE1

Aggregates Define Rapid Pro-totyping Scenario

1

Aggregates Encapsulate SW-C 1Aggregates Generate A2L 1Aggregates Generate BSW

and RTE1

Aggregates Generate ECU Ex-ecutable

1

Aggregates Generate ECU Ex-tract

1

Aggregates Prepare ECU Con-figuration

1

Aggregates Refine Rapid Pro-totyping Scenario

1

Table 2.53: Rapid Prototyping Overview

Activity Encapsulate SW-CPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Rapid Prototyping OverviewBrief DescriptionDescription Encapsulate the software component to enable rapid prototyping.

During this activity the wrapper code is generated based on the RapidPrototyping Scenario and the software component is compiled andlinked with the generated wrapper.

Relation Type Related Element Mul. NoteAggregates Compile Atomic

Software Compo-nent

1

Aggregates Generate RapidPrototyping Wrap-per

1

Table 2.54: Encapsulate SW-C

152 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 153: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.14 Safety Extensions

2.14.1 Purpose

This use case provides an overview of the usage of the Safety Extensions (see [16]).

2.14.2 Description

ISO 26262 [17] is the applicable standard for functional safety of electronic and soft-ware based systems in road vehicles which impacts almost all development activities,including software specifications, design and implementation. The Safety Extensionsenable a standardized exchange of the safety information in an AUTOSAR context andprovide the basis for consistent management as required by ISO 26262. The additionalsafety related information can be used e.g. for generation of the documentation or thechecking of ASIL constraints (w.r.t. allocation, mapping, decomposition and hierarchy),which are prescribed by the ISO 26262. The AUTOSAR Methodology focuses on thecreation and refinement of the information. The corresponding analysis is out of scopeof this document.

According to the ISO 26262, the Safety Extensions provide the following means toexpress safety information (for more details see TPS_SafetyExtension [16]):

• Safety Requirements (Artifact Safety Requirement)

• Safety Measures (Artifact Safety Measure)

• Safety integrity levels: attribute of Safety Requirement, Safety Measureand any AUTOSAR element

• Decomposition of Safety Requirements: reference between the original and thedecomposed requirement (Task Decompose Safety Requirement)

• Refinement of Safety Requirements: reference between the original and the re-fined requirement (Task Refine Safety Requirement)

• Allocation of Safety Requirements: reference between of Safety Requirementand an AUTOSAR element (Task Allocate Safety Requirement)

• Allocation of Safety Measures: reference between Safety Measure and anAUTOSAR element (Task Allocate Safety Measure)

• Mapping between Safety Requirements and Safety Measures (Task MapSafety Requirement to Safety Measure)

• Independence relation between Safety Requirements (Task Add Indepen-dence Relation)

The safety relevant information can be exchanged independently and are thereforeconsolidated in a separate deliverable Safety Extensions.

153 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 154: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

[TR_METH_01144] Activity Define Safety Information d The activity DefineSafety Information (see Figure 2.63) represents a generic pattern for defin-ing safety relevant information. The safety extensions are not restricted to specificAUTOSAR elements so that safety relevant information can be added and modified inseveral stages of the AUTOSAR Methodology in an iterative way. Thus, the AUTOSARelements consumed by some of the nested tasks are modeled using the GeneralAutosar Artifact. The AUTOSAR Methodology does not prescribe an explicit ex-ecution order of the tasks. The only restrictions with respect to the execution order aregiven by the input and output relations (E.g. obviously, before a Safety Require-ment can be decomposed, it has to be defined). c(RS_METH_00081)

[TR_METH_01145] Creation of Safety Requirements d Naturally, the processstarts with the task Define Safety Requirement. This task creates a SafetyRequirement and assigns the required attributes such as ASIL. The top level SafetyRequirement is a safety goal and obviously results from the hazard analysis and riskassessment. If Safety Requirements are not detailed enough to allocate themdirectly to appropriate AUTOSAR elements, it is necessary to refine them first (taskRefine Safety Requirement). The refinement will add new Safety Require-ments which are in a hierarchy relation to existing Safety Requirements. The ASILis maintained as attribute at each safety goal and inherited consistently through thesubsequent levels of functional safety requirements (as part of the Functional SafetyConcept) and technical safety requirements (as part of the Technical Safety Concept).The latter will be refined into SW and HW safety requirements. c(RS_METH_00081)

[TR_METH_01146] Allocation of Safety Requirements d Each Safety Re-quirement must be allocated properly to an element of the system architecture, i.e.component, HW, SW or both (HW and SW). Hence, an AUTOSAR element might re-ceive an ASIL which indicates that it is in the scope of an ISO 26262 development.The allocation is done by task Allocate Safety Requirement. If safety require-ments are not available or will not be exchanged together with a specification, theAUTOSAR implementation must at least be aware that the element is used in a safetycontext. Hence, the task Define ASIL For AUTOSAR Element directly assignsthe ASIL attribute to an AUTOSAR element (independent of an allocation). Especiallyin cases of a SEooC (Safety Element out of Context) development, where the safetyrequirements are not fully known at development time, the ASIL attribute supports theintegration and verification of such parts in a later stage of development by matchingthe assumptions against the finalized safety requirements. c(RS_METH_00081)

[TR_METH_01147] Decomposition of Safety Requirements d In order to tailorthe ASIL of Safety Requirements, ASIL decomposition may be applied. The de-composition is done by task Decompose Safety Requirement. According to theISO 26262 a requirement can be decomposed into two requirements. In the con-text of ASIL decomposition the independence (freedom of interference) for the result-ing requirements has to be demonstrated (Task Add Independence Relation).c(RS_METH_00081)

[TR_METH_01148] Definition of Safety Measures d Safety of a system is achievedby means of safety measures that are applied at various stages of the development pro-

154 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 155: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

cess and safety mechanisms which are implemented in a number of technologies intothe system. Safety measures and safety mechanisms are represented by the artifactSafety Measure which is created by the task Define Safety Measure. In taskAllocate Safety Measure the Safety Measures which are safety mechanismsrealized in AUTOSAR are allocated to AUTOSAR elements in order to describe what el-ements are involved in the provision of a safety measure. The task Map Safety Re-quirement to Safety Measure creates a mapping between the Safety Mea-sure and the Safety Requirement. c(RS_METH_00081)

The following specialized activities demonstrate the usage of the Safety Extensions indifferent development stages and are integrated into the corresponding use cases:

• Define VFB Safety Information

• Define Software Component Safety Information

• Define System Safety Information

2.14.3 Workflow

Safety Extensions Overview

Define Safety Information

Map Safety Requirement to Safety Measure

Define Safety Requirement

Define Safety Measure

Refine Safety Requirement

Decompose Safety Requirement

Define ASIL For AUTOSAR Element

Add Independence Relation

Allocate Safety Measure

Allocate Safety Requirement

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting»

«nesting» «nesting»

«nesting»

«nesting»

Figure 2.63: Safety Extensions Overview

155 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 156: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Process Pattern Safety Extensions OverviewPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Safety Extensions OverviewBrief DescriptionDescriptionRelation Type Related Element Mul. NoteAggregates Define Safety In-

formation1

Table 2.55: Safety Extensions Overview

Activity Define Safety InformationPackage AUTOSAR Root::M2::Methodology::Methodology Use Cases::High

Level::Safety Extensions OverviewBrief Description Defines all required safety information.Description This activity represents a generic pattern for defining safety relevant

information. The safety extensions are not restricted to specificAUTOSAR elements so that safety relevant information can be addedand modified in several stages of the AUTOSAR Methodology. Thus,the AUTOSAR elements consumed by some of the nested tasks aremodeled using the "General Autosar Artifact".

Extended by Define Software Component Safety Information, Define System SafetyInformation, Define VFB Safety Information

Relation Type Related Element Mul. NoteAggregates Add Independence

Relation1

Aggregates Allocate SafetyMeasure

1

Aggregates Allocate Safety Re-quirement

1

Aggregates Decompose SafetyRequirement

1

Aggregates Define ASIL For AUTOSAR Element

1

Aggregates Define Safety Mea-sure

1

Aggregates Define Safety Re-quirement

1

Aggregates Map Safety Re-quirement toSafety Measure

1

Aggregates Refine Safety Re-quirement

1

Table 2.56: Define Safety Information

156 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 157: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.15 Variant Handling

2.15.1 Overview

[TR_METH_02009] Variation points in Variant Handling d Variant Handling forAUTOSAR is defined in the Generic Structure Template Template [18]. First, this con-cept defines means to designate certain locations in the AUTOSAR meta-model asvariation points. A point roughly consists of a condition (under which conditions is thisvariation active?) and a binding time (when should this variation be resolved?). c()

Second, there are predefined variants.

[TR_METH_02010] Predefined variants in Variant Handling d A typical AUTOSARmodel may contain a large number of variation points. However, usually only a relativelysmall number of variants (i.e., combinations of “active” variation points) is actively used.Each predefined variant describes such a variant. c()

2.15.2 Binding Times

[TR_METH_02011] Types of binding times d The AUTOSAR variant handling de-fines two kinds of binding times for AUTOSAR: the latest binding time and the actualbinding time. They have the same kinds of values3, but are used in different contexts.c(RS_METH_00074)

AUTOSAR defines the following binding times (presented here in chronological order):

• BlueprintDerivationTime

• SystemDesignTime

• CodeGenerationTime

• PreCompileTime

• LinkTime

• PostBuild

The Generic Structure Template mentions two more binding times. First, there isFunctionDesignTime, which comes before SystemDesignTime, but is indepen-dent of BluePrintDerivationTime. Second, there is Runtime, which comes afterPostBuild. These binding times are not covered by AUTOSAR and mentioned hereonly for completeness.

[TR_METH_02012] Definition of a binding time d It should also be noted that a bind-ing “time” is not really a point in time, but rather denotes a phase in the development ofan AUTOSAR system. c(RS_METH_00074)

3BlueprintDerivationTime and PostBuild are not part of the actual enum that is used in themeta-model, but they are implied by the structure of the variation point. See chapter 7 in the GenericStructure Template Template [18] are more details.

157 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 158: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.15.2.1 Latest Binding Time

[TR_METH_02013] Latest Binding Time d In the AUTOSAR meta model, ev-ery variation point has a latest binding time, which is implemented by the tagVh.LatestBindingTime. As the name suggests, the latest binding time of a par-ticular variation point puts an upper limit on when this point can be bound. A variationmay be bound earlier than this time, but not later. c(RS_METH_00074)

For example, the latest binding time for a software component which is part of a com-position is PostBuild. In other words, an ECU can be configured to decide at startupwhether a software component is active or not.

However, it is not always possible to bind a variant at the latest possible time. Tocontinue the above example, making all software components PostBuild means thatan executable always contains code and other resources for all software components,regardless whether it gets activated or not. Because of this, it may happen that theexecutable becomes too large to fit onto its designated ECU. If this is the case, thesoftware component needs to be bound earlier, typically at PreCompileTime or even atSystemDesignTime.

This is not the only scenario that leads to this decision. For example, a software com-ponent might contain two or more subcomponents each of which is specific to a certainvendor. In this case, before delivering the software component to a specific vendor, itis custom to remove the subcomponents that are targeted at the other vendor(s). Thiscan obviously be done at PrecompileTime the latest.

There are also cases where there is an implicit (i.e., not stated of the meta-model)lower limit for the binding time of a variation point. For example, if a variant in softwarecomponent A uses a variant in software component B, then the binding times needto be coordinated. Component A cannot be SystemDesignTime if component B isPostBuild, but makes use of software component A.

2.15.2.2 Actual Binding Time

[TR_METH_02014] Actual Binding Time d This brings us to the actual binding timeof a variation point, which is stored in an attribute4 of the variation point. Again, it is notmandatory that the variation point is bound exactly at this stage; it rather states thatthe variation point must not be bound at a later stage.

This binding time may be earlier than the latest binding time. c(RS_METH_00074)

As explained in the previous section, composition of software components can bebound at PostBuild, but it is not always desirable or even feasible to do so. In sucha case. bindingTime should state an earlier binding time.

4The attribute is named bindingTime and is located at the ConditionByformula element of avariation point. For an AttributeValueVariationPoint, it is contained in the attribute binding-Time.

158 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 159: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Also, unlike the latest binding time, which is a meta model element and is stated onM2 level, this binding time is a model element associated with a variation point and isstated on M1 level.

That is, the binding time of a variation point limits the point at which a particular vari-ation point has to be bound, but this binding time is again constrained by the latestbinding time.

2.15.3 Defining Variants

[TR_METH_02015] Definition of variants d A variant is almost always more than asingle variant point or a single system constant. Typically, a variant is a list of value as-signments to system constants or postbuild variant conditions. In an AUTOSAR model,such a list is represented by an instance of the meta-class PredefinedVariant, seedefinition of artifact Predefined Variant. c(RS_METH_00005)

[TR_METH_02016] Evaluated Variant Set d Similarly, an instance of the meta-class EvaluatedVariantSet is a set of PredefinedVariants that are known towork (or not to work) for a certain element of the meta-model, for example a specificsoftware component. Evaluated variants may be used to exchange information aboutknown variants between different vendors, for example to document which variants ofa software component have been tested and are known to work.

In the Methodology SPEM model, the variant selectors are represented by the Eval-uated Variant Set artifact which is created by the Evaluate Variant task.c(RS_METH_00005, RS_METH_00075, RS_METH_00076)

This information is necessary because there is a extremely high number of possiblevariants, but only a very small subset of them are feasible.

[TR_METH_02017] Use of Predefined Variant d The set of system constantsthat are contained in an instance of PredefinedVariant usually affect a number ofvariation points, which are at different locations in the model and have different bindingtimes.

Hence, a predefined variant cannot be directly associated with a specific locationin the meta-model, or a certain binding time. On the contrary, a Predefined-Variant is used for several meta-model elements and at different binding times.c(RS_METH_00005, RS_METH_00076)

2.15.4 Choosing Variants

Whether a variation point is included in a system or not is determined by one or morevariables. If the binding time of a variation point is anywhere from SystemDesignTimeto LinkTime, then the variation point contains an expression that is based on systemconstants (see artifact System Constant Value Set). If this expression evaluatesto true, then the variation point is included in the system. PostBuild uses a simplified

159 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 160: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

scheme that allows only a single comparison with a PostBuildVariantCriterion(technically, an ARElement).

[TR_METH_02018] Choosing variants d So, a variant is chosen as soon as the val-ues for the respective system constants or postbuild variant conditions have been de-termined. This is usually done by selecting a PredefinedVariant, which containsthe respective values. This selection must obviously happen before a variation point isbound. But, it does not need to happen immediately before a variation point is bound.c(RS_METH_00005)

For example, the system constants that determine a PreCompileTime variation pointmay already have been chosen at SystemDesignTime, but the actual binding hasto be delayed to PreCompileTime because of a dependency on another softwarecomponents that have the binding time PreCompileTime, as described in Sec-tion 2.15.2.2.

Furthermore, since PredefinedVariant spans several variation points, which mayhave different binding times, some might have a binding time (latest or even actual)immediately after the PredefinedVariant has been chosen, and the others mighthave a later binding time.

Finally, the decision to go for a particular variant is often tied to vendor specific pro-cesses that follow their own timeline.

Hence, the time at which a particular variant is chosen is often not the same as thetime when the associated variation points are bound. In summary, a variant must bechosen some time before it is bound, but the actual time when this is happening is notdetermined by AUTOSAR, and is also quite vendor specific.

2.16 Definition of Binding Times

2.16.1 Overview

A binding time is not (as the name probably suggests) a precise point in time, butrather a classification of processing steps. For example, the binding time CodeGener-ationTime refers to a transformation step from an AUTOSAR model in ARXML formatto code.

In this section, we define binding times for artifacts and tasks in the methodology.

[TR_METH_00001] Definition of Binding Time for Tasks d A task has binding timeX if it binds variation points of binding time X.

This means in particular:

• Any task that works on the model may bind variation points that have the bindingtime SystemDesignTime.

160 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 161: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

• Any task that generates code needs to bind open variation points that have thebinding time CodeGenerationTime. All variation points with earlier bindingtimes must have been bound by then.

• Similarly, any task that compiles code needs to bind open variation points thathave the binding time PreCompileTime.5 All variation points with earlier bindingtimes must have been bound by then.

At this time, the values for PostBuildVariantConditions of variation pointsmust also be bound. These values have a latest binding time of PreCompile-Time6.

In all these cases, the system constants that are needed by the condition of a variationpoint obviously must be defined before the variation point is bound.

In the Methodology library, the binding time of a task is indicated by a value of the tagMeth.bindingTime for those tasks which always can be associated with this bindingtime. It is not indicated for tasks that only optionally bind variations. This typicallyis the case for all tasks that only work on the ARXML model, for example, it is upto the concrete process whether a task like Extract ECU Topology shall bind anyvariations. c(RS_METH_00074, RS_METH_00075)

[TR_METH_00002] Definition of Binding Time for Artifacts d In an artifact with bind-ing time X, all variation points up to binding time X shall be bound.

We do not denote such a binding time for artifacts in the Methodology library, be-cause their binding time typically depends on the context. However, this definitioncould be used to assign a binding time to an artifact as part of a specific use case.c(RS_METH_00074)

[TR_METH_00003] Definition of Binding Time for Artifacts in the context of par-ticular tasks d If an artifact of binding time X is used as input or output of a particulartask, then all variation points related to that task with binding time up to X shall bebound.

This in particular means that if the artifact is input to the task, then binding time variationpoints X shall be bound and the task relies on this.

If the artifact is output to the task, it is granted that the such created artifact has allvariation points of binding time X bound.

In the Methodology library, this is indicated by a value of the tag Meth.bindingTimeattached to a Consumes/ConsumedBy resp. Produces/ProducedBy relationship.

5Note that in case of the RTE code, the technical step of binding PreCompileTime variants ispartially done by a preparatory task which runs before the actual compilation, see Generate RTEPrebuild Dataset. That means in particular, the relevant system constants must be defined beforeexecuting this preparatory task. The binding time of actual compilation task Compile ECU SourceCode is indicated as CompileTime in this case.

6The variation point is still PostBuild: the PostBuildVariantCondition is fixed at PreCompile-Time, but the comparison with the associated PostBuildVariantCriterion occurs at PostBuild-VariantCriterion. See the Generic Structure Template [18] for details

161 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 162: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Note that the tag Meth.bindingTime is not applicable to inout relationships, as thebinding time values according to the above definition are usually different for the inputsand outputs of a particular task. If it is important to express these binding times, theinout relation must be split into an input (i.e. ConsumedBy) and output (i.e. Pro-duces) relation. c(RS_METH_00074)

Figure 2.64 presents an overview of binding times as used in the AUTOSAR method-ology. Boxed elements in this figure correspond to binding times, and the connectionsbetween them characterize artifacts.

Model + Requirements

BluePrintDerivationTime FunctionDesignTime

InitialBindingTime

CodeGenerationTime

PreCompileTime

CompileTime

LinkTime

PostBuild

RunTime

Executable, Configuration Data Set

Object Code

Bound Source Code

Source Code

ARXML

Function ModelARXML

Figure 2.64: Overview of Binding Times

162 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 163: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.16.2 A Classification of Artifacts with respect to Binding Times

Model, Requirements, Functional Model These refer to models that are not anAUTOSAR Model. For example, a Model may be a Matlab/Simulink model ora requirements document.

ARXML An ARXML artifact is a XML document that conforms to the AUTOSAR XMLschema.

Source Code A Source Code artifact is text written using the syntax of a programminglanguage, for example such as C or C++.

Source Code may be generated by hand, or may be the output of a code gener-ator.

Bound Source Code A Bound Source Code artifact contains source code without anyunbound precompile variation points.

Object Code An Object Code is the output of a compiler. Object code is typicallymachine code, but may also include descriptive information in a format such asXML.

Executable An Executable is an artifact that can run on an ECU. It is often similar toObject Code; the difference between the two is that the former does not providemeans for execution on an ECU.

Configuration Data Set A Configuration Data Set is a set of assignments to Post-BuildVariantCriterion.

2.16.3 Classification of Binding Times

Table 2.57 presents an overview of the binding times in AUTOSAR Variant Handling.

Binding Time AUTOSAR Metamodel AUTOSAR MethodologyBlueprintDerivationTime partially yesFunctionDesignTime out of scope out of scopeInitialBindingTime no yesSystemDesignTime yes yesCodeGenerationTime yes yesPreCompileTime yes yesCompileTime unused yesLinkTime yes yesPostBuild yes yesRuntime out of scope out of scope

Table 2.57: Binding Times in Meta Model and Methodology

Variant handling in the AUTOSAR meta model supports the following binding times:

• BlueprintDerivationTime

163 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 164: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

• SystemDesignTime

• CodeGenerationTime

• PreCompileTime

• LinkTime

• PostBuild

[TR_METH_02020] Definition of latest Binding Time for a variation pointin the meta-model d All these binding times may be used in the tag�Vh.latestBindingTime�, which is used to define the latest binding time for avariation point in the meta model.

The actual binding time of a variation point is stored in the attribute bindingTimeof the ConditionByFormula of a VariationPoint, and can only use the val-ues SystemDesignTime, CodeGenerationTime, PreCompileTime, LinkTime.c(RS_METH_00074)

The AUTOSAR methodology utilizes two more binding times, InitialBinding-Times to characterize artifacts where no variation points are bound, and Compile-Time to distinguish between preprocessing and compiling of code. Finally, Func-tionDesignTime and Runtime are not in the scope of AUTOSAR variant handlingbut mentioned here for completeness.

2.16.3.1 BlueprintDerivationTime

At BlueprintDerivationTime, a model is derived from Blueprints. For example,a function design tool provides the option to derive objects from a predefined set ofblueprints. See [19] for more details. This is different from the variant handling definedin this chapter, but it uses the same meta model features (see [18]).

BlueprintDerivationTime is out of the scope of this document, but mentionedhere for completeness.

Input Artifacts: Model, Requirements

Output Artifacts: ARXML

2.16.3.2 FunctionDesignTime

At FunctionDesignTime, a software architecture independent model for (control)systems is developed. Typical tools used at this stage are Matlab/Simulink, or ASCET-MD.

If a function design tool supports variant handling according to AUTOSAR it has noother choice than using CodeGenerationTime or later as binding time in the gener-ated AUTOSAR artifacts.

164 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 165: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

FunctionDesignTime is out of the scope of this document (as long as it does notaffect calibration measurements), but mentioned here for completeness.

Input Artifacts: Model, Requirements

Output Artifacts: Function model

2.16.3.3 InitialBindingTime

At InitialBindingTime, no variation points are bound. This binding time is needed toexpress a state where no SystemDesignTime points are bound in artifact

Input Artifacts: Model, Requirements, Function model, AUTOSAR models fromblueprints in ARXML format.

Output Artifacts: ARXML.

2.16.3.4 SystemDesignTime

SystemDesignTime is characterized by the following tasks:

• Designing the VFB

• Software Component types (Interfaces)

• SWC Prototypes and the Connections between SWCprototypes

• Designing the Topology

• ECUs and interconnecting Networks

• Designing the Communication Matrix and Data Mapping

Input Artifacts: Function model, Requirements, AUTOSAR models from blueprints inARXML format.

Output Artifacts: ARXML.

2.16.3.5 CodeGenerationTime

At this step, code is generated. This may be done either by hand, or using a tool, or amixture of both.

Handwritten code is typically based on a requirements document, whereas generatedcode is usually created from a model that was designed at FunctionDesignTime orSystemDesignTime.

Both the requirements and the model may contain variants, but code is only generatedfor those variants that have been selected, or which need to be resolved later.

165 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 166: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Input Artifacts: ARXML.

Output Artifacts: Source Code.

2.16.3.6 PreCompileTime

At PreCompileTime, a preprocessor (e.g., the C preprocessor) is used to furthercustomize the code and exclude parts of the code from the compilation process.

There are several reasons for such an exclusion: code is not required for the selectedvariant(s), code is incompatible with the selected variant(s), or code requires resourcesthat are not present in the selected variant(s). The code that is excluded at this stagecode will not be available at later stages.

PreCompileTime is typically used for handwritten code (for which SystemDesign-Time and CodeGenerationTime obviously cannot not take effect) or when a systemconstant needs to be bound after code generation.

Input Artifacts: Source Code.

Output Artifacts: Bound Source Code.

2.16.3.7 CompileTime

At CompileTime, source code that has already been processed by a macro processorsuch as the C preprocessor and stripped of all PreCompileTime variation points istransformed into object code. The compiler might eliminate further variants by remov-ing unused code paths.

CompileTime is not used in the AUTOSAR meta model, but is used in the AUTOSARmethodology to discriminate between a preprocessor and a compiler.

Input Artifacts: Bound Source Code.

Output Artifacts: Object code.

2.16.3.8 LinkTime

The configuration at this stage determines which modules are included in the resultingobject code (executable), and which ones are omitted based on the selected variants.

Input Artifacts: Object code.

Output Artifacts: Executable program.

166 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 167: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

2.16.3.9 PostBuild

PostBuild is the binding time which is bound latest at startup of the ECU. In other wordsthis is everything between creation of the executable program and startup of the ECU.

The startup of the ECU is the PostBuild binding since and obviously cannot be resolvedin the model.

Input Artifacts: Executable program, Configuration data set.

Output Artifacts: –

2.16.3.10 Runtime

Everything after startup and initialization is RunTime. Variant Handling at RunTime isout of the scope of this document, but mentioned here for completeness.

2.17 How to resolve Name Conflicts

2.17.1 Reasons for Name Conflicts

In the highly distributed development of an AUTOSAR system, there is a certain riskthat symbolic names used in different development artifacts are not unique so thatname conflicts may occur when applying software tools.

[TR_METH_03000] Name spaces via ARPackages d In the “upstream” specificationof an AUTOSAR system, a software component, a basic software module or config-uration parameters via AUTOSAR XML artifacts, such a risk can be widely avoidedthrough the proper usage of ARPackages because they set up name spaces andmay be nested (see also General Autosar Artifact). Here it is recommendedto follow similar rules as AUTOSAR is using for its own published artifacts, see [18]:[TPS_GST_00081], [TPS_GST_00083], [TPS_GST_00086]. c(RS_METH_00002,RS_METH_00003, RS_METH_00004, RS_METH_00005)

However, certain symbols specified in the AUTOSAR XML artifacts need to be trans-ferred to other development artifacts in later process steps (“downstream”) and willappear e.g. as symbols in C-code, as file names, as names displayed by calibrationtools or in textual documents. Here we have in general two reasons for naming conflicts(which may also occur in combination):

[TR_METH_03001] Reasons for name conflicts in “downstream” artifacts d

• Uncoordinated co-development

Due to the global name space of the C-language within one compilation unit, therisk of name conflicts is rather high if pieces of source code are integrated thatwere developed by different parties without coordinating the definition of symbols.

167 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 168: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

The same can happen with names of header files or with symbols visible by thelinker.

In AUTOSAR, the programming language interfaces between software compo-nents and (to some extend) between basic software modules are restricted tocertain patterns and are generated from ARXML, so the coordination effort isrestricted to the proper definition of the relevant symbols in ARXML.

In several cases the shortName of an ARElement corresponds to an identifierin the code (or to a part of such an identifier), sometimes also to a file nameor a part of it. Since shortNames are also used in the links between ARXMLelements, it is hard to change such a name without impact on the overall design.This is for example the case for the names of the AtomicSwComponentTypes.

• Multiple instantiation

The AUTOSAR Runtime Environment (RTE) supports multiple instantiation ofsoftware components. This means, in a system and even on one ECU therecan be several instances of a given AtomicSwComponentType. Each instancepossesses its own data (managed by the RTE), but there is only one artifact (VFBAtomic Software Component) describing the whole type. If one needs asymbol identifying a particular component instance or particular data belongingto that instance (for example for display in a calibration tool), a conflict arises.

A similar thing happens with data elements or operation arguments in a PortIn-terface or in a composite data type, if the enclosing element is reused in morethan one context.

A different kind of “multiple instantiation” can occur in the basic software, if severaldriver modules implement the same interface (only distinguished by an instanceidentifier). In this case, we actually have different implementations of code, themodules only share the upper levels of description (artifacts Basic SoftwareModule Description and Basic Software Module Internal Behav-ior).

c(RS_METH_00038)

2.17.2 Points in the Methodology where Name Conflicts are resolved

On the other hand we have multiple points in the methodology where to resolve thoseconflicts.

In general we can distinguish between the development phase in which a name conflictis resolved and the phase in which it occurs (or would occur). Because a conflict usuallyprevents a certain task from being completed (e.g. compilation), it must be resolved inthe same or an earlier phase than the phase in which it would occur.

• [TR_METH_03002] Conflict solution at system design time dThis is mentioned mainly for completeness. Of course, a proper system design

168 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 169: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

can avoid conflicts in the first place and if a name conflict still arises in a laterphase, it is in principle possible to iterate over the system design. But in thischapter we focus on solutions that allow to resolve name conflicts in later processphases which usually causes less effort.c(RS_METH_00006)

• [TR_METH_03003] Conflict solution at coding time dConflicts occurring at compile time or link time must be resolved (latest) at thetime a developer is producing the code and/or the ARXML descriptions leading tothe generation of code. In other words, this has to happen within the activities De-velop an Atomic Software Component or Develop BSW Module. Notethat in the worst case, such a conflict is detected not before integration time (dur-ing activity Build Executable) which means that some kind of iteration of theactivities is required.c(RS_METH_00006)

• [TR_METH_03004] Conflict solution at ECU integration time dDuring ECU integration time (latest) it is still possible to resolve name conflictsthat would occur in tasks after the software build, e.g. during generation of A2Lfiles.c(RS_METH_00006)

2.17.3 Mechanisms for resolving Name Conflicts

The mechanisms to resolve the name conflicts are:

• [TR_METH_03005] Conflict solution via SymbolProps d

This mechanism allows to redefine a name in cases where the shortName bydefault is used to generate RTE relevant code. This avoids to change the overalldesign in the ARXML model.

This mechanism can be applied at coding time (activity Develop an AtomicSoftware Component, task Define SymbolProps for Types) and solvesconflicts caused by uncoordinated development. Such changes - even if they donot influence the overall design of the software - should be agreed upon by theinvolved parties.

This mechanism is provided for the following meta-model elements:

AtomicSwComponentType.symbolPropsAllows to redefine the software component type name that the RTE is using inits code. This resolves name clashes among different software component typesdesigned accidentally with the same shortName.7

ImplementationDataType.symbolPropsAllows to redefine the implementation data type name used in the code of the

7Note that this mechanism is not applicable for the prefixes used in the preprocessor code of memorysections and compiler memory classes. Conflicts among these preprocessor symbols due to duplicatecomponent type names are not visible to the linker. However conflicts might occur when compiling theheader file Compiler_Cfg.h and must be resolved manually.

169 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 170: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

RTE and/or the components. This resolves name clashes among different imple-mentation data types designed accidentally with the same shortName.

For more information on the meta-model refer to [TPS_SWCT_01194] and[TPS_SWCT_01110] in [5].c(RS_METH_00002)

• [TR_METH_03006] Conflict solution via literal prefixes d

This mechanisms is similar to the one described before. It allows to define a pre-fix for preprocessor literals (e.g. for enumeration types or upper/lower limits) cre-ated by the RTE generator contract phase. Also this mechanism solves conflictscaused by uncoordinated development and must be applied at coding time (partof task Define Atomic Software Component Internal Behavior).

The model element to be manipulated is:SwcInternalBehavior.includedDataTypeSet.literalPrefix

For more information refer to [TPS_SWCT_01157] in [5].c(RS_METH_00002)

• [TR_METH_03007] Conflict solution in names of runnable entities d

In case of a RunnableEntity the symbol used in the code is already indepen-dent from the shortName - it is always modeled via the attributeRunnableEntity.symbol. However, since these symbols need to be uniquein the scope of one RTE instance (see [constr_2025] in [5]), also here a nameconflict can occur at integration time if the definition of the symbols was not coor-dinated before.

Similar to the cases discussed before, this conflict must be solved at coding timesimply be changing the symbol. Note that such a change would not influencethe overall design and can be done locally on one component (whose runnableshall be renamed) since the runnable symbol is hidden to other component by theRTE. Despite of that, the definition of unique runnable symbols still might needsome human coordination.c(RS_METH_00002)

• [TR_METH_03008] Conflict solution via FlatMap d

This mechanism allows to assign identifiers to instances of model elements (e.g.software component instances or data element instances) so that they are uniquein a certain scope, e.g. a system or an ECU. Thereby name conflicts are avoided,which would occur if simply the shortNames of the ARXML elements would beused. In other words, this mechanisms solves the name conflicts arising frommultiple instantiation of types in the ARXML model.

The identifiers defined in this way are typically not used within the code, sinceAUTOSAR components do not rely on global variables. The main purpose is theusage within other artifacts which need to handle symbols out of the packagecontext of the ARXML model, for example citation in documents (e.g. in arti-fact Software Component Documentation) or input for measurement andcalibration tools (e.g. in artifact RTE Measurement and Calibration Sup-port Data). A special use case of the ECU Flat Map is the the model trans-

170 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 171: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

formation from the System to ECU Extract, where it is used to define additionalnames of component prototypes.

The point in the methodology where this mechanisms is applied depends ofcourse on the use case. The typical tasks in the methodology library for defininga Flat Map are normally performed before integration time: Generate or Ad-just System Flat Map, Define Partial Flat Map and Generate orAdjust ECU Flat Map. But since identifiers in a FlatMap are independent ofthe code, it can in principle be adjusted even at integration time in case a conflictoccurs.

For more information see artifacts System Flat Map, Partial Flat Mapand ECU Flat Map, for the underlying meta-model parts refer to referto [9].c(RS_METH_00005)

• [TR_METH_03009] Conflict solution via AliasNameSet d

This mechanism is similar to FlatMap. It allows to define additional names formodel elements, either on top of an entry in a FlatMap or standalone. Theusage is also similar, but there are no standardized use cases in connection withthe AUTOSAR RTE. It can be used in cases where the format of the FlatMap istoo restrictive.

For more information refer to the artifact Alias Name Set and task DefineAlias Names. For the meta-model of AliasNameSet refer to [9]. The docu-ment [9] also gives recommendations on how to transfer certain attributes belowAliasNameSet into an ASAM ASAP2 (“A2L”) specification.c()

• [TR_METH_03010] Conflict solution via API Infixes d

If several “instances” of a basic software module (with different implementationbut identical interface definition) are linked together, name conflicts have to besolved by defining “infixes”. These are small pieces of strings denoting the mod-ule vendor and the instance role. They are used to extend globally visible Csymbols and certain header file names. The mechanism is also relevant for thebasic software scheduler APIs generated in task Generate BSWM ContractHeader Files.

Though this mechanism solves a conflict of a certain kind of multiple instantiation,it is relevant to the code and thus must be applied at coding time. The descriptionof the infixes has to be put into the artifact Basic Software Module Imple-mentation Description.

For more information refer to [TPS_BSWMDT_04031] in [8] and to[SWS_BSW_00102] in [6].c(RS_METH_00003)

171 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 172: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3 Methodology Library

3.1 Common Elements

This chapter contains the definition of work products and tasks used in several areas ofAUTOSAR development. For the definition of the relevant meta-model elements referto [18].

3.1.1 Work Product Kinds

Category(Work Product Kind)

AUTOSAR XML

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription An artifact that conforms to the AUTOSAR XML schema.

Table 3.1: AUTOSAR XML

Category(Work Product Kind)

Source Code

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription A human readable artifact that conforms to a defined programming

language syntax, such as C or Java.

Table 3.2: Source Code

Category(Work Product Kind)

Bound Source Code

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription A Bound Source Code artifact contains source code without any

unbound precompile variation points.

Table 3.3: Bound Source Code

Category(Work Product Kind)

Object Code

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief Description

172 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 173: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Description An Object Code is the output of a compiler. Object code is typicallymachine code, but may also include descriptive information in a formatsuch as XML.

Table 3.4: Object Code

Category(Work Product Kind)

Configuration Data Set

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription This is a special kind of binary code containing configuration that can

be loaded separately from the main ECU code.

Table 3.5: Configuration Data Set

Category(Work Product Kind)

Executable

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription An Executable is an artifact that can run on an ECU. It is often similar

to Object Code; the difference between the two is that the former doesnot provide means for execution on an ECU.

Table 3.6: Executable

Category(Work Product Kind)

Text

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription A human readable artifact that is stored as plain text, rich text, PDF, etc.

Table 3.7: Text

Category(Work Product Kind)

Custom

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription A custom artifact format which is not further specified in the AUTOSAR

Methodology.

Table 3.8: Custom

173 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 174: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Category(Work Product Kind)

Delivered

Package AUTOSAR Root::M2::Methodology::Methodology Library::CommonElements::Work Product Kinds

Brief DescriptionDescription These are collections of delivered work products. They form the basis

of exchange between organizations.

Table 3.9: Delivered

3.1.2 Tasks

3.1.2.1 Add General Documentation

Add General Documentation

General Documentation

«output» 1

Figure 3.1: Add General Documentation

Task Definition Add General DocumentationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription Add General Documentation to work products (AR_MET_REQ069)Relation Type Related Element Mul. NoteProduces General Documen-

tation1

Table 3.10: Add General Documentation

3.1.2.2 Define Admin Data

Define Admin Data

General Autosar Artifact

«output» 1

Figure 3.2: Define Admin Data

174 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 175: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define Admin DataPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief Description Generic task to define admin data of an Identifiable within an

AUTOSAR artifact.Description Generic task to define administration data (metamodel element

AdminData) of an Identifiable within an AUTOSAR artifact. Note thatadministration data can be defined on several levels, namely for thetop-level package of a General Autosar Artifact, but also forsub-packages and for other Identifiables within the XML description.

Admininistration data include versioning information of the modelelement via the meta-class DocRevision, and the aggretation of userspecific data via so-called special data groups, meta-class Sdg.

For more details on the administration data content seeAUTOSAR_TPS_GenericStructureTemplate.pdf.

Relation Type Related Element Mul. NoteProduces General Autosar

Artifact1

Table 3.11: Define Admin Data

3.1.2.3 Define Alias Names

Define Alias Names

Alias Name Set

Delivered Atomic Software Components

System Description

«output» 1

0..1

«input»

0..1

«input»

Figure 3.3: Define Alias Names

175 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 176: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define Alias NamesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief Description Define a set of alias names for AUTOSAR model elements.Description The usual mechanism for defining global names for nested elements

within an AUTOSAR XML model is the Flat Map. However in thecooperation with non-AUTOSAR tools, there are uses cases whichrequire additional alias names which can be defined by this task.

It can be applied on System and on ECU level as well. Possible usecases are for example:

• The names defined by an ECU Flat Map, System Flat Map orPartial Flat Map shall be superseded when used by an externaltool (e.g. in order to use a more general string format).

• Resolve name conflicts for elements which cannot be referred inthe context of a Flat Map (e.g. for elements directly defined inthe scope of ARPackages, like System Constants to bedisplayed by A2L tools).

Relation Type Related Element Mul. NoteConsumes Delivered Atomic

Software Compo-nents

0..1 Needed for definition of alias names inthe scope of delivered softwarecomponents.

Consumes System Descrip-tion

0..1 Needed for definition of alias names withsystem, system extract or ECU scope,depending of the role of the SystemDescription.

Produces Alias Name Set 1

Table 3.12: Define Alias Names

176 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 177: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.4 Evaluate Variant

Evaluate Variant Evaluated Variant Set

Postbuild Variant Set

General Autosar Artifact

Predefined Variant

System Constant Value Set

«input»

0..*

«input» 0..1

«output» 1

«input»0..*

«input»

1..*

«input»

0..*

Figure 3.4: Evaluate Variant

Task Definition Evaluate VariantPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief Description Document the evaluation of variants in the software description.Description Create or modify an Evaluated Variant Set in order to document the

outcome of an evaluation of particular variants. This namely meanssetting the "approval status" in relation to a given set ofPredefinedVariants and a given set of model elements (e.g. aparticular Software Component) which were evaluated.

This is a general task which can be applied on different levels,therefore the input is modeled as General Autosar Artifact.

Relation Type Related Element Mul. NoteConsumes General Autosar

Artifact1..*

Consumes Evaluated VariantSet

0..1

Consumes Postbuild VariantSet

0..*

Consumes Predefined Variant 0..*Consumes System Constant

Value Set0..*

Produces Evaluated VariantSet

1

Table 3.13: Evaluate Variant

177 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 178: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.5 Define Memory Addressing Modes

Define Memory Addressing Modes

BSW Module Preconfigured Configuration

Basic Software Module Developer

Software Component Developer

«output»

+MemMapAddressingModeSet

1..*

1

«performs»

0..1

«performs»

Figure 3.5: Define Memory Addressing Modes

Task Definition Define Memory Addressing ModesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription Define the compiler specific configuration used in a later task to

generate the "pragmas" in memory mapping header files.

The output (container MemMapAddressingModeSet) is treated aspre-configured configuration values for the "module" MemMap,because it can be prepared independently from the configuration for aspecific integration project.

Meth.bindingTime = SystemDesignTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Performed by Software Compo-nent Developer

0..1

Produces BSW Module Pre-configured Config-uration

1..* MemMapAddressingModeSet:Meth.bindingTime = SystemDesignTime

Table 3.14: Define Memory Addressing Modes

178 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 179: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.6 Configure Memmap Allocation

Configure Memmap Allocation

BSW Module Preconfigured Configuration

ECU Configuration Values

VFB Types

Basic Software Module Implementation Description

ECU Integrator

Basic Software Module Developer

Software Component Developer

Atomic Software Component Implementation

0..1

«performs»

0..1 «performs»

+MemorySections

0..* «input»

0..1

«performs»

+SwAddrMethods

0..*

«input»

+MemorySections

0..*

«input»

+MemMapAddressingModeSet

1..*

«input»

«output»

+MemMapAllocation

1

Figure 3.6: Configure Memmap Allocation

179 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 180: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Configure Memmap AllocationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription Configure the ECU Configuration part MemMapAllocation for module

"MemMap".

The output is to be used for generating memory mapping headersduring ECU integration as well as for BSW and SWC compiling/linkingin local environments.

MemMapAllocation defines a mapping between abstract memorysections used in BSW or SWC code and compiler specificconfiguration elements. The abstract sections are identified via links toSwAddrmethods (generic mapping) resp. MemorySections of the XMLinput files. The compiler specific configuration is given as apre-configured configuration for module "MemMap" via the containerMemMapAddressingModeSet.

For more information refer to document ID 128:SWS_MemoryMapping.

Meth.bindingTime = SystemDesignTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer0..1

Performed by ECU Integrator 0..1Performed by Software Compo-

nent Developer0..1

Consumes BSW Module Pre-configured Config-uration

1..* MemMapAddressingModeSet: Collectionof compiler specific configurationelements for memory allocation andaddressing modes.

Consumes Atomic SoftwareComponent Imple-mentation

0..* MemorySections:

Consumes Basic SoftwareModule Implemen-tation Description

0..* MemorySections:

Consumes VFB Types 0..* SwAddrMethods: SwAddrMethods usedfor the generic mapping. Note that oneSwAddrmethod can represent severalmemory sections.

Produces ECU ConfigurationValues

1 MemMapAllocation:Meth.bindingTime = SystemDesignTime

Table 3.15: Configure Memmap Allocation

180 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 181: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.7 Generate BSW Memory Mapping Header

Generate BSW Memory Mapping Header

BSW Module Preconfigured Configuration

ECU Configuration Values

VFB Types

Standard Header Files

Basic Software Module Implementation Description

Basic Software Module Developer

ECU Integrator

Basic Software Module Description

+SwAddrMethod

1..*

«input»

+moduleDescription

0..1

«input»

+infixes

1

«input»+DependencyOnArtifact

1

«input»

+MemorySections

1

«input»

+MemMapAddressingModeSet

1..*

«input»

+MemMapAllocation

1

«input»

1

«performs»

+shortName 0..1

«input»

0..1

«performs»

«output»

+BSW_MemMap

1

Figure 3.7: Generate BSW Memory Mapping Header

181 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 182: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Generate BSW Memory Mapping HeaderPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription Generate a memory mapping header to be used for one BSW module

(the default case) or a group of BSW modules (e.g. an ICC2 cluster).Note that the usage of one MemMap.h for the complete BSW of onebuild environment is possible, but deprecated.

This task can be used in ECU scope or with preliminary scope to testBSW modules. Note that the content of the generated file is compilerspecific (#pragma statements).

Inputs are:

• From Basic Software Module Description: The shortName isused (in the default case) as the first part of the generated filename.

• From VFB Types: Properties of abstract sections given bySwAddrmethods, which in turn are referred by MemorySectionas well as by MemMapAllocation.

• From Basic Software Module Implementation Description:Names of the individual abstract sections (preprocessor macros)used in the code (including optional prefixes overriding thedefault rule); optional infixes for the file name (if the default ruleis used); optional declaration of file name (elementDependencyOnArtifact) overriding the default rule.

• From Preconfigured Configuration for module "MemMap":Collection of compiler specific configuration elements.

• From ECU Configuration for module "MemMap" :MemMapAllocation - this is the concrete mapping for thisenvironment.

• From ECU Configuration: Find the list of used BSW modules incase the task is done for the whole BSW(EcucValueCollection.ecucValue.moduleDescription).

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by ECU Integrator 1Performed by Basic Software

Module Developer0..1

Consumes Basic SoftwareModule Implemen-tation Description

1 infixes: Optional infixes (denotinginstance and vendor ID) to be usedwithin the created header file name.Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule Implemen-tation Description

1 DependencyOnArtifact: Can be used tooverride the default name of the memorymapping header file.Meth.bindingTime = SystemDesignTime

182 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 183: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Basic Software

Module Implemen-tation Description

1 MemorySections: MemorySectionsdefined for a BSW module. This inputincludes optional prefixes for memorysections overriding the default rule.Meth.bindingTime = SystemDesignTime

Consumes ECU ConfigurationValues

1 MemMapAllocation: Mapping of theabstract sections (SwAddressMethodsfor generic mapping resp.MemorySection Elements for specificmapping) to the compiler specificMemMapAddressingModes.Meth.bindingTime = SystemDesignTime

Consumes BSW Module Pre-configured Config-uration

1..* MemMapAddressingModeSet: Collectionof compiler specific configurationelements for memory allocation.Meth.bindingTime = SystemDesignTime

Consumes VFB Types 1..* SwAddrMethod: ReferredSwAddrMethodsMeth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule Descrip-tion

0..1 shortName: The BSW module’sshortName is used as the first part of thegenerated file name, in case the defaultrule applies.Meth.bindingTime = SystemDesignTime

Consumes ECU ConfigurationValues

0..1 moduleDescription: List of used BSWmodules (EcucValueCollec-tion.ecucValue.moduleDescription)Meth.bindingTime = SystemDesignTime

Produces Standard HeaderFiles

1 BSW_MemMap: The memory mappingheader file to be used for one or moreBSW modules in a given buildenvironment.

The file name has in the standardizedcase a form like {Mip}_MemMap.h inwhich the prefixes {Mip} are determinedby the module (or cluster) name andoptional infixes.

However, it is also possible to create acompletely different filename via explicitdeclaration in the BSW ModuleImplementation.

For more detailed rules on the name ofthe generated file refer toAUTOSAR_SWS_MemoryMapping.Meth.bindingTime =CodeGenerationTime

Table 3.16: Generate BSW Memory Mapping Header

183 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 184: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.8 Generate SWC Memory Mapping Header

BSW Module Preconfigured Configuration

ECU Configuration Values

VFB Types

Standard Header Files

ECU Integrator

Generate SWC Memory Mapping Header

Software Component Developer

Atomic Software Component Implementation

«output»

+SWC_MemMap

1

1

«performs»

+MemMapAllocation

1

«input»

+MemMapAddressingModeSet

1..* «input»

+RteImplementationRef

0..1

«input»

+MemorySections

1

«input»

0..1

«performs»

+SwAddrMethod

1..*

«input»

Figure 3.8: Generate SWC Memory Mapping Header

184 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 185: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Generate SWC Memory Mapping HeaderPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription Generate the memory mapping header file for one build environment

and one Atomic Software Component. This task can be used in ECUscope or with preliminary scope to test software component. Note thatthe generated header file is compiler specific (#pragma statements).

Inputs are:

• From VFB Types: Properties of abstract sections given bySwAddrmethods, which in turn are referred by MemorySectionas well as by MemMapAllocation

• From Software Component Implementation, elementMemorySection: Names of the individual abstract sections(preprocessor macros) used in the code.

• From Preconfigured Configuration for module "MemMap":Collection of compiler specific configuration elements.

• From ECU Configuration for module "MemMap" :MemMapAllocation - This is the concrete mapping for thisenvironment.

• From ECU Configuration: Find (optionally) the list of usedsoftware component implementations by usage of the RTE ECUConfiguration "RteSwComponentType.RteImplementationRef"

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by ECU Integrator 1Performed by Software Compo-

nent Developer0..1

Consumes Atomic SoftwareComponent Imple-mentation

1 MemorySections: MemorySectionsdefined for an Atomic SoftwareComponent.Meth.bindingTime = SystemDesignTime

Consumes ECU ConfigurationValues

1 MemMapAllocation: Mapipng of theabstract sections (SwAddressMethodsfor generic mapping resp.MemorySection Elements for specificmapping) to the compiler specificMemMapAddressingModes.Meth.bindingTime = SystemDesignTime

Consumes BSW Module Pre-configured Config-uration

1..* MemMapAddressingModeSet: Collectionof compiler specific configurationelements for memory allocation.Meth.bindingTime = SystemDesignTime

Consumes VFB Types 1..* SwAddrMethod: ReferredSwAddrMethodsMeth.bindingTime = SystemDesignTime

185 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 186: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes ECU Configuration

Values0..1 RteImplementationRef: Existence of

SWCs could be identified by usage of theRTE ECU Configuration "RteSwCompo-nentType.RteImplementationRef"Meth.bindingTime = SystemDesignTime

Produces Standard HeaderFiles

1 SWC_MemMap: One header persoftware component type for a givenbuild environment.

The file name follows the pattern{componentTypeName}_MemMap.h inwhich the prefix componentTypeName isdetermined by the software componenttype name.

For more detailed rules on the name ofthe generated file refer toAUTOSAR_SWS_MemoryMapping.Meth.bindingTime =CodeGenerationTime

Table 3.17: Generate SWC Memory Mapping Header

3.1.2.9 Configure Compiler Memory Classes

Basic Software Module Developer

Software Component Developer

BSW Module Preconfigured Configuration

Configure Compiler Memory Classes

1

«performs»

0..1

«performs»

«output»

+MemMap config forcompiler memclasses

1..*

Figure 3.9: Define Compiler Memory Classes

186 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 187: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Configure Compiler Memory ClassesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription Define the compiler specific configuration for "memory classes" used in

a later task to generate the preprocessor code of the compilerconfiguration header file (Compiler_Cfg.h).

The output is treated as pre-configured configuration values for the"module" MemMap, because it can be prepared independently fromthe configuration for a specific integration project.

Meth.bindingTime = SystemDesignTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Performed by Software Compo-nent Developer

0..1

Produces BSW Module Pre-configured Config-uration

1..* MemMap config for compilermemclasses: Set the parameter valuesthat define generic MemClassSymbols(i.e. those not defined by modules orSWCs.).

Set the parameter values that define theimplementation behind all kind ofMemClassSymbols (generic and localones).Meth.bindingTime = SystemDesignTime

Table 3.18: Configure Compiler Memory Classes

187 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 188: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.2.10 Generate Compiler Configuration

Generate Compiler Configuration

Software Component Developer

Basic Software Module Developer

ECU Integrator

Standard Header Files

ECU Configuration Values

BSW Module Preconfigured Configuration

Basic Software Module Implementation Description

VFB Types

Atomic Software Component Implementation

«output»

+Compiler_Cfg

1

«performs»

+MemorySections

0..*

«input»

+RteImplementationRef

0..1

«input»

+CompilerMemClassConfiguration

1..*

«input»

0..1

«performs»

0..1 «performs»

+SwAddrMethod

1..*

«input»

+MemorySections

1..* «input»

+ModuleDescription

0..1

«input»

Figure 3.10: Generate Compiler Configuration

Task Definition Generate Compiler ConfigurationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::TasksBrief DescriptionDescription This task generates a compiler configuration header (Compiler_cfg.h)

for one build environment to be used for all BSW modules and softwarecomponents.

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by ECU Integrator 1Performed by Basic Software

Module Developer0..1

Performed by Software Compo-nent Developer

0..1

188 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 189: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes BSW Module Pre-

configured Config-uration

1..* CompilerMemClassConfiguration: Theparameters "MemMapCompilerMem-ClassSymbolImpl" and"MemMapGenericCompilerMem-ClassSymbolImpl" define theimplementation behind aMemClassSymbol.Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule Implemen-tation Description

1..* MemorySections: Find referredSwAddrMethods or specificmemClassSymbols in theMemorySections defined for BSWmodules.Meth.bindingTime = SystemDesignTime

Consumes VFB Types 1..* SwAddrMethod: ReferredSwAddrMethods. They provide thedefault names for the compiler memoryclasses.Meth.bindingTime = SystemDesignTime

Consumes ECU ConfigurationValues

0..1 RteImplementationRef: Existence ofSWCs could be identified by usage of theRTE ECU Configuration "RteSwCompo-nentType.RteImplementationRef"Meth.bindingTime = SystemDesignTime

Consumes ECU ConfigurationValues

0..1 ModuleDescription: List of used BSWmodules (EcucValueCollec-tion.ecucValue.moduleDescription)Meth.bindingTime = SystemDesignTime

Consumes Atomic SoftwareComponent Imple-mentation

0..* MemorySections: Find referredSwAddrMethods or specificmemClassSymbols in theMemorySections defined for AtomicSoftware Components.Meth.bindingTime = SystemDesignTime

Produces Standard HeaderFiles

1 Compiler_Cfg: The output file"Compiler_Cfg.h" configures theabstraction of compiler specifics.Meth.bindingTime =CodeGenerationTime

Table 3.19: Generate Compiler Configuration

3.1.3 Work Products

3.1.3.1 General Documentation

189 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 190: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact General DocumentationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief DescriptionDescription General documentation link to a given work productKind CustomRelation Type Related Element Mul. NoteAggregated by General Deliver-

able0..*

Produced by Add General Docu-mentation

1

Table 3.20: General Documentation

3.1.3.2 Alias Name Set

Artifact Alias Name SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Set of alias names for AUTOSAR model elements for usage outside of

AUTOSAR.Description Set of alias names, each consisting of the name (string) itself and the

reference to the model element it renames.

Each reference to a model element is either a reference to anIdentifiable or to an entry in an ECU Flat Map or System Flat Map.

For an explanation of uses cases see task Define Alias Names.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..1 Alias names valid in the context of thedelivered components.

Aggregated by System Descrip-tion

0..*

Produced by Define AliasNames

1

Consumed by Add Documenta-tion to the SoftwareComponent

0..* Optional input in order to refer to uniquenames defined in an Alias Name Set(e.g. System Constants).

Consumed by Generate A2L 0..*Use meta model element AliasNameSet 1

Table 3.21: Alias Name Set

3.1.3.3 Evaluated Variant Set

190 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 191: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Evaluated Variant SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description A set of evaluated variantsDescription This artifact represents a table defining which ArElements or

ArPackages (referrred as "evaluatedElements") are able to support oneor more particular variant. It can thus be used to document whichvariants are support by a certain delivery, e.g. of a software componentor of a system.

In other words, for a given set of evaluatedElements this elementrepresents a table of evaluated variants, where each PredefinedVariantrepresents one column. In this column each descendantswSystemConstantValue (part of System Constant Value Set) resp.postbuildVariantCriterionValue (part of Postbuid Variant Set) representsone entry.

In a graphical representation each swSystemConstantValueSet /postBuildVariantCriterionValueSet could be used as an intermediateheadline in the table column.

The Evaluated Variant Set comes with an attribute "approvalStatus". Ifthis is set to "APPROVED" it expresses that the evaluatedElements areknown be valid for the given evaluated variants.

Note that an evaluatedElement could be another Evaluated VariantSet. This allows to establish a hierarchy of EvaluatedVariantSets.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..1

Aggregated by ECU Extract ofSystem VariantModel

0..*

Aggregated by System Descrip-tion

0..*

Aggregated by VFB System 0..*Produced by Define System

Variants1

Produced by Evaluate Variant 1Produced by Define Integration

Variant0..1 Meth.bindingTime = SystemDesignTime

Produced by Define VFB Vari-ants

0..*

Consumed by Evaluate Variant 0..1Consumed by Extract ECU Sys-

tem Variant Model0..*

Use meta model element EvaluatedVariantSet

1

Table 3.22: Evaluated Variant Set

191 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 192: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.3.4 General Autosar Artifact

Artifact General Autosar ArtifactPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Describes the meta data for an AUTOSAR artifact.Description This artifact represents the data which are common to all AUTOSAR

XML artifacts.

Each file starts with the root element AUTOSAR.

The content of such an artifact below this root element is organized bypackages using the element ARPackage. Packages can be nested. Itis important to understand, that the hierarchy defined via packages andother aggregated elements can (in general) span over several XMLfiles, i.e. over several artifacts. That means, if an aggregation is "split"between several files, each file is considered as a separate artifact bythe methodology, even if the elements are formally aggregated withinthe same package.

All elements derived from meta-class Identifiable can carrydocumentation and administrative description based on the elementAdminData. Note that ARPackage is itself derived from Identifiable, sothere can be AdminData for the top-level package, for sub-packagesand for more specific elements (derived from Identifiable) as well. TheAdminData among other things contain revision information (includingthe artifact version) based on the metamodel element DocRevision .

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by General Deliver-

able0..*

Produced by Define ASIL For AUTOSAR Element

1

Produced by Define Admin Data 1Produced by Allocate Safety

Measure0..* Allocated Elements:

Produced by Allocate Safety Re-quirement

0..* Allocated Elements:

Consumed by Define ASIL For AUTOSAR Element

1

Consumed by Allocate SafetyMeasure

1..*

Consumed by Allocate Safety Re-quirement

1..*

Consumed by Evaluate Variant 1..*Consumed by Define Safety Mea-

sure0..*

Consumed by Define Safety Re-quirement

0..*

Use meta model element ARPackage 1Use meta model element AUTOSAR 1

192 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 193: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. Note

Table 3.23: General Autosar Artifact

3.1.3.5 General Deliverable

General Deliverable

General Autosar Artifact General Non Autosar Artifact General Documentation

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

Figure 3.11: General Deliverable

Deliverable General DeliverablePackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description General data for an XML based deliverable within AUTOSAR.Description General data for an XML based deliverable within AUTOSAR :

Especially it contains a catalog of all included artifacts. These can beAUTOSAR artifacts (see General Autosar Artifact) or non-AUTOSARartifacts (see General Non AUTOSAR Artifact).

An AUTOSAR XML artifact which is contained in the catalog may referto an non AUTOSAR Artifact whithin the catalog via the metamodelelement AutosarEngineeringObject (seeAUTOSAR_TPS_GenericStructureTemplate.pdf for further description).

Kind DeliveredRelation Type Related Element Mul. NoteAggregates General Autosar

Artifact0..*

Aggregates General Documen-tation

0..*

Aggregates General NonAutosar Artifact

0..*

Table 3.24: General Deliverable

3.1.3.6 General Non-Autosar Artifact

193 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 194: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact General Non Autosar ArtifactPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Describes the data for a non AUTOSAR artifact.Description Describes the data for a non AUTOSAR artifact.Kind CustomRelation Type Related Element Mul. NoteAggregated by General Deliver-

able0..*

Consumed by Provide RTE Cali-bration Dataset

1..* input from calibration process

Table 3.25: General Non Autosar Artifact

3.1.3.7 Postbuild Variant Set

Artifact Postbuild Variant SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Set of Postbuild Variant Criterion Values used to define post-build

variants of the software.Description Set of Postbuild Variant Criterion Values used to define post-build

variants of the software.

Such a set does not necessarily define a variant which is actually used.To define a meaningful variant in the production process, such a set isto be used via reference by artifact PredefinedVariant.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..1

Aggregated by ECU Extract ofSystem VariantModel

0..*

Aggregated by System Descrip-tion

0..*

Aggregated by VFB System 0..*In/out Define System

Variants1

In/out Define IntegrationVariant

0..*

In/out Define VFB Vari-ants

0..*

Consumed by Generate RTEPostbuild Dataset

1

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..1

194 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 195: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Generate RTE

Prebuild Dataset0..1

Consumed by Evaluate Variant 0..*Consumed by Extract ECU Sys-

tem Variant Model0..*

Use meta model element PostBuildVariantCriterionValueSet

1

Table 3.26: Postbuild Variant Set

3.1.3.8 Predefined Variant

Artifact Predefined VariantPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Defines a variant predefined for usage in subsequent process steps.Description Defines one variant of a software description for delivery and/or usage

in subsequent process steps. The actual definition of all settings whichmake up this variant is given by attached System Constant Value Set(all settings which are resolved prior to post-build) and/or PostbuidVariant Set (all settings which are resolved after software build). Thesesets may be part of the same artifact or may be separated artifacts. Viathese settings, the actual values which make up a particular variant,are selected.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Aggregated by ECU Extract ofSystem VariantModel

0..*

Aggregated by System Descrip-tion

0..*

Aggregated by VFB System 0..*Produced by Define Integration

Variant1 Meth.bindingTime = SystemDesignTime

Produced by Define SystemVariants

1

Produced by Define VFB Vari-ants

0..*

Consumed by Generate BSWModule PrebuildData Set

1

Consumed by Generate RTEPostbuild Dataset

1

Consumed by Generate RTEPrebuild Dataset

1

195 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 196: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Generate Atomic

Software Com-ponent ContractHeader Files

0..1

Consumed by Evaluate Variant 0..*Consumed by Extract ECU Sys-

tem Variant Model0..*

Consumed by Generate Compo-nent Prebuild DataSet

0..*

Use meta model element PredefinedVariant 1

Table 3.27: Predefined Variant

3.1.3.9 Standard Header Files

Artifact Standard Header FilesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Overall header files to be included by each standardized BSW module,

optionally also by Software Component code.Description Overall header files to be included by each standardized BSW module,

optionally also by Software Component code. For simplicity of themethodology, these are modeled as one artifact though in practicethese are several different files:

• (<prefixes>_)MemMap.h - defines a common set of macros inorder to define abstract memory sections for code and data inthe source code . The prefixes indicates whether the scope islimited to a component, module or some other source code area(e.g. an ICC2 cluster). Note that the usage of one MemMap.hfor the complete BSW is possible, but deprecated. It is alsopossible to use a completely different filename via explicitdeclaration in the BSW Module Implementation Description.

• Std_Types.h - defines a common set of C data types for usagewithin the basic software, this header includes the following twoheaders:

• Compiler.h (in turn including Compiler_Cfg.h) - for abstraction ofcompiler specifics, in which the second header is the part that issubject to configuration

• Platform_Types.h - for abstraction of platform specific types

Kind Source CodeRelation Type Related Element Mul. Note

196 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 197: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Generate BSW

Memory MappingHeader

1 BSW_MemMap: The memory mappingheader file to be used for one or moreBSW modules in a given buildenvironment.

The file name has in the standardizedcase a form like {Mip}_MemMap.h inwhich the prefixes {Mip} are determinedby the module (or cluster) name andoptional infixes.

However, it is also possible to create acompletely different filename via explicitdeclaration in the BSW ModuleImplementation.

For more detailed rules on the name ofthe generated file refer toAUTOSAR_SWS_MemoryMapping.Meth.bindingTime =CodeGenerationTime

Produced by Generate CompilerConfiguration

1 Compiler_Cfg: The output file"Compiler_Cfg.h" configures theabstraction of compiler specifics.Meth.bindingTime =CodeGenerationTime

Produced by Generate SWCMemory MappingHeader

1 SWC_MemMap: One header persoftware component type for a givenbuild environment.

The file name follows the pattern{componentTypeName}_MemMap.h inwhich the prefix componentTypeName isdetermined by the software componenttype name.

For more detailed rules on the name ofthe generated file refer toAUTOSAR_SWS_MemoryMapping.Meth.bindingTime =CodeGenerationTime

Consumed by Compile AtomicSoftware Compo-nent

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile BSWCore Code

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile ECUSource Code

1 Meth.bindingTime =CodeGenerationTime

Consumed by Implement a BSWModule

1 Meth.bindingTime =CodeGenerationTime

Consumed by Re-compile Com-ponent in ECUcontext

1 Meth.bindingTime =CodeGenerationTime

197 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 198: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Implement Atomic

Software Compo-nent

0..1 Meth.bindingTime =CodeGenerationTime

Table 3.28: Standard Header Files

3.1.3.10 System Constant Value Set

Artifact System Constant Value SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Work ProductsBrief Description Set of System Constant Values used to handle variants.Description Set of System Constant Values used to define pre-build variants of the

software.

Such a set does not necessarily define a variant which is actually used.To define a meaningful variant in the production process, such a set isto be used via reference by artifact PredefinedVariant.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Aggregated by ECU Extract ofSystem VariantModel

0..*

Aggregated by System Descrip-tion

0..*

Aggregated by VFB System 0..*In/out Define System

Variants1

In/out Define IntegrationVariant

0..*

In/out Define VFB Vari-ants

0..*

Consumed by Generate BSWModule PrebuildData Set

1

Consumed by Generate RTEPrebuild Dataset

1

Consumed by Generate Compo-nent Prebuild DataSet

1..* Meth.bindingTime =CodeGenerationTime

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..1 Meth.bindingTime = SystemDesignTime

Consumed by Evaluate Variant 0..*Consumed by Extract ECU Sys-

tem Variant Model0..*

198 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 199: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteUse meta model element SwSystemcon-

stantValueSet1

Table 3.29: System Constant Value Set

3.1.4 Roles

Role AUTOSAR PartnershipPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description The AUTOSAR Partnership development defines standard artifacts.DescriptionRelation Type Related Element Mul. Note

Table 3.30: AUTOSAR Partnership

Role Basic Software DesignerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Role responsible for the overall design of the Basic Software.Description Role responsible for the overall design of the Basic Software. In

contrast to the Basic Software Module Developer he is responsible forthe consistency of interfaces and data types between modules.

Relation Type Related Element Mul. NotePerforms Define BSW Be-

havior1

Performs Define BSW En-tries

1

Performs Define BSW Inter-faces

1

Performs Define BSW Types 1Performs Create Trans-

former Specifica-tion

0..1

Performs Define VFB NvBlock SoftwareComponent

0..1

Performs Define VendorSpecific ModuleDefinition

0..1

Table 3.31: Basic Software Designer

199 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 200: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Role Basic Software Module DeveloperPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Role responsible to develop and deliver a Basic Software Module.DescriptionRelation Type Related Element Mul. NotePerforms Compile BSW

Core Code1

Performs Configure Com-piler MemoryClasses

1

Performs Create Library 1Performs Define BSW En-

tries1

Performs Define BSW Inter-faces

1

Performs Define BSW Mod-ule Timing

1

Performs Define BSW Types 1Performs Define Memory

Addressing Modes1

Performs Develop BSWModule Generator

1

Performs Generate BSWModule PrebuildData Set

1

Performs Generate BSWMContract HeaderFiles

1

Performs Implement a BSWModule

1

Performs ConfigureMemmap Allo-cation

0..1

Performs Define VendorSpecific ModuleDefinition

0..1

Performs Generate BSWMemory MappingHeader

0..1

Performs Generate CompilerConfiguration

0..1

Performs Measure Compo-nent Resources

0..1

Table 3.32: Basic Software Module Developer

200 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 201: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Role Calibration EngineerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description The calibration engieer determines the calibration parameters of an

ECU.DescriptionRelation Type Related Element Mul. NotePerforms Define VFB Pa-

rameter Compo-nent

1

Performs Generate A2L 1Performs Create MC Func-

tion Model0..1

Performs Define VFB Con-stants

0..1

Performs Provide RTE Cali-bration Dataset

0..1

Table 3.33: Calibration Engineer

Role Certification AgencyPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description The certification agency verifies the conformance of artifacts with

respect to the standard artifacts defined by the autosar consortium.DescriptionRelation Type Related Element Mul. Note

Table 3.34: Certification Agency

Role ECU IntegratorPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Integrates the complete software on an ECU.Description Integrates the complete software on an ECU, which includes

generating necessary code and completing the configuration of allsoftware components and basic software modules.

Relation Type Related Element Mul. NotePerforms Compile ECU

Source Code1

Performs Configure Com 1Performs Configure Debug 1Performs Configure Diag-

nostics1

Performs Configure ECUC 1Performs Configure IO Hard-

ware abstraction1

Performs Configure MCAL 1

201 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 202: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NotePerforms Configure Mode

Management1

Performs Configure NvM 1Performs Configure OS 1Performs Configure RTE 1Performs Configure Trans-

former1

Performs Configure Watch-dog Manager

1

Performs Connect ServiceComponent

1

Performs Create Library 1Performs Create Service

Component1

Performs Define ECU Tim-ing

1

Performs Define IntegrationVariant

1

Performs Extract the ECUCommunication

1

Performs Generate BSW ConfigurationCode

1

Performs Generate BSWMemory MappingHeader

1

Performs Generate BaseEcu Configuration

1

Performs Generate CompilerConfiguration

1

Performs Generate ECU Ex-ecutable

1

Performs Generate Local MC Data Support

1

Performs Generate OS 1Performs Generate RTE 1Performs Generate RTE

Postbuild Dataset1

Performs Generate RTEPrebuild Dataset

1

Performs Generate SWCMemory MappingHeader

1

Performs Generate Sched-uler

1

Performs Generate UpdatedECU Configuration

1

Performs Measure Re-sources

1

202 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 203: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NotePerforms Provide RTE Cali-

bration Dataset1

Performs ConfigureMemmap Allo-cation

0..1

Performs Create MC Func-tion Model

0..1

Performs Define VFB NvBlock SoftwareComponent

0..1

Performs Extend Topology 0..1Performs Extract ECU Rapid

Prototyping Sce-nario

0..1

Performs Extract ECU Sys-tem Timing

0..1

Performs Extract ECU Sys-tem Variant Model

0..1

Performs Extract ECU Topol-ogy

0..1

Performs Flatten SoftwareComposition

0..1

Performs Generate Compo-nent Header File inVendor Mode

0..1

Performs Generate or AdjustECU Flat Map

0..1

Performs Map SoftwareComponent to BSW

0..1

Performs Measure Compo-nent Resources

0..1

Table 3.35: ECU Integrator

Role Software Component DesignerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Designer of software components and VFB systems.DescriptionRelation Type Related Element Mul. NotePerforms Add Documenta-

tion to the SoftwareComponent

1

Performs Define AtomicSoftware Com-ponent InternalBehavior

1

Performs Define ComplexDriver Component

1

203 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 204: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NotePerforms Define Consis-

tency Needs1

Performs Define ECUAbstraction Com-ponent

1

Performs Define VFB Ap-plication SoftwareComponent

1

Performs Define VFB Com-position Compo-nent

1

Performs Define VFB Con-stants

1

Performs Define VFB Inter-faces

1

Performs Define VFB Modes 1Performs Define VFB Sen-

sor or ActuatorComponent

1

Performs Define VFB Timing 1Performs Define VFB Types 1Performs Define VFB Vari-

ants1

Performs Define WrapperComponents toIntegrate LegacySoftware

1

Performs Map SoftwareComponent to BSW

1

Performs Define Partial FlatMap

0..1

Performs Define VFB Com-ponent Constraints

0..1

Performs Define VFB NvBlock SoftwareComponent

0..1

Performs Define VFB TopLevel

0..1

Table 3.36: Software Component Designer

Role Software Component DeveloperPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Developer of the software component code.DescriptionRelation Type Related Element Mul. Note

204 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 205: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NotePerforms Define Consis-

tency Needs1

Performs Define SoftwareComponent Timing

1

Performs Define SymbolProps for Types

1

Performs Generate AtomicSoftware Com-ponent ContractHeader Files

1

Performs Generate Compo-nent Header File inVendor Mode

1

Performs Generate Compo-nent Prebuild DataSet

1

Performs Implement AtomicSoftware Compo-nent

1

Performs Measure Compo-nent Resources

1

Performs Re-compile Com-ponent in ECUcontext

1

Performs Add Documenta-tion to the SoftwareComponent

0..1

Performs Compile AtomicSoftware Compo-nent

0..1

Performs Configure Com-piler MemoryClasses

0..1

Performs ConfigureMemmap Allo-cation

0..1

Performs Define AtomicSoftware Com-ponent InternalBehavior

0..1

Performs Define MemoryAddressing Modes

0..1

Performs Define Partial FlatMap

0..1

Performs Generate CompilerConfiguration

0..1

Performs Generate SWCMemory MappingHeader

0..1

Table 3.37: Software Component Developer

205 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 206: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Role System EngineerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Creation, management, developement and integration of systems

within the vehicleDescriptionRelation Type Related Element Mul. NotePerforms Assign Top Level

Composition1

Performs Create Trans-former Specifica-tion

1

Performs Define Communi-cation Matrix

1

Performs Define E2E Trans-former Technology

1

Performs Define ECU De-scription

1

Performs Define Frames 1Performs Define Network

Management1

Performs Define PDU Gate-way

1

Performs Define RTE Fan-out

1

Performs Define Secured PDUs

1

Performs Define SignalGateway

1

Performs Define Signal PDUs

1

Performs Define Signal PathConstraints

1

Performs Define SoftwareComponent Map-ping Constraints

1

Performs Define SystemTiming

1

Performs Define SystemTopology

1

Performs Define SystemVariants

1

Performs Define SystemView Mapping

1

Performs Define TP 1Performs Define Transforma-

tion Technology1

Performs Deploy SoftwareComponent

1

206 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 207: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NotePerforms Derive Communi-

cation Needs1

Performs Extend Composi-tion

1

Performs Extract the ECUCommunication

1

Performs Flatten SoftwareComposition

1

Performs Generate or AdjustSystem Flat Map

1

Performs Select DesignTime Variant

1

Performs Select SoftwareComponent Imple-mentation

1

Performs Set System Root 1Performs Define VFB Com-

ponent Constraints0..1

Performs Define VFB Com-position Compo-nent

0..1

Performs Define VFB Con-stants

0..1

Performs Define VFB TopLevel

0..1

Performs Extend Topology 0..1Performs Extract ECU Rapid

Prototyping Sce-nario

0..1

Performs Extract ECU Sys-tem Timing

0..1

Performs Extract ECU Sys-tem Variant Model

0..1

Performs Extract ECU Topol-ogy

0..1

Performs Generate or AdjustECU Flat Map

0..1

Table 3.38: System Engineer

207 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 208: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Role Non-AUTOSAR System IntegratorPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief Description Responsibility for the quality of the description of the non-AUTOSAR

system and its integration into the AUTOSAR process.Description The non-AUTOSAR System Integrator is responsible for the quality of

the Description of the non-AUTOSAR System, the correct definition ofthe VFB Integration Connector, and the integration of thenon-AUTOSAR system into the AUTOSAR process via the translationof the non-AUTOSAR artifacts.

Relation Type Related Element Mul. NotePerforms Define VFB Inte-

gration Connector1

Performs Translate Non-Autosar Descrip-tion to AutosarDescription

1

Table 3.39: Non-AUTOSAR System Integrator

Role Rapid Prototyping EngineerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief DescriptionDescriptionRelation Type Related Element Mul. NotePerforms Define Rapid Pro-

totyping Scenario1

Performs Generate RapidPrototyping Wrap-per

1

Performs Refine Rapid Pro-totyping Scenario

1

Performs Compile AtomicSoftware Compo-nent

0..1

Table 3.40: Rapid Prototyping Engineer

Role Safety EngineerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::RolesBrief DescriptionDescription Responsibility for the safety relevant steps in the AUTOSAR

development processRelation Type Related Element Mul. NotePerforms Add Independence

Relation1

Performs Allocate SafetyMeasure

1

208 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 209: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NotePerforms Allocate Safety Re-

quirement1

Performs Decompose SafetyRequirement

1

Performs Define ASIL For AUTOSAR Element

1

Performs Define Safety Mea-sure

1

Performs Define Safety Re-quirement

1

Performs Map Safety Re-quirement toSafety Measure

1

Performs Refine Safety Re-quirement

1

Table 3.41: Safety Engineer

3.1.5 Tools

3.1.5.1 Compiler

Tool CompilerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::GuidanceBrief DescriptionDescriptionKindRelation Type Related Element Mul. NoteUsed Compile Atomic

Software Compo-nent

1

Used Compile BSWConfiguration Data

1

Used Compile BSWCore Code

1

Used Compile Config-ured BSW

1

Used Compile ECUSource Code

1

Used Compile Gener-ated BSW

1

Used Compile Unconfig-ured BSW

1

Used Re-compile Com-ponent in ECUcontext

1

Table 3.42: Compiler

209 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 210: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.5.2 Linker

Tool LinkerPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::GuidanceBrief DescriptionDescriptionKindRelation Type Related Element Mul. NoteUsed Generate ECU Ex-

ecutable1

Used Link ECU Codeafter PrecompileConfiguration

1

Used Link ECU Codeduring Link TimeConfiguration

1

Used Link ECU Codeduring Post-BuildTime

1

Table 3.43: Linker

3.1.6 Diagnostics

3.1.6.1 Work Products

Deliverable Diagnostic ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Diagnostics::Work ProductsBrief DescriptionDescription Generic deliverable for defining diagnostic information. It is used in

different roles (Diagnostic Extract categories).

In each role, this deliverable may contain variation points in its ARXMLartifacts which need to be bound in later steps. If such variation pointsare present, the Diagnostic Description may optionally includePredefinedVariants in order to predefine variants for later selection andan Evaluated Variant Set.

KindExtended by Diagnostic Abstract System Description, Diagnostic ECU Extract,

Diagnostic System ExtractRelation Type Related Element Mul. Note

Table 3.44: Diagnostic Extract

210 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 211: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable Diagnostic Abstract System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Diagnostics::Work ProductsBrief DescriptionDescription This deliverable represents a more or less high-level definition of

diagnostic information that can be taken as a template for creatingDiagnostic System Extract or Diagnostic ECU Extract. It correspondsto an Diagnostic Extract with DiagnosticContributionSet of categoryDIAGNOSTICS_ABSTRACT_SYSTEM_DESCRIPTION.

KindExtends Diagnostic ExtractRelation Type Related Element Mul. Note

Develop Diagnos-tic Requirements

0..*

Produced by Develop Diagnos-tic Abstract SystemDescription

1

Table 3.45: Diagnostic Abstract System Description

Deliverable Diagnostic System ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Diagnostics::Work ProductsBrief DescriptionDescription This deliverable represents concrete diagnostic information for several

ECUs. It corresponds to an Diagnostic Extract withDiagnosticContributionSet of categoryDIAGNOSTICS_SYSTEM_EXTRACT.

KindExtends Diagnostic ExtractRelation Type Related Element Mul. NoteProduced by Develop Applica-

tion Software0..*

Produced by Develop BasicSoftware

0..*

Produced by Develop Diagnos-tic Requirements

0..*

Consumed by Develop Applica-tion Software

0..*

Consumed by Develop BasicSoftware

0..*

Consumed by Develop Diagnos-tic Requirements

0..*

Consumed by Integrate Diagnos-tic Information

0..*

Table 3.46: Diagnostic System Extract

211 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 212: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable Diagnostic ECU ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Diagnostics::Work ProductsBrief DescriptionDescription This deliverable represents concrete diagnostic information for a single

ECUs. It corresponds to an Diagnostic Extract withDiagnosticContributionSet of categoryDIAGNOSTICS_ECU_EXTRACT.

KindExtends Diagnostic ExtractRelation Type Related Element Mul. NoteProduced by Integrate Diagnos-

tic Information1..* complete DE:

Produced by Develop Diagnos-tic Requirements

0..*

Consumed by Generate BaseEcu Configuration

0..1

Consumed by Generate UpdatedECU Configuration

0..1

Consumed by Integrate Softwarefor ECU

0..1 complete DE:

Consumed by Prepare ECU Con-figuration

0..1

Consumed by Update ECU Con-figuration

0..1

Consumed by Integrate Diagnos-tic Information

0..* partially filled DE:

Table 3.47: Diagnostic ECU Extract

3.1.7 Safety

3.1.7.1 Tasks

3.1.7.1.1 Define Safety Requirement

Safety Engineer

Define Safety Requirement

General Autosar Artifact

Safety Requirement

«output»

10..*

«input»

«performs»

Figure 3.12: Define Safety Requirement

212 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 213: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define Safety RequirementPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Add Safety Requirements to work products.Description This task creates a safety requirement and sets the corresponding

attributes such as ASIL. The allocation to an AUTOSAR element andthe mapping to a safety measure are not part of this task.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes General Autosar

Artifact0..*

Produces Safety Require-ment

1

Table 3.48: Define Safety Requirement

3.1.7.1.2 Define Safety Measure

Safety Engineer

Define Safety Measure

General Autosar Artifact

Safety Measure

«output»

1

«performs»

0..* «input»

Figure 3.13: Define Safety Measure

Task Definition Define Safety MeasurePackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Add Safety Measures to work products.Description This task creates a safety measure and sets the corresponding

attributes such as ASIL. The allocation to an AUTOSAR element andthe mapping to a safety requirement are not part of this task.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes General Autosar

Artifact0..*

Produces Safety Measure 1

Table 3.49: Define Safety Measure

213 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 214: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.3 Define ASIL For AUTOSAR Element

General Autosar Artifact

Safety Engineer

Define ASIL For AUTOSAR Element

1

«input»

«performs»

«output» 1

Figure 3.14: Define ASIL For AUTOSAR Element

Task Definition Define ASIL For AUTOSAR ElementPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Provide ASIL attribute for AUTOSAR element.Description According to the safety extensions, AUTOSAR elements can carry

ASIL attributes if they are safety relevant. This task assigns the ASILattribute to an AUTOSAR element.

The assignment of the ASIL attribute can also be done for safetyrequirements and safety measures. This is covered by the tasks"Define Safety Requirement" and "Define Safety Measure".

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes General Autosar

Artifact1

Produces General AutosarArtifact

1

Table 3.50: Define ASIL For AUTOSAR Element

214 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 215: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.4 Refine Safety Requirement

Safety Engineer

Refine Safety Requirement

Safety Requirement

«output»

+Refined Safety Requirement

1..*

+Original Safety Requirement

1 «input»

«performs»

Figure 3.15: Refine Safety Requirement

Task Definition Refine Safety RequirementPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Refine existing Safety Requirements by adding more detailed safety

requirements and organize them in an appropriate hierarchy.Description If safety requirements are not detailed enough to allocate them directly

to appropriate AUTOSAR elements, it is necessary to refine them first.The refinement will add new safety requirements which are in ahierarchy relation to existing safety requirements.

This task adds the corresponding "REFINEMENT" relation between theoriginal requirement and the newly created requirements.

This task can be done on different levels, depending on the level ofdetails of the safety requirements.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes Safety Require-

ment1 Original Safety Requirement:

Produces Safety Require-ment

1..* Refined Safety Requirement:

Table 3.51: Refine Safety Requirement

215 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 216: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.5 Decompose Safety Requirement

Safety Engineer

Decompose Safety Requirement

Safety Requirement

«output»

+Decomposed Safety Requirements

2

«performs»

+Initial Safety Requirement

1 «input»

Figure 3.16: Decompose Safety Requirement

Task Definition Decompose Safety RequirementPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Decompose existing Safety Requirements into independent Safety

Requirements to tailor the ASIL.Description By ASIL decomposition it is possible to decompose a safety

requirement into two new safety requirements with potentially lowerASILs. This can be done, if the independence (freedom of interference)for the resulting requirements can be demonstrated. The modeling ofthe corresponding INDEPENDENCE relation is covered by task "AddIndependence Relation".

This task adds the corresponding "DECOMPOSITION" reference.Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes Safety Require-

ment1 Initial Safety Requirement:

Produces Safety Require-ment

2 Decomposed Safety Requirements:

Table 3.52: Decompose Safety Requirement

216 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 217: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.6 Allocate Safety Measure

Safety Engineer

Allocate Safety MeasureGeneral

Autosar Artifact Safety Measure

«output»

+Allocated Safety Measure

0..1 «output»

+Allocated Elements

0..*

1

«input»1..* «input»

«performs»

Figure 3.17: Allocate Safety Measure

Task Definition Allocate Safety MeasurePackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Allocate Safety Measure to AUTOSAR elements.Description Safety measures which are safety mechanisms realized in AUTOSAR

are allocated to AUTOSAR elements in order to describe whatelements are involved in the provision of a safety measure. This taskadds the corresponding "ALLOCATION" reference. The reference canbe contained by the AUTOSAR element or by the safety measure.

The allocation can be done on different levels, depending on thegranularity of the safety measures and the availability of theappropriate elements in the model.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes Safety Measure 1Consumes General Autosar

Artifact1..*

Produces Safety Measure 0..1 Allocated Safety Measure:Produces General Autosar

Artifact0..* Allocated Elements:

Table 3.53: Allocate Safety Measure

217 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 218: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.7 Allocate Safety Requirement

Allocate Safety Requirement

General Autosar Artifact

Safety Engineer

Safety Requirement

«output»

+Allocated Requirement

0..1 «output»

+Allocated Elements

0..*

1

«input»

1..*

«input»

«performs»

Figure 3.18: Allocate Safety Requirement

Task Definition Allocate Safety RequirementPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Allocate Safety Requirement to AUTOSAR elements.Description Safety requirements are allocated to AUTOSAR elements in order to

fulfill the needs of ISO 26262. By this allocation, AUTOSAR elementsobtain their ASIL attribute (if not defined e.g. during previousdevelopment of the element).

This task adds the corresponding allocation reference to the AUTOSARelement. The reference can be contained by the AUTOSAR element orby the safety requirement.

The allocation can be done on different levels, depending on thegranularity of the safety requirements and the availability of theappropriate elements in the model.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes Safety Require-

ment1

Consumes General AutosarArtifact

1..*

Produces Safety Require-ment

0..1 Allocated Requirement:

Produces General AutosarArtifact

0..* Allocated Elements:

Table 3.54: Allocate Safety Requirement

218 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 219: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.8 Map Safety Requirement to Safety Measure

Safety Engineer

Map Safety Requirement to Safety MeasureSafety Requirement

Safety Measure

«output» 0..1 «output»0..1

1 «input»

«performs»

1 «input»

Figure 3.19: Map Safety Requirement to Safety Measure

Task Definition Map Safety Requirement to Safety MeasurePackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Map Safety Requirements to Safety MeasuresDescription The mapping relates safety requirements with safety measures. This

task creates the corresponding MAPS_TO relation. The mappingrelation can either be contained by the safety requirement or by thesafety measure.

The mapping can be done on different levels, depending on thegranularity of the safety requirements and the safety measures.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes Safety Measure 1Consumes Safety Require-

ment1

Produces Safety Measure 0..1Produces Safety Require-

ment0..1

Table 3.55: Map Safety Requirement to Safety Measure

219 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 220: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.1.9 Add Independence Relation

Add Independence Relation

Safety Engineer

Safety Requirement

«output»

+Linked Requirement

1..*

«performs»

1..* «input»

Figure 3.20: Add Independence Relation

Task Definition Add Independence RelationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::TasksBrief Description Add Independence relation to decomposed requirements.Description This task establishes the INDEPENDENCE relation between

requirements. The relation is established between a decomposedrequirement and a requirement which express a means to achievefreedom from interference for the two requirements into which thedecomposed requirement is decomposed by the task DecomposeSafety Requirement.

Obviously, this task is processed in the context of the decomposition ofsafety requirements.

Relation Type Related Element Mul. NotePerformed by Safety Engineer 1Consumes Safety Require-

ment1..*

Produces Safety Require-ment

1..* Linked Requirement:

Table 3.56: Add Independence Relation

220 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 221: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.2 Work Products

3.1.7.2.1 Safety Extensions

Safety Extensions

Safety Requirement

Safety Measure

VFB Safety Extensions Software Component Safety Extensions

System Safety Extensions

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.21: Safety Extensions

Deliverable Safety ExtensionsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::Work ProductsBrief Description Safety ExtensionsDescription This element represents an abstract deliverable containing all safety

relevant artifacts. Several specializations of this deliverable are used todemonstrate the handling of safety extensions in specific developmentactivities.

The explicit separation of the safety information from the AUTOSARmodels allows an independent exchange and processing of them.

Kind DeliveredExtended by Software Component Safety Extensions, System Safety Extensions, V

FB Safety ExtensionsRelation Type Related Element Mul. NoteAggregates Safety Measure 0..*Aggregates Safety Require-

ment0..*

Table 3.57: Safety Extensions

221 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 222: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable VFB Safety ExtensionsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::Work ProductsBrief Description Vfb Safety ExtensionsDescription This deliverable contains all safety information related to VFB

elements.Kind DeliveredExtends Safety ExtensionsRelation Type Related Element Mul. NoteProduced by Define VFB Safety

Information1

Consumed by Define SoftwareComponent SafetyInformation

1

Consumed by Define SystemSafety Information

1

Table 3.58: VFB Safety Extensions

Deliverable Software Component Safety ExtensionsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::Work ProductsBrief Description Software Component Safety ExtensionsDescription This deliverable contains all safety information related to software

components.Kind DeliveredExtends Safety ExtensionsRelation Type Related Element Mul. NoteProduced by Define Software

Component SafetyInformation

1

Consumed by Define SystemSafety Information

1

Table 3.59: Software Component Safety Extensions

Deliverable System Safety ExtensionsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::Work ProductsBrief Description System Safety ExtensionsDescription This deliverable contains all safety information related to system

elements (see Deliverable "System Description" for more details).Kind DeliveredExtends Safety ExtensionsRelation Type Related Element Mul. NoteProduced by Define System

Safety Information1

Table 3.60: System Safety Extensions

222 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 223: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.1.7.2.2 Safety Requirement

Artifact Safety RequirementPackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::Work ProductsBrief Description Safety RequirementDescription This artifact represents a safety requirement and the corresponding

ASIL attribute. ISO 26262 defines a hierarchy of safety requirements:safety goals, technical, hardware and software. Furthermore, it mightbe the case that safety requirements are specified outside theAUTOSAR model (external) and are only referenced. Thus, the safetyrequirement can have one of the following categories:

• SAFETY_GOAL

• SAFETY_FUNCTIONAL

• SAFETY_TECHNICAL

• SAFETY_SOFTWARE

• SAFETY_HARDWARE

• SAFETY_EXTERNAL

For details refer to ISO 26262-3, 4, 9 and TPS_SafetyExtensionsdocument.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Safety Extensions 0..*Produced by Decompose Safety

Requirement2 Decomposed Safety Requirements:

Produced by Define Safety Re-quirement

1

Produced by Add IndependenceRelation

1..* Linked Requirement:

Produced by Refine Safety Re-quirement

1..* Refined Safety Requirement:

Produced by Allocate Safety Re-quirement

0..1 Allocated Requirement:

Produced by Map Safety Re-quirement toSafety Measure

0..1

Consumed by Allocate Safety Re-quirement

1

Consumed by Decompose SafetyRequirement

1 Initial Safety Requirement:

Consumed by Map Safety Re-quirement toSafety Measure

1

Consumed by Refine Safety Re-quirement

1 Original Safety Requirement:

223 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 224: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Add Independence

Relation1..*

Use meta model element StructuredReq 1

Table 3.61: Safety Requirement

3.1.7.2.3 Safety Measure

Artifact Safety MeasurePackage AUTOSAR Root::M2::Methodology::Methodology Library::Common

Elements::Safety::Work ProductsBrief Description Safety MeasureDescription This artifact represents a safety measure. A safety measure is an

activity or solution to avoid systematic failures and to detect randomhardware failures or control failures (see ISO 26262).

The safety measure can have one of the following categories:

• SAFETY_MEASURE

• SAFETY_MECHANISM

For further details refer to TPS_SafetyExtensions document.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Safety Extensions 0..*Produced by Define Safety Mea-

sure1

Produced by Allocate SafetyMeasure

0..1 Allocated Safety Measure:

Produced by Map Safety Re-quirement toSafety Measure

0..1

Consumed by Allocate SafetyMeasure

1

Consumed by Map Safety Re-quirement toSafety Measure

1

Use meta model element TraceableText 1

Table 3.62: Safety Measure

3.2 Virtual Functional Bus

This chapter contains the definition of work products and tasks used for the develop-ment of a VFB system. For the definition of the relevant meta-model elements referto [5], for the VFB concepts refer to [4].

224 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 225: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1 Tasks

3.2.1.1 Define VFB Top Level

Define VFB Top Level

VFB Composition Component

VFB Atomic Software Component

VFB Non AUTOSAR Component

Software Component Designer

System Engineer

VFB Parameter Component

VFB Top Level System Composition

«output» 1

0..1

«performs»

0..*

«input»

0..*

«input»

0..*

«input»

0..* «input»

0..1

«performs»

Figure 3.22: Task Define VFB Top Level

Task Definition Define VFB Top LevelPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define the top level VFB composition of a concrete system.Description Define the top level composition of a VFB system.Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer0..1

Performed by System Engineer 0..1Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB Atomic Soft-

ware Component0..*

Consumes VFB CompositionComponent

0..*

Consumes VFB Modes 0..*Consumes VFB Non AUTOSA

R Component0..*

Consumes VFB ParameterComponent

0..*

Produces VFB Top LevelSystem Composi-tion

1

Table 3.63: Define VFB Top Level

225 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 226: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.2 Define VFB Composition Component

Define VFB Composition Component

Software Component DesignerSystem Engineer

VFB Composition Component

VFB Interfaces

VFB AUTOSAR Standard Package

VFB Types

VFB Atomic Software Component

VFB Modes

VFB Non AUTOSAR Component VFB Parameter Component

0..*

«input»

1..*

«input»

1

«performs»

0..*

«input»

0..*

«input»

0..*

«input»

0..1

«input»

1..* «input»

0..*

«input»

0..1

«performs»

«output» 1

Figure 3.23: Task Define VFB Composition Component

Task Definition Define VFB Composition ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a Composition of VFB Software Components, i.e. a

ComponentTypes which contains other Component Types.Description Define a Composition of VFB Software Components, i.e. a

ComponentType which contains other Component Types. Iteration ofthis task can create a complete VFB system without the AtomicSoftware Components itself.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Performed by System Engineer 0..1Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1 Use port blueprints in order to create

ports with standardized applicationinterfaces.

Consumes VFB Atomic Soft-ware Component

0..*

Consumes VFB CompositionComponent

0..*

226 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 227: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes VFB Modes 0..*Consumes VFB Non AUTOSA

R Component0..*

Consumes VFB ParameterComponent

0..*

Produces VFB CompositionComponent

1

Table 3.64: Define VFB Composition Component

3.2.1.3 Extend Composition

Extend Composition

System Engineer

VFB System

VFB Composition Component

VFB Atomic Software Component

VFB Parameter Component

VFB Interfaces

VFB Modes

VFB Software Component MappingConstraints

VFB Types

VFB Non AUTOSAR Component

«output»

0..*

«output»

0..*

1

«performs»

+initial system

1 «input»

«output»

+extended system

1

«output» 0..*

«output»

0..*

«output»

0..*

«output»

0..*

«output»

0..*

«output»

0..*

Figure 3.24: Task Extend Composition

227 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 228: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Extend CompositionPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Extend a software composistion with further compositions and atomic

software components.Description This tasks describes the refinement of a delivered VFB System by

extending an existing composition with further sub-elements, whichcould be software components (Atomic Software Components as wellas Compositions), connectors or port groups, plus the relatedinterfaces, data types and modes.

The main use case is the refinement of the VFB description of asub-system: New elements are added but the original delivery is notchanged.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes VFB System 1 initial system:Produces VFB System 1 extended system:Produces VFB Atomic Soft-

ware Component0..*

Produces VFB CompositionComponent

0..*

Produces VFB Interfaces 0..*Produces VFB Modes 0..*Produces VFB Non AUTOSA

R Component0..*

Produces VFB ParameterComponent

0..*

Produces VFB SoftwareComponent Map-ping Constraints

0..*

Produces VFB Types 0..*

Table 3.65: Extend Composition

228 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 229: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.4 Define VFB Component Constraints

Define VFB Component Constraints

Software Component Designer

VFB Software Component Mapping Constraints

VFB Composition Component

VFB Top Level System Composition

VFB Atomic Software Component

System Engineer

1 «input»

0..1

«performs»

2..*

«input»

1..*

«input»

0..1

«performs»

«output» 1..*

Figure 3.25: Task Define VFB Component Constraints

Task Definition Define VFB Component ConstraintsPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define which components need to be deployed together, and which

need to be deployed separately.Description Define which components need to be deployed together, and which

need to be deployed separately, independent of any topology.Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer0..1

Performed by System Engineer 0..1Consumes VFB Atomic Soft-

ware Component2..*

Consumes VFB Top LevelSystem Composi-tion

1

Consumes VFB CompositionComponent

1..*

Produces VFB SoftwareComponent Map-ping Constraints

1..*

Table 3.66: Define VFB Component Constraints

229 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 230: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.5 Define VFB Application Software Component

Define VFB Application Software Component

VFB AUTOSAR Standard Package

VFB Interfaces

VFB Types

VFB Modes

VFB Atomic Application Software Component

Software Component Designer

«output» 1

0..1

«input»

«performs»

1..*

«input»

0..*

«input»

1..* «input»

Figure 3.26: Task Define VFB Application Software Component

Task Definition Define VFB Application Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define an ApplicationSoftwareComponentType on VFB levelDescription Define an ApplicationSwComponentType on VFB level. (i.e. without

Internal Behavior and Implementation).Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1 Use port blueprints in order to create

ports with standardized applicationinterfaces.

Consumes VFB Modes 0..*Produces VFB Atomic Ap-

plication SoftwareComponent

1

Table 3.67: Define VFB Application Software Component

230 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 231: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.6 Define VFB Sensor or Actuator Component

Define VFB Sensor or Actuator Component

Software Component Designer

VFB AUTOSAR Standard Package

VFB Types

ECU Resources Description

VFB Sensor Actuator Component

VFB Interfaces

1..*

«input»

«performs»

1..*

«input»

0..1

«input»

0..*

«input»

«output» 1

Figure 3.27: Task Define VFB Sensor or Actuator Component

Task Definition Define VFB Sensor or Actuator ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a VFB Sensor or Actuator Comnponent.Description Define a SensorActuatorSwComponentType on VFB level. (i.e. without

Internal Behavior and Implementation). In addition to defining theports, references to the required sensor/actuator hardrware shall bespecified.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1 Use port blueprints in order to create

ports with standardized applicationinterfaces.

Consumes ECU ResourcesDescription

0..*

Produces VFB Sensor Actu-ator Component

1

Table 3.68: Define VFB Sensor or Actuator Component

231 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 232: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.7 Define VFB Parameter Component

Define VFB Parameter Component

Calibration Engineer

VFB Parameter Component

VFB Interfaces

VFB AUTOSAR Standard Package

VFB Types

«output» 1

«performs»

1..*

«input»

1..* «input»

0..1

«input»

Figure 3.28: Task Define VFB Parameter Component

Task Definition Define VFB Parameter ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a VFB Parameter Component.Description Define a VFB Parameter Component.Relation Type Related Element Mul. NotePerformed by Calibration Engi-

neer1

Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1 Use port blueprints in order to create

ports with standardized applicationinterfaces.

Produces VFB ParameterComponent

1

Table 3.69: Define VFB Parameter Component

232 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 233: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.8 Define ECU Abstraction Component

Define ECU Abstraction Component

Software Component Designer

VFB AUTOSAR Standard Package

VFB Interfaces

VFB Types

VFB Modes ECU Resources Description

ECU Abstraction Software Component

«output» 1

«input»

«input»

0..*

«input»

«performs»

0..1

«input»

«input»

Figure 3.29: Task Define ECU Abstraction Component

Task Definition Define ECU Abstraction ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define an EcuAbstractionSoftwareComponentType on VFB level.Description Define a EcuAbstractionSwComponentType on VFB level. (i.e. without

Internal Behavior and Implementation). In addition to the defining theports, references to required ECU or processor hardware elementsshall be specified.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB AUTOSARStandard Package

1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumes VFB Interfaces 1Consumes VFB Types 1Consumes ECU Resources

Description0..1

Consumes VFB Modes 0..*Produces ECU Abstraction

Software Compo-nent

1

Table 3.70: Define ECU Abstraction Component

233 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 234: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.9 Define Complex Driver Component

Define Complex Driver Component

Software Component Designer

VFB AUTOSAR Standard Package

VFB Interfaces

VFB Types

VFB Modes ECU Resources Description

Complex Driver Component

«output» 1

1..*

«input»

0..1

«input»

0..*

«input»

«performs»

0..*

«input»

1..*

«input»

Figure 3.30: Task Define Complex Driver Component

Task Definition Define Complex Driver ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a ComplexDeviceDriverSwComponentType on VFB level.Description Define a ComplexDeviceDriverSwComponentType on VFB level. (i.e.

without Internal Behavior and Implementation). In addition to thedefining the ports, references to the required ECU or processorhardware elements shall be specified.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1 Use port blueprints in order to create

ports with standardized applicationinterfaces.

Consumes ECU ResourcesDescription

0..*

Consumes VFB Modes 0..*Produces Complex Driver

Component1

Table 3.71: Define Complex Driver Component

234 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 235: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.10 Define VFB NvBlock Software Component

Define VFB NvBlock Software Component

ECU Integrator

Basic Software Designer

Software Component Designer

VFB AUTOSARStandard Package

VFB Interfaces

VFB Types

VFB Modes Software Component Internal Behavior

VFB NvBlock Software Component

0..1

«input»

1..*

«input»

0..1

«performs»

0..*

«input»

1..*

«input»

0..1

«performs»

0..1

«performs»

0..*

«input»

«output»

1

Figure 3.31: Task Define VFB NvBlock Software Component

Task Definition Define VFB NvBlock Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief DescriptionDescription Define an NvBlockSwComponentType on VFB level. The

NvBlockSwComponentType defines non volatile data which can beshared between SwComponentPrototypes. The non volatile data of theNvBlockSwComponentType are accessible via provided and requiredports.

Relation Type Related Element Mul. NotePerformed by Basic Software De-

signer0..1

Performed by ECU Integrator 0..1Performed by Software Compo-

nent Designer0..1

Consumes VFB Interfaces 1..*Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1

Consumes Software Compo-nent Internal Be-havior

0..* This input is required to collect therequirements for the NvBlockNeeds fromthe using application software.

Consumes VFB Modes 0..*

235 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 236: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces VFB NvBlock Soft-

ware Component1

Table 3.72: Define VFB NvBlock Software Component

3.2.1.11 Define Wrapper Components to Integrate Legacy Software

Define Wrapper Components to Integrate Legacy Software

Software Component Designer

VFB AUTOSAR Standard Package

VFB Modes

VFB Types

VFB Non AUTOSAR Component

VFB Interfaces

«output» 10..* «input»

0..*

«input»

«performs»

0..1

«input»0..*

«input»

Figure 3.32: Task Define Wrapper Components to Integrate Legacy Software

Task Definition Define Wrapper Components to Integrate Legacy SoftwarePackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a wrapper component used to represent legacy software that is

integrated into an AUTOSAR system.Description Define a wrapper component used to represent legacy software that is

integrated into an AUTOSAR system. For the VFB system, this mainlymeans to define the corresponding port interfaces and data elements.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB AUTOSARStandard Package

0..1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumes VFB Interfaces 0..*Consumes VFB Modes 0..*Consumes VFB Types 0..*Produces VFB Non AUTOSA

R Component1

Table 3.73: Define Wrapper Components to Integrate Legacy Software

236 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 237: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.12 Define VFB Interfaces

Define VFB Interfaces

Software Component Designer

VFB AUTOSAR Standard Package

VFB InterfacesVFB Types

0..1

«input» «performs»

1..* «input» «output» 1..*

Figure 3.33: Task Define VFB Interfaces

Task Definition Define VFB InterfacesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a set of Port Interface required by a system.Description Define a set of Port Interfaces required by a VFB system, to describe

the communication of data via SWC ports.Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB Types 1..*Consumes VFB AUTOSAR

Standard Package0..1 Use standardized Port Interfaces as

blueprints (as far as applicable) to createthe corresponding elements of the actualproject.

Produces VFB Interfaces 1..*

Table 3.74: Define VFB Interfaces

237 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 238: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.13 Define VFB Types

Software Component Designer

VFB AUTOSAR Standard Package

Define VFB Types

VFB Types

VFB Data Type Mapping Set

«output»

0..*

«output»1..*

«performs»

0..1

«input»

Figure 3.34: Task Define VFB Types

Task Definition Define VFB TypesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define a set of data types required by a system, but not already

defined by AUTOSAR.Description Define a set of Autosar Data Types and related elements as far as

visible on the VFB. Standardized types can be used as input in order tocopy and refine them.

The VFB Types will be used for specifying types of DataElements inSender-Receiver PortInterfaces and argument/return values ofClient-Server PortInterfaces.

This task inludes (optionally) also the creation of a VFB Data Typemapping Set between application and implementation data types.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB AUTOSARStandard Package

0..1 Use standardized elements (e.g. DataTypes, Compu Methods) as blueprints(as far as applicable) to create thecorresponding elements of the actualproject.

Produces VFB Types 1..*Produces VFB Data Type

Mapping Set0..*

Table 3.75: Define VFB Types

238 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 239: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.14 Define VFB Modes

Define VFB Modes

VFB Modes

Software Component Designer

«performs»

«output» 1..*

Figure 3.35: Task Define VFB Modes

Task Definition Define VFB ModesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define modes that are used by the VFB components.Description Define modes (mode groups and the modes they contain) that are

used by the VFB components.Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Produces VFB Modes 1..*

Table 3.76: Define VFB Modes

239 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 240: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.15 Define VFB Constants

Define VFB Constants

VFB Constants

VFB Data Type Mapping Set

VFB Types

Software Component Designer

Calibration Engineer

System Engineer

«output»

1..*

0..*

«input»

0..*

«input»

1

«performs»

0..1

«performs»

0..1

«performs»

Figure 3.36: Task Define VFB Constants

Task Definition Define VFB ConstantsPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define one or more VFB Constants.Description Define one or more VFB Constants as standalone artifact. Such

constants can be referred in the specification of inital values at severalplaces in the VFB descrption, such as port interfaces or declaration oflocal parameters or variables.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Performed by Calibration Engi-neer

0..1

Performed by System Engineer 0..1Consumes VFB Data Type

Mapping Set0..*

Consumes VFB Types 0..*Produces VFB Constants 1..*

Table 3.77: Define VFB Constants

240 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 241: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.16 Define VFB Timing

Define VFB Timing

Software Component Designer

VFB Interfaces

VFB AUTOSAR Standard Package

VFB Atomic Software Component

VFB Non AUTOSAR Component

VFB Composition Component VFB Timing

VFB Parameter Component

0..*

«input»

0..*

«input»

1..* «input»

«performs»

0..*

«input»

0..1

«input»1..*

«input»

«output» 1

Figure 3.37: Task Define VFB Timing

Task Definition Define VFB TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define VFB Timing (TimingDescription and TimingConstraints) for an

Atomic Software Component or a Composition ComponentDescription Define VFB Timing (TimingDescription and TimingConstraints) for an

Atomic Software Component or a Composition ComponentRelation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB CompositionComponent

1..*

Consumes VFB Interfaces 1..*Consumes VFB AUTOSAR

Standard Package0..1

Consumes VFB Atomic Soft-ware Component

0..*

Consumes VFB Non AUTOSAR Component

0..*

Consumes VFB ParameterComponent

0..*

Produces VFB Timing 1

Table 3.78: Define VFB Timing

241 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 242: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.17 Define VFB Variants

Define VFB Variants

System Constant Value Set

Predefined Variant

Evaluated Variant Set

Postbuild Variant Set

VFB Top Level System Composition VFB Composition Component

VFB Atomic Software Component

VFB Interfaces

VFB Non AUTOSAR Component

VFB Timing

Software Component Designer

VFB Parameter Component

«output»

0..*

«inoutput»

0..*

1

«input»

0..*

«input»

0..*

«input»

1..*

«input»

0..*

«input»

«performs»

0..1

«input»0..*

«input»

«inoutput»0..*

«output»

0..*

Figure 3.38: Task Define VFB Variants

Task Definition Define VFB VariantsPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define variants for the artifacts of a VFB system.Description Define one or more variants for the artifacts of a VFB system. Defining

one variant means creating a Predefined Variant related to the settingsused by the VFB elements in scope. To do so, this task can make useof existing System Constant Value Sets and/or Postbuid Variant Sets ordefine new ones.

Several Predefined Variants can be combined to one Evaluated VariantSet.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Consumes VFB Top LevelSystem Composi-tion

1

Consumes VFB CompositionComponent

1..*

Consumes VFB Timing 0..1Consumes VFB Atomic Soft-

ware Component0..*

242 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 243: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes VFB Interfaces 0..*Consumes VFB Non AUTOSA

R Component0..*

Consumes VFB ParameterComponent

0..*

In/out Postbuild VariantSet

0..*

In/out System ConstantValue Set

0..*

Produces Evaluated VariantSet

0..*

Produces Predefined Variant 0..*

Table 3.79: Define VFB Variants

3.2.1.18 Define VFB Integration Connector

Non-AUTOSAR System Integrator

Define VFB Integration Connector

VFB System

Description of a Non-AUTOSAR System

Integration Connector

«output» 1

1

«performs»

1 «input»

1 «input»

Figure 3.39: Task Define VFB Integration Connector

243 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 244: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define VFB Integration ConnectorPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Define how the non-AUTOSAR system shall be connected to the

AUTOSAR system.Description The VFB Integration Connector is used to represent the connection of

the non-AUTOSAR system and the AUTOSAR system. Its contentsand format depend on the way in which the non-AUTOSAR system isdefined.

To define the VFB Integration Connector the requirements on theconnection are brought into the format of the Integration Connector.When the requirements are defined in a proprietary format the have tobe translated to the format of the Integration Connector. When they areonly informally defined or are even more tangible the format of theIntegration Connector can be used to elicit, formalize, and analyze theconnection requirements.

Relation Type Related Element Mul. NotePerformed by Non-AUTOSAR

System Integrator1

Consumes Description of aNon-AUTOSARSystem

1

Consumes VFB System 1Produces Integration Con-

nector1

Predecessor Translate Non-Autosar Descrip-tion to AutosarDescription

1

Table 3.80: Define VFB Integration Connector

244 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 245: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.1.19 Translate Non-AUTOSAR Description to AUTOSAR Description

Translate Non-Autosar Description to Autosar Description

Non-AUTOSAR SystemIntegrator

Integration Connector

Description of a Non-AUTOSAR System

VFB System

«output»+Integrated VFB System

1

1

«performs»1 «input»

1

«input»

+Initial VFB System

1 «input»

Figure 3.40: Task Translate Non-AUTOSAR Description to AUTOSAR Descrip-tion

Task Definition Translate Non-Autosar Description to Autosar DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::TasksBrief Description Translate the description of the non-AUTOSAR system into a

semantically equivalent AUTOSAR description (template).Description In order to incorporate the development of the non-AUTOSAR system

into the AUTOSAR process the Description of the non-AUTOSARsystem must be translated into an AUTOSAR format. Typically this willbe achieved by a translation tool, although in principle it might also bedone manually.

Relation Type Related Element Mul. NotePerformed by Non-AUTOSAR

System Integrator1

Consumes Description of aNon-AUTOSARSystem

1

Consumes Integration Con-nector

1

Consumes VFB System 1 Initial VFB System:Produces VFB System 1 Integrated VFB System:

Table 3.81: Translate Non-Autosar Description to Autosar Description

245 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 246: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2 Work Products

3.2.2.1 VFB System

VFB System

Overall VFB System

VFB System Extract

ECU Extract of VFB System

VFB Top Level System Composition

VFB Composition Component

See separate diagram for further aggregations.

System View Mapping

«extends» «extends» «extends»

1

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation» 0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.41: Overview on the different roles of Deliverables based on VFB System

246 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 247: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

VFB System

System Constant Value Set

Predefined Variant

Evaluated Variant Set

Postbuild Variant Set

VFB Top Level System Composition

VFB Interfaces VFB Data Type Mapping SetVFB Modes VFB Types

VFB Atomic Application Software Component

Complex Driver Component

VFB SensorActuator Component

ECU Abstraction Software Component

VFB Parameter Component

VFB Non AUTOSAR Component

VFB Software Component Mapping Constraints

Consistency Needs

VFB NvBlock Software Component

1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*«SPEM_Aggregation»

0..*«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*«SPEM_Aggregation»

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.42: Structure of Deliverable VFB System

Deliverable VFB SystemPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Complete VFB view of a concrete system.Description Delivery of a VFB view of a concrete system. i.e. the top level

composition and all nested compositions and components. Thiselement is the basis for several extensions according to the scope ofthe VFB which can be an Overall System, a System Extract or an ECUExtract.

This deliverable may contain variation points in its XML artifacts whichneed to be bound in later steps of the methodology. If such variationpoints are present, the delivered VFB system may optionally includePredefinedVariants in order to predefine variants for later selection andan Evaluated Variant Set.

Kind DeliveredExtended by ECU Extract of VFB System, Overall VFB System, VFB System ExtractRelation Type Related Element Mul. Note

247 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 248: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Consistency

Needs1 Correlation between a group of

RunnableEntitys and a group ofDataPrototypes.

Aggregates VFB Top LevelSystem Composi-tion

1

Aggregates Complex DriverComponent

0..*

Aggregates ECU AbstractionSoftware Compo-nent

0..*

Aggregates Evaluated VariantSet

0..*

Aggregates Postbuild VariantSet

0..*

Aggregates Predefined Variant 0..*Aggregates System Constant

Value Set0..*

Aggregates VFB Atomic Ap-plication SoftwareComponent

0..*

Aggregates VFB Data TypeMapping Set

0..*

Aggregates VFB Interfaces 0..*Aggregates VFB Modes 0..*Aggregates VFB Non AUTOSA

R Component0..*

Aggregates VFB NvBlock Soft-ware Component

0..*

Aggregates VFB ParameterComponent

0..*

Aggregates VFB Sensor Actu-ator Component

0..*

Aggregates VFB SoftwareComponent Map-ping Constraints

0..*

Aggregates VFB Types 0..*Produced by Extend Composi-

tion1 extended system:

Produced by Translate Non-Autosar Descrip-tion to AutosarDescription

1 Integrated VFB System:

248 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 249: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Define Partial Flat

Map1 Various parts of a given VFB system will

be used as input:

• Refer to parameters and variablesin port interfaces and their datatypes.

• In order to define unique names,also other the componentdefinitions not in the scope of thepartial flat map might be checked.

• Set a link to the context of the FlatMap, e.g. a VFB Composition.

Consumed by Define VFB Inte-gration Connector

1

Consumed by Define VFB SafetyInformation

1

Consumed by Extend Composi-tion

1 initial system:

Consumed by Extract the ECUCommunication

1 Need as input in order to set up the DataMapping.

Consumed by Generate or AdjustSystem Flat Map

1

Consumed by Translate Non-Autosar Descrip-tion to AutosarDescription

1 Initial VFB System:

Table 3.82: VFB System

3.2.2.2 Overall VFB System

Deliverable Overall VFB SystemPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief DescriptionDescription Deliverable containing an overall VFB description. It must contain the

VFB Top Level System Composition of the complete system.Kind DeliveredExtends VFB SystemRelation Type Related Element Mul. NoteAggregated by Abstract System

Description1

Aggregated by System Configura-tion Description

1

Aggregated by System ConstraintDescription

0..1

249 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 250: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates System View Map-

ping0..1 The Overall VFB System aggregates a

potential mapping to the abstract orfunctional view of the system.

Aggregates VFB CompositionComponent

0..* Further compositions below the top levelcomposition.

Produced by Develop a VFBSystem Descrip-tion

1

Consumed by Define SoftwareComponent SafetyInformation

1

Consumed by Develop Applica-tion Software

1 The application software needs to referto the relevant elements of the overallVFB system such as SoftwareComponent Types, Port Interfaces andData Types.

Consumed by Develop System 0..1 Usually the System refers to elements ofan overall VFB descriptions. But for thedescription of a legacy system, this inputmight be empty.

Consumed by Flatten SoftwareComposition

0..1 Read relevant elements starting fromVFB Top Level System Composition incase transformation starts with the fullsystem.

Consumed by Generate or AdjustECU Flat Map

0..1 Used to set the upstream references incase one starts from a complete system.

Table 3.83: Overall VFB System

3.2.2.3 VFB System Extract

Deliverable VFB System ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description The VFB description for the partial system.Description The VFB description for a sub-system. It contains only those software

components which belong to this sub-system. It should contain a VFBTop Level System Composition which has unconnected ports reflectingthe connection points to the outer system.

Kind DeliveredExtends VFB SystemRelation Type Related Element Mul. NoteAggregated by System Extract 1Aggregates System View Map-

ping0..1 The VFB System Extract aggregates a

potential mapping to the abstract orfunctional view of the system.

Aggregates VFB CompositionComponent

0..* Further compositions below the top levelcomposition.

250 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 251: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Flatten Software

Composition0..1 Read relevant elements starting from

VFB Top Level System Composition incase transformation starts from thesystem extract.

Consumed by Generate or AdjustECU Flat Map

0..1 Used to set the upstream references incase one starts from a system extract.

Table 3.84: VFB System Extract

3.2.2.4 VFB Top Level System Composition

Artifact VFB Top Level System CompositionPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Highest Level Composition consisting of all components that make up

the Virtual Functional Bus.Description Highest Level Composition consisting of all components and their

connectors that make up the VFB System Deliverable.

This composition is not allowed to have ports if it represents the toplevel composition of an Overall VFB System, but it may haveunconnected ports (and port groups) if it is at the top of a SystemExtract or ECU Extract.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by VFB System 1Produced by Define VFB Top

Level1

Consumed by Assign Top LevelComposition

1

Consumed by Define SoftwareComponent Map-ping Constraints

1

Consumed by Define VFB Com-ponent Constraints

1

Consumed by Define VFB Vari-ants

1

Consumed by Deploy SoftwareComponent

1

Use meta model element CompositionSwComponentType

1

Table 3.85: VFB Top Level System Composition

3.2.2.5 VFB Composition Component

251 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 252: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact VFB Composition ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Describes a set of VFB CompositionTypes.Description Describes a set of CompositionComponentTypes, which may be

nested. A VFB composition aggregates component types toencapsulate and abstract subsystem functionality. Compositionscontain instances of components (other compositions and atomiccomponents), as well as the connectors between them.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..* In case the delivered atomic componentsmake up one or more VFB Compositions,the composition description(s) shall beincluded in the delivery.

Aggregated by Overall VFB Sys-tem

0..* Further compositions below the top levelcomposition.

Aggregated by VFB System Ex-tract

0..* Further compositions below the top levelcomposition.

Produced by Define VFB Com-position Compo-nent

1

Produced by Extend Composi-tion

0..*

Consumed by Set System Root 1 Only the reference to the artifact isneeded

Consumed by Define VFB Com-ponent Constraints

1..*

Consumed by Define VFB Timing 1..*Consumed by Define VFB Vari-

ants1..*

Consumed by Define VFB Com-position Compo-nent

0..*

Consumed by Define VFB TopLevel

0..*

Use meta model element CompositionSwComponentType

1

Use meta model element SwComponentType

1

Table 3.86: VFB Composition Component

252 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 253: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2.6 VFB AUTOSAR Standard Package

VFB AUTOSAR Standard Package

AUTOSAR Specification of Application Interfaces

AUTOSAR Standard Types

AUTOSAR Platform Types

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

Figure 3.43: Structure of Deliverable VFB AUTOSAR Standard Package

Deliverable VFB AUTOSAR Standard PackagePackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Package with standardized AUTOSAR DataTypes, PortInterfaces,

ComponentTypes (may include compositions), etc. on VFB level.Description Package with standardized AUTOSAR elements needed on VFB level.

This deliverable is released by AUTOSAR and is readonly within themethodology.

Kind DeliveredRelation Type Related Element Mul. NoteAggregates AUTOSAR Plat-

form Types1

Aggregates AUTOSAR Specifi-cation of Applica-tion Interfaces

1

Aggregates AUTOSAR Stan-dard Types

1

Consumed by Define ECUAbstraction Com-ponent

1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumed by Develop a VFBSystem Descrip-tion

1..*

Consumed by Develop an Ab-stract SystemDescription

1..*

Consumed by Define AtomicSoftware Com-ponent InternalBehavior

0..1 Use standardized elements (e.g. DataTypes) as blueprints (as far asapplicable) to create the correspondingelements of the actual project.

253 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 254: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Define Complex

Driver Component0..1 Use port blueprints in order to create

ports with standardized applicationinterfaces.

Consumed by Define VFB Ap-plication SoftwareComponent

0..1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumed by Define VFB Com-position Compo-nent

0..1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumed by Define VFB Inter-faces

0..1 Use standardized Port Interfaces asblueprints (as far as applicable) to createthe corresponding elements of the actualproject.

Consumed by Define VFB NvBlock SoftwareComponent

0..1

Consumed by Define VFB Pa-rameter Compo-nent

0..1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumed by Define VFB Sen-sor or ActuatorComponent

0..1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumed by Define VFB Timing 0..1Consumed by Define VFB Types 0..1 Use standardized elements (e.g. Data

Types, Compu Methods) as blueprints(as far as applicable) to create thecorresponding elements of the actualproject.

Consumed by Define WrapperComponents toIntegrate LegacySoftware

0..1 Use port blueprints in order to createports with standardized applicationinterfaces.

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..1

Consumed by Generate Compo-nent Header File inVendor Mode

0..1

Consumed by Generate Compo-nent Prebuild DataSet

0..1

Table 3.87: VFB AUTOSAR Standard Package

254 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 255: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2.7 AUTOSAR Specification of Application Interfaces

AUTOSAR Specification of Application Interfaces

ARElementAtpType

Datatypes::AutosarDataType

ARElementAtpBlueprint

AtpBlueprintableAtpType

PortInterface::PortInterface

ARElementAtpBlueprint

AtpBlueprintableAtpType

Components::SwComponentType

ARElement

Units::Unit

ARElementAtpBlueprint

AtpStructureElement

PortProtoypeBlueprint::PortPrototypeBlueprint

ARElementAtpBlueprint

AtpBlueprintable

GlobalConstraints::DataConstr

ARElementAtpBlueprint

AtpBlueprintable

ComputationMethod::CompuMethod

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

Figure 3.44: The AUTOSAR Specification of Application Interfaces

Artifact AUTOSAR Specification of Application InterfacesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Definitions of the AUTOSAR standard appliction interfaces.Description This includes standardized data types, port interfaces, units, port

blueprints and example component types (including compositions) forthe design of Application Software Components.

Note that most of the content is not meant as direct input for defining aVFB system but as so-called blueprints:

Blueprints need to be completed with company or project specificelements (e.g. a component type defined as blueprint may needadditional ports or a data type defined as blueprint may need additionalproperties).

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by VFB AUTOSAR

Standard Package1

Use meta model element AutosarDataType 1Use meta model element CompuMethod 1

255 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 256: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteUse meta model element DataConstr 1Use meta model element PortInterface 1Use meta model element PortPrototype

Blueprint1

Use meta model element SwComponentType

1

Use meta model element Unit 1

Table 3.88: AUTOSAR Specification of Application Interfaces

3.2.2.8 VFB Atomic Software Component

VFB Atomic Software Component

VFB Atomic Application Software Component

Complex Driver Component

ECU Abstraction Software Component

VFB Sensor Actuator Component

Components::AtomicSwComponentType

ARElementAtpBlueprint

AtpBlueprintableAtpType

Components::SwComponentType

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«extends»

«extends»

«extends» «extends»

Figure 3.45: The Generic Work Product VFB Atomic Software Component

Artifact VFB Atomic Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Description of an Atomic VFB Component.Description The description of an Atomic Software Component Type without

Internal Behavior. Note that there are more specific artifacts extendingthis one. This artifact is used to describe general use cases which arevalid for all kind of Atomic Software Components.

Kind AUTOSAR XMLExtended by Complex Driver Component, ECU Abstraction Software Component, V

FB Atomic Application Software Component, VFB Sensor ActuatorComponent

Relation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

1..*

256 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 257: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Define Symbol

Props for Types0..* symbolProps: The symbolProps attribute

redefines the software component typename used in the code of the RTE. Thisresolves name clashes among differentsoftware component types designedaccidentally with the same shortName.

Note that this output is a splitableelement, so it can be added later withoutchanging the VFB model.

Produced by Extend Composi-tion

0..*

Consumed by Define VFB Com-ponent Constraints

2..*

Consumed by Define AtomicSoftware Com-ponent InternalBehavior

1

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

1 Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Header File inVendor Mode

1 Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Prebuild DataSet

1 Meth.bindingTime =CodeGenerationTime

Consumed by Select SoftwareComponent Imple-mentation

1..*

Consumed by Define Consis-tency Needs

0..* The description of anAtomicSoftwareComponentType withoutInternalBehavior.

Consumed by Define VFB Com-position Compo-nent

0..*

Consumed by Define VFB Timing 0..*Consumed by Define VFB Top

Level0..*

Consumed by Define VFB Vari-ants

0..*

Use meta model element AtomicSwCompo-nentType

1

Use meta model element SwComponentType

1

Table 3.89: VFB Atomic Software Component

257 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 258: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2.9 VFB Atomic Application Software Component

Artifact VFB Atomic Application Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Description of an Atomic VFB Component.Description The description of an Application Software Component Type.

It is used to represent the ECU-independent application software.Kind AUTOSAR XMLExtends VFB Atomic Software ComponentRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define VFB Ap-

plication SoftwareComponent

1

Use meta model element ApplicationSwComponentType

1

Table 3.90: VFB Atomic Application Software Component

3.2.2.10 Complex Driver Component

Artifact Complex Driver ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description VFB Description of a Complex Driver Component.Description The Complex Driver Component is a special VFB Atomic Software

Component that has direct access to hardware on an ECU and whichis therefore linked to a specific ECU or specific hardware.

It uses the meta-model elementComplexDeviceDriverSwComponentType which introduces thepossibility to link from the software representation to its hardwaredescription provided by the ECU Resource Template.

It provides (non-standardized) AUTOSAR Interfaces via ports on VFBlevel.

Kind AUTOSAR XMLExtends VFB Atomic Software ComponentRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define Complex

Driver Component1

Consumed by Configure Debug 0..1Consumed by Map Software

Component to BSW

0..1

258 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 259: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteUse meta model element ComplexDevice

DriverSwCompo-nentType

1

Table 3.91: Complex Driver Component

3.2.2.11 ECU Abstraction Software Component

Artifact ECU Abstraction Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description VFB Description of an ECU Abstraction Software Component.Description The ECU Abstraction Software Component is a special Atomic

Software Component that sits between a component that wants toaccess ECU periphery (typically a Sensor Actuator Component) andthe Microcontroller Abstraction.

It provides (non-standardized) AUTOSAR Interfaces via ports whichrepresent the ECU periphery. The EcuAbstractionSwComponentTypeintroduces the possibility to link from the software representation to itshardware description provided by the ECU Resource Template.

During integration, an ECU Abstraction Software Component will bemapped to a BSW module which implements it and which will directly(without RTE) be connected to the Microcontroller Abstraction.

Kind AUTOSAR XMLExtends VFB Atomic Software ComponentRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define ECU

Abstraction Com-ponent

1

Consumed by Map SoftwareComponent to BSW

0..1

Use meta model element EcuAbstractionSwComponentType

1

Table 3.92: ECU Abstraction Software Component

3.2.2.12 VFB Parameter Component

259 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 260: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact VFB Parameter ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description A ParameterComponentType defines parameters and characteristic

values accessible via provided Ports.Description A ParameterSwComponentType defines parameters and characteristic

values accessible via Provide Ports. The provided values are the samefor all connected Component Prototypes. This is as opposed to privateparameters which are only available within the scope of an AtomicSoftware Component

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define VFB Pa-

rameter Compo-nent

1

Produced by Extend Composi-tion

0..*

Consumed by Define VFB Com-position Compo-nent

0..*

Consumed by Define VFB Timing 0..*Consumed by Define VFB Top

Level0..*

Consumed by Define VFB Vari-ants

0..*

Use meta model element ParameterSwComponentType

1

Table 3.93: VFB Parameter Component

3.2.2.13 VFB Sensor Actuator Component

260 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 261: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact VFB Sensor Actuator ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Describes a sensor or actuator component that exist at the VFB Level

and represents the physical interface of an actual sensor or actuatorhardware element.

Description A Sensor Actuator Software Component is an Atomic SoftwareComponent that makes the functionality of a sensor or actuator usablefor other software components. That means that the Sensor ActuatorSoftware Component provides to the application software componentsan interface for the physical values of the sensors and actuators. It iswritten for a concrete sensor or actuator and uses the ECU Abstractioninterface.

It references the description of the associated hardware elements.Kind AUTOSAR XMLExtends VFB Atomic Software ComponentRelation Type Related Element Mul. NoteAggregated by Complete ECU

Description0..*

Aggregated by VFB System 0..*Produced by Define VFB Sen-

sor or ActuatorComponent

1

Use meta model element SensorActuatorSwComponentType

1

Table 3.94: VFB Sensor Actuator Component

3.2.2.14 VFB NvBlock Software Component

Artifact VFB NvBlock Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief DescriptionDescription The VFB NvBlock Software Component defines non volatile data which

can be shared between SwComponentPrototypes. The non volatiledata of the VFB NvBlock Software Component are accessible viaprovided and required ports.

KindRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define VFB Nv

Block SoftwareComponent

1

Use meta model element NvBlockSwCom-ponentType

1

Table 3.95: VFB NvBlock Software Component

261 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 262: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2.15 VFB Non AUTOSAR Component

Artifact VFB Non AUTOSAR ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description A Component used to describe the non-autosar entities that exist at the

VFB level.Description A Component used to describe the non-AUTOSAR entities that exist at

the VFB level.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define Wrapper

Components toIntegrate LegacySoftware

1

Produced by Extend Composi-tion

0..*

Consumed by Define VFB Com-position Compo-nent

0..*

Consumed by Define VFB Timing 0..*Consumed by Define VFB Top

Level0..*

Consumed by Define VFB Vari-ants

0..*

Use meta model element SwComponentType

1

Table 3.96: VFB Non AUTOSAR Component

3.2.2.16 VFB Interfaces

Artifact VFB InterfacesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Interfaces and related elements that form part of the VFB, but are not

standardized by AUTOSAR.Description Interfaces and related elements that form part of the VFB, but are not

standardized by AUTOSAR.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Aggregated by VFB System 0..*Produced by Define VFB Inter-

faces1..*

262 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 263: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Extend Composi-

tion0..*

Consumed by Define ECUAbstraction Com-ponent

1

Consumed by Define ComplexDriver Component

1..*

Consumed by Define VFB Ap-plication SoftwareComponent

1..*

Consumed by Define VFB Com-position Compo-nent

1..*

Consumed by Define VFB NvBlock SoftwareComponent

1..*

Consumed by Define VFB Pa-rameter Compo-nent

1..*

Consumed by Define VFB Sen-sor or ActuatorComponent

1..*

Consumed by Define VFB Timing 1..*Consumed by Define VFB Top

Level1..*

Consumed by Define Consis-tency Needs

0..* Interfaces which are relevant for theconsistency definition.

Consumed by Define VFB Vari-ants

0..*

Consumed by Define WrapperComponents toIntegrate LegacySoftware

0..*

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..* Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Header File inVendor Mode

0..* Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Prebuild DataSet

0..* Meth.bindingTime =CodeGenerationTime

Use meta model element AutosarDataType 1Use meta model element ModeDeclaration

Group1

Use meta model element PortInterface 1

Table 3.97: VFB Interfaces

263 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 264: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2.17 VFB Types

Artifact VFB TypesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Data types and related elements that form part of the VFB, but are not

standardized by AUTOSAR.Description Description of AutosarDataTypes and related elements (e.g. units,

computation methods, etc.) that form part of the VFB, but are notstandardized by AUTOSAR. This may also include copies ofstandardized elements which have been completed with projectspecific information (e.g. with calibration access information orcomputation methods). A VFB system can contain several differentinstances of this artifact, which may fulfill different roles.

AutosarDataTypes can come as so-called ApplicationDatatypes orImplementationDataTypes. This package can contain both kinds butthey can also be split into separate artifacts. However, since it is alsopossible to generate ImplementationDataTypes fromApplicationDataTypes, a VFB system can be completely defined withApplicationDatatypes only.

Note that this work product is meant for use cases, in which a set ofdata types is maintained as a separate artifact. It is also possible todefine particular AutosarDataTypes as part of another artifact, e.g. ofVFB Interfaces if the types are closely related to certain port interfaces.

In the methodology this artifact stands not only for data type definitions,but also for related elements like addressing methods, units,computation methods, constraints. etc. This is done for simplicity,because these elements are often consumed by the same tasks. Ofcourse these can be treated as separate artifacts in real projects.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Aggregated by VFB System 0..*Produced by Define VFB Types 1..*Produced by Define Symbol

Props for Types0..* symbolProps: The symbolProps attribute

redefines the implementation data typename used in the code of the RTE and/orthe component. This resolves nameclashes among different implementationdata types designed accidentally with thesame shortName.

Note that this output is a splitableelement, so it can be added later withoutchanging the VFB model.

Produced by Extend Composi-tion

0..*

264 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 265: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Define ECU

Abstraction Com-ponent

1

Consumed by Define ComplexDriver Component

1..*

Consumed by Define VFB Ap-plication SoftwareComponent

1..*

Consumed by Define VFB Com-position Compo-nent

1..*

Consumed by Define VFB Inter-faces

1..*

Consumed by Define VFB NvBlock SoftwareComponent

1..*

Consumed by Define VFB Pa-rameter Compo-nent

1..*

Consumed by Define VFB Sen-sor or ActuatorComponent

1..*

Consumed by Define VFB TopLevel

1..*

Consumed by Generate BSWMemory MappingHeader

1..* SwAddrMethod: ReferredSwAddrMethodsMeth.bindingTime = SystemDesignTime

Consumed by Generate CompilerConfiguration

1..* SwAddrMethod: ReferredSwAddrMethods. They provide thedefault names for the compiler memoryclasses.Meth.bindingTime = SystemDesignTime

Consumed by Generate SWCMemory MappingHeader

1..* SwAddrMethod: ReferredSwAddrMethodsMeth.bindingTime = SystemDesignTime

Consumed by ConfigureMemmap Allo-cation

0..* SwAddrMethods: SwAddrMethods usedfor the generic mapping. Note that oneSwAddrmethod can represent severalmemory sections.

Consumed by Define Consis-tency Needs

0..* Data types which are relevant for theconsistency definition.

Consumed by Define VFB Con-stants

0..*

Consumed by Define WrapperComponents toIntegrate LegacySoftware

0..*

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..* Meth.bindingTime = SystemDesignTime

265 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 266: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Generate Compo-

nent Header File inVendor Mode

0..* Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Prebuild DataSet

0..* Meth.bindingTime =CodeGenerationTime

Use meta model element ApplicationDataType

1

Use meta model element AutosarDataType 1Use meta model element CompuMethod 1Use meta model element DataConstr 1Use meta model element Implementation

DataType1

Use meta model element SwAddrMethod 1Use meta model element Unit 1

Table 3.98: VFB Types

3.2.2.18 VFB Data Type Mapping Set

Artifact VFB Data Type Mapping SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Mapping Set between Application and Implementation Data Types.Description Mapping Set between Application and Implementation Data Types.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Aggregated by VFB System 0..*Produced by Define VFB Types 0..*Consumed by Generate Atomic

Software Com-ponent ContractHeader Files

0..1 Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Header File inVendor Mode

0..1 Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Prebuild DataSet

0..1 Meth.bindingTime =CodeGenerationTime

Consumed by Define VFB Con-stants

0..*

Use meta model element DataTypeMappingSet

1

Table 3.99: VFB Data Type Mapping Set

266 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 267: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.2.2.19 VFB Modes

Artifact VFB ModesPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Modes declared here are non-AUTOSAR standard. They are modes

that are managed by a software component acting as a applicationmode manager.

Description Desclaration of mode groups and of the modes they contain. Modesdeclared here are non-AUTOSAR standard. They are modes that aremanaged by an application software component acting as a modemanager.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Aggregated by VFB System 0..*Produced by Define VFB Modes 1..*Produced by Extend Composi-

tion0..*

Consumed by Define ComplexDriver Component

0..*

Consumed by Define ECUAbstraction Com-ponent

0..*

Consumed by Define VFB Ap-plication SoftwareComponent

0..*

Consumed by Define VFB Com-position Compo-nent

0..*

Consumed by Define VFB NvBlock SoftwareComponent

0..*

Consumed by Define VFB TopLevel

0..*

Consumed by Define WrapperComponents toIntegrate LegacySoftware

0..*

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..* Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Header File inVendor Mode

0..* Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Prebuild DataSet

0..* Meth.bindingTime =CodeGenerationTime

267 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 268: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteUse meta model element ModeDeclaration

Group1

Table 3.100: VFB Modes

3.2.2.20 VFB Constants

Artifact VFB ConstantsPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Specification of constant data for usage as initial values by other

artifacts.Description Specification of constant data for usage as initial values by other

artifacts, e.g. initial values for calibration parameters or variable dataelements provided in ports.

By using the ConstantSpecification meta-class, such data can bestandalone artifacts and thus be maintained independently of thecomponents or interfaces to which they apply.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteProduced by Define VFB Con-

stants1..*

Use meta model element ConstantSpecifica-tion

1

Table 3.101: VFB Constants

3.2.2.21 VFB Software Component Mapping Constraints

Artifact VFB Software Component Mapping ConstraintsPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description A defined constraint on how certain components must be mapped

(clustered or separated) to ECUs.Description One or more defined constraints on how certain components must be

mapped (clustered, separated or dedicated mapping).

This defines constraints to which components need to be mapped to asingle ECU, and which must be mapped to separate ECUs, withoutregard to any particular ECU or topology.

Notes: The meta-model element SystemMapping allows to describe acollection of such constraints as one single artifact.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by VFB System 0..*Produced by Define VFB Com-

ponent Constraints1..*

268 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 269: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Extend Composi-

tion0..*

Consumed by Deploy SoftwareComponent

0..1 Constraints defined on the VFB level

Use meta model element MappingConstraint 1Use meta model element SystemMapping 1 The splitable element SystemMapping is

the root for this artifact.

Table 3.102: VFB Software Component Mapping Constraints

3.2.2.22 VFB Timing

Artifact VFB TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Atomic Software Component or Composition Component

TimingDescription and TimingConstraintsDescription TimingDescription and TimingConstraints defined for an Atomic

Software Component or a Composition ComponentKind AUTOSAR XMLRelation Type Related Element Mul. NoteProduced by Define VFB Timing 1Consumed by Define Software

Component Timing0..1

Consumed by Define SystemTiming

0..1

Consumed by Define VFB Vari-ants

0..1

Use meta model element VfbTiming 1

Table 3.103: VFB Timing

3.2.2.23 Description of a Non-AUTOSAR System

269 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 270: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Description of a Non-AUTOSAR SystemPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description View of the non-AUTOSAR system that contains the relevant

information for its integration with the AUTOSAR system at VFB levelDescription This artifact describes the elements of the non-AUTOSAR system that

are relevant for its integration with an AUTOSAR system at the VFBlevel. The format of the description depends on the methodology orplatform that is employed for the development of the non-AUTOSARsystem. It may not be assumed that the description of thenon-AUTOSAR system comes in an AUTOSAR format. Also thecontents of the description may differ both in its scope and in its detailsfrom an AUTOSAR description that also addresses the VFB level, i.e. aSwComponent Description.

The interfaces of infotainment system components developed on thebasis of the GENIVI platform for instance are specified with the FrancaInterface Definition Language. A Franca IDL description containsinterfaces that define data types, methods, attributes, and broadcasts.It does neither define the components that implement these interfacesnor their connections. In addition, the granularity of the data typedescription is much coarser than a data type description with theSwComponent Template.

Kind CustomRelation Type Related Element Mul. NoteConsumed by Define VFB Inte-

gration Connector1

Consumed by Translate Non-Autosar Descrip-tion to AutosarDescription

1

Table 3.104: Description of a Non-AUTOSAR System

3.2.2.24 Integration Connector

270 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 271: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Integration ConnectorPackage AUTOSAR Root::M2::Methodology::Methodology Library::VFB::Work

ProductsBrief Description Specification of the connections of the elements of the non-AUTOSAR

system with the elements of the AUTOSAR systemDescription This artifact specifies which elements of the non-AUTOSAR system are

to be connected with which elements of the AUTOSAR system. If forinstance the Description of the non-AUTOSAR system containselements corresponding to port instances, the integration connectorwould define how these ports are connected with the port instancescontained in the AUTOSAR SwComponent Description. In addition, theIntegration Connector may specify information that is necessary for theintegration but not yet contained in the Description of thenon-AUTOSAR system.

If for instance the Description of the non-AUTOSAR system containsonly very coarse grained data type descriptions the IntegrationConnector will be used to add sufficient information such that thecompatibility of the data types with the ones defined in the AUTOSARSwComponent Description can be checked.

Kind CustomRelation Type Related Element Mul. NoteProduced by Define VFB Inte-

gration Connector1

Consumed by Translate Non-Autosar Descrip-tion to AutosarDescription

1

Table 3.105: Integration Connector

3.3 System

This chapter contains the definition of work products and tasks used for the devel-opment of systems and sub-systems. For the definition of the relevant meta-modelelements refer to [9] and [20].

271 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 272: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1 Tasks

3.3.1.1 Set System Root

Set System Root

System Description Root Element

Topology

Mapping of Software Components to ECUs

Signal Path Constraints

Software Component Mapping Constraints

Communication Layers

System Engineer

VFB Composition Component

Data Mapping

«output» 1

1

«input»

1

«input»

1

«input»

1

«input»

1..*

«input»

1 «input»

1

«input»

1

«performs»

Figure 3.46: Set System Root

Task Definition Set System RootPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief DescriptionDescription Set up the root element of a system description.Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Communication

Layers1 Only the reference to the artifact is

neededConsumes Mapping of Soft-

ware Componentsto ECUs

1 Only the reference to the artifact isneeded

Consumes Signal Path Con-straints

1 Only the reference to the artifact isneeded

Consumes Software Compo-nent Mapping Con-straints

1 Only the reference to the artifact isneeded

Consumes Topology 1 Only the reference to the artifact isneeded

Consumes VFB CompositionComponent

1 Only the reference to the artifact isneeded

272 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 273: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Data Mapping 1..* Only the reference to the artifact is

neededProduces System Descrip-

tion Root Element1 Set up the root element, and the links to

other artifacts

Table 3.106: Set System Root

3.3.1.2 Assign Top Level Composition

Assign Top Level Composition

System Description Root Element

VFB Top Level System Composition

System Engineer

«output»11

«input»

«performs»

Figure 3.47: Assign Top Level Composition

Task Definition Assign Top Level CompositionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief DescriptionDescription Assign a VFB Top Level Composition to the System RootRelation Type Related Element Mul. NotePerformed by System Engineer 1Consumes VFB Top Level

System Composi-tion

1

Produces System Descrip-tion Root Element

1

Table 3.107: Assign Top Level Composition

273 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 274: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.3 Define ECU Description

ECU Resources Description

Define ECU Description

System Engineer

«performs»

«output»1..*

Figure 3.48: Define ECU description

Task Definition Define ECU DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Define a particular ECU’s resources.Description Define a particular ECU’s resources by describing Hardware Elements,

pins, connections.The HW Elements are the main describing elementsof an ECU,e;g processing units, memory, peripherals, sensors andactuators. HW Elements have a unique name and can be identifiedwithin the ECU description. HW Elements do not necessarily have tobe described on the level of an ECU. It is possible to describe HWElements as parts of other HW Elements. By this means, a hierarchicaldescription of HW Elements can be created. HW Elements provide HWPinGroups and HW Pins for being interconnected among each others.HW PinGroups allow a rough description of how certain groups ofHWPins are arranged. The detailed description can be done using theHW Pins.HW Connections are used to describe connection on severallevels:connections between HW Elements, connections between HWPinGroups, connections between HW Pins.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Produces ECU Resources

Description1..*

Table 3.108: Define ECU Description

274 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 275: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.4 Define System Topology

System Engineer

ECU Resources Description

TopologyDefine System Topology

1

«performs»

1..* «input»

«output»

1

Figure 3.49: Define System Topology

Task Definition Define System TopologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Select the ECUs and how the they are interconnected by networks.Description Define how the ECUs of a system are interconnected by networks.Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes ECU Resources

Description1..*

Produces Topology 1

Table 3.109: Define System Topology

3.3.1.5 Define Software Component Mapping Constraints

VFB Top Level System Composition

Topology

Software Component Mapping Constraints

Define Software Component Mapping Constraints

System Engineer

«performs»

1 «input»

1 «input»

«output»

1

Figure 3.50: Define Software Component Mapping Constraints

275 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 276: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define Software Component Mapping ConstraintsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Define Constraints on software components that are clusterred

together or separate, and how software components need to beassigned to a particular ECU or not.

Description Define constraints on Software Components during the mappingphase. These constraints are described into the System Constraintdescription. Two constraints express the restrictions that SoftwareComponents impose each other when performing the mapping ontothe ECUs.

In fact, before the mapping process begins, it can be useful to imposethe allocation of a predefined set of SW components onto the sameECU, especially if such a set is tightly linked from a functional point ofview. In the same way, two critical SW components, performing somekind of redundancy, may be not suitable to run both on the same ECU.Thus, we call these two kinds of mapping constraints, respectively,ComponentClustering and ComponentSeparation.

The ComponentClustering constraint (also, clustering) is to be used forexpressing that a certain set of SW components (atomic or not) mustbe mapped (allocated) onto the same ECU. This is some kind of"execute together on same ECU" constraint.

The ComponentSeparation constraint (also, separation) is to be usedfor expressing that two SW components (atomic or not) shall not bemapped (allocated) onto the same ECU. This is some kind of do notexecute together on same ECU constraint.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Topology 1Consumes VFB Top Level

System Composi-tion

1

Produces Software Compo-nent Mapping Con-straints

1

Table 3.110: Define Software Component Mapping Constraints

276 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 277: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.6 Deploy Software Component

System Engineer

Topology

VFB Top Level System Composition

VFB Software ComponentMapping Constraints

System Timing

Mapping of Software Components to ECUs

Deploy Software Component

Software Component Mapping Constraints

«output»

1

1

«input»

0..1

«input»

1 «input»

0..1

«input»

1

«performs»

0..1

«input»

Figure 3.51: Deploy Software Component

Task Definition Deploy Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Deploy VFB Software Components to an ECUDescription Deploy each VFB Software Component to an ECU that will execute the

component.Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Topology 1Consumes VFB Top Level

System Composi-tion

1

Consumes Software Compo-nent Mapping Con-straints

0..1 Constraints defined on the System level

Consumes System Timing 0..1Consumes VFB Software

Component Map-ping Constraints

0..1 Constraints defined on the VFB level

Produces Mapping of Soft-ware Componentsto ECUs

1

Table 3.111: Deploy Software Component

277 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 278: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.7 Generate or Adjust System Flat Map

System Flat Map

System Description Root Element

VFB System

Generate or Adjust System Flat Map

System Engineer

Partial Flat Map

«performs»

0..* «input»

1

«input»

1

«input»

«inoutput»

1

Figure 3.52: Generate or Adjust System Flat Map

Task Definition Generate or Adjust System Flat MapPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Generates and/or adjust the unique names of component prototypes

and MCD display data in the scope of system.Description Generates and/or adjust the unique names of component prototypes

and MCD display data in the scope of a System or System Extract.Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes System Descrip-

tion Root Element1

Consumes VFB System 1Consumes Partial Flat Map 0..* If Partial Flat Maps were delivered along

with software components, they must beintegrated into the System Flat Map:

• The instance refs used in a partialflat map must be taken over andadjusted to the context of theSystem or System Extract.

• Name conflicts have to beresolved if several partial flatmaps are merged.

In/out System Flat Map 1

Table 3.112: Generate or Adjust System Flat Map

278 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 279: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.8 Derive Communication Needs

System Engineer

Mapping of Software Components to ECUs

System Signal

Derive CommunicationNeeds

Data Mapping

System Signal Group

«output» 0..*

1 «input»

1

«performs»

«output»

1..*

«output»

1..*

Figure 3.53: Derive Communication Needs

Task Definition Derive Communication NeedsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Define the signals used to exchange data & operations needed by

software components over a network.Description Define the signals used to exchange data & operations needed by

software components over a network.Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Mapping of Soft-

ware Componentsto ECUs

1

Produces Data Mapping 1..*Produces System Signal 1..*Produces System Signal

Group0..*

Table 3.113: Derive Communication Needs

279 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 280: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.9 Define Signal Path Constraints

System Engineer

Mapping of Software Components to ECUs

Topology

Signal Path ConstraintsDefine Signal Path Constraints

1

«performs»

1 «input»

1 «input»

«output»

1

Figure 3.54: Define Signal Path Constraints

Task Definition Define Signal Path ConstraintsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Additional guidelines for the System Generator, which specific way a

signal between two Software Components should take in the networkwithout defining in which frame and with which timing it is transmitted.

Description Define additional guidelines for the System Generator, which specificway a signal between two Software Components should take in thenetwork without defining in which frame and with which timing it istransmitted.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Mapping of Soft-

ware Componentsto ECUs

1

Consumes Topology 1Produces Signal Path Con-

straints1

Table 3.114: Define Signal Path Constraints

280 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 281: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.10 Define System Variants

System Engineer

System Description Root Element

Topology

Complete ECU Description

Mapping of Software Components to Implementations

Postbuild Variant Set

Software Component Mapping Constraints

Mapping of Software Components to ECUs

System Constant Value Set

System Description

System Signal Group

System Signal

System Timing

Evaluated Variant Set

Predefined Variant

Define System Variants

«inoutput»

«output»

«output»

«inoutput»

«input»

«input»

«input»

«input»

«input»

1..*

«input»

«input»

1

«performs»

0..*

«input»

«input»

1

«input»

Figure 3.55: Define System Variants

Task Definition Define System VariantsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Define variants for the artifacts of a System Description.Description Define variants for the artifacts of a System Description. Definition of a

variant means in general to define its conditions and its latest bindingtime. Therefore one has to create a PredefinedVariant referring to thesettings which are used by the system elements in scope. To do so,this task can make use of existing System Constant Value Set s and/orPostbuid Variant Set s or define new ones. Several PredefinedVariant scan be combined to one Evaluated Variant Set . This task can also beapplied when designing a subsystem, therefore the System Extract isan optional input.

Relation Type Related Element Mul. NotePerformed by System Engineer 1

281 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 282: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Mapping of Soft-

ware Componentsto ECUs

1

Consumes Mapping of Soft-ware Componentsto Implementations

1

Consumes Software Compo-nent Mapping Con-straints

1

Consumes System Descrip-tion Root Element

1

Consumes System Signal 1Consumes System Signal

Group1

Consumes System Timing 1Consumes Topology 1Consumes Complete ECU

Description1..*

Consumes System Descrip-tion

0..*

In/out Postbuild VariantSet

1

In/out System ConstantValue Set

1

Produces Evaluated VariantSet

1

Produces Predefined Variant 1

Table 3.115: Define System Variants

282 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 283: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.11 Define System Timing

System Engineer

Mapping of Software Components to Implementations

Mapping of Software Components to ECUs

Topology

Communication Layers

Software Component Timing

VFB Timing

System Timing

Define System Timing

«output»

1

1

«input»

0..1

«input»

0..1

«input»

1

«performs»

1

«input»

1

«input»

0..1

«input»

Figure 3.56: Define System Timing

Task Definition Define System TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Define SystemTiming for a concrete system taking the mapping of

software components to ECUs and their implementation into accountDescription Define SystemTiming (TimingDescription and TimingConstraints) for a

concrete system taking the mapping of software components to ECUsand their implementation into account. This means that the resultingCommunication Matrix (and its implication to the communication stack)can also be referenced by the timing specification to refine remotecommunication timing behavior.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Communication

Layers1

Consumes Mapping of Soft-ware Componentsto ECUs

1

Consumes Topology 1Consumes Mapping of Soft-

ware Componentsto Implementations

0..1

Consumes Software Compo-nent Timing

0..1

Consumes VFB Timing 0..1Produces System Timing 1

283 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 284: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. Note

Table 3.116: Define System Timing

3.3.1.12 Extend Topology

System Engineer

ECU Integrator

ECU Resources Description

TopologyExtend Topology

1

«inoutput»

10..1

«input»

0..1

«performs»

0..1

«performs»

Figure 3.57: Extend Topology

Task Definition Extend TopologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Extend the existing System TopologyDescription Extend the existing System Topology by describing how new ECUs will

be connected to the existing one through the current networkRelation Type Related Element Mul. NotePerformed by ECU Integrator 0..1Performed by System Engineer 0..1Consumes ECU Resources

Description0..1

In/out Topology 1

Table 3.117: Extend Topology

284 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 285: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.13 Select Software Component Implementation

Select Software Component Implementation

Mapping of Software Components to Implementations

Atomic Software Component Implementation

Software Component Internal Behavior

VFB Atomic Software Component

System Engineer

1..*

«input»

1..*

«input»

1..*

«input»

1

«performs»

«output»

1

Figure 3.58: Select Software Component Implementation

Task Definition Select Software Component ImplementationPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Select implementation for an Atomic Software Component.Description The system engineer selects an Atomic Software Component

Implementation for each defined VFB Atomic Software ComponentRelation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Atomic Software

Component Imple-mentation

1..*

Consumes Software Compo-nent Internal Be-havior

1..*

Consumes VFB Atomic Soft-ware Component

1..*

Produces Mapping of Soft-ware Componentsto Implementations

1

Table 3.118: Select Software Component Implementation

285 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 286: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.14 Select Design Time Variant

System Description

Complete ECU Description

Select Design Time Variant

System Engineer

«performs»

1

«input»

1

«inoutput»

1

Figure 3.59: Select Design Time Variant

Task Definition Select Design Time VariantPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Select a system variant at system design time.Description Select a system variant at system design time. This could be done in

different ways: Replace a model, which contains the variation pointscontributing to this particular variant and all the possiblesettings/elements, by a model, which does no more contain thesevariation points and which contains only the particularsettings/elements selected for this variant. In order to document theselection for further process steps, it is also possible to keep theinformation about the selected variant and the variation points in themodel by introducing a PredefinedVariant along with appropriate fixedsettings of system constant values. In constrast to variant selection inlater process steps, no code generation or compilation is involved atsystem design time, thus this task is just a transformation of one XMLmodel into another one. This task can be applied to a complete systemdescription, represented by a System Extract

Meth.bindingTime = SystemDesignTimeRelation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Complete ECU

Description1

In/out System Descrip-tion

1

Table 3.119: Select Design Time Variant

286 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 287: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.15 Define System View Mapping

The task Define System View Mapping (see Figure 3.60) creates the SystemView Mapping between two System Descriptions. Different cases can be sepa-rated:

• Mapping of different overall VFB systems - the Abstract System Descrip-tion and the System Configuration Description.

• Mapping of different structured System Extracts, e.g. System Extract de-livered by a primary organization and the different structure (ECU System De-scription) of the secondary organization (see 2.5.4, 2.5.5).

System Description

System View Mapping

Define System View Mapping

System Engineer

«output»

2

«input»

«performs»

Figure 3.60: Define System View Mapping

Task Definition Define System View MappingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief Description Map elements from different views on the system.Description This task creates the System View Mapping between two System

Descriptions (Mapping of different structured system descriptions, e.g.system extract delivered by a primary organization and the differentstructure of the secondary organisation).

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes System Descrip-

tion2

Produces System View Map-ping

1

Table 3.120: Define System View Mapping

287 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 288: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.16 Create Transformer Specification

Create Transformer Specification

System Engineer

Transformer Specification

Basic Software Designer

«output»

1

0..1

«performs»

1

«performs»

Figure 3.61: Create Transformer Specification

Task Definition Create Transformer SpecificationPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief DescriptionDescription In this task the specification of a transformer module is created. Since

the specification is created as a part of the communication design, theSystem Engineer has to perform this task. Optionally a Basic SoftwareDesigner can support the creation of the specification.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Performed by Basic Software De-

signer0..1

Produces Transformer Speci-fication

1

Table 3.121: Create Transformer Specification

288 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 289: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.1.17 Define Rapid Prototyping Scenario

Rapid Prototyping Engineer

Define Rapid Prototyping ScenarioSoftware Component Internal

Behavior

System Description Root Element

Rapid Prototyping Scenario

«output»

1

1

«input»

1..*

«input»

1

«performs»

Figure 3.62: Define Rapid Prototyping Scenario

Task Definition Define Rapid Prototyping ScenarioPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

TasksBrief DescriptionDescription Defines the rapid prototyping scenario.Relation Type Related Element Mul. NotePerformed by Rapid Prototyping

Engineer1

Consumes System Descrip-tion Root Element

1

Consumes Software Compo-nent Internal Be-havior

1..*

Produces Rapid PrototypingScenario

1

Table 3.122: Define Rapid Prototyping Scenario

289 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 290: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.2 Work Products

3.3.2.1 System Description

System Description

Mapping of Software Components to Implementations

Software Component Mapping Constraints

Mapping of Software Components to ECUs

System Description Root Element

System Signal Group System Signal

System Timing

Topology

Evaluated Variant Set

Postbuild Variant Set

Predefined Variant

System Constant Value Set

Data MappingCommunication Matrix

Alias Name Set

Communication Layers

Rapid Prototyping Scenario

0..*

«SPEM_Aggregation»

1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation» 0..1

«SPEM_Aggregation»

0..*«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.63: Structure of generic deliverable System Description

290 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 291: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Partial Extract of a SystemDescription Generic deliverable for defining a System. It is used in different roles

within the methodology.

In each role, this deliverable may contain variation points in its ARXMLartifacts which need to be bound in later steps, e.g. when defining asubsystem from a complete system or later for the single ECUs. If suchvariation points are present, the System Description may optionallyinclude PredefinedVariants in order to predefine variants for laterselection and an Evaluated Variant Set.

Please note that this generic deliverable does not correspond to thesystem description with the system category"SYSTEM_DESCRIPTION" (see [TPS_SYST_01003]). The systemdescription with the category "SYSTEM_DESCRIPTION" isrepresented by the deliverable "System Configuration Description".

This deliverable is equivalent to a description of a system with anycategory. In the System Template Specification "system description" isthe most frequently used term for this kind of artifact.

Kind DeliveredExtended by Abstract System Description, System Configuration Description,

System Constraint Description, System ExtractRelation Type Related Element Mul. NoteAggregates System Descrip-

tion Root Element1

Aggregates CommunicationLayers

0..1

Aggregates Mapping of Soft-ware Componentsto ECUs

0..1

Aggregates Mapping of Soft-ware Componentsto Implementations

0..1

Aggregates Rapid PrototypingScenario

0..1

Aggregates Topology 0..1Aggregates Alias Name Set 0..*Aggregates Communication

Matrix0..*

Aggregates Data Mapping 0..*Aggregates Evaluated Variant

Set0..*

Aggregates Postbuild VariantSet

0..*

Aggregates Predefined Variant 0..*Aggregates Software Compo-

nent Mapping Con-straints

0..*

291 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 292: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates System Constant

Value Set0..*

Aggregates System Signal 0..*Aggregates System Signal

Group0..*

Aggregates System Timing 0..*In/out Select Design

Time Variant1

Consumed by Define SystemView Mapping

2

Consumed by Define SystemSafety Information

1

Consumed by Define AliasNames

0..1 Needed for definition of alias names withsystem, system extract or ECU scope,depending of the role of the SystemDescription.

Consumed by Define SystemVariants

0..*

Table 3.123: System Description

Deliverable System Constraint DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription Contains the artifacts that describe System Constraints. It serves as an

input for setting up the complete Abstract System Description and/orSystem Configuration Description.

This deliverable corresponds to the system description with the systemcategory "SYSTEM_CONSTRAINTS" (see [TPS_SYST_01003]).

Kind DeliveredExtends System DescriptionRelation Type Related Element Mul. NoteAggregates Overall VFB Sys-

tem0..1

Aggregates System Flat Map 0..1Consumed by Develop System 0..1Consumed by Develop an Ab-

stract SystemDescription

0..1 In the context of the "Develop anAbstract System Description" activity, theconstraints for the abstract or functionalview on the system can be provided bythe "System Constraint Description".

Table 3.124: System Constraint Description

292 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 293: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable System Configuration DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription Contains the artifacts that describe a complete AUTOSAR System. It is

the basis for extracting descriptions for sub-systems or ECUs.

Note that System Extracts may be refined by details which are notpresent in the System Configuration.

This deliverable corresponds to the system description with the systemcategory "SYSTEM_DESCRIPTION" (see [TPS_SYST_01003]).

Kind DeliveredExtends System DescriptionRelation Type Related Element Mul. NoteAggregates Overall VFB Sys-

tem1

Aggregates System Flat Map 0..1Produced by Develop System 1..*Consumed by Generate System

Extract1

Consumed by Generate ECU Ex-tract

0..1

Table 3.125: System Configuration Description

Deliverable System ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription Contains the artifacts that describe a subsystem specific view on the

complete System Description. Initially, the System Extract is not fullydecomposed and still contains compositions. It is the basis fordesigning subsystems, e.g. by adding further ECUs within the givenconstraints.

This deliverable corresponds to the system description with the systemcategory "SYSTEM_EXTRACT" (see [TPS_SYST_01003]).

Kind DeliveredExtended by ECU System DescriptionExtends System DescriptionRelation Type Related Element Mul. NoteAggregates VFB System Ex-

tract1

Aggregates System Flat Map 0..1Produced by Develop System 0..*Produced by Generate System

Extract0..*

Consumed by Create ECU Sys-tem Description

1

293 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 294: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Develop Sub-Sys-

tem1

Consumed by Generate ECU Ex-tract

0..1

Table 3.126: System Extract

Deliverable ECU System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription This System Description is used to describe the closed view on one

ECU (note that an AUTOSAR ECU is defined being onemicroprocessor running one AUTOSAR Stack). It can be derived froma System Extract or it can be designed independently and mapped to aSystem Extract. The ECU System Description is not fully decomposedand still may contain compositions.

It is refined during the activity Design Sub-System.

This deliverable corresponds to the system description with the systemcategory "ECU_SYSTEM_DESCRIPTION" (see [TPS_SYST_01003]).

KindExtends System ExtractRelation Type Related Element Mul. NoteProduced by Design Sub-Sys-

tem1 System Extract refined during design of

the corresponding sub-system withelements needed to generate ECUExtract(s).

Produced by Create ECU Sys-tem Description

1..*

Consumed by Design Sub-Sys-tem

1 System Extract as generated from theouter system.

Consumed by Generate ECU Ex-tract

0..1

Table 3.127: ECU System Description

3.3.2.2 Abstract System Description

294 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 295: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable Abstract System DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Provides an abstract or functional view on the systemDescription The Abstract System Description extends the general System

Description and provides an abstract or functional view on the systemto be developed.

This deliverable corresponds to the system description with the systemcategory "ABSTRACT_SYSTEM_DESCRIPTION" (see[TPS_SYST_01003]).

Kind DeliveredExtends System DescriptionRelation Type Related Element Mul. NoteAggregates Overall VFB Sys-

tem1

Produced by Develop an Ab-stract SystemDescription

1..*

Consumed by Develop System 0..* The abstract System Description is anoptional input for the activity "DevelopSystem". Please note, that in this stepthe Abstract System Description isrefined to a System Description.

Consumed by Develop a VFBSystem Descrip-tion

0..* The abstract System Description is anoptional input for the activity "Develop aVFB System Description". TheVFB-related part of the Abstract SystemDescription can be than refined to theconcrete "Overall VFB System".Additionally, a mapping between thosetwo views can be established.

Table 3.128: Abstract System Description

295 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 296: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.2.3 Complete ECU Description

Complete ECU Description

ECU Resources Description

VFB Sensor Actuator Component

1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.64: Complete ECU Description

Deliverable Complete ECU DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description An ECU Description includes the resources it has available along with

its corresponding ECU-specific software components.Description An ECU Description includes the resources it has available along with

its corresponding ECU-specific software components.Kind DeliveredRelation Type Related Element Mul. NoteAggregates ECU Resources

Description1

Aggregates VFB Sensor Actu-ator Component

0..*

Consumed by Select DesignTime Variant

1

Consumed by Define SystemVariants

1..*

Table 3.129: Complete ECU Description

3.3.2.4 System Description Root Element

296 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 297: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact System Description Root ElementPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description A System Description root element.Description The System description defines the following major elements:

• Topology : description of the Topology of the System.

• Software : description of the root software compositioncontaining all software components in the System in ahierarchical structure.

• Communication : description of all Communication elementsused in the System.

• Mapping and Mapping Constraints : description of all mappingaspects (mapping of SW components to ECUs, mapping of dataelements to signals, and mapping constraints).

The root element can be the basis for a System extract as well as forthe whole System depending on which elements are aggregated.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion1

Produced by Assign Top LevelComposition

1

Produced by Set System Root 1 Set up the root element, and the links toother artifacts

Consumed by Define Rapid Pro-totyping Scenario

1

Consumed by Define SystemVariants

1

Consumed by Flatten SoftwareComposition

1 find the top level composition

Consumed by Generate or AdjustSystem Flat Map

1

Use meta model element System 1

Table 3.130: System Description Root Element

3.3.2.5 System Mapping Overview

There are various artifacts which correspond to the mappings collected under the meta-model element SystemMapping. Figure 3.65 shows an overview. The details will beexplained in the following sub-chapters.

297 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 298: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Data Mapping

Software Component Mapping Constraints

Mapping of Software Components to ECUs

Mapping of Software Components to Implementations

VFB Software Component Mapping Constraints

Identifiable

SystemTemplate::SystemMapping

DataMapping::DataMapping

SignalPaths::SignalPathConstraint

Identifiable

SWmapping::SwcToImplMapping

SWmapping::MappingConstraint

Identifiable

SWmapping::SwcToEcuMapping

ARElementAtpStructureElement

SystemTemplate::System

Signal Path Constraints

System View Mapping

Identifiable

ViewMapSet::ViewMap

ARElement

ViewMapSet::ViewMapSet

+dataMapping*

«atpVariation»

+mapping 0..*

«atpVariation,atpSplitable»

«AtpUseMetaModelElement»

+swMapping *

«atpVariation»

+mappingConstraint

*

«atpVariation»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

+swImplMapping *

«atpVariation»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

+signalPathConstraint *

«atpVariation»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

+viewMap

0..*

«AtpUseMetaModelElement»

Figure 3.65: Overview on the various artifacts for System Mapping

3.3.2.6 Software Component Mapping Contraints

298 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 299: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Software Component Mapping ConstraintsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Defined constraints on how certain components must be mapped

(clustered or separated).Description Description of one or more constraints on Software Components during

mapping to the ECUs. Three type of constraints have been defined:

The ComponentClustering constraint (also, clustering) is to be used forexpressing that a certain set of SW components (atomic or not) mustbe mapped (allocated) onto the same ECU. This is some kind of"execute together on same ECU" constraint.The semantic of theclustering constraint is straightforward if all concerned SW componentsare atomic. Otherwise, it shall be interpreted as follows: all of theatomic SW components making up the composition must be mappedtogether onto the same ECU together with all other SW components(atomic or not) affected by the constraint. This also means that aclustering constraint can also refer to only a single composition.

The ComponentSeparation constraint (also, separation) is to be usedfor expressing that two SW components (atomic or not) shall not bemapped (allocated) onto the same ECU. This is some kind of do notexecute together on same ECU constraint.The semantic of theseparation constraint is straightforward if one or both SW componentsare atomic. Otherwise, it shall be interpreted as follows: any of theatomic SW components making up the first composition, must not bemapped onto the same ECU with any atomic SW component from thesecond composition. As a consequence, and to preserve consistency,an atomic SW component instance cannot be part of two compositionsconcerned by the same separation constraint, i.e. the two compositionshave to be disjoint with regards to component instances.

SwcToEcuMapping constraint: The System Constraint Description hasto describe dedicated and exclusive mapping of SW-Cs to one or moreECUs.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..*

Produced by Define SoftwareComponent Map-ping Constraints

1

Consumed by Define SystemVariants

1

Consumed by Set System Root 1 Only the reference to the artifact isneeded

Consumed by Deploy SoftwareComponent

0..1 Constraints defined on the System level

Use meta model element MappingConstraint 1Use meta model element SystemMapping 1 The splitable element SystemMapping is

the root for this artifact.

Table 3.131: Software Component Mapping Constraints

299 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 300: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.2.7 Data Mapping

Artifact Data MappingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription Mapping of data prototypes from the VFB description to System

signals.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..*

Produced by Derive Communi-cation Needs

1..*

Consumed by Define Signal PDUs

1

Consumed by Flatten SoftwareComposition

1..*

Consumed by Set System Root 1..* Only the reference to the artifact isneeded

Use meta model element DataMapping 1Use meta model element SystemMapping 1 The splitable element SystemMapping is

the root for this artifact.

Table 3.132: Data Mapping

3.3.2.8 Mapping of Software Components to ECUs

Artifact Mapping of Software Components to ECUsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Describes the mapping of Software Components to the ECUs that are

defined in the VFB context.Description The VFB shows all Software Components independently of their

deployment on individual ECUs. This work product defines for eachSoftware Component the corresponding ECU on which the SoftwareComponent will be deployed and executed.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..1

Produced by Deploy SoftwareComponent

1

Consumed by Define Signal PDUs

1

Consumed by Define Signal PathConstraints

1

Consumed by Define SystemTiming

1

300 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 301: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Define System

Variants1

Consumed by Derive Communi-cation Needs

1

Consumed by Extract the ECUCommunication

1

Consumed by Flatten SoftwareComposition

1

Consumed by Set System Root 1 Only the reference to the artifact isneeded

Use meta model element SwcToEcuMap-ping

1

Use meta model element SystemMapping 1 The splitable element SystemMapping isthe root for this artifact.

Table 3.133: Mapping of Software Components to ECUs

3.3.2.9 Mapping of Software Components to Implementations

Artifact Mapping of Software Components to ImplementationsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription Specifies the selection of software implementations for the atomic

component prototypes. Because component prototypes can be locatedon different ECUs, it is possible to have different Implementations oftwo prototypes of the same AtomicComponentType in the system.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..1

Produced by Select SoftwareComponent Imple-mentation

1

Consumed by Define SystemVariants

1

Consumed by Define SystemTiming

0..1

Use meta model element SwcToImplMap-ping

1

Use meta model element SystemMapping 1 The splitable element SystemMapping isthe root for this artifact..

Table 3.134: Mapping of Software Components to Implementations

3.3.2.10 Signal Path Constraints

301 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 302: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Signal Path ConstraintsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Constraints on the Path that should be used or not by SignalsDescription One of the tasks of the System Generator is actually to calculate

automatically the communication (signals) between the RTEs anddefine the needed frames for that communication. These definitions ofthe frames include implicitly the definition of the paths theAUTOSAR-Signals are transmitted through the system. Thereby theSystem Generator often has the choice between alternative waysthrough the system. There exist four different constraints for signalsregarding the signal path:

• The CommonSignalPath describes that two signals must takethe same way (Signal Path) in the topology.

• ’The ForbiddenSignalPath describes the way (Signal Path) that asignal must not take in the topology, e.g. in case of safety criticaltransmission.

• The PermissibleSignalPath describes the way (Signal Path) asignal can take in the topology. If more than onePermissibleSignalPath is defined for the same signal/operationattributes, any of them can be chosen.

• The SeparateSignalPath describes that two or more signalsmust not take the same way (Signal Path) in the topology e.g. incase of redundant transmission. It is also possible that the samesignal is aggregated two times by the SeparateSignalPathelement to indicate that this signal should be transmittedredundantly over two different paths.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteProduced by Define Signal Path

Constraints1

Consumed by Set System Root 1 Only the reference to the artifact isneeded

Use meta model element SignalPathCon-straint

1

Use meta model element SystemMapping 1 The splitable element SystemMapping isthe root for this artifact.

Table 3.135: Signal Path Constraints

3.3.2.11 Topology

302 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 303: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact TopologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description The system topology, which may be reused in different systems.Description Describes the topology of the system : A topology is formed by a

number of EcuInstances that are interconnected to each other in orderto form ensembles of ECUs and CommunicationClusters.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..1

Produced by Define SystemTopology

1

In/out Extend Topology 1Consumed by Define Communi-

cation Matrix1

Consumed by Define NetworkManagement

1

Consumed by Define Signal PDUs

1

Consumed by Define Signal PathConstraints

1

Consumed by Define SoftwareComponent Map-ping Constraints

1

Consumed by Define SystemTiming

1

Consumed by Define SystemVariants

1

Consumed by Define TP 1Consumed by Deploy Software

Component1

Consumed by Extract ECU Topol-ogy

1

Consumed by Set System Root 1 Only the reference to the artifact isneeded

Consumed by Define Secured PDUs

0..1

Use meta model element CommunicationCluster

1

Use meta model element EcuInstance 1

Table 3.136: Topology

3.3.2.12 Ecu Resources Description

303 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 304: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact ECU Resources DescriptionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Definition of the resources available on an ECU.Description Definition of the resources available on an ECU. It mainly contains a

description of hardware elements (like physical memory sections orperipherals, pins, hardware connections) which need to be referred bya software component or a basic software description. The focus is todescribe an already engineered piece of hardware, its content andstructure. It is not in the focus of the ECU Resource Description tosupport the design of electronics hardware itself. In the XML it isrepresented as a set of HwDescriptionEntity -s

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Complete ECU

Description1

Produced by Define ECU De-scription

1..*

Consumed by Define SystemTopology

1..*

Consumed by Define BSW Inter-faces

0..1

Consumed by Define ECUAbstraction Com-ponent

0..1

Consumed by Extend Topology 0..1Consumed by Generate ECU Ex-

ecutable0..1 may be used to set up build environment

Meth.bindingTime = CompileTimeConsumed by Implement a BSW

Module0..1 Meth.bindingTime = SystemDesignTime

Consumed by Measure Compo-nent Resources

0..1

Consumed by Measure Re-sources

0..1

Consumed by Define ComplexDriver Component

0..*

Consumed by Define VFB Sen-sor or ActuatorComponent

0..*

Use meta model element HwElement 1

Table 3.137: ECU Resources Description

3.3.2.13 System Signal

304 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 305: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact System SignalPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription The system signals allow to represent this communication view in a

flattened structure, with (at least) one system signal defined for eachdata element sent or received by a SW component instance. If datahas to be sent over gateways, there is still only one system signalrepresenting this data. The representation of the data on the individualcommunication systems is done by the cluster signals.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..*

Produced by Derive Communi-cation Needs

1..*

Consumed by Define Signal PDUs

1

Consumed by Define SystemVariants

1

Consumed by Define RTE Fan-out

1..*

Consumed by Extract the ECUCommunication

0..*

Use meta model element SystemSignal 1

Table 3.138: System Signal

3.3.2.14 System Signal Group

305 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 306: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact System Signal GroupPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description A signal group refers to a set of signals that must always be kept

together. A signal group is used to guarantee the atomic transfer ofAUTOSAR composite data types.

Description The System Signal Group is representing a set of Signals that must bekept together. A signal group is to guarantee the transfer of AUTOSARcomposite data types for sender receiver communication.The RTE isrequired to treat AUTOSAR signals transmitted using sender-receivercommunication atomically. To achieve this, the "signal group"mechanisms shall be utilized.It is not possible to map a Variable DataPrototype with a composite datatype directly to a System Signal . Thecomplex data type must be decomposed into single signals. As this setof single signals has to be treated as atomic, it is placed in a "signalgroup". It is also used in client server communication when the RTEmaps a response to a corresponding operation request. Thearguments, application errors, client identifier and sequence counter ofan operation are mapped to System Signal of two dedicatedSystemSignalGroup elements;one for the request and one for theresponse. The RTE Client Server Protocol is used to provide a specificsemantics to each of these SystemSignalGroups and System Signal ,also those which are introduced only to support the protocol.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..*

Produced by Derive Communi-cation Needs

0..*

Consumed by Define SystemVariants

1

Consumed by Extract the ECUCommunication

0..*

Use meta model element SystemSignalGroup

1

Table 3.139: System Signal Group

3.3.2.15 System Flat Map

306 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 307: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact System Flat MapPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Mapping of instance names to nested model elements. Use cases:

Resolve name conflicts when flattening VFB software compositions;provide unique names and unique model references for measurementand calibration data.

Description The flat map is a list of elements, each element represents exactly onenode (e.g. a component instance or data element) of the instance treeof a software system. The purpose of this element is to map thevarious nested representations of this instance to a flat representationand assign a unique name to it. The name will be unique in the scopeto which this Flat Map belongs (which could be a whole System or aSystem Extract).

Use case: The System Flat Map is defined in the context of a Systemor System Extract. It serves as a basis for generating an ECU Flat Map(or a Flat Map of a "child" System Extract). In the ECU Flat Map, thenames will be used as display names for MCD tools or as names forcomponent prototypes in a flattened software composition. For furtherinformation refer to the description of artifact ECU Flat Map.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Configura-

tion Description0..1

Aggregated by System ConstraintDescription

0..1

Aggregated by System Extract 0..1In/out Generate or Adjust

System Flat Map1

Consumed by Add Documenta-tion to the SoftwareComponent

0..1 Optional input in order to refer to uniquenames defined in system context.

Consumed by Generate or AdjustECU Flat Map

0..1 Take over definitions of unique namesfrom system level to ECU level.

Use meta model element FlatMap 1

Table 3.140: System Flat Map

3.3.2.16 System Timing

307 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 308: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact System TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Concrete system’s TimingDescription and TimingConstraintsDescription TimingDescription and TimingConstraints defined for a concrete

system taking the mapping of software components to ECUs and theirimplementation into account. This means that the resultingCommunication Matrix (and its implication to the communication stack)can also be referenced by the timing specification to refine remotecommunication timing behavior.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..*

Produced by Define SystemTiming

1

Consumed by Define SystemVariants

1

Consumed by Extract ECU Sys-tem Timing

1

Consumed by Deploy SoftwareComponent

0..1

Use meta model element SystemTiming 1

Table 3.141: System Timing

3.3.2.17 System View Mapping

Artifact System View MappingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description The System View Mapping provide an mapping between different

views on the system.Description This artifact contains a set of system view mappings and provides an

mapping between different views on the system, e.g. different overallVFB systems (e.g. abstract system description with systemconfiguration description), or the overall VFB system with the VFBSystem Extract description.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Overall VFB Sys-

tem0..1 The Overall VFB System aggregates a

potential mapping to the abstract orfunctional view of the system.

Aggregated by VFB System Ex-tract

0..1 The VFB System Extract aggregates apotential mapping to the abstract orfunctional view of the system.

Produced by Define SystemView Mapping

1

Use meta model element ViewMapSet 1

Table 3.142: System View Mapping

308 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 309: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.2.18 Transformer Design Bundle

Transformer Design Bundle

Transformer Specification

BSW Module Vendor- Specific Configuration Parameter Definition

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

Figure 3.66: Structure of deliverable Transformer Design Bundle

Deliverable Transformer Design BundlePackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription This deliverable contains a specification of the transformer technology

to be implemented by the BSWM developer. Furthermore it containsthe Vendor specific parameter definition for the correspondingtransformer.

Kind DeliveredRelation Type Related Element Mul. NoteAggregates Transformer Speci-

fication1

Aggregates BSW ModuleVendor- SpecificConfiguration Pa-rameter Definition

0..1

Produced by Design Trans-former

1

Produced by Develop System 0..*Consumed by Develop Basic

Software0..*

Table 3.143: Transformer Design Bundle

3.3.2.19 Transformer Specification

309 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 310: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Transformer SpecificationPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief DescriptionDescription This artifact represents the functional specification of the Transformer

to be implemented. The AUTOSAR methodology does not prescribethe format of this artifact.

Kind CustomRelation Type Related Element Mul. NoteAggregated by Transformer De-

sign Bundle1

Produced by Create Trans-former Specifica-tion

1

Table 3.144: Transformer Specification

3.3.2.20 Rapid Prototyping Scenario

Artifact Rapid Prototyping ScenarioPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Work productsBrief Description Description of the (required) bypass points and the hooks in the

system.Description Description of the (required) bypass points and the in the system and

the corresponding hooks. This artifact contains the RptContainers withbypass points referencing things like parameterAccess(dataWriteAccess, dataReadAccess, dataSendPoint,dataReceivePointByValue, dataReceivePointByArgument,writtenLocalVariable, readLocalVariable, etc.) The hooks describe thelink between the bypass points and the rapid prototyping algorithm.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..1

Produced by Define Rapid Pro-totyping Scenario

1

Consumed by Extract ECU RapidPrototyping Sce-nario

1

Use meta model element RapidPrototypingScenario

1

Table 3.145: Rapid Prototyping Scenario

3.3.3 Communication Matrix and Communication Layers

This section contains the tasks and work products to set up the communication matrixand the communication layers as part of a system description.

310 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 311: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1 Tasks

3.3.3.1.1 Define Communication Matrix

System Engineer

Define Communication Matrix

Communication MatrixTopology

«output» 1

1

«performs»

1 «input»

Figure 3.67: Define Communication Matrix

Task Definition Define Communication MatrixPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description The communication matrix contents are created or extended by adding

communication definitions.Description Define or extend Communication Matrix.

Define the triggering of the Physical Channels and the mapping to thecommunication connector ports.

In case of extension the original communication matrix contents (whichwere delivered as part of a system extract) are extended by addingcommunication definitions. The main use case is the extension of thecommunication matrix when refining a sub-system.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Topology 1Produces Communication

Matrix1

Table 3.146: Define Communication Matrix

311 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 312: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.2 Define Frames

System Engineer

Network Layer

Data Link LayerDefine Frames

Interaction Layer

«output» 1

0..1

«input»

1

«performs»

0..1 «input»

Figure 3.68: Define Frames

Task Definition Define FramesPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define Data Link LayerDescription Define the Frame and assign it to a physical channel of a

communication cluster. Determine the number, the type, the length andthe timing of Frames that are sent or received by the ECUs. Describethe mapping of Pdus (I-Pdus, N-Pdus or NmPdus) into the frame.Define the triggering and the identification of a frame on the physicalchannel, on which it is sent.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Interaction Layer 0..1Consumes Network Layer 0..1Produces Data Link Layer 1

Table 3.147: Define Frames

312 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 313: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.3 Define Signal PDUs

System Engineer

Mapping of Software Components to ECUs

System Signal

Topology

Define Signal PDUsInteraction Layer

Data Mapping

«output»

1 «input»

1

«input»

1

«input»

1

«performs»

1

«input»

Figure 3.69: Define Signal PDUs

Task Definition Define Signal PDUsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define the I-PDU and their ISignalsDescription Define the Signal Pdu that is handled by AUTOSAR COM and assign it

to a physical channel of a communication cluster. Determine the lengthand the timing and describe the mapping of Signals into the SignalPdu..

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Data Mapping 1Consumes Mapping of Soft-

ware Componentsto ECUs

1

Consumes System Signal 1Consumes Topology 1Produces Interaction Layer 1 ISignals

Table 3.148: Define Signal PDUs

313 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 314: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.4 Define Secured PDUs

System Engineer

Topology Interaction Layer

Define Secured PDUs

1

«performs»

+I-PDUs

1 «input»

0..1 «input»

«output»

+Secured PDUs

1

Figure 3.70: Define Secured PDUs

Task Definition Define Secured PDUsPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define Secured PDUsDescription If a secured communication of a PDU over network is required,

SecuredIPDUs are defined. A secured communication can beestablished for IPDUs from the Interaction Layer. In addition to theSecuredPDUs corresponding SecureCommunicationProperties arespecified that describe how the PDU is secured (e.g. authenticationalgorithm).

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Interaction Layer 1 I-PDUs: Authentic IPdu that will be

secured against manipulation and replayattacks.

Consumes Topology 0..1Produces Interaction Layer 1 Secured PDUs: Secured IPdu that

contains payload of an Authentic IPdusupplemented by additionalAuthentication Information.

Table 3.149: Define Secured PDUs

314 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 315: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.5 Define TP

System Engineer

Topology

Network Layer

Define TP

Interaction Layer

Diagnostics Interaction Layer

1

«performs»

0..1

«input»

1 «input»

«output»

0..1

«output»1

Figure 3.71: Define TP

Task Definition Define TPPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define the Network management and the N-PDUsDescription Define the N-PDU - Network Layer Protocol Data Unit (assembled and

disassembled in a Transport Protocol module). If an I-PDU does not fitinto one frame, a segmentation is needed and will be done throughseveral N-PDUs by the Transport Protocol module.

If large COM PDUs are transported by TP, the Interaction Layer shouldbe the Input to the Define TP task. If Diagnostic is used then theDiagnostics Interaction Layer should be an output of Task Define TP.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Topology 1Consumes Interaction Layer 0..1Produces Network Layer 1Produces Diagnostics Inter-

action Layer0..1

Table 3.150: Define TP

315 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 316: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.6 Define Network Management

System Engineer

TopologyNetwork Layer

Interaction Layer

Define Network Management

«performs»

1 «input»

0..1

«input»

«output»

Figure 3.72: Define Network Management

Task Definition Define Network ManagementPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief DescriptionDescription Define the Network Management that is responsible for the cluster

wide coordinated switching of ECUs between operational modes(Network Mode, Bus-sleep Mode). Describe the Nm Pdus andconfigure the Nm Coordinator, the Nm Clusters and Nm Nodes.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Topology 1Consumes Interaction Layer 0..1Produces Network Layer 1

Table 3.151: Define Network Management

316 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 317: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.7 Define PDU Gateway

System Engineer

Define PDU Gateway

Interaction Layer

1 «inoutput» 1

1

«performs»

Figure 3.73: Define PDU Gateway

Task Definition Define PDU GatewayPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define the gateway for IPDUsDescription Define the gateways that are transferring the I-Pdus from one channel

to the other in pairs. Each pair consist of a source and a targetreferencing to a IPduTriggering. In the case that a Pdu is beinggatewayed to more than one channel of the same cluster, all of thisgateway relationships shall be specified. Therefore, all affectedIpduTriggerings must be described as gateway mappings.

Relation Type Related Element Mul. NotePerformed by System Engineer 1In/out Interaction Layer 1

Table 3.152: Define PDU Gateway

3.3.3.1.8 Define Signal Gateway

System Engineer

Interaction Layer

Define Signal Gateway

«performs»

1 «inoutput» 1

Figure 3.74: Define Signal Gateway

317 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 318: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define Signal GatewayPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief DescriptionDescription Define the Signal Gateway to describe the routing of signals and signal

groups from one Physical Channel to another Physical Channel.Relation Type Related Element Mul. NotePerformed by System Engineer 1In/out Interaction Layer 1

Table 3.153: Define Signal Gateway

3.3.3.1.9 Define RTE Fan-out

System Engineer

System SignalDefine RTE Fan-out

Interaction Layer

1

«performs»

1..*

«input» «output»

1

Figure 3.75: Define RTE Fan-out

Task Definition Define RTE Fan-outPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define RTE fan-out which are the relation between ISignals and

System SignalDescription The RTE supports a "signal fan-out" where the same signal (System

Signal) is sent in different IPdus to multiple receivers. The Pdu Routersupports the "PDU fan-out" where the same IPdu is sent to multipledestinations.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes System Signal 1..*Produces Interaction Layer 1 Link of ISignals to System Signals

Table 3.154: Define RTE Fan-out

318 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 319: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.3.1.10 Define Transformation Technology

Define Transformation Technology

System Engineer

Interaction Layer

+DataTransformationSet

1

+ISignals

1

1

«performs»

Figure 3.76: Define Transformation Technology

Task Definition Define Transformation TechnologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief DescriptionDescription Define the information required for the correct usage of the Transformer

(e.g. DataTransformation and TransformationTechnology). This taskproduces a set of DataTransformationSets.

Relation Type Related Element Mul. NoteInteraction Layer 1Interaction Layer 1

Performed by System Engineer 1

Table 3.155: Define Transformation Technology

3.3.3.1.11 Define E2E Transformer Technology

Define E2E Transformer Technology

System Engineer

Interaction Layer

«output»

+E2E Transformer Technology

1

+ISignals

1

«input»

1

«performs»

Figure 3.77: Define E2E Transformer Technology

319 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 320: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Define E2E Transformer TechnologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::TasksBrief Description Define the E2E transformer technology.Description This task defines the E2E transformer technology.Relation Type Related Element Mul. NotePerformed by System Engineer 1Consumes Interaction Layer 1 ISignals:Produces Interaction Layer 1 E2E Transformer Technology:

Table 3.156: Define E2E Transformer Technology

3.3.3.2 Work Products

3.3.3.2.1 Communication Layers

Communication Layers

Data Link Layer Interaction Layer Network Layer

FibexElement

CoreCommunication::Frame

+ frameLength :Integer

Pdu

CoreCommunication::IPdu

CoreCommunication::NPdu

FibexElement

CoreCommunication::ISignal

+ dataTypePolicy :DataTypePolicyEnum+ length :Integer

ARElement

CoreCommunication::SystemSignal

+ dynamicLength :Boolean

Diagnostics Interaction Layer

CoreCommunication::DcmIPdu

+ diagPduType :DiagPduType

ARElement

Transformer::DataTransformationSet

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

0..1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

«AtpUseMetaModelElement» «AtpUseMetaModelElement»«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

1..*

+systemSignal 1

Figure 3.78: Communication Layers

320 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 321: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable Communication LayersPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::Work productsBrief Description Communication MatrixDescription It’s a container for the description elements of the communication

layersKind DeliveredRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..1

Aggregates Data Link Layer 1Aggregates Interaction Layer 1Aggregates Diagnostics Inter-

action Layer0..1

Aggregates Network Layer 0..1Consumed by Define System

Timing1

Consumed by Extract the ECUCommunication

1

Consumed by Set System Root 1 Only the reference to the artifact isneeded

Table 3.157: Communication Layers

3.3.3.2.2 Communication Matrix

Communication Matrix

Identifiable

CoreCommunication::ISignalTriggering

Identifiable

CoreCommunication::PduTriggering

Identifiable

CoreCommunication::FrameTriggering

«AtpUseMetaModelElement»

«AtpUseMetaModelElement»

«atpVariation»

+iSignalTriggering

0..*

«AtpUseMetaModelElement»

«atpVariation»

+pduTriggering 0..*

Figure 3.79: Communication Matrix

321 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 322: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Communication MatrixPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::Work productsBrief DescriptionDescription Define the mapping of the triggering elements within the Physical

Channels to the communication connector ports for the individualECUs.

Because the triggering elements are aggregated as splitable elementswithin the Physical Channels it is possible to define them in an artifactseparated from the Topology.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by System Descrip-

tion0..*

Produced by Define Communi-cation Matrix

1

Use meta model element FrameTriggering 1Use meta model element ISignalTriggering 1Use meta model element PduTriggering 1

Table 3.158: Communication Matrix

3.3.3.2.3 Data Link Layer

Artifact Data Link LayerPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::Work productsBrief Description Describes the frames that are used in the Data Link LayerDescription Describes the layout of frames to be sent over communication

channels. This definition belongs to the Data Link Layer. The Data LinkLayer provides the functional and procedural means to transfer databetween network entities. This layer is used to transmit data passed byan upper layer (PduR, Tp) between adjacent network nodes. InAUTOSAR the Drivers (FrDrv, CanDrv, LinDrv) and Interfaces (FrIf,CanIf, LinIf) belong to the Data Link Layer.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Communication

Layers1

Produced by Define Frames 1Use meta model element Frame 1

Table 3.159: Data Link Layer

3.3.3.2.4 Interaction Layer

322 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 323: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Interaction LayerPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::Work productsBrief Description Describes the Signals of the Interaction Layer.Description Describes the Signals of the Interaction Layer covering the COM

Signals. The Interaction Layer packs one or more signals into assignedCOM I-Pdus and passes them to the underlying layer for transferbetween nodes in a network.

Kind AUTOSAR XMLRelation Type Related Element Mul. Note

Define Transforma-tion Technology

1

Define Transforma-tion Technology

1

Aggregated by CommunicationLayers

1

Produced by Define E2E Trans-former Technology

1 E2E Transformer Technology:

Produced by Define RTE Fan-out

1 Link of ISignals to System Signals

Produced by Define Secured PDUs

1 Secured PDUs: Secured IPdu thatcontains payload of an Authentic IPdusupplemented by additionalAuthentication Information.

Produced by Define Signal PDUs

1 ISignals

In/out Define PDU Gate-way

1

In/out Define SignalGateway

1

Consumed by Define E2E Trans-former Technology

1 ISignals:

Consumed by Define Secured PDUs

1 I-PDUs: Authentic IPdu that will besecured against manipulation and replayattacks.

Consumed by Define Frames 0..1Consumed by Define Network

Management0..1

Consumed by Define TP 0..1Use meta model element DataTransforma-

tionSet1

Use meta model element IPdu 1Use meta model element ISignal 1

Table 3.160: Interaction Layer

3.3.3.2.5 Diagnostics Interaction Layer

323 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 324: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Diagnostics Interaction LayerPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::Work productsBrief DescriptionDescription Collection of DCM IPDUs.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Communication

Layers0..1

Produced by Define TP 0..1Use meta model element DcmIPdu 1

Table 3.161: Diagnostics Interaction Layer

3.3.3.2.6 Network Layer

Artifact Network LayerPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::

Communication Matrix::Work productsBrief Description Describes the PDUs of the Network Layer.Description Describes the PDUs of the Network Layer (N-PDUs and NM-PDUs).

The Network Layer’s main purposes are :

• the segmentation and reassembly of I-PDUs and DCM I-PDUsthat do not fit in one of the assigned N-PDUs

• the definition of NM-PDUs

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Communication

Layers0..1

Produced by Define NetworkManagement

1

Produced by Define TP 1Consumed by Define Frames 0..1Use meta model element NPdu 1

Table 3.162: Network Layer

324 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 325: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.4 ECU Extract

3.3.4.1 Tasks

3.3.4.1.1 Extract ECU Topology

System Engineer ECU Integrator

Topology Extract ECU Topology

System DescriptionECU Extract

ECU Extract of Topology

«output»

1..*1 «input»

0..1

«performs»

0..1

«performs»

0..1

«SPEM_Aggregation»1

«SPEM_Aggregation»

Figure 3.80: Extract ECU Topology

Task Definition Extract ECU TopologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief Description Extract the topology for a single ECU from the System TopologyDescription From the System or System Extract Topology, extract the topology for a

single ECU.Relation Type Related Element Mul. NotePerformed by ECU Integrator 0..1Performed by System Engineer 0..1Consumes Topology 1Produces ECU Extract of

Topology1..*

Table 3.163: Extract ECU Topology

325 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 326: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.4.1.2 Generate or Adjust ECU Flat Map

System Engineer

ECU Integrator

ECU Flat Map

System Flat Map

Generate or Adjust ECU Flat Map

Partial Flat Map

Overall VFB System

VFB System Extract ECU Extract

0..1 «input»

0..1

«performs»0..1

«input»

0..*

«input»0..1

«input»

0..1

«performs»

1

«SPEM_Aggregation»

1 «inoutput» 1

Figure 3.81: Generate or Adjust ECU Flat Map

Task Definition Generate or Adjust ECU Flat MapPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief Description Generates and/or adjust the unique names of component prototypes

and MCD display data in the scope of a single ECU.Description Generates and/or adjust the unique names of component prototypes

and MCD display data in the scope of a single ECU. This information iskept in the so-called ECU Flat Map.

The names can be generated according to some rules (e.g. frommodel elements of the VFB system), taken over from the System FlatMap, from partial Flat Maps, or be manually defined. The task shallalways result in an ECU Flat Map with unique names.

Relation Type Related Element Mul. NotePerformed by ECU Integrator 0..1Performed by System Engineer 0..1Consumes Overall VFB Sys-

tem0..1 Used to set the upstream references in

case one starts from a complete system.Consumes System Flat Map 0..1 Take over definitions of unique names

from system level to ECU level.Consumes VFB System Ex-

tract0..1 Used to set the upstream references in

case one starts from a system extract.

326 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 327: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Partial Flat Map 0..* If Partial Flat Maps were delivered along

with software components referring onlyto ECU internal information, they may beintegrated into the ECU Flat Map directly,i.e. without needing the System FlatMap.

• The instance refs used in a partialflat map must be taken over andadjusted to the context ECUExtract.

• Name conflicts have to beresolved if several partial flatmaps are merged.

In/out ECU Flat Map 1

Table 3.164: Generate or Adjust ECU Flat Map

3.3.4.1.3 Flatten Software Composition

System EngineerECU Integrator

ECU Flat Map

Mapping of Software Components to ECUs

ECU Extract of VFB System

Flatten Software Composition

System Description Root Element

VFB System ExtractOverall VFB System

ECU Extract of Data Mapping

Data Mapping

«output»

1

1

«input»

1 «input»

1..*

«input»

0..1

«input»

1

«performs»

0..1 «input»

1

«input»

0..1

«performs»

«output»

1

Figure 3.82: Flatten Software Composition

327 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 328: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Flatten Software CompositionPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief Description Extract and flatten the ECU Software Composition.Description Generate the complete software composition in an ECU by copying

ComponentPrototypes from the VFB description into a flatrepresentation (still without service components).

Flat representation means, that all compositions are removed and a"flat" set of ComponetPrototypes is generated. Due to the replication ofComponentPrototypes new names have to be generated for those.These can be predefined in the FlatMap which is an input to this task.

The ECU Extract of Data Mapping is also created by this task, as thereferences to the Data Prototypes need to be created with respect tothe new component structure.

Relation Type Related Element Mul. NotePerformed by System Engineer 1Performed by ECU Integrator 0..1Consumes ECU Flat Map 1Consumes Mapping of Soft-

ware Componentsto ECUs

1

Consumes System Descrip-tion Root Element

1 find the top level composition

Consumes Data Mapping 1..*Consumes Overall VFB Sys-

tem0..1 Read relevant elements starting from

VFB Top Level System Composition incase transformation starts with the fullsystem.

Consumes VFB System Ex-tract

0..1 Read relevant elements starting fromVFB Top Level System Composition incase transformation starts from thesystem extract.

Produces ECU Extract ofData Mapping

1

Produces ECU Extract of VFB System

1

Table 3.165: Flatten Software Composition

328 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 329: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.4.1.4 Extract the ECU Communication

System EngineerECU Integrator

Communication Layers

ECU Extract for Communication

Extract the ECU Communication

System Signal

ECU Extract

VFB System

Mapping of Software Components to ECUs

System Signal Group

«output»

1..*

1 «input»

0..*

«input»

1

«input»

0..*

«input»

1

«performs»

1

«input»

1

«performs»

1

«SPEM_Aggregation»

Figure 3.83: Extract the ECU Communication

Task Definition Extract the ECU CommunicationPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief Description The limited-scope communication matrices for an ECU to communicate

on all networks on which it is directly connected.Description The limited-scope communication matrices for an ECU to communicate

on all networks on which it is directly connected.Relation Type Related Element Mul. NotePerformed by ECU Integrator 1Performed by System Engineer 1Consumes Communication

Layers1

Consumes Mapping of Soft-ware Componentsto ECUs

1

Consumes VFB System 1 Need as input in order to set up the DataMapping.

Consumes System Signal 0..*Consumes System Signal

Group0..*

Produces ECU Extract forCommunication

1..*

Table 3.166: Extract the ECU Communication

329 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 330: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.4.1.5 Extract the ECU Timing Model

System Engineer ECU IntegratorSystem Description

ECU Extract

Extract ECU System TimingECU Extract of System Timing

System Timing

0..1

«performs»

1 «input»

0..1

«performs»

«output»1

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.84: Extract the ECU System Timing Model

Task Definition Extract ECU System TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief DescriptionDescription Extract the System Timing Model for a particular ECU from the model

for a complete system or system extract.Relation Type Related Element Mul. NotePerformed by ECU Integrator 0..1Performed by System Engineer 0..1Consumes System Timing 1Produces ECU Extract of

System Timing1

Table 3.167: Extract ECU System Timing

330 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 331: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.4.1.6 Extract the ECU System Variant Model

System Engineer ECU Integrator

System Description

ECU Extract

Extract ECU System Variant Model ECU Extract of System

Variant Model

System Constant Value Set

Predefined Variant

Postbuild Variant Set

Evaluated Variant Set

0..*

«SPEM_Aggregation»

0..1

«performs»0..*

«input»

0..1

«performs»

0..*

«input»

0..*

«input»

0..*

«input»

0..*

«SPEM_Aggregation»

«output»

1

0..*

«SPEM_Aggregation»

0..*«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

Figure 3.85: Extract the ECU System Variant Model

Task Definition Extract ECU System Variant ModelPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief DescriptionDescription Extract the global model elements (ARElements) that are used to

describe variants from system or system extract scope to a particularECU scope. This applies to:

• System Constant Value Set

• Postbuild Variant Set

• Predefined Variant

• Evaluated Variant Set

They are transformed as far as they are needed into the ECU Extract.Relation Type Related Element Mul. NotePerformed by ECU Integrator 0..1Performed by System Engineer 0..1Consumes Evaluated Variant

Set0..*

Consumes Postbuild VariantSet

0..*

Consumes Predefined Variant 0..*

331 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 332: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes System Constant

Value Set0..*

Produces ECU Extract ofSystem VariantModel

1

Table 3.168: Extract ECU System Variant Model

3.3.4.1.7 Extract ECU Rapid Prototyping Scenario

Extract ECU Rapid Prototyping Scenario

ECU IntegratorSystem EngineerSystem Description

Rapid Prototyping Scenario

ECU Extract of Rapid Prototyping Scenario

ECU Extract

0..1

«SPEM_Aggregation»

«output» 1

0..1

«SPEM_Aggregation»

0..1

«performs»

1 «input»

0..1

«performs»

Figure 3.86: Extract ECU Rapid Prototyping Scenario

Task Definition Extract ECU Rapid Prototyping ScenarioPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::TasksBrief Description Extracts the ECU Rapid Prototyping ScenarioDescription From the System Rapid Prototyping Scenario extract the entities

relevant for the single ECU.Relation Type Related Element Mul. NotePerformed by ECU Integrator 0..1Performed by System Engineer 0..1Consumes Rapid Prototyping

Scenario1

Produces ECU Extract ofRapid PrototypingScenario

1

Table 3.169: Extract ECU Rapid Prototyping Scenario

332 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 333: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.3.4.2 Work Products

3.3.4.2.1 ECU Extract

ECU Extract

ECU Extract for Communication

ECU Extract of VFB System

ECU Extract of Topology

ECU Flat Map

ECU Extract Root Element

ECU Extract of System Timing

ECU Extract of System Variant Model

ECU Extract of Data Mapping

ECU Extract of Rapid Prototyping Scenario

0..1

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

1«SPEM_Aggregation»

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

1«SPEM_Aggregation»

1

«SPEM_Aggregation»

Figure 3.87: ECU Extract

Deliverable ECU ExtractPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief Description A version of the System Description, with information pertaining to a

single ECU.Description A deliverable used to describe the ECU specific view on the System

Description. The ECU Extract is fully decomposed and contains onlyAtomic Software Components.It is the basis for setting up the ECUConfiguration.

A timing model is optionally included.

This deliverable may contain variation points in its XML artifacts whichneed to be bound for the ECU. If such variation points are present, theECU extract may optionally include Predefined Variants in order topredefine variants for later selection and an Evaluated Variant Set (thisis expressed by artifact ECU Extract of System Variant Model).

This deliverable corresponds to the system description with the systemcategory "ECU_EXTRACT" (see [TPS_SYST_01003]).

Kind DeliveredRelation Type Related Element Mul. Note

Configure Trans-former

1

333 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 334: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates ECU Extract Root

Element1

Aggregates ECU Extract forCommunication

1

Aggregates ECU Extract ofData Mapping

1

Aggregates ECU Extract ofTopology

1

Aggregates ECU Extract of VFB System

1

Aggregates ECU Flat Map 1Aggregates ECU Extract of

Rapid PrototypingScenario

0..1

Aggregates ECU Extract ofSystem Timing

0..1

Aggregates ECU Extract ofSystem VariantModel

0..1

Produced by Generate ECU Ex-tract

1

Produced by Develop Sub-Sys-tem

1..*

Produced by Develop System 1..*Consumed by Configure Com 1Consumed by Configure Debug 1Consumed by Configure Diag-

nostics1 Application software requirements for

diagnostics, especiallySwcServiceDependency andServiceNeeds.

Consumed by Configure ECUC 1Consumed by Configure Mode

Management1 Application software requirements for

NvM, especially SwcServiceDependencyand ServiceNeeds.

Consumed by Configure NvM 1 Application software requirements forNvM, especially SwcServiceDependencyand ServiceNeeds.

Consumed by Configure RTE 1 Elements of the System Description andVFB Description are referred by the RTEconfiguration.

Optional Input: ECU Extract of SystemTiming, e.g. execution order constraints.

Consumed by Configure Watch-dog Manager

1 Application software requirements forWdgM, especiallySwcServiceDependency andServiceNeeds.

Consumed by Connect ServiceComponent

1 Find the ports on the application side tobe connected to the Service Component.

334 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 335: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Define Integration

Variant1

Consumed by Generate BaseEcu Configuration

1

Consumed by Generate RTE 1 Find the VFB description of all AtomicSoftware Components on this ECU andthe relevant parts of the systemdescription.

The ECU Flat Map is also an input.Meth.bindingTime = SystemDesignTime

Consumed by Generate RTEPostbuild Dataset

1 Meth.bindingTime = LinkTime

Consumed by Generate RTEPrebuild Dataset

1 Meth.bindingTime =CodeGenerationTime

Consumed by Generate UpdatedECU Configuration

1

Consumed by Integrate Softwarefor ECU

1

Consumed by Prepare ECU Con-figuration

1

Consumed by Update ECU Con-figuration

1

Consumed by Create MC Func-tion Model

0..1 The ECU Flat Map can be used to definereferences to variables and parameterswhich are later visible in A2L.

Furthermore, the ECU Extract can beused to find the relevant softwarecomponents.

Consumed by Create ServiceComponent

0..1 Input information about the Service Portsand Service Dependencies of thesoftware components.

Consumed by Define ECU Tim-ing

0..1 Needed to set up links to the elements ofthe ECU extract.

Table 3.170: ECU Extract

3.3.4.2.2 ECU Extract Root Element

Artifact ECU Extract Root ElementPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief DescriptionDescription Extract of the System root element for a specific ECU.Kind AUTOSAR XMLExtends SystemRelation Type Related Element Mul. Note

335 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 336: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregated by ECU Extract 1Consumed by Generate Rapid

Prototyping Wrap-per

1

Use meta model element System 1

Table 3.171: ECU Extract Root Element

3.3.4.2.3 ECU Extract of VFB System

Deliverable ECU Extract of VFB SystemPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief Description Contains the complete software composition in an ECU, copied from

the VFB description into a flat representation, it is still without servicecomponents.

Description Contains the complete software composition in an ECU, copied fromthe VFB description into a flat representation, that means it is stillwithout service components. Flat representation means, that allcompositions have been removed and a "flat" set ofComponentPrototypes was generated (including their connectors)which are put into the top level composition of the ECU.

Kind DeliveredExtends VFB SystemRelation Type Related Element Mul. NoteAggregated by ECU Extract 1Produced by Flatten Software

Composition1

Consumed by Generate RapidPrototyping Wrap-per

1

Use meta model element RootSwComposi-tionPrototype

1

Table 3.172: ECU Extract of VFB System

3.3.4.2.4 ECU Extract of Data Mapping

Artifact ECU Extract of Data MappingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief DescriptionDescription ECU extract of the mapping of data prototypes from the (flattened) VFB

description to System Signals.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by ECU Extract 1

336 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 337: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Flatten Software

Composition1

Use meta model element DataMapping 1

Table 3.173: ECU Extract of Data Mapping

3.3.4.2.5 ECU Extract of Topology

Artifact ECU Extract of TopologyPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief Description A view of the topology centered around a single ECU.Description A view of the topology centered around a single ECU.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by ECU Extract 1Produced by Extract ECU Topol-

ogy1..*

Use meta model element CommunicationCluster

1

Use meta model element EcuInstance 1

Table 3.174: ECU Extract of Topology

3.3.4.2.6 ECU Extract for Communication

Artifact ECU Extract for CommunicationPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief Description A version of the System Communication Matrix work product, with

information pertaining to a single ECU.Description This artifact represents an extract of the System Description elements

for communication with respect to a single ECU. It provides allinformation needed to let the ECU communicate on all networks onwhich it is directly connected.

It is extracted from these system artifacts:

• Communication Matrix

• Communication Layers

• System Signal(s)

• System Signal Group(s)

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by ECU Extract 1

337 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 338: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Extract the ECU

Communication1..*

Use meta model element FibexElement 1

Table 3.175: ECU Extract for Communication

3.3.4.2.7 ECU Extract of System Timing

Artifact ECU Extract of System TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief DescriptionDescription The extract of the System Timing for a particular ECU.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by ECU Extract 0..1Produced by Extract ECU Sys-

tem Timing1

Consumed by Define ECU Tim-ing

0..1

Use meta model element SystemTiming 1

Table 3.176: ECU Extract of System Timing

3.3.4.2.8 ECU Extract of System Variant Model

Deliverable ECU Extract of System Variant ModelPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief DescriptionDescription An extract of the System artifacts

• System Constant Value Set

• Postbuld Variant Set

• Predefined Variant

• Evaluated Variant Set

It contains only the elements relevant for a particular ECU.Kind DeliveredRelation Type Related Element Mul. NoteAggregated by ECU Extract 0..1Aggregates Evaluated Variant

Set0..*

Aggregates Postbuild VariantSet

0..*

338 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 339: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Predefined Variant 0..*Aggregates System Constant

Value Set0..*

Produced by Extract ECU Sys-tem Variant Model

1

Consumed by Generate RapidPrototyping Wrap-per

0..1

Table 3.177: ECU Extract of System Variant Model

3.3.4.2.9 ECU Flat Map

Artifact ECU Flat MapPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief Description Mapping of instance names to nested model elements. Use cases:

Resolve name conflicts when flattening VFB software compositions;provide unique names for measurement and calibration data.

Description The flat map is a list of elements, each element represents exactly onenode (e.g. a component instance or data element) of the instance treeof a software system. The purpose of this element is to map thevarious nested representations of this instance to a flat representationand assign a unique name to it. The name will be unique in the scopeof a single ECU. (Note that additional alias names can be defined viaartifact Alias Name Set.)

Use cases:

• Specify the display name of a data object for measurement andcalibration. This serves as an input for the calibration supportwhich is produced by the RTE generator. The RTE generatorneeds to find the attributes assigned to these data via theattached references.

• Specify a unique name for an instance of a componentprototype in the ECU extract of the system description. Thisinformation is needed to set up the ECU extract.

• Assign initial values to calibration parameters as input for theRTE generator.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by ECU Extract 1In/out Generate or Adjust

ECU Flat Map1

Consumed by Flatten SoftwareComposition

1

Consumed by Generate Local MC Data Support

1 Meth.bindingTime = SystemDesignTime

339 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 340: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Generate Rapid

Prototyping Wrap-per

1

Consumed by Provide RTE Cali-bration Dataset

1

Consumed by Generate A2L 0..1 The ECU Flat Map is needed in case theA2L generator has to process an MCFunction Model that relates to data in theECU Flat Map.

Use meta model element FlatInstanceDe-scriptor

1

Table 3.178: ECU Flat Map

3.3.4.2.10 ECU Extract of Rapid Prototyping Scenario

Artifact ECU Extract of Rapid Prototyping ScenarioPackage AUTOSAR Root::M2::Methodology::Methodology Library::System::EC

U Extract::Work productsBrief Description Description of the (required) bypass points in the ECU.Description Description of the (required) bypass points in the ECU.Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by ECU Extract 0..1Produced by Extract ECU Rapid

Prototyping Sce-nario

1

In/out Refine Rapid Pro-totyping Scenario

1

Consumed by Generate RapidPrototyping Wrap-per

1

Table 3.179: ECU Extract of Rapid Prototyping Scenario

3.4 Software Component

This chapter contains the definition of work products and tasks used for the develop-ment of a single software component against a given VFB description. For the definitionof the relevant meta-model elements refer to [5].

340 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 341: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1 Tasks

3.4.1.1 Define Software Component Internal Behavior

Define Atomic Software Component Internal Behavior

Software Component Designer

Software Component Developer

Software Component Internal Behavior

VFB Atomic Software Component

VFB AUTOSAR Standard Package

«performs»

0..1

«input»

1 «input»

0..1

«performs»

«output» 1

Figure 3.88: Define Software Component Internal Behavior

Task Definition Define Atomic Software Component Internal BehaviorPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Define the InternalBehavior in relation to a given

AtomicSoftwareComponentTypeDescription Define the InternalBehavior in relation to a given

AtomicSoftwareComponentType so that an RTE API can be generated.This includes the definition of Runnables, RTE Events, Inter-Runnablevariables, etc.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Performed by Software Compo-nent Developer

0..1

Consumes VFB Atomic Soft-ware Component

1

Consumes VFB AUTOSARStandard Package

0..1 Use standardized elements (e.g. DataTypes) as blueprints (as far asapplicable) to create the correspondingelements of the actual project.

Produces Software Compo-nent Internal Be-havior

1

Table 3.180: Define Atomic Software Component Internal Behavior

341 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 342: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.2 Define Partial Flat Map

Software Component Designer

Software Component Developer

Software Component Internal Behavior

VFB System

Partial Flat Map

Define Partial Flat Map

«output» 1

0..*

«input»

0..1

«performs»

1

«input»

0..1

«performs»

Figure 3.89: Define Partial Flat Map

Task Definition Define Partial Flat MapPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief DescriptionDescription Define a Partial Flat Map for an intended delivery of Atomic Software

Components.Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer0..1

Performed by Software Compo-nent Developer

0..1

Consumes VFB System 1 Various parts of a given VFB system willbe used as input:

• Refer to parameters and variablesin port interfaces and their datatypes.

• In order to define unique names,also other the componentdefinitions not in the scope of thepartial flat map might be checked.

• Set a link to the context of the FlatMap, e.g. a VFB Composition.

Consumes Software Compo-nent Internal Be-havior

0..* Refer to parameter and variables definedin the Internal Behavior of one or moreAtomic Software Components.

Produces Partial Flat Map 1

Table 3.181: Define Partial Flat Map

342 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 343: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.3 Define Software Component Timing

Define Software Component Timing

Software Component Developer

Software Component Internal Behavior

VFB Timing

Software Component Timing

«output» 1

1 «input» «performs»

0..1

«input»

Figure 3.90: Define Software Component Timing

Task Definition Define Software Component TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Define SWCTiming (TimingDescription and TimingConstraints) for the

Internal Behavior (RunnableEntities) of a Software ComponentDescription Define SWCTiming (TimingDescription and TimingConstraints) of a

software component. A software component can either be of typeAtomicSWComponentType or CompositionSWComponentType.

In the former case, the task allows to describe timing description andconstraints for the InternalBehavior of the AtomicSWComponentType.

In the latter case, timing descriptions and constraints can be defined forall Atomic Software Components in theCompositionSWComponentType.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Consumes Software Compo-nent Internal Be-havior

1

Consumes VFB Timing 0..1Produces Software Compo-

nent Timing1

Table 3.182: Define Software Component Timing

343 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 344: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.4 Define SymbolProps for Types

Software Component Developer

VFB Atomic Software Component

VFB Types

Define SymbolProps for Types

«performs»

«output»

+symbolProps

0..*

«output» +symbolProps

0..*

Figure 3.91: Define SymbolProps for Types

Task Definition Define SymbolProps for TypesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Define SymbolProps for types in order to resolve name conflicts in the

code.Description Redefines the symbols used by the RTE contract for the names of

software component types and/or implementation data types (in thecode as well as in certain header file names).

This task is used to resolve name conflicts between different softwarecomponents without changing the VFB model.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Produces VFB Atomic Soft-ware Component

0..* symbolProps: The symbolProps attributeredefines the software component typename used in the code of the RTE. Thisresolves name clashes among differentsoftware component types designedaccidentally with the same shortName.

Note that this output is a splitableelement, so it can be added later withoutchanging the VFB model.

344 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 345: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces VFB Types 0..* symbolProps: The symbolProps attribute

redefines the implementation data typename used in the code of the RTE and/orthe component. This resolves nameclashes among different implementationdata types designed accidentally with thesame shortName.

Note that this output is a splitableelement, so it can be added later withoutchanging the VFB model.

Table 3.183: Define SymbolProps for Types

3.4.1.5 Add Documentation to the Software Component

Add Documentation to the Software Component

Software Component Developer

Software Component Designer

Software Component Documentation

System Flat Map

Alias Name Set

Partial Flat Map

0..*

«input»

0..1

«input»

0..1

«performs»

0..1

«input»

1

«performs»

1

«inoutput»

Figure 3.92: Add Documentation to the Software Component

Task Definition Add Documentation to the Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Add documentation to the Software ComponentDescription Add documentation to the Software Component describing the

functionality, how to test it, the calibration uses, the maintenance anddiagnosis issues.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Performed by Software Compo-nent Developer

0..1

345 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 346: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Partial Flat Map 0..1 Optional input in order to refer to unique

names defined in component orcomposition context.

Consumes System Flat Map 0..1 Optional input in order to refer to uniquenames defined in system context.

Consumes Alias Name Set 0..* Optional input in order to refer to uniquenames defined in an Alias Name Set(e.g. System Constants).

In/out Software Compo-nent Documenta-tion

1

Table 3.184: Add Documentation to the Software Component

3.4.1.6 Generate Atomic Software Component Contract Header Files

Generate Atomic Software Component Contract Header Files

Software Component Developer

Component API Generator Tool

Application Header File

Software Component Data Types Header

Software Component Internal Behavior

VFB Atomic Software Component

Postbuild Variant Set

Predefined Variant

System Constant Value Set

VFB Data Type Mapping Set

VFB Interfaces

VFB ModesVFB AUTOSAR Standard Package

VFB Types

Software Component to BSW Mapping

«used tool»

«output»

1

1

«input»

0..*

«input»

«performs»

0..1

«input»

0..*

«input»

0..1

«input»

0..1

«input»

0..1

«input»

0..1 «input»

0..1

«input»

0..*

«input»

1

«input»

«output»1

Figure 3.93: Generate Atomic Software Component Contract Header Files

346 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 347: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Generate Atomic Software Component Contract Header FilesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Generate the component contract header files.Description Generate the component header files as part of the so-called "contract

phase". These headers will allow to link the component lateron with theRTE.

The header can still contain variants with later binding time, thereforethe information about these variants is contained in the input to thistask.

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Consumes Software Compo-nent Internal Be-havior

1 Meth.bindingTime = SystemDesignTime

Consumes VFB Atomic Soft-ware Component

1 Meth.bindingTime = SystemDesignTime

Consumes Postbuild VariantSet

0..1

Consumes Predefined Variant 0..1Consumes Software Compo-

nent to BSW Map-ping

0..1 If a Software Component is mapped to aBSW module description, this input isoptionally needed already in the contractphase in order to ensure that thegenerated prototypes for runnables areconsistent with the definitions inSoftware Component and BSW.Meth.bindingTime = SystemDesignTime

Consumes System ConstantValue Set

0..1 Meth.bindingTime = SystemDesignTime

Consumes VFB AUTOSARStandard Package

0..1

Consumes VFB Data TypeMapping Set

0..1 Meth.bindingTime = SystemDesignTime

Consumes VFB Interfaces 0..* Meth.bindingTime = SystemDesignTimeConsumes VFB Modes 0..* Meth.bindingTime = SystemDesignTimeConsumes VFB Types 0..* Meth.bindingTime = SystemDesignTimeProduces Application Header

File1 Meth.bindingTime =

CodeGenerationTimeProduces Software Compo-

nent Data TypesHeader

1 Meth.bindingTime =CodeGenerationTime

Used tool Component APIGenerator Tool

1

Table 3.185: Generate Atomic Software Component Contract Header Files

347 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 348: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.7 Generate Component Header File in Vendor Mode

Generate Component Header File in Vendor Mode

Component API Generator Tool

Optimized Application HeaderFile

Software Component Data Types Header

Software Component Internal Behavior

Atomic Software Component Implementation

VFB Atomic Software Component

VFB Data Type Mapping Set

VFB Interfaces

VFB Modes

VFB AUTOSAR Standard Package

VFB Types

Software Component Developer

ECU Integrator

«used tool»

«output»1

«output»

1

0..* «input»

0..1

«performs»

0..1

«input»

1

«input»

0..*

«input»

1

«input»

0..*

«input»

1

«input»

1

«performs»

0..1

«input»

Figure 3.94: Generate Component Header File in Vendor Mode

Task Definition Generate Component Header File in Vendor ModePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Generate an optimized component header file. This is achieved by

using the RTE’s vendor mode.Description Generate an optimized component header file. This is achieved by

using the RTE’s vendor mode.

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Performed by ECU Integrator 0..1Consumes Atomic Software

Component Imple-mentation

1 Meth.bindingTime = SystemDesignTime

Consumes Software Compo-nent Internal Be-havior

1 Meth.bindingTime = SystemDesignTime

348 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 349: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes VFB Atomic Soft-

ware Component1 Meth.bindingTime = SystemDesignTime

Consumes VFB AUTOSARStandard Package

0..1

Consumes VFB Data TypeMapping Set

0..1 Meth.bindingTime = SystemDesignTime

Consumes VFB Interfaces 0..* Meth.bindingTime = SystemDesignTimeConsumes VFB Modes 0..* Meth.bindingTime = SystemDesignTimeConsumes VFB Types 0..* Meth.bindingTime = SystemDesignTimeProduces Optimized Applica-

tion Header File1 Meth.bindingTime =

CodeGenerationTimeProduces Software Compo-

nent Data TypesHeader

1 Meth.bindingTime =CodeGenerationTime

Used tool Component APIGenerator Tool

1

Table 3.186: Generate Component Header File in Vendor Mode

349 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 350: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.8 Generate Component Prebuild Data Set

Generate Component Prebuild Data Set

Software Component Developer

Predefined Variant

System Constant Value Set

Software Component InternalBehavior

VFB Atomic Software Component

VFB Data Type MappingSet

VFB Interfaces

VFB Modes

VFB AUTOSAR Standard Package

VFB Types

Component RTE Prebuild Configuration Header

Component API Generator Tool

0..*

«input»

0..*

«input»

1

«input»

0..1

«input»

0..1

«input»

1..*

«input»

«performs»

0..*

«input»

1

«input»

0..*

«input»

«used tool»

«output» 1

Figure 3.95: Generate Component Prebuild Data Set

Task Definition Generate Component Prebuild Data SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Prebuild Data Set Generation Phase for a software component: It binds

all variations which need to be set after generation of the RTE contractheader but before compilation of the component.

Description Prebuild Data Set Generation Phase for a software component: It bindsall variations which need to be set after generation of the RTE contractheader but before compilation of the component. The output is aconfiguration header which is used when compiling the component andthe RTE as well.

Meth.bindingTime = PreCompileTimeRelation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Consumes Software Compo-nent Internal Be-havior

1 Meth.bindingTime =CodeGenerationTime

350 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 351: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes VFB Atomic Soft-

ware Component1 Meth.bindingTime =

CodeGenerationTimeConsumes System Constant

Value Set1..* Meth.bindingTime =

CodeGenerationTimeConsumes VFB AUTOSAR

Standard Package0..1

Consumes VFB Data TypeMapping Set

0..1 Meth.bindingTime =CodeGenerationTime

Consumes Predefined Variant 0..*Consumes VFB Interfaces 0..* Meth.bindingTime =

CodeGenerationTimeConsumes VFB Modes 0..* Meth.bindingTime =

CodeGenerationTimeConsumes VFB Types 0..* Meth.bindingTime =

CodeGenerationTimeProduces Component RTE

Prebuild Configu-ration Header

1 Meth.bindingTime = PreCompileTime

Used tool Component APIGenerator Tool

1

Table 3.187: Generate Component Prebuild Data Set

3.4.1.9 Implement Atomic Software Component

Implement Atomic Software Component

Software Component Developer

Atomic Software Component Source Code

Atomic Software Component Implementation

Standard Header Files Software Component Timing

Library Description

Library Header Files

Software Component Internal Behavior

Application Header File

Software Component Data Types Header

1

«input»

0..1

«input»

0..*

«input»

0..*

«input»1

«input»

1 «input»

«performs»

0..1

«input»

«output»

1

«output»

1

Figure 3.96: Implement Atomic Software Component

351 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 352: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Implement Atomic Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Implement the code of the AtomicSoftwareComponent and decribe the

Implementation.Description Implement the code of the AtomicSoftwareComponent against the

generated component contract header. Document the basicinformation in the Implementation Description.

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Consumes Application HeaderFile

1 Meth.bindingTime = SystemDesignTime

Consumes Software Compo-nent Data TypesHeader

1 Meth.bindingTime = SystemDesignTime

Consumes Software Compo-nent Internal Be-havior

1 Meth.bindingTime = SystemDesignTime

Consumes Software Compo-nent Timing

0..1 Meth.bindingTime = SystemDesignTime

Consumes Standard HeaderFiles

0..1 Meth.bindingTime =CodeGenerationTime

Consumes Library Description 0..* Meth.bindingTime =CodeGenerationTime

Consumes Library HeaderFiles

0..* Meth.bindingTime =CodeGenerationTime

Produces Atomic SoftwareComponent Imple-mentation

1 Meth.bindingTime =CodeGenerationTime

Produces Atomic Soft-ware ComponentSource Code

1 Meth.bindingTime =CodeGenerationTime

Table 3.188: Implement Atomic Software Component

352 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 353: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.10 Compile Atomic Software Component

Compile Atomic Software Component

Software Component Developer

Compiler

Atomic Software Component Object Code

Atomic Software Component Source Code

Application Header File

Component RTE Prebuild Configuration Header

Software Component Data Types Header

Library Header FilesStandard Header Files

Rapid Prototyping Wrapper Header File

Rapid Prototyping Wrapper Source Code

Rapid Prototyping Engineer

«used tool»

«output» 1

0..1

«performs»

0..1

«input»

0..1

«input»

0..*

«input»

1

«input»

1 «input»

1

«input»

0..1

«input»

1

«input»

0..1

«performs»

Figure 3.97: Compile Atomic Software Component

Task Definition Compile Atomic Software ComponentPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Compile the AtomicSoftwareComponent independently of an ECU.Description Compile the Atomic Software Component independently of an ECU. In

the context of Rapid Prototyping Wrapper compilation the task isperformed by the Rapid Prototyping Engineer.

Meth.bindingTime = CompileTimeRelation Type Related Element Mul. NotePerformed by Rapid Prototyping

Engineer0..1

Performed by Software Compo-nent Developer

0..1

Consumes Application HeaderFile

1 Meth.bindingTime =CodeGenerationTime

Consumes Atomic Soft-ware ComponentSource Code

1 Meth.bindingTime =CodeGenerationTime

353 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 354: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Software Compo-

nent Data TypesHeader

1 Meth.bindingTime =CodeGenerationTime

Consumes Standard HeaderFiles

1 Meth.bindingTime =CodeGenerationTime

Consumes Component RTEPrebuild Configu-ration Header

0..1 Meth.bindingTime = PreCompileTime

Consumes Rapid PrototypingWrapper HeaderFile

0..1

Consumes Rapid PrototypingWrapper SourceCode

0..1

Consumes Library HeaderFiles

0..* Meth.bindingTime =CodeGenerationTime

Produces Atomic SoftwareComponent ObjectCode

1 The object file should include both codeof the SWC and the E2E ProtectionWrapper code (if present as an input).Meth.bindingTime = CompileTime

Used tool Compiler 1

Table 3.189: Compile Atomic Software Component

3.4.1.11 Map Software Component to BSW

Map Software Component to BSW Software Component to BSW Mapping

Basic Software Module Internal Behavior

Software Component Internal Behavior

Complex Driver Component

ECU Abstraction Software Component

Software Component Designer

ECU Integrator

«output» 1

0..1

«input»

0..1

«input»

0..1

«performs»1

«input»

1

«performs»

1

«input»

Figure 3.98: Map Software Component to BSW

354 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 355: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Map Software Component to BSWPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Define the mapping between a Software Component and a BSW

Module.Description Define the mapping between a Software Component and a BSW

Module. Required only for Complex Drivers and ECU AbstractionComponents. Note that for Service Components, this mapping will begenerated in the ECU integration phase, so the latter is not consideredas a task in the responsibility of the BSW developer.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Performed by ECU Integrator 0..1Consumes Basic Software

Module InternalBehavior

1

Consumes Software Compo-nent Internal Be-havior

1

Consumes Complex DriverComponent

0..1

Consumes ECU AbstractionSoftware Compo-nent

0..1

Produces Software Compo-nent to BSW Map-ping

1

Table 3.190: Map Software Component to BSW

355 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 356: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.1.12 Measure Component Resources

Measure Component Resources

Basic Software Module Developer

ECU Integrator

Software Component Developer

Atomic Software Component Implementation

Atomic Software Component ObjectCode

ECU Resources Description

Software Component Timing

«inoutput» 1

0..1

«performs»

0..1

«performs»

1 «input»

1

«performs»

«input»

0..1

«input»

0..1

Figure 3.99: Measure Component Resources

Task Definition Measure Component ResourcesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Measure the resource consumption of an Atomic Software ComponentDescription Determine the resource consumption (memory, execution time) for a

specific implementation of an Atomic Software Component in a certaincontext (ECU or test environment) and document the results in theImplementation description targeted at this specific platform.

The ECU Resources Description is an optional input, because someresults should be documented in relation to the hardware elements.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Performed by Basic SoftwareModule Developer

0..1

Performed by ECU Integrator 0..1Consumes Atomic Software

Component ObjectCode

1

Consumes ECU ResourcesDescription

0..1

Consumes Software Compo-nent Timing

0..1

In/out Atomic SoftwareComponent Imple-mentation

1

356 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 357: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. Note

Table 3.191: Measure Component Resources

3.4.1.13 Recompile Component in ECU Context

Re-compile Component in ECU context

Software Component Developer

Compiler

Atomic Software Component Source Code

Library Header Files

Optimized Software Component Object Code

Optimized ApplicationHeader File

Standard Header Files

«output»

1

«used tool»

0..* «input»

1

«input»

«performs»

1 «input»

1

«input»

Figure 3.100: Recompile Component in ECU Context

Task Definition Re-compile Component in ECU contextPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Re-compile Component with ECU-Configuration specific optimizations.Description Re-compile Component with optimizations made by the RTE in the

context of an ECU (so-called RTE implementation phase).

Meth.bindingTime = CompileTimeRelation Type Related Element Mul. NotePerformed by Software Compo-

nent Developer1

Consumes Atomic Soft-ware ComponentSource Code

1 Meth.bindingTime =CodeGenerationTime

Consumes Optimized Applica-tion Header File

1 Meth.bindingTime =CodeGenerationTime

Consumes Standard HeaderFiles

1 Meth.bindingTime =CodeGenerationTime

Consumes Library HeaderFiles

0..* Meth.bindingTime =CodeGenerationTime

357 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 358: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces Optimized Soft-

ware ComponentObject Code

1 Meth.bindingTime = CompileTime

Used tool Compiler 1

Table 3.192: Re-compile Component in ECU context

3.4.1.14 Define Consistency Needs

Define Consistency Needs

Software Component Designer

Software Component Developer

Consistency Needs

Software Component Internal Behavior

VFB Types

VFB Interfaces

VFB Atomic Software Component

«inoutput»

1

0..* «input»

0..*

«input»0..*

«input»

1..*

«input»

«performs»

«performs»

Figure 3.101: Define Consistency Needs

Task Definition Define Consistency NeedsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief DescriptionDescription Defines the consistency relations between a group of RunnableEntitys

and a group of DataPrototypes. The consistency relations can bedefined first time at the design of an Atomic Software Component butcan be added as well if Compositions are created.

Relation Type Related Element Mul. NotePerformed by Software Compo-

nent Designer1

Performed by Software Compo-nent Developer

1

358 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 359: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Software Compo-

nent Internal Be-havior

1..* Runnables the consistency is defined for.

Consumes VFB Atomic Soft-ware Component

0..* The description of anAtomicSoftwareComponentType withoutInternalBehavior.

Consumes VFB Interfaces 0..* Interfaces which are relevant for theconsistency definition.

Consumes VFB Types 0..* Data types which are relevant for theconsistency definition.

In/out ConsistencyNeeds

1 The description of the correlationbetween a group of RunnableEntitys anda group of DataPrototypes. In order toallow incremental development andrefinement the Consistency Needsartifact is also used as an input.

Table 3.193: Define Consistency Needs

3.4.1.15 Generate Rapid Prototyping Wrapper

Generate Rapid Prototyping Wrapper

Software Component Internal Behavior

Rapid Prototyping Wrapper Header File

Rapid Prototyping Wrapper Source Code

Rapid Prototyping Engineer

ECU Extract Root Element

ECU Extract of System Variant Model

ECU Extract of VFB System

ECU Extract of Rapid Prototyping Scenario

ECU Flat Map

«output»

1

«output»

1

1

«input»

1

«input»

1

«performs»

1

«input»

1 «input»

1

«input»0..1

«input»

Figure 3.102: Generate Rapid Prototyping Wrapper

359 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 360: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Generate Rapid Prototyping WrapperPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

TasksBrief Description Generate Rapid Prototyping Wrapper code.Description Generate Rapid Prototyping Wrapper code. The header and source

code are generated based on the Rapid Prototyping Scenariodescribing the bypass points and the RPT hooks.

Relation Type Related Element Mul. NotePerformed by Rapid Prototyping

Engineer1

Consumes ECU Extract RootElement

1

Consumes ECU Extract ofRapid PrototypingScenario

1

Consumes ECU Extract of VFB System

1

Consumes ECU Flat Map 1Consumes Software Compo-

nent Internal Be-havior

1

Consumes ECU Extract ofSystem VariantModel

0..1

Produces Rapid PrototypingWrapper HeaderFile

1

Produces Rapid PrototypingWrapper SourceCode

1

Table 3.194: Generate Rapid Prototyping Wrapper

360 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 361: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.2 Work Products

3.4.2.1 Delivered Atomic Software Components

Delivered Atomic Software Components

Software Component Internal Behavior

Software Component to BSW Mapping

Atomic Software Component Source Code

Software Component Documentation

Atomic Software Component Implementation

Atomic Software Component Object Code

Application Header File

Component RTE Prebuild Configuration Header

Software Component Data Types Header

System Constant Value Set

Predefined Variant

Software Component Timing

Evaluated Variant Set

Postbuild Variant Set

Library Object Code

VFB Atomic Software Component

VFB Interfaces

VFB Data Type Mapping SetVFB Modes VFB Types

VFB Composition Component

Partial Flat MapAlias Name SetConsistency Needs

1..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

1..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

1..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»0..*

«SPEM_Aggregation»

Figure 3.103: Delivered Atomic Software Components

361 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 362: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable Delivered Atomic Software ComponentsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Delivery of a set of AtomicSoftwareComponents including their

Implementation.Description Complete description of a set of AtomicSoftwareComponents including

Implementation (still standalone, not yet mapped to a specific ECU).The source or object code files are referred by the ImplementationDescription.

The Atomic Software Components that make up the delivery may ormay not form a composition (in the sense of the VFB).

Note that the VFB descriptions of the components, compositions andthe used interfaces are part of the deliverable too in order to describethe delivered components completely. However, depending on the usecase, these parts could have been predefined and were treated as"readonly" during the component development. The same holds(optionally) for the Internal Behavior(s).

In case of RTE generation a mapping set between Application andImplementation Data Types shall be included if Application Data Typesare used. A Timing Model is included optionally.

The delivery can optionally also contain variants (an Evaluated VariantSet and the related artifacts).

Kind DeliveredRelation Type Related Element Mul. NoteAggregates Application Header

File1..*

Aggregates Software Compo-nent Data TypesHeader

1..*

Aggregates VFB Atomic Soft-ware Component

1..*

Aggregates Alias Name Set 0..1 Alias names valid in the context of thedelivered components.

Aggregates Evaluated VariantSet

0..1

Aggregates Partial Flat Map 0..1Aggregates Postbuild Variant

Set0..1

Aggregates Atomic SoftwareComponent Imple-mentation

0..* If the delivery contains only VFB NvBlockSoftware Components, noimplementation is contained as the codeis generated as part of the RTE.

Aggregates Atomic SoftwareComponent ObjectCode

0..*

Aggregates Atomic Soft-ware ComponentSource Code

0..*

362 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 363: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates Component RTE

Prebuild Configu-ration Header

0..*

Aggregates ConsistencyNeeds

0..* Correlation between a group ofRunnableEntitys and a group ofDataPrototypes.

Aggregates Library ObjectCode

0..*

Aggregates Predefined Variant 0..*Aggregates Software Compo-

nent Documenta-tion

0..*

Aggregates Software Compo-nent Internal Be-havior

0..* If the delivery contains only VFB NvBlockSoftware Components, the InternalBehavior is optional since it is neededonly in special cases.

Aggregates Software Compo-nent Timing

0..*

Aggregates Software Compo-nent to BSW Map-ping

0..*

Aggregates System ConstantValue Set

0..*

Aggregates VFB CompositionComponent

0..* In case the delivered atomic componentsmake up one or more VFB Compositions,the composition description(s) shall beincluded in the delivery.

Aggregates VFB Data TypeMapping Set

0..*

Aggregates VFB Interfaces 0..*Aggregates VFB Modes 0..*Aggregates VFB Types 0..*Produced by Develop Applica-

tion Software1..*

Consumed by Configure RTE 1..* Required input:

• References to all componentimplementation descriptions onthis ECU

• SwcInternalBehavior (for exampleto map the runnables to tasks)which was used in the contractphase of the software componentson this ECU

363 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 364: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Generate RTE 1..* Required input:

• References to all componentimplementation descriptions onthis ECU

• SwcInternalBehavior which wasused in the contract phase of thesoftware components on this ECU

• (optional) Software Component toBSW Mapping

Meth.bindingTime = SystemDesignTimeConsumed by Integrate Software

for ECU1..*

Consumed by Define AliasNames

0..1 Needed for definition of alias names inthe scope of delivered softwarecomponents.

Consumed by Create MC Func-tion Model

0..* The component model may be used toderive an MC Function Model.

Table 3.195: Delivered Atomic Software Components

3.4.2.2 Software Component Internal Behavior

Artifact Software Component Internal BehaviorPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Description of the InternalBehavor: It describes the RTE relevant

aspects of a component, for example the runnable entities and theevents they respond to.

Description Description of the Internal Behavor. The Internal Behavior of an AtomicSoftware Component describes the RTE relevant aspects of acomponent, i.e. the runnable entities and the events they respond to. Itis used to generate the RTE but also as input for parts of the basicsoftware generation (AUTOSAR Services). The Internal Behavior (i.e.the XML description) can only be used together with an AtomicSoftware Component Type to which it is related.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..* If the delivery contains only VFB NvBlockSoftware Components, the InternalBehavior is optional since it is neededonly in special cases.

Produced by Define AtomicSoftware Com-ponent InternalBehavior

1

364 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 365: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Define Software

Component SafetyInformation

1

Consumed by Define SoftwareComponent Timing

1

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

1 Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Header File inVendor Mode

1 Meth.bindingTime = SystemDesignTime

Consumed by Generate Compo-nent Prebuild DataSet

1 Meth.bindingTime =CodeGenerationTime

Consumed by Generate RapidPrototyping Wrap-per

1

Consumed by Implement AtomicSoftware Compo-nent

1 Meth.bindingTime = SystemDesignTime

Consumed by Map SoftwareComponent to BSW

1

Consumed by Refine Rapid Pro-totyping Scenario

1

Consumed by Define Consis-tency Needs

1..* Runnables the consistency is defined for.

Consumed by Define Rapid Pro-totyping Scenario

1..*

Consumed by Select SoftwareComponent Imple-mentation

1..*

Consumed by Generate Local MC Data Support

0..1 Meth.bindingTime = SystemDesignTime

Consumed by Define Partial FlatMap

0..* Refer to parameter and variables definedin the Internal Behavior of one or moreAtomic Software Components.

Consumed by Define VFB NvBlock SoftwareComponent

0..* This input is required to collect therequirements for the NvBlockNeeds fromthe using application software.

Use meta model element SwcInternalBehav-ior

1

Table 3.196: Software Component Internal Behavior

3.4.2.3 Atomic Software Component Implementation

365 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 366: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Atomic Software Component ImplementationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Description of an implementation for a single Atomic Software

Component.Description Description of an implementation for a single Atomic Software

Component. It is possible to have several different implementations forthe same Software Component Internal Behavior, but only oneimplementation can be mapped to a particular ECU. In general, thisXML artifact relates to one particular version of the code. It containsthe version information as defined by the vendor.

An implementation description may depend on several non-AUTOSARartifacts, especially its own code files (source or object) but alsorequired libraries, generator tools etc. These dependencies are notdescribed by direct references to files (because this might beambiguous), but by referring entries in the container catalog of theGeneral Deliverable which contains the implementation artifacts. Sucha reference is described via the metamodel elementAutosarEngineeringObject (seeAUTOSAR_TPS_GenericStructureTemplate.pdf for furtherdescription). This allows among other things to refer to a particularversion of an artifact.

For more information on the content of the implmementationdescription refer toAUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..* If the delivery contains only VFB NvBlockSoftware Components, noimplementation is contained as the codeis generated as part of the RTE.

Produced by Create ServiceComponent

1 In order to generate the RTE, one needsto create a kind of dummyImplementation element for the ServiceComponent, however this should not befilled with descriptive elements, e.g.resource consumption, as these arealready defined by the Basic SoftwareModule Implementation Description.Meth.bindingTime = SystemDesignTime

Produced by Implement AtomicSoftware Compo-nent

1 Meth.bindingTime =CodeGenerationTime

Produced by Measure Re-sources

0..* Add extensions to the ImplementationDescription.Meth.bindingTime = PostBuild

In/out Measure Compo-nent Resources

1

Consumed by Generate Compo-nent Header File inVendor Mode

1 Meth.bindingTime = SystemDesignTime

366 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 367: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Generate SWC

Memory MappingHeader

1 MemorySections: MemorySectionsdefined for an Atomic SoftwareComponent.Meth.bindingTime = SystemDesignTime

Consumed by Select SoftwareComponent Imple-mentation

1..*

Consumed by ConfigureMemmap Allo-cation

0..* MemorySections:

Consumed by Generate CompilerConfiguration

0..* MemorySections: Find referredSwAddrMethods or specificmemClassSymbols in theMemorySections defined for AtomicSoftware Components.Meth.bindingTime = SystemDesignTime

Use meta model element Implementation 1

Table 3.197: Atomic Software Component Implementation

3.4.2.4 Software Component Documentation

Artifact Software Component DocumentationPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Documentation dedicated to a Software Component.Description Documentation of a dedicated Software Component. This

documentation is following the ASAM FSX standard. In thisdocumentation, you will find the SW Feature definition and descriptionwhich define the physical functionality of the Swc, the SW testdescription which will contains suggestions and hints for the test of thesoftware functionality of the Swc, the SW calibration notes which willgive calibration instructions and hints for a calibration engineer, somemaintenance, diagnosis and CARB notes which will bring generalinformation, on the maintenance diagnosis and CARB issues on theSwc. For other description not listed previously, some notes (chapters)are left free for that.

This artifact may also contain standalone documentation (meta-classDocumentation) not aggregeted by a specific software component.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

In/out Add Documenta-tion to the SoftwareComponent

1

Use meta model element Documentation 1Use meta model element SwComponent

Documentation1

367 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 368: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. Note

Table 3.198: Software Component Documentation

3.4.2.5 Software Component Timing

Artifact Software Component TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Software Component’s TimingDescription and TimingConstraintsDescription TimingDescription and TimingConstraints of a software component. A

software component can either be of type AtomicSWComponentTypeor CompositionSWComponentType.

In the former case, the SwcTiming allows to describe timing descriptionand constraints for the InternalBehavior of theAtomicSWComponentType.

In the latter case, timing descriptions and constraints can be defined forall Atomic Software Components in theCompositionSWComponentType.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Produced by Define SoftwareComponent Timing

1

Consumed by Define SystemTiming

0..1

Consumed by Implement AtomicSoftware Compo-nent

0..1 Meth.bindingTime = SystemDesignTime

Consumed by Measure Compo-nent Resources

0..1

Use meta model element SwcTiming 1

Table 3.199: Software Component Timing

3.4.2.6 Software Component to BSW Mapping

368 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 369: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Software Component to BSW MappingPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Desribes how to map a software component to basic software

elements (required in special cases only).Description Maps an SwcInternalBehavior to an BswInternalBehavior. This is

required to coordinate the API generation and the scheduling forAUTOSAR Service Components, ECU Abstraction Components andComplex Driver Components by the RTE and the BSW schedulingmechanisms.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Produced by Map SoftwareComponent to BSW

1

Produced by Create ServiceComponent

0..1 Meth.bindingTime = SystemDesignTime

Consumed by Generate AtomicSoftware Com-ponent ContractHeader Files

0..1 If a Software Component is mapped to aBSW module description, this input isoptionally needed already in the contractphase in order to ensure that thegenerated prototypes for runnables areconsistent with the definitions inSoftware Component and BSW.Meth.bindingTime = SystemDesignTime

Consumed by Generate RTE 0..* This input is explicitly stated because themapping may be created during ECUintegration and thus is not necessarilypart of the Delivered Atomic SoftwareComponents.Meth.bindingTime = SystemDesignTime

Use meta model element SwcBswMapping 1

Table 3.200: Software Component to BSW Mapping

3.4.2.7 Partial Flat Map

369 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 370: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Partial Flat MapPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief DescriptionDescription The Partial Flat Map pre-defines Flat Map entries in the context of

delivered software components. This allows the component developerto specify names of data instances for measurement and calibration. Ithas to be integrated into the System Flat Map.

For more information on the Flat Map concept refer to artifact SystemFlat Map in the system domain.

Kind AUTOSAR XMLRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..1

Produced by Define Partial FlatMap

1

Consumed by Add Documenta-tion to the SoftwareComponent

0..1 Optional input in order to refer to uniquenames defined in component orcomposition context.

Consumed by Generate or AdjustECU Flat Map

0..* If Partial Flat Maps were delivered alongwith software components referring onlyto ECU internal information, they may beintegrated into the ECU Flat Map directly,i.e. without needing the System FlatMap.

• The instance refs used in a partialflat map must be taken over andadjusted to the context ECUExtract.

• Name conflicts have to beresolved if several partial flatmaps are merged.

Consumed by Generate or AdjustSystem Flat Map

0..* If Partial Flat Maps were delivered alongwith software components, they must beintegrated into the System Flat Map:

• The instance refs used in a partialflat map must be taken over andadjusted to the context of theSystem or System Extract.

• Name conflicts have to beresolved if several partial flatmaps are merged.

Use meta model element FlatMap 1

Table 3.201: Partial Flat Map

370 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 371: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.4.2.8 Application Header File

Artifact Application Header FilePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Header generated for an AtomicSoftwareComponentType in the RTE

contract phase.Description Header generated for an AtomicSoftwareComponentType in the RTE

contract phase. It represents the complete source-code interfacebetween the component code and RTE (calls into the RTE as well asprototypes called by the RTE). All communication of the componentcode with other components is routed through this header.

Kind Source CodeRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

1..*

Produced by Generate AtomicSoftware Com-ponent ContractHeader Files

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile AtomicSoftware Compo-nent

1 Meth.bindingTime =CodeGenerationTime

Consumed by Implement AtomicSoftware Compo-nent

1 Meth.bindingTime = SystemDesignTime

Consumed by Compile ECUSource Code

1..* Meth.bindingTime =CodeGenerationTime

Table 3.202: Application Header File

3.4.2.9 Software Component Data Types Header

Artifact Software Component Data Types HeaderPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Software Component Data Types Header provided by the RTE in the

contract phase.Description Software Component Data Types Header provided by the RTE in the

contract phase. This includes data types, which were declared as partof the SWC description but not used in any ports or data elements.

Kind Source CodeRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

1..*

371 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 372: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduced by Generate Atomic

Software Com-ponent ContractHeader Files

1 Meth.bindingTime =CodeGenerationTime

Produced by Generate Compo-nent Header File inVendor Mode

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile AtomicSoftware Compo-nent

1 Meth.bindingTime =CodeGenerationTime

Consumed by Implement AtomicSoftware Compo-nent

1 Meth.bindingTime = SystemDesignTime

Consumed by Compile ECUSource Code

0..* Meth.bindingTime =CodeGenerationTime

Table 3.203: Software Component Data Types Header

3.4.2.10 Component RTE Prebuild Configuration Header

Artifact Component RTE Prebuild Configuration HeaderPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Generated header file used to resolve the prebuild variants in the

prebuild RTE contract phase for an SWC.Description Generated header file used to resolve the prebuild variants of a

software component in the prebuild RTE contract phase. Containsmacros which resolve the variants when compiled with the module andthe generated RTE.

Kind Bound Source CodeRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Produced by Generate Compo-nent Prebuild DataSet

1 Meth.bindingTime = PreCompileTime

Consumed by Compile AtomicSoftware Compo-nent

0..1 Meth.bindingTime = PreCompileTime

Consumed by Compile ECUSource Code

0..* Meth.bindingTime =CodeGenerationTime

Table 3.204: Component RTE Prebuild Configuration Header

3.4.2.11 Atomic Software Component Source Code

372 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 373: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Atomic Software Component Source CodePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Source code implementing an Atomic Software Component TypeDescription Source code implementing an Atomic Software Component Type. In

general it is independent from an ECU.Kind Source CodeRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Produced by Implement AtomicSoftware Compo-nent

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile AtomicSoftware Compo-nent

1 Meth.bindingTime =CodeGenerationTime

Consumed by Re-compile Com-ponent in ECUcontext

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile ECUSource Code

0..* Meth.bindingTime =CodeGenerationTime

Table 3.205: Atomic Software Component Source Code

3.4.2.12 Atomic Software Component Object Code

Artifact Atomic Software Component Object CodePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief DescriptionDescription Object Code of an Atomic Software Component.Kind Object CodeRelation Type Related Element Mul. NoteAggregated by Delivered Atomic

Software Compo-nents

0..*

Produced by Compile AtomicSoftware Compo-nent

1 The object file should include both codeof the SWC and the E2E ProtectionWrapper code (if present as an input).Meth.bindingTime = CompileTime

Consumed by Measure Compo-nent Resources

1

Consumed by Generate ECU Ex-ecutable

0..* Meth.bindingTime = CompileTime

Table 3.206: Atomic Software Component Object Code

3.4.2.13 Optimized Application Header File

373 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 374: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Optimized Application Header FilePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description Optimized application header file for a software component.Description Application header file for a software component optimized by the RTE

in vendor mode.Kind Source CodeRelation Type Related Element Mul. NoteProduced by Generate Compo-

nent Header File inVendor Mode

1 Meth.bindingTime =CodeGenerationTime

Consumed by Re-compile Com-ponent in ECUcontext

1 Meth.bindingTime =CodeGenerationTime

Consumed by Compile ECUSource Code

0..* Meth.bindingTime =CodeGenerationTime

Table 3.207: Optimized Application Header File

3.4.2.14 Optimized Software Component Object Code

Artifact Optimized Software Component Object CodePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief Description The object code of a software component compiled with ECU specific

optimizations.Description The object code of a software component compiled with ECU specific

optimizations.Kind Object CodeRelation Type Related Element Mul. NoteProduced by Re-compile Com-

ponent in ECUcontext

1 Meth.bindingTime = CompileTime

Table 3.208: Optimized Software Component Object Code

3.4.2.15 Consistency Needs

374 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 375: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Artifact Consistency NeedsPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief DescriptionDescription A ConsistencyNeed describes the correlation between a group of

RunnableEntitys and a group of DataPrototypes with the intendedpurpose to describe the need for

• Stable data during the execution of a group of RunnableEntitys.

• Coherent data consumption and propagation for a group ofDataPrototypes.

The information can be defined first time at the design of an AtomicSoftware Component but can be added as well if Compositions arecreated. In order to allow incremental development the groups ofRunnables and DataPrototypes can be distributed over severalartifacts.

KindRelation Type Related Element Mul. NoteAggregated by VFB System 1 Correlation between a group of

RunnableEntitys and a group ofDataPrototypes.

Aggregated by Delivered AtomicSoftware Compo-nents

0..* Correlation between a group ofRunnableEntitys and a group ofDataPrototypes.

In/out Define Consis-tency Needs

1 The description of the correlationbetween a group of RunnableEntitys anda group of DataPrototypes. In order toallow incremental development andrefinement the Consistency Needsartifact is also used as an input.

Use meta model element ConsistencyNeeds 1

Table 3.209: Consistency Needs

3.4.2.16 Rapid Prototyping Wrapper Header File

Artifact Rapid Prototyping Wrapper Header FilePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief DescriptionDescription This header replaces the RTE API in order to allow to read and modify

inputs and outputs of the original SWC as well as to control executionof the original (and prototype) runnable.

Kind Source CodeRelation Type Related Element Mul. NoteProduced by Generate Rapid

Prototyping Wrap-per

1

375 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 376: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumed by Compile Atomic

Software Compo-nent

0..1

Table 3.210: Rapid Prototyping Wrapper Header File

3.4.2.17 Rapid Prototyping Wrapper Source Code

Artifact Rapid Prototyping Wrapper Source CodePackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

Work ProductsBrief DescriptionDescription A piece of code that is placed between software components and the

RTE in order to provide rapid prototyping functionality. This code allowsto encapsulate the SWC to bypass into the rapid prototypingcomponent and may be implemented ad as a complex device driverand/or integration code.

Kind Source CodeRelation Type Related Element Mul. NoteProduced by Generate Rapid

Prototyping Wrap-per

1

Consumed by Compile AtomicSoftware Compo-nent

0..1

Table 3.211: Rapid Prototyping Wrapper Source Code

3.4.3 Tools

3.4.3.1 Component API Generator Tool

376 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 377: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Tool Component API Generator ToolPackage AUTOSAR Root::M2::Methodology::Methodology Library::Component::

GuidanceBrief Description Generates the software component contract header used to connect

the software component to the RTE layer.Description This guidance represents the so-called contract phase of the RTE

generation process.

• SWC Contract phase - a limited set of information about acomponent, principally the AUTOSAR Interface definitions andthe internal behavior, is used to create an application header filefor a component type. The application header file defines the"contract" between component and RTE.

• BSW Contract phase - a similar use case for a BSW module inorder to generate the module interlink header files, which areused to interface between the module and the BSW Scheduler.

• Additional phases - for SWS and BSW as well - are used to bindpre-build variants in the contract headers of a single SoftwareComponent or BSW module.

KindRelation Type Related Element Mul. NoteUsed Generate Atomic

Software Com-ponent ContractHeader Files

1

Used Generate BSWModule PrebuildData Set

1

Used Generate BSWMContract HeaderFiles

1

Used Generate Compo-nent Header File inVendor Mode

1

Used Generate Compo-nent Prebuild DataSet

1

Table 3.212: Component API Generator Tool

3.5 Basic Software

This chapter contains the definition of work products and tasks used for the develop-ment of Basic Software modules. For the definition of the relevant meta-model ele-ments refer to [8].

377 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 378: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1 Tasks

3.5.1.1 Define BSW Types

Define BSW TypesBSW Standard Package

BSW Types

Basic Software Designer Basic Software Module Developer

«performs»

0..1

«performs»

1

«inoutput» «input»0..1

Figure 3.104: Define BSW Types

Task Definition Define BSW TypesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Define data types for usage within the Basic Software.Description A data type is typically based on elements standardized by AUTOSAR,

therefore BSW Standard Package appears as a mandatory input.Relation Type Related Element Mul. NotePerformed by Basic Software De-

signer1

Performed by Basic SoftwareModule Developer

1

Consumes BSW StandardPackage

0..1

In/out BSW Types 1

Table 3.213: Define BSW Types

378 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 379: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.2 Define BSW Entries

Define BSW Entries

BSW Types

BSW Standard Package

Basic Software Entries

Basic Software Designer

Basic Software Module Developer

«input»

1

«output» 1

«input»

0..1

«performs»

0..1

«performs»

1

Figure 3.105: Define BSW Entries

Task Definition Define BSW EntriesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Define BswEntries (= function signatures) for usage within the Basic

Software.DescriptionRelation Type Related Element Mul. NotePerformed by Basic Software De-

signer1

Performed by Basic SoftwareModule Developer

1

Consumes BSW Types 1Consumes BSW Standard

Package0..1

Produces Basic Software En-tries

1

Table 3.214: Define BSW Entries

379 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 380: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.3 Define BSW Interfaces

Define BSW InterfacesBSW Standard Package

BSW Types

Basic Software Entries

ECU Resources Description

Basic Software Module Description

Basic Software Designer

Basic Software Module Developer

«input»0..1

«performs»

1

«performs»

0..1

«input»

1

«input»

0..1

«output» 1

«input»

1

Figure 3.106: Define BSW Interfaces

Task Definition Define BSW InterfacesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Define the interfaces for a single BSW Module.Description Define the interfaces for a particular BSW Module or cluster as part of

the BSW Module Description. This includes an abstraction of therequired and provided C-functions, as well as triggers and modes.Note that this task also exists for modules standardized by AUTOSAR,as it may be required to decide on optional or alternative elements andto add allowed project specific extensions.

Relation Type Related Element Mul. NotePerformed by Basic Software De-

signer1

Performed by Basic SoftwareModule Developer

1

Consumes BSW Types 1Consumes Basic Software En-

tries1

Consumes BSW StandardPackage

0..1

Consumes ECU ResourcesDescription

0..1

380 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 381: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces Basic Software

Module Descrip-tion

1

Table 3.215: Define BSW Interfaces

3.5.1.4 Define Vendor Specific Module Definition

Define Vendor Specific Module Definition

BSW Module Vendor- Specific Configuration Parameter Definition

AUTOSAR Standardized ECU Configuration Parameter Definition

Basic Software Designer

Basic Software Module Developer

«output» 1

0..1

«performs»

0..1

«performs»

1 «input»

Figure 3.107: Define Vendor Specific Module Definition

Task Definition Define Vendor Specific Module DefinitionPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief DescriptionDescription Define the Vendor Specific Module Definition (=Configuration

Parameters).Relation Type Related Element Mul. NotePerformed by Basic Software De-

signer0..1

Performed by Basic SoftwareModule Developer

0..1

Consumes AUTOSAR Stan-dardized ECUConfiguration Pa-rameter Definition

1

Produces BSW ModuleVendor- SpecificConfiguration Pa-rameter Definition

1

Table 3.216: Define Vendor Specific Module Definition

381 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 382: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.5 Define BSW Behavior

Define BSW Behavior

Basic Software Module Description

BSW Standard Package

Basic Software Module Internal Behavior

Basic Software Designer

«performs»

1

«output» 1

«input»

1

«input»

0..1

Figure 3.108: Define BSW Behavior

Task Definition Define BSW BehaviorPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Define the BSW Behavior related to a BSW Module Description.Description Define the BSW Behavior related to a BSW Module Description. This

task is required during BSW module development in order to be able togenerate the API to the BSW Scheduler. In addition, local data(variables or parameters) may be defined during this task in order touse the AUTOSAR data type system for module local data and togenerate measurement & calibration support.

Relation Type Related Element Mul. NotePerformed by Basic Software De-

signer1

Consumes Basic SoftwareModule Descrip-tion

1

Consumes BSW StandardPackage

0..1

Produces Basic SoftwareModule InternalBehavior

1

Table 3.217: Define BSW Behavior

382 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 383: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.6 Define BSW Module Timing

Basic Software Module Internal Behavior

Basic Software Module Timing

Basic Software Module Developer

Define BSW Module Timing

«performs»

1

«output» 1 «input»1

Figure 3.109: Define BSW Module Timing

Task Definition Define BSW Module TimingPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Define BSWModuleTiming (TimingDescription and TimingConstraints)

for the Internal Behavior (BSWModuleEntities) of a BSW moduleDescription Define BSWModuleTiming (TimingDescription and TimingConstraints)

for the Internal Behavior (BSWModuleEntities) of a BSW moduleRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Consumes Basic SoftwareModule InternalBehavior

1

Produces Basic SoftwareModule Timing

1

Table 3.218: Define BSW Module Timing

383 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 384: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.7 Generate BSW Contract Header Files

Generate BSWM Contract Header Files

Basic Software Module Internal Behavior

Basic Software Module Description

Basic Software Module Implementation Description

BSW Standard Package

Basic Software Module Interl ink Header

Basic Software Interl ink Types Header

Basic Software Module Developer

Component API Generator Tool

«output»

1

«used tool»

«input»1

«input»

1

«output» 1

«input»

0..1

«performs»

1

«input»

1

Figure 3.110: Generate BSW Contract Header Files

Task Definition Generate BSWM Contract Header FilesPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Generate Basic Softwaree Module Contract Header FilesDescription Generate the header files needed for a BSW module as part of the

so-called "contract phase". These headers will allow to link the modulelateron with the RTE (namely the BSW Scheduler).

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Consumes Basic SoftwareModule Descrip-tion

1 Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule Implemen-tation Description

1 Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule InternalBehavior

1 Meth.bindingTime = SystemDesignTime

Consumes BSW StandardPackage

0..1

384 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 385: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces Basic Software

Interlink TypesHeader

1 Meth.bindingTime =CodeGenerationTime

Produces Basic SoftwareModule InterlinkHeader

1 Meth.bindingTime =CodeGenerationTime

Used tool Component APIGenerator Tool

1

Table 3.219: Generate BSWM Contract Header Files

3.5.1.8 Implement a BSW Module

Implement a BSW Module

Basic Software Module Internal Behavior

Basic Software Module Description

Basic Software Module Interl ink Header

Basic Software Interl ink Types Header

BSW Standard Package

Basic Software Module Timing

Library Header Files

ECU Resources Description

Basic Software Module Core Header

Basic Software Module Core Source Code

Basic Software Module Implementation Description

Standard Header Files

Basic Software Module Developer

Build Action Manifest

«input»1

«input»

1

«input»

0..1

«input»

0..1

«input»

1

«output»

1

«input»

0..1

«input»

1

«performs»

1

«input»

0..1

«output»

0..1

«input»

1

«output»

1

«output»0..1

Figure 3.111: Implement a BSW Module

385 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 386: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Implement a BSW ModulePackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Implement the source code of a BSW module.Description Implement the source code of a BSW module. This task is not

described by AUTOSAR completely, but included for completeness ofthe AUTOSAR use cases. Note that specification of an AUTOSARstandard module imposes several requirements, e.g. the inclusion ofcertain header files, onto this task.

In addition to the code, this task also produces the necessary XMLdescriptions.

Optionally, a build action manifest may be created or modified in orderto be used for code generation or further processing of the code.

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Consumes Basic SoftwareInterlink TypesHeader

1 Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule Descrip-tion

1 Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule InterlinkHeader

1 Meth.bindingTime = SystemDesignTime

Consumes Basic SoftwareModule InternalBehavior

1 Meth.bindingTime = SystemDesignTime

Consumes Standard HeaderFiles

1 Meth.bindingTime =CodeGenerationTime

Consumes BSW StandardPackage

0..1

Consumes Basic SoftwareModule Timing

0..1 Meth.bindingTime = SystemDesignTime

Consumes ECU ResourcesDescription

0..1 Meth.bindingTime = SystemDesignTime

Consumes Library HeaderFiles

0..1 Meth.bindingTime =CodeGenerationTime

Produces Basic SoftwareModule CoreHeader

1 Meth.bindingTime =CodeGenerationTime

Produces Basic SoftwareModule Implemen-tation Description

1 Meth.bindingTime =CodeGenerationTime

386 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 387: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces Basic Software

Module CoreSource Code

0..1 The creation of source code is optional,since it might be generated completely ina later step based on the Build ActionManifest.Meth.bindingTime =CodeGenerationTime

Produces Build Action Mani-fest

0..1

Table 3.220: Implement a BSW Module

3.5.1.9 Develop BSW Module Generator

BSW Module Generator

Develop BSW Module Generator

BSW Standard Package

Basic Software Module Developer

BSW Module Vendor- Specific Configuration Parameter Definition

«output» 1

1

«input»

0..*

«input»

«performs»

Figure 3.112: Develop BSW Module Generator

Task Definition Develop BSW Module GeneratorPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief DescriptionDescription Develop a generator for one or more BSW modules.Relation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Consumes BSW StandardPackage

1

Consumes BSW ModuleVendor- SpecificConfiguration Pa-rameter Definition

0..*

Produces BSW Module Gen-erator

1

Table 3.221: Develop BSW Module Generator

387 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 388: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.10 Create Library

Create Library

Basic Software Module Internal Behavior

Library Description

Library Header Files

Library Object Code

Basic Software Module Developer

ECU Integrator

Basic Software Module Implementation Description

BSW Standard Package

1

«input»

«performs»

0..1

«performs»

1

«output»

1

«output»

1

«output»

1

«output»

1

«output» 1

Figure 3.113: Create Library

Task Definition Create LibraryPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Create a library to be used within an Autosar ECU.Description Create a non-standardized library to be used within an Autosar ECU.

The task is the same for the basic software and application level, but itis considered as a basic software task because no VFB resp. RTEabstraction is used. The output includes source code, header file andXML descriptions of the interfaces and of the implementation. A"dummy" BSW Behavior must be created too in order to be able to linkthe other two XML artifacts.

Meth.bindingTime = CodeGenerationTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Performed by ECU Integrator 1Consumes BSW Standard

Package1 Used for standard types and

specifications.

388 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 389: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteProduces Basic Software

Module Implemen-tation Description

1 Meth.bindingTime =CodeGenerationTime

Produces Basic SoftwareModule InternalBehavior

1 Meth.bindingTime =CodeGenerationTime

Produces Library Description 1 Meth.bindingTime =CodeGenerationTime

Produces Library HeaderFiles

1 Meth.bindingTime =CodeGenerationTime

Produces Library ObjectCode

1 Meth.bindingTime =CodeGenerationTime

Table 3.222: Create Library

3.5.1.11 Compile BSW Core Code

Compile BSW Core Code

Basic Software Module Core Header

Basic Software Module Interl ink Header

Basic Software Interl ink Types Header

BSW RTE Prebuild Configuration Header

Basic Software Module Object Code

Library Header Files Basic Software

Module Developer

Standard Header Files

Compiler

Basic Software Module Core Source Code

Build Action Manifest

«output»1 «input»

1

«input»

1

«used tool»

«input»

1

«input»

1

«input»

0..1

1

«input»

«input»

0..1

«input»

«performs»

Figure 3.114: Compile BSW Core Code

389 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 390: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Task Definition Compile BSW Core CodePackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Compile the source code of a BSW modue without ECU specific

configurations.Description Compile the source code of a BSW modue without ECU specific

configurations. This task is mainly used to describe the use cases ofBSW development for object code delivery. The output will onlyrepresent the "core code". During ECU integration, additionalgenerated code may be added per module in response to ECUconfiguration.

Meth.bindingTime = CompileTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Consumes BSW RTE Pre-build ConfigurationHeader

1 Meth.bindingTime = PreCompileTime

Consumes BSW Types 1 Meth.bindingTime =CodeGenerationTime

Consumes Basic SoftwareInterlink TypesHeader

1 Meth.bindingTime =CodeGenerationTime

Consumes Basic SoftwareModule CoreHeader

1 Meth.bindingTime =CodeGenerationTime

Consumes Basic SoftwareModule CoreSource Code

1 Meth.bindingTime =CodeGenerationTime

Consumes Basic SoftwareModule InterlinkHeader

1 Meth.bindingTime =CodeGenerationTime

Consumes Standard HeaderFiles

1 Meth.bindingTime =CodeGenerationTime

Consumes Build Action Mani-fest

0..1 The compilation can optionally becontrolled by a Build Action Manifest.

Consumes Library HeaderFiles

0..1 Meth.bindingTime =CodeGenerationTime

Produces Basic SoftwareModule ObjectCode

1 Meth.bindingTime = CompileTime

Used tool Compiler 1

Table 3.223: Compile BSW Core Code

390 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 391: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.1.12 Generate BSW Module Prebuild Dataset

Generate BSW Module Prebuild Data Set

Basic Software Module Description

Basic Software Module Internal Behavior

Basic Software Module Implementation Description

BSW RTE Prebuild Configuration Header

BSW Standard Package

Predefined Variant

Basic Software Module Developer

Component API Generator Tool

System Constant Value Set

«input»

1

«input»

0..1

«performs»

1

«input»

«input»

1

«input»1

«used tool»

«output» 1

«input»

1

Figure 3.115: Generate BSW Module Prebuild Dataset

Task Definition Generate BSW Module Prebuild Data SetPackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::TasksBrief Description Prebuild Data Set Generation Phase for a BSW module: It binds all

variations which need to be set after generation of the RTE contractheader but before compilation of the module.

Description Prebuild Data Set Generation Phase for a basic software module: Itbinds all variations which need to be set after generation of the RTEcontract header but before compilation of the module. The variantsettings must be defined by the PredefinedVariant given as input.

The output is a BSW Module RTE Prebuild Configuration Header whichis included by the corresponding BSW Module Interlink Header,thereby resolving the variation points when compiled. Note that linktime variants are not allowed here.

Meth.bindingTime = PreCompileTimeRelation Type Related Element Mul. NotePerformed by Basic Software

Module Developer1

Consumes Basic SoftwareModule Descrip-tion

1 Meth.bindingTime =CodeGenerationTime

391 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 392: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteConsumes Basic Software

Module Implemen-tation Description

1 Meth.bindingTime =CodeGenerationTime

Consumes Basic SoftwareModule InternalBehavior

1 Meth.bindingTime =CodeGenerationTime

Consumes Predefined Variant 1Consumes System Constant

Value Set1

Consumes BSW StandardPackage

0..1

Produces BSW RTE Pre-build ConfigurationHeader

1 Meth.bindingTime = PreCompileTime

Used tool Component APIGenerator Tool

1

Table 3.224: Generate BSW Module Prebuild Data Set

3.5.2 Work Products

3.5.2.1 BSW Standard Package

BSW Standard Package

AUTOSAR Standardized ECU Configuration Parameter Definition

AUTOSAR Standard Types

AUTOSAR Platform Types

AUTOSAR Software Module Specification

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

1

«SPEM_Aggregation»

*

«SPEM_Aggregation»

Figure 3.116: BSW Standard Package

392 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 393: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Deliverable BSW Standard PackagePackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::Work

productsBrief Description Package containing standard artifacts for BSW.Description Contains the standard specifications and standard ARXML artifacts to

be used within the AUTOSAR basic software and for the generation ofthe RTE.

This deliverable is released by AUTOSAR and is readonly within themethodology.

Kind DeliveredRelation Type Related Element Mul. NoteAggregates AUTOSAR Plat-

form Types1

Aggregates AUTOSAR Stan-dard Types

1

Aggregates AUTOSAR Stan-dardized ECUConfiguration Pa-rameter Definition

1

Aggregates AUTOSAR Soft-ware ModuleSpecification

0..*

Consumed by Create Library 1 Used for standard types andspecifications.

Consumed by Design Basic Soft-ware

1

Consumed by Develop BSWModule

1

Consumed by Develop BSWModule Generator

1

Consumed by Develop BasicSoftware

1

Consumed by Define BSW Be-havior

0..1

Consumed by Define BSW En-tries

0..1

Consumed by Define BSW Inter-faces

0..1

Consumed by Define BSW Types 0..1Consumed by Generate BSW

Module PrebuildData Set

0..1

Consumed by Generate BSWMContract HeaderFiles

0..1

Consumed by Implement a BSWModule

0..1

Table 3.225: BSW Standard Package

393 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 394: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.2.2 BSW Module Bundle

BSW Module Bundle

BSW Module ICSBundle

BSW Module Integration Bundle

Basic Software Module Description

Basic Software Module Timing

Basic Software Entries

BSW Types

BSW Module Delivered Bundle

BSW Design Bundle

BSW Module Vendor- Specific Configuration Parameter Definition

«extends»

1..*

«SPEM_Aggregation»

«extends»

0..*

«SPEM_Aggregation»

0..1

«SPEM_Aggregation»

«extends»

«extends»

0..1

«SPEM_Aggregation»

0..*

«SPEM_Aggregation»

Figure 3.117: BSW Module Bundle

Deliverable BSW Module BundlePackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::Work

productsBrief DescriptionDescription Generic deliverable representing a bundle of one or more BSW

modules. It is used as a basis for extended deliverables.

The deliverable aggregates the ARXML definitions on the interfacelevel including vendor specific configuration parameter definition.

According to the role of the extended deliverable, these elementsmaybe blueprints completely or partially. .

Kind DeliveredExtended by BSW Design Bundle, BSW Module Delivered Bundle, BSW Module IC

S BundleRelation Type Related Element Mul. NoteAggregates Basic Software

Module Descrip-tion

1..*

Aggregates Basic Software En-tries

0..1

Aggregates Basic SoftwareModule Timing

0..1

394 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 395: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

Relation Type Related Element Mul. NoteAggregates BSW Module

Vendor- SpecificConfiguration Pa-rameter Definition

0..* The configuration parameter definitionsof the modules under test - needed forstatic check against the standardizedconfiguration parameters.

Aggregates BSW Types 0..*

Table 3.226: BSW Module Bundle

3.5.2.3 BSW Design Bundle

Deliverable BSW Design BundlePackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::Work

productsBrief DescriptionDescription A bundle of one or more BSW modules used in the design phase.

It contains only definitions on the interface level. These elementsmaybe blueprints completely or partially.

Kind DeliveredExtends BSW Module BundleRelation Type Related Element Mul. NoteProduced by Design Basic Soft-

ware1..*

Consumed by Develop BSWModule

1..*

Table 3.227: BSW Design Bundle

395 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 396: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.2.4 BSW Module ICS Bundle

BSW Module Bundle

Basic Software Module Implementation Description

BSW Module Preconfigured Configuration

Basic Software Module Object Code

BSW Module ICS Bundle

«extends»

0..*

«SPEM_Aggregation»

1

«SPEM_Aggregation»

1..*

«SPEM_Aggregation»

Figure 3.118: BSW Module ICS Bundle

Deliverable BSW Module ICS BundlePackage AUTOSAR Root::M2::Methodology::Methodology Library::Bsw::Work

productsBrief DescriptionDescription Deliverable containing the Implementation Conformance Statement

(ICS) for one or more BSW modules.Kind DeliveredExtends BSW Module BundleRelation Type Related Element Mul. NoteAggregates Basic Software

Module Implemen-tation Description

1 The administrative elements (e.g.version info) of the Implementationmodel needed for the conformance test.

Aggregates Basic SoftwareModule ObjectCode

1..*

Aggregates BSW Module Pre-configured Config-uration

0..* The predefined configurationsimplemented by the modules under test.The modules under test are completelyconfigured.

Table 3.228: BSW Module ICS Bundle

396 of 503— AUTOSAR CONFIDENTIAL —

Document ID 068: AUTOSAR_TR_Methodology

Page 397: Document Title Methodology - AUTOSAR · Methodology AUTOSAR Release 4.2.2 Document Title Methodology Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification

MethodologyAUTOSAR Release 4.2.2

3.5.2.5 BSW Module Delivered Bundle

BSW Module Delivered Bundle

BSW Module Bundle

BSW Module Integration Bundle

Basic Software Module Internal Behavior

Basic Software Module Core Header

Basic Software Module Implementation Description

Basic Software Module Interl ink Header

BSW RTE Prebuild Configuration Header

Basic Software Interl ink Types Header

Basic Software Module Core Source Code

Basic Software Module Object Code

BSW Mo