Methodology
参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
AUTOSAR_FO_RS_Main
1. 引言¶
本文档定义规定 AUTOSAR 方法论所需的需求。
本文档分为多个小节：AUTOSAR 方法论的通用需求见 第 2.1 节，经典平台（CP）的专用需求见 第 2.2 节，自适应平台（AP）的专用需求见 第 2.3 节。
1.1. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[1]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[1]）。
1.2. 缩写¶
术语和缩写的主列表在 [2] 中定义。下表包含本文档范围内使用、且尚未在 [2] 中定义的术语和缩写列表，以及每个缩写的完整含义。
表1.1：本文档范围内使用的缩写（Abbreviations used in the scope of this Document）
| 缩写 | 含义 |
|---|---|
| SIL | 安全完整性等级（Safety Integrity Level，IEC 61508 定义） |
2. 方法论需求¶
本章提供需求的定义。
2.1. 通用需求¶
本节规定主要对两个平台都有效的通用需求。
2.1.1. 主要需求¶
2.1.1.1. 方法论应解释如何构建 AUTOSAR 系统¶
| 描述 | 方法论应解释如何使用活动和工件（work product）构建 AUTOSAR 系统。它应像一本用户手册，帮助组织高效地应用 AUTOSAR。特别地，方法论应解释如何构建由经典平台和自适应平台组成的系统。 |
|---|---|
| 理由 | 需要强有力的方法论来有效管理大型系统的构建。 |
| 依赖项 | - |
| 用例 | 工程师希望完成一项活动，并希望知道需要哪些输入、应使用哪些指导等。构建 AUTOSAR 系统的典型用例包括： * SWC 实现 * ECU 集成 * 系统集成 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.2. 方法论应支持自顶向下和自底向上的方法¶
| 描述 | 方法论应同时支持自顶向下和自底向上的方法。在自顶向下的方法中，应考虑应用软件及其在 ECU 上分布的全部约束。在自底向上的方法中，应考虑来自硬件（ECU/传感器/执行器）的全部约束。 |
|---|---|
| 理由 | 改进集成阶段，并掌控嵌入式实时分布式系统中的复杂性。 |
| 依赖项 | - |
| 用例 | 如果在给定的车辆架构中新增一个 ECU 或用新的 ECU 替换既有 ECU，则集成期间需要把该 ECU 的所有新的或修改的资源纳入系统配置。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.3. 方法论应支持构建同时包含 AUTOSAR 与非 AUTOSAR ECU 的系统¶
| 描述 | 方法论应支持构建由符合 AUTOSAR 的 ECU 和不符合 AUTOSAR 的 ECU 组成的系统。 |
|---|---|
| 理由 | 应支持完整车辆系统的设计。 |
| 依赖项 | - |
| 用例 | 既有 ECU 和 LIN 从节点需要与 AUTOSAR ECU 互操作。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.4. 方法论应支持构建由多个 AUTOSAR 平台组成的系统¶
| 描述 | 方法论应支持构建由多个 AUTOSAR 平台组成的系统。 |
|---|---|
| 理由 | 应支持完整车辆系统的设计。 |
| 依赖项 | - |
| 用例 | 基于经典与自适应 AUTOSAR 平台的机器（或 ECU）之间的通信描述。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.5. 方法论应支持不同利益相关方之间的数据交换¶
| 描述 | AUTOSAR 应定义用于在基于 AUTOSAR 车辆的开发期间、不同利益相关方之间进行数据交换的交换格式。交换格式应涵盖软件、网络拓扑和网络通信的描述。 |
|---|---|
| 理由 | 在开发过程中使用 AUTOSAR 模板 |
| 依赖项 | - |
| 用例 | 一个 OEM 提供软件接口描述和网络通信描述，并将其交付给供应商进行开发和集成。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.6. 方法论应是模块化的¶
| 描述 | 利用流程组件。子流程应在自身上是完整且可测试的，以便在仍与既有工具和流程集成的同时，使用方法论的某些部分。 |
|---|---|
| 理由 | 更易于理解和验证方法论的各个部分。更易于管理修改，封装由变更引起的连锁反应，以允许迁移当前流程。更易于同时利用既有活动与 AUTOSAR 活动。应可以从某个中间活动开始，而不必从方法论的开头开始。模块化的方法论便于组织从其当前流程迁移或与之合并。模块化的方法论允许组织插入质量门（quality gate）等中间活动或其他检查，以及收集符合 CMMI 流程和/或 SIL-3 所需的度量。 |
| 依赖项 | - |
| 用例 | 某组织计划将一个 AUTOSAR ECU 引入其既有架构，但不打算使用系统模板及其相应活动和工件。他们计划直接从 ECU 层级开始。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.7. 方法论应支持不同的抽象层级¶
| 描述 | 方法论应支持开发 AUTOSAR 系统的不同视图。这对应于参与系统开发的典型领域和相关方。 |
|---|---|
| 理由 | 改进集成阶段，并掌控嵌入式实时分布式系统中的复杂性。 |
| 依赖项 | - |
| 用例 | AUTOSAR 使用若干抽象层级来描述不同参与方之间交换的信息。例如在早期阶段只使用「虚拟功能总线」（VFB），而在后续开发阶段处理部署到多个 ECU 上的 SWC 的真实实现。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.8. 方法论应支持往返工程¶
| 描述 | 方法论应支持往返工程（round-trip engineering）。这意味着为完成任务或工件可能需要若干次迭代循环。 |
|---|---|
| 理由 | 满足 AUTOSAR 质量需求。 |
| 依赖项 | - |
| 用例 | 汽车系统通常分若干样车阶段（A、B、C 等）开发。一个软件组件在 AUTOSAR 系统中被更新。只要迭代中没有发生相互矛盾的变更，更新后的 ECU 提取（ECU Extract）仍与既有的 ECU 配置匹配。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.9. 方法论应支持 OEM 与供应商对 SW-C 结构的不同视图¶
| 描述 | 方法论应支持 OEM 与供应商之间的交互，其中 OEM 和供应商对 SWC 结构持有不同的视图。 |
|---|---|
| 理由 | 供应商调整 SWC 结构的可能性。 |
| 依赖项 | - |
| 用例 | OEM 将初始系统提取（System Extract）作为正式的需求规范交付给供应商。供应商扩展并重构该系统提取。在下一个开发周期中，OEM 将更新后的系统提取交付给供应商。此后供应商必须基于 OEM 所做的更新来更新其系统提取结构。供应商侧的变更量应限于 OEM 更新引起的变更。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.10. 方法论应解释 OEM 对系统的不同视图的典型用法¶
| 描述 | 方法论应支持 OEM 对系统持有不同视图的用例。 |
|---|---|
| 理由 | 软件系统开发方法中方法论的一致性 |
| 依赖项 | - |
| 用例 | OEM 可能从功能角度构造 AUTOSAR 软件组件。然而，对于具体的车辆开发项目，需要 SWC 结构的拓扑视图。为了在生命周期中更好地处理，来自功能分解的 SWC 通过适当的映射被映射到拓扑视图。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.1.11. 方法论应解释供应商对系统的不同视图的典型用法¶
| 描述 | 方法论应支持供应商对系统持有不同视图的用例。 |
|---|---|
| 理由 | 软件系统开发方法中方法论的一致性 |
| 依赖项 | - |
| 用例 | 供应商需要映射系统的不同视图，例如：a) 供应商已有一个既有软件架构。通过软件共享，一些组件被 OEM 交付的组件替代。b) 供应商需要正式描述表示不同版本的系统描述之间的变更。c) 供应商为不同 OEM 开发同一 ECU，因此需要将 OEM 的需求视图映射到其解决方案视图。d) 供应商用 2 个 ECU 实现 OEM 对一个 ECU 的定义，因此需要映射系统描述。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.2. 编程语言¶
2.1.2.1. 方法论应独立于编程语言¶
| 描述 | 方法论应通过提供通用解决方案而独立于编程语言。对于必然依赖编程语言的部分，这些小节应被显式注明并且是模块化的，使整体方法论可被裁剪以适配其他编程语言。 |
|---|---|
| 理由 | 通过恰当地构造方法论以支持既有和新兴的编程语言，方法论可以一致且成功地应用于整辆车。 |
| 依赖项 | - |
| 用例 | 为特定微控制器构建的 ECU 针对编程语言 ABC 显式优化。方法论解释何时以及如何规定和选择与所需编程语言兼容的软件组件实现。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.3. 活动¶
2.1.3.1. 方法论应允许引用工具的活动¶
| 描述 | 活动可以引用帮助完成该活动的工具。方法论应描述这些类型的工具及其使用时机。 |
|---|---|
| 理由 | 通过定义需要哪些工具，活动的执行者可以确保在活动开始之前所有工具都已被采购和安装。同时，AUTOSAR 特定工具的实现者可以清楚地了解其工具应支持哪些活动，并知道输入和输出工件是什么。这将有助于确保 AUTOSAR 工具的互操作性。 |
| 依赖项 | - |
| 用例 | 对于经典平台，活动「生成 RTE」需要一个 RTE 生成器工具和一个编译器。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.3.2. 方法论应纳入行业标准工具的使用¶
| 描述 | 在存在编译器和链接器等行业标准工具的地方，方法论应将它们纳入。 |
|---|---|
| 理由 | 当行业标准工具已经存在时，AUTOSAR 不应要求使用特定工具。 |
| 依赖项 | - |
| 用例 | 编译器是行业标准工具。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.4. 流程需求¶
2.1.4.1. AUTOSAR 方法论不应绑定于特定的生命周期模型¶
| 描述 | AUTOSAR 方法论不应绑定于特定的生命周期模型。活动必须相对于其执行所处的开发流程的时间和阶段保持独立。 |
|---|---|
| 理由 | 与企业特定生命周期模型的连接：方法论应允许使用不同的生命周期模型，例如 V 模型、Rational 统一过程（Rational Unified Process）。 |
| 依赖项 | - |
| 用例 | 例如如果使用极限编程，测试用例在实现之前创建。对于大多数其他开发流程，实现在测试用例创建之前生成。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.4.2. 应能够为每个工件添加精确且人类可读的文档¶
| 描述 | 方法论应允许为每个工件添加精确且人类可读的文档。该文档应是工件的一部分，或被唯一地引用。 |
|---|---|
| 理由 | 这对于记录无法从形式内容（例如名称）中显而易见地推导出的设计决策或限制是必要的。此类文档将提高质量或安全标准所要求的可追溯性。 |
| 依赖项 | - |
| 用例 | 选择冗余机制，例如 NVRAM 数据块的配置，可能与某条安全需求相关。这可能需要文字说明。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.5. 变体处理需求¶
2.1.5.1. 方法论应支持不同绑定时间的参数配置¶
| 描述 | AUTOSAR 方法论应允许带变体处理支持的系统开发。 |
|---|---|
| 理由 | 参数的配置可以在不同流程步骤、不同时间执行。 |
| 依赖项 | - |
| 用例 | Tier 1 供应商发布之后的 OEM（post-build）数据配置。处理与不同配置项（用于版本控制的单元）相关的信息。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.5.2. 方法论应规定绑定时间¶
| 描述 | AUTOSAR 方法论应规定工作流中可以解析变体的特定时间点。 |
|---|---|
| 理由 | 需要关于绑定时间的稳定参考。 |
| 依赖项 | - |
| 用例 | 在 AUTOSAR 系统和 ECU 的开发期间，需要创建并最终选择特定的变体，例如预编译（pre-compile）或 post-build。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.5.3. 方法论应规定解析变体的任务¶
| 描述 | AUTOSAR 方法论应规定解析变体的特定任务/活动。 |
|---|---|
| 理由 | 需要澄清关于变体的方法论。 |
| 依赖项 | - |
| 用例 | 如果两个软件组件在系统的不同变体中提供相同接口，则需要一个任务来选择其中一个提供者以解析该系统变体。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.1.5.4. 方法论应规定变体选择器值的工件¶
| 描述 | AUTOSAR 方法论应规定用于维护变体选择器（variant selector）值的特定工件。 |
|---|---|
| 理由 | 这明确了变体选择器的值在哪里存储和维护。 |
| 依赖项 | - |
| 用例 | 可能的变体是预先已知的：它们在某个时刻被创建并作为一个工件被拥有，最终在选定变体时被消费。 |
| 适用平台 | CP、AP |
| 支撑材料 | - |
2.2. 面向经典平台的需求¶
2.2.1. 通用需求¶
2.2.1.1. 方法论应支持 VFB 概念¶
| 描述 | 虚拟功能总线概念允许在完全抽象硬件的情况下，对 SWC 之间进行早期检查。方法论应包含该概念。 |
|---|---|
| 理由 | 改进集成阶段和并行开发。 |
| 依赖项 | - |
| 用例 | 在 AUTOSAR 中，一个应用被建模为互连组件的组合。VFB 是允许这些组件交互的通信机制。即使这些组件使用的资源在开发期间尚不可用（硬件/网络），也可以进行一些基本检查并提前解决一些问题，从而减轻后续集成阶段的负担。 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.1.2. AUTOSAR 方法论应支持隐式通信行为概念¶
| 描述 | AUTOSAR 方法论应支持交换信息，以按照软件组件的需求配置 RTE 的隐式通信行为（Implicit Communication Behavior）。该信息可以在原子软件组件（Atomic Software Component）设计时首次定义，也可以在创建组合（composition）时添加。就隐式通信行为而言，原子软件组件的设计可以由隐式通信行为描述的蓝图（blueprint）引导。 |
|---|---|
| 理由 | 在自顶向下的设计方法中定义隐式通信行为需求 |
| 依赖项 | - |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | RS_SWCT_03065、RS_STDT_00034 |
2.2.1.3. AUTOSAR 方法论应解释数据交换点的描述与处理¶
| 描述 | 方法论应解释用于开发和使用数据交换点（Data Exchange Point）的工作流。例如，应描述 AUTOSAR 提供哪些制品来支持数据交换点 profile 的开发，这些 profile 可用于分析潜在的工具互操作性问题，或按照所描述的数据交换点配置 AUTOSAR 工具的验证引擎。 |
|---|---|
| 理由 | 工具互操作性 |
| 依赖项 | §2.2.1.4 |
| 用例 | • AUTOSAR 为方法论中的不同步骤规定制品的内容。 * 在生产 AUTOSAR 工具和消费 AUTOSAR 工具之间就交换的制品建立契约。生产工具确保其遵循约定的 profile，消费工具使用该 profile 指定其期望。 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.1.4. AUTOSAR 方法论应将模板与分布式开发流程相关联¶
| 描述 | AUTOSAR 模板规定了描述基于 AUTOSAR 的软件或系统的语言。方法论应支持规定模板的一个子集，该子集用于分布式开发流程中的特定工件。 |
|---|---|
| 理由 | 分布式开发中 AUTOSAR 制品的交换 |
| 依赖项 | §2.2.1.3 |
| 用例 | VFB 系统描述应只包含与 SWC 开发相关的信息，而不包含向 ECU 网络部署的信息。 |
| 适用平台 | CP |
| 支撑材料 |
2.3. 面向自适应平台的需求¶
本节规定仅对自适应平台有效的需求。
2.3.1. 主要需求¶
2.3.1.1. 方法论应解释如何设计系统的服务¶
| 描述 | 方法论应解释如何描述自适应 AUTOSAR 系统中用于面向服务通信的服务。服务接口由方法、事件和字段组成，这些需要被规定。 |
|---|---|
| 理由 | 应用之间交换信息的一致性描述。 |
| 依赖项 | - |
| 用例 | 规定一个由三个事件和一个方法组成的服务接口。 |
| 适用平台 | AP |
| 支撑材料 | - |
2.3.1.2. 方法论应解释如何配置系统服务实例¶
| 描述 | 方法论应解释服务部署的必要步骤。这从为所选网络绑定配置服务接口的部署开始。方法论还应描述如何为特定机器定义和配置服务实例。 |
|---|---|
| 理由 | 系统内服务实例的完整描述。 |
| 依赖项 | - |
| 用例 | 定义服务实例是被需求还是被提供，以及它们用于面向服务通信的查找或提供判据。 |
| 适用平台 | AP |
| 支撑材料 | - |
2.3.1.3. 方法论应解释如何开发自适应应用¶
| 描述 | 自适应应用基于服务接口开发。方法论应描述先设计、后实现自适应应用的必要活动。 |
|---|---|
| 理由 | 为应用开发者清晰导航，描述可能的开发方法。 |
| 依赖项 | - |
| 用例 | 设计带所有必要端口的软件组件模型，以便使用服务接口。 |
| 适用平台 | AP |
| 支撑材料 | - |
2.3.1.4. 方法论应解释清单规范的高层用法¶
| 描述 | 清单（manifest）包含将应用集成到自适应平台所需的全部信息。方法论应解释如何为机器、服务实例以及应用本身收集这些信息，以及清单随后如何用于配置目的。 |
|---|---|
| 理由 | 使用清单规范的方法论一致性 |
| 依赖项 | §2.1.1.5 |
| 用例 | 执行清单（Execution Manifest）用于描述可执行文件的所有流程相关方面。 |
| 适用平台 | AP |
| 支撑材料 | - |
2.3.1.5. 方法论应解释如何为自适应平台开发平台软件¶
| 描述 | 方法论应解释如何为自适应平台开发功能集群。 |
|---|---|
| 理由 | 自适应平台的高效开发。 |
| 依赖项 | - |
| 用例 | 自适应平台的执行管理与通信管理的开发。 |
| 适用平台 | AP |
| 支撑材料 | - |
2.3.1.6. 方法论应描述如何为自适应平台配置机器¶
| 描述 | 方法论应描述定义和配置机器的不同步骤，使软件能够部署到其上。这些步骤应独立于其他开发步骤，以确保软件后续可以在不重新配置机器的情况下轻松上传。 |
|---|---|
| 理由 | 无需调整机器配置即可部署或更新软件。 |
| 依赖项 | - |
| 适用平台 | AP |
| 用例 | 为面向服务通信配置机器上的所有端口和 IP 地址。 |
| 支撑材料 | - |
2.3.1.7. 方法论应描述如何在自适应平台上部署软件¶
| 描述 | 软件包（SW package）是部署到自适应 AUTOSAR 平台实例上的最小单元。方法论应描述软件包的内容以及它如何部署到自适应平台。 |
|---|---|
| 理由 | 直至软件被部署的应用开发工作流的完整描述。 |
| 依赖项 | - |
| 适用平台 | AP |
| 用例 | 下载并部署软件更新。 |
| 支撑材料 | - |
3. 变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的需求项。这些需求项在文档中不作为超链接出现。
3.1. 本文档依据 AUTOSAR 版本 R1.1.0 的变更历史¶
3.1.1. R1.1.0 中新增的需求¶
表3.1：R1.1.0 中新增的需求
| 标题 |
|---|
| 方法论应解释如何设计系统的服务 |
| 方法论应解释如何开发自适应应用 |
| 方法论应解释清单规范的高层用法 |
| 方法论应描述如何为自适应平台配置机器 |
| 方法论应描述如何在自适应平台上部署软件 |
| 方法论应解释如何配置系统服务实例 |
| 方法论应解释如何为自适应平台开发平台软件 |
3.1.2. R1.1.0 中变更的需求¶
无
3.1.3. R1.1.0 中删除的需求¶
无
3.2. 本文档依据 AUTOSAR 版本 R1.2.0 的变更历史¶
3.2.1. R1.2.0 中新增的需求¶
无
3.2.2. R1.2.0 中变更的需求¶
表3.2：R1.2.0 中变更的需求
| 标题 |
|---|
| 方法论应解释 Autosar 系统如何构建 |
| 方法论应支持自底向上方法 |
| 方法论应是模块化的 |
| 方法论应遵循不同的抽象层级 |
| 方法论应支持迭代 |
| 方法论应解释 OEM 与供应商之间的典型交互 |
| 方法论应解释 OEM 对系统的不同视图的典型用法 |
| 方法论应解释供应商对系统的不同视图的典型用法 |
| AUTOSAR 方法论应将模板与分布式开发流程相关联 |
| 方法论应独立于编程语言 |
| 方法论应支持引用工具的活动 |
| 方法论应纳入行业标准工具的使用 |
| AUTOSAR 方法论不应绑定于特定的生命周期模型 |
3.2.3. R1.2.0 中删除的需求¶
无
3.3. 本文档依据 AUTOSAR 版本 R1.3.0 的变更历史¶
3.3.1. R1.3.0 中新增的需求¶
表3.3：R1.3.0 中新增的需求
| 标题 |
|---|
| 方法论应支持构建由多个 AUTOSAR 平台组成的系统 |
| 方法论应解释 AUTOSAR 模板的高层用法 |
3.3.2. R1.3.0 中变更的需求¶
表3.4：R1.3.0 中变更的需求
| 标题 |
|---|
| 方法论应解释如何构建 AUTOSAR 系统 |
| 方法论应支持自顶向下和自底向上的方法 |
| 方法论应支持构建同时包含 AUTOSAR 与非 AUTOSAR ECU 的系统 |
| 方法论应支持不同的抽象层级 |
| 方法论应支持往返工程 |
| 方法论应支持 OEM 与供应商对 SWC 结构的不同视图 |
| 方法论应解释 OEM 对系统的不同视图的典型用法 |
| 方法论应解释供应商对系统的不同视图的典型用法 |
| 方法论应允许引用工具的活动 |
| 方法论应纳入行业标准工具的使用 |
| AUTOSAR 方法论不应绑定于特定的生命周期模型 |
| 应能够为每个工件添加精确且人类可读的文档 |
| 方法论应支持 VFB 概念 |
| 方法论应独立于编程语言 |
| AUTOSAR 方法论应将模板与分布式开发流程相关联 |
| 方法论应解释如何设计系统的服务 |
| 方法论应解释如何开发自适应应用 |
| 方法论应解释清单规范的高层用法 |
| 方法论应描述如何为自适应平台配置机器 |
| 方法论应描述如何在自适应平台上部署软件 |
| 方法论应解释如何配置系统服务实例 |
| 方法论应解释如何为自适应平台开发平台软件 |
3.3.3. R1.3.0 中删除的需求¶
表3.5：R1.3.0 中删除的需求
| 标题 |
|---|
| 方法论应明确定义哪些被标准化、哪些不被标准化 |
| 方法论应解释 SWC 模板的典型用法 |
| 方法论应解释 BSW 模块模板的典型用法 |
| 方法论应解释 ECU 配置模板的典型用法 |
| 方法论应解释系统模板的典型用法 |
| 方法论应解释安全扩展的典型用法 |
| 方法论应解释诊断提取模板的典型用法 |
| 方法论应支持 C 编程语言 |
| 方法论应定义活动 |
| 活动应有目的 |
| 活动应有输入工件 |
| 活动应有输出工件 |
| 活动应包括角色 |
| 方法论应定义工件 |
| 工件应有描述 |
| 工件应有指向 Autosar 元模型中元类（metaclass）的引用 |
| 必须能够避免工件中的数据重复 |
| 工件不应与其他工件存在循环引用 |
| 方法论应描述既有工件的变更 |
| 方法论应定义无歧义的指导术语 |
| 方法论应定义角色 |
| 角色应有描述 |
| 方法论应被建模 |
| 方法论应定义将方法论模型转换为文档的规则 |
| AUTOSAR 方法论应支持对外部制品的可追溯性 |
| 方法论文档应包括活动、角色、工件与指导之间的超链接 |
3.4. 本文档依据 AUTOSAR 版本 R1.4.0 的变更历史¶
3.4.1. R1.4.0 中新增的需求¶
无
3.4.2. R1.4.0 中变更的需求¶
无
3.4.3. R1.4.0 中删除的需求¶
无
3.5. 本文档依据 AUTOSAR 版本 R1.5.0 的变更历史¶
3.5.1. R1.5.0 中新增的需求¶
无
3.5.2. R1.5.0 中变更的需求¶
表3.6：R1.5.0 中变更的需求
| 标题 |
|---|
| 方法论应支持不同绑定时间的参数配置 |
| 方法论应规定绑定时间 |
| 方法论应规定解析变体的任务 |
| 方法论应规定变体选择器值的工件 |
| 方法论应解释清单规范的高层用法 |
| 方法论应支持不同利益相关方之间的数据交换 |
3.5.3. R1.5.0 中删除的需求¶
无
3.6. 本文档依据 AUTOSAR 版本 R1.5.1 的变更历史¶
3.6.1. R1.5.1 中新增的需求¶
无
3.6.2. R1.5.1 中变更的需求¶
无
3.6.3. R1.5.1 中删除的需求¶
无
3.7. 本文档依据 AUTOSAR 版本 R19-11 的变更历史¶
3.7.1. R19-11 中新增的需求¶
无
3.7.2. R19-11 中变更的需求¶
无
3.7.3. R19-11 中删除的需求¶
无
3.8. 本文档依据 AUTOSAR 版本 R20-11 的变更历史¶
无
3.9. 本文档依据 AUTOSAR 版本 R21-11 的变更历史¶
3.9.1. R21-11 中新增的需求¶
无
3.9.2. R21-11 中变更的需求¶
无
3.9.3. R21-11 中删除的需求¶
无
3.10. 本文档依据 AUTOSAR 版本 R22-11 的变更历史¶
3.10.1. R22-11 中新增的需求¶
无
3.10.2. R22-11 中变更的需求¶
无
3.10.3. R22-11 中删除的需求¶
无
3.11. 本文档依据 AUTOSAR 版本 R23-11 的变更历史¶
3.11.1. R23-11 中新增的需求¶
无
3.11.2. R23-11 中变更的需求¶
表3.7：R23-11 中变更的需求
| 标题 |
|---|
| 方法论应支持不同的抽象层级 |
| 方法论应支持构建由多个 AUTOSAR 平台组成的系统 |
3.11.3. R23-11 中删除的需求¶
无