基于快照信息判定车辆故障原因的设计

惠志洲

基于快照信息判定车辆故障原因的设计

惠志洲

（南京协和电子科技有限公司，江苏 南京 211100）

车辆行驶过程中发生故障时，会有很多的故障相关信息，为了将故障发生时的关键信息及时记录下来，用于后期问题分析与故障维修，文章设计了如下方案：当故障发生时，将故障发生的时间，故障发生时的行驶状态，行车速度，整车电压，整车行驶的总里程等信息全部存储在EEPROM中，这样，即使整车掉电，数据也不会丢失。这些关键数据为后期维修车辆时锁定车辆故障原因提供重要的原始数据，便于工程师分析车辆故障原因和维修车辆。该设计方案不仅适用于汽车仪表，对于整车上其它带存储功能的ECU也同样适用，对行业内其它ECU具有借鉴作用。

故障码；故障快照；非易失性存储器

前言

汽车仪表作为汽车上不可或缺的零部件，从传统时代的指针式机械仪表，到现代的全液晶数字仪表。经过了数代的发展，显示方式发生了巨大的变化，显示内容也由原来的仅显示转速表、车速表、燃油表、水温表、报警指示灯等内容扩展到能够显示文字报警信息、投射导航、收音机、歌词等。随着汽车往智能网联化方向发展，汽车上智能化的零部件越来越多，随着零部件数量的增加，随之而来的风险也越来越大。智能驾驶中的车辆失控，无法人工干预，某个ECU模块的异常死机等，都属于异常现象。这些异常现象轻则造成车辆无法启动，重则导致人员伤亡。而某些故障的发生可能是偶发性的，仅出现在一瞬间，过了这段时间后故障又消失了，这对于后期故障问题的排查也带来了一定的困难。如果在故障发生时，能够将车辆的关键行驶状态信息及时存储起来，那么即使后面故障自动恢复，也能够根据故障发生时的一些关键信息分析问题原因。基于此，在UDS诊断协议中定义了故障码快照这个诊断子功能，但对于快照信息中存储哪些内容，则没有具体明确[1]。

1 仪表功能设计

本文设计了一款汽车仪表，该仪表装配在某新能源汽车量产的车型上，仪表主芯片使用飞思卡尔公司的MC9S12G64芯片，该芯片内置EEPROM，空间为2 Kbyte。该仪表安装在整车上，通过CAN通信与其他ECU进行实时信息的交互，同时能够记录整车以及其他ECU的故障信息，比如整车电池电压异常，包括电压偏高或偏低；与其他ECU通信模块的通信丢失；接收到其他ECU发送的无效数据等一些故障信息，并能够记录故障发生时的车辆状态，包括故障发生时的整车电压、行驶总里程、故障时的点火状态、车速，以及故障发生的时间等。由于故障发生的次数可能不止一次，理论上每次发生故障时，都应该将故障数据记录下来，以供后期查找问题原因，但是由于芯片存储空间有限，所以软件设计时，将第一次发生故障时的数据和最近一次发生故障时的数据存储了下来，后面每次再发生故障时，则将故障发生时的数据覆盖最近一次的数据，以达到最新的故障总是会被记录的效果。该款仪表总共可以记录11个故障码，故障码格式定义依照ISO15765—6协议[2]。具体故障码列表如表1所示。每个故障码支持的故障快照信息如表2所示。

表1 故障码列表

序号故障码故障码名称 191 17 17电池电压过高 291 16 16电池电压过低 3C0 73 88BUSOFF故障 4C0 01 87与VCU丢失通信 5C0 02 87与TBOX丢失通信 6C0 03 87与BDCM丢失通信 7C0 04 87与IHU丢失通信 8C0 08 87与EPS丢失通信 9C0 09 87与ABS丢失通信 10C0 21 81接收到转速信号无效故障 11C0 29 81接收到车速信号无效故障

