11-2 智能汽车软件开发流程详细解析

本专题由深圳季连李博及团队出品。以下内容来源于AEB、ACC、ALC、TJA、HWA、NOA、L4 等 ADS 和 ADAS 具体项目实施过程的总结，如有疏漏或不当之处，请不吝指出。

1. 汽车软件过程改进及能力评定模型

汽车软件过程改进及能力评定模型 ASPICE –ISO/IEC33004 总体预览。

从上图可以看出汽车软件过程改进及能力评定（Automotive Software Process Improvement and Capability dEtermination, ASPICE）包含生命周期过程、组织生命周期过程、支持生命周期过程三个生命周期过程，它还进一步可以细分为：

需求获取组 ACQ ；

供应管理组 SPL；

系统组 SYS；

软件组 SWE；

支持组 SUP；

管理组 MAN；

过程改进组 PIM。

本文重点阐述重在流程改进的系统组和软件组两方面内容。至于重在安全的文档，请参见团队后期关于标准 ISO26262 的介绍。

2. 核心概念

2.1 过程评估模型

Process Assessment Model，PAM：在 ASPICE 中，使用过程评估模型来确定过程能力。

该模型基于一个二维框架，该框架的第一个维度是由过程参考模型定义的过程来提供，满足参考模型要求以及参考模型指定成果要求。第二个维度是由过程属性的能力等级所构成。因此，过程能力可以通过对过程参考模型和所涉及的过程属性能力等级的评估来进行确定。

该模型能够用于评估和改进汽车行业中的过程，以提高组织的过程能力和产品质量。

2.2 过程参考模型PRM

Process Reference Model，PRM：指的是按照一定的过程类别分组，界定领域和范围。另外针对每个过程，描述其目的，获得过程结果清单等，如上述的图即为 ASPICE 过程参考模型。

2.3 过程属性 PA

PA Process Attribute，PA：是通用实践 GP、通用资源 GR 组合形成的针对一个过程的特征描述。

2.4 基本实践 BP

Base Practice，BP：指某个特定过程中指定活动的指标，也可以理解为最佳实践。

譬如 AEB 产品开发包括：开发详细设计、软件接口定义、描述动态行为等，这些活动为该过程的基本实践。

2.5 工作产品 WP

Work Product，WP：工作产品指的是每个过程的输出物。

2.6 通用实践 GP

Generic Practice，GP：是指在不同行业或领域中通用的最佳实践方法，被认为是在管理和组织方面最成功和广泛使用的方法。通用实践指出每个过程属性的特征，是通用类型，即它们适用于任何过程，是面向活动的指标。

2.7 通用资源 GR

Generic Resource，GR：是项目管理中的一个术语，指的是不涉及具体技能和专业知识领域的资源。GR 通常是指那些对项目非常重要，但在项目团队中较难找到和管理的资源，例如会议室、设备、工作空间和文件存储等资源。通用资源与整体的过程属性相关联，是面向基础设施的指标。有效管理 GR 不仅需要评估其可用性和优先级，还需要充分利用它们的能力和成本效益。

2.8 过程实施指标

包含基本实践 BP 和工作产品 WP。

2.9 过程能力指标

包含通用实践 GP 和通用资源 GR。

3. 各个等级说明

3.1 级别等级定义

3.2 评估指标与过程能力

Level 1 要求企业满足 BP（基本实践）、WP（工作实践）和PA1.1（过程能力）的要求。Level 2 在 Level 1 的基础上，企业需要参加进一步的评估。同理， Level 5 要求企业在满足 Level 4 的基础上还要满足 PA5.1 和 PA5.2 的要求。通常情况下，通往更高成熟度水平的道路需要企业逐步提高其过程能力和实践水平，确保企业能够不断提高其效率和能力。企业必须采用科学的管理姿态，牢记这些实践方法和标准要求，并在实践中持续改进业务。

换成中文解读：ASPICE 评审过程中，在满足基本过程要求的基础上，更注重过程的能力。

