A vehicle diagnostic communication method, device, equipment and medium

Abstract

The present application discloses a vehicle diagnosis communication method, device, equipment and medium, which relates to the technical field of vehicle diagnosis, and includes: after switching the current communication model to a target communication model matching the diagnosed node, establishing a communication connection with the diagnosed node; determining the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, so as to judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key currently; if so, after establishing a DoIP diagnosis connection with the diagnosed node and determining that the current diagnosis writing needs to be performed, encrypting the preprocessed message group with the target key to obtain an encrypted message group, and matching the encrypted message group with the response message sent by the diagnosed node; using the successfully matched message as the response message, and disconnecting the communication connection after completing the verification of the response message. The communication model of the diagnostic device can be switched according to the diagnosed node, and the data parsing in the diagnosis process is accelerated through the preprocessing mode.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle diagnosis, and particularly to a vehicle diagnosis communication method, device, equipment and medium. Background Art

[0002] DoIP (Diagnostic communication over Internet Protocol) is a diagnosis based on in-vehicle Ethernet and belongs to the transport layer in the OSI seven-layer model. The diagnostic data it transmits is based on UDS (Unified Diagnostic Services), that is, DoIP is a transport protocol for transmitting UDS diagnostic data over an Ethernet network. DoIP has a high bandwidth and is suitable for scenarios where a large amount of data needs to be transmitted, such as OTA (Over-the-Air Technology) software upgrades in vehicles.

[0003] Compared with the CAN protocol used by traditional automobile manufacturers, the DoIP protocol based on Ethernet is relatively novel in technology, and both the transmission speed and reliability have been qualitatively improved. It can be foreseen that it is one of the main development directions of future in-vehicle communication. However, since this protocol was introduced relatively late, there are currently few related tools or resources based on this protocol. In addition, the current mainstream DoIP technology of the host factory is mainly based on the ISO 13400-22012 version, and existing DoIP-related tools or resources are also implemented based on this version. However, some host factories have upgraded to the ISO 13400-2 2019 version, so systems that can be compatible with both protocol versions are extremely rare.

[0004] In the current design of the host factory, in-vehicle diagnosed nodes are designed as either server structures or client structures. Therefore, when developing diagnostic equipment, it is often necessary to develop servers or clients according to different projects, which is rather troublesome. In addition, although in-vehicle Ethernet has greatly improved the data transmission speed, according to the requirements of the DoIP protocol, during actual diagnosis, it is necessary to receive DoIP diagnostic response messages. This often leads to the situation where the parsing and checking of DoIP diagnostic response messages have not been completed, but the UDS diagnostic response messages have already been received and cached, which to a certain extent affects the speed advantage of in-vehicle Ethernet.

[0005] In summary, how to enable the diagnostic equipment system to be compatible with multiple DoIP protocol versions, implement the switching of communication models, and accelerate the parsing of data during diagnosis is an issue to be solved currently. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to provide a vehicle diagnostic communication method, device, equipment and medium, which can enable the diagnostic equipment system to be compatible with multiple DoIP protocol versions, realize the switching of communication models, and speed up the parsing of data during diagnosis. The specific solutions are as follows:

[0007] In the first aspect, the present application discloses a vehicle diagnostic communication method, which is applied to a diagnostic device and includes:

[0008] After switching the current communication model to a target communication model that matches the diagnosed node, establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model;

[0009] Determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version;

[0010] If so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic rewrite needs to be performed currently, encrypt the preprocessed message group with the target key to obtain an encrypted message group, and match each message in the encrypted message group with the response message sent by the diagnosed node;

[0011] If there is a target message in the encrypted message group that matches the response message, use the target message as the response message, and after completing the verification of the response message, disconnect the communication connection with the diagnosed node.

[0012] Optionally, in the process of determining the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, it further includes:

[0013] If the vehicle declaration message sent by the diagnosed node is not received, send a request message for obtaining the vehicle declaration message to the diagnosed node;

[0014] After the diagnosed node responds to the request message, obtain the vehicle declaration message sent by the diagnosed node.

[0015] Optionally, the judgment on whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version includes:

[0016] Judge whether the DoIP protocol version is the current latest automotive Ethernet diagnostic standard;

[0017] If it is the current latest automotive Ethernet diagnostic standard and it is determined that the TSL security check needs to be activated currently, perform a TLS handshake with the diagnosed node to obtain the target key;

[0018] If it is not the latest version of the automotive Ethernet diagnostic standard, or if it is determined that the TSL security check does not need to be activated currently, it is determined that there is no need to perform a TLS handshake with the diagnosed node to obtain the target key.

[0019] Optionally, after determining whether to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version, the following steps are further included:

[0020] If not, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash needs to be performed currently, a diagnostic request message is sent to the diagnosed node, and a DoIP diagnostic response message returned by the diagnosed node is obtained. Then, it is determined whether the DoIP diagnostic response message is a positive response.

[0021] If the DoIP diagnostic response message is a positive response, a UDS diagnostic response message returned by the diagnosed node is obtained. If the DoIP diagnostic response message is a negative response, the diagnostic process is ended.

[0022] It is determined whether the UDS diagnostic response message is a positive response. If the UDS diagnostic response message is a positive response, the UDS diagnostic response message is parsed and verified. If the UDS diagnostic response message is a negative response, the diagnostic process is ended.

[0023] Optionally, the switching of the current communication model to a target communication model that matches the diagnosed node includes:

[0024] When the communication model type of the diagnosed node is a server model, and the target communication model that matches the diagnosed node is a client model, the current communication model is switched to the client model.

[0025] When the communication model type of the diagnosed node is a client model, and the target communication model that matches the diagnosed node is a server model, the current communication model is switched to the server model.

[0026] Optionally, during the process of performing a TLS handshake with the diagnosed node to obtain the target key, the following steps are further included:

[0027] Historical diagnostic response messages are obtained, and the usage probabilities of different message types in the historical diagnostic response messages are determined according to a preset probability algorithm; where the diagnostic messages include DoIP diagnostic response messages and UDS diagnostic response messages.

[0028] Target response messages whose usage probabilities meet the preset probability conditions are screened out from the historical diagnostic response messages, and a preprocessing message group is constructed based on the target response messages.

[0029] Optionally, after establishing a DoIP diagnostic connection with the diagnosed node and determining that diagnostic flashing needs to be performed currently, it further includes:

