Requirements on Methodology for Classic and

Adaptive Platform
AUTOSAR FO R23-11

Requirements on Methodology
Document Title for Classic and Adaptive Platform
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 362

Document Status published

Part of AUTOSAR Standard Foundation
Part of Standard Release R23-11

Document Change History

Date Release Changed by Description
AUTOSAR • No content changes
2023-11-23 R23-11 Release • Editorial changes - fix uptraces to
Management removed main requirements
AUTOSAR
2022-11-24 R22-11 Release • No content changes
Management
AUTOSAR
2021-11-25 R21-11 Release • No content changes
Management
AUTOSAR
2020-11-30 R20-11 Release • Editorial changes
Management
AUTOSAR • No content changes
2019-11-28 R19-11 Release • Changed Document Status from Final to
Management published
AUTOSAR
2019-03-29 1.5.1 Release • No content changes
Management
AUTOSAR
• scope of some requirements extended
2018-10-31 1.5.0 Release
(from CP to CP+AP)
Management
AUTOSAR
2018-03-29 1.4.0 Release • No content changes
Management
5

1 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
• Migration of the Classic Platform
requirements document to standard
“Foundation” finalized
AUTOSAR • Enhanced quality of requirements
2017-12-08 1.3.0 Release
Management • New requirement added which applies to
both platforms

• New requirement for Classic Platform

only added
AUTOSAR
• Enhanced formal quality of requirements
2017-10-27 1.2.0 Release
and requirements tracing
Management
• – Migration of document to standard
“Foundation” –
AUTOSAR • Only those requirements from Classic
2017-03-31 1.1.0 Release Platform incorporated which apply to
Management Adaptive Platform as well

• New requirements for Adaptive Platform

added

2 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

Disclaimer

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

3 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

Contents
1 Introduction 8
1.1 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Requirements Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Methodology Requirements 10
2.1 General Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Main Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
[RS_METH_00006] The methodology shall explain how to build an
AUTOSAR system . . . . . . . . . . . . . . . . . . . . 10
[RS_METH_00041] The methodology shall support top-down and
bottom-up approaches . . . . . . . . . . . . . . . . . . 10
[RS_METH_00016] The methodology shall support building a sys-
tem of both AUTOSAR and Non-AUTOSAR ECUs . . . 11
[RS_METH_00200] The methodology shall support building a sys-
tem consisting of several AUTOSAR platforms . . . . 11
[RS_METH_00208] The methodology shall support the data ex-
change between different stakeholders . . . . . . . . . 12
[RS_METH_00018] The methodology shall be modular . . . . . . . 12
[RS_METH_00032] The methodology shall support different ab-
straction levels . . . . . . . . . . . . . . . . . . . . . . 13
[RS_METH_00020] The methodology shall support round-trip en-
gineering . . . . . . . . . . . . . . . . . . . . . . . . . 13
[RS_METH_00077] The methodology shall support different views
on the SW-C structure by OEMs and suppliers . . . . . 13
[RS_METH_00078] The methodology shall explain the typical us-
age of different views on the system of the OEM . . . . 14
[RS_METH_00079] The methodology shall explain the typical us-
age of different views on the system of the supplier . . 14
2.1.2 Programming Language . . . . . . . . . . . . . . . . . . . . . . 15
[RS_METH_00015] The methodology shall be independent of pro-
gramming languages . . . . . . . . . . . . . . . . . . . 15
2.1.3 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
[RS_METH_00066] The methodology shall allow activities that ref-
erence tools . . . . . . . . . . . . . . . . . . . . . . . . 16
[RS_METH_00042] The methodology shall incorporate the usage
of industry standard tools . . . . . . . . . . . . . . . . 16
2.1.4 Process Requirements . . . . . . . . . . . . . . . . . . . . . . 16
[RS_METH_00056] The AUTOSAR methodology shall not be
bound to a particular life-cycle model . . . . . . . . . . 16
[RS_METH_00069] It shall be possible to add precise and human
readable documentation to each work product . . . . . 17
2.1.5 Variant Handling Requirements . . . . . . . . . . . . . . . . . . 17

4 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00062] The methodology shall support configuration