下面举例来说明，假设由于BDCM模块故障，导致不能正常发送BDCM的报文，那么当持续一段时间接收不到BDCM的报文，仪表就会记录与BDCM通信丢失的故障，在记录故障的同时，会将这个故障发生时的电压值、里程、车速、车辆启动状态，以及发生故障的时间等都记录下来，这些信息会被存储在仪表主芯片的EEPROM中，此后即使掉电，数据也不会丢失。

表2 故障码快照列表

编号数据标识符数据描述占用字节长度 101 12电池电压1 2E1 01行驶总里程3 3B1 00车速2 4D0 01启动状态1 5F0 02时间7

这些故障数据的读取通过UDS（Unified Diagnostic Services，统一诊断服务）协议来执行。在ISO14229标准中，规定读取故障码的服务是$19服务，而读取快照数据的子服务是04，对于子服务后面的内容，由各整车厂或零部件供应商自由定义。在本文设计的汽车仪表中，读取故障码快照信息的数据格式为19 04 XX XX XX AA，其中XX XX XX是表1中定义的故障码，而AA仅支持01，02和FF。其中01表示请求第一次故障发生时的快照数据，02表示请求最近一次故障发生时的快照数据，而FF表示请求所有的故障快照数据记录，包括第一次和最近一次。如果仅发生过一次故障，那么请求FF与请求01，回复的数据是相同的。

2 软件设计

表3 故障码发生条件确认表

序号故障码故障确认条件 191 17 17电压高于16.5 V，持续时间超过5 s 291 16 16电压低于8.5 V，持续时间超过5 s 3C0 73 88发生连续BUSOFF次数≥6次 4C0 01 87超过500 ms未接收到VCU报文 5C0 02 87超过500 ms未接收到TBOX报文 6C0 03 87超过500 ms未接收到BDCM报文 7C0 04 87超过1 000 ms未接收到IHU报文 8C0 08 87超过500 ms未接收到EPS报文 9C0 09 87超过500 ms未接收到ABS报文 10C0 21 81连续5次接收到无效的转速值 11C0 29 81连续5次接收到无效的车速值

汽车按下启动按钮或者旋转钥匙至ON挡时，理论上每个ECU的上电时间都是一致的，但是由于每个ECU使用的电源芯片以及电源的滤波电路不同，滤波时间不同，所以每个ECU判断上电至程序正常运行是有先后不同顺序的，假设ECU1上电判断的滤波时间比较长，而ECU2上电判断的滤波时间比较短，则ECU2程序会先运行，而ECU1程序会后运行。如果ECU2程序一上电运行就开始执行ECU1的故障码判断。此时ECU1还没有开始工作，当判断条件满足后，就会报ECU1的丢失故障，而实际上ECU1还没有正常启动。为了规避这种误报故障的行为，整车厂一般都会定义一个延时时间，在这个延时时间还未到时，是不做故障码判断的。本车型仪表设计的上电延时时间是1 s，仪表上电的滤波时间为60 ms。即上电后，仪表先持续判断60 ms的电源状态，如果持续为有效电压，则开始执行程序，1 s的计时器开始计时，当计时到1 s后打开故障码判断函数，开始判断故障码的相关条件。上述表1的11个故障码的确认条件如表3所示。

软件上电逻辑判断与正常工作时的故障判断逻辑框图如图1所示。仪表上电后，先持续判断一段时间，防止是由于干扰造成的误上电，待持续滤波判断60 ms后，确认无误，将上电状态置为1，接着开始执行应用程序，在应用程序中，判断故障的前提是必须为上电状态，待确认为上电状态后，开始1 s的计时，在这1 s内不做故障判断，当1 s计时时间到后，以10 ms为周期定时去查询各个故障发生的条件。以电压为例，假设某个时刻读取电压值时发现电压偏高，则本次将电压偏高发生的次数加1。下一个10 ms再次读取该电压值时仍发现该电压偏高，则再将电压偏高发生的次数加1。以此类推，如果中途某次读取电压值时发现电压恢复正常，则将电压偏高发生次数的计数器清零；如果一直偏高，则一直累加，当该计数器加到500后，即达到了5 s的时间要求，此时确认该故障，同时将该故障存储到内部EEPROM中[3]。

