feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f5197069cbded395b8b3d866701fad6ae5ce965f
autosar_standard_spec_v4.4/MethodologyAndTemplates/AUTOSAR_TR_Methodology.md
T

24 KiB
Raw Blame History

方法论

AUTOSAR CP Release 4.4.0

元信息

项目 内容
文档标题 Methodology（方法论）
文档所有者 AUTOSAR
文档责任方 AUTOSAR
文档标识号 068
文档状态 Final（最终版）
AUTOSAR 标准组成部分 Classic Platform（经典平台）
标准发布版本 4.4.0

文档变更历史

日期 发布版本 变更人 描述
2018-10-31 4.4.0 AUTOSAR Release Management • 删除了对过时需求的引用
• 编辑性变更
2017-12-08 4.3.1 AUTOSAR Release Management • 由于修改了一项需求而进行的细微修正
• 编辑性变更
2016-11-30 4.3.0 AUTOSAR Release Management • 增加了对数据交换点（Data Exchange Points）的支持
• 细微修正/澄清/编辑性变更
2015-07-31 4.2.2 AUTOSAR Release Management • 细微修正和编辑性变更
2014-10-31 4.2.1 AUTOSAR Release Management • 增加了对安全扩展（Safety Extensions）的支持
• 增加了对诊断提取（Diagnostic Extract）的支持
• 增加了对快速原型（Rapid Prototyping）的支持
• 增加了对发送者-接收者序列化（Sender Receiver Serialization）的支持
2014-03-31 4.1.3 AUTOSAR Release Management • AUTOSAR 方法论与系统描述类别的对齐
• 编辑性变更
2013-10-31 4.1.2 AUTOSAR Release Management • ECU 配置规范与 AUTOSAR 方法论之间的协调
2013-03-15 4.1.1 AUTOSAR Release Management • 允许在规范项中使用需求 ID 定义和追踪
• 更新了第 3.6 章 ECU 集成和配置，增加了对 A2L 函数的支持
• 添加了第 2.14 章"如何解决名称冲突"
• 添加了第 3.4.1.15 节"定义一致性需求"和第 3.4.2.17 节"一致性需求"
2011-12-22 4.0.3 AUTOSAR Administration • 完善了绑定时间的定义
• 通过删除任务使用并在用例级别引入可交付成果来简化用例图（见方法论概念章节）
• 通过生成具有可导航链接的表来提高可读性
• 引入了变体处理、E2E 支持、系统约束描述
• 完善了方法论库，包括在不同用例中扩展可交付成果
• 更改了 SPEM 模型的工具平台
• 以 pdf 文件发布而不是 html
• 对模型元素使用新的表格式
• 添加了 SPEM 图表
2009-12-18 4.0.1 AUTOSAR Administration • 详细说明了方法论概念章节
• 添加了内存映射用例
• 重做并重组了用例以提高可读性
• 在图形和表中直接引用元模型元素
2008-08-13 3.1.1 AUTOSAR Administration • 修改了法律免责声明
• 增强了当前版本限制的子章节
2007-12-21 3.0.1 AUTOSAR Administration • 扩展了文档元信息
• 进行了小型布局调整
2007-01-24 2.1.15 AUTOSAR Administration • 更新了第 5 章 ECU 设计
• 更新了第 6.1 章"与 Services 的关系"
• 修改了法律免责声明
• 添加了发布说明
• 修订了用户建议
• 添加了修订信息
2006-05-16 2.0 AUTOSAR Administration • 初始发布

翻译说明：本文档为方法论规范（515 页）。根据翻译策略，封面、文档标识、变更历史、目录、核心章节（介绍、方法论概念、用例概览、几个核心用例的描述、变体处理、绑定时间、命名冲突、数据交换点）已完整翻译关键内容；详细的工作流步骤、角色定义、工具定义、工作产品定义（超过 100+ 个工作产品）等采用摘要处理并指向原文 PDF。

目录

  1. 介绍
  2. 用例
  3. 方法论库

1 介绍

1.1 目标

本文档是 AUTOSAR 方法论的规范。AUTOSAR 方法论描述了在 AUTOSAR 系统开发过程中需要执行的活动、所需的可交付成果（工作产品）以及参与的角色和工具。

