The ISO15765-2 standard defines a transport protocol for a CAN-based system that allows segmented periodic messages in UDS protocol. The data byte is more than 8 can not be sent by a single can frame. To send it over the can, it will be segmented into multiple frames nothing but the periodic messages in UDS protocol. The ISO transport protocol is on the fourth layer of the OSI layer model for PC to PC seamlessly data communication. The CAN-Bus can send a maximum of 8 bytes of user data per frame. The ISO TP defined a transmission method that allows us to send up to 4095 bytes via the CAN-bus periodically. For this, the messages to be sent are segmented and individual CAN frames divided which helps in the transmission of more than 8-bytes of data over CAN network.
The UDS protocol is a diagnostic protocol working like client-server communication to do the diagnostic fault of a vehicle. To do the communication or the data transfer between the Client and Server, it uses the periodic message.
- Unacknowledged Segmented Data Transfer (USDT)
- Unacknowledged Un-segmented Data Transfer (UUDT)
Mostly the UDS protocol having two types of SID (Service Identifier).
- SID with
the response. - SID without response.
Message segmentation in CAN
The primary objective of the transport protocol is to transfer the messages which cannot be transmitted as a single Protocol Data Unit due to their length in CAN network. Messages which contain more data that can be transmitted within a single PDU are segmented by means of the transport protocol and divided into multiple, separate PDUs or you can say different frames or data packets. This procedure can also be implemented on the data link layer. The segmentation of the message must then be administered in PDUs of the corresponding link protocol to send these periodic messages in UDS protocol.
I would like to request to go through my CAN_TP Tutorial for the understanding of different frame formats of CAN TP. After then please come to this session to understand how the real time periodic messages are sending by dividing the total data packets into multiple CAN data frames. It is nothing like only CAN protocol but all the communication protocols are used in vehicle networking communication purposes. Here we will take the CAN protocol for better understanding and also it is used in 80% of the vehicle in the current generation.
Let us discuss this data packet send as to how to send periodic messages. Suppose you have 100 bytes of data and you are going to transfer to an ECU available in the vehicle. So you will connect your computer on OBD-II port using the OBD-II hardware then open your diagnostic tool on the computer. After then select your file and transfer to that particular file onto that ECU. this process is very easy for a diagnostic engineer who doesn’t know how it really works inside a vehicle with client-server communication. But here we will discuss as an Embedded Automotive developer or tester how you have implemented or tested it for your project.
First, the Client will send the first frame since the data is more than 8-bytes to server nothing but the ECU. Then the server will send the flow control frame with all details as to how the client going to send the periodic messages periodically to the server.
First Frame: Client – Server
10 64 xx xx xx xx xx xx
In the above, the client is sending a CAN data frame where the first byte is defining as 0x10. The MSB 4-bit is 1 which defines it is the first frame and the LSB 4-bit plus next 1-byte is having a total 12-bit which defines the CAN TP data length. This value is 0x64 and in decimal, it is 100 bytes. So from there, the server understood that the client is going to send a total of 100 bytes of data. Next 6-bytes are xx means any data the client can send. So from here, we understood that the first 2-bytes of data are Protocol control information which is not the real data. The next 6-bytes are real data that the server needs it. Then after this data received by the server, it will calculate its own receiver buffer memory defined in its programs and as per this, it will make a decision that how and when the next 94 bytes (100 – 6) of data client is going to send. Then the server will send the flow control frame like below as:
Flow Control Frame: Server to Client
30 0A 14 xx xx xx xx xx
In the above frame, 4-MSB of the first byte is 3 means flow control frame and the next 4-LSB is flow status having 0 means clear to send. The clear to send means the server informs the client that the server is now free so that the client can start sending the periodic messages in UDS protocol frame format. The second byte is 0A is the block size nothing but the number of consecutive frames the client can send periodically. ten third byte is 0x14 is the minimum separation time nothing but the time delay in between the two consecutive frames to give some time to server to be ready to receive the next consecutive frame periodically seamlessly.
After the client received the flow control frame it will start sending the consecutive frames periodically as below:
Consecutive Frame: Clients – Server
20 xx xx xx xx xx xx xx
21 xx xx xx xx xx xx xx
22 xx xx xx xx xx xx xx
23 xx xx xx xx xx xx xx
24 xx xx xx xx xx xx xx
25 xx xx xx xx xx xx xx
26 xx xx xx xx xx xx xx
27 xx xx xx xx xx xx xx
28 xx xx xx xx xx xx xx
29 xx xx xx xx xx xx xx
In above the 10 consecutive frames sent to the server where the first 4-MSB defines the consecutive type and the second 4-LSB defines the index or the number of consecutive frames sending to the server. Since the server sent to the client for 10 periodic messages should be sent by the client periodically, the client sent it and after then it will wait for the next flow control frame from the server since the total 100 bytes need to be sent to the server. In the first frame, the client 6-bytes of data and in the next 10 consecutive frames having 7-bytes in each frame is 70 (10×7) plus the 6 bytes having a total 76 bytes. The remaining 24 (100-76) bytes will continue in the next phase. The total bytes of data transfer in a segment format is called periodic messages in UDS protocol
After the total 10 periodic messages received by the server, it will send the next flow control frame as below:
Flow Control Frame: Server to Client
30 00 14 xx xx xx xx xx
Then the client will receive this frame and after receiving it will understand that all the other bytes are already defined and in second byte it is 00 means now the client can send unlimited consecutive frames to server. So after receiving this frame the client again will start to send the consecutive frames like as below:
Consecutive Frame: Client to Server
20 xx xx xx xx xx xx xx
21 xx xx xx xx xx xx xx
22 xx xx xx xx xx xx xx
23 xx xx xx 00 00 00 00
In above after sending of 24 bytes, the client stops the periodic message send. After then the client-server communication will end. Like this, the UDS protocol uses the periodical message send to the server for multi-byte message communication.