[0030] Sending a diagnostic request message to the diagnosed node to obtain the encrypted DoIP diagnostic response message returned by the diagnosed node, and matching each message in the encrypted message group with the DoIP diagnostic response message;

[0031] If there is a first target message in the encrypted message group that matches the DoIP diagnostic response message, then use the first target message as the DoIP diagnostic response message, and determine whether the DoIP diagnostic response message is a positive response;

[0032] If the DoIP diagnostic response message is a positive response, obtain the encrypted UDS diagnostic response message returned by the diagnosed node, and match each message in the encrypted message group with the UDS diagnostic response message. If the DoIP diagnostic response message is a negative response, end the diagnostic process;

[0033] If there is a second target message in the encrypted message group that matches the UDS diagnostic response message, then use the second target message as the UDS diagnostic response message, and determine whether the UDS diagnostic response message is a positive response. If the UDS diagnostic response message is a positive response, parse and verify the UDS diagnostic response message. If the UDS diagnostic response message is a negative response, end the diagnostic process.

[0034] In a second aspect, the present application discloses a vehicle diagnostic communication device, which is applied to a diagnostic device and includes:

[0035] A communication model switching module, configured to switch the current communication model to a target communication model that matches the diagnosed node, and then establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model;

[0036] A judgment module, configured to determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain a target key based on the DoIP protocol version;

[0037] A response message matching module, configured to, if so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that diagnostic flashing needs to be performed currently, encrypt the preprocessed message group with the target key to obtain an encrypted message group, and match each message in the encrypted message group with the response message sent by the diagnosed node;

[0038] A response message determination module, configured to, if there is a target message in the encrypted message group that matches the response message, use the target message as the response message, and after completing the verification of the response message, disconnect the communication connection with the diagnosed node.

[0039] In a third aspect, the present application discloses an electronic device, including:

[0040] A memory for storing a computer program;

[0041] A processor for executing the computer program to implement the steps of the vehicle diagnostic communication method disclosed above.

[0042] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the steps of the vehicle diagnostic communication method disclosed above are implemented.

[0043] It can be seen that after the diagnostic device in the present application switches the current communication model to a target communication model that matches the diagnosed node, a communication connection is established with the diagnosed node; wherein, the communication model includes a server model and a client model; the DoIP protocol version of the diagnosed node is determined according to the received vehicle declaration message, and it is judged whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version; if so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that the current diagnosis and writing needs to be performed, the preprocessed message group is encrypted with the target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node; if there is a target message in the encrypted message group that matches the response message, the target message is used as the response message, and after completing the verification of the response message, the communication connection with the diagnosed node is disconnected. Thus, it can be seen that the diagnostic device in the present application can switch the current communication model to a target communication model that matches the diagnosed node, so as to realize the switch between the server model and the client model; in addition, after the diagnostic device obtains the vehicle declaration message, it can determine the DoIP protocol version used by the diagnosed node according to the vehicle declaration message, so as to judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version, that is, the present application can perform corresponding processing according to different protocol versions used by the diagnosed node, so as to achieve the purpose of being compatible with multiple DoIP protocol versions. Further, if a TLS handshake is required, after establishing a DoIP diagnostic connection with the diagnosed node and determining that the current diagnosis and writing needs to be performed, the preprocessed message group is encrypted with the obtained target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node. If there is a target message in the encrypted message group that matches the response message, the target message can be directly used as the response message, that is, the present application can directly use the message result in the preprocessed message, thus skipping the cumbersome decryption process and accelerating the data parsing process during diagnosis; finally, after completing the message verification, the communication connection with the diagnosed node is disconnected and the communication is stopped. Description of the Drawings

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0045] Figure 1 It is a flowchart of a vehicle diagnostic communication method disclosed in the present application;

[0046] Figure 2 The switching flowchart of a communication model disclosed in this application;

[0047] Figure 3 The request flowchart of a vehicle declaration message disclosed in this application;

[0048] Figure 4 The flowchart of a specific vehicle diagnostic communication method disclosed in this application;

[0049] Figure 5 The routing activation flowchart under different DoIP protocol versions disclosed in this application;

[0050] Figure 6 The generation flowchart of a preprocessing message group disclosed in this application;

[0051] Figure 7 The response flowchart of a diagnostic request message disclosed in this application;

[0052] Figure 8 The response flowchart of a specific diagnostic request message disclosed in this application;

[0053] Figure 9 The system module call diagram disclosed in this application;

[0054] Figure 10 The flowchart of another specific vehicle diagnostic communication method disclosed in this application;

[0055] Figure 11 The structural schematic diagram of a vehicle diagnostic communication device disclosed in this application;

[0056] Figure 12 The structural diagram of an electronic device disclosed in this application. Specific embodiments

[0057] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0058] Currently, due to the relatively late introduction of the DoIP protocol based on Ethernet, there are currently few related tools or resources based on this protocol. Additionally, the mainstream DoIP technology of current vehicle manufacturers mainly follows the 2012 version of ISO 13400-2, and existing DoIP-related tools or resources are also implemented based on this version. However, some vehicle manufacturers have upgraded to the 2019 version of ISO 13400-2. Therefore, systems that can be compatible with both protocol versions are extremely rare. In the current designs of vehicle manufacturers, in-vehicle diagnosed nodes are designed as either server structures or client structures. Therefore, when developing diagnostic devices, it is often necessary to develop servers or clients according to different projects, which is rather troublesome. Moreover, although in-vehicle Ethernet has greatly increased the data transmission speed, according to the requirements of the DoIP protocol, during actual diagnosis, DoIP diagnostic response messages need to be received. This often leads to the situation where the UDS diagnostic response message has already been received and cached before the parsing and checking of the DoIP diagnostic response message are completed, which to a certain extent affects the speed advantage of in-vehicle Ethernet. For this reason, the embodiments of the present application disclose a vehicle diagnostic communication method, device, equipment, and medium, which can enable the diagnostic device system to be compatible with multiple DoIP protocol versions, implement the switching of communication models, and accelerate the parsing of data during diagnosis.

[0059] See Figure 1 As shown, the embodiments of the present application disclose a vehicle diagnostic communication method, which is applied to a diagnostic device, and the method includes:

[0060] Step S11: After switching the current communication model to a target communication model that matches the diagnosed node, establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model.

