基于UDS的CAN通讯故障诊断
摘要：阐述一种诊断控制单元之间通讯丢失故障的机制，经过基于UDS的诊断协议进行原理分析，并制定一种有效的诊断处理策略。html
汽车故障诊断是利用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所示。this
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控制单元就是以这样的诊断原理，将网络通讯丢失的故障记录下来。3d
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。这种规则化的处理方式方便了数据的传输，更方便了数据的处理。诊断通讯就是创建在这种规则化的通讯方式之上的。
表三、表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策略，极大地提升了车载网络通讯的可靠性和鲁棒性。