UDS诊断ISO14229新手入门篇

前言：参考ISO-14229

UDS 诊断教程（一）

UDS 由 ISO-14229 系列标准定义，ISO 14229-1 定义了诊断服务，不涉及网络及实现，只有应用层的内容。而 ISO 14229-3 则定义了 UDS 在 CAN 总线上的实现。诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，

ECU 给出诊断响应（response），而 UDS 就是为不同的诊断功能的 request 和 response 定义了统一的内容和格式。

最近关于 UDS 的一系列专栏文章只关注应用层的诊断服务，忽略下层的通信机制。

Diagnostic request 的格式：

Diagnostic request 的格式可以分为两类：一类是拥有 sub-function 的，另一类是没有 sub-function 的，如下面两张图所示。Service ID(以下简称 SID)的长度固定为 1

个字节，代表了这条诊断命令执行的什么功能。sub-function 的长度也是 1 个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。

而后面的 parameter 则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。

parameter 的一个重要应用是作为标识符，标识诊断请求要读出的数据内容，我会在后续的文章里详细讲述各个诊断服务的应用。

拥有 sub-function 的诊断请求

无 sub-function 的诊断请求

有一点要补充的是，其实 sub-function 严格来说是 7 个 bit，而不是 1 个 byte，因为它的最高位 bit 被用于抑制正响应（suppress positive response,SPR），如果这个 bit 被置 1，则 ECU 不会给出正响应（positive response）；如果这个 bit 被置 0，则

ECU 会给出正响应。这样做的目的是可以告诉 ECU 不要发不必要的 response，从

而节约通信资源。

Diagnostic response 的格式：

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

positive response

positive response 的格式如上图所示，也基本上是由三部分组成，其中的 response SID 这个字节作为诊断请求的 echo，它等于 SID + 0X40。后面的两个部分则视具体的诊断服务而定。

negative response

negative response 的格式固定为 3 个字节，第一个字节为 0x7F，第二个字节是被拒绝掉的 SID，第三个字节是这个诊断服务无法被执行的原因。下面这张图列举了部分原因代码，比如，如果 ECU 给出 7F 22 13 这个 negative response，则说明 22 这个服务因为诊断请求数据长度不对的原因无法执行。

Negative Response Code

总结：诊断通信的过程就是诊断仪和 ECU 交换数据，前者发的是 request，后者发的是 response，而 UDS 最重要的作用就是定义了这些 request 和 response 的格式和内容。本文对 request 和 response 进行了简要介绍，在后面描述各种诊断服务的文章中我会通过更多的示例来说明这两个基本概念。

UDS 诊断教程（二）

UDS 定义的诊断服务从逻辑来说分为以下几类：

Diagnostic and Communication Management （诊断和通信管理）
Data Transmission （数据传输）
Stored Data Transmission （存储数据传输，用于操作 DTC）
InputOutput Control （IO 控制）
Routine Control （不知如何翻译好，作用是调用 ECU 内部的预置函数）
Upload Download （上传下载）

UDS 规定使用 1 个 byte 来表示诊断服务，即所谓的 Service ID,简称 SID。本文介绍一下

Diagnostic and Communication Management 这一类诊断服务中的一部分。

DiagnosticSessionControl (0x10)

DiagnosticSessionControl 诊断 request 的格式 DiagnosticSessionControl 这个服务的 SID 是 0x10，request 固定为 2 个 byte，第一个 byte 是 SID，第二个 byte 的低 7bit 是 sub-function，用于指示 ECU 将进入的 session。

UDS 定义的 session 包括：

0x00 ISOSAEReserved（保留）

0x01 defaultSession

0x02 ProgrammingSession

0x03 extendedDiagnosticSession

0x04 safetySystemDiagnosticSession

0x05 – 0x3F ISOSAEReserved（保留）

0x40 – 0x5F vehicleManufacturerSpecific（由整车厂自定义使用）

0x60 – 0x7E systemSupplierSpecific（由 ECU 供应商自定义使用）

0x7F ISOSAEReserved（保留）

DiagnosticSessionControl 用于控制 ECU 在不同的 session 之间进行转换，session 可以看作是 ECU 所处的一种软件状态，在不同的 session 中诊断服务执行的权限不同。 ECU 上电之后，默认处在 defaultSession 中，在这个 session 中很多诊断服务不可以执行，很多诊断相关的数据不能读取或写入。一般的诊断仪启动之后，会给 ECU 发送 10 03，即让 ECU 进入 extendedDiagnosticSession 中，在这个 session 中可执行的诊断服务就很多了。而如果要让 ECU 保持在 non-defaultSession 中，则需要诊断仪每隔固定的时间发送 0x3E 服务，ECU 才会知道诊断仪有和自己通信的需求，从而保持在 non-

defaultSession 中。另一个常用的 session 是 ProgrammingSession，在这个 session 中可以进行软件刷写的一系列诊断服务。0x40 – 0x5F 这个范围中的 session 由整车厂自定义使用，比如，某些诊断服务或诊断数据的操作需要在生产线上执行，即所谓的 End-OfLine，整车厂可以从这个范围中选择一个值来表示 EOL session；又或者在开发阶段需要某种“超级”session，则也可以从这里选一个值用来使 ECU 进入开发模式的 session。 DiagnosticSessionControl 这个服务非常简单，但是它却是 ECU 和诊断通信的第一条诊断命令。