UDS（九）应用层 14/19

Stored Data Transmission functional unit

UDS的第三类诊断服务：存储数据传输。该类型服务包含SID如下：

ClearDiagnosticInformation (0x14)：清除诊断信息
ReadDTCInformation (0x19)：读取诊断信息

1. ClearDiagnosticInformation (0x14) Service

客户端通过该诊断服务清除ECU中存储的诊断信息。

1.1 请求格式

由上图可知请求格式分为两个部分
第一部分：请求SID：0x14，占用一个字节
第二部分：groupOfDTC，由厂家自定义，占用三个字节

1.2 响应格式

由上图可知响应格式只有response SID：0x54，占用一个字节

1.3 举例

groupOfDTC为3个FF代表清除所有DTC

2. ReadDTCInformation (0x19) Service

转载于：https://zhuanlan.zhihu.com/p/37310388
转载于：https://zhuanlan.zhihu.com/p/35371763

19服务是一套诊断服务中的重中之重。协议中篇幅长达63页，通信举例达到了18个。可以说没有19服务，就没有完整的UDS。

DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将存储为DTC。DTC可表现为：一个显而易见的故障；通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节。

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。DTMMiddleByte和DTCLowByte两个字节是我们熟知的类似P0047（ISO15031中的故障码）中“0047”的纯数字故障码。第一个字节在乘用车中，前两个bit代表P/C/B/U（动力/底盘/车身/网络）中的一个，之后六个bit是数字，合在一起的样子形如“C01”。第一个字节的前2个bit中，用00/01/10/11分别表示P/C/B/U。（感谢aymjwwl007）

举个例子，U312345这个故障码（我杜撰的），它的状态是Test failed叠加Confirmed，那么DTC信息这四个字节就应该是0xF1(二进制11110001)，0x23，0x45，0x09。

$19拥有28个子服务（Sub-Function）。常用的子服务有：

01 (读取符合掩码条件的DTC数量)（必须支持）,后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读。

在肯定回复时，组合应该是59(19+40) - 01 （子功能） - 09 （本ECU所支持的掩码条件）-01 DTC的格式（ISO14229-1为01） - 00 01 （目前满足条件的DTC有一个）

02（读取符合掩码条件的DTC列表及其状态）（必须支持），后面的参数是DTC状态掩码，解读同上。

在肯定回复是，59 - 02（子功能）- 09（本ECU所支持的掩码条件） - XX XX XX ( DTC,车厂定义 ) - 01 （这个故障码怎么了，01表示当前故障）

04（读取快照信息），也叫冻结帧。
为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。请求格式如下：

其中，DTCSnapshotRecordNumber表示DTC快照记录码，占一个字节，表示特定的 DTC快照数据记录编号。例如当我们需要记录某个DTC第一次发生（假设用1表示）和最近一次发生的快照数据时（假设用2表示）；那么当DTCSnapshotRecordNumber为1时，则表示请求该DTC第一次发生时的快照信息。

如果ECU支持多个DTC快照数据记录，那么该纪录码应使用0x01~0xFE范围内的数值。当该参数值为FF（Hex）时，要求ECU一次性报告所有存储的DTC快照数据记录。

收到请求后，ECU的响应报文格式如下：


如上，响应报文中DTCSnapshotRecordNumber表示返回的是该DTC的哪一个快照记录；DTCSnapshotRecordNumberOfIdentifiers表示快照信息中定义的成员量；如定义的快照数据有四项信息，则该值为4。

06（读取扩展信息）。

0A（读取ECU支持的所有DTC列表及其状态）（必须支持）。这个就不必发DTC状态掩码了。所有支持的DTC列表及其状态都会打印出来。

上图中黄色框是DTC，紧跟着的是DTC状态

上图中同时读取当前/历史故障，黄色框是DTC，紧跟着的是DTC状态

刚才提到，一个DTC除了它自己的3个字节，还有一个字节专门用于表达DTC的状态，这个字节我们叫它DTC状态掩码。这个状态字节每个位的含义下面列举出来。注意，在实际项目中，并不是所有的DTC状态都是支持的。DTC状态掩码前7个位的理解是UDS的一个难点。

从汽车ECU中读取储存的DTC(故障码)时，除了故障码本身，还可以读出很多其他的信息，包括优先级、发生次数计数器、发生时的里程和时间，以及本文中所讲的状态位（DTC status ）。