图1 软件设计框图

3 设计验证

软件设计完成后，为了验证软件设计的功能是否能够满足要求，需要进行相关的测试。测试工具软件使用德国Vector公司的CANoe，硬件为VN1640A，在电脑上安装好CANoe软件后，使用CANoe软件配置硬件的相关信息，然后进行CAN诊断报文的发送，仪表诊断请求报文ID为0x781，响应报文ID为0x791。给仪表供电，使之正常工作，使用CANoe工具给仪表发整车的相关报文，让仪表稳定工作几分钟，然后发送清除故障码指令，这一步非常重要，目的是测试结果的准确性。因为仪表上电工作后，如果CANoe没有及时发送其他ECU的相关报文，那么当超时后，仪表就会记录相应ECU的故障码，此时再发送那些报文，仪表存储的故障码还在，所以必须将之前存储的故障码清除，然后再制造相应的故障，看仪表能否正常记录[4]。以测试故障码C0 01 87为例，设置供电电压为13.5 V，仪表显示的总里程为0 km，启动状态设为04，通过CANoe给仪表发送固定车速60 km/h，时间从2020年8月15日8:00:00开始，当仪表正常工作2.2 min后，停止发送VCU报文1.02 s，然后再恢复正常发送，等待约5 s后，读取故障信息。测试时发送的全部报文数据如图2所示。

图2 通过CANoe发送与接收的所有报文

请求的诊断数据如图3所示。从图3可以看出，启动运行后，在时间为81.090 s时请求清除故障码指令04 14 FF FF FF，仪表在清除完故障码后会回复一个肯定响应01 54，为了确保故障码是真的被清除了，还需要读取故障码，看能否再读到故障码，请求03 19 02 FF读取具体的故障码，可以看到仪表回复的数据是03 59 02 09，即没有故障码。从图4中得知，VCU报文在132 s时停发了1 020 ms，之后恢复正常。在141.230 s时请求读取故障码03 19 02 FF，仪表回复的数据为07 59 02 09 C0 01 87 08，其中C0 01 87就是表1中与VCU丢失通信的DTC码，后面的08表示是历史故障，并且该故障已经被确认，即已经被储存。读第一次快照数据，请求与回复的数据内容如下：

请求1：06 19 04 C0 01 87 01 00

回复1：10 20 59 04 C0 01 87 08

请求2：30 00 14 00 00 00 00 00

回复2：21 01 05 01 12 87 E1 01

回复3：22 00 00 02 B1 00 17 70

回复4：23 D0 01 04 F0 20 14 14

回复5：24 08 0F 08 02 0C 00 00

其中C0 01 87后面的01表示第一次快照数据记录，回复1中的第一个字节“10”表示仪表需要往外发送的数据多于一帧数据，必须使用连续帧发送，“20”表示后面所有的有效数据的个数（注：CANoe中的所有数据都是以16进制显示，下同），59 04 C0 01 87为对19 04 C0 01 87的肯定应答响应，“08”表示故障码的状态，和通过19 02 FF读出来的故障状态是相同的。请求2中的“30”表示同意仪表接着发送连续帧，回复2、3、4、5中的第一个字节21、22、23、24表示连续帧的顺序号，不是有效数据。顺序号后面才是有效数据。21后面的“01”表示是请求第一次快照数据，“05”表示后面有5组数据标识符，“01 12”是电池电压数据标识符（参见表2），“87”表示故障发生时的电池电压，精度为0.1 V，转换为十进制后为13.5 V，与稳压电源调节的电压值一致；“E1 01”是总里程标识符，后面的3个字节数据“00 00 02”是故障发生时的总里程。由于仪表启动时，总里程为0，给固定车速60 km/h，在启动2.2 min时故障发生了1 s，所以故障发生时的总里程应该为2 km（总里程精度为1 km），理论计算值与仪表实际记录的数据相同；“B1 00”是车速标识符，后面的“17 70”是故障发生时的车速值，测试时给的是固定值60 km/h，“17 70”转换成车速即为60 km/h（精度0.01 km/h，16位长度），与实际给的数值相同。“D0 01”是电源状态，在之前设置启动状态为“04”，读出来的数据也是04，二者相同；“F0 20”为故障发生时的时间。初始时间为2020年8月15日8:00:00，过2.2 min发生故障，理论的故障时间是2020年8月15日8:02:12，仪表回复的数据为14 14 08 0F 08 02 0C，转换为具体的时间即为2020年8月15日08:02:12，与理论时间完全吻合。

