Vehicle diagnosis data processing method and device, electronic equipment and cloud server

Abstract

The invention relates to the technical field of Internet of Vehicles, in particular to a vehicle diagnosis data processing method and device, electronic equipment and a cloud server, and the vehicle diagnosis data processing method comprises the steps: determining a task type according to a diagnosis request, and calling a registered function module interface based on the task type; calling a function module interface to obtain multi-type diagnosis data related to the diagnosis request from a plurality of independent service systems; and analyzing the multi-type diagnosis data based on the context information in the multi-type diagnosis data to obtain a diagnosis result. Multi-type diagnosis data can be automatically obtained from a plurality of dispersed service systems, and data islands between existing systems are effectively broken; furthermore, context information embedded in various types of data is used for association analysis, automatic integration and version matching of diagnosis data are achieved, the efficiency and accuracy of fault analysis are remarkably improved, and the problem that a data organization mode of an existing vehicle diagnosis system is highly fragmented is solved.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, specifically to a vehicle diagnostic data processing method, apparatus, electronic device, and cloud server. Background Technology

[0002] Driven by electrification, intelligent connectivity, EEA (Electrical, Electrical, and Aspect Ratio) transformation, and integration in the automotive industry, the electronic and electrical systems of both gasoline-powered and new energy vehicles are undergoing rapid changes. Software-defined vehicles and intelligentization have become strategic directions for the development of the automotive industry. The automotive electronic and electrical architecture is shifting from a traditional distributed EE architecture to a domain-centralized EE architecture. A widely adopted solution is the three-domain centralized architecture, which includes three domain controllers (DCUs): the Vehicle Domain Controller (VDC), the Advanced Driver Controller (ADAS / AD Domain Controller, ADC), and the Cockpit Domain Controller (CDC).

[0003] In the evolution towards a three-domain centralized architecture, the amount of diagnostic data generated by domain controllers has surged. According to a Bosch 2024 report, a single smart car uploads over 2TB of ECU diagnostic data daily, covering critical information such as fault codes, operating parameters, and safety logs. This data, uploaded to an enterprise-level diagnostic server via an in-vehicle T-Box, has become a core asset for vehicle health management. However, although existing vehicle diagnostic systems have implemented cloud storage for diagnostic data, the data organization remains highly fragmented. Taking a single ECU as an example, its complete information is broken down and scattered across multiple independent business modules: fault codes are typically stored in the "fault management" system, telemetry parameters reside in the "real-time monitoring platform," frozen frame snapshots are saved in the "event retrospective" module, firmware versions are recorded in the "device asset management" system, and communication logs may be stored in another network diagnostic platform. When performing fault analysis, engineers have to repeatedly switch between different system pages and repeatedly enter the same query conditions (such as VIN, time range, etc.) to manually piece together fragmented information. This fragmented architecture severely restricts diagnostic efficiency and accuracy. For example, EEPROM data parsing contains crucial clues such as reset reasons and Trap stack information. Correct interpretation relies on a matching software version and corresponding configuration code (e.g., a decoding mapping table or symbol file). In the current process, engineers must manually obtain the raw EEPROM data, the vehicle's software version number at that moment, and the corresponding configuration code file from multiple systems. They then use local scripts to parse the data line by line to reconstruct the event context. This entire process is highly dependent on personal experience, taking hours or even days, and is extremely prone to misjudgments due to version mismatches or data omissions. Summary of the Invention

[0004] This invention provides a vehicle diagnostic data processing method, apparatus, electronic device, and cloud server to solve the problem of highly fragmented data organization in existing vehicle diagnostic systems.

[0005] In a first aspect, the present invention provides a vehicle diagnostic data processing method applied to a cloud server. The method includes the following steps: receiving a diagnostic request; determining the task type according to the diagnostic request, and calling a registered functional module interface based on the task type; calling the functional module interface to obtain multi-type diagnostic data related to the diagnostic request from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data respectively; and parsing the multi-type diagnostic data based on the context information in the multi-type diagnostic data to obtain a diagnostic result.

[0006] The vehicle diagnostic data processing method provided by this invention receives diagnostic requests uniformly on a cloud server and dynamically calls registered functional module interfaces based on task type. This enables the automatic acquisition of multiple types of diagnostic data from multiple dispersed business systems, effectively breaking down data silos between existing systems. Furthermore, by utilizing the contextual information embedded in various types of data for correlation parsing, the method achieves automatic integration and version matching of diagnostic data, significantly improving the efficiency and accuracy of fault analysis and solving the problem of highly fragmented data organization in existing vehicle diagnostic systems.

[0007] In some alternative implementations, before parsing the multi-type diagnostic data based on contextual information in the multi-type diagnostic data, the method further includes aligning the diagnostic data from different ECUs based on a common timestamp or common event identifier when the multi-type diagnostic data involves multiple electronic control units (ECUs).

[0008] This implementation method accurately aligns multi-source diagnostic data by introducing common timestamps or common event identifiers, ensuring that data from different domain controllers such as vehicle control domain, intelligent driving domain, and intelligent cockpit domain are fused under a unified time or event benchmark, thereby restoring the real vehicle operating state sequence.

[0009] In some optional implementations, determining the task type based on the diagnostic request includes: if the diagnostic request is a fixed-format instruction, extracting the task type from the diagnostic request using a preset regular expression; if the diagnostic request is natural language, processing the diagnostic request using a preset language recognition model to obtain the task type; if the diagnostic request is a table containing structured instructions, parsing the table's field content and determining the task type according to preset field mapping rules.

[0010] This implementation method supports multiple diagnostic request input formats and adopts an adaptive parsing strategy, enabling intelligent and accurate identification of task types and improving the system's compatibility with different user habits and tool ecosystems.

[0011] In some optional implementations, before calling the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data, the method further includes: validating the task type and the task parameters associated with the task type, wherein the task parameters include vehicle model code, vehicle identification code and time range, and the validity verification includes verifying whether the vehicle model code belongs to the supported vehicle model list, whether the vehicle identification code conforms to the standard encoding format, and whether the time range is within the allowed historical data query window.

[0012] This implementation method performs a pre-validation check on the task type and its associated parameters before calling the interfaces of various business systems. This can effectively intercept illegal or invalid requests and avoid invalid data queries, waste of system resources, or subsequent parsing anomalies caused by input errors.

[0013] In some optional implementations, calling the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request from multiple independent business systems includes: sending a data acquisition command carrying a data identifier to the vehicle's T-Box, the data identifier being determined based on the diagnostic request; receiving diagnostic data returned by the vehicle through the T-Box, the diagnostic data being collected by the vehicle's domain controller from its subordinate sub-controllers according to the data identifier and then uploaded.

[0014] This implementation sends a collection command carrying a specific data identifier to the vehicle's T-Box via a cloud server. The domain controller then accurately retrieves diagnostic data related to the diagnostic request from its subordinate sub-controllers as needed and sends it back, realizing a data acquisition mechanism of "on-demand retrieval and accurate collection".

[0015] In some optional implementations, before calling the functional module interface, the method further includes: combining the task type, the task parameters associated with the task type, and the user terminal identifier into a task object, and storing the task object in a task queue; after obtaining the diagnostic result, combining the diagnostic result with the user terminal identifier into a result object, and storing the result object in a task result queue.

[0016] This implementation achieves a standardized scheduling and asynchronous processing mechanism for diagnostic tasks by encapsulating the task type, task parameters, and user terminal identifier into a task object and queuing it before calling the functional module interface, and binding the generated diagnostic results with the user terminal identifier to form a result object and storing it in the result queue. This not only supports orderly task management and load balancing in high-concurrency scenarios, preventing system overload, but also ensures that diagnostic results can be accurately and reliably transmitted back to the corresponding user terminal, improving system traceability, stability, and user experience.

[0017] Secondly, the present invention also provides a vehicle diagnostic data processing device applied to a cloud server. The device includes an acquisition module, a task type determination module, a diagnostic data acquisition module, and a parsing module. The acquisition module is used to receive diagnostic requests. The task type determination module is used to determine the task type according to the diagnostic request and call the registered functional module interface based on the task type. The diagnostic data acquisition module is used to call the functional module interface to acquire multiple types of diagnostic data related to the diagnostic request from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data. The parsing module is used to parse the multiple types of diagnostic data based on the context information in the multiple types of diagnostic data to obtain diagnostic results.

