Introduction

As CAN protocol can take a maximum of 8 bytes per frame, this protocol used in the Transport layers the CAN stack disassembles the request from application layer of external tester (or the response from ECU) into 8 bytes each and feeds them into the lower layers for CAN communication.

List of protocol control information field types

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).

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.

Deep Dive

Let us take the example of two simple UDS diagnostics commands that is being communicated between an external tester and ECU over CAN line.

Command Set 1 (Read DTC Command):

• Tester to ECU: 19 02 AF
• ECU to Tester: 59 02 FF 06 15 00 AF 00 00 00 23 01 08 00 AF 21 76 00 AF 21 76 00 AF 09 16 00 AF 15 02 00 AF 21 22 00 AF 21 27 00 AF 15 06 00 AF 01 13 00 23 01 18 00 AF

See the traffic on CAN Bus for this request and response below:

We will now try to analyse this communication step by step. Flow of Request from Tester to ECU is illustrated below:

Flow of Response from ECU to Tester is illustrated below:

Application Layer:

If you observe, the request from the application layer of the tester starts with 1902FF (which is what is specified in UDS protocol standard – ISO 14229). Note that there is no bar on the length of the message you can push from this layer to the subsequent layer.

Transport Layer:

Here is where the ISO TP protocol ISO 15765 comes into picture (as we are using the CAN physical layer). As CAN protocol can take a maximum of 8 bytes per frame, this layer disassembles the request from application layer into 8 bytes each and feeds them into the lower layers for CAN communication. Read the ISO 15765 article for more details on how this layer operates.

Datalink Layer

Datalink layer adds CAN related headers and footers to this frame (coming from transport layer) and sends it to the physical layer for transmission on CAN lines

Command Set 2 (Write VIN):

• Tester to ECU: 2E F1 90 4D 44 32 4A 50 43 58 4C 36 4C 43 30 37 33 33 30 37
• ECU to Tester: 6E F1 90

See the traffic on CAN Bus for this request and response below:

We will now try to analyse this communication step by step. Flow of Request from Tester to ECU is illustrated below:

Flow of Response from ECU to Tester is illustrated below:

For more information about ISO CAN TP layer and to practically learn this topic, you are welcome to subscribe to our YouTube channel or book for a training session on Automotive Diagnostics.