Understanding DBC Files in CAN Bus Networks - AD-EYE/AD-EYE_Core GitHub Wiki

DBC File

A DBC (Database CAN) file is a structured database that holds information about the message, signals, and the encoding scheme used by an electronic control unit (ECU) to transmit messages over a Controller Area Network (CAN) bus. The format of a DBC file is text-based, and it is used to decode and encode CAN messages. DBC files are commonly used in the automotive industry for CAN communication between various ECUs.

The following are the basic components of a DBC file:

  1. Version Information: This component specifies the version number of the format of the DBC file.

  2. Nodes: A node is an ECU that communicates over the CAN bus network. This component specifies the name of the node and its unique identifier.

  3. Messages: A message is a piece of information that is transmitted over the CAN bus network. This component specifies the name of the message, its identifier, and the format of the data.

  4. Signals: A signal is a specific piece of data within a message. This component specifies the name of the signal, the length of the data, and its encoding scheme.

  5. Multiplexors: A multiplexor is used to group related signals within a message.

Here is an example of a DBC file:

VERSION "1.0

NS_ : NS_DESC_ CM_ BA_DEF_ BA_ VAL_ CAT_DEF_ CAT_ FILTER SGTYPE_ SGTYPE_VAL_ EV_DATA_ ENVVAR_DATA_ SGTYPE_DATA_ DEPRECATED_

BU_: BO_ 256 MESSAGE1: 8 MY_ECU BO_ 257 MESSAGE2: 8 OTHER_ECU

BO_ 512 MESSAGE3: 8 MY_ECU
SG_ SIGNAL1 : 0|16@1+ (1,0) [0|65535] "Nm" Vector__XXX
SG_ SIGNAL2 : 16|16@1+ (1,0) [0|65535] "km/h" Vector__XXX
SG_ SIGNAL3 : 32|32@1+ (1,0) [0|4294967295] "" Vector__XXX

BO_ 513 MESSAGE4: 6 OTHER_ECU
SG_ SIGNAL4 : 0|8@1+ (1,0) [0|255] "" MY_ECU
SG_ SIGNAL5 : 8|16@1+ (1,0) [0|65535] "" MY_ECU
SG_ SIGNAL6 : 24|8@1+ (1,0) [0|255] "" MY_ECU"   

Explanation of the above:

VERSION: This specifies the version of the CAN database file format. In this example, the version is set to "1.0".

NS_: This is the namespace section, which defines the different sections and objects that are used in the file. Each section and object is defined on a separate line.

BU_: This is the section where you define the different nodes or ECUs on the network.

BO_: This is the section where you define the different CAN messages that are transmitted on the network. Each message is identified by a unique identifier, in this case 256 or 257, followed by the message name and the length in bytes.

SG_: This is the section where you define the different signals that are transmitted within a message. Each signal is identified by a name and a bit position within the message.

The @ symbol followed by a 1 indicates that the signal is transmitted in little-endian byte order.

The (1,0) in the signal definition represents the scaling factor and offset, respectively.

The [0|65535] specifies the minimum and maximum values that the signal can take on.

MY_ECU and OTHER_ECU are the names of the different nodes that can transmit or receive these messages.

In the above sample dbc file. - the sender and receiver within the messages are identified as "MY_ECU" and "OTHER_ECU". The ID of "MESSAGE1" is 256, the ID of "MESSAGE2" is 257, the ID of "MESSAGE3" is 512, and the ID of "MESSAGE4" is 513. The length of "MESSAGE1", "MESSAGE2", and "MESSAGE3" is 8 bytes, while the length of "MESSAGE4" is 6 bytes.

To be clearer, the sender is not restricted to “MY_ECU” alone, “OTHER_ECU” can also be the sender and vice versa. For example, in "MESSAGE1", "MY_ECU" is identified as the sender, but the intended receiver is not specified in the sample DBC file. However, it is possible for the message to be received by any other ECU in the vehicle, provided that it can interpret and utilize the data contained in the message. While, in "MESSAGE4", "OTHER_ECU" is identified as the sender, and the signals "SIGNAL4", "SIGNAL5", and "SIGNAL6" are intended for receipt by "MY_ECU". However, it is also possible for the message to be received by any other ECU in the vehicle, as long as it can interpret and utilize the data contained in the message.

