UDS诊断系列之十五 通过DID读取数据（22）服务

通过DID读取数据服务，服务ID是0x22，主要功能是通过数据标识符（Data Identifier/DID）读取ECU存储的数据。

一、服务说明

先说什么是数据标识符（Data Identifier/DID，以下简称DID），它由两个字节组成，可以理解为一个编号，用来标识读取的是哪个数据。大部分OEM都会要求ECU内部存储一些数据或者一些运行时候的数据可以使用诊断仪或其他诊断设备读取，例如软硬件版本、序列号、某些传感器的实时数值、一些特殊配置状态等等，通过两个字节的标识符与对应的数据进行对应，这样就可以通过22服务加上对应的DID来读取相应的数据了。
为了规范使用，ISO14229-1规定了DID的使用范围，甚至定义了一些常用的DID所表示的内容，例如车辆VIN所使用的DID就是F190，任何车辆都要使用这个DID，具体范围可参考ISO14229-1的附录C.1。
通过22服务读取的数据格式，除固定格式以外，都由OEM和供应商约定。
通过22服务可以请求一个DID的数据，也可以请求多个，其数量限制也由OEM和供应商来约定。无论请求的DID数量是多少，只要满足数量限制，那么ECU都应该在一次肯定响应里包含所有数据，即使多个DID里面有重复的，响应的时候也要当成是两个单独的DID请求。

二、应用数据格式

1、请求报文

下表是22服务的请求格式，可以看到格式比较简单，第一个字节是服务标识22，后面每两个字节表示一个DID，通过cvt列也能看出至少要跟一个DID。

2、响应报文

响应报文格式稍复杂一些，第一个字节仍然是响应的SID，之后两个字节是被请求的DID，DID之后跟着对应的数据，长度根据实际的DID数据长度而定。如果请求了多个DID，那么后面的数据格式就是DID+DATA+DID+DATA…，这样一直循环下去，直到把所有的DID数据都响应完。

3、否定响应

下图是ISO14229-1里面给出的响应流程图。

首先应注意开始的两个NRC13所检查的内容是不一样的，第一次检查的是最小长度，即只读取一个DID的长度——SID+DID共3个字节，第二次检查的是最大长度——SID+DID*N，N即请求的DID个数是否满足要求，并且长度必须是奇数。
下面的循环主要检查的是请求的每个DID是否有安全或者其他条件限制：

• NRC34：如果ECU支持29服务的认证，且被请求的DID需要认证后才能读取，那么需要检查请求之前是否已经通过认证；
• NRC33：如果ECU支持27服务的校验，且被请求的DID需要校验后才能读取，那么需要检查请求之前是否已经通过校验；
• NRC22：如果被请求的DID需要满足特定条件才能读取，那么需要检查当前是否满足读取的条件；

后面的检查就比较好理解了：

• NRC31：如果请求的DID至少有一个是支持的，那么正常响应这个DID的数据，否则给这个否定响应码；
• NRC14：如果请求的DID数据过长，ECU无法处理这么长的数据，那么给这个否定响应码。