本文简略地讲述如何理解和应用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的技术合作伙伴提供:
