大家好，欢迎来到IT知识分享网。

本文主要内容来自：https://zhuanlan.zhihu.com/p/37310388

简介

ISO 14229是汽车行业诊断通信协议，也称为UDS（Unified Diagnostic Service）统一诊断服务。是由ISO 14230-3和ISO 15765-3衍生而来。

ISO 14229规定了诊断工具与ECU的诊断协议，基于服务的。

from 恒润科技公开资料

UDS服务

UDS本质上是一些列服务的集合，包含6大类，26种。每种服务都有自己的ID，称为SID。

SID：Service Identifier，诊断服务ID。UDS本质是一种请求/应答（request/response）的交互协议：诊断仪（Tester）ECU发送请求，请求用SID标识，且SID处于该应用层数据的第一个byte。
如果积极应答（positive response），首字节回复[SID + 0x40]，如请求0x10（诊断会话控制），积极应答0x50；请求0x22，积极应答0x62。
如果消极应答（Negative Response），首字节回复0x7F，第二个字节回复刚才请求的SID，第三个字节是NRC（否定应答码），表示否定的依据。

寻址

UDS寻址分为两种模式：
1）物理寻址，即点对点、一对一，只能访问单个ECU节点，诊断CAN ID通常由车厂分配；
2）功能寻址，即广播、一对多，根据功能的不同进行访问，能访问多个ECU节点，对于标准帧来说，CNA ID是0x7DF。

UDS 26种服务

6大类，常用15种。粗略可分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制。

UDS请求命令4种构成方式：
1）SID
2）SID + SF（Sub-function）
3）SID + DID（Data Identifier）（读写用）
4）SID + SF + DID

具体可以查看对应服务说明。

NRC 消极应答

NRC：Negative Response Code（否定应答码）。如果ECU拒绝一个请求，做出消极应答，会在第三字节回复NRC。不同NRC有不同含义。

应答码定义列表：

特殊NRC：0x78，requestCorrectlyReceived-ResponsePending（RCRRP，请求已被正确接收-回复待定）。该NRC表示请求消息已被正确接收，请求消息中所有参数都是有效的，但要执行的操作还没完成，Server端还没准备好接收另一个请求。一旦请求的服务已经完成，服务器应该发送一个积极的响应或消极的响应，响应代码应与0x78不同。

当使用此NRC时，服务器（被测ECU）应始终发送最终响应（不论积极应答，还是消极应答），与suppress-PosRspMsgIndicationBit值（抑制肯定响应位）或NRCs（SNS 、SFNS、SNSIAS、SFNSIAS和ROOR）对功能寻址的处理请求的响应抑制要求无关。也就是说，什么情况下，功能寻址是不需要给出否定响应的呢？如果被测ECU需要回复上面5个NRC（SRC 0x11、SFNS 0x12、SNSIAS 0x7E、SFNSIAS 0x7F和ROOR 0x31）时，不需要回复否定响应。

$10诊断会话控制

$10包含3个子功能，对应3种诊断会话模式：
1）01: 标准诊断模式（默认）；
2）02: ECU编程会话模式；
3）03: ECU扩展诊断模式。

为什么设计3个会话模式？
因为权限。默认会话权限最小，可操作的服务少；扩展模式通常用于解锁高权限诊断服务，如写入数据/参数、读写诊断码；编程模式用于解锁bootloader相关诊断服务，即程序烧录。

如果进入一个非默认会话状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01（标准会话模式）。$3E服务，可以使得诊断保持在非默认状态。

下面是一张权限表格，描述了APP Code（应用程序代码）、Boot Code（引导程序代码）不同服务所需会话模式。

如果进入了一个非默认会话状态，一个定时器将会运转。如果一段时间内没有请求，那么到时间后，诊断退回到默认会话模式（01）。$3E服务可以使诊断保持在非默认状态。

$3E待机握手

$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能仍然保持激活状态。

// 服务器（ECU）接收
02 3E 00 55 55 55 55 55
// 服务器积极应答
02 7E 00 AA AA AA AA AA

$27安全访问

ECU中有很多数据是车厂独有的，不希望开放给所有人，需要做一个保密设定。我们在读取一些特殊数据时，要先进行安全解锁。ECU上电后，处于锁定状态（Locked），通过$27服务+子服务+钥匙，可以进行解锁。

解锁序列：

// Tester -> ECU
Request for Seed: 27 2n-1, n=1 // 2n-1是子服务
// ECU -> Tester
Seed: 67 2n-1
// Tester -> ECU
Send Key: 27 2n k1 // 2n是子服务
// ECU Compare Key k2 if (Key ke1 == Key k2) then unlock ECU
// ECU -> Tester
Unlocked: 67 2n

$22通过ID读数据

请求格式： 22 + DID（Data Identifier，通常2byte）
应答格式积极：62 + DID + Data

示例：

// 请求
03 22 F1 86 AA AA AA AA
// 应答
04 62 F1 86 01 AA AA AA