图3 CANoe发送诊断请求与仪表回复的诊断报文

图4 VCU报文发送周期状态图

可以请求19 04 C0 01 87 FF读取所有的快照数据，由于C0 01 87故障仅发生了一次，所以请求读取首次故障与请求所有故障，回复的数据相同。图3中请求所有快照数据与请求首次快照数据一致。

VCU报文正常发送周期为20 ms，在测试开始2.2 min时停发1.02 s，然后继续恢复发送的状态如图4所示。从图4中可以看出，正常发送时，VCU报文每20 ms发送一帧，当测试时间到达132 s时，出现了一个尖峰，尖峰达到了1 020 ms，表示在这之间报文停发了1 020 ms，之后又迅速回到正常的20 ms。

4 结论

快照数据的存储对后期工程师分析车辆故障原因起到很大的作用，能够准确无误地记录故障发生时的关键数据是非常重要的。本文设计的汽车仪表能够实现预期的功能，达到了设计的要求。

[1] International Organization for Standardization.Road vehicles-Unified diagnostic services (UDS)-Part1:Specification and requirements: ISO14229—1:2013[S].Switzerland:ISO copyright office,2013.

[2] International Organization for Standardization.Road vehicles-Comm- unication between vehicle and external equipment for emissions- related diagnostics-part6:Diagnostic trouble code definitions:ISO 15031—6:2005[S].Switzerland:ISO copyright office,2005.

[3] 沈凯.基于UDS协议的纯电动汽车整车控制器故障诊断研究[D].武汉:湖北汽车工业学院,2017.

[4] 周红英,陶龙龙.基于ISO15765 CAN总线诊断测试方法研究[J].汽车实用技术,2016(10):140-142.

Design of Vehicle Fault Cause Determination Based on Fault Snapshot Information

HUI Zhizhou

（Nanjing Xiehe Electronic Technology Co., Ltd., Jiangsu Nanjing 211100）

When a vehicle fails during driving, there will be a lot of fault related information. In order to timely record the key information for later problem analysis and fault maintenance, the following scheme is designed in this paper: when the fault occurs, the information such as the time when the fault occurs, the driving state, the driving speed, the vehicle voltage, and the total mileage of the vehicle are stored in the EEPROM. In this way, even if the vehicle is powered off, the data will not be lost. These key data provide important original data for locking the cause of vehicle failure in the later maintenance of vehicles, which is convenient for engineers to analyze the cause of vehicle failure and repair vehicles. The design scheme is not only suitable for automobile instruments, but also for other ECUs with storage functions on the vehicle, which can be used as a reference for other ECUs in the automotive industry.

DTC; DTC snapshot; EEPROM

U463.67

B

1671-7988(2021)20-77-05

U463.67

B

1671-7988(2021)20-77-05

10.16638/j.cnki.1671-7988.2021.020.018

惠志洲，工学硕士、中级工程师，就职于南京协和电子科技有限公司，研究方向为CAN通讯、OSEK网络管理、AUTOSAR、UDS等。