UDS诊断协议

UDS

主要功能：读取故障，数据传输，上传下载，复位等

借鉴参考了shnsxz大佬的博客
借鉴参考了fish_study_csdn大佬的博客

诊断请求

第一字节

为了解决数据过长，即分包的问题，15765-2总共定义了4种类型的帧结构
表示四种帧的类型主要靠byte1的高四位，单帧为0，首帧为1，连续为2，流控为3

在这里插入图片描述

在单帧的情况下(即)，SF_DL代表后面有几个字节数据，如果有没有使用的字节，通常要用0x55或0xAA来填充。

在这里插入图片描述

分包情况的工作流程，如下图所示

在这里插入图片描述

首先，发送端通过FF（FirstFrame）启动通信，其中前两个字节的高位4bit标识为0001代表FF，低4bit与第二个字节共同表示总数据长度。接着，接收端回应FC（FlowControl），首字节高4bit为0011，低4bit的FlowStatus和第二个字节的BlockSize、第三个字节的SeperateTime共同指示接收速率。FlowStatus存在三种状态：CTS（0）、WT（1）、OVFLW（2）。
- FlowStatus的状态：FlowStatus为0时，允许发送ConsecutiveFrame；为1时要求暂停发送，恢复时再发FlowStatus=0通知；若因资源限制无法接收数据，则发送FlowStatus=2的FlowControl。
- Stmin的状态：由控制图可知，Stmin的大小控制的是上一帧CF结束到开始下一帧CF中间的最小时间间隔
- BS的状态：BS的大小是CF帧在没有流控帧的情况下能发多少帧，例如BS为5，那么CF能够发五帧，然后就要看新的流控帧如何调配。
分段传输的诊断服务举例：
这是一个读取DTC的命令和应答。
03 19 02 08 55 55 55 55 （诊断仪发送的SingleFrame的request）
10 33 59 02 19 01 00 07 （ECU以FirstFrame开始传输的response）
30 00 00 55 55 55 55 55 （诊断仪发送的FC）
21 09 03 05 02 09 05 04 （ECU发送的CF）
22 07 09 05 06 06 09 05 （ECU发送的CF）
23 08 03 08 07 01 05 08 （ECU发送的CF）
24 07 01 06 08 07 01 0C （ECU发送的CF）
25 08 07 01 0D 08 07 03 （ECU发送的CF）
26 07 09 08 01 01 09 09 （ECU发送的CF）
27 01 07 09 AA AA AA AA （ECU发送的CF，此时传输结束）
BS和STmin等于0时，表示接收端可以以最快的速度来接收数据，发送端可以一次发送的CF数量不受限制。

其余字节

UDS报文

有子功能
- 1byte：Service ID(SID)，服务标识符，相当于CCP的CMD，代表了这条诊断命令执行的什么功能。
- 1byte：Sub-function，当前服务标识符具体的操作，代表当前诊断服务的具体操作
  - 其中Sub-function的8个bit，最高位的1bit用于抑制正响应。当最高位为1时，不会给出正响应；为0，给出正响应。
- xbyte：Parameter，当前功能下的发送参数
- 例如：31 01 08 09为开启软件刷写检查，31 02 08 09为关闭
  - 31为服务标识符，01为子功能ID，08 09为具体参数
没有子功能
- 1byte：Service ID，服务标识符
- xbyte：Parameter，当前功能下的发送参数

通用介绍

正响应的意思是执行成功后，服务端返回报文报告执行成功
负响应的意思是执行失败后，服务端返回报文报告执行失败

负响应返回的报文：最高字节固定为7F，第二字节为被拒绝的SID，后续字节为被拒绝的原因
- 发送报文：27 05
- 回复：7F 27 13
正响应返回的报文：最高字节为SID基础上加上0x40，次高字节为子功能ID，后续表示发送的数据
- 发送报文：27 05
- 回复：67 05 01 01 01
诊断会话包含三个子功能：01 Default默认会话，02 Programming编程会话，03 Extended扩展会话，
- ECU上电后，一般处于默认状态
- 编程会话：可以进行软件刷写等一系列操作
- 扩展会话：大部分诊断数据读写
如图为UDS诊断协议图片，进入01会话成功，进入02会话失败，进入03会话成功