[0061] In this embodiment, the diagnostic device can switch the current communication model to a target communication model that matches the diagnosed node, thereby achieving the switching between the server model and the client model. As Figure 2 shown, the diagnostic device system selects to use the server model or the client model according to project needs or test needs, and obtains the corresponding server or client parameters after selection to switch to the corresponding communication mode. This design helps to flexibly switch communication models in different projects and eliminates the problem of repeated development.

[0062] In addition, due to the limitations of the test environment, many simple test scenarios also need to be carried out on a real vehicle, resulting in complex operations and difficulties in performing stress tests and other tasks. Therefore, in addition to being able to set this system to the client mode or the server mode according to needs, in actual use, one or several computers can also be used to directly simulate the diagnostic device and the diagnosed node, getting rid of the dependence on the vehicle to a certain extent. That is, this system can not only perform real vehicle diagnostic flashing tests, but also simulate communication tests between two or more diagnosed nodes by simultaneously enabling multiple systems, and test and verify the solutions of multiple DoIP nodes in in-vehicle Ethernet.

[0063] In the specific implementation manner, the above-mentioned switching of the current communication model to the target communication model matching the diagnosed node includes: when the communication model type of the diagnosed node is the server model, the target communication model matching the diagnosed node is the client model, and the current communication model is switched to the client model; when the communication model type of the diagnosed node is the client model, the target communication model matching the diagnosed node is the server model, and the current communication model is switched to the server model. It can be understood that in the current design of the host factory, in-vehicle diagnosed nodes are designed as server structures and some are designed as client structures. Therefore, for diagnosed nodes with different communication structures, this application can switch the current communication model of the diagnostic device to the target communication model matching the diagnosed node. Among them, if the communication model type of the diagnosed node is the server model, the current communication model is switched to the client model; if the communication model type of the diagnosed node is the client model, the current communication model is switched to the server model.

[0064] Further, after switching the current communication model to the target communication model matching the diagnosed node, a communication connection is established with the diagnosed node. The above-mentioned communication connection is specifically a TCP (Transmission Control Protocol) connection. According to the TCP protocol, the diagnostic device actively sends a TCP connection request message to the diagnosed node according to the project configuration. After receiving it, the diagnosed node sends a confirmation message for the connection request message, and then the diagnosed node continues to send a connection request message. After the diagnostic device receives the connection request message sent by the diagnosed node, it also needs to send a confirmation message for the connection request message. After completion, the diagnostic device and the diagnosed node successfully establish a TCP communication.

[0065] Step S12: Determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version.

[0066] In this embodiment, it can be understood that according to the DoIP protocol specification, after the diagnosed node is powered on and starts up, it will actively send a vehicle declaration message by broadcasting, and actively send vehicle-related information. Therefore, after establishing TCP communication, the diagnostic system should attempt to receive and obtain the vehicle declaration message and parse out the required vehicle-related information.

[0067] In addition, as Figure 3 shown, in the process of determining the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, it further includes: if the vehicle declaration message sent by the diagnosed node is not received, a request message for obtaining the vehicle declaration message is sent to the diagnosed node; after the diagnosed node responds to the request message, the vehicle declaration message sent by the diagnosed node is obtained. That is to say, if the attempt to receive the vehicle declaration message fails, then according to the DoIP protocol specification, the diagnostic device can also send an active request for the vehicle declaration message, and then the diagnosed node will resend the vehicle declaration message to complete the establishment of the vehicle diagnosis connection. Therefore, the main purpose of establishing the vehicle diagnosis connection is to receive the correct vehicle declaration message and parse it as needed.

[0068] Specifically, after parsing the vehicle declaration message, the DoIP protocol version currently used by the diagnosed node can be determined according to the information in the declaration message, and it is judged whether it is necessary to perform a TLS (Transport Layer Security) handshake with the diagnosed node to obtain the target key based on the DoIP protocol version. That is to say, the present application can perform corresponding processing according to different protocol versions used by the diagnosed node, so as to achieve the purpose of being compatible with multiple DoIP protocol versions. Among them, TLS is a security protocol, the purpose of which is to provide security and data integrity guarantee for Internet communication. The protocol consists of two layers: the TLS Record Protocol (i.e., TLS Record) and the TLS Handshake Protocol (i.e., TLS Handshake). According to the TLS security protocol specification, during the TLS security handshake process, the diagnostic device and the diagnosed node will communicate and define the TLS target key and encryption scheme during this connection process, and jointly form a cipher suite for encrypting and decrypting the subsequent data.

[0069] Step S13: If so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that diagnosis flashing needs to be performed currently, the preprocessed message group is encrypted with the target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node.

[0070] In this embodiment, if it is determined according to the DoIP protocol version that a TLS handshake needs to be performed with the diagnosed node to obtain the target key currently, after the TLS handshake process is completed, a routing activation request is sent, and after receiving the routing activation response returned by the diagnosed node, the DoIP diagnosis connection establishment result is determined according to the response result. That is, after the diagnosed node returns a routing activation response, it indicates that the DoIP diagnosis connection has been established. From the above, it can be seen that the communication establishment phase in this application can be specifically divided into three phases, namely TCP communication connection establishment, vehicle diagnosis connection establishment, and DoIP diagnosis connection establishment. After all connections are successfully established, diagnostic messages can be sent and received according to the TCP protocol, DoIP protocol, and UDS protocol.

[0071] Furthermore, after completing all the communication establishment phases, the version verification phase will be entered next. According to different project requirements, the existing version verification methods are divided into extracting version information, requesting the current version, and version verification. Among them, the version information can be written in advance through the software interface or file configuration, or the data in the relevant software upgrade package can be directly read. When requesting the current version, diagnostic requests are mainly made through the DoIP and UDS protocols, and the software version of the currently diagnosed node is received according to the pre-agreed format. Finally, after obtaining the existing software version of the diagnosed node and the software version information in the pre-upgrade software package at the same time, the two are verified. If the versions are the same, it means that the existing software version of the diagnosed node is already the latest version, and the flashing test process is directly ended. If the versions are different, the subsequent diagnostic flashing process continues for software upgrade. That is, this application determines whether to perform diagnostic flashing currently by comparing whether the existing software version of the diagnosed node is the same as the software version information in the upgrade software package.