这里DID=F186，应答的Data=01。

DID有一部分被ISO 14229-1规定了，如0xF186表示当前诊断会话，0xF187表示车厂备件号，0xF188表示车厂ECU软件号，0xF189表示车厂ECU软件版本号。详见ISO 14229-1表C.1

$2E根据标识符写数据

与$22读数据服务相对，$2E用于写数据。
请求格式：2E + DID + Data
积极应答格式：6E + DID

写数据，通常需要权限，在APP下，需要进入扩展模式；Boot下，需要进入编程模式。

$19 读DTC

19服务是核心诊断服务，是UDS的重心。

DTC（diagnostic trouble code，故障码）：如果系统检测到一个错误，将其存储为DTC。DTC通常表现为：一个明显的故障；通讯信号丢失；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置、类型。DTC通常占用3byte，OBD II占用2byte。

故障码包括4大类，分别是PCBU：P代表powertrain动力系统，C代表Chassis底盘，B代表Body车身，U代表network通信系统。一个DTC信息占用4byte：3byte DTC + 1byte DTC状态。

DTC信息格式：

┌──────────────────────────────────────────────────────────────────────┐
│                           DTC information                            │
├──────────────────────────────────────────────────────┬───────────────┤
│                           DTC                        │               │
├─────────────────┬──────────────────┬─────────────────┤   DTCStatus   │
│  DTCHightByte   │  DTCMiddleByte   │   DTCLowByte    │               │
├─────────────────┼──────────────────┼─────────────────┼───────────────┤
│     byte1       │      byte2       │      byte3      │     byte4     │
└─────────────────┴──────────────────┴─────────────────┴───────────────┘

在乘用车中，byte1前两个bit，用00/01/10/11，分别表示P/C/B/U（动力/底盘/车身/网络）中的一个，之后6bit是数字，合在一起形如“C01”。

例如，故障码U0167，该OBD故障码适用于所有汽车制造商：

注：这是ISO15031中的故障码，与UDS中故障码在长度上有一定的不同

DTC状态位

下面是statusOfDTC（DTC状态）描述：

$19有28个子服务（sub-function），常用的有（参考ISO 14229-1-2013表269）：

• 01 读取与状态mask匹配的DTC数量（reportNumberOfDTCByStatusMask），后面参数是DTC状态掩码，例如01表示想读当前故障，08表示想读历史故障，09表示当前故障和历史故障都想读。

示例：

// 请求
19 01 09 // 读取当前故障和历史故障的数量
// 积极应答
59 01 09 01 00 01 // 09: 本ECU所支持的掩码; 01: DTC的格式(ISO14229-1为01); 00 01: 目前满足条件的DTC数量

• 02 读取与状态mask匹配的DTC列表及其状态（reportDTCByStatusMask），后面参数是DTC状态掩码，含义同子功能01。

每个故障码都会对应一个1byte的DTC status，该status与 DTCStatusMask进行按位与操作后，如果非0，证明匹配；如果为0，证明不匹配。因此，可能存在一个匹配的DTC列表及其状态。

示例：

// 请求
19 02 09
// 积极应答
59 02 09 XX XX XX 01 // XX XX XX: DTC, 由车厂定义; 01: 表示当前故障

• 03 检索DTCSnapshot记录标识（reportDTCSnapshotIdentification）

客户端可以通过该子功能服务，来检索所有捕获的DTCSnapshot记录的DTCSnapshot记录标识（ID）信息。服务器应返回所有存储的DTCSnapshot记录的DTCSnapshot记录ID信息列表。

单个DTCSnapshot记录 = DTCRecord（DTC编号（高，中，低字节））和DTCSnapshot记录号

如果为单个DTC存储多个DTCSnapshot记录，则服务器应在每次出现的响应中放置一个项目，每次使用不同的DTCSnapshot记录号（用于稍后检索记录数据）。

注：服务器可以为单个DTC存储多个DTCSnapshot记录，以跟踪每次DTC出现的情况，如电机短路故障，DTCSnapshot记录可以是电源电压值 + 负载电流。要支持的DTCSnapshot记录及其数量，应由系统供应商/车辆制造商定义。

DTCSnapshot记录标识信息应在客户端成功执行ClearDiagnosticInformation请求时清除。车辆制造商有责任在发生内存溢出（存储的DTC和DTCSnapshot数据在服务器中完全占用存储空间）时，指定删除存储的DTC和DTCSnapshot数据的规则。

• 04 读取快照信息（reportDTCSnapshotRecordByDTCNumber），也叫冻结帧

DTCSnapshot记录数据以及DTCSnapshot记录号（Number）由客户端定义。服务器收到请求后，搜索支持的DTC与客户指定的DTCMaskRecord（包含DTC编号（高，中，低字节））完全匹配。客户请求中提供的DTCSnapshotRecordNumber参数应指定一个特定的DTCSnapshot记录数据被请求的DTC的出现。

