目录
UDS诊断协议是一种在汽车电子ECU环境下使用的诊断通讯协议，基于ISO 14229标准。其主要目的是为了快速准确地判断车辆或控制器的故障及其原因，从而为维修提供可靠的依据。
一：UDS诊断服务的分类和常见服务
UDS诊断服务分为6大类，共26种服务，每种服务都有自己独立的SID（Service Identifier）。常见的服务包括：
- 会话控制（DiagnosticSessionControl）
- ECU复位（ECUReset）
- 安全访问（SecurityAccess）
- 通信控制请求（CommunicationControlRequest）
- 诊断仪在线（TesterPresent）
- 诊断故障码设置（ControlDTCSetting）
- 读取数据（ReadDataByIdentifier）
二：UDS诊断服务的请求和响应格式
UDS诊断服务通过问答形式实现，请求由客户端发送给服务器，响应则由服务器发送回客户端。
若请求报文仅包含SID和可能的数据，请求格式为“SID+数据”，肯定响应格式为“SID+40+数据”，否定响应格式为“7F+请求报文里的SID+一个字节的NRC”。
如：22服务读取DID信息；
请求报文：22 02 00（02 00 为DID）
肯定响应：62 02 00 01（02 00 为DID，01表示 02 00 代表的数据）
否定响应：7F 22 NRC
若请求报文中包含子功能和可能的数据，请求格式为“SID+Sub-FunctionID+数据”，肯定响应为“SID+40+子功能+数据”，否定响应格式为“7F+请求报文里的SID+一个字节的NRC”。
如：31例程控制服务；
请求报文：31 01 02 03（02 03 为DID）
肯定响应：71 01 02 03 00
否定响应：7F 31 NRC
Service-ID：简称SID，表示诊断服务的ID，长度为固定的1Bytes；
sub-function:表示诊断服务的子服务，可以理解为诊断请求的子功能，比如85服务的01子服务表示开启故障诊断数据的更新的功能，85服务的02子服务表示停止故障诊断数据更新的功能，占1byte的固定长度。其中sub-function的最高位表示肯定响应抑制位，剩下的7个bit才表示sub-function。
如果最高位置为1，表示肯定响应抑制，在物理寻址条件下，ECU收到这条请求，不会做出肯定响应，但是会回复否定响应；
如果最高位置为0，在物理寻址条件下，ECU必须对该请求做出肯定/否定响应。
比如ECU在收到10 01、3E 00、85 02等诊断请求之后，必须做出肯定/否定响应，而收到10 81、3E 80等诊断请求之后，不会作出肯定响应。响应抑制的原因是减少ECU不必要的肯定响应，节约通信资源！！
在上面的描述中，对诊断请求的响应分为肯定响应和否定响应：
否定响应的格式为：7F SID NRC；
其中，ISO14229中规定的常见NRC码如下图所示：
三：UDS诊断服务的NRC优先级
根据ISO14229 - 2013定义：在接收到诊断请求之后，需要在处理子服务之前按照以下顺序执行NRC码的响应；
其中，最左边的为必须执行的检查，如：NRC：0x11（当前请求的服务是否支持）
中间的为配置可选的检查，如：NRC：0x33（当前请求的服务所要求的安全访问是否通过）
对服务的NRC码响应条件进行检索之后，若该服务有子服务，需要按照以下顺序执行NRC码的响应检索；
其中，最左边的为必须执行的检索，如：NRC：0x7E（当前会话下是否支持该子服务）；
中间的为配置可选的检索，如：NRC：0x24（当前请求的子服务是否满足请求顺序，例如：31 02服务之前必须先执行31 01服务，否则会报NRC：0x24否定响应码）；
在执行以上NRC检索后，可以执行各自服务的一些NRC条件检索；
四：UDS诊断服务的寻址方式
UDS诊断服务是实现人或设备与ECU控制器交流的一种语言，在总线上往往有着众多ECU设备，作为诊断设备既可以与所有的ECU一起沟通，也可以指定某一个ECU单独沟通。所以寻址方式就有功能寻址（Functionally Addressed）和物理寻址（Physically Addressed）两种。
1、功能寻址：即广播诊断请求Request，同时等待总线上的ECU给与响应。
2、物理寻址：指定发送特定诊断请求Request，等待指定ECU给与响应。
4.1：寻址方式与诊断响应的关联：
根据ISO14229 - 2013定义：诊断报文的响应需要结合寻址方式、肯定响应抑制位、服务与子服务的支持情况等条件综合判断来执行：
在物理寻址条件下，且请求的服务包含子服务时的响应行为参考下图：
在功能寻址条件下，且请求的服务包含子服务时的响应行为参考下图：
在物理寻址条件下，且请求的服务不包含子服务时的响应行为参考下图：
在功能寻址条件下，且请求的服务不包含子服务时的响应行为参考下图：
需要注意的是：在功能寻址条件下，响应的报文的长度不会大于 8 byes，多余的部分不会响应；
五：UDS相关的时间参数 -- P2,P3,S3
P2Server_max:表示的是ECU在接收到总线上的诊断报文请求后到开始响应的时间间隔，ECU必须确保一个单帧响应消息或者多帧响应消息的第一帧消息在P2Server时间内完成（成功发送CAN网络上）。
P2*Server_max：从ECU发送了NRC为0x78的否定响应消息到开始发送下一个响应消息之间的时间间隔。
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在没有接收到任何诊断请求的前提下保持非默认会话激活状态的时间，一旦ECU在非默认会话下接收到了任何诊断请求偶会重新计时；
S3Client：在功能通信方式下，为了使得多个ECU保 持在非默认会话状态，诊断仪发送功能寻 址的“诊断仪在线”请求消息之间的时间为 S3client。 或者，在物理通信方式下，针对单一ECU， 诊断仪发送的物理寻址请求消息之间的最大时间间隔为S3client。
六：基于CAN总线的UDS诊断报文规则
待
七：UDS诊断相关的CANTp层的时间参数
待
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
