陈江波， 涂将辉， 夏永强， 赵能卿， 李 娟， 贾和平

（江铃汽车股份有限公司， 江西 南昌 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的硬件复位，并在整个下线流程结束后进行整车所有模块硬件复位，彻底解决了这类问题。