UDS诊断服务详解

首先介绍一下UDS，UDS(unified diagnostic service)也叫统一诊断服务，它主要功能是诊断仪（Tester）向ECU发送诊断请求(Diagnostic request),ECU收到请求后向诊断仪给出诊断响应（Diagnostic response）的过程，也就是诊断通信的过程。其中请求和响应的内容和格式由ISO-14229定义同i标准，ISO 14229定义了诊断服务以及UDS在CAN总线上的实现。

1.1.1 诊断请求格式：

诊断请求分为两类：一类带有子服务(sub-function),一类没有子服务(sub-function)。

介绍一下请求格式中各位的含意：

Service ID: 简称SID，表示诊断请求的功能，占1byte的固定长度。

sub-function:表示诊断服务的子服务，可以理解为诊断请求的子功能，比如表示开启或者停止该诊断请求的功能等，占1byte的固定长度。其中sub-function的最高位表示肯定响应抑制位，剩下的7个bit才表示sub-function。如果最高位置为1，表示肯定响应抑制，那么ECU收到这条请求，不会做出肯定响应；如果最高位置为0那么ECU必须对该请求做出肯定响应。比如ECU再收到10 01、3E 00、85 02等诊断请求之后，必须做出肯定响应，而收到10 81、3E 80等诊断请求之后，不会作出肯定响应。响应抑制的原因是减少ECU不必要的肯定响应，节约通信资源！！

Parameter:诊断请求的参数，对不同诊断服务，Parameter的长度、内容、格式等通常都会不同。Parameter的内容可以作为标识符(CAN仲裁域的标识部分),表示诊断请求读取或者传递的数据参数。Parameter还可以表示诊断服务的限制条件，比如时间参数等等。

1.1.2 诊断响应的格式

诊断响应格式有两类：一类是肯定响应（positive response），一类是否定响应（negative response）。

ECU响应肯定时，表示诊断仪发送的诊断请求被ECU执行了，ECU响应否定时，表示ECU因为某种原因拒绝了诊断仪发送的诊断请求，拒绝的原因，也就是否定响应码，存在了否定响应的报文中。

1. 肯定响应由三部分组成：

response SID：占1个字节，作为诊断请求的响应，它的值等于SID + 0X40。

sub-function: 占1个字节，表示该诊断服务的子服务，与诊断请求中一致。

Parameter：ECU响应给诊断请求的参数，不同的诊断请求，ECU响应的参数通常不同。例如ECU对请求28 03 03做出的肯定响应为68 03 03。

2. 否定响应也是由三部分组成：

Negative Response SID: 占1个字节，等于0X7F。

Reque Service ID：占1个字节，表示被拒绝的SID，与诊断请求中SID一致。

Negtive Response Code：占1个字节，表示诊断请求被拒绝的原因。例如ECU对请求10 02做出否定响应7F 10 7E，表示10 02请求因为该子服务在当前会话不支持返回0X7E而拒绝。

1.2 UDS诊断服务

1.2.1 DignosticSessionControl(会话诊断控制 10服务)

通过会话诊断控制请求，控制ECU在不同的会话间切换，不同的会话表示ECU当前所处的软件状态，或者说是当前所处的线程，不同会话下，支持的可执行的诊断服务权限不同。

诊断会话控制的诊断请求固定为2字节第一个字节是SID，第二个字节的7bit表示请求ECU进入的会话。

诊断会话控制，该诊断服务通常是诊断仪与ECU进行通信的第一条诊断服务请求。

1.2.1.1 DiagnosticSessionControl request

Requst ID(SID)：固定为1字节，其值为0X10。

sub-function固定为1字节，最高位表示肯定响应抑制位，低7bit是表示ECU将进入的会话。UDS通过低7位定义了不同的会话，比如BT中常见的默认会话、编程会话、扩展编程会话等。

UDS定义的会话包括：

0X00 ISOSAEReserved (保留)

0X01 defaultSession (默认会话)

