自动驾驶中车载ECU开发测试的思考

随着项目进展，最近又开始承担一部分测试验证工作。看到我司的测试能力和流程，忍不住深深叹了口气。
0.前言
回想起上次写关于测试的内容，起因还是蔚来的两位工程师在工作中发生事故，为两位同事感到悲伤和惋惜而动笔。时间就像驾车时的后视镜，越走越远，但也时刻提醒我们前路的方向。自我进入汽车行业之日起，我的工作角色不断变化，从测试到系统再到架构，但总绕不开“测试”这两个字。
最近有感而发：系统工程师的归宿就是测试。这句话看似玩笑，却并不是空穴来风。纵观ASPICE开发流程，系统需求设计和系统测试是处在V模型的两端，分别处于ASPICE SYS.1和SYS.5的位置。从开发的角度来说，功能的需求提出者，一定需要对功能的表现去负责，因为只有提出者才能最清晰的知道期望的产品形态。所以每个系统工程师应该必备一身的测试技能。

图1 ASPICE Overview （来源于ASPICE）,1.测试闭环
是的，以上讨论的测试是基于ECU的系统测试。这个意义上的系统测试，一般是供应商的系统工程师在交付产品时进行的，ECU的软件以及硬件都已经成形，供应商在仿真环境或对手件在线的情况下完成的测试；或者主机厂的系统工程师在验收产品时，将零部件装车进行的系统级测试。在实际研发过程中，这种系统测试其实已经到了研发的结束阶段，多用来验证复杂工况下产品的性能。本人以前在主机厂做测试和系统时，主要就是负责这种系统测试。
那我们在车载ECU开发过程中，完整的测试闭环是怎么样的呢？,从软件出发，各模块的工程师应该对模块进行自测。比如感知、定位、规控等应用模块，以及中间件的更新，需要在提交前进行自测并提交报告。在模块自测通过后，软件部门leader有责任进行集成测试。完备的集成测试应该包括功能层面、性能层面、基础通讯、鲁棒性等，这部分可以通过流水线实现。每次软件释放后，需要注意生成的版本号，便于进行问题排查。
以上的测试都是跑在仿真环境中的，接下来将软件版本刷入经过DV/PV实验的ECU板子中，验证软件在硬件中的表现。这个环节普遍是问题最多的，而且不易定位是软件问题还是硬件问题，往往需要工程师的经验来分析解决。
当然，目前市面上有很多自动化测试设备能够帮助我们进行迭代测试，这类测试设备养活了一部分企业。国外的Vector是此中翘楚，近年来国内的昆易电子也发展的很不错。当年我第一个使用的HIL测试台架就是昆易的，说来有趣，本来是测试ECU，结果变成了“免费”帮供应商测试他们的台架.....嘿嘿，当然那已经是几年以前了，现在国产厂商发展的都十分不错。最近也接触了北汇的测试设备以及培训，他们在吉利系内部承接了很多项目。
到最后，就可以将ECU放入整车环境中进行测试了。这里的整车环境可以是通过多个对手件接入台架组成的仿真环境，也可以是实车环境。实车环境更为逼真，趋近于客户使用，但在车上毕竟测试环境较为恶劣，工作效率也比较低。一般是在量产关键节点多个ECU一起装车后，由主机厂专业测试工程师去进行路试，然后上报各ECU的问题，由不同责任人处理。

图2 V模型测试流程 （来源于北汇信息）,以上这一大段，其实就是描述的MIL-SIL-HIL-VIL的测试链路。在老东家负责系统的时候，当时还带了几个应届生做ADAS产品测试，曾经反复思考过，应该如何做测试，做哪些测试，我们需要哪些工具和环境，如何做到快速迭代验证。现在想来，还是要结合现状，每个公司的需求不同，拥有的资源不同，研发目标不同，能够提供的测试条件自然不同。
2.自动驾驶中的测试
在自动驾驶领域，测试更需要专业和细致，就像是进入了“硬核”模式。目前我司的一款在研高配车型，装配12*Camera，3*Lidar，5Radar，12Uss，1*高精度定位盒子，接入域控制器。考虑一下，我们这款车上有那么多的传感器，你能想象测试的复杂性吗？但这正是挑战的魅力所在，对不对？在如此复杂的网络拓扑的情况下，如何做到精确快速稳定全面的检出问题，定位问题，是需要持续思考的。

图3 智能汽车传感器 （来源于网络）,自动驾驶领域的测试与普通软硬件测试存在着显著的差异，这些差异主要源于自动驾驶系统的复杂性、多样性以及其对安全性的特殊需求。
3.思考
到了我司，重算法重开发，现阶段没有专业的测试团队，也没有完善的测试流程，测试问题的闭环链路有待完善。往往是算法工程师去车上简单验证后就可以合入主线，而他人提报的问题，仅在本地验证后就能够关闭，等等这些问题很容易在后续的开发中埋下伏笔。有时候，实车测试和仿真测试的结果是南辕北辙。
系统工程师是项目开发中的关键角色，他们不仅需要具备深厚的系统知识，对架构和设计有深入的了解，还需要具备一系列的测试能力来确保系统的质量和可靠性。作为系统工程师的我们，更应该保持冷静，记录、分析、跟踪问题。以下是从我司实际情况角度出发考虑的一些建议。
测试工具和自动化: 随着软硬件的复杂性增加，手动测试的效率和准确性都将受到挑战。因此，借助自动化测试工具，如Vector的CANoe、CANalyzer等工具，可以大大提高测试效率。此外，编写完善的自动化测试脚本和测试用例也是至关重要的。
持续集成和持续测试: 通过建立持续集成和持续测试（CI/CD）的环境，可以确保软件在每次更改后都能快速得到验证，从而尽早发现和修复问题。
故障注入和鲁棒性测试: 为了确保ECU在各种异常和故障情况下的稳定运行，可以进行故障注入测试，模拟各种可能的硬件故障、通讯中断等情况。
模拟环境与实际环境的差异: 在仿真环境中，测试的条件是可控的，而实车测试的条件则更加复杂多变。为了桥接这两者之间的差距，可以考虑使用更为逼真的仿真工具，如IPG CarMaker等。
文档和跟踪: 记录测试过程、测试结果和问题跟踪是至关重要的。可以考虑使用问题跟踪工具如JIRA，并且定义清楚问题关闭的条件和责任人，确保每个问题都被妥善处理。
团队培训和知识分享: 定期组织团队内部的技术分享和培训，可以确保团队成员对测试方法和工具的了解都保持在最新的状态。
安全和法规考虑: 随着全球汽车行业对功能安全和相关法规要求的越来越高，ISO 26262等标准对车载软件的测试提出了更为严格的要求。考虑这些因素，会使得测试更为严格，但也更具有挑战性。比如NOP功能需要考虑R79的法规要求，而ACC/LCC等功能很早之前已经有了完善的法规定义。
写到这里，其实是想说，我们在测试上还有很长的路要走。但也请记住，每一次的进步都是为了更好的未来。最后，预祝大家十一快乐，开车别忘了测...哦，是带上安全带！