ADAS融合认知算法测试杂记

---

前言

总结下所负责过一段时间的融合认识算法测试。满打满算参与了不到一年，在此期间，从测试端，算法端，需求端，项目端，质量端都看到了一些新的东西，但所有交付物都在老东家的电脑里，只能通过记忆去梳理下。

---

一、融合认知算法的地位

笔者从事的是较为传统的1R1V融合方案的算法测试，Radar和Camera都是老东家自研的，Camera对标ME的EyQ4, Radar对标Bosch MRR5和Conti ARS510, 融合算法部署在Camera板子里。通过此1R1V的软硬件全栈自研，来建立从传感器硬件，基础软件，算法，测试及工具链等的一系列能力。
在笔者看来，融合认知算法是向上承接各传感器感知输入，向下面对规划控制的中间核心环节，融合认知算法的质量既取决于上游传感器感知输入的质量，还跟自身的融合算法策略，认知预测策略等有莫大的关系，也是融合认识算法的核心，绝不能出现融合后的效果弱于融合前单个传感器的整体效果。当然这里说的是后融合。

二、融合测试团队的主要职责

测试计划和测试用例

首先肯定需要基于项目计划制定测试计划，比如当前负责的是首款平台化的RC融合解决方案，基于PDT开发流程，制定适配于开发交付的测试计划，每个节点需要提供一份完整的测试报告来总结当前整个节点的测试活动以及测试结论。

此外，需要基于解决方案的SE需求来拆解对应的测试用例需求，并在系统上把测试用例和需求用例进行适配，确保后续测试用例的结论能够映射到需求用例，形成统计的KPI来看开发质量的达成情况，也就是内部所谓的“点灯”活动。

整个需求的层级基本就是IR（原始需求）到FuR（功能需求）到SAR（系统需求），测试用例会匹配上SAR层级的需求，然后做好一一映射和匹配。

团队的主要测试活动包括回灌，场地和公共道路，由于是测融合算法而非规控算法，因此对于功能本身的性能不会直接关注，但可以通过带规控版本软件的一些误触发等功能表现来发现感知或者融合乃至认知的问题。

回灌测试

回灌能够跑起来的前提有两个：

一个是路采回来足够数量和场景丰富度的原始数据，这些数据必须携带雷达的RIF数据和Camera的视频数据，此外还需要激光等作为真值的数据，当时团队还增加了对标的EyQ4和ARS510的感知数据。

第二个是需要搭建起回灌环境，这就涉及到回灌方案的设计，包括数采方案比如RC等的时间戳要在采数时做好记录以便回灌时对齐；融合回灌是使用软回灌还是硬回灌还是软硬回灌各占一部分；此外还有数据中心的建设，包括对路采回来数据的存储和自动化调用；比如后面我们设计的自动回灌，是指能够通过远层启动板子，对数据中心的数据能够按照日期进行自动跑通，后面自动化生成KPI的报告。

当然，自动生成KPI的报告涉及到对KPI判据的设计，比如采数时采集到AEB Flag位，可以在自动化回灌时，通过AEB Flag位统计出AEB触发的次数和时间，然后通过人工分析有限的AEB Flag场景是误触发还是自动触发，当然也可以通过和采数车上竞品的AEB Flag（如有）进行自动比对，不过竞品的AEB本身也有误触发率，并不能由此直接得出本车的触发就是误触发；除此之外，对于感知的KPI，就要依赖于采数过程中对于真值设备的使用，来比对自研感知融合认知的精度和真值精度的比对，目标分类准确度的比对，CIPV识别准确率的比对等等。回灌无论是长里程采数的几十万公里目标，还是数据中心巨大的存储要求，还是回灌工具的效率，稳定性和自动化报告工具链的可靠性，都是一项巨大的工程，需要硬件，算法，工具链，测试等团队密切配合，一切解决遇到的问题。

场地测试

场地测试根据测试用例进行就可以，跟功能场地测试（比如NCAP）不同的主要在于测试用例，此外就是必须要带GPRO等真值设备。场地测试需要采集到目标车功能，目标车性能，车道线功能，车道线性能，目标人功能，目标人性能，目标车两轮车功能，目标两轮车性能等一系列测试用例下的数据，目的就是能够通过场地的规范化测试用例和测试目标物，对感知融合认知算法的目标物识别及时性，准确性，目标物相对位置，相对速度，相对加速度等精度能够统计出，并服务于算法的质量迭代。

实际道路测试

