Network Services - Diagnostics on CAN
ISO15765-2 is a specification produced by ISO to define a standard network-layer protocol for manufacturer enhanced diagnostics on CAN. Put simply, the network layer defined in 15765-2 allows a frame of 0-4095 bytes to be sent over CAN in a standard manner between two peers on a CAN bus. The underlying CAN specification, ISO 11898, is also available from ISO, but the specifications aren't cheap.
Please note that this document is in no way normative or a formal specification - merely a summary of the protocol for those attempting to dive into. No warranty is expressly given or implied - use the ISO specs for a normative reference if you're attempting to create an implementation or decode the protocol.
Note: This page will deal only with the normal addressing form of ISO15765-2.
Overview
The protocol described in ISO15765-2 defines a method for a payload to be sent between two peers on a CAN bus where the payload is larger than a single CAN frame (8 bytes). The protocol allows for a payload between 0 and 4095 bytes, and operates on a positive flow control mechanism - that is, the receiver must send a flow control frame in order for the sender to transmit a payload frame beyond the first frame.
Firstly, the sender of the payload will transmit a "First Frame" to the receiver. This frame specifies a 12-bit data length, alongside the first 6 bytes of the payload.
Upon receipt of the First Frame, the receiver will send a Flow Control frame to the sender. This frame will specify 3 bytes of flow control information - the first byte contains a flow status value - Continue To Send (CTS), Wait (WT), or Overflow (OVFLW). The latter condition is a fatal condition, and may only be sent in the first reply, and the former two conditions determine whether a sender will continue to originate frames with the payload. The second byte contains the number of consecutive frames that may be transmitted by the sender without a flow control reply, and the third byte specifies the minimum frame separation time.
Once a successful CTS flow control frame is received from the receiver, the sender will originate a number of Consecutive Frames, each containing a single byte sequence number, and 7 bytes of payload. These frames must be sent no faster than the minimum separation time specified in the Flow Control response.
Upon receipt of all the Consecutive Frames expected, the receiver will acknowledge transmission with a further Flow Control frame.
This process continues until the sender has originated the entire contents of the message.
Please note that there is no retry strategy within this network transport protocol.
General Format
Every frame includes the PCI Type, or Protocol Control Information data. This is the high nibble of first byte in every CAN frame for the transport protocol, and describes the frame type, as follows:
| PDU Type | PCI Type byte |
|---|---|
| Single Frame (SF) | 0 |
| First Frame (FF) | 1 |
| Consecutive Frame (CF) | 2 |
| Flow Control (FC) | 3 |
Single Frame
A single frame is used to convey a small payload via the transport protocol, in this instance, up to 7 bytes of application payload.
A single frame need not be acknowledged by the receiving node.
Frame Contents:
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | |
|---|---|---|---|---|---|---|---|---|
| Bits 7-4 | Bits 3-0 | |||||||
| PCI Type - 0 | Data Length | Application Payload | ||||||
Data Length
Data length refers to the length of the application payload within the single frame payload. This value must be <= 7. Please note that the CAN frame should still be padded to 8 bytes, even if the data length is insufficient to fill the frame.
Example Frame
Take, for example, an application frame of 5 bytes. This is the Single Frame packing of the data:
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 |
|---|---|---|---|---|---|---|---|
| 0x05 | 0xAA | 0x55 | 0xAA | 0x55 | 0xAA | 0x00 | 0x00 |
This frame has been padded with 0x00 to extend the frame to the full 8 bytes.
First Frames
A first frame is used to signify the start of transmission between two nodes on a CAN bus using the ISO15765 transport protocol.
The first frame includes the overall data length (up to 4095 bytes), and the first 6 bytes of application payload. On receipt of a first frame with a data length of more than 7, the receiving node must acknowledge the transmission with a flow control frame to start the transmission.
Frame Contents:
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | |
|---|---|---|---|---|---|---|---|---|
| Bits 7-4 | Bits 3-0 | |||||||
| PCI Type - 1 | Data Length | First 6 bytes of application Payload | ||||||
Data Length
Data length refers to the length of the application payload within the complete transmission. This is provided to allow receiving ECUs to allocate sufficient buffer space prior to the receipt of consecutive frames. This value must be >7, and <= 4095. A value of 7 or less indicates that a single frame should be used instead.
Example Frame
Take, for example, an application frame of 28 bytes. This is the First Frame for the packing of the data:
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 |
|---|---|---|---|---|---|---|---|
| 0x10 | 0x1C | 0x55 | 0xAA | 0x55 | 0xAA | 0x55 | 0xAA |
Flow Control frame
Flow control frames are the most complex frame in ISO15765, and as the name suggests, controls the rate at which the sender transmits consecutive frames. Flow control frames must be sent in response to a first frame, and will typically be sent in response to a number of consecutive frames. It is expected that an ECU will have timing information predetermined to control the data rate, including inter-frame spacing, and number of frames to be sent between flow control replies.
Frame Contents:
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | |
|---|---|---|---|---|---|---|---|---|
| Bits 7-4 | Bits 3-0 | |||||||
| PCI Type - 3 | Flow Status | Block Size | Minimum Separation Time | n/a | ||||
Flow Status
Flow status indicates the readiness of the receiving ECU to accept further consecutive frames. It can take the following states:
| State | Flow Status nibble | Description |
|---|---|---|
| Continue to Send (CTS) | 0 | The transmitting node may send further Consecutive Frames (CF). The number of frames, and inter-frame spacing is specified within the flow control frame. |
| Wait (WT) | 1 | The sender shall cease sending Consecutive Frames, and wait for a further flow control (FC) frame. |
| Overflow (OVFLW) | 2 | This status may only be sent in response to a First Frame, and signifies that the receiver has insufficient buffer space to receive the complete frame. The sender shall abort the transmission. |
Block Size
The block size defines the number of Consecutive Frames that may be sent between flow control frames. For example, if a FC CTS frame is sent in response to a First Frame, with a block size of 10, the sender may transmit 10 Consecutive Frames until it must wait for the recipient to send a further Flow Control frame.
The value 0x00 is special for block size - it indicates that the transmitting node may continue to send the entire application frame without waiting for a further Flow Control frame. The separation time, however, must be observed.
Minimum Separation Time
The minimum separation time specifies a value in units of milliseconds or microseconds that are to be used as an inter-frame spacing delay.
| PDU Type | PCI Type byte |
|---|---|
| 0x00 to 0x7F | 0 to 127 milliseconds |
| 0xF1 to 0xF9 | 100 to 900 µsec. |
All other values are reserved.