A CAN frame's data can be divided into eight 1-bit values, 64 1-bit values, one 64-bit value, or any combination of these, and a DBC file can be used to identify, scale, and offset the data represented by any or all of these values.
Vector Informatik GmbH introduced the DBC CAN data description file format.
What is a DBC file?
DBC file is an abbreviation of DataBase Container file.
CAN database files are also known as files with the (.dbc) suffix. DBC files are basic text files that include information for decoding raw CAN bus data to physical values or in human readable form. It specifies which signals (e.g., RPM, Vehicle Speed, etc.) are contained within specific messages (i.e., CAN IDs).
The DBC file is presented since it is the most often used method for managing data identification and translation. The DBC file format was created to provide a mechanism of record keeping in a CAN network.
The DBC file format only represents the reading or passive component; it does not allow for the elaboration of transmissions. To support cars that do not yet have a native adaptation. This is accomplished by utilizing the common DBC vehicle type and DBC files to transform CAN data intro metrics.
Each message in a DBC is converted into a C structure, with the signals acting as its members.
Note: Arrays enable the definition of variable types that may hold many data objects of the same type. Structure is another user-defined data type available in C that permits the combination of data items of various types. A record is represented by a structure.
The DBC structure
The DBC data is made up of the following components:
-
Simple DBC message
-
Signed signals
-
Fractional Signals
-
Enumeration Types
-
Multiplexed Message
A basic DBC message is made up of the Message ID and at least one signal.
An example of a message composed of a single 8-bit signal:
BO_ 500 IO_DEBUG: 4 IO SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG
By providing a negative offset to a transmission, a signed signal may be delivered.
An example of a signed signal in response to the preceding message:
BO_ 500 IO_DEBUG: 4 IO SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG SG_ IO_DEBUG_test_signed : 8|8@1- (1,-128) [0|0] "" DBG
A fractional signal can be transmitted by specifying the range and, if necessary, the accuracy.
BO_ 500 IO_DEBUG: 4 IO SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG SG_ IO_DEBUG_test_signed : 8|8@1- (1,-128) [0|0] "" DBG SG_ IO_DEBUG_test_float1 : 16|8@1+ (0.1,0) [0|0] "" DBG SG_ IO_DEBUG_test_float2 : 24|12@1+ (0.01,-20.48) [-20.48|20.47] "" DBG
When the user prefers to view names rather than numbers, an enumeration type is utilized.
BO_ 500 IO_DEBUG: 4 IO SG_ IO_DEBUG_test_enum : 8|8@1+ (1,0) [0|0] "" DBG BA_ "FieldType" SG_ 500 IO_DEBUG_test_enum "IO_DEBUG_test_enum"; VAL_ 500 IO_DEBUG_test_enum 2 "IO_DEBUG_test2_enum_two" 1 "IO_DEBUG_test2_enum_one" ;
Multiplexed messages can convey more than 8 bytes with a single message ID. A multiplexed message with a single message ID can be defined; however, they are processed and decoded differently depending on which multiplexed value was delivered.
To transmit a multiplexed message, you must send two different messages, one for the m0 and one for the m1.
BO_ 200 SENSOR_SONARS: 8 SENSOR SG_ SENSOR_SONARS_mux M : 0|4@1+ (1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_err_count : 4|12@1+ (1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_left m0 : 16|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_middle m0 : 28|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_right m0 : 40|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_rear m0 : 52|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_no_filt_left m1 : 16|12@1+ (0.1,0) [0|0] "" DBG SG_ SENSOR_SONARS_no_filt_middle m1 : 28|12@1+ (0.1,0) [0|0] "" DBG SG_ SENSOR_SONARS_no_filt_right m1 : 40|12@1+ (0.1,0) [0|0] "" DBG SG_ SENSOR_SONARS_no_filt_rear m1 : 52|12@1+ (0.1,0) [0|0] "" DBG
DBC Example:
VERSION ""
NS_ : BA_ BA_DEF_ BA_DEF_DEF_ BA_DEF_DEF_REL_ BA_DEF_REL_ BA_DEF_SGTYPE_ BA_REL_ BA_SGTYPE_ BO_TX_BU_ BU_BO_REL_ BU_EV_REL_ BU_SG_REL_ CAT_ CAT_DEF_ CM_ ENVVAR_DATA_ EV_DATA_ FILTER NS_DESC_ SGTYPE_ SGTYPE_VAL_ SG_MUL_VAL_ SIGTYPE_VALTYPE_ SIG_GROUP_ SIG_TYPE_REF_ SIG_VALTYPE_ VAL_ VAL_TABLE_
BS_:
BU_: DBG DRIVER IO MOTOR SENSOR
BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR
BO_ 500 IO_DEBUG: 4 IO SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG SG_ IO_DEBUG_test_enum : 8|8@1+ (1,0) [0|0] "" DBG SG_ IO_DEBUG_test_signed : 16|8@1- (1,0) [0|0] "" DBG SG_ IO_DEBUG_test_float : 24|8@1+ (0.5,0) [0|0] "" DBG
BO_ 101 MOTOR_CMD: 1 DRIVER SG_ MOTOR_CMD_steer : 0|4@1- (1,-5) [-5|5] "" MOTOR SG_ MOTOR_CMD_drive : 4|4@1+ (1,0) [0|9] "" MOTOR
BO_ 400 MOTOR_STATUS: 3 MOTOR SG_ MOTOR_STATUS_wheel_error : 0|1@1+ (1,0) [0|0] "" DRIVER,IO SG_ MOTOR_STATUS_speed_kph : 8|16@1+ (0.001,0) [0|0] "kph" DRIVER,IO
BO_ 200 SENSOR_SONARS: 8 SENSOR SG_ SENSOR_SONARS_mux M : 0|4@1+ (1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_err_count : 4|12@1+ (1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_left m0 : 16|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_middle m0 : 28|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_right m0 : 40|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_rear m0 : 52|12@1+ (0.1,0) [0|0] "" DRIVER,IO SG_ SENSOR_SONARS_no_filt_left m1 : 16|12@1+ (0.1,0) [0|0] "" DBG SG_ SENSOR_SONARS_no_filt_middle m1 : 28|12@1+ (0.1,0) [0|0] "" DBG SG_ SENSOR_SONARS_no_filt_right m1 : 40|12@1+ (0.1,0) [0|0] "" DBG SG_ SENSOR_SONARS_no_filt_rear m1 : 52|12@1+ (0.1,0) [0|0] "" DBG
CM_ BU_ DRIVER "The driver controller driving the car"; CM_ BU_ MOTOR "The motor controller of the car"; CM_ BU_ SENSOR "The sensor controller of the car"; CM_ BO_ 100 "Sync message used to synchronize the controllers";
BA_DEF_ "BusType" STRING ; BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0; BA_DEF_ SG_ "FieldType" STRING ;
BA_DEF_DEF_ "BusType" "CAN"; BA_DEF_DEF_ "FieldType" ""; BA_DEF_DEF_ "GenMsgCycleTime" 0;
BA_ "GenMsgCycleTime" BO_ 100 1000; BA_ "GenMsgCycleTime" BO_ 500 100; BA_ "GenMsgCycleTime" BO_ 101 100; BA_ "GenMsgCycleTime" BO_ 400 100; BA_ "GenMsgCycleTime" BO_ 200 100; BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd"; BA_ "FieldType" SG_ 500 IO_DEBUG_test_enum "IO_DEBUG_test_enum";
VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ; VAL_ 500 IO_DEBUG_test_enum 2 "IO_DEBUG_test2_enum_two" 1 "IO_DEBUG_test2_enum_one" ;
How to import DBC files
As previously said, DBC files represent a vehicle's CAN network, and the following will teach you how to import a DBC file from your Autopi cloud.
Step 1: Navigate to Car Explorer Library and press the import button:
Step 2: From the dropdown menu, pick DBC and then the file from your filesystem.
Step 3: In your library, you will see a list of the imported CAN signals:
Some signal names may be self-explanatory, while others may be more difficult to comprehend.
To discover more about it, click this link.
Example of DBC file use cases.
-
OEM CAN data logging
-
Heavy-duty J1939 telematics
-
Recording OBD2 data from automobiles
OEMs frequently utilize proprietary DBC files to decode their CAN data.
The J1939 DBC provides data decoding across vehicle brands and types for heavy-duty vehicle fleet management.
The OBD2 protocol allows you to log data from several automobile brands and quickly decode it using an OBD2 DBC file.
DBC files are essential for establishing prediction models for assessing physical values from machines/vehicles.