本文详细解释了ISO15765-2协议，涉及单帧和多帧传输方法，以及首帧、流控帧和连续帧的结构。重点介绍了如何通过CAN总线高效传输长数据，如VIN码等。
目录
1 ISO15765-2协议简介
1.1 ISO15765-2协议的诞生
经典CAN数据链路层最大能够支持8个字节，但ISO 14229协议并不仅仅是为了CAN总线设计的，最大容量达到4095个字节。比如VIN码是17个字节，CAN总线必然需要传递3帧才能传完VIN码，那么如何科学、快捷、安全地将多个字节通过经典CAN来进行传输，就成了一个需要解决的问题。ISO 15765-2 协议由此诞生。
1.2 协议的作用
协议最主要的目的就是把数据转换成能适应CAN总线规范的单一数据帧，从而进行传输。如果将要传输的报文长度超过了CAN数据帧的长度，则需要将报文信息进行拆分后传输，每次至多可以传输4095个字节长度的报文。
诊断数据的传输按照传输数据字节的大小分为单帧（SingleFrame）和多帧，诊断数据长度（不包含PCI）小于等于7bytes时采用单帧传输；诊断数据长度（不包含PCI）大于7bytes时采用多帧传输，多帧传输的过程中包含首帧（FirstFrame）、流控帧（ConsecutiverFrame）和连续帧（FlowControl），下图介绍了这几种帧类型所包含的信息。
1.3 PDU简介
PDU根据ISO的分层有不同且明确的称谓：
（1）在数据链路层传递的PDU为L-PDU
（2）在网络层传递的PDU为N-PDU
（3）在交互层传递的PDU为I-PDU
这里主要介绍N-PDU的相关知识，N-PDU包含以下几个部分：N-AI，N-PCI，N-Data。
N-AI：包含了PDU的地址信息，源地址、目标地址以及寻址方式等等。
N-PCI：包含协议控制信息，说明帧类型，帧的有效长度等。
N-Data：包含诊断报文传输的具体数据
2 单帧传输
2.1 单帧传输介绍
单帧顾名思义就是通过一帧报文可以传输完当前请求的报文数据。当诊断数据长度小于等于7时，再加上一个字节的PCI控制信息就是小于等于8，可以在一帧CAN报文上传输，所以不需要进行分包。
图1：单帧传输形式
图2：单帧数据格式
数据域的第一个字节高4 Bit值为0000，标识这是一个帧SingleFrame，低4 Bit是SF_DL，即DataLength，描述后面有几个有效字节。
2.2 单帧传输举例
以ECU进入扩展会话为例：
Request：02 10 03 55 55 55 55 55 response：06 50 03 00 32 01 F4 AA
备注：（1）Request帧中，02的0表示单帧，2表示后面2个有效字节，10 03表示进入扩展会话，55为填充位；（2）Response帧中，06的0表示单帧，6表示后面6个有效字节，50 03表示肯定响应，00 32 01 F4表示时间参数，AA为填充位。
图3：单帧传输数据流
3 多帧传输
如果诊断报文超过7个字节，一帧CAN报文无法承载，则需要按照下面的流程进行分包发送：
图4：多帧传输数据流
备注：以上ECU发送的连续帧数量只是用于说明传输形式，实际一次发送连续帧数量与诊断仪发送的流控帧参数有关，具体流控帧参数定义参考下文中流控帧介绍部分。
3.1 首帧（FirstFrame）
首帧数据段格式如下：
图5：首帧数据格式
数据域的第一个字节高4 Bit值为0001，标识这是一个帧FirstFrame，第一个字节低4 Bit加上第二个字节是FF_DL，即DataLength，描述后面有效字节的个数，最大为4095个。
3.2 流控帧（FlowControl）
流控帧数据格式如下：
图6：流控帧格式
数据域的第一个字节高4 Bit值为0011，标识这是一个帧FlowControl，第一个字节低4 Bit为FS，即FlowStatus，FlowControl有0，1，2三种状态，分别命名为ContinueToSend(CTS)，Wait(WT)，Overflow(OVFLW)；
FS的三种状态对应的功能如下图所示：
图7：FS状态对应图
BS：指示ECU一次可以发送多少个ConsecutiveFrame，当发送ConsecutiveFrame数量达到BS时，需要诊断仪再次发送一个FlowControl开启下一波的ConsecutiveFrame发送；如果BS=0，则可以发送无限个连续帧，无需再次发送FlowControl。
Stmin：定义上一个连续帧确认接收（ACK）到新的连续帧开始发出的最小间隔时间。
3.3 连续帧（ConsecutiverFrame）
连续帧数据格式如下：
图8：连续帧数据格式
数据域的第一个字节高4 Bit值为0010，标识这是一个帧ConsecutiverFrame，第一个字节低4 Bit为SN，SN为标识连续帧的序号，从1开始，每发送一次连续帧增加1，最大为F，计数满之后从0开始循环计数。
注意：计算满之后SN是从0开始计数，不是从1，第一个循环之所以从1开始计数，是因为有首帧的存在，后续循环没有首帧，故从0开始计数。
4 举例
以读取DTC为例，诊断仪发出请求，读取ECU的DTC，ECU响应的DTC码超过8个字节，需按照15765协议进行拆包：
03 19 02 08 55 55 55 55（诊断仪发送的SigleFrame的request）
10 33 59 02 19 01 00 07（ECU以FirstFrame开始传输的response）
30 00 00 55 55 55 55 55（诊断仪发送的FlowControl）
21 09 03 05 02 09 05 04（ECU发送的ConsecutiveFrame）
22 07 09 05 06 06 09 05（ECU发送的ConsecutiveFrame）
23 08 03 08 07 01 05 08（ECU发送的ConsecutiveFrame）
24 07 01 06 08 07 01 0C（ECU发送的ConsecutiveFrame）
25 08 07 01 0D 08 07 03（ECU发送的ConsecutiveFrame）
26 07 09 08 01 01 09 09（ECU发送的ConsecutiveFrame）
27 01 07 09 AA AA AA AA（ECU发送的ConsecutiveFrame）
扫一扫
9万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
