分享一个OTA升级失败的排查案例

前段时间遇到了一个OTA升级失败的问题，个人觉得问题类型与排查思路比较经典，在此分享给大家：

背景：某CANFD+以太网域控制器在量产车上OTA升级失败（通过CANFD进行OTA升级），失败概率100%，但相同状态的产品在试验车上OTA升级100%成功，故障不复现

排查过程：
1.因为相同状态的产品在不同的车上表现不同，重点考虑实车状态的影响。

2.相比台架进行的OTA升级测试，实车多了网关这一环节，因此先从网关着手进行分析：首先使用诊断设备通过OBD对产品进行升级，并比对诊断CAN和产品CAN两端的数据，发现数据未出错，且产品升级依旧失败，查看log可以知道是产品在升级过程中不响应36服务（第一个block），至此排除OTA流程的影响。

3.根据产品不响应36服务的现象（之前台架验证过出现此现象的工况），怀疑是在升级过程中产品受到了干扰，因此更改诊断设备升级速率，用较慢的速率升级产品，结果是产品可以响应36服务一段时间，大概几十个block，之后还会出现不响应36服务的现象，现象符合升级过程中受到干扰的表现，到这里可以基本把问题锁定在干扰上。

4.依次拔掉产品各个总线，并进行升级测试，发现当拔掉产品以太网时，产品可以升级成功，使用实车OTA进行升级，依旧可以升级成功，重新接上以太网，故障复现，问题锁定到以太网总线上之后，使用wireshark监控以太网报文，发现以太网上存在极高频率的无意义广播报文。对比可以OTA升级成功的试验车，并没有此现象，同时台架模拟实车以太网环境进行测试，成功复现故障，故障现象与实车一致。

5.后续追溯实车以太网报文来源，得知是其他控制器软件bug导致的，升级有问题的控制器后，再次对产品进行OTA升级测试，OTA升级成功。

结论：其他控制器干扰了产品的OTA升级流程。具体原因是产品在升级过程中依旧需要接收总线报文，并在中断里进行识别确认，当出现干扰时会导致中断异常，从而导致不响应诊断服务。

问题排查的启发：
1.没有对产品进行大量前期测试的话，难以识别故障现象对应的可能工况。
2.主机厂目前对以太网的认知较为欠缺，从需求定义，测试到问题排查没有较为明确目标。

思考：
能不能在产品信息安全上做措施避免这种问题？因为产品本身还是需要接收到报文才能判断是不是需要的报文，因此接收干扰报文本身这一流程就已经导致了干扰的结果，有没有什么办法可以规避？