[0018] Thirdly, the present invention also provides a cloud server, including a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform the vehicle diagnostic data processing method described in the first aspect or any of its corresponding embodiments.

[0019] Fourthly, the present invention also provides a computer-readable storage medium storing computer instructions for causing a computer to execute the vehicle diagnostic data processing method of the first aspect or any corresponding embodiment thereof.

[0020] Fifthly, the present invention also provides a computer program product, including computer instructions for causing a computer to execute the vehicle diagnostic data processing method of the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1This is a schematic diagram of a vehicle diagnostic system according to an embodiment of the present invention; Figure 2 This is a first flowchart of a vehicle diagnostic data processing method according to an embodiment of the present invention; Figure 3 This is a second flowchart of a vehicle diagnostic data processing method according to an embodiment of the present invention; Figure 4 This is a third flowchart of the vehicle diagnostic data processing method according to an embodiment of the present invention; Figure 5 This is a diagram illustrating the interaction framework between the intelligent dialogue platform and the user terminal. Figure 6 This is a diagram of the internal framework of the task processing engine; Figure 7 This is a structural block diagram of a vehicle diagnostic data processing device according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0025] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] As an optional application scenario of this invention, such as Figure 1As shown, the vehicle diagnostic system comprises four parts: a user terminal, a cloud server, a vehicle TBox (Telematics Box), and a vehicle controller. Users initiate diagnostic information retrieval requests through their user terminals (including client or mobile clients). This system framework supports concurrent requests from multiple clients or mobile clients. User requests are sent to the cloud server via a TSP (Telematics Service Provider).

[0027] In the cloud server, the system makes intelligent decisions through modules such as algorithm analysis, AI large-scale models, and task execution, and completes task processing by combining functions such as information verification, parameter verification, and data assembly. The processed tasks are then sent to the vehicle's TBOX via vehicle-to-everything (V2X) communication. Specifically, the cloud server includes an intelligent dialogue platform and a task processing engine. The user terminal software (supporting PC and mobile devices) interacts with the intelligent dialogue platform through sending and receiving user messages. Furthermore, to ensure communication security and efficiency, both the terminal software and the intelligent dialogue platform integrate data encryption functions and employ data compression transmission technology to reduce transmission load and meet the needs of high-frequency data interaction. The task processing engine includes a task execution module and a data assembly module.

[0028] The vehicle-mounted TBox undertakes the core functions of vehicle-to-everything (V2X) communication, data acquisition, and signal deployment. Upon receiving a task from the cloud, the TBox checks whether it has deployed the data acquisition capabilities required for that task. If it has, the TBox immediately sends a data acquisition command to the vehicle controller; otherwise, it returns a negative result for the request.

[0029] The vehicle controller comprises a domain controller and its subordinate sub-controllers. Upon receiving a data acquisition request from the TBox, the domain controller requests specified signal data or diagnostic information from each sub-controller via the CAN / LIN bus. The sub-controllers then relay this information to the domain controller, which in turn uploads this data to the cloud server via the vehicle-side TBox.

[0030] Finally, the cloud server assembles and processes the received data and sends the task execution results back to the user terminal.

[0031] According to an embodiment of the present invention, a vehicle diagnostic data processing method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] This embodiment provides a vehicle diagnostic data processing method that can be used on a cloud server. Figure 2This is a first flowchart of a vehicle diagnostic data processing method according to an embodiment of the present invention, as follows: Figure 2 As shown, the process includes the following steps: Step S201: Receive diagnostic request.

[0033] A diagnostic request refers to a data query or analysis command initiated by a user terminal to a cloud server to obtain specific vehicle status or fault analysis results.

[0034] Step S202: Determine the task type based on the diagnostic request, and call the registered functional module interface based on the task type.

[0035] The task type is the specific diagnostic target or analysis category identified based on the diagnostic request. It is used to clarify the intent and scope of this diagnostic operation, including EEPROM data export, event snapshot backtracking, ECU health report generation, or multi-ECU joint event analysis, etc. Different task types correspond to different data requirements and processing logic.

[0036] The functional module interface is a standardized service interface pre-registered in the cloud, used to connect with various independent business systems, and encapsulates details such as data query, authentication and format conversion.

[0037] Step S203: Call the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request from multiple independent business systems, where the multiple independent business systems are used to store different categories of diagnostic data.

[0038] The diagnostic data types include fault codes, freeze frame snapshots, telemetry operating parameters, bus communication logs, ECU firmware and software version information, as well as system security logs and trap stacks.

[0039] Step S204: Analyze the multi-type diagnostic data based on the contextual information in the multi-type diagnostic data to obtain the diagnostic results.

[0040] The vehicle diagnostic data processing method provided in this embodiment receives diagnostic requests uniformly on a cloud server and dynamically calls registered functional module interfaces based on task type. This enables the automatic acquisition of various types of diagnostic data from multiple dispersed business systems, effectively breaking down data silos between existing systems. Furthermore, by utilizing the contextual information embedded in various types of data for correlation analysis, the method achieves automatic integration and version matching of diagnostic data, significantly improving the efficiency and accuracy of fault analysis. This provides a reliable data foundation for subsequent automated root cause localization, real-time early warning, and large-scale fleet health management, greatly reducing reliance on human experience and the risk of misjudgment.

[0041] This embodiment provides a vehicle diagnostic data processing method that can be used on a cloud server. Figure 3This is a second flowchart of a vehicle diagnostic data processing method according to an embodiment of the present invention, as follows: Figure 3 As shown, the process includes the following steps: Step S301: Receive diagnostic request.

[0042] Specifically, determining the task type based on the diagnostic request includes: if the diagnostic request is a fixed-format instruction, the task type is extracted from the diagnostic request using a preset regular expression; if the diagnostic request is natural language, the diagnostic request is processed using a preset language recognition model to obtain the task type; if the diagnostic request is a table containing structured instructions, the table's field content is parsed, and the task type is determined according to preset field mapping rules.

[0043] Step S302: Determine the task type based on the diagnostic request, and call the registered functional module interface based on the task type.

[0044] Step S303: Call the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request from multiple independent business systems, where the multiple independent business systems are used to store different categories of diagnostic data.

[0045] Step S304: When multiple types of diagnostic data involve multiple electronic control units (ECUs), align the diagnostic data from different ECUs based on a common timestamp or common event identifier.

[0046] This is because diagnostic data across ECUs (such as data from multiple electronic control units that collaborate on the same function, including radar, cameras, brake controllers, and gateways) are typically scattered across multiple isolated, independent business systems with inconsistent technology stacks. Furthermore, the lack of a unified time base or common event identifier leads to fragmented context between the raw data. Engineers must manually compare timestamps and piece together logs one by one to barely reconstruct the complete scenario at the time of the fault. This embodiment introduces a common timestamp or common event identifier to accurately align multi-source diagnostic data, ensuring that data from different domain controllers, such as the vehicle control domain, intelligent driving domain, and intelligent cockpit domain, are fused under a unified time or event base, thereby reconstructing the true sequence of vehicle operating states.

[0047] Step S305: Parse the multi-type diagnostic data based on the contextual information in the multi-type diagnostic data to obtain the diagnostic results.

[0048] The vehicle diagnostic data processing method provided in this embodiment receives diagnostic requests uniformly on a cloud server and dynamically calls registered functional module interfaces based on task type. It can automatically obtain multiple types of diagnostic data from multiple distributed business systems. When multiple types of diagnostic data involve multiple electronic control units (ECUs), the diagnostic data from different ECUs are aligned based on a common timestamp or common event identifier. This not only solves the technical problem in related technologies that data from the same ECU needs to be obtained from different system pages, but also solves the technical problem in related technologies that data from different ECUs needs to be manually associated.

[0049] This embodiment provides a vehicle diagnostic data processing method that can be used on a cloud server. Figure 4 This is a third flowchart of the vehicle diagnostic data processing method according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps: Step S401: Receive diagnostic request.

[0050] Step S402: Determine the task type based on the diagnostic request, and call the registered functional module interface based on the task type.

[0051] like Figure 5 As shown, the user terminal can send diagnostic requests to the intelligent dialogue platform. These requests can be fixed-format commands or natural language. Based on the diagnostic request, the platform obtains the task type and task parameters, where the task parameters include at least one of the following: vehicle model code, vehicle identification number (VIN), and time range. For example, suppose a user needs to obtain EEPROM data from a controller within a specific time period for troubleshooting. The user can send the request in the following two ways: 1. Fixed format instruction: <vehicle model code>_EEPROM_<vehicle identification number>_<time range> (e.g., ModelA_EEPROM_VIN123456_20250101-20250131) 2. Natural Language Command: Retrieve the EEPROM data of Model A (vehicle code) with VIN123456 from January 1, 2025 to January 31, 2025.

[0052] After receiving the instruction, the intelligent dialogue platform obtains the task type as EEPROM and the task parameters as: vehicle model code, vehicle identification number (VIN), and time range.

[0053] Based on the concept of customer service dialogue, an AI engine is introduced for semantic understanding, enabling end-to-end automation of business processes. Users can conveniently invoke the backend task processing engine through dialogue, effectively solving problems such as tedious manual operations and time and space constraints, significantly improving work efficiency. For example, users only need to use dialogue commands (such as "query the logs of vehicles with VIN XXX"), and the system can automatically pull logs and parse data, achieving fully automated processing; it supports initiating multi-task parallel execution through dialogue (such as "pull data for VIN XXX and YYY simultaneously"), significantly improving data processing efficiency; for the parsing of some data, the system relies on a file library self-updating mechanism to ensure compatibility with software versions officially released within the last six months, reducing system maintenance costs.

[0054] Step S403: Perform validity checks on the task type and the task parameters associated with the task type.

[0055] Specifically, the task parameters include vehicle model code, vehicle identification number (VIN), and time range. Validity verification includes verifying whether the vehicle model code belongs to the supported vehicle model list, whether the VIN conforms to the standard encoding format, and whether the time range is within the allowed historical data query window.

[0056] like Figure 5 As shown, the intelligent dialogue platform validates the extracted task type and task parameters. Once the validation is successful, both are passed to the downstream task processing engine.

[0057] Step S404: Combine the task type, the task parameters associated with the task type, and the user terminal identifier into a task object, and store the task object in the task queue.

[0058] Step S405: Obtain the current task object from the task queue, and call the functional module interface to obtain multi-type diagnostic data related to the diagnostic request of the current task object from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data.

[0059] In some optional implementations, retrieving the current task object from the task queue and calling the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request of the current task object from multiple independent business systems includes: Step S4051: Obtain the current task object from the task queue and send a data acquisition command carrying a data identifier to the vehicle's T-Box. The data identifier is determined based on the diagnostic request of the current task object.

[0060] Step S4052: Receive diagnostic data returned by the vehicle via the T-Box. The diagnostic data is collected by the vehicle's domain controller from its subordinate sub-controllers based on the data identifier and then uploaded.

[0061] Step S406: When multiple types of diagnostic data involve multiple electronic control units (ECUs), align the diagnostic data from different ECUs based on a common timestamp or common event identifier.

[0062] Step S407: Parse the multi-type diagnostic data based on the contextual information in the multi-type diagnostic data to obtain the diagnostic results.

[0063] Step S408: After obtaining the diagnostic results, combine the diagnostic results with the user terminal identifier to form a result object, and store the result object in the task result queue.

[0064] For example, such as Figure 6 As shown, the task execution module consists of a task management unit (Task Manager) and a task execution unit (Running Manager). The two units interact through the get() and put() interfaces of the task management unit's queue. The get() interface retrieves tasks from the task queue, and the put() interface puts the execution results into the result queue. These interfaces are thread-safe.

[0065] The task management unit primarily comprises two queues: a task result queue and a task queue. Each element in the task queue contains the parameters required for the task, the task type, and the user terminal ID, where the user terminal ID is used to establish a one-to-one relationship between the task and the user. Each element in the task result queue contains the result corresponding to the task type and the user terminal ID. Task results support both file and string types, and the user terminal ID is used by the information management unit to accurately return the result to the corresponding user. Both queues are thread-safe.

[0066] The task execution unit mainly consists of three components: a task allocator, a process / thread pool, and functional module interfaces. Each functional module interface becomes a supported interface of the execution module through "registration." Upon receiving a task, it is placed into the process / thread pool, and the result is obtained through the functional module interface. The task allocator maintains the "registered" interface information and selects the corresponding functional interface based on the task type. The process / thread pool provides the ability to execute tasks in parallel, improving the system's ability to handle task requests. The functional module interfaces are the concrete implementation interfaces of the functions and encapsulate the required results for return.

[0067] The task execution module consists of a task management unit and a task execution unit, which work together through a thread-safe queue interface. When a user requests EEPROM data for a specific vehicle within a specified time range (e.g., via the command "ModelA_EEPROM_VIN123456_20250101-20250131"), the intelligent dialogue platform parses and generates a task element containing the task type (EEPROM_DUMP), task parameters (vehicle model code, VIN, time range), and user terminal ID. This element is then written to the task queue via the thread-safe put() interface of the task management unit. The task allocator of the task execution unit retrieves the task via the get() interface, matches it to the registered EEPROM function interface based on the task type, and schedules execution via a thread pool: it calls the vehicle communication interface to send a command to the target vehicle's TBox, retrieves the raw EEPROM data for the specified time period, and encapsulates it into a compressed file. The execution result, including the file storage path and the associated user terminal ID, is stored in the result queue via the put() interface. The task management unit pushes the result to the intelligent dialogue platform, ultimately returning the data file precisely to the user terminal that initiated the request. This engine decouples different diagnostic information acquisition methods through a dynamic interface registration mechanism, improving system maintainability and scalability. It also enables asynchronous, non-blocking task calls, enhancing task performance. A thread-safe queue ensures high-concurrency processing capabilities, and a user binding mechanism guarantees the accuracy of data returns, achieving automated and secure collection and distribution of vehicle diagnostic data.

[0068] The vehicle diagnostic data processing method provided in this embodiment not only addresses the highly fragmented data organization problem of existing vehicle diagnostic systems, but also achieves intelligent and accurate identification of task types by supporting multiple diagnostic request input formats and adopting an adaptive parsing strategy, thereby improving the system's compatibility with different user habits and tool ecosystems. Furthermore, by encapsulating the task type, task parameters, and user terminal identifier into a task object and queuing it before calling the functional module interface, and binding the diagnostic result with the user terminal identifier to form a result object and storing it in the result queue after generating the diagnostic result, a standardized scheduling and asynchronous processing mechanism for diagnostic tasks is achieved.

[0069] This embodiment also provides a vehicle diagnostic data processing device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0070] This embodiment provides a vehicle diagnostic data processing device, such as... Figure 7As shown, it includes: The acquisition module 701 is used to receive diagnostic requests.

[0071] The task type determination module 702 is used to determine the task type based on the diagnostic request and call the registered functional module interface based on the task type.

[0072] The diagnostic data acquisition module 703 is used to call the functional module interface to obtain various types of diagnostic data related to the diagnostic request from multiple independent business systems, where the multiple independent business systems are used to store different categories of diagnostic data.

[0073] The parsing module 704 is used to parse multi-type diagnostic data based on contextual information in the multi-type diagnostic data to obtain diagnostic results.

[0074] In some optional implementations, the vehicle diagnostic data processing apparatus further includes a data alignment module. Before parsing the multi-type diagnostic data based on contextual information within the multi-type diagnostic data, the data alignment module aligns diagnostic data from different ECUs based on a common timestamp or common event identifier when the multi-type diagnostic data involves multiple electronic control units (ECUs).

[0075] In some optional implementations, the task type determination module 702 is specifically used for: if the diagnostic request is a fixed-format instruction, extracting the task type from the diagnostic request using a preset regular expression; if the diagnostic request is natural language, processing the diagnostic request using a preset language recognition model to obtain the task type; if the diagnostic request is a table containing structured instructions, parsing the table's field content and determining the task type according to preset field mapping rules.

[0076] In some optional implementations, the vehicle diagnostic data processing device further includes a validity verification module. Before calling the functional module interface to obtain various types of diagnostic data related to the diagnostic request from multiple independent business systems, where each independent business system stores different categories of diagnostic data, the validity verification module performs validity verification on the task type and the task parameters associated with the task type. The task parameters include the vehicle model code, vehicle identification number, and time range. The validity verification includes verifying whether the vehicle model code belongs to the supported vehicle model list, whether the vehicle identification number conforms to the standard encoding format, and whether the time range is within the allowed historical data query window.

[0077] In some optional implementations, the diagnostic data acquisition module 703 is used to: send a data acquisition command carrying a data identifier to the vehicle's T-Box, the data identifier being determined based on a diagnostic request; and receive diagnostic data returned by the vehicle through the T-Box, the diagnostic data being collected by the vehicle's domain controller from its subordinate sub-controllers according to the data identifier and then uploaded.

[0078] In some optional implementations, the vehicle diagnostic data processing device further includes a task management module. Before calling the functional module interface, the task management module combines the task type, the task parameters associated with the task type, and the user terminal identifier into a task object, and stores the task object in a task queue; after obtaining the diagnostic result, the task management module combines the diagnostic result and the user terminal identifier into a result object, and stores the result object in a task result queue.

[0079] The vehicle diagnostic data processing device provided in this embodiment of the invention can execute the vehicle diagnostic data processing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0080] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0081] The following is a detailed reference. Figure 8 This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 801, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0082] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0083] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the vehicle diagnostic data processing method of the embodiments of the present invention.

[0084] Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0085] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the vehicle diagnostic data processing method shown in the above embodiments is implemented.

[0086] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0087] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for processing vehicle diagnostic data, characterized in that, Applied to a cloud server, the method includes: Receive diagnostic request; The task type is determined based on the diagnostic request, and the registered functional module interface is invoked based on the task type; The function module interface is invoked to obtain various types of diagnostic data related to the diagnostic request from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data. The diagnostic results are obtained by parsing the multi-type diagnostic data based on the contextual information in the multi-type diagnostic data.

2. The method according to claim 1, characterized in that, Before parsing the multi-type diagnostic data based on the contextual information in the multi-type diagnostic data, the method further includes: When the multi-type diagnostic data involves multiple electronic control units (ECUs), the diagnostic data from different ECUs are aligned based on a common timestamp or common event identifier.

3. The method according to claim 1, characterized in that, Determining the task type based on the diagnostic request includes: If the diagnostic request is a fixed-format instruction, the task type is extracted from the diagnostic request using a preset regular expression; If the diagnostic request is in natural language, the diagnostic request is processed using a preset language recognition model to obtain the task type; If the diagnostic request is a table containing structured instructions, the field content of the table is parsed, and the task type is determined according to the preset field mapping rules.

4. The method according to claim 1, characterized in that, Before calling the functional module interface to obtain multi-type diagnostic data related to the diagnostic request from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data, the method further includes: The validity of the task type and the task parameters associated with the task type is validated. The task parameters include vehicle model code, vehicle identification number and time range. The validity validation includes verifying whether the vehicle model code belongs to the supported vehicle model list, whether the vehicle identification number conforms to the standard encoding format, and whether the time range is within the allowed historical data query window.

5. The method according to claim 1, characterized in that, The step of calling the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request from multiple independent business systems includes: Send a data acquisition command carrying a data identifier to the vehicle's T-Box, the data identifier being determined based on the diagnostic request; The system receives diagnostic data returned by the vehicle via a T-Box. This diagnostic data is collected and uploaded by the vehicle's domain controller from its subordinate sub-controllers based on the data identifier.

6. The method according to claim 1, characterized in that: Before calling the functional module interface, the method further includes: combining the task type, the task parameters associated with the task type, and the user terminal identifier into a task object, and storing the task object in a task queue; After obtaining the diagnostic results, the diagnostic results are combined with the user terminal identifier to form a result object, and the result object is stored in the task result queue.

7. A vehicle diagnostic data processing device, characterized in that, The device, used in a cloud server, includes: The acquisition module is used to receive diagnostic requests; The task type determination module is used to determine the task type based on the diagnostic request and call the registered functional module interface based on the task type. The diagnostic data acquisition module is used to call the functional module interface to obtain multiple types of diagnostic data related to the diagnostic request from multiple independent business systems, wherein the multiple independent business systems are used to store different categories of diagnostic data. The parsing module is used to parse the multi-type diagnostic data based on the context information in the multi-type diagnostic data to obtain diagnostic results.

8. A cloud server, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the vehicle diagnostic data processing method according to any one of claims 1 to 6 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the vehicle diagnostic data processing method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to perform the vehicle diagnostic data processing method according to any one of claims 1 to 6.

Images