UDS 22服务

最新推荐文章于 2026-04-12 09:41:20 发布

原创最新推荐文章于 2026-04-12 09:41:20 发布 · 1.8k 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#汽车

AUTOSAR 同时被 2 个专栏收录

94 篇文章

订阅专栏

UDS

9 篇文章

订阅专栏

本文详细介绍了UDS22服务中的服务请求报文、肯定响应与否定响应格式，包括NRC代码的含义，以及DID的使用和常见DID的含义。重点讨论了诊断服务的响应优先级和涉及的Flash操作及Security等级。

UDS 22服务

文章目录

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范围