Do you want to learn how to use DoIP, or Diagnostics over Internet Protocol, for remote diagnostics of vehicles and other complex systems? Do you want to know how DoIP works with UDS, or Unified Diagnostic Services, and Ethernet/IP? Do you want to see a typical communication sequence of DoIP with Vector CANoe? If you answered yes to any of these questions, then this DoIP Protocol Tutorial blog post is for you.
In this tutorial, we will cover the following topics:
Table of contents
- Introduction to DoIP Protocol
- DoIP Protocol In OSI Layer
- DoIP Protocol Message Frame Format
- Generic DoIP Header Message Structure
- DoIP Protocol Communication Sequence
- Example Of DoIP Request Message Frame Format
- Diagnostic Message Positive Acknowledgment Structure
- DoIP Protocol NACK Codes
- DoIP Protocol Logical Addressing
- How Does DoIP Works in between External Test Equipment & Vehicle
- Advantages of DoIP Protocol
- Disadvantages of DoIP Protocol
- Future Development and Enhancement of DoIP Protocol
- DoIP Protocol Related keywords Explained
Introduction to DoIP Protocol
The DoIP is extending for Diagnostic Over Internet Protocol. An upcoming trend in the automotive industry is to enable remote access to vehicles for a flexible interface between the diagnostic engineer and vehicle ECU. The vehicle diagnostic is getting done with a wired interface and also ECU flashing is taking a lot of time due to the low data rate.
Even if you want to do diagnose your vehicle and fix the issues but you are in a jungle or at night, so it is very difficult to get the diagnostic engineer and fix the issues. So to perform vehicle diagnostics over the air is very important nowadays. But you know till now mostly all the OEMs are using some low end diagnostic standardized protocols like KWP-2000, etc, but after the UDS protocol released that is now trending in the automotive industry.
The OEMs are using any kind of communication protocol, but they are implementing the UDS protocol for vehicle diagnostic. This is called DoCAN protocol. Like this whenever the Ethernet or Internet protocol (IP) used with UDS protocol this is called DoIP Protocol. There are obvious benefits in being able to diagnose a vehicle remotely that if a driver experiences a problem with the car can just pull over to the side and call the workshop, which may perform a diagnosis of the vehicle over the air.
What is DoIP and what are its benefits?
DoIP, or Diagnostics over Internet Protocol, is a communication protocol that enables remote diagnostics of automobiles and other complicated systems. As the Internet of Things (IoT) expands, more and more devices are connected to the internet, making remote diagnosis and repairs possible.
The DoIP protocol was essentially introduced to enable communication between external tester tools and electronics control units (ECUs). Today, DoIP is an important protocol in the automobile industry since it allows you to retrieve diagnostic information from your vehicle’s onboard computer system through the internet. This is especially beneficial when your car is on the road or in a remote area. Furthermore, you can use DoIP to quickly and easily detect problems with a vehicle’s engine, gearbox, brakes, and other vital components. You can then use this information to create a repair plan, purchase components, and carry out repairs without ever touching the vehicle.
While DoIP is most often employed in the automobile sector, it has the potential to be applied in a variety of other industries. It may, for example, be used to troubleshoot industrial machinery, medical equipment, or even household appliances.
Some of the main benefits of using DoIP are:
- Faster data transfer rates compared to traditional diagnostic protocols such as KWP 2000 or diagnostics on CAN.
- Higher bandwidth availability for large data volumes such as software updates or flash programming.
- Reduced wiring complexity and cost by using existing Ethernet infrastructure.
- Enhanced security features such as encryption and authentication.
- Scalability and flexibility for future extensions.
What is UDS and how does it relate to DoIP?
UDS, or Unified Diagnostic Services, is a protocol used by diagnostic systems to communicate with ECUs in vehicles. UDS combines standards such as KWP 2000 (ISO 14230) or diagnostics on CAN (ISO 15765) and is independent of vehicle manufacturers. UDS is nowadays one of the most properly used standards for diagnostic protocols.
DoIP Protocol In OSI Layer
- Part 1 – General information and use case definition.
- Part 2 – Transport protocol and network layer services.
- Assignment of IP address.
- Vehicle search.
- Link connection.
- Status information.
- Data routing to sub buses.
- Message types.
- Error handling.
- Part 3 – Wired vehicle interface based on IEEE 802.3.
- Part 4 – Ethernet-based high-speed data link connector.
- Part 5 – Conformance test specification.
DoIP Protocol in Combination with other Standards
The DoIP (Diagnostics over Internet Protocol) protocol is a standard for vehicle diagnostics that allows communication between diagnostic devices and electronic control units over Ethernet networks.
DoIP can be used in combination with other standards such as ISO 13400, ISO 22900 and ISO 27145 to enable interoperability, security and compatibility of diagnostic systems. DoIP offers several advantages over traditional protocols such as CAN or K-Line, such as higher bandwidth, lower latency, scalability and flexibility.