[0072] Therefore, in this embodiment, after the diagnostic device establishes a DoIP diagnosis connection with the diagnosed node and determines that diagnostic flashing needs to be performed currently, the preprocessed message group is encrypted using the obtained target key and the corresponding encryption scheme to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node.

[0073] Step S14: If there is a target message in the encrypted message group that matches the response message, use the target message as the response message, and after completing the verification of the response message, disconnect the communication connection with the diagnosed node.

[0074] In this embodiment, if there is a target message in the encrypted message group that matches the response message, the target message can be directly used as the response message. That is, the present application can directly use the message result in the preprocessed message, thus skipping the cumbersome decryption process and eliminating the need for re-decryption or encryption calculations. This speeds up the data parsing process during diagnosis, and while ensuring security requirements, also maximizes the TLS security encryption speed as much as possible. Finally, after verifying the response message, the communication connection with the diagnosed node is disconnected and the communication is stopped. It can be understood that according to the TCP protocol and DoIP protocol regulations, after all communication is completed, the diagnostic device needs to actively close the communication connection, which mainly includes sending an end request, receiving a request confirmation, receiving an end request, and sending a request confirmation. When the diagnostic device closes the connection, it needs to first send an end request message, and then wait for the request confirmation message returned by the diagnosed node for this end request. After receiving the request confirmation message, the diagnostic device continues to wait for the end request message actively sent by the diagnosed node. After receiving the end request message sent by the diagnosed node, the diagnostic device also needs to send an end request confirmation message for confirmation according to the protocol requirements. After that, the diagnosed node will disconnect the connection, and the diagnostic device can also stop the communication.

[0075] It can be seen that in the present application, after the diagnostic device switches the current communication model to a target communication model that matches the diagnosed node, a communication connection is established with the diagnosed node; wherein, the communication model includes a server model and a client model; the DoIP protocol version of the diagnosed node is determined according to the received vehicle declaration message, and it is judged whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version; if so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that the current diagnosis and writing needs to be performed, the preprocessed message group is encrypted with the target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node; if there is a target message in the encrypted message group that matches the response message, the target message is used as the response message, and after the verification of the response message is completed, the communication connection with the diagnosed node is disconnected. Thus, it can be seen that the diagnostic device in the present application can switch the current communication model to a target communication model that matches the diagnosed node, so as to realize the switch between the server model and the client model; in addition, after the diagnostic device obtains the vehicle declaration message, it can determine the DoIP protocol version used by the diagnosed node according to the vehicle declaration message, so as to judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version, that is, the present application can perform corresponding processing according to different protocol versions used by the diagnosed node, so as to achieve the purpose of being compatible with multiple DoIP protocol versions. Further, if a TLS handshake is required, after establishing a DoIP diagnostic connection with the diagnosed node and determining that the current diagnosis and writing needs to be performed, the preprocessed message group is encrypted with the obtained target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node. If there is a target message in the encrypted message group that matches the response message, the target message can be directly used as the response message, that is, the present application can directly use the message result in the preprocessed message, thus skipping the cumbersome decryption process and accelerating the data parsing process during the diagnosis; finally, after the message verification is completed, the communication connection with the diagnosed node is disconnected and the communication is stopped.

[0076] See Figure 4 As shown, an embodiment of the present application discloses a specific vehicle diagnosis communication method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically, it includes:

[0077] Step S21: After switching the current communication model to a target communication model that matches the diagnosed node, establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model.

[0078] Step S22: Determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and determine whether the DoIP protocol version is the current latest automotive Ethernet diagnostic standard.

[0079] In this embodiment, after determining the DoIP protocol version currently used by the diagnosed node according to the information in the vehicle declaration message, it can be specifically determined whether the DoIP protocol version is the current latest automotive Ethernet diagnostic standard. Among them, it should be pointed out that the current latest automotive Ethernet diagnostic standard is ISO 13400-2-2019. According to the current usage of in-vehicle Ethernet technology, the DoIP protocol version mainly used by OEMs is still the ISO13400-2 2012 version, and a small number of OEMs have started to use the ISO13400-2 2019 version.

[0080] Step S23: If it is the current latest automotive Ethernet diagnostic standard and it is determined that TSL security verification needs to be activated currently, perform a TLS handshake with the diagnosed node to obtain the target key; if it is not the current latest automotive Ethernet diagnostic standard, or if it is determined that TSL security verification does not need to be activated currently, it is determined that there is no need to perform a TLS handshake with the diagnosed node to obtain the target key.

[0081] In this embodiment, reference can be made to Figure 5As shown, it should be noted first that the 2019 version of ISO13400-2 has added a TLS handshake process protocol. However, according to the current usage of the ISO 13400-2 2019 version protocol by the current OEMs, the application of the newly added TLS security protocol technology in this protocol is still being explored and tried, and there is no mandatory requirement to use it. Therefore, in this embodiment, the use option for this part of the function needs to be added. Specifically, if the DoIP protocol version currently used by the diagnosed node is the current latest automotive Ethernet diagnostic standard, that is, the ISO13400-2 2019 version, then before the routing activation request, the TLS handshake process needs to be carried out according to the protocol regulations. At the same time, all subsequent processes will perform full-process data encryption on the data according to TLS. However, this protocol setting can be activated by the content set by the system. If the TLS security check is not activated, the current diagnostic flashing process will only be carried out according to the regulations of the ISO13400-2 2019 protocol version, and no relevant data security encryption process will be carried out according to the TLS protocol. Therefore, only when the DoIP protocol version is the ISO13400-2 2019 version and it is determined that the TSL security check needs to be activated according to the system settings, does the diagnostic device need to perform a TLS handshake with the diagnosed node to obtain the security key; if the DoIP protocol version is the ISO13400-2 2012 version, or if the TSL security check is not activated when the DoIP protocol version is the ISO13400-2 2019 version, there is no need to perform a TLS handshake with the diagnosed node, but directly perform the routing activation request. Therefore, through the above content, it can be seen that this application is compatible with the current mainstream ISO 13400-2 2012 version and the latest ISO 13400-2 2019 version, and can selectively activate the application of the TLS protocol during the flashing process.