4. 双向追溯关系

软件需求和系统需求、详细设计和软件需求、软件单元测试和集成测试结果等需要建立双向追溯关系。

双向追溯关系指的是在质量管理中，对于产品或服务的验收及其所对应的质量要求，需要在整个生命周期中建立起来一个双向的关系。即产品或服务的需求向前追溯到生产和服务的实施阶段，同时生产和服务的实施情况则向后追溯到产品或服务的验收阶段。这样可以确保生产和服务过程的质量，符合验收要求。双向追溯关系在追溯与管理产品或服务质量方面的问题时非常重要，它有助于发现生产过程中存在的问题和缺陷，并及时消除，从而保证产品或服务的质量并满足客户的需求。

从这里也可以看出智能汽车软件开发通用流程：系统需求、系统架构、软件需求、软件架构、软件设计、单元验证测试、软件集成及集成测试。

5.  系统需求详细解析

汽车软件开发系统需求 V 模型：

以下内容根据具体项目实施过程总结，有疏漏不当之处，请不吝指教。

汽车软件开发系统需求 V 模型是一种软件开发过程模型，它是一种用于描述软件开发阶段的结构性模型，通过在不同阶段之间建立关联和追溯，以确保最终产品的质量和符合需求。V字形模型中，需求分析和系统设计处于上半部分，具体设计、编程和测试则位于下半部分，通过测试从下往上追溯到设计和需求，可以确保系统的质量和符合需求。

5.1 需求挖掘 SYS.1

5.1.1 相关内容

获得利益相关方的需求和要求

理解利益相关方的期望

达成需求共识

建立利益相关方需求基线

管理利益相关方需求变更

建立客户-供应商查询沟通机制

5.1.2 结果

建立了与利益相关方的持续沟通

定义和基线化了约定的利益相关需求

建立变更机制

建立了持续监控利益相关方需要的机制

建立了机制，以确保客户可以容易地判定其要求的状态和处置结果

识别了因技术或利益相关方需要的变化而引发的变更，评估相关风险并管理其带来的影响

5.1.3 产品输出物

风险管理计划

风险缓解计划

沟通记录

评审记录

变更控制记录

5.1.4 参照标准 SYS.1

5.2 系统需求分析 SYS.2

5.2.1 相关内容

定义系统需求

结构化系统需求

分析系统需求

分析对运行环境的影响

制订验证准则

建立双向可追溯性

确保一致性

5.2.2 结果

建立了一组定义的系统需求

对系统需求进行分类，并分析了其正确性和可验证性

分析了系统需求对运行环境的影响

定义了系统表求实施的优先级

根据需要更新了系统需求

建立了利益和关方需求和系统需求之间的致性和双向可追溯性

从成本、进度和技术影响来评估系统需求

约定了系统需求，并与所有受影响方沟通

5.2.3 输出物

沟通记录

评审记录

变更控制记录

追溯记录

分析报告

接口需求规范

系统需求规范

验证准则

5.2.4 参照标准 SYS.2

 

5.3 系统架构设计 SYS.3

5.3.1 相关内容

开发系统架构设计

分配系统需求

定义系统要素的接口

描述动态怎为

评估备选的系统架构

建立双向可追溯性

确保一致性

沟通约定的系统架构设计

5.3.2 结果

定义了识别系统要素的系统架构设计

将系统需求分配给系统的要素

定义了每个系统要素的接口

定义了系统要素的动态行为

建立了系统需求和系统架构设计之间的一致性和双向可追溯性

约定了系统架构设计，并与所有受影响方沟通

5.3.3 输出物

系统架构设计

沟通记录

评审记录

追溯记录

接口需求规范

5.3.4 参照标准 SYS.3

5.4 系统集成与集成测试 SYS.4

5.4.1 相关内容

制定系统集成策略

制订包括回归测试策略在内的系统集成测试策略

开发系统集成测试规范

集成系统项

选择测试用例