0X02 ProgrammingSession （编译会话）

        0X03 extendeDiagnosticSession (扩展会话)

        0X04 safetySystemDiagnosticSession (系统安全诊断会话)

        0X05 - 0x3F ISOSAEReserved (保留)

        0X40 - 0x5F vehicleManufacturerSpecific（由整车厂自定义使用）

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

        0x7F ISOSAEReserved（保留）

常用的会话就是以上加粗的会话。

会话模式	如何进入	权限
默认会话	通常ECU断电/上电之后就会停留在BT的默认会话	权限较低，很多诊断服务请求不被支持，很多诊断相关的数据不能被读写。
扩展会话	默认会话下，诊断仪给ECU发送诊断会话请求10 03	扩展会话的权限比较高，支持的诊断服务业较多。
编译会话	扩展会话下，诊断仪向ECU发送站短会话请求10 02，ECU惠切换进入扩展会话中。	编译会话的权限很高，支持的诊断服务很多，例如软件刷写相关的一系列服务。

非默认会话：扩展会话和编程会话统称位费默认会话，如果要让ECU保持在非默认会话中，诊断仪需要定时向ECU发送诊断请求0X3E（诊断在线服务），保持诊断仪与ECU之间的通信，使ECU一直处于非默认会话。

1.2.1.2 DiagnosticSessionControl response

会话诊断控制响应分为三部分：

Response SID：固定为1个字节，表示对SID（0x10）的响应，其值为（0x10 + 0x40）.

sub-function: 固定为1个字节，表示诊断仪请求ECU进入的会话，与诊断请求中的sub-function一致，表示对sub-function的响应

Parameter：固定为4个字节，前2个字节表示P2Server_max,也就是ECU对诊断请求的响应时间。后2个字节表示P2*Server_max，也就是ECU在当前无法在P2Server_max时间对诊断请求做出响应，会先响应一帧NRC（否定响应码） 0x78,诊断仪收到0x78的否定响应后，会等待更长的响应时间，也就是P2*Server_max表示ECU响应NRC 0x78后，对诊断请求的最长响应时间。

诊断会话控制对应否定响应码：

1.2.2 ECUReset(ECU复位11服务)

诊断仪通过发送诊断请求ECUReset（0x11）,可以使ECU复位在。

ECUReset(0x11)的请求和响应格式为：

Request ID（SID）：固定为1字节，其值为0x11。

sub-function：固定为1字节，最高位表示肯定响应抑制位，低7bit是表示ECU将模拟那种方式进行复位。UDS通过低7位定义了3种不同的复位方式。

0x01 hardReswet硬件复位，此值定义了模拟断开供电电源后（eg：电池）后重新上电/启动序列的“硬件复位”的情况。此执行动作需具体规定，并没有标准规定。其结果可能导致重新初始化易失性存储（RAM）和非易失性存储（ROM）至预定义的值。

0x02 keyOffOnReset 钥匙开关复位，此值定义了类似驾驶员关闭又开启点火钥匙的情况。此复位情况要求模拟一个“KEY-OFF-ON”序列（例如，干扰供电电源的转换）。此执行动作执行需要具体规定，并没有标准规定。通常非易失性存储位置收到保护而易失性存储被初始化。

0x03 软复位 该类型的复位强迫ECU重启其应用程序，并且在非易失性存储器中存储所有在应用程序重启时可能会丢失的数据。该复位操作应导致应用程序的重启，但不对之前学习的配置参数、自适应系数以及其他长时调整参数等数据重新初始化。

当诊断仪通过诊断请求对ECU进行某些操作，修改了ECU某些数据，只有ECU复位这些操作才能生效，此时需要发送复位请求。在ECUReset执行之后，ECU复位请求的肯定响应报文在复位操作执行之前发送，复位之后，ECU应首先进入默认会话，ECU也从非默认会话进入默认会话。

复位请求ECUReset对应否定响应码：

1.2.3 SecuityAccess(0x27 27服务)