of parameters with different binding time. . . . . . . . . 17
[RS_METH_00074] The methodology shall specify binding times . . 18
[RS_METH_00075] The methodology shall specify the tasks of re-
solving variant . . . . . . . . . . . . . . . . . . . . . . 18
[RS_METH_00076] The methodology shall specify a work product
for values of variant selectors . . . . . . . . . . . . . . 18
2.2 Requirements for the Classic Platform . . . . . . . . . . . . . . . . . . . 19
2.2.1 General Requirements . . . . . . . . . . . . . . . . . . . . . . 19
[RS_METH_00033] The methodology should support the VFB concept19
[RS_METH_00080] The AUTOSAR methodology shall support the
concept of implicit communication behavior . . . . . . 19
[RS_METH_00083] The AUTOSAR methodology shall explain the
description and handling of Data Exchange Points . . 20
[RS_METH_00084] The AUTOSAR methodology shall relate tem-
plates to a distributed development process . . . . . . 20
2.3 Requirements for the Adaptive Platform . . . . . . . . . . . . . . . . . . 21
2.3.1 Main Requirements . . . . . . . . . . . . . . . . . . . . . . . . 21
[RS_METH_00201] The methodology shall explain how to design
the services of a system . . . . . . . . . . . . . . . . . 21
[RS_METH_00206] The methodology shall explain how to config-
ure the instances of services of a system . . . . . . . 21
[RS_METH_00202] The methodology shall explain how to develop
an Adaptive Application . . . . . . . . . . . . . . . . . 22
[RS_METH_00203] The methodology shall explain the high-level
usage of the Manifest Specification . . . . . . . . . . . 22
[RS_METH_00207] The methodology shall explain how to develop
Platform Software for the Adaptive Platform . . . . . . 22
[RS_METH_00204] The methodology shall describe how to config-
ure a machine for the Adaptive Platform . . . . . . . . 23
[RS_METH_00205] The methodology shall describe how to deploy
software on the Adaptive Platform . . . . . . . . . . . 23
3 Change History 24
3.1 Change History of this document according to AUTOSAR Release R1.1.024
3.1.1 Added Requirements in R1.1.0 . . . . . . . . . . . . . . . . . . 24
3.1.2 Changed Requirements in R1.1.0 . . . . . . . . . . . . . . . . 24
3.1.3 Deleted Requirements in R1.1.0 . . . . . . . . . . . . . . . . . 24
3.2 Change History of this document according to AUTOSAR Release R1.2.024
3.2.1 Added Requirements in R1.2.0 . . . . . . . . . . . . . . . . . . 24
3.2.2 Changed Requirements in R1.2.0 . . . . . . . . . . . . . . . . 24
3.2.3 Deleted Requirements in R1.2.0 . . . . . . . . . . . . . . . . . 25
3.3 Change History of this document according to AUTOSAR Release R1.3.025
3.3.1 Added Requirements in R1.3.0 . . . . . . . . . . . . . . . . . . 25
3.3.2 Changed Requirements in R1.3.0 . . . . . . . . . . . . . . . . 25
3.3.3 Deleted Requirements in R1.3.0 . . . . . . . . . . . . . . . . . 26

5 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

3.4 Change History of this document according to AUTOSAR Release R1.4.027

3.4.1 Added Requirements in R1.4.0 . . . . . . . . . . . . . . . . . . 27
3.4.2 Changed Requirements in R1.4.0 . . . . . . . . . . . . . . . . 27
3.4.3 Deleted Requirements in R1.4.0 . . . . . . . . . . . . . . . . . 27
3.5 Change History of this document according to AUTOSAR Release R1.5.027
3.5.1 Added Requirements in R1.5.0 . . . . . . . . . . . . . . . . . . 27
3.5.2 Changed Requirements in R1.5.0 . . . . . . . . . . . . . . . . 27
3.5.3 Deleted Requirements in R1.5.0 . . . . . . . . . . . . . . . . . 27
3.6 Change History of this document according to AUTOSAR Release R1.5.128
3.6.1 Added Requirements in 1.5.1 . . . . . . . . . . . . . . . . . . . 28
3.6.2 Changed Requirements in 1.5.1 . . . . . . . . . . . . . . . . . 28
3.6.3 Deleted Requirements in 1.5.1 . . . . . . . . . . . . . . . . . . 28
3.7 Change History of this document according to AUTOSAR Release
R19-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7.1 Added Requirements in 19-11 . . . . . . . . . . . . . . . . . . 28
3.7.2 Changed Requirements in 19-11 . . . . . . . . . . . . . . . . . 28
3.7.3 Deleted Requirements in 19-11 . . . . . . . . . . . . . . . . . . 28
3.8 Change History of this document according to AUTOSAR Release
R20-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 Change History of this document according to AUTOSAR Release
R21-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9.1 Added Requirements in R21-11 . . . . . . . . . . . . . . . . . 29
3.9.2 Changed Requirements in R21-11 . . . . . . . . . . . . . . . . 29
3.9.3 Deleted Requirements in R21-11 . . . . . . . . . . . . . . . . . 29
3.10 Change History of this document according to AUTOSAR Release
R22-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10.1 Added Requirements in R22-11 . . . . . . . . . . . . . . . . . 29
3.10.2 Changed Requirements in R22-11 . . . . . . . . . . . . . . . . 29
3.10.3 Deleted Requirements in R22-11 . . . . . . . . . . . . . . . . . 29
3.11 Change History of this document according to AUTOSAR Release
R23-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11.1 Added Requirements in R23-11 . . . . . . . . . . . . . . . . . 30
3.11.2 Changed Requirements in R23-11 . . . . . . . . . . . . . . . . 30
3.11.3 Deleted Requirements in R23-11 . . . . . . . . . . . . . . . . . 30

6 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

References
[1] Standardization Template
AUTOSAR_FO_TPS_StandardizationTemplate
[2] Glossary
AUTOSAR_FO_TR_Glossary
[3] Main Requirements
AUTOSAR_FO_RS_Main

7 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

1 Introduction
This document defines the requirements needed to specify the AUTOSAR methodol-
ogy.
The document is structured into several sections with general requirements for the
AUTOSAR methodology, see section 2.1, as well as dedicated requirements for the
Classic Platform (CP) in section 2.2 and Adaptive Platform (AP) in section 2.3.

1.1 Document Conventions

