（转载）详解汽车UDS诊断协议

一.概述

UDS（UnifiedDiagnostic Services，统一诊断服务,有时也称增强诊断）是ISO-14229定义的基于OSI模型中应用层的协议。其中，ISO 14229-1定义了诊断服务，但不涉及网络层及实现手段，只有应用层的内容，因此可在不同的汽车总线（如CAN, LIN, Flexray, Ethernet和K-line等）上实现。

结合ISO 15765-3和ISO 14229-1则实现了基于CAN总线的UDS汽车统一诊断服务。如下图所示：

ISO15765-4规定排放相关的诊断内容

OSI各层	汽车制造商的增强诊断	法规要求的排放相关诊断(OBD)
诊断应用	用户定义	ISO 15031-5
应用层	ISO 15765-3/ISO 14229-1	ISO 15031-5
表示层	无	无
会话层	ISO 15765-3	ISO 15765-4
传输层	无	无
网络层	ISO 15765-2	ISO 15765-4
数据链路层	ISO 11898-1	ISO 15765-4
物理层	用户定义	ISO 15765-4

UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。

诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能的request和response定义了统一的内容和格式。

二.诊断服务交互方式

UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），ECU反馈给诊断方信息（Response）。

Diagnostic Request的格式：

DiagnosticRequest的格式可以分为两类：

一类是拥有sub-function的；

一类是没有sub-function的；

Service ID(以下简称SID)的长度固定为1个字节，代表了这条诊断命令执行的什么功能。Sub-function的长度也是1个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。而后面的Parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。Parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容。

有一点要补充的是，其实Sub-function严格来说是7个bit，而不是1个byte，因为它的最高位bit被用于抑制正响应（Suppress Ppositive Response, SPR），如果这个bit被置1，则ECU不会给出正响应（PositiveResponse）；如果这个bit被置0，则ECU会给出正响应。这样做的目的是可以告诉ECU不要发不必要的Response，从而节约通信资源。

Diagnostic Response的格式：

Diagnosticresponse分为positive和negative两类。

positive response意味着诊断仪发过来的诊断请求被执行了，而negativeresponse则意味着ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negative response报文中的NRC中

Positive response肯定响应的格式是由三部分组成，其中的response SID这个字节作为诊断请求的echo，回复[SID+0x40]，例如请求10，响应50；请求22，响应62，回复的是一组数据。后面的两个字节分别为子功能及其他，视具体的诊断服务而定。

Negative response否定响应的格式固定为3个字节，回复[7F+SID+NRC]，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是NRC否定响应码。比如，若ECU给出7F22 13这个negative response，则说明SID=22这个服务因为诊断请求数据长度不对（NRC=13）的原因而无法执行。NRC否定响应码如下图所示：