方法论的目标是：

  • 提供 AUTOSAR 系统开发的统一方法。
  • 描述开发活动之间的依赖关系。
  • 定义可交付成果。
  • 支持工具互操作性。

1.2 文档约定

技术术语以等宽字体排版，例如 PortPrototype。

本文档采用 SPEM 2.0（Software Process Engineering Meta-Model）作为建模方法论流程的元模型。

1.3 范围

本文档的范围是：

  • 描述 AUTOSAR 系统开发所需的主要活动。
  • 定义每个活动的输入、输出和角色。
  • 提供工作产品（Work Product）的定义。
  • 描述变体处理、绑定时间、命名冲突解决等横向关注点。

本文档不涉及：

  • 具体工具的实现细节。
  • 元模型元素的详细定义（详见各模板规范）。
  • AUTOSAR 标准的具体技术细节。

1.4 概述

AUTOSAR 方法论采用两层组织结构：

  • 用例（Use Cases）：描述开发活动，例如"开发一个抽象系统描述"、"开发软件组件"等。
  • 方法论库（Methodology Library）：提供可重用的元素，如任务、工作产品、角色、工具等。

每个用例都包含：

  • 目的（Purpose）：用例的目标。
  • 描述（Description）：用例的详细描述。
  • 工作流（Workflow）：用例的工作流图和说明。

1.5 方法论概念

1.5.1 方法论库元素

方法论库包含可重用的方法论元素。

1.5.1.1 任务定义（Task Definition）

TaskDefinition 元类描述一个任务，定义：

  • 任务的名称和描述。
  • 任务的输入和输出。
  • 执行任务所需的能力。
1.5.1.2 工作产品定义（Work Product Definition）

WorkProductDefinition 元类描述一个工作产品，定义：

  • 工作产品的名称和描述。
  • 工作产品的类型（如文档、模型、代码）。
  • 工作产品的责任方。
1.5.1.3 角色定义（Role Definition）

RoleDefinition 元类描述一个角色，定义：

  • 角色的名称和描述。
  • 角色的责任。
1.5.1.4 工具定义（Tool Definition）

ToolDefinition 元类描述一个工具，定义：

  • 工具的名称和描述。
  • 工具的功能。
1.5.1.5 指南（Guidance）

Guidance 提供关于如何执行任务的建议。

1.5.2 用例规范

1.5.2.1 活动（Activity）

活动是 AUTOSAR 方法论中的主要工作单元。

1.5.2.2 能力模式（Capability Pattern）

能力模式定义了一组可重用的活动。

1.5.2.3 用例描述

每个用例都有目的、描述和工作流三部分。

1.6 需求追踪

需求追踪表引用了 AUTOSAR RS_METH_* 系列需求，并指出它们在本文档中如何被满足。

主要需求包括：

  • [RS_METH_00006]：AUTOSAR 方法论
  • [RS_METH_00018]：软件组件开发
  • [RS_METH_00077]：ECU 系统描述
  • [RS_METH_00208]：分阶段开发
  • 等等

完整需求追踪表见原文 PDF 第 33-37 页

2 用例

2.1 整体视图

2.1.1 目的

整体视图提供了 AUTOSAR 方法论中所有用例的概览。

2.1.2 描述

2.1.2.1 系统的视图

AUTOSAR 系统可以从多个视图来看待：

  • 车辆视图（Vehicle View）：从整车角度看的系统。
  • 系统视图（System View）：从车辆电气/电子系统的角度看的系统。
  • ECU 视图（ECU View）：从单个 ECU 的角度看的系统。
  • 软件组件视图（SW-C View）：从软件组件的角度看的系统。
  • 实现视图（Implementation View）：从代码实现的角度看的系统。
2.1.2.2 整体工作流

AUTOSAR 方法论的整体工作流包含以下主要活动：

  1. 开发抽象系统描述（Develop an Abstract System Description）：定义系统的高级功能需求。
  2. 开发 VFB 系统描述（Develop a VFB System Description）：在 VFB 级别定义系统。
  3. 开发软件组件（Develop Software Components）：实现软件组件。
  4. 开发系统和子系统（Develop System and Subsystems）：在系统级别设计系统。
  5. 开发基本软件（Develop Basic Software）：实现 BSW 模块。
  6. 为 ECU 集成软件（Integrate Software for ECU）：将软件集成到 ECU 中。
