CAN DBC File Explained - A Simple Intro [+Editor Playground]

• A message starts with BO_ and the ID must be unique and in decimal (not hexadecimal)
• The DBC ID 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)

A standardized DBC file like our J1939 DBC will typically allow you to DBC decode 60-80% of the CAN bus messages that you record from a J1939 network in a given truck, excavator, tractor or other heavy-duty machine. The rest of the messages are proprietary. The explanation is that most heavy-duty OEMs agree to encode most standard parameters like speed, RPM, temperatures etc. according to the J1939 specification - but they are not forced to do so. For example, an OEM may decide that the J1939 standard does not provide adequate encoding for a specific subset of their data - and instead opt for a proprietary encoding. Others may simply prefer to only use the J1939 encoding for a very limited subset of their data - if any at all. A similar logic applies to the NMEA 2000 and ISOBUS data.

OBD2 differs to some extent as your car's electronic control units do not rely on OBD2 to function. Rather, each car OEM implements their own proprietary CAN protocol for this purpose. You can use a CAN bus data logger to request OBD2 data from the car and the car will then respond if it supports the requested data. It is somewhat up to the OEM to what extent they support OBD2 data in their car, meaning that a specific car will typically only support a subset of the potentially available OBD2 parameters.

Because of the above, you should generally test what data is available from a specific application early on. If you have one of our CAN bus data loggers, you can record data from your application and send it to us for free sample DBC decoding, allowing you to identify what data is available before you decide whether to get a specific DBC file.

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 files to get started on creating your own UDS DBC file. See also our Unified Diagnostic Services tutorial.

Getting started: If you need to construct a new DBC file, we recommend using one of the DBC editors above. For most users (incl. beginners), we recommend our own online DBC editor. When creating a new DBC file, you can take outset in the default template - or clear this to create your own DBC file from scratch.

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, you can optionally do a full 'consistency check' via Vector's CANDB++ tool. 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). 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.

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.

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 as in below example:

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 are advanced topics and not supported by all DBC editors or data processing tools. However, you can use e.g. the CANDB++ DBC editor or our online DBC editor to more easily view and understand DBC files with multiplexing, like our OBD2 and UDS DBC files. Further, all CANedge software/API tools support extended multiplexing in terms of DBC decoding data. For more on this topic, see Vector's guide to extended multiplexing in DBC files here.

Some higher-layer CAN bus protocols include transport protocols, e.g. below:

• J1939 TP (J1939, ISOBUS, NMEA 2000)
• ISO TP (UDS, OBD2)
• NMEA 2000 Fast Packets

You can learn more about how these transport protocols work in our intros above.

Importantly, not all CAN software/API tools support transport protocol aka multi-frame data. As an exampe, the transport protocols are supported via the CANedge MF4 decoders (and thus indirectly for e.g. dashboard visualization and Python/MATLAB analysis) - but not the asammdf GUI.

In addition to the more limited software/API support, the DBC file format is not optimally designed for transport protocol handling - and as a result, the implementation may vary by software. Of course, if you use our J1939 DBC, ISOBUS DBC, NMEA 2000 DBC, OBD2 DBC or UDS DBC, these will already be set up for use with the CANedge MF4 decoder TP handling.

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.

In some cases (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 software that can load multiple DBC files (such as asammdf or our MF4 decoders).