The representation of requirements in AUTOSAR documents follows the table specified
in [TPS_STDT_00078], see Standardization Template, chapter Support for Traceability
([1]).
The verbal forms for the expression of obligation specified in [TPS_STDT_00053] shall
be used to indicate requirements, see Standardization Template, chapter Support for
Traceability ([1]).

1.2 Abbreviations
The main list of terms and abbreviations are defined in [2]. The following table contains
the list of terms and abbreviations used in the scope of this document which are not
already defined in [2] along with the spelled-out meaning of each of the abbreviations.

Abbreviation Meaning
SIL Safety Integrity Level (IEC61508 definition)
Table 1.1: Abbreviations used in the scope of this Document

8 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

1.3 Requirements Tracing

The following table references the requirements specified in [3] and links to the fulfill-
ments of these.
Requirement Description Satisfied by
[RS_Main_00002] AUTOSAR shall provide a software [RS_METH_00204] [RS_METH_00207]
platform for high performance
computing platforms
[RS_Main_00030] Safety Related Process Support [RS_METH_00018] [RS_METH_00069]
[RS_Main_00060] Standardized Application [RS_METH_00033] [RS_METH_00200]
Communication Interface [RS_METH_00201]
[RS_Main_00080] Formal Description Language [RS_METH_00015] [RS_METH_00062]
[RS_METH_00080] [RS_METH_00202]
[RS_Main_00130] Hardware Abstraction Layer [RS_METH_00032] [RS_METH_00033]
[RS_Main_00150] AUTOSAR shall support the [RS_METH_00033] [RS_METH_00078]
deployment and reallocation of [RS_METH_00079] [RS_METH_00201]
AUTOSAR Application Software [RS_METH_00202] [RS_METH_00205]
[RS_METH_00208]
[RS_Main_00190] Non-AUTOSAR Software Integration [RS_METH_00016] [RS_METH_00018]
[RS_Main_00250] AUTOSAR methodology shall provide [RS_METH_00042] [RS_METH_00066]
a predefinition of typical roles and
activities
[RS_Main_00300] AUTOSAR shall provide data [RS_METH_00006] [RS_METH_00018]
exchange formats to support [RS_METH_00020] [RS_METH_00033]
work-share in large inter and intra [RS_METH_00069] [RS_METH_00077]
company development groups [RS_METH_00078] [RS_METH_00079]
[RS_METH_00080] [RS_METH_00208]
[RS_Main_00301] AUTOSAR shall specify profiles for [RS_METH_00083] [RS_METH_00084]
data exchange to support work-share
in large inter- and intra-company
development groups
[RS_Main_00310] AUTOSAR shall support hierarchical [RS_METH_00041]
Application Software design methods
[RS_Main_00320] AUTOSAR shall provide formats to [RS_METH_00206]
specify system development
[RS_Main_00350] Documented Software Architecture [RS_METH_00041]
[RS_Main_00360] Variant Management Support [RS_METH_00062] [RS_METH_00074]
[RS_METH_00075] [RS_METH_00076]
[RS_Main_00400] AUTOSAR shall provide a layered [RS_METH_00032] [RS_METH_00033]
software architecture
[RS_Main_00503] AUTOSAR shall support change of [RS_METH_00203] [RS_METH_00204]
communication and application [RS_METH_00205]
software at runtime.
[RS_Main_00507] Development Collaboration Support [RS_METH_00056]
[RS_Main_00653] Means for Functional Modeling [RS_METH_00200]
[RS_Main_01002] AUTOSAR shall support [RS_METH_00206]
service-oriented communication
Table 1.2: RequirementsTracing

9 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

2 Methodology Requirements
This chapter provides the definition of the requirements.

2.1 General Requirements

This sections specifies the general requirements, which are mainly valid for both plat-
forms.

2.1.1 Main Requirements

[RS_METH_00006] The methodology shall explain how to build an AUTOSAR

system d

The methodology shall explain how to build an AUTOSAR system using the
activities and work products. It should be like a user manual to help an
Description: organization efficiently apply AUTOSAR.
In particular, the methodology shall explain how to build a system consisting of
classic and adaptive platforms.
A strong methodology is necessary to effectively manage building a large
Rationale:
system.
Dependencies: –
An engineer would like to complete an activity and would like to know what
inputs are needed, guidance should be used, etc. Typical use cases involved to
build an AUTOSAR system include:
Use Case: • SWC implementation
• ECU integration
• System integration
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00300)
[RS_METH_00041] The methodology shall support top-down and bottom-up ap-
proaches d

The methodology shall support both top-down and bottom-up approaches.

In the top-down approach, all constraints on the application software and their
Description: distribution on ECUs shall be considered.
In the bottom-up approach, all constraints coming from the hardware (
ECUs/sensors/actuators) should be taken into account.
5

10 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
To improve the integration phases, and to master the complexity in embedded
Rationale: real time distributed systems
Dependencies: –
If in a given vehicle architecture, a new ECU is added or an existing ECU is
Use Case: replaced with a new one, all the new or modified resources from the ECU need
to be included into the system configuration during integration.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00310, RS_Main_00350)
[RS_METH_00016] The methodology shall support building a system of both
AUTOSAR and Non-AUTOSAR ECUs d

The methodology shall support building a system of AUTOSAR compliant ECUs

Description:
and non-AUTOSAR compliant ECUs.
Rationale: The design of a complete vehicle system shall be supported.
Dependencies: –
Use Case: Legacy ECUs and LIN slaves need to interoperate with AUTOSAR ECUs.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00190)
[RS_METH_00200] The methodology shall support building a system consisting
of several AUTOSAR platforms d

The methodology shall support building a system consisting of several

Description:
AUTOSAR platforms.
Rationale: The design of a complete vehicle system shall be supported.
Dependencies: –
The communication description between machines (or ECUs) based on classic
Use Case:
and adaptive AUTOSAR platforms.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00060, RS_Main_00653)

11 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00208] The methodology shall support the data exchange between

different stakeholders d

AUTOSAR shall define an exchange format for data exchange between

Description: different stakeholders during the development of AUTOSAR-based vehicles.
The exchange format shall cover the description of software, network topology
and network communication.
Rationale: Usage of AUTOSAR templates in the development process
Dependencies: –
An OEM provides a software interface description and network communication
Use Case: description and delivers it to a supplier for the development and integration.
AppliesTo: CP, AP
Supporting –
Material:

c(RS_Main_00300, RS_Main_00150)
[RS_METH_00018] The methodology shall be modular d

Utilize process components. Subprocesses shall be complete and testable on

Description: their own to allow the usage of certain portions of the methodology while still
integrating with legacy tools and processes.
It is easier to understand and verify all portions of the methodology.
It is easier to manage modifications, encapsulates ripple effect due to changes
to allow migration of current processes.
It is easier to utilize both legacy and AUTOSAR activities.
It should be possible to start from an intermediate activity and not necessarily
Rationale: from the beginning of the methodology.
A modular methodology facilitates organizations to migrate from or merge with
their current processes.
A modular methodology allows organizations to insert intermediate activities
such as quality gates, or other inspections, as well as collect metrics necessary
to comply with CMMI processes and/or SIL-3.
Dependencies: –
An organization is planning to introduce an AUTOSAR ECU into their existing
architecture, but is not planning to use the System Template and their
Use Case:
respective activities and work products. Rather they plan to begin directly at the
ECU level.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00190, RS_Main_00300, RS_Main_00030)

12 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00032] The methodology shall support different abstraction levels d

The methodology shall support different views for the development of an

Description: AUTOSAR system. This corresponds to the typical domains and parties, which
are involved in the system development.
To improve the integration phases and to master the complexity in embedded
Rationale: real time distributed systems.
Dependencies: –
AUTOSAR is using several abstraction levels to describe the information
exchanged between the different players. In an early phase for instance only
Use Case:
the "Virtual Functional Bus" is used, whereas in later development phases we
handle real implementations of the SWC deployed to several ECUs.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00130, RS_Main_00400)
[RS_METH_00020] The methodology shall support round-trip engineering d

The methodology shall support round-trip engineering. This implies that several
Description:
iteration loops might be necessary in order to finalize a task or work product.
Rationale: Meet AUTOSAR Quality requirements.
Dependencies: –
Automotive systems are typically developed in several sample phases (A, B, C,
etc). A single Software Component is updated in a AUTOSAR System. The
Use Case: updated ECU Extract still matches the existing ECU Configuration (as long as no
contradicting changes are made in the iteration).
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00300)
[RS_METH_00077] The methodology shall support different views on the SW-C
structure by OEMs and suppliers d

The methodology shall support the interaction between OEM and supplier,
Description:
where the OEM and the supplier have different views on the SW-C structure.
Rationale: Possibility for the supplier to adapt SW-C structure.
Dependencies: –
5

13 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
The OEM hands over the initial System Extract to the supplier as a formal
requirements specification. The supplier extends and refactors this System
Extract.
Use Case: In the next development cycle the OEM hands over an updated System Extract
to the supplier. Thereafter the supplier has to update his System Extract
structure based on the updates made by the OEM. The amount of changes on
the supplier side shall be limited to the changes caused by OEM updates.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00300)
[RS_METH_00078] The methodology shall explain the typical usage of different
views on the system of the OEM d

The methodology shall support use cases of the OEM, where the OEM has
Description:
different views on the system.
Rationale: Methodology consistency in the software system development approach
Dependencies: –
An OEM might structure the AUTOSAR software components from a functional
point of view. However, for the concrete vehicle development project a
Use Case: topological view of structure of SW-Cs is needed. For better handling during
the life-cycle, the SW-Cs from the functional decomposition are mapped to the
topological view using appropriate mappings.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00300, RS_Main_00150)
[RS_METH_00079] The methodology shall explain the typical usage of different
views on the system of the supplier d

The methodology shall support use cases of the supplier where the supplier
Description:
has different views on the system.
Rationale: Methodology consistency in the software system development approach
Dependencies: –
5

14 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
The supplier needs to map different views of the system, e.g.
a) the supplier already has an existing software architecture. Via software
sharing some of the components are substituted by the ones delivered by the
OEM.
b) The supplier needs to formally describe changes between system
Use Case:
descriptions representing different releases.
c) The supplier develops one ECU for different OEMs and therefore needs to
map the requirement-views of the OEMs to his solution view.
d) The supplier realizes the OEMs definition for one ECU by 2 ECUs and
therefore needs to map the system descriptions.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00300, RS_Main_00150)

