本文内容参考以下两篇文章，感谢两位作者！
https://blog.csdn.net/weixin_44536482/article/details/90521791
https://zhuanlan.zhihu.com/p/35371763
DTC(Diagnostic Trouble Code)表示诊断故障码，是故障类型的”身份ID”；用于汽车故障时对故障部位及原因的排查。其格式如下：
1. 故障内码与5位标准故障码的对应关系
其中，DTCHighByte、DTCMiddleByte这两个字节表示故障内码，对应5位标准故障码（第一位是字母，后面四位是数字），如”B100016″这个故障码中的”B1000″；最后面的”16″则是DTCLowByte的内容。故障内码与5位标准故障码的位置对应关系如下：
（1）、第一位是字母，表示故障所属系统；有如下的四种情况：
（2）、第二位是数字，表示故障类型；有如下的四种情况：
（3）、第三位是数字，表示故障所属的子系统；以对动力系统为例（P开头的故障码），有以下的情况：
0：表示燃油和空气计量辅助排放控制整个系统；
1：表示燃油和空气计量系统；
2：表示燃油和空气计量系统（喷油器）；
3：表示点火系统；
4：表示废气控制系统；
5：表示巡航、怠速控制系统；
6：车载电脑和输出信号；
7：传动系统控制；
8：传动系统控制；
DTCLowByte则是描述故障种类和子类型，该部分内容遵循ISO 15031-6；对于不需要该字节信息的DTC，可填充为0x00。
2. 故障码的16进制表示
根据前面介绍的故障内码与5位标准故障码的对应关系，我们可以将标准故障码换算成其16进制的表示，便于我们在代码中的记录操作。
关于标准故障码换算为16进制表示，其实只需根据第一小节中介绍的故障内码与5位标准故障码的对应关系；将标准故障码的第一、第二位（如下例中的“U0”、“B1”）换算为对应的内码格式，再以16进制表示出来；至于后面的其他内容，其格式本来就是16进制进行表示的，直接照着写下来即可（其实只是将标准故障码的第一、二位进行转换即可了）。例如：
U007304，其故障内码为：1100 0000 0111 0011，换算成16进制则为C073；补充上DTCLowByte(04)，则其完整的16进制表示为0xC07304；
B100016，其故障内码为：1001 0000 0000 0000，换算成16进制则为9000；补充上DTCLowByte(16)，则其完整的16进制表示为0x900016；
3.DTCStatus状态位
从汽车ECU中读取储存的DTC(故障码)时，除了故障码本身，还可以读出很多其他的信息，包括优先级、发生次数计数器、发生时的里程和时间，以及本文中所讲的状态位（DTC status ）。
这个状态位包含1个byte，这里面的8个bit都有各自的含义，但是这8个 bit不一定都要使用，各个主机厂可以根据自己的需求使用其中的几个，当然也可以全部使用。下图是UDS对DTC status这8个bit的定义。
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。