一文清楚自动驾驶测试体系
发布时间：2021-11-07 13:50:25 所属栏目：动态 来源：互联网
导读：自动驾驶的测试是一个非常复杂的系统，我们用一篇文章，由小到大的逐个展开来和大家一起梳理下。 在梳理之前我们先抛出一个问题：自动驾驶的测试需要达到什么量级？ 根据国际一般标准统计，人类司机驾驶一小时的死亡概率约为1/10^6，全世界每年因道路交通事故
|
自动驾驶的测试是一个非常复杂的系统，我们用一篇文章，由小到大的逐个展开来和大家一起梳理下。 在梳理之前我们先抛出一个问题：自动驾驶的测试需要达到什么量级？ 根据国际一般标准统计，人类司机驾驶一小时的死亡概率约为1/10^6，全世界每年因道路交通事故死亡人数约有125万。自动驾驶汽车如果要发展，其死亡概率必然要远低于这个标准。根据调查，目前社会可以接受的自动驾驶一小时的死亡率须不高于1/10^9。因此，如果要将死亡率降到1/10^9，每更新一次软件，司机必须驾驶10^9小时，才能保证功能的可靠性。显然，这种实车测试的方法并不可取。 真实的测试体系往往利用了分层思想，结合多种不同成本和覆盖角度的测试手段，让我们可以用可控的时间和成本，近似达成类似实车测试的效果。不同测试方法的成本是不同的，合理迭代次数也是有区别的。一个拥有合理测试体系的项目，模块逻辑测试必须规避60%以上的潜在问题，仿真功能性能测试则要解决30%的剩余潜在问题，而留给实车鲁棒性测试最多10%。在各自手段内尽可能的发现潜在问题，控制后道测试手段的问题量，如果搭配合理，则在保证极高覆盖度的同时，成本也会进入可控范围。比如如果仿真测试体系完备，则规划开发几乎无须上车验证，就可以减少大量的外围支持资源。 不同测试方法的对比 多层次的测试手段搭配也并非没有代价，构建一个专项测试系统往往存在搭建周期长，初期成本高的问题。无论是零部件测试中的CAE,DV,PV测试，还是软件里的静态，集成，仿真测试，常有为了追赶进度而绕过一些测试工序的情况发生。 其实这是一笔经济账，当我们省略了某一前道测试工序时，如果后道高成本的测试工序解决前道工序遗留问题时所耗费的资源，要高于设立前道流程的花费，整个测试体系就会变得得不偿失，反之亦然。 合理的测试层次也是一个平衡过程。 但一般而言，在一个延续性和成熟度较强的研发体系内，更多梯次且相互正交的测试体系配合高效的流转往往会达成更高的效率。 真正有效的测试，往往是使用特定的测试工具和特定的测试用例，审核被测对象特定维度的问题。任何一种测试系统，只要其针对某一类潜在问题，成本低于其他手段，覆盖问题范围又高于其他手段，则就是一个好的测试系统，并无所谓其属于哪种类型的测试系统，那都是后期被人为强行划分出来的概念。在测试的设计中，务实非常重要。 工程实践过程中的测试过程 另外，测试Pipeline往往也是训练Pipeline的一部分。过去测试体系的工作主要是杜绝+由于人的失误所导致的潜在产品隐患。 最为我们所熟知的就是测试驱动开发（Test-DrivenDevelopment，TDD），其要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动开发进行。 而现在自动驾驶正在走向自监督过程，我们看到更多机器与机器之间的互动。其中也包括机器与机器之间的测试反馈和开发调整，也就是我们非常熟悉的深度学习。对人而言，测试是为了保证产品和目标一致。对机器而言，训练也是为了达成类似的目的。 自动驾驶的常用测试手段 从不同合作模式来看，可以分为黑盒、白盒以及灰盒测试。 白盒测试会检查内部结构每一条通路是否按照设计正常工作，一般用于产品提供方内部的管理；黑盒测试一般不考虑内部结构，仅检查产品功能是否按照合同提出的技术要求实现了，一般用于被提供方的内部管理；灰盒测试介于上述两种测试程度之间，在测试外部功能的基础上，会对关键链路进行确认，一般用于提供方的发布测试或者被提供方的验收测试，具体程度视具体合作而定。 从不同领域专项来看，不同的领域有各自特有的问题及其对应的测试维度。 从软件代码出发会有静态测试、动态测试等：静态测试会分析程序的语句结构、编程规范等是否有错误和不妥,常用工具包括QAC/Converity等，占整个测试体系的比重较小，一般是软件测试的第一道，与之类似的是codereview其会组织相关专家对代码的静态设计做出评估；而动态测试则会比对运行程序后的结果与预期，分析运行效率和健壮性，目前自动驾驶绝大部分软件测试科目都属于动态测试范畴，比如性能测试及各类在环测试。 从不同技术断面出发，是所有划分模式中最复杂也是最重要的。 首先解释下设置断面的意义。当我们面临一个复杂多因素混合作用的系统问题时，通过设置断面，可以隔离影响变量，将复杂性简化到一个可被测试的程度，同时可以将原本串行的问题排查任务转化成并行任务，缩短项目进度。 如下图所示，最底层的是单元测试、模块测试和模块集成测试。在研发平台上（X86），将软件函数、单个或多个模块的输入输出作为断面，核心在于验证代码逻辑的正确性。通过VectorCast、GTest等工具将大量的错误输入和少量的正确输入注入被测对象，确认反馈符合预期，这个过程一般是开环的。 模块级别的测试一般也被称为模型在环测试Model-in-the-Loop(MIL) 除了考虑部分正确性外，还会有一些模型性能指标比如感知模块的识别精度等。 软件逻辑层面的测试方法 一个在X86上稳定运行的软件，在嵌入式环境下可能出现堆栈溢出，调度混乱，时间戳不稳定，系统调用支持不到位，内存读取异常，运行阻塞等一系列问题。为了排查这种差异。如下图所示，在软件逻辑层面之上可以继续引入目标硬件这个维度，也就是处理器在环测试Processor-in-the-Loop(PIL)，其是将部分代码放置于目标处理器上，验证代码功能正确性的同时，确认其性能是否达到要求。比如，软件最长耗时，系统调用可靠性等。软件在环测试一般评估正确性，而硬件在环测试一般评估稳定性。 PIL测试方法 如下图所示，以上所有的测试一般都是开环的，并不会验证与环境的交互。当我们在软硬件的维度上增加和虚拟或者现实环境的交互，就产生了软件在环测试SIL(Software-in-the-Loop)和硬件在环测试HIL(Hardware-in-the-Loop)的概念。 引入环境要素后，还会同时引入场景库作为测试用例。测试过程除了验证基本逻辑外，还会评估一部分智能驾驶的运行服务指标。 SIL测试不考虑目标硬件，可以在服务器上大量部署，成本较低，核心用于验证智驾功能的闭环运行正确性。可以划分为使用语义级仿真系统进行的局部闭环测试，以及使用环境渲染级别仿真系统进行的软件全功能闭环测试。 SIL是目前最有潜力的测试手段之一，因此我们做一个简单展开。单元测试、模块测试等方法虽然自动化率高，但不能直接发现智驾系统的功能性问题。而硬件在环测试、实车测试等虽然问题发现更为直观，但成本较高。而SIL在这些方法之间取得了不错的平衡，是一种性价比很高的手段。SIL系统从内部看核心要确保可重复性。如果测试无法复现其过去的实验结果，对后续评估会构成很大影响。如果由于多线程等原因确实无法完全保持可重复性，也需要多次实验后确认其方差与稳定性。从整个测试体系看，越靠近内部（比如单元测试），则越容易控制可重复性，而越靠近外部（比如实车测试），就越难控制。从SIL系统的外部看核心是自动化率和大规模并行部署的能力，作为整个测试体系当中综合分析来说规模最大的测试手段。减少人工和提高并发部署能力可以有效降低测试成本，并提高测试效率。SIL系统在智能驾驶的闭环体系下，除了测试，也开始为规划的迭代训练服务。我们在仿真测试中进行的安全评估、功能评估、法规要求评估、舒适性评估等所使用的指标和用例，其实也都是规控训练过程中的一种“损失函数”。 HIL测试区别于SIL需要考虑目标硬件，一般不会大量部署，因为成本较高，其结果相比SIL更接近真实状态，可以额外评估软件在目标硬件上的整体性能（运行调度，内存调用，算力调用）是否符合预期。HIL测试通常将一个被测控制器和一系列模拟设备做硬线（PWM、UART、CAN、GPIO等）连接，将记录或模拟的原始数据反向构建成真实信号输入，来完成对目标硬件的测试工作。在实践过程中，个人认为，切勿执着于全功能长周期工作的HIL台架，20台轻量级HIL台架（PIL台架）的价格可能还不及1台全功能HIL台架。效果上两者对比差距却并不大。一部分物理IO，一部分功能模拟往往更为科学，HIL台架一般仅用于短周期的闭环测试，长周期测试往往会有较大误差。 SIL和HIL测试方法 完成了单控制器的测试后，智能驾驶测试会继续进入整车级别，如下图所示，首先我们要介绍的是车辆在环测试VIL（Vehicle-in-Loop）或者说实车虚拟注入测试，即通过在软件内部配置断面测试接口，在封闭测试场内的实车测试环境下，屏蔽部分真实感知输入，从而在测试场内的空旷区域模拟任何形式的道路环境。比如在路上添加并不存在的车辆，或是模拟一个交叉口的信号灯切换。由于其他测试要素均为真实内容，因此测试可信度高，且可以充分利用封闭测试场的环境资源。 VIL测试方法 另一种VIL的全新形态是实车交通环境在环测试（VTEHIL），在室内场地构建模拟的周边环境变化以及车辆移动，来进行智能驾驶车的测试。由于环境完全受控，不受到气候变化影响，可实现24小时连续测试，并且可以高效且完整模拟极端工况。 VTEHIL测试方法 进一步往下，是道路在环测试RIL（Road-in-Loop）或者说封闭场地测试。除了环境参与者和司机之外，其他全部都是真实要素。 在常规汽车测试体系中，此种测试手段也是常规操作，但不同于过去人工遥控和摆放的实施手段，目前已经出现了自动化测试方案，由于最新的假人假车装备同样配置了必要的传感器，执行器与通信设备，可以接入云端集中指挥调度。因此云端的测试用例可以同步到封闭测试场内被智能假人和假车“表演”出来。大大提升完成一次测试的效率。 （编辑：衡阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
