开发不仅需要高效的编码能力，更需要编程思维的指导。 作为一个刚刚进入车载电子行业的开发新手，这篇博文将总结一下我最近学到的车载软件行业的开发思维：V模型。
1.V模型概述
车辆软件开发流程中的V模型已经是业界开发者的通用模型。 它是由大瀑布模型演变而来，是目前汽车行业应用最广泛的软件开发模型。 由于该模型的灯光酷似字母V，所以也被称为V模型。 V模型的核心思想是通过A-SPICE流程（汽车行业软件流程改进和能力测量标准）来支持和管理整个开发流程，从需求到源代码的每个流程都有相应的测试。
V模型大致可以定义为几个不同的步骤：功能需求、功能开发、软件开发、软件集成测试、功能集成测试、整车集成测试（系统资格测试），如右图所示，右为流程需求分析和设计开发的过程中，右侧是左侧的测试验证，右侧的每个流程都与右侧的流程相对应。
从系统需求到软件需求，再到软件发布，都需要工具来管理，以达到可追溯、可记录的目的。 目前市场上的主流工具丰富有Door、ClearCase、GIT、SDOM等，也有一些公司自己开发。事实上，此类工具的操作方法都符合V的要求、开发和测试要求。过程。
2、V模型的实现
2.1. 系统需求分析
系统需求需要由系统工程师来完成。
根据项目的总体需求，以及软硬件的总体定义，进行系统逻辑架构的总体定义。 这部分工作包括：硬件功能的定义、控制器与其他控制器之间通信的定义、软件简单功能的定义。 该流程没有定义具体的技术实现。
2.2. 软件需求分析
软件需求需要由系统工程师来完成。
系统工程师根据系统相关方需求规格、软硬件socket文件、变更通知等的输入，梳理并定义软件开发需求规格，包括操作系统需求、电源管理策略、传感器读取、执行器控制、信号特征需求，以及存储服务、通信服务、网络管理、故障诊断、标定、程序升级等功能需求和非功能需求。
根据项目计划，制定软件开发计划。
软件需求分析构建需求跟踪矩阵，将软件需求映射到系统需求，并确保覆盖软件要实现的所有系统需求。
该过程成功执行的结果如下：
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时代正在逐渐到来。 目前，人工智能算法广泛应用于自然语言识别、行为分析、决策辅助、身份识别等不涉及公共安全的领域。 它们也逐渐应用于手动驾驶、医疗诊断等安全领域。 对于安全关键系统，系统工程方法是否仍然适合软件2.0时代，不同行业安全软件开发所遵循的功能安全标准，如IEC61508、ISO26262、EN50128等是否可以指导开发软件2.0的实践，下面是从开发流程、软件需求和开发工具三个方面讲一下。
4.1. 软件2.0开发流程
软件1.0的开发生命周期模型以系统工程V模型的形式进行开发，它是自上而下的瀑布式，明确了每个阶段的流程要求、工具和人员要求，以及前一阶段的输出可交付成果作为下一个阶段的输入，每个阶段完成后对交付成果进行验证，并在软件集成后的最后阶段确认与软件需求的一致性。 在实际应用中，小版本之间的迭代是在设计实现阶段和测试阶段规划的。 从整体流程来看，仍然是V型模式。
在软件 2.0 中，软件的行为要求很大程度上取决于所使用的数据集。 数据集不同于传统意义上的数据。 前几年的数据，如传感数据、系统参数（如配置参数、标定数据等）或系统使用的数据库（如导航数据库、障碍物数据库等），这些数据可以确定机器人的行为系统在一定程度上，但它们没有描述这些行为的逻辑。 除了提取信息和构建模型之外，机器学习使用的数据集还用于处理其他数据并确定系统的行为，并确定安全关键系统的需求，这相当于软件需求。 当软件需求阶段无法获得完整的训练数据集时，从V模型的角度来看，相邻的架构、设计和实现阶段也无法启动。
软件2.0的开发模式源于数据，可以定义为数据管理、模型训练、模型验证、模型部署。 这四个阶段是不断迭代的，并不是一次性完成的。
数据管理：首先构建所需数据集的需求，通过数据分析确定数据采集、增强和预处理的要求，采集什么数据，如何采集数据，如何解决样本数量不足、成本高的问题收集的过程，如何清理和预处理收集到的数据。
模型训练：选择要使用的模型，建立损失函数作为训练偏差的标准。 训练的目的是形成一个使偏差最小化的模型。 需要针对训练模型、验证模型、测试模型的比例制定合适的数据分割策略。
模型验证：通过对数据管理阶段形成的独立于训练数据集的验证数据集进行测试来评估训练模型的性能。
模型部署：使用经过验证的模型的系统将被集成，将经过验证的机器学习模型与使用传统软件工程方法开发和验证的系统组件集成，监控其运行，并进行在线维护或在线学习。 更新。
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功能，软件变更的评估应考虑其使用寿命和操作设计领域所有现有的数据记录如差异、产品异常行为记录报告等。
参考：
1. 汽车软件开发V流程
2、自动驾驶工程实现的障碍是什么？宏观设计
3、软件2.0时代功能安全的思考
4、汽车软件开发模型——瀑布模型/V模型
