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

2023-09-25

随着项目进展,最近又开始承担一部分测试验证工作。看到我司的测试能力和流程,忍不住深深叹了口气。
0.前言
回想起上次写关于测试的内容,起因还是蔚来的两位工程师在工作中发生事故,为两位同事感到悲伤和惋惜而动笔。时间就像驾车时的后视镜,越走越远,但也时刻提醒我们前路的方向。自我进入汽车行业之日起,我的工作角色不断变化,从测试到系统再到架构,但总绕不开“测试”这两个字。
最近有感而发:系统工程师的归宿就是测试。这句话看似玩笑,却并不是空穴来风。纵观ASPICE开发流程,系统需求设计和系统测试是处在V模型的两端,分别处于ASPICE SYS.1和SYS.5的位置。从开发的角度来说,功能的需求提出者,一定需要对功能的表现去负责,因为只有提出者才能最清晰的知道期望的产品形态。所以每个系统工程师应该必备一身的测试技能。
自动驾驶中车载ECU开发测试的思考 (https://ic.work/) 传感器 第1张
图1 ASPICE Overview (来源于ASPICE),1.测试闭环
是的,以上讨论的测试是基于ECU的系统测试。这个意义上的系统测试,一般是供应商的系统工程师在交付产品时进行的,ECU的软件以及硬件都已经成形,供应商在仿真环境或对手件在线的情况下完成的测试;或者主机厂的系统工程师在验收产品时,将零部件装车进行的系统级测试。在实际研发过程中,这种系统测试其实已经到了研发的结束阶段,多用来验证复杂工况下产品的性能。本人以前在主机厂做测试和系统时,主要就是负责这种系统测试。
那我们在车载ECU开发过程中,完整的测试闭环是怎么样的呢?,从软件出发,各模块的工程师应该对模块进行自测。比如感知、定位、规控等应用模块,以及中间件的更新,需要在提交前进行自测并提交报告。在模块自测通过后,软件部门leader有责任进行集成测试。完备的集成测试应该包括功能层面、性能层面、基础通讯、鲁棒性等,这部分可以通过流水线实现。每次软件释放后,需要注意生成的版本号,便于进行问题排查。
以上的测试都是跑在仿真环境中的,接下来将软件版本刷入经过DV/PV实验的ECU板子中,验证软件在硬件中的表现。这个环节普遍是问题最多的,而且不易定位是软件问题还是硬件问题,往往需要工程师的经验来分析解决。
当然,目前市面上有很多自动化测试设备能够帮助我们进行迭代测试,这类测试设备养活了一部分企业。国外的Vector是此中翘楚,近年来国内的昆易电子也发展的很不错。当年我第一个使用的HIL测试台架就是昆易的,说来有趣,本来是测试ECU,结果变成了“免费”帮供应商测试他们的台架.....嘿嘿,当然那已经是几年以前了,现在国产厂商发展的都十分不错。最近也接触了北汇的测试设备以及培训,他们在吉利系内部承接了很多项目。
到最后,就可以将ECU放入整车环境中进行测试了。这里的整车环境可以是通过多个对手件接入台架组成的仿真环境,也可以是实车环境。实车环境更为逼真,趋近于客户使用,但在车上毕竟测试环境较为恶劣,工作效率也比较低。一般是在量产关键节点多个ECU一起装车后,由主机厂专业测试工程师去进行路试,然后上报各ECU的问题,由不同责任人处理。
自动驾驶中车载ECU开发测试的思考 (https://ic.work/) 传感器 第2张
图2 V模型测试流程 (来源于北汇信息),以上这一大段,其实就是描述的MIL-SIL-HIL-VIL的测试链路。在老东家负责系统的时候,当时还带了几个应届生做ADAS产品测试,曾经反复思考过,应该如何做测试,做哪些测试,我们需要哪些工具和环境,如何做到快速迭代验证。现在想来,还是要结合现状,每个公司的需求不同,拥有的资源不同,研发目标不同,能够提供的测试条件自然不同。
2.自动驾驶中的测试
在自动驾驶领域,测试更需要专业和细致,就像是进入了“硬核”模式。目前我司的一款在研高配车型,装配12*Camera,3*Lidar,5Radar,12Uss,1*高精度定位盒子,接入域控制器。考虑一下,我们这款车上有那么多的传感器,你能想象测试的复杂性吗?但这正是挑战的魅力所在,对不对?在如此复杂的网络拓扑的情况下,如何做到精确快速稳定全面的检出问题,定位问题,是需要持续思考的。
自动驾驶中车载ECU开发测试的思考 (https://ic.work/) 传感器 第3张
图3 智能汽车传感器 (来源于网络),自动驾驶领域的测试与普通软硬件测试存在着显著的差异,这些差异主要源于自动驾驶系统的复杂性、多样性以及其对安全性的特殊需求。
3.思考
到了我司,重算法重开发,现阶段没有专业的测试团队,也没有完善的测试流程,测试问题的闭环链路有待完善。往往是算法工程师去车上简单验证后就可以合入主线,而他人提报的问题,仅在本地验证后就能够关闭,等等这些问题很容易在后续的开发中埋下伏笔。有时候,实车测试和仿真测试的结果是南辕北辙。
系统工程师是项目开发中的关键角色,他们不仅需要具备深厚的系统知识,对架构和设计有深入的了解,还需要具备一系列的测试能力来确保系统的质量和可靠性。作为系统工程师的我们,更应该保持冷静,记录、分析、跟踪问题。以下是从我司实际情况角度出发考虑的一些建议。
测试工具和自动化: 随着软硬件的复杂性增加,手动测试的效率和准确性都将受到挑战。因此,借助自动化测试工具,如Vector的CANoe、CANalyzer等工具,可以大大提高测试效率。此外,编写完善的自动化测试脚本和测试用例也是至关重要的。
持续集成和持续测试: 通过建立持续集成和持续测试(CI/CD)的环境,可以确保软件在每次更改后都能快速得到验证,从而尽早发现和修复问题。
故障注入和鲁棒性测试: 为了确保ECU在各种异常和故障情况下的稳定运行,可以进行故障注入测试,模拟各种可能的硬件故障、通讯中断等情况。
模拟环境与实际环境的差异: 在仿真环境中,测试的条件是可控的,而实车测试的条件则更加复杂多变。为了桥接这两者之间的差距,可以考虑使用更为逼真的仿真工具,如IPG CarMaker等。
文档和跟踪: 记录测试过程、测试结果和问题跟踪是至关重要的。可以考虑使用问题跟踪工具如JIRA,并且定义清楚问题关闭的条件和责任人,确保每个问题都被妥善处理。
团队培训和知识分享: 定期组织团队内部的技术分享和培训,可以确保团队成员对测试方法和工具的了解都保持在最新的状态。
安全和法规考虑: 随着全球汽车行业对功能安全和相关法规要求的越来越高,ISO 26262等标准对车载软件的测试提出了更为严格的要求。考虑这些因素,会使得测试更为严格,但也更具有挑战性。比如NOP功能需要考虑R79的法规要求,而ACC/LCC等功能很早之前已经有了完善的法规定义。
写到这里,其实是想说,我们在测试上还有很长的路要走。但也请记住,每一次的进步都是为了更好的未来。最后,预祝大家十一快乐,开车别忘了测...哦,是带上安全带!

文章推荐

相关推荐