27服务的目的就为受限于访问安全的数据提供一种访问方法（请求解锁ECU）。一般厂家可能会为ECU定义某些安全级别稍微高一些r的诊断服务，在执行此类服务之前，就需要执行SecurityAccess这个安全访问诊断请求，进行一个简单的身份验证。例如，完成上传/下载程序或者例程或者数据至服务器、从服务器中读取特殊位置内存数据等诊断服务一般需要执行安全访问。因为不恰当的下载程序或数据至服务器可能惠破坏电子设备或者其它汽车部件，或对汽车排放实现，安全性以及安全标准造成风险。

1.2.3.1 安全访问步骤（重点）

安全访问的概念是使用“种子”(Seed)和“密钥”(Key)来实现，安全访问的步骤有以下步骤：

1. 诊断仪向ECU请求“Seed”

2. ECU向诊断仪做出肯定响应，发送“Seed”（Seed通常是生成的伪随机数）

3. 诊断仪向ECU发送“Key”（Key根据ECU响应的Seed计算得来）

4.ECU判断诊断仪发过来的“Key”是否有效，做出肯定或者否定响应。

通常，根据UDS的定义，sub-funciton：0x03,0x05,0x07-0x41是用于请求Seed，sub-function：0x04,0x06,0x08-0x042是用于发送Key。请求Seed和发送Key的sub-fucntion是成对出现的，发送Key的sub-function等于请求Seed的sub-function加0x01,比如请求Seed为27 03，那么发送Key为27 04。具体选择哪对值，由整车厂定义。整车厂也可以选择多对sub-function，用于不同等级的安全访问。

安全访问请求Seed的否定响应码包括：

安全访问发送Key的否定码包括：

1.2.4 通信控制请求（0x28 28服务）

通信控制请求CommunicationControl

表示允许客户端用来 “使能/禁止”一个或者多个服务器发送或者接受特定的报文。通常在刷写软件或者大量数据的时候使用，因为在刷写软件或者参数的时候并不需要ECU进行与通信相关的功能，将通信关闭之后可以把所有通信资源都留给软件或者参数的下载，当下载过程完成之后再利用该服务将通信恢复即可。

通信控制服务的请求和响应的格式

CommunicationControl request SID：固定为1个字节，其值为0x28。

sub-function：固定为1字节，最高位表示肯定响应抑制位，低7bit是表示对ECU通信进行那种控制，即“控制类型” （ControlType）。UDS通过低7位定义了7中不同的控制方式。

0x00 enableRxAndTx（激活接受和发送）此值说明对于指定的通信类型须允许接受和发送报文。

0x01 enableRxAndDisableTx（激活接收和关闭发送）此值说明对于指定的通信类型须允许接收报文但禁止发送报文。

0x02 disableRxAndEnableTx（激活发送和禁止接收）此值说明对于指定的通信类型须允许发送报文但禁止接收报文。

0x03 disableRxAndTx（禁止发送和接收）此值说明对于指定的通信类型须禁止接收和发送报文。

0x04 enableRxAndDisableTxWithEnhancedAddressInformation（激活接收和关闭发送，针对特定的地址）

0x05 enableRxAndTxWithEnhancedAddressInformation（激活接收和发送，针对特定的地址）

0x06-0x7F 都是保留或者留给厂商自定义。

CommunicationType：固定为1个字节，表示对ECU的哪种报文进行控制。用来定义控制通信的类别。CommunicationType是一个位代码（bit-code）值，允许同一时刻控制多种通信类型，最常用的就是低2位：

0x1代表普通应用报文，此值定义的所有的应用相关通信。（内部应用信号在整车多服务器间交换）。

0x2代表网络管理报文，此值定义了所有网络管理相关通信。

0x3代表普通应用报文和网络管理报文，此值定义了所有网络管理相关和应用相关通信。

CommunicationType定义如下表：

nodeIdentificatioNumber ：是optional可选的，只有当sub-function等于0x04或0x05时才需要使用。

通信控制CommunicationControl的否定响应码

注意：如果ECU在多信道通信，此服务会影响所有信道的响应报文（不仅是收到28诊断请求的信道）。

1.2.5 TesterPresent （0x3E 3E服务）

