电池工匠-电池行业报告、技术及资讯专业平台！ 戳“电车匠”即可关注我们！

进群|  进“专业电池社群”——钠电池群、固态电池群、复合集流体、动力电池安全与热管理群等 ，请加微18158711612，备注电池

为了保证软件（应用层和底层）开发的质量和效率，当前成熟的ECU软件开发都会采用V流程形式。

所有工程过程（即：系统工程和软件工程）是按照“V” 字模型原理进行组织：左边的每个过程是与右边的过程正好相对应。因此，过程 SWE.3 “软件详细设计与单元构建” 与 SWE.4 “软件单元验证”是分离的。

V流程来源于软件开发过程中一个称为快速应用开发的模型，由于该模型的构图形似字母V，所以俗称V模型。V模型是软件开发、测试中最重要的一种模型，其大体可划分为几个不同的阶段步骤，即功能需求、功能开发、软件开发、软件集成测试、功能集成测试、整车集成测试（系统合格性测试），如上图所示。左边为需求分析和设计开发的过程，右边则为针对左边的测试验证。

从系统需求到软件需求，再到软件的释放，需要工具对其进行管理，以达到可追溯，可记录的目的，目前市场主流的工具含有 Door,ClearCase,GIT,SDOM 等，同时也有公司自己研发的一些流程工具。这些工具的运作方式都遵循需求，研发，测试的V流程。

在架构设计过程中，需要使用EA架构设计工具，isolar等AUTOSAR配置工具。

软件实现过程中，需要使用到Matlab等模型开发工具。

软件组件集成过程中需要使用到编译工具。

软件组件测试过程中需要使用到Tessy等测试工具。

一、软件开发v流程的实施

1. 系统需求分析

这部分为系统需求。需要系统工程师完成。

基于项目的整体需求，以及软硬件整体定义，对系统逻辑架构进行整体定义，这部分工作包括：硬件功能定义，控制器与其他控制器通信定义，软件简要功能定义。这个过程并不会对具体的技术实现做出定义。

通常会使用Doors等流程软件定义系统需求。

2. 软件需求分析

这部分为软件需求，需要系统工程师完成。

系统工程师根据系统相关方需求说明书、软硬件接口文件、变更通知书等输入，梳理定义软件研发需求说明书，包括操作系统需求、电源管理策略、传感器读取，执行器控制、信号特性需求、存储服务、通信服务，网络管理、故障诊断、标定、程序升级等功能需求和非功能需求。

根据项目规划，制定软件开发计划。

软件需求分析建立需求追踪矩阵，将软件需求映射到系统需求，确保软件要实现的系统需求全部覆盖，为了完成这个功能，通常我们也是使用Doors等流程软件完成。

成功实施这个过程的结果如下：

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

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

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

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

5) 根据需要更新了软件需求；

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

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

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

3. 软件架构设计

这部分为软件架构，需要架构工程师完成。

为了建立清晰的、结构化的软件设计，应该统一分配软件需求，然后完成软件架构设计。根据系统相关需求、软硬件接口表、软件需求确定软件架构。将每条软件需求合理分配到软件模块中，定义每个软件模块的输入输出接口、动态行为、资源消耗目标等，评估多种软件架构的优缺点等。

架构工程师需要使用EA等架构软件画出整个控制器软件所有模块的输入输出接口、以及内部动态行为。

如果项目基于AUTOSAR开发，需要架构工程师配置应用层的所有组件，并输出每个组件的ARXML描述文件。

一般来说，还需要架构工程师输出架构文档。

成功实施这个过程的结果如下：

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

2) 将软件需求分配给软件的要素

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

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

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

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

4. 软件单元设计和软件实现

这部分为软件单元设计，需要软件开发工程师完成。

在此阶段，需要对每个组件内部的算法逻辑进行详细的内部设计。组件功能的详细设计需要与软件需求建立有效的对应关系。

如果是算法逻辑编码，建议使用Matlab进行模型开发，如果是接近底层的复杂驱动，一般是使用手写代码。

如果项目使用AUTOSAR架构，使用模型开发时需要导入arxml生成模型框架进行开发，使用手写代码进行开发时需要使用AUTOSAR工具生成的组件代码框架进行开发。

需要将代码经过多次代码审查和优化之后，将最终版本上传至代码库，以实现最佳的可靠性和性能。

成功实施这个过程的结果如下：

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

2) 定义了各软件单元的接口；

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

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

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

方沟通；

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

6. 软件单元测试

当进行单元测试通过后，将会将软件编译成ECU可执行的文件，比如Hex格式的文件，将其刷写到ECU进行集成测试（或称HIL测试），如果只是测试底层软件，那么一般只需要额外的硬件负载箱支持就行，比如用负载箱来模拟一些传感器信号输入，或制造一些执行器的短路和开路故障；如果测试包括应用层软件，那么就还需要物理模型支持才行，比如电机控制就需要电机的物理模型，变速箱控制可能就需要整个动力传动系统的模型才行。

这部分为组件单元测试，一般需要软件开发工程师完成，也可以让测试工程师完成。

单元测试与软件单元设计对应。

单元测试是根据软件单元设计，进行代码级别上进行的测试。

单元测试一般可以通过Matlab和Tessy等工具进行。

成功实施这个过程的结果如下：

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

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

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

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

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

7. 软件集成测试

这部分为集成测试，需要测试工程师完成。

集成测试与软件需求对应。

集成测试将各个组成部分整合入一个软件系统中之后，最后进行软件的集成测试。根据定义的需求，测试相应的功能是否满足软件需求。

成功实施本过程的结果如下：

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

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

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

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

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

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

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

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

8. 软件系统测试

这部分为系统测试，需要测试工程师完成。

系统测试与系统需求对应。

因为软件给各个ECU提供了相应的功能，因此在集成测试中，需要将软件烧录至硬件中。然后ECU要与其他电子系统组件集成起来，比如传感器和执行器。在接下来的系统综合测试中，对所有系统设备的交互响应进行评估。

成功实施本过程的结果如下：

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

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

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

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

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

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

二、软件开发中的术语

下图描述了在工程过程中一致使用的要素、组件、软件单元和项之间的关系。

架构包括架构“要素”，可以被进一步分解到各合适层级上的架构子“要素”。软件“组件”是软件架构的最低层级的“要素”，以定义最终的详细设计。一个软件“组件”可包含一个或多个软件“单元”。

在 V 模型右边的“项”对应到左边的“要素”（如：软件“项”可以是对象文件、库或可执行形式）。这可以是 1:1 或 m:n 的关系，如：一个项可表示超过一个架构“要素”。

三、软件开发中的追溯性和一致性

追溯性和一致性在 Automotive SPICE 3.1 PAM 是通过两个单独的基本实践来提出。追溯性指的是在工作产品之间存在引用或链接，由此可以进一步支持覆盖率、影响分析、需求实施状态跟踪等。相反，一致性关注内容和语义。

此外，双向可追溯性可被明确地定义在测试用例和测试结果之间 、变更请求和受这些变更请求影响的工作产品之间 、双向可追溯性和一致性的概览见下图所示。