Bus traffic analysis from recordings
Work through timestamped communication to correlate missing messages, error activity, timing, and changes in traffic across a recording rather than a single moment.
Vehicle Networks & Communication
In-vehicle network engineering and analysis
Network problems tend to look like a missing message and turn out to be something else: a definition that no longer matches the bus, a gateway that drops a frame, a timing relationship that only breaks under load. The work here is establishing what the bus is actually carrying, and then integrating, simulating, or fixing against that evidence.
Discuss a Network ProjectProblems I can investigate
Find the behavior behind the symptom
- 01
An expected message is missing from the bus
A frame that should be present is absent, intermittent, or arriving under conditions nobody expected. Recordings are compared against the expected communication rather than against assumption.
- 02
A decoded signal carries the wrong value
Plausible but incorrect values usually point at scaling, byte order, offset, multiplexing, or a definition that does not match the sending node. Each is checkable against raw frame content.
- 03
The bus reports errors
Error frames, error counters, and bus-off events are read where the interface or ECU makes them available. A traffic recording alone does not always contain controller-level diagnostics, and that limitation is stated rather than papered over.
- 04
Communication fails intermittently
Behavior that appears only sometimes needs evidence across time rather than a single capture. Recordings are examined for the conditions under which the behavior appears and disappears.
- 05
The database no longer matches the bus
A DBC that has drifted from the network produces silent decoding errors. Observed traffic is reconciled with the definitions, and unresolved payload semantics are documented as unresolved.
- 06
A gateway changes or drops communication
Messages are traced across networks to establish whether they are forwarded, modified, delayed, or routed somewhere other than expected.
What I can help with
Focused engineering work in Vehicle Networks & Communication
Signal decoding and database work
Decode frames against CAN database definitions, reconcile mismatches between a definition and observed traffic, and produce or correct DBC content where the evidence supports it.
CAN and CAN-FD integration
Bring a node, tool, or application onto the bus: bit timing and data-phase configuration, addressing, cycle behavior, and the interaction with existing network participants.
Restbus simulation and network stubbing
Simulate the network participants that are missing from a bench setup so a component can be exercised without the complete vehicle environment.
Gateway and routing investigation
Follow individual messages between networks and document evidence of omission, modification, or unexpected routing, including the timing effects that routing introduces.
Automotive Ethernet and IP-based communication
Analyze packet captures and service-oriented communication where the vehicle network extends beyond CAN, including the transports diagnostics runs over.
Scripted and repeatable network analysis
Turn a one-off investigation into a repeatable Python workflow when the same question has to be asked of many recordings.
Specific services
Services in Vehicle Networks & Communication
Automotive Ethernet Analysis Service
Analyze Automotive Ethernet PCAP files for communication sequences, discovery failures, and timing issues with findings tied to capture evidence.
Automotive Ethernet Integration
Integrate Automotive Ethernet endpoints and software interfaces with scoped configuration changes, communication checks, and packet evidence.
Automotive Ethernet Testing
Automotive Ethernet testing for DoIP, SOME/IP, UDS, and PCAP traffic, with focused analysis of connection failures and network timing issues.
CAN Integration
CAN integration support for gateway issues, missing messages, ISO-TP failures, and unknown signals using recordings, DBC data, and focused analysis.
CAN Log Analysis
Analyze CAN, CAN-FD, BLF, ASC, and DBC data to investigate communication issues, signal behavior, intermittent events, and vehicle-network problems.
CAN Restbus Simulation
Build CAN restbus simulations to reproduce missing network participants, investigate communication failures, and analyze vehicle-network behavior.
CAN Signal Decoding
Decode CAN signals with DBC definitions, check byte order and scaling, and receive engineering values with traceable interpretation notes.
CAN Testing
Test CAN message presence, timing, signal values, and gateway routing against requirements, with repeatable checks and recorded evidence.
CAN-FD Analysis Service
CAN-FD analysis for missing messages, bus errors, decoding issues, and gateway behavior using recordings, CAN dumps, and DBC data.
CAN-FD Integration
Integrate CAN FD communication with controller configuration checks, DBC alignment, gateway mappings, and verification of agreed network changes.
CAN-FD Testing
CAN-FD acceptance testing with defined scenarios, timing tolerances, captured evidence, and repeatable pass/fail results for engineering regression checks.
DBC Analysis Service
DBC analysis for decoding CAN traffic, investigating signal and message mismatches, and producing usable databases, findings, and repeatable converters.
DBC Conversion
Convert CAN database definitions with checks for identifiers, bit layout, scaling, and multiplexing. Document target-format limits and verify decoded values.
What to send
Start with the evidence you already have
Problem description
Observed symptoms, context, reproduction steps, and expected behavior.
BLF recording
A Vector binary log containing timestamped bus communication.
ASC recording
A text-based Vector bus recording.
CAN dump
Raw or text-exported CAN frames.
DBC
A CAN database defining messages and signals.
PCAP
A packet capture for Ethernet-based vehicle communication.
How the analysis works
From recorded data to engineering findings
- 01
Establish the expected communication
Confirm which messages should be present, from which nodes, at which rates, and under which conditions — before comparing anything against a recording.
- 02
Review the available evidence
Check what the recording or capture actually covers: its scope, its timestamps, and whether controller-level diagnostics such as error counters are present at all.
- 03
Decode and compare
Apply the available database definitions, decode messages and signals, and compare observed traffic with the expected behavior established at the start.
- 04
Trace across the network
Where more than one bus is involved, follow the relevant messages through gateways and document what changes on the way.
- 05
Integrate, simulate, or correct
Depending on the finding, this becomes a configuration change, a corrected database, an integration on the bus, or a simulation of the missing participants.
- 06
Document findings
Separate direct observation from engineering interpretation, and record what the available evidence could not settle.
What you receive
Deliverables matched to the investigation
Engineering analysis
A documented technical analysis with the evidence and findings behind it.
Root-cause report
A traced explanation of a network failure, with confirmed cause separated from hypothesis.
CAN decoding results
Decoded frames, signals, and interpretation notes.
DBC file
An agreed database update supported by supplied definitions or verified evidence; unresolved payload semantics stay documented as unresolved.
Restbus simulation
A simulation of missing network nodes and their communication.
CAN analysis tool
A focused tool for viewing, decoding, or checking bus traffic in your workflow.
Technologies & formats
Automotive data and analysis environments
- CAN
Controller Area Network
A priority-based broadcast bus used for in-vehicle control communication.
- CAN-FD
CAN Flexible Data-rate
An extension of CAN with larger payloads and a faster data phase.
- LIN
Local Interconnect Network
A low-cost scheduled serial bus for local vehicle subsystems.
- J1939
SAE J1939
A higher-layer vehicle network protocol suite using CAN, common in heavy vehicles.
- Automotive Ethernet
Automotive Ethernet
Automotive physical and data-link networking based on Ethernet.
- SOME/IP
Scalable service-Oriented MiddlewarE over IP
An automotive middleware protocol for service-oriented communication over IP.
- DoIP
Diagnostics over Internet Protocol
Diagnostic transport over IP networks as defined by ISO 13400.
- ISO-TP
ISO 15765-2 Transport Protocol
A segmented transport protocol for messages carried over CAN.
- DBC
CAN Database
A text format describing CAN messages, signals, nodes, scaling, and metadata.
- BLF
Binary Logging Format
A Vector binary container for timestamped bus communication.
- ASC
ASCII Log Format
A human-readable Vector format for timestamped bus events.
- PCAP
Packet Capture
A captured sequence of network packets with timestamps and headers.
- CANoe
Vector CANoe
A development, simulation, test, and analysis environment for vehicle networks.
- CANalyzer
Vector CANalyzer
A Vector environment for recording and analyzing vehicle-network communication.
- CAPL
Communication Access Programming Language
Vector event-driven language for network simulation, testing, and automation.
- Wireshark
Wireshark
A packet analyzer for capturing, decoding, and inspecting network traffic.
- SocketCAN
SocketCAN
The Linux kernel networking interface and tools for CAN communication.
- python-can
python-can
A Python library providing a common API for CAN interfaces and messages.
- cantools
cantools
A Python package for parsing CAN databases and encoding or decoding messages.
FAQ
Practical questions before an investigation
- Can you work without a DBC?
- Yes. Frame-level analysis is possible from a recording or CAN dump alone — arbitration IDs, payload bytes, timing, and error activity are all visible without a database. Signal-level interpretation is more limited, and any payload semantics inferred without definitions are reported as inference rather than fact.
- What is the most useful thing to send first?
- A recording that contains the behavior in question, together with a description of what should have happened instead. If a DBC exists, include it. If the behavior is intermittent, a longer recording covering both good and bad periods is far more useful than a short capture of the failure alone.
- Do you cover networks other than CAN?
- Yes — LIN, J1939, and Automotive Ethernet including SOME/IP and DoIP. CAN and CAN-FD are the most common in practice, and the analysis approach is the same: establish expected communication, compare it against captured evidence, and trace what differs.
- Can bus errors be diagnosed from a recording alone?
- Partly. Error frames and their timing are usually visible, but controller error counters and bus-off status depend on what the recording interface captured. Where that data is absent, the analysis says so rather than treating the absence of recorded errors as evidence that none occurred.
- Is restbus simulation possible without the full vehicle?
- That is precisely what it is for. Given the database and the expected behavior of the missing nodes, the surrounding network communication can be simulated so a single component can be exercised on a bench. The fidelity depends on how completely the missing nodes' behavior is specified.
Discuss the evidence
Discuss a Vehicle Network Project
Send a recording, a DBC, or a description of the communication behavior you need investigated, integrated, or simulated.