CANoe中发送长度大于8字节的长帧报文(1)-J1939.dll

蜉蚁撼树

已于 2024-04-20 06:46:56 修改

阅读量1.3k

点赞数 26

分类专栏： Vector CANoe-CAPL 学习笔记文章标签：笔记经验分享

于 2024-04-19 21:00:00 首次发布

本文链接：https://blog.csdn.net/qq_15290027/article/details/137948472

版权

CANoe-CAPL 同时被 3 个专栏收录

11 篇文章 12 订阅

订阅专栏

学习笔记

10 篇文章 1 订阅

订阅专栏

Vector

6 篇文章 0 订阅

订阅专栏

J1939协议中长帧报文发送时有请求和应答机制，不同于短帧报文直接发送。
对CAPL实现长帧报文发送，使用分包方式发送，0x10发送多包请求，0x11接收多包发送请求，0x13多包数据接收完成。
请求和应答TPCM：EC；数据传输TPDT：EB。要发送长帧，长帧的ID需要定义，制作DBC文件，编写CAPL代码。

《电动汽车非车载传导式充电机与电池管理系统协议之间的通信协议》GB T 27930–2015
GB/T 27930协议中，车辆有多个长消息报文，比如BRM、BCP、BCS等。
如何在CANoe中用CAPL代码实现长帧报文的发送？
介绍一种简单方法，在要实现长帧发送的Node节点，添加J1939_IL.DLL文件，实现长帧的发送

1、充电协议解读

在这里插入图片描述
地址分配：充电机 86(56H)
地址分配：BMS 244（F4H）
• 帧4位ID最后2位代表着传输方向
• 0xXXXXF456为充电机到BMS
• 0xXXXX56F4 为BMS到充电机
BMS报文ID帧识别
• 帧ID是唯一识别码，我们通过ID来识别不同的信息，
• 如果数据包数据不超过8个字节，数据直接在ID帧后出现
• 如果如果数据包数据超过8个字节采用多包协议TPCM传输。
超过8个字节，发送时会按照J1939协议发送数据。在发送大于8个字节的数据之前，无论充电机或者BMS会先发送一个连接请求的报文：0x1CEC56F4，1C为包含报文优先级（3位）、保留位（1个位）和数据页（1个位）。EC为此报文的功能说明。
【EC为数据大于8个字节的报文连接请求，EB为长度大于8字节的报文数据内容传输】
在接收方接收长包的数据时，接收方无法判断此时的数据内容为哪个报文的数据，所以在整个充电流程中，每次只允许建立一次长包请求连接，直到接收方将数据全部接收完成才能进行下一个请求连接的允许。如果上一个连接存在，数据没有接收完全，则发送方想要再次建立连接时，接收方将发送放弃连接报文。
报文数据格式
• 报文数据最多为8个字节，数据均为16进值数据，高字节在高位低字节在低位。
• 例如一个2字节的数据700=0x02bc，传输的时候是bc02。
• 单包协议每帧数据一般为小于或等于8个字节（byte0-7），每个字节数据均有其含义，为具体信息。
• 多包协议每帧数据一般为8个字节，byte0为多包序号，byte1-7为有用信息数据。
关于多包协议：
byte0：0x10控制字符，表示通知我要发多包
byte0：0x11控制字符,表示充电机收到了多包协议请求
byte0：0x13 控制字符，表示结束多包传输

2、J1939长帧发送

CAN多包数据传输-知乎

J1939协议定义了三种通信方式——广播（BAM, Broadcast Announce Message）、基于连接的数据传输（Connection Mode Data Transfer）、直接数据传输（DIRECT）。如果数据多余8字节，则会通过BAM或者CMDT来发送，而小于等于8字节时，直接发送。

SAEJ1939网络协议规范定义的数据帧中，数据场的长度不能超过8个字节。

发动机信息及诊断报文等信号需要传输的数据长度会达到几十个字节甚至上百字节。这些长度大于8个字节的消息是无法用单个CAN数据帧来装载。需要使用***SAEJ1939-21***多包数据传输协议。

一个多包传输报文最多可传送255包数据（每包7个数据字节），一个多包报文最多传输1785个字节的数据。255*7=1785

SAEJ1939-21 中 TP （transport protocol）部分，主要功能：对数据长度大于8个字节的参数组进行***打包、重组、连接、管理、数据传输***，用来实现多包传输。

传输协议报文的优先级与单包报文的优先级的保持一致。

SAEJ1939-21协议中定的连接管理有两种类型

