【车载开发系列】UDS诊断---读取数据（$0x22）

【车载开发系列】UDS诊断—读取数据（$0x22）

一.概念定义

该服务的英文简称为ReadDataByIdentifier 。
根据ISO14119-1标准中所述，诊断服务22主要用于Client向Server(ECU)通过DID的方式读取相关的数据。这些数据可以输入输出的数字信号，模拟信号，内部数据以及其他的系统状态信息。作为诊断服务种的基础服务，可以简单理解为就是一个用于读取ECU数据的外部接口，可实时获取软件内部的相关的状态信息。概括起来就是诊断工具读取数据标识符对应的数据记录。

二.报文格式

0x22服务用于读did，客户端请求格式为 “22+did”，服务端肯定响应为“62+DID+数据”，否定响应为“7f+22+NRC码”
当客户端发送22+F186这个请求时，服务端肯定会返回当前的会话状态，
回复“62+F186+（01 or 02 or 03）”

1）请求

这里的MSB也是DID的值，在这里可以看到，读取数据服务$22是支持一条指令取得多个DID信息的。

2）肯定响应

这里的MSB也是DID的值，譬如：某协议定义了DID = 0xF190，那么这里的MSB就是0xF1和0x90；而此时Record就是服务端的VIN码

3）否定响应

否定响应SID+通过标识符读取数据请求SID+否定响应码

1. 如当尝试读取F190的DID值且当前车速条件不满足，此时Client发送诊断指令"22 F1 90"请求Server读取数据，Server将会回复“7F 22 22”来告诉请求者当前读取数据的条件不满足，请再次检查读取该DID的条件。
2. 当发送报文长度或者格式不对时，则Server会回复"7F 22 13"；
3. 当诊断请求的DID太多导致超出了传输层的限定时，则Server会回复”7F 22 14“；
4. 当诊断请求DID不存在或者在当前Session中不支持时，则Server就会回复“7F 22 31”；
5. 当Server在发生复位前处于security lock状态，那么此时Server则会回复"7F 22 33"

三.应用场景

1. 读取当前ECU的序列号，版本号等；
2. 标定成功后读取内部标定结果等；
3. 读取当前ECU所处在的Session，内部状态，Snapshot Data等；
4. 其他需要读取内部相关参数的场合；
5. 内部测试时需要取得相关测试用状态和数据的场合

四.注意事项

1. 特别需要注意的是22诊断并不存在Subfunction。
2. 不光存在单个DID的读取，还可以多个DID读取，而且读取DID的个数是不受到限制的。
3. 绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。
   因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

五.DID参数定义

逻辑上，参数数据标识符DID代表了一个对象或者是多个对象的集合。此参数可从服务器的内存中获取。如果数标识符经过了服务动态定义数据标识符的动态定义，则既存在于固定内存中，也能存储在随机存取存储器RAM当中。
一般来说，数据定义符能够在含0x22，0x2E和0x2F在内的多个诊断服务请求中使用，数据标识符还可以用于各种诊断服务的响应中。
例如在0x19服务的子功能readDTCSnapshotRecordByDTCNumber（按照DTC编号读取DTC快照）的肯定响应中。
动态定义的数据标识符除外，虽然ECU未定义此标识符，但客户端使用服务0x2C（动态定义数据标识）可对其进行定义。
重要
无论数据标识符用于哪个服务，在固定的ECU当中，该数据标识符始终应仅代表一个对象。即具有固定大小、意义等的固定对象。