0 引言
随着近年来电动汽车行业如火如荼的发展，电动汽车技术相关的各种标准也相继推出，其中包括了《电动汽车非车载传导式充电机与电池管理系统之间的通信协议》(GB/T 27930-2011)。该协议是基于CAN应用层协议SAE J1939,J1939 是目前在国内汽车行业中应用广泛的CAN总线应用层协议。只有电池管理系统与充电机之间的正常数据交互才能保证电动汽车进行高效、安全的充电。因此，电池管理系统与充电机通信协议测试是电池管理系统测试的一个必不可少的项目。
本课题来源于北方车辆研究所电池管理系统测试平台项目。美国国家仪器NI PXI CAN采集卡以及LabVIEW为模拟充电机与BMS通信提供了良好的软硬件环境。
LabVIEW是美国国家仪器推出的一种程序开发环境，图形化语言使其与其他的代码类型语言相比之下更为方便直观。以计算机作为运行环境的LabVIEW,充分利用了计算机无可比拟的硬件优势，具有强大的数据处理能力。开发者可以很容易实现多线程编程，极大降低了软件开发的难度。LabVIEW的前面板提供了丰富的类似传统仪器的控件，开发者可以很方便的创建用户界面。
本文重点在于如何用LabVIEW实现SAE J1939多帧传输机制，完成超过8 B 报文的接收重组、拆分发送。以及如何实时判断通信过程出现的错误、指出错误类型、定位错误发生的阶段。
1 SAE J1939 协议
J1939 协议是基于CAN 2.0B 制定的，协议对物理层、数据链路层、网路层以及应用层都进行了相关的规定。本文针对数据链路层的规定进行简单介绍。
1.1 协议数据单元(PDU)
J1939 将CAN 2.0B 的29 位标识符ID 划分为六部分，每部分都代表不同的含义，包括优先级(P)、保留位(R)、数据页(DP)、PDU格式(PF)、特定PDU(PS)、源地址(SA)，见表1.
根据CAN 2.0 总线的仲裁机制，标识符值越小，CAN帧优先级越高，J1939把这一权利赋予了标识符最高三位(P)。R、DP通常为0.SA代表了该帧数据的发送节点的地址，CAN 网络中每个设备都分配了惟一的SA.在介绍PF 与PS之前有必要先介绍下参数组编号(PGN)的概念。每个PGN代表着惟一的参数组(可以包含一个或多个参数)，当参数组的数据域大于8 B时，需要遵循J1939的多帧传输机制。PGN 由R、DP、PF 以及PS 组成，见表2.从表2 中可以看出PDU2 格式报文没有目标地址，此类报文只能发送给全局地址。由于PS作为PDU2 格式参数组编号的一部分，因此PDU2 比PDU1能定义更多的参数组编号。
1.2 多帧传输机制
CAN 2.0B 数据域最多有8 B,而在J1939协议中当一个参数组编号(PGN)所对应的数据超过8 B时，规定了一种多帧传输机制，发送者按此机制拆分发送，接收者按此机制接收重组，因此一个参数组编号所对应的数据最多可以为1 785 B.点对点未发生错误的多帧传输机制如图1 所示，J1939 对传输过程出现错误的情况也规定了相应的处理机制，在此不作介绍。
TP.CM_RTS、TP.CM_CTS、TP.DT、TP.EndofMsgACK均为J1939特定功能报文，其参数组编号也由J1939规定，因此这些参数组编号不能再被用户定义。TP.CM_RTS为消息发送者发送的请求发送帧，由此开始建立多帧传输链接，其数据域包括了此次发送的消息全部字节数、全部数据包数(TP.DT 帧数)以及该消息的参数组编号等信息。接收者根据自己的接收能力，发送准备发送帧TP.CM_CTS,通知发送者下次可发送的数据包数、下一个要发送的数据包编号以及消息的参数组编号。发送者根据接收者的要求开始发送数据包TP.DT,数据包的数据域第一字节代表了该包号，因此一个数据包最多包含消息的7 B.
这个过程循环进行，直至接收者接收到全部数据包后发送消息结束应答帧TP.EndofMsgACK代表着这次多帧传输的结束。若发送的消息是全局消息，则所有接收者不应有任何应答，整个传输过程如图2所示。
2 基于LabVIEW实现J1939 协议平台
2.1 硬件接口
利用NI PXI-8513 CAN 接口板卡实现该系统的硬件接口。NI已为开发者提供了该板卡的底层驱动，可以很方便对CAN节点参数进行配置以及接收和发送符合CAN 2.0的消息帧，然而对于多帧传输机制还需开发者自行设计。由于J1939 协议涉及发送者与接收者的应答，因此在基于LabVIEW开发J1939同时也利用C语言开发基于飞思卡尔单片机的电池管理系统中使用的J1939 协议，两者相辅相成，并且利用VECTOR CANoe软件监视总线，以保证程序开发的顺利进行。
2.2 软件实现
利用LabVIEW多线程编程以及生产者消费者结构实现J1939协议。分别为未拆分的发送报文、已拆分发送报文、未重组的接收报文、已重组的接收报文建立队列。创建已重组报文读取线程，已重组报文出队列用于应用层协议。创建接收报文处理线程，用于按多帧传输机制处理接收到的CAN 2.0数据帧，程序流程图如图3所示，经过目的地址过滤报文后，利用条件结构按照报文参数组编号进行分类处理，在计算参数组编号时要注意PDU1与PDU2格式的区别，主要分为以下几种情况：
数据小于7 B的正常数据报文：直接入已处理接收报文队列供应用层使用;请求发送帧TP.CM_RTS:由于两个节点之间同一时间最多只能有一个发送和一个接收的多帧传输链接，若这时已有一个接收链接，则需要发送放弃链接帧TP.ABORT告知发送者，若无接收链接，创建新的接收状态机并插入接收状态机数组。接收状态机为一个数据簇，包含了参数组编号、下一个接收数据包编号、数据包总数、当前已接收字节数、字节总数、以及已接收字节数组。之后应发送准备发送帧TP.CM_CTS 通知发送者发送数据包，同时应开始计时，若发送者响应时间超过规定时间，应发送放弃帧TP.ABORT;准备发送帧TP.CM_CTS:此报文为接收者对发送报文的应答，此次发送状态机已建立，搜索相应状态机，根据准备发送帧要求拆分数据创建数据包TP.DT;数据包TP.DT:搜索相应的接收状态机并核对是否与目前状态机相符，如果相符则对数据进行重组存入状态机的接收字节数组，若不符则发送该参数组编号的放弃链接帧，最后判断多帧传输是否结束，并根据是否为全局报文决定是否发送完成链接帧;完成链接帧TP.EndofMsgACK:表示相应的多帧发送链接已完成，删除相应的发送状态机。广播公告消息TP.
CM_BAM:收到全局消息的请求链接帧，只需建立相应的接收状态机，等待接收数据包，而不需要任何的应答。
发送报文均先入未拆分发送报文队列;创建未拆分发送报文处理线程，用于按多帧传输机制处理发送报文，程序流程图如图4所示，若发送报文数据超过8 B则需要通过多帧传输机制拆分发送。
2.3 J1939平台应用效果
定义电池管理系统BMS和LabVIEW的J1939协议地址分别为244和86.首先由BMS发送PGN为256的9 B报文给LabVIEW,CANoe监视到总线时序如图5所示。
由第一帧ID可以看出源地址为0xF4(244)，目的地址为0×56(86)，PGN为0xEC00,因此该帧为链接管理帧TP.CM,并且Data 域控制字节(第1 字节)为0×10,综上该帧为BMS 发送给LabVIEW 的请求发送帧，并由Data域可以看出此次报文共有0×09字节(第2,3字节)，数据包共有0×02 包(第4 字节)，PGN 为0×0100(第6,7,8 字节)。同理第二帧为LabVIEW发送的准备发送帧，通知BMS 从第0×01 包(第3 字节)开始发送0×02(第2 字节)包数据包。待接收到BMS发送的两帧TP.DT,LabVIEW发送TP.EndofMsgACK 代表此次多帧传输完成。Lab-VIEW接收重组后的数据如图6所示。
同理分析LabVIEW 作为发送节点的情况，总线时序图如图7所示，LabVIEW拆分前的发送数据如图8所示。综上分析，利用LabVIEW 开发平台很好地实现了J1939协议。
3 通信协议测试软件的开发
通信协议将整个通信分为多个阶段：充电握手阶段、充电参数配置阶段、充电阶段、充电结束阶段。每个通信阶段均涉及充电机与BMS 的信息交互，每次信息交互均有超时限制。为了实现对通信协议进行测试，不仅要模拟充电机与BMS 进行通信，还要实时监测通信的状态，判断通信过程是否出错并解析BMS 发送的信息。测试软件主要测试通信阶段出现的时序错乱以及信息交互超时这两种错误。
在已开发J1939协议基础上进行测试软件的开发，J1939协议提供了两个接口：需要发送报文直接入未处理发送报文队列、已处理接收报文出队列供应用层使用。通信阶段改变利用LabVIEW 状态机结构来实现。
创建充电机接收状态、充电机发送状态两个数据簇，记录接收报文是否已被接收、发送报文是否已被发送以及发送的时间。利用单独程序线程通过这两个数据簇实时判断是否有错误发生。
应用效果如图9所示，为了试验是否能准确测试出错误类型，有意将BMS 程序设置为不发送电池充电需求报文，测试软件指示超时类型代码为5,即电池充电需求报文超时，接收错误类型主要为通信顺序出错。通过对每个接收超时类型以及顺序出错类型进行测试，结果表明能很好地实现对通信协议进行测试。
4 结语
在LabVIEW开发平台上，利用其强大的数据处理能力以及丰富实用的程序结构实现了J1939协议，在此基础上开发电动汽车非车载传导式充电机与电池管理系统之间的通信协议测试软件，不仅可以辅助BMS的程序开发，还可以作为BMS测试平台的部分功能评价BMS合格与否。通过与BMS进行通信，并利用CANoe对总线进行监视，试验结果表明该测试软件可以实现J1939协议，能完成多帧传输机制，并且可以测试出通信协议中出现的通信流程错乱以及通信超时错误，可以满足要求。
