ISO 15765-2 (CAN-TP): The Complete Guide to CAN Transport Protocol

Classic CAN frames top out at 8 data bytes. That's plenty for a sensor reading or a status flag, but it's nowhere near enough for a diagnostic trouble code report, a firmware download, or a security seed/key exchange. ISO 15765-2 — commonly called CAN-TP or ISO-TP — is the transport layer that solves this by segmenting larger payloads into a sequence of CAN frames and reassembling them on the receiving end, with a flow-control mechanism to keep sender and receiver in step.

It's easy to confuse ISO 15765-2 with ISO 15765-4. They are not the same specification, and mixing them up leads to real integration problems: ISO 15765-4 is the OBD-II-specific network layer (fixed baud rate, standardized addressing, emissions-related diagnostics), while ISO 15765-2 is the general-purpose transport protocol underneath it — the same segmentation and flow-control mechanism that also carries UDS (ISO 14229) diagnostics, proprietary application messages, and non-OBD-II CAN traffic in industrial, off-highway, and commercial vehicle systems. If your project needs transport-layer segmentation for anything beyond legislated OBD-II PIDs — UDS diagnostic sessions, ECU reflashing, custom multi-byte application messages — you need ISO 15765-2, not ISO 15765-4.

Why CAN Needs a Transport Layer at All

Classic CAN 2.0 frames carry up to 8 bytes of data. CAN FD extends this to 64 bytes, but even that ceiling gets hit quickly by anything resembling a real payload: a UDS "Read Data by Identifier" response, a security access seed, or a block of firmware being downloaded during a reflash. ISO 15765-2 defines how to:

• Break a payload larger than one frame's capacity into multiple frames (segmentation)
• Reassemble those frames back into the original payload at the receiver (reassembly)
• Regulate how fast the sender transmits consecutive frames so the receiver's buffer isn't overrun (flow control)
• Detect and recover from timing errors or out-of-sequence frames (error handling)

This sits at OSI Layer 4 (transport), below the diagnostic/application protocols (UDS, KWP2000, proprietary protocols) that actually interpret the reassembled payload's meaning.

Frame Types and the Multi-Frame Exchange, Briefly

ISO 15765-2 defines four PCI (Protocol Control Information) frame types — Single Frame (SF), First Frame (FF), Consecutive Frame (CF), and Flow Control (FC) — distinguished by the high nibble of the first data byte. A payload that fits in one frame is sent as a Single Frame with no further handshake needed. A larger payload starts with a First Frame announcing the total length, is met with a Flow Control frame from the receiver specifying BlockSize and STmin, and is then delivered across sequentially numbered Consecutive Frames until reassembly completes on the receiving end.

We've covered this handshake — SF/FF/CF/FC, STmin, and Block Size — in detail in our ISO 15765-4 (OBD-II over CAN) guide, since the same ISO-TP mechanism underlies OBD-II diagnostics. What follows here goes beyond that OBD-II-specific implementation into the parts of ISO 15765-2 that a general-purpose, multi-application transport layer needs to handle.

Addressing Formats

ISO 15765-2 supports multiple addressing schemes, which determine how CAN identifiers map to source/target/functional addressing — a distinction that matters as soon as more than two nodes share a bus.

Choosing the wrong addressing format for a given network topology is one of the most common sources of interoperability failures between tools from different vendors — a diagnostic tester expecting Normal Fixed Addressing will not correctly parse traffic from an ECU configured for Extended Addressing, even though both are valid ISO 15765-2 configurations.

ISO 15765-2 vs. ISO 15765-4: Clearing Up the Confusion

In short: ISO 15765-4 is a specific, constrained profile of ISO 15765-2. Implementing only the -4 profile means an ECU can talk OBD-II, but it cannot support the broader set of UDS diagnostic services, manufacturer-specific CAN messaging, or non-OBD-II network topologies that a full ISO 15765-2 transport layer enables. Any system needing UDS-based reflashing, extended diagnostic sessions, or proprietary multi-frame application data over CAN needs the complete -2 implementation, not just the -4 subset.

Implementation Considerations for Embedded Systems

A production-grade ISO 15765-2 stack has to handle more than the happy-path FF/FC/CF exchange:

• STmin enforcement. The sender must respect the receiver's requested separation time precisely; too-fast transmission can overrun buffers on slower ECUs, while ignoring STmin is a common cause of intermittent, hard-to-reproduce field failures.
• BlockSize=0 handling. A receiver requesting BlockSize 0 means "send everything without further flow control," which changes buffer management on the sender side.
• Timeout recovery. N_Ar, N_Bs, N_Cr and related timers need to abort cleanly and free buffers rather than leaving the state machine stuck, especially under bus-off or arbitration-loss conditions.
• Concurrent sessions. Multi-ECU networks often need to support multiple simultaneous transport-layer conversations (e.g., a tester polling several ECUs), which means the stack needs per-session state rather than a single global buffer.
• Sequence number wraparound. CF sequence numbers cycle 0-15; a robust implementation must correctly detect and reject out-of-sequence or duplicate frames rather than silently corrupting reassembly.
• Real-time determinism. Because CAN-TP commonly underlies UDS-based reflashing, the transport layer's buffer management and timer handling need to run predictably alongside the rest of the real-time application — a slow or blocking implementation directly extends flash/reprogramming time.

How Simma Software Fits In

Simma Software's protocol stacks span the full diagnostic and transport stack that ISO 15765-2 sits within — CAN, UDS, ISO 15765-4/OBD-II, KWP2000, and J1939 — all written in 100% ANSI C against a stable, vendor-independent hardware API (can_tx(), can_rx(), nv_write(), nv_read(), and similar). Because our stacks are built for deterministic, hard real-time performance — typically ~2% CPU utilization while sustaining ~8,000 CAN frames/sec — a full ISO 15765-2 transport layer integrates without disturbing the timing guarantees the rest of the application depends on, whether it's supporting UDS-based ECU reflashing, extended diagnostic sessions, or proprietary multi-frame CAN messaging beyond what an OBD-II-only implementation can carry.

Frequently Asked Questions

Is ISO 15765-2 the same as ISO-TP?

Yes. "ISO-TP" and "CAN-TP" are both common shorthand names for ISO 15765-2, the CAN Transport Protocol standard.

Do I need ISO 15765-2 if I already have ISO 15765-4 (OBD-II)?

If your system only needs to respond to legislated OBD-II PIDs, the -4 profile alone may suffice. But ISO 15765-4 is built on top of ISO 15765-2's segmentation and flow-control mechanism with a constrained addressing/baud-rate profile — it does not include the broader addressing formats or general-purpose transport capability needed for UDS diagnostic sessions, ECU reflashing, or proprietary CAN messaging. Most systems that need more than basic emissions diagnostics need the full -2 implementation.

What's the maximum payload size ISO 15765-2 supports?

The First Frame length field allows payloads up to 4095 bytes under the standard addressing scheme, with an extended length mechanism in later revisions of the standard supporting larger payloads for CAN FD-based systems.

Can ISO 15765-2 run over CAN FD as well as classic CAN?

Yes. ISO 15765-2 has been extended to support CAN FD's larger frame payloads (up to 64 bytes), which reduces the number of Consecutive Frames needed for a given payload size compared to classic CAN's 8-byte frames.

What causes most real-world ISO 15765-2 interoperability failures?

Mismatched addressing formats (e.g., one node using Extended Addressing while another expects Normal Fixed Addressing) and incorrect STmin/timeout handling are the two most common sources of failures between tools and ECUs from different vendors, even when both sides claim standard compliance.