[BSW 标准包] → [开发抽象系统描述] → [抽象系统描述]
       ↓                              ↓
       ↓            [VFB AUTOSAR 标准包] → [开发 VFB 系统描述]
       ↓                              ↓
       ↓                              ↓
   [系统约束]              [整体 VFB 系统] ←── [整体 VFB 系统描述]
       ↓                              ↓
       ↓                       [系统提取 1] ←── [开发系统]
       ↓                              ↓
[开发基本软件]                  [开发子系统]
       ↓                              ↓
       ↓                       [ECU 提取]
       ↓                              ↓
       ↓                       [开发应用软件]
       ↓                              ↓
       [BSW 模块交付包]     [原子软件组件]
       ↓                              ↓
       └──────────[为 ECU 集成软件]────────┘
                          ↓
                  [ECU 软件交付]

图 2.8/2.9：方法论概览 - 整体结构和工作流

[TR_METH_01047] 两阶段开发方法 d 当存在组织责任分离时使用两阶段方法，其中主要组织（通常是 OEM）在第一阶段定义整个系统，其他几个组织（通常是供应商）在第二阶段并行定义子系统。在这种情况下，主要组织移交代表整个系统的子系统的系统提取。这些子系统包含子系统 VFB，它们是整体 VFB 的一部分。 c (RS_METH_00006, RS_METH_00208)

[TR_METH_01048] 整体系统 d 整体系统定义主要的公共 ECU 和拓扑，子系统设计通过添加私有 ECU 和网络到系统来做出贡献。请注意，在子系统内定义的部分不直接对任何其他子系统或整体系统可见。 c (RS_METH_00006)

[TR_METH_01049] 组织之间的交互 d 此外，主要组织交付的系统提取的软件组件结构可以通过接收组织（ECU 系统描述）转换为每个 ECU 的不同结构。在这种情况下，主要组织的系统提取可被视为需求，接收组织的子系统（由一个或多个 ECU 系统描述表示）可被视为必须满足已交付需求的解决方案。 c (RS_METH_00006, RS_METH_00077)

[TR_METH_01109] 产生特定于 ECU 的可交付成果 d 系统设计完成后，与特定 ECU 相关的部分被提取，为每个 ECU 产生一个可交付成果，即所谓的 ECU 提取。与系统或 ECU 的先前描述相比，ECU 提取完全分解并且仅包含原子软件组件。它是 ECU 配置的基础。 c (RS_METH_00006, RS_METH_00208)

[TR_METH_01110] 软件组件的开发 d 与系统设计并行，软件组件（已交付的原子软件组件）根据抽象 VFB、VFB 或子系统 VFB 所需的定义来实现。基于 VFB 定义的外部接口，可以定义内部行为并最终实现软件组件。软件组件被交付以集成到 ECU 中，在那里它们被部署。请注意，软件组件的实现很大程度上独立于 ECU 的配置。这是 AUTOSAR 方法论的一个关键特性。 c (RS_METH_00006, RS_METH_00018, RS_METH_00208)

[TR_METH_01111] 基本软件模块的开发 d 由于基本软件模块独立于 VFB，它们可以在 ECU 集成之前的任何时间开发。 c (RS_METH_00006)

[TR_METH_01112] AUTOSAR ECU 的集成 d 当 BSW 模块交付包、ECU 提取和所有已交付原子软件组件的实现都可用时，AUTOSAR ECU 的集成开始。在此阶段，ECU 被配置。通过调度任务定义执行顺序，并将软件组件 Runnables 分配给这些任务。最后，基本软件模块被配置。生成 RTE 后，完整的代码被编译并链接到可执行文件中。 c (RS_METH_00006, RS_METH_00208)

2.1.3 工作流

图 2.8 显示了 AUTOSAR 方法论中主要活动的整体结构。图 2.9 显示了工作流和可交付成果之间的依赖关系。

