The so-called DoIP is actually based on the Ethernet communication protocol for UDS protocol data transfer, that is, diagnostic communication over the Internet Protocol. It is also a protocol in itself, standardized in the ISO13400 standard. Because DoIP can transmit a large amount of data, has a fast response speed, and can perform remote diagnosis via Ethernet, DoIP has gradually replaced traditional bus methods such as CAN, and has become the inevitable trend of car network diagnosis. .

Application of DoIP in the automotive field First of all, the overall structure of the automotive system must support DoIP. Due to the rapid development of automotive Ethernet, compared to the traditional automotive system, the overall structure of the current automotive system will add a layer of DoIP protocol over TCP/IP. And in order to better cooperate with OBD diagnosis, remote diagnosis, FOTA and other technologies, the overall architecture of the vehicle has been adjusted with a switch to connect MPU, MCU and other Ethernet ECUs via Ethernet, and connect the external network to the internal network. isolate.

Of course, DoIP is not just a UDS carrier. Although there isn't a lot of content in the ISO13400 standard, it also has some logic. It cannot be said that adding an encapsulation layer on top of TCP/IP can perform its own tasks. Then there is no guarantee of safety. After all, the car's Ethernet can connect the inside and outside of the car through the network, and DoIP is the input for diagnostics. If these doors are not well preserved, there will be security problems.

Simply put, DoIP can perform vehicle detection, status query, routing activation (including security certification), and sending and receiving diagnostic data. This content will be expanded later. With DoIP, UDS data transmission can be performed on top of DoIP, and UDS transmission can be performed when the DoIP preorder logic is normal. Of course, UDS data cannot be transmitted over DoIP, which is configured by customers and may meet some other special requirements for transmission over Ethernet.

DoIP network topology

ISO13400-2 has an example of the following image which is more representative. In this article, we mainly introduce the DoIP network topology based on this network topology diagram.

In the figure, it is not difficult to see that the network topology of the entire vehicle is divided into two parts, namely the internal network and the external network. The default network node in the figure may have a node that supports an Ethernet connection, such as a radar, camera, etc. However, DoIP is not supported, but you can perform network analysis on nodes with DoIP prefixes in their names. From the figure, we can easily see that the DoIP network topology consists of the following roles:

(1) External test equipment

This part is external test equipment, usually an OBD diagnostic tool or other diagnostic client

(2) DoIP edge node gateway

How is this part different from a DoIP gateway? In fact, there is no difference. The only difference is the evaluation of the additional enable line. The figure shows that there is a line called the activation line between the external test equipment and the gateway of the DoIP edge node. The function of this line is then to enable the protocol stack. Of course, the connection between the external test equipment and the gateway of the peripheral DoIP node is not only an activation line. The OBD-II connector is connected, and one of the contacts is the activation line. For more information, see the introduction to ISO 13400-4.

Coming back, what is the role of this role? First of all, it is a gateway. As a gateway, it has several ECUs mounted on its subnet, which is the same as a DoIP gateway. Second, it is the input for interfacing between the in-vehicle network and the out-of-vehicle network and has a switch function that controls whether the DoIP protocol stack is working.

This role can support both server side and client side. The server is easy to understand and the test equipment can diagnose the ECU node under the gateway. So what happens on the client side? Imagine if the DoIP edge node gateway acts as an entry point, how do you interact with DoIP ECUs in other internal subnets? Of course, it is forwarded by the gateway of the DoIP edge node. This is just one of the use cases, the redirection will perform an identity switch, i.e. the server side will switch to the client side. Another scenario is to update via OTA. The gateway application layer of the DoIP edge node can run an OTA client program to diagnose and flash intranet ECUs. This is currently the client ID.

(3) Gateway

DoIP A DoIP gateway is not very different from the role of a gateway of two DoIP edge nodes. In real application scenarios, the MCU usually plays this role and the MPU plays the DoIP edge node gateway role, or vice versa, so this role usually runs the server-side application separately.

(4) Knot

The role of the DoIP node is well understood. An ECU that supports an Ethernet connection and supports the DoIP protocol is considered a DoIP node. This role usually runs the server application itself.

The entire vehicle network consists of four roles. The external test equipment acts as a client to diagnose each ECU in the vehicle network that supports the DoIP protocol stack. (Some CAN ECUs are usually installed on the MCU, and the MCU performs DoIP-DoCAN routing) The external vehicle network test equipment communicates with the vehicle network peripheral gateway via OBD-II, and the peripheral gateway is used to enable the vehicle network DoIP function. Once the routing is open, the sent diagnostic data goes to different ECUs in the car network according to different destination addresses.

DoIP acquisition method and protocol format

3.1 Ports

As you can see from the name DoIP, the protocol is based on TCP/IP. If you want to receive DoIP packets, the protocol requires you to monitor the port number specifically assigned to the DoIP protocol stack, namely 13400, UDP, TCP You need to monitor the receiving port, and the send port is a random value in the range [49152\~65535].Of course, the protocol stack in the code must cache the opposite end's send port to play the data.

A port number is specified, and the client and server can send and receive data through this port. The network packet can then be analyzed to see if the data received by the port is indeed a DoIP packet. (This could be a network attack, maybe another program accidentally uses the port number). Parsing the received message involves the creation of the DoIP protocol, and only if it conforms to the specification can it be considered a legitimate and valid DoIP message.

