UDS(Unified diagnostic services)协议（统一诊断服务），即ISO14229，是诊断服务的规范化标准。
OBD是关注车辆售后实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范，只是应用层的规范。UDS与OBD最大的区别就在于“Unified”上，它是面向整车所有ECU(电控单元)的，而OBD是面向排放系统ECU的，单说UDS而言，它只是一个应用层协议(ISO 14229-1)。UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。
UDS诊断原理分析
根据UDS的诊断协议，汽车上的控制系统需要根据规则化的诊断协议进行故障记录和处理，最终体现为诊断故障编码DTC的方式。
根据ISO-14229协议规定，每个DTC均由DTC内容和DTC状态表示。DTC内容代表了该故障的具体故障方式、故障标志等信息，例如车身系统中ABS传感器故障。DTC状态则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的故障状态信息，详细意义如下表。
| 位 | 功能 | 描述 |
|---|---|---|
| bit0 | Test Failed | DTC最近的一次诊断结果为失败 |
| bit1 | Test Failed This Operation Cycle | 在当前驾驶循环中处于故障状态 |
| bit2 | pending DTC | 在当前或者钱一个驾驶循环DTC处于故障状态 |
| bit3 | Confirmed DTC | DTC已被确认 |
| bit4 | Test Not Completed Since Last Clear | 自上次清除故障码后测试没有完成 |
| bit5 | Test Failed Since Last Clear | 自上一次清除故障码后测试结果为失败 |
| bit6 | Test Not Completed This Operation Cycle | 在当前驾驶循环中测试没有完成 |
| bit7 | Waring Indicator Requested | 与DTC相关的报警指示请求 |
根据ISO 14229诊断协议，DTC的记录原理和状态信息控制如图5所示。控制系统以一定的时间周期（如50 ms）进行一次相应的故障监测，检测是否出现了故障。下图中，椭圆框中竖线部分表示检测到了故障。每一个控制单元中都会设定一个错误监测计数器，如黑色框中图形显示，计数器有计数上、下限，例如错误计数上限为127，下限为-128。
- 一个驾驶循环开始的时候，错误检测计数从0开始，监测信号没有错误，则计数器减1，若一直累计到下限-128，则不再递减。而一旦监测到一个错误信号，计数器将归零或置于零上，若之后有连续的错误帧，则计数器持续累加，直到上限127,此时第一位（Bit 0 Test Failed）将置1。
- 在一个驾驶循环内，如果某一时段监测停止，则计数保持不变。
- 在一个驾驶循环结束，下一个驾驶循环开始时，计数器归零，重新开始计数。
其他位的记录原理与此类似，见下图注。TCU控制单元就是以这样的诊断原理，将网络通信丢失的故障记录下来。
诊断通信分析
诊断通信即为外部诊断设备与车载ECU之间进行的诊断信息交互。这个信息交互的过程要遵循一定的诊断通信协议要求，而诊断通信协议即为每个ECU生产商根据ECU的功能需求定义的诊断通信规范。外部诊断设备和ECU内部的诊断模块都要根据这个规范进行定义和开发，这样才可以保证外部诊断设备与ECU之间进行准确的诊断通信。
汽车故障诊断除了可以让系统更加健壮，并实时处理出现的故障这个功能以外，还能将故障以DTC的形式记录下来，并通过诊断通信的形式传输给外部诊断设备进行分析。DTC被记录下来以后，外部诊断设备通过诊断通信的形式去读取这些故障信息。诊断通信通过不同的诊断服务，执行不同的诊断目的，例如：读取故障的诊断服务，是为了读取控制系统中所记录的DTC；读取数据信息的诊断服务，就是为了读取控制系统的一些参数。
在整车诊断通信中，客户端tester（诊断仪）和服务器端控制系统ECU是统一编址的，且每一个tester和ECU的地址都是惟一的。
ECU发生故障时，ECU通过自诊断模块检测到系统部件敌障，然后将故障的信息以数字代码的形式存储在模块内部的EEPROM中。诊断仪通过诊断通信与ECU建立通信联系，ECU从自身的存储器中读取这些数字代码并传输给诊断设备。诊断设备根据代码所对应的故障信息来识别故障。
诊断仪首先需要请求TCU开始建立诊断通信，然后告知TCU诊断的目的，例如：开始建立连接或读取故障信息等。这种诊断目的性体现在ISO14229中即为诊断服务的方式，例如：请求诊断服务、读取故障服务、读取数据服务等。下表是一段实际的诊断数据。
| Time | ID | Data |
|---|---|---|
| 223.174 | 7E1 | 02 10 03 00 00 00 00 00 |
| 223.177 | 7E9 | 06 50 03 00 32 01 F4 00 |
上表所示，诊断开始时刻，诊断仪向TCU发送建立诊断请求，TCU进行回复。其中7E1和7E9分别代表TCU诊断标识和TCU响应诊断标识。10表示建立诊断通信请求服务标识，50是响应服务标识。在ISO 14229中规定，ECU的诊断响应ID=ECU诊断请求ID+0x008，例如7E1的请求，响应则为7E9；响应服务的ID＝请求服务的ID+0x40，例如10的服务响应则是50。这种规则化的处理方式方便了数据的传输，更方便了数据的处理。诊断通信就是建立在这种规则化的通信方式之上的。
下表所示的两段数据表示诊断仪对TCU进行读取故障码诊断服务，TCU分别反馈故障DTC个数和故障DTC内容的情况。其中，19服务是读取故障码信息服务，59是19服务的肯定响应服务。
| Time | ID | Data |
|---|---|---|
| 244.849 | 7E1 | 03 19 01 FF 00 00 00 00 |
| 244.859 | 7E9 | 06 59 01 FF 00 00 00 00 |
| 400.598 | 7E1 | 03 19 02 FF 00 00 00 00 |
| 400.599 | 7E9 | 07 59 02 FF C1 21 20 DB |
根据ISO 14229的诊断协议，19服务有01,02, 04, 06, OA等子服务。在01子服务中，第4个数据字节代表DTC状态掩码，即需要读取哪种状态的DTC。在上表所显示数据的19服务请求中，第4个字节为FF，它代表的意义为读取所有Bit置1位的DTC。在59响应服务中，第5, 6字节表示DTC的个数。如上述数据显示，第5, 6字节均为00，即DTC的个数为0。
19服务的02子服务代表了根据故障信息掩码读取DTC内容。以上表为例，结果显示有1个故障DTC。数据中前3个字节所代表的含义可参照01子服务，之后的3个字节表示了这个DTC的内容，最后一个字节表示了这个DTC的状态。
根据UDS诊断规范，DTC信息可由4部分组成，分别为DTC高位字节、DTC中位字节以及DTC低位字节和DTC状态。而根据UDS协议，我们将DTC高位字节又分为3个部分，且每一部分赋予了一定的意义，如下表所示。
| 逻辑值 | DTC高位字节信息 | |||||||
| Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0 | |
| 编码集合 | first | second | third | |||||
基于UDS的诊断协议，Bit7和Bit6组合为第1个编码集合；Bit5和Bit4组合为第2个编码集合；Bit3到Bit0组合为第3个编码集合。这样做的好处是可以根据不同的编码集合设计不同的故障类别和故障信息，而事实上，因为位数比较多，很多Bit位目前并没有使用，但这样也为未来可扩展性做了预留，是一种非常好的机制。
其中，DTC高位字节first编码集合代表的是汽车上哪种系统出现了故障。目前，规范定义的系统有动力系统、底盘系统、车身系统和网络系统。但随着汽车研究的高速发展，当前定义的4个系统已经不能满足要求，例如安全系统、娱乐系统等均没有制定出来，此时即可以使用其他预留的位加以辅助来进行识别。first编码集合的意义如下表所示。
| 高位字节Bit7-6 | 编码分类 | 系统 | 缩写 |
|---|---|---|---|
| 00 | P0xxx - P3xxx | 动力系统 | P |
| 01 | C0xxx - C3xxx | 底盘系统 | C |
| 10 | B0xxx - B3xxx | 车身系统 | B |
| 11 | U0xxx - U3xxx | 网络系统 | U |
反馈的59信息为d8 07 59 02 FF C1 21 20 DB，其中C1 21 20 DB所代表就是DTC的信息，C1, 21, 20分别是DTC高位字节、DTC中位字节和DTC低位字节。将C1分解为8位的二进制为1100 0001，它最高两位（Bit7-6）为11，对应到上表中可知，是网络出现了问题，即出现了通信故障。剩下的几位00 0001和剩下的字节21, 20，根据整车厂策略不同，可以表示不同的内容，例如本文中最开始所提出的范例TCU记录的DTC为与ABS通信丢失，就可通过设置编译后，由剩下的位数表述出此故障信息。最后一个字节OxDB表示了该DTC的状态，此信息含义对应到本文第2章所述，将DB分解为8位二进制，由置1位分析DTC内容，此过程分析见下表。
| C1 | 21 | 20 | DB | |||||
| 11 | 00 | 0001 | 0010 | 0001 | 0010 | 0000 | 1101 | 1011 |
| U =Network | 与ABS数据丢失 | "DTC bit | ||||||
所示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出现错误，且在当前驾驶循环下被确认。
UDS的通信故障诊断处理策略
UDS诊断协议提供了故障检测、记录的方法和方向。但实际应用中还需要做两个方面的设计：一是底层机制的支持，二是上层诊断处理策略的制定。
以车载网络通信中通信丢失这一故障诊断为例：首先，协议栈的驱动层应该定期地（或采用中断方式）接收网络上传输过来的信息，并通过某种机制告知上层协议栈。上层协议栈（例如交互层）应该具备检测通信丢失的功能机制，例如：周期性地进行检测（continuous test run）。当检测到缺失了应该接收到的信息或者接收超出了规定的时间闽值时，ECU应该记录下此次诊断失败（fault detectionat moment of test run）。
上层诊断处理策略主要指如何记录DTC、记录DTC的哪些属性以及如何清除这些故障码,这是诊断处理策略制定的关键！以车载网络通信丢失这一故障诊断为例，需要严格而可靠地诊断出这一故障，制定了以下机制，如下图所示。
- 1)设定一个通信丢失错误计数器，一旦检测到通信丢失，错误计数器开始计数。
- 2)在计数过程中一旦接收到信息，则计数器减1。
- 3)如果错误计数达到5次或者一个更可靠的阂值（这与具体的应用有关，在某些高安全高可靠领域可能更小）时，启动通信丢失预警定时器，也称之为恢复阶段定时器，并开始定时。
- 4)一旦通信丢失，预警定时器达到6s还没有接收到信息，我们认为通信丢失故障检测完成，并置相应DTC的test failed位为1，如图7中“1”处所标识。
下图所示的时间流程图能够更清晰地说明这个基于UDS优化后的通信故障诊断处理策略。
在上电以后，各个系统开始正常的通信，发送和接收信号都没有诊断出故障。在T0时刻，ECU检测到应该接收的信号丢失，开始启动错误计数器。当错误计数器达到一定I01值但还没有接收到信息时，启动恢复阶段定时器。如果在恢复定时器时间段内，还检测到通信丢失故障并且没有恢复，则在定时器结束时记录下该DTC，并在与外部设备进行故障诊断时，以诊断通信的方式传输给诊断设备。
3137
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
