UDS诊断服务详解_uds诊断 service f15a bcd格式

会话模式	如何进入	权限
默认会话	通常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表示连续帧序列号：

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年嵌入式&物联网开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上嵌入式&物联网开发知识点，真正体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新！！

，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**

[外链图片转存中…(img-1rrdl98p-1715601951906)]

[外链图片转存中…(img-qysmsrpe-1715601951907)]

[外链图片转存中…(img-LsG3FUQb-1715601951907)]

[外链图片转存中…(img-1ClxULhQ-1715601951908)]

[外链图片转存中…(img-BEURRJih-1715601951909)]

[外链图片转存中…(img-LXbPoqVP-1715601951909)]

[外链图片转存中…(img-y81AwwTO-1715601951910)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上嵌入式&物联网开发知识点，真正体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新！！