19服务,即 ReadDTCInformation
(读取 DTC 信息)服务,允许客户端读取接受自任何车载服务器或服务器组的服务器常驻故障诊断码(DTC)信息。除非特殊子功能提出要求,服务器应返回所有 DTC 信息(如排放或非排放相关信息)。
归纳起来,诊断的request格式无非以下两种:
<SID> + <Sub-function> + <Parameter>
<SID> + <Parameter>
即有无sub-function的区别。Parameter可以是DID,可以是输入参数,可以是自定义的值,字节数视具体要求而定。
2、子功能参数定义(1字节数据)
由于 19 服务子功能较多,此处只介绍常用子功能,其他参考ISO14229-1 文档。
<SID + 0x40> + <Sub-function> + <Parameter>
<SID + 0x40> + <Parameter>
要注意,第一个字节是由SID和0x40的和构成。这里的Parameter项是optional的,具体要看协议规定。
检索与客户端定义 DTC 状态掩码相匹配的 DTC 的数量
请求:
肯定响应
示例
假设服务器共支持三个 DTC(为简单起见!),DTC码和状态分别为
检索与客户端定义 DTC 状态掩码相匹配的 DTC 列表
请求
肯定响应
示例
假设服务器共支持三个 DTC(为简单起见!),DTC码和状态分别为
获取DTC快照记录ID
诊断仪可以通过该子功能请求来检索所有捕获的 DTC快照记录的ID信息。服务器应返回所有已存储 DTC快照记录的 ID信息列表。服务器在响应消息中为单个 DTCSnapshot 记录放置的每个项目都应包含一个DTCRecord [包含 DTC number(high,middle,low字节)]和 DTCSnapshot record number。如果为单个 DTC 存储了多个DTCSnapshot 记录,则ECU应在每次响应时使用1个不同的DTCSnapshot record number(便于后续的查询)来表示。
ECU可支持对单个DTC存储多个DTCSnapshot records来跟踪每次DTC发生时的环境条件。DTCSnapshot records数量应被系统供应商或整车厂定义。
客户端成功发出 ClearDiagnosticInformation 请求后,应清除 DTCSnapshot 记录ID信息。 整车厂需要定义清楚删除已存储 DTC 和 DTCSnapshot 数据的规则以防内存溢出。
请求
肯定响应
示例
下述假定适用于:
是用于请求指定故障码(DTC)的快照信息
其中,DTCSnapshotRecordNumber
表示DTC快照记录码,占一个字节,表示特定的DTC快照数据记录编号。
例如当我们需要记录某个DTC第一次发生(假设用1表示)和最近一次发生的快照数据时(假设用2表示);那么当DTCSnapshotRecordNumber为1时,则表示请求该DTC第一次发生时的快照信息。
如果ECU支持多个DTC快照数据记录,那么该纪录码应使用Ox01~0xFE范围内的数值。当该参数值为0xFF时,要求ECU一次性报告所有存储的DTC快照数据记录。
肯定响应
示例
下述假定适用于:
读取与客户端定义 DTC 掩码和客户端定义 DTCExtendedData(DTC 扩展数据)记录编号匹配的DTCExtendedData ( DTC 扩 展 数 据 ) 记 录 数 据
除了前面04服务中介绍到的快照信息;一般还会再定义一个扩展信息,用于记录故障的一些其他信息,比如故障发生的次数、老化次数、已老化次数等。
请求
肯定请求
示例
下述假定适用于:
读取ECU支持的所有DTC列表及其状态
请求
肯定响应
示例
DTC 0x123456
, statusOfDTC(DTC 状态) 0x24
(0010 0100b)。DTC 0x234505
, statusOfDTC(DTC 状态) 0x00
(0000 0000b)。DTC 0xABCD01
, statusOfDTC(DTC 状态) 0x2F
(0010 1111b)。检索 DTC 内存中与客户端定义 DTC 掩码以及客户端定义 DTCExtendedData(DTC 扩展数据)记录编号匹配的用户定义内存 DTCExtendedData(DTC 扩展数据)记录数据
请求
肯定响应
示例
空
基本格式:
<0x7F> + <SID> + <NRC>
看起来比较简单,格式比较固定,只要是Negative Response,第一字节就是0x7F,第二字节照抄原来的SID,第三个字节是错误响应码,指示具体错误响应的原因