这个状态位包含1个byte，这里面的8个bit都有各自的含义，但是这8个 bit不一定都要使用，各个主机厂可以根据自己的需求使用其中的几个，当然也可以全部使用。下图是UDS对DTC status这8个bit的定义

bit 0 : testFailed

通常来说，ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态位就要被置1，表征出错。此时DTC的testFailed位被置1，但是它不一定被ECU存储到non-volatile memory中，只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置为0。

bit 1 :testFailedThisOperationCycle

这个bit用于标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，即是否出现过错误。operation cycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠，对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过，比如，当前testFailed = 0， 说明当前这个DTC没有出错，如果testFailedThisOperationCycle = 1的话，就说明这个DTC在当前这个operation cycle中出过错，但是当前错误又消失了。

bit 2 : pendingDTC

根据规范的解释，pendingDTC = 1表示某个DTC在当前或者上一个operation cycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个operation cycle中出现才可以被判定为confirmed的状态，此时就需要借助于pendingDTC位了。pendingDTC = 1的时候，DTC就要被存储下来了，如果接下来的两个operation cycle中这个DTC都还存在，那么confirmedDTC就要置1了。如果当前operation cycle中，故障发生，pendingDTC = 1，但是在下一个operation cycle中，故障没有了，pendingDTC 仍然为 1，再下一个operation cycle中，故障仍然不存在，那么pendingDTC 就可以置0了。

bit 3 : confirmedDTC

当confirmedDTC = 1时，则说明某个DTC已经被存储到ECU的non-volatile memory中，说明这个DTC曾经满足了被confirmed的条件。但是请注意，confirmedDTC = 1时，并不意味着当前这个DTC仍然出错，如果confirmedDTC = 1，但testFailed = 0，则说明这个DTC表示的故障目前已经消失了。将confirmedDTC 重新置0的方法只有删除DTC，UDS用0x14服务，OBD用0x04服务。

bit 4 : testNotCompletedSinceLastClear

这个bit用于标识，自从上次调用了清理DTC的服务（UDS用0x14服务，OBD用0x04服务）之后，是否成功地执行了对某个DTC的测试（不管测试结果是什么，只关心是否测了）。因为很多DTC的测试也是需要满足某些边界条件的，并不是ECU上电就一定会对DTC进行检测。

testNotCompletedSinceLastClear = 1 : 自从清理DTC之后还没有完成过针对该DTC的测试。

testNotCompletedSinceLastClear = 0 : 自从清理DTC之后已经完成过针对该DTC的测试。

bit 5 : testFailedSinceLastClear

这个位与bit 1 :testFailedThisOperationCycle有些类似，后者标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，而testFailedSinceLastClear标识的是在上次执行过清理DTC之后某个DTC是否出过错。

testFailedSinceLastClear = 0 ， 自从清理DTC之后该DTC没有出过错。

testFailedSinceLastClear = 1， 自从清理DTC之后该DTC出过至少一次错。

bit 6 : testNotCompletedThisOperationCycle

这个位与bit 4 : testNotCompletedSinceLastClear类似，后者标识自从上次调用了清理DTC的服务之后，是否成功地执行了对某个DTC的测试。而testNotCompletedThisOperationCycle则标识在当前operation cycle中是否成功地执行了对某个DTC的测试。

testNotCompletedThisOperationCycle = 1 ： 在当前operation cycle中还没在完成过针对该DTC的测试。

testNotCompletedThisOperationCycle = 0 ： 在当前operation cycle中已经完成过针对该DTC的测试。

bit 7 : warningIndicatorRequested

某些比较严重的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯，或者是文字，或者是声音。这个warningIndicatorRequested就用于此类DTC。

warningIndicatorRequested = 1 ： ECU请求激活警告指示。

warningIndicatorRequested = 0： ECU不请求激活警告指示。

注意：如果这个DTC不支持警告指示，则这个位永远置0。

总结来说，这8个状态位只用文字描述的话会略显抽象，如果在工作中看到这些状态位的变化，那么就很好理解它了。

UDS协议栈系列文章：

UDS（一）入门概述

UDS（二）网络层

UDS（三）网络层时间参数

UDS（四）应用层

UDS（五）应用层10/3E

UDS（六）应用层11/27

UDS（七）应用层28/85

UDS（八）应用层22/2E

UDS（九）应用层14/19

UDS（十）应用层34/36/37