How do you analyze a CAN log with a DBC?
Match the log to the correct database and channel, decode the relevant frames into signals, isolate the issue window, and measure transitions and timing. Compare observations with a sourced expectation, then preserve the original source locations and missing evidence before choosing the next investigation step.
When to use this workflow
Use it when a customer reports an intermittent function, a timing mismatch or an inconsistent request/response sequence, and you have a recorded bus log. The goal is to answer a focused engineering question, such as “Was the request visible, and what response was observable in that window?”
Start with the symptom and operating conditions. Decoding every signal without a question can create more data than insight.
Inputs and terminology
- CAN — Controller Area Network
- The bus communication represented by recorded frames. A frame observation is a bus observation, not direct access to an internal software state.
- CAN log / ASC text log
- A recording of message identifiers, payloads, timestamps and channel information. ASC is an ASCII text log format; ASCII means American Standard Code for Information Interchange. Verify the specific dialect and timestamp mode supported by your parser.
- DBC — CAN signal database
- A file describing message and signal encoding, including bit positions, byte order, signedness, factors, offsets and value descriptions. It must match the project and software configuration.
- Function context
- A versioned specification or requirement that defines relevant conditions and expected behavior. An engineer’s statement is also a source, but should be labeled as human input.
- Signal timing and request/response
- Measurements between recorded events within a known time domain. A chosen observation window is an analysis assumption unless a requirement defines it.
Six investigation steps
- Verify input identity. Record the log, database version, channel and applicable specification. Check capture coverage, timestamp mode and gaps. A mismatched database can produce plausible but incorrect values.
- Find candidate signals. Map the issue to a function and likely messages. Use database definitions and requirement references, then retain the selected scope. Treat name-based guesses as candidates, not confirmed ownership or topology.
- Decode and sanity-check. Check identifiers, payload lengths, bit layout, signedness and byte order. Apply the database conversion, commonly
physical = raw × factor + offset. Verify multiplexed signal interpretation where applicable; an inactive branch is not a zero value. - Extract the relevant window. Keep enough surrounding context to see entry conditions and responses. Record state changes, intervals and durations from the source samples. Do not turn a gap or an absent sample into an observed off-state.
- Separate observed and expected. List what the log shows. In a separate record, cite the expectation and its conditions. Assess only what those observations and the supported rule semantics allow. Without an expectation source, keep abnormality unassessed.
- Preserve evidence and move the boundary. Keep a stable evidence reference, project-relative artifact, source line or frame, time domain, measured interval and limitations. Ask for the smallest additional observation that could distinguish the candidate explanations.
The DBC conversion and encoding checks above are described in the CSS Electronics DBC format guide.
What the manual workflow often misses
- Capture coverage: “No response observed” is meaningful only for the monitored channel, signal, time window and available samples.
- Unsynchronized clocks: files from different recordings can use different time bases. Do not subtract their timestamps without established synchronization.
- Condition completeness: visible bus inputs may satisfy part of a requirement while an internal condition remains unavailable.
- Alternatives in the specification: an “or” trigger is not a set of “and” conditions. Preserve branches that your evaluator cannot assess.
- Signal symmetry: names such as Left and Right do not establish a peer relationship. Confirm group membership and bindings explicitly.
What the evidence can prove
A traceable log observation can establish that a decoded value, transition or interval appears in the recorded data under the selected database and time domain. A sourced requirement can establish what behavior is specified. Together they can support a bounded assessment or a candidate investigation direction.
What it cannot prove
A bus log alone cannot establish which internal software branch ran, what an electronic control unit (ECU) sampled internally, or whether a physical actuator behaved correctly. Temporal proximity does not prove internal causality. A missing recorded response does not, by itself, prove an ECU failure.
Keep facts, inferences, unknowns and next investigation steps separate. A narrower, well-supported question is often more useful than an unsupported final root cause.
How EmbedVera approaches it
The current EmbedVera engine combines tested ASC logs, DBC databases, DOCX function specifications and explicit engineer context. Deterministic processing extracts observations and measurements locally; selected context supports AI-assisted retrieval and investigation.
It preserves evidence references, expectation sources, confidence, unknowns and next steps. It does not offer online CAN analysis on this website or currently analyze source code, Simulink or Stateflow. Learn what to look for in a CAN log analyzer or request early access.
Questions, answered
Frequently asked questions
Can I analyze a CAN log without a DBC?
You can inspect frame identifiers, payload bytes, recorded timing and message presence. A matching DBC is needed to decode named signals and their defined conversions reliably. Do not infer a proprietary signal meaning from bytes alone.
Does a DBC define the expected function behavior?
Usually it defines how messages and signals are encoded, not the complete functional requirement. Use a versioned specification, requirement or verified expert context to assess expected behavior. Without that source, abnormality is not assessed.
Does a request followed by a response prove causality?
No. Their timing can support a candidate relationship inside an observed time domain. It does not prove that the software sampled the request, took a particular branch or caused the physical outcome.
Can I merge timestamps from different CAN logs?
Only correlate across logs or channels when synchronization is explicitly established. Similar-looking timestamps do not establish a shared clock. Keep unsynchronized observations separate.