Communication message processing method and processing device

Abstract

The present application relates to the field of communication technology, and provides a communication message processing method and processing device. The method obtains a target message sent by or to a target client through a server, and when it is determined that the target message is an illegal message, searches for the associated message data of the target message from the adjacent messages of the target message, and after finding and obtaining the associated message data, determines the updated target message at least based on the associated message data, thereby avoiding the failure of all client services caused by directly resetting the server when receiving an illegal message, and can autonomously repair some erroneous target messages, thereby improving the stability of message processing and the processing efficiency.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication message processing method and processing device. Background Art

[0002] As smart cars become more and more versatile, the number of electronic control units (ECUs) in the vehicle system is increasing, the functions are becoming more complex and richer, and the function update cycle is becoming more frequent. ECU upgrades can be performed using Over-the-Air Technology (OTA), but OTA upgrades take a lot of time. If serial upgrades are used, they take a lot of time and cannot truly meet the car owner's car needs and experience. If parallel upgrades are used, the upgrade time can be greatly saved, but if the Internet Diagnostic Protocol (Diagnostic communication over Internet Protocol, DoIP) server receives an abnormal message from a client during parallel upgrades, the DoIP server will reset, which will cause all clients to fail to upgrade due to the reset of the DoIP server. Summary of the invention

[0003] In view of this, an embodiment of the present application provides a communication message processing method and processing device to solve the problem in the prior art that when multiple clients process services in parallel through a server, a message error of a single client may cause the failure of all client services.

[0004] In a first aspect of an embodiment of the present application, a communication message processing method is provided, the method being executed by a server, the server being connected to at least one client, the method comprising:

[0005] receiving a target message, where the target message is a request message sent by a target client to a server, and the target client is any client among the at least one client;

[0006] In response to determining that the target message is an illegal message, searching for associated message data of the target message in adjacent messages of the target message, where the associated message data includes a legal message header or legal message data of the target message;

[0007] In response to finding the associated message data, an updated target message is determined based at least on the associated message data.

[0008] A second aspect of an embodiment of the present application provides a communication message processing device, including:

[0009] A receiving module is configured to receive a target message, where the target message is a request message sent by a target client to a server, where the server is connected to at least one client, and the target client is any one of the at least one client;

[0010] A search module, configured to search for associated message data of the target message in adjacent messages of the target message in response to determining that the target message is an illegal message, wherein the associated message data includes a legal message header or legal message data of the target message;

[0011] The processing module is configured to determine an updated target message based at least on the associated message data in response to the associated message data being found.

[0012] The beneficial effects of the embodiments of the present application compared with the prior art are as follows: the embodiments of the present application obtain a target message sent by or to a target client through a server, and when determining that the target message is an illegal message, search for associated message data of the target message from adjacent messages of the target message, and after finding and obtaining the associated message data, determine an updated target message at least based on the associated message data, thereby avoiding the failure of all client services caused by directly resetting the server when an illegal message is received, and being able to autonomously repair some erroneous target messages, thereby improving the stability of message processing and improving processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0014] Figure 1 It is a flow chart of a multi-client communication message processing method provided in an embodiment of the present application.

[0015] Figure 2 It is a system structure that implements vehicle OTA download.

[0016] Figure 3 It is a schematic diagram of a method in which VGW communicates with multiple CDCs to perform OTA upgrades on multiple ECUs in parallel.

[0017] Figure 4 It is a schematic diagram of a VGW reset method in the related art when the VGW communicates with multiple CDCs to perform OTA upgrades on multiple ECUs in parallel.

[0018] Figure 5 It is an interaction diagram of VGW communicating with multiple CDCs to perform OTA upgrades on multiple ECUs in parallel.

[0019] Figure 6 It is a flow chart of another multi-client communication message processing method provided in an embodiment of the present application.

[0020] Figure 7 It is a schematic diagram of a method for establishing a communication connection between a server and a client provided in an embodiment of the present application.

[0021] Figure 8 A schematic diagram of the format of a DoIP message provided in an embodiment of the present application.

[0022] Fig. 9 It is a schematic diagram of a communication message processing device provided in an embodiment of the present application.

[0023] Fig.10 It is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0025] A multi-client communication message processing method and device according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0026] As mentioned above, when a vehicle includes many ECUs, parallel upgrades for multiple ECUs that need OTA upgrades can greatly save upgrade time. However, during parallel upgrades, multiple clients communicate with the server through the same socket (SOCKET). If the DoIP server receives an abnormal message from a client, the DoIP server will first close the SOCKET and then reset it, which will cause all clients to fail to upgrade due to the reset of the DoIP server.

