UDS诊断服务位于应用层，应用层下面是网络层，所以诊断数据从应用层下压到网络层，由网络层进行数据的解包、打包、传输

网络层

网络层用的协议是CAN协议，规范是ISO 15765-2，它是诊断对网络层的说明

我们知道UDS是应用层里的诊断功能的协议，它的结构是：

服务标识符（Service ID） + 子功能（SubFunction）/数据位（DataIdentifier） + 数据(Data)

那应用层的结构是：

应用层头部 + UDS数据结构，这里的应用层头部就是：源地址（发送节点地址）+ 目标地址（接收节点地址）+ 类型。。。

网络层是把应用层头部映射成网络层头部，UDS数据映射成网络层数据，但是由于数据帧的标准长度只有8个字节，如果UDS数据太长则需要分多次发送，所以还需要留有一到两个字节用来控制是按照单帧机制发送还是多包机制发送

单帧

如果UDS数据在网络层是单帧，那么用来表明单帧的标志N_PCI是一个字节，由于网络层标准帧的长度是8个字节，N_PCI占一个字节，UDS数据只能有7个字节

单帧的N_PCI是一个字节，结构是：

如果网络帧byte0的高四位是0000，表示单帧，低四位用来表示UDS数据长度

如果UDS数据小于7个byte，网络层数据填不满8个字节，怎么办？用固定值填充即可

比如发10 03诊断会话请求，网络层数据帧应用是：

02 10 03 50 50 50 50 50 （这里用50填充空缺的byte位）

多帧

如果UDS数据大于7个字节，那么在网络层无法通过一个网络帧发完，就必须把数据分成多帧发送，此时的N_PCI不可能和单帧时一样

- 首帧

如果网络帧byte0的高四位是0001，表示多帧的第一帧，低四位和byte1，共12位表示UDS数据长度

- 流控帧

那是不是发完首帧后接着发第二帧呢？并不是。Tester给ECU发完首帧后，需要等待ECU回复确认信息，确认什么？确认ECU此时的状态，是否忙碌？有没有空？允许连续发多少帧？只有确认了这些，Tester才能接着发第二帧第三帧…

所以流控帧就是ECU收到首帧后回复的网络帧，流控帧的数据结构是：

流控帧是ECU告诉Tester接下来要如何发送连续帧，byte0高四位0011，表示流控帧，低四位是状态位，0表示Tester可以继续发送，1说明Tester还要等待，2表示已经溢出，不能再发送

byte1表示Tester接下来可以一次连续发送多少条连续帧 byte2表示时间，时间间隔？（不懂）

- 连续帧

Tester只有收到流控帧并确认可以发送，才能继续发送连续帧，一次连续发送的帧数也是根据流控帧确定的

连续帧的byte0的高四位是0010，低四位是连续帧的序列号，从1开始，一直到15，如果超过了15，又从1开始

当发完流控帧规定的帧数后，Tester又需要等待ECU的流控帧，确认是否继续发送，发送多少条

整个流程如下：

数据链路层

常规寻址模式-仅用11位ID

常规固定寻址模式-仅用29位ID

扩展寻址模式-仅用11位ID

混合寻址模式-29位ID

混合寻址模式-11位ID