The automotive DoIP protocol, 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, the DoIP protocol enables diagnostic protocols used in vehicles — such as 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. Compliance aspects of deploying the automotive DoIP protocol are covered under our product regulatory compliance services.
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 automotive DoIP protocol offers the 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.
The automotive DoIP protocol 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 results in cost savings and improved efficiency.
Without the inherent limitation of the underlying physical layer (like the 8-byte limit for CAN), there is no need to send large amounts of data in segmented packets like DoCAN protocol. The DoIP protocol can transfer huge data packets in a single network cycle. With ISO standardizing the diagnostics over internet protocol as ISO13400, it ensures interoperability between various vehicle manufacturers and diagnostic equipment providers, making the protocol easier to apply across the industry.
The DoIP protocol 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, the automotive DoIP protocol 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 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 the DoIP protocol is utilized as the Transport Layer and provides mechanisms for segmentation, reassembly, and flow management of diagnostic messages, effectively permitting the delivery of packets up to 4,294,967,295 bytes in size. These layers ensure that data is sent between two endpoints in a reliable and error-free manner.
The UDS protocol running on top of the automotive DoIP protocol 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 DoIP protocol 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 specifies the DoIP protocol version being used, such as 0x01, 0x02, 0x03, with 0x03 being the latest at time of writing.
Inverse Protocol Version:This 1-byte field carries the bit-inverted value of the Protocol Version.
Payload Type:This 2-byte parameter specifies the type of payload in the message, including vehicle identification, diagnostic message delivery, and route activation.
Payload Length:This 4-byte parameter represents the payload's length in bytes, specifying the number of data bytes that follow 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 identifies 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.
User diagnostic data request.
The diagnostics over internet protocol specification defines specific ports for both UDP and TCP operations. The details are captured below:
| Name | Port Number | Description |
|---|---|---|
| UDP_DISCOVERY | 13400 | The UDP port on which the server listens for incoming requests. Also optionally used as source port for broadcast packets. |
| UDP_TEST_EQUIPMENT_REQUEST | Dynamically assigned | UDP port from which the client transmits messages. Also used as destination port for responses. |
| 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 / TCP_DATA | Sent 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. |
| 0x0004 | Vehicle announcement / identification response | UDP_DISCOVERY | 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. |
| 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 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 the maximum active connections registered, 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 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, a Read Data request (0x22 UDS service) is sent by the client DoIP. When a diagnostic message from a client DoIP arrives, the DoIP server 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, then forwards it to the UDS protocol handler. Once the diagnostic response is formed, the ECU transmits the diagnostic response 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 protocol provides protection at both the network layer level and the UDS (Unified Diagnostic Services) application level.
Security in network layerDiagnostic communication using Transport Layer Security (TLS) allows establishing 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 server DoIP.
Before the client DoIP and the server DoIP begin exchanging DoIP messages over TLS, the secured TCP connection is first negotiated within the TLS handshake: the client DoIP and the server DoIP agree on the TLS protocol version, choose the common cipher suite, verify certificates, and complete the TLS session key exchange. After a successful handshake, 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 security, emissions, or safety reasons.
The Security Access service enables the customer to unlock restricted-access functions and services. Key and Seed is the traditional means of gaining secure access to a diagnostic tester for an ECU.
An ISO13400 DoIP stack implements both the network and application layer logic of the automotive DoIP protocol — from UDP discovery through TLS-secured TCP data exchange to UDS message routing. A production-ready ISO13400 DoIP stack must handle concurrent client connections, timing supervision, VIN/GID-based vehicle identification, and graceful error recovery. Embien has developed its own RAPIDSEA ISO13400 DoIP stack, available for both client and server functionalities, enabling OEMs to deploy UDS over Ethernet on tester and ECU sides respectively.
Adopting the ISO13400 protocol in a vehicle platform requires verification against the standard's conformance test suites. ISO13400 protocol compliance covers header integrity checks, payload type validation, timing conformance, and TLS configuration. Teams looking to achieve ISO13400 protocol certification can leverage Embien's digital transformation services to accelerate integration and validation across their vehicle ECU network.
Based on the industry-standard Ethernet and TCP/IP protocols, it is quite advantageous to bring UDS support over the 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 — particularly beneficial in flash programming applications. With an added security layer, 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 onto Linux, Android, Windows, and MCU-based bare-metal environments. Available for both client and server functionalities, our ISO13400 protocol stack makes it possible to enable UDS over Automotive Ethernet on both the Tester and ECU sides respectively.
Embien's cross-domain embedded services include automotive DoIP protocol development, ISO13400 stack integration, and UDS over Ethernet deployment across vehicle domains.
Embien's embedded security services cover TLS-based ISO13400 automotive DoIP protocol protection, safeguarding diagnostics over internet protocol traffic in connected vehicles.
A real-world ISO13400 automotive DoIP protocol deployment enabling remote vehicle diagnostics and FOTA over Ethernet in an Android-based instrument cluster.