It also include the below standards listed below.
- OTX (Open Test sequence eXchange):
- ISO 13209
- DoIP extensions in preparation.
- MCD-3D API:
- ISO 22900-3.
- ASAM MCD-3D 3.0 required.
- D-PDU API:
- ISO 22900-2.
- DoIP specified as amendment.
- UDS (Unified Diagnostic Services)
- ISO 14229-5 for DoIP.
- WWH-OBD:
- ISO 27145 for DoIP and CAN.
DoIP Protocol in OSI Layer
The DoIP (Diagnostics over Internet Protocol) protocol is a standardized diagnostic communication protocol that allows vehicle diagnostics to be performed over Ethernet networks. The DoIP protocol is based on the OSI (Open Systems Interconnection) reference model, which defines seven layers of communication functions: physical, data link, network, transport, session, presentation and application.
The DoIP protocol uses TCP/IP as the transport layer and UDP/IP as the network layer. The DoIP protocol defines its own session layer and application layer protocols to enable diagnostic services such as vehicle identification, diagnostic data transfer and control functions.

DoIP Protocol Message Frame Format
The DoIP protocol message frame format consists of several components, including a header and a payload. Here’s a breakdown of the key elements in a DoIP message frame:

Generic DoIP Header Message Structure
The Generic Diagnostic over Internet Protocol (DoIP) header structure is used for communication between different modules in a vehicle’s network over IP-based Ethernet communication. The header is used to encapsulate diagnostic messages and provide information about the sender and receiver of the message.
The Generic DoIP header structure is made up of four main fields:
- Protocol Version: This field is used to indicate the version of the DoIP protocol being used. The current version is 0x02.
- Inverse Protocol Version: This 1-byte field contains the inverted value of the Protocol Version (0xFD for the current version).
- Payload Type: This 2-byte field indicates the type of payload contained in the message. There are several defined payload types for various diagnostic purposes, such as vehicle identification, diagnostic message transmission, and routing activation.
- Payload Length: This 4-byte field represents the length of the payload in bytes. It specifies how much data 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.
- Identifier: 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.
- Diagnostic Commad: User diagnostic data request.
Generic DoIP Header Synchronization Pattern
Item | Position | Length | Description | Values |
---|---|---|---|---|
Protocol Version | 0 | 1 | Identifies the protocol version of DoIP packets. | 0x00: reserved 0x01: DoIP ISO/DIS 13400-2:2010 0x02: DoIP ISO 13400-2:2012 0x03…0xFE: reserved by this part of ISO 13400 0xFF: default value for vehicle identification request messages |
Inverse protocol version | 1 | 1 | The value of the bit-wise inverse of the protocol version is included, which, in combination with the DoIP protocol version, serves as a verification pattern for the protocol. This pattern ensures that any received DoIP message is properly formatted. | Equals the XOR 0xFF (e.g. 0xFE for protocol version 0x01). |
Payload type (GH_ PT) | 2 | 2 | This section provides guidance on how to interpret the data that follows the generic DoIP header, such as gateway commands, diagnostic messages, and other types of information. | Check the DoIP Payload Types table for a complete list of currently specified payload type values. |
Payload length (GH_PL) | 4 | 4 | This section specifies the size of the DoIP message payload in bytes, which excludes the generic DoIP header bytes. The payload length may vary depending on the payload type, with some payloads requiring no additional parameters (payload length is 0), others having a fixed DoIP message length, and some allowing for dynamic length DoIP messages. | 0…4 294 967 295 bytes (= ) |
Payload type specific message content | 8 | … | The message content specific to the payload type begins at this point. It should be noted that, for instance, the byte position 0 in the payload type-specific section of the message corresponds to byte position 8 in the larger context of the DoIP message. | NA |
DoIP Protocol Payload Types
Payload Type Value | Payload Type Name | Support (DoIP gateways) | Support (DoIP nodes) | Port & protocol |
---|---|---|---|---|
0x0000 | Generic DoIP header negative acknowledge | Mandatory | Mandatory | UDP_DISCOVERY UDP_TEST_EQUIPMENT_REQUEST TCP_DATA |
0x0001 | Vehicle identification request message | Mandatory | Mandatory | UDP_DISCOVERY |
0x0002 | Vehicle identification request message with EID | Optional | Optional | UDP_DISCOVERY |
0x0003 | Vehicle identification request message with VIN | Mandatory | Mandatory | UDP_DISCOVERY |
0x0004 | Vehicle announcement message/vehicle identification response message | Mandatory | Mandatory | UDP_DISCOVERY UDP_TEST_EQUIPMENT_REQUEST |
0x0005 | Routing Activation Request | Mandatory | Mandatory | TCP_DATA |
0x0006 | Routing activation response | Mandatory | Mandatory | TCP_DATA |
0x0007 | Alive check request | Mandatory | Mandatory | TCP_DATA |
0x0008 | Alive check response | Mandatory | Mandatory | TCP_DATA |
0x0009 – 0x4000 | Reserved by this part of ISO 13400 | Reserved | Reserved | Reserved |
0x4001 | DoIP entity status request | Optional | Optional | UDP_DISCOVERY |
0x4002 | DoIP entity status response | Optional | Optional | UDP_TEST_EQUIPMENT_REQUEST |
0x4003 | Diagnostic power mode information request | Mandatory | Mandatory | UDP_DISCOVERY |
0x4004 | Diagnostic power mode information response | Mandatory | Mandatory | UDP_TEST_EQUIPMENT_REQUEST |
0x4005 – 0x8000 | Reserved by this part of ISO 13400 | Reserved | Reserved | Reserved |
0x8001 | Diagnostic message | Mandatory | Mandatory | TCP_DATA |
0x8002 | Diagnostic message positive acknowledgement | Mandatory | Mandatory | TCP_DATA |
0x8003 | Diagnostic message negative acknowledgement | Mandatory | Mandatory | TCP_DATA |
0x8004 – 0xEFFF | Reserved by this part of ISO 13400 | Reserved | Reserved | Reserved |
0xF000 – 0XFFFF | Reserved for manufacturer-specific use (OEM) | Optional | Optional | OEM Dependent Reserved |
Generic DoIP Header Negative Acknowledge Structure
Item | Position | Length | Description | Values |
---|---|---|---|---|
Generic DoIP header NACK code | 0 | 1 | The negative acknowledge code found in the generic header signifies either the particular error detected in the generic DoIP header, or an unsupported payload, or a memory overload condition. | 0x00 – 0xFF |
Generic DoIP header NACK codes
NACK Values | Description | Action |
---|---|---|
0x00 | Incorrect pattern format | Close socket |
0x01 | Unknown payload type | Discard DoIP message |
0x02 | Message too large | Discard DoIP message |
0x03 | Out of memory | Discard DoIP message |
0x04 | Invalid payload length | Close socket |
0x05 – 0xFF | Reserved by ISO 13400 | NA |
DoIP Protocol Communication Sequence