实际道路测试分两大块，其中一块长里程，就是刚才所说要服务于回灌的。长里程需要投入巨大的人力物力和财力，雷达和摄像头首发平台业界主流Tire1比如大陆基本都是在百万量级，当然大陆首发平台会联合VW和丰田等OEM共同实现，所以整体实现难度有限。但国内纯自研公司如果在供货前能够达到一个性能基线，往往需要自己投入资源去跑这个长里程，每辆车的改装和硬件费用基本在一两百万，比如速腾的整套真值，EyQ4的竞品采数设备，整车5R1V的Vector原始采数设备，还有改装费等；为了短期内尽快采集到相当数量的数据，一般需要同时改装5辆以上的车子。路线基本就是国内典型城市，高速，城际，城市，基本4:3:3，每家不尽相同，但基本就是这个比例范围。此外还需要设计合理的路线来连接这些城市，以便达到上述不同路段的里程比例。除了里程之外，还需要设计好兴趣点，在采数过程中进行打点操作，兴趣点一般还涵盖天气，交通参与者，基础设施，特殊事件等维度。比如天气可以记录雨雪大雾沙尘等特殊路段，交通参与者可以是异型车，近距离交互的VRU，紧急切入的前车等，基础设施可以是一些特殊的桥梁，隧道，路沿，凸起的井盖等，特殊事件可以是车辆误制动等操作。打点回来的数据还可以做场景切片，方便算法有针对性的回灌验证。另一块实际道路主要服务于算法的快速迭代验证。自研算法迭代往往很快，每周两个版本很正常，这时候通过快速去周边典型道路进行采数（3-4小时左右的数据），回来后进行数据分析，可以快速发现主要的问题和阻塞点。

提问题单&回归测试

提问题单是测试团队非常重要的工作和工作输出成果，涉及到跟算法团队的正式问题交互反馈。

说到这儿，想到了我们融合算法测试团队的有趣事儿，我们的问题单可能是单R引起的，可能是单C引起的，可能是RC融合算法引起的，也可能是认知算法引起，还有可能是规控引起的，还有的是基础软件引起的，上面所说的分别对应不同的开发团队，也就是6个团队，所以我们每次分析问题的时候需要先看下这些问题可能是哪个团队引起的，然后这个这个团队的开发对问题，确定问题可能原因归属以及严重度等，然后愉快的提单。

测试发现问题提单看起来很爽，但实则不然。提单一时爽，回归要骂娘。测试提的问题单，提示单及以上的算法过点前原则上都要解决，不解决的通过SE这种会来评审可以留在下个节点解决。那算法通过新版本解决了的问题，测试都是要回归验证的。回归验证分为回灌回归验证和实车回归验证，回归问题时哪些问题可以回灌，哪些问题必须重新采数，要看当时问题的性质和版本。有些老版本采数提的问题单的数据已经无法适应新的回灌环境，只能重新找相似场景采数来回归验证；有些规控的问题可能也无法进行回灌只能实车重新采数验证。

测试报告

测试经理非常重要的一项工作就是写测试报告。测试报告要包含这个开发节点所有的测试活动总结，包括前面提到的回灌，场地和实车，各种统计率的体现，比如CIPV某某工况下的统计率，各场景测距测速等精度的统计，以及AEB等误触发率的统计，还有就是重点问题单的展示以及解决情况，未解决的问题测试角度是否可以接受遗留在下个节点。基于上述测试总结，最终给出测试是否同意过点的结论。
过点评审时，测试报告是非常重要的评审依据，测试报告的结论也是非常重要的过点依据，由此可以看出测试团队的话语权。
除此之外，过点前还有一些活动，质量会有对过点的要求，比如前面提到的灭灯，那么每个灯会有分值，致命问题单的灯分数最高，其次是严重问题单，还有一般问题单乃至提示问题单。过点前，项目经理会拉上质量督促算法，SE，测试一起解决相关的问题单，算法要尽快通过迭代解决问题单上的问题，测试要尽快回归问题。但上面这些点灯灭灯行动，本质上还是测试发现问题的解决。当然也有开发本身质量的解决，比如SE需求过点前依然没有承接，SE需求设计不合理等。

---

总结

第一次在CSDN上写Blog，献给了那段难忘的奋斗岁月，每天晚上九点开会对问题，经常十二点多以后下班，周六也要上班，自己后面带着融合算法测试这个小团队，也做出来了一些小成绩，获得了组织的认可，最后还是因为外面的机会和逃离测试的想法离开了。