Relationship between UDS (ISO 14229–1) and ISO-TP (ISO 15765–2)
In this blog, I will try to explain the two common protocols(UDS and ISO-TP aka CAN-TP) that are commonly used in the Automotive Industry. Before we dive into the relationship between the two protocols, we have to understand the purposes and concepts of these protocols.
Understanding UDS (Unified Diagnostic Services (ISO 14229–1)
Unified Diagnostic Services (UDS) is a diagnostic communication protocol that runs at the application layer of the OSI layer and is used in the automotive industry. The UDS hosts multiple services whose purpose is diagnostics, software updates, and authentication. I won’t explain all these services in this blog to stay on topic, I plan to cover UDS services comprehensively in another article.
In short, UDS is a diagnostic protocol with a request-response cycle between the tester tool(client) and the ECU(server). UDS enables communication between a vehicle’s electronic control units (ECUs) and a diagnostic tool, allowing for the diagnosis and troubleshooting of vehicle issues. In addition to that, we can use UDS protocol for software updates with Transfer Data(0x36) or we can authenticate our communication with Authentication service (0x29).
What is the ISO 15765–2? Why we should use it?
The ISO 15765–2 a.k.a. ISO-TP or CAN-TP or DoCAN whatever you want to call is a protocol that contains both Transport Protocol(Layer 4) and Network protocol(Layer 3) of OSI Layers. The main purpose of ISO-TP is to send messages that do not fit in an 8-byte CAN frame. In doing so, it divides large messages into parts and transfers them to the receiver. While doing this it allows the send up to 4096 bytes via the CAN-bus. When we compare it with the UDS it's primitive(I mean it just covers sending larger messages than 8 bytes) as expected Because it is usual that the level of complexity decreases as you go down the OSI layers.
If you decide to UDS in your architecture, you will have to use CAN-TP protocol for handling a UDS frame that has a larger size of 8 bytes. Let's suppose that you’re gonna use an Authentication service that contains a public key, proof of ownership, and challenge. Then you decide a 256-bit public key or challenge size for your authentication process. At this point, CAN-TP usage becoming mandatory for transmitting these values.
The most common scenario to use CAN-TP probably would be in the Transfer Data(0x37) Service. Let’s think about you having the latest version of ECU software and you have to update the software with this service. I assume that the software doesn’t fit a single can frame which is highly expected. Therefore CAN-TP protocol will split this large software data into small chunks and transmit it to the server side one by one.
Now, I will explain all these things on the real CAN log but before this, we have to knowledge about CAN-TP frame types.
Frame types in the ISO 15765–2
ISO-TP uses a sequence of frame types to perform the communication. There are Single Frame and Multiple Frames. In addition to that Multiple Frame also has 3 different frame types which are
First Frame (0x1)
Consecutive Frame (0x2)
Flow Control Frame (0x3)
I will explain each type in detail in the following section
Single Frame (0x00)
In ISO 15765–2, a Single frame is a frame type used to send messages that fit in a single CAN frame. If my message is smaller than 7 bytes, it can be sent in a lump with a Single Frame. Maybe you’re wondering why we can send 7 bytes and not 8 bytes. There is a simple explanation of it. ISO 15765–2 allocates 1 byte of space in Single Frame for PCI (Procotol Control Informatıon) space. As all we know a CAN frame is up to 8 bytes and if we separate 1 byte for PCI it will be 7 bytes remaining for the Data field.
1 byte PCI also has two fields. Most Significant 4-bit use for incidate addressing in this case is 0x00, which tells that this is a Single Frame. The least Significant 4-bit tells the data length of the payload. The rest of the diagnostic data field contains original data. For instance, if you using UDS it will probably Service hex value, subfunction, and parameters belonging to the used service will be located in the data field.
Multiple Frames
First Frame
The “First frame” is the literal first frame of the multiple frame communication. The first frame contains the length of the full packet, along with the initial data.
As you see in the above image First four bit of First Frame indicate the type of the frame which is “1”. So that means our CAN frame will start with the “1". Then the next 12 bit give information about the entire message. Like in the Single Frame Original Data contains Service ID, Subfunction and parameters If you’re using UDS.
After First Frame is sent from the client or server-side then the other side must respond to it with the Flow Control Frame. Let's suppose we send the First Frame from the client side then the Server must respond to it with Flow Control.
Flow Control Frame
The Flow Control frame is another type of frame in CAN-TP. This message type facilitates the coordination of data exchange between the server and the client, providing crucial details such as the number of consecutive frames for transmission before requiring the receiver to send an acknowledgment message. Also, Flow Control frames help prevent data overload by allowing the receiver to indicate to the transmitter how much data it can receive and process at a given time. This prevents situations where the transmitter inundates the receiver with more data than it can handle, avoiding potential data loss or system instability.
The first 4 bits of the frame tell that it is a Flow Control frame. The next four bit gives information about Flow Status. We have three types Flow status. These are;
Flow Status 0 “Clear to send”: When the client side saw the status bit it will start or keep sending consecutive frames.
Flow Status 1 “Wait”: When the client side saw the status bit it stops the sending consecutive frames.
Flow Status 2 “Overflow”: When the status “2” set in flow control frame it indicate that there is a memory problem in ECU side. At this point the software process might be restart at the beggining.
The second byte of the Flow Control message contains the Block Size. The Block Size refers to the parameter indicating the number of consecutive data frames that can be sent by the transmitter before it expects an acknowledgment from the receiver. According to this value, the sender side specifies the number of Consecutive Frames to send at one time.
The third byte of the Flow Control message gives information about Separation Time to the client. The Separation Time parameter represents the minimum time interval that must elapse between the consecutive frames sent by the transmitter. Let’s suppose that Separation Time has a 0x14 hex value which is 20 in decimal client sends the consecutive frame each 20ms.
Consecutive Frame
When the transmitter gets the Flow Control message it is ready to send consecutive frames. Each Consecutive Frame message encapsulates a portion of the data and is equipped with a sequence number, pinpointing its position within the overarching data block.
In Consecutive Frame first 4 bit indicate the type of frame which is 0x02 means that this is a Consecutive Frame. The last 4 bit gives information about “Sequence Number”. The “Sequence Number“ as befits the name it gives number to the frames. This allows the ECU to understand the order in which the messages arrive and take action on its side accordingly.
In the above image, you can see the “Sequence Number” in the red box.
Visual Communication Schema
Real CAN Log
In this CAN log shows us communication with ECU through UDS. Which is in our scenario “18FECA0B” is our tester tool can id and the other one “18FEBE09” is the ECU can id.
Firstly, communication starts with a Diagnostic Session Control Service(0x10)Programming Session (0x02) subfunction. Then ECU respond it with a Positive Response message. After that Routine Control(0x31) Service called by the Tester tool. All these messages respond with PRC. Then tester calls the Request download service for updating software on ECU. After that Transfer Data(0x36) Service is called by the tester tool. Since the software size is too large to fit in a single frame, the tester tool uses the first frame to share the necessary information with the ECU. Then ECU responds to it with the Flow Control Frame. After the tester tool gets the Flow control, it sends Consecutive Frames in sequence.
Sources
1- ISO 15765–2–2016
2-ISO 14229–1 Application Layer
