Messages
Messages define the CAN frames that a DBC recognizes and provide the structure in which signals are carried. A missing or incorrectly defined message can prevent expected traffic from being decoded.
Vehicle Networks & Communication
DBC Development Guide
A practical guide to creating, reviewing, and validating CAN databases so that observed CAN traffic can be decoded into dependable engineering values.
Engineering model
How DBC fits together
A DBC governs how CAN frames are interpreted as messages and signals, including message identity, payload layout, nodes, scaling, and metadata. Its usefulness depends on agreement with the actual CAN or CAN-FD traffic, the relevant software version, and the recordings or CAN dumps used for validation. A DBC is therefore both a data definition and an executable interpretation of bus traffic: when its layout or scaling is wrong, decoded results can appear valid while representing the wrong system state.
Core concepts
The parts of a practical DBC setup
Signals
Signals identify fields within a message and describe how their encoded values become engineering values. Signal definitions are the main control point for diagnosing unknown or incorrect CAN signal values.
Scaling
Scaling connects an encoded signal value to the engineering value presented to an analyst or software component. Incorrect scaling can produce plausible-looking but incorrect results even when the frame and signal layout are otherwise correct.
Nodes and metadata
Nodes and metadata add ownership and interpretation context to the CAN database. This information helps engineers review completeness and relate a message definition to the surrounding network model.
The engineering model of a DBC
Treat a DBC as a structured agreement between raw bus traffic and the engineering values extracted from it.
A CAN recording or CAN dump contains frames and payload data, while a DBC supplies the interpretation needed to identify messages and decode signals. The interpretation must agree with the observed message layout, signal encoding, scaling, nodes, and relevant software version. CAN-FD traffic requires the same discipline: the database definition still has to match the observed message and payload arrangement.
| DBC element | What it describes | Why it matters |
|---|---|---|
| Message | A named CAN message and its payload structure | Provides the container used to locate and decode signals |
| Signal | A defined field within a message | Connects encoded payload data to an engineering value |
| Scaling | The transformation from encoded value to engineering value | Determines whether decoded results have the intended magnitude and interpretation |
| Node | A communicating participant associated with the database | Adds network context for review and analysis |
| Metadata | Additional descriptive information stored with the database | Preserves interpretation context that is not contained in raw payload bytes |
Inputs and evidence for development
Build the database from explicit evidence, and keep the source of each definition identifiable during review.
The main inputs are an existing DBC, a BLF recording, an ASC recording, or a CAN dump. An existing DBC provides an initial interpretation; recordings and dumps provide observed traffic. When these sources disagree, preserve the disagreement as an engineering finding rather than silently changing the definition.
- Use the DBC to inventory known messages, signals, nodes, scaling, and metadata.
- Use a BLF recording or ASC recording to check whether expected messages occur and whether their payloads vary as expected.
- Use a CAN dump to inspect raw frames when a decoded value is implausible or a message is missing.
- Record the software version associated with the source definition when assessing a possible DBC mismatch.
- Separate observed facts from interpretations so later review can distinguish traffic evidence from database assumptions.
- 01
Inventory the available source data
List the DBC, BLF recording, ASC recording, or CAN dump available for the analysis and identify which source is authoritative for each observation.
- 02
Compare message presence
Check whether messages defined in the DBC appear in the recording or CAN dump, and whether observed messages are absent from the DBC.
- 03
Compare payload behavior
Inspect changing payload fields and compare them with the signals and scaling defined by the DBC.
- 04
Capture discrepancies
Document missing messages, unknown CAN signals, incorrect CAN signal values, and other evidence of a DBC mismatch.
Developing a DBC file
Create definitions in a controlled order so that message structure and signal interpretation can be checked independently.
- 01
Define the message inventory
Identify the CAN messages that must be represented and give each definition a stable message identity, payload structure, and relevant node context.
- 02
Add signal definitions
Place each known signal in its message and describe the encoded field, its interpretation, and its relationship to the engineering value.
- 03
Add scaling and metadata
Define the transformation needed for engineering values and preserve useful nodes and metadata instead of relying on undocumented assumptions.
- 04
Check the definition against traffic
Decode representative frames from a BLF recording, ASC recording, or CAN dump and compare the results with expected system behavior.
- 05
Review the resulting DBC file
Look for ambiguous names, incomplete definitions, inconsistent scaling, and differences between the database and the software version under analysis.
Development is not complete when the DBC file can be parsed. The useful acceptance criterion is that its message and signal definitions explain the relevant observed traffic without introducing implausible engineering values or hiding unknown fields.
Encoding and decoding workflow
Use repeatable decoding to distinguish a database problem from a traffic problem.
The decoding path is: source recording or CAN dump, message selection, signal extraction, scaling, and engineering interpretation. A DBC supplies the definitions for this path. cantools can parse CAN databases and encode or decode messages, making it useful for repeatable checks of a DBC file and for producing CAN decoding results.
| Workflow stage | Input | Review question |
|---|---|---|
| Source selection | BLF recording, ASC recording, or CAN dump | Does the source contain the message and payload under investigation? |
| Message selection | Observed CAN frame and DBC message definition | Does the observed frame correspond to the intended message definition? |
| Signal decoding | Message payload and DBC signal definition | Does the extracted field match the documented signal? |
| Scaling | Encoded signal value and DBC scaling | Is the resulting engineering value plausible for the observed system state? |
| Result review | CAN decoding results | Are discrepancies documented rather than treated as confirmed behavior? |
- Decode the same representative frames repeatedly when comparing DBC revisions.
- Check message presence before investigating a signal value; an absent message cannot produce a valid current decoding.
- Compare raw payload evidence with decoded values whenever the result differs from the system state.
- Use cantools as a repeatable parsing and encoding or decoding component, while keeping traffic validation as a separate engineering check.
Reviewing a DBC mismatch
A mismatch is a comparison problem: determine whether the traffic, the database, or the assumed software version differs from the expected model.
- 01
Confirm the source and version
Identify the DBC, recording or CAN dump, and software version being compared so that different definitions are not mixed unintentionally.
- 02
Check message presence
Determine whether the expected CAN message is absent from live traffic or the recording, or whether the message is present but not represented correctly in the DBC.
- 03
Check message layout
Compare the observed payload behavior with the message and signal layout described by the DBC.
- 04
Check scaling and interpretation
If the field changes as expected but the engineering value is wrong, review signal interpretation and scaling before concluding that the traffic is incorrect.
- 05
Document the finding
Produce engineering analysis that states the evidence, the competing explanations, and the validation still required.
- A CAN message missing from a recording may indicate traffic conditions, source selection, or a database expectation that does not apply to that software version.
- An unknown CAN signal should remain unknown until its encoding and meaning are supported by evidence.
- An incorrect CAN signal value may result from signal layout, scaling, message selection, or a mismatch between the DBC and the observed software version.
- A DBC mismatch can affect many decoded signals at once, so check the shared message definition before changing individual signal interpretations.
Validation and deliverables
The final artifact should be reproducible, reviewable, and clear about what has been observed versus inferred.
A completed DBC development workflow can produce a DBC file, CAN decoding results, engineering analysis, or a data converter. These deliverables serve different purposes: the DBC file defines interpretation, decoding results show what the definition produced, engineering analysis explains discrepancies, and a data converter makes a transformation repeatable.
| Deliverable | Primary purpose | Minimum useful content |
|---|---|---|
| DBC file | Define messages, signals, scaling, nodes, and metadata | A reviewed definition that corresponds to the intended CAN traffic |
| CAN decoding results | Show decoded frames and signals | Source reference, decoded values, and interpretation notes |
| Engineering analysis | Explain evidence and findings | Observed traffic, DBC comparison, discrepancies, and remaining uncertainty |
| Data converter | Repeat a data transformation | Defined input, output, conversion behavior, and reviewable results |
- Keep the source DBC and the resulting DBC file distinguishable during review.
- Include interpretation notes with CAN decoding results when a signal remains uncertain.
- Tie engineering analysis to specific observed frames or records rather than only to expected values.
- Re-run representative decoding after changes to message definitions, signal definitions, or scaling.
- Treat conversion output as a new artifact that still requires comparison with the source data.
Engineering pitfalls
Common mistakes
Assuming a parseable DBC is a validated DBC
Parsing confirms that the database can be read, not that its messages, signals, layout, or scaling match observed CAN traffic. Validate against a BLF recording, ASC recording, or CAN dump.
Changing scaling to make a value look plausible
A plausible result does not prove the scaling is correct. Check the source frame, message selection, signal layout, and software version before changing the definition.
Treating an absent message as a signal-decoding failure
If the expected CAN message is missing from live traffic or a recording, inspect traffic conditions and source selection before investigating signal encoding.
Assigning meaning to an unknown CAN signal from one sample
A changing payload field is not sufficient evidence of its meaning. Keep the field identified as unknown until message behavior and engineering evidence support the interpretation.
Mixing DBC versions during comparison
A DBC mismatch can reflect different software versions rather than a defect in one file. Identify the source definition and version before comparing decoded results.
Validating only decoded values
Decoded values can hide an incorrect interpretation. Review raw CAN frames, message presence, payload layout, scaling, and the resulting CAN decoding results together.
FAQ
DBC questions
- What does a DBC file control?
- A DBC file describes CAN messages, signals, nodes, scaling, and metadata so that encoded payload data can be interpreted as engineering values.
- Why can a DBC decode successfully but still be wrong?
- Successful decoding only shows that the definition can be applied. The DBC may still disagree with the observed message layout, scaling, payload, or software version.
- How should I investigate an incorrect CAN signal value?
- Check the source frame, message selection, signal layout, scaling, and software version in that order. Compare the result with the raw CAN data and document uncertainty rather than assuming one cause.
- What should I do with an unknown CAN signal?
- Record the observed payload field and its behavior, but do not assign a meaning without supporting evidence from the DBC, traffic comparison, or engineering analysis.
- Can cantools replace validation of a DBC?
- No. cantools can parse CAN databases and encode or decode messages, but validation still requires comparison with observed CAN traffic and expected engineering behavior.
Engineering support
Discuss a DBC Project
Need a repeatable DBC review or CAN decoding workflow? I can help turn your recordings, CAN dumps, and database definitions into clear engineering analysis and maintainable tooling.