DBC files and CAN signals

Concrete technical facts

• A DBC describes CAN frames/signals with CAN ID, start bit, bit length, byte order, signedness, factor, offset, limits and unit.
• Physical value is commonly calculated as physical = raw × factor + offset.
• Intel/little-endian and Motorola/big-endian layouts can decode the same byte sequence differently.
• Multiplexed signals allow one CAN identifier to carry different signal groups selected by a multiplexer value.
• A DBC does not generate CAN traffic; it defines semantics for traffic that exists on the bus.
• A mismatched DBC version can decode the right CAN ID with the wrong scaling or bit position.

Worked example

• Example: for a 16-bit raw speed value of 1000 with factor 0.1 and offset 0, physical speed is 100.0 km/h.

Data-structure example

SG_ VehicleSpeed : 0|16@1+ (0.1,0) [0|250] "km/h"

Measurement and verification sequence

• Capture the raw CAN frame with timestamp first.
• Verify CAN ID, DLC and bytes independently of the DBC.
• Check start bit, length, endianness, factor and offset individually.
• Compare the decoded value with an independent source such as scan data or physical measurement.

Fault-separation logic

• Is a valid command present and are power/ground/network healthy?
• Does feedback follow the command?
• Does an independent physical measurement confirm the output?
• Is the fault limited to a specific temperature/load/speed condition?
• Does the result remain stable when the original condition is repeated after repair?