UDS汽车诊断标准协议（ISO 14229）

本篇记录了ISO 14229协议，即：UDS，同意诊断服务协议的基础知识，记录的很全面，耐心看完本篇可对UDS有清晰认知，学的都是一些常用到的诊断服务，看完本篇再之后即可开始着手开始用，在实际使用中边做边学。

文章共12,255字 · 阅读需要大约41分钟

一键AI生成摘要，助你高效阅读

问答

xiaoliu_niuniu

2620人浏览 · 2023-12-08 16:04:01

xiaoliu_niuniu · 2023-12-08 16:04:01 发布

1、前言

1、车辆诊断的目的

为能快速准确判断车辆或某控制器的故障及故障原因，为维修提供可靠依据。诊断服务常用于Tester（客户端）和ECU（服务器）间的会话控制、安全访问、例程控制、DTC读取，ECU软件刷写（软件下载）等。

2、ECU

ECU（Electronic Control Unit）电子控制器单元，又称汽车的“行车电脑”，它们的用途就是控制汽车的行驶状态及实现其各种功能。主要利用各种传感器、总线的数据采集与交换，来判断车辆状态及司机的意图并通过执行器来操控汽车。如下图为：博世16bit发动机控制器（机械节气门）。

现今ECU已经成为汽车上最为常见部件之一，依据功能的不同可分为不同类型。常见有如下几种ECU：

EMS（Engine Mangement System）发动机管理系统，应用在包括汽油机PFI（如上图）、GDI，柴油机，混合动力系统等，主要控制发动机的喷油、点火、扭矩分配等功能。
TCU（Transmision Control Unit）自动变速箱控制单元，常用于AMT、AT、DCT、CVT等自动变速器中，根据车辆的驾驶状态采用不同的档位策略。
BCM（Body Control Module）车身控制模块，主要控制车身电器，比如整车灯具、雨刮、洗涤、门锁、电动窗、天窗、电动后视镜、遥控等。
ESP（Electronic Stability Program）车身电子稳定控制系统。ESP可使车辆在各种状况下保持最佳的稳定性，在转向过度或转向不足的情形下效果更加明显。ESP是博世公司的专门叫法，日产的车辆行驶动力学调整系统VDC，丰田的车辆稳定控制系统VSC，宝马的动态稳定控制系统DSC等。现如今很多中高端合资车、国产车都会配备这个模块。
BMS（Battery Management System）电池管理系统，此控制器是专门针对配备有动力电池的电动车或者混合动力车准备的。主要功能就是为提高电池的利用率，防止电池出现过度充电和放电，延长电池的使用寿命，监控电池状态。
VCU（Vehicle Control Unit）整车控制器，用于混合动力/纯电动汽车动力系统的总成控制器，负责协调发动机、驱动电机、变速箱、动力电池等各部件的工作，提高新能源汽车的经济性、动力性、安全性并降低排放污染。

2、诊断的基本概念（概述）

1、诊断的三要素：

请求
肯定响应
否定响应

2、车辆诊断的Tester和ECU端：

客户端Tester为诊断请求的提供者，发送诊断请求；
某个ECU：诊断响应的提供者，发送诊断响应；
诊断报文：诊断报文是典型的事件触发型报文，有请求时才会响应。
本地客户端（Local Client）和本地服务器（Local Sever）：客户端连接到与服务器相同的本地网络，并且是与服务器相同的地址空间的一部分。
远程客户端（Remote Client）和远程服务器（Remote Sever）：Tester与ECU两者不在同一“网段”，通过远程地址来标识。

Tester端和ECU端以一问一答形式通信，因此Tester和ECU端都需遵循同样的诊断通信协议，协议中用途

描述一系列诊断服务
定义ECU与诊断仪之间的请求响应规则
ECU对于请求报文的处理行为以及请求、响应报文信息含义

常用诊断协议有ISO 14230，ISO 15031，还有ISO 14229也就是UDS协议，协议里面定义了诊断的请求，诊断响应的报文格式，ECU怎样处理诊断请求报文，以及诊断服务的应用。

UDS标准中除了定义服务的用法及服务的格式外，还定义了一些标准化的数据，OEM（OEM的字面意思是”原始设备制造“。）要使用UDS协议时，除了要用标准定义的服务及标准数据外，还要依据自身情况，定义属于OEM的特定数据，比如，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于后续ECU诊断功能的开发以及验证。

随着车辆ECU的增多，车辆网络拓扑结构也越来越复杂，比如一辆车要有多种总线（CAN总线，LIN，以太网，FlexRay），在2013年释放的UDS协议中，除了对通用诊断服务的定义外，还增加了关于UDS在各个总线中应用的定义。

