01

$22读服务

$22读服务通常在默认会话下即可执行，特殊情况下，某些信息做了读取保密设计，需要在扩展会话和安全控制下才能读取该DID（Data ID）信息。

DID长度通常为16进制2个字节，范围从0x00 00至0xFF FF，每个DID代表一条对应的消息，这样我们需要知道该信息的内容时，只需要使用$22+DID既可以获取该信息内容。如：我们用DID 0xF1 90标识车辆VIN，需要知道车辆VIN具体号码信息时，向ECU发送$22 F1 90进行信息查询，即可得到内容反馈。

之前我们一直在强调UDS诊断的自定义空间比较大，在极个别项目中，我们遇到过DID长度为3个字节的情况，我们需要以实际项目研发测试过程设计为准。

1.1 DID的分类

通过上面的描述我们可以理解，车辆上很多信息可以通过DID进行设计定义，通常主机厂根据信息属性不同将DID进行设计分类：

1）物流数据

物流数据中一般包含的是跟车辆和设备生产相关的固定信息。在生产过程中，零部件供应商不会一个批次完成所有零部件的生产和交付，这个过程一般是以月份或者季度为单位分批次执行，伴随着这个过程的通常还有主机产要求的VAVE等活动，因此同一个零部件也会因生产批次不同，对应的软硬件和配置信息有所不同。物流数据通常有：零部件硬件批次号、软件批次号、本设备的串号、部件号、出厂时间、制造时间、供应商硬件号、供应商软件号、ECU部件数量、ECU应用软件数量、ECU配置文件数量、车型信息、车辆VIN码等等。

2）内部属性数据

内部属性数据一般包含了ECU本身的软硬件配置相关信息，如：软件版本号、设备温度、ICCID号、IMEI号、GNSS天线状态、GNSS定位信息、NAD基本信息、NAD天线信息等等。

3）配置属性数据

配置属性数据顾名思义包含了ECU中需要进行配置的相关数据，这些数据一般情况下都可以做成模板进行复用，根据要求不一样进行模板选择，如：当前车辆的车型（同一型号的车具体有高中低等不同配置，具体到当前车辆可能发动机等配置都是有区别的）、移动通信运营商国家代码、运营商网络编码、APN拨号配置等。

4）Bitmapped I/O parameter DID和Non-Bitmapped I/O parameter DID

ECU通常会收到网络上其他设备发送的周期信号，这些信号通常可以在相应的网络上实时获取，也可以通过诊断读取，这类信号一般包含在Bitmapped和Non-Bitmapped属性数据中，区别是一个通常包含的是开关与否、报警与否的状态信号，另一个通常包含的对应的数值，如：机油过低报警状态、机油量、油量过低报警状态、当前油量等等。

1.2 $22服务请求报文

$22服务的请求报文格式总体与第三篇文档的描述一致。但是$22服务没有子功能，在服务ID后直接跟DID。发送报文帧结构如下图：

图 1

举例$22服务请求VIN码对应的DID，报文为：03 22 F1 90，当然根据项目实际情况车辆VIN可能是其他DID。

$22服务支持多个DID一次读取，报文格式如下图：

图 2

举例$22服务一次请求多个DID，$22 F1 80 F1 81。

1.3 $22服务响应报文

$22服务的响应报文格式总体与第三篇文档的描述一致。正响应报文的服务号为$62，第二、三字节对应请求报文的DID。从第四字节至最后为对应DID的实际数据。响应报文帧的结构图如下所示：

图 3

举例$22服务的响应报文通常为：

ECU：  10 14 62 F1 90 01 02 03

Tester：30 00（流控制帧）

ECU：  21 04 05 06 07 08 09 0A

ECU：  22 0B 0C 0D 0E 0F 10 11

$22服务一次读取多个DID的响应报文格式如下图：

图 4

$22服务一次读取多个DID的响应报文，如：

ECU：  10 0C 62 F1 80 01 02 03

Tester：30 00（流控制帧）

ECU：  21 04 F1 81 0A 0B 0C AA

$22服务的否定响应格式，可以参考第三篇文章服务响应总体中负响应部分介绍，所有UDS服务的负响应故障代码表在项目中均是通用的。

02

$2E写服务