UDS诊断

UDS（Unified Diagnostic Services）是一种汽车诊断通信协议，其全称为“统一诊断服务”。UDS协议是ISO 14229标准的一部分，旨在为汽车电子控制单元（ECU）提供统一的诊断服务规范。

UDS协议的基本概念和功能

UDS协议的主要功能包括读取和清除故障码、读取数据流、控制ECU参数设置等。它不仅适用于CAN总线，还可以通过DoIP（Diagnostic over Internet Protocol）在Ethernet上实现。UDS协议的“统一”特性意味着它是一个国际化的标准，适用于所有ECU，而不仅仅是特定的ECU。

UDS协议的应用场景

UDS协议广泛应用于汽车售后维修、生产线检测设备开发以及车联网功能实现中。由于其标准化和统一化的特点，UDS协议方便了诊断工具的开发和使用，降低了维护成本，同时也促进了汽车电子系统的互操作性‌1。

UDS诊断包括6大类，26种服务，每种服务都有自己独立的ID，即SID（Service Identifier）

以诊断和通信管理功能单元（Diagnostic and Communication Management functional unit ）为例，服务请求和响应有两类：一类是具有Subfunction（子功能），另一类是不具有Subfunction（子功能）。

不具有Subfunction（子功能）的UDS诊断服务请求和响应机制如下图所示：

诊断方（Tester）向ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。

ECU接收到请求数据（Request）后会返回响应，可返回肯定响应或者否定响应。

肯定响应（Positive Response）格式为：（SID+0X40）+数据。例如，请求0X10服务，肯定响应第1个字节为0X50；请求0X22服务，肯定响应第1个字节为0X62。

否定响应（Negative Response）格式为：0X7F+SID+NRC。例如，请求0X10服务，否定响应第1个字节为固定的0X7F，第2个字节为0X10，第3个字节为NRC。NRC是否定响应码，可以根据返回的NRC判断是什么原因导致的否定响应。

具有Subfunction（子功能）的UDS诊断服务请求和响应机制如下图所示：

诊断方（Tester）向ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。

ECU接收到请求数据（Request）后会返回响应，可返回肯定响应或者否定响应。

肯定响应（Positive Response）格式为：（SID+0X40）+Subfunction（子功能）+数据。例如，请求0X10服务，Subfunction（子功能）为0X02，肯定响应第1个字节为0X50，第2个字节为0X02。

否定响应（Negative Response）格式为：0X7F+SID+NRC。例如，请求0X10服务，否定响应第1个字节为固定的0X7F，第2个字节为0X10，第3个字节为NRC。NRC是否定响应码，可以根据返回的NRC判断是什么原因导致的否定响应。

1.请求的格式

UDS请求格式分为4类

格式1：[SID]

格式2：[SID]+[DID]

格式3：[SID]+[SF]

格式4：[SID]+[SF]+[DID]

其中：SID-Service Identifier （服务ID），DID-Data Identifier （数据单元的ID）

SF-Sub-function（子功能）

SF的作用是细分服务，提供更多的服务类型。

2.响应的格式

响应格式分两种，一种为Positive Response（肯定响应），即诊断请求执行成功；一种为Negative Response（否定响应），即诊断请求执行失败。

Positive Response：

格式1：[SID + 0x40]

格式2：[SID + 0x40] + [DID]

格式3：[SID + 0x40] + [Sub-function]

格式4：[SID + 0x40] + [Sub-function] + [DID]

Negative Response：

[0x7F] + [SID] + [NRC]

DRC-Negative Response Code（负响应码），指示出现了何种问题导致控制器不响应请求。

三、接收方如何区分SF和DID？

协议中对各个服务的请求格式有不同的规定，有强制性要求、自定义要求，如下面图2中所示，也就是说当确定使用哪种服务时就已经确定它有没有子功能了，接收器自然是能分辨SF和DID了。图中缩写解释如下：

M：强制的

