商用车CAN总线多帧数据通讯

蔺春明，王守胜，高美芹，俞燚

（安徽江淮汽车集团股份有限公司，安徽 合肥 230601）

前言

CAN数据包的长度不超过8个字节，在诊断等场合下会需要传输几十甚至上百字节的数据，为了解决这种情形下的应用矛盾，目前有两种较好的方案：一是ISO 15765-2标准中在网络层定义的多帧数据通讯；二是SAE J1939-21标准在数据链路层中也定义了多帧数据通讯，二者虽然都是对于多帧数据通讯的实现，但是在实现方式、最大通讯数据量、超时、错误处理等上存在较大的差异，下面分别分析两种多帧数据通讯以及二者之间的差异、优劣、应用趋势、发展前景等。

1 ISO 15765-2多帧数据通讯

ISO15765协议在传输多帧数据的过程中需要对报文进行组包、分包和流控制（FC），ISO15765协议是通过一个控制信息来实现的。

1.1 控制及数据结构

ISO15765定义了一个协议控制信息（PCI）来完成数据的通讯，通过PCI将数据分为单帧（SF）、第一帧（FF）、连续帧（CF）和流控制帧（FC）4种类型的消息帧，通过数据域的PCI区别帧功能类型（本文仅对常规寻址、常规固定寻址进行说明，其他寻址方式的 PCI填充信息会稍有差异）。表1描述了这几种帧的数据域结构。

表1 数据域结构

表2～表4描述了实现多帧数据通讯的四种PDU类型及数据域结构信息含义：

第一帧的0字节的高4位填充1，表示PDU的类型为第一帧，0字节和1字节共同组成数据包的长度，共12位，所以ISO 15765-2定义的多帧数据通讯的最大数据量为4095字节；2～7字节填充第一帧数据。

表2 第一帧的数据域结构描述

表3 流控制帧的数据域结构描述

表4 连续帧的数据域结构描述

1.2 数据通讯过程

图1描述了一个完整的基于ISO 15765-2协议定义的多帧数据通讯过程。

图1 多帧数据通讯过程

发送节点从应用层接收数据后，来判断是属于长数据还是短数据。如果数据长度≤7时，数据就会以单帧的形式通讯。生成的单帧PCI（1个字节）、数据和CAN标识符一起组成网络层PDU传输到数据链路层。

当数据长度＞7时，就会对数据进行打包，将前6个字节的数据放在 FF帧（第一帧）中，在第一帧的前两个字节是PCI，包含消息帧的长度。随后接收数据的节点会发送流控制帧（FC），流控制帧就是告诉发送节点接下来怎么样发送剩下的数据。流控制帧包含BS（Block Size）和STmin。其中 BS决定了接收节点一次可以接收连续帧的个数。STmin为连续发送连续帧的最小时间间隔。每次发送过程均收到FC，再根据FC发送剩余数据，直至全部数据发送完。

当SF和CF的最后一帧加上PCI的信息不够8个字节时，即数据域没有全部使用时，协议规定要填充，具体填充1或0可由OEM定义，目的是在CAN总线上传输的数据都是8个字节，省去数据链路层去计算DLC。

以上是在发送时的拆装过程，相反，如果接收来自电控单元的数据时则要完成组装过程，这时需要一个具有足够空间的缓存区以存放接收的数据。

1.3 连接超时及错误处理

1.3.1 连接超时

在 4种消息帧通讯的过程中，会有 As、Ar、Bs、Br、Cs和Cr六种定时参数约束这四种消息帧的通讯时间和通讯的间隔等。

图2 时间参数定义

表5 超时定义

1.3.2 错误识别与处理

SF_DL错误：SF_DL=0 或者SF_DL＞7（常规寻址）接收方网络层应忽略接收到的单帧，且接收方无 indication；FF_DL＞接收方的缓存，那么接收方网络层应中断报文接收，接收方发送 FC，其中 FS=Overflow，接收方无 indication；FF_DL＜=7/6（常规寻址模式为7，扩展或混合寻址为6），网络层忽略FF，接收方无indication，且不发送FC；SN错误：CF N_PDU中的SN错误，报文接收应被中断，接收方网络层应指示上层＜Result＞=N_WRONG_SN；SN 错误：CF N_PDU中的SN错误，报文接收应被中断，接收方网络层应指示上层＜Result＞=N_WRONG_SN；FS错误：如果发送方网络层发现接收到的FC N_PDU中的FS错误，那么报文发送应被中断，发送方网络层应确认上层＜Result＞=N_INVALID_FS；N_WFTmax：接收方最多连续发送多少个等待FC帧个数，本地变量，仅可以在多帧报文发送过程中接收方网络实体中定义，系统初始化时应设置正确，使用这个变量用于避免发送方节点一直处于等待FC状态；ST错误：发送方接收到的FC中的STmin设置为保留值时，发送方继续发送 CF，只是各个CF之间的间隔时间为协议最大值（7F-127ms），发送方和接收方没有错误向各自上层报告。

