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

从软件的角度谈谈特斯拉没有上榜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调用节拍到，此时