0x14:ClearDiagnosticInformation
0x19:ReadDTCInformation
这两条服务用于操作存储在ECU中的DTC，使用频率很高，而且它们比较好地体现了“诊断”两个字的含义。
0x14:ClearDiagnosticInformation
这条诊断命令的格式比较简单，用法也很好理解，即删除存储在ECU中的DTC。
0x14诊断命令请求的格式第一个字节就是SID了，后边的三个字节用于标识将要被删除的DTC种类，UDS规定用FF FF FF表示所有种类的DTC，由厂家自定义代表Powertrain、Chassis、、Body、Network Communication等种类DTC的值。
比如，14 FF FF FF这条指令表示的就是删除掉ECU中的所有DTC。ECU只需要返回一个0x54表示成功执行即可。
0x19:ReadDTCInformation
这条指令用于读取存储在ECU中的DTC，它的格式如下
0x19诊断命令请求的格式0x14诊断命令请求的格式0x19服务的sub-function代表了各式各样读取DTC的方法，UDS给19服务的sub-function从0x00到0x19进行了明确定义，我只使用过其中4种，下面对我用过的这些进行介绍，如果大家对其他的感兴趣，可以查阅ISO 14229的定义。
sub-function = 0x01 （reportNumberOfDTCByStatusMask）
sub-function = 0x01用于读取符合特定条件的DTC数量，此时parameter为一个byte的Mask，用于与DTC的Status进行“与”运算，而ECU返回的则是"与"运算之后结果不为0的DTC的数量。DTC的Status用一个byte表示，其中的8个bit分别代表DTC的不同状态，比如，bit 0 表示这个DTC是active的还是passive的，bit 4表示这个DTC是否已经被confirm了，如果DTC的状态是confirm，则说明该DTC已经被ECU存储下来了。
比如：19 01 08这个命令的用途，就是读取所有状态为confirm的DTC的数量。
sub-function = 0x02 （reportDTCByStatusMask）
sub-function = 0x02用于读取符合特定条件的DTC列表，此时parameter仍然为一个byte的Mask，用于与DTC的Status进行“与”运算，而ECU返回的则是"与"运算之后结果不为0的DTC列表。
比如19 02 01这个命令的用途，就是读取所有状态为active的DTC的数量。此时ECU返回的格式应该是59 02 01 XX XX XX 01 YY YY YY 09......。返回的DTC列表中的每个条目为4个字节，前三个字节用于标识DTC，比如 XX XX XX，最后一个字节用于标识DTC状态，比如01，表示DTC是active的，09表示DTC是active且confirm的。
sub-function = 0x06 （reportDTCExtDataRecordByDTCNumber）
sub-function = 0x06用于读取某个DTC及其相关的环境数据，此时parameter为4个byte，前三个byte用于标识我们要读取的DTC，第四个byte用于标识要读取的环境数据的范围，UDS规定使用FF来表示读取所有的环境数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。
比如 19 06 XX XX XX FF就表示读取 XX XX XX这个DTC的所有环境数据，ECU的返回值应该是59 06 XX XX XX AA BB CC DD.....，其中AA BB CC DD...代表的就是XX XX XX这个DTC产生时所一起存储的环境数据。
sub-function = 0x0E（reportMostRecentConfirmedDTC）
sub-function = 0x0E时，不需要parameter。0x0E表示，要求ECU上报最近的一条被置为confirm的DTC。我在《统一诊断服务 (Unified diagnostic services ， UDS) （三）》一文中介绍过0x86服务，sub-function = 0x0E的19服务通常被作为参数传递给86指令，要求ECU在发生DTC存储的时候进行自动上报，即19 0E这两个字节的指令被嵌入到86服务的命令中。这条命令在开发阶段会用到，比如验证某个故障路径是否生效。
转载于 https://zhuanlan.zhihu.com/p/34425737
Service 19：通过Service 19相应的子服务来读取DTC或者关于DTC的其他参数信息（e.g. Snapshot、Extended Data）；
Service 14：通过Service 14清除DTC（当故障出现，达到阈值就会将对应DTC以及状态位存储在内存中），相当于擦除内存上的数据内容；
关于Service 14在清除DTC时，可以全部清除所有DTC，也可以清除在诊断需求规范中定义好的一组DTC。如下是UDS协议按照车身部位对DTC进行分组。
关于DTC状态位（每一个bit定义内容），UDS给出如下详细定义。在以前公众号文章中对于每一个bit触发条件、转换关系有说明（感兴趣可自行查阅）。
在Service 19中，使用DTC Status最常用的是0x 19 02（请求以及响应格式如下）：
如上图，在请求以及响应中所涉及的三种DTC状态位：
1) SM：请求时的DTC状态位，表示测试人员想要获取控制器中那些状态位被置1，在请求中将这个状态位置1，并发送；
2) SAM：在控制器诊断需求规范中，OEM会定义控制器支持那些状态位被置1；
3) Status：表示响应中DTC当前实际状态位。
在实际项目中，如下图表示SAM为0xFF（表示所有Status状态位都支持）：
项目中进行测试时，测试工程师按照所需发送请求。这里按照手头有一个小项目实际演练下：
背景信息：我使用诊断数据库编辑工具CANdelaStudio基于诊断需求规范编辑生成诊断数据库CDD文件，加载到CANoe中，使用接口卡连接ECU测试：
图中请求DTC状态位是0x 1B，响应中根据CANoe Trace：
分析：
响应59 02 FF，其中SAM为FF。
两个DTC以及当前实际状态位：
DTC Status
D0 00 87 50
D0 01 87 50
并且UDS协议对Aging Counter这个参数用图详细说明：
如图中，每一个DTC Status bit如何触发以及怎么样转换。对于其中两点说明下：
1、 标识2中，PendingDTC从1什么条件转0，协议中如下解释：
pendingDTC is set to zero after an operation cycle in which the test completed and did not fail.
2、 标识5中，ConfirmedDTC状态位从1跳转到0，涉及到一个线路老化（Aging Counter）概念。一般定义在ECU中，当故障出现并存储到内存中，若ECU进行了特定次数的Operation Cycle（e.g. 40次）切换，ECU存储的这个DTC就会被清除。Operation Cycle可以是车辆钥匙开关（Ignition）从On-Off-On，也可以是车载网络从休眠-唤醒-休眠。
个人经验分享：
在研发工程师做Aging Counter功能实现以及测试时，首先在代码做功能实现，在CANoe中用IG模块仿真车辆钥匙开关量，在编译环境下，将存储Aging Counter的寄存器标注出来，Debug运行。每一次开关量的切换，看Aging Counter存储器值是否增加+1.等到40，检测DTC是否清除。
转载于：https://zhuanlan.zhihu.com/p/181074986
/3 