3、UDS诊断通信支持的寻址方式

1、物理寻址（1：1）

Tester与ECU之间采用一对一的诊断通信方式

2、功能寻址（1：N）

Tester与ECU之间采用一对多的诊断通信方式，客户端向多个服务器发出同一功能寻址的诊断请求

3、地址及报文ID

源地址（SourceAddress，SA）：发送节点地址
目标地址（Target Address，TA）：接收节点地址

地址和报文ID相关：诊断报文ID=基地址+节点地址

以某ECU物理寻址为例，基地址为0X700，Tester节点地址为0X01，ECU节点地址为0X08，那么Tester对于发送此ECU的物理寻址请求ID为0X701，ECU的响应ID为0X708。功能寻址一般为特定ID，比如：0X7DF。为协议所规定。

3、诊断体系结构

1、诊断协议OSI七层结构模型

第一，二层分别定义了物理层和数据链路层；三，四层定义了网络层和传输层，第七层是应用层。

比如CAN总线：物理层和数据链路层遵循的是ISO 11898，它的传输层遵循的是ISO 15765-2，在ISO 14229-3中定义了UDS基于CAN总线的应用；以太网，它的物理层和数据链路层遵循的是ISO 13400-3，它的传输层也就是DoIP遵循的是ISO 13400-2, 它的UDS基于以太网的应用是ISO 14229-5。

以CAN通讯举例：

应用层诊断服务数据<——>CAN数据帧
诊断的数据有的大于CAN数据帧，网络层进行数据的打包和拆包，协调上下层的工作
网络层还可以对等实体间的通信，数据同步，时间管理，错误处理

2、诊断的通信流程U型图

应用层服务（通常被称为诊断服务）：应用层服务用于基于客户端-服务器的系统。以执行诸如车载服务器的测试，检查，监视或诊断之类的功能。
客户端（通常称外部测试设备）：使用应用层服务来请求在一个或者多个服务器中执行诊断功能。
服务器（通常是作为ECU一部分的功能）：使用应用层服务将请求的诊断服务提供的响应数据发送回客户端。

诊断通信的框架：对等实体间通信
每一层的目的是为上面的层提供服务
应用层为诊断应用程序提供服务
每一层提供的服务可在该层的服务访问点（SAP）获得
以软件、硬件或者软硬件任何组合实现的每层的活动部分称为实体
在OSI模型中，通信发生在不同节点中的同一层的实体之间，同一层的这种通信实体称为对等实体。

UDS实现了模块化诊断，上层测试仪（Tester）只要发送同样的命令就可以得到ECU的数据，并不需要关心底层的数据链路层和物理层的具体实现方式（T-PDU接口）。成功实现软硬件分别开发。

T_PDU：作为统一诊断服务PDU和任何通信协议（如：CAN,LIN等）之间的接口。

3、协议数据单元PDU

协议数据单元（PDU，Protocol Data Unit）：是一组信息和数据的集合，表示了发送方和接收方对等实体之间传递的信息和数据，主要由：协议控制信息（PCI）和数据（Data）组成。每一层都有自己的PDU（L_PDU、N_PDU、T_PDU、S_PDU、A_PDU）如下图：

4、服务原语

1、什么是服务原语

除诊断服务外，ISO-14229-1中还描述了调用这些诊断服务的函数接口，即：将具体诊断服务的实现封装在一个个API中，做协议实现的公司负责实现具体的API，使用这些协议的只需要调用这些API即可。为使API的调用更简洁，UDS中规定了6种通信原语（primitive），每个诊断服务的实现都包括了这6种原语，且原语的格式都一致，所以对调用者来说比较简单。原语，也就是API的实现在UDS协议栈的应用层中，用户自己编写的软件调用这些API来实现通信。

诊断应用程序层的服务访问点提供了许多具有相同通用结构的服务。对于每个服务，指定6个服务原语：

服务请求原语（Service Request Primitive）：client的用户软件调用此原语进行诊断请求的发送。
服务请求确认原语（Service Request -Confirmation Primitive）：client的应用层软件使用此原语通知client的用户软件诊断请求已经发送到总线上。
服务指示原语（Service Indication Primitive）：server的应用层软件使用这个原语通知server的用户软件有诊断请求到达。
服务响应原语（Service Response Primitive）server的用户软件调用这个原语进行诊断响应的发送。
服务响应确认原语（Service Response-Confirmation Primitive）：server的应用层软件使用这个原语通知server的用户软件诊断响应已经发送到总线上。
服务确认原语（Service Confirmation Primitive）：client的应用层软件使用这个原语通知client的用户软件有诊断响应到达。

