汽车电子 - UDS
- 概念
- 基本概念
- 分类
- 请求与响应
- 寻址信息
- 物理寻址
- 功能寻址
- 协议格式???
- 750/758厂家自定义的吗???, 所有的UDS服务都在这里边吗???,代码中的Indata和outData???
- 帧格式
- 单帧传输 SF
- 多帧传输
- UDS服务
- 10 服务
概念
参考
https://zhuanlan.zhihu.com/p/162710671
https://zhuanlan.zhihu.com/p/438099472
基本概念
客户端:诊断工具
服务端:ECU
UDS不止与诊断有关,还可以有诊断、刷写、升级都可以通过UDS诊断进行操作
分类
6大类26个服务
每个服务有一个唯一的服务ID,也叫SID
- 诊断和通信控制管理功能相关的
10 :诊断会话
11:ECU复位,重启
27:安全访问(解锁ECU服务),ECU写入数据必须,必须要得到厂商提供的安全秘钥,然后根据秘钥利用27服务进行解锁ECU
3E:保持ECU和诊断仪通信
- 故障码传输功能类
19:读取ECU存储的故障的信息,
14:清楚ECU故障码
- 数据传输类的服务
22:根据想读的那一项数据的数据ID来读取ECU现在存储的运行时的一些数据
2E:向ECU写入一些指定的数据
- 输入输出控制类功能
2F: 服务输入输出控制(模拟我们的车身控制模块去控制车窗升降) ,模拟输出一个让车窗升降的信号,来控制,验证模块正常
- 例程控制服务
31: 检查可刷写前置条件的一个程序(开发制造),然后用31服务启动/停止个程序
- 上传、下载服务,从ECU读取/写入,刷写ECU
34
36
请求与响应
UDS请求和响应
诊断仪请求 ECU给响应
诊断仪:CANoe/VBA工具/手持诊断仪
读取工作电压:诊断仪发送(诊断)报文
ECU返回的结果就是诊断响应(报文)
请求/响应规定
报文格式:SID(服务ID)+对应服务中某一项的数据ID
肯定响应:(SID+40)+服务特有的响应
否定响应:7F+SID(否的是哪个请求)+否定响应码(失败的原因是什么)
否定响应码NRC:3个字节
7F(固定)
SID(否定的响应服务)
NRC:
- 11 请求的服务ID不支持
(数据ID项(不是SID)不被支持 <- 请求22 02 07中02 07代表某项数据的数据ID,不被当前ECU支持)
诊断仪发送的请求就没有做进去,就是ECU不支持服务 - 12 服务SID下的子功能不支持
- 22 先决条件不满足,本来是在扩展会话下进行,但是在默认会话下执行请求,所以就是先决条件不满足
- 31 参数数据溢出,
- 33 不满足安全策略,想用2E服务写入一些数据,但是必须先解锁ECU,如果没有解锁那么就报33错误,必须先解锁
- 35 秘钥不匹配,如果想用27服务解锁ECU时,ECU需要诊断仪提供一个秘钥,如果秘钥不匹配那么报错
- 36 解锁次数上限
- 78 不代表响应失败,值代表收到请求,但是没有马上返回响应,ECU会等一会再返回响应
寻址信息
源地址:发送方
目标地址:接收方
诊断请求、响应的服务信息,包含在(这)一帧CAN报文中,(每一帧CAN报文对应一个ID)
针对基于CAN协议的UDS诊断,UDS诊断发出和接收的报文就是CAN报文,
请求和响应的地址信息就是CAN报文的ID
请求和响应的服务信息就是CAN报文中的数据域的字节
物理寻址
物理寻址和功能寻址只针对诊断请求,在诊断响应中并没有这个概念
诊断仪与单个ECU之间的通讯,(一对一)
诊断仪通过物理寻址的方式发送请求报文时,只有指向那个ECU进行响应
功能寻址
物理寻址和功能寻址只针对诊断请求,在诊断响应中并没有这个概念
诊断仪与多个ECU之间的通讯,(群发,所有的指向对象都会进行响应)
7DF,作为功能寻址的报文ID (诊断仪发7DF,其他ECU发送各自的响应报文ID)
协议格式???
750/758厂家自定义的吗???, 所有的UDS服务都在这里边吗???,代码中的Indata和outData???
750对应TX
758对应RX
如何带参数进行传输,和带参数进行相应
帧格式
针对基于CAN的UDS服务,CAN帧数据场中,最多传输8个字节的数据
UDS报文帧分类
单帧CAN传输UDS报文(一帧CAN报文能装的下请求和响应)
多帧CAN传输UDS报文(一帧CAN报文不能装的下请求和响应)
单帧传输 SF
单帧传输,一个CAN帧最多传输8个字节,如果UDS请求和发送报文要传输的字节小于8个字节,就使用单帧传输
单帧例子:请求:02 10 03 00 00 00 00 00 其中02中的0就表示单帧,2表示有2个有效字节
响应:06 50 03 00 32 01 F4 00 其中06中的0表示单帧,6表示有6个有效字节
多帧传输
- 首帧
- 流控帧
- 连续帧
发送方发送首帧FF给接收方,接收方必须立刻返回一个流控帧FC(流控帧的作用:告知发送方接下来该怎么继续发送,如何发送后续的帧,后续的帧每隔多久发送一个帧… 见下面的bash)
发送方按照接收方流控帧的指示,继续发送帧(按照指示发送完成后,需要等待下一个流控帧的指示)
首帧 -> <-流控帧(高速发送方,后续的多个连续的帧,最少间隔多少发送一个帧,最多发几个帧,能不能发连续帧)
连续帧 -> (发送方接收流控帧的指示,发送多个连续帧)
...
连续帧 ->(等待接收下一个流控帧的指示)<- 流控帧
首帧:1表示首帧,
流控帧:3表示流控帧
连续帧:2表示连续帧
UDS服务
10 服务
10服务- 诊断会话控制
诊断会话:
会话(聊天),会话分场合,
诊断仪-ECU之间通信,就是需要构建一个会话的场合
默认会话1001:读取数据、故障码、重置ECU,22、19、14、11
扩展会话1002:解锁ECU,控制输入输出,2E,2F,27
编程会话1003:刷写ECU的相关服务:34,35,36,38,对ECU进行编程,刷写固件程序
编程会话和扩展会话,为非默认会话
ECU上电默认就是默认会话
如果在跳转到非默认会话后,没有使用非默认会话下的服务,那么ECU就会跳转回默认会话下,一般推荐5s
进入编程会话必须先进入扩展会话
USD 服务
请求报文:10+会话子功能
响应报文:肯定响应(10+40)+会话子功能+会话超时时间(规定)+增强型会话超时时间(78响应码相关)
PDU: 协议数据单元,其实就是报文