摘要：阐述一种诊断控制单元之间通信丢失故障的机制，通过基于UDS的诊断协议进行原理分析，并制定一种有效的诊断处理策略。

    汽车故障诊断是利用ECU监测控制系统各组成部分的工作情况，发现故障后自动启动故障记录和处理逻辑。汽车故障诊断模块不仅能够存储记忆汽车故障，还能够实时提供汽车各种运行参数川。外部诊断设备通过一定的诊断通信规则与ECU建立诊断通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。故障诊断记录处理，并将这些处理的信息通过诊断通信传输给外部诊断设备，这一系列处理机制构成了汽车立体化的诊断系统，如图1所示。

    统一诊断服务UDS (Unified diagnostic services)是基于OSI (Open Systems Interconnection）参考模型设计的，是当前汽车领域广泛使用的一种车载诊断协议标准。当前车载网络快速发展，网络总线也不断变化更新，由初始的低速LIN总线，到低速容错CAN总线、高速CAN总线，再到F1exRay和Most总线等等，越来越多的网络总线和电子控制单元的出现迫切需要统一车载诊断协议。ISO 14229基于UDS诊断规范，可应用于多种数据链路网络，是一种可广泛应用的满足诊断需求的协议标准，如图2所示。

    CAN网络是一种非破坏性仲裁的通信网络它因具有较高的通信速率（最高可达1 Mb/s）和灵活可靠的通信方式，在车载网络领域广受青睐。控制系统之间的信息交互即可通过CAN网络通信的方式进行。但如其他系统一样，通信实体之间也需要进行通信故障的诊断，例如诊断通信异常、通信丢失等故障。CAN网络通信不仅实现了车载电子单元之间的通信，同时也为在线诊断提供了网络载体。CAN总线电控单元及诊断接人端分布见图3。

    本文基于ISO 14229协议，以CAN总线为通信介质，对车载控制单元之间记录通信丢失故障原理及诊断仪如何读取故障信息数据原理进行了分析，并根据协议规范制定了一种通信丢失处理策略。

1网络通信丢失的故障诊断机制
    变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元，这2个ECU要通过CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因，2个控制单元之间可能会出现通信丢失的现象。

    控制系统需要将故障信息（例如通信丢失故障信息）诊断出来，以处理通信被破坏时出现丢失帧的故障现象，并记录为 DTC ( diagnostic troublecode)。一旦某一控制系统，如TCU监测到一段规定的时间内并没有接收到ABS发来的通信数据，便将此DTC记录下来。外部诊断设备通过规则的诊断通信与控制系统建立诊断通信连接，并选择相应的诊断方式，例如：读取故障信息服务时，就会将此故障信息读出，并在诊断仪中显示出来。TCU记录网络通信丢失流程如图4所示。

 

 

2基于UDS的诊断原理分析
    根据UDS的诊断协议，汽车上的控制系统需要根据规则化的诊断协议进行故障记录和处理，最终体现为诊断故障编码DTC的方式。

 

    根据ISO 14229协议规定，每个DTC均由DTC内容和DTC状态表示。DTC内容代表了该故障的具体故障方式、故障标志等信息，例如车身系统中ABS传感器故障。DTC状态则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的故障状态信息，详细意义如表1所示。

    根据ISO 14229诊断协议，DTC的记录原理和状态信息控制如图5所示。控制系统以一定的时间周期（如50 ms）进行一次相应的故障监测，检测是否出现了故障。图5中，椭圆框中竖线部分表示检测到了故障。每一个控制单元中都会设定一个错误监测计数器，如黑色框中图形显示，计数器有计数上、下限，例如错误计数上限为127，下限为-128。一个驾驶循环开始的时候，错误检测计数从0开始，监测信号没有错误，则计数器减1，若一直累计到下限-128，则不再递减。而一旦监测到一个错误信号，计数器将归零或置于零上，若之后有连续的错误帧，则计数器持续累加，直到上限127,此时第一位（Bit 0 Test Failed）将置1。在一个驾驶循环内，如果某一时段监测停止，则计数保持不变。在一个驾驶循环结束，下一个驾驶循环开始时，计数器归零，重新开始计数。其他位的记录原理与此类似，见图5图注。TCU控制单元就是以这样的诊断原理，将网络通信丢失的故障记录下来。

 

3诊断通信分析
    诊断通信即为外部诊断设备与车载ECU之间进行的诊断信息交互。这个信息交互的过程要遵循一定的诊断通信协议要求，而诊断通信协议即为每个ECU生产商根据ECU的功能需求定义的诊断通信规范。外部诊断设备和ECU内部的诊断模块都要根据这个规范进行定义和开发，这样才可以保证外部诊断设备与ECU之间进行准确的诊断通信。

 

    汽车故障诊断除了可以让系统更加健壮，并实时处理出现的故障这个功能以外，还能将故障以DTC的形式记录下来，并通过诊断通信的形式传输给外部诊断设备进行分析。DTC被记录下来以后，外部诊断设备通过诊断通信的形式去读取这些故障信息。诊断通信通过不同的诊断服务，执行不同的诊断目的，例如：读取故障的诊断服务，是为了读取控制系统中所记录的DTC;读取数据信息的诊断服务，就是为了读取控制系统的一些参数。

    为了更好地分析诊断仪读取诊断信息的原理，不仅需要诊断仪对控制系统进行实时诊断，还需要CANoe将诊断仪和ECU之间交互的信息记录下来。通过分析CANoe实际记录的故障代码数据，进行诊断通信分析。在整车诊断通信中，客户端tester（诊断仪）和服务器端控制系统ECU是统一编址的，且每一个tester和ECU的地址都是惟一的。

    ECU发生故障时，ECU通过自诊断模块检测到系统部件敌障，然后将故障的信息以数字代码的形式存储在模块内部的EEPROM中。诊断仪通过诊断通信与ECU建立通信联系，ECU从自身的存储器中读取这些数字代码并传输给诊断设备。诊断设备根据代码所对应的故障信息来识别故障。

    诊断仪首先需要请求TCU开始建立诊断通信，然后告知TCU诊断的目的，例如：开始建立连接或读取故障信息等。这种诊断目的性体现在ISO14229中即为诊断服务的方式，例如：请求诊断服务、读取故障服务、读取数据服务等。表2是一段实际的诊断数据。

如表2所示，诊断开始时刻，诊断仪向TCU发送建立诊断请求，TCU进行回复。其中7E1和7E9分别代表TCU诊断标识和TCU响应诊断标识。10表示建立诊断通信请求服务标识，50是响应服务标识。在ISO 14229中规定，ECU的诊断响应ID=ECU诊断请求ID+0x008，例如7E1的请求，响应则为7E9；响应服务的ID＝请求服务的ID+0x40，例如10的服务响应则是50。这种规则化的处理方式方便了数据的传输，更方便了数据的处理。诊断通信就是建立在这种规则化的通信方式之上的。

    表3、表4所示的两段数据表示诊断仪对TCU进行读取故障码诊断服务，TCU分别反馈故障DTC个数和故障DTC内容的情况。其中，19服务是读取故障码信息服务，59是19服务的肯定响应服务。

    根据ISO 14229的诊断协议，19服务有01,02, 04, 06, OA等子服务。在01子服务中，第4个数据字节代表DTC状态掩码，即需要读取哪种状态的DTC。在表3所显示数据的19服务请求中，第4个字节为FF，它代表的意义为读取所有Bit置1位的DTC。在59响应服务中，第5, 6字节表示DTC的个数。如上述数据显示，第5, 6字节均为00，即DTC的个数为0。

    19服务的02子服务代表了根据故障信息掩码读取DTC内容。以表4为例，结果显示有1个故障DTC。
    数据中前3个字节所代表的含义可参照01子服务，之后的3个字节表示了这个DTC的内容，最后一个字节表示了这个DTC的状态。

    根据UDS诊断规范，DTC信息可由4部分组成，分别为DTC高位字节、DTC中位字节以及DTC低位字节和DTC状态。而根据UDS协议，我们将DTC高位字节又分为3个部分，且每一部分赋予了一定的意义，如表5所示。

    基于UDS的诊断协议，Bit7和Bit6组合为第1个编码集合；Bit5和Bit4组合为第2个编码集合；Bit3到BitO组合为第3个编码集合。这样做的好处是可以根据不同的编码集合设计不同的故障类别和故障信息，而事实上，因为位数比较多，很多Bit位目前并没有使用，但这样也为未来可扩展性做了预留，是一种非常好的机制。

    其中，DTC高位字节first编码集合代表的是汽车上哪种系统出现了故障。目前，规范定义的系统有动力系统、底盘系统、车身系统和网络系统。但随着汽车研究的高速发展，当前定义的4个系统已经不能满足要求，例如安全系统、娱乐系统等均没有制定出来，此时即可以使用其他预留的位加以辅助来进行识别。first编码集合的意义如表6所示。

    根据表4分析数据可知：反馈的59信息为d80759 02 FF C l 21 20 DB，其中C12120DB所代表就是DTC的信息，C1, 21, 20分别是DTC高位字节、DTC中位字节和DTC低位字节。将C1分解为8位的二进制为1100 0001，它最高两位（Bit7-6）为11，对应到表6中可知，是网络出现了问题，即出现了通信故障。剩下的几位00 0001和剩下的字节21, 20，根据整车厂策略不同，可以表示不同的内容，例如本文中最开始所提出的范例TCU记录的DTC为与ABS通信丢失，就可通过设置编译后，由剩下的位数表述出此故障信息。最后一个字节OxDB表示了该DTC的状态，此信息含义对应到本文第2章所述，将DB分解为8位二进制，由置1位分析DTC内容，此过程分析见图6。

    图6所示DTC状态为：置1位分别为test failed,test failed this operation cycle，confirmed DTC，testnot completed since last clear，test not completedthis operation cycle和Warning Indicator requested，由此分析可知此DTC出现错误，且在当前驾驶循环下被确认。

 

4基于UDS的通信故障诊断处理策略制定
    UDS诊断协议提供了故障检测、记录的方法和方向。但实际应用中还需要做两个方面的设计：一是底层机制的支持，二是上层诊断处理策略的制定。

    以车载网络通信中通信丢失这一故障诊断为例：首先，协议栈的驱动层应该定期地（或采用中断方式）接收网络上传输过来的信息，并通过某种机制告知上层协议栈。上层协议栈（例如交互层）应该具备检测通信丢失的功能机制，例如：周期性地进行检测（continuous test run）。当检测到缺失了应该接收到的信息或者接收超出了规定的时间闽值时，ECU应该记录下此次诊断失败（fault detectionat moment of test run）。

    上层诊断处理策略主要指如何记录DTC、记录DTC的哪些属性以及如何清除这些故障码，这是诊断处理策略制定的关键！

    以车载网络通信丢失这一故障诊断为例，需要严格而可靠地诊断出这一故障，为此本文提出在UDS的基础上进行优化，制定了以下机制，如图7所示。

    1)设定一个通信丢失错误计数器，一旦检测到通信丢失，错误计数器开始计数。
    2)在计数过程中一旦接收到信息，则计数器减1。
    3)如果错误计数达到5次或者一个更可靠的阂值（这与具体的应用有关，在某些高安全高可靠领域可能更小）时，启动通信丢失预警定时器，也称之为恢复阶段定时器，并开始定时。
    4)一旦通信丢失，预警定时器达到6s还没有接收到信息，我们认为通信丢失故障检测完成，并置相应DTC的test failed位为1，如图7中“1”处所标识。

    图8所示的时间流程图能够更清晰地说明这个基于UDS优化后的通信故障诊断处理策略。

    在上电以后，各个系统开始正常的通信，发送和接收信号都没有诊断出故障。在T0时刻，ECU检测到应该接收的信号丢失，开始启动错误计数器。当错误计数器达到一定I01值但还没有接收到信息时，启动恢复阶段定时器。如果在恢复定时器时间段内，还检测到通信丢失故障并且没有恢复，则在定时器结束时记录下该DTC，并在与外部设备进行故障诊断时，以诊断通信的方式传输给诊断设备。

5结束语
    本文主要基于UDS统一诊断服务对车载网络诊断过程的机制、策略进行了分析和研究。根据网络通信的规范，设计出车载网络通信丢失故障的诊断策略。通过故障数据记录，结合ISO 14229诊断规范，分析到数据每一个字节、每一位所代表的含义，提出了新的优化机制，从而完善了网络通信诊断记录DTC策略，极大地提高了车载网络通信的可靠性和鲁棒性。