总线50讲，如何彻底搞明白dbc中“发送类型”？

dbc是Vector公司发明的，是明码。

dbc文件是汽车电子电控领域最基础的设计文件之一，重要性不言而喻。今天，我们更进一步，来研究一下dbc文件中的一个非常常用、同时也非常混乱的参数，GenMsgSendType。

打开一个dbc文件看看

顾名思义

这个参数的前面三个字母，Gen，不知道是啥意思。

但是从字面上看，这整个词语的意思应该是：报文发送类型。实际上的确如此。下图是一个dbc文件，我们打开之后，双击一个Message，0x666，发现它的TxMethod是FixedPeriod。

“FixedPeriod”这个词是怎么来的呢？如上图所示，我们切换到Attribute选项卡，发现了一个GenMsgSendType选项，可以下拉选择发送类型。当你选中一个（比如Event)之后，在返回去看，就会看到已经生效了，说白了这个参数就是设置发送类型的。如下图所示：

进一步思考

但是，上面那个“发送类型”下拉选项，在不同的dbc文件中，有可能是不一样的，因为不同公司习惯不同。

比如这样的：

再比如这样的：

下拉选项的秘诀在哪里？

我们打开一份dbc文件，用txt打开，找到这样一行：

嗯，就是它，决定了前面那个下拉选择框，GenMsgSendType，所显示的选项。

真相是什么？

既然如此，显示的内容可以不统一，那到底是什么在决定Msg的发送方式呢？

CANoe、TSMaster等总线工具，到底是如何认定的呢？

这个很简单，实际上，在dbc文件中，有另外的参数，真正决定报文的发送方式，参数信息如下：

字母虽然可以定制化，但是数字是全球统一的！！！

比如，0，代表的就是周期报文1，代表的就是事件型报文。

CANoe、Veristand、ControlDesk、TSMaster、PCAN Explorer等一大批商业软件，都是这么识别判断的，它是按照数字来的，不是按照字母。

所以，下拉选择框的设置，你可以设置为：

'FixedPeriodic','Event','EnabledPeriodic','NotUsed','NotUsed','EventPeriodic','NotUsed','NotUsed','NoMsgSendType';

也可以设置为：

'Cyclic','Event','IfActive';

或者甚至直接用汉字：

'周期型','事件型','事件周期型';

都是无关痛痒的！！！

但是！

BA_DEF_ BO_  'GenMsgSendType' ENUM后面的字符串序列，相同索引位置的字符，意思基本是一样的。

比如'FixedPeriodic'和'Cyclic'发索引都是0，、'EnabledPeriodic'和'IfActive'的索引都是2。

这也充分说明了我们刚才的结论，下拉选项的序号，0、1、2、3、4……才是真正决定报文的发送类型，字符只是个显示效果。

由实践到理论，再用理论指导实践

我们接下来，通过实践，来进一步验证我们的理论。

Veristand目前支持三种报文发送类型，如下图所示：

在这三种发送类型下面，如果您要添加报文的话，它是会自动过滤发送类型的。

也就是说，只有周期型的报文才能添加到Cyclic下面，只有Event类型的报文才能添加到EventTriggered下面……

只保留周期型在刚才是讲解中，dbc中的0x666报文（报文名BMS1）的发送类型已经被我修改成了Event。

此时，我们如果试图右键Cyclic然后import frame的话，会发现，BMS1报文被自动过滤掉了，是找不到的，不能添加。

如下图所示，选中all frame之后，底下的报文列表中没有BMS1(0x666)的，只出现了周期型报文。

这也从一个侧面说明了，虽然Veristand和CANdb++对报文发送类型的显示可能不一样，二者的背后识别逻辑却是一样的，都是用数字（以及相关的参数）来识别。

只保留事件型

同样的道理，如果我们在EventTriggerd里面右键，选择import frame的话，BMS1（0x666）又出现了，而刚才的那一堆周期报文全都不见了，不可选了，因为它们不是事件报文，被过滤了。

在CANoe里面做这样的测试，结果是完全一样的！

逆向试验

真理的逆否命题仍然是真理，师子一号做个逆向试验！目前，在这个dbc中，BMS1（0x666）是事件型报文，Event；GW180(0x180)是周期型报文，FixedPeriodic。在导入报文的时候，它们都会被对应的规则过滤出来。

如果我修改dbc源文件里的定义序列枚举字符串，使'FixedPeriodic','Event'位置反一下，会怎样呢？

修改之后如下图所示：

这样修改之后，立刻就会出现变化效果。

在CAN db++中，0x666将会显示为'FixedPeriodic'，0x180将会显示为'Event'，反了过来。

我们可以查看一下：

再利用Veristand的过滤功能鉴定一下：

把这个dbc加载到Veristand工程中，您会发现，它的用法没有丝毫改变，当您右键Cyclic然后import frame时，照样能把0x180导入进来，根本不在乎它现在在CANdb++里面显示自己是Event！

说白了，这些字符只是个显示效果，软件背后的识别规则，是按照数字做的。

博大精深的汉字，浓浓中国风

我们把上面的理论和实际相结合起来，再次修改一下dbc源文件里面的序列，用上汉字。

保存之后，在CANoe里面打开。

神奇而又意料之中的一幕出现了：

把这个dbc导入到Veristand或者CANoe里面，完全正常使用，没有任何违和感，无论人家这个软件能不能处理中文字符…

结论

对于绝大多数Excel2dbc转换工具而言，都不会做这么精细，不用考虑这么多。能显示信号位置，能正常解析信号物理值就得了。但是，对于车辆技术，我们必须做到，因为我们的目标是网络仿真、通信性能分析！更进一步的

不仅仅是这个参数，dbc文件中几乎所有的参数，都是这样的运行机理，都是“逻辑和显示相分离”的，有兴趣的朋友可以研究下。

【推荐】