[0082] Furthermore, referring to Figure 6As shown above, during the process of performing a TLS handshake with the diagnosed node to obtain the target key, the following steps are further included: obtaining historical diagnostic response messages, and determining the usage probabilities of different message types in the historical diagnostic response messages according to a preset probability algorithm; wherein, the diagnostic messages include DoIP diagnostic response messages and UDS diagnostic response messages; screening out target response messages from the historical diagnostic response messages whose usage probabilities meet the preset probability conditions, and constructing a preprocessing message group based on the target response messages. It can be understood that during the in-vehicle Ethernet diagnostic communication process, the data interaction speed is greatly accelerated, so it often occurs that before the decryption and processing check process of the previous message is completed, the next message has already been received and cached, resulting in the difficulty of giving full play to the speed advantage of the in-vehicle Ethernet. Therefore, this application designs a preprocessing scheme, which iteratively calculates the data of the historical diagnostic response messages in the past according to a preset probability algorithm while performing a TLS handshake, obtains DoIP messages or UDS messages that are likely to be used, and thus establishes a preprocessing message group.

[0083] Step S24: If it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key, then after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash is currently required, encrypt the preprocessing message group using the target key to obtain an encrypted message group, and send a diagnostic request message to the diagnosed node to obtain the encrypted DoIP diagnostic response message returned by the diagnosed node, and match each message in the encrypted message group with the DoIP diagnostic response message.

[0084] In this embodiment, according to the relevant regulations of the DoIP protocol and the UDS protocol, after officially entering the diagnostic flash stage, the request, response, and verification processes of each diagnostic message shall be carried out according to the Figure 7 process shown. From the foregoing content, it can be seen that if the DoIP protocol version currently used by the diagnosed node is the ISO13400-2 2019 version, then all subsequent processes will perform full-process data encryption processing on the data according to TLS. Therefore, after the diagnostic device first sends a diagnostic request message through Ethernet communication, the diagnostic device will first receive the encrypted DoIP diagnostic response message returned by the diagnosed node, and then the diagnostic device will match each message in the encrypted message group with the DoIP diagnostic response message.

[0085] Step S25: If there is a first target message in the encrypted message group that matches the DoIP diagnostic response message, then use the first target message as the DoIP diagnostic response message, and determine whether the DoIP diagnostic response message is a positive response.

[0086] If there is a first target message in the encrypted message group that matches the DoIP diagnostic response message, directly use the first target message as the DoIP diagnostic response message, without decrypting the DoIP diagnostic response message anymore, and determine whether the DoIP diagnostic response message is a positive response, that is, determine whether the first target message is a positive response. It should be noted that if there is no response message in the encrypted message group that matches the DoIP diagnostic response message, the DoIP diagnostic response message returned by the diagnosed node needs to be decrypted according to the existing process, and then determine whether the decrypted DoIP diagnostic response message is a positive response.

[0087] Step S26: If the DoIP diagnostic response message is a positive response, obtain the encrypted UDS diagnostic response message returned by the diagnosed node, and match each message in the encrypted message group with the UDS diagnostic response message. If the DoIP diagnostic response message is a negative response, end the diagnostic process.

[0088] In this embodiment, if the DoIP diagnostic response message is a positive response, the diagnostic device continues to wait for the encrypted UDS diagnostic response message returned by the diagnosed node, and match each message in the encrypted message group with the UDS diagnostic response message. If the DoIP diagnostic response message is a negative response, after parsing and recording the error information, end the current diagnostic process.

[0089] Step S27: If there is a second target message in the encrypted message group that matches the UDS diagnostic response message, use the second target message as the UDS diagnostic response message, and determine whether the UDS diagnostic response message is a positive response. If the UDS diagnostic response message is a positive response, after parsing and verifying the UDS diagnostic response message, disconnect the communication connection with the diagnosed node; if the UDS diagnostic response message is a negative response, end the diagnostic process.

[0090] In this embodiment, if there is a second target message in the encrypted message group that matches the UDS diagnostic response message, use the second target message as the UDS diagnostic response message, and determine whether the UDS diagnostic response message is a positive response according to the UDS protocol. If the result is a positive response, further perform data parsing and check verification according to the process preset by the system, so as to disconnect the communication connection with the diagnosed node after completing the verification. Among them, it should be noted that if there are other diagnostic steps, proceed to the next diagnostic process, and disconnect the communication connection with the diagnosed node after completing all diagnostic processes. If the UDS diagnostic response message is a negative response, also parse and record the error information, and then end the current diagnostic process.

[0091] In another specific implementation, such as Figure 8As shown, after determining whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the above DoIP protocol version, the following steps are further included:

[0092] Step S31: If it is determined that it is not necessary to perform a TLS handshake with the diagnosed node to obtain the target key, then after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash is currently required, send a diagnostic request message to the diagnosed node, obtain the DoIP diagnostic response message returned by the diagnosed node, and then determine whether the DoIP diagnostic response message is a positive response.

[0093] Step S32: If the DoIP diagnostic response message is a positive response, obtain the UDS diagnostic response message returned by the diagnosed node; if the DoIP diagnostic response message is a negative response, end the diagnostic process.

[0094] Step S33: Determine whether the UDS diagnostic response message is a positive response. If the UDS diagnostic response message is a positive response, parse and verify the UDS diagnostic response message; if the UDS diagnostic response message is a negative response, end the diagnostic process.

[0095] That is to say, if there is no need to perform a TLS handshake with the diagnosed node currently, after successfully establishing a DoIP diagnostic connection with the diagnosed node by completing route activation and determining that a diagnostic flash is currently required after completing the version verification phase, send a diagnostic request message to the diagnosed node and obtain the DoIP diagnostic response message returned by the diagnosed node. After receiving this result, the diagnostic device makes a judgment. If the result is a negative response, parse and record the error information and end the current diagnostic process; if the result is a positive response, the diagnostic device continues to wait for the response result that conforms to the UDS protocol. After receiving the UDS diagnostic response message, first judge the response result according to the UDS protocol. If it is a negative response, also parse and record the error information and end the current diagnostic process. If the result is a positive response, further perform the data parsing and verification process. At this time, it should be noted that since the TLS security verification is not activated, the DoIP diagnostic response message and the UDS diagnostic response message returned by the diagnosed node are plaintext data.

