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

• 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 noname 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 isused as default)

In practice, most raw CAN data log files contain 20-80 unique CAN IDs. As such, the first step is to map each CANID to the relevant conversion rules in the DBC. For regular 11-bit CAN IDs, this can simply bedone by mapping the decimal value of the CAN ID to the DBC CAN IDs. For extended 29-bit CANIDs, a mask (0x1FFFFFFF) needs to be applied to the 32-bitDBC ID to get the 29-bit CAN ID - which can then be mapped against the log file.

To easily convert between the IDs, see our J1939 PGN converter.

Regarding J1939 PGN conversion

Steps 1-3 take outset in a single CAN frame. In practice, you'll decode raw data from e.g. vehicles, machines orboats 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 byloading the data log files and related DBC file(s). To illustrate what the output may look like, we've added asnippet of DBC decoded J1939 data logged with a CANedge. The datahas been converted via asammdf, filtered to include a set ofrelevant signals and exported as CSV:

The DBC file can contain various extra information and below we outline the most common types. This informationis 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 moreinformation.

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 typicalattribute 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 orhandling 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 definitelydo this, it is not the most common convention. Further, the first character in a CAN DBC signal name cannot be anumber - 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. Thesetake 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 physicaldecimal value of each state of a signal. The states should be in descending order.

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 OBD2communication. Consider for example the below OBD2 response frames:

7E8 03 41 11 30 FF FF FF FF7E8 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, theinterpretation of the data differs between the two frames. This is because byte 2 serves as a multiplexer,specifying which OBD2PID 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 signalserves 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 mode01.

The above is referred to as simple multiplexing. But CAN DBC files also support extendedmultiplexing, where a multiplexed signal (in this case S1) can also be a multiplexor and thuscontrol the interpretation of other parts of the data payload. To see this, note that S1 takes the same role asService in the syntax, adding an M after m1 and being grouped withthe 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 amultiplexer switch value of 13 should be taken into account. In this example, it means that byte 4 reflects datafor vehicle speed. If byte 3 equals 17 (HEX 11), byte 4reflects 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 or our online DBC editor to more easilyview 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 loggersfor the purpose of decoding OBD2 frames in e.g. asammdf or our Python API modules. For more on thistopic, see Vector's guide toextended multiplexing in DBC files here.

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

To ensure your DBC looks OK, we recommend to open the DBC in a text editor. This way you can verify that thebasic DBC syntax looks as you'd expect - and you can use this version as a benchmark for comparison. It's a goodidea 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 decodersoftware tool. For example, if you're using a CANedge CAN bus datalogger to record raw CAN data from your application, you can use the free CAN decoder software, asammdf, to loadyour raw data and your DBC file. This way you can quicklyextract 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 ascomments/descriptions, value tables etc. We recommend to do regular checks as before to ensure the constructionis OK.

Check consistency: Finally, you can optionally do a full 'consistency check' via Vector'sCANDB++ tool. In CANDB++ select 'File/Consistency Check' and keep an eye out for critical errors (though notethat your DBC may be sufficiently valid for most tools, even if some issues are reported). Once you are done, wealways 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 simplest option is normally to log OBD2 data, which is supported in most cars after 2008. If your car doesnot support OBD2 (or you need non-OBD2 signals), you can check if open source DBC files exist for your specificcar.

In some cars, you can neither record OBD2 or raw CAN data via the OBD2 connector (due to gateways). If youbelieve you have found online CAN DBC files for your car, but you are not getting any CAN data via the OBD2connector due to a gateway, you can try using a CANCrocodile adapter to log CAN data directly from the CANwiring harness.

An alternative may be proprietary UDS requests via the OBD2 connector, assuming you can find details on these foryour 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 andhighly time consuming.

Note that some of the databases above contain information for decoding proprietaryUDS data. The proprietary UDS databases are typically not structured in DBC form, though you can takeoutset in our to get started on creating your own UDS DBC file. See also our UnifiedDiagnostic Services tutorial.

Most CAN networks are proprietary in the sense that only the Original Equipment Manufacturer (OEM) has the DBCfile required to decode the data. This is the case e.g. for raw CAN data in most cars, bikes, EVs, productionmachinery etc. As such, if you are not the OEM, you will need to reverse engineer the decoding rules (orresearch to see if others have done this already). Reverseengineering 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 thatyou can typically use the standardized J1939DBC 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 theencoding follows the standard, so often there will still be a share of proprietary CAN IDs in each vehicle.

NMEA 2000: For NMEA2000 use cases, you can use our NMEA 2000 DBC to decodemost 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 OBD2PIDdata recorded with the CANedge.

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 byordering it online (or by requesting a quotation via mail). The J1939 DBC is based on the J1939 DigitalAnnex 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 CANedgeCAN 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 therelevant parameters for your use case across heavy-duty vehicle brands. In case you need to extend the J1939 DBCwith proprietary J1939 PGN or SPNs (e.g. from reverse engineering or from the OEM), you can do so via one of theDBC 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 commonformat for storing CAN bus conversion rules. It should be noted, though, that the DBC standard is proprietary inthe sense that no official DBC file format documentation is available. As such, most online DBC syntaxdocumentation 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 useof CAN database files entirely and instead 'hardcode' the necessary decodinginformation 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 packedin the dataframe. The J1939 DBC that we offer is based on the J1939 Digital Annex and provides information thatgoes across most heavy duty vehicle brands. Of course, not every truck or excavator will include the same dataand 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 thatparticular CAN message ID.

To handle this, the J1939 standard specifies that bytes padded with "FF" should be considered invalid or notavailable. Some DBC decoding tools will still decode these parts of the data frame, which can result inodd-looking charts where the invalid signals take on constant values equal to their theoretical maximum. Othertools, like asammdf and our Python API modules, enable the user toignore 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 havemultiple DBC files, e.g. one for your GPS module, wind sensor and engine data. These can either be combined intoone '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 LDFvs DBC guide for details.

A2L files are commonly used in the context of the CAN Calibration Protocol (CCP) and Universal Measurement andCalibration 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) forcommunication with an Electronic Control Unit (ECU), typically in prototype vehicles. The A2L file containsinformation on how the master can communicate with an ECU, incl. what request frames to send to e.g. triggerdata 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. aPC tool) can directly plot incoming response data. In this regard, an A2L file can be thought of as a similarconcept to DBC files - but with a wider array of use cases. Some software tools also allow the export ofdecoding information from an A2L file into the DBC file format.

Buy nowContact us