2.1.2 Programming Language

[RS_METH_00015] The methodology shall be independent of programming lan-

guages d

The methodology shall be independent of programming languages by providing

generic solutions. For portions that are necessarily dependent on the
Description: programming language, these sections shall be explicitly noted and be modular
such that the overall methodology can be tailored to accommodate other
programming languages.
By appropriately structuring the methodology to support existing and emerging
Rationale: programming languages, the methodology can be consistently and successfully
applied across an entire vehicle.
Dependencies: –
An ECU built for a particular microcontroller is explicitly optimized for
programming language ABC. The methodology explains when and how to
Use Case: specify and to select the implementation of the software components
compatible with the required programming language.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00080)

15 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

2.1.3 Activities

[RS_METH_00066] The methodology shall allow activities that reference tools d

Activities may reference tools that help to complete the activity. The
Description:
methodology shall describe these types of tools and when they are used.
By defining which tools are needed, the performers of the activity can ensure
that all tools have been sourced and installed prior to the beginning of the
activity.
Rationale: As well, the implementers of tools that are AUTOSAR specific, have a clear
understanding of what activities their tool should support and know what the
input and output work products are available. This will help to ensure
interoperability of AUTOSAR tools.
Dependencies: –
For the Classic Platform, the activity "Generate RTE" requires an RTE generator
Use Case:
tool and a compiler.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00250)
[RS_METH_00042] The methodology shall incorporate the usage of industry
standard tools d

Where industry standard tools, such as compilers and linkers exist, the
Description:
methodology shall incorporate them.
AUTOSAR should not require the use of particular tools when industry standard
Rationale:
tools already exist.
Dependencies: –
Use Case: Compilers are industry standard tools.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00250)

2.1.4 Process Requirements

[RS_METH_00056] The AUTOSAR methodology shall not be bound to a particular

life-cycle model d

The AUTOSAR methodology shall not be bound to a particular life-cycle model.

Description: Activities must be independent with respect to the time and phase of the
development process they are executed.
5

16 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
Connection to company specific life-cycle model: The methodology shall
Rationale: enable the use of different life-cycle models such as e.g. V-Model, Rational
Unified Process.
Dependencies: –
If e.g. extreme programming is used, the test cases are created prior to the
Use Case: implementation. For most other development processes, the implementation is
generated prior to the creation of test cases.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00507)
[RS_METH_00069] It shall be possible to add precise and human readable docu-
mentation to each work product d

The methodology shall allow that precise and human readable documentation
Description: be added to each work product. This documentation shall be either part of the
work product or uniquely referred.
This is necessary in order to document design decisions or restrictions, which
cannot obviously be deduced from the formal content, e.g. from names. Such
Rationale: documentation will increase the traceability which is demanded by quality or
safety standards.
Dependencies: –
Choosing a redundancy mechanism, e.g. in the configuration for a NVRAM
Use Case: data block, may be related to a safety requirement. This may need verbal
explanation.
AppliesTo: CP,AP
Supporting –
Material:

c(RS_Main_00030, RS_Main_00300)

2.1.5 Variant Handling Requirements

[RS_METH_00062] The methodology shall support configuration of parameters

with different binding time. d

The AUTOSAR methodology shall allow system development with variant

Description:
handling support.
The configuration of parameters can be performed in different process steps at
Rationale:
different times.
Dependencies: –
5

17 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
OEM configuration of (post-build) data after a release from a Tier 1 supplier.
Use Case: Handling information related to different configuration items (units for version
control).
AppliesTo: CP, AP
Supporting –
Material:

c(RS_Main_00080, RS_Main_00360)
[RS_METH_00074] The methodology shall specify binding times d

Description: The AUTOSAR Methodology shall specify particular points in the workflow on
which variation can be resolved.
Rationale: Need for a stable reference on Binding times.
Dependencies: –
During the development of an AUTOSAR System and ECU, specific variants
Use Case: need to be created, and eventual chosen, e.g pre-compile, or post-build.
AppliesTo: CP, AP
Supporting –
Material:

c(RS_Main_00360)
[RS_METH_00075] The methodology shall specify the tasks of resolving variant
d

Description: The AUTOSAR Methodology shall specify particular tasks/activities in which

variation will be resolved.
Rationale: Need for clarification of methodology of variants.
Dependencies: –
If two software components provide the same interface in different variants of
Use Case: the system, a task is needed to select the one provider to resolve that system
variant.
AppliesTo: CP, AP
Supporting –
Material:

c(RS_Main_00360)
[RS_METH_00076] The methodology shall specify a work product for values of
variant selectors d

Description: AUTOSAR Methodology shall specify particular work products to maintain the
values of variant selectors.
This makes it clear where the values for variant selectors are stored and
Rationale:
maintained.
5

18 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
Dependencies: –
The possible variants are known up front: they are created at a certain time and
Use Case:
owned as a work product, and finally consumed when the variant is selected.
AppliesTo: CP, AP
Supporting –
Material:

c(RS_Main_00360)

2.2 Requirements for the Classic Platform

2.2.1 General Requirements

[RS_METH_00033] The methodology should support the VFB concept d

