某车型组合仪表总里程跳变问题快速排查及设计改进

潘钢 魏鹿义 李天辉 蓝凯 甘成

关键词：组合仪表；总计里程；鱼骨图；故障排查

0 引言

乘用车在上市之前的设计研发阶段，需根据各零部件开发周期的不同，进行多轮次及多种类的道路测试，以测试验证整车各个部件的结构、性能和耐久等是否满足整车要求。但各零部件尤其是各电子电器功能件，在路试车辆中均处于研发阶段，其功能均未达到认可状态，很有可能在路试过程中出现故障问题，直接影响到路试的进度。因此在整车项目的开发中，掌握快速解决故障问题的方法十分必要。

某车型在进行实车道路耐久测试工况时，发现组合仪表在总计里程达到7 648 km 时，直接跳变至7 596 km。测试员停车后将车辆下电，闭锁等待车辆休眠后再重新解锁唤醒，以及采取重新断接蓄电池负极操作，组合仪表总计里程表都没有恢复至原先的数值。由于以上原因，上述现象判定为故障。车辆暂停测试，需要工程师快速排查故障。

1 故障分析

1.1 总计里程信号流向

组合仪表总计里程显示异常，首先需要弄清楚计算总计里程的所需信息来源于哪个传感器，相关信号在整车上如何传递，组合仪表采集到信号后是如何处理显示的。该故障车型组合仪表总计里程的显示，是通过采集车速信号进行里程累计积分计算。行车过程中车速信号流向如下：防抱死制动系统（ABS）控制单元采集轮速传感器的频率信号，经过换算后得出车速信号，再通过CAN 总线传输至组合仪表（图1）。

在完成信息流分析后，工程师梳理组合仪表系统内部的工作原理。汽车组合仪表系统一般由PCB 电路板、电源模块、MCU芯片、CAN 收发器、蜂鸣器和LED 显示屏等组成。其中电源模块把主接插件输入的12 V 蓄电池电压降到5 V，再将5 V 电源提供给CAN 收发器、MCU 芯片、LCD 显示屏、蜂鸣器和LED 指示灯或指示灯等模块。车速CAN 信号由接插件的CAN_H 和CAN_L 端子输入，CAN 收发器将接收到的信号通过CAN 收发器的协议层进行帧识别、响应等，然后将得到的CAN 帧放入消息缓存。系统软件读取CAN 消息，按照矩阵的定义识别消息中的信息量，然后通过识别的实际车速对时间进行积分运算[1]，最终得出总计里程（图2）。

1.2 总计里程储存备份原理

组合仪表中储存总计里程数的存储器一般为随机存储器（RAM），备份里程数的存储器一般为带电可擦可编程只读存储器（EEPROM）。RAM 集成在MCU 里面；EEPROM 有外置的，也有集成在MCU 里面的。

组合仪表上电后，立即从EEPROM 中读取前次里程数，并显示在组合仪表上。在组合仪表上电超过3 s 且组合仪表显示里程数有效（车速信号有效且CAN 信号正常）时，将每100 ms 进行一次累加计算，总计里程ODO 每次增加0.1 km，并显示在组合仪表上。与此同时，将最后一次有效报文指示的总计里程表值更新到组合仪表中的RAM 和EEPROM 中。

组合仪表下电后，且组合仪表正常（即里程信息错误状态位置0）的条件下，停止计算总计里程ODO，并将组合仪表的总计里程数值更新到EEPROM 中[2]。汽车组合仪表总计里程储存备份流程如图3 所示.

1.3 EEPROM 芯片存储结构及储存策略

EEPROM 芯片中使用240 Bytes 大小的空间来储存里程数据（图4），储存里程数据需要用到8 Bytes。其中，总计里程ODO使用4 Bytes，小计里程Trip 使用2 Bytes，标识用于识别当前存储位置内的ODO 和Trip 数据是否有效使用2 Bytes（图5）。其总计里程ODO、小计里程Trip 以及标识数据结构如图5 所示，故240 Bytes 存储单元内可以储存30 组里程数据。

根据EEPROM 芯片的规格书，其擦除/ 写入次数是有限的（100 万次）。为了在有效的寿命周期内最大限度地保证数据的有效性，总里程数据在EEPROM 内部是顺序循环储存的，即从第1组存储单元顺序存放数据，储存完最后1 组单元（第30 组）后再循环到第1 组存储单元存放数据。

车辆在行驶过程中每1 km 保存一次里程数据到EEPROM 中，为了保证有效数据的唯一性，在确认储存完新的里程数据后，必须把前一次储存的数据擦除掉。例如当前存储位置是第3 组，确认新的数据储存完成后，必须把前一组存储单元（第2 组）内的数据擦除掉。当存储单元使用到第30 组时，下一次储存的数据要存放到第1 组的位置，确认完数据储存完成后，需要把第30组的数据（前一组里程数据）和标识都擦除掉。

