Methodology for Classic Platform (`Methodology`)¶

属性	值
平台	CP
类别	TR — 技术报告（Technical Report）
UID	068
规范版本	R25-11

本地文件¶

规范 PDF: F:\Work\Standards\01_Sources\CP_TR_Methodology_068\AUTOSAR_CP_TR_Methodology.pdf
ARXML 模型: F:\Work\Standards\01_Sources\CP_TR_Methodology_068\AUTOSAR_CP_TR_Methodology.arxml
纯文本全文: F:\Work\Standards\01_Sources\CP_TR_Methodology_068\zzgen\CP_TR_Methodology.complete.txt

模块依赖¶

Task Definition	Add Independence Relation	<	<
Package	AUTOSAR Root::M2::Methodology::Methodology Library::Common Elements::Safety::Tasks	<	<
Brief Description	Add Independence relation to decomposed requirements.	<	<
Description	This task establishes the INDEPENDENCE relation between requirements. The relation is established between a decomposed requirement and a requirement which express a means to achieve freedom from interference for the two requirements into which the decomposed requirement is decomposed by the task Decompose Safety Requirement.

Obviously, this task is processed in the context of the decomposition of safety requirements.	<	<
Relation Type	Related Element	Mult.	Note
Performed by	Safety Engineer	1
Consumes	Safety Requirement	1..*
Produces	Safety Requirement	1..*	Linked Requirement:

章节详细内容¶

1. 简介¶

原文标题：Introduction

2. Objective¶

AUTOSAR requires a common technical approach for some steps of system development. This approach is called the AUTOSAR methodology. This document defines and describes this AUTOSAR methodology. It covers all major steps of the development of a system with AUTOSAR: from the definition of the Virtual Functional Bus to the generation of an ECU executable.

3. Document Conventions¶

This document follows a list of document conventions, which are described in the following.

Technical terms of AUTOSAR are typeset in mono spaced font, e.g. ECU. As a general rule, plural forms of technical terms are created by adding "s" to the singular form, e.g. ECUs.

This document contains specification items in textual form that are distinguished from the rest of the text by a unique numerical ID, a headline, and the actual text starting after the \lceil character and terminated by the \rfloor character. The conventions for requirements traceability follow , see Standardization Template ().

4. 范围¶

原文标题：Scope

Scope of the AUTOSAR methodology ⌈ The AUTOSAR methodology is not a complete process description, but rather aggregates the various elements of AUTOSAR and shows how they are brought together to develop a complete system. ⌋

Note: Sample aggregations are provided as Use Cases in chapter .

Support for various stakeholders by the AUTOSAR methodology ⌈ The structure of the methodology was designed to help cover the needs of various AUTOSAR stakeholders:

Organizations: Methodology is modeled in a modular format to allow organizations 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 find AUTOSAR information that is relevant to their specific needs.
Tool Vendors: Methodology provides a common language to share among all AUTOSAR members and a common expectation of what capabilities tools should support. ⌋

Restrictions of AUTOSAR methodology ⌈ Furthermore, the methodology does not prescribe a precise order in which activities should be carried out.

5. Terms and Abbreviations¶

The main list of terms and abbreviations are defined in .

Abbreviation / Acronym	Description
SPEM	Software and Systems Process Engineering Meta-Model (previously called Software Process Engineering Metamodel) - a way of modeling processes.

6. 概述¶

原文标题：Overview

Domains of the AUTOSAR methodology ⌈ The AUTOSAR methodology is structured into several domains of development:

Virtual Functional Bus
System
Software Component
Basic Software
ECU

These domains are depicted in the methodology overview workflow. ⌋

Note: See Figure .

AUTOSAR methodology assets ⌈ For each domain relevant Work Product, Task, Role, and Tool elements are defined. In addition, there are elements that are common for all domains. ⌋

Note: See chapter and chapter for the relevant elements.

AUTOSAR methodology use cases ⌈ Use cases show how these standard reusable elements are applied to support real-world development. The Overall View provides an end to end view on the typical use cases of all domains. ⌋

Note: See chapter for the use cases and chapter for the overall view.

7. Methodology 概念¶

原文标题：Methodology Concepts

General AUTOSAR methodology concepts ⌈ The AUTOSAR methodology defines activities performed by roles that create work products as general reusable method patterns. The reusable method pattern elements are described in the methodology library elements chapter. The methodology also describes sample process patterns of typical use cases considered for the creation of AUTOSAR work products. The patterns use process elements that are described in the use case elements chapter.

The definitions and the figures are made according to the Software Process Engineering Meta-Model Specification . The symbols are taken from the Enterprise Architect modeling tool. ⌋

Note: See chapter for the methodology library elements and chapter for the use case elements.

8. Methodology 库 Elements¶