The Virtual Functional Bus concept allows early checks between SW-C with a
Description: complete abstraction of the hardware. The methodology should include this
concept.
Rationale: To improve the integration phases and the concurrent development.
Dependencies: –
In AUTOSAR, an application is modeled as a composition of interconnected
components. The VFB is the communication mechanism that allows these
components to interact.
Use Case:
Even if all the resources used by these components are not available yet during
the development (HW/Network) some basic checks can be done and early
problems can be solved that will ease the integration phase later.
AppliesTo: CP
Supporting –
Material:

c(RS_Main_00060, RS_Main_00130, RS_Main_00150, RS_Main_00300, RS_Main_-

00400)
[RS_METH_00080] The AUTOSAR methodology shall support the concept of im-
plicit communication behavior d

The AUTOSAR methodology shall support the exchange of information to

configure the Implicit Communication Behavior of the RTE according to the
requirements of the Software Components.

Description: The information can be defined first time at the design of an Atomic Software
Component but can be added as well if compositions are created. The design
of an Atomic Software Component with respect to implicit communication
behavior may be guided by blueprints of the Implicit Communication Behavior
descriptions.
5

19 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
Define Implicit Communication Behavior requirements in a top down design
Rationale:
approach
Dependencies: –
Use Case: –
AppliesTo: CP
Supporting [RS_SWCT_03065], [RS_STDT_00034]
Material:

c(RS_Main_00080, RS_Main_00300)
[RS_METH_00083] The AUTOSAR methodology shall explain the description and
handling of Data Exchange Points d

The methodology shall explain workflows for the development and the use of
Data Exchange Points. E.g., it shall describe which artifacts are provided by
AUTOSAR that support the development of profiles of Data Exchange Points
Description:
that can be used to analyze potential tool interoperability issues or to configure
validation engines of AUTOSAR tools according to the described data
exchange point.
Rationale: Tool interoperability
Dependencies: [RS_METH_00084]
• AUTOSAR specifies the contents of artifacts for different steps in the
methodology.

Use Case: • A contract is established between producing and consuming AUTOSAR tools
with respect to exchanged artifacts. The producing tool assures its
adherence to a an agreed profile and the consuming tool specifies its
expectations using this profile.
AppliesTo: CP
Supporting –
Material:

c(RS_Main_00301)
[RS_METH_00084] The AUTOSAR methodology shall relate templates to a dis-
tributed development process d

The AUTOSAR templates specify the language for describing an

AUTOSAR-based software or system. The methodology shall support the
Description:
specification of a subset of the templates, which is used for a specific work
product in a distributed development process.
Rationale: Exchange of AUTOSAR artifacts in distributed development
Dependencies: [RS_METH_00083]
A (VFB) system description shall only contain relevant information for the
Use Case:
development of SW-Cs without the deployment to an ECU network yet.
AppliesTo: CP
5

20 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

4
Supporting
Material:

c(RS_Main_00301)

2.3 Requirements for the Adaptive Platform

This section specifies requirements, which are valid for the Adaptive Platform only.

2.3.1 Main Requirements

[RS_METH_00201] The methodology shall explain how to design the services of

a system d

The methodology shall explain how to describe services for service-oriented

Description: communication used in an Adaptive AUTOSAR system. The service interfaces
consist of methods, events and fields, which need to be specified.
Consistent description of the information that is exchanged between
Rationale:
applications.
Dependencies: –
Use Case: Specify a service interface, which consists of three events and one method.
AppliesTo: AP
Supporting –
Material:

c(RS_Main_00150, RS_Main_00060)
[RS_METH_00206] The methodology shall explain how to configure the in-
stances of services of a system d

The methodology shall explain the necessary steps for the deployment of
services. This starts with the configuration of the deployment of service
Description: interfaces for the chosen network binding. The methodology shall further
describe how service instances are defined and configured for a specific
machine.
Rationale: Complete description of service instances within a system.
Dependencies: –
Define if service instances are required or provided as well as their search or
Use Case:
offer criteria for service-oriented communication.
AppliesTo: AP
Supporting –
Material:

c(RS_Main_00320, RS_Main_01002)

21 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00202] The methodology shall explain how to develop an Adaptive

Application d

An Adaptive Application is developed based on the service interfaces. The

Description: methodology shall describe the necessary activities for first designing and then
implementing the Adaptive Application.
Clear navigation with a description of possible development approaches for the
Rationale:
application developer.
Dependencies: –
Design a model of the software component with all necessary ports in order to
Use Case:
use the service interfaces.
AppliesTo: AP
Supporting –
Material:

c(RS_Main_00080, RS_Main_00150)
[RS_METH_00203] The methodology shall explain the high-level usage of the
Manifest Specification d

The manifest contains all necessary information that is needed in order to

integrate applications onto the Adaptive Platform.
Description: The methodology shall explain how this information will be collected, for the
machine, the service instances as well as for the application itself, and later on
how the manifest will be used for configuration purposes.
Rationale: Methodology consistency using the Manifest Specification
Dependencies: [RS_METH_00208]
The Execution Manifest is used for describing all process related aspects of an
Use Case:
executable.
AppliesTo: AP
Supporting –
Material:

c(RS_Main_00503)
[RS_METH_00207] The methodology shall explain how to develop Platform Soft-
ware for the Adaptive Platform d

