DoIP, or Diagnostics Over Internet Protocol, is a communication protocol used in the automotive industry for diagnostics and remote vehicle servicing. It facilitates communication between a vehicle's electronic control units (ECUs) and diagnostic instruments or remote service apps via IP networks. An equivalent of DoCAN over CAN bus, DoIP enables diagnostic protocols used in vehicles, such as the UDS on the Ethernet bus.
Further sections will cover the internals of the ISO13400 protocol, OSI-layer mapping of the automotive DoIP protocol and various important payloads associated with it.
Being a very large collection of dependent and closely connected systems, diagnosing a vehicle when there are issues and performing fine-tuning is a complex task. To overcome this, OEMs have supported various diagnostic techniques and Unified Diagnostic Services (UDS) protocol is one such mechanism to help analyze each of the ECUs present. While the conventional approach is using CAN interface with DoCAN(ISO 15765) running on top of it, modern vehicles employ faster communication over Automotive Ethernet.
The solution to support UDS on Ethernet is the Diagnostics Over Internet Protocol i.e., DoIP protocol. Standardized as ISO 13400, this protocol offers those same capabilities that DoCAN offers over CAN interface. Combined with the advantages of Automotive Ethernet and industry standard TCP/IP protocols, UDS over automotive DoIP protocol offers better throughput and faster response.
ISO13400 aka DoIP has faster data transfer rates than prior diagnostic methods. resulting in shorter diagnostic and servicing times. With support of TCU and Gateways, it enables remote diagnostics, which allows automotive experts and service providers to diagnose and troubleshoot vehicle issues without requiring physical access to the vehicle with minimal modification in the vehicle network. This can result in cost savings and improved efficiency.
Without the inherent limitation of underlying physical layer (like 8-byte limit for CAN), there is no need to send large amounts of data (greater than 8 bytes) in segmented packets like DoCAN protocol. DoIP can transfer huge data packets in a single network cycle. With ISO (International Organisation for Standardization) standardizing DoIP as ISO13400 protocol, it ensures interoperability between various vehicle manufacturers and diagnostic equipment providers, making the protocol easier to apply across the industry.
DoIP has precautions in place to prevent unauthorized access and data breaches. When doing remote diagnostics and servicing, this is crucial for ensuring the confidentiality and privacy of vehicle data. This is achieved with the help of secure TLS connections and can communicate securely across a wide range of IP networks, including Ethernet, Wi-Fi, and cellular networks.
On the vehicle side, DoIP enables the efficient management and retrieval of several parameters and data within the ECUs, making it easier to monitor the vehicle's health and performance.
Understanding the ISO 13400 or automotive DoIP Protocol requires an understanding of its place in the OSI (Open Systems Interconnection) layer model. The OSI model is a theoretical framework that describes how various network protocols interact and communicate with one another.
TCP/UDP is used as the transport layer in the automotive DoIP protocol, and IP is used as the network layer. DoIP encapsulates standard UDS messages in TCP/IP packets, allowing them to be transmitted over Ethernet or WLAN. This means that DoIP is utilized as the Transport Layer provides mechanisms for segmentation, reassembly, and flow management of diagnostic messages, effectively permitting the delivery of packets up to 4294967295 bytes in size. These layers oversee ensuring that data is sent between two endpoints in a reliable and error-free manner.
The UDS protocol running on top of automotive DoIP, has its own session layer and application layer protocols to support diagnostic services such as vehicle identification, diagnostic data transfer, and control functions.
The generic Diagnostics over Internet Protocol (DoIP) header structure is used for IP-based Ethernet communication between multiple modules in a vehicle's network. The header is used to encapsulate diagnostic messages and to offer information about the message's sender and receiver.
The automotive DoIP protocol header structure consists of four primary fields:
Protocol Version:This parameter is used to specify the DoIP protocol version that is being used. such as 0x01,0x02,0x03 with 0x03 being the latest at the time of writing.
Inverse Protocol Version:This 1-byte field carries the bit inverted value of Protocol Version.
Payload Type:This 2-byte parameter specifies the type of payload in the message. There are multiple defined payload types. such as vehicle identification, diagnostic message delivery, and route activation.
Payload Length:This 4-byte parameter represents the payload's length in bytes. It specifies the number of data that follows the header section.
DoIP Payload:The payload contains the actual data to be transmitted, such as diagnostic messages or control signals. The structure of the payload depends on the Payload Type specified in the header.
This field is used to identify the sender and receiver of the message. It contains two subfields: Source Address and Target Address. The Source Address identifies the module that sent the message, while the Target Address identifies the intended recipient of the message.
User diagnostic data request.
Diagnostics over Internet Protocol specification defines some of the ports both on UDP and TCP for operation. The details of the same are captured below.
| Name | Port Number | Description |
|---|---|---|
| UDP_DISCOVERY | 13400 | The UDP port on which the server listens to for incoming requests and commands. Also optionally utilized as source port for broadcast packets. |
| UDP_TEST_EQUIPMENT_REQUEST | Dynamically assigned | UDP Port from which the client transmits messages. Also, can be used as destination port for response |
| TCP_DATA | 13400 - Unsecured 3496 - Secured (TLS) | TCP Port at which the server listens for incoming connection requests. |
Some of the primary payloads defined by the DoIP protocol are captured in the below table.
| Payload Type Value | Payload Type Name | Port & protocol | Description |
|---|---|---|---|
| 0x0000 | Generic DoIP header negative acknowledge | UDP_DISCOVERY UDP_TEST_EQUIPMENT_REQUEST TCP_DATA |
Send by server to indicate error conditions. |
| 0x0001 | Vehicle identification request message | UDP_DISCOVERY | Vehicle identity request sent by client to get vehicle details like VIN ,GID, EID, logical address. |
| 0x0002 | Vehicle identification request message with EID | UDP_DISCOVERY | Vehicle identity request with already known EID. |
| 0x0003 | Vehicle identification request message with VIN | UDP_DISCOVERY | Vehicle identity request with already known VIN. |
| 0x0004 | Vehicle announcement message/vehicle identification response message | UDP_DISCOVERY UDP_TEST_EQUIPMENT_REQUEST |
Vehicle identity response with details like VIN , GID, EID, Logical address. |
| 0x0005 | Routing Activation Request | TCP_DATA | Routing activation request sent by client with client source address. |
| 0x0006 | Routing activation response | TCP_DATA | Routing activation response sent after the client source address is configured. |
| 0x0007 | Alive check request | TCP_DATA | Request sent by the server to check whether the client is connected or not. |
| 0x0008 | Alive check response | TCP_DATA | Response sent by the client if it is connected with server |
| 0x4001 | DoIP entity status request | UDP_DISCOVERY | Request sent by client to know about entity status |
| 0x4002 | DoIP entity status response | UDP_TEST_EQUIPMENT_REQUEST | Response sent by server about entity status |
| 0x4003 | Diagnostic power mode information request | UDP_DISCOVERY | Request sent by client whether the server is ready for diagnostic process |
| 0x4004 | Diagnostic power mode information response | UDP_TEST_EQUIPMENT_REQUEST | Server sends its status whether it is ready or not as response |
| 0x8001 | Diagnostic message | TCP_DATA | Send and receive UDS messages via diagnostic message payload type |
| 0x8002 | Diagnostic message positive acknowledgement | TCP_DATA | Positive response to diagnostic request message |
| 0x8003 | Diagnostic message negative acknowledgement | TCP_DATA | Negative response to diagnostic request message |
The UDS protocol implementation requires careful consideration of various design aspects to ensure optimal performance and compatibility. Some key design considerations include:
The initial step in connecting the user test equipment to the DoIP entity in the vehicle is to open a UDP socket with the destination port (13400). Then the client sends the vehicle identity request to the server DoIP and gets the vehicle identification response.
After this, the client opens a connection over TCP_DATA port and all further messages should be exchanged via this TCP socket. To enable routing on the initialized connection, the user test equipment must send a routing activation request message to the DoIP server. If the user test equipment is eligible and there are less than active connections registered, and the socket state changes to Registered and Routing active assuming no additional authentication or confirmation is necessary. At this point, valid DoIP messages such as DoIP diagnostic messages can be routed or processed. A positive routing activation response message confirms this to the user test equipment.
The DoIP entity initially executes the DoIP header handler when receiving any type of data. If the payload contains a diagnostic message (identified by the payload type 0x8001 in the generic DoIP header), the diagnostic message handler is called to process the payload.
In the sequence diagram, Read the data request 22h UDS service is sent by the client DoIP. When a diagnostic message from a client DoIP arrives, the DoIP server, to acknowledge recepit, must immediately deliver the DoIP confirmation to the user test equipment. The message is simultaneously handled by the diagnostic message handler, which parses the received request and filters the required data for the UDS request, based on the service ID and identification. And then forwards it to the UDS protocol handler. Once the diagnostic response if formed, the ECU transmits the diagnostic response of this Read data request 22h to the user test equipment.
With looming cyber-security threats, it is essential to protect vehicle systems from unauthorized access and ensure the safety and integrity of diagnostic operations. The DoIP provides the same on both the network later level and UDS (Unified Diagnostic Services) application level.
Security in network layerDiagnostic communication using Transport Layer Security (TLS) allows to establish an authenticated (ensures authenticity and integrity) and encrypted (confidentiality protection) communication channel between the client DoIP and the server DoIP.
This secure diagnostic communication leverages the widely used TLS protocol for the transport channel between client DoIP and a server DoIP.
Before the client DoIP and the server DoIP begin exchanging DoIP messages over TLS, first the secured TCP connection is negotiated within the TLS handshake: the client DoIP and the server DoIP agree on the version of the TLS protocol, choose the common cipher suite, verify certificates, and complete the TLS session key exchange. After a successful handshake between the client DoIP and the server DoIP, the diagnostic communication can start on the secured environment.
Verify the identities of the diagnostic tool and the vehicle's Electronic Control Units (ECUs) before allowing access to diagnostic services. This is typically achieved through secure authentication mechanisms, such as certificates, keys, or other cryptographic methods. In the UDS protocol, there are two services to check the diagnostic tool identities.
Authentication is a more advanced means of authentication and authorization of a diagnostic tester to an ECU. An authentication service allows the client to authenticate its identity, allowing it to access data and/or diagnostic services which have restricted access for, for example security, emissions, or safety reasons.
The Security Access service enables the customer to unlock restricted-access functions and services. Key and Seed The traditional means of gaining secure access to a diagnostic tester for an ECU.
Based on the industry standard Ethernet and TCP/IP protocols, it is quite advantageous to bring in the support of UDS over automotive DoIP protocol. Due to the much greater bandwidth in comparison to CAN, Diagnostics over Internet Protocol makes it possible to handle large amounts of data which is particularly beneficial in applications with flash programming. With added security layer, the data between the participating parties is also secure and confidential.
Overall, the DoIP protocol is a critical component in the automotive industry, enabling efficient and secure communication between diagnostic tools and a vehicle's electronic systems. It plays a pivotal role in improving vehicle diagnostics, maintenance, and overall vehicle health, as well as enhancing the user experience with modern connected vehicle services.
Embien has developed its own RAPIDSEA ISO13400 DoIP stack that allows developers and OEMs to quickly integrate the UDS stack on to Linux, Android, Windows and MCU based bare metal environments. Available for both client and server functionalities, our ISO13400 protocol stack makes it is possible to enable UDS over Automotive on both the Tester and ECU sides respectively.
Electrical/electronic architecture, also known as EE architecture, is the intricate system that manages the flow of electrical and electronic signals within a vehicle.