注意：DTCSnapshotRecordNumber不共享与DTCStoredDataRecordNumber相同地址空间。

如果服务器支持为单个DTC存储多个DTCSnapshot记录（支持此功能由系统供应商/车辆制造商定义），则建议服务器还实施reportDTCSnapshotIdentification子功能参数（子功能=03）。建议客户在通过reportDTCSnapshotRecordByDTCNumber请求特定的DTCSnapshotRecordNumber之前，首先请求使用子函数参数reportDTCSnapshotIdentification存储的DTCSnapshot记录的标识。

还建议支持子函数reportDTCSnapshotRecordIdentification，以便客户会直接识别存储的DTCSnapshot记录，而不是通过解析服务器的所有存储的DTC来确定是否存储DTCSnapshot记录。

系统供应商/车辆制造商有责任确定在此类服务器内捕获的DTCSnapshot记录，是否将与故障发生信息相关的数据存储为ECU文档的一部分。

如果客户端定义的DTCMaskRecord和DTCSnapshotRecordNumber参数（DTCSnapshotRecordNumber≠0xFF）已被识别出故障，则服务器将返回单个预定义的DTCSnapshotRecord以响应客户端的请求，以及DTC号和statusDTC。
请求消息：

思考：DTCSnapshot记录号与DTCSnapshotRecordNumber，有何不同？

思考：子功能03与04,有何区别？
03指定服务器将所有DTCSnapshot数据记录标识（DTC编号和DTCSnapshot记录编号）传送给客户端；而04 指定服务器将与客户端定义的DTC编号和DTCSnapshot记录编号（所有记录为0xFF）关联的DTSCnapshot记录传输到客户端。

06 读取扩展信息（reportDTCExtDataRecordByDTCNumber）。

0A 读取ECU支持的所有DTC列表及其状态（reportSupportedDTC）

检索服务器支持的所有DTC的状态。请求中应包含DTCStatusAvailabilityMask，提供DTC状态位掩码功能。服务器应向客户端发送支持的所有DTC和相应状态位列表。

$19服务几个常用的请求参数：

常用应答数据参数：

$14 清除DTC

清除（复位）DTC格式，可以改变DTC的状态。DTC状态中8bit，除bit4，bit6外，均会被清0。bit4表示自上次代码清除以来，DTC测试已完成（testNotCompletedSinceLastClear）；bit6表示DTC测试完成了这个操作周期（testNotCompletedThisOperationCycle）。

该服务包含一个参数groupOfDT，占3byte，指示DTC组（例如，动力总成，车身，底盘）或要清除的特定DTC。3个FF代表清除所有DTC状态位。

groupOfDTC定义如下：

$2F IO控制（InputOutputControlByIdentifier）

该服务通过DID（数据标识符）来进行输入信号的替换，和控制零部件负载输出。

请求消息格式：0x2F + 2byte DID（MSB + LSB）+ 1byte InputOutputControlParameter
如下表所示：

DID全称数据标识（dataIdentifier），部分由ISO规定，部分由车厂定义，可参考各家车厂提供的总线诊断规范；InputOutputControlParameter可以看做是IO控制类型，分为4类：
1）00 控制权还给ECU，returnControlToECU；
2）01 重置为默认值，resetToDefault；
3）02 冻结当前的状态，freezeCurrentState；
4）03 短暂接管控制权，shortTermAdjustment。

如果控制类型是00~02，则请求报文4byte；如果控制类型是03，则请求报文5byte，第5byte是控制代码，可以是数字量，如01：开，00：关；也可以是模拟量，如空调风门的开度。

6种模式的配置

非默认会话在实际应用中，分为编程会话（Programming Diagnostic session）和扩展会话（Extended Diagnostic session）。UDS实际应用中，需要对26种服务根据不同会话、寻址模式的支持度进行配置，共6种模式：
物理寻址+默认会话，物理寻址+编程会话、物理寻址+扩展会话、功能寻址+默认会话、功能寻址+编程会话、功能寻址+扩展会话。

至此，可以设计出一个26行、6列的表格（通常由车厂诊断设计规范提供）：

抑制肯定应答指示位的配置

抑制肯定应答指示位（Suppress Positive Response Message Indication Bit）顾名思义，用来抑制积极应答的。该配置指示对方静默，不需要肯定应答。该位的位置与子服务在同一byte（应用层数据第二字节），为bit7。

例如，SID=0x10，子服务0x01，如果抑制肯定应答，子服务对应字节改为0x81。这样，ECU收到该请求后，就不会回复肯定应答了。

UDS应用设备

最出名的是Vector的VN1630/1640+CANoe软件。Vector家产品特点：好用，节省开发时间，价格昂贵，不适用于小厂或大规模采购。

其他很多厂商如Kvaser、ZLG等能提供低成本、小体积、驱动简单、开放文档的设备，适用于UDS二次开发。

参考

UDS诊断入门
[Automotive Wiki ISO_14229]https://automotive.wiki/index.php/ISO_14229
画图