诊断应用程序和应用层之间的交互即为信息在服务用户（诊断应用程序）和服务提供者（应用层）之间通过原语传递，服务原语可传参数。如下图为UDS诊断响应确认的服务流程：红色框里面前3个与诊断请求相关，蓝色框后3个与诊断响应相关。

2、服务原语的格式

//service_name是诊断服务的名称（如：DiagnosticSessionControl）
service_name.type(    //type表示服务原语的类型（例如：请求）
                    parameter A,    //是A_SDU，作为服务原语传递的值列表（寻址信息）
                    parameter B,    //parameter A，B，C是必须包含在所有服务调用中的必需参数
                    parameter C
                    [,parameter1,...]    //[]此为取决于特定服务的参数
                 )

六种服务原语的具体格式如下：

service_name.request (
service_name.indication      A_MType,     //枚举类型，应用层消息类型（本地诊断/远程诊断）
service_name.response        A_SA,        //应用层源地址
service_name.confirm         A_TA,        //应用层目标地址
                             A_TA_type,   //应用层目标地址类型（物理寻址/功能寻址）
                             [A_AE],      //应用层远程地址
                             A_Length,
                             A_Data       //由更高层实体交换的所有数据
                             [,parameter1,...],
                     )

service_name.req_confirm(
service_name.rsp_confirm    A_MType,     //应用层消息类型（本地诊断/远程诊断）
                            A_SA,        //应用层源地址
                            A_TA,        //应用层目标地址
                            A_TA_type,   //应用层目标地址类型（物理寻址/功能寻址）
                            [A_AE],      //应用层远程地址
                            A_Result     //来指示消息是否已正确传输或传输不成功
                        )

发送方诊断应用程序种带有的：SA-源地址，TA-目的地址，TAtype，parameter参数。然后通过服务原语传递SA，TA，TAtype.....这些寻址信息还有服务器的一些parameter参数给到发送方对等实体，在应用层提取服务原语里面的参数组成A_PDU发送给接收方对等实体。然后接收方诊断应用程序中的SA，TA，TAtype，parameter参数等的信息后传递给接收方上层，上层再提取服务原语里面的参数以及协议里面的一些控制信息添加A_PCI之后，再把信息发给对等实体，再之后：对等实体间传送，发送方上层接收对等实体传递的信息这一整套流程。

5、A_PDU：应用层协议数据单元。

A_PDU格式：

A_PDU=A_PCI+A_SDU，A_PCI：应用层协议控制信息

“Mtype，SA，TA，TA_type，RA，Length”为应用层地址信息，(A_AI)与A_SDU中使用的参数相同

“A_Data”是为每个单独的应用层服务定义的字节数据字符串（如：CAN，LIN等），A_Data字符串以A_PCI开头，后跟A_SDU中为每个服务指定的所有服务特定参数

“Length”确定A_Data的字节数

1、A_PCI

两种格式如下：根据A_PCI参数的第一个字节是否为0x7F区分

A_PCI(SI)：服务标识符SI,也称之为SID。0x00~0xFF，一个字节无符号整数。（适用于请求服务和肯定响应）
A_PCI(NR_SI,SI)：否定响应服务标识符NR_SI。（适用于否定响应）

1、服务标识符（SID）

ISO 14229-1中一共定义了26种SID（UDS诊断服务分为6大类，26个服务），如下表格：

诊断和通信管理功能单元，如：DiagnosticSessionControl（0x10）,SecurityAccess（0x27）
数据传输功能单元，如：ReadDataByIdentifier（0x22）,WriteDataByIdentifier（0x2E）
存储数据传输功能单元，如：ReadDTCInformation（0x19）,ClearDiagnosticInformation（0x14）
输入/输出控制功能单元，如：InputOutputControlByIdentifier（0x2F）
例程功能单元，如：RoutioneControl（0x31）
上传/下载功能单元，如：RequestDownload（0x34），TransferData（0x36）

2、Tester和ECU的诊断通信交互过程

Tester发送诊断请求服务，ECU回复诊断响应数据。诊断请求服务可以是：诊断通信管理请求、数据请求、故障代码请求、输入/输出控制、安全访问和重新编程请求（如：Reflash）等。ECU收到请求后进行处理，若符合某设定条件：如计算出某特定结果，则回复肯定响应，否则回复否定响应。