S：强制的，需从参数列表中选择一个

U：用户自定义，可选择的

注：以下所有例子中的数据都为16进制格式，为表达简明，省去“0x”前缀。

1.含有子功能的请求报文及正响应

含有子功能的请求报文由请求ID，子服务ID，数据参数[可选]组成，如下图2所示。

含有子功能的响应报文由响应ID，子服务ID，数据参数[可选]组成，其中响应ID值为对应请求ID加0x40，如下图3所示

例1：

请求：10 01(切换默认会话模式，01为子功能)

响应：50 01 xx xx xx xx(成功切换默认会话模式)

例2：

请求：19 02 FF(请求读取以0xFF为DID的故障信息)

响应：59 02 FF xx xx xx x

2.不含子功能的请求报文及正响应

不含有子功能的请求报文由请求ID，数据参数[可选]组成，如下图4所示。

不含有子功能的响应报文由响应ID，数据参数[可选]组成，其中响应ID值为对应请求ID加0x40，如下图5所示。

例1：

请求：22 F1 90(读取DID为0xF190的数据)

响应：62 F1 90 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10

(返回DID为0xF190的数值为00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10)

例2：

请求：37(请求数据传输退出)

响应：77

3.负响应报文

负响应的格式只有一种，第一个字节固定为7F，第二个字节为服务ID，第三个为NRC即不响应请求的原因，如下图6所示。

例：

请求：10 02(切换编程会话模式)

响应：7F 10 7E (错误切换至编程会话模式，NRC为7E )
说点UDS具体的场景应用：

（1）ECU开发过程要用到它来构建bootloader，上传和下载数据，即软件刷写，控制器Reset；

（2）测试时要用它来读写存储，控制外设；

（3）产线上，要用它来校准机械件，控制例程，进行下线执行器测试，刷新软件，配置防盗，读取号码，下线配置等；

（4）在行驶过程中，要用它来监测各种故障，并记下故障码；

（5）4S店里，技师需要读取当前故障、历史故障，读取故障发生时刻环境信息状态，清除故障，判断故障发生点，还可以用来升级ECU程序。
OBD与UDS的区别是：

（1）OBD是关注车辆实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范。电动车不需要满足这个标准，因为没有尾气排放。燃油车通常既要满足OBD，又要满足UDS。诊断服务下面才会讲到，看完诊断服务可以回头看这里。UDS的诊断服务代码是从0x10开始的，小于0x10的代码则被OBD用了。

（2）UDS是面向整车所有ECU的，而OBD是面向排放系统ECU的。既然UDS可以用于所有的ECU，那是否能把OBD完全取代呢？这点不太清楚。
常用诊断命令：
 诊断会话控制服务-0x10

诊断会话控制服务被用来使能服务端中的不同诊断会话模式，诊断会话模式分为两大类：默认会话和非默认会话，其中非默认会话又包括编程会话和扩展会话，如下图所示。
这里分为三种会话模式，主要考虑的是服务的使用权限问题，不同会话模式下能使用的服务有区别，如下图所示。
 

     默认会话是指ECU在刚上电时保持的会话状态，其服务的使用权限小，即可操作的功能单元服务少，比如不能使用27，28，83，84等服务；
    编程会话是仅使用与刷写程序相关的诊断服务，比如27，31，34，36，37等服务；      
    扩展会话相较于默认会话，其使用服务的权限大，即可操作的功能单元服务多，默认会话模式下不能使用的服务，在扩展模式下都能使用。

模式切换遵循以下规则：

（1）当ECU上电时，ECU总是从默认会话模式开始。

（2）当ECU上电后，非默认会话没被激活时，ECU会一直处于默认会话模式。

（3）当进入非默认会话后，如果服务端的S3定时器超时或请求了默认会话，将进入默认会话；