执行系统集成测试

建立双向可追溯性

确保一致性

总结和测试报告

5.4.2 结果

制订了与项目计划、发布计划和系统架构设计相一致的系统集成策略，以集成系统项

制订了包括回归测试策略在内的系统集成测试策略，以测试系统项之间的交互

根据系统集成测试策略，制订了系统集成测试规范，以适于提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据

根据集成策略将系统项集成为完整的集成系统

根据系统集成测试策略和发布计划，选择了系统集成测试规范中的测试用例

使用选定的测试用例测试了系统项之间的交互，并记录了系统集成测试结果

建立了系统架构设计的要素和系统集成测试规范中的测试用例之间的一致性和双向可追溯性，并建立了测试用例和测试结果之间的双向可追测性

总结了系统集成测试结果，并与所有受影响方沟通

5.4.3 输出物

测试规范

测试计划

系统

沟通记录

评审记录

追溯记录

测试结果

5.4.4 参照标准 SYS.4

 

5.5 系统合格线性测试 SYS.5

5.5.1 相关内容

制订包括回归测试策略在内的系统合格性测试策略

开发系统合格性测试规范

选择测试用例

测试已完成的系统

建立双向可追溯性

确保一致性

5.5.2 结果

制订了与项目计划和发布计划相一致的系统合格性测试策略（包括回归测试策略)，以测试已集成的系统

根据系统合格性测试策略，制订了已集成系统的系统合格性测试规范以适于提供符合系统需求的证据

根据系统合格性测试策略和发布计划，选择了系统合格性测试规范中的测试用例

使用选择的测试用例测试了已集成的系统，并记录了系统合格性测试的结果

建立了系统需求与系统合格性测试规范中测试用例之间的一致性和双向可追溯性，并建立了测试用例与测试结果之间的一致性和可追溯性

总结了系统合格性测试结果，并与所有受影响方沟通

5.5.3 输出物

测试规范

测试计划

沟通记录

评审记录

追溯记录

测试结果

5.5.4 参照标准 SYS.5

 

6. 软件需求详细解析

汽车软件开发软件需求 V 模型：

以下内容根据具体项目实施过程总结，有疏漏不当之处，请不吝指教。

6.1 软件需求分析 SWE.1

6.1.1 相关内容

定义软件需求

结构化软件需求

分析软件需求

分析对运行环境的影响

制订验证准则

建立双向可追溯性

确保一致性沟通

约定的软件需求

6.1.2 结果

定义了系统中分配给软件要素的软件需求及其接口

将软件需求进行分类，并分析了其正确性和可验证性

分析了软件需求对运行环境的影响

定义了软件需求实现的优先级

根据需要更新了软件需求

在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和可追溯性

从成本、进度和技术影响来评估软件需求

约定了软件需求，并与所有受影响方沟通

6.1.3 输出物

沟通记录

评审记录

变更控制记录

追溯记录

分析报告

接口需求规范

软件需求规范

验证准则

6.1.4 参照标准 SWE.1

 

6.2 软件架构设计 SWE.2

6.2.1 相关内容

开发软件架构设计

分配软件需求

定义软件要素的接口

描述动态行为

定义资源消耗目标

评估备选的软件架构

建立双向可追溯性

确保一致性

沟通约定的软件架构设计

6.2.2 结果

定义了识别软件要素的软件架构设计

将软件需求配给软件的要素

定义了每个软件要素的接口

定义了软件要素的动态行为和资源消耗目标

建立了软件需求与软件架构设计之间的一致性和双向可追溯性

约定了软件架构设计，并与所有受影响方沟通

6.2.3 输出物

软件架构设计

沟通记录

评审记录

追溯记录

接口需求规范

6.2.4 参照标准 SWE.2 

 

6.3 软件详细设计和单元构建 SWE.3

6.3.1 相关内容

开发软件详细设定

定义软件单元的接口

描述动态行为

评估软件详细设计

建立双向可追溯性

确保一致性