请求服务标识符（SID）：请求服务的SID：（X0XX XXXX），SID的第6位为0。
肯定响应服务标识符（SID）：肯定响应服务的SID：（X1XX XXXX）SID的第6位为1。可理解为：肯定响应服务的SID=请求服务的SID+0x40。比如：ReadDTCInformation（0x19）服务响应的SID为（0101 1001=0x59），肯定响应后面跟的就是数据。
否定响应服务标识符（NR_SID）：ECU方处理未符合条件，回复否定响应。否定响应格式为：0x7F开头，后面跟着否定响应消息对应的服务请求的SID以及一个否定响应代码NRC，NRC指示诊断服务失败或者无法及时完成的原因。

3、NRC

NRC(0x00-0xFF) 分为三个范围：

0x00：服务器内部实现的positiveResponse参数值
0x01~0x7F：与通信相关的否定响应代码
0x80-0xFF：在服务器接收请求的时间点上不正确的特定条件的否定响应代码

常见NRC如下表（不全，其余的可去网上搜索）：

4、UDS诊断服务支持的形式

某些UDS诊断服务只有SID（如：0x3E）

大多数UDS诊断服务支持SID后跟子功能（SF）

一些UDS诊断服务支持数据标识符（DID），常见如下：SID+DID，响应（SID+0x40）+DID

其他：RID：例程标识符，比如：SID+子功能+RID

2、UDS的服务描述约定

1、A_PDU的参数约定

每个诊断服务的A_PDU的格式：对于给定的A_PDU的request/indication和response/confirmation ，每个参数都会有一个convention（Cvt）值来描述，下表定义了A_PDU字段参数约定：

Mandatory（M）：该参数必须存在于A_PDU中
Conditional（C）：该参数可以基于某些条件（例如A_PDU中的子函数/参数）存在于A_PDU中
Selection（S）：表示该参数是必需的（除非另有指定），并且是从参数列表中选择的参数
Use option（U）：该参数可能存在，也可能不存在，具体取决于用户的动态使用情况
NOTE：标记为“M”（强制）的<服务名称>请求 SID”并不意味着此服务必须得到服务器的支持。“M”仅表示在服务器支持该服务的情况下，请求A_PDU中必须存在此参数。

2、Request message（请求消息）

根据A_DATA.Parameter1（第一个参数）是必须的参数选择S或者是用户定义的一个U分为下面两种情况：

1.带有子功能的请求A_PDU

2.没有子功能的请求A_PDU

3、子功能/子函数/子服务

请求消息子功能参数定义

bit7：一个位的抑制肯定响应消息指示位 SPRMIB：

0 - FALSE，表示不抑制肯定响应消息（需要肯定响应消息）
1 - TRUE，表示抑制肯定响应消息（被寻址的服务器不应发送肯定响应消息）

bit6~0：子功能参数值位，范围：0x00~0x7F（0~127）

若某诊断服务本身支持SPRMIB，但没有子功能参数值表，它也要因为SPRMIB而必须填充SF（子功能）这个字节，此时的SF为0x00=0000 0000或0x80=1000 0000，例如TesterPresent服务（0x3E00或者0x3E80）。

支持子功能参数值的服务应支持子功能参数值表中定义的子功能参数值。不同的ECU有其对应的不同的子功能参数值表。

3、响应的A_PDU

1、肯定响应的A_PDU的格式：

2、否定响应A_PDU的格式

3、消息流示例

请求消息流

肯定响应消息流

否定响应消息流

6、诊断服务

1、诊断和通信管理

诊断会话控制（0x10）

1、什么是诊断会话

诊断会话控制（Diagnostic Session Control, SID 0x10）用于使能服务器（ECU）的诊断会话。诊断会话关联了一系列诊断服务或诊断功能。只有当前激活的诊断会话支持的诊断服务才能被响应。ECU通常有两个以上的诊断会话，包括一个默认会话和若干非默认会话。非默认会话由用户自定义。不同诊断会话具有：不同的功能，不同的定时参数，受到不同的安全访问保护。典型的ECU诊断会话定义如下：

同一时刻只有一个诊断会话处于激活状态。此时ECU可响应该诊断会话关联的诊断服务。若Tester请求了当前诊断会话下不支持的诊断服务，则服务器ECU需给出NRC为0x7F的否定响应。激活新的诊断会话会关闭上一个诊断会话。

2、不同诊断会话下允许的诊断服务

通常在默认会话（Default Session）下，允许如下诊断服务：

0x10 诊断会话控制 DiagnosticSessionControl
0x11 ECU复位 ECUReset
0x14 清除诊断信息（清除DTC） ClearDiagnosticInformation
0x19 读取诊断故障码信息 ReadDTCInformation

非默认会话下支持的诊断服务由用户自定义。

通常编程会话（Programming Session）下支持的诊断服务如下：