非预期帧的处理：在多帧报文通讯过程中，任何一方接收到的非期望报文（同一个N_AI），总线设计者确定总线采用全双工或半双工，然后依据节点处于接收状态，发送状态及空闲状态时，接收到非预期报文，网络层的处理方法不同：①半双工状态，网络层处于发送状态，收到任何数据报文，均忽略；②全双工状态，除SF和物理寻址的FF外，包括功能寻址FF均作忽略处理，且不向上层报告。

表6 STmin定义

多帧报文的发送必须使用物理寻址，如果多帧报文的发送是功能寻址则需忽略功能寻址第一帧。

2 SAE J1939-21数据通讯

1个SAE J1939消息帧的数据场不超过8个字节，因此，如果要发送的数据长度超过8个字节，就需要将消息帧分成几个不超过8个字节的消息帧分包发送。

2.1 控制及数据结构

表7～表14描述了实现连接管理及数据通讯的数据结构。

SAE J1939-21数据数据通讯中对于TP.DT(数据传送)数据域的结构定义见表7，数据场的第1个字节从1开始作为消息帧的序号，后7个字节用来存放数据，所以可发送255×7=1785个字节的数据（255表示最大能够发送的包数，范围1～255包；7表示每包消息帧的字节数，2～8位为存放数据位）。数据包按照包编号顺序发送，最后一个数据包未用的字节以0xFF填充。

表7 TP.DT数据域结构

表8 TP.DT参数组描述

表9 TP.CM参数组描述

表10 TP.CM_RTS参数描述

表11 TP.CM_CTS参数描述

表12 TP.CM_EndofMsgAck参数描述

表13 TP.CM_Abort参数描述

表14 TP.CM_BAM参数描述

消息帧被接收以后按序号重新组合成原来的数据，消息帧的重组过程正好是拆分包的逆向过程。

2.2 数据通讯过程

连接管理主要对节点之间连接的建立和关闭、数据的传送进行管理，其中定义了发送请求帧、发送清除帧、结束应答帧、连接失败帧及用来全局接收的广播帧5种帧结构。节点之间的连接通过1个节点向目的地址发送1个发送请求帧而建立。在接收发送请求帧以后，节点如果有足够的空间来接收数据并且数据有效，则发送1个发送清除帧，开始数据的传送；如果存储空间不够或数据无效等原因而节点需要拒绝连接，则发送连接失败帧，连接关闭；如果数据接收全部完成，则节点发送1个结束应答帧，连接关闭。

2.2.1 点对点会话

一般会话的通讯过程参考图3：图3描述了基于请求、应答模式的连接管理及数据通讯过程，发送节点请求传输一个PGN为65259的数据包，字节长度为23字节，包长度为4包，接收节点允许单次连续发送不超过2包的数据，通讯过程按照一般正常过程完成连接管理及数据通讯。

图3 点对点会话过程

要求某一个数据包重发：参考图4虚线框内，接收节点要求把PGN65259的第2包数据重发，发送节点下一帧把第2包数据重新发送一遍。

图4 数据包重发过程

利用RTS的最大数据包能力：参考图5虚线框内，发送节点单次连续发送5包数据。

图5 RTS的最大数据包通讯

2.2.2 广播会话

图6描述了基于广播模式的数据通讯过程：发送节点广播请求传输一个PGN为65260的数据包，字节长度为17字节，包长度为3包，通讯过程按照一般正常过程完成数据通讯。

图6 广播会话通讯过程

2.3 连接超时及错误处理

2.3.1 连接超时

超时功能：控制报文的发送速率，留给对方足够的处理时间，防止长时间等待。

超时处理：点对点会话中，等待方发送放弃连接报文，退出通讯过程；广播公告中，直接退出通讯过程。

表15 超时的时间参数设定

2.3.2 错误识别与处理

1）连接关闭的情形：

①BAM 报文的连接关闭情形：发送节点发送最后一包DT；响应节点接收到最后一包DT，出现一次T1连接超时。

②RTS/CTS报文连接关闭情形：发送节点完成数据通讯后接收到 TP.CM_EndOfMsgAck；发送了放弃连接报文；接收到放弃连接报文。响应节点完成数据通讯后发送TP.CM_EndOfMsgAck；接收到放弃连接报文；发送了放弃连接报文。

2）连接限制的情形：

①同一时刻，发送节点对一个节点只能发起一个点对点会话。

②发送节点同一时刻只能发起一个广播公告。

③连接状态下，如果接收节点不支持另一个连接，必须发送放弃连接报文进行拒绝。

④接收节点必须能够同时接收来自多个不同节点的连接（包括点对点会话和广播公告）。

⑤接收节点能够同时支持由同一个发送节点发起的一个点对点会话和一个广播公告。

3 两种多帧数据通讯差异

CAN数据包的长度不超过8个字节，在诊断等场合下会需要传输几十甚至上百字节的数据，无论ISO 15765-2还是SAE J1939-21均能很好的解决多帧数据通讯的功能，只是二者在实现思想及细节上存在一定差异。

3.1 连接管理、数据通讯