The methodology shall explain how to develop the functional clusters for an
Description:
Adaptive Platform.
Rationale: Efficient development of Adaptive Platform.
Dependencies: –
Development of the Execution and Communication Management of an
Use Case:
Adaptive Platform.
AppliesTo: AP
Supporting –
Material:

c(RS_Main_00002)

22 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00204] The methodology shall describe how to configure a machine

for the Adaptive Platform d

The methodology shall describe the different steps for defining and configuring
the machine so that software can be deployed on it.
Description: These steps shall be independent of other development steps in order to
ensure that software can be easily uploaded later without a new configuration
of the machine.
Rationale: Deployment or updating of software without adapting machine configuration.
Dependencies: –
AppliesTo: AP
Configuration of all ports and IP addresses on the machine for service-oriented
Use Case:
communication.
Supporting –
Material:

c(RS_Main_00503, RS_Main_00002)
[RS_METH_00205] The methodology shall describe how to deploy software on
the Adaptive Platform d

A SW package is the smallest unit for deployment onto an Adaptive AUTOSAR

Description: Platform instance. The methodology shall describe the content of a SW
package and how it is deployed on the Adaptive Platform.
Complete description of application development workflow until software is
Rationale:
deployed.
Dependencies: –
AppliesTo: AP
Use Case: Downloading and deploying a software update.
Supporting –
Material:

c(RS_Main_00503, RS_Main_00150)

23 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

3 Change History
Please note that the lists in this chapter also include requirement items that have been
removed from the specification in a later version. These requirement items do not
appear as hyperlinks in the document.

3.1 Change History of this document according to AUTOSAR Re-

lease R1.1.0

3.1.1 Added Requirements in R1.1.0

Id Heading
[RS_METH_00201] Methodology shall explain how to design the services of a system
[RS_METH_00202] Methodology shall explain how to develop an Adaptive Application
[RS_METH_00203] Methodology shall explain the high-level usage of the Manifest Specification
[RS_METH_00204] Methodology shall describe how to configure a machine for the Adaptive Plat-
form
[RS_METH_00205] Methodology shall describe how to deploy software on the Adaptive Platform
[RS_METH_00206] Methodology shall explain how to configure the instances of services of a
system
[RS_METH_00207] Methodology shall explain how to develop Platform Software for the Adaptive
Platform

3.1.2 Changed Requirements in R1.1.0

3.1.3 Deleted Requirements in R1.1.0

none

3.2 Change History of this document according to AUTOSAR Re-

lease R1.2.0

3.2.1 Added Requirements in R1.2.0

none

3.2.2 Changed Requirements in R1.2.0

Id Heading
[RS_METH_00006] Methodology shall explain how Autosar system is built
[RS_METH_00041] Methodology shall support Bottom/Up Approach
[RS_METH_00018] Methodology shall be modular
[RS_METH_00032] The methodology shall respect the different levels of abstractions

24 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00020] Methodology shall support iterations

[RS_METH_00077] Methodology shall explain the typical interaction between OEMs and suppli-
ers
[RS_METH_00078] Methodology shall explain the typical usage of different views on the system
of the OEM
[RS_METH_00079] Methodology shall explain the typical usage of different views on the system
of the Supplier
[RS_METH_00084] AUTOSAR methodology shall relate templates to a distributed development
process
[RS_METH_00015] Methodology shall be independent of programming language
[RS_METH_00066] Methodology shall support activities that reference tools
[RS_METH_00042] Methodology shall incorporate the usage of industry standard tools
[RS_METH_00056] AUTOSAR methodology shall not be bound to a particular lifecycle model

3.2.3 Deleted Requirements in R1.2.0

none

3.3 Change History of this document according to AUTOSAR Re-

lease R1.3.0

3.3.1 Added Requirements in R1.3.0

Id Heading
[RS_METH_00200] The methodology shall support building a system consisting of several
AUTOSAR platforms
[RS_METH_00208] The methodology shall explain the high-level usage of the AUTOSAR tem-
plates

3.3.2 Changed Requirements in R1.3.0

Id Heading
[RS_METH_00006] The methodology shall explain how to build an AUTOSAR system
[RS_METH_00041] The methodology shall support top-down and bottom-up approaches
[RS_METH_00016] The methodology shall support building a system of both AUTOSAR and Non-
AUTOSAR ECUs
[RS_METH_00032] The methodology shall support different levels of abstractions
[RS_METH_00020] The methodology shall support round-trip engineering
[RS_METH_00077] The methodology shall support different views on the SW-C structure by
OEMs and suppliers
[RS_METH_00078] The methodology shall explain the typical usage of different views on the
system of the OEM
[RS_METH_00079] The methodology shall explain the typical usage of different views on the
system of the supplier
[RS_METH_00066] The methodology shall allow activities that reference tools
[RS_METH_00042] The methodology shall incorporate the usage of industry standard tools
[RS_METH_00056] The AUTOSAR methodology shall not be bound to a particular life-cycle
model

25 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

