【UDS学习笔记】

微光城上

已于 2024-11-05 20:49:17 修改

阅读量3.4k

点赞数 29

文章标签：职场和发展经验分享

于 2024-10-30 22:43:25 首次发布

本文链接：https://blog.csdn.net/weixin_43405695/article/details/143374380

版权

UDS学习笔记

文章目录

UDS学习笔记
前言
一、UDS是什么？
二、UDS协议的格式是什么？
- 1.请求的格式
- 2.响应的格式
三、接收方如何区分SF和DID？
四、UDS和1939故障诊断的区别？
五、UDS和J1939在总线上可以共存吗？
六、UDS是怎么在CAN线上实现传输的？
七、OBD与UDS的关系？
原文连接

前言

以前没有接触过UDS，在网上有很多相关文章讲的都很好，但因为之前没有接触过，没有一个系统的概念，在看网上看文章时，有时候会有一些疑问，于是再去找相关文章，看过很多文章后才算大体有了了解，为了防止以后忘记，将自己在学习时遇到的问题记录下来，同时也为了可以给刚接触UDS服务的人提供一些帮助。因为刚接触UDS理解上肯定是有局限性，仅供参考，这篇笔记是在多篇文章基础上写的，为了偷懒，有些内容直接复制别人的文章，我会在笔记最后附上链接，大家看一下原文可以更好的理解。

一、UDS是什么？

UDS（Unified Diagnostic Services）是ISO 14229定义的一种汽车通用诊断协议，通过该协议可以实现车辆故障诊断，信息读写。在ISO14229-1中定义了UDS诊断包括6大类，26种服务，如图1所示，每种服务都有自己独立的ID，即SID（Service Identifier）[1]。UDS是一种对话服务，只有向相关的控制器发出请求，控制器才根据请求内容做出相应的应答。
图1 UDS服务

二、UDS协议的格式是什么？

1.请求的格式

UDS请求格式分为4类[2]：
格式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中所示[3]，也就是说当确定使用哪种服务时就已经确定它有没有子功能了，接收器自然是能分辨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 )

所以在你选择使用哪个服务的时候就决定了是否带子功能，所以接收方是可以分辨出SF和DID的，并给出相应的响应。

四、UDS和1939故障诊断的区别？

UDS和1939故障诊断的主要区别是UDS是请求/应答机制，通过故障诊断19服务来获取故障信息，而J1939通过DM1将当前故障主动连续发送到总线上，当然J1939中其他故障报文也采用请求/应答机制。

五、UDS和J1939在总线上可以共存吗？

UDS和J1939均定义了在不同总线上传输的格式，以CAN总线为例，这二者均是在CAN协议的仲裁场设置ID，以便某个或多个控制器能够识别报文，并给出响应。在总线上统一报文ID的协议格式，就要想办法将UDS的CAN报文ID使用J1939协议格式表示。那为什么要统一ID的协议格式呢？想想看如果有两套CAN报文ID的协议格式，ECU就需要有两套算法来解析报文，这不就增加ECU的负担了嘛。
首先看一下CAN扩展帧的格式，一个CAN报文包含帧起始、仲裁场（即报文ID）、控制场、数据场、校验场、帧结束。J1939协议其实就是对CAN扩展帧的ID进行了再定义，对其报文的分配给出了统一的定义，将PDU作为协议数据单元，即报文ID和数据，如图7所示。
PDU里又定义了参数组编号PGN，就是用某些位来分组，每组固定表示某些信息，如图8所示，具体含义可以上网搜一下，有很多介绍。
UDS有两种方式与J1939在CAN总线上共存。一种是使用J1939中的某个PGN参数组，其中PF是固定的，PS作为接收控制器的目标地址，SA作为发送控制器的源地址，如下图9所示[4]。J1939中对DM的故障请求也是这种格式，这就做到了UDS和J1939在传输格式上的统一。

在这里插入图片描述

