DBC Files & Signal Decoding

Why decoding is a separate step

Nothing about a raw CAN frame tells you what it means. 0x3E1 02 5A 00 00 3C 00 00 00 is unambiguous at the wire level — an ID and eight bytes — but meaningless without a definition of which bits carry which signal, how to scale a raw integer into a physical unit, and what the valid range is. A DBC file (from Vector's original ".dbc" CANdb format, now a de facto industry standard even outside Vector's own tools) is that definition, in plain text.

Anatomy of a DBC file

A DBC file is a list of message definitions, each containing one or more signal definitions:

BO_ 993 EngineData: 8 ECU
 SG_ Engine_RPM : 16|16@1+ (0.25,0) [0|16383.75] "rpm" Vector__XXX
 SG_ Throttle_Pos : 32|8@1+ (0.392157,0) [0|100] "%" Vector__XXX
 SG_ Coolant_Temp : 40|8@1+ (1,-40) [-40|215] "degC" Vector__XXX

Reading a signal definition

Take SG_ Engine_RPM : 16|16@1+ (0.25,0) [0|16383.75] "rpm" apart piece by piece:

So a raw 16-bit value of 9520 at that bit position decodes to 9520 × 0.25 = 2380 rpm — exactly the value used as the worked example in CAN Bus Fundamentals.

Byte order is the most common mistake

Little-endian (Intel, @1) and big-endian (Motorola, @0) signals lay their bytes out in the opposite order, and the start-bit numbering convention is different between the two as well. Getting this wrong doesn't usually produce an obvious error — it produces a plausible-looking but wrong value, which is far more dangerous than a decode that visibly fails. When reverse-engineering an unknown signal, always sanity-check against a known reference (log the vehicle at idle and confirm RPM reads ~700-900, not a scaled or byte-swapped version of it).

Where DBC files come from

• Provided by the OEM/supplier — the ideal case, and common on a development or fleet vehicle where you have a support relationship.
• Published/community sources — partial DBC files exist publicly for some popular platforms, useful as a starting point but not authoritative.
• Reverse-engineered from a log — capture traffic while triggering a known, observable change (press the brake, rev the engine, turn the wheel) and look for the byte(s) that change in a corresponding way. This is slow, methodical work, and it's exactly what an AI-assisted signal search (like ONAC Network Studio's reverse-engineering tooling) is built to speed up.

Where this fits into the ONAC platform

ONAC Network Studio loads a DBC file and applies it to live or recorded traffic in real time, turning the raw frame view into the named-signal table shown in CAN Bus Fundamentals. Building and validating DBC files — including the reverse-engineering work when one doesn't exist yet — is also part of our vehicle network systems consultancy work directly.