0x10 诊断会话控制 DiagnosticSessionControl
0x11 ECU复位 ECUReset
0x27 安全访问 SecurityAccess
0x31 例程控制 RoutineControl
0x34 请求下载 RequestDownload
0x36 数据传输 TransferData
0x37 请求结束传输 RequestTransferExit
0x3E 测试设备在线 TesterPresent

3、诊断会话控制请求消息的格式

诊断会话控制（Diagnostic Session Control, SID 0x10）请求报文定义如下:

A_Data byte	参数名称 Parameter Name	参数取值 Byte Value
#1	诊断会话控制服务请求SID DiagnosticSessionControl Request SID	0x10
#2	诊断会话类型 DiagnosticSessionType	0x00-0xFF

格式：0x10 xx，A_Data_byte #1：为该服务的请求SID，值为0x10。
A_Data_byte #2：为诊断会话类型（Diagnostic SessionType），即请求激活的诊断会话。诊断会话类型仅占A_Data_byte #2的bit 0~6。Bit 7为肯定响应抑制位。子功能参数 0x10 xx 取值如下：

0x00 ISO/SAE预留 ISOSAEReserved
0x01 默认会话 Default Session
0x02 编程会话 Programming Session
0x03 扩展会话 Externded Session
0x04 安全系统诊断会话 Safety System Diagnostic Session
0x05 - 0x3F ISO/SAE预留 ISOSAEReserved
0x40 - 0x5F 整车厂定义 Vehicle Manufacturer Specific
0x60 - 0x7F 零部件供应商定义 System Supplier Specific
0x7F ISO/SAE预留 ISOSAEReserved

4、ECU响应消息的格式

肯定响应：如成功进入请求的诊断会话，则服务器给出如下的肯定响应。

#1 诊断会话控制服务肯定响应SID DiagnosticSessionControl Response SID 0x50
#2 诊断会话类型 DiagnosticSessionType 0x00-0xFF
#3 P2Server_max高字节 0x00-0xFF
#4 P2Server_max低字节 0x00-0xFF
#5 P2*Server_max高字节 0x00-0xFF
#6 P2*Server_max低字节 0x00-0xFF

格式如下：

A_Data_byte #1为诊断会话控制服务响应SID，值为0x50。（0x10+0x40）
A_Data_byte #2为请求的诊断会话类型，与诊断请求中的SF参数相同。
A_Databyte #3 ~ #6为被激活的诊断会话参数。

否定响应

如不能激活请求的诊断会话，则给出格式如下的否定响应。

#1 否定响应SID Negative Response SID 0x7F
#2 诊断会话控制服务请求SID DiagnosticSessionControl Request SID 0x10
#3 否定响应码 Negative Response Code 取值见下文

诊断会话控制服务支持如下的否定响应码

0x12 服务器不支持请求的诊断会话类型参数时，回复此NRC。
0x13 诊断请求报文中的数据长度不等于2时，回复此NRC。
0x22 请求的诊断会话激活条件不满足时，回复此NRC。

5、诊断会话间的切换

上图中：只有ECU发送肯定响应报文后，即：会话层使用S_Data.confirm向应用层确认S_Result=S_OK，ECU才会进入Tester所请求的诊断会话模式，否则当前诊断会话模式不变。

6、诊断会话的时间参数

文章最后有UDS的所有时间参数总结，这部分可以对比着后面看。

ECU上电后首先进入默认会话。若没有收到诊断会话控制服务（0x10）激活新会话，将一直处于默认会话（这是一种安全状态）。非默认会话（不安全状态）。

非默认会话下，若服务器（ECU）在 $S3_{Sever}$ 时间内未收到任何诊断服务，将会退回到默认会话。此情况被称为诊断会话超时。通常在客户端没有诊断服务请求但又希望服务器（ECU）维持非默认会话时，需定期发送诊断仪在线服务（Tester Present, SID 0x3E），避免服务器（ECU）发生诊断会话超时，告诉ECU：我Tester还在线，不要断开诊断会话。两次发送诊断仪在线服务（Tester Present, SID 0x3E）的间隔时间由 $S3_{Client}$ 来规定。

安全访问（0x27）

并不希望ECU所有的数据被Tester读取或写入，此时Tester就需对ECU进行安全访问。ECU在上电或复位之后会处于一个锁定状态，即所谓的默认会话。Tester想要读取ECU的数据，就需要通过密钥来解锁ECU的安全模式。Tester想执行受保护的服务，需要解锁ECU的安全模式，如：

WriteDataByIdentifier（0x2E）服务（写入VIN）
InputOutputControlByIdentifier（0x2F）服务
RequestDownload（0x34）服务（ECU刷写）