在ISO 15765-4中定义了UDS的固定格式，如下图10所示，就是将PF固定为0xDA或0xDB，其中PF为0xDB表明进行功能寻址，支持功能寻址的ECU都将给出响应。PF为0xDA表明进行物理寻址，只有唯一的ECU进行响应。响应报文的ID格式就是将报文ID中的目标地址和源地址交换了过来。
另一种是将PGN中的数据页（EDP+DP）置1，目标地址和原地址都占 11位，如下图11所示，这种方法不常见，了解不多。

在这里插入图片描述

六、UDS是怎么在CAN线上实现传输的？

上文讲的是UDS和J1939如何使用统一报文的ID格式，而这里讲的就是UDS数据场的格式。因为CAN协议一次最多可以携带8个字节数据，当要传输的数据超过8字节时，就要对数据拆分发送，接收器还要对拆分的数组进行重组，因此在ISO 15765-2中规定了传输方式。J1939中要发送超过8字节数据，是靠TP.CM和TP.DT报文来来成的。
UDS网络层协议数据单元（N_PDU，Network_Protocol Data Unit）包含N_AI，N_PCI，N_Data，即地址信息，协议控制信息和数据。在CAN协议中，N_AI位于CAN报文帧的ID处，就是上文讲的内容，N_PCI和N_Data位于CAN报文帧的数据场，其中N_PCI至少占1个字节，因此一帧CAN报文能够传输的有效数据最多为7字节，如图12所示。

在这里插入图片描述
J1939协议中N_AI格式可参考上文内容。
N_PCI标识网络层帧的类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC），其中FF、CF、FC这些帧是为了实现传输长度超过7字节的数据，如下图13所示。

CAN报文中的数据场第一字节的高4位用来标识当前报文是哪种帧，后4位不同帧的使用不同：

1.单帧(SF)

单帧低4位表示数据的长度，如图14所示[5]，有效数据为3字节。
在这里插入图片描述

2.首帧(FF)

首帧主要目的是告诉接收器接下来要接收多少数据（字节），好让接收器有心里准备，低4位与第二字节共12位表示数据长度（最大4095个字节）。如图15所示表示要传输0x18个字节数据，即24个字节。

在这里插入图片描述

3.流控制帧(FC)

流控帧共3个字节，是接收器告诉发送器接下来要不要发送，怎么发送，发送间隔是多长，如图16所示。
在这里插入图片描述
第一字节低4位为FS：表示流控状态参数，0表示的是继续发送(CTS)，1表示的是等待(WT)，这两个配合使用可以控制发送速度；2表示溢出(OVFLW)，用于接收者告诉发送者数据过大，在首帧后的第一条流控帧应答。
第二字节为BS：表示的是块的大小，即发送端一次性可以向接收器发送多少个连续帧。要注意的是，BS表示的是在发送端没有再次接收到流控信号时，能够发送的帧的数目。而当BS为0则表示，在数据传输的时，接收端不再发送流控帧了。发送端应当连续不断的发送数据。
STmin：表示的是两个连续帧(FF)的最小时间间隔，不同的数值表示不同的时间间隔，如图17所示。为什么只设置最小间隔？因为发送间隔太小，处理器不能即使处理，而最大时间间隔即超时时间是在控制器中已经设置好的，具体各种帧发送接收的超时时间可以自己查一下。
在这里插入图片描述

4.连续帧（CF）

第一字节低4位为连续发送帧的序号，从0到15后，又置零，注意首帧也占一个SN，因此首帧之后的连续帧需要从1开始计数。
如图18-19所示分别为多帧发送的流程图和例子。
在这里插入图片描述

七、OBD与UDS的关系？

OBD（全称：On Board Diagnostics），即车载自动诊断系统，是汽车排放和驱动性相关故障的标准化诊断规范，有严格的排放针对性，其实质就是通过监测汽车的动力和排放控制系统来监控汽车的排放。UDS的诊断服务代码是从0x10开始的，小于0x10的代码则被OBD用了。OBD是国家强制要求的协议，为了降低同时需要实现两套协议的成本，ISO 27145 标准化文件将OBD与UDS统一，使用UDS中的诊断服务来替代OBD相关的诊断服务。具体替换方案如下图20所示[6]：

在这里插入图片描述