What does a CAN log analyzer do?
A CAN log analyzer helps engineers inspect recorded Controller Area Network communication. With a matching DBC signal database, it can turn frame payloads into named signals, expose transitions and timing, and help investigate a customer issue. Functional judgment also needs a source for expected behavior.
When to use one
Use an analyzer when you need to understand what was visible on the bus during a reported symptom: whether a request appeared, which conditions changed, how long a state lasted, or whether a selected response was observable.
For customer issue investigation, decoding is a starting point. The valuable outcome is a traceable explanation of the observations, the missing evidence and the next useful boundary to investigate.
Typical inputs
| Input | What it contributes | What to verify |
|---|---|---|
| Customer issue | Symptom and investigation question | Operating conditions and source of human context |
| Recorded CAN log | Frames, payloads, times and channels | Parser compatibility, gaps and time domain |
| DBC database | Message-to-signal decoding definitions | Project version, channel and encoding |
| Function specification | Relevant expected behavior | Version, source location and condition semantics |
Log support differs by tool. ASC text logs are one recording format; binary formats need their own readers. Do not assume support for a format, diagnostic protocol or transport layer unless it is explicitly available and verified.
A DBC file describes signal encoding. It does not, by itself, define the complete function. A requirement, specification or verified expert input supplies that expectation.
A common investigation workflow
- Write the customer symptom as a question that the available evidence could answer.
- Confirm the database, log format, channel and time domain.
- Identify the relevant function, signals and capture window.
- Decode and measure transitions, durations and request/response observations.
- Compare supported observations with sourced expectations.
- Record the evidence, limitations and next observation needed.
See the step-by-step CAN log and DBC guide for the practical checks.
What to look for when choosing a tool
- Input fit: test the exact recordings and database variants you use. Check timestamp and channel handling, not only file extensions.
- Traceability: ask whether a reported interval or state can be located again in the original source.
- Functional context: check whether observed behavior stays separate from requirements and unsupported conditions remain unknown.
- Data boundaries: understand where raw files are processed, what leaves the machine and whether an online model is optional.
- Investigation value: assess whether the output narrows the question and supports a concrete next step.
- Performance: verify behavior on your log sizes and candidate-signal scope. No universal benchmark follows from a small demonstration.
What the evidence can and cannot prove
Recorded bus data can support observations about the captured values and their timing. A valid expectation source can support a bounded comparison. Reports should retain the database identity, observation window, source references, confidence and limitations.
It cannot automatically establish internal execution, physical outcomes or a final software root cause. A missing response is a statement about a selected capture and observation window. Timing correlation is a candidate relationship, not proof of internal causality.
What the current EmbedVera Beta does
EmbedVera is an AI (Artificial Intelligence) CAN Debugger focused on customer issue investigation. Its current v0.2.1 engine accepts tested ASC text logs, DBC databases, DOCX text specifications and explicit engineer input. It combines local deterministic measurements, specification retrieval, supported condition assessment and a bounded investigation loop.
Peer comparisons require confirmed project topology and signal bindings. Live AI uses an explicitly configured provider with selected relevant context. Large raw logs stay local; model output is not engineering evidence.
The current evaluator supports one main entry branch. Complex alternatives or unavailable internal states may remain unassessed. Source-code, Simulink and Stateflow analysis and additional log readers are not currently offered.
Early access is by request. Join the Beta conversation or read the security boundaries before deciding whether the workflow fits your project.
Questions, answered
Frequently asked questions
Is a CAN log analyzer the same as a CAN simulator?
No. Log analysis examines recorded communication. Simulation generates or models communication and often needs additional hardware or execution environments. Choose based on the investigation task, not an assumption that every tool provides both.
Do all analyzers support every CAN log format?
No. Verify the exact file format, timestamp mode, channel mapping, signal decoding and any protocol-specific needs with your own data. A list of formats is not a guarantee that all variants are supported.
What makes an AI-assisted analyzer useful?
It should connect the issue to relevant engineering sources, preserve measured observations, explain uncertainty and suggest a testable next step. Model text should not be treated as evidence or replace numeric measurement and source validation.
Can I upload a log to this website?
No. This website explains EmbedVera and accepts email-based early access requests. The current engine is local-first; no browser upload or online CAN analysis is offered here.