Generic DoIP Header Negative Acknowledge Structure
Item | Position | Length (Byte) | Description | Values |
---|---|---|---|---|
Generic DoIP header NACK code | 0 | 1 | The generic header negative acknowledge (NACK) code is used to specify the error detected in the generic DoIP header or to signal that the payload is not supported or that there is a memory overload issue | 0x00 – 0x04 |
DoIP Header Negative Acknowledge Values List
Value | Description | Required Action | Support |
---|---|---|---|
0x00 | Incorrect pattern format | Close socket | Mandatory |
0x01 | Unknown payload type | Discard DoIP message | Mandatory |
0x02 | Message too large | Discard DoIP message | Mandatory |
0x03 | Out of memory | Discard DoIP message | Mandatory |
0x04 | Invalid payload length | Close socket | Mandatory |
Example Of DoIP Request Message Frame Format
Protocol Version (B0) | Inverse Protocol Version (B1) | Payload Type (B2-B3) | Payload Length (HB4-LB7) | Source Address (HB8-LB9) | Target Address (HB10-LB11) | ReadDataByIdentifier request SID (B12) | Data Identifier (HB13) | Data Identifier (LB12) |
---|---|---|---|---|---|---|---|---|
0X01 | 0xFE | 0X8001 | 0X00000007 | 0x0E00 | 0xE000 | 0X22 | 0xF8 | 0x10 |
Diagnostic Message Positive Acknowledgment Structure
Source Address (B0-B1) | Target Address (B2-B3) | NACK Code (B4) | Previous Diag. Message Data (Optional) |
---|---|---|---|
0x0E00 | 0x0E80 | 0x02 | NA |
DoIP Protocol NACK Codes
NACK Value | Description | Support Type |
---|---|---|
0x00 – 0x01 | Reserved by this part of ISO 13400 | Reserved |
0x02 | Invalid source address | Mandatory |
0x03 | Unknown target address | Mandatory |
0x04 | Diagnostic message too large | Mandatory |
0x05 | Out of memory | Mandatory |
0x06 | Target unreachable | Optional |
0x07 | Unknown network | Optional |
0x08 | Transport protocol error | Optional |
0x09 – 0xFF | Reserved by this part of ISO 13400 | Reserved |
DoIP Protocol Logical Addressing
This section explains how the addresses used for diagnostic messages, called logical addresses, are structured and used.
- DoIP Physical Addressing: A physical logical address is a unique way to identify a diagnostic application layer entity in any DoIP entity or on any electronic control unit (ECU) connected to the vehicle’s network through DoIP gateways. The process of finding a vehicle allows the testing equipment to match physical logical addresses with IP addresses.
- DoIP Functional Addressing: Functional logical addresses are used to send messages to groups or all diagnostic application layer entities within a vehicle. To do this, the testing equipment may need to send multiple IP packets. There is no way to send messages to multiple DoIP entities with just one IP address. For a DoIP Gateway, receiving a functionally addressed diagnostic message means it has to send it as a multi- or broadcast on the connected vehicle sub-networks.
DoIP Protocol Logical Address Details
Address | Description |
---|---|
0x0000 | ISO/SAE reserved |
0x0001 – 0x0DFF | OEM specific |
0x0E00 – 0x0FFF | Reserved for addresses of external test equipment |
0x0E00 – 0x0E7F | External legislated diagnostics test equipment (e.g. for emissions test scan-tool use) |
0x0E80 – 0x0EFF | External vehicle-manufacturer-/aftermarket-enhanced diagnostics test equipment |
0x0F00 – 0x0F7F | Internal data collection/on-board diagnostic equipment (for vehicle-manufacturer use only) |
0x0F80 – 0x0FFF | External prolonged data collection equipment (vehicle data recorders and loggers, e.g. used by insurance companies or to collect vehicle fleet data) |
0x1000 – 0x7FFF | OEM specific |
0x8000 – 0xCFFF | ISO/SAE reserved |
0xD000 – 0xDFFF | Reserved for SAE Truck & Bus Control and Communication Committee |
0xE000 – 0xE3FF | ISO/SAE-reserved functional group addresses |
0xE000 | ISO 27145 WWH-OBD functional group address |
0xE001 – 0xE3FF | ISO/SAE reserved |
0xE400 – 0xEFFF | Vehicle-manufacturer-defined functional group logical addresses |
0xF000 – 0xFFFF | ISO/SAE reserved |
How Does DoIP Works in between External Test Equipment & Vehicle
To establish a connection between the external test equipment and the DoIP entity in the vehicle, the first step is to open a socket with TCP_DATA as the destination port. This socket must be opened before any message exchange can occur. The DoIP entity is responsible for providing the necessary resources to handle incoming communication requests, including socket resources. To support the specified number of concurrently active DoIP sessions plus one extra socket, the DoIP entity must provide sufficient resources.
According to DoIP-002, if more than the specified number of connection attempts arrive simultaneously, the DoIP entity may run out of resources, and the connection attempt beyond the specified number plus one will be refused. This refusal occurs because there are no longer any sockets in the listening state, not because of DoIP protocol handling.

