Vehicle fault diagnosis message processing method and device and electronic equipment

Abstract

The invention provides a vehicle fault diagnosis message processing method and device and electronic equipment, and the method comprises the steps: responding to a starting instruction, and determining that a target server is in a message waiting state; determining whether a preset message is received; if the preset message is received, determining that the target server is in a header message analysis state, and analyzing a message header of the preset message so as to verify the message header of the preset message; if the message header verification of the preset message fails, determining that the target server is in a header analysis failure state, and executing an analysis failure action; and if the message header verification of the preset message is successful, determining that the target server side is in a message processing load state, executing load processing based on the content analyzed from the header message, and after the load processing, determining that the target server side returns a message waiting state. Through the state transition of the DoIP server, the upper layer service logic can correctly process the concurrent diagnosis requests from the plurality of ECUs.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a method, device, electronic device and storage medium for processing vehicle fault diagnosis messages. Background Art

[0002] With the continuous development of automotive network technology, the diagnosis of automotive electronic control units (ECUs) has become a key link in ensuring the normal operation of vehicles. As an important communication method, the Diagnostic Communication Protocol (DCP) is used to detect and solve faults in automotive electronic systems. Among the many diagnostic protocols, DoIP (Diagnostic over Internet Protocol) has attracted attention because it can use the existing Internet infrastructure for efficient vehicle diagnosis. The DoIP protocol follows the ISO 13400 standard and is built on the TCP / IP protocol. It can establish a stable and efficient communication link between the vehicle and the external diagnostic tool.

[0003] Traditional vehicle diagnostic communication systems have certain limitations in dealing with concurrent operation of multiple devices, message verification, data security, and compatibility between different protocols. For example, communication conflicts may occur when multiple devices are operating concurrently; imperfect message verification mechanisms may lead to the risk of data tampering; the high complexity of data encryption and decryption increases system overhead; in addition, different vehicle manufacturers may use different diagnostic protocols, resulting in prominent protocol compatibility issues. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a method, device and electronic device for processing vehicle fault diagnosis messages, so as to improve the concurrent diagnosis capability and compatibility of the DoIP server.

[0005] In a first aspect, the present invention provides a method for processing vehicle fault diagnosis messages, the method comprising responding to a start instruction, determining that a target server is in a message waiting state; determining whether a preset message is received; if a preset message is received, determining that the target server is in a header message parsing state, and parsing the message header of the preset message to verify the message header of the preset message; if the message header verification of the preset message fails, determining that the target server is in a header parsing failure state, and executing a parsing failure action; if the message header verification of the preset message succeeds, determining that the target server is in a message load processing state, and performing load processing based on the content parsed from the header message, and after the load processing, determining that the target server returns to a message waiting state.

[0006] In an optional implementation, the message header is verified in the following manner:

[0007] Parsing the received preset message to obtain the protocol version, load type and load length indicated by the message header of the preset message;

[0008] Determine whether the protocol version matches the preset protocol version;

[0009] If they match, determine whether the load type is compliant;

[0010] If it is compliant, determine whether the load length is within the preset range;

[0011] If they match, determine whether the payload length and payload type match;

[0012] If they match, the verification is determined to be successful;

[0013] If there is no match or non-compliance, the verification is determined to have failed.

[0014] In an optional implementation, when it is determined that the target server is in a header parsing failure state, the step of executing a parsing failure action includes:

[0015] Generate a NACK response message and send it back to the client;

[0016] Generate error logs;

[0017] Make sure the target server returns the message waiting status.

[0018] In an optional implementation, the step of performing load processing based on the content parsed from the header message specifically includes:

[0019] Based on the payload type indicated by the message header of the acquired preset message, a corresponding response message is generated and sent back to the client.

[0020] In an optional implementation manner, the preset message is parsed through the following steps:

[0021] Determine whether the message type indicated by the preset message is valid;

[0022] If the message type is valid, determine whether the message header of the preset message is valid;

[0023] If the message header is valid, determine whether the payload type of the preset message is valid;

[0024] If the load type is valid, the load type is identified.

