Cloud Login
Need a simple, practical intro to DBC files?
DBC files are used to decode raw CAN bus data. They define which CAN ID contains which signals, where each signal is located in the payload, and how the raw bytes should be converted into physical values such as speed, RPM, temperature, pressure or status.
A DBC file is used to describe CAN messages and signals.
It works like a translation layer between raw CAN frames and values that people can actually use.
Without a DBC file, a CAN frame is mostly just an identifier and a payload of bytes.
With a DBC file, those bytes can be decoded into real values such as vehicle speed, engine RPM, battery temperature, hydraulic pressure, switch states or diagnostic flags.
This article explains what a DBC file is, how the structure works, why it matters in CAN projects and how DBC files can be imported and used in AutoPi Cloud.
What is a DBC File?
A DBC file, or DataBase Container file, is a CAN database format used to define CAN messages and signals.
The format is commonly associated with Vector Informatik GmbH and is widely used in automotive and embedded CAN projects.
In practical terms, a DBC file tells the decoder how to turn raw CAN data into readable values.
When we talk about raw CAN bus data, we are talking about frames made of identifiers and payload bytes.
That data can contain useful information, but it is not obvious by just looking at the raw values.
A frame may include vehicle speed, engine RPM, battery state, sensor status, torque demand or fault information.
But without the signal definition, it is just bytes.
A DBC file describes how those bytes should be interpreted.
It defines the message ID, signal name, start bit, length, byte order, signed or unsigned format, scaling, offset, unit and valid range.
This is what makes the raw CAN data useful for dashboards, logs, diagnostics and backend integrations.
Keep reading if you want to know how to import DBC files into AutoPi Cloud.
A simple example is vehicle speed.
The CAN frame may contain a value like 0x1A90.
The DBC file explains which bits belong to the speed signal, whether the value is little-endian or big-endian and how the value should be scaled.
After decoding, the result can become a physical value such as 67.4 km/h.
This is why DBC files are important in CAN data logging.
They turn bus traffic into useful information.
For AutoPi projects, a DBC file can be used to decode CAN traffic from vehicles, machines and equipment before the data is shown in dashboards or sent to another system.
Import DBC files, decode CAN signals and use the data in dashboards, logs and integrations.
The DBC Structure
A DBC file has a few important parts.
The most important parts are messages, signals, scaling, units, value tables and optional comments.
When you understand these parts, reading a DBC file becomes much more simple.
-
DBC message: A CAN message definition. It includes the message ID, message name, payload length and sender. It normally contains one or more signals.
BO_ 500 IO_DEBUG: 4 IO SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG
-
Signed signals: Used when a signal can have negative values. This can be needed for values such as steering angle, torque request or temperature.
A signed signal can be defined by using a signed signal type and an offset where needed.
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
-
Fractional signals: Used when the raw value must be scaled to get the real physical value. This is common for speed, temperature, pressure and current.
A fractional signal uses a factor and sometimes an offset to convert the raw value.
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
-
Enumeration types: Used when a numeric signal should be shown as a readable state. For example, 0 can mean off and 1 can mean on.
Enumeration values make logs and dashboards easier to read.
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 message: Used when the same message ID can contain different signal layouts. The mux value decides which signal group should be decoded.
Multiplexing is useful when several related payload formats share the same CAN ID.
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
Here is a DBC file 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" ;
The description field in DBC files
In DBC files, most attention is normally on signal definitions, scaling and attributes.
But the description field is also useful.
It gives space to document what a signal is used for, where it comes from and how it should be understood.
This is important when several engineers, customers or systems work with the same DBC file.
A good description can reduce confusion and make the DBC easier to maintain.
It can explain the signal purpose, expected range, operating condition or special notes that are not clear from the raw scaling alone.
A segment of a DBC file with a description field can look like this:
VERSION "1.0" NS_: NS_DESC_ NS_SIG_ NS_VAL_ BS_: BU_: ECU1 ECU2 BO_ 1 Message_1: 8 ECU1 SG_ Signal_1 : 0|8@1+ (1,0) [0|255] "" ECU2 SG_ Signal_2 : 8|8@1+ (1,0) [0|255] "" ECU2 CM_ SG_ 1 Signal_1 "This signal is used for temperature reading in Fahrenheit." CM_ SG_ 1 Signal_2 "This signal represents the fuel level as a percentage." VAL_ 1 Signal_1 0 "Low" 255 "High"; VAL_ 1 Signal_2 0 "Empty" 100 "Full";
Use DBC files to turn CAN frames into values that can be logged, shown and used in your project.
Why DBCs matter in real projects
DBC files are important because they connect raw CAN traffic with useful engineering data.
In many projects, the problem is not only collecting CAN frames.
The real problem is understanding what the frames mean and using the data in a system.
Common use cases include:
- Vehicle diagnostics: DBC files help technicians and engineers decode CAN data faster and use it for troubleshooting.
- Fleet management and J1939: J1939 DBC data can be used for heavy-duty fleet signals such as engine speed, fuel rate, engine hours and fault information.
- Performance tuning with OBD2 data: DBC files can help decode vehicle values used for testing, calibration and performance analysis.
- Predictive maintenance: Decoded CAN signals can show trends that help plan service before a fault becomes downtime.
- Safety and ADAS: DBC definitions can help interpret sensor and controller data from safety-related systems.
- Agriculture and industrial automation: DBC files are also useful in machines and industrial systems where CAN is used outside passenger cars.
In short, DBC files make CAN data easier to use.
They are a practical part of diagnostics, logging, development, fleet management and machine monitoring.
DBC File Guide Video
Step-by-step guide to importing DBC files
AutoPi Cloud can import DBC files so decoded CAN signals can be used in the platform.
The flow below shows the basic process.
- Start the process: Register or log in to the AutoPi demo environment.
- Open the OBD Library: After login, go to the fleet management overview. In the left sidebar, under Device Management, select OBD Library.
- Click import: In the OBD Library, click the Import button to start the file import process.
- Select import file: In the pop-up window, choose Import File.
- Choose the DBC file: Browse your computer and select the DBC file you want to import.
- Upload the file: After selecting the file, click Upload and wait until the file is imported.
- Check the imported DBC file: After import, the DBC file is available in AutoPi Cloud. You can view the file and edit CAN message definitions where needed.
For more details about managing DBC files in AutoPi Cloud, see the Car Explorer Library documentation.
This is useful when DBC files are part of a fleet management, CAN logging or vehicle data project.
Concluding thoughts
DBC files are one of the most useful parts of a CAN data workflow.
They bridge the gap between raw CAN frames and readable vehicle or machine data.
A good DBC file makes it possible to decode signals, build dashboards, generate reports, detect problems and send useful values to other systems.
For simple testing, a DBC file can help an engineer understand what is happening on the bus.
For fleet and industrial projects, it can become part of the full data pipeline from vehicle to cloud.
With AutoPi Cloud and AutoPi devices, DBC files can be used to decode CAN data and make it available for diagnostics, monitoring, development and integrations.