[0096] Furthermore, as Figure 9As shown in the figure, the embodiment of the present application also discloses a system module call graph, which provides all configuration contents of important system parameters, including the enabling of key steps and task scheduling logic. Among them, the TCP protocol module provides TCP protocol content, the DoIP protocol module provides DoIP protocol content, the UDS protocol module provides UDS protocol content, the TLS protocol module provides TLS security protocol content, the Python software library interface mainly uses software libraries developed in Python and provides all function interfaces for the host computer or script to call. The task scheduling management module will allocate and schedule tasks for other sub-modules according to the system configuration content. Functions such as the selection of the DoIP protocol version and whether to enable data encryption of the TLS protocol are processed in this module. The TCP protocol stack mainly processes packets according to the TCP protocol, the DoIP protocol stack mainly processes packets according to the DoIP protocol, the UDS protocol stack mainly processes packets according to the UDS protocol, the TLS protocol stack mainly encrypts and decrypts packets according to the TLS protocol when it is activated. The hardware driver part mainly connects and uses hardware devices according to relevant in-vehicle Ethernet drivers. The system log module mainly stores the general information and error information during the system usage process. The packet log module mainly stores all the received and sent packet contents during the system usage process. If TLS encryption processing is enabled, the packet log module stores both the pre-encrypted and post-encrypted packets at the same time.

[0097] Among them, for a more specific processing process of the above step S21, reference can be made to the corresponding content disclosed in the foregoing embodiments, and details will not be repeated here.

[0098] It can be seen that the embodiments of the present application are compatible with the current mainstream ISO 13400-2 2012 version and the latest ISO 13400-2 2019 version, and can selectively activate the use of the TLS protocol during the flashing process. Only when the DoIP protocol version currently used by the diagnosed node is the ISO 13400-2 2019 version and it is determined according to the system settings that the TLS security check needs to be activated currently, does the diagnostic device need to perform a TLS handshake with the diagnosed node to obtain the security key; if the DoIP protocol version is the ISO 13400-2 2012 version, or the TLS security check is not activated when the DoIP protocol version is the ISO 13400-2 2019 version, there is no need to perform a TLS handshake with the diagnosed node, but directly perform a routing activation request. In addition, the present application iteratively calculates the historical diagnostic response message data according to a preset probability algorithm while performing the TLS handshake, obtains the DoIP message or UDS message that is likely to be used, thereby establishing a preprocessing message group and encrypting the preprocessing message group. Then, during the subsequent diagnostic communication process, if the received encrypted data can exactly match the data in the preprocessing message group, the message in the preprocessing message group is directly used without re-decrypting or encrypting and calculating, which not only ensures the security requirements but also improves the TLS security encryption speed as much as possible.

[0099] The technical solution of the present invention is an implementation of the current mainstream in-vehicle Ethernet technology. Based on the existing technology, it further deepens the use of DoIP and TLS technologies, optimizes the TLS security encryption speed, increases the speed limit during the in-vehicle Ethernet diagnosis application process, reduces the technical usage threshold, simplifies the usage process, and is also more suitable for the current mainstream trend of the rapid development of in-vehicle Ethernet technology. In addition, by continuously exploring, using, and summarizing new technologies, the coexistence of multiple diagnosed DoIP nodes can be tested through the server-client mode switch, which can better face the rapid development of the automotive industry in the future and better adapt to the market environment where more and more vehicle manufacturers use DoIP technology and multiple protocol versions coexist.

[0100] See Figure 10 As shown in the figure, the embodiments of the present application disclose a vehicle diagnostic communication method, which is applied to a diagnosed node. The method includes:

[0101] Step S41: After receiving the communication connection establishment request sent by the diagnostic device, establish a communication connection with the diagnostic device.

[0102] In this embodiment, the above communication connection may specifically be a TCP communication connection. The diagnostic device actively sends a TCP connection request message to the diagnosed node according to the project configuration. After receiving the message, the diagnosed node sends an acknowledgement message for the connection request message, and then continues to send a connection request message. After receiving the connection request message sent by the diagnosed node, the diagnostic device also needs to send an acknowledgement message for the connection request message. After that, the diagnostic device and the diagnosed node successfully establish a TCP communication connection.

[0103] Step S42: Send the vehicle declaration message to the diagnostic device, so that after the diagnostic device determines the DoIP protocol version of the diagnosed node according to the vehicle declaration message, it determines whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version.

[0104] In this embodiment, according to the DoIP protocol regulations, after being powered on and started, the diagnosed node actively sends a vehicle declaration message in a broadcast manner to send vehicle-related information. After obtaining the vehicle declaration message, the diagnostic device needs to parse out the required vehicle-related information to determine the current DoIP protocol version used by the diagnosed node, and determine whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version. That is, in this application, the diagnostic device can perform corresponding processing according to different protocol versions used by the diagnosed node, so as to achieve the purpose of being compatible with multiple DoIP protocol versions.

[0105] Step S43: If so, after establishing a DoIP diagnostic connection with the diagnostic device and determining that a diagnostic flash needs to be performed currently, obtain the diagnostic request message sent by the diagnostic device, and reply with a corresponding response message to the diagnostic device, so that the diagnostic device matches each message in the encrypted message group with the response message; where the encrypted message group is obtained by the diagnostic device encrypting the preprocessed message group using the target key.

[0106] In this embodiment, if the diagnostic device determines that a TLS handshake needs to be performed with the diagnosed node according to the DoIP protocol version to obtain the target key, after the diagnosed node establishes a DoIP diagnostic connection with the diagnostic device and determines that a diagnostic flash needs to be performed currently, it obtains the diagnostic request message sent by the diagnostic device, and replies a corresponding response message to the diagnostic device based on the diagnostic request message, so that the diagnostic device can match each message in the encrypted message group with the response message. Among them, after the diagnostic device and the diagnosed node complete the TLS handshake, the diagnostic device needs to send a routing activation request to the diagnosed node. After the diagnosed node returns a routing activation response to the diagnostic, it indicates that the DoIP diagnostic connection is established. Further, by comparing whether the existing software version of the diagnosed node is consistent with the software version information in the upgrade software package, it is determined whether a diagnostic flash needs to be performed currently. It should be noted that the above encrypted message group is obtained by the diagnostic device encrypting the preprocessed message group with the target key.

[0107] Step S44: If there is a target message in the encrypted message group that matches the response message, the diagnostic device uses the target message as the response message, and after completing the verification of the response message, based on the connection disconnection request sent by the diagnostic device, disconnects the communication connection with the diagnostic device.