[0025] In an optional implementation, if the message type is invalid, if the message header is invalid, if the payload type is invalid, the preset message is discarded.

[0026] In an optional implementation, a message header of a fixed length is read from a preset message;

[0027] The message type field is read from the message header to determine the message type indicated by the message header of the preset message.

[0028] In a second aspect, the present invention provides a device for processing vehicle fault diagnosis messages, the device including a state machine module for responding to a start instruction, determining that a target server is in a message waiting state; determining whether a preset message is received; if a preset message is received, determining that the target server is in a header message parsing state, and parsing the message header of the preset message to verify the message header of the preset message; if the message header verification of the preset message fails, determining that the target server is in a header parsing failure state, and executing a parsing failure action; if the message header verification of the preset message succeeds, determining that the target server is in a message load processing state, and executing load processing based on the content parsed from the header message, and after the load processing, determining that the target server returns to the message waiting state.

[0029] In a third aspect, the present invention provides an electronic device comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the memory communicate via the bus, and the processor executes the machine-readable instructions to perform the steps of a method for processing a vehicle fault diagnosis message as described in any of the aforementioned embodiments.

[0030] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the method for processing vehicle fault diagnosis messages as described in any of the aforementioned embodiments are executed.

[0031] The present application provides a method, device and electronic device for processing vehicle fault diagnosis messages, the method includes responding to a startup instruction, determining that the target server is in a message waiting state; determining whether a preset message is received; if a preset message is received, determining that the target server is in a header message parsing state, and parsing the message header of the preset message to verify the message header of the preset message; if the message header verification of the preset message fails, determining that the target server is in a header parsing failure state, and performing a parsing failure action; if the message header verification of the preset message succeeds, determining that the target server is in a message load processing state, and performing load processing based on the content parsed from the header message, and after load processing, determining that the target server returns to a message waiting state. Through the state transition of the DoIP server, it is ensured that the upper-level business logic can correctly handle concurrent diagnostic requests from multiple ECUs, thereby improving the concurrent diagnostic capability of the DoIP server. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0033] Figure 1 A DoIP server system structure diagram provided for an embodiment of the present application;

[0034] Figure 2 A DoIP server system flow chart provided for an embodiment of the present application;

[0035] Figure 3 A DoIP server-side UDP parsing flow chart provided in an embodiment of the present application;

[0036] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] First, the application scenario of this application is described. This application is applicable to the server of the automotive diagnostic communication protocol (DoIP) for fault diagnosis of the vehicle's ECU. The DoIP server here is used to receive the service request of the client, and then hand it over to the UDS server for processing, and then sent out by the DoIP server.

[0038] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0039] Figure 1 A DoIP server system structure diagram provided in the embodiment of the present application. Figure 1 As shown, the implementation method of a DoIP protocol stack server provided by the present application includes modules such as entity management, message processing, service management, and callback management. Each module implements a loosely coupled architecture through layered design and interface definition, which not only ensures the scalability of the system, but also improves the maintainability of the code.

[0040] In order to solve the packet sticking problem in communication and improve the reliability of large data transmission, in one embodiment of the present application, the DoIP server sets a message processing mechanism based on a finite state machine.

[0041] Four states are defined here: message waiting state (PS_PROCESS_NONE), header message parsing state (PS_PROCESS_HEADER_MESSAGE), header parsing failure state (PS_PROCESS_HEADER_MESSAGE_FAILED), and message load processing state (PS_PROCESS_PAYLOAD_MESSAGE).

[0042] Specifically, Figure 2 As shown, the DoIP server can perform state transitions through the following steps:

[0043] S1. Respond to the start instruction and determine that the target server is in a message waiting state.

[0044] S2. Determine whether a preset message is received.

[0045] S3. If a preset message is received, it is determined that the target server is in a header message parsing state, and the message header of the preset message is parsed to verify the message header of the preset message.

[0046] Here, the message header can be verified in the following ways:

[0047] Parsing the received preset message to obtain the protocol version, load type and load length indicated by the message header of the preset message;

[0048] Determine whether the protocol version matches the preset protocol version;

