UDS诊断故障码及诊断服务介绍(14h, 19h, 85h)
1 诊断故障码日常生活中人总是免不了生病，人生病去医院，医生望闻问切找出病因，对症下压然后要到病除。同理汽车也可能“生病”，比如车载空调系统的电机被卡住，小电瓶没电了；这些故障都会影响到功能实现。人看病时，你要说出具体的症状，具体病因由医生判定，而车载诊断功能是车子自己判定自身故障原因，当维修人员或者开发人员通过诊断设备请求读取当前的故障时，ECU把当前所有故障告诉给诊断设备。开发时，会事先...
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 |
|---|---|---|
| EE | 04 | 68 |
DTC故障码高字节定义如下；中低字节表明具体故障对象跟类型。
小解：前面提及的故障码为U2E0468；，
U指的是通用/网络故障，DTC High bytes的第7位跟第6位是1，
bit5是1，bit4是0
把该故障码解析成16进制变为0xEE0468.
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数量(19 01)。
-检索与客户端定义的DTC状态掩码匹配的所以的DTC列表(19 02)。
-检索一个特定DTC对应的快照数据。
-检索一个特定DTC对应的扩展数据。
-检索一个服务器支持的所有DTC列表。
2.2.1 Sub_Func 检索与客户端定义掩码匹配的DTC的数量
该子服务请求服务器检索出客户端定义的掩码相匹配的DTC数量；
subfunc = 0x1: 请求报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务请求SID | 19h | |
| #2 | 子功能=0x01reportNumberOfDTCByStatusMask | 01h | |
| #3 | 诊断掩码字节 | 0x00~0xFF | 详细见chapter1.1 |
subfunc = 0x01: 肯定响应报文格式
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务响应SID | 59h | 19h+40h |
| #2 | 子功能=0x01reportNumberOfDTCByStatusMask | 01h | |
| #3 | 服务器支持的诊断掩码 | 0x00~0xFF | 诊断掩码有8个bit，对应8个特定状态，服务器实际支持的状态的集合视项目实际而定 |
| #4 | DTC格式标识符 | 0x00：ISO-15031指定格式 0x01: ISO 14229指定格式 0x03: J1939格式 | |
| #5~#6 | 匹配的DTC的数量 |
例程：
2.2.2 Sub_Fuc 检索与客户端定义的状态掩码匹配的DTC列表
该子服务请求服务器报告与请求客户端请求掩码对应的所有已检测到DTC。
子服务通过掩码报告DTC数量：服务器通过把客户端定义掩码的值与DTC诊断状态字节进行按位与操作，当(statusOfDTC & DTCStatusMask) != 0]时，则认为故障满足请求的状态。
当客户端发送的状态码某位服务器不支持，则处理时，仅考虑服务器支持的位。
代码中定义的DTC状态可用状态位标识定义如下：
如：客户端请求诊断状态掩码为 0x90（1001 0000），即是要求服务器返回当前故障码存在或者历史故障码存在的所有的DTC的列表。
subfunc = 0x2： 请求报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务请求SID | 19h | |
| #2 | 子功能=0x02reportDTCByStatusMask | 02h | |
| #3 | 诊断掩码字节 | 0x00~0xFF | 详细见chapter1.1 |
subfunc = 0x2： 肯定响应报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务响应SID | 59h | 19h+40h |
| #2 | 子功能=0x02reportDTCByStatusMask | 02h | |
| #3 | 服务器支持的诊断掩码 | 0x00~0xFF | 诊断掩码有8个bit，对应8个特定状态，服务器实际支持的状态的集合视项目实际而定 |
| #4~#7 | DTC_0 + status of DTC_0 | 3字节诊断故障码+ 当前故障码的状态字节 | |
| … | … | 3字节诊断故障码+ 当前故障码的状态字节 | |
| #n4+4~ n4+6 | DTC_N + status of DTC_N | 3字节诊断故障码+ 当前故障码的状态字节 |
例程：
2.2.4 快照数据处理
快照数据又称冻结帧，是与DTC相关联的特定数据记录，存储在服务器的内存中。
快照常用于储存故障发生时候的车辆状态信息及环境状态信息，如：
-当前点火时间
-行驶里程
-车辆模式
-车辆车速
-外界温度
通常一个DTC支持一个或者多个快照数据，每个快照数据用一个快照记录标识符表示(类似于DID)且每个快照包含一个或者一组指定的数据。
如：DTC 0xEE0468产生且有俩组快照数据，故障发生存储的具体数据如下：
快照数据_0: 快照记录标识符 = 0x00；{ 车速 = 50km/h， 模式 = 驾驶模式， 历程 = 5000km}
快照数据_1: 快照记录标识符 = 0x01；{ 外温= 35摄氏度}
***2.2.4.1 Sub_Func 3 检索快照的记录标识符 ***
Retrieving DTCSnapshot record identification
该子服务会请求服务器检索所有存在DTC的快照数据并返回所有的快照的标识符列。
如上例子：如果当前只有一个DTC(0xEE0468)存在且DTC 快照的记录标识符为0x00 跟 0x01，sub_func 0x3会返回的内容如下： 5904EE046800EE046801
请求服务报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务请求SID | 19h | |
| #2 | 子功能 =0x3， reportDTCSnapshotIdentification | 0x03 |
肯定响应报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务响应SID | 59h | 19h+40h |
| #2 | 子功能 =0x3， reportDTCSnapshotIdentification | 0x03 | |
| #3~#7 | DTC+DTCSnapshotRecordNumber#1 | ||
| … | |||
| #n-4~#n | DTC+DTCSnapshotRecordNumber#n |
2.2.4.2 Sub_Func 4 检索快照数据通过DTC码及快照记录标识符
检索快照的记录标识符子服务会检索出所有发生故障的快照记录标识符列表，本子服务可以根据检索快照的记录标识符返回的列表为输入参数，读取特定一个快照数据。
请求服务报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务请求SID | 19h | |
| #2 | 子功能 =0x4， reportDTCSnapshotRecordByDTCNumber | 0x04 | |
| #3~#5 | DTC码 | DTCHighByte+DTCMIDByte+DTCLowByte | |
| #6 | DTCSnapshotRecordNumber |
肯定响应报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务响应SID | 59h | 19h+40h |
| #2 | 子功能 =0x4， reportDTCSnapshotRecordByDTCNumber | 0x04 | |
| #3~#7 | DTC+DTCSnapshotRecordNumber#1 | ||
| #8~n | datas |
2.2.4 读取扩展数据
扩展数据是DTC相关的扩展状态信息数据。扩展数据常用于存储跟诊断故障相关的动态数据。
如：
- DTC 老化计数器的值
- 最近一次发生故障的时间
- 测试失败的次数
- DTC occurrence counter, counts number of driving cycles in which “testFailed” has been reported,
请求服务报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务请求SID | 19h | |
| #2 | 子功能 =0x6， reportDTCExtDataRecordByDTCNumber | 0x06 | |
| #3~#5 | DTC码 | DTCHighByte+DTCMIDByte+DTCLowByte | |
| #6 | DTCExtDataRecordNumber |
肯定响应报文格式：
| Bytes_Num | 参数名 | HEX值 | 描叙 |
|---|---|---|---|
| #1 | 读诊断信息服务响应SID | 59h | 19h+40h |
| #2 | 子功能 =0x6， reportDTCExtDataRecordByDTCNumber | 0x06 | |
| #3~#7 | DTC+DTCSnapshotRecordNumber#1 | ||
| #8~n | datas |
2.2.5 读取server支持的所有DTC
例程：
标题2.3 ControlDTCSetting (85h)/控制DTC设置服务(85h)
本服务允许上位机请求一个或一组服务器启用/停禁用DTC检测；
软件实现中；当应用模块检测到故障后，如果读DTC控制状态为OFF，将不会进行DTC状态掩码操作。
当执行ECU Rest(11hex)服务后，DTC控制状态默认到ON。
当执行ClearDTCInformation(14hex)服务后，85服务不应阻止服务器重置DTC内存信息。
Request Message
Postive Reponse Message
例程：
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
38
0- 0
已为社区贡献4条内容
所有评论(0)