ISO15765-2定义了一个PCI来完成连接管理及数据的通讯，PCI放置在数据域的第1～3字节，通过PCI将数据分为SF、FF、CF和FC 4种类型的消息帧及对应的控制信息，4种数据帧共用一个ID，通过PCI来区别帧的功能类型及对应的控制信息。节点之间的连接管理及数据通讯控制信息均是通过PCI来体现。

而SAE J1939-21则是通过PGN TP.CM来实现节点之间的连接管理，包括：发送请求、发送允许、结束应答、连接失败及用来全局接收的广播功能的实现，5种功能的控制信息则是填充到对应数据域的第1字节内。SAE J1939-21实现数据通讯则是通过PGNTP.DT来实现，数据域第1字节填充数据包的编号，第2～7字节填充具体数据。节点之间的连接管理及数据通讯控制信息是通过两个 PGN及对应的控制字节来实现的。

3.2 数据域结构

由于二者在通讯模式、实现策略上的差异性，二者的数据域结构也存在一定的差异，第2、3章节已详细说明，此章节就不再详述，但是二者基于对报文组包、拆包及连接控制的核心思想都是相通的，都是为了实现多帧通讯的功能。

3.3 最大数据长度

由于二者数据格式定义的差异性，所以二者在最大数据传输长度上也不同，其中ISO15765-2的为4095字节，SAE J1939-21的为1785字节。

3.4 超时及错误处理

为了控制数据的发送速率，留给控制器足够的处理时间，防止长时间等待，应对总线异常状况，超时处理和故障处理策略的定义是非常必要的。二者为了数据通讯功能的实现均提供了完善的超时功能及故障处理策略。二者在超时参数的定义及故障处理策略上根据自身通讯机制的差异分别作了详细的定义，差异较大。

4 优劣分析及应用趋势

从二者的差异性可以看出，SAE J1939-21数据通讯在通讯模式、实现策略上更为复杂，对于主机厂、供应商等开发应用者来说更难理解和应用。ISO15765-2定义的数据结构上相较更为紧凑，对数据域的利用率也更高，在传输同等数据量的情况下，通讯效率也更高。ISO15765-2支持的最大数据长度为4095字节，SAE J1939-21为1785字节。从技术角度分析，ISO15765-2的数据通讯略优于SAE J1939-21定义的数据通讯。

另外，多帧数据通讯一般应用于诊断场合，依附于诊断协议的推广而被推广，所以诊断协议的应用推广状况代表着两种多帧数据通讯的推广情况。ISO 15765-2属于ISO的体系，一般和ISO 11898、ISO 14229等协议规范共同组成整车的总线协议，一般应用在乘用车领域。SAEJ1939-21由于属于SAE J1939系列协议的体系，所以在SAE J1939通讯协议的场合中应用广泛，应用车型主要包含中大型卡车和客车等。IS0 15765诊断协议是全球统一诊断协议IS014229基于CAN总线的具体应用，IS0 15765和IS014229的组合形成的诊断协议标准经过多年的发展和应用已非常完善与成熟，适用于电控单元的在线配置、开发标定、售后维修和软件升级等，在乘用车及中小型的商用车上得到非常广泛的应用。SAE J1939是美国汽车工程师协会制定的专门针对重型车应用的通讯、诊断协议，由于SAE J1939起步稍晚，其定义的增强型诊断实现机制异常复杂，尤其是诊断服务不够完善，所以若想进一步推广还需做大量的完善工作。

目前无论从技术的角度还是从各自所从属的诊断协议的推广状况来看，ISO15765-2的多帧数据通讯都要优于 SAE J1939-21定义的多帧数据通讯。所以笔者大胆预测，未来ISO15765-2的多帧数据通讯凭借自身的技术优势及和 ISO 14229、ISO 15765的依附关系会进一步扩大应用范围，包括乘用车，中小型商用车，甚至是采用SAE J1939系统通讯的控制器，SAEJ1939-21多帧数据通讯的应用范围可能将进一步被蚕食，局限于DM1、DM2（SAE J1939定义的当前故障、历史故障诊断服务）等有限的诊断服务中。

5 结论

两种多帧数据多帧数据通讯虽在通讯原理、机制、实现手段、细节等方面存在较大的差异，但是二者基于对报文组包、拆包及连接控制的核心思想都是相通的，都是为了实现多帧通讯的功能。只有充分理解和掌握这些协议的原理、机制等，才能更加方便、精准地指导汽车总线设计、验证，了解汽车的故障，准确快速地分析、解决汽车出现的问题。而主机厂也应根据自身及外界发展趋势合理选择适合自身的多帧数据通讯，通过长远的平台规划，以提高整车的系统兼容性。

[1] SAEJ1939-21:DataLinkLayer,2006.

[2] SAEJ1939-71:VehicleApplicationLayer,2010.

[3] SAEJ1939-73:ApplicationLayerDiagnostics,2010.

[4] IS015765-2:Roadvehicles Diagnosticson ControllerArea Networks(CAN),Part2:Networklayerservices,2004.