点评一下，恒润的OTA自动化测试方案，顺便建个群
文摘
汽车
2024-03-24 20:54
上海
恒润近期介绍了他们的OTA测试方案，我们一起围观一下恒润润是一家现象级企业，作为中国汽车电子产业的先驱和先行者，它值得友商们好好研究学习，也值得广大同行认真借鉴。恒润作为中国最早的汽车电子研发企业，是dSPACE、Vector等一众世界一流公司的刚进入中国时的首选合作伙伴，其在国内的江湖地位，在全世界的影响力，可见一斑。
虽然他们后来都闹掰了，但是这思考不妨碍他们曾经腻歪过。
而且，恒润现在在军工、量产业务、港口无人驾驶开发等领域，也都搞得风生水起，现金流充沛得很，也基本上不太可能会倒闭了。如果文章已失效，请后台联系车辆技术，我把原文发给您。不过这不重要，因为我们接下来将用全文对恒润的这篇介绍进行说文解字。这段是恒润做的OTA的典型架构图，基本上也没啥问题。但是师子一号觉得，如果它的OTA主控是IVI的话，那么它图中的TBOX和IVI之间可能少了一根直接连线，通常为USB线，因为IVI需要通过TBOX下载软件包，存到IVI里面。这段话也属于常规用语，但是其重点在最后这句“ECU诊断应答模拟”，信息量非常大。这说明恒润的测试方案中，测试对象是“OTA云端+TBOX+IVI+GW”，不包含被刷写ECU，被刷写ECU是虚拟的，通过软件来模拟的。说实话，这里面的工作量还是相当大的，需要做若干虚拟ECU。而且，这样测完了之后，并不能保证实车就ok，因为我们不能默认实车ECU的行为特征和它“应答模拟”的ECU完全一样。这个差距，需要一个环节来弥补，那就是ECU本地刷写测试，包含LIN刷写、CAN刷写、CANFD刷写、DOIP刷写等等，我们要模拟出多种复杂工况，验证它刷写的可靠性，永远不成砖。
到这里，读者可能有疑问了，直接用真实的ECU不好嘛？非也非也，这样做是有意义的，打个比方就是，某个CAN信号的定义是结果信号的发送方和接收方都做错了，到了整车上面，功能反而正确。但是，其巨大的风险就在于，其他接收ECU可能不知道这个情况，到时候可能会闯祸。所以说，切分成2个环节做OTA测试，它不仅保证了结果的正确性，还保证了过程的正确性，避免“负负得正”、“将错就错”等各种奇葩现象的出现，是为长远可靠性做打算。这个图，说实话，远程预约自动化，师子一号没太明白啥意思，可能是让工程师在房间A里面，远程操作房间B里面的TAE软件吧，TAE软件扮演了个网站服务器的角色。接下来“云端任务配置及下发自动化”，指的是TAE向OTA服务器发请求，实现OTA任务自动下发。但是说实话，其实我们可以直接在房间A里面干这个事情的。直接在房间A里，通过本地软件对OTA服务器发请求。之所以搞了个TAE服务器绕一下，估计还是想建自己的标准，推广自己的玩法，出售自己的产品。TAE是通过什么方式调用的OTA服务器呢？这个问题的答案，恒润的这篇文章里有伏笔的，我们继续往下看。HMI自动控制及验证，指的就是通过ADB自动操作IVI，模拟人的点击、滑动等动作，并判断画面的值。诊断响应仿真，指的就是上面所说的“ECU诊断应答模拟”，用于替换掉真实的ECU。自动化上下电，师子一号理解为KL15信号，或者启动按钮的按键动作，这个用继电器就能实现了。恒润在这里放了一个程控电源，说实话有点费解，可能是断电重启吧。但是，这种测试中，总电源一定不要动不动就切断，这会掩盖很多问题的，因为实车上的IVI、TBOX、GW等件，它都是接常电的，运行时间久了，可能会激活碎片bug，你断电重启，它就清空了，测试演示虽然好看了，但是问题也可能被掩盖了。通常大家戏谑所说的“重启大法好”，就是这个意思，但是实车上这就相当于拔掉蓄电池，要求客户通过插拔蓄电池来消除车辆故障，是个挺过分的事情
所以，千万不要用程控电源控制总电源切断，只用来模拟电源电压就好了。总线环境模拟自动控制，指的是发车速、门状态、档位状态等信号，这些信号可能是OTA活动发起的前提。这段话，中规中矩，但是其中的ODX/PDX有点过分了。因为刷写流程在各个企业基本上都是有规范的，固定的，你没有必要去跟客户要ODX文件或者诊断规范，这属于吃空饷。恒润和Vector的友谊小船不是早就翻了吗？而且恒润的方案图里用的是自己家的硬件VCI呀。该不会是仅仅用来做报文回放的吧？那你可得选好版本咯，不能超过CANoe10.看来，强大如恒润，还是需要把Vector的图片放进去的，提升一下方案档次。ADB就是安卓的东西，只能用于安卓系统的车机，苹果CarPlay不行，unix的也不行。师子一号建议，不要在ABD上浪费太多时间，我们可以对OTA测试系统进行解耦，把预约和云端车端自动化解耦开，解耦之后，直接跳过ADB，自动化程度大大提升，并且更快更简洁。车机操作属于人机交互测试，不是逻辑测试，最好还是用人工进行测试评价，测试质量更好。关于“什么是解耦”，这可能是测试方法论上的一个创新，有兴趣的朋友们可以后台交流一下，车辆技术在这方面有十分成功的经验，效果好得不要不要的。摊牌了啊，交代实底了啊，诊断仿真是通过DST实现的（多卖点DST）但是，你都仿真了，重点应该放在逆向测试、异常工况仿真啊。重点在于模拟各种异常，而不是把正向测试拿出来说，如果真把重点放在正向测试，那我直接用真实ECU，岂不是更方便更省事？当然，我们还是要看看恒润所说的“必要的逆向测试”指的是什么，再进一步评论下结论，不能因为“虚拟ECU做正向测试”，就断定它的方案差劲TAE是通过什么方式调用的OTA服务器呢？这个问题的答案，恒润的这篇文章里有伏笔的，我们继续往下看。
此处，我们已经看到真相了，那就是：类似于按键精灵那样，模拟人对浏览器的操作。证据就是这个叫“Selenium”的库，它就是用于操纵浏览器的。Selenium库可以通过id、name等方式，查找页面元素，然后模拟点击、填入、选择文件等操作。
如果id、name不好用，Selenium还有个xpath的方法，来识别网页元素，这个应该算是终极大招了。
优点，简单，省事儿，出货快。显而易见嘛，你能用人工操作出来的结果，它也可以做。首先，速度慢，不是一般的慢，而是非常慢，人工操作需要1分钟的话，它也快不了多少。
其次，页面元素属于浏览器前端，前段的更新、美化、页面重构，是再普遍不过的事情了，这极其容易导致页面元素的id、name、xpath等特征符发生变化，导致编好的自动化程序无法使用了。说人话就是，“客户原因导致新增工作量啦，修改升级啦，得加钱”
浏览器操作，类似于HIL中的开环动作，它方便模拟人的操作，但是不容易模拟人的肉眼观察。这就导致它动态性极差，无脑往前冲的感觉，浏览器崩溃了或者页面瘫痪了也不知道，测试系统运行起来比较脆弱，健壮性不够。答案当然是有的，那就是用python、C#、LabVIEW等软件，模拟http请求，直接向服务器后端发指令，做数据层面的交互。当你打开OTA网站的时候，你的所有的动作，都对应一个或者多个api函数，这些函数名及函数体，会在浏览器的开发者模式下有清晰明确的显示罗列。把这些函数连同它的执行参数一起复制下来，生成python代码，就可以愉快地通过代码直接调用后台啦。它几乎完美克服了浏览器模拟的所有缺点，速度快、可靠性高、可闭环，稳定性高（网站后端的稳定性要比前端高太多了）jenkins是互联网技术在汽车软件行业的应用拓展，它就是帮助大家在办公室a1\a2\a3\a4\etc里面，对实验室b1\b2\b3\b4\etc的设备进行远程调用，远程执行，远程出结果。但是汽车行业毕竟不同于互联网行业，互联网行业使用它，那是因为互联网行业的大多数产品都是虚的，都是软件或者代码，测试对象基本上都是云、服务器代码等等，天然适合这种集中管理的远程调用。
而汽车行业和互联网行业的最大区别就是，汽车行业有实体产品，比如各种控制器等等，而且汽车行业控制器对实时性可靠性要求很高，网页崩了可以刷新，服务器崩了可以重启，但是汽车ECU趴窝了，可能就出大事了。所以，结论是，车载ECU的测试，还是非常需要工程师在旁边关注着的，如果jenlins接口这块砍掉，总价可以便宜点，那就果断砍掉。“更多功能”章节，应该不是恒润重点宣传的亮点，而是部分客户提供的冷门需求，不怎么典型，复购率很低，所以就放在最后了。恒润的项目经验还是不容置疑的，师子一号也曾经和恒润在OTA领域的资深工程师有过会议交流，对方思路很清晰，也很灵活，几乎没有从他脸上看到任何为难的表情。当你指出他们推销的方案的某些猫腻之处时，他们也不慌张、不激动，立刻提供性价比更高的方案，给人一种“我啥都会”的感觉！无论任何类型的测试方案，它永远逃脱不出车辆技术对测试工作“虚实结合”的表述：寻找恰当的虚部和实部，找好切割线，探索高性价比、高价值的测试方法，是我们不懈追求的目标。
针对OTA，“整体合格”绝不是我们的目标，我们不仅需要结果正确，还需要各个环节正确。
OTA功能模块，车机人机界面的流畅度、合理性。这部分不是重点，说实话也不咋重要，车机外包测试的小伙伴顺手就测了。
最后补一点，一定要做自动化测试，做大量大量的重复测试，做各种复杂工况的可靠性测试。欢迎朋友们后台沟通，我们一起交流OTA开发和测试的各种奇闻轶事，大家一起晒坑、闭坑……最后，我们一起建个群，专门讲OTA开发和测试技术，欢迎有需要的朋友们加入哈。
