从软件的角度谈谈特斯拉没有上榜315

导语：

网络上有关国内特斯拉“突然加速”或“刹车失灵”的报道已经有十多起。尤其是前几天河南女车主手持喇叭坐在特斯拉Model 3车顶上大喊维权的事件还上了热搜，引起热议。

但目前特斯拉与维权车主多为各执一词，社会舆论几乎都是偏向消费者，认为特斯拉“甩锅”成性，不负责任。而今年的315晚会上特斯拉却始终没有“亮相”，让人“大失所望”，这件事你怎么看？

先借用知乎作者@何先生的观点：

特斯拉的问题不在做工差，不在续航缩水，不在态度差，而在于“突然加速”。

这是一个不常见，概率低，难复现，没有办法取证，甚至连特斯拉方面想解决这个问题，都不知道从何下手的问题。

我相信特斯拉也想解决这个bug，毕竟只需要OTA就行，但是一直没有进展，因为工作量太大，且问题很难复现，做工程的知道，一个无法复现的问题，是很难解决的。

突然加速，基本上就是软件问题，需要像当年美国人调查丰田“刹车门”事件一样，让NHTSA牵头，外加NASA专家，以及一大批嵌入式软件团队对源代码进行分析，一行行测试，验证，找到可能失效的原因，当年丰田事件对源代码进行检查用了八个月。

因此我觉得最可能的原因是：特斯拉的这个问题太难取证了。

非常赞同 @何先生的观点，不同于机械故障的稳定性，许多控制器的偶发故障，想解决起来确实很难，因为难就难在......故障无法复现！

对于这种偶发故障，工程师们要么需要从海量的记录数据里面一条条翻看，找寻蛛丝马迹，要么需要投入极大的精力，不断重复模拟故障发生环境，直到故障复现，抓取故障发生时的通讯信号。

下面cao sir就用一起小例子来说明：

某一天，工厂反馈产线报出现一辆SOP车测试完后静置10min左右后车辆无法启动，车身控制器（BCM）在PT-CAN上无报文，断电后功能恢复正常的故障。

很显然车辆无法启动是车身控制模块（BCM）功能失效，那么又是什么导致了失效的发生呢？

为了找出根本原因，工程师先列了一个鱼骨图，将所有可能导致BCM失效的原因都列了出来，然后再一一去排除。



首先排除了现场工艺的原因，因为车辆刚下线时功能正常，且重新上电后恢复通讯功能，说明整车线束上PCAN到BCM的连接没有问题。

物料状态：将故障的车身控制器（BCM）返回工厂分析，硬件测试焊点连接正常，无虚焊漏焊现象，硬件上的SBC芯片，CAN收发器正常，工厂EOL分析正常。



下面重点分析故障发生时的信号表现：

故障发生时，读其他节点故障码，报出BCM节点丢失DTC；断电后读BCM故障码，有PT-CAN其他节点丢失历史DTC，无PT-CAN BUS-Off的DTC。排除BCM系统检测到总线异常，主动关闭总线通讯的可能。



继续查看总线报文，故障发生时，整车网络上，PT-CAN上无BCM任何报文，BD-CAN有BCM应用报文，排除BCM的MCU和SBC芯片无法唤醒工作的软件控制错误；



断电后读BCM故障码，无高低压DTC，排除软件控制FlexCAN进入低功耗，不能退出的软件控制错误；BCM报出与PCAN其他节点丢失通讯历史DTC，说明BCM PCAN无法收发报文。



根据以上分析，初步怀疑是BCM PT-CAN网络从休眠到唤醒时，FlexCAN连接没有正常初始化，造成无法收发报文。

为了验证这个怀疑的真实性，下面就进行故障模拟：

通过CAN工具Tellus编写测试脚本，在BCM网络休眠的最后1.48s-1.53s区间内通过NM报文反复循环尝试唤醒BCM，步进为5ms。长时间压力测试BCM网络管理NetWork Normal Mode到BusSleep状态切换，多轮测试后复现故障现象；实车用相同方法测试问题软件经过1个循环测试即可复现故障。



根据故障复现方法结合代码分析，发现问题出在网络管理Prepare Bus Sleep到Bus Sleep模式切换的1.5s超时时间的最后5ms时间窗口中，此时有网络唤醒请求，但是由于调用时序问题错误，导致网络休眠标志被清除，无法进行FlexCAN的初始化和连接，造成CAN网络无法通讯的问题。




1.在网络由PreBusSleep到BusSleep的最后10ms窗口内，由于任务B周期5ms，会比任务A多调用一次，若此时任务B检测到唤醒源，会 将g_PCANnetHandleEnable置位，并调用CanNm_NetworkRequest (V_PCAN)请求网络到Normal状态；

2.接着任务A调用节拍到，由于代码顺序执行，会先将网络状态切换到BusSleep，调用v_ctl_discon (V_PCAN)断开FlexCAN连接，并置位g_bPCANSleepFlag标志。紧接着由于上一次任务B调用时请求网络到Normal状态，又会清除g_bPCANSleepFlag标志。

3.再接着任务B调用节拍到，此时g_bPCANSleepFlag==FALSE，无法重新调用v_ctl_init(V_PCAN)连接网络，造成CAN网络无法收发报文。


故障的时序图

找到根本原因之后，解决措施就是修改网络管理休眠唤醒时序问题：

网络休眠后，删除远程唤醒请求和本地唤醒请求共用一个标志的问题，本地唤醒请求造成的com的初始化和连接改到CanNm模块中处理，在CanNm中增加网络唤醒请求状态切换到Network Mode时，如果当前网络处于休眠状态，则调用FlexCAN的初始化和连接。


修复后的时序图

修改好代码后，用复现故障的方法验证新版软件测试7301次，故障不再复现，然后再将修改后的软件在实车上验证，测试了581次，故障不再复现，从而证明了解决方法的有效性。



你看，就是当初写代码时大意地将本地唤醒和远程唤醒共用一个标志位，导致了偶发故障的发生。事后排查起来，却是千辛万苦.....

据统计，在系统测试阶段找出并修正错误，要比开发者自己完成这一工作多付出2倍的努力。而当系统已经交付使用之后找出并修正错误，要比系统测试阶段多付出9倍的努力。
所以才有那句名言：

如果我们没能力修好它，我们就会告诉你它根本没坏。—— Walt Weir