1、安全访问的四个步骤：

Tester向ECU发送0x27服务，请求种子（Seed），2n-1为ECU解锁的安全等级
ECU接收到请求种子后，向Tester发送Seed（一般为随机数）
Tester接收到种子，根据安全运算 f( ) 计算得到一个密钥Key1=f(Seed)，将密钥Key1发送给ECU
ECU根据自己的安全算法，结合自己的本地种子Seed，计算出ECU端的一个密钥Key2，若Tester端的Key1等于ECU端的Key2，则ECU进行解锁。若不等，Tester暴力访问ECU时候会被延时。

注：若在收到请求种子消息时，ECU已解锁，则ECU应回复包含种子值为0的肯定响应消息。Seed的字节长度可以由OEM指定，可设置为2个字节，3个字节等等。

2、安全状态处理

若ECU支持多个安全等级，Tester可以发送0x27服务在各个安全等级之间切换，但是在任意时刻都只能激活一个安全等级。

3、安全访问的请求格式

SID为0x27，后面跟的子功能SF为奇数表示请求种子，子功能为偶数表示发送密钥。

肯定响应格式：0x27+0x40=0x67，后面跟子功能SF值，再后面：若为Tester发送的请求种子，则肯定响应这部分加上随机产生的种子值，若Tester发送的密钥，ECU的肯定响应这部分就没有了。

支持的否定响应代码：

通信控制（0x28）

作用：打开/关闭服务器的某些消息的发送/接收（如：正常应用程序通信消息、网络管理通信消息），一般用于降低总线的负载率。

#3：communicationType，表示启用或者禁用接收/发送消息

#2的值可以是如下表：

肯定响应格式与上面的诊断会话和安全访问类似：0x28+0x40=0x68后面跟SF。

通信控制（0x28）服务示例：ECU刷写

Tester为降低刷写过程中ECU的通信负载率，会禁用所有非诊断消息的传输，包括网络管理通话消息和正常通话消息。Tester发送0x28 03 03，禁止ECU的网络管理通话报文和应用程序报文。

通信控制（0x3E）

作用：周期性向服务器（或多个服务器）指示Tester仍然连接到服务器，且先前已激活的某些诊断服务/通信将保持活动。——保持诊断会话

Tester发送0x3E 00，ECU回复0x7E 00，支持的否定响应NRC代码：0x12，0x13。

常用于：刷写前使用0x28(CommunicationControl)服务对某些ECU禁言

诊断设置（0x85）

用于停止或恢复单个服务器或者一组服务器中DTC状态位的更新，子功能参数如下表：

肯定响应消息：0x85+0x40=0xC5，后跟一个DTCSettingType，该参数是来自请求消息的子功能参数的位6~0的回应。支持的否定响应代码：0x12，0x13，0x22，0x31。

常用于：刷写前使用0x85(ControlDTCSetting)服务关闭ECU故障检查功能。

其他控制服务

ECUReset（0x11）：请求ECU执行复位
AccessTimingParameter（0x83）：在通信链路活动期间读取和更改通信链路的默认时序（timing）参数
SecuredDataTransmission（0x84）：传输受第三方攻击保护的数据，可能会危及数据安全
ResponseOnEvent（0x86）：请求服务器启动或停止对指定事件的响应传输
LinkControl（0x87）：控制客户端与服务器间通信，以便获得用于诊断目的的总线带宽

2、数据传输功能

根据DID读取数据（0x22）

根据DID读取数据（如：模拟/数字输入和输出信号、内部数据和系统状态信息。）

请求消息以及ECU响应消息格式如下：

0x22的请求响应消息可以包含一个或多个双字节DID值。

支持的否定响应代码：0x13，0x14，0x22，0x31，0x33

读取多个DID示例

DID=0x010A包含发动机冷却液的温度，节气门位置，发动机转速，歧管的绝对压力，质量空气流量，车速传感器，气压，计算负载值，加速踏板位置。

DID=0x0110包含电池的正电压

根据DID写入数据（0x2E）

注：服务器可能限制或禁止对某些DataIdentifier值的写访问。

请求消息以及ECU响应消息格式如下：

0x2E支持的否定响应代码：0x13，0x22，0x31，0x33，0x72

示例：通过DID=0xF190写入VIN编号

3、存储数据传输功能

诊断的最初目的为了发现ECU上的故障，我们这里说的故障（fault）分为：肉眼可观察到的故障（如仪表盘上的警报灯），不可观察的故障（如通信故障），合法的故障。我们使用UDS对整车进行诊断测试就是想要找出：ECU的故障位置和故障类型。若检测到故障，就会通过诊断故障代码（DTC）进行存储。

