DoIP protocol Message Frame Format

DoIP Protocol

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:

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

  1. Part 1 – General information and use case definition.
  2. 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.
  3. Part 3 – Wired vehicle interface based on IEEE 802.3.
  4. Part 4 – Ethernet-based high-speed data link connector.
  5. 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.

DoIP Protocol with Other Standards

It also include the below standards listed below.

  1. OTX (Open Test sequence eXchange):
    • ISO 13209
    • DoIP extensions in preparation.
  2. MCD-3D API:
    • ISO 22900-3.
    • ASAM MCD-3D 3.0 required.
  3. D-PDU API:
    • ISO 22900-2.
    • DoIP specified as amendment.
  4. UDS (Unified Diagnostic Services)
    • ISO 14229-5 for DoIP.
  5. 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 Implementation Design in ISO Layer

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:

DoIP protocol Message Frame Format

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:

  1. Protocol Version: This field is used to indicate the version of the DoIP protocol being used. The current version is 0x02.
  2. Inverse Protocol Version: This 1-byte field contains the inverted value of the Protocol Version (0xFD for the current version).
  3. 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.
  4. Payload Length: This 4-byte field represents the length of the payload in bytes. It specifies how much data follows the header section.
  5. 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

ItemPositionLengthDescriptionValues
Protocol
Version
01Identifies 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
11The 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)22This 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)44This 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 content8The 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 Header Synchronization Pattern

DoIP Protocol Payload Types

Payload Type ValuePayload Type NameSupport (DoIP gateways)Support (DoIP nodes)Port &
protocol
0x0000Generic DoIP header negative acknowledgeMandatoryMandatoryUDP_DISCOVERY
UDP_TEST_EQUIPMENT_REQUEST
TCP_DATA
0x0001Vehicle identification request messageMandatoryMandatoryUDP_DISCOVERY
0x0002Vehicle identification request message with EIDOptionalOptionalUDP_DISCOVERY
0x0003Vehicle identification request message with VINMandatoryMandatoryUDP_DISCOVERY
0x0004Vehicle announcement message/vehicle identification response messageMandatoryMandatoryUDP_DISCOVERY
UDP_TEST_EQUIPMENT_REQUEST
0x0005Routing Activation RequestMandatoryMandatoryTCP_DATA
0x0006Routing activation responseMandatoryMandatoryTCP_DATA
0x0007Alive check requestMandatoryMandatoryTCP_DATA
0x0008Alive check responseMandatoryMandatoryTCP_DATA
0x0009 – 0x4000Reserved by this part of ISO 13400Reserved Reserved Reserved
0x4001DoIP entity status requestOptionalOptionalUDP_DISCOVERY
0x4002DoIP entity status responseOptionalOptionalUDP_TEST_EQUIPMENT_REQUEST
0x4003Diagnostic power mode information requestMandatoryMandatoryUDP_DISCOVERY
0x4004Diagnostic power mode information responseMandatoryMandatoryUDP_TEST_EQUIPMENT_REQUEST
0x4005 – 0x8000Reserved by this part of ISO 13400Reserved ReservedReserved
0x8001Diagnostic messageMandatoryMandatoryTCP_DATA
0x8002Diagnostic message positive acknowledgementMandatoryMandatoryTCP_DATA
0x8003Diagnostic message negative acknowledgementMandatoryMandatoryTCP_DATA
0x8004 – 0xEFFFReserved by this part of ISO 13400Reserved Reserved Reserved
0xF000 – 0XFFFFReserved for manufacturer-specific use (OEM)OptionalOptionalOEM Dependent Reserved
DoIP Protocol Payload Types

Generic DoIP Header Negative Acknowledge Structure

ItemPositionLengthDescriptionValues
Generic DoIP header NACK code01The 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 Negative Acknowledge Structure

Generic DoIP header NACK codes

NACK
Values
DescriptionAction
0x00Incorrect pattern formatClose socket
0x01Unknown payload typeDiscard DoIP message
0x02Message too largeDiscard DoIP message
0x03Out of memoryDiscard DoIP message
0x04Invalid payload lengthClose socket
0x05 – 0xFFReserved by ISO 13400NA
Generic DoIP header NACK codes

DoIP Protocol Communication Sequence

DoIP Protocol Communication Sequence

Generic DoIP Header Negative Acknowledge Structure

ItemPositionLength (Byte)DescriptionValues
Generic DoIP header NACK code01The 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 issue0x00 – 0x04
DoIP Header Negative Acknowledge Structure

DoIP Header Negative Acknowledge Values List

ValueDescriptionRequired ActionSupport
0x00Incorrect pattern formatClose socketMandatory
0x01Unknown payload typeDiscard DoIP messageMandatory
0x02Message too largeDiscard DoIP messageMandatory
0x03Out of memoryDiscard DoIP messageMandatory
0x04Invalid payload lengthClose socketMandatory
DoIP Header Negative Acknowledge Values List

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)
0X010xFE0X80010X000000070x0E000xE0000X220xF80x10
Example Of DoIP Request Message Frame Format

Diagnostic Message Positive Acknowledgment Structure

Source Address
(B0-B1)
Target Address
(B2-B3)
NACK Code
(B4)
Previous Diag. Message Data
(Optional)
0x0E000x0E80 0x02NA
Diagnostic Message Positive Acknowledgment Structure

DoIP Protocol NACK Codes

NACK ValueDescriptionSupport Type
0x00 – 0x01Reserved by this part of ISO 13400Reserved
0x02Invalid source addressMandatory
0x03Unknown target addressMandatory
0x04Diagnostic message too largeMandatory
0x05Out of memoryMandatory
0x06Target unreachableOptional
0x07Unknown networkOptional
0x08Transport protocol errorOptional
0x09 – 0xFFReserved by this part of ISO 13400Reserved
DoIP Protocol NACK Codes

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

AddressDescription
0x0000ISO/SAE reserved
0x0001 – 0x0DFFOEM specific
0x0E00 – 0x0FFFReserved for addresses of external test equipment
0x0E00 – 0x0E7FExternal legislated diagnostics test equipment (e.g. for emissions test scan-tool use)
0x0E80 – 0x0EFFExternal vehicle-manufacturer-/aftermarket-enhanced diagnostics test equipment
0x0F00 – 0x0F7FInternal data collection/on-board diagnostic equipment (for vehicle-manufacturer use
only)
0x0F80 – 0x0FFFExternal prolonged data collection equipment (vehicle data recorders and loggers, e.g.
used by insurance companies or to collect vehicle fleet data)
0x1000 – 0x7FFFOEM specific
0x8000 – 0xCFFFISO/SAE reserved
0xD000 – 0xDFFFReserved for SAE Truck & Bus Control and Communication Committee
0xE000 – 0xE3FFISO/SAE-reserved functional group addresses
0xE000ISO 27145 WWH-OBD functional group address
0xE001 – 0xE3FFISO/SAE reserved
0xE400 – 0xEFFFVehicle-manufacturer-defined functional group logical addresses
0xF000 – 0xFFFFISO/SAE reserved
DoIP Protocol Logical Address Details

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:

  1. 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.
  2. 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.
  3. Increased Security: DoIP includes robust security features, including authentication and encryption, to protect against unauthorized access and data theft.
  4. 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.
  5. 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.
  6. Reduced Time: Time-saving at ECU Flash Programming.
  7. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 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.
Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments
Scroll to Top