做开发除了需要高效的编码能力，同样也离不开编程思维的指导。作为刚刚进入汽车电子行业的开发小白，本篇博文将总结最近学习到的汽车软件行业开发思维：V模型。
1、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模型面临的挑战
特斯拉人工智能总监Andrej Karparthy在他的一篇技术博客中提出构建软件2.0技术栈的观点，代码正在从软件 1.0（由人类编写的代码）过渡到软件 2.0（由优化编写的代码，以神经网络训练的形式编写）。
软件1.0 是我们熟悉的V模型，它是用 Python、C++、C等语言书写的。它包括程序员对计算机的明确说明，通过编写每行代码，程序员会用一些可取的行为识别程序空间中的特定点。
软件1.0的工程方法遵循以下4个步骤：
- 确定要解决的问题，即需求；
- 把需求进行分解；
- 为每个分解的需求设计软件；
- 逐级测试，集成并部署软件。
软件2.0时代正在逐渐到来，目前AI算法大量应用于自然语言识别、行为分析、决策协助、身份识别等不涉及公众安全的领域，也在自动驾驶、医疗诊断等安全领域也在逐步应用。对于安全关键系统，系统工程方法学是否还适合软件2.0时代，功能安全标准如IEC61508、ISO26262、EN50128不同行业安全软件开发所遵循的标准，是否还能指导软件2.0的开发实践，下面从开发过程、软件需求、开发工具三个方面谈谈想法。
4.1、软件2.0开发过程
软件1.0的开发生命周期模型按照系统工程V模型的方式开发，从上到下是瀑布式的，规定每个阶段的过程要求、使用的工具方法和人员要求，前一阶段的输出交付物作为下一阶段输入，在每个阶段完成后对交付物进行验证，在软件集成后在最后阶段进行确认与软件需求的一致性。在实际应用中，设计实现阶段和测试阶段，会规划小版本之间的迭代，从整体过程来看还是V模型。
在软件2.0中，软件的行为需求很大程度上取决于所使用的数据集（datasets），数据集不同于传统意义上的数据，以往的数据如传感器数据、系统的参数（如配置参数、校准数据等）或系统使用的数据库（如导航数据库、障碍物数据库等），这些数据可以一定程度上确定系统的行为，但它们并不描述这种行为的逻辑。而机器学习使用的数据集不仅用来提取信息，而且用来建立模型，用来处理其他数据并确定一个系统的行为，确定安全关键系统的需求，等同于软件需求。当软件需求阶段无法获得完整的训练数据集，从V模型来说，后面的架构、设计实现阶段也无法开始。
软件2.0的开发模型始于数据，可以划分为数据管理、模型训练、模型验证、模型部署，这四个阶段不断往复迭代，不是一次性完成的。
数据管理：先建立所需数据集的要求，通过对数据的分析确定数据收集、增强和预处理的需求，收集什么数据，如何收集数据，如何解决样本数不足，收集成本过高的问题，如何对收集的数据清洗预处理。
模型训练：选择所使用的模型，构建损失函数作为训练误差的衡量标准，训练的目的是产生一个最小化该误差的模型。需要制定一个合适的数据拆分策略，用于训练模型、验证模型、测试模型的比例。
模型验证：针对数据管理阶段产生的独立于训练数据集的验证数据集，通过测试评估训练模型的性能。
模型部署：使用验证过的模型的系统将被集成，将经过验证的ML模型与使用传统软件工程方法开发和验证的系统组件进行整合，对其运行进行监控，并通过在线维护或在线学习进行更新。
4.2、软件2.0新的软件需求：数据集
既然软件2.0的系统行为主要由数据集决定，系统是否符合其预期功能，很大程度上取决于数据集的质量。要证明数据集对于软件的预期功能在系统的操作环境下是足够的，对于认证来说是非常大的挑战。与软件1.0的需求对比，有以下不同：
- 确定软件需求不是在需求阶段，而是在软件开发阶段，对软件设计实现的输入将不是软件的功能需求，而是训练过程的输出。如一个神经网络架构、权重和偏差。
- 需求和设计实现不具备可追溯性，神经网络结构和权重不能追溯到开发它们的软件需求，追溯不到描述预期属性的需求文件，也追溯不到训练数据集。
- 安全软件的验证方法不再适合数据集及训练模型，人类已无法理解，无法实现人工审查和分析，传统软件基于需求的测试方法也无法进行。例如，功能安全软件的测试用例采用的等价类生成分析，由于常规规模的神经网络的高度复杂和非线性特征，不适用于模型的实施。要确定神经网络模型算法的等价类是不可能的。
ISO26262 软件单元测试用例生成推荐方法
- 数据集的属性与软件需求保证属性存在差异，传统软件需求的完整性，清晰性，精确性，无歧义性，可验证性，可测试性，可维护性，可扩展性 这些属性的含义需要重新定义。
- 网络权重作为参数数据项，在本质上与传统的数据配置文件不同，依据已有配置参数修改流程而套用网络权重，存在很大偏差。
4.3、软件2.0开发工具链
传统软件开发中已建立完善的工具链用于支持开发，集成开发环境，编辑器，编译器，调试器，git集成，单元测试，集成测试工具，在功能安全软件工具的鉴定中，根据工具对软件安全性影响的不同，划分为不同的级别，例如ISO26262-8对软件工具的TCL1、TCL2和TCL3分级。在软件2.0中，也可以按照类似的分类对工具进行分级，但目前还没有完善的开发工具链和如何对工具鉴定的标准。
从软件领域的发展来看，软件2.0所占的规模越来越大，已出现机器自动生成的代码，当这类软件应用于安全关键系统时，有可能彻底改变既有软件的开发模式，需要识别与现有标准的差异，安全关键领域如航空航天、铁路、汽车标准，采用协作的方式在不同领域之间获取经验；对应用软件2.0产品的鉴定也不再是一次性的，与软件2.0生命周期类似，是一个迭代的过程，评估系统运行性能表现是重要环节；软件的变更会更加频繁，如智能网联汽车的OTA功能，对软件变更的评估，应考虑其服务期限、运行设计域差异、产品异常行为记录报告等所有既有数据记录。