(1）点对点会话。多包消息需要发送到指定目标地址时使用的一种连接管理.这种类型的连接管理用于处理节点间虚拟连接的打开、使用、关闭。

(2)广播会话。如果消息是发送到多个节点或者是全局。则不需要数据流控制和关闭的管理功能。只需要通过广播消息来通知信息的发送即可。BAM只有发送者向接收者的交互过程

TP.CM 数据传输首先在节点之间建立连接。连接管理主要是对节点之间连接的建立和关闭、数据的传送过程进行管理。

J1939-21协议
在这里插入图片描述
TPCM报文：0x18ECFF**（广播：内容包含即将传输报文的PGN、总的数据包长度等信息）
TPDT报文： 0x18EBFF**（数据传输：不含有PGN信息，只含有报文包序和具体的7字节数据）

相临两个TPDT之间的时间间隔是50ms到200ms。
在这里插入图片描述

3、BRM报文示例

接收,10:05:28.383,0x1801F456,数据帧,扩展帧,0x08, 0x 00 01 FF FF FF 31 32 33
接收,10:05:28.399,0x1CEC56F4,数据帧,扩展帧,0x08, 0x 10 31 00 07 FF 00 02 00
接收,10:05:28.414,0x1CECF456,数据帧,扩展帧,0x08, 0x 11 07 01 FF FF 00 02 00
接收,10:05:28.430,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 01 01 01 00 03 88 13 4C
接收,10:05:28.446,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 02 1D FF FF FF FF FF FF
接收,10:05:28.461,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 03 FF FF FF FF FF FF FF
接收,10:05:28.477,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 04 FF FF FF 78 49 41 4E
接收,10:05:28.492,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 05 52 44 56 49 4E 54 45
接收,10:05:28.508,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 06 53 54 30 30 30 30 FF
接收,10:05:28.524,0x1CEB56F4,数据帧,扩展帧,0x08, 0x 07 FF FF FF FF FF FF FF
接收,10:05:28.539,0x1CECF456,数据帧,扩展帧,0x08, 0x 13 31 00 07 FF 00 02 00
接收,10:05:28.555,0x1801F456,数据帧,扩展帧,0x08, 0x aa 01 FF FF FF 31 32 33

[CRM-00]
接收,10:05:28.383,0x1801F456,数据帧,扩展帧,0x08, 0x00 01 FF FF FF 31 32 33
优先权：18；优先级：6；PF=01；方向：充电机-BMS；数据位：8；
Byte0：00，充电机主动发送识别，请求握手，有回应时变为AA。
Byte1：01，标识充电机编号，每个厂家生产的充电机编号不一样。
Byte2-7：6个字节为充电机充电站所在编号，可选信息。
BMS收到CRM<00>，BMS发送BMS和车辆握手辨识报文BRM
[BRM][TPCM_RTS]
接收,10:05:28.399,0x1CEC56F4,数据帧,扩展帧,0x08, 0x10 31 00 07 FF 00 02 00
byte0: 0x10控制字符，表示通知我要发多包.0x31=49,49个字节数据，7包数据
当 BMS 收到充电机的 CRM 报文后，启动数据传输协议 TCPM
BMS发送RTS报文：ID: 1CEC56F4，通知充电机准备发送多少包数据。
[TPCM_CTS]
接收,10:05:28.414,0x1CECF456,数据帧,扩展帧,0x08, 0x11 07 01 FF FF 00 02 00
byte0,0x11控制字符,表示充电机收到了多包协议请求
当充电机收到BMS发送的RTS报文后，作出应答信号，回复CTS给BMS。
[TPCM_DT]
接收,10:05:28.430,0x1CEB56F4,数据帧,扩展帧,0x08, 0x01 01 01 00 03 88 13 4C
接收,10:05:28.446,0x1CEB56F4,数据帧,扩展帧,0x08, 0x02 1D FF FF FF FF FF FF
接收,10:05:28.461,0x1CEB56F4,数据帧,扩展帧,0x08, 0x03 FF FF FF FF FF FF FF
接收,10:05:28.477,0x1CEB56F4,数据帧,扩展帧,0x08, 0x04 FF FF FF 78 49 41 4E 车辆识别码VIN
接收,10:05:28.492,0x1CEB56F4,数据帧,扩展帧,0x08, 0x05 52 44 56 49 4E 54 45 车辆识别码VIN
接收,10:05:28.508,0x1CEB56F4,数据帧,扩展帧,0x08, 0x06 53 54 30 30 30 30 FF 车辆识别码VIN
接收,10:05:28.524,0x1CEB56F4,数据帧,扩展帧,0x08, 0x07 FF FF FF FF FF FF FF
测试充电桩的设备，此处车辆识别码可以不填写，全为FF
当BMS收到充电机的应答报文CTS后，开始建立连接，发送数据DT【BMS发PGN512多包数据】
第一包数据：010100协议版本V1.1；
•byte0-2:00 01 01 BMS通讯协议号V1.01；一般是一个标准就规定了当前版本
01 01 00，BMS通讯协议版本号：V1.1；
00 01 00，BMS通讯协议版本号：V1.0
00 01 01，BMS通讯协议版本号：V1.01
03磷酸铁锂电池；0x1388=50000.1=500A.H；
•byte3: 06 电池类型：06三元，03磷酸铁锂……
•byte4-5：bc 02:电池额定容量 02bc=7000.1=70A.h
•byte6-7：fa0b电池额定总电压 0bfa=30580.1=305.8V
•byte8-40是可选数据，没有默认为FF
第一报最后一个字节+第二包第一个字节：0x1D4C=75000.1=750V

[TPCM_EM]
接收,10:05:28.539,0x1CECF456,数据帧,扩展帧,0x08, 0x 13 31 00 07 FF 00 02 00
byte0,0x13 控制字符，表示结束多包传输
当充电机接收完BMS发送到数据报文DT后，回复EM给BMS用于消息结束应答。
充电机收到BRM，充电机发送CRM
[CRM-AA]
接收,10:05:28.555,0x1801F456,数据帧,扩展帧,0x08, 0x AA 01 FF FF FF 31 32 33
充电机结束应答，就相当于充电机接收到了BMS发送到电池身份编码信息BRM，充电机回复辨识报文CRM-0XAA给BMS。
aa 表示可以识别BMS，可以进行到第二阶段充电配置了

4、定义多包报文

（1）在DBC中定义多包报文格式
在CANdb++中点击ID 右侧的选项，配置PGN、SA、PS、Priority。
在这里插入图片描述
多包传输协议的TPCM和TPDT的格式，也要在DBC中定义，如下图所示：
TPCM请求应答格式DCB定义
TPDT数据格式DCB定义
（2）在Network节点中添加J1939_IL.DLL
右击仿真节点–configuration–Component：点击add，DLL 文件在CANoe 安装路径下的EXEC32 文件夹中。注意选择与CANoe版本相对应的dll文件。
在这里插入图片描述
（3）Network节点CAPL编程
数据库定义了PG 的长度和信号，只需要配置信号值以及进行发送即可：
pg BRM msgBRM;
configBRM();//配置BRM报文
output(msgBRM);//发送BRM报文

//=================================CAPL代码==============================
on key '1'
{
    LONG i;
    LONG j;
    pgBRM.dlc = 49;//0x31
    pgBRM.dp = 0;
    pgBRM.prio = 7;
    pgBRM.pf = 2;//PGN 00 02 00   PF:02
    pgBRM.ps = 0x56;
    pgBRM.edp = 0;
    pgBRM.sa = 0xF4;  
    //BRM报文初始化数据域
	output(pgBRM); 
}

在这里插入图片描述
（4）多包报文接收
多包报文接收，使用on pgTPCMxx和on pgTPDT进行接收和解析。具体解析方法可参考demo工程。路径：C:\Users\Public\Documents\Vector\CANoe\Sample Configurations 13.0.118\J1939\MoreExamples\TransportProtocol。
C:\Users\Public\Documents\Vector\CANoe\Sample Configurations 13.0.168\SmartCharging\GBT27930\Simulation\CAPL
C:\Users\Public\Documents\Vector\CANoe\Sample Configurations 13.0.168\SmartCharging\GBT27930\Simulation

//=================================CAPL代码==============================
on pg TPCM, TPDT
{
on pg TPCM, TPDT
{
  BYTE  sessionAddress[1]  = { kNullAddr };
  BYTE  sessionsPackets[1] = { 0 };
  WORD  sessionsBytes[1]   = { 0 };
  DWORD sessionPGN[1]      = { 0x0000 };
  int   i;
  pg    TPCM cmPG;

  if (this.DIR != RX) return;

  cmPG.SA  = Node2.NmStationAddress;
  cmPG.DA  = this.SA;
  cmPG.CAN = this.CAN;
  cmPG.dword(0) = cmPG.dword(4) = 0xffffffff;

  if (this.PF == 0xec) // Command
  {
    if (this.byte(0) == 0x10) // RTS
    {
      // new session
      for( i = 0; i < elCount(sessionAddress); i++ ) 
      {
        if ((sessionAddress[i] == this.SA) || (sessionAddress[i] == kNullAddr)) 
        {
          sessionAddress[i]  = this.SA;
          sessionsPackets[i] = this.byte(3); 
          sessionsBytes[i]   = this.word(1);
          sessionPGN[i]      = (this.byte(7)) | (this.byte(6) << 8) | (this.byte(5) << 16);
          // send CTS
          cmPG.ControlByte   = cmPG.ControlByte::CTS;
          cmPG.NumberOfPacketsThatCanBeSent = 1;
          cmPG.NextPacketNumberToBeSent     = 1;
          cmPG.PGNumber      = sessionPGN[i];
          output( cmPG );
          break;
        }
      }
    }
  }
}

总结

J1939 是基于CAN 的高层协议，而J1939_IL.DLL 则是用来实现J1939 通信的Vector 内置函数库。这里output发送的是J1939的报文，也就是PG，分层则是IL层自己实现的。所以需要DBC 里面定义好报文，方便解析。另外，这种方式，接收是可以直接使用 on pg BRM 的，收到的是完整的数据（49Bbyte）