开发不仅需要高效的编码能力，更需要编程思维的引导。作为一名刚刚进入汽车电子行业的开发小白，本篇博文将总结一下最近学习到的汽车软件行业的开发思想：V模型。一、V模型概述汽车软件开发过程中的V模型一直是业界开发者常用的模型。它由瀑布模型演变而来，是目前汽车行业应用最广泛的软件开发模型。由于模型的构成酷似字母V，故俗称V模型。V模型的核心思想是通过A-SPICE过程（汽车行业的软件过程改进和能力衡量标准）来支持和管理整个开发过程，从需求到源代码的每个过程都有相应的测试。V模型大致可以分为几个不同的步骤：功能需求、功能开发、软件开发、软件集成测试、功能集成测试、整车集成测试（系统资格测试），如下图所示，对左边是分析设计开发的过程，右边是对左边的测试验证，左边的每一个过程都和右边的过程完全对应。从系统需求到软件需求，再到软件发布，都需要工具来管理，以实现可追溯和可记录。目前市场上主流的工具有Door、ClearCase、GIT、SDOM等，也有一些是公司自己开发的。一些流程工具，当然这些工具的操作方法是遵循V流程的要求，开发和测试要求的。2.V-模型实现2.1.系统需求分析系统需求需要由系统工程师来完成。基于项目的整体需求，以及软硬件的整体定义，进行系统逻辑架构的整体定义。这部分工作包括：硬件功能的定义、控制器与其他控制器的通信定义、软件的简要功能定义。这个过程没有定义具体的技术实现。2.2.软件需求分析软件需求需要由系统工程师来完成。系统工程师根据系统利益相关者的输入、软硬件接口文档、变更通告，梳理定义软件研发需求，包括操作系统需求、电源管理策略、传感器读取、执行器控制、信号特性需求、存储服务等，通信服务、网络管理、故障诊断、校准、程序升级等功能需求和非功能需求。根据项目计划，制定软件开发计划。软件需求分析建立需求跟踪矩阵，将软件需求映射到系统需求，确保涵盖软件要实现的所有系统需求。成功实施该过程的结果如下：定义软件需求及其分配给系统中软件元素的接口；对软件需求进行分类并分析其正确性和可验证性；分析软件需求对运行环境的影响；需求实现的优先级；根据需要更新软件要求；建立系统需求与软件需求、系统架构设计与软件需求的一致性和双向可追溯性；根据成本、进度和技术影响评估软件需求；软件要求已达成一致并传达给所有受影响的各方。2.3.软件架构设计软件架构需要架构工程师来完成。为了建立清晰的、结构化的软件设计，应统一分配软件需求，然后完成软件体系结构设计。根据系统相关需求、软硬件接口表、软件需求确定软件架构。将每个软件需求合理分配到软件模块，定义每个软件模块的输入输出接口、动态行为、资源消耗目标等，评估各种软件架构的优缺点。架构师需要使用EA等架构软件绘制整个控制器软件各模块的输入输出接口和内部动态行为。如果项目是基于AUTOSAR开发的，架构师需要对应用层的所有组件进行配置，并输出每个组件的ARXML描述文件。一般来说，架构工程师也需要输出架构文档。成功实施该过程的结果如下：定义了识别软件元素的软件架构设计；软件需求分配给软件元素；定义了每个软件元素的接口；定义软件元素的动态行为和资源消耗目标；软件架构设计之间的一致性和双向可追溯性；就软件架构设计达成一致并与所有受影响的各方进行沟通。2.4.软件单元设计与软件实现软件单元设计需要由软件开发工程师来完成。在此阶段，需要对每个组件内部的算法逻辑进行详细的内部设计。构件功能的详细设计需要与软件需求建立有效的对应关系。对于算法逻辑编码，推荐使用Matlab进行模型开发。对于靠近底层的复杂驱动，一般采用手写代码。如果项目使用AUTOSAR架构，使用模型开发需要导入arxml生成模型框架进行开发，使用手写代码开发需要使用AUTOSAR工具生成的组件代码框架进行开发。代码需要经过多次代码审查和优化后，最终版本上传到代码库，以达到最佳的可靠性和性能。成功实施该过程的结果如下：开发描述软件单元的详细设计；定义每个软件单元的接口；定义软件单元的动态行为；建立软件需求和软件单元之间的一致性和双向可追溯性；建立软件架构设计与软件详细设计之间的一致性和双向可追溯性；建立软件详细设计和软件单元之间的一致性和双向可追溯性；就软件详细设计以及设计与软件架构设计之间的关系达成一致，并与所有受影响的各方进行沟通；生成由软件详细设计定义的软件单元。2.5.软件单元测试组件单元测试一般需要由软件开发工程师完成，也可以由测试工程师完成。单元测试通过后，软件会编译成ECU可执行文件，比如Hex格式的文件，刷入ECU进行集成测试（或HIL测试）。如果只测试底层软件，那么一般只需要额外的硬件负载箱支持，比如用负载箱模拟一些传感器信号输入，或者制造一些执行器的短路、开路故障；如果测试包括应用层软件，那么还需要物理模型支持，比如电机控制需要电机的物理模型，变速箱控制可能需要整个传动系统的模型。单元测试对应于软件单元设计。单元测试是基于代码级别的软件单元设计和测试。单元测试一般可以通过Matlab、Tessy等工具进行。成功实施该过程的结果如下：开发软件单元验证策略，包括回归策略，以验证软件单元；基于软件单元验证策略，制定适用于提供符合软件详细设计和非功能性软件单元的软件单元验证准则根据软件单元验证策略和软件单元验证准则，对软件单元进行验证并得出结果被记录；建立软件单元、验证准则和验证结果之间的双向可追溯性和一致性；对机组核查结果进行总结，并与所有受影响方进行沟通。2.6.软件集成测试集成测试需要由测试工程师来完成。集成测试对应于软件需求。集成测试将各个组件集成到一个软件系统之后，最后就是对软件进行集成测试。根据定义的需求，测试相应的功能是否满足软件需求。成功实施该过程的结果如下：制定与项目计划、发布计划和软件架构设计一致的软件集成策略以集成软件项；制定软件集成测试策略，包括软件回归测试策略，以测试软件项之间的交互；根据软件集成测试策略，制定软件集成测试规范，以适用于为集成的软件项符合软件架构设计（包括软件单元之间和软件项之间的接口）提供证据；将软件单元和软件项集成起来根据集成策略到完整的集成软件；根据软件集成测试策略和发布计划，选取软件集成测试规范中的测试用例；使用选定的测试用例对集成的软件项进行测试，并记录测试结果；建立软件架构设计元素与软件集成测试规范中测试用例的一致性和双向可追溯性，建立测试用例与测试结果的一致性和双向可追溯性；总结软件集成测试结果并与所有受影响的各方沟通。2.7.软件系统测试系统测试需要由测试工程师完成。系统测试对应于系统需求。由于软件为每个ECU提供了相应的功能，因此在集成测试时需要将软件烧录到硬件中。然后，ECU与其他电子系统组件集成，例如传感器和执行器。在接下来的系统集成测试中，评估所有系统设备的交互响应。成功实施该过程的结果如下：制定软件资格测试策略，包括回归测试策略，与项目计划和发布计划一致，以测试集成软件；根据软件资格测试策略为集成软件开发软件资格测试，测试规范适合提供符合软件要求的证据；根据软件资格测试策略和发布计划，选取软件资格测试规范中的测试用例；使用选定的测试用例对集成软件进行测试，并将测试结果记录在案；建立软件合格性测试规范中软件需求和测试用例的一致性和双向可追溯性，建立测试用例和测试结果的一致性和双向可追溯性；总结软件资格测试结果并与所有受影响的各方进行沟通。3、V模型的可追溯性和一致性要求汽车软件开发过程中有严格的可追溯性和一致性要求。每个阶段的过程要求、工具方法和人员要求，上一阶段的输出可交付成果作为下一阶段的输入，每个阶段完成后对可交付成果进行验证，最后阶段确认与软件需求的符合性软件集成后。概况如下图所示：4.V型车面临的挑战特斯拉人工智能总监AndrejKarparthy在他的一篇技术博客中提出了构建软件2.0技术栈的想法，代码从软件转向1.0（人类编写的代码）过渡到软件2.0（优化编写的代码，以神经网络训练的形式编写）。软件1.0就是我们熟悉的V模型，它是用Python、C++、C等语言编写的。它由程序员对计算机的显式指令组成，通过编写每一行代码，程序员识别程序空间中具有某些理想行为的特定点。软件1.0的工程方法遵循以下四个步骤：确定要解决的问题，即需求；分解需求；为每个分解的需求设计软件；逐步测试、集成和部署软件。软件2.0时代正在逐渐到来。目前，人工智能算法广泛应用于自然语言识别、行为分析、辅助决策、身份识别等不涉及公共安全的领域。也逐步应用于自动驾驶、医疗诊断等安全领域。对于安全关键系统，系统工程方法论是否还适用于软件2.0时代，不同行业安全软件开发所遵循的IEC61508、ISO26262、EN50128等功能安全标准是否也能指导开发实践软件2.0.下面从开发过程中，从软件需求、开发工具等方面谈谈思路。4.1.软件2.0开发流程软件1.0的开发生命周期模型采用系统工程V模型的方式开发，自上而下瀑布式，明确了每个阶段的流程要求、使用的工具和方法以及人员要求。输出的可交付成果作为下一阶段的输入，每个阶段完成后对可交付成果进行验证，在软件集成后的最后阶段确认与软件需求的一致性。在实际应用中，小版本之间的迭代是在设计实现阶段和测试阶段进行规划的。从整体流程来看，依然是V型。在软件2.0中，软件的行为要求在很大程度上取决于所使用的数据集。数据集不同于传统意义上的数据。以前的数据如传感器数据、系统参数（如配置参数、校准数据等）或系统使用的数据库（如导航数据库、障碍物数据库等），这些数据可以决定系统的行为以一定程度上，但他们没有描述这种行为的逻辑。而机器学习所用到的数据集不仅用来提取信息，还用来建立模型，用来处理其他数据和判断一个系统的行为，来判断安全关键系统的需求，相当于软件要求。当在软件需求阶段无法获得完整的训练数据集时，从V模型的角度来看，后续的架构、设计和实现阶段就无法启动。Software2.0的开发模式从数据开始，分为数据管理、模型训练、模型验证、模型部署。这四个阶段不断迭代，并非一次完成。数据管理：首先建立所需数据集的需求，通过数据分析确定数据采集、增强和预处理的要求，采集什么数据，如何采集数据，如何解决样本数量不足和采集量高的问题成本，如何清理和预处理收集到的数据。模型训练：选择要使用的模型，建立一个损失函数作为训练误差的度量，训练的目的是产生一个最小化这个误差的模型。需要针对训练模型、验证模型和测试模型的比例制定合适的数据拆分策略。模型验证：通过对数据管理阶段生成的独立于训练数据集的验证数据集进行测试，评估训练模型的性能。模型部署：使用经过验证的模型的系统将被集成，将经过验证的ML模型与使用传统软件工程方法开发和验证的系统组件集成，监控它们的运行，并通过在线维护或在线学习进行更新。4.2.软件2.0的新软件需求：数据集由于软件2.0的系统行为主要由数据集决定，因此系统能否达到预期的功能在很大程度上取决于数据集的质量。证明数据集足以在系统运行环境下实现软件的预期功能，这对认证来说非常具有挑战性。与软件1.0的需求相比，有以下不同：确定软件需求不是在需求阶段，而是在软件开发阶段，软件设计和实现的输入将不再是软件的功能需求，但是训练过程的输出。例如神经网络架构、权重和偏差。没有需求和设计实现的可追溯性，神经网络结构和权重无法追溯到开发它们的软件需求、描述预期属性的需求文档或训练数据集。安全软件的验证方式不再适用于数据集和训练模型。人类已经无法理解，无法实现人工审核和分析。传统的基于需求的软件测试方法无法进行。例如，功能安全软件测试用例采用的等价类生成分析，由于常规规模神经网络的高度复杂性和非线性特性，不适用于模型的实现。无法确定神经网络模型算法的等价类。ISO26262软件单元测试用例生成推荐方法数据集属性不同于软件需求保证属性，传统的软件需求完整性、清晰性、准确性、无歧义性、可验证性、可测试性、可维护性、可扩展性这些属性的含义需要重新定义。网络权重作为参数数据项，与传统的数据配置文件有着本质的区别。按照现有的配置参数修改流程应用网络权重存在较大偏差。4.3.Software2.0开发工具链在传统软件开发中，已经建立了完整的工具链来支撑开发，集成开发环境、编辑器、编译器、调试器、git集成、单元测试、集成测试工具、功能安全软件工具在识别中软件工具，根据对软件安全的影响分为不同的等级。例如，ISO26262-8将软件工具分为TCL1、TCL2和TCL3。在Software2.0中，工具也可以按照类似的分类进行分类，但是没有完整的开发工具链和如何识别工具的标准。从软件领域的发展来看，软件2.0的规模越来越大，出现了机器自动生成的代码。当这类软件应用于安全关键系统时，可能会彻底改变现有软件的开发模式。找出与现有标准、航空航天、铁路和汽车标准等安全关键领域的差异，并采用协作的方式在不同领域之间积累经验；应用软件2.0产品的识别不再是一次性的，软件2.0的生命周期是相似的，是一个迭代的过程。系统性能评价是一个重要环节；软件变化会更频繁，比如智能网联汽车的OTA功能。软件变更的评估应考虑其服务期和运行设计域。所有存在的数据记录如差异、产品异常行为记录报告等。
