UDS服务基础篇之22

UDS诊断服务基础篇之22
前言
22服务作为诊断服务种的基础服务，可以简单理解为就是一个用于读取ECU数据的外部接口，可实时获取软件内部的相关的状态信息。

鉴于本文是基础入门介绍，小T还是会问下大家有关22诊断服务的相关问题？

22服务的实际用途是什么？
22服务的应用场景有哪些呢？
22服务的诊断治疗格式如何？
这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

正文
服务功能
功能描述
根据ISO14119-1标准中所述，诊断服务22主要用于Client向Server(ECU)通过DID的方式读取相关的数据。这些数据可以输入输出的数字信号，模拟信号，内部数据以及其他的系统状态信息。

应用场景
一般而言，对于22诊断服务，主要应用场景为以下场合：

读取当前ECU的序列号，版本号等；
标定成功后读取内部标定结果等；
读取当前ECU所处在的Session，内部状态，Snapshot Data等；
其他需要读取内部相关参数的场合；
上述这些应用场景较为常见，除此以外，当然还有很多面向ECU内部测试的应用场合，这里就不一一列举。

服务请求
服务请求是Client发送给到Server的诊断服务指令。其中Client可以理解为Tester，Server可以理解为ECU节点。

请求格式
按照ISO14229-1标准所述，如下图1所示：

                                                  图1 22诊断服务请求格式
下图2中各参数解释如下：

                                                  图2 22请求格式说明
常见DID总结

根据ISO14229-1规范，定义了诸多只能用于特定场合的DID，也就意味着大家都不能随意乱用DID，在使用DID Number应充分考虑到14229的要求，防止出现跟客户扯皮的现象。

如下图3所示简要列举了较为常见的DID种类及其含义：

                                             图3 常见DID总结
请求实例
Single DID Format

以读取单个DID F1 90 （VIN码）为例，其对应的诊断请求实例如下图4所示：

                                              图4 22服务单DID诊断请求示例
特别需要注意的是22诊断并不存在Subfunction。

Multiple DID Format

既然存在单个DID读取，自然也就存在Multiple DID读取数据的操作，如下图5所示为同时读取多个DID(01 0A + 01 10)的22诊断服务请求实例：

                                                    图5 22服务多DID诊断请求示例
当然多DID读取时表示的是超过一个DID以上的22诊断读取请求，因为个数不受限制。

谈到22服务的多DID读取，这边也可以拓展下Composite DID的使用，即通过读取一个DID便可以将map至该DID的多个DID一并读取出来，这样做的好处就是可以通过某一DID一次性获取其余已存在的DID的值，其软件实现也完全可通过配置来实现。

服务响应
服务响应是针对Client对Server诊断请求的响应。

正响应格式
如下图6所示，为22诊断服务的正响应格式：

                                                图6 22诊断服务正响应格式
从上图中可以看出，22诊断服务的正响应由以下两个部分组成：

Response ID：该参数固定为SID+0x40 = 0x62；
DID：该参数表示某个数据的标识符，图中表示可以存在多个DID，具体DID的数目应与诊断请求的DID保持一致；
正响应实例
Single DID Format

如下图7所示，为上述单DID(F1 90)请求示例所对应的正响应：

                                                   图7 22诊断服务单DID正响应示例
Multiple DID Format

如下图8所示，为上述多DID(01 0A + 01 10)请求示例所对应的正响应：

                                               图8 22诊断服务多DID正响应示例
如上图可知，该多DID的诊断回复中存在多种两个DID的Number以及紧随其后的数据取值。

负响应NRC
NRC Code

绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。

因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于22服务而言支持的NRC如下图9所示：

                                                            图9 22服务NRC Code
例如当尝试读取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"；
NRC优先级

当诊断请求存在多种条件不满足的情况下，那么哪个NRC应当回复呢？毫无疑问此时就需要引入NRC优先级的概念，以下就是诊断服务22的NRC优先级，供君参考：

                                                   图10 22服务NRC优先级
NRC优先级

当诊断请求存在多种条件不满足的情况下，那么哪个NRC应当回复呢？毫无疑问此时就需要引入NRC优先级的概念，以下就是诊断服务22的NRC优先级，供君参考：

                                                          图10 22服务NRC优先级