过程模式 方法论概览
包 AUTOSAR Root::M2::Methodology::Methodology Use Cases::High Level::Methodology Overview
简要描述 AUTOSAR 方法论的高层视图
描述 此过程模式包含开发 AUTOSAR 系统的典型活动
关系类型 相关元素 / 数量 / 说明
聚合 开发应用软件 / 1
聚合 开发基本软件 / 1
聚合 开发子系统 / 1
聚合 开发系统 / 1
聚合 开发 VFB 系统描述 / 1
聚合 开发抽象系统描述 / 1
聚合 为 ECU 集成软件 / 1

表 2.1：方法论概览

2.2 开发抽象系统描述

2.2.1 目的

此活动提供抽象系统描述创建的大纲。

2.2.2 描述

[TR_METH_01050] 抽象系统描述活动 d 由于对车辆功能的整体视图可能与系统的实际技术定义不同，因此有必要在早期阶段对车辆功能进行概要描述。 c()

2.2.3 工作流

抽象系统描述活动的工作流包括：

  1. 定义车辆功能。
  2. 定义功能需求。
  3. 描述功能交互。

2.3 开发 VFB 系统描述

2.3.1 目的

此活动在 VFB 级别定义系统。

2.3.2 描述

VFB 系统描述是 AUTOSAR 系统的核心描述，定义了系统中的所有软件组件及其交互。

2.3.3 工作流

VFB 系统描述活动的工作流包括：

  1. 定义软件组件类型。
  2. 定义端口和接口。
  3. 定义数据类型。
  4. 描述组件交互。
  5. 定义组件到 ECU 的映射。

2.4 开发软件组件

2.4.1 开发原子软件组件

2.4.1.1 目的

开发一个原子软件组件。

2.4.1.2 描述

原子软件组件是 AUTOSAR 系统中的基本部署单元。

2.4.1.3 工作流

工作流包括：

  1. 定义组件接口。
  2. 定义内部行为。
  3. 实现组件。
  4. 编译和打包。

2.4.2 开发应用软件

2.4.2.1 目的

开发应用软件（由多个原子软件组件组成）。

2.4.2.2 描述

应用软件开发涉及多个原子软件组件的设计、实现和集成。

2.4.2.3 工作流

工作流包括：

  1. 设计组件结构。
  2. 实现组件。
  3. 集成组件。
  4. 测试组件。

2.4.3 更专门化软件组件的用例

2.4.3.1 目的

更专门化的软件组件（如模式管理、诊断、标定）。

2.4.3.2 描述

这些组件具有特殊功能。

2.4.3.3 工作流

2.5 开发系统和子系统

2.5.1 概述

2.5.1.1 目的

设计整个系统，包括整体系统和子系统。

2.5.1.2 描述

系统设计包括 ECU 拓扑、通信配置等。

2.5.2 设计系统

2.5.2.1 目的

设计完整的 AUTOSAR 系统。

2.5.2.2 描述
2.5.2.3 工作流

2.5.3 生成系统提取

2.5.3.1 目的

从整体系统生成系统提取。

2.5.3.2 描述
2.5.3.3 工作流

2.5.4 创建 ECU 系统描述

2.5.4.1 目的

为每个 ECU 创建系统描述。

2.5.4.2 描述
2.5.4.3 工作流

2.5.5 设计子系统

2.5.5.1 目的

设计子系统的详细结构。

2.5.5.2 描述
2.5.5.3 工作流

2.5.6 生成 ECU 提取

2.5.6.1 目的

从系统描述生成 ECU 提取。

2.5.6.2 描述
2.5.6.3 工作流

2.5.7 设计自定义转换器

2.5.7.1 目的

设计自定义转换器以转换数据。

2.5.7.2 描述
2.5.7.3 工作流

2.5.8 定义系统安全信息

2.5.8.1 目的

定义系统级安全信息。

2.5.8.2 描述
2.5.8.3 工作流

2.6 开发基本软件

2.6.1 概述

2.6.1.1 目的

开发 AUTOSAR 基本软件（BSW）。

2.6.1.2 描述

BSW 模块独立于 VFB，可以在任何时候开发。

2.6.1.3 工作流

2.6.2 设计 BSW

2.6.2.1 目的

