不只是诊断的统一诊断服务UDS

统一诊断服务UDS，看名字就知道这一定是有发有收的服务，但众所周知，在CAN总线上“只知接收方不知发送方”，因此UDS一般会设置一个仲裁位作为返回地址

由于标准的CAN每帧仅能发送8字节数据，而有的数据（比如VIN码17字节）远大于这个长度，想要在CAN总线上运行UDS则需要对于数据分片传输，即单帧与多帧

因此，一次完整的UDS通讯将由三部分组成：发送/接收地址，帧类型，数据

目前UDS主要运行在两种网络上，一种是以CAN为代表的总线网络，称为DoCAN；另一种是以车载以太网为载体的DoIP，下文的UDS默认为DoCAN

UDS寻址

UDS寻址分为功能寻址和物理寻址两种

功能寻址类似于广播通讯，一般由诊断仪向一特定仲裁位（OBD标准定义为7DF，但随着UDS常复用OBD接口，标准的OBD一般包含在UDS的0x19、0x22等子服务中）发送UDS请求，所有收到的ECU都会返回消息

物理寻址则是一对一，诊断仪向ECU的UDS专用仲裁位发送请求，该ECU将以特定仲裁位（常见为发送仲裁位+8，但不一定）做出响应

UDS分片

UDS分片主要分为单帧与多帧
多帧的传输又由首帧、连续帧、控制帧组成：发送方需先发送首帧，将标识数据的长度；接收方需发送流控帧，告诉发送方一次发多少数据或停止发送、暂缓发送等；发送方接收到流控帧后，根据流控帧继续发送数据

每帧的首字节的高四位用于表示帧的类型：

单帧SF：0b0000+4位DL+Data
首帧FF：0b0001+4位DL前半段+1字节DL后半段+Data
连续帧CF：0b0010+4位帧序号+Data
流控帧FC：0b0011+4位帧状态+1字节块大小（到下一个流控帧前发多少帧）+1字节发送间隔毫秒

UDS收发

UDS的数据段中自然存放的就是请求/响应数据了，常见格式如下：

请求仅SID
- 积极响应(SID+0x40)
- 消极响应7F+SID+NRC（消极响应代码），后续都一致，节省篇幅省略
请求SID+SF（SubFunction）
- 积极响应(SID+0x40)+SF
请求SID+DID（DataID）
- 积极响应(SID+0x40)+DID+Data
请求SID+SF+RoutineID
- 积极响应(SID+40)+SF+RoutineID+Status

安全测试中常用的UDS子服务

UDS在合规测试中经常用到，常见涉及到的子服务如下：

0x10：会话控制，切换 ECU 的工作状态（如进入调试、编程模式）
0x11：复位服务，请求ECU 重启，根据SF采用不同的重启方式
0x22：读数据，通过DID获取ECU内部存储的信息
0x27：安全访问，通过 Seed & Key 算法解锁高权限服务
0x28：通信控制，开启或关闭 ECU 的应用层报文（非诊断报文）发送或接收，常用于刷写前清理总线带宽
0x2E：写数据，通过DID修改ECU的配置或参数
0x31：例程（Routine）控制，如擦除内存、自检、校验
0x34：请求下载，启动数据传输，用于协商传输参数
0x35：请求上传，与0x34反向
0x36：实际传输数据块，在0x34或0x35之后使用
0x37：请求退出传输，数据传输完成后，通知ECU结束传输流程，通常会触发 ECU 进行数据完整性校验
0x3E：会话保持，告诉 ECU 诊断仪还在线，用于保持非默认会话（如扩展/编程会话）不超时退回，通常 2-4 秒发一次

详细一点的可以查看这篇博客（~~其实没有必要~~）CANFD协议与UDS服务|BornChu’s Blog, Blog!

浅谈DoIP

在前文中提到，UDS服务跑在车载以太网上就是DoIP，那么从TCP/IP模型上看，必定是在应用层，也就是基于TCP实现的
由于TCP协议每次可发送的数据远比CAN总线多，并且自身有实现分片，所以并不需要DoCAN的分片标识位，因此直接发送UDS诊断报文信息即可
可连接的ECU（通常是OBD网关）在获取到IP地址后，会一直向外发送DoIP广播报文直至连接成功，公告报文中包含了ECU的UDS地址和端口，可通过对应信息建立DoIP连接实现收发

从连接的协议报文上看：