原文标题：Methodology Library Elements

Methodology Library ⌈ The Methodology Library defines the Methodology Library Elements of every method pattern such as Roles, Tasks, and Work Product Definitions. ⌋

Note: See chapter .

Methodology Library Element ⌈ A Methodology Library Element contains a description of the element to define its purpose in the methodology and thus provides the basic contents of the AUTOSAR methodology. The Methodology Library Elements are used for the description of the related development processes. These Methodology Library Elements can been seen as a standard. ⌋

Relation of Methodology Library and Methodology Library Element to the SPEM meta model ⌈ The Methodology Library and the Methodology Library Elements correspond to the Method Content and Method Content Elements in the SPEM meta model . ⌋

Overview of Methodology Library Elements ⌈ Methodology Library Elements comprise:

Task Definition
Work Product Definition
Role Definition
Tool Definition
Guidance ⌋

Note: See chapter for Task Definition, chapter for Work Product Definition, chapter for Role Definition, chapter for Tool Definition and chapter for Guidance.

The element symbols are shown in Figure .

s

9. Task 定义¶

原文标题：Task Definition

Task Definition ⌈ According to the SPEM meta model, a Task Definition is an assignable unit of work that is being performed by specific Roles. The duration of a task is generally a few hours to a few days. Tasks usually generate one or more work products. Each Task is associated to input and output Work Products. Inputs are differentiated in mandatory and optional inputs. A Task is used as one element among others to define a Process. ⌋

Task semantics ⌈ A Task has a clear purpose in which the performing roles achieve a well defined goal. It provides complete step-by-step explanations of doing all the work that needs to be done to achieve this goal. This description is completely independent of when in a process lifecycle the work would actually be done. It does not describe when what work is being done, but describes all the work that gets done. ⌋

Task usage ⌈ When a Task will be used in a development process, it provides the information which pieces of the Task will actually be performed at any particular point in time.

10. Work Product 定义¶

原文标题：Work Product Definition

Work Product Definition ⌈ According to the SPEM meta model, 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 products consumed, produced, or modified by Tasks. They may serve as a basis for defining reusable assets. A Work Product can be related to other work products by a kind of nesting relationship, but work products shall not have circular references with other work products. ⌋

Relationship between Roles and Work Products ⌈ Roles use Work Products to perform Tasks and produce Work Products in the course of performing the Tasks. Work Products are in the responsibility of the associated Roles, thereby also defining a set of skills the performing Role should have. Even though one Role might own a specific type of Work Product, other Roles can still use the Work Product for their work, and update them . ⌋

A Work Product can be of type Artifact or Deliverable:

Artifact Definition ⌈ Artifact: A tangible Work Product that is consumed, produced, or modified by one or more Tasks. Artifacts may be composed of other Artifacts and may serve as a basis for defining reusable assets .

11. Role 定义¶

原文标题：Role Definition

Role Definition ⌈ According to the SPEM meta model, Role Definitions define responsibilities of an individual or a set of individuals and thereby define a set of related skills, competencies, and qualifications needed to perform a Task. A Role can be filled by one person or multiple people, one person may fill several Roles. Each Role performs Tasks. ⌋

Role assignment ⌈ Roles are not individuals or resources. Individual members of the development organization will wear different hats, or perform different Roles. The mapping from individual to Role, usually performed by the project manager when planning and staffing a project, allows different individuals to act as several different Roles, and for a Role to be taken by several individuals .

In the AUTOSAR Methodology, a Role also assigns the responsibility of a Task and defines optional performers. Performers that are responsible for e.g. a Task have a multiplicity of 1 for the relationship to the Task, optional performers have optional multiplicity assigned. Role Definitions are usually generic and still provide sufficient level of detail for managers to organize a team.

12. Tool 定义¶

原文标题：Tool Definition

Tool Definition ⌈ According to the SPEM meta model, Tool Definitions can be used to specify a tool's participation in a Task. A Tool Definition describes the capabilities of a CASE tool, general purpose tool, or any other automation unit that supports the associated Roles in performing the work defined by a Task. A Tool can identify a resource as useful, recommended, or necessary for a task's completion. A Tool can also be used to manage one or more Work Products .

