CAN DBC File Explained - A Simple Intro [+Editor Playground]
Need a simple, practical intro to CAN DBC files?
To get practical, we also include real J1939/OBD2 data and DBC files - which you can load in free open source CAN tools.
Get ready to fully understand CAN DBC files!
Tip: Start by checking out our 5 min intro video above!
What is a CAN DBC file?
A CAN DBC file (CAN database) is a text file that contains information for decoding raw CAN bus data to 'physical values'.
To understand what 'raw CAN data' looks like, see the below example CAN frame from a truck:
CAN ID Data bytes 0CF00400 FF FF FF 68 13 FF FF FF
If you have a CAN DBC that contains decoding rules for the CAN ID, you can 'extract' parameters (signals) from the data bytes. One such signal could be EngineSpeed:
Message Signal Value Unit EEC1 EngineSpeed 621 rpm
To understand how DBC decoding works, we will explain the DBC syntax and provide step-by-step decoding examples.
DBC message & signal syntax
Let us start with a real CAN DBC file example.
Below is a demo J1939 DBC file that contains decoding rules for speed (km/h) and engine speed (rpm). You can copy this into a text file, rename it as e.g. j1939.dbc and use it to extract speed/RPM from trucks, tractors or other heavy-duty vehicles.
VERSION "" NS_ : CM_ BA_DEF_ BA_ BA_DEF_DEF_ BS_: BU_: BO_ 2364540158 EEC1: 8 Vector_XXX SG_ EngineSpeed : 24|16@1+ (0.125,0) [0|8031.875] "rpm" Vector_XXX BO_ 2566844926 CCVS1: 8 Vector_XXX SG_ WheelBasedVehicleSpeed : 8|16@1+ (0.00390625,0) [0|250.996] "km/h" Vector_XXX CM_ BO_ 2364540158 "Electronic Engine Controller 1"; CM_ SG_ 2364540158 EngineSpeed "Actual engine speed which is calculated over a minimum crankshaft angle of 720 degrees divided by the number of cylinders...."; CM_ BO_ 2566844926 "Cruise Control/Vehicle Speed 1"; CM_ SG_ 2566844926 WheelBasedVehicleSpeed "Wheel-Based Vehicle Speed: Speed of the vehicle as calculated from wheel or tailshaft speed."; BA_DEF_ SG_ "SPN" INT 0 524287; BA_DEF_ BO_ "VFrameFormat" ENUM "StandardCAN","ExtendedCAN","reserved","J1939PG"; BA_DEF_ "BusType" STRING ; BA_DEF_ "ProtocolType" STRING ; BA_DEF_DEF_ "SPN" 0; BA_DEF_DEF_ "VFrameFormat" "J1939PG"; BA_DEF_DEF_ "BusType" ""; BA_DEF_DEF_ "ProtocolType" ""; BA_ "ProtocolType" "J1939"; BA_ "BusType" "CAN"; BA_ "VFrameFormat" BO_ 2364540158 3; BA_ "VFrameFormat" BO_ 2566844926 3; BA_ "SPN" SG_ 2364540158 EngineSpeed 190; BA_ "SPN" SG_ 2566844926 WheelBasedVehicleSpeed 84;
At the heart of a DBC file are the rules that describe how to decode CAN messages and signals:
- A message starts with BO_ and the ID must be unique and in decimal (not hexadecimal)
- The DBC ID adds adds 3 extra bits for 29 bit CAN IDs to serve as an 'extended ID' flag
- The name must be unique, 1-32 characters and may contain [A-z], digits and underscores
- The length (DLC) must be an integer between 0 and 1785
- The sender is the name of the transmitting node, or Vector__XXX if no name is available
- Each message contains 1+ signals that start with SG_
- The name must be unique, 1-32 characters and may contain [A-z], digits and underscores
- The bit start counts from 0 and marks the start of the signal in the data payload
- The bit length is the signal length
- The @1 specifies that the byte order is little-endian/Intel (vs @0 for big-endian/Motorola)
- The + informs that the value type is unsigned (vs - for signed signals)
- The (scale,offset) values are used in the physical value linear equation (more below)
- The [min|max] and unit are optional meta information (they can e.g. be set to [0|0] and "")
- The receiver is the name of the receiving node (again, Vector__XXX is used as default)
Example: Extract physical value of EngineSpeed signal
To understand how DBC decoding works, we'll show how to extract the signal EngineSpeed from the CAN frame in the intro:
CAN ID Data bytes 0CF00400 FF FF FF 68 13 FF FF FF
Tip: Further below we provide a simple DBC editor playground - try using it with this EngineSpeed example.
In practice, most raw CAN data log files contain 20-80 unique CAN IDs. As such, the first step is to map each CAN ID to the relevant conversion rules in the DBC. For regular 11-bit CAN IDs, this can simply be done by mapping the decimal value of the CAN ID to the DBC CAN IDs. For extended 29-bit CAN IDs, a mask (0x1FFFFFFF) needs to be applied to the 32-bit DBC ID to get the 29-bit CAN ID - which can then be mapped against the log file.
To easily convert between the IDs, see the 'DBC ID vs CAN ID' sheet in our DBC editor playground.
Regarding J1939 PGN conversion
In this example we directly map the 29-bit CAN ID to the 'masked' DBC ID. In practice, J1939 conversion is often done by extracting the 18-bit J1939 PGN from the CAN ID and the DBC ID and then comparing the PGNs.
Next, use the DBC bit start, length and endianness to extract the relevant bits from the CAN frame data payload. In this example, the start bit is 24 (meaning byte 3 when counting from 0) and the bit length is 16 (2 bytes):
FF FF FF 68 13 FF FF FF
Big endian vs. little-endian (advanced)
In the example, we use little-endian, meaning that the 'bit start' in the DBC file reflects the position of least-significant bit (LSB). If you add a DBC signal in a DBC file viewer (e.g. Vector CANDB++), the LSB is also used as the bit start in the DBC editor.
If you instead add a big-endian signal in a DBC editor GUI, you'll still see the LSB as the bit start - but when you save the DBC, the bit start is set to the most significant bit (MSB) in the signal. This approach makes GUI editing more intuitive, but can be confusing if you switch between a GUI and text editor.
To understand this fully, check out our CAN DBC editor playground.
The EngineSpeed signal is little-endian (@1) and we therefore need to reorder the byte sequence from 6813 to 1368.
Next, we convert the HEX string to decimal and apply the linear conversion:
physical_value = offset + scale * raw_value_decimal 621 rpm = 0 + 0.125 * 4968
In short, the EngineSpeed physical value (aka scaled engineering value) is 621 rpm.
Steps 1-3 take outset in a single CAN frame. In practice, you'll decode raw data from e.g. vehicles, machines or boats with millions of CAN frames, timestamps, several unique CAN IDs and sometimes hundreds of signals.
To handle this complexity, specialized software is used to decode raw CAN data into human-readable form by loading the data log files and related DBC file(s). To illustrate what the output may look like, we've added a snippet of DBC decoded J1939 data logged with a CANedge. The data has been converted via asammdf, filtered to include a set of relevant signals and exported as CSV:
CAN DBC editor playground
Adding or editing signals in your DBC file can be confusing.
To help you better understand how this works, we've created a very basic online 'CAN DBC editor playground'. You can open it and edit the yellow cells - or make a copy for personal use.
Feel free to bookmark the editor and share it!DBC editor playground
J1939/OBD2 data & DBC samples
The best way to learn more about DBC conversion of raw CAN bus data is to try it out.
Below you can download raw J1939/OBD2 data from the CANedge2. The zip also includes an OBD2 DBC and a demo J1939 DBC.
Via the link, you can also download the free asammdf GUI to open the data & DBC files. Try plotting EngineSpeed as an example.Sample data & dbc files
Advanced: Meta info, attributes & multiplexing
In this section we briefly outline some of the more advanced topics of CAN DBC files, incl. meta info, attributes, value tables and multiplexing. If you're new to DBC files you can optionally skip this section.
The DBC file can contain various extra information and below we outline the most common types. This information is stored in the DBC file after all the messages.
The comment attribute lets you map a 1-255 character comment to a message ID or signal name, e.g. to provide more information.
Example for EEC1 message:
CM_ BO_ 2364540158 "Electronic Engine Controller 1"
Example for EngineSpeed signal:
CM_ SG_ 2364540158 EngineSpeed "Actual engine speed which is calculated over a minimum crankshaft angle of 720 degrees divided by the number of cylinders....";
Custom attributes can be added to messages and signals in a similar way as the comment syntax. A typical attribute is the VFrameFormat, which can be used to describe the message frame type. It is initialized as below:
BA_DEF_ BO_ "VFrameFormat" ENUM "StandardCAN","ExtendedCAN","reserved","J1939PG";
Once initialized, a message can be mapped as follows (indexing from 0):
BA_ "VFrameFormat" BO_ 2364540158 3;
In this case, we inform that the message EEC1 is of the J1939 PGN type, which may result in specific display or handling in various DBC editor GUI tools, as well as data processing tools.
Similarly, you can add J1939 SPN IDs as an attribute as below:
BA_DEF_ SG_ "SPN" INT 0 524287; BA_ "SPN" SG_ 2364540158 EngineSpeed 190;
Here, EngineSpeed is assigned the SPN 190. You might find it more natural to do this in the opposite way - i.e. use the SPN IDs in the message/signal section, then map the SPN names via attributes. While you can definitely do this, it is not the most common convention. Further, the first character in a CAN DBC signal name cannot be a number - so you'd need to write e.g. _190 or SPN_190.
Some CAN DBC signals are 'state variables', such as gear-shift, diagnostic trouble codes, status codes etc. These take discrete values and will require a mapping table to enable interpretation.
The CAN DBC format enables this via value tables, which let you assign a state description to the physical decimal value of each state of a signal. The states should be in descending order.
VAL_ 2297441534 MaterialDropActiveStatus 3 "NotAvailable" 2 "Error" 1 "On" 0 "Off" ;
Multiplexing is sometimes used in CAN bus communication, with perhaps the most known example being within OBD2 communication. Consider for example the below OBD2 response frames:
7E8 03 41 11 30 FF FF FF FF 7E8 03 41 0D 37 FF FF FF FF
Here, both response frames carry 1 byte of data in byte 3, yet despite the CAN ID being identical, the interpretation of the data differs between the two frames. This is because byte 2 serves as a multiplexer, specifying which OBD2 PID the data is coming from.
To handle this in a DBC file context, the below syntax can be applied:
BO_ 2024 OBD2: 8 Vector__XXX SG_ S1_PID_0D_VehicleSpeed m13 : 31|8@0+ (1,0) [0|255] "km/h" Vector__XXX SG_ S1_PID_11_ThrottlePosition m17 : 31|8@0+ (0.39216,0) [0|100] "%" Vector__XXX SG_ S1 m1M : 23|8@0+ (1,0) [0|255] "" Vector__XXX SG_ Service M : 11|4@0+ (1,0) [0|15] "" Vector__XXX ... SG_MUL_VAL_ 2024 S1_PID_0D_VehicleSpeed S1 13-13; SG_MUL_VAL_ 2024 S1_PID_11_ThrottlePosition S1 17-17; SG_MUL_VAL_ 2024 S1 Service 1-1;
Here, the M in the Service signal serves as the 'multiplexor signal'. In this case, it toggles which OBD2 service mode is used (mode 01, 02, ...). The signal S1 is multiplexed by Service, which is evident from the SG_MUL_VAL_ field where the two are grouped.
As evident, the signal S1 has the value m1 after the signal name, which means that if the Service signal takes the value 1, the data reflects the OBD2 service mode 01.
The above is referred to as simple multiplexing. But CAN DBC files also support extended multiplexing, where a multiplexed signal (in this case S1) can also be a multiplexor and thus control the interpretation of other parts of the data payload. To see this, note that S1 takes the same role as Service in the syntax, adding an M after m1 and being grouped with the two OBD2 PIDs, speed and throttle position.
Extended multiplexing works as before: If S1 takes the value 13 (HEX 0D), it means that only signals that are A) part of the S1 group and B) have a multiplexer switch value of 13 should be taken into account. In this example, it means that byte 4 reflects data for vehicle speed. If byte 3 equals 17 (HEX 11), byte 4 reflects data for the throttle position instead.
DBC multiplexing and extended multiplexing is an advanced topic and not supported by all data processing tools. However, you can use e.g. the CANDB++ DBC editor to more easily view and understand DBC files with multiplexing, like the OBD2 DBC:OBD2 DBC file
The OBD2 DBC file can be used together with our CANedge CAN loggers for the purpose of decoding OBD2 frames in e.g. asammdf or our Python API modules. For more on this topic, see Vector's guide to extended multiplexing in DBC files here.
DBC software tools (editing & processing)
Software that uses CAN DBC files can be split in two groups: Editing & data processing.
DBC editor tools
- Vector CANDB++: The free demo version of Vector's CANalyzer includes a useful version of CANDB++, the Vector DBC editor. It offers the most extensive functionality available, including quick "consistency checks" of DBC files
- Kvaser Database Editor: Kvaser provides a free and easy-to-use CAN DBC editor, which includes the ability to append DBC files and visualize the signal construction
- canmatrix: This open source Python DBC module lets you load DBC files, edit them and export them to other formats. It is used in e.g. asammdf and our Python API
CAN data processing tools
Most CAN data processing tools support DBC files - including below:
- asammdf GUI: The asammdf GUI lets you load raw MDF4 data and DBC convert it to human-readable form - as well as create quick plots, analyses and exports
- Python API: Our Python API lets you automate the DBC conversion of your data e.g. for large-scale data analysis or as part of telematics dashboard integrations
- Other tools: Our MDF4 converters let you quickly convert your CANedge MF4 data to e.g. Vector ASC, PEAK TRC and more
Getting started: If you need to construct a new DBC file, we recommend using one of the DBC editors above. For beginners, we recommend the Kvaser DBC editor. When creating a new DBC file, you can typically select a DBC template (e.g. a CAN FD DBC, J1939 DBC, NMEA 2000 DBC etc). Next, start by adding a single message and a single signal to the DBC and save it.
To ensure your DBC looks OK, we recommend to open the DBC in a text editor. This way you can verify that the basic DBC syntax looks as you'd expect - and you can use this version as a benchmark for comparison. It's a good idea to maintain git revisioning on any changes to the DBC from here.
Test your DBC: As a second step, we recommend to test the DBC file using a CAN bus decoder software tool. For example, if you're using a CANedge CAN bus data logger to record raw CAN data from your application, you can use the free CAN decoder software, asammdf, to load your raw data and your DBC file. This way you can quickly extract the signal you added in the DBC - and verify via a visual plot that the construction looks OK.
Expand your DBC: Next, you can add any remaining CAN messages and signals, as well as comments/descriptions, value tables etc. We recommend to do regular checks as before to ensure the construction is OK.
Check consistency: Finally, we recommend doing a full consistency check both in Vector's DBC editor, CANDB++, and Kvaser's DBC editor. In CANDB++ select 'File/Consistency Check' and keep an eye out for critical errors (though note that your DBC may be sufficiently valid for most tools, even if some issues are reported). In the Kvaser database editor, you can select each message to quickly spot signals with invalid fields (they'll be highlighted in yellow). Once you are done, we always recommend doing a visual analysis of your scaled CAN data to ensure that you do not have e.g. endianness, scale factor or offset errors.
Public DBC files for your car
How do you decode CAN data from your car if you're not the manufacturer?
Below are the main options:
The simplest option is normally to log OBD2 data, which is supported in most cars after 2008. If your car does not support OBD2 (or you need non-OBD2 signals), you can check if open source DBC files exist for your specific car.
In some cars, you can neither record OBD2 or raw CAN data via the OBD2 connector (due to gateways). If you believe you have found online CAN DBC files for your car, but you are not getting any CAN data via the OBD2 connector due to a gateway, you can try using a CANCrocodile adapter to log CAN data directly from the CAN wiring harness.
An alternative may be proprietary UDS requests via the OBD2 connector, assuming you can find details on these for your car online (e.g. via our list below).
As a last resort, you can try and reverse engineer certain CAN signals, though it's a difficult exercise and highly time consuming.
Reverse engineered CAN/OBD2/UDS databases for cars
Below we list a number of online open source databases that contain decoding rules for cars in the form of DBC files (or other formats). These are typically based on reverse engineering so the quality may vary.
- OpenDBC: DBC files for BMW, Cadillac, Chrysler, Ford, GM, Honda, Hyundai, Lexus, Nissan Leaf, Tesla, Toyota, VW and more
- Tesla Model 3 & Y: DBC file for Tesla Model 3 and Tesla Model Y
- OBD Dash: Proprietary OBD2 PID info on Mitsubishi, Renault, Subaru, Opel, Hummer and more
- Kia Soul: Google sheet containing decoding information for the Kia Soul EV
- Open Garages: Collection of links for decoding info, incl. Mazda, Ford Mondeo, Prius, Mini Cooper, Dodge and more
- EV PID collection: Proprietary OBD2/UDS PIDs for EVs, incl. Hyundai Kona, Ioniq EV, Kia Niro, Optima, Ray, Soul EV and more
- Nissan Leaf DBC: Nissan Leaf EV DBC files for use in some Leaf EV models (though not 2019+)
- Renault Zoe: This CSV contains decoding info for the Renault Zoe EV
Note that some of the databases above contain information for decoding proprietary UDS data. The proprietary UDS databases are typically not structured in DBC form, though you can take outset in our UDS DBC & API example to get started on creating your own UDS DBC file. See also our Unified Diagnostic Services tutorial.
Most CAN networks are proprietary in the sense that only the Original Equipment Manufacturer (OEM) has the DBC file required to decode the data. This is the case e.g. for raw CAN data in most cars, bikes, EVs, production machinery etc. As such, if you are not the OEM, you will need to reverse engineer the decoding rules (or research to see if others have done this already). Reverse engineering CAN bus data is a time-consuming exercise, but can be done in some cases.
There are, however, also cases where the decoding rules are standardized:
J1939: The vast majority of heavy-duty vehicles are based on the J1939 protocol. This means that you can typically use the standardized J1939 DBC file to decode data across different models/brands/years of trucks, excavators, transit buses etc. However, it is still up to the OEM to what extent the encoding follows the standard, so often there will still be a share of proprietary CAN IDs in each vehicle.
NMEA 2000: For maritime use cases, you can use our NMEA 2000 DBC to decode most signals from marine CAN bus applications.
OBD2: While raw CAN data in cars is proprietary, most cars support data via the OBD2 protocol. The decoding rules for most of these OBD2 parameter IDs (PIDs) are public. As such, you can use e.g. our free OBD2 DBC file to decode standard Mode 01 OBD2 PID data recorded with the CANedge. Similarly, the OBD2 decoding rules are embedded in the CLX000 software CANvas, enabling easy decoding of standard OBD2 PIDs.
Get the 'DBC Data Pack'
Want a compiled list of car DBC files?
Download your 'data pack' incl. our OBD2 DBC, 25+ car DBCs and 100+ MB of OBD2 data across 10+ cars!
CAN DBC file example use cases
DBC files are vital to practically any use case related to logging CAN bus data - below we outline some examples:
OEM CAN data logging
Proprietary DBC files are often used by OEMs for decoding their CAN data - e.g. for blackbox data loggingcan bus blackbox
Heavy-duty J1939 telematics
For heavy-duty vehicle fleet management, the J1939 DBC enables decoding of data across vehicle brands & modelsj1939 telematics
Logging OBD2 data from cars
The OBD2 protocol lets you log data across car brands - and easily decode it using our free OBD2 DBC fileobd2 logger
DBC files are key to setting up prediction models for analyzing physical values from machines/vehiclespredictive maintenance
Do you have a CAN logging & DBC decoding use case? Reach out for free sparring!Contact us
Yes, you can purchase a J1939 DBC file by ordering it online (or by requesting a quotation via mail). The J1939 DBC is based on the J1939 Digital Annex by SAE (Society of Automotive Engineers) and is sold as a legal license in collaboration with SAE.
The J1939 DBC can be loaded in CAN data processing tools like asammdf and the Python API tools for the CANedge CAN logger. This lets you decode data for heavy-duty vehicles across different manufacturers.
The J1939 DBC contains 6,400+ J1939 SPN signals, meaning in practice that you can typically decode most of the relevant parameters for your use case across heavy-duty vehicle brands. In case you need to extend the J1939 DBC with proprietary J1939 PGN or SPNs (e.g. from reverse engineering or from the OEM), you can do so via one of the DBC editing tools.
If you have questions on the J1939 DBC, feel free to contact us.
The CAN DBC file format was developed by Vector Informatik GmbH in the 1990s. Today it is by far the most common format for storing CAN bus conversion rules. It should be noted, though, that the DBC standard is proprietary in the sense that no official DBC file format documentation is available. As such, most online DBC syntax documentation is added by 3rd parties.
The proprietary nature of the DBC file standard has given rise to a number of open source DBC file alternatives. Examples include DBF by Busmaster and KCD by Kayak. Of course, some projects also disregard the use of CAN database files entirely and instead 'hardcode' the necessary decoding information into scripts and software.
In some casee (like SAE J1939), a DBC file may include more CAN signals in a CAN message than are actually packed in the dataframe. The J1939 DBC that we offer is based on the J1939 Digital Annex and provides information that goes across most heavy duty vehicle brands. Of course, not every truck or excavator will include the same data and often a specific vehicle model/year will only use e.g. 2-3 SPNs within a specific CAN message - while the J1939 DBC may specify up to e.g. 8 unique signals for that particular CAN message ID.
To handle this, the J1939 standard specifies that bytes padded with "FF" should be considered invalid or not available. Some DBC decoding tools will still decode these parts of the data frame, which can result in odd-looking charts where the invalid signals take on constant values equal to their theoretical maximum. Other tools, like asammdf and our Python API modules, enable the user to ignore invalid signals - thus limiting the decoded data to the relevant signals.
In some cases it can be useful to load multiple DBC files in parallel. For example, in marine telematics you often have multiple DBC files, e.g. one for your GPS module, wind sensor and engine data. These can either be combined into one 'master DBC file' or you can rely on softwar that can load multiple DBC files (such as asammdf).
Yes - the DBC file format can also be used to store decoding rules for LIN bus data - see our LIN bus LDF vs DBC guide for details.
A2L files are commonly used in the context of the CAN Calibration Protocol (CCP) and Universal Measurement and Calibration Protocol (XCP) - see also our intro to CCP/XCP.
In simple terms, A2L files are used to 'configure' a master device (e.g. a PC tool or a CAN bus data logger) for communication with an Electronic Control Unit (ECU), typically in prototype vehicles. The A2L file contains information on how the master can communicate with an ECU, incl. what request frames to send to e.g. trigger data measurement or to calibrate parameters in the ECU.
The A2L file also provides decoding rules for interpreting recorded ECU signals - meaning that the master (e.g. a PC tool) can directly plot incoming response data. In this regard, an A2L file can be thought of as a similar concept to DBC files - but with a wider array of use cases. Some software tools also allow the export of decoding information from an A2L file into the DBC file format.
Need to log & DBC decode your CAN data?
Get your CANedge today!