[RS_METH_00069] It shall be possible to add precise and human readable documentation to each
work product
[RS_METH_00033] The methodology should support the VFB concept
[RS_METH_00015] The methodology shall be independent of programming languages
[RS_METH_00084] The AUTOSAR methodology shall relate templates to a distributed develop-
ment process
[RS_METH_00201] The methodology shall explain how to design the services of a system
[RS_METH_00202] The methodology shall explain how to develop an Adaptive Application
[RS_METH_00203] The methodology shall explain the high-level usage of the Manifest Specifica-
tion
[RS_METH_00204] The methodology shall describe how to configure a machine for the Adaptive
Platform
[RS_METH_00205] The methodology shall describe how to deploy software on the Adaptive Plat-
form
[RS_METH_00206] The methodology shall explain how to configure the instances of services of
a system
[RS_METH_00207] The methodology shall explain how to develop Platform Software for the
Adaptive Platform

3.3.3 Deleted Requirements in R1.3.0

Id Heading
[RS_METH_00017] Methodology shall clearly define what is standardized and what is not stan-
dardized
[RS_METH_00002] Methodology shall explain the typical usage of SW-C template
[RS_METH_00003] Methodology shall explain the typical usage of BSW Module Template
[RS_METH_00004] Methodology shall explain the typical usage of the ECU Configuration tem-
plate
[RS_METH_00005] Methodology shall explain the typical usage of the System Template
[RS_METH_00081] Methodology shall explain the typical usage of Safety Extensions
[RS_METH_00082] Methodology shall explain the typical usage of Diagnostic Extract Template
[RS_METH_00038] Methodology shall support the C programming language
[RS_METH_00021] Methodology shall define Activities
[RS_METH_00043] Activities shall have a purpose
[RS_METH_00046] Activities shall have input work products
[RS_METH_00047] Activities shall have output work products
[RS_METH_00048] Activities shall include roles
[RS_METH_00025] Methodology shall define Work products
[RS_METH_00050] Work products shall have a description
[RS_METH_00051] Work products shall have a reference(s) to metaclass(es) in the Autosar Meta-
model
[RS_METH_00052] It must be possible to avoid duplication of data in Work Products
[RS_METH_00054] Work Products shall not have circular references with other work products
[RS_METH_00061] Methodology shall describe the change of existing work products
[RS_METH_00027] Methodology shall define unambiguous guidance terminology
[RS_METH_00028] Methodology shall define Roles
[RS_METH_00064] Roles shall have a description
[RS_METH_00009] Methodology should be modeled
[RS_METH_00010] Methodology should define rules to translate methodology model into a doc-
ument
[RS_METH_00057] AUTOSAR methodology shall support traceability to external artifacts
[RS_METH_00067] Methodology document shall include hyperlinks between Activities, Roles,
Work Products, and Guidance

26 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

3.4 Change History of this document according to AUTOSAR Re-

lease R1.4.0

3.4.1 Added Requirements in R1.4.0

none

3.4.2 Changed Requirements in R1.4.0

none

3.4.3 Deleted Requirements in R1.4.0

none

3.5 Change History of this document according to AUTOSAR Re-

lease R1.5.0

3.5.1 Added Requirements in R1.5.0

none

3.5.2 Changed Requirements in R1.5.0

Number Heading
The methodology shall support configuration of parameters with different
[RS_METH_00062]
binding time.
[RS_METH_00074] The methodology shall specify binding times
[RS_METH_00075] The methodology shall specify the tasks of resolving variant
[RS_METH_00076] The methodology shall specify a work product for values of variant selectors
The methodology shall explain the high-level usage of the Manifest Specifi-
[RS_METH_00203]
cation
The methodology shall support the data exchange between different stake-
[RS_METH_00208]
holders

3.5.3 Deleted Requirements in R1.5.0

none

27 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

3.6 Change History of this document according to AUTOSAR Re-

lease R1.5.1

3.6.1 Added Requirements in 1.5.1

none

3.6.2 Changed Requirements in 1.5.1

none

3.6.3 Deleted Requirements in 1.5.1

none

3.7 Change History of this document according to AUTOSAR Re-

lease R19-11

3.7.1 Added Requirements in 19-11

none

3.7.2 Changed Requirements in 19-11

none

3.7.3 Deleted Requirements in 19-11

none

28 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

3.8 Change History of this document according to AUTOSAR Re-

lease R20-11

3.9 Change History of this document according to AUTOSAR Re-

lease R21-11

3.9.1 Added Requirements in R21-11

none

3.9.2 Changed Requirements in R21-11

none

3.9.3 Deleted Requirements in R21-11

none

3.10 Change History of this document according to AUTOSAR Re-

lease R22-11

3.10.1 Added Requirements in R22-11

none

3.10.2 Changed Requirements in R22-11

none

3.10.3 Deleted Requirements in R22-11

none

29 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology

 Requirements on Methodology for Classic and
Adaptive Platform
AUTOSAR FO R23-11

3.11 Change History of this document according to AUTOSAR Re-

lease R23-11

3.11.1 Added Requirements in R23-11

none

3.11.2 Changed Requirements in R23-11

Number Heading
[RS_METH_00032] The methodology shall support different abstraction levels
The methodology shall support building a system consisting of several
[RS_METH_00200]
AUTOSAR platforms
Table 3.1: Changed Requirements in R23-11

3.11.3 Deleted Requirements in R23-11

none

30 of 30 Document ID 362: AUTOSAR_FO_RS_Methodology