Dbc File Format Documentationl

The files with .dbc extension are also known as CAN database files. The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form. The DBC file is introduced, because this is the very common way to manage identification and translation of the data. The DBC file type was developed to provide the means of record keeping as described in a CAN network.

DBC files for different models of the same brand have a lot of overlap. Therefore, we wrote a preprocessor to create DBC files from a brand DBC file and a model specific DBC file. The source DBC files can be found in the generator folder. After changing one of the files run the generator.py script to regenerate the output files. These output files will be placed in the root of the opendbc repository and are suffixed by _generated.

This extension provides basic syntax highlighting, bracket completion, codesnippets, lexer/parser errors, and a preview window for the Vector DBC file format.This is created to work with version 2 of the Vector DBC file format.

Although DBC files are often programmatically generated, it can be useful tomore easily read the DBC file itself in a plaintext format.Syntax highlighting is handled locally through VSCode'sintegrated TextMates language parsing engine, using PCRE regularexpressions to match syntax.

This extension also provides a sidebar to preview messages in the current, openDBC file. While this doesn't allow editing, it takes information from variousparts of the DBC and makes it easily readable and searchable.

Below is a demo J1939 DBC filethat contains decoding rules for speed (km/h) and engine speed (rpm). You can copythis into a text file, rename it as e.g. j1939.dbc and use it to extractspeed/RPM from trucks, tractors or otherheavy-duty vehicles.

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.

In the example, we use little-endian (Intel), meaning that the 'bit start' in the DBC filereflects the position of least-significant bit (LSB). If you add a DBC signal in a DBC file viewer fromVector (CANDB++) or Kvaser, the LSB is also used as the bit start in the DBC editor.

To avoid this confusion, ourDBC file editor instead uses the DBC syntax within the editor for both little-endian andbig-endian signals - meaning that the bit start you enter in the editor equals the bit start you'll seein the DBC - even for big-endian.

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:

To help guide our users in creating their own DBC files, we have created a full-fledged online DBC fileeditor. In particular, the 'signal preview' and built-in signal decoding functionality makes it a powerfultool for learning about the DBC file syntax.

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 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.

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:

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.

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.

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.

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.

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 UDSDBC & API example 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.

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.

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. Similarly, the OBD2 decoding rulesare embedded in the CLX000 software CANvas, enabling easy decodingof standard OBD2 PIDs.

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 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.

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).

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 resp