The AUTOSAR Methodology uses the Tool Definition to describe AUTOSAR specific (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 will need to perform the Task. ⌋

Tool	Tool Name	<	<
Package	Location in the MetaModel package	<	<
Brief Description	some description as summary	<	<
Description	some description as more detailed explanation	<	<
Kind	Tool Kind (e.g. Editor)	<	<
Relation Type	Related Element	Mult.	Note
Used	Task where the tool is used	0..1 or 1	Description of the activites supported by the tool in this task

13. Guidance¶

Guidance definition ⌈ According to the SPEM meta model, a Guidance provides additional information related to e.g. Roles, Work Products, and Tasks. A Guidance is classified to indicate a specific type for which perhaps a specific structure and type of content is assumed . ⌋

Guidance kinds ⌈ A Guidance can be a

Supporting Material: Supporting Material is a catch-all for other types of guidance not specifically defined elsewhere. It can be related to all kinds of Content Elements, i.e., including other guidance elements. The AUTOSAR Methodology uses the Supporting Material Guidance type to define title pages, change histories, disclaimers etc.
Tool Mentor: A Tool Mentor shows how to use a specific Tool to accomplish some piece of work either in the context of or independent from a Task or Activity. In the context of the AUTOSAR Methodology, a Tool Mentor is used in the same way as the Tool element.
White Paper: White Papers are concept guidances that have been externally reviewed or published and can be read and understood in isolation from other Method Content. AUTOSAR documents are examples of White Papers.

14. Use Case Specifications¶

This section explains how the use cases in chapter are specified. The first two subsections introduce the main constituents of the use cases. Afterwards, it is explained how these elements together with the Methodology Library elements are used for describing the use cases.

Adaptability of the AUTOSAR methodology ⌈ The main focus of this section is merely to provide a use case process flow that can be supported by an AUTOSAR tool chain rather than to define a complete process description. One reason for doing this is that the AUTOSAR methodology should be adaptable to development processes of different organizations. ⌋

Use case elements ⌈ This section describes the main elements to build a use case, which are given by the Capability Pattern and the Activity. Roles, Work Products, Deliverables and Tasks are used directly to describe the details of an Activity. The SPEM meta model additionally defines the Role Use , the Work Product Use and the Task Use elements, which are not used in the AUTOSAR methodology.

15. Activity¶

Definition of Activities ⌈ In the SPEM meta model, an Activity is the main building block to define a process. An Activity is usually a defined task or work to be done that is commonly executed in one sequence. ⌋

Composition of Activities ⌈ Activities can include other Activities and thereby often decompose a flow of work and show which Activity precedes other Activities . At the lowest level, Activities are collections of work breakdown elements which in AUTOSAR methodology are Tasks, Roles, and Work Products. ⌋

Definition of Processes ⌈ A Process is a special Activity in the SPEM meta model that describes a typical structure of development projects or parts of them. A Process focuses on the lifecycle and the sequencing of work in breakdown structures. Processes contain sequences of Task and Activities and thereby express a lifecycle of the product under development. Processes also define how to get from one milestone to the next by defining sequences of work, operations, or events . ⌋

16. Capability Pattern¶

The methodology library elements (cf. Section ) are referenced in order to describe together with activities the so-called Capability Patterns.

Capability Pattern definition ⌈ A Capability Pattern is a process pattern that contains a reusable set of activities. ⌋

Composition of Capability Patterns ⌈ Capability Patterns can be assembled to larger Capability Patterns that describe development processes or parts of a development process including typical use cases. ⌋

17. 描述 of Use Cases¶

原文标题：Description of Use Cases

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

Description of overall Use Cases ⌈ In the first diagram, one Capability Pattern describes the overall Use Case, composing a set of Activities and their main outputs (Deliverables). In these diagrams, the predecessor relationship can be used in order to define a sequence of the Activities. However, the predecessor relationship can be skipped and Deliverables can be extended by other Deliverables. ⌋

Note: See Figure .

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

Process Pattern	Capability Pattern Name	<	<
Package	Location in the MetaModel package	<	<
Brief Description	some description as summary	<	<
Description	some description as more detailed explanation	<	<
Relation Type	Related Element	Mult.

18. 通用需求¶

原文标题：General Requirements

The following requirements are satisfied by the AUTOSAR methodology in a general way together with other documents as listed in the following:

Definition of Consistency Needs ⌈ The AUTOSAR methodology supports the exchange of implicit communication behavior description as consistency needs. ⌋

Note: Chapters and depict the task and the artifact which allow to define the corresponding consistency needs.

Building the AUTOSAR methodology document ⌈ All AUTOSAR methodology related model elements are consumed by an internal AUTOSAR tool that automatically produces the corresponding text, tables, and diagrams. These artifacts are included into a document which is automatically transformed into the final PDF file. ⌋

Note: See chapter .

Relations between AUTOSAR Work Products ⌈ Work Products (Deliverables and Artifacts) are designed in such a way that no circular references with other Work Products exist. ⌋

Traceability to external artifacts ⌈ Artifacts considered in the Methodology model include external artifacts like c-code, libraries, documentation and generated artifacts. General Non Autosar Artifact is a generic representation of non AUTOSAR artifacts.

19. Use Cases¶

In the following, the main use cases for building an AUTOSAR system are described. Chapter gives an overall brief description of the main development steps. These steps are elaborated in detail in chapter to chapter . In addition, chapter to decribe general topics of interest.

20. Overall 视图¶

原文标题：Overall View

21. 目的¶

原文标题：Purpose

This chapter provides a rough outline of the design steps to build an AUTOSAR system. The main activities are depicted in Figure . The overall workflow including relevant work products is given in Figure . A brief description of these main steps is given below in section . For a detailed description please refer to the relevant chapters to .

22. 描述¶

原文标题：Description

23. Views on the 系统¶

原文标题：Views on the System

During the development of an AUTOSAR system different views on the system can exist. This allows to refine the system step by step as well as to concentrate on the relevant parts during the development.

Virtual Functional Bus View ⌈ The development of an AUTOSAR System is based on the definition of the Virtual Functional Bus (VFB). The VFB is an abstract communication mechanism that allows software components to interact. This view is independent of any ECUs and networks used. Based on the VFB the system is designed. ⌋

Support of different system views ⌈ The views on the system might further be restricted to e.g. the functionality only, or a subsystem. These views are described explicitly, whereas a mapping mechanism is used to express the relation between them. ⌋

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

Abstract system ⌈ The abstract system abstracts from the concrete software architecture and describes e.g. the functional view on the system. ⌋
Overall technical system ⌈ The overall technical system is organized from the software architecture perspective including a topology of ECUs.

24. Overall 工作流¶

原文标题：Overall Workflow

The main activities in order to develop an AUTOSAR system are described briefly in the following. The first step focuses on the development of an abstract system, followed by the description of the VFB development and finally the activities for refining and developing the system further.

Development of a functional view on the system ⌈ The overall workflow starts with an optional activity. In this activity, the Abstract System Description is developed in advance, which represents the overall system from a functional or abstract view (functional architecture). On the one hand, this Abstract System Description might contain VFB-related parts. This information might serve as an input for the development of the VFB later and a mapping between those two views might be established. Please note that during this step the functionality including ports is mapped to software components. Therefore some ports used in the abstract view might not be used in the subsequent development. On the other hand, the Abstract System Description might contain information regarding the topology and the mapping to ECUs. This is then the basis for the development of the concrete System Description. ⌋

25. The role of Extracts¶

Extracts bundle together parts of a System. This allows splitting the task of developing a whole car into subsystems. For example, a System Level Extract covers a system or subsystem, while an ECU Level Extract covers a single EcuInstance. In addition to the extracts that cover the overall VFB architecture (like the System Extract), there are also extracts that cover specific topics. This allows experts to focus on their subtopics (often cross cutting concerns like diagnostics or security).

These extracts evolved over time to facilitate typical working models of automotive projects: some pieces of information are created by specialists, or contain information that has to be exchanged independently from a software binary. In the example of diagnostics, both aspects apply: creating and maintaining diagnostic test routines is often done by specialists, and the information is needed in workshops and for homologation.

An additional benefit of using extracts is that the amount of information is reduced, leading to smaller file sizes and faster tool processing times.

26. 工作流¶

原文标题：Workflow

Process Pattern	Methodology Overview	<	<
Package	AUTOSAR Root::M2::Methodology::Methodology Use Cases::High Level::Methodology Overview	<	<
Brief Description	High level view of the AUTOSAR Methodology	<	<
Description	This Process Patterns contains the typical activities to develop an AUTOSAR system.	<	<
Relation Type	Related Element	Mult.	Note
Aggregates	Develop Application Software	1
Aggregates	Develop Basic Software	1
Aggregates	Develop Sub-System	1
Aggregates	Develop System	1
Aggregates	Develop a VFB System Description	1
Aggregates	Develop an Abstract System Description	1
Aggregates	Integrate Software for ECU	1

27. Develop an 抽象系统描述¶

原文标题：Develop an Abstract System Description

28. 目的¶

原文标题：Purpose

This Activity provides a rough outline of the creation of the Abstract System Description.

29. 描述¶

原文标题：Description

Abstract System Description activity ⌈ Due to the fact that the overall view on vehicle functions can differ from the actual technical definition of the software architectures of individual ECUs, the optional activity Develop an Abstract System Description allows to define a view on the overall system from an 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 the software architecture. ⌋

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

Data Model Development
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 as well.

30. 工作流¶

原文标题：Workflow

Activity	Develop an Abstract System Description	<	<
Package	AUTOSAR Root::M2::Methodology::Methodology Use Cases::System::Develop System	<	<
Brief 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	Mult.	Note
Consumes	System Constraint Description	0..1	In the context of the "Develop an Abstract System Description" activity, the constraints for the abstract or functional view on the system can be provided by the "System Constraint Description".
Consumes	VFB AUTOSAR Standard Package	1..*
Produces	Abstract System Description	1..*
Aggregates	Component Model Development	1
Aggregates	Data Model Development	1
Aggregates	Define VFB Component Constraints	1
Aggregates	Define VFB Top Level	1
Aggregates	Design System	1	In the context of the "Develop an Abstract System Description" activity, not all tasks have to be performed.
Aggregates	Integrate Non AUTOSAR System at VFB level	1
Aggregates	VFB Timing Development	1

31. Develop a VFB 系统描述¶

原文标题：Develop a VFB System Description

32. 目的¶

原文标题：Purpose

This Activity provides a rough outline of the creation of a Virtual Functional Bus view of a System.

33. 描述¶

原文标题：Description

Virtual Functional Bus ⌈ The Virtual Functional Bus (VFB) view of a System shows how the Systems software functions interact independently of any network topology or deployment of features across multiple ECUs. ⌋

For more information on the VFB concept see . For detailed information on the meta-model parts relevant for the VFB see .

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

Data Model Development
Component Model Development
VFB Timing Development
Integrate Non AUTOSAR System at VFB level
Define VFB Safety Information

Data Model Development activity ⌈ In the Data Model Development, the set of VFB Interfaces, VFB Modes, and VFB Types that are used throughout the VFB are defined. Some of these have already been pre-defined by AUTOSAR (so-called "blueprints"). ⌋

Note: See chapter .

Definition of the VFB ⌈ In the Component Model Development activity, the VFB is defined. This can either be done by the use of the abstract VFB as a basis, or is done directly by defining the software components.

34. 工作流¶

原文标题：Workflow

Activity	Develop a VFB System Description	<	<
Package	AUTOSAR Root::M2::Methodology::Methodology Use Cases::VFB::Develop VFB	<	<
Brief 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 any network topology or deployment of features across muliple ECUs. This Activity 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 | Mult. | Note | | Consumes | Abstract System Description | 0..* | The abstract System Description is an optional input for the activity "Develop a VFB System Description". The VFB-related part of the Abstract System Description can be than refined to the concrete "Overall VFB System". Additionally, a mapping between those two views can be established. |

35. Develop 软件 Components¶

原文标题：Develop Software Components

36. Develop an Atomic 软件组件¶

原文标题：Develop an Atomic Software Component

37. 目的¶

原文标题：Purpose

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

38. 描述¶

原文标题：Description

Develop an Atomic Software Component activity ⌈ This is the generic Activity valid for several kinds of Atomic Software Components. The first step is to create design, including the runnables, events, inter-runnable variables, etc. Once this is complete, the contract header files can be created and the software component can be implemented.

Optionally, the safety relevant information for the software component and all contained elements can be defined. If the software component is developed as a SEOOC (Safety Element out of Context) and the safety requirements are not fully known at development time, the ASIL attribute can be set to indicate the integrity level the component was developed for, i.e. in the development process all development process related requirements of ISO 26262 for the specified ASIL have been applied. ⌋

For safety aspects, see chapter .

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

After the component is implemented and successfully compiled, its resources are measured and stored as part of the software component description for further usage by downstream processes.

其余 559 章（内容从略，见纯文本全文）¶

工作流
Develop Application 软件
目的
描述
工作流
Uses Cases for more Specialized 软件 Components
目的
描述
工作流
Develop 系统 and Subsystems
概述
目的
描述
设计系统
目的
描述
工作流
Generate 系统 Extract
目的
描述
工作流
Create ECU 系统描述
目的
描述
工作流
设计 Sub-System
目的
描述
工作流
Generate CpSoftwareCluster Extract
目的
描述
工作流
Generate ECU Extract
目的
描述
工作流
设计 Custom 转换器
目的
描述
工作流
Define 系统 Safety Information
目的
描述
工作流
Develop 基础软件
概述
目的
描述
工作流
设计 BSW
目的
描述
工作流
Develop BSW 模块
目的
描述
工作流
Integrate 软件 for ECU
描述
概述
目的
描述
Inputs to ECU 配置
ECU 配置 Values
工作流
Prepare ECU 配置
描述
工作流
Configure BSW and RTE
描述
工作流
Update ECU 配置
描述
工作流
建模 ECU 时序
工作流
Generate BSW and RTE
描述
工作流
Build Executable
描述
工作流
配置 Classes
配置 Class：Pre-compile Time
描述
工作流
配置 Class：Link Time
描述
工作流
配置 Class：Post-build Time
描述
工作流
different post-build variants in 配置 classes的处理
描述
Components and 服务
目的
描述
工作流
Calibration 概述
目的
描述
工作流
存储映射
目的
描述
工作流
E2E Protection
目的
描述
工作流
诊断 Extract
目的
描述
工作流
Rapid Prototyping
目的
描述
工作流
Safety Information
目的
描述
工作流
Variant 处理
概述
Binding Times
Latest Binding Time
Actual Binding Time
Defining Variants
Choosing Variants
定义 of Binding Times
概述
A Classification of Artifacts with respect to Binding Times
Classification of Binding Times
BlueprintDerivationTime
FunctionDesignTime
InitialBindingTime
SystemDesignTime
CodeGenerationTime
PreCompileTime
CompileTime
LinkTime
PostBuild
Runtime
How to resolve Name Conflicts
Reasons for Name Conflicts
Points in the Methodology where Name Conflicts are resolved
Mechanisms for resolving Name Conflicts
Methodology 库
Common Elements
Work Product Kinds
Tasks
Add 通用 Documentation
Define Admin 数据
Define Alias Names
Evaluate Variant
Define 存储 Addressing Modes
Configure Memmap Allocation
Generate BSW 存储映射 Header
Generate SWC 存储映射 Header
Work Products
通用 Documentation
Alias Name Set
Evaluated Variant Set
Autosar 规范
通用 Autosar Artifact
通用 Deliverable
通用 Non-Autosar Artifact
Postbuild Variant Set
Predefined Variant
Standard Header Files
系统 Constant Value Set
Roles
Tools
Compiler
Linker
诊断
Work Products
Safety
Tasks
Define Safety Requirement
Define Safety Measure
Define ASIL For AUTOSAR Element
Refine Safety Requirement
Decompose Safety Requirement
Allocate Safety Measure
Allocate Safety Requirement
映射 Safety Requirement to Safety Measure
Add Independence Relation
Work Products
Safety Information
Safety Requirement
Safety Measure
Virtual 功能性 Bus
Tasks
Define VFB Top Level
Define VFB Composition 组件
Extend Composition
Define VFB 组件 Constraints
Define VFB Application 软件组件
Define VFB Sensor or Actuator 组件
Define VFB Parameter 组件
Define ECU 抽象组件
Define Complex 驱动组件
Define VFB NvBlock 软件组件
Define Wrapper Components to Integrate Legacy 软件
Define VFB 接口
Define VFB 类型
Define VFB Modes
Define VFB Constants
Define VFB 时序
Define VFB Variants
Define VFB 集成 Connector
Translate Non-AUTOSAR 描述 to AUTOSAR 描述
Work Products
VFB 系统
Overall VFB 系统
VFB 系统 Extract
VFB Top Level 系统 Composition
VFB Composition 组件
VFB AUTOSAR Standard Package
Application 接口的AUTOSAR 规范
VFB Atomic 软件组件
VFB Atomic Application 软件组件
Complex 驱动组件
ECU 抽象软件组件
VFB Parameter 组件
VFB Sensor Actuator 组件
VFB NvBlock 软件组件
VFB Non AUTOSAR 组件
VFB 接口
VFB 类型
VFB 数据类型映射 Set
VFB Modes
VFB Constants
VFB 软件组件映射 Constraints
VFB 时序
a Non-AUTOSAR 系统的描述
集成 Connector
系统
Tasks
Set 系统 Root
Assign Top Level Composition
Define ECU 描述
Define 系统 Topology
Deploy 软件组件
设计 CpSoftwareCluster
Extend CpSoftwareCluster
Generate or Adjust 系统 Flat 映射
Derive Communication Needs
Define Signal Path Constraints
Define 系统 Variants
Define 系统时序
Define Security Events
Extend Topology
Select 软件组件 Implementation
Select 设计 Time Variant
Define 系统视图映射
Create 转换器规范
Define Rapid Prototyping Scenario
Define 集成需求
Work Products
系统描述
抽象系统描述
Complete ECU 描述
CpSoftwareCluster Extract
系统描述 Root Element
系统映射概述
数据映射
软件 Components to ECUs的映射
软件 Components to Implementations的映射
Signal Path Constraints
Topology
Ecu Resources 描述
系统 Signal
系统 Signal Group
系统 Flat 映射
系统时序
Security Extract
系统视图映射
转换器设计 Bundle
Custom 转换器规范
Rapid Prototyping Scenario
集成需求
Communication Matrix and Communication Layers
Tasks
Define Communication Matrix
Define Frames
Define Signal PDUs
Define Secured PDUs
Define TP
Define 网络管理
Define PDU Gateway
Define Signal Gateway
Define RTE Fan-out
Define Transformation Technology
Define E2E 转换器 Technology
Define Transformation Chain
Work Products
Communication Layers
Communication Matrix
数据 Link Layer
Interaction Layer
诊断 Interaction Layer
网络 Layer
Serializer 转换器
E2E 转换器
ECU Extract
Tasks
Extract ECU Topology
Generate or Adjust ECU Flat 映射
Flatten 软件 Composition
Extract the ECU Communication
Extract the ECU 时序建模
Extract the ECU 系统 Variant 建模
Extract ECU Rapid Prototyping Scenario
Work Products
ECU Extract
ECU Extract Root Element
ECU Extract of VFB 系统
ECU Extract of 数据映射
ECU Extract of Topology
ECU Extract for Communication
ECU Extract of 系统时序
ECU Extract of 系统 Variant 建模
ECU Flat 映射
ECU Extract of Rapid Prototyping Scenario
软件组件
Tasks
Define 软件组件 Internal 行为
Define Partial Flat 映射
Define 软件组件时序
Define SymbolProps for 类型
Add Documentation to the 软件组件
Generate Atomic 软件组件 Contract Header Files
Generate 组件 Header 文件 in Vendor 模式
Generate 组件 Prebuild 数据 Set
Implement Atomic 软件组件
Compile Atomic 软件组件
映射软件组件 to BSW
Measure 组件 Resources
Recompile 组件 in ECU Context
Define Consistency Needs
Generate Rapid Prototyping Wrapper
Work Products
Delivered Atomic 软件 Components
软件组件 Internal 行为
Atomic 软件组件 Implementation
软件组件 Documentation
软件组件时序
软件组件 to BSW 映射
Partial Flat 映射
Application Header 文件
软件组件数据类型 Header
组件 RTE Prebuild 配置 Header
Atomic 软件组件 Source 代码
Atomic 软件组件 Object 代码
Optimized Application Header 文件
Optimized 软件组件 Object 代码
Consistency Needs
Rapid Prototyping Wrapper Header 文件
Rapid Prototyping Wrapper Source 代码
Tools
组件 API Generator Tool
基础软件
Tasks
Define BSW 类型
Define BSW Entries
Define BSW 接口
Define Vendor Specific 模块定义
Define BSW 行为
Define BSW 模块时序
Generate BSW Contract Header Files
Implement a BSW 模块
Develop BSW 模块 Generator
Create 库
Compile BSW 核代码
Generate BSW 模块 Prebuild Dataset
Work Products
BSW Standard Package
BSW 模块 Bundle
BSW 设计 Bundle
BSW 模块 ICS Bundle
BSW 模块 Delivered Bundle
AUTOSAR 软件模块规范
AUTOSAR Standard 类型 and Blueprints
AUTOSAR Platform 类型 and Blueprints
BSW 模块 Generator
AUTOSAR Standardized ECU 配置 Parameter 定义
BSW 模块 Preconfigured 配置
BSW 模块 Recommended 配置
BSW 模块 Vendor Specific 配置 Parameter 定义
BSW 类型
基础软件 Entries
基础软件模块描述
基础软件模块 Internal 行为
基础软件模块 Implementation 描述
Build Action 清单
基础软件模块时序
基础软件模块核 Header
基础软件模块核 Source 代码
基础软件 Interlink Header
基础软件 Interlink 类型 Header
BSW RTE Prebuild 配置 Header
基础软件模块 Object 代码
库描述
库 Header Files
库 Object 代码
Custom 转换器
ECU 集成 and 配置
Tasks
Provide RTE Calibration Dataset
Define 集成 Variant
Generate Base ECU 配置
Generate Updated ECU 配置
Define ECU 时序
Configure EcuC
Configure OS
Configure RTE
Configure Watchdog 管理器
Configure 模式管理
Configure NvM
Configure 诊断
Create 服务组件
Connect 服务组件
Configure COM
Configure IO Hardware 抽象
Configure MCAL
Configure 转换器
Generate BSW 配置代码 and 建模 Extensions
Generate Local MC 数据支持
Create MC 功能建模
Generate RTE
Generate Scheduler
Generate OS
Generate RTE Prebuild Dataset
Compile ECU Source 代码
Generate ECU Executable
Generate RTE Postbuild Dataset
Generate A2L
Measure Resources
Refine Rapid Prototyping Scenario
Merge CpSoftwareCluster
Work Products
BSW 模块集成 Bundle
ECU 软件 Delivered
服务组件描述
ECU 服务 Connectors
ECU 时序
BSW 模块接口 Extension
BSW 模块行为 Extension
BSW 模块 Implementation Extension
ECU 配置 Values
RTE Implementation 描述
RTE Prebuild 配置 Header
Calibration Parameter Value Set
MC 功能建模
Local Measurement and Calibration 支持数据
RTE Measurement and Calibration 支持数据
RTE Source 代码
BSW Scheduler 代码
OS Generated 代码
RTE Postbuild Variants Dataset
ECU Object 代码
ECU Executable
Merged ECU Executable
映射 of the ECU Executable
A2L 文件
MC 驱动支持数据
MC Additional Config
Tools
RTE Generator
BSW Generator Framework
ECU Config Classes
Tasks
Compile Unconfigured Bsw
Compile Configured Bsw
Compile BSW 配置数据
Compile Generated BSW
Generate BSW Precompile 配置 Header
Generate BSW Source 代码
Generate BSW 配置代码
Generate BSW Postbuild 配置代码
Link ECU 代码 after Precompile 配置
Link ECU 代码 During Link Time 配置
Link ECU 代码 During Post-build Time
Work Products
BSW 模块配置 Header 文件
BSW 模块 Completely Generated Source 代码
BSW 模块配置数据 Source 代码
BSW 模块配置数据 Object 代码
BSW 模块配置数据 Loadable to ECU 存储
附录
Mentioned Class Tables
Change History
Change History of this document according to AUTOSAR Release R4.1.1
Added 规范 Items in 4.1.1
Changed 规范 Items in 4.1.1
Deleted 规范 Items in 4.1.1
Change History of this document according to AUTOSAR Release R4.1.2
Added 规范 Items in 4.1.2
Changed 规范 Items in 4.1.2
Deleted 规范 Items in 4.1.2
Change History of this document according to AUTOSAR Release R4.1.3
Added 规范 Items in 4.1.3
Changed 规范 Items in 4.1.3
Deleted 规范 Items in 4.1.3
Change History of this document according to AUTOSAR Release R4.2.1
Added 规范 Items in 4.2.1
Changed 规范 Items in 4.2.1
Deleted 规范 Items in 4.2.1
Change History of this document according to AUTOSAR Release R4.2.2
Added 规范 Items in 4.2.2
Changed 规范 Items in 4.2.2
Deleted 规范 Items in 4.2.2
Change History of this document according to AUTOSAR Release R4.3.0
Added 规范 Items in 4.3.0
Changed 规范 Items in 4.3.0
Deleted 规范 Items in 4.3.0
Change History of this document according to AUTOSAR Release R4.3.1
Added 规范 Items in 4.3.1
Changed 规范 Items in 4.3.1
Deleted 规范 Items in 4.3.1
Change History of this document according to AUTOSAR Release R4.4.0
Added 规范 Items in 4.4.0
Changed 规范 Items in 4.4.0
Deleted 规范 Items in 4.4.0
Change History of this document according to AUTOSAR Release R19-11
Added 规范 Items in 19-11
Changed 规范 Items in 19-11
Deleted 规范 Items in 19-11
Change History of this document according to AUTOSAR Release R20-11
Added 规范 Items in R20-11
Changed 规范 Items in R20-11
Deleted 规范 Items in R20-11
Change History of this document according to AUTOSAR Release R21-11
Added 规范 Items in R21-11
Changed 规范 Items in R21-11
Deleted 规范 Items in R21-11
Change History of this document according to AUTOSAR Release R22-11
Added 规范 Items in R22-11
Changed 规范 Items in R22-11
Deleted 规范 Items in R22-11
Change History of this document according to AUTOSAR Release R23-11
Added 规范 Items in R23-11
Changed 规范 Items in R23-11
Deleted 规范 Items in R23-11
Change History of this document according to AUTOSAR Release R24-11
Added 规范 Items in R24-11
Changed 规范 Items in R24-11
Deleted 规范 Items in R24-11
Change History of this document according to AUTOSAR Release R25-11
Added 规范 Items in R25-11
Changed 规范 Items in R25-11
Deleted 规范 Items in R25-11
Change History of this document according to AUTOSAR Release R26-11
Added 规范 Items in R26-11
Changed 规范 Items in R26-11
Deleted 规范 Items in R26-11

Methodology for Classic Platform (Methodology)¶

本地文件¶

模块依赖¶

章节详细内容¶

1. 简介¶

2. Objective¶

3. Document Conventions¶

4. 范围¶

5. Terms and Abbreviations¶

6. 概述¶

7. Methodology 概念¶

8. Methodology 库 Elements¶

9. Task 定义¶

10. Work Product 定义¶

11. Role 定义¶

12. Tool 定义¶

13. Guidance¶

14. Use Case Specifications¶

15. Activity¶

16. Capability Pattern¶

17. 描述 of Use Cases¶

18. 通用需求¶

19. Use Cases¶

20. Overall 视图¶

21. 目的¶

22. 描述¶

23. Views on the 系统¶

24. Overall 工作流¶

25. The role of Extracts¶

26. 工作流¶

27. Develop an 抽象系统描述¶

28. 目的¶

29. 描述¶

30. 工作流¶

31. Develop a VFB 系统描述¶

32. 目的¶

33. 描述¶

34. 工作流¶

35. Develop 软件 Components¶

36. Develop an Atomic 软件组件¶

37. 目的¶

38. 描述¶

其余 559 章（内容从略，见纯文本全文）¶

Methodology for Classic Platform (`Methodology`)¶