ISO 15765-2
ISO 15765-2, or ISO-TP, 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 that allows the interpretation of individual frames and reassembly into a complete message packet by the recipient. It can carry up to 4095 bytes of payload per message packet.
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.
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.
The ISO-TP defines four frame types:
List of protocol control information field types
| Type | Code | Description |
|---|---|---|
| Single frame | 0 | The single frame transferred contains the complete payload of up to 7 bytes (normal addressing) or 6 bytes (extended addressing) |
| First frame | 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 | 2 | A frame containing subsequent data for a multi-frame packet |
| Flow control frame | 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. 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).
| Bit offset | 7 .. 4 | 3 .. 0 | 15 .. 8 | 23..16 |
|---|---|---|---|---|
| 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, 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, 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 = Clear 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.