[0049] If they match, determine whether the load type is compliant;

[0050] If it is compliant, determine whether the load length is within the preset range;

[0051] If they match, determine whether the payload length and payload type match;

[0052] If they match, the verification is determined to be successful;

[0053] If there is no match or non-compliance, the verification is determined to have failed.

[0054] When receiving new TCP data, the system starts from the PS_PROCESS_NONE state and first reads the fixed-length (8-byte) DoIP message header. The message header contains information such as the protocol version, payload type, and payload length.

[0055] After entering the PS_PROCESS_HEADER_MESSAGE state, the system will verify the message header. The specific verification conditions include: checking whether the protocol version matches, verifying whether the payload type is legal, judging whether the payload length is within the allowed range, and judging whether the payload length corresponds to the payload type.

[0056] S4. If the message header verification of the preset message fails, the target server is determined to be in a header parsing failure state, and a parsing failure action is executed.

[0057] In step S4, when it is determined that the target server is in a header parsing failure state, the steps of executing a parsing failure action include:

[0058] Generate a NACK response message and send it back to the client; generate an error log; and confirm that the target server returns a message waiting status.

[0059] If the message header verification fails, it will enter the PS_PROCESS_HEADER_MESSAGE_FAILED state and perform the following steps respectively: generate a NACK response message, record an error log, discard the current message, return to the PS_PROCESS_NONE state, and prepare to process the next message.

[0060] S5. If the message header verification of the preset message succeeds, the target server is determined to be in the message load processing state, and load processing is performed based on the content parsed from the header message. After the load processing, it is determined that the target server returns to the message waiting state.

[0061] The step of performing load processing based on the content parsed from the header message specifically includes generating a corresponding response message based on the load type indicated by the message header of the acquired preset message and sending the response message back to the client.

[0062] Specifically, if the message header verification succeeds, the system enters the PS_PROCESS_PAYLOAD_MESSAGE state. Read the complete payload according to the payload length information in the header. Deserialize the payload. Call the corresponding processing function according to the payload type. Generate a response message. After the payload processing is completed, the system returns to the PS_PROCESS_NONE state and waits for the next message.

[0063] In this way, by ensuring the message boundary through state management, it is possible to avoid the mismatch between the load length and the actual data, ensure the integrity of the message, make the state transition clear and unambiguous, facilitate problem location and debugging, and easily expand new message types, thereby improving the concurrent diagnostic capabilities and compatibility of the DoIP server.

[0064] In one embodiment of the present application, the DoIP server adopts a layered connection management architecture, which can be specifically a three-layer architecture for connection management, divided into an entity management layer, a connection processing layer, and a transmission management layer.

[0065] The entity management layer (doip_entity_manager) is used to manage all known DoIP entity information, maintain the mapping relationship between the logical address and the physical address of the entity, provide entity lifecycle management functions, and handle address conflicts between entities.

[0066] The connection handling layer (socket_handler_manager) is used to manage the establishment and disconnection of TCP connections. It is used to implement connection pool management and resource restrictions, handle connection state transitions, and provide connection survival detection mechanisms.

[0067] The transport management layer (tcp_server_endpoint) is used to handle the underlying socket communication, manage asynchronous IO operations, implement data transmission and reception, and provide TLS encryption support.

[0068] The interaction process between the three layers includes:

[0069] 1. Connection establishment process

[0070] tcp_server_endpoint receives new TCP connection requests;

[0071] socket_handler_manager checks the connection limit;

[0072] doip_entity_manager creates a new entity record.

[0073] 2. Routing Activation Process

[0074] tcp_server_endpoint receives the activation request;

[0075] socket_handler_manager verifies the connection status;

[0076] doip_entity_manager allocates logical addresses.

[0077] 3. Disconnection Process

[0078] tcp_server_endpoint detects disconnection;

[0079] socket_handler_manager cleans up connection resources;

[0080] doip_entity_manager removes entity records.

[0081] This layered architecture facilitates the expansion and maintenance of the DoIP server system and makes resource management more controllable.