[0108] In this embodiment, if there is a target message in the encrypted message group that matches the response message, the diagnostic device can directly use the target message as the response message, that is, in this application, the diagnostic device can directly use the message result in the preprocessed message, thus skipping the cumbersome decryption process and not requiring re-decryption or encryption calculation, which speeds up the data parsing process during diagnosis. While ensuring security requirements, it also improves the TLS security encryption speed as much as possible. Finally, after completing the verification of the response message, the diagnostic device will send a connection disconnection request to the diagnosed node, so that after the diagnosed node responds to the connection disconnection request, it disconnects the communication connection with the diagnostic device to stop the communication.

[0109] It can be understood that according to the TCP protocol and DoIP protocol regulations, after all communications are completed, the diagnostic device needs to actively close the communication connection, which mainly includes sending an end request, receiving a request confirmation, receiving an end request, and sending a request confirmation. When the diagnostic device closes the connection, it needs to first send an end request message, and then wait for the request confirmation message returned by the diagnosed node for this end request. After receiving the request confirmation message, the diagnostic device continues to wait to receive the end request message actively sent by the diagnosed node. After receiving the end request message sent by the diagnosed node, the diagnostic device also needs to send an end request confirmation message according to the protocol requirements for confirmation response. After that, the diagnosed node will disconnect the connection, and the diagnostic device can also stop the communication.

[0110] It can be seen that after the diagnosed node is powered on and starts up, it will actively send a vehicle declaration message through broadcasting. After the diagnostic device obtains the vehicle declaration message, it can determine the DoIP protocol version used by the diagnosed node according to the vehicle declaration message, and then judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key according to the DoIP protocol version. That is, in the present application, the diagnostic device can perform corresponding processing according to different protocol versions used by the diagnosed node, so as to achieve the purpose of being compatible with multiple DoIP protocol versions. Further, if a TLS handshake is required, after establishing a DoIP diagnostic connection with the diagnostic device and determining that the current diagnosis and writing need to be performed, obtain the diagnostic request message sent by the diagnostic device, and reply a corresponding response message to the diagnostic device based on the diagnostic request message, so that the diagnostic device can match each message in the encrypted message group with the response message. The above encrypted message group is obtained by the diagnostic device encrypting the preprocessed message group using the target key. If there is a target message in the encrypted message group that matches the response message, the diagnostic device can directly use the target message as the response message, that is, the diagnostic device in the present application can directly use the message result in the preprocessed message, thus skipping the cumbersome decryption process and accelerating the data parsing process during diagnosis; finally, after completing the message verification, respond to the disconnection request sent by the diagnostic device and stop communicating with the diagnostic device.

[0111] See Figure 11 As shown, an embodiment of the present application discloses a vehicle diagnostic communication device, which is applied to a diagnostic device. The device includes:

[0112] A communication model switching module 11, configured to switch the current communication model to a target communication model matching the diagnosed node, and then establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model;

[0113] A judgment module 12, configured to determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version;

[0114] A response message matching module 13, configured to, if so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that the current diagnosis and writing need to be performed, encrypt the preprocessed message group using the target key to obtain an encrypted message group, and match each message in the encrypted message group with the response message sent by the diagnosed node;

[0115] A response message determination module 14, configured to, if there is a target message in the encrypted message group that matches the response message, use the target message as the response message, and after completing the verification of the response message, disconnect the communication connection with the diagnosed node.

[0116] It can be seen that in this application, after the diagnostic device switches the current communication model to a target communication model that matches the diagnosed node, a communication connection is established with the diagnosed node; wherein, the communication model includes a server model and a client model; the DoIP protocol version of the diagnosed node is determined according to the received vehicle declaration message, and it is determined whether a TLS handshake needs to be performed with the diagnosed node to obtain the target key based on the DoIP protocol version; if so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic rewrite needs to be performed currently, the preprocessed message group is encrypted with the target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node; if there is a target message in the encrypted message group that matches the response message, the target message is used as the response message, and after completing the verification of the response message, the communication connection with the diagnosed node is disconnected. Thus, it can be seen that the diagnostic device in this application can switch the current communication model to a target communication model that matches the diagnosed node, thereby realizing the switch between the server model and the client model; in addition, after the diagnostic device obtains the vehicle declaration message, it can determine the DoIP protocol version used by the diagnosed node according to the vehicle declaration message, and thus determine whether a TLS handshake needs to be performed with the diagnosed node to obtain the target key based on the DoIP protocol version, that is, this application can perform corresponding processing according to different protocol versions used by the diagnosed node, so as to achieve the purpose of being compatible with multiple DoIP protocol versions. Further, if a TLS handshake is required, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic rewrite needs to be performed currently, the preprocessed message group is encrypted with the obtained target key to obtain an encrypted message group, and each message in the encrypted message group is matched with the response message sent by the diagnosed node. If there is a target message in the encrypted message group that matches the response message, the target message can be directly used as the response message, that is, this application can directly use the message result in the preprocessed message, thereby skipping the cumbersome decryption process and accelerating the data parsing process during diagnosis; finally, after completing the message verification, the communication connection with the diagnosed node is disconnected and the communication is stopped.

[0117] Figure 12A schematic structural diagram of an electronic device provided by an embodiment of the present application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the vehicle diagnostic communication method executed by the electronic device disclosed in any of the foregoing embodiments.

[0118] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows is any communication protocol applicable to the technical solution of the present application, and no specific limitation is imposed on it here; the input / output interface 25 is used to obtain external input data or output data to the outside, and its specific interface type can be selected according to specific application needs, and no specific limitation is made here.

[0119] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor used to process data in the wake state, also known as the CPU (Central Processing Unit); the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, and the AI processor is used to process computational operations related to machine learning.

[0120] In addition, the memory 22, as a carrier for resource storage, may be a read-only memory, a random access memory, a disk, or an optical disc, etc. The resources stored thereon include an operating system 221, a computer program 222, and data 223, etc., and the storage method may be short-term storage or permanent storage.

[0121] Among them, the operating system 221 is used to manage and control each hardware device and computer program 222 on the electronic device 20, so as to implement the operation and processing of the massive data 223 in the memory 22 by the processor 21. It can be Windows, Unix, Linux, etc. In addition to the computer program that can be used to complete the vehicle diagnostic communication method executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs that can be used to complete other specific tasks. The data 223 may include not only the data transmitted by external devices received by the electronic device, but also the data collected by its own input / output interface 25, etc.

[0122] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium, in which a computer program is stored. When the computer program is loaded and executed by a processor, the method steps executed during the vehicle diagnostic communication disclosed in any of the foregoing embodiments are implemented.