设计 BSW 模块。

2.6.2.2 描述
2.6.2.3 工作流

2.6.3 开发 BSW 模块

2.6.3.1 目的

实现 BSW 模块。

2.6.3.2 描述
2.6.3.3 工作流

2.7 为 ECU 集成软件

2.7.1 描述

ECU 软件集成是 AUTOSAR 方法论中的最后阶段，将所有软件组件、BSW 模块、RTE 集成到一个可执行文件中。

2.7.2 概述

2.7.2.1 目的

集成所有软件到 ECU 中。

2.7.2.2 描述
2.7.2.3 工作流

2.7.3 准备 ECU 配置

2.7.3.1 描述
2.7.3.2 工作流

2.7.4 配置 BSW 和 RTE

2.7.4.1 描述
2.7.4.2 工作流

2.7.5 更新 ECU 配置

2.7.5.1 描述
2.7.5.2 工作流

2.7.6 建模 ECU 时序

2.7.6.1 工作流

2.7.7 生成 BSW 和 RTE

2.7.7.1 描述
2.7.7.2 工作流

2.7.8 构建可执行文件

2.7.8.1 描述
2.7.8.2 工作流

2.7.9 配置类

2.7.9.1 配置类：预编译时间
2.7.9.2 配置类：链接时间
2.7.9.3 配置类：Post-build 时间
2.7.9.4 处理配置类中的不同 post-build 变体

2.8 组件和服务

2.8.1 目的

定义 AUTOSAR 组件和服务的开发。

2.8.2 描述

2.8.3 工作流

2.9 标定概览

2.9.1 目的

定义标定流程。

2.9.2 描述

标定是在 ECU 上调整参数以优化系统行为的过程。

2.9.3 工作流

2.10 内存映射

2.10.1 目的

定义内存映射流程。

2.10.2 描述

内存映射将软件元素分配到物理内存段。

2.10.3 工作流

2.11 E2E 保护

2.11.1 目的

定义端到端（E2E）保护流程。

2.11.2 描述

E2E 保护用于在通信过程中检测错误。

2.11.3 工作流

2.12 诊断提取

2.12.1 目的

定义诊断提取流程。

2.12.2 描述

诊断提取是用于交换诊断配置数据的格式（详见 [AUTOSAR_TPS_DiagnosticExtractTemplate]）。

2.12.3 工作流

2.13 快速原型

2.13.1 目的

定义快速原型流程。

2.13.2 描述

快速原型允许在 ECU 上运行未优化的算法。

2.13.3 工作流

2.14 安全扩展

2.14.1 目的

定义安全扩展流程。

2.14.2 描述

安全扩展用于满足 ISO 26262 等功能安全标准。

2.14.3 工作流

2.15 变体处理

2.15.1 概述

变体处理（Variant Handling）用于管理 AUTOSAR 系统中的多个变体。变体是同一系统的不同配置或实现。

2.15.2 绑定时间

绑定时间定义变体被绑定（即最终确定）的时间点。

2.15.2.1 最晚绑定时间

最晚绑定时间（Latest Binding Time）是变体可被绑定的最晚时间点。

2.15.2.2 实际绑定时间

实际绑定时间（Actual Binding Time）是变体实际被绑定的时间点。

2.15.3 定义变体

变体通过 VariationPoint 元素定义。

2.15.4 选择变体

变体可在编译时、链接时、post-build 时或运行时选择。

2.16 绑定时间的定义

2.16.1 概述

AUTOSAR 方法论定义了一组绑定时间，每个绑定时间对应于开发过程中的一个阶段。

2.16.2 关于绑定时间的制品分类

不同制品在不同的绑定时间被绑定。

2.16.3 绑定时间的分类

绑定时间分类如下：

2.16.3.1 BlueprintDerivationTime

蓝图派生时间。

2.16.3.2 FunctionDesignTime

功能设计时间。

2.16.3.3 InitialBindingTime

初始绑定时间。

2.16.3.4 SystemDesignTime

系统设计时间。

2.16.3.5 CodeGenerationTime

代码生成时间。

2.16.3.6 PreCompileTime

预编译时间。

2.16.3.7 CompileTime

编译时间。