此服务用于向服务器指示诊断仪在线。当其他UDS服务不存在时，为了防止服务器自动转入默认会话并停止通信，必须使用此服务。如果没有诊断在线服务的发送和接收，ECU将从非默认会议中复位，然后进入默认会议，0x3E就是用于使ECU保持在当前Session中。

0x3E诊断服务的请求格式

当sub-function是0x00时，ECU要给出response；当sub-function是0x80时，ECU不需要给出response。（抑制位是否置1）

诊断仪在线的否定响应码

1.2.6 ControlDTCSetting （0x85 85服务）

此服务用于启动或者禁止ECU中的诊断故障码（DTC）设置，控制ECU的DTC存储，该服务能够有助于避免某一ECU在特殊诊断过程中，其它ECU记录DTC。典型的情况是当ECU在刷新flash时。85服务和28服务通常一起使用，比如，在刷写软件之前，为了获得更快的传输速度，用28服务把所有ECU通信关闭了，但此时ECU因为收不到相关报文，会没有必要地存储很多DTC，因为通信关闭对于ECU来说就是一次故障，这时使用85服务把ECU存储DTC的功能暂时性地禁止掉，则不会造成这种麻烦。

诊断故障码（DTC）设置ControlDTCSetting的请求和响应格式

诊断故障码DTC设置的请求分为3个部分

ControlDTCSetting request SID：固定为1个字节，其值为0x85

sub-function: 固定为1个字节，最高位表示肯定响应抑制位，低7位表示打开还是关闭ECU的DTC存储，UDS通过低7位定义了两种DTCSettingType：0x01 表示打开，0x02表示关闭。

OptionRecord：是可选择optional的，由厂家自定义，eg 可以用FF FF FF来表示这条诊断服务针对所有的DTC。

ControlDTCSetting请求的否定响应码

1.2.7 ReadDataByIdentifier （0x22 22服务）

0x22服务（ReadDataByIdentifier 按数据标识符读取服务）允许客户端从服务端中定义的一个或者多个数据标识符中请求数据记录值。通过DID读取数据。

客户端请求消息包含一个或者多个两个字节的数据标识符值，其表示服务端所维持的数据记录值。数据记录值的格式和定义应该由车辆制造厂商或者系统供应商所指定，这些数据记录值可能会包含模拟量输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。

服务端可能会先同时请求的数据标识符数量，首先需要由车辆制造厂商和系统供应商商讨决定。

一旦收到了0x22服务的请求消息，服务端应该访问由数据标识符参数指定数据元素几率之，并且在单个22服务肯定应答报文中去传输他们的值。请求报文中可能会多次包含同一个DID值，服务端应该将这些重复的DID看作独立的DID并答复。

多个DID格式

响应格式

DID数据参数定义

22读服务的否定响应码包括：

1.2.7 WriteDataByIdentifier（0x2E 2E服务）

2E服务（WriteDataByIdentifier,按数据标识符写入数据服务）允许客户端写入数据到服务端，这需要在数据标识符DID所指定的位置实现，该数据标识符可以时保密的也可以不是。

动态定义数据标识符（2C服务其实就是临时在指定地址创建个信息DID，里面可以存写临时数据，到时候可以给自己读写，但是这东西一重启或者过段时间就没了。要用0x22服务去读取，0x2A来写）不能够使用2E服务（因为2E服务不能指定地址写，应该使用2A来写）。当执行该服务时需要满足哪些条件时车辆制造厂商来制定的。以下情况可能会用到该服务：

刷新时写入一些配置信息到服务端（如，VIN号）；

清除非易失性存储(NVM)；

重置自学习值；

设置选项内容；

否定应答码格式

1.2.8 RoutineControl （0x31 31服务）

例程控制服务是调用ECU内置的一些操作序列的接口，厂家可以根据自己的需要位ECU定义各种各样的内部操作，而执行这些操作只需要调用31服务就可以。典型的涌入包括检查边界条件】清除闪存、对数据进行校验、对软硬件依赖性进行校验等等，甚至还可以进行恢复出厂设置的操作。

例程控制服务的请求和相应格式：