（4）当进入非默认会话后，如果控制服务端的S3定时器不超时，比如使用待机握手服务（$3E），则即可进行编程会话与扩展会话切换。
（4）当进入非默认会话后，如果控制服务端的S3定时器不超时，比如使用待机握手服务（$3E），则即可进行编程会话与扩展会话切换。

 
这里解释以下S3参数，S3参数可分为S3server和S3client。

S3server是服务器的定时参数，通常取5000ms，仅用于非默认会话模式。在该模式下，如果在S3server时间内，服务端没有接受到任何诊断请求服务，则退出非默认会话，返回默认会话。
   S3client是客户端的定时参数，通常取4000ms。客户端为了保持非默认会话的连接，可以通过发送3E请求（待机握手服务）来保持连接，但必须在S3server的时间内发送一次。相当于每4000ms，客户端告诉服务端它还在，不要退出非默认会话。

下面来看下0x10的请求和响应格式。0x10是有多个子功能的，所以其请求格式为SID+SF。比如请求默认会话模式，客户端会发送10 01；编程会话模式，则发送10 02，其他以此类推。需要说明的是上面提到了0x10的三个子功能，其实0x10的子功能不止三个，其他的子功能如下图，这里不展开。

以客户端发送了10 01为例，服务器端应回复50 01 xx xx xx xx。这里的xx是响应的相关参数，如下图所示。

参数通常是会话参数，即P2Server和P2*Server，如下图所示。

这里来解释一下P2Server和P2*Server。

P2Server的定义如下，表示从服务器端接收到请求消息到开始发送响应消息的时间。通常取值为50ms。

P2*Server的定义如下，表示从服务器端接收到请求消息到开始发送响应消息的时间。通常取值为5000ms。

P2*Server的定义如下，表示从ECU发送了NRC为0x78的否定响应消息到开始发送下一个响应消息之间的additional max.time，通常取5000ms。

如果设置P2server_max=50ms，P2*server_max=5000ms，则肯定响应就是50 01 00 32 01 F4。

需要说明的是，时间参数不止以上两个。会话层，即ISO 14229-2还定义了其他时间参数，有需要的可以查找标准。

当客户端发送诊断服务请求，服务端需要回复否定响应时，这时否定响应格式为 7F+SID+NRC，0x10服务支持的部分NRC如下图所示。

比如客户端发送请求10 05，但服务端未定义05，即不支持该子功能，则产生否定响应7F 10 12；比如请求10 01 01，不符合请求格式SID+SF的长度，则产生否定响应7F 10 13。

2.3.2 安全访问服务-0x27

访问数据服务和某些诊断服务需要考虑保密或安全等原因，比如下载/上传诊断服务例程或数据进入ECU并从其读取特定的内存位置，或者下载到ECU中的不正确例程或数据可能会损坏电子设备或其他车辆部件，或危及车辆的排放和安全标准。为了解决这些情况，就定义了安全访问服务。

​

安全服务的实现过程如下图所示。

​

上图中请求种子使用的格式是27 2n-1，原因是ECU需要解锁情况有多种，比如扩展会话模式下读写数据前需要解锁，比如采用27 01；编程会话模式下刷写程序前也需要解锁，比如采用27 03；当然可能还包括其他情况，故上图采用27 2n-1就更具有概括性，可适用多种情况。2n-1具体对应解锁什么服务，由整车厂自己定义。

当请求种子后，ECU就需要响应，发送种子。当客户端收到种子后，通过某种算法获得密钥后，客户端发送密钥给ECU。发送密钥的子功能代码都是偶数。

举个例子，假设扩展会话模式下，读写数据前需要先解锁，比如约定好了，这种场景下解锁采用的是27 01命令。我们发送27 01请求种子；ECU发送67 01 36 57，其中36 57是种子。密钥是种子的二进制补码，于是客户端计算出密钥是C9 A9；随后通过27 02 C9 A9发送密钥给ECU；ECU验证正确后，回复67 02，表明解锁成功。解锁成功后，就可以读写数据了。

