汽车电子 - UDS

概念

参考
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
如何带参数进行传输，和带参数进行相应
通过2702也可以看出rte_call的输入输出数据

帧格式

针对基于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表示连续帧

流控帧
必须是3个字节，其他5个字节用00进行默认填充（3+5=8表示CAN帧的数据位一共就是8个字节）
3：表示流控帧
FS流状态：0,1，2

0：表示接收方（发送帧流控帧的接收方，也就是发送首帧的发送方）允许发送后续的连续帧，允许二者之间继续通讯
1：表示接收方（原发送方），进行等到，不要发送后续的连续帧，需要等到发送方（原接收方）新的流控帧的进一步指示
2：表示接收方（原接收方）溢出，没有能力再进行接收数据了，要求发送方（原发送方终止本次通信）

BS块大小

允许一次发送所有的数据，还是先发n个再发m个
00：不限制发送方（原发送方）发送连续帧的数量，也就是允许发送方一次性奖后续的所有连续帧全部发送完毕，且接收方（原接收方）不在发送流控帧
1~255：允许发送方（原发送方）能够连续发送的最大帧数，如果未发送完，则等待接收方的下一个流控帧

STime 最小间隔时间

连续帧间的发送帧的频率 ms,us（连续帧与连续帧之间的间隔时间）

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: 协议数据单元，其实就是报文

27 服务

DTC / 19 服务

DTC

ECU会周期性的进行自检，并存储DTC，一般ECU在存储DTC的时候是2个字节，2个字节会解读成5位故障码（UDS在使用19服务的时候一般会读取到3个字节）

低12位保留，翻译成DTC五位故障码的后3位
前4=2+2 作为五位故障码的前三位

00(0)，01(1)，10(2)，11(3)

19服务

在符合UDS协议规范的DTC存储机制中，ECU一般存储3个字节的DTC：（前两个字节，解读成五位故障码，是继承自）OBD协议的）+FTB（故障类型字节）