In MESSAGE3, The sender is the name of the transmitting node (MY_ECU) and the receiving node is not mentioned. Vector__XXX is used if no name is available

Details of the signals within the messages are also provided in the DBC file. For "MESSAGE1", "SIGNAL1" starts at bit 0 of byte 0, "SIGNAL2" starts at bit 16 of byte 0, and "SIGNAL3" starts at bit 32 of byte 0. For "MESSAGE4", "SIGNAL4" starts at bit 0 of byte 0, "SIGNAL5" starts at bit 8 of byte 0, and "SIGNAL6" starts at bit 24 of byte 0. The scale factor of all signals is 1 and the offset is 0. The details for the signals' minimum and maximum values, units, and sender are also provided.

Similarly, a DBC file is a template used by different Electronic Control Units (ECUs) within a vehicle to communicate with each other. The DBC file specify how the messages should be structured, including the sender, receiver, ID, length, and details of the signals within the messages. Using this template, the ECUs can easily communicate with each other, without any errors or confusion.

To use a DBC file in a software application, the application needs to be able to parse the contents of the file and generate code to encode and decode CAN messages. There are several tools and libraries available for this purpose, such as the Vector CANdb++ Editor, the Kvaser DBC Editor, and the cantools, canmatrix library in Python.

Once the DBC file has been created and parsed by the software application, it can be used to send and receive CAN messages between ECUs. The software application can use the information in the DBC file to encode and decode messages, ensuring that the correct signals are assigned to their respective bits within a message. This makes it easier to develop and test applications that communicate over the CAN bus network.

Important Notes:

DBC file format: The DBC file format is a binary file format used to describe a CAN database. The format is used by various software tools in the automotive industry and other industries to generate source code, documentation, and simulation models for CAN-based systems. It is important to know the structure of the DBC file, which includes the headers, messages, signals, and attribute definitions.

Message definitions: A message is a data packet that is sent over the CAN bus to communicate between two or more nodes. The DBC file defines each message sent by the CAN bus system. It details the ID of the message, the name of the message, its length, the data bytes that it contains, and the signals that are contained within each message.

Signal definitions: Signals are used to convey data within the message. The DBC file defines each signal and specifies its ID, name, and length. It also defines the position of each signal within the message, the bit size of the signal, the scaling factor, and the offset value. A signal can also have an associated unit, such as meters or degrees.

Attribute definitions: Attributes define additional information about a specific signal or message. They are used to specify the physical characteristics of a signal, such as the minimum and maximum values, units of measurement, and scaling values. The DBC file specifies the attribute definitions and assigns values to each attribute.

Node and network definitions: The DBC file defines the participating nodes and the communication network topology. It is necessary to know the node names and the network structure in order to establish communication between nodes. DBC files are not limited to use in the automotive industry, but can be used in any application where CAN communication is used. This can include industrial automation, aerospace, and more.

In addition to specifying the format of the messages and signals, a DBC file can also define any signal-specific attributes, such as the physical units associated with a signal. This can help ensure consistency across different ECUs and applications.

There are several advantages to using a DBC file for CAN communication. These include reducing the development time for applications that use the CAN bus, enabling easier debugging and testing of applications, and promoting better communication and collaboration between different teams and departments involved in the development of a system that uses the CAN bus network.

It is important to note that while DBC files provide a standard format for describing and decoding CAN messages, they do not specify how the messages should be processed once they have been received by an ECU. This is typically left up to the specific application or software running on the ECU, and can vary widely depending on the requirements of the system.

DBC files can be created and modified using a variety of software tools, including specialized editors and libraries that support the format. When working with DBC files, it is important to ensure that any changes made to the file are communicated effectively to all teams and departments involved in the development of the system, to avoid introducing errors or inconsistencies.

In conclusion, a DBC file contains structured information about messages, signals, and encoding schemes utilized by ECUs to communicate messages over a CAN bus network. It's widely used in the automotive industry and other industrial sectors. Consequently, understanding how to use a DBC file is a crucial skill for embedded software engineers working on projects that involve communication over a CAN bus network.