Request SID：固定为1字节，其值为0x31.

Sub-function：固定为1个字节，用于标识要执行什么动作，启动（0x01）、停止（0x02）、查询结果（0x03）。

routineIdentifier：用于标识要执行的例程 routine

routineControlOptionRecord：可选参数，用于标识routine执行时所需要的参数，由厂家自定义它的内容。

例程控制服务的否定响应码：

1.2.9 大量数据传输服务（34、35、36、37服务）

数据上传下载。当传输的数据大于ECU缓存传输数据的buffer时，不能在用2E和22服务进行数据传输了。此时，UDS提供了传输大量数据的服务也就是34、35、36、37服务，用于大量数据的传输。

RequestDownload（0x34）：客户端向服务器请求下载数据。

RequestUpload（0x35）：客户端向服务请求上传数据。

TransferData（0x36）：客户端向服务器传输数据。

RequestTransferExit（0x37）：数据传输完成，请求退出数据传输。

整个流程图

RequestDownload（0x34 34服务）

客户端使用34服务初始化从客户端到服务器的数据传输（下载）。接受到此服务的请求报文时，服务器应在发送肯定响应报文前，采取所有必要动作用于数据接受。34服务用于请求数据传输，通过ECU的肯定响应0x74，响应给诊断仪最大传输的数据量。

34服务的请求格式

Request SID：固定为1个字节，其值为0x34。

dataFormatIdentifier：固定为1个字节，标识了数据格式相关的信息，比如数据是否有压缩，是否有加密，用的什么算法加密等。

addressAndLengthFormatIdentifier：固定为1个字节，高4bit标识memorySize所占的字节长度，低4bit标识memoryAddress所占的字节长度。

memoryAddress：写入数据在ECU中的地址。

memorySize：写入数据的字节数。

34服务的肯定响应格式

        Response SID：固定为1个Byte，其值为0x74。

        dataFormatIdentifier：固定为1个Byte，标识了数据格式相关的信息,与请求中的一致。

        maxNumberOfBlockLength：长度不定，允许36服务一次传输的最大数据量。

34服务的否定响应码：

TransferData（0x36 36服务）

客户端使用TransferData服务从客户端到服务器传输数据（下载）或者从服务器到客户端传输数据（上传）。如果ECU对34服务进行了肯定响应，诊断仪就要发送36服务请求，请求数据传输。

36服务的格式：

36服务的请求格式：

        Request SID：固定为1个字节，其值为0x36。

        blockSequenceCounter：固定为1个字节，标识当前传输的是第几个数据块，或者简单地说就是第几次调用36服务。

        maxNumberOfBlockLength：长度不定，允许36服务一次传输的最大数据量。

        transferRequestParameterRecord：传输的数据。每次传输最大数据量就是34服务响应中的maxNumberOfBlockLength。

36服务的肯定响应：

Response SID：固定为1个字节，其值为0x76。

blockSequenceCounter：固定为1个字节，标识当前传输的是第几个数据块。

36的否定响应码：

RequestTransferExit（0x37 37服务）

客户端使用37服务终止客户端与服务器的数据传输。37服务标识退出数据传输，如果ECU对34和36服务进行了肯定响应，ECU也会对37服务进行肯定响应。37服务的请求只有一个字节37，肯定响应也只有一个字节77。如果前面的36服务没有执行完成，比如出现丢帧或者数据没有传完，此时发37服务，ECU会做出否定响应NRC 0x7F 37 24。

37服务的否定响应码：

1.2.10 UDS相关的时间参数--P2,P3,S3

P2Server_max:表示从ECU接收到请求消息到开始发送响应消息之间的定时器性能要求数值。ECU必须确保一个单帧响应消息或者多帧响应消息的第一帧消息在P2Server时间内完成（成功发送CAN网络上）。P2Server_max指的是ECU在收到请求和给出响应之间的这个时间间隔，它描述了ECU的反应速度。

