背景

最近在项目中，同事遇到了一个dbc数据库解析错误的问题：基于ekuiper 对can报文解析，发现实际输出结果与预期差距较大。当时他第一反应是ekuiper的解析规则有误，因此就没有跟踪下去了。因为之前我用过ekuiper的CAN报文解析功能，是没有问题的。因此我更倾向于是他的dbc数据库有问题，于是研究了一下DBC文件解析的规则，并实际验证。过程中也踩了一些坑，在此记录。希望能帮助到有需要的人。

DBC 数据库介绍

DBC是vector公司定义的can网络通信文件格式。网上介绍的文章很多，有兴趣的朋友可以去搜索一下。本文的主要核心是解析DBC信号部分，对于相关信息进行简略描述。

dbc文件一般包含了如下信息：

1. 版本与新符号
2. 波特率定义
3. 网络节点的定义
4. 报文帧的定义
5. 信号的定义
6. 注解部分
7. 特征部分
8. 数值表部分

版本与新符号

这两个参数一般在文件的开头，tag为VERSION和NS_。其中VERSION可以为空或自定义，NS_一般固定，不需要修改。如下：

VERSION ""NS_ :NS_DESC_CM_BA_DEF_BA_VAL_CAT_DEF_CAT_FILTERBA_DEF_DEF_EV_DATA_ENVVAR_DATA_SGTYPE_SGTYPE_VAL_BA_DEF_SGTYPE_BA_SGTYPE_SIG_TYPE_REF_VAL_TABLE_SIG_GROUP_SIG_VALTYPE_SIGTYPE_VALTYPE_BO_TX_BU_BA_DEF_REL_BA_REL_BA_DEF_DEF_REL_BU_SG_REL_BU_EV_REL_BU_BO_REL_SG_MUL_VAL_

波特率

格式为BS_:[baudrate:BTR1,BTR2]; 含义如下：

• BS_为关键字，用于定义CAN网络的波特率；
• [ ]内容表示为可选部分，可以省略；
  注：但关键字BS_:必须存在，省略则会出错。如下：

BS_:

网络节点的定义

格式为BU_: Nodename1 Nodename2 Nodename3 ……含义如下：。

• BU_为关键字，表示网络节点；
• Nodename1、Nodename2表示网络节点名字，由用户自己定义。通过网络节点方便地进行CAN网络的设计、开发和测试。如下：

BU_:  EOCM_F_FO Dummy_FO

报文帧的定义（重点）

格式为BO_ MessageId MessageName: MessageSize Transmitter含义如下：

• BO_,为关键字，表示报文；
• MessageId,报文ID，是以10进制数表示的；
• MessageName,报文的名字，命名规则和C语言变量相同；
• MessageSize,报文数据域字节数，为无符号整型数据，CAN 2.0为最大8字节，CAN FD 最大64字节；
• Transmitter,该报文的网络节点；如果该报文没有指定发送节点，则该值需设置为” Vector__XXX”。
  如下：定义了一个报文ID为0x586的报文，报文名称为RVB_TVR_Debug2_FO, 报文长度仅7Byte,由EOCM_F_FO网络节点发出。

BO_ 1414 RVB_TVR_Debug2_FO: 7 EOCM_F_FO

信号的定义（核心）

格式为：SG_ SignalName (SigTypeDefinition) : StartBit|SignalSize@ByteOrder ValueType (Factor,Offset) [Min|Max] Unit Receiver含义如下：

• SG_为关键字，表示信号；
• SignalName表示该信号的名字;
• SigTypeDefinition是可选项，有3种格式：
  a）空，表示普通信号。
  b）M，表示多路选择器信号。
  c）m50，表示被多路选择器选择的信号，50，表示当M定义的信号的值等于50的时候，该报文使用此通路。
• StartBit、 SignalSize表示该信号起始位、信号长度,不同的字节序，StartBit含义不同；
• ByteOrder表示信号的字节顺序：0代表Motorola格式，1代表Inter格式；
• ValueType表示该信号的数值类型：+表示无符号数，-表示有符号数；
• Factor，Offset 表示因子，偏移量；这两个值用于信号的原始值与物理值之间的转换。转换如：物理值=原始值*因子+偏移量；
• Min|Max表示该信号的最小值和最大值，即指定了该信号值的范围；这两个值为double类型；
• Unit表示该信号的物理单位，为字符串类型；
• Receiver表示该信号的接收节点；若该信号没有指定的接收节点，则必须设置为” Vector__XXX”。

如下：定义了一个VBTOSLonPstn的普通信号，它的起始值在bit7,长度为12。字节序为Motorola,有符号。因子为0.125，偏移为0。数值的范围为-256~255.875，单位是m,由Dummy_FO网络节点接收。

SG_ VBTOSLonPstn : 7|12@0- (0.125,0) [-256|255.875] "m"  Dummy_FO

注解部分，特征部分，数值表部分在dbc文件中属于非必须部分，本文不再进一步介绍。综上所述，我们得到最小的dbc文件，后续基于该文件进行解析。

