Segmentation and reassembly
CanTp divides a diagnostic payload into transport segments and reconstructs it at the receiver; a defect in either direction can appear as a truncated, stalled, or rejected diagnostic exchange.
Vehicle Diagnostics
CanTp Debugging Guide
A practical engineering guide to diagnosing segmented diagnostic communication over CAN, from application requests through DCM, PduR, CanTp, and the bus.
Engineering model
How CanTp fits together
CanTp governs how diagnostic payloads larger than one CAN message are segmented, transmitted, acknowledged through flow control, and reassembled. In an AUTOSAR system, its behavior depends on aligned configuration across DCM, PduR, CanTp, and CAN, as well as compatible addressing, buffer, and timing parameters. Debugging is most effective when the software path is compared with the observed CAN traffic at each boundary.
Core concepts
The parts of a practical CanTp setup
Flow control
The receiving side regulates continued transmission through flow-control behavior, so buffer availability, permitted transmission quantity, and timing must agree between both endpoints.
Layer routing
PduR connects the diagnostic communication path between DCM and CanTp, making routing configuration and PDU identity central to isolating whether a failure is above or below transport.
CAN observation
CAN provides the observable bus traffic used to distinguish missing transmissions, incorrect identifiers, malformed segmentation, arbitration effects, and responses that never reach the expected software layer.
How the CanTp path is assembled
Start with the complete path rather than treating a failed diagnostic request as a CanTp-only defect.
A diagnostic exchange normally crosses DCM, PduR, CanTp, and CAN in sequence. DCM produces or consumes diagnostic data, PduR routes the relevant communication path, CanTp manages segmentation and reassembly, and CAN carries the resulting messages. The reverse path follows the same layers in the opposite direction. A failure is easier to localize when each boundary has an expected input and output.
| Layer | Primary responsibility | Useful observation |
|---|---|---|
| DCM | Handles diagnostic communication and its diagnostic data exchange | Whether the diagnostic request or response is created and accepted by the diagnostic layer |
| PduR | Routes communication between upper and lower layers | Whether the expected routed path is selected for the relevant payload |
| CanTp | Segments, transmits, receives, and reassembles diagnostic payloads | Whether transport state advances, waits, times out, or rejects the exchange |
| CAN | Carries the messages used by the transport exchange | Whether the expected messages appear with compatible identifiers and ordering |
Build an observable failure model
Define what should happen before changing configuration or code.
- 01
Record the intended exchange
Use the requirements to identify the direction, expected diagnostic payload, addressing arrangement, and whether the payload requires segmentation.
- 02
Separate software and bus evidence
Capture the CAN exchange while observing the relevant DCM, PduR, and CanTp boundaries. A missing bus message and a missing upper-layer callback are different failure classes.
- 03
Mark the first divergence
Compare the expected sequence with the observed sequence and identify the first absent, unexpected, delayed, or malformed event rather than starting from the final timeout.
- 04
Repeat with one controlled change
Change one configuration or implementation variable at a time, then repeat the same request and compare the resulting software and CAN evidence.
Addressing and route consistency
Many apparent transport defects are caused by inconsistent identities across configuration artifacts and runtime layers.
The sender and receiver must agree on which CAN traffic belongs to the diagnostic path. Check that the identifiers and addressing assumptions represented in the ARXML, DBC, and requirements describe the same exchange. Then verify that PduR routes the corresponding upper-layer and lower-layer objects to the intended CanTp path. A CAN trace can show valid-looking traffic while the software ignores it if the configured identity does not match.
- Compare the intended request and response identities in the requirements with the ARXML configuration and DBC representation.
- Confirm that the transmit direction and receive direction are not accidentally exchanged.
- Check that the routed communication objects are connected to the expected DCM and CanTp instances.
- Distinguish an absent CAN transmission from a received message that is discarded before reaching the expected layer.
- Repeat the check for both directions; a working request path does not prove that the response path is correctly routed.
Segmentation and flow-control behavior
Use the observed sequence to determine whether the exchange fails before segmentation, during continuation, or during reassembly.
For a payload that exceeds one CAN message, CanTp must establish a segmented exchange, transmit or receive the initial portion, and continue according to the receiver's flow-control behavior. The receiver must accept the segments in order and retain enough buffer state to reassemble the payload. If the exchange stops after the initial portion, investigate whether flow control was sent, received, interpreted, and acted upon. If it stops during continuation, inspect sequence progression, receiver state, and buffer availability.
| Observed behavior | Likely investigation area | Evidence to collect |
|---|---|---|
| No transport traffic appears | Upper-layer trigger, PduR route, CanTp activation, or CAN transmission path | DCM request result, PduR routing observation, CanTp state entry, and CAN trace |
| Initial portion appears but continuation does not | Flow-control reception, sender state, or transport timing | Flow-control message, sender state transition, and elapsed time between messages |
| Continuation appears but receiver does not complete | Sequence handling, receiver buffer, or reassembly state | Message order, sequence progression, receive-state changes, and completion indication |
| Exchange works for short payloads but not longer payloads | Segmentation threshold, buffer sizing, or multi-message configuration | Payload length, configured buffer capacity, and the first message where behavior diverges |
Timing and state progression
Timing should be analyzed as a sequence of state transitions, not as a single large timeout.
CanTp behavior depends on the receiver responding within the permitted timing window and the sender continuing only when the transport state allows it. A delayed flow-control response, an unexpectedly delayed continuation, or a timer that is started or stopped at the wrong state can produce the same external symptom: the exchange ends without a complete diagnostic payload. Compare timestamps from the CAN trace with transport state changes and periodic processing. Also check whether the configured timing values are represented consistently across the relevant ARXML configuration and requirements.
- Measure the interval from the initial segmented transmission to the flow-control response.
- Measure the interval between each permitted continuation and the next transmitted segment.
- Check whether a timer begins at transmission, reception, or a state transition as intended by the implementation.
- Look for periodic processing delays that make a valid CAN message arrive after the software has already abandoned the exchange.
- Test both directions because a receiver-side delay and a sender-side delay can produce different traces.
A disciplined debugging procedure
Use a repeatable sequence that narrows the defect without changing several assumptions at once.
- 01
Validate the test stimulus
Confirm that the request is the intended diagnostic exchange, that its payload length is known, and that the same stimulus can be repeated.
- 02
Inspect the CAN trace
Determine whether the initial, flow-control, and continuation traffic expected for the exchange is present, correctly ordered, and delivered in the expected direction.
- 03
Trace the software boundaries
Correlate the CAN observation with DCM callbacks, PduR routing activity, and CanTp state changes to locate the first layer that diverges.
- 04
Check configuration artifacts
Compare ARXML, DBC, and requirements for identifiers, directions, payload assumptions, buffer-related settings, and timing values.
- 05
Reproduce at boundary conditions
Test a payload that remains within one CAN message and another that requires segmentation, then compare the first divergent event.
- 06
Lock the regression
Add the reproducible exchange and its expected software and CAN observations to an automated test suite.
The most useful debug record contains the stimulus, payload length, relevant configuration revision, CAN trace, first divergence, suspected layer, and the result after one controlled change. This makes a transport defect distinguishable from an integration defect and gives later testing a precise expected behavior.
Testing CanTp changes
Transport fixes need tests that exercise both successful progression and controlled failure behavior.
- Test a payload that does not require segmentation to separate basic routing from segmented transport behavior.
- Test a payload that requires segmentation and verify completion, ordering, and reassembly.
- Test delayed or absent flow-control behavior and verify that the exchange terminates according to the configured behavior.
- Test incompatible addressing or routing configuration and verify that the failure is observable without being misclassified as a successful diagnostic exchange.
- Repeat the same cases in both communication directions where the implementation supports both roles.
- Preserve the CAN evidence and software result as assertions in the automated test suite.
| Test focus | Expected evidence | Diagnostic value |
|---|---|---|
| Single-message diagnostic payload | DCM and PduR path completes without segmented transport continuation | Separates basic routing and CAN delivery from segmentation behavior |
| Segmented diagnostic payload | Initial transmission, permitted continuation, and complete reassembly are observed | Confirms normal CanTp progression across multiple messages |
| Flow-control delay or absence | Transport does not remain indefinitely active and reports the configured failure behavior | Exposes timer and state-cleanup defects |
| Configuration mismatch | Unexpected traffic is rejected or not routed, with a reproducible software result | Helps distinguish identity errors from bus loss |
Engineering pitfalls
Common mistakes
Debugging only the final timeout
A timeout does not identify the failing layer. Trace backward to the first missing or unexpected event across DCM, PduR, CanTp, and CAN.
Assuming a CAN trace proves software reception
A message can be visible on CAN but fail to match configured addressing or routing. Confirm that the expected software boundary receives and accepts it.
Changing timing before checking flow control
A missing or incorrectly interpreted flow-control response can look like a timing defect. Verify the response and state transition before widening timing values.
Testing only short diagnostic payloads
A path can work for a single CAN message while failing during segmentation, continuation, buffering, or reassembly. Include payloads that require transport segmentation.
Treating ARXML, DBC, and requirements as independent truths
Inconsistent identifiers, directions, or payload assumptions across these inputs can create a valid-looking but unusable integration. Compare them as one configuration model.
Changing several configuration values in one iteration
Multiple simultaneous changes destroy causal evidence. Modify one variable, reproduce the same exchange, and record the first changed observation.
FAQ
CanTp questions
- How can I tell whether a failure is in CanTp or PduR?
- Compare the first software event with the CAN trace. If the expected upper-layer data reaches the routing boundary but no corresponding CanTp activity occurs, inspect PduR connectivity and object identity. If CanTp starts but the expected CAN traffic or state progression is absent, inspect CanTp configuration and runtime behavior.
- Why can a diagnostic request work for a short payload but fail for a longer one?
- The short request may never exercise segmentation, flow control, continuation, buffer handling, or reassembly. Compare the two exchanges at the first additional transport event and check payload length, buffer-related configuration, timing, and continuation ordering.
- What should a CAN trace contain during a segmented exchange?
- It should show the initial transport transmission, the receiver's flow-control behavior, and the permitted continuation traffic in the expected order and direction. The exact sequence depends on the configured exchange, so compare the trace with the requirements and configuration rather than assuming one universal timing pattern.
- Can incorrect DBC data cause a CanTp failure?
- Yes, if the DBC is used to define or validate the expected CAN identities and those identities differ from ARXML or the requirements. The bus may carry traffic that appears plausible while the configured software does not associate it with the intended diagnostic path.
- What evidence should be retained after fixing a CanTp defect?
- Retain the reproducible stimulus, payload length, relevant ARXML and DBC assumptions, CAN trace, software observations at DCM, PduR, and CanTp boundaries, first divergence, and the automated test result. This supports regression analysis without relying on the final symptom alone.
Engineering support
Discuss a CanTp Project
Need focused CanTp integration support, a firmware module, or an automated test suite? Define the exchange and produce an evidence-based engineering path.