整车下线EPS 刷写偶发性失败问题分析与方案优选
2020-11-27陈江波涂将辉夏永强赵能卿贾和平
陈江波, 涂将辉, 夏永强, 赵能卿, 李 娟, 贾和平
(江铃汽车股份有限公司, 江西 南昌 330001)
下线EOL诊断仪是汽车主机厂生产下线时的重要生产工具[1],整车项目开发后期需要进行EOL设备进行联调以满足生产的需求[2]。EOL设备一般具有读取模块软件故障码、清除模块软件故障码、模块软件功能自动识别配置、特殊功能学习、模块软件刷写更新等功能[3]。EOL功能指令的发送时序与时间参数的设置是根据产线工序、软件特殊需求、下线流程来定义[4]。ECU Bootloader刷写是根据UDS协议开发定义[5]。
1 软件刷写电气原理
图1为EPS模块(电动助力转向) 诊断通信的路径,刷写指令由EOL设备发送,经网关从动力CAN路由转发至EPS所在总线上,EOL发送指令,各模块根据诊断通信规范做出正响应或否定响应 (设定条件不符时),EOL根据得到的响应进行下一步的指令发送。
图1 EPS模块诊断通信的路径
图2 EPS模块刷写流程
图2 为EPS软件刷写流程,EPS进入刷写之前需要对诊断模式切换,需要从默认会话模式(正常工作状态) 进入拓展会话模式(响应拓展模式下的指令),再进入编程模式 (响应编程模式下的编程指令可以对EPS进行刷写操作)。通过图2步骤实现整车软件刷写过程,这些流程按照顺序执行,任何步骤出现问题,如出现负响应,EPS的刷写过程都会被中断导致刷写失败。
2 故障现象
项目投产阶段总装工厂反馈有部分下线车辆配置线上出现EPS刷写一次测试不通过情况,经过录制数据跟踪问题主要是以下两种失败情况:①10台左右车失败的原因为31 01 FF 02回复了7F 31 7F。②EPS模块未有任何响应(含7DF指令和721),功能寻址10 83/85 82发出EPS并没有正响应。针对以上两种刷写失败情况,得到问题出现的3种可能原因。
1) 反馈负响应的模块有SWM (组合开关)、EPS (电动助力转向)、SRS (安全气囊),3个模块均对28指令反馈7F,这3个模块在CCAN上,而EOL设备发送指令是在PCAN上,说明很大概率是网关丢帧导致包括10 83指令在内的很多指令未成功转发至模块终端,指令缺失导致不符合EPS刷写流程,EPS对后面转发过来的指令给出7F反馈,不执行后续的刷写命令。
2) EPS软件问题,软件未按照流程开发,导致出现报错情况。
3) 转向盘异动导致失败,可能会影响刷写模块出现负响应。
3 问题分析
3.1 情况1问题分析
针对以上两个刷写失败的情况,经过确认情况①EOL设备31 01 FF 02回复7F 31 22,下线在对EPS进行刷写时,方向盘被有意触动后,电动助力转向系统转向机扭矩会出现波动,容易产生EPS刷写失败;EPS刷写时需要监控的因素主要有方向盘扭矩处、车速、发动机状态、供电电压,其中任何一个条件不满足都无法完成刷写流程。EPS在进入编程模式时触碰方向盘导致EPS内部的扭矩传感器波动,出于整车安全考虑,EPS软件刷写编程是不允许出现扭矩波动情况(上限值2.5Nm),出于安全考虑的原因是确保在无驾驶员操作车辆,即EPS处于非工作状态,EPS软件才能进入再编程模式。
3.2 情况2问题分析
根据图3所示问题数据1分析,在T=150.434542和T=150.693814两个时间点,PCAN上有诊断报文7DF,但网关未将其转发至CCAN。直到T=150.953830时,PCAN上出现第3帧诊断报文时,网关GW才开始将诊断报文路由到CCAN。之后各模块反馈否定响应码7F导致刷写失败。根据数据分析刷写失败原因初步定位为网关未转发诊断报文导致 (CAN1:PCAN,CAN6:CCAN,CAN8:BCAN)。
网关未转发诊断报文是否正常需要继续分析,从图3中T=144.311722可知BCAN上下线测试设备在BCAN上发送0x763 TBOX诊断请求及诊断响应,当前诊断优先级为BCAN;之后0x763报文停发,BCAN上做其他模块 (0x732/0x7E0) 本地诊断,当前诊断不需要网关处理,网关会从最后一帧0x763开始5s诊断报文超时计时;而在T=150.434542时,发送第1帧0x7DF时,此时网关会认为BCAN/PCAN诊断报文已超时,如果超时后TCAN上有诊断报文,则会将诊断优先级切换至TCAN;此时再请求0x7DF会涉及一次诊断优先级从TCAN->PCAN的过程,而这一过程中,TCAN诊断报文未超时,此时会有500ms延时处理PCAN诊断请求的计时器,这也就是前面0x7DF报文网关未处理,而在T=150.953830时,0x7DF开始从PCAN正常路由至CCAN。因此,根据进一步分析,网关漏转报文是因为TBOX有诊断请求导致。
图3 问题数据1
根据深入分析发现:按照下线匹配流程,在问题数据2(图4) 中T=85s,下线设备对TBOX进行了一次硬件复位;按照TBOX和网关握手认证策略,此时TBOX需要发起握手认证流程,如未握手认证成功,TBOX会一直发0x760尝试和网关进行握手认证;又由于网关未经过重启,不满足网关握手的条件,未进入等待握手流程状态。
图4 问题数据2
综上所述,从流程上梳理问题根本原因如下所述。
1) 根据EOL下线流程,需要先完成TBOX模块与PEPS模块之间的匹配认证(TBOX学习完成SC码),然后会执行硬件复位,复位后就开始和网关进行认证 (TBOX会发出网关诊断0x760报文)。
2) 按照TBOX与网关握手认证策略,GW网关未执行上下电操作,网关不会对该握手认证指令进行响应。导致TBOX握手失败情况,总线上会一直发送网关诊断0x760报文。
3) 在完成TBOX和PEPS匹配认证后,EOL流程会等待6s后才开始执行EPS模块刷写操作,此时TBOX还在发送网关诊断0x760报文。
4) 按照网关诊断策略,Tester/EOL设备的诊断优先级高于T-Box模块自身的诊断优先级,如果BCAN、PCAN上5s未收到任何诊断指令时,此时如TCAN上出现诊断报文,网关会将本地诊断模式切换为远程模式。车子下线时,出现TBOX握手报文,正好处于5~6s的时间段内,网关将会把诊断路由模式切换为远程模式。
5) 当网关在PCAN收到EPS刷写的第1条报文时,此时依据本地诊断优先级高于远程诊断策略原则,会将诊断路由模式切换为本地诊断模式,但考虑远程诊断还在进行,预留了一个500ms的切换时间。该段时间内的本地诊断报文不会路由,从而导致EPS刷写失败。
4 整改方案优选
按照刷写失败原因分析,有以下3个方案去解决该问题。
1) 网关修改软件,将网关的等待握手流程开始的条件修改为任意时刻。当前只有上电或者唤醒时,网关会响应进行握手协议。把网关的等待握手流程修改为任意时刻,只要TBOX发送握手协议指令,网关响应后停止发送指令,就可以完全避免出现EPS刷写时从诊断报文不会路由的情况。考虑到更改GW软件时间周期较长,且涉及开发费用,因此建议不采用。
2) TBOX修改软件,TBOX按照其他项目,在下线的前20min内不进行诊断。此次刷写失败的原因主要是因为TBOX需要进行诊断,进行诊断之前需要通过握手实现诊断通信,前20min不进行握手通信,就可以完全避免出现EPS刷写时出现漏转发诊断信号的情况。但是由于修改TBOX软件时间周期长,同时还需要进行联调测试,因此建议不采用。
3) 修改EOL流程,调整硬件复位时间,由于EOL在整个流程结束会进行一次7DF的硬件复位,将TBOX学习完SC码后的硬件复位取消。在EPS刷写过程中不会出现握手指令,使得GW始终处于本地诊断模式,GW进行正确的报文转发,不会出现停止发送报文的情况。且该方案不涉及开发费用,经评估方案可行,同时经过联调测试,该方法测试验证通过,未对其他下线流程产生影响。综上所述,此方案为最优方案。
5 结论
针对下线EOL设备对EPS模块进行Bootloader刷写时出现偶发性失败情况,对问题进行跟踪并录制CAN总线数据进行分析,结合下线流程详细分析了出现问题的根本原因,同时提出3种修改策略。对3种修改策略分别分析方案的可行性,分析结果表明:通过调整下线流程取消TBOX的硬件复位,并在整个下线流程结束后进行整车所有模块硬件复位,彻底解决了这类问题。