3.2 Protocol format

A DoIP packet consists of a protocol header + payload. The protocol header [8 bytes] consists of the following four fields

• Protocol version [1 byte]
• Inverse protocol version [1 byte]
• Payload Type [2 bytes]
• Payload length [4 bytes]
• Payload [N bytes] According to the actual payload type, the payload data will differ

3.3 Protocol Versioning and Reverse Protocol Versioning

Normally, the protocol version is 0x02, and values above 0x02 are currently reserved. The inverse protocol version is the inverse of the protocol version. In this example, 0x02 is 0xFD after negation. The protocol specifically states that the protocol version can be 0xFF. The function of setting this value is that when the client and server protocol versions do not match, this value can be set to bypass the protocol header version mismatch case and reject the request.

3.4 Type of payload

The payload type may represent the functions supported by the DoIP protocol stack as follows (the type supported by the server and the type supported by the client are intentionally separated)

DoIP SERVER

DoIP client

It is described separately, as above, because the logic can be separated in terms of code implementation. That is, the server only cares about the payload types it supports, and the client only cares about the payload types it supports, and those that are not supported can be ignored. This facilitates the separation and combination of modules, and it is also useful to implement the different roles mentioned in the previous section. In the future, the different roles will be represented by the configuration of the configuration file.

3.5 Payload length

The payload length is allocated here by 4 bytes, that is, the maximum transfer of a DoIP message is 4 GB /4294967295 bytes, which is 0xFFFFFFFF. This is just a valid range. In general, diagnosis via DoIP takes only a few bytes to tens of bytes, and the update package for an ECU update is usually only a few MB. So 4GB is just a theoretical upper limit.

This value can be used to check the validity of the length, since other payload types besides diagnostic data have a fixed length. What else can be done? In fact, when doing development, you should also consider how to handle the following situations.

• given glue
• Data truncation
• unusually large size
• More than the protocol stack can handle

3.6 Payload

The payload here refers to the payload of the DoIP protocol. Of course, when the payload type is a diagnostic type, the payload includes UDS data in addition to the contents of the DoIP itself for further analysis by the upper-level UDS module. . Since each type of payload is different, it will not be explained here. A detailed introduction will be provided in the following function sections.

Running and using DoIP diagnostics

4.1 Establishing a connection

The DoIP connection table is managed in the DoIP object, which is used to record and maintain the logical connection of the diagnostic communication. The figure above is an element of this table, logically connected by a state machine. The box in the image above is the state the connection is in, and the [Step] is what happens when you transition between states.

[Step 1] When a new socket is established, the state of the logical connection changes from "listening" to "initialized socket" and a timer, the initial idle timer, starts at the same time.
[Step 2] When the DoIP entity receives the routing activation message sent by the tester, the state of the logical connection changes from "socket initialized" to "Registered [Waiting for authentication]". At this time, the initial inactivity timer is stopped and a timer called the general inactivity timer.
[Step 3] After the authentication is complete, the status of the logical connection changes from "Registered [Awaiting Authentication]" to "Registered [Awaiting Confirmation]".
[Step 4] After the confirmation is complete, the status of the logical connection changes from "Registered [Awaiting Confirmation]" to "Registered [Routing Active]".
[Step 5] If the initial timer or general inactivity timer expires and no subsequent request is received, or authentication and confirmation are rejected, or the external test device does not respond to the activity check message, the logical connection goes to Termination. state.
[Step 6] After entering Finalize, the TCP socket will be closed and returned to the "listening" state.

4.2 Detection of the vehicle

When the DoIP object and the external test equipment are connected to the network, they will receive their own IP address using the DHCP protocol. In a network, the router acts as a DHCP server and assigns IP addresses to devices newly added to the network. Once the IP address is obtained, there are two ways to detect the vehicle as shown in the image above. One method is for the vehicle to actively report its own information 3 times. If the test equipment does not receive information actively reported by the vehicle, it will send an identification request. If there is a vehicle on the network, the vehicle will respond to the request and the test equipment will find the vehicle under test.

4.3 Establishing a session

When the diagnostic device finds a vehicle, it will add it to its own vehicle list. When the user selects a vehicle in this list, if the connection is established successfully, the user can diagnose the vehicle.

Next, the user sends the diagnostic information to the car, and the gateway forwards the diagnostic information to the corresponding ECU in the network according to the object of receiving the information. After receiving the response from the ECU, the gateway sends the final response to the diagnostic device. . When the user opts out, the socket used for DoIP communication is closed.

The following figure shows an example of a complete DoIP data structure:

An example of a complete DoIP data structure
byte 0: ISO13400 version
byte 1: ISO13400 version bitwise inversion
byte 2~3: data type, 0x8001, indicating that this is a diagnostic information packet
byte 4~7: data length, in this example the value is 7, which indicates the presence of 7 bytes of data
byte 8~9: source address
byte 10~11: destination address
byte 12~13: special diagnostic command, SID is 22, which means read, DID is 0xF8 10
This data segment is passed to the lower layer protocol as an SDU, encapsulated layer by layer as a complete Ethernet frame, and sent.

Source

Another article about DoIP