​

如果在解锁状态下，重复发送解锁请求，比如发送27 01的命令，则ECU会回复67 01 00 00，表明ECU已解锁。

​

27 01解锁的是数据读写的功能，如果要解锁刷写程序的功能，假设刷写程序解锁的子功能代码是03，则需要重复上面的，使用27 03等指令取解锁刷写程序的功能。

0x27服务支持的否定响应码如下。举个例子，如果客户端给服务端发送的密钥不对，那么服务端将会发送否定响应，即7F 27 35。

  2.3.3 根据标识符读数据-0x22

0x22是根据DataIdentifier（即DID）去请求读取数据，其请求格式为SID+DID。这里请求的DID可以是一个，也可以是多个。其肯定响应的格式为(SID+40)+DID+Data，看一个例子。其中22是SID，响应时SID+40=62。F1 90为DID，紫色部分则为具体的数据。

再看请求两个DID的情况。其中01 0A和01 10为两个DID。A6-7E这部分数据为01 0A这个DID的数据，8C为DID=01 10的数据。

​编辑

2.3.4 根据标识符读数据-0x2E

0x2E是根据DataIdentifier（即DID）去请求写入数据，其请求格式为SID+DID+Data.

注意这里一次只写一个DID的数据，不像读取数据服务可以一次读取多个DID的数据。通过该服务可以：写入一些配置信息到ECU（比如VIN码，即车辆识别码），清除非易失性数据，重置学习值，设置一些可选内容。

需要注意的是，2E服务需要ECU解锁了才能执行，默认会话模式不支持该服务，所以要先进入非默认会话模式，然后解锁，才能写入数据。假设F1 90为DID，根据该DID写入数据的整个过程见下图。

DiagnosticSessionControl(0x10)为控制切换各个会话模式的服务。

如下图，为三种常用会话模式的转换图

默认会话模式(default session 0x01)
编程会话模式(ProgrammingSession 0x02)
拓展诊断会话模式(extendedDiagnosticSession 0x03)

图4-1 常用会话模式切换

ECU在刚上电或者复位之后处于默认会话模式(0x01)，默认会话模式下发送10 03可以切换至拓展会话模式(0x03)，拓展会话模式发送10 02可以切换至编程会话模式(0x02)，而在默认会话模式不可以直接跳转至编程会话模式，若在模式会话模式直接发送10 02，此时ECU需要响应NRC为0x7E(subFunctionNotSupportedInActiveSession)的负响应，响应内容为7F 10 7E。

如果ECU处于非默认会话模式下，客户端发送10 01进入默认会话模式，ECU收到该请求后，ECU的安全访问状态切换到锁定状态，由ReadDataByPeriodicIdentifer(0x2A)服务配置的周期调度被禁止，通过CommunicationControl(0x28)和ControlDTCSetting(0x85)进行的设置均被复位，即ECU初始化所有在非默认模式下激活的事件，设置和控制等操作，但不包括已经写入到非易失性存储位置的操作。

请求格式

正响应格式

负响应格式

ECU复位ECUReset(0x11)

ECU复位ECUReset(0x11)是控制ECU端执行复位的服务。诊断仪发送11 01复位请求后，ECU复位动作执行前，正响应需先发送给诊断仪，然后ECU执行复位操作，成功复位后，ECU需进入默认会话模式。

请求格式

正响应格式

负响应格式

安全访问SecurityAccess(0x27)

安全访问SecurityAccess(0x27)，此服务是提供访问ECU内部数据或者出于安全因素需被限制的诊断服务的请求权限。常见的如读服务(0x22)读取非安全信息时能够直接读取，不需要利用27服务进行安全访问，而通过写服务(0x2E)写入数据时，则通常需要通过27服务进行安全访问才可以写，刷新程序也需要利用27服务通过相关的安全等级才能够对ECU进行程序下载，显然这些都是需要利用27服务进行权限管控，从而保障ECU的安全可靠。

