UDS troubleshooting
A diagnostic request reaches an unexpected negative response, times out, or cannot be exchanged correctly with the ECU. This guide narrows the failure across CAN, ISO-TP, DoIP, diagnostic session, DID, routine control, and security access behavior.
Start the diagnostic workflowObservable symptoms
The request is sent, but the trace contains no corresponding ECU response. This differs from a negative response, where the ECU has received and answered the request.
The ECU answers, but the response indicates that the requested service is not accepted in the current condition. Compare the returned code and request context rather than treating every negative response as a transport failure.
The first part of a request or response is visible, but the ISO-TP exchange does not complete. This differs from an application-level rejection after a complete request has been received.
A response is present in the trace, but the diagnostic application cannot map or validate it. Compare the raw request and response with the applicable ODX or PDX data.
The same request succeeds after a diagnostic session change or security access sequence but fails when sent directly. This points toward ECU state or access prerequisites rather than a general bus outage.
Possible causes
The request may contain an incorrect service, DID, routine-control parameter, or expected response interpretation. An ODX or PDX mismatch can make a valid ECU exchange appear invalid or cause the ECU to reject the request.
The ECU may expose the requested service only in a particular diagnostic session or after an expected sequence. Sending the request in the default or otherwise unsuitable session can produce a negative response even when communication is healthy.
Protected services can remain unavailable until security access has been completed, or an unlock can become invalid after a session change or timeout. The request then reaches the ECU but is not authorized for execution.
Incorrect CAN communication parameters, diagnostic addressing, message identifiers, or ISO-TP handling can prevent the ECU from receiving the complete request or the tester from decoding the response.
For a DoIP exchange, an unavailable or incorrectly configured IP diagnostic path can prevent requests from reaching the ECU even though the diagnostic payload is correct.
The ECU implementation, Diagnostic Communication Manager, or its configuration may not support the requested service in the observed state, or may contain a defect in service handling and response timing.
Ordered investigation
Use the problem description to record the ECU, request bytes or diagnostic operation, transport in use, expected response, actual response, timing, and the sequence that preceded the failure. This separates a reproducible request failure from an incomplete observation.
Inspect the raw exchange and classify it as no response, negative response, incomplete ISO-TP transfer, or response-decoding failure. This rules out unrelated branches before changing ECU state or configuration.
Confirm that CAN traffic or the DoIP path carries the complete request and that the ECU response is received without an interrupted segmented transfer. This rules out many bus, addressing, and transport-handling causes but does not prove that the application request is valid.
Use the applicable ODX or PDX description to compare the requested service, DID or routine-control parameters, response structure, and ECU variant assumptions. This can identify an invalid request or decoder mismatch without changing ECU state.
Reproduce the failure while explicitly controlling the diagnostic session and, where required, the security access sequence. Compare the result before and after those prerequisites; a change narrows the issue to session or authorization handling.
If transport and request data are consistent but the failure remains, compare the trace with the ECU or Diagnostic Communication Manager configuration and review the timing and service-handling behavior. This is the point to involve the ECU software owner when the available evidence cannot distinguish configuration from implementation.
Verification gates
In the trace, locate the response corresponding to the failed request and compare its timing and payload with the request context.
A complete response is present and can be associated unambiguously with the request.
No response points toward ECU availability, CAN, DoIP, addressing, or transport-path investigation; a present but unrelated response requires correlation review.
Compare the request and response frames in the BLF recording, including whether each segmented exchange reaches completion and whether the transport sequence remains consistent.
The complete request reaches the ECU and the complete response is received without an interrupted ISO-TP transfer.
An incomplete exchange points toward CAN configuration, CanTp or ISO-TP handling, addressing, or bus-level conditions rather than the requested diagnostic service.
Compare the service, DID or routine-control parameters, ECU variant, request length, and response interpretation with the applicable ODX or PDX data.
The request and expected response structure match the diagnostic description for the target ECU.
A mismatch can cause ECU rejection or local decoding failure; correct the diagnostic data selection or request construction before deeper ECU analysis.
Read the trace sequence and verify which diagnostic session was active immediately before the failed request and whether the expected session transition completed.
The ECU is in the session required by the requested service, with the transition acknowledged before the request is sent.
A missing or unsuccessful transition makes session availability a primary suspect; confirm the sequence and ECU session behavior.
Review whether the required security access sequence completed before the protected request and whether a session change or timeout occurred afterward.
The required access state is established and remains valid when the request is issued.
The protected service may be rejected because access was not completed, was invalidated, or was attempted in an unsuitable session; involve the ECU or security owner if the expected sequence is unclear.
Capture or compare a sequence in which the request succeeds with the sequence in which it fails, including transport, session, security access, and request data.
The sequences differ in a specific, reproducible prerequisite or payload field.
No material difference remains; investigate ECU or Diagnostic Communication Manager configuration and implementation behavior rather than repeatedly changing the request.
From evidence to action
Select the correct ODX or PDX data for the ECU variant and fix the service, DID, routine-control parameters, request construction, or response interpretation. Re-run the same trace-based checks to confirm that the exchange is complete and correctly interpreted.
Implement the required diagnostic session transition and security access handling before the failed request, including appropriate sequencing and state checks. If the expected sequence is not documented or does not behave consistently, obtain the required ECU or OEM diagnostic definition.
Correct the relevant transport, addressing, communication, or path configuration and verify it against a complete trace. Changes to ECU-side CanTp or Diagnostic Communication Manager configuration require the responsible software owner when they are not controlled by the diagnostic application.
If the request, transport, session, and access state are supported and consistent but the ECU still fails, provide the engineering analysis and reproducible evidence to the ECU software, supplier, or OEM owner. The resolution may require a configuration change, software correction, or clarification of supported behavior rather than a local tester change.
FAQ
Diagnostic support
If the evidence spans transport, ECU state, and diagnostic data, an engineering analysis can document the fault boundary; a diagnostic application, automated test suite, or CAPL script can then make the verified sequence repeatable.