2 故障排查

为了快速解决故障问题，工程师借用鱼骨图工具，将引起问题的各类因素，根据总计里程信号流向、系统原理，储存备份原理及储存策略，按照相互关联性整理而成，搭建起层次分明、条例清晰的图形[3]。在问题分析基本结构搭建起来后，通过5W1H 的方法，在每个层级下继续讨论找出所有可能的原因与因素。

应用鱼骨图进行原因分析，将所有可能导致组合仪表总计里程跳变的故障原因分析罗列（图6）。最终结合当前车型开发状态，确定重点因素为组合仪表软件这个层别，故障分析排查如下。

（1）确认ABS、组合仪表系统线束原理是否正确，检查线束样件与图纸的一致性。使用万用表对该系统每个回路的导通进行测试，排查是否存在断路、对搭铁短路以及接触不良等导致的仪表接电异常；排查该系统每个插接器是否存在损坏、异物进入、形变和装配不到位等情况；排查该系统每个端子是否存在腐蚀、退出、损坏、母端扩孔和公端弯折等情况[4]。综上检查，未发现线束连接异常。

（2）排查ABS 控制单元故障，这个可以通过诊断设备读取CAN 报文、诊断故障码来判断[5]。实车未读取到ABS 与组合仪表总成当前与车速信号相关的故障码记录。对故障车进行实車动态测试，记录总线报文，ABS 外发的车速信号可以正常发送，且表显的车速与总线车速符合计算公式，可知ABS 的车速信号以及组合仪表的车速接收与显示策略正常。

（3）手动发送清除仪表不相关的故障码指令，再开始实车行车，发现组合仪表里程显示恢复正常。由此可知与车速信号不相关故障码的储存，也会影响到该组合仪表里程的写入。

通过排查分析组合仪表总成的软件发现，本次故障就发生在故障码的存储位置。原因可以定位到仪表在软件编写时，需要同时储存里程和储存故障码时存在逻辑问题，导致里程数据没能正常储存。

3 故障原因分析

检查软件的故障码与总计里程的储存逻辑。如图7 所示，在储存总计里程信息前，需要保证无新的故障码储存需求后，才开始执行储存总计里程信息。而实车清除故障码后，总计里程还可以继续储存，证明问题发生原因为一直有故障码需要储存的动作，且动作一直在进行且无法结束。当程序出现异常，在执行判断“是否需要储存故障码”时，一直为“是”，程序无法进入总计里程储存条件判断。

使用存储空间前，如需要擦除时，则必须先进行擦除。查找软件履历，软件代码编写的储存故障码逻辑为：在存储位置上设置一个标志位。如不需要擦除或者已擦除完成，则将标志位置为0。如未擦除，则标志位为1，在整车上出现故障码储存到EEPROM 时，需先对存储位进行擦除或者判断后进行擦除工作。此时需要判断标志位状态，当擦除完成后才能进行储存。

由此可知，故障车可能一直无法储存故障码，导致程序一直在“储存失败”与执行“错误处理程序”的循环内。排查故障码的储存代码，发现判断擦除状态标志位逻辑错误。正确逻辑应为“检测到标志位为0，则执行储存”，实际软件为“检测到标志位为1，则执行储存”。而此时由于擦除后，标志位已经为0，但需要储存故障码，所以不满足储存条件，导致故障码无法储存，进而执行错误处理程序，陷入错误循环。儲存程序一直被故障码占用，导致程序不能进入保存里程的状态。

4 改进方案与结果

分析出原因后，工程师将判断的值由1（需要擦除或擦除未完成）改为0（不需要擦除或擦除已完成）。至此，逻辑的执行链路打通，即储存故障码时，检测到已经擦除，则执行储存。故障码储存成功后，程序执行“是否需要储存总计里程”条件判断，判断完成后，总计里程成功储存。至此，总计里程被更新到EEPROM 存储空间内。

软件更改后，实车测试并进行休眠唤醒与蓄电池断接动作，总计里程和故障码信息可正常储存。组合仪表总计里程跳变问题得以解决。

5 结束语

本文研究的组合仪表总计里程跳变问题为组合仪表软件设计不足导致。本研究通过鱼骨图工具，将其应用于实际故障分析。该方法有效、高效，从问题现象出发，快速缩小问题排查范围的同时，完善检查了组合仪表软件总计里程储存策略，消除组合仪表总计里程跳变问题，保证了路试的正常进行。通过研究，还能积累一些解决组合仪表总计里程跳变问题在软件层面上的解决思路和软件设计改进方案。