[0123] In this specification, the various embodiments are described in a progressive manner. The key point of each embodiment is the difference from other embodiments. The same or similar parts among the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0124] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this document can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0125] The steps of the method or algorithm described in combination with the embodiments disclosed in this document can be directly implemented by hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, or any other form of storage medium well-known in the technical field.

[0126] Finally, it should also be noted that in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising said element.

[0127] The above has introduced in detail a vehicle diagnostic communication method, apparatus, device and storage medium provided by the present invention. Specific examples are used in this text to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only for helping to understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A vehicle diagnostic communication method, characterized in that, Applied to a diagnostic device, including: After switching the current communication model to a target communication model that matches the diagnosed node, establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model; Determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and determine whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version; If so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash needs to be performed currently, encrypt the preprocessed message group with the target key to obtain an encrypted message group, and match each message in the encrypted message group with the response message sent by the diagnosed node; If there is a target message in the encrypted message group that matches the response message, use the target message as the response message, and after completing the verification of the response message, disconnect the communication connection with the diagnosed node; Wherein, in the process of performing a TLS handshake with the diagnosed node to obtain the target key, it further includes: Obtain historical diagnostic response messages, and determine the usage probabilities of different message types in the historical diagnostic response messages according to a preset probability algorithm; wherein, the diagnostic messages include DoIP diagnostic response messages and UDS diagnostic response messages; Screen out the target response messages whose usage probabilities meet the preset probability conditions from the historical diagnostic response messages, and construct a preprocessed message group based on the target response messages.

2. The vehicle diagnostic communication method according to claim 1, wherein In the process of determining the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, it further includes: If the vehicle declaration message sent by the diagnosed node is not received, send a request message for obtaining the vehicle declaration message to the diagnosed node; After the diagnosed node responds to the request message, obtain the vehicle declaration message sent by the diagnosed node.

3. The vehicle diagnostic communication method according to claim 1, wherein The determination of whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version includes: Judge whether the DoIP protocol version is the current latest automotive Ethernet diagnostic standard; If it is the current latest automotive Ethernet diagnostic standard and it is determined that TSL security verification needs to be activated currently, perform a TLS handshake with the diagnosed node to obtain the target key; If it is not the current latest automotive Ethernet diagnostic standard, or if it is determined that TSL security verification does not need to be activated currently, it is determined that it is not necessary to perform a TLS handshake with the diagnosed node to obtain the target key.

4. The vehicle diagnosis communication method according to claim 1, wherein After the determination of whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version, it further includes: If not, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash needs to be performed currently, send a diagnostic request message to the diagnosed node, obtain the DoIP diagnostic response message returned by the diagnosed node, and then judge whether the DoIP diagnostic response message is a positive response; If the DoIP diagnostic response message is a positive response, obtain the UDS diagnostic response message returned by the diagnosed node; if the DoIP diagnostic response message is a negative response, end the diagnostic process. Judge whether the UDS diagnostic response message is a positive response. If the UDS diagnostic response message is a positive response, parse and verify the UDS diagnostic response message; if the UDS diagnostic response message is a negative response, end the diagnostic process.

5. The vehicle diagnostic communication method according to claim 1, wherein, The switching of the current communication model to the target communication model matching the diagnosed node includes: When the communication model type of the diagnosed node is the server model, and the target communication model matching the diagnosed node is the client model, switch the current communication model to the client model; When the communication model type of the diagnosed node is the client model, and the target communication model matching the diagnosed node is the server model, switch the current communication model to the server model.

6. The vehicle diagnostic communication method according to claim 1, wherein After establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash needs to be performed currently, it further includes: Send a diagnostic request message to the diagnosed node to obtain the encrypted DoIP diagnostic response message returned by the diagnosed node, and match each message in the encrypted message group with the DoIP diagnostic response message; If there is a first target message in the encrypted message group that matches the DoIP diagnostic response message, use the first target message as the DoIP diagnostic response message, and judge whether the DoIP diagnostic response message is a positive response; If the DoIP diagnostic response message is a positive response, obtain the encrypted UDS diagnostic response message returned by the diagnosed node, and match each message in the encrypted message group with the UDS diagnostic response message; if the DoIP diagnostic response message is a negative response, end the diagnostic process; If there is a second target message in the encrypted message group that matches the UDS diagnostic response message, use the second target message as the UDS diagnostic response message, and judge whether the UDS diagnostic response message is a positive response. If the UDS diagnostic response message is a positive response, parse and verify the UDS diagnostic response message; if the UDS diagnostic response message is a negative response, end the diagnostic process.

7. A vehicle diagnostic communication device, characterized in that, Applied to a diagnostic device, it includes: A communication model switching module, used to switch the current communication model to the target communication model matching the diagnosed node and then establish a communication connection with the diagnosed node; wherein, the communication model includes a server model and a client model; A judgment module, used to determine the DoIP protocol version of the diagnosed node according to the received vehicle declaration message, and judge whether it is necessary to perform a TLS handshake with the diagnosed node to obtain the target key based on the DoIP protocol version; A response message matching module, configured to, if so, after establishing a DoIP diagnostic connection with the diagnosed node and determining that a diagnostic flash needs to be performed currently, encrypt the preprocessed message group using the target key to obtain an encrypted message group, and match each message in the encrypted message group with the response message sent by the diagnosed node; A response message determination module, configured to, if there is a target message in the encrypted message group that matches the response message, use the target message as the response message, and after completing the verification of the response message, disconnect the communication connection with the diagnosed node; Wherein, the vehicle diagnostic communication device is further configured to obtain historical diagnostic response messages, and determine the usage probabilities of different message types in the historical diagnostic response messages according to a preset probability algorithm; wherein, the diagnostic messages include DoIP diagnostic response messages and UDS diagnostic response messages; screen out target response messages whose usage probabilities meet the preset probability conditions from the historical diagnostic response messages, and construct a preprocessed message group based on the target response messages.

8. A diagnostic device, characterized in that, Comprising: A memory, configured to store a computer program; A processor, configured to execute the computer program to implement the steps of the vehicle diagnostic communication method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, For storing a computer program; wherein, when the computer program is executed by the processor, the steps of the vehicle diagnostic communication method according to any one of claims 1 to 6 are implemented.

Images