P2*Server_max：从ECU发送了NRC为0x78的否定响应消息到开始发送下一个响应消息之间的增强型定时器性能要求数据值。P2*Server_max与P2Server_max的含义类似，区别在于，P2*Server_max这个时间参数实在ECU给NRC 0x78之后生效的，ECU返回NRC 0x78，说明ECU当前处理能力不足，所以需要更长的反应时间，即P2*Server_max通常比P2Server_max大很多。比如在请求诊断会话服务中，10服务的肯定响应格式是类似50 01 xx xx yy yy， xx xx就表示P2Server_max，yy yy 就表示P2*Server_max。诊断仪收到这两个参数之后，根据这两个参数来判断ECU的响应是否及时。

P2Client：从诊断仪成功发送请求消息到开始接收相应的响应消息之间的定时器超时数值，诊断仪在成功发出请求之后，会期望在一定的时间内收到响应，这个时间就是P2Client。

P2*Client：表示从诊断仪接收到NRC为0x78的否定响应消息到开始接收下一个响应消息之间的增强型定时器超时数值。P2*Client与P2Client类似，当诊断仪在没有超时的情况下收到NRC 0X78后，就会启动这个时间参数，在收到NRC 0X78之后，诊断仪不再发请求，只是等待ECU的下一次响应。

P3Client_Phys：从诊断仪成功发送一个不要求肯定响应（抑制肯定响应消息指示位为真）的物理寻址请求消息0到允许发送下一个物理寻址请求消息之间的最小间隔时间。

P3client_Func：从诊断仪成功发送一个功能寻址请求消息到允许发送下一个功能寻址请求消息之间的最小间隔时间。

P3Client_Phys和P3client_Func这两个参数定义了诊断仪在发送完一条UDS命令之后，下次再发送命令的最小时间间隔，分别适用于物理寻址和功能寻址的情况。在ISO24229中，它俩的值与P2Client相同。

S3Server：在没有接收到任何诊断请求信息时，ECU 保持在非默认会话状态下的时间为 S3server，ECU需要收到诊断服务才能维持在某个非default session中，或者收到诊断仪持续发送的3E服务。S3Server定义的是ECU多长时间收不到任何诊断服务复位，之后进入default session。

S3Client：在功能通信方式下，为了使得多个ECU保持在非默认会话状态，诊断仪发送功能寻址的“诊断仪在线”请求消息之间的时间为 S3client。 或者，在物理通信方式下，针对单一ECU，诊断仪发送的物理寻址请求消息之间的最大间隔时间为S3client。

1.3.11 CAN总线实现的UDS诊断--SF F CF FC

CAN总线每一帧只能传输8个字节，那么如果UDS产生的一帧超过了8个字节诊断报文，在CAN总线上，就需要进行分包，为了实现诊断报文的分包传输，15765-2总共定义了4种类型的帧类型，分别是单帧（SingleFrame）、第一帧（FirstFrame）、流控帧（FlowControl）、连续帧（ConsecutiveFrame）。单帧用于长度不超过7个字节的诊断服务请求或响应。第一帧，流控帧，连续帧用于传输长度大于7个字节的诊断服务请求或响应。

SF_DL表示单帧的数据长度

FF_DL表示首帧的数据长度：

SN表示连续帧序列号：

FS表示流控状态：

BS表示块大小：

STmin表示连续帧最小时间间隔：

BS和STmin等于0时，表示接收端可以以最快的速度来接收数据，发送端可以一次发送的 ConsecutiveFrame数量不受限制。

FigHtinG_D

关注

22
点赞
踩
32

收藏

觉得还不错? 一键收藏
3
评论
UDS诊断服务详解

数据记录值的格式和定义应该由车辆制造厂商或者系统供应商所指定，这些数据记录值可能会包含模拟量输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。服务端可能会先同时请求的数据标识符数量，首先需要由车辆制造厂商和系统供应商商讨决定。一旦收到了0x22服务的请求消息，服务端应该访问由数据标识符参数指定数据元素几率之，并且在单个22服务肯定应答报文中去传输他们的值。请求报文中可能会多次包含同一个DID值，服务端应该将这些重复的DID看作独立的DID并答复。
复制链接

扫一扫