[0082] In one embodiment of the present application, the DoIP server is supported by a TCP and UDP dual communication protocol stack for processing different types of DoIP messages.

[0083] Among them, the UDP protocol stack function is used to process vehicle discovery messages, broadcast vehicle announcements, process entity status requests, and process power mode information.

[0084] The TCP protocol stack function is used to process routing activation requests, manage diagnostic sessions, process diagnostic messages, and maintain connection status.

[0085] The protocol stack interaction mechanism can be implemented through the following steps.

[0086] Entity discovery phase: UDP broadcasts vehicle notification messages; processes vehicle identification requests; responds to vehicle identification results; and enters the TCP connection phase.

[0087] Diagnostic session phase: TCP establishes a secure connection; processes routing activation; exchanges diagnostic data; and keeps the session alive.

[0088] State synchronization mechanism: UDP broadcasts state changes; TCP updates connection state; synchronizes entity information; handles exceptions.

[0089] The dual communication protocol stack switching strategy includes automatic protocol selection based on message type, dynamic adjustment according to network status, support for configuration priority strategy, and provision of failure retry mechanism.

[0090] In this embodiment, unified message encapsulation and parsing, shared security mechanism, consistent resource management, and unified configuration interface can also be implemented on the basis of the dual communication protocol stack.

[0091] This dual communication protocol stack design ensures that the system can simultaneously support all DoIP communication scenarios defined in the ISO 13400 standard. The DoIP server can meet the needs of different scenarios by adopting dual communication transmission protocol stack technology, improve protocol compatibility, enhance system flexibility, and optimize network resource utilization.

[0092] In a specific embodiment of the present application, the DoIP server includes a DoIP entity management module, a message processing module, a callback function management module, and a UDP / TCP communication management module.

[0093] The DoIP entity management module is used to dynamically manage the life cycle of DoIP entities and achieve efficient query by mapping logical addresses to communication endpoints. Containers can be used to store DoIP entities, with logical addresses as keys and entity objects as values. Thread-safe mutexes are used to protect data operations and avoid data competition in a multi-threaded environment. The DoIP entity management module can implement the entity addition function to support dynamic addition of new entities based on logical addresses. If the entity already exists, its attributes (such as VIN, EID, etc.) are updated. The entity removal function accurately locates and deletes entities through logical addresses. The entity query function searches for entities through logical addresses, or obtains the corresponding logical addresses based on communication endpoints. The dynamic address management function supports the addition and removal of target logical addresses and relay logical addresses.

[0094] The message processing module is used to provide a complete parsing and verification mechanism for DoIP protocol messages, supporting protocol extension and packet sticking processing.

[0095] The message processing module can parse the message header, use the state machine to process TCP sticky packets, and solve the packet problem of large data transmission by parsing the message header and payload in stages. Verify the protocol version number and payload type, and verify whether the payload length is legal through the mapping table.

[0096] The message processing module can also process the load. It supports multiple load types (such as vehicle identification requests, route activation requests, diagnostic messages, etc.). It designs processing functions for different load types and provides dynamic expansion capabilities.

[0097] The message processing module can also implement an error response mechanism. When parsing fails, a NACK response message related to the load type is generated, and whether to close the connection is determined based on the error type.

[0098] The callback function management module is used to provide a flexible callback mechanism and support user-defined extended functions, such as dynamic setting of VIN, relay mode processing, etc.

[0099] The callback function management module is specifically used for callback function registration and calling. It uses function pointers and hash tables to store different types of callback functions, and implements dynamic registration and calling through a unified interface. Callback types include: routing activation authentication, dynamic VIN setting, relay mode processing, etc.

[0100] The callback function management module is specifically used for dynamic VIN setting. When a vehicle identification request is received, the VIN information is dynamically generated by calling the registered callback function to meet the needs of various scenarios.

[0101] The UDP / TCP communication management module is used to provide efficient multi-protocol communication support to ensure data transmission security and performance.