VERSION ""NS_ :NS_DESC_CM_BA_DEF_BA_VAL_CAT_DEF_CAT_FILTERBA_DEF_DEF_EV_DATA_ENVVAR_DATA_SGTYPE_SGTYPE_VAL_BA_DEF_SGTYPE_BA_SGTYPE_SIG_TYPE_REF_VAL_TABLE_SIG_GROUP_SIG_VALTYPE_SIGTYPE_VALTYPE_BO_TX_BU_BA_DEF_REL_BA_REL_BA_DEF_DEF_REL_BU_SG_REL_BU_EV_REL_BU_BO_REL_SG_MUL_VAL_BS_:BU_:  EOCM_F_FO Dummy_FOBO_ 1414 RVB_TVR_Debug2_FO: 7 EOCM_F_FOSG_ VBBrkCntlAccel : 45|12@0- (0.01,0) [-20.48|20.47] "m/s^2"  Dummy_FOSG_ VBTOSObjID : 35|6@0+ (1,0) [0|63] ""  Dummy_FOSG_ VBTOSTTC : 31|12@0+ (0.025,0) [0|102.375] "s"  Dummy_FOSG_ VBTOSLatPstn : 11|11@0- (0.125,0) [-128|127.875] "m"  Dummy_FOSG_ VBTOSLonPstn : 7|12@0- (0.125,0) [-256|255.875] "m"  Dummy_FO

案例分析

根据上面的dbc文件，我们进行如下示例分析。向can0网卡发送数据 cansend can0 586#d465737400000000,ekuiper输出以下结果：

[{"VBBrkCntlAccel": 0,"VBTOSLatPstn": 87.125,"VBTOSLonPstn": -87.25,"VBTOSObjID": 0,"VBTOSTTC": 46.400000000000009}
]

我们尝试通过对dbc数据库文件的理解进行分析，看看是否与ekuiper的计算结果一致。在分析前，我们需要了解几点内容：

1. 位序
   我们知道字节序是一个对象中的多个字节之间的顺序问题，比特序就是一个字节中的8个比特位(bit)之间的顺序问题。一般情况下系统的比特序和字节序是保持一致的。

比如：二进制数11010100,若比特序为大端msb，则最高有效比特位在高位，最低有效比特位在低位，那么它代表的值为0xd4;若比特序为lsb，则最高有效比特位在低位，最低有效比特位在高位，那么它代表的值为0x2b。CAN 总线协议中规定，位序都是大端模式，即 msb。

2. motorola和inter字节序
   在dbc文件解析中，信号定义中有一个参数ByteOrder表示信号的字节顺序。分别为inter和Motorola两种格式。

• Intel格式跟小端格式一样，低地址代表低字节，高地址代表高字节。
• Motorola格式跟大端格式一样，低地址代表高字节，高地址代表低字节。
  注：Motorola格式有2种表达方式，一种是Motorola_LSB，另一种是Motorola_MSB。Motorola_LSB的起始位是从低字节开始的，而Motorola_MSB的起始位是从高字节开始的。dbc文件默认表示Motorola_MSB表达方式，而CANdb++则是Motorola_LSB。

3. 信号传输，都是以补码的形式传输。

分析：

1. 586#d465737400000000表示报文ID为0x586=1414，与RVB_TVR_Debug2_FO报文匹配。其中d465737400000000则为该报文的数据部分。
2. 因为CAN总线协议规定，位序都是大端模式，即可得到下面的layout 图。其中蓝色背景为数据内容，因为RVB_TVR_Debug2_FO报文长度仅有7Byte。

3. VBBrkCntlAccel信号的起始位bit45,且为Motorola字节序，则bit45是信号VBBrkCntlAccel最高有效比特位，因此信号内容如下。即信号原始值为000000000000,物理值=原始值*（0.01）+0 = 0；

4. 同理，可得到其它信号的layout如图。

• VBTOSObjID原始值为000000,物理值=0*1+0=0；
• VBTOSTTC原始值为011101000000,物理值=1856*0.025+0=46.4。至于最终的打印结果为什么是46.400000000000009,可以参考我的博客flaot 数据类型的一些坑（大数吃小数）。
• VBTOSLatPstn原始值为01010111001,物理值=697*0.125+0=87.125。
• VBTOSLonPstn原始值为110101000110。</font color=blue>因为该信号为有符号数，因此最高位1，则表示该值为负。其原始值的补码为110101000110,则原始值为101010111010=-698。物理值=-698*0.125+0=-87.25。

同样的dbc文件，若由CANdb++进行解析，如下。可知Startbit与dbc文件不一致。因为CANdb++默认是Motorola_LSB表达方式。

若我的内容对您有所帮助，还请关注我的公众号。不定期分享干活,剖析案例，也可以一起讨论分享。
我的宗旨：
踩完您工作中的所有坑并分享给您，让你的工作无bug，人生尽是坦途。

总结

经过两天的查阅资料，以及咨询同事，算是熟悉了dbc数据库的解析规则。希望本篇文章，能够帮助到各位小伙伴。