ISO 15765-2
ISO 15765-2,[1] or ISO-TP (Transport Layer), is an international standard for sending data packets over a CAN-Bus. The protocol allows for the transport of messages that exceed the eight byte maximum payload of CAN frames. ISO-TP segments longer messages into multiple frames, adding metadata (CAN-TP Header) that allows the interpretation of individual frames and reassembly into a complete message packet by the recipient. It can carry up to 232-1 (4294967295) bytes of payload per message packet starting from the 2016 version. Prior version were limited to a maximum payload size of 4095 bytes.
In the OSI Model, ISO-TP covers the layer 3 (network layer) and 4 (transport layer).
The most common application for ISO-TP is the transfer of diagnostic messages with OBD-2 equipped vehicles using KWP2000 and UDS, but is used broadly in other application-specific CAN implementations where one might need to send messages longer than what the CAN protocol physical layer allows (8 bytes for CAN, 64 bytes for CAN-FD, and 2048 bytes for CAN-XL).
ISO-TP can be operated with its own addressing as so-called Extended Addressing or without address using only the CAN ID (so-called Normal Addressing). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte. For clarity the protocol description below is based on Normal Addressing with eight byte CAN frames. In total, six types of addressing are allowed by the ISO 15765-2 Protocol.
ISO-TP prepends one or more metadata bytes to the payload data in the eight byte CAN frame, reducing the payload to seven or fewer bytes per frame. The metadata is called the Protocol Control Information, or PCI. The PCI is one, two or three bytes. The initial field is four bits indicating the frame type, and implicitly describing the PCI length.
ISO 15765-2 is a part of ISO 15765 (headlined Road vehicles — Diagnostic communication over Controller Area Network (DoCAN)), which has the following parts:
- ISO 15765-1 Part 1: General information and use case definition
- ISO 15765-2 Part 2: Transport protocol and network layer services
- ISO 15765-3 Part 3: Implementation of unified diagnostic services (UDS on CAN) – replaced by ISO 14229-3 Road vehicles — Unified diagnostic services
- ISO 15765-4 Part 4: Requirements for emissions-related systems
List of protocol control information field types
The ISO-TP defines four frame types:
| Type | Code | Description |
|---|---|---|
| Single frame (SF) | 0 | The single frame transferred contains the complete payload of up to 7 bytes (normal addressing) or 6 bytes (extended addressing) |
| First frame (FF) | 1 | The first frame of a longer multi-frame message packet, used when more than 6/7 bytes of data segmented must be communicated. The first frame contains the length of the full packet, along with the initial data. |
| Consecutive frame (CF) | 2 | A frame containing subsequent data for a multi-frame packet |
| Flow control frame (FC) | 3 | the response from the receiver, acknowledging a First-frame segment. It lays down the parameters for the transmission of further consecutive frames. |
| 4..15 | Reserved |
| Bit offset | 7 .. 4 (byte 0) | 3 .. 0 (byte 0) | 15 .. 8 (byte 1) | 23..16 (byte 2) | .... |
|---|---|---|---|---|---|
| Single | 0 | size (0..7) | Data A | Data B | Data C |
| First | 1 | size (8..4095) | Data A | Data B | |
| Consecutive | 2 | index (0..15) | Data A | Data B | Data C |
| Flow | 3 | FC flag (0,1,2) | Block size | ST | |
A message of seven bytes or less is sent in a single frame, with the initial byte containing the type (0) and payload length (1-7 bytes). With the 0 in the type field, this can also pass as a simpler protocol with a length-data format and is often misinterpreted as such.
A message longer than 7 bytes requires segmenting the message packet over multiple frames. A segmented transfer starts with a First Frame. The PCI is two bytes in this case, with the first 4 bit field the type (type 1) and the following 12 bits the message length (excluding the type and length bytes). The recipient confirms the transfer with a flow control frame. The flow control frame has three PCI bytes specifying the interval between subsequent frames and how many consecutive frames may be sent (Block Size).
For CAN FD, the ISO 15765-2 protocol has been extended for Single and First frame, to allow larger size values, but still backwards compatible with traditional ISO 15765. See CAN FD.
| Bit offset | 7 .. 4 (byte 0) | 3 .. 0 (byte 0) | 15 .. 8 (byte 1) | 23..16 (byte2) |
|---|---|---|---|---|
| Description | type | if the transfer is allowed | Block Size | Separation Time (ST), minimum delay time between frames (end of one frame and the beginning of the other) |
| Single | type = 3 | (0 = Continue To Send, 1 = Wait, 2 = Overflow/abort) | 0 = remaining "frames" to be sent without flow control or delay | <= 127 (0x00 to 0x7F), separation time in milliseconds. |
| Single | type = 3 | (0 = Continue To Send, 1 = Wait, 2 = Overflow/abort) | > 0 send number of "frames" before waiting for the next flow control frame | 0xF1 to 0xF9 UF, 100 to 900 microseconds. |
The initial byte contains the type (type = 3) in the first four bits, and a flag in the next four bits indicating if the transfer is allowed (0 = Continue To Send, 1 = Wait, 2 = Overflow/abort). The next byte is the block size, the count of frames that may be sent before waiting for the next flow control frame. A value of zero allows the remaining frames to be sent without flow control or delay. The third byte is the Separation Time (ST), the minimum delay time between frames. ST values up to 127 (0x7F) specify the minimum number of milliseconds to delay between frames, while values in the range 241 (0xF1) to 249 (0xF9) specify delays increasing from 100 to 900 microseconds. Note that the Separation Time is defined as the minimum time between the end of one frame to the beginning of the next. Robust implementations should be prepared to accept frames from a sender that misinterprets this as the frame repetition rate i.e. from start-of-frame to start-of-frame. Even careful implementations may fail to account for the minor effect of bit-stuffing in the physical layer.
The sender transmits the rest of the message using Consecutive Frames. Each Consecutive Frame has a one byte PCI, with a four bit type (type = 2) followed by a 4-bit sequence number. The sequence number starts at 1 and increments with each frame sent (1, 2,..., 15, 0, 1,...), with which lost or discarded frames can be detected. Each consecutive frame starts at 0, initially for the first set of data in the first frame will be considered as 0th data. So the first set of CF(Consecutive frames) start from "1". There afterwards when it reaches "15", will be started from "0". The 12 bit length field (in the FF) allows up to 4095 bytes of user data in a segmented message, but in practice the typical application-specific limit is considerably lower because of receive buffer or hardware limitations.
Timing parameters
Timing parameters like P1 and P2 timer has to be mentioned.
Standards
References
 |  |