[0102] The UDP / TCP communication management module can use non-blocking network communication. Asynchronous communication of TCP and UDP is implemented based on the ASIO library, and concurrent connections are supported. The efficiency of data reception and processing is improved through multi-threading mechanism. The UDP / TCP communication management module can support TLS encryption. Dynamically adjust the TCP port to support TLS encrypted communication to ensure the security of sensitive diagnostic data. The UDP / TCP communication management module also has a broadcast mechanism. Periodic broadcast of vehicle identification response is implemented through UDP to ensure that the diagnostic tool can quickly find the target vehicle.

[0103] The DoIP server can also include status management and diagnosis functions, provide active checking and node status reporting functions, and optimize the server's operating status management.

[0104] Specifically, online checks can be used. Active check status can be managed regularly through conditional variables to detect whether the client is online. Node status reports can also be used to return information such as the current number of TCP connections and the maximum supported data length in real time to improve system observability.

[0105] In a specific embodiment of the present application, Figure 2 As shown, the DoIP server system can be run according to the following steps:

[0106] Step 1: System Initialization

[0107] When the DoIP server is started, it is initialized according to the following steps:

[0108] Create basic components: create an IO service (asio::io_service) instance to handle asynchronous events, create a service manager (doip_server_manager) instance, pass in IO service and IP address parameters, and initialize the entity manager (doip_entity_manager) instance to manage ECU entities.

[0109] Configure network parameters: Set the TCP listening port to 13400, the UDP listening port to 13400, determine whether to enable TLS encryption based on the configuration, the TLS port is 3496 (optional), set the Socket buffer size to 8192 bytes (optional), and configure Socket options: TCP_NODELAY, SO_KEEPALIVE, etc.

[0110] Start network services: create a UDP server endpoint (udp_server_endpoint), create a TCP server endpoint (tcp_server_endpoint), start UDP broadcast monitoring, and start TCP connection monitoring.

[0111] Configure diagnostic parameters: set vehicle identification number (VIN), set ECU identification number (EID), set group identification number (GID) (optional), set functional address and physical address.

[0112] Step 2: Connection Management

[0113] The server's connection management steps include:

[0114] Connection establishment: receive client TCP connection request, create a socket object for the new connection, initialize the connection buffer, and start the handshake timer (2 seconds).

[0115] Connection state management: initial state (LISTEN), socket initialization state (SOCKET_INITIALIZED), routing authentication waiting state (REGISTERED_PENDING_FOR_AUTHENTICATION), routing confirmation waiting state (REGISTERED_PENDING_FOR_CONFIRMATION), routing activation state (REGISTERED_ROUTING_ACTIVE), connection termination state (SOCKET_FINALIZE).

[0116] Connection monitoring: Start the initial activity timer with a timeout of 2 seconds, start the general activity timer with a timeout of 5 seconds, send survival detection messages regularly, and detect client response timeouts.

[0117] Connection cleanup: detect connection timeouts, close unresponsive connections, release connection resources, and update status tables.

[0118] Step 3: Message processing

[0119] The steps for the DoIP server to process the message include:

[0120] Message reception: Set the initial reception length to 8 bytes (protocol header), use the asynchronous read interface to receive data, store the received data in the receive buffer, and trigger the receive callback process.

[0121] Header parsing: check protocol version (0x02) (optional), check reverse protocol version (0xFD), get payload type (payload type), get payload length (payload length).

[0122] Message verification: verify the correctness of the protocol version, check whether the payload type is supported, verify the legitimacy of the payload length, and confirm that the payload length does not exceed the maximum value.

[0123] Payload processing: receiving complete payload data, distributing and processing according to message type, calling corresponding processing functions, and sending processing responses.

[0124] State control: Use atomic variables to control processing status, implement state machine transition logic, ensure message processing integrity, and handle exceptions.

[0125] Step 4: Routing activation process

[0126] The steps for DoIP server to process route activation include:

[0127] Request reception: stop the initial activity timer, receive the routing activation request, parse the activation parameters, and extract the source address information.

[0128] Parameter verification: check source address validity, verify activation type support, confirm resource availability, and check address conflicts.

[0129] Authentication processing: determine whether authentication is required, call the authentication callback function, generate authentication challenge data, and verify the authentication response.

