UDS 22服务
这个服务的目的就是读DID。那么什么是DID？DID通俗的来讲，其实就是某一存储在非易失性存储器（Non-volatile memory，NVM）里，表示汽车或者软件的一些标识的ID，最为大家熟知的比如汽车的VIN码，还有软件发布日期等等。
1. 服务请求报文定义
0x22服务请求报文格式：
注：服务请求报文可以请求一个或者多个DID。
本服务不支持Sub-function，关于DID命名规则可以参考ISO 14229 - 1。
2. 肯定响应
0x22服务肯定响应报文格式：
22诊断服务的肯定响应由以下两个部分组成：
Response ID：该参数固定为SID+0x40 = 0x62；
DID：该参数表示某个数据的标识符，图中表示可以存在多个DID，具体DID的数目应与诊断请求的DID保持一致。
3. 否定响应
绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。
因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。
其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于22服务而言支持的NRC如下图所示：
NRC 34：如果ECU支持29服务的认证，且被请求的DID需要认证后才能读取，那么需要检查请求之前是否已经通过认证；
NRC 33：如果ECU支持27服务的校验，且被请求的DID需要校验后才能读取，那么需要检查请求之前是否已经通过校验；
NRC 22：如果被请求的DID需要满足特定条件才能读取，那么需要检查当前是否满足读取的条件；
NRC 31：如果请求的DID至少有一个是支持的，那么正常响应这个DID的数据，否则给这个否定响应码；
NRC 14：如果请求的DID数据过长，ECU无法处理这么长的数据，那么给这个否定响应码；
NRC 13：如果请求的DID数据格式或长度不正确，ECU无法处理这个数据，那么给这个否定响应码。
4. 否定响应优先级
当诊断请求存在多种条件不满足的情况下，那么哪个NRC应当回复呢？毫无疑问此时就需要引入NRC优先级的概念，以下就是诊断服务22的NRC优先级：
5. 示例
1）读汽车VIN码
2）读多个DID，例如0xF190和0xF193
常见DID
| DID Number(Hex) | 含义 |
|---|---|
| 0100-A5FF，A800-ACFF，B000-B1FF，C000-C2FF，CF00-EFFF，F010-F0FF | 主机厂推荐使用DID范围 |
| F186 | 当前激活的Session |
| F18C | ECU序列号 |
| F190 | VIN 码 |
| F193 | 供应商硬件版本号 |
| F195 | 供应商软件版本号 |
| F19D | ECU安装日期 |
| F0D0-FEFF | 供应商推荐使用DID范围 |
总结
在上述22服务中，还涉及到Flash的读写擦除操作，有一些还有一定的Security等级要求。