DTC信息由三个字节的DTC信息和一个字节的DTC状态组成，如下表：

DTC常见格式

DTC第四个字节的状态位

描述DTC状态：发生故障（“测试失败...”），确认故障（“已确认”），.....

DTC处理

读取DTC信息（0x19）

一共有28种子功能，常用到的有4种如下：

根据状态掩码读取DTC的（0x19 02）服务

读取服务器所有支持的DTC的（0x19 0A）服务

注：SM—StatusMask—状态掩码，SAM—StatusAvailabilityMask—状态可用掩码

假设服务器总共支持3个DTC：

DTC 0x123456，statusOfDTC=0x24（0010 0100）
DTC 0x234505，statusOfDTC=0x00（0010 0000）
DTC 0xABCD01，statusOfDTC=0x2F（0010 11121）

通过0x19 0A发送请求以及得到的肯定响应格式如下表：

清除DTC信息（0x14）

请求以及响应的格式

3个字节“DTC组（groupOfDTC）”是用于选择DTC子组的掩码，允许客户端（Tester）清除一组DTC或特定DTC。

groupOfDTC=0xFF FF FF表示一次性清除所有DTC

常用于：使用0x14(ClearDiagnosticInformation)服务清除多个ECU DTC等。

4、输入/输出控制功能

输入输出控制（0x2F）

该服务是用于Tester请求ECU去对相关输入/输出信号进行控制。所谓输入/输出控制简而言之就是屏蔽实际的输入输出信号值，取而代之的是Tester主动以某种特定的控制方式去设置这些信号值。

服务 0x22（ReadDataByIdentifier），该服务可通过信号所在的DID去获取对应的数值，然后与2F请求设置的数值比较是否相同，进而便可以知道2F控制是否生效。

请求消息格式

dataIdenfier：服务请求受控cs所分配的DID；

ControlOptionRecord：表示控制模式及控制的相关参数组成的数据集；

肯定响应格式

支持的否定响应NRC代码：0x13，0x22，0x31，0x33

5、例程功能

例程控制（0x31）

执行定义的步骤序列并获得任何相关结果

典型用法：擦除存储器（DID=FF00），重置或学习自适应数据，运行自检，ECU软件下载后的编程依赖性检查（DID=FF01），覆盖正常服务器控制策略以及控制服务器值随时间变化等功能（如：关闭敞篷车顶）。

使用0x31服务的使用步骤：

开始例程（0x31 01）服务
询问例程执行的结果（0x31 03）服务
停止例程（0x31 02）服务

请求消息的格式;SID+例程控制类型（SF）+RID标识符+一些相应的数据

请求消息的子功能SF的定义如下表：

肯定响应格式：0x31+0x40=0x71+例程控制类型+例程控制ID（RID）

支持的否定响应代码：0x12，0x13，0x22，0x24，0x31，0x33，0x72

6、上传/下载功能

上传功能用的较少，下载功能也就是我们常说的Tester刷写ECU应用程序

请求下载（0x34）

请求格式：0x34+数据格式标识符（高低半字节有不同功能）+指定下载到的存储器的地址和长度

肯定响应格式：0x34+0x40=0x74+回复本ECU最大可接收的Block长度+回复Tester端每次发来的0x36服务后面可跟随多少字节（也就是告诉Tester每次能刷写到ECU的字节数）。

传输数据（0x36）

用来传输需要刷写到ECU的数据

请求格式：

肯定响应格式：0x36+block+要刷写的数据

比如要传输的第一个数据块：36 01 + 数据；第二个数据块36 02 + 数据

请求传输退出（0x37）

请求格式：

肯定响应格式：（ECU利用最近刷写的指定地址范围的数据来计算一个字节校验和（CRC）作为0x37服务的肯定响应）

支持的否定响应NRC代码：0x13，0x24，0x31，0x72

其他服务

请求下载（0x35）

请求文件传输（0x38）

7、CAN总线寻址示例

1、物理寻址

具体实现方式（Tester物理寻址ECU2）：Tester向CAN总线网络上广播0x604这个请求CAN ID报文，所有ECU都会接收到，但最后只有ECU2给予响应。而ECU2的响应消息的格式是0x606后面跟着响应的数据。

2、功能寻址

FG—Functional Group—功能组

具体实现方式（Tester物理寻址FG1）：Tester向CAN总线网络上广播0x6FF这个请求CAN ID报文，所有ECU都会接收到，但最后只有ECU1，ECU2，ECU5给予响应。各个ECU的响应格式有所区别。ECU1的响应报文是0x602+数据，依次如下图所示：

8、UDS时间参数总结

