一、自动驾驶软件开发流程
1. 软件 1.0 时代：V 模型开发流程
1.1 V 模型开发流程
为确保底层和应用层软件开发的质量和效率，汽车行业普遍遵循“V”模式开发流程。V 流程来源于软件开发过程中一个称为快速应用开发的模型，因其流程图形似字母 V 而得名。V 模型是软件开发、测试中最重要的一种模型，其大体可划分为几个不同的阶段步骤，即系统需求分析、系统架构设计、软件需求分析、软件架构设计、软件单元设计、软件单元测试、软件集成测试、系统集成测试、整车集成测试（系统合格性测试）。左边为需求分析和设计开发的过程，右边则为针对左边的测试验证/确认阶段。
软件开发的 V 模型流程
1.2 V 模型开发中的追溯性和一致性要求
汽车软件开发的过程中有严格的追溯性和一致性要求。追溯性要求在开发阶段主要体现在开发人员可以从高层次的需求追溯到低层次的设计和代码，也可以从低层次的实现追溯回高层次的需求；在测试阶段主要体现在测试人员能够追溯到需求规格、设计文档，确保测试用例的设计和执行与开发阶段的需求和设计文档双向可追溯。一致性要求在开发阶段主要体现在开发人员在编写代码时要遵循设计规范和标准，确保代码的质量和结构与设计一致（即开发过程的各阶段输入、输出保持一致）；在测试阶段主要体现在测试人员在测试过程中要根据需求规格书编写测试用例，遵循测试计划和测试策略，确保测试内容与设计要求之间的关系和结果保持一致。
2. 软件 2.0 时代：敏捷开发流程
软件 2.0 时代正在逐渐到来，目前AI算法大量应用于自然语言识别、行为分析、决策协助、身份识别等不涉及公众安全的领域，也在自动驾驶、医疗诊断等安全领域也在逐步应用。特斯拉人工智能总监 Andrej Karparthy 2017年在他的一篇技术博客中提出构建软件 2.0 技术栈的观点，代码正在从软件 1.0（由人类编写的代码）过渡到软件 2.0（以神经网络训练的形式编写）。
2.1 编码特点
软件 1.0 的开发生命周期模型按照系统工程“V”模型的方式开发，从上到下是瀑布式的，规定每个阶段的过程要求、使用的工具方法和人员要求，前一阶段的输出交付物作为下一阶段输入，在每个阶段完成后对交付物进行验证，在软件集成后在最后阶段进行确认与软件需求的一致性。在实际应用中，设计实现阶段和测试阶段，会规划小版本之间的迭代，从整体过程来看还是V模型。
我们所熟悉的软件 1.0 是用 Python、C++ 等语言编写的。这类软件包含了程序员为计算机撰写的明确指令。程序员通过编写代码的每一行，标定了程序空间中某一特定点，这一点展现了某种我们期望的行为。与此相反，软件 2.0 的编写语言则更加抽象且对人类不那么友好，例如神经网络中的权重。在这种情况下，人类并不直接参与代码编写，因为涉及的权重实在太多了（典型的网络可能有数百万个权重），直接使用权重来编码是相当困难的。
在软件 1.0 中，由人工编写的源代码（比如一些 .cpp 文件）会被编译成能够执行实际工作的二进制文件。而在软件 2.0 中，源代码主要包括两部分：1）定义理想行为的数据集；2）神经网络架构，它为代码提供了基本框架，但许多细节（如权重）还需要填充。神经网络的训练过程实际上是将数据集编译成二进制文件——即最终的神经网络。在当今的大多数实际应用中，神经网络架构和训练系统正在变得越来越标准化，成为一种常规产品，因此软件 2.0 时代的大部分“软件开发”实际上变成了策划、扩充、调整和清洗已标记的数据集。这种做法从根本上改变了我们对软件进行迭代的编程范式，团队也因此分为两个部分：2.0 程序员（数据标注者）负责编辑和扩展数据集，而少数 1.0 程序员则负责维护和改进训练代码的基础设施、分析工具、可视化和标注接口。
2.2 数据集
软件 2.0 中，软件的行为需求很大程度上取决于所使用的数据集（datasets），数据集不同于传统意义上的数据，以往的数据如传感器数据、系统的参数（如配置参数、校准数据等）或系统使用的数据库（如导航数据库、障碍物数据库等），这些数据可以一定程度上确定系统的行为，但它们并不描述和改变这种行为的逻辑。而机器学习使用的数据集不仅用来提取信息，而且用来建立模型，用来处理其他数据并确定一个系统的行为，确定安全关键系统的需求，等同于软件需求。当软件需求阶段无法获得完整的训练数据集，从 V 模型来说，后面的架构、设计实现阶段也无法开始。
2.3 软件 2.0 开发过程
软件 2.0 的开发模型始于数据，可以划分为数据管理、模型训练、模型验证、模型部署，这四个阶段不断往复迭代，不是一次性完成的。
- 数据管理：先建立所需数据集的要求，通过对数据的分析确定数据收集、增强和预处理的需求，收集什么数据，如何收集数据，如何解决样本数不足，收集成本过高的问题，如何对收集的数据清洗预处理。
- 模型训练：选择所使用的模型，构建损失函数作为训练误差的衡量标准，训练的目的是产生一个最小化该误差的模型。需要制定一个合适的数据拆分策略，用于训练模型、验证模型、测试模型的比例。
- 模型验证：针对数据管理阶段产生的独立于训练数据集的验证数据集，通过测试评估训练模型的性能。
- 模型部署：使用验证过的模型的系统将被集成，将经过验证的 ML 模型与使用传统软件工程方法开发和验证的系统组件进行整合，对其运行进行监控，并通过在线维护或在线学习进行更新。
以FSD数据引擎为例，该系统起始于一个已经人工标注好的数据集，通过该数据集对算法进行初步训练，训练完成后，算法通过云端下发部署到配备有影子模式（Shadow Mode）的车队中。在影子模式下，尽管自动驾驶系统会根据环境做出预测和决策，但这些决策不会直接控制车辆，而是与人类驾驶员的实际操作进行对比。如果影子模式下车端发现了异常情况（比如司机实际操作和算法所预测的操作不符合），则将异常情况的数据回传到云端，如此，通过整个庞大的车队收集的类似数据将经过人工标注后，补充到原始数据集中，然后再次对算法进行训练，再次进行车端部署……如此循环反复，从而实现一个数据标注和训练的大循环。
这种方式体现了软件 2.0 中以数据迭代渐进为主线的敏捷开发理念，与传统的瀑布式软件开发方法有着显著的不同。后者通常遵循严格的线性流程，而前者则更加注重快速迭代和持续优化，以适应复杂多变的实际应用场景。
3. 自动驾驶软件开发测试流程
自动驾驶汽车的量产涉及到极为复杂的软硬件一体化系统的开发，既要遵循正向开发的严谨性，也要应对自动驾驶系统中被大量应用的深度学习算法和需求定义的不确定性。在自动驾驶量产实践中，需对传统V模型开发方法、软件2.0时代敏捷开发方法和测试验证体系进行创新融合，建立一套统一的自动驾驶软件开发与测试流程，以确保高效、灵活且高质量的产品开发。
- 需求定义与设计：V 模型左侧对应设计过程，自顶向下共计四层，依次为需求分析、整车系统设计、自动驾驶域架构设计、自动驾驶软件模块设计。
- 测试与验证：V 模型右侧对应测试验证过程，与左侧设计层次一一对应，自底向上依次为单元/模块测试、集成测试、系统测试、验收测试。每个测试阶段都与测试验证体系中相应的仿真/实车测试方法相匹配，确保整个软件硬件系统的质量和可靠性。
- 敏捷迭代闭环：在 V 模型左侧的软件模块设计和 V 模型右侧的四层测试验证过程之间，通过敏捷开发模式贯穿起来，获得足够的敏捷性和效率。
二、自动驾驶仿真测试平台发展过程（技术方向）
自动驾驶主流的“三支柱 ”测试架构包括仿真测试、封闭场地测试和开放道路测试。随着自动驾驶车辆技术的发展，交通场景越来越复杂，交通参与者与日剧增，单一测试方法很难确保测试效果，未来的自动驾驶车辆测试将更注重仿真测试、封闭场地测试、开放道路测试三者的有机融合。相较于后两者，仿真测试具有高安全性、低成本、高效率、并且能够灵活模拟各类极端交通场景等优势。通过构建自动驾驶仿真测试平台，可以在虚拟环境中安全、高效、低成本地验证和优化自动驾驶车辆的各项功能与性能指标，确保其在面对复杂的交通场景时能够做出准确、快速的反应。
与软件开发过程相类似，自动驾驶仿真测试体系的发展也经历了从基于模型设计（Model Based Design，MBD）的ADAS仿真阶段（仿真测试1.0）向以数据闭环驱动为核心、重场景的自动驾驶仿真阶段（仿真测试2.0）的演变过程。
1. 仿真测试 1.0 时代：基于MBD的ADAS仿真测试阶段
早期的仿真主要是以动力学仿真为主，用来对整车的动力性、操稳性、制动性等基础车控进行建模仿真，软件以Carsim为代表。
随着一些相对简单的辅助驾驶（ADAS）功能的开发，场景的概念开始被引入。于是，能够提供简单的道路环境，可以对交通车辆、行人等动态要素进行编辑，以及布局简单传感器模型的ADAS开发仿真软件开始出现，例如Prescan。同时，以往那些纯粹的动力学软件也朝着这个方向进化。
此时，V模型左侧的设计开发流程，其方式主要是以基于模型的设计（Model Based Design，MBD）为主（ISO26262也要求车规级软件需要基于MBD开发）。大多数公司基于Matlab Simulink提供的工具箱来搭建快速模型，然后导入用Prescan等软件创建的较为简单的场景、导入CarSim等软件创建的车辆动力学模型，进而对被测对象进行联合仿真验证；然后利用Simulink自动生成工业级的C代码，并烧写到控制器上，应用dSPACE、SpeedGaot、NI等公司提供的快速原型硬件进行下一步的HIL、VIL测试验证流程。
运用此开发手段，从算法构想、到快速模型、再到SIL、HIL的仿真测试，最后到工业部署一整套的开发流程得以快速实现，围绕Simulink的工具链的功能安全和测试验证流程严格且成熟，保证了车企规模化的稳定量产。
但该套开发方案也存在很多局限性，例如：
- ADAS测试仅针对离散场景测试需求而没有考虑连续的交通流，无法支持大规模城市级仿真；
- 软件仅仅运行在单机上，虽预留了交通流仿真软件接口，可以跟车辆动力学仿真软件和交通流仿真软件构成联合仿真平台。但受限于仿真实时性和本地算力，联合仿真平台仍然难以支持城市级仿真；
- Simulink 物理组块建模的方式，使得其十分偏向于底层运动控制算法以及车辆动力学层面（即操控性）的验证，而非以数据驱动为核心、基于深度学习算法的感知和规划层算法的验证。
当前，L3+主流开发框架和生态与Simulink兼容性不高，基于MBD的方法论、以及Simulink提供的结构化工具箱和组块建模，在应对重场景+深度学习算法时候，显得力不从心。
综上，当前的自动驾驶软件开发工程师往往选择直接编程搭建仿真系统，而不是像以往一样用Simulink建模，自动生成代码。当然，以上也不意味着传统的方法完全过时。V模型的开发流程在实际生产中仍然具有重要意义，对于OEM而言，能够提供从MIL到VIL整套自动驾驶仿真解决方案，才有可能转化为真正的生产力。
2. 仿真测试 2.0 时代：以数据闭环驱动为核心、重场景的自动驾驶仿真阶段
随着以Waymo为代表的L4+厂商出现，仿真技术迎来了突破。此类厂商运用仿真技术搭建逼近真实的虚拟自动驾驶测试环境，来对自动驾驶算法进行测试。尤其是基于AI的感知、决策算法。这个时候仿真场景的重要性第一次被业界所重视。
2015年前后，出现了一批基于游戏引擎（主要是Unreal，Unity）开发的自动驾驶仿真平台，其最明显的特征就是场景比以往丰富的多，也真实的多。而传统的仿真工具链也在朝着这个方向进化，比如2020年4月，Mathworks收购了地图编辑软件RoadRunner，升级了构建大规模静态场景的能力；Simulink也开放了与Unreal引擎联合仿真接口，提升了传统工具链在场景搭建方面的实力。
一个完整的自动驾驶仿真测试平台集成了静态场景还原、动态案例仿真、车载传感器仿真、车辆动力学仿真等功能，同时提供了高效的并行加速计算能力，支持通过云技术实现大规模的仿真部署。该平台还设计了易于接入自动驾驶感知、决策、规划和控制算法的接口，确保各模块的设计开发与仿真测试环境紧密耦合，形成闭环迭代优化机制，从而有效支持各类自动驾驶算法的开发、测试与验证。
当前自动驾驶仿真测试工具的种类较多，联系十分复杂，不过当前自动驾驶仿真平台的技术方向基本一致：
2.1 静、动态场景构建
技术方向：
- 基于游戏引擎开发，以实现对静态、动态场景的高保真渲染和物理模拟；
- 具有静态场景编辑功能，支持基于高精地图的静态场景搭建；
- 具有动态场景编辑功能，支持交通流仿真（或从第三方软件接入）；
主要需求：
- 如何快速构建高精度的大规模城市级测试场景，实现被测试车辆的长时间连续测评；
- 如何通过智能体重建、数据增强等技术将闭环测试（主要针对自动驾驶系统的决策、规划、控制和执行环节）和开环测试（主要针对自动驾驶系统的感知模块）的优势结合起来，构建基于场景数据库驱动的开/闭环融合测试方法；
2.2 车载传感器仿真
- 传感器的仿真一般不会太复杂，一般仿真平台都会自带，关键是要基于物理模型；
2.3 汽车动力学仿真
- 汽车动力学模型则一般由外部的专业仿真软件导入；
2.4 云计算平台仿真
- 支持分布式的云平台仿真 ，调动大量算力实现物理加速测试；
- 云端大模型数据训练和知识蒸馏技术；
三、自动驾驶仿真测试实施方法
汽车自动驾驶仿真测试具体实施过程主要分为以下几个过程：仿真测试需求分析、仿真测试对象分析、仿真测方案设计、仿真测试方案实施及仿真测试结果评价，如下图所示。
从自动驾驶算法开发的完整链条分析，仿真测试对象可分为自动驾驶算法模型、算法模块集成、自动驾驶单体控制器、自动驾驶系统级零部件和自动驾驶实车。此外，这些测试对象也可归类为软件、硬件和产品（实车）三大领域，软件测试主要验证代码逻辑的正确性，硬件测试关注智驾域控制器的性能和稳定性，而实车测试则注重系统整体表现和驾乘体验。通过这种多层次、多领域的综合测试方法，确保了自动驾驶技术的安全性和可靠性。
1. MIL 模型在环测试
自动驾驶算法模型包括感知识别算法、数据融合算法、目标筛选算法、决策规划、控制执行算法等。针对算法模型设计阶段的测试一般采用单元测试和模块测试相结合的方法，核心在于验证代码逻辑的正确性。此外，还会进行软件性能测试，评估软件在特定负载条件下的表现。
- 算法模型测试第一步是静态测试，会对程序结构和编码规范进行分析，通过CodeReview来评估代码的静态设计是否合理；
- 单元测试通过对比程序的实际运行结果与预期值，来验证代码的功能逻辑是否准确，确保每个单元能够按照设计要求正确无误地工作；
- 模块级别的测试一般也被称为模型在环测试（MIL），MIL 测试一般采用带被控对象的闭环测试方法，测试目的是验证算法模型功能是否完整、正确。此外，MIL 测试还涉及部分模型性能指标，例如感知模块的识别精度等；
- 性能测试则主要是评估软件在特定负载条件下的表现，包括响应时间、吞吐量、资源利用率和稳定性等方面。这项测试旨在确保软件即使在高负载或极端条件下也能保持高效的运行状态。
2. SIL 软件在环测试
SIL（Software-in-the-Loop）测试的关键在于如何搭建一个逼真的运行环境，实现真实场景在仿真环境中的复现，对自动驾驶算法模块的集成进行闭环验证（被测对象与周围环境存在交互）。仿真环境要素包括：车辆动力学模型、车载传感器模型、环境交通模型等。SIL 测试不考虑目标硬件，可以在服务器上大量部署，成本较低，核心用于验证智驾功能的闭环运行正确性。SIL 测试可以划分为使用语义级仿真系统进行的局部闭环测试，以及使用环境渲染级别仿真系统进行的软件全功能闭环测试。
语义级仿真通常不需要详细建模环境中的每一个细节，而侧重于高级别的行为逻辑和决策过程。语义级仿真场景中的各个对象信息，是以标签的形式存在的，而不是基于图像中的像素值来表示，它更关心算法如何根据识别到的对象和它们的状态（如位置、速度、方向等）来做出决策。因此，可以在较简单的计算资源上运行，速度更快，成本更低。这使得开发团队可以快速地测试和迭代不同的算法和策略，特别适合于早期的功能验证和算法开发。
3. PIL 处理器在环测试
一个在 X86 上稳定运行的软件，在嵌入式环境下可能出现堆栈溢出，调度混乱，时间戳不稳定，系统调用支持不到位，内存读取异常，运行阻塞等一系列问题。为了排查这种差异，在软件逻辑层面之上可以继续引入目标硬件这个维度，也就是处理器在环测试 Processor-in-the-Loop（PIL），PIL 将部分代码放置于目标处理器上，验证代码功能正确性的同时，确认其性能是否达到要求。比如，软件最长耗时，系统调用可靠性等。
PIL测试专注于验证编译后的代码在目标处理器上的功能和性能。PIL 测试本质上是一种等效性测试，旨在验证自动生成的代码在目标处理器上的执行结果与模型仿真结果是否一致。PIL 测试通常在软件开发的早期阶段进行，成本相对较低。通过在实际的控制器上运行代码，PIL 测试不仅能检查代码与模型的一致性，还能获取算法在真实硬件上的最长运行时间，系统调用可靠性等，以确保其性能满足要求。此外，PIL测试也有助于发现编译器优化问题或硬件兼容性问题。
4. HIL 硬件在环测试
HIL 测试区别于 SIL，需要考虑目标硬件，因为成本较高一般不会大量部署，其结果相比 SIL 更接近真实状态，可以额外评估软件在目标硬件上的整体性能（运行调度，内存调用，算力调用）是否符合预期。HIL 测试通常将一个被测控制器和一系列模拟设备做硬线（PWM、UART、CAN、GPIO 等）连接，将记录或模拟的原始数据反向构建成真实信号输入，来完成对目标硬件的测试工作。
HIL 测试是一种更为全面的测试方法，它不仅验证软件的功能，还测试整个控制系统，包括硬件、底层软件和应用层软件。HIL 测试通常将一个被测控制器和工控机相连，工控机上运行着被控对象的模型，并且模拟出被控对象的一些电气特性。在 HIL 场景下，被测试的控制器并不知道和它相连的是一台工控机，它会认为自己连接的就是真实的实物对象。针对系统级零部件对象，基本的 HIL 测试环境与 PIL 相类似，不同的是该类测试中测试对象往往还包括真实的传感器及真实的底盘执行系统，需要根据真实接入的系统零部件进行相关仿真环境的搭建，如毫米波雷达模拟器、超声波仿真板卡、摄像头暗箱或使用视频注入板卡、驾驶员模拟器等。
在实践过程中，切勿执着于全功能长周期工作的 HIL 台架，20台轻量级 HIL 台架（PIL 台架）的价格可能还不及1台全功能 HIL 台架，效果上两者对比差距却并不大。一部分物理IO，一部分功能模拟往往更为科学，HIL 台架一般仅用于短周期的闭环测试，长周期测试往往会有较大误差。
5. DIL 驾驶员在环测试
上述四种自动驾驶仿真测试方法只能给出测试的客观数据、逻辑，对数据、逻辑符合性并不能进行主观评价。驾驶员是最终用户，因此其主观评价也应是测试中的重要环节。DIL 测试正是将驾驶员引入汽车测试环节的技术，在原理样车还未开发出来之前，利用参数化或硬件在环技术，对车辆的相关性能进行测试、评价，保证前期设计的正确性、测试的充分性，从而缩短整车开发的周期、节省开发成本。
DIL 测试常用于自动驾驶测试评价的如下方面：
- 自动驾驶功能与性能测试：配合场景模型及硬件在环设备，在产品设计阶段对自动驾驶的功能与性能进行模拟真实道路场景的测试，并且驾驶员可以对测试过程中所表现出来的性能进行主观评价；
- 人机切换策略测试：在人机共驾过程中，通过对切换时间、舒适性、安全性等的评价，来评估人机共驾策略的合理性；
- HMI（Human Machine Interface，人机交互界面）系统设计：配合驾驶模拟器中可配置的人机交互界面，在概念设计初期从声音、图像等方面对人机交互界面进行主观评价，尽早发现设计中的缺陷并完善，从而提高设计质量和效率；
- 驾驶员行为分析：通过给驾驶员穿戴相关的传感设备，可以在自动驾驶的不同交通场景下对驾驶员的行为进行分析，如疲劳、注意力、心跳、压力、焦虑等。
6. VIL 车辆在环测试
完成了自动驾驶单体控制器和系统级零部件的 HIL 测试后，智能驾驶测试会继续进入整车级别。VIL（Vehicle-in-Loop）或者说实车虚拟注入测试，即通过在软件内部配置断面测试接口，在封闭测试场内的实车测试环境下，屏蔽部分真实感知输入，从而在测试场内的空旷区域模拟任何形式的道路环境。比如在路上添加并不存在的车辆，或是模拟一个交叉口的信号灯切换。由于其他测试要素均为真实内容，因此测试可信度高，且可以充分利用封闭测试场的环境资源。
另一种 VIL 的全新形态是实车交通环境在环测试（VTEHIL），在室内场地构建模拟的周边环境变化以及车辆移动，来进行智能驾驶车的测试。由于环境完全受控，不受到气候变化影响，可实现24小时连续测试，并且可以高效且完整模拟极端工况。
7. RIL 道路在环测试
进一步往下，是道路在环测试 RIL（Road-in-Loop）或者说封闭场地测试。除了环境参与者和司机之外（即假人假车），其他全部都是真实要素。在常规汽车测试体系中，此种测试手段也是常规操作，但不同于过去人工遥控和摆放的实施手段，目前已经出现了自动化测试方案，由于最新的假人假车装备同样配置了必要的传感器，执行器与通信设备，可以接入云端集中指挥调度。因此云端的测试用例可以同步到封闭测试场内被智能假人和假车“表演”出来。大大提升完成一次测试的效率。
相比控制器级别的测试，整车级测试更关心体验下指标，比如接管率，系统稳定性，系统鲁棒性等指标。除了VIL和RIL之外，整车级别测试还有 LabCar 测试以及大规模实车测试（Field Operational Tests, FOT），这部分内容更多和传统整车其他传统测试流程一起进行。LABCAR测试也可以理解为几个控制器组成的硬件在环（HIL）测试。通过模拟外围传感器与执行器信息来检测整个电子电气系统是否工作正常，同时LABCAR还可以人为注入故障（短路，断路等）来检测非正常情况下反应是否符合预期。
FOT 一般做法就是真实路试。首先是汽车的六大基本性能，包括动力性、经济性、制动性、操稳性、通过性，都有标准客观试验做定量解析，平顺性可能涉及工程师校调，随风格会有些许差异。另外会在各种极端环境下做综合测试（高原，高寒，高温），常说的“冬天去黑河，夏天去海南”，就是这么来的。一般来说所有测试的试验条件会比正常用车条件苛刻的多，从而可以有效提升测试效率。当然还包括汽车NVH性能，耐久性能等只有在整车环境下才可以进行的测试。总的来说，整车测试的核心逻辑和零部件测试类似。由于测试需要配备牌照，保险，司机以及大量其他人力和保障资源，时间和经济成本都很高。因此整车测试往往较为精炼且被严格计划。实验工况数量和测试次数会被精密计算，一般根据理论外加经验估计得到。
FOT 的另一个目的就是获得政府认可公告。中国有针对乘用车的强制检验标准，大概40余项，对于可以在市场售卖的车辆而言，这些试验是必须通过的。随着智能驾驶技术的逐步落地，智能驾驶往往也会加入整车级测试科目当中。核心原因不同于传统路侧。由于真实交通中存在中千变万化的情况，而在驾驶模拟器或者受控场地测试中只能复现很小的一部分，因此评价的结果存在着与真实情况有偏差可能性。因此，需要采用 FOT 来对整个交通环境进行长期影响分析。
发表回复