DID troubleshooting
A requested Data Identifier does not return a positive response, returns an unexpected negative response, or produces data that cannot be decoded as expected. This guide narrows the failure across diagnostic data, ECU state, access conditions, transport, and implementation behavior.
Start the diagnostic workflowObservable symptoms
The diagnostic trace shows a requested DID read followed by a negative response rather than the expected data record. Compare the response code and request context with the intended diagnostic session and access state to distinguish an unavailable DID from a sequencing or permission problem.
The ECU returns data for the requested DID, but the length, byte order, encoding, scaling, or value range does not match the diagnostic definition. This differs from a transport failure because the complete response is received and can be associated with the requested DID.
No usable response arrives, or a segmented response stops before the complete DID data is received. A trace showing missing or incomplete transport messages points toward communication, addressing, timing, or transport handling rather than only a DID definition error.
The DID can be read in one diagnostic session but returns a negative response, times out, or changes interpretation in another. Reproducing the result with the session transition and access sequence recorded helps separate session policy from ECU data availability.
The same ECU behavior is interpreted differently when different ODX or PDX data is used. This suggests a mismatch in DID definition, request construction, response decoding, session requirements, or versioned diagnostic data.
Possible causes
The ODX or PDX definition may contain the wrong DID value, request structure, response length, encoding, session requirement, or access requirement. The request can therefore target the wrong data or decode a valid response incorrectly.
The ECU's Diagnostic Communication Manager may restrict the DID to a particular diagnostic session. A request made before the required session transition can produce a negative response even when the DID is implemented.
The ECU may protect the DID behind Security Access or require an earlier diagnostic operation. Without the required state, the ECU can reject the read while communication and DID addressing remain correct.
A valid-looking request can reach a different ECU, an unintended diagnostic endpoint, or no intended endpoint at all. The resulting negative response, timeout, or unrelated data may resemble a DID implementation problem.
A DID response that exceeds one transport message depends on correct ISO-TP handling, including segmentation and reassembly. Incorrect transport processing can cause an incomplete response, timeout, or decoding failure even when the ECU generated valid data.
The DCM or application-side DID handler may use a different length, encoding, availability rule, or data source than the ODX or PDX description. This can produce a valid response with unexpected content or a consistent negative response.
Ordered investigation
Use the problem description and ECU to record the exact DID request, addressing context, diagnostic session, access sequence, complete response, timing, and expected value. This establishes whether the failure is a rejection, timeout, incomplete response, or decoding discrepancy.
Determine whether the ECU sends a positive response, a negative response, no response, or an incomplete response. This separates definition and ECU-policy investigation from addressing, timing, and transport investigation without assuming a root cause.
Compare the requested DID, request bytes, expected response structure, data length, encoding, session requirement, and access requirement with the active ODX or PDX data. This can rule out a description mismatch but cannot by itself prove the ECU implementation is correct.
Repeat the request in the documented diagnostic session and, where specified, after the required Security Access or prerequisite sequence. Record which state changes the result; a change narrows the issue to ECU policy or request sequencing rather than basic DID addressing.
Confirm that the request reaches the intended ECU and that the complete response is received and reassembled according to the selected transport. For an IP-based path, inspect DoIP behavior; for a segmented path, inspect ISO-TP transaction continuity and timing.
Use a trace from the diagnostic application or an analysis environment to compare raw request and response content with the decoded result. If the raw response is consistent but the displayed value is not, focus on ODX or PDX interpretation and application decoding.
If the request, state, addressing, transport, and diagnostic data are consistent, inspect the DCM and the ECU data provider for DID availability, length, encoding, and runtime errors. This is the point at which ECU software evidence or supplier analysis may be required.
Verification gates
Read the DID value and request structure from the active ODX or PDX data and compare them byte-for-byte with the transmitted diagnostic request.
The transmitted request addresses the intended DID and matches the active diagnostic definition.
A mismatch points to stale, incorrect, or incorrectly selected ODX or PDX data; correct the diagnostic data source before changing ECU behavior.
Capture the full response transaction, including any negative response, response timing, and all segmented transport messages when applicable.
The response is complete, associated with the request, and contains either the expected DID data or an interpretable negative response.
A missing or incomplete transaction directs investigation toward addressing, timing, ISO-TP, or DoIP handling rather than DID decoding alone.
Read the current Diagnostic Session state and compare it with the session required for the DID in the ODX or PDX definition.
The ECU is in the required diagnostic session before the DID request is sent.
A session mismatch can explain an otherwise valid request being rejected; verify the session transition and its timing.
Compare the requested DID's documented access requirement with the recorded Security Access sequence and resulting ECU state.
The ECU is in the access state required to read the DID, or the DID is documented as unrestricted.
A missing or unsuccessful access sequence points to diagnostic flow or ECU authorization handling; do not infer that the DID itself is absent.
Compare the received DID data length, byte order, encoding, scaling, and value range with the ODX or PDX definition.
The response conforms to the defined length and decoding rules and produces a plausible engineering value.
A mismatch points to diagnostic-data interpretation or ECU DID implementation; preserve the raw response for comparison.
For a segmented response, compare the received transport sequence with the expected ISO-TP reassembly and check whether the transaction terminates cleanly.
All response segments arrive in order and reassemble into one complete diagnostic response.
Missing, reordered, or malformed transport data points to transport configuration, timing, addressing, or interface handling.
From evidence to action
Update or select the ODX or PDX data that matches the ECU software and DID variant. Validate the request, session requirements, access requirements, response length, and decoding against a captured transaction.
Make the diagnostic application enter the required Diagnostic Session and complete any documented Security Access prerequisite before reading the DID. Preserve the response evidence to confirm that the sequence changes the result.
Fix the selected ECU endpoint, transport configuration, timeout handling, or ISO-TP or DoIP processing when the trace shows that the request or complete response is not reaching the intended interpretation path.
If the ECU receives the correct request but returns an inconsistent response, inspect the DCM integration and DID data provider for availability, length, encoding, and runtime behavior. A software correction may require an ECU build and regression testing.
FAQ
Diagnostic support
Need focused support for a reproducible DID read failure? Provide the diagnostic data and observed transaction for an evidence-based engineering analysis.