UDS 19服务，即0x19服务，是UDS（Unified Diagnostic Services，统一诊断服务）协议中的 “读取DTC信息 (ReadDTCInformation)”服务，即读取车辆电子控制单元（ECU）中的诊断故障码（DTC）信息。
客户端可以通过该服务读取存储在车辆ECU中的DTC状态信息。0x19服务包含多个子功能（Sub-Function），用于实现不同的诊断需求，比如:
reportNumberOfDTCByStatusMask（0x01）：报告与状态掩码匹配的DTC数量。 reportDTCByStatusMask（0x02）：根据状态掩码报告DTC列表。 reportDTCSnapshotIdentification（0x03）：报告DTC快照标识。 reportDTCStoredDataByRecordNumber（0x05）：根据记录号报告DTC存储数据。 reportDTCExtDataRecordByDTCNumber（0x06）：根据DTC编号报告扩展数据记录。 reportSupportedDTC（0x0A）：报告支持的DTC。 reportFirstTestFailedDTC（0x0B）：报告第一次测试失败的DTC。 reportMostRecentTestFailedDTC（0x0D）：报告最近一次测试失败的DTC。
请求格式：19 + 子功能码 + 状态掩码或其他参数； 响应格式：59 + 子功能码 + DTC信息。
DTC状态是用于描述故障发生情况、严重程度以及故障检测状态的一组信息，DTC状态由一个字节（8个bit）组成，每个bit都有特定的含义，用于表示不同的故障状态。以下是DTC状态的8个bit位的定义：
Bit0：Test Failed，表示当前测试是否失败。如果当前检测到故障条件满足，该位置1。 Bit1：Test Failed This Operation Cycle，表示在当前操作循环中是否检测到故障。 Bit2：Pending DTC，表示故障处于待确认状态，即故障可能尚未完全确认。 Bit3：Confirmed DTC，表示故障已被确认，通常意味着故障多次出现或满足特定条件。 Bit4：Test Not Completed Since Last Clear，自上次清除故障码后，测试是否完成。 Bit5：Test Failed Since Last Clear，自上次清除故障码后，是否检测到故障。 Bit6：Test Not Completed This Operation Cycle，当前操作循环中测试是否完成。 Bit7：Warning Indicator Requested，是否请求激活警告指示灯（如仪表盘上的报警灯）。
这些状态位通过组合提供了故障的详细信息，帮助维修人员快速定位问题并判断故障的严重程度。
而状态掩码（Status Mask）是用于筛选和过滤诊断故障码（DTC）状态的工具，它也是由8个状态位组成，每个位的含义与DTC状态的一样，所以状态掩码主要用于以下场景：
在0x19服务中，客户端通过设置状态掩码来请求与特定状态匹配的DTC信息，比如设置状态掩码为0x01，表示请求最近一次测试失败的DTC；
在0x19服务的响应中，服务器通过该掩码告知客户端其支持的状态位（DTCStatusAvailabilityMask），比如0x09表示服务器支持bit0和bit3的状态；
在0x19服务的响应中，反映了DTC当前的实际状态（statusOfDTC）。
这里再通过一个例子来了解，假设ECU支持的状态掩码为0x09（支持bit0和bit3），客户端请求的状态掩码为0x01，以下是DTC的匹配逻辑：
这样通过状态掩码的筛选机制，诊断工具可以高效地获取特定状态的故障码信息，从而提高故障排查的效率。
3 快照数据
快照数据可以记录故障发生时的关键参数，例如发动机转速、车速、电压、时间戳等，这些信息帮助工程师快速了解故障发生时的具体环境。 通过快照数据，维修人员可以获取故障发生时的详细信息，从而更高效地定位问题。 快照数据可以记录多次故障发生时的不同状态，帮助分析故障的重复性和规律。
在UDS协议中，快照数据可以通过0x19服务的子功能0x04读取，该子功能允许客户端请求特定DTC的快照数据，响应中包含DTC的状态、快照记录编号、数据标识符（DID）以及具体的快照数据。
假设某个DTC为0x123456，表示转向灯故障，快照数据可能包括：车速（50kph）,发动机转速(2500rpm)、电压(12V)和油门深度（20%）等其他相关参数。
4 扩展数据
扩展数据（Extended Data）是指与DTC相关的一些附加信息，用于提供更多关于故障发生的历史和上下文信息。扩展数据通常包括以下内容：
故障发生计数器（Fault Occurrence Counter）：记录某个故障DTC发生的具体次数；
等待故障计数器（Fault Pending Counter）：记录某个故障DTC处于“待确认”状态的次数；
老化计数器（Aging Counter）：记录故障DTC的“老化”次数，即故障持续存在的次数；
已老化计数器：记录故障DTC已经老化（即确认为真实故障）的次数；
故障指示灯计数器：记录故障指示灯（MIL）点亮的次数。
通过扩展数据，维修人员可以了解故障发生的历史情况，判断故障是偶发的还是频繁出现的。扩展数据也可以帮助判断故障是否指向硬件或软件问题，从而更精准地进行维修。
扩展数据可以通过0x19服务的子功能0x06读取，请求报文格式与读取快照数据类似，只是最后一个字节定义为扩展数据编号。
假设某个DTC为0x123456，其扩展信息可能包括：故障发生计数器：3（表示该故障已发生3次），等待故障计数器：1（表示该故障曾处于待确认状态1次），老化计数器：2（表示该故障已老化2次）。
5 关键点
在理解了这些基本概念之后，有两个问题需要思考：为什么需要这些内容，以及怎么去实现这些内容。这里先以DTC状态为例：
对于DTC状态的每位，其实现逻辑是怎样的，即什么情况下置1，又什么情况下置0？
以DTC状态 bit0 : testFailed 为例：如果在最近的一次测试结果为Failed，那么相应DTC的状态位bit0就置1；当OEM定义的重置条件满足，或者最近的一次测试结果Passed，或者使用诊断设备执行了清除DTC指令，那么相应DTC的状态位bit0就重置为0，其切换逻辑如下所示，该位初始值为0。
也就是说当你去开发或测试时，需要明白这点，不然只看到现象，不知道其背后的逻辑。另外，但为什么需要这样来定义DTC状态位？或者为什么需要DTC状态位？
可以从以下几个方面进一步了解到DTC状态位作用：
故障确认：DTC状态位可以用于确认故障是否持续存在。一旦故障被检测到并生成了故障码，相关的DTC状态位可以指示故障是否仍然存在。如下所示：
情况1表示一个瞬时（潜在）故障； 情况2表示是一个历史故障； 情况3表示是一个当前故障。
故障历史记录：DTC状态位可以记录故障的历史信息。当故障发生时，DTC状态位可以被设置为指示该故障已经发生过，如上情况2的历史故障等。 故障清除和重置：DTC状态位还可以用于指示故障码是否已被清除或重置，如下所示：
情况1有种解释是DTC被清除过后没出现过故障；
情况2有种解释是DTC被清除过后出现过故障。
驾驶循环：汽车完成点火，运转（若车辆存在故障应能被检测到），熄火的完整过程称为一个驾驶循环。
暖机循环：发动机经充分运转，使冷却温度比发动机启动时上升至少20℃，并达到一个最低温度70℃的过程。一般是针对排放相关DTC所设定的循环周期。
通常定义三四十个暖机循环作为故障码清除的条件，因为在相对较长过程中，如果车辆没再发生这个故障，则可认为是一个偶发的现象，车辆处于相对稳定的状态，则可将这个故障码清除。
6 小结
以上就为0x19服务开了个头，介绍19服务的基本概念，以及涉及到专有词汇，下篇文章就开始介绍0x19服务的子功能，敬请关注。
创作不易，欢迎点赞再看收藏关注！
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。
