Diagnostic communication troubleshooting
Investigate why diagnostic communication fails or behaves inconsistently, working from captured traffic, tester logs, and the ECU's documented diagnostic behavior rather than from assumption.
Vehicle Diagnostics
Vehicle and ECU diagnostics engineering
Diagnostic problems are rarely solved by reading a single response code. This is the work of establishing how an ECU actually behaves on the diagnostic stack — request handling, transport, session state, security, and stored fault data — and then building or fixing whatever sits on top of it.
Discuss a Diagnostics ProjectProblems I can investigate
Find the behavior behind the symptom
- 01
An ECU does not respond to diagnostic requests
Silence on the diagnostic channel can originate at the physical connection, the transport layer, the addressing configuration, or the ECU's own state. Isolating which layer is involved comes before any conclusion about the ECU itself.
- 02
Requests are answered with a negative response
A negative response code narrows the search but does not explain it. The useful question is which precondition the ECU considers unmet — session, security state, timing, sequencing, or the request's own parameters.
- 03
A diagnostic session cannot be entered or held
Sessions fail to start, drop unexpectedly, or reset during a sequence. Tester-present timing, session transitions, and security-access handling are examined against the ECU's documented behavior.
- 04
A data identifier cannot be read or does not decode
A DID may be unsupported in the current session, restricted by security access, or returned in a layout that does not match the description data being used to interpret it.
- 05
A fault code returns after clearing
A DTC that reappears is reporting a condition that is still present or a detection path that is still being triggered. Status bits, freeze-frame data, and operating conditions are used to separate the two.
- 06
A DoIP connection cannot be established
Diagnostics over IP introduces vehicle announcement, routing activation, and network configuration as additional failure points ahead of any UDS service. Each is checked in sequence rather than assumed.
What I can help with
Focused engineering work in Vehicle Diagnostics
UDS service development and integration
Implement and integrate diagnostic services on the tester side or in application code: session handling, data identifiers, routine control, and the sequencing these services depend on.
Transport layer work: ISO-TP and DoIP
Configure and debug the transport beneath UDS — segmentation, flow control, addressing, timing parameters, and, for DoIP, routing activation and network setup.
Fault memory and DTC analysis
Interpret stored fault data, status bits, and freeze frames to establish what a fault entry actually records, and how detection and healing conditions relate to observed vehicle behavior.
ODX and PDX interpretation
Use diagnostic description data to trace how requests, responses, and parameters are defined, and to reconcile differences between a description package and the behavior an ECU actually shows.
Diagnostic tooling and test automation
Build diagnostic applications and automated diagnostic tests where repeated manual tester work is the bottleneck, including scripted sequences, result capture, and reporting.
Specific services
Services in Vehicle Diagnostics
Diagnostic Application Development
Build focused ECU diagnostic applications with Python or Qt, UDS communication, ODX data handling, and clear results for engineering teams.
Diagnostic Session Development
Implement UDS diagnostic session transitions, keep-alive behavior, response handling, and recovery from project-specific ECU requirements.
Diagnostic Session Testing
Test ECU diagnostic sessions and UDS response flows using defined inputs, repeatable automation, and focused engineering analysis.
DID Decoding Service
Decode UDS DID response bytes using ODX or PDX definitions, with checks for data layout, conversions, ECU variants, and interpretation limits.
DID Development
Develop UDS Data Identifier handling with aligned data definitions, access conditions, diagnostic application logic, and repeatable ECU checks.
DID Testing
DID testing for ECU diagnostics, covering UDS reads, negative responses, transport paths, automated checks, and engineering findings.
DoIP Integration
Integrate UDS diagnostics over DoIP with discovery, routing activation, connection recovery, and separate transport and diagnostic response handling.
DoIP Testing
DoIP testing for connection failures, UDS request issues, and ECU response problems using packet analysis and repeatable diagnostic tests.
DTC Decoding Service
Decode ECU DTC records and status information using diagnostic definitions, with raw evidence, operating context, and clear interpretation limits.
ISO-TP Integration
Integrate ISO-TP transport for UDS over CAN, with addressing, flow-control configuration, timeout handling, and repeatable communication checks.
ISO-TP Testing
Test ISO-TP communication over CAN, investigate diagnostic transport failures, and receive repeatable findings, applications, or automated tests.
ODX Analysis Service
Analyze ODX and PDX diagnostic definitions to resolve ECU variant selection, parameter interpretation, and data paths for diagnostic applications.
ODX Review
Review ODX and PDX diagnostic data for consistency, traceability, and practical use in ECU diagnostic applications.
UDS Diagnostic Development
UDS diagnostic development for ECU communication, ODX or PDX data use, CANoe automation, and evidence-based troubleshooting.
UDS Testing
Independent UDS testing for ECU diagnostics, negative responses, DTC behavior, transport issues, and repeatable CANoe-based test automation.
What to send
Start with the evidence you already have
Problem description
Observed symptoms, context, reproduction steps, and expected behavior.
ECU
Access to the ECU, a bench setup, or a vehicle in which the behavior appears.
Diagnostic trace
A recording or tester log of the diagnostic exchange, including negative responses.
ODX
Diagnostic description data for services, identifiers, and parameters.
PDX
A packaged diagnostic description container.
Requirements or specification
Diagnostic requirements, an ECU diagnostic specification, or the intended behavior.
How the analysis works
From recorded data to engineering findings
- 01
Establish what is actually observed
Separate the reported symptom from the evidence available for it. Confirm which requests were sent, what came back, and under which vehicle or bench conditions.
- 02
Locate the failing layer
Work down the stack — physical and network access, transport, session and security state, then the diagnostic service itself — so that later analysis is not aimed at the wrong layer.
- 03
Compare behavior against the specification
Use ODX, PDX, requirements, or an ECU diagnostic specification to establish what the ECU is supposed to do, and where observed behavior diverges from it.
- 04
Build or correct what is needed
Depending on the finding, this is a configuration fix, a corrected request sequence, an implemented diagnostic service, an automated test, or a diagnostic tool.
- 05
Validate against the real target
Check the result against the ECU, bench, or recordings available, and record which conditions were covered and which could not be reproduced.
- 06
Document findings and open questions
Distinguish direct observations from engineering interpretation, and state clearly what remains unresolved or untested.
What you receive
Deliverables matched to the investigation
Engineering analysis
A documented technical analysis of the diagnostic behavior, with the evidence it rests on.
Root-cause report
A traced explanation of a diagnostic failure, separating confirmed cause from remaining hypothesis.
Diagnostic application
A focused application for ECU communication, DTC handling, sessions, or live parameters.
Automated test suite
Repeatable diagnostic tests with defined verdicts, replacing manual tester sequences.
Engineering documentation
Written documentation of the diagnostic behavior, configuration, or implementation delivered.
Technologies & formats
Automotive data and analysis environments
- UDS
Unified Diagnostic Services
ISO 14229 diagnostic services for communicating with vehicle ECUs.
- OBD-II
On-Board Diagnostics II
A standardized vehicle interface for emissions diagnostics and generic data access.
- ISO-TP
ISO 15765-2 Transport Protocol
A segmented transport protocol for messages carried over CAN.
- DoIP
Diagnostics over Internet Protocol
Diagnostic transport over IP networks as defined by ISO 13400.
- DTC
Diagnostic Trouble Code
A coded diagnostic record identifying a detected fault condition.
- DID
Data Identifier
A UDS identifier addressing diagnostic data exposed by an ECU.
- Diagnostic Session
Diagnostic Session
An ECU diagnostic operating mode controlling service availability and timing.
- Routine Control
Routine Control
The UDS service used to start, stop, or request results from ECU routines.
- Security Access
Security Access
A diagnostic challenge-response mechanism that unlocks protected ECU services.
- ODX
Open Diagnostic Data Exchange
An ASAM model for machine-readable ECU diagnostic data.
- PDX
Packed ODX Exchange
A distributable package containing related ODX documents and assets.
- DCM
Diagnostic Communication Manager
The Classic AUTOSAR basic-software module handling diagnostic communication.
- DEM
Diagnostic Event Manager
The Classic AUTOSAR module managing diagnostic events and trouble-code status.
FAQ
Practical questions before an investigation
- What do you need to start a diagnostic investigation?
- A description of the observed behavior is enough to begin. Progress is faster with a trace of the diagnostic exchange, access to the ECU or a bench setup, and whatever description data exists — ODX, PDX, or an ECU diagnostic specification. Where none of that is available, the first step is usually establishing a reproducible capture.
- Can a diagnostic problem be investigated without vehicle access?
- Often yes, if there is a recorded diagnostic exchange to work from. A trace shows request and response sequences, timing, and negative response codes, which is frequently enough to locate the failing layer. Confirming a fix, however, normally needs the ECU or a bench setup.
- Do you work on the tester side or in the ECU?
- Primarily the tester and application side — diagnostic clients, test sequences, analysis, and tooling — including integration against an existing ECU diagnostic implementation. ECU-side work is possible where the scope and the available source or specification make it practical.
- Is UDS work limited to CAN?
- No. UDS is handled over ISO-TP on CAN and CAN-FD as well as over DoIP on Automotive Ethernet. The diagnostic services are largely the same; the transport, addressing, and connection setup differ, and DoIP adds routing activation and network configuration as separate failure points.
- Can existing diagnostic tooling be extended rather than replaced?
- Yes, where the existing tool exposes a usable interface or its source is available. Extending an established workflow is usually cheaper than replacing it, and the choice is made from what the current tooling can and cannot reach.
Discuss the evidence
Discuss a Vehicle Diagnostics Project
Describe the diagnostic behavior you need investigated, built, or automated. A trace, an ODX package, or an ECU specification helps, but a clear problem description is enough to start.