本文主要是介绍[UDS] --- ReadDataByIdentifier 0x22，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 0x22功能描述
根据ISO14119-1标准中所述，诊断服务22主要用于Client向Server(ECU)通过DID的方式读取相关的数据。这些数据可以输入输出的数字信号，模拟信号，内部数据以及其他的系统状态信息。
2 0x22 应用场景
一般而言，对于22诊断服务，主要应用场景为以下场合：
读取当前ECU的序列号，版本号等；
标定成功后读取内部标定结果等；
读取当前ECU所处在的Session，内部状态，Snapshot Data等；
其他需要读取内部相关参数的场合；
上述这些应用场景较为常见，除此以外，当然还有很多面向ECU内部测试的应用场合，这里就不一一列举。
3 0x22服务请求
服务请求是Client发送给到Server的诊断服务指令。其中Client可以理解为Tester，Server可以理解为ECU节点。
3.1 请求格式
按照ISO14229-1标准所述，如下图1所示：
DID占2字节，取值范围为0x00-0xFF,根据ISO14229-1规范，定义了诸多只能用于特定场合的DID，也就意味着大家都不能随意乱用DID，在使用DID Number应充分考虑到14229的要求，防止出现跟客户扯皮的现象。
如下图所示简要列举了较为常见的DID种类及其含义：
4 请求和响应
4.1 Single DID Format请求与正响应
以读取单个DID F1 90 （VIN码）为例，其对应的诊断请求实例如下图所示：
特别需要注意的是22诊断并不存在Subfunction。
单DID(F1 90)请求示例所对应的正响应：
4.2 Multiple DID Format请求与正响应
既然存在单个DID读取，自然也就存在Multiple DID读取数据的操作，如下图5所示为同时读取多个DID(01 0A + 01 10)的22诊断服务请求实例：
当然多DID读取时表示的是超过一个DID以上的22诊断读取请求，因为个数不受限制。
谈到22服务的多DID读取，这边也可以拓展下Composite DID的使用，即通过读取一个DID便可以将map至该DID的多个DID一并读取出来，这样做的好处就是可以通过某一DID一次性获取其余已存在的DID的值，其软件实现也完全可通过配置来实现。
多DID(01 0A + 01 10)请求示例所对应的正响应：
4.3 0x22负响应
负响应的诊断格式：7F +SID + NRC。对于0x22支持的负响应如下表：
- 例如当尝试读取F190的DID值且当前车速条件不满足，此时Client发送诊断指令"22 F1 90"请求Server读取数据，Server将会回复“7F 22 22”来告诉请求者当前读取数据的条件不满足，请再次检查读取该DID的条件。
- 当发送报文长度或者格式不对时，则Server会回复"7F 22 13"；
- 当诊断请求的DID太多导致超出了传输层的限定时，则Server会回复”7F 22 14“；
- 当诊断请求DID不存在或者在当前Session中不支持时，则Server就会回复“7F 22 31”；
- 当Server在发生复位前处于security lock状态，那么此时Server则会回复"7F 22 33"；
这篇关于[UDS] --- ReadDataByIdentifier 0x22的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
![UDS报文-数据参数操作 [0x22] [0x2E]](/front/images/it_default2.jpg)