沟通约定的软件详细设计

开发软件单元

6.3.2 结果

开发了描述软件单元的详细设计

定义了各软件单元的接口

定义了软件单元的动态行为

建立了软件需求与软件单元之间的一致性及双向可追溯性:建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性;建立了软件详细设计与软件单元之间一致性和双向可追溯性

约定了软件详细设计及该设计与软件架构设计的关系，并和所有受影响方沟通

生成了软件详细设计所定义的软件单元

6.3.3 输出物

软件详细设计

软件单元

沟通记录

评审记录

追溯记录

6.3.4 参照标准 SWE.3

 

6.4 软件单元验证 SWE.4

6.4.1 相关内容

制订包括回归策略在内的软件单元验证策略

制订单元验证准则-MAAB，MISRA

执行软件单元的静态验证

测试软件单元-测试脚本

建立双向可追溯性

确保一致性

总结并沟通结果

6.4.2 结果

制订了包括回归策略在内的软件单元验证策略，以验证软件单元

根据软件单元验证策略，制订了软件单元验证准则，以适于提供软件单元符合软件详细设计及非功能性软件需求的证据

根据软件单元验证策略及软件单元验证准则，验证了软件单元并记录了结果

建立了软件单元、验证准则及验证结来之间的双向可追溯性和一致性

总结了单元验证结果，并与所有受影响方沟通

6.4.3 输出物

测试规范

测试计划

沟通记录

评审记录

追溯记录

验证结果

测试结果

分析报告 

 6.4.4 参照标准 SWE.4

6.5 软件集成和集成测试 SWE.5

6.5.1 相关内容

制订软件集成策略

制订包含回归测试策略在内的软件集成测试策略

开发软件集成测试规范

集成软件单元和软件项

选择测试用例

执行软件集成测试

建立双向可追溯性

确保一致性

总结和沟通测试结果

6.5.2 结果

制订了与项目计划、发布计划和软件架构设计相一致的软件集成策略以集成软件项

制订了包括软件回归测试策略在内的软件集成测试策略，以测试软件单元之间和软件项之间的交互

根据软件集成测试策略，开发了软件集成测试规范，以适于提供集成的软件项符合软件架构设计(包括软件单元之间和软件项之间的接口)的证据

根据集成策略集成了软件单元和软件项直至完整的集成软件

根据软件集成测试策略和发布计划，选择了软件集成测试规范中的测试用例

使用选定的测试用例测试了集成的软件项，并记录了测试结果

建立了软件架构设计要素与软件集成测试规范中的测试用例之间的一致性和双向可追溯性，并建立了测试用例与测试结果之间的一致性和双向可追溯性

总结了软件集成测试结果，并与所有受影响方沟通

6.5.3 输出物

软件项集成

软件测试规范

测试计划

沟通记录

评审记录

追溯记录

测试结果

编译清单

6.5.4 参照标准 SWE.5

 

6.6 软件合格性测试 SWE.6

6.6.1 相关内容

制订包括回归测试策略在内的软件合格性测试策略

开发软件合格性测试规范

选择测试用例

测试集成软件

建立双间可追溯性

确保一致性

总结和沟通结果

6.6.2 结果

制订了与项目计划和发布计划相一致的包括回归测试策略在内的软件合格性测试策略，以测试集成软件

根据软件合格性测试策略，开发了集成软件的软件合格性测试规范，以适于提供符合软件需求的证据

根据软件合格性测试策略和发布计划，选择了软件合格性测试规范中的测试用例

使用选定的测试用例测试了集成软件，并记录了软件合格性测试结果

建立了软件需求与软件合格性测试规范中的测试用例之间的一致性和双向可追溯性，建立了刚试用例与测试结果之间的一致性和双向的可追溯性

总结了软件合格性测试结果，并与所有受影响方沟通

6.6.3 输出物

测试规范

测试计划

沟通记录

评审记录

追溯记录

测试结果

6.6.4 参照标准 SWE.6