UDS 诊断报文格式
文章目录
- 网络层目的
- N_PDU 格式
- 诊断报文的分类：单帧、多帧
网络层目的
N_PDU(network protocol data unit)，即网络层协议数据单元
网络层最重要的目的就是把数据转换成符合标准的单一数据帧（符合can总线规范的），从而进行数据传输。报文信息每次最多传输4095个字节（基于can），但是单帧长度最多为8个字节，此时需要将报文进行拆分传输。
N_PDU 格式
| N_PDU 格式 | ||
|---|---|---|
| 地址信息 | 协议控制信息 | 数据区 |
| N_AI（Address Information） | N_PCI（Protocol Control Information） | N_Data |
- N_AI 包含了目标地址、源地址、可能还有远程地址等所有与地址有关的信息，通常就是指CAN报文的ID
- N_PCI 协议控制信息，表示帧类型：SF，FF，CF，FC 和 数据长度
- N_DATA 数据
对于CAN诊断通信，我们可以通过分析每个CAN帧数据域的第一个字节来确定它属于四种不同类型中的哪一种。
诊断报文的分类：单帧、多帧
在传输协议（TP，Transport Protocol）层面，我们将诊断消息分为两大类：单帧和多帧。
- 单帧消息（Single Frame）：单帧消息只包含一个N_PCI，即单帧。它们适用于较小的诊断消息，可以在单个CAN帧中传输完整的诊断数据。
- 多帧消息（Multi-Frame）：多帧消息分为三种不同的N_PCI类型，包括首帧、流控制帧和连续帧。这些消息用于传输较大的诊断数据，需要分成多个CAN帧来传输。
- 首帧（First Frame）：首帧包含了诊断数据的一部分，并提供了有关数据总长度的信息。
- 流控制帧（Flow Control Frame）：流控制帧用于通知发送方可以继续发送数据帧的数量。
- 连续帧（Consecutive Frame）：连续帧包含了较大诊断数据的剩余部分，根据流控制帧中的信息，发送方可以持续发送这些帧。
| N_PDU类型 | N_PCI (Byte1 - Byte 8) CAN2.0为例 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | ... | Byte 8 | ||||
| Bit 7-4 | Bit 3-0 | |||||||||
| 单帧(SF) | N_PCI Type = 0 | SF_DL <= 7 | N_Data | |||||||
| 首帧(FF) | N_PCI Type = 1 | N_PCI Type = 1 | 7 < FF_DL <= 4095 | N_Data | ||||||
| 首帧(FF) | N_PCI Type = 1 | 0 | 0 | 4095 < FF_DL | N_Data | |||||
| 流控帧(FC) | N_PCI Type = 3 | FS | BS | STmin | reserve | |||||
| 连续帧(CF) | N_PCI Type = 2 | SN (0-F循环计数) | N_Data | |||||||
-
SF_DL ：单帧的数据长度
-
FF_DL ：首帧的数据长度
-
FS (Flow State) 流状态：
- 0 ： 继续发送
- 1 ： 等待
- 2 ： 溢出，即第一帧中的FF_DL信息的长度超过接受实体缓冲区的大小）
-
BS 表示 允许一次可连续发送连续帧
CF的次数 -
STmin 表示 发送方发送连续帧
CF与连续帧CF间的最小间隔时间