[0130] Entity registration: create ECU entity object, set entity parameter information, register connection correspondence, and update status information.

[0131] Session establishment: Send activation confirmation response, start general activity timer, record session information, and prepare to start diagnostic service.

[0132] Step 5: Diagnostic message processing

[0133] The steps for the DoIP server to process the diagnostic message include:

[0134] Message preprocessing: stop the general activity timer, parse the diagnostic request content, extract the source address and destination address, and obtain the diagnostic service identifier.

[0135] Parameter verification: check the legitimacy of the source address, verify the existence of the target address, confirm the legitimacy of the message length, and determine the service permissions.

[0136] Message forwarding: determine the forwarding mode (direct / relay), find the target ECU information, call the UDS processing interface, and wait for the processing result.

[0137] Response processing: send positive response confirmation (ACK), restart activity timer, wait for diagnostic response, and forward diagnostic results.

[0138] Exception handling: send negative response (NACK), indicate the cause of the error, record error information, and restore to normal state.

[0139] Step 6. Secure communication (optional)

[0140] The DoIP server can support TLS encryption. If encrypted communication is not required, TLS configuration and related port switching operations can be omitted.

[0141] The steps to implement secure communication on the DoIP server include:

[0142] TLS configuration: create an SSL context object, load a server certificate, load a private key file, and configure TLS parameters.

[0143] Security parameter settings: set TLS version (1.2 / 1.3), configure encryption suite, set DH parameters, and configure session options.

[0144] Handshake processing: wait for client request, verify client certificate, complete key exchange, and establish encrypted channel.

[0145] Encrypted communication: encrypt sent data, decrypt received data, verify message integrity, and protect session security.

[0146] Step 7: Resource Management

[0147] The resource management steps of the DoIP server include:

[0148] Connection pool management: initialize connection pool size, allocate connection objects, recycle idle connections, and control the maximum number of connections.

[0149] Memory management: use smart pointers to manage objects, release unused resources in a timely manner, avoid memory leaks, and control memory usage.

[0150] Thread management: create a worker thread pool, distribute processing tasks, synchronize thread operations, and ensure thread safety.

[0151] Timer management: create timer objects, set timeouts, handle timeout events, and clean up expired timers.

[0152] Step 8: Reliability assurance

[0153] The reliability assurance steps of the DoIP server include:

[0154] Exception handling: Capture system exceptions, handle network errors, restore abnormal status, and record error logs.

[0155] Concurrency control: Use mutex locks to protect shared resources, implement atomic operations, avoid deadlocks, and ensure data consistency.

[0156] Fault-tolerance processing: detect disconnection, retry failed operations, restore service status, and maintain system stability.

[0157] Monitoring and alarm (optional): monitor system status, detect abnormal conditions, and send alarm information.

[0158] The implementation method of a DoIP protocol stack server provided in the embodiment of the present application realizes dynamic management of DoIP entities through logical address mapping and multi-threaded protection. The integrity and accuracy of the message are ensured through state machine and mapping table verification. User customization functions are supported through callback functions to enhance system adaptability. Based on non-blocking communication and TLS encryption, high-performance and high-security communication capabilities can be provided. Comprehensive monitoring and optimization of the server are achieved through active inspection and status reporting.

[0159] The default message can be of UDP type or TCP type. Figure 3 As shown, in one embodiment of the present application, taking UDP as an example, the DoIP server can parse the preset message through the following steps:

[0160] Determine whether the message type indicated by the preset message is valid;

[0161] If the message type is valid, determine whether the message header of the preset message is valid;

[0162] If the message header is valid, determine whether the payload type of the preset message is valid;

[0163] If the load type is valid, the load type is identified.

[0164] If the message type is invalid, if the message header is invalid, if the payload type is invalid, the preset message is discarded.

[0165] Specifically, a message header of a fixed length may be read from a preset message; and a message type field may be read from the message header to determine the message type indicated by the message header of the preset message.

[0166] The load types here include vehicle identification request, entity status request, power mode request, vehicle identification response, etc.