安全访问序列如下图所示，一共4步组成，

诊断仪先发送请求seed的报文(27 01)
ECU响应seed(67 01 xx xx xx xx)
诊断仪根据返回的seed按照约定算法计算key值，并发送给ECU请求验证(27 02 xx xx xx xx)
ECU收到请求之后，也按照约定的算法对该key进行校验，并给出响应，若计算一致，则为正响应(67 02)，否则为负响应(7F 27 NRC)

ECU若校验key一致，则ECU则切换安全状态至对应的解锁状态，此时在该解锁状态下能够支持的服务都应该可以工作。如果ECU已经处于解锁状态，此时诊断仪再次发送请求seed的报文，ECU应该响应seed为0的正响应。

seed请求的子服务值为奇数，对应的key请求验证的子服务值为该奇数加1，如27 01与27 02为一组安全等级，27 03与27 04为一组安全等级，27 11与27 12为一组安全等级。不同的安全等级由客户定义功能区分。

seed请求格式

seed正响应格式

key请求验证格式

key验证正响应格式格式

负响应格式

通讯控制CommunicationControl(0x28)

通讯控制服务用于开启或关闭ECU对某些报文的发送或接收，如应用报文和网络管理报文等。

请求格式

正响应格式

负响应格式

待机在线TesterPresent(0x3E)

该服务用于诊断仪端告知ECU诊断仪依然在线。该服务通常用于保持ECU处于非默认模式，由于ECU在S3server时间收不到诊断请求的话，ECU将会退回默认会话模式(default session)，所以诊断仪为了保持ECU处于非默认模式，需要周期性发送TesterPresent服务指令，周期时间需要小于S3server。

请求格式

正响应格式

负响应格式

诊断故障码设置控制ControlDTCSetting(0x85)

诊断故障代码设置控制服务用于停止或重启ECU诊断故障代码的记录。

当通过该服务对故障码记录进行抑制操作后，若会话层时序参数超时从而ECU进入默认会话，或ECU执行复位操作后，诊断故障代码应该恢复记录。

当接收到诊断仪发送的清除诊断信息(0x14)服务后，ECU应重新开启诊断故障代码记录。

请求格式

正响应格式

负响应格式

读DID数据ReadDataByIdentifier(0x22)

根据DID(标识符)读取数据服务用于从ECU存储器中读取由DID所确定的数据记录值，其中DID为两个字节长度的数值。

ISO14229中定义该服务的请求报文允许支持1个或者多个数据标识符，一般主机厂仅支持1个DID读取。下图报文格式也以1个DID作为讲解。

请求格式

正响应格式

负响应格式

写DID数据WriteDataByIdentifier(0x2E)

根据DID写入数据服务允许诊断仪将数据写入由DID指定的内部存储单元。ECU应在数据写入成功后发送该服务的肯定响应。

请求格式

正响应格式

负响应格式

清除故障码ClearDiagnosticInformation(0x14)

正响应需在诊断信息清除请求后，ECU处理完成后发出，即使 ECU 没有存储的 DTC，也需发出正响应报文。清除 DTC 的同时，所有 DTC 相关存储信息都应被清除。

请求格式

正响应格式

负响应格式

读故障码信息ReadDTCInformation(0x19)

请求格式

正响应格式

负响应格式

通过DID控制输入输出InputOutputControlByIdentifier(0x2F)

该服务是用于通过DID来直接控制ECU对应的输入输出信号。

请求格式

正响应格式

负响应格式

例程控制RoutineControl(0x31)

请求格式

正响应格式

负响应格式

请求下载RequestDownload(0x34)

请求格式

正响应格式

负响应格式

传输数据TransferData(0x36)

请求格式

正响应格式

负响应格式

请求数据传输退出RequestTransferExit(0x37)

请求格式

正响应格式

负响应格式

5. 负响应码