DBC¶

This page teaches how a DBC turns CAN payload bits into named signal claims, and why database provenance matters before treating those claims as machine truth.

A Concrete Artifact¶

BO_ 291 ENGINE_STATUS: 8 Vector__XXX
 SG_ EngineState : 0|8@1+ (1,0) [0|3] "" Vector__XXX
 SG_ EngineSpeed : 8|16@1+ (0.125,0) [0|8031.875] "rpm" Vector__XXX
 SG_ HydraulicPressure : 24|16@1+ (0.5,0) [0|32767.5] "kPa" Vector__XXX
VAL_ 291 EngineState 0 "Off" 1 "Cranking" 2 "Running" 3 "Fault" ;

# matching synthetic CAN payload for decimal ID 291 / hex 0x123
0x123 00 40 1f 40 1f 00 00 00

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Inspection Trap¶

A DBC can make a synthetic CAN payload look precise and official. The names, units, scales, offsets, and state labels come from the database, not from the frame.

The safer claim is database-relative: this DBC would render these bytes as this signal value. That is weaker than saying the machine truly had that value or state.

Worked Decode¶

1. BO_ 291 ENGINE_STATUS: 8 defines a message with decimal CAN identifier 291, which is hex 0x123, and an eight-byte payload.
2. SG_ EngineSpeed : 8|16@1+ starts at bit 8, spans 16 bits, uses Intel/little-endian ordering, and treats the raw value as unsigned.
3. Payload byte indexes 1 and 2 are 40 1f, which produce raw 0x1F40 under this little-endian signal definition.
4. Raw 0x1F40 is decimal 8000; scale 0.125 and offset 0 produce 1000 rpm.
5. HydraulicPressure uses the next two bytes with scale 0.5, producing 4000 kPa from the same raw value.
6. Byte 0x00 makes EngineState = 0, and VAL_ 291 EngineState renders that as Off.
7. A displayed word like Running or Off comes from the database, not the CAN frame itself. If a different DBC assigned state 0 to Running, the same frame could display a confident but wrong state label.

What The Evidence Supports¶

Given the synthetic DBC fragment and the matching synthetic CAN payload, the database defines decimal identifier 291 / hex 0x123 as an eight-byte message with named signals. Under the stated little-endian unsigned signal definitions, the payload bytes decode as:

• EngineState = 0, rendered by the value table as Off.
• EngineSpeed raw value 0x1F40, scaled to 1000 rpm.
• HydraulicPressure raw value 0x1F40, scaled to 4000 kPa.

The supported observer claim is database-relative: this toy DBC would render this toy payload as those signal values.

DBC files are semantic claims when provenance is trusted. With that provenance, a passive observer can make source-grounded claims; without it, the result is only a plausible rendering.

What The Evidence Does Not Support¶

The artifact does not prove that a real engine was off, that a real speed was 1000 rpm, that a real pressure was 4000 kPa, or that identifier 0x123 belongs to any real system.

The DBC snippet does not prove capture freshness, sender identity, bus cadence, database correctness, OEM provenance, or universal DBC grammar. A stale, wrong, or project-specific database could produce confident labels and units for the wrong payload. The provenance of the database itself determines whether the decode can be treated as source-grounded evidence.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

A DBC supplies semantic authority for interpreting payload bits. It does not supply traffic, freshness, cadence, sender behavior, or machine state by itself. Timing evidence must come from the capture or trace that contains the frame.

Semantic confidence comes from database provenance: for example, an OEM/supplier release, a validated internal database, a documented reverse-engineering result, or, in this page, a synthetic teaching artifact.

Failure And Ambiguity¶

• Using the wrong DBC can produce plausible false values with correct-looking units.
• Endian and start-bit conventions are a common source of wrong but stable decodes.
• Multiplexed messages can decode the wrong signal set if the mode field is ignored.
• Value tables can hide numeric uncertainty behind confident labels.
• DBC files may encode project assumptions, not universal truth; always record which database produced the decode.

Python Model¶

The current package exposes a concrete minimal DBC decode example:

"""Runnable DBC decode example for the schoolbus binder."""

from schoolbus.formats.dbc import DbcDatabase
from schoolbus.protocols.examples import DBC_TEACHING_TEXT

database = DbcDatabase.from_text(DBC_TEACHING_TEXT)
signals = database.decode(0x123, bytes.fromhex("00 40 1f 40 1f 00 00 00"))

print(database.show_fields())
for decoded_signal in signals.values():
    print(decoded_signal.explain())

The model supports the documented BO_, SG_, and VAL_ teaching subset for little-endian unsigned signals and standard 11-bit CAN identifiers (0x000 through 0x7ff). It rejects extended-ID encoding rather than silently misreading a broader DBC grammar. Decoded values use the shared Signal primitive so provenance stays visible instead of hiding behind a bare engineering number.

The first workbook sample pack includes a passive synthetic DBC fixture under samples/first-workbook/ that decodes the matching CAN payload as EngineSpeed == 1000 rpm and EngineState == Off while preserving DBC provenance.

The DBC snippet and payload are synthetic. The page does not reproduce the full Vector grammar, proprietary database content, multiplexing variants, J1939DA exports, or every tool-specific attribute.

Source Notes¶

References¶

Public Sources¶

• Vector
• Vector CANdb++ product and DBC format context — de facto/proprietary format context.
• CSS Electronics
• DBC file explained — vendor tutorial and public explainer.
• Tooling references
• cantools — description-file parsing and signal inspection.
• canmatrix — CAN matrix conversion and inspection.

Project posture is aggregated in the protocol support policy, source policy, and project charter.