本文简略地讲述如何理解和应用J1939 DBC文件。
技术博客
简述J1939和DBC文件
总述
DBC文件是一个基于ASCII的转换文件,用来给CAN帧内传输的数据添加标识名称、缩放比例、偏移量和定义信息。对于任何给定的CAN ID,DBC文件能标识CAN帧中的部分或全部数据。CAN帧中的数据可以分解为8个单字节值、64个一位值、1个六十四位值或这些值的任意组合 – DBC文件可用于标识、缩放和补偿所有这些值代表的数据,或其中的任何一个值所表示的数据。
介绍
要处理控制器局域网(CAN)数据,主要是理解它们的格式和格式转换。在介绍CAN数据时,你很快就会看到到DBC文件,因为这是最常用的数据标识和转换的方法。具体地说,这是对CAN报文的识别,以及将在CAN帧内传输的初始CAN数据转换为有意义的值和信息。
DBC文件类型是Vector Informatik GmbH公司在20世纪90年代开发的,是作为在CAN网络中,描述存储的信息的一个标准方法。它主要用于汽车行业,而且Vector数据库文件(.dbc)实际上已成为标识CAN通讯的行业标准。类似的标准也应用于其他总线系统中,例如FlexRay的FIBEX数据库文件(.xml)和LIN的LIN (.ldf)。
SAE J1939标准在编写和维护时完全认可DBC文件,但该标准中很少提及其术语和细节。实际上,我最近查阅了大多数SAE J1939标准的文献,但这些文献在涉及DBC file概念的部分,既没有提及术语“DBC”,也未提及“database”。
DBC是“database”的缩略,你会听到工程师们交替使用这两个名称。虽然database这个词也应用在许多其他领域和场景中,但在谈及CAN数据时,它很可能是指DBC文件。
J1939 DBC文件
如果我们仅讨论J1939 DBC文件,则需要了解SAE J1939标准协会(正式名称为Truck Bus Control and Communications Network Committee – 卡车总线控制和通信网络协会)不维护或分发任何类型的DBC文件。该标准委员会指定了很多在DBC文件中使用的标识符、名称、编号和格式,但DBC文件本身不是一个SAE产品。SAE维护并销售一个WindowsExcel文件,该文件用于传递创建J1939DBC文件所需的技术信息。此Excel文件名为J1939DA,或Digital Annex(数字附件),可从SAE网站购买。
当你有了此Digital Annex,就可以创建一个J1939DBC文件,它包含所有或部分信息。如果你的产品只需要了解SAE J1939标准中的少量报文,那么你的DBC文件只需要定义该产品需要理解的这部分报文,而不需要定义DBC文件中的所有其他报文。
电脑上的许多Windows应用程序都能读取DBC文件,包括Kvaser的CanKing、和Accurate Technologies的Vision和CANLab 、TK Engineering的CANtrace、Mathworks的 MATLAB Vehicle Network Toolbox、Pi Innovo的PiSnoop、Warwick Controls的X-Analyser 、Vector的CAN db++等。如果你需要,也可以使用Windows记事本来读取和编辑DBC文件,但这很困难,因为该文件不易理解,并使用特殊字符来执行不同的操作。读取和编辑DBC文件的一个简单选项是免费的Kvaser Database Editor 3,可从此处下载。
还有许多其他供应商提供功能各异的DBC文件编辑器,而一些Kvaser合作伙伴已经将Kvaser Database Editor(数据库编辑器)嵌入到他们的工具中。
多数电脑软件应用程序允许同时使用多个DBC文件。这是因为具体的CAN总线有时既包含J1939报文,也包括J1939未定义的其他报文,包括专有报文、其他协议,以及校准数据。通常一个CAN总线监控应用程序会有两个或更多的DBC文件,以便在该应用中定义各种数据。在复杂的CAN网络中,通常也会有部分报文,与任何DBC文件都不相关,没有被任何DBC文件定义。在这种情况下,这些报文通常会由应用程序显示为原始CAN数据。
知识产权考虑
SAE认为SAE J1939DA,即Digital Annex,是其知识产权,因此受到SAE专利和/或版权的保护。SAEs 知识产权声明的第一行是:
SAE的知识产权是其最重要资产。因此,此协会投入大量资源来维护和保护其知识产权。
由于J1939 DBC文件是SAE J1939DA中信息的数字表述,SAE认为J1939 DBC文件是其知识产权。我不是律师,因此我建议你在转售任何可能包含SAE知识产权的产品之前,与律师一起查看SAE条款和条件:
购买J1939协议栈
许多Kvaser技术合作伙伴都销售用于系统开发的J1939协议栈。关于价格等更多信息,请直接联系他们:
emotas GmbH (Germany)
Link: www.emotas.de/en/produkte/sae-j1939-stack
Email: service@emotas.de
LogiCAN (Israel)
Link: www.logi-can.com
Email: ranweiss@bezeqint.net
Warwick Control Technologies (UK)
Link: www.warwickcontrol.com/protocol-stacks/
Email: sales@warwickcontrol.com
理解一个CAN帧中的数据
在我们可以使用DBC文件中的信息之前,我们需要把CAN帧标识符从数据中分离出来。这是一篇旨在理解DBC文件的文章,因此除了说明如何从数据中分离标识符之外,我不打算详细介绍CAN框架。下面是一个典型的CAN帧示例,它有29位标识符和8个字节的数据,如在CANKing中所示:
为了区分不同的信息块,我用各种色彩标示这个CAN帧的每个部分,并用小写字母a到g标记每个块。
- 这只是此设备接收数据的通道。0表示通道1。
- 报文标识符。进一步的说明:标识符包含报文的优先权、参数组号(PGN)和源地址(SA)。
- X表示这是扩展标识符报文,即29位标识符。
- Data Length Code (DLC) – 数据长度代码为8,表示此报文包含8个字节的数据。
- 这就是我们需要的 – 8个字节的数据。
- 这是一个以秒为单位的时间戳,由应用程序添加到每个接收到的CAN帧上。
- R只是告诉我们,这个帧是由CANKing接收的。
现在我们已经分离了此CAN帧的数据部分,让我们来看一下如何表达这些数据。这是我们查看DBC文件的地方。DBC文件给电脑应用程序提供数据、分解数据、比例和偏移量,以及标识数据和解释数据所需的信息,从而让应用程序可以解读这些信息。我们现在是从接收数据的角度解释DBC文件。当我们收到CAN帧时,我们会做所有这些操作。而当我们需要将这一原理应用到CAN帧的创建和发送,我们则需要反向思维和反向操作。本文将解释DBC文件如何为接收CAN帧服务,因为一旦理解了这一点,就不难理解发送原理
如何使用DBC文件的范例
如果我们使用任何给定的监测软件查看CAN通讯,而且该通讯中的一个报文不是由某个相关的DBC文件定义的,那么它将显示为原始CAN帧,并且看起来像这样:
这是用Kvaser的CANKing捕捉到的一行代码。CANKing是一个免费CAN监测应用程序,能通过任何一款Kvaser适配器使用操作,可在这里下载:
CANKing使用我们称为格式器的应用程序来格式化数据,并使其更易于显示。在CANKing中,你可以打开 Select Formatter (选择格式器)窗口,在各种格式器中进行选择。上面的数据是通过CANKing中的Standard Text Format(标准文本格式)选项格式化的。我不会深入讨论CANKing及其格式器,因为这篇博客是关于DBC文件的,但是由于我们使用CANKing来显示本博客范例中使用的数据,所以有必要适当说明格式化选项和不同的格式。
CANKing能够加载和使用DBC文件,以使这些数据更有意义,更易于阅读。如果我们已将适当的DBC文件上传到CANKing中,则该CAN帧的标识符将被能识别,并且此数组中的数据会得到正确的转换和标示。现在你的显示器屏幕看起来基本是这样:
0 18FE6900 X 8 9C 27 DC 29 FF FF F3 23 230.871160 R
CAN 1 65129 0 all 6 J1939.ET3 230.871160 R
9C27DC29 FFFFF323
-> EngChargeAirCooler1Outlet 14.5938 deg C
-> EngIntkVlvActuationSystem 1774.9688 deg C
-> EngIntakeManifold1AirTemp 43.8750 deg C
-> EngCoolantTemp 61.8750 deg C
在此范例中,报文被标识为ET3 ,该报文中的一个信号被标识为EngCoolantTemp。所有这些标识信息都包含在DBC文件中,在此例中,DBC文件名为J1939.dbc。CANKing使用CAN报文18FE6900的眉头的一部分,通过引用DBC文件中的信息,将此报文标识为ET3。当标识报文完成,CANKing就可以进入该数据,选择如何对该数据的进行格式化和标示,让它成为我们可读的信息。
在这个范例中,我只关注数据中的一个信号, EngCoolantTemp 信号。下面是Kvaser的免费应用 – Kvaser Database Editor 3(可从上面的链接下载)- 的一个截图。
这些数据告诉我的是,信号EngCoolantTemp是Intel格式的无符号整数,从16位开始,长度为16位。它还告诉我偏移量是-273,信号的比例因数是0.03125。
我们现在可以手动执行通常由CANKing对DBC文件中的信息,和对信号EngCoolantTemp中的数据所做的操作。首先我们分离信号。下面是该报文中传输的8个字节的数据,信号 EngCoolantTemp 位于下面的红色框中:
我们怎么会知道信号EngCoolantTemp在该报文中的位置?DBC文件告诉我们信号从16位开始,长度为16位。如果我们从左向右读取数据,会看到9C处于最前面8位(位0到7),27是报文中的第二个字节(位8到15),而DC 29处于位16到31。位16到位31代表我们知道的EngCoolantTemp的16位值。
在添加偏移量和比例因数之前,我们必须考虑字节顺序。这就是Byteorder Intel (字节顺序)的位置;字节顺序的 Intel 格式被称为Little end-in – 即最低有效字节优先。如果最低有效字节最先传输,那么我们必须调转该信号中的两个字节的位置,这样此信号将为29DC。这是在应用偏移和比例之前,信号EngCoolantTemp所传输的十六进制值。
下一步,我们必须将此数值转换为十进制,我们可以手动计算或使用电脑上的计算器,将其设置为Programmer mode(程序员模式):
29DC (基于16进制) = 10,716
(如果你对这种转换不是非常熟悉,请去查阅不同进制的转换,以及十六进制到十进制的转换。)
现在我们已准备好添加比例和偏移。刻度和偏移量都显示为十进制数,所有我们将它们添加到EngCoolantTemp进制值10,716:
首先我们加上比例:
10,716 x 0.03125 = 334.875
然后,附加偏移之后我们得到:
334.875 – 273 = 61.875
这个信号上的单位是摄氏度,所以结果是61.875℃,正如上面从CANKing截图所示。
所以,当你回去看一下上面的EngCoolantTemp值,如CANKing所显示,正好就是我们在这里计算出来的值。我们在这里手工做的计算,与任何软件应用程序通过DBC文件显示可读数据进行的计算完全相同。我们已经获取了通过CAN总线适配器接收到的原始数据,就像从总线接收到的一样,并在适当的DBC文件中进行了定义和信息处理,对原始数据添加了偏移和比例,获得了可读数值。如果没有DBC文件中的信息,CAN数据将对我们毫无意义。因此可见,DBC文件是在CAN总线通讯中标识关键传输数据和信息的最常用方式。
你有任何问题?
请联系 support@kvaser.com, 或者直接与Bryan先生联系: bryan.hennessy@kvaser.com.
进一步培训
其他培训,包括网站上培训,可由Kvaser的技术合作伙伴提供: