Method and device for asynchronously analyzing automobile CAN message data and medium

Abstract

The embodiment of the invention discloses a method and equipment for asynchronously analyzing automobile CAN message data and a medium, belongs to the technical field of automobile data processing, and solves the problems that when the CAN message data is processed in a synchronous mode, interface updating becomes a bottleneck in the whole logic, and under the condition of high-frequency data, a large amount of message data is easily accumulated, and the interface is dead. Comprising the following steps: acquiring automobile CAN message data through a main thread, and storing the automobile CAN message data to a data queue; starting a first sub-thread, analyzing the message data in the data queue through the first sub-thread, and updating the processed message data to a variable internal value queue and a real-time data recording queue; starting a second sub-thread, and regularly updating the data in the variable internal value queue to a data display interface through the second sub-thread; and starting a third sub-thread, and storing the data in the real-time data recording queue into a recording file through the third sub-thread.

Description

Technical Field

[0001] This application relates to the field of automotive data processing technology, and in particular to a method, device and medium for asynchronously parsing automotive CAN message data. Background Technology

[0002] During the research, development, testing, and production of automobiles, it is necessary to collect message data transmitted by the on-board electronic control unit (ECU) through the CAN (Controller Area Network) bus in real time using host computer software. This data includes key parameters such as engine speed, water temperature, and oil pressure, in order to monitor, analyze, and diagnose the vehicle's operating status.

[0003] Existing automotive data acquisition host computer software typically uses a synchronous method to directly parse the data in the message after acquiring CAN data, updates the data on the host computer software interface, and then records the parsed data to a file.

[0004] However, updating the interface in the host computer software consumes a lot of computer resources. In the existing technology, when processing CAN message data synchronously, updating the interface will become the bottleneck of the entire logic. In the case of high-frequency data, it is easy to cause a large amount of message data to accumulate, causing the interface to freeze. Summary of the Invention

[0005] This application provides a method, device, and medium for asynchronously parsing automotive CAN message data, which solves the following technical problem: In the prior art, when processing CAN message data synchronously, updating the interface becomes a bottleneck in the entire logic. In the case of high-frequency data, it is easy to cause a large amount of message data to accumulate, leading to the interface freezing problem.

[0006] The embodiments of this application adopt the following technical solutions:

[0007] This application provides a method for asynchronously parsing automotive CAN message data. The method includes: acquiring automotive CAN message data through a main thread and saving it to a data queue; starting a first sub-thread to parse and process the message data in the data queue, and updating the processed message data to a variable internal value queue and a real-time data recording queue; starting a second sub-thread to periodically update the data in the variable internal value queue to a data display interface; and starting a third sub-thread to store the data in the real-time data recording queue to a recording file.

[0008] In one implementation of this application, a first sub-thread parses and processes the message data in the data queue, and updates the processed message data to the variable internal value queue and the real-time data recording queue. Specifically, the first sub-thread performs format parsing and business calculations on the acquired message data according to preset parsing rules to obtain processed data; based on data characteristic information, the processed data is updated to the variable internal value queue and the real-time data recording queue respectively; wherein, the data characteristic information corresponding to the variable internal value queue includes at least the variable name, information related to the conversion of the variable internal value to the physical value, and the internal value; the data characteristic information corresponding to the real-time data recording queue includes at least the variable name, the variable internal value, and the timestamp; after the data update is completed, the first sub-thread marks the message data as processed and continues to monitor the data queue.

[0009] In one implementation of this application, a second sub-thread periodically updates the data in the variable internal value queue to the data display interface. Specifically, this includes: after a preset time interval, the second sub-thread sequentially retrieves the data to be updated from the variable internal value queue; based on the internal value conversion method corresponding to the data to be updated, performs data conversion on the data to be updated to obtain the physical value to be displayed; and updates the physical value to the data display interface.

[0010] In one implementation of this application, the data to be updated is converted based on the internal value conversion method corresponding to the data to be updated to obtain the physical value to be displayed. Specifically, this includes: matching a preset internal value conversion method with the variable identifier corresponding to the data to be updated through a second sub-thread; converting the data to be updated according to the internal value conversion method to obtain the physical value to be displayed; performing a reasonableness check on the physical value; and updating the physical value to the data display interface after the check passes.

[0011] In one implementation of this application, a third sub-thread stores the real-time data in the real-time data recording queue into a recording file. Specifically, this includes: obtaining the timestamp of each data in the real-time data recording queue; and storing each data sequentially into the recording file according to the order corresponding to the timestamp.

[0012] In one implementation of this application, after storing each piece of data sequentially into a record file according to the chronological order corresponding to the timestamps, the method further includes: responding to a data query instruction and querying the target data in the record file through a third sub-thread; wherein the data query instruction includes at least the query range and the target variable; generating visualization data from the queried target data; and feeding back the generated visualization data to the user through the third sub-thread.

[0013] In one implementation of this application, after the main thread acquires the CAN message data of the vehicle and saves it to the data queue, the method further includes: real-time monitoring of the number of message data in the data queue; when the number of message data in the data queue reaches a preset threshold, starting multiple derivative sub-threads corresponding to the first sub-thread; performing parallel parsing processing on the message data in the data queue through the multiple derivative sub-threads; and writing the processed data into the variable internal value queue and the real-time data recording queue respectively through the multiple derivative sub-threads.

[0014] In one implementation of this application, before acquiring the vehicle's CAN message data through the main thread and saving it to the data queue, the method further includes: receiving parameter configuration information input by the user, and generating a parameter set corresponding to the data acquisition device based on the parameter configuration information; wherein, the parameter set corresponding to the data acquisition device includes at least variable identification information, acquisition period parameters, and data transmission rules; establishing a communication connection with the electronic control unit based on the XCP / CCP protocol; sending the parameter set corresponding to the data acquisition device to the electronic control unit based on the communication connection, and receiving a parameter confirmation response returned by the electronic control unit; and starting the message data acquisition process after receiving the parameter activation instruction returned by the electronic control unit.

[0015] This application provides an asynchronous CAN message data parsing device for automobiles, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: acquire automobile CAN message data through a main thread and save it to a data queue; start a first sub-thread to parse and process the message data in the data queue, and update the processed message data to a variable internal value queue and a real-time data recording queue; start a second sub-thread to update the data in the variable internal value queue to a data display interface; and start a third sub-thread to store the data in the real-time data recording queue to a recording file.

[0016] This application provides a non-volatile computer storage medium storing computer-executable instructions. The computer-executable instructions are configured to: acquire vehicle CAN message data through a main thread and save it to a data queue; start a first sub-thread to parse and process the message data in the data queue and update the processed message data to a variable internal value queue and a real-time data recording queue; start a second sub-thread to update the data in the variable internal value queue to a data display interface; and start a third sub-thread to store the data in the real-time data recording queue to a recording file.

[0017] The above-mentioned technical solutions adopted in this application embodiment can achieve the following beneficial effects: This application embodiment uses the main thread to acquire CAN messages and store data in the queue, avoiding the blocking caused by parsing, interface updates, or file storage in the synchronous mode. When the host computer software collects high-frequency data, it separates data parsing, interface updates, and data saving, and avoids the problem of software freezing caused by frequent interface refreshes by periodically refreshing the interface. The first sub-thread is used to parse the messages and distribute them to two queues. The second and third sub-threads handle interface updates and file storage independently, and each link is executed in parallel, reducing the impact of the time spent in a single link on the overall process efficiency. Secondly, in the high-frequency data acquisition scenario, even if the interface update of the second sub-thread is slow, the variable internal value queue can cache the parsed data, which does not affect the continuous parsing of the first sub-thread. Similarly, if the third sub-thread encounters an anomaly during file storage, the real-time data recording queue can temporarily store the data, and the third sub-thread will reprocess it after the fault is resolved, avoiding data loss. The multi-threaded parallel processing method in this application embodiment reduces the accumulation of a large amount of message data and improves the real-time capability of data parsing and processing. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0019] Figure 1 A flowchart illustrating a method for asynchronously parsing automotive CAN message data, provided in an embodiment of this application;

[0020] Figure 2 A logical diagram illustrating asynchronous parsing of automotive CAN message data is provided in an embodiment of this application.

[0021] Figure 3 This is a schematic diagram of the structure of an asynchronous CAN message data parsing device for automobiles, provided in an embodiment of this application.

[0022] Figure label:

[0023] 200: Asynchronous CAN message parsing device; 201: Processor; 202: Memory. Detailed Implementation

[0024] This application provides a method, device, and medium for asynchronously parsing automotive CAN message data.

[0025] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0026] The technical solutions proposed in the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0027] Figure 1 A flowchart illustrating a method for asynchronously parsing automotive CAN message data, as provided in this application embodiment, is shown below. Figure 1 As shown, the method for asynchronously parsing automotive CAN message data includes the following steps:

[0028] S101. Obtain the vehicle's CAN message data through the main thread and save it to the data queue.

[0029] In one implementation of this application, parameter configuration information input by the user is received, and a parameter set corresponding to the data acquisition device is generated based on the parameter configuration information. The parameter set corresponding to the data acquisition device includes at least variable identification information, acquisition period parameters, and data transmission rules. A communication connection based on the XCP / CCP protocol is established with the electronic control unit. Based on the communication connection, the parameter set corresponding to the data acquisition device is sent to the electronic control unit, and a parameter confirmation response is received from the electronic control unit. After receiving the parameter activation command from the electronic control unit, the message data acquisition process is initiated.

[0030] In this embodiment of the application, a CAN message refers to a frame in which the transmitting unit sends data to the receiving unit. On the CAN bus, data is transmitted in the form of messages, each message containing specific information used to achieve communication and control between devices.

[0031] DAQ: The data acquisition unit (DAQ) is a crucial component of the XCP / CCP calibration protocol. It is responsible for communicating with the ECU and transmitting data to the calibration tool for processing. The DAQ typically consists of hardware and software components. The hardware is responsible for the physical connection to the ECU, while the software controls the acquisition and transmission of data.

[0032] Among them, the XCP / CCP protocol is an important protocol used for ECU calibration and measurement in the automotive electronics field. It includes the CCP protocol (CAN Calibration Protocol) and the XCP protocol (Universal Calibration Protocol). The CCP protocol is a CAN bus-based calibration protocol that enables communication between the calibration tool and the ECU via the CAN bus. The XCP protocol is a universal calibration protocol that does not depend on a specific bus and can be adapted to various communication media such as CAN and Ethernet. Both use standardized communication interfaces to enable the calibration tool to adjust ECU parameters and acquire data, ultimately optimizing ECU performance.

[0033] Specifically, the host computer data acquisition software receives configuration information input by the user, such as the target monitoring variables, acquisition frequency, and data transmission method, and converts it into a parameter set that the data acquisition device can recognize. The software establishes a physical connection with the ECU through the hardware interface, initializes the XCP / CCP protocol stack, sends protocol handshake commands, negotiates key parameters such as protocol version and communication rate, completes the electronic control unit authentication, and establishes a stable logical communication link after confirming that the communication formats of both parties are consistent, and then enters the parameter configuration mode.

[0034] Furthermore, the software encapsulates the generated parameter set into protocol data frames in batches according to the command format specified by the XCP / CCP protocol, and sends them to the electronic control unit (ECU) through the established communication connection. When the software receives the parameter activation command returned by the ECU, it sends a data acquisition start command to the ECU. The ECU, based on the configured parameter set, starts its internal data acquisition logic, acquires data from specified variables according to the set acquisition cycle, generates message data according to the data transmission rules, and sends it to the software through the communication link. The software then starts the corresponding receiving thread to receive and process the message data sent by the ECU.

[0035] In one implementation of this application, the main thread initiates a continuous listening mode, capturing messages transmitted on the bus in real time via the CAN hardware interface, and recording the corresponding timestamp for each received message. The main thread writes the received message data into a data queue according to a first-in, first-out (FIFO) principle.

[0036] S102. Start the first sub-thread, which parses and processes the message data in the data queue, and updates the processed message data to the variable internal value queue and the real-time data recording queue.

[0037] In one implementation of this application, a first sub-thread performs format parsing and business calculations on the acquired message data according to preset parsing rules to obtain processed data. Based on data characteristic information, the processed data is updated to both the variable internal value queue and the real-time data recording queue. The data characteristic information corresponding to the variable internal value queue includes at least the variable name, information related to the conversion of the variable's internal value to its physical value, and the internal value itself. The data characteristic information corresponding to the real-time data recording queue includes at least the variable name, the variable's internal value, and a timestamp. After the data update is completed, the first sub-thread marks the message data as processed and continues to monitor the data queue.

[0038] Specifically, upon software startup, the first sub-thread begins loading preset message parsing rules, such as the mapping relationship between message IDs and variables, data segment parsing formats, and business calculation algorithms. Based on these rules, the first sub-thread parses the extracted message data, separating the original internal values ​​of each variable from the data segment, such as binary or hexadecimal values, and verifying that the data length and field integrity comply with the rules. After parsing, calculations are performed according to business requirements, including unit conversion, logical operations, and data standardization, resulting in processed structured data containing the names, internal values, and relevant conversion parameters of each variable.

[0039] Furthermore, the first sub-thread categorizes the processed data based on data characteristic information. For the variable internal value queue, it extracts the variable name, internal value, and related information for converting to physical values, encapsulates them according to the queue's specified format, and then completes the writing. For the real-time data recording queue, it extracts the variable name, internal value, and corresponding timestamp, encapsulates them according to the complete record format, and then completes the writing.

[0040] Furthermore, after completing the data writing to both queues, the first sub-thread returns to the data queue, marks the currently processed message as processed, removes the message from the queue, and releases the buffer resources associated with the message. Subsequently, the first sub-thread re-enters the listening state, continuously checking if there are any new unprocessed messages in the data queue.

[0041] S103. Start the second sub-thread, and update the data in the variable internal value queue to the data display interface periodically through the second sub-thread.

[0042] In one implementation of this application, after a preset time interval, a second sub-thread sequentially retrieves data to be updated from the variable's internal value queue. Based on the internal value conversion method corresponding to the data to be updated, the data to be updated is converted to obtain the physical value to be displayed. The physical value is then updated to the data display interface. In this embodiment, the interface is refreshed on demand via a sub-thread, eliminating resource waste caused by frequent refreshes.

[0043] Specifically, when the software starts, a second sub-thread is launched, loading a preset time interval parameter, such as 500ms. After starting, the second sub-thread enters a loop state, periodically triggering the data acquisition process according to a preset duration using a built-in timer. After triggering, it extracts unprocessed data to be updated from the variable's internal value queue according to the first-in-first-out principle. If there is no new data in the queue, it waits for the next preset duration before attempting to acquire it again.

[0044] Furthermore, the second sub-thread matches the corresponding internal value conversion method from the conversion rule base based on the variable name in each data entry. According to the matched conversion method, it performs conversion calculations on the internal values, converting them into physical values ​​such as temperature and pressure, and then updates these physical values ​​to the display interface. Secondly, during data conversion, this application implementation can also simultaneously verify whether the conversion result is within a reasonable range and mark abnormal values ​​with warning indicators.

[0045] Furthermore, when updating physical values ​​to the data display interface, the second sub-thread queries the mapping table based on the variable names to determine the corresponding interface controls for each physical value, such as dashboards, numeric display boxes, and indicator lights. It then encapsulates the physical values ​​and control identifiers according to the control's required format and generates an interface update command. This update command is sent to the data display interface through the system UI interaction interface. Upon receiving the command, the main interface thread synchronously updates the display content of the corresponding controls within the UI rendering cycle.

[0046] S104. Start the third sub-thread and store the data in the real-time data recording queue into the recording file through the third sub-thread.

[0047] In one implementation of this application, the timestamps of each data item are obtained from the real-time data recording queue, and the data items are stored sequentially into a recording file according to the order corresponding to the timestamps. This embodiment of the application saves real-time data to the recording queue and then saves it to the recording file via a sub-thread to prevent data loss.

[0048] Specifically, when the third sub-thread detects unstored data in the real-time data recording queue, it extracts batch data according to the first-in-first-out principle and parses the timestamp information from each data entry. Furthermore, the third sub-thread rearranges the data in ascending order of timestamps. If data with the same timestamp exists, it is re-sorted according to the preset priority of variable names or alphabetical order to ensure the continuity and consistency of data over time.

[0049] Furthermore, the third sub-thread writes the sorted data into the record file one by one according to the configured file format. Each record contains complete information such as variable name, internal value, and corresponding timestamp. During the writing process, it ensures that the field separator, line break, and other formats conform to the specifications.

[0050] In one implementation of this application, in response to a data query command, a third sub-thread queries the target data in a record file; wherein the data query command includes at least a query range and a target variable. The queried target data is then used to generate visualized data, which is then fed back to the user via the third sub-thread.

[0051] Specifically, while monitoring the real-time data recording queue, the third sub-thread opens a query command receiving interface. When it receives a data query command sent by a user, it parses the query range in the command, and based on the time information in the query range, it traverses the record files under the storage path to filter out the target files whose time covers the query range. Furthermore, the third sub-thread performs graphical processing on the query result set according to preset visualization types, such as waveform charts and bar charts, to generate visualized data.

[0052] Furthermore, the third sub-thread sends the generated visualization data to the data display interface through the interface interaction interface, so as to display the query results on the data display interface.

[0053] In one implementation of this application, the main thread acquires CAN message data from the vehicle and saves it to a data queue. The number of message data items in the data queue is then monitored in real time. When the number of message data items in the data queue reaches a preset threshold, multiple derived sub-threads corresponding to the first sub-thread are started. These derived sub-threads perform parallel parsing and processing of the message data in the data queue. The processed data is then written to an internal variable value queue and a real-time data recording queue, respectively, by these derived sub-threads.

[0054] Specifically, while continuously acquiring CAN message data from the vehicle and writing it to the data queue, the main thread activates a queue count monitoring mechanism to monitor the total amount of unprocessed message data in the queue in real time and compares the statistical results with a preset threshold. When the main thread detects that the number of messages in the data queue reaches or exceeds the preset threshold, it sends a derivative start command to the first child thread. After receiving the command, the first child thread calculates the required number of derivative child threads based on the current queue data volume and the single-thread processing capacity, and then starts the derivative child threads.

[0055] Furthermore, after each derived sub-thread completes message parsing, it categorizes the processed data based on data characteristics. For data to be written to the variable internal value queue, it encapsulates the variable name, internal value, and conversion information according to the required format. For data to be written to the real-time data recording queue, it encapsulates the variable name, internal value, and timestamp. When a derived sub-thread finishes processing its assigned message data and the remaining data in the data queue is below a preset threshold, the first sub-thread sends a termination message to all derived sub-threads. After completing the current data writing, each derived sub-thread releases the occupied memory resources, queue locks, and parsing resources.

[0056] Figure 2 This application provides a logical diagram illustrating asynchronous parsing of automotive CAN message data, as shown in the embodiments. Figure 2 As shown, the software selects the variables, frequencies, and other information to be monitored and recorded within the context logic; and sets the DAQ parameters for the ECU according to the XCP / CCP calibration protocol. The ECU broadcasts messages on the CAN bus according to the set frequency. The host computer receives the CAN messages and stores them in the data queue. The first sub-thread processes the messages in the data queue sequentially and updates the calculated data in the variable internal value queue and the data recording queue. The second thread executes every 500ms, calculating the physical values ​​based on the new internal values ​​and updating the interface. The third thread saves the real-time data calculated in the main thread to the recording file according to the timestamp order.

[0057] Figure 3 This is a schematic diagram of the structure of an asynchronous CAN message data parsing device for automobiles, provided as an embodiment of this application. Figure 3 As shown, the asynchronous CAN message data parsing device 200 includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201. The memory 202 stores instructions executable by the at least one processor 201. These instructions, when executed by the at least one processor 201, enable the at least one processor 201 to: acquire CAN message data from the vehicle via a main thread and save it to a data queue; start a first sub-thread to parse and process the message data in the data queue, and update the processed message data to a variable internal value queue and a real-time data recording queue; start a second sub-thread to update the data in the variable internal value queue to a data display interface; and start a third sub-thread to store the data in the real-time data recording queue to a recording file.

[0058] This application provides a non-volatile computer storage medium storing computer-executable instructions. The computer-executable instructions are configured to: acquire vehicle CAN message data through a main thread and save it to a data queue; start a first sub-thread to parse and process the message data in the data queue and update the processed message data to a variable internal value queue and a real-time data recording queue; start a second sub-thread to update the data in the variable internal value queue to a data display interface; and start a third sub-thread to store the data in the real-time data recording queue to a recording file.

[0059] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0060] The above descriptions are merely embodiments of this application and are not intended to limit the scope of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions in the embodiments of this application.

Claims

1. A method for asynchronously parsing automobile CAN message data, characterized in that, The method includes: The main thread acquires the vehicle's CAN message data and saves it to the data queue. Start the first sub-thread, and use the first sub-thread to parse and process the message data in the data queue, and update the processed message data to the variable internal value queue and the real-time data recording queue; Start a second sub-thread, and use the second sub-thread to periodically update the data in the internal value queue of the variable to the data display interface; In addition, a third sub-thread is started, through which the data in the real-time data recording queue is stored in the recording file.

2. The method for asynchronously parsing automotive CAN message data according to claim 1, characterized in that, The step of parsing and processing the message data in the data queue through the first sub-thread, and updating the processed message data to the variable internal value queue and the real-time data recording queue, specifically includes: The first sub-thread performs format parsing and business calculations on the acquired message data according to preset parsing rules to obtain processed data. Based on the data characteristic information, the processed data is updated to the variable internal value queue and the real-time data recording queue, respectively; wherein, the data characteristic information corresponding to the variable internal value queue includes at least the variable name, information related to the conversion of the variable internal value into a physical value, and the internal value; the data characteristic information corresponding to the real-time data recording queue includes at least the variable name, the variable internal value, and a timestamp; After the data update is completed, the first sub-thread marks the message data as processed and continues to listen to the data queue.

3. The method for asynchronously parsing automotive CAN message data according to claim 1, characterized in that, The step of periodically updating the data in the variable's internal value queue to the data display interface via the second sub-thread specifically includes: After a preset time interval, the second sub-thread sequentially retrieves the data to be updated from the variable's internal value queue. Based on the internal value conversion method corresponding to the data to be updated, the data to be updated is converted to obtain the physical value to be displayed; Update the physical values ​​to the data display interface.

4. The method for asynchronously parsing automotive CAN message data according to claim 3, characterized in that, The step of performing data transformation on the data to be updated based on the internal value transformation method corresponding to the data to be updated, to obtain the physical value to be displayed, specifically includes: The second sub-thread matches a preset internal value conversion method based on the variable identifier corresponding to the data to be updated. The data to be updated is converted according to the internal value conversion method to obtain the physical value to be displayed; The physical values ​​are validated for reasonableness. Once the validation is successful, the physical values ​​are updated to the data display interface.

5. The method for asynchronously parsing automotive CAN message data according to claim 1, characterized in that, The step of storing the data in the real-time data recording queue into a recording file via the third sub-thread specifically includes: Obtain the timestamp of each data item from the real-time data recording queue; According to the chronological order corresponding to the timestamps, each piece of data is stored sequentially in the record file.

6. The method for asynchronously parsing automotive CAN message data according to claim 5, characterized in that, After storing the data sequentially into the record file according to the chronological order corresponding to the timestamps, the method further includes: In response to a data query command, the third sub-thread queries the target data in the record file; wherein the data query command includes at least the query range and the target variable; The retrieved target data will be used to generate visualized data; The generated visualization data is fed back to the user through the third sub-thread.

7. The method for asynchronously parsing automotive CAN message data according to claim 1, characterized in that, After obtaining the vehicle CAN message data through the main thread and saving it to the data queue, the method further includes: The number of message data in the data queue is monitored in real time; When the number of message data in the data queue reaches a preset threshold, multiple derivative sub-threads corresponding to the first sub-thread are started. The message data in the data queue is parsed and processed in parallel by multiple derived sub-threads; The processed data is written into the variable internal value queue and the real-time data recording queue by multiple derived sub-threads.

8. The method for asynchronously parsing automotive CAN message data according to claim 1, characterized in that, Before acquiring the vehicle CAN message data through the main thread and saving it to the data queue, the method further includes: The system receives parameter configuration information input by the user and generates a parameter set corresponding to the data collector based on the parameter configuration information; wherein the parameter set corresponding to the data collector includes at least variable identification information, collection period parameters, and data transmission rules; Establish a communication connection with the electronic control unit based on the XCP / CCP protocol; Based on the communication connection, the parameter set corresponding to the data acquisition device is sent to the electronic control unit, and the parameter confirmation response returned by the electronic control unit is received. After receiving the parameter activation command returned by the electronic control unit, the message data acquisition process is initiated.

9. An asynchronous device for parsing automotive CAN message data, characterized in that, The device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to perform the method described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of performing the method described in any one of claims 1-8.

Images