UDS诊断故障码及诊断服务介绍(14h, 19h, 85h)
1 诊断故障
人看病就医时，医生通过望闻问切来判定病因。而汽车运行出现故障时，维修人员(或开发人员)通过专业的诊断仪器直接读取当前车辆的故障。原理是车载控制器会时刻监控自身的运行情况，并把发现的故障信息进行存储，当诊断设备通过CAN总线请求读取故障时(19h服务)，车载控制器返回相应的数据。
常见汽车故障
常见的车载故障如下(包含不限于)
1 ECU内部故障（如ECU供电电压过高，ECU供电电压过低）
2 网络通信异常（如总线bus off，节点丢失）
3 输入输出电路异常(传感器短路/开路，执行器异常，温度传感器数值过高)
诊断故障码
产品设计时，会根据产品硬件罗列出所有可能的故障，并为每个特定的故障分配一个代码，这个代码就是诊断故障码。如定义供电电压过低的故障码为U2E0468.诊断故障码可以理解为故障的身份证号。故障码对应一个故障的产生条件，恢复条件，故障内容。
如诊断仪读取到U2E0468，便知道发生了供电电压过低的故障，这个故障会在供电电压持续低于8.6V 3秒后产生，而当供电电压持续大于9V 5秒后消失。
诊断故障码(Diagnostic Trouble Code)的格式如下：
由三个字节组成：(DTC故障码定义由主机厂总线人员定义，且采用ISO15031-6定义的标准)。
| DTCHighByte | DTCMiddleByte | DTCLowByte |
|---|---|---|
| 7E | 04 | 68 |
DTC故障码高字节定义如下；中低字节表明具体故障对象跟类型。
小解：前面提及的故障码为U2E0468；U指的是通用/网络故障，把该故障码解析成16进制变为0x7E0468.
1.1 状态掩码字节
DTC状态掩码用于判定当前故障的状态，占用一个字节。 如该字节计算出的数值为2E代表历史故障确认码，2F代表故障当前检测到。
1.1.1 Bit 0：TF(Test Failed)
该位用以指示当前时刻是否检测到错误；
当检测到故障后，该位置1；
当未检测到故障或者收到$14服务后，该位清0.
状态迁移见下图：
1.1.2 Bit 1：TFTOC(Test Failed This Operation Cycle)
该位指示是否有故障产生在当前点火周期里任一时间内。
本周期内，检测到故障产生，该位置1，
直到下一个周期到来或者收到$14服务请求，该位清0。
当Bit2支持时，Bit1强制支持。
状态迁移见下图：
1.1.3 Bit2 PendingDtc 挂起错误标志位(最近俩个点火周期)
该位指示是否有故障检测到在当前及上个点火周期；
当上个点火周期或本个点火周期检测到错误后，该位置1；
当上个点火周期或本个点火周期都没检测到错误后，或收到$14请求后，该位清0.
1.1.4 bit3_CDTC ConfirmedDtc 历史确认DTC码位
该位用于表示检测到的某故障的次数达一定次数，确认故障存在，该故障被写进掉电非易失型内存中；
该位用于表示故障在过去存在，当前不一定存在。
上次请求$14服务后检测到故障且老化机制没有满足，该位置1；
当接收$14服务或者满足老化机制（连续40个点火周期没有检测到该故障）或存储内存被新的故障信息刷写后或自上次清除故障后再没有检测到该故障，清0；
1.1.5 Bit4_TNCSLC 测试未完成自从上次清除testNotCompletedSinceLastClear
该位指示自从上次$14服务后，是否完成有效的检测(无论检测是有故障还是故障)；
初始化后，该位置1；
当完成检测后，无论检测是否有故障，该位清0；
收到$14服务或自初始化后未完成一次有效检测，该位置1；
（为什么需要这位？某些检测是需要基于一定的条件的，例如检测电机反馈电压就需要电池电压在正常区间，节点丢失通信错误检测就需要在电池电压正常，并且是非Limphome和非BusOff状态下检测）
1.1.6 Bit_5 TFSLC testFailedSinceLastClear 自从上次清除后，检测到错误
该位用于表示是否有故障检测到自从上次请求$14服务，该位不会随老化机制以及内存刷写改变。
初始化该位清0；
当没有测试或者测试一直没有检测到或请求$14服务后；该位清0；
自从上次请求$14后，检测到一次错误后，该位置1；
1.1.7 Bit6 TNCTOC testNotCompletedThisOperationCycle 当前点火周期测试未完成
该位用于当前点火周期是否有一次检测完成，无论是否检测到错误。
初始化置1；
当本个点火周期完成一次检测，无论检测结果是否存在故障，该位清零；
当下个点火周期或者请求$14服务后，该位置1
1.1.8 Bit7 WIR警告指示请求位warningIndicatorRequested
1.2 状态码操作机制
每个故障有一个错误计数器，FaultDetetionCounter，如当前周期检查到故障发生，该错误计数器值加1，当当前周期检查到该故障未发生，错误计数器减1。(故障计数器每次加建的值视项目定义)。
下图定义了诊断状态掩码字节各bit基于错误计数器的操作机制。
方式一
方式二：
1.3 老化计数器
每个故障还配置个老化计数器，该计数器的数据值存放在非易失性内存中，该计数器的作用是：当确认故障发生时，激活该计数器，每个点火周期该计数器加1，当计数器达到设定值时，清除诊断状态掩码的CDTC位。
简单来说，当前认为模拟故障A确认发生一次，老化计数器设置为40；然后连续点火45次并读取故障A（该过程中没有z故障产生）。效果是前40次点火能读取到历史故障码，后5次读取不到该故障。认为超过40次后，该故障消失了。
2 诊断相关服务
2.1 ClearDTCInformation(清除诊断信息服务 14h)
清除诊断信息服务用于客户端去清除一个或多个ECU内的诊断信息。
请求报文唯一参数为GoupOfDTC，用于清除ECU里的类型（如：动力系统、车身、地盘）或者指定的DTC。服务器应该清除排放相关跟非排放相关的DTC信息在请求的组类别中。
本服务清除的DTC信息应包含：
DTC状态字节
快照信息
DTC扩展信息
相关数据（如：最近的DTC、标志量、定时计数器）
上位机请求报文格式为：
例程：
注：肯定响应报文数据只有一个服务ID。
2.2 ReadDTCInformation 读取诊断信息（19h）
本服务允许上位机读取一个或一组服务器中的DTC状态信息。包含以下内容
通过掩码报告DTC数量；
通过掩码报告DTC信息；(F14暂不支持)
通过DTC及掩码报告快照信息；(F14暂不支持)
通过DTC及掩码报告DTC扩展信息；
报告支持的DTC
2.2.1 Sub_Func 01通过掩码报告DTC数量
该子服务请求服务器报告与请求报文掩码相匹配的DTC数量；
Request Message
Postive Reponse Message
例程：
2.2.2 Sub_Fuc 02通过掩码报告检测DTC列表
该字符请求服务器报告与请求报文中掩码对应的所有已检测到DTC。
Postive Reponse Message
例程：
子服务通过掩码报告DTC数量、通过掩码报告DTC服务中，服务器中通过按位和操作比较掩码与DTC状态码，当(statusOfDTC & DTCStatusMask) != 0]时，则认为故障存在。
当客户端发送的状态码某位服务器不支持，则处理时，仅考虑服务器支持的位。
代码中定义的DTC状态可用状态位标识定义如下：
该位需根据实际情况进行配置；要求TNCTOC、TNCSLC俩位不能置1(因该俩位是检测未完成)。
2.2.3 Sub_Func 0A报告所有支持的DTC
Request message
Reponse message
例程：
标题2.3 ControlDTCSetting (85h)/控制DTC设置服务(85h)
本服务允许上位机请求一个或一组服务器启用/停禁用DTC检测；
软件实现中；当应用模块检测到故障后，如果读DTC控制状态为OFF，将不会进行DTC状态掩码操作。
当执行ECU Rest(11hex)服务后，DTC控制状态默认到ON。
当执行ClearDTCInformation(14hex)服务后，85服务不应阻止服务器重置DTC内存信息。
Request Message
Postive Reponse Message
例程：