1、传输层时间参数

Block Size与STmin

BS（Block Size ）：该参数与STmin一般同时出现。表示接收方发送流控帧之后，发送方被允许连续发送的最大帧数。特殊情况下：若该值为0，则表示发送连续帧没有限制；若值为8，表示发送方最多能连续发送8帧连续帧就会继续收到接收方的流控帧。

STmin： 接收方发送流控帧后，发送方发送的连续帧之间的时间最小间隔。若值为0，表示对于发送方发送连续帧的最小时间没有要求。

此两参数主要用于诊断报文传输多帧时使用到。在传输多帧诊断报文过程中，存在三种类型的帧：

首帧FF（First Frame ）：发送多帧过程中的首帧报文；
流控帧FC（Flow Control）：发送方发送首帧报文之后，如果有流控，接收方回复的流控帧；
连续帧CF（Consecutive Frame）：流控帧之后发送方能够连续发送的报文帧；

应用场景与作用：

在APP模式下，发送报文长度大于8或者大于64（CANFD）时，就会自动开启流控模式。在Boot模式下，由于使用到0x36下载服务，涉及到大量数据传输，也必然会使用到流控。

BS与STmin的大小可用来评估接收方的接收能力，若都为0，表示接收方接收能力最强；有些时候，虽然Boot均可以设置为0，但是往往FBL（Flash Bootloader）刷写过程中涉及到网关的转发，而网关接收能力存在限制，此时对应的Boot也必须按照网关的接收能力来设置BS与Stmin。

2、网络层时间参数

N_As: 表示CAN数据帧从请求数据链路层发送至接收到回应ACK的最大时间间隔；
N_Bs: 表示发送方数据链路层接收到流控帧的最大时间间隔；
N_Ar: 表示接收方从请求数据链路层发送流控帧至接收到对应的ACK的最大时间间隔；
N_Br: 表示接收方请求数据链路层发送流控帧的内在最大时间间隔 (N_Br + N_Ar)<(0.9倍N_Bs)；
N_Cs: 表示发送方请求数据链路层发送流控帧的内在最大时间间隔 (N_Cs + N_As)<(0.9倍N_Cr);
N_Cr: 表示接收方接收到流控帧的最大等待时间间隔；

上述时间参数的确定，对于网络层各报文的发送与接收起到很好的监控作用，能及时发现问题所在。如下图所示，表达了各时间参数的起始及终止时间，以传输层的流控交互过程为例。

3、会话层时间参数

S3定时器

S3Client：表示Tester为了保持一个ECU或者多个ECU节点同时保持在非默认会话下的时间间隔，Tester的定时参数，客户端为将ECU保持在非默认会话状态，两个连续0x3E服务请求报文之间的的间隔时间。

S3Server：有时也称S3Timeout，ECU的定时参数，仅用于非默认会话模式，通过功能寻址将各ECU由默认会话切换为非默认会话时使用。在S3Server 时间内，如果ECU没有接收到任何诊断请求报文，则退出非默认会话模式，返回默认会话模式，S3client<S3server

常用场景：有些诊断服务只能在扩展会话下才能够执行的场景，需要保持在非默认会话下，执行该诊断指令。比如在刷写过程中(非必须，但一般一直发送比较号，防止意外的超时)或者其他需要一直工作在默认会话下的场景。

4、应用层时间参数

P2定时器

若ECU无法在规定时间内完成对诊断服务的判断，ECU便向Tester发送延迟的负响应。

在ISO-15765-3标准（UDS ON CAN）中针对Tester以及Server列出了3对P时间参数，分别为P2Client、P2Server、P2*Client、P2*Server、P3Client(Phy) 、P3Client(Func)。

常用场景：这些时间参数主要用于上位机在测试UDS的过程中，诊断工具需要设置一些参数来实时掌握诊断报文的响应状态以及控制相应诊断请求的发送。这作为评估整个UDS的通信是否稳定等性能指标。

写在最后：本文是本人初学UDS时候所做的笔记，后续本人若学习或者应用更深入会补充笔记，可以收藏。本篇顺序并没有很严谨，但是知识足够全面，若阅读完本文对你有帮助，麻烦帮忙点个赞！在此谢过！

GitCode 开源社区

旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。

更多推荐

GitTalk | 使用面向业务的狮偶编程语言提升开发效率

GitCode 开源社区

GitTalk | DevUI Suits 场景解决方案

GitCode 开源社区

GitTalk | DevUI Admin 前端项目构建

GitCode 开源社区

所有评论(0)

查看更多评论

xiaoliu_niuniu

@xiaoliu_niuniu

已为社区贡献1条内容