DoIP Diagnostics Guide

The diagnostic application first needs a functioning Automotive Ethernet path to the ECU. DoIP then handles discovery, routing activation, and transport over IP networks. Once that path is available, the application exchanges UDS requests and responses with the ECU. A failure at an earlier stage prevents later stages from being interpreted reliably.

DoIP is responsible for moving diagnostic communication through the IP-based path. UDS defines the diagnostic services used to access ECU functions and data, including diagnostic sessions, DIDs, DTC handling, routine control, and security access. A successful DoIP connection does not establish that a particular UDS request is supported or permitted.

• Use DoIP evidence to determine whether the ECU can be discovered, routed, and reached over TCP communication.
• Use UDS evidence to determine whether the request format, service state, diagnostic session, and ECU response are consistent with the expected behavior.
• Use ODX or PDX to interpret the intended diagnostic data, but compare that description with observed ECU behavior.
• Do not classify an absent UDS response as a UDS service failure until the DoIP connection and transport path have been shown to be healthy.

1. 01

   Define the expected exchange

   Record the ECU, the diagnostic request, the expected response, the reproduction steps, and the conditions under which the problem occurs. Use the problem description as the baseline for analysis.

2. 02

   Check Automotive Ethernet activity

   Determine whether network traffic exists at all. If the packet capture contains no relevant traffic, investigate the network path before evaluating DoIP or UDS behavior.

3. 03

   Inspect DoIP discovery

   Check whether the expected ECU participates in discovery. An ECU not responding at this stage cannot be diagnosed by analyzing a later UDS response.

4. 04

   Inspect routing activation

   Verify whether diagnostic routing is requested and whether the exchange completes. A discovery result alone does not demonstrate that diagnostic communication is available.

5. 05

   Check TCP communication

   Confirm that the transport connection is established and remains usable for the diagnostic exchange. Separate connection establishment problems from request-level problems.

6. 06

   Evaluate the UDS exchange

   Only after the DoIP path is established, compare the request and response with the expected UDS behavior and the applicable ODX or PDX description.

7. 07

   Preserve and correlate evidence

   Correlate application timestamps, packet timestamps, request content, response content, and the problem description. Record uncertainty where the evidence does not isolate one cause.

Start by identifying the first relevant network activity and follow the exchange through discovery, routing activation, TCP communication, and UDS traffic. Compare the observed order with the expected connection model. Missing traffic, repeated attempts, delayed responses, and a connection that closes at a specific point are all useful evidence, but none should be treated as conclusive without correlating the application result and reproduction conditions.

• Preserve the original PCAP and analyze a working and failing exchange separately when both are available.
• Record timestamps and maintain the observed order of discovery, routing activation, TCP communication, and UDS activity.
• Distinguish no response from a negative UDS response; they indicate different points of failure.
• Correlate packet evidence with the diagnostic application result rather than relying on the application message alone.
• Document the capture conditions, ECU under test, request used, and expected behavior so the analysis can be repeated.

ODX provides diagnostic-data descriptions, while PDX packages ODX data for exchange. A diagnostic application can use these inputs to construct and interpret UDS communication, but the data description does not establish that the ECU is reachable through DoIP or that the implementation behaves exactly as described.

1. 01

   Load the diagnostic description

   Identify the ODX or PDX data that applies to the ECU and diagnostic operation being tested.

2. 02

   Separate description from observation

   Record what the diagnostic data predicts independently from what the ECU and packet capture actually show.

3. 03

   Exercise the communication path

   Establish the DoIP path and perform the UDS exchange under defined test conditions.

4. 04

   Compare expected and observed behavior

   Check request structure, response behavior, diagnostic session assumptions, and timing evidence without treating a mismatch as proof of one specific root cause.

5. 05

   Document the discrepancy

   Capture the relevant input data, PCAP evidence, application result, and problem description in an engineering analysis.

A useful diagnostic application should not collapse discovery failure, routing activation failure, TCP communication failure, and UDS request failure into one generic result. An automated test suite should assert each relevant stage separately, preserve the request and response evidence, and report the point at which expected behavior diverged.

• Represent DoIP connection stages explicitly so failures can be located without inspecting raw output first.
• Keep UDS service interpretation separate from transport status.
• Make the ECU, ODX or PDX input, request, expected response, and reproduction conditions part of the test context.
• Store packet evidence when a test fails so a repeated run can be compared with the original result.
• Use engineering analysis to record evidence and reasoning rather than only recording pass or fail.