After establishing a socket, several initialization steps must be completed. Firstly, both an initial inactivity timer and a general inactivity timer must be assigned and activated. Additionally, to prevent arriving data from being routed or processed, except for the routing activation request message, the connection state must be set to “initialize”. All further messages should be exchanged via this TCP_DATA socket.
To enable routing on the initialized connection, the external test equipment must send a routing activation request message to the DoIP entity. If the external test equipment is eligible and there are less than active connections registered, the corresponding initial timer is halted, and the socket state changes to “registered [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 external test equipment. The general inactivity timer is then restarted and remains active.
Upon receiving any form of data, the DoIP entity initially invokes the DoIP header handler. If the payload contains a diagnostic message (recognized by the payload type 0x8001 in the generic DoIP header, as explainede above), the diagnostic message handler is invoked to process the payload.
Upon the arrival of a diagnostic message, the DoIP entity must promptly send the DoIP confirmation to the external test equipment that initiated the message. The confirmation acknowledgement is sent after the message has successfully passed through the diagnostic message handler and the corresponding internal routing mechanism (assuming the DoIP entity functions as a DoIP gateway), although it may not yet have been sent to the intended ECU destination.
If a UDS-compliant diagnostic message payload is received, the destination ECU transmits a diagnostic response to the external test equipment. This behavior is defined by the relevant diagnostic protocol encapsulated in the DoIP message and therefore falls outside the scope of this section of ISO 13400.
You ca go through the DoIP Protocol Timing And Communication Parameters article to understand the timing related topics of DoIP Protocol.
Advantages of DoIP Protocol
The advantages of the DoIP (Diagnostics over Internet Protocol) protocol include:
- Enhanced Diagnostic Capabilities: DoIP enables faster and more efficient diagnostics by allowing multiple diagnostic testers to access and diagnose the same vehicle simultaneously. It also supports a wider range of diagnostic functions than traditional diagnostic protocols.
- Improved Efficiency: DoIP is designed to be used over Ethernet networks, which offer higher bandwidth and faster data transfer rates than traditional diagnostic protocols. This allows for faster and more efficient communication between diagnostic testers and vehicles.
- Increased Security: DoIP includes robust security features, including authentication and encryption, to protect against unauthorized access and data theft.
- Reduced Costs: DoIP allows for the use of standard Ethernet hardware and cabling, which is widely available and relatively inexpensive. This reduces the cost of implementing DoIP in vehicles and diagnostic tools.
- Future-Proofing: DoIP is a modern protocol designed to meet the demands of the automotive industry in the years to come. It is expected to become the standard protocol for vehicle diagnostics and is being adopted by more and more automakers and diagnostic tool manufacturers.
- Reduced Time: Time-saving at ECU Flash Programming.
- Integration with other Standards: Integrated with other standards for vehicle diagnosis and analysis.
Disadvantages of DoIP Protocol
While the DoIP (Diagnostics over Internet Protocol) protocol has many advantages, there are also some potential disadvantages, including:
- Compatibility: DoIP requires Ethernet hardware and cabling, which may not be compatible with all existing diagnostic tools and vehicles. This could make it difficult or costly to upgrade to DoIP.
- Complexity: DoIP is a complex protocol that requires a higher level of technical expertise than traditional diagnostic protocols. This could make it more difficult for smaller diagnostic tool manufacturers to implement DoIP in their products.
- Security Risks: While DoIP includes robust security features, any network-connected system is vulnerable to cyber attacks. As the automotive industry becomes increasingly connected, the risk of cyber attacks on vehicles and diagnostic tools will continue to increase.
- Network Performance: DoIP relies on Ethernet networks, which may not provide consistent performance in all environments. This could result in slower or less reliable communication between diagnostic testers and vehicles.
- Cost: Implementing DoIP in vehicles and diagnostic tools may require significant investment in new hardware and software. This could be a barrier to adoption for some automakers and diagnostic tool manufacturers.
Future Development and Enhancement of DoIP Protocol
The future development and enhancement of the DoIP (Diagnostics over Internet Protocol) protocol will likely focus on addressing some of the potential disadvantages and improving its capabilities. Some possible areas of development include:
- Interoperability: Future versions of DoIP may focus on improving compatibility with existing diagnostic tools and vehicles. This could include support for legacy diagnostic protocols or new features to help bridge the gap between older and newer systems.
- Security: As the automotive industry becomes more connected, the need for robust security features will only increase. Future versions of DoIP may include even stronger authentication and encryption mechanisms to protect against cyber attacks.
- Performance: While Ethernet networks offer higher bandwidth and faster data transfer rates than traditional diagnostic protocols, they may not provide consistent performance in all environments. Future versions of DoIP may include optimizations to improve network performance and reduce latency.
- Flexibility: DoIP is currently used primarily for vehicle diagnostics, but future versions of the protocol could be designed to support other use cases, such as firmware updates, remote monitoring, or predictive maintenance.
- Standardization: The adoption of DoIP as a standard protocol for vehicle diagnostics is still ongoing, and future development will likely focus on standardizing the protocol and ensuring interoperability between different implementations. This will help to promote wider adoption and facilitate the development of new diagnostic tools and services.
DoIP Protocol Related keywords Explained
- DoIP Protocol PDF: You can send us a mail to get the PDF version of our tutorial of DoIP Protocol Tutorial after adding a comment below.
- DoIP Protocol PPT: You can send us a mail to get the PPT of our tutorial of DoIP Protocol Tutorial after adding a comment below.