In the field of automotive engineering, there are various file formats that play a crucial role in the development and testing of vehicle systems. One such file format that is widely used in the automotive industry is the DBC file format. In this article, we will embark on a journey to explore the inner workings of DBC files, from understanding the need for this format to delving into the details of messages, signals, and data representation with practical information.
Need for a common file format
As is well known, there are anywhere between tens to few hundreds of ECUs (Electronic Control Units) in a vehicle. Each of these ECUs plays a particular role and are connected over the CAN (Controller Area Network) bus. Many of their operations are dependent on one another. For example, a Vehicle Control Unit (VCU) in an electric vehicle will continuously monitor the performance of Motor Control Unit (MCU) and Battery Management System (BMS) to deliver an optimal performance.
Another good example is the Instrument cluster collecting information from various ECUs and showing them to the user via the display interface. All these ECUs come from different vendors and having to manually define the messages and signals exchanged between ECUs was a time-consuming and error-prone process. This called for specification of a common format that describes the CAN frames transmitted by each of these.
The DBC file format, which stands for 'database container' was developed by Vector Informatik GmbH in the 1990s to simplify the communication between ECUs in vehicles. With the increasing complexity of vehicle systems and the need for standardized communication protocols, the DBC file format emerged as a solution. It provides a structured and standardized way to define messages, signals, and their attributes, making it easier for engineers to develop and test automotive systems.
Messages in DBC file
Messages are the building blocks of communication in a DBC file. They represent the information exchanged between ECUs in a vehicle system. Essentially each message corresponds to a CAN frame transmitted by an ECU and an ECU can originate more than one messages.
Each message has a unique identifier and is associated with one or more signals. Messages can be classified into different categories based on their attributes, such as the message type, cycle time, and start delay time.
The message is encoded in the following format:
BO_ CAN ID Message Name: Data Length Transmitter Name
An example message format is given below:
DBC Message Format
The message syntax is indicated by the BO_ keyword.
It is followed by the decimal representation of the CAN ID associated with the message.
Then the name of the message is mentioned.
After a colon, the length of the message in bytes follows.
Finally, the message contains the name of the transmitting ECU optionally. If it is not mentioned, Vector__XXX string is used.
Signals in DBC file
Signals carry the actual data within messages in a DBC file. They represent the physical quantities, such as temperature, speed, or pressure, that are transmitted between ECUs. Each signal has a unique name, bit start position, bit size, and data type. Signals can be either signed or unsigned, and they can have different scaling, offset, limits, and units.
Format of a signal is given below:
SG_[M|m MultiplexerIdentifier ] : BitStart| NumBits @ Endianness Signed (ScalingFactor,Offset) [Min|Max] '[Unit]' [Receiver]
The details of these fields are covered in the next section.
The below snippet is an example of a message in a DBC file.
BO_ 123 SPEEDM: 8 Vector__XXX SG_ ODOValue : 7|16@0+ (1,0) [0|65534] 'm' InstrumentCluster SG_ ODoStatus : 17|2@0+ (1,0) [0|3] '' InstrumentCluster SG_ VehSpd : 39|12@0+ (0.05,0) [0|127.96875] 'm/s' InstrumentCluster SG_ VehSpdStatus : 43|2@0+ (1,0) [0|3] '' InstrumentCluster
Here the line that starts with BO_ indicates the message and the rest of the 4 lines starting with SG_ represents the signal inside the message. Let us have a deep dive into the structure in the upcoming sections.
Data representation in DBC file
Understanding the details of signals is crucial for interpreting the data in a DBC file. In a digital system, any data information is typically represented in binary format. While DBC file also does the same, it offers some features that will help pack more data in an 8-byte CAN packet.
The DBC file format supports various data types, such as integers, floating-point numbers, and enumerated types. Each signal in a DBC file is associated with a data type, which defines the range and precision of the signal values.
The signal information is captured in DBC file in the following format:
DBC Signal Format
The signal starts with a SG_ keyword followed by the signal name.
The bit start position indicates the starting bit of a signal within a message. It is important to correctly identify the bit start position to extract the relevant data from a message.
The bit size defines the number of bits used to represent the signal's value. It determines the range of values that a signal can have.
The endianness determines the byte order of the signal data. It can be either little endian (@1) or big endian(@0), usually depending on the architecture of the transmitter.
The signed(-)/unsigned (+0) attribute indicates whether the signal values can be negative or not. A signed signal can represent both positive and negative values, while an unsigned signal can only represent positive values.
Scaling and offset are used to convert the raw signal values into meaningful engineering units. Scaling factors are multiplied to the incoming raw value followed by an addition with offset value to obtain the actual physical quantities.
Limits define the valid range of signal values. They ensure that the signal values fall within a specified range, preventing erroneous or out-of-range data.
Units provide a common understanding of the physical quantities being transmitted. They specify the engineering units in which the signal values are represented.
Finally, the name of the intended receiver is given optionally.
Data in the Bus
This section shows the screen shot of CAN data bus for the same data in different endianness.
BO_ 123 SPEEDM: 8 Vector__XXX SG_ ODOValue : 7|16@0+ (1,0) [0|65535] 'm' InstrumentCluster SG_ Test1 : 23|16@0+ (1,0) [0|65535] 'm' InstrumentCluster SG_ Test2 : 39|16@0+ (1,0) [0|65535] 'm' InstrumentCluster SG_ Test3 : 55|16@0+ (1,0) [0|65535] 'm' InstrumentCluster BO_ 124 SPEEDM1: 8 Vector__XXX SG_ ODOValue : 0|16@1+ (1,0) [0|65535] 'm' InstrumentCluster SG_ Test1 : 16|16@1+ (1,0) [0|65535] 'm' InstrumentCluster SG_ Test2 : 32|16@1+ (1,0) [0|65535] 'm' InstrumentCluster SG_ Test3 : 48|16@1+ (1,0) [0|65535] 'm' InstrumentCluster
When the first signal SpeedM is transmitted in Big endian format, the BusMaster representation along with the actual data on the bus is given below. Other signals are sent as alternating 0 and 1 pattern to avoid confusion due to CAN bit-stuffing.
Bid Endian Signal
When the same signal is sent in little endian format, the corresponding BusMaster representation and data on the bus is given below.
Little Endian Signal
These screen shots give a good idea how the endianness of the signal is handled.
Conclusion
This article covered most of the basic concepts of an DBC file and explained how the DBC files provide a structured and standardized way to define messages, signals, and their attributes, enabling efficient communication between ECUs. Understanding the inner workings of DBC files, from messages and signals to data representation and bit start, is essential for automotive engineers working with these files. We will explore some of the advanced concepts such as keywords, attributes and multiplexors in the next article.