2.16.3.8 LinkTime

链接时间。

2.16.3.9 PostBuild

Post-build 时间。

2.16.3.10 Runtime

运行时间。

2.17 如何解决名称冲突

2.17.1 名称冲突的原因

在 AUTOSAR 系统开发中，名称冲突可能由于以下原因产生：

  • 多个组织使用相同的名称。
  • 多个组件类型使用相同的端口名称。
  • 等等。

2.17.2 方法论中解决名称冲突的点

2.17.3 解决名称冲突的机制

AUTOSAR 提供了多种解决名称冲突的机制：

  • 使用 vendorApiInfix 区分不同供应商的实现。
  • 使用 vendorId 和 vendorSpecificElement 标记供应商特定元素。
  • 使用分层命名空间。

2.18 数据交换点

2.18.1 目的

数据交换点（Data Exchange Points）用于在 AUTOSAR 方法论的不同阶段之间定义明确的数据交换接口。

2.18.2 描述

数据交换点指定：

  • 交换的数据。
  • 交换的格式。
  • 交换的时机。
  • 交换的责任方。

2.18.3 工作流

完整内容见原文 PDF 第 38-181 页

3 方法论库

3.1 公共元素

3.1.1 工作产品种类

工作产品（Work Product）种类包括：

  • 文档（Document）
  • 模型（Model）
  • 代码（Code）
  • 配置（Configuration）
  • 可执行文件（Executable）
  • 等等

3.1.2 任务

主要任务包括：

3.1.2.1 添加一般文档
3.1.2.2 定义管理数据
3.1.2.3 定义别名
3.1.2.4 评估变体
3.1.2.5 定义内存寻址模式
3.1.2.6 配置 Memmap 分配
3.1.2.7 生成 BSW 内存映射头文件
3.1.2.8 生成 SWC 内存映射头文件
3.1.2.9 配置编译器内存类
3.1.2.10 生成编译器配置

3.1.3 工作产品

主要工作产品包括：

3.1.3.1 一般文档
3.1.3.2 别名集
3.1.3.3 评估的变体集
3.1.3.4 Autosar 规范
3.1.3.5 一般 Autosar 制品
3.1.3.6 一般可交付成果
3.1.3.7 一般非 Autosar 制品
3.1.3.8 Post-build 变体集
3.1.3.9 预定义变体
3.1.3.10 标准头文件
3.1.3.11 系统常量值集

3.1.4 角色

主要角色包括：

  • OEM：原始设备制造商
  • Tier-1：一级供应商
  • Tier-2：二级供应商
  • 集成商：ECU 集成商
  • 应用开发者
  • 系统设计者
  • BSW 开发者
  • 等等

3.1.5 工具

主要工具包括：

3.1.5.1 编译器
3.1.5.2 链接器

3.1.6 诊断

3.1.6.1 工作产品

完整方法论库（包含所有任务、工作产品、角色、工具的详细定义）见原文 PDF 第 182-515 页

翻译说明

  1. 保留内容：所有 API 标识符（TaskDefinition、WorkProductDefinition 等）、UML 类名、属性名、ARXML 标签、AUTOSAR 方框符 ⌈⌋、需求 ID（RS_METH_xxxxx、TR_METH_xxxxx 等）、文档标识号。
  2. 翻译内容：标题、描述性文字、章节概述、用例的 Purpose/Description/Workflow 概述、规范项的措辞、术语。
  3. 策略：封面、文档标识、变更历史、目录、第 1-2 章（核心内容）已翻译关键概念和主要用例的概述；详细的工作流步骤、角色定义、工具定义、工作产品定义（约 100+ 个工作产品）采用摘要处理，列出主要分类和小节名，并指向原文 PDF。
  4. 代码块：UML 图使用代码块简化展示，详细图示见原文 PDF；使用伪图表示方法论概览的工作流。
  5. 约束/规范标记：保留 [TR_METH_xxxxx]、[RS_METH_xxxxx]、[constr_xxxx] 等 ID 标识。

主要文档 ID：068（AUTOSAR_TR_Methodology）

翻译版本：基于 AUTOSAR CP Release 4.4.0

Reference in New Issue View Git Blame Copy Permalink