车辆电控模块通信类故障快速诊断方法研究

2020-06-02杨洪福吴君张斌

汽车零部件 2020年5期

杨洪福,吴君,张斌

(泛亚汽车技术中心有限公司，上海 201201)

0 引言

伴随着车辆电气化、数字化及智能化[1]程度的提高，车辆模块间的交互需求越来越强烈，车辆的电控模块间的通信消息的数量越来越多。伴随着通信数量的增加，模块间通信类故障发生的概率也会增大。针对模块间通信类故障的具体原因调查，需由专业人员或者受过培训的人员进行手动数据分析，进而确定哪条信号引起了该故障。人工分析总线故障排查效率较低，且有一定的门槛，受人员技术水平的限制。

实际造车过程中，为不影响正常造车节拍，针对造车中出现的问题，需要快速定位问题原因。传统的人工分析方式效率较低，为了减小对造车节拍的影响，对提高总线故障分析效率、简化总线故障分析过程以及降低总线故障分析门槛提出了迫切需求。

本文作者主要针对车辆电控模块通信类问题的快速分析理论及实际应用，利用该理论开发相应分析软件，用于代替人工；通过自动化分析，快速锁定通信类问题的根本原因，并生成问题分析报告，极大提高分析效率，实现原因排查操作简单化，入手容易，且可大范围推广。

1 通信类问题基本类型

模块间的通信消息一般包含以下基本内容：信号值，信号有效性，rolling count(滚动计数)value和protect(checksum)value。若车辆实施了网络安全[3]，可能还会包含MAC(Message Authentication Codes)。图1给出了一些实例。

图1 通信消息内容举例

通信类故障一般包含两部分：信号未接收到(timeout)，接受到的信号异常[2]。针对信号异常故障，依据消息中包含的信号内容，主要包含以下几类故障：

(1)Invalid

信号有效性故障。理论上，当信号无效时，发送方会将validity置为invalid。接收方检测到validity的状态为invalid时，当满足报码条件时，触发故障码。

(2)DLC(Data length code)error

信号的长度不正确。当信号实际发送的数据长度和定义的数据长度不一致，当满足报码条件时，触发故障。

(3)Value error

信号发送的值不正确。发送方发送的信号值若不是规定的数值，或者接收方核对值不正确，当满足报码条件时，触发故障。

(4)Rolling count error

Rolling count主要目的是为了保证信号的连续性，防止信号中断的产生。理论上rolling count变化规律为：0，1，2，3，0，1，2，3……，当rolling count的变化未按照规律进行时，表明存在信号丢失，当在规定的时间内满足一定的故障次数、满足报码条件时，触发故障。

(5)Protect value error

Protect value主要是为了保证此信号的正确性。Protect value是此信号中内容经过一定的算法获得的结果值，并存储在protect value中，连同该消息一同发出，若接受方依据相同的算法得到的数值与发送方发送的protect value值不一致，当满足报码条件后，触发故障。

(6)MAC(Message Authentication Codes)error

MAC是车辆增加网络安全后新增的一个通信内容。MAC主要通过密钥将信号加密，接收方成功解密后，信号才可用。当接收方依据算法无法解析MAC时，一定程度上说明发送方发送的MAC存在错误，当满足报码条件后，触发故障。

2 故障快速诊断介绍

基于故障自诊断原理[4]，车辆模块针对接受到的信号都有一套自身的诊断规范(Diagnostic Specification)，依据诊断规范，对信号进行判断，若信号异常，达到报码条件，则触发相应故障码。

利用诊断规范，结合整车数据库(Database)和故障数据，理论上可自动对故障数据进行分析，找出故障码信息及导致该故障具体原因：

利用数据库解析故障数据，读取故障数据中记录的故障码信息；调用诊断规范，确认引发故障码的可能原因；依据可能原因，检查故障数据，锁定引发故障的真实原因；最终将分析结果以图标的形式进行展现。具体流程可参考图2。

图2 通信故障诊断流程

2.1 故障快速诊断基本框架介绍

快速诊断系统基本框架主要由以下几部分组成：

(1)整车数据库(Database)。整车数据库是车辆通信数据解析的集合。它记录了通信消息的发送方，接收方，CAN ID，发送频率，消息名称，消息中包含的信号名称、位数、信号默认值等信息(内容举例见图3)，利用数据库可进行整车总线数据的解析。

图3 数据库内容举例

(2)故障诊断规范又叫故障字典，该字典中记录了针对故障的具体解析，包含故障码信息、引发故障的原因描述等(具体示例见图4)，依据该字典可以查到何种信号导致该故障。

车辆模块间的通信类故障码多以U开头，故障码包含两部分：主码和子码。综合考虑存储量和故障原因的数量，同一故障码下面可能存在多个原因，需要依次检查相关的信号是否存在异常。若人为依次检查每个信号的话，操作偏向机械化，时间长、效率低。

(3)故障数据记录了问题发生时刻的总线数据，包含了故障码由无到有的过程。利用录取的故障数据，依据快速诊断原理，确认引发故障的根本原因。整个分析过程可通过上位机软件自动完成。

(4)分析结论。分析结论中包含了故障码信息、报码时间、引发该故障码的信号状态，信号异常的时间。分析结论需要体现并证明，故障码由于某信号异常导致。分析结论由上位机分析软件自动生成。

图4 诊断规范内容举例

2.2 快速诊断方法具体软件实现

依据基础逻辑框架，搭建快速诊断软件，具体操作及界面如图5所示。

图5 快速诊断软件界面

针对整车具有多个模块的特点，软件包含了众多车辆模块，例如EPS、ECM、TCM、EBCM等。依据需求选择对应的模块，然后导入或选择对应的故障字典(诊断规范)和数据库。数据库和故障字典第一次导入之后，后续可直接使用，无需再次导入。针对故障数据，通过读取故障数据中的故障码信息获取需要分析的故障码，依据故障字典查找故障数据中对应的信号在故障发生时刻是否异常，当检查到信号异常与报码时刻一致，自动生成数据分析报告。