Vehicle Diagnostics
Understand how segmented diagnostic communication travels over CAN, how ISO-TP coordinates message exchange, and how to isolate transport failures from UDS behavior.
Engineering model
ISO-TP governs the transport of diagnostic messages that do not fit into one CAN message. It depends on CAN for communication, on addressing and flow-control behavior for segmented transfers, and often carries UDS requests and responses between a diagnostic application and an ECU. Effective diagnosis separates CAN communication, ISO-TP transport, and UDS service behavior instead of treating every failed request as one problem.
Core concepts
ISO-TP divides a diagnostic payload into multiple CAN messages when the payload exceeds the available single-message capacity, then reconstructs it at the receiver. The sender and receiver must agree on the transfer state and timing.
Flow-control behavior regulates how a sender continues a segmented transfer. Incorrect handling can stop an otherwise valid diagnostic exchange even when CAN communication itself is present.
ISO-TP transports the payload used by UDS, while UDS defines the diagnostic meaning of the request and response. Keeping these layers separate helps distinguish a transport failure from a rejected diagnostic request.
CanTp provides an AUTOSAR implementation context for CAN transport behavior. Integration issues can arise when application, transport, and CAN configuration do not use compatible addressing or timing assumptions.
A diagnostic exchange is a chain of dependent layers. A failure at a lower layer can prevent the higher layer from producing any meaningful response.
CAN provides the in-vehicle communication path on which diagnostic messages are transmitted.
ISO-TP transports a diagnostic payload as one or more related CAN messages and reconstructs the payload at the receiving ECU.
UDS gives the reconstructed request and response their diagnostic meaning, such as reading data, handling a diagnostic session, or controlling a routine.
The application must distinguish a missing response, an incomplete transport exchange, and a valid UDS response that does not meet the expected behavior.
The first useful distinction is whether the diagnostic payload fits within one CAN message or requires transport coordination.
A small diagnostic payload can be transferred without a multi-message exchange. A larger payload requires ISO-TP segmentation: the sender transfers portions of the payload, the receiver provides flow-control information, and the sender continues according to the agreed transfer conditions. The receiver then reassembles the payload before UDS interprets it.
| Exchange characteristic | Single-message transfer | Segmented transfer |
|---|---|---|
| Payload size | Fits within one CAN message | Exceeds the available single-message capacity |
| Transport coordination | No multi-message flow-control exchange is required | Flow-control behavior coordinates continuation |
| Primary evidence | One diagnostic CAN message and its response | A sequence of related CAN messages with timing and continuation behavior |
| Typical failure focus | CAN communication, addressing, or UDS interpretation | Addressing, flow-control, timing, or incomplete reassembly |
Most ISO-TP communication failures are coordination failures: both endpoints may be present, but they do not agree on where or how the segmented exchange should proceed.
Timing observations should be interpreted with the complete exchange in view. A delayed message may reflect transport coordination, CAN bus activity, ECU processing, or an incomplete exchange; the recording alone may not identify the cause without the problem description and expected behavior.
Use a layered workflow so that each conclusion is supported by observable communication rather than by the final symptom alone.
Use the problem description to record the request, expected ECU response, relevant diagnostic session, and the conditions under which the issue occurs.
Inspect the BLF recording or ASC recording to determine whether the request and any ECU communication are present on the CAN path.
Determine whether the exchange is a single-message transfer or a segmented ISO-TP transfer.
For a segmented exchange, examine addressing, flow-control behavior, ordering, and timing until the payload is either completed or shown to be incomplete.
Only after transport completion, assess whether the ECU produced the expected UDS response, a diagnostic rejection, or no response.
Record what the communication proves, what remains uncertain, and which additional ECU or configuration observation would distinguish the remaining possibilities.
| Observed result | Most relevant layer | Reasoning direction |
|---|---|---|
| No diagnostic communication is visible | CAN or integration | Check communication path, addressing assumptions, and whether the diagnostic application transmitted the request. |
| Request is visible but segmented transfer stops | ISO-TP or CanTp | Inspect flow-control behavior, timing, and transfer progression before analyzing UDS. |
| Complete request is visible but no UDS response follows | ECU or UDS behavior | Check diagnostic session, request conditions, and whether the ECU was expected to answer. |
| A UDS response is received but is not positive | UDS | Interpret the response at the diagnostic-service layer rather than labeling it an ISO-TP failure. |
Recordings and definitions are evidence sources, but each has a different role in an ISO-TP investigation.
| Input | Useful role | Limitation |
|---|---|---|
| BLF recording | Preserves timestamped CAN communication for sequence and timing analysis | Shows observed communication, not necessarily the intended ECU configuration or expected response |
| ASC recording | Provides a text-based record that can be inspected for message order and timing | May require careful interpretation of the recorded CAN representation before transport conclusions are made |
| DBC | Defines CAN messages and signals when those definitions are relevant to the communication | Does not by itself establish that an ISO-TP exchange completed or that a UDS request was accepted |
| Problem description | Supplies symptoms, reproduction steps, context, and expected behavior | Can be incomplete or ambiguous if the expected diagnostic exchange is not stated |
| ECU | Provides the communication endpoint for reproduction or testing | Observed behavior may depend on diagnostic session and integration conditions |
An engineering analysis should connect each finding to an observed exchange, a stated expectation, or a controlled test. Avoid treating a DBC as a complete description of diagnostic transport behavior when the actual question concerns ISO-TP progression.
A diagnostic application or automated test suite should expose transport outcomes separately from UDS outcomes so that failures remain actionable.
The same visible symptom can result from different layers. Classify the evidence before assigning a cause.
| Problem | Evidence to collect | Finding to avoid |
|---|---|---|
| ECU not responding | Whether the request appears in the CAN recording, whether any transport progression follows, and whether the ECU is available for testing | Assuming the ECU is inactive without checking the communication path and transport exchange |
| UDS request fails | Whether the complete ISO-TP payload was transferred and whether the received response is a UDS response | Calling every unsuccessful diagnostic result an ISO-TP communication failure |
| ISO-TP communication failure | Addressing, flow-control behavior, message order, and timing across the complete exchange | Concluding that payload content caused the failure before transport completion is established |
The final engineering analysis should state the observed boundary: for example, whether communication was absent, transport stopped before completion, or UDS responded after a complete transfer. This keeps the finding proportional to the available evidence.
Engineering pitfalls
CAN messages may be present while a segmented exchange is incomplete. Verify transport progression, flow-control behavior, and timing before evaluating the diagnostic payload.
A UDS request cannot be interpreted reliably if ISO-TP did not deliver the complete payload. Separate transport status from UDS response status.
The same ECU may behave differently depending on the diagnostic session and request conditions. Include session state in the expected exchange and test setup.
A DBC defines CAN messages and signals, but it does not by itself prove ISO-TP completion or define the expected UDS result.
A missing response may reflect absent CAN communication, incorrect addressing, stopped flow control, timing behavior, ECU conditions, or an integration defect. Preserve these distinctions in the analysis.
A test can report a failed UDS assertion while hiding the fact that transport never completed. Record transport and diagnostic outcomes separately.
FAQ
Engineering support
Need a focused way to inspect ISO-TP traces, separate transport failures from UDS behavior, or build repeatable diagnostic tests? Discuss the engineering scope and expected evidence for a diagnostic application, engineering analysis, or automated test suite.