[0167] Based on the same inventive concept, an embodiment of the present application also provides a vehicle fault diagnosis message processing device, which includes a state machine module for responding to a start instruction, determining that the target server is in a message waiting state; determining whether a preset message is received; if the preset message is received, determining that the target server is in a header message parsing state, and parsing the message header of the preset message to verify the message header of the preset message; if the message header verification of the preset message fails, determining that the target server is in a header parsing failure state, and executing a parsing failure action; if the message header verification of the preset message succeeds, determining that the target server is in a message load processing state, and executing load processing based on the content parsed from the header message, and after the load processing, determining that the target server returns to the message waiting state.

[0168] See also Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 4 As shown in , the electronic device 400 includes a processor 410 , a memory 420 and a bus 430 .

[0169] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, steps for processing a vehicle fault diagnosis message as in the above method embodiment can be performed. The specific implementation method can be found in the method embodiment and will not be repeated here.

[0170] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of processing a vehicle fault diagnosis message in the above method embodiment can be executed. The specific implementation method can be found in the method embodiment and will not be repeated here.

[0171] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0172] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0173] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0174] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0175] It should be noted that if the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM) random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0176] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0177] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for processing vehicle fault diagnosis messages, characterized in that: The method comprises: Respond to the start instruction and determine that the target server is in a message waiting state; Determine whether a preset message is received; If a preset message is received, determining that the target server is in a header message parsing state, and parsing a message header of the preset message to verify the message header of the preset message; If the message header verification of the preset message fails, the target server is determined to be in the header parsing failure state, and the parsing failure action is executed; If the message header verification of the preset message succeeds, the target server is determined to be in the message load processing state, and load processing is performed based on the content parsed from the header message. After the load processing, it is determined that the target server returns to the message waiting state.

2. The method according to claim 1, characterized in that: Verify the message header in the following ways: Parsing the received preset message to obtain the protocol version, load type and load length indicated by the message header of the preset message; Determine whether the protocol version matches a preset protocol version; If they match, determining whether the load type is compliant; If it is compliant, determine whether the load length is within the preset range; If they match, determine whether the payload length and payload type match; If they match, the verification is determined to be successful; If there is no match or non-compliance, the verification is determined to have failed.

3. The method according to claim 1, characterized in that When it is determined that the target server is in a header parsing failure state, the step of executing the parsing failure action includes: Generate a NACK response message and send it back to the client; Generate error logs; Make sure the target server returns the message waiting status.

4. The method according to claim 2, characterized in that: The step of performing load processing based on the content parsed from the header message specifically includes: Based on the payload type indicated by the message header of the acquired preset message, a corresponding response message is generated and sent back to the client.

5. The method according to claim 2, characterized in that: The preset message is parsed through the following steps: Determine whether the message type indicated by the preset message is valid; If the message type is valid, determine whether the message header of the preset message is valid; If the message header is valid, determine whether the payload type of the preset message is valid; If the load type is valid, the load type is identified.

6. The method according to claim 5, characterized in that If the message type is invalid, if the message header is invalid, if the payload type is invalid, the preset message is discarded.

7. The method according to claim 5, characterized in that Read a fixed-length message header from a preset message; The message type field is read from the message header to determine the message type indicated by the message header of the preset message.

8. A vehicle fault diagnosis message processing device, characterized in that: The device includes a state machine module for responding to a start instruction, determining that the target server is in a message waiting state; determining whether a preset message is received; if the preset message is received, determining that the target server is in a header message parsing state, and parsing the message header of the preset message to verify the message header of the preset message; if the message header verification of the preset message fails, determining that the target server is in a header parsing failure state, and executing a parsing failure action; if the message header verification of the preset message succeeds, determining that the target server is in a message load processing state, and executing load processing based on the content parsed from the header message, and after the load processing, determining that the target server returns to a message waiting state.

9. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate via the bus, and the processor executes the machine-readable instructions to perform the steps of the method for processing vehicle fault diagnosis messages as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method for processing vehicle fault diagnosis messages as claimed in any one of claims 1 to 7 are executed.

Images