[0027] In view of this, an embodiment of the present application provides a multi-client communication message processing method, which obtains a target message sent by a target client or sent to a target client through a server, and when it is determined that the target message is an illegal message, searches for associated message data of the target message from adjacent messages of the target message, and after finding the associated message data, determines an updated target message at least based on the associated message data, thereby avoiding the failure of all client services caused by directly resetting the server when an illegal message is received, and can autonomously repair some erroneous target messages, thereby improving the stability of message processing and improving processing efficiency.

[0028] Figure 1 FIG. 1 is a flow chart of a multi-client communication message processing method provided in an embodiment of the present application. Figure 1 As shown, the method comprises the following steps:

[0029] In step S101, a target message is received.

[0030] The target message is a request message sent by a target client to a server, and the target client is any client among the at least one client.

[0031] In step S102, in response to determining that the target message is an illegal message, the associated message data of the target message is searched in adjacent messages of the target message.

[0032] The associated message data includes a legitimate message header of the target message or legitimate message data of the target message.

[0033] In step S103, in response to obtaining the associated message data through searching, an updated target message is determined based at least on the associated message data.

[0034] In some implementations, the method may be performed by a server. The server may be connected to one or more clients, receive messages sent by the one or more clients, or send messages to the one or more clients. When there are multiple clients, the multiple clients may process services in parallel through the server.

[0035] The server may receive a target message, which may be a request message sent by a target client to the server.

[0036] After receiving the target message, the server can perform a legitimacy check on the target message, such as checking whether the target message includes an illegal message header, or checking whether the payload data length of the target message is consistent with the payload length recorded in the message header of the target message.

[0037] In the related art, when the server detects and determines that the target message is an illegal message, the server will send a negative response NACK message to the client, disconnect the SOCKET connection between the server and the client, and then perform a reset operation on the server. However, when the server is connected to multiple clients and the multiple clients communicate with the server through the same SOCKET, when a message from a client is abnormal, the server is immediately disconnected from the SOCKET and then reset, which will cause all clients connected to the server to fail to perform services correctly. On the other hand, even if the server is currently only connected to a single client, the abnormal message may be caused by "sticky packets" in the communication, that is, part of the information of the current message is transmitted in the previous message, or the abnormal message may be a small amount of erroneous data, and the correct message may be transmitted immediately in the subsequent message. At this time, the correct target message can still be obtained by reasonably parsing and reorganizing the received data packets through information features, and there is no need to immediately perform a reset operation on the server, which leads to a longer process and a waste of resources.

[0038] Therefore, in certain embodiments of the present application, when it is detected that the target message is an illegal message, there is no need to immediately perform a reset operation on the server. Instead, the associated message data of the target message can be first searched in the adjacent messages of the target message, and then it can be determined whether a reset operation needs to be performed on the server based on the search results.

[0039] In some implementations, if the associated message data is obtained by searching in the adjacent messages of the target message, the target message can be determined based on at least the associated message data. For example, if the associated message data is a legitimate message header of the target message, and it immediately follows the complete message payload data, the associated message data and its subsequent message payload data can be used as an updated target message as a whole, so that the server can parse or forward the target message. For another example, if the associated message data is partial payload data of the target message, the associated message data can be assembled with the message header and other partial payload data received by the server, including the target message, to obtain a complete and correct target message, so that the server can parse or forward the target message.

[0040] According to the technical solution provided in the embodiment of the present application, a target message sent by or to a target client is obtained through a server. When it is determined that the target message is an illegal message, the associated message data of the target message is searched from adjacent messages of the target message. After the associated message data is found, an updated target message is determined at least based on the associated message data. This avoids the failure of all client services caused by directly resetting the server when an illegal message is received, and is able to autonomously repair some erroneous target messages, thereby improving the stability of message processing and the processing efficiency.

[0041] In some embodiments, the client may be an OTA master controller (UMC) for vehicle OTA upgrades, such as a telematics box (TBOX) or a cockpit domain controller (CDC). The server may be a vehicle gateway (VGW) or a vehicle integration unit (VIU) for an OTA upgrade agent (UA). The UMC is connected to the UA via Ethernet, and the UA is connected to each ECU in the vehicle as an OTA upgrade slave (US) via a controller area network (CAN).

[0042] Figure 2 It is the system structure that realizes vehicle OTA download. Figure 2 As shown, the CDC as UMC connects to the network access point (APN) of the private network through the 4G or 5G network to download the OTA upgrade data package from the cloud. The UMC is connected to the VGW as the UA through Ethernet (ETH), and the UA is connected to each ECU mounted under it as the US through the CAN bus. Among them, ECU1 to ECUm, and ECUm+1 to ECUn are all ECUs mounted under the VGW, m and n are both positive integers, and n is greater than m.

[0043] Figure 3 This is a schematic diagram of a method in which VGW communicates with multiple CDCs to perform OTA upgrades on multiple ECUs in parallel. Figure 3 As shown in the figure, VGW can be connected to n CDCs through the same SOCKET, and each CDC sends a DoIP message carried in an Ethernet message to VGW. After VGW converts the n DoIP messages into Unified Diagnostic Services (UDS) messages, it forwards the UDS messages to n ECUs through the CAN bus, so that each ECU can perform OTA upgrade based on the received messages.

[0044] Among them, the DoIP message generated by each CDC may include a message header, which includes at least a protocol version and a protocol version inverse. For a DoIP message, the protocol version may be, for example, 0x02, and the protocol version inverse may be, for example, 0xfd. Furthermore, the message header may also include a load type, for example, 0x8001. The specific value of the load type field is described in detail below and will not be repeated here.

[0045] Furthermore, the DoIP message may also include fields such as payload length, source address, and destination address. In the DoIP message generated by each CDC, the payload length field can be represented by LEN, the source address is the address of each CDC, such as C1, C2, ..., Cn, etc., and the destination address is the address of each ECU, such as ECU1, ECU2, ..., ECUn, etc. Among them, for OTA upgrade messages, C1, C2, ..., Cn in the DoIP request message can be the same, all of which are the addresses of the OTA upgrade master.

[0046] In the UDS message forwarded by the VGW to each ECU, the target address may be the address of each ECU, such as ECU1, ECU2, ..., ECUn, etc.

[0047] That is to say, when the OTA master controller is upgrading and flashing the target ECU, the OTA master controller establishes a TCP communication connection with the VGW, the VGW parses the target ECU address of the message, converts the UDS message through the ETH message format, and forwards the message to the target ECU for data communication and upgrading and flashing. During parallel upgrading, multiple OTA masters establish the same TCP communication connection with the VGW, which means that the VGW needs to timely and correctly parse and process the data transmitted by each OTA master controller at the same time, and forward the data to the target ECU that does not support Ethernet for upgrading and flashing.

[0048] Figure 4 Schematic diagram of a VGW reset method in the related art when the VGW communicates with multiple CDCs to perform OTA upgrades on multiple ECUs in parallel. Figure 4 As shown, after receiving the DoIP message sent by the CDC, the VGW first performs a legitimacy check on the message, such as a general message header format check. If the check determines that the message header is an illegal message header, the VGW sends a negative response NACK to the client, immediately disconnects the SOCKET connection with the client, and then performs a VGW reset operation.

[0049] Figure 5 This is an interactive diagram of VGW communicating with multiple CDCs to perform OTA upgrades on multiple ECUs in parallel. Figure 5As shown, the CDCDoIP client can establish a communication connection with the VGW DoIP server through vehicle body discovery. When the CDC OTA application server determines that one or some services of the vehicle need to be upgraded OTA, it sends a message to select the vehicle body to the CDC DoIP client. The CDC DoIP client sends a request to establish a TCP data transmission (TCP_DATA) connection to the VGW DoIP server, and the VGW DoIP server performs the connection initialization operation. The CDC DoIP client also needs to send a route activation request to the VGW DoIP server. After completing the route activation, the VGW DoIP server sends a route activation response to the CDC DoIP client. After receiving the route activation response, the CDCDoIP client forwards the connection success response message to the CDC OTA application service, and then the OTA upgrade operation can be performed.

[0050] During OTA upgrade, each end needs to perform the following polling session: the CDC OTA application service sends a "36 xxxxxxxx" request to the CDC DoIP client. In the "36 xxxxxxxx" request, "36" is used to indicate an OTA upgrade, and "xxxxxxxx" is the upgrade information. After receiving the request, the CDC DoIP client sends a DoIP request message to the VGW DoIP server. The payload type field in the DoIP request message is 0x8001. After receiving the DoIP request message, the VGW DoIP server performs a validity check on the message header and replies the check result to the CDC DoIP client through a DoIP confirmation response message. In the message of the DoIP confirmation response message, the payload type field can be 0x8002 or 0x8003. When it is 0x8002, it indicates that the check result is normal and this response is a positive response. When it is 0x8003, it indicates that the inspection result is abnormal and this response is a negative response. The message needs to be processed, such as retransmitting the DoIP request message or reorganizing the DoIP request message, until this response is a positive response.

[0051] Next, the VGW DoIP server can first send the first frame (FF) data to the target ECU, which is an ECU that cannot serve as a DoIP server. The target ECU can send a flow control (FC) message to the VGW DoIP server to enable the VGW DoIP server to control the data flow sent. After that, the VGW DoIP server can send multiple continuous frames (CF) to the target ECU until the target ECU completes the OTA upgrade and sends the OTA upgrade response to the VGW DoIP server. To avoid timeout, the VGW DoIP server can also periodically send a response message "NRC78: 7F 36 78" to the CDC DoIP client after sending FF to the target ECU and before receiving the OTA upgrade response. The response message indicates that the current response is a negative response, but the negative response is not caused by abnormal business execution, but the business has not been completed. Further, the CDC DoIP client can forward the received response message "NRC78: 7F 36 78" to the CDC OTA application service.

[0052] After receiving the OTA upgrade response message sent by the target ECU, the VGW DoIP server can send a DoIP response message to the CDC DoIP client. The payload type field in the DoIP response message can be 0x8001. After receiving the DoIP response message, the CDC DoIP client sends an OTA upgrade result response to the CDC OTA application service. At this point, this round of OTA upgrade polling is completed.

[0053] After this round of OTA upgrade is completed, the CDC OTA application service sends an OTA upgrade completion message to the CDC DoIP client. After receiving the OTA upgrade completion message, the CDC DoIP client sends a close TCP communication message to the VGW DoIP server. After receiving the close TCP communication message, the VGW DoIP server ends this round of session with the CDC DoIP client.

[0054] That is, one or more clients establish a TCP connection with the server. After the TCP connection is successful, the DoIP routing is activated. After the activation is successful, the DoIP communication phase begins. When the client and the server communicate with each other through DoIP, the server first performs a legitimacy check on the DoIP message of the client. If it passes, the communication is normal. If it fails, a negative response NACK is sent to the client. The VGW can perform a reset operation based on the received NACK signal. When the VGW is reset, the communication between the VGW and all clients is interrupted.

[0055] In some embodiments of the present application, the VGW DoIP server can perform a message legitimacy check on the received DoIP request message. When the check determines that the message is illegal, the legitimate message header or message data of the DoIP message is searched from the adjacent messages including the illegal DoIP message. If the legitimate message header or message data of the DoIP message can be found, the DoIP message can be reassembled to continue the subsequent process. Otherwise, if the legitimate message of the DoIP message cannot be found, it is necessary to use different methods to handle the abnormal DoIP message according to the number of CDC DoIP clients that have established a communication connection with the VGW DoIP server.

[0056] Figure 6 : is a flowchart of another multi-client communication message processing method provided in an embodiment of the present application. Figure 6 Steps S601 to S603 in the embodiment shown are Figure 1 Steps S101 to S103 in the illustrated embodiment are substantially the same and will not be described in detail herein. Figure 6 As shown, the method also includes the following steps:

[0057] In step S604, in response to not finding the associated message data, the client connection count of the server is obtained.

[0058] In step S605, in response to determining that the client connection count of the server is greater than 1, a request message sent again by the target client after determining that the response has timed out is received.

[0059] In some embodiments of the present application, when no associated message data is found in adjacent messages of the target message, a client connection count of the server can be obtained. The client connection count is used to represent the number of clients that have established communication connections with the server.

[0060] That is to say, the server can maintain the client information connected to it. For example, the server can maintain a record status table, which records the connection information of each client that has established a communication connection with the server, and the number of clients that have currently established a communication connection with the server. When a client establishes a communication connection with the server, the server saves the connection information of the client and the server in the record status table, and adds 1 to the client connection count in the record status table. When a client disconnects the communication connection with the server, the server deletes the connection information of the client and the server from the record status table, and subtracts 1 from the client connection count in the record status table.

[0061] The connection information may include, for example, a server identification (ID), a connection status, a source address, a destination address, a source port, a destination port, a client connection number, etc. Furthermore, the record status table may be stored locally on the server, in the cloud, or in other storage media accessible to the server.

[0062] If the obtained client connection count is greater than 1, it indicates that there are other clients currently connected to the server. Therefore, the server can be temporarily reset without resetting it. Instead, the target client can wait for the target client to send a request message again after the response timeout. The server receives the request message sent again, executes the request in the message, and sends a response message to the target client after the execution.

[0063] If this operation can be performed normally, it means that the communication between the server and the target client has been restored to normal, and the server can process the messages from each server normally. Otherwise, if the server still encounters an abnormality when processing the request message sent by the target client again, you can wait until the client connection count decreases to 1 to reset the server. At this time, since other clients connected to the server have completed the service, resetting the server will not affect other clients, thereby improving the overall service execution efficiency.

[0064] Furthermore, Figure 6 The illustrated embodiment also includes the following steps:

[0065] In step S606, in response to determining that the client connection count of the server is equal to 1, a reset operation is performed on the server.

[0066] As mentioned above, when it is determined that the client connection count of the server is equal to 1, other clients connected to the server have completed the service and disconnected the communication with the server. Therefore, a reset operation can be performed on the server to restore the communication connection between the server and the target client, and then execute the service of the target client.

[0067] For example, if the client is the CDC used as the main controller of the vehicle OTA upgrade and the server is the VGW used as the OTA upgrade agent, when the associated message data is not found, the VGW can obtain the client connection count from the record status table it maintains, and when it is determined that the client connection count is greater than 1, it does not perform the reset operation of the VGW, but waits to receive the request message sent by the CDC again after the connection timeout, which is the DoIP request message of the OTA upgrade of the corresponding round of the target message. On the other hand, if the CGW determines that the client connection count is equal to 1, it can directly perform the reset operation on the VGW.

[0068] Figure 7Schematic diagram of a method for establishing a communication connection between a server and a client provided in an embodiment of the present application. Figure 7 As shown, the CDC as UMC may include n OTA upgrade clients, each of which may include a DoIP protocol stack and a client UDP / TCP socket SOCKET. Furthermore, the CDC also includes an IP layer, a link layer (Medium Access Control, MAC) and a physical layer PHY.

[0069] On the other hand, the VGW as a UA may include an OTA proxy, DoIP, and a server UDP / TCP SOCKET. The VGW also includes an IP layer, a MAC layer, and a PHY layer.

[0070] Whenever the server establishes a connection with a client, it records the connection information in Figure 7 The record status table is shown, and the client connection count in the record status table is increased by 1. If a client disconnects from the server, the client connection number and its corresponding "server ID, connection status, source address, destination address, source port, destination port" and other contents are deleted, and the client connection count is reduced by 1.

[0071] If there are multiple clients connected to the server, and the server checks a message sent by a client and determines that its message header is an illegal message header, that is, it is not "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003", then the server can first check in the adjacent message whether it contains the message header tag "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003". Or, when the server checks a message sent by a client and determines that the payload data length of the message is less than the payload length recorded in the message header, the server can check in the subsequent adjacent message to confirm whether the lost payload data is in the subsequent adjacent message.

[0072] For example, when the target message includes an illegal message header, the tail of the adjacent client data message, that is, the message of the current connection message to the front message can be checked to see if the message of the maximum preset number of bytes contains the message header mark of "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003". If so, it is considered that the communication has a "sticky packet" problem. These data are the communication data of this time. The field after "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003" is "payload length". 0x02, 0xfd, 0x8001 / 0x8002 / 0x8003 is taken out, and the complete data of this message is obtained by splicing with the payload length and the message data, and then forwarded to the target ECU. Among them, the message data is the message data immediately after the payload length and the length is equal to the payload length. The payload length is a field in the DoIP message, including the upgrade data packet length and the four-byte ECU address length.

[0073] For another example, when the target message includes an illegal message header, if the forward search does not get "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003", you can also search the received message backward for the "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003" mark. If found, these data are the current communication data, and the field after "0x02, 0xfd, 0x8001 / 0x8002 / 0x8003" is "payload length". Take out 0x02, 0xfd, 0x8001 / 0x8002 / 0x8003, concatenate it with the payloadlength and the message data to get the complete data of this message, and forward it to the target ECU.

[0074] For another example, if the actual payload length of the target message is less than the payload length recorded in the target message, n bits of data can also be searched backwards, where the value of n can be the difference between the payload length recorded in the target message and the actual payload length of the target message, and n is a positive integer. For example, if the payload length recorded in the payload length field of the target message is 100 bits, and the actual payload length of the currently received target message is 95 bits, 5 bits can be searched backwards.

[0075] Furthermore, the end of the payload data may carry verification information. For example, in an upgrade data packet of the payload data, the last two bits may be used to record verification information. The verification information may be, for example, the sum of all payload data except the verification information, or other values ​​calculated from all payload data except the verification information. After searching backwards for n bits of data, the other data in the n bits of data except the verification information may be subjected to a preset operation with the payload data in the target message, and then the operation result may be compared with the verification information in the n bits of data. If the comparison result is consistent, it may be determined that the n bits of data are associated message data.

[0076] If the forward and backward search fails, the client connection count can be checked in the record status table to see if it is greater than 1. If it is greater than 1, the VGW reset operation is not performed to ensure that other clients can communicate and transmit data normally. If it is determined that the obtained client connection count is equal to 1, the VGW is directly reset.

[0077] In some embodiments of the present application, searching for associated message data of a target message in an adjacent message of a target message may be, in response to determining that the target message includes an illegal message header, in a previous message adjacent to the target message, searching forward from the end of the message for a first preset data segment; in response to searching for a legal message header of the target message in the first preset data segment, determining that the legal message header is associated message data. Alternatively, in response to determining that the target message includes an illegal message header, in a subsequent message adjacent to the target message, searching backward for a second preset data segment; in response to searching for a legal message header of the target message in the second preset data segment, determining that the legal message header is associated message data. Alternatively, in response to determining that the payload length of the received target message is less than the payload length recorded in the target message, in a subsequent message adjacent to the target message, searching backward for a third preset data segment to obtain associated payload data and verification information; in response to determining that the associated payload data and the payload data in the target message satisfy the verification information, determining that the associated payload data and the verification information are associated message data.

[0078] That is, the first preset data segment can be queried from the end of the preceding message in the preceding message of the target message to find out whether the associated message data is included therein. The first preset data segment can be set according to actual needs, for example, to 64 bytes, or 32 bytes, or other values.

[0079] On the other hand, the second preset data segment can also be queried in the latter segment of the target message from the message header of the latter segment to find out whether the associated message data is included therein. The second preset data segment can be set according to actual needs. It is understandable that, in order to avoid wasting resources, the second preset data segment can be set to be smaller than the difference between the total message length of the latter segment and the message header length.

[0080] On the other hand, the third preset data segment can also be queried from the beginning to the end in the subsequent message of the target message to find out whether the associated data message is included therein. The third preset data segment can be the difference between the load length recorded in the target message and the actual load length of the target message.

[0081] In some embodiments of the present application, the target message also includes at least a protocol version field and a load type field. Further, the illegal message header of the target message may include at least one of the following situations: the message header of the target message is at least partially missing, the protocol version field of the target message is inconsistent with the preset message protocol version, and it is determined that the load type field of the target message does not belong to any of the preset load type values.

[0082] Among them, the preset load type value of the load type field of the target message may include a first value, a second value and a third value, the first value is used to characterize the target service corresponding to the target message, the second value is used to characterize that the target service request is correctly responded to, and the third value is used to characterize that the target service request is abnormally responded to.

[0083] Furthermore, the third value may be configured to have N different values, and each third value is used to represent a type of abnormal response, that is, different third values ​​correspond to different abnormal responses. N is a positive integer.

[0084] Still taking the case where the client is the CDC used as the vehicle OTA upgrade master, the server is the VGW used as the OTA upgrade agent, and the target message is a DoIP message, Figure 8 The format diagram of the DoIP message provided in the embodiment of the present application is shown in FIG. Figure 8 As shown, the DoIP message may include an Ethernet message header ETH header (EthHead), an Internet Protocol (IP) message header IP header (IPHead), and the IPHead may further include a source IP and a destination IP, a Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) message header, a data field, and a cyclic redundancy check (CRC) bit.

[0085] The data field may include the protocol version of the DoIP message, the inverse of the protocol version, the payload type, the payload length, and the DoIP data. The Protocol version and the Protocol version may occupy one byte respectively, the payload type may occupy two bytes, and the payload length may occupy four bytes of the message.

[0086] Further, when the message is a DoIP message, Protocol version can be 0x02, and Protocol version can be 0xfd. Payload type can be configured as a first value 0x8001, a second value 0x8002, and a third value 0x8003, corresponding to DoIP transmission request, DoIP positive response, and DoIP negative response, respectively. In some embodiments, the third value of payload type can also be configured to have multiple different values, such as configuring 0x00~0x01 and 0x09~0xFF as reserved values, 0x02 represents an invalid source address, 0x03 represents an unknown target address, 0x04 represents a diagnostic message that is too large, 0x05 represents insufficient memory, 0x06 represents an inaccessible target device, 0x07 represents an unknown network, and 0x08 represents a transmission protocol error. Each third value corresponds to a negative response type, so that different types of negative responses can be better distinguished, helping users quickly locate the cause of communication failure, and assisting in completing repairs.

[0087] The DoIP data may include the ECU source address, ECU destination address and upgrade data packet. The ECU source address is the address of the OTA master ECU, i.e., CDC, and the ECU destination address is the address of the target ECU to be upgraded. The ECU source address and ECU destination address may occupy 2 bytes respectively. Furthermore, the last 2 bits of the upgrade data packet may be used to transmit verification information.

[0088] When the DoIP message is a request message, in addition to EthHead, IPHead and TCP / UDPHead, the message may also include the vehicle Ethernet communication protocol (Scalable service-Oriented MiddlewarE over IP, SOME / IP) or DoIP message header, source address SA, destination address TA and data domain. Among them, the logical address can be stored in SA and TA, and the UDS data can be stored in the data domain. The request message can be converted by the upgrade agent into a CAN message that can be parsed by the upgrade slave control. The CANID in the CAN message is the request ID. The CAN message also includes the data length DLC field, the protocol control information DoCAN PCI field for CAN to implement UDS diagnosis, and UDS data. Among them, CANID is consistent with TA in the DoIP message.

[0089] When the DoIP message is a response message, it is converted from the CAN message. The formats of the response DoIP message and the CAN message are basically the same as the request message, except that the CANID in the CAN message is the response ID, and the response ID is consistent with the SA in the DoIP message.

[0090] By adopting the technical solution provided in the embodiment of the present application, it is possible to implement parallel upgrade and flashing of DoIP. When the DoIP server receives a DoIP message and determines that an abnormal message header has appeared after message parsing, it queries if there are other clients communicating and transmitting messages with the server, and does not perform an immediate reset operation to ensure normal communication of other clients. This message searches for a legitimate message header in the front and back segments of the received message. If so, the message is reassembled, and the message is not discarded, and a retransmission operation is performed. This ensures that the message transmission of other clients is not affected, and the message of this client may also be repaired and reassembled, greatly improving the efficiency of upgrade and flashing.

[0091] The technical solution provided in the embodiment of the present application aims at the situation that multiple clients simultaneously send data packets to each target ECU, which may "cross each other" and cause illegal data packets. The data packets are reassembled and parsed according to the characteristic information, and the data of each data packet is repaired so that the data is complete, thereby improving the message processing efficiency. Furthermore, when the server receives an unexpected header tag message to query the client and there are still multiple clients, it does not need to reset and continue to receive messages to ensure the continued upgrade transmission of OTA upgrades, thereby ensuring the stability of multi-client message processing and improving the processing success rate.

[0092] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present application, which will not be described one by one here.

[0093] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0094] Fig. 9 Schematic diagram of a communication message processing device provided in an embodiment of the present application. Fig. 9 As shown, the device comprises:

[0095] The receiving module 901 is configured to receive a target message, where the target message is a request message sent by a target client to a server, where the server is connected to at least one client, and the target client is any one of the at least one client.

[0096] The search module 902 is configured to search for associated message data of the target message in adjacent messages of the target message in response to determining that the target message is an illegal message, wherein the associated message data includes a legal message header of the target message or legal message data of the target message.

[0097] The processing module 903 is configured to determine, in response to obtaining the associated message data through searching, an updated target message at least based on the associated message data.

[0098] According to the technical solution provided in the embodiment of the present application, a target message sent by or to a target client is obtained through a server. When it is determined that the target message is an illegal message, the associated message data of the target message is searched from adjacent messages of the target message. After the associated message data is found, an updated target message is determined at least based on the associated message data. This avoids the failure of all client services caused by directly resetting the server when an illegal message is received, and is able to autonomously repair some erroneous target messages, thereby improving the stability of message processing and the processing efficiency.

[0099] In some embodiments, the device also includes a determination module 904, which is configured to obtain the client connection count of the server in response to not finding the associated message data; in response to determining that the client connection count of the server is greater than 1, receive the request message sent again by the target client after determining that the response has timed out.

[0100] In some embodiments, the determination module 904 is further configured to, in response to determining that the client connection count of the server is equal to 1, perform a reset operation on the server.

[0101] In some embodiments, determining that the target message is an illegal message includes: in response to the target message including an illegal message header, determining that the target message is an illegal message; or in response to determining that the payload length of the received target message is less than the payload length recorded in the target message, determining that the target message is an illegal message.

[0102] In some embodiments, searching for associated message data of a target message in adjacent messages of the target message includes: in response to determining that the target message includes an illegal message header, in a previous message adjacent to the target message, querying a first preset data segment forward from the end of the message; in response to finding a legal message header of the target message in the first preset data segment, determining that the legal message header is the associated message data; or in response to determining that the target message includes an illegal message header, in a subsequent message adjacent to the target message, querying a second preset data segment backward; in response to finding a legal message header of the target message in the second preset data segment, determining that the legal message header is the associated message data; or in response to determining that the payload length of the received target message is less than the payload length recorded in the target message, in a subsequent message adjacent to the target message, querying a third preset data segment backward to obtain associated payload data and verification information; in response to determining that the associated payload data and the payload data in the target message satisfy the verification information, determining that the associated payload data and the verification information are the associated message data.

[0103] In some embodiments, the target message also includes at least a protocol version field and a load type field; the illegal message header included in the target message includes at least one of the following situations: the message header of the target message is at least partially missing; the protocol version field of the target message is inconsistent with the preset message protocol version; the load type field of the target message does not belong to any of the preset load type values.

[0104] In some embodiments, the preset load type value of the load type field of the target message includes: a first value used to characterize the target service corresponding to the target message; a second value used to characterize that the target service request is responded to correctly; and a third value used to characterize that the target service request is responded to abnormally.

[0105] In some embodiments, an updated target message is determined based at least on associated message data, including: in response to the associated message data being a legal message header, combining the legal message header and its data of an immediately subsequent target length to obtain an updated target message, wherein the target length is the load length recorded in the legal message header; in response to the associated message data being associated load data and verification information, combining the target message with the associated load data and verification information to obtain an updated target message.

[0106] In some embodiments, the client connection count of the server is maintained in the following manner: in response to determining that a first client has established a communication connection with the server, the connection information of the first client and the server is saved in a record status table, and an operation of adding 1 is performed on the client connection count in the record status table; in response to determining that a second client has disconnected the communication connection with the server, the connection information of the second client and the server is deleted from the record status table, and an operation of subtracting 1 is performed on the client connection count in the record status table; wherein the first client is the same as or different from the second client.

[0107] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0108] Fig.10 Schematic diagram of an electronic device provided in an embodiment of the present application. Fig.10 As shown, the electronic device 10 of this embodiment includes: a processor 1001, a memory 1002, and a computer program 1003 stored in the memory 1002 and executable on the processor 1001. When the processor 1001 executes the computer program 1003, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 1001 executes the computer program 1003, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0109] The electronic device 10 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 10 may include, but is not limited to, a processor 1001 and a memory 1002. Those skilled in the art will appreciate that Fig.10 The electronic device 10 is merely an example and does not limit the electronic device 10 . The electronic device 10 may include more or fewer components than shown in the figure, or different components.

[0110] The processor 1001 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0111] The memory 1002 may be an internal storage unit of the electronic device 10, for example, a hard disk or memory of the electronic device 10. The memory 1002 may also be an external storage device of the electronic device 10, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card (FlashCard), etc. equipped on the electronic device 10. The memory 1002 may also include both an internal storage unit of the electronic device 10 and an external storage device. The memory 1002 is used to store computer programs and other programs and data required by the electronic device.

[0112] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0113] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0114] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A communication message processing method, characterized in that: The method is executed by a server, the server is connected to at least one client, and the method includes: receiving a target message, wherein the target message is a request message sent by a target client to the server, and the target client is any client among the at least one client; In response to determining that the target message is an illegal message, searching for associated message data of the target message in adjacent messages of the target message, wherein the associated message data includes a legal message header of the target message or legal message data of the target message, and the adjacent message of the target message is a previous message adjacent to the target message, or a subsequent message adjacent to the target message; In response to obtaining the associated message data through searching, an updated target message is determined based at least on the associated message data.

2. The method according to claim 1, characterized in that The method further comprises: In response to failing to find the associated message data, obtaining a client connection count of the server; In response to determining that the client connection count of the server is greater than 1, receiving a request message sent again by the target client after determining that a response has timed out.

3. The method according to claim 2, characterized in that The method further comprises: In response to determining that the client connection count of the server is equal to 1, a reset operation is performed on the server.

4. The method according to claim 1, characterized in that The determining that the target message is an illegal message includes: In response to the target message including an illegal message header, determining that the target message is an illegal message; or In response to determining that the payload length of the received target message is less than the payload length recorded in the target message, the target message is determined to be an illegal message.

5. The method according to claim 4, characterized in that Searching for associated message data of the target message in adjacent messages of the target message includes: In response to determining that the target message includes an illegal message header, searching for a first preset data segment from the end of a message in a previous message adjacent to the target message; In response to searching for a legitimate message header of the target message in the first preset data segment, determining that the legitimate message header is the associated message data; or In response to determining that the target message includes an illegal message header, backward querying a second preset data segment in a subsequent message adjacent to the target message; In response to searching for a legitimate message header of the target message in the second preset data segment, determining that the legitimate message header is the associated message data; or In response to determining that the payload length of the received target message is less than the payload length recorded in the target message, backward querying a third preset data segment in a subsequent message adjacent to the target message to obtain associated payload data and verification information; In response to determining that the associated payload data and the payload data in the target message satisfy the verification information, the associated payload data and the verification information are determined to be the associated message data.

6. The method according to claim 4, characterized in that The target message also includes at least a protocol version field and a load type field; The illegal message header included in the target message includes at least one of the following situations: The message header of the target message is at least partially missing; The protocol version field of the target message is inconsistent with the preset message protocol version; The load type field of the target message does not belong to any of the preset load type values.

7. The method according to claim 6, characterized in that The preset payload type values ​​of the payload type field of the target message include: A first value is used to characterize a target service corresponding to the target message; The second value is used to indicate that the target service request is correctly responded to; The third value is used to indicate that the target service request is responded to abnormally.

8. The method according to claim 4, characterized in that The step of determining the updated target message at least based on the associated message data comprises: In response to the associated message data being a legitimate message header, combining the legitimate message header and data of an immediately subsequent target length to obtain the updated target message, wherein the target length is a payload length recorded in the legitimate message header; In response to the associated message data being associated payload data and verification information, the target message is combined with the associated payload data and verification information to obtain the updated target message.

9. The method according to claim 2 or 3, characterized in that: The client connection count of the server is maintained in the following manner: In response to determining that the first client has established a communication connection with the server, the connection information between the first client and the server is saved in a record status table, and a client connection count in the record status table is incremented by 1; In response to determining that the second client is disconnected from the server, the connection information between the second client and the server is deleted from the record status table, and a client connection count in the record status table is reduced by 1; The first client and the second client are the same or different.

10. A communication message processing device, characterized in that: include: A receiving module is configured to receive a target message, wherein the target message is a request message sent by a target client to a server, wherein the server is connected to at least one client, and the target client is any one of the at least one client; A search module, configured to search for associated message data of the target message in adjacent messages of the target message in response to determining that the target message is an illegal message, wherein the associated message data includes a legal message header of the target message or legal message data of the target message, and the adjacent message of the target message is a previous message adjacent to the target message, or a subsequent message adjacent to the target message; The processing module is configured to determine an updated target message at least based on the associated message data in response to the associated message data being found.

Images