A method and system for combining on-vehicle diagnosis and remote diagnosis

Abstract

The present application provides a method and system for combining on-vehicle diagnosis and remote diagnosis, which relates to the technical field of automotive fault diagnosis. The method includes: converting diagnostic service data into a diagnostic script and deploying it to an on-vehicle diagnostic unit to generate a preliminary diagnostic result based on fault data; sending the preliminary diagnostic result and the fault data to a regional diagnostic center to match corresponding computing resources for coordinated analysis and generate an intermediate diagnostic plan; when the confidence level of the intermediate diagnostic plan is lower than a preset threshold, submitting the preliminary diagnostic result, the fault data, and the intermediate diagnostic plan to a cloud server for in-depth analysis to obtain an optimized diagnostic strategy, and separately sending them to the on-vehicle diagnostic unit and the regional diagnostic center to complete collaborative diagnosis. Implementing this method, by constructing a three-level diagnostic architecture, different architectures complete fault diagnoses of different complexities, relieving the pressure on the remote platform, achieving reasonable allocation of computing resources, and improving the overall diagnostic efficiency.

Description

Technical Field

[0001] This application relates to the technical field of vehicle fault diagnosis, and particularly to a method and system for combining on-vehicle diagnosis and remote diagnosis. Background Art

[0002] With the continuous improvement of the electronic level of vehicles, the complexity of vehicle fault diagnosis has also increased. In order to accurately identify and timely handle various faults, the vehicle diagnosis system needs to have both fast response and in-depth analysis capabilities. Currently, vehicle diagnosis has evolved from single on-vehicle diagnosis to a comprehensive solution that combines on-vehicle diagnosis and remote diagnosis.

[0003] In related technologies, the vehicle diagnosis system usually adopts a two-level diagnosis architecture, that is, the on-vehicle diagnosis device is responsible for collecting fault data and performing preliminary analysis. When encountering complex faults, the data is transmitted to the remote diagnosis platform. The remote diagnosis platform is equipped with professional diagnosis devices and technicians. By analyzing the fault data uploaded by the on-vehicle device and combining historical maintenance cases and expert experience, a diagnosis solution is provided for the vehicle. At the same time, the remote platform will regularly push updated diagnosis rules to the on-vehicle diagnosis device to improve the diagnosis ability of the on-vehicle side.

[0004] However, this two-level diagnosis architecture has obvious deficiencies in dealing with faults of a large-scale fleet. When multiple vehicles simultaneously encounter complex faults that require remote diagnosis, all diagnosis requests are directly sent to the remote platform, resulting in a serious backlog of remote computing resources. In addition, each diagnosis request requires a complete remote diagnosis process. Even for common faults with high repeatability, a large amount of remote computing resources will be occupied. This direct docking method leads to low overall diagnosis efficiency. Summary of the Invention

[0005] This application provides a method and system for combining on-vehicle diagnosis and remote diagnosis to solve the technical problem of low efficiency in allocating diagnosis resources in the existing vehicle diagnosis system.

[0006] In a first aspect, this application provides a method for combining on-vehicle diagnosis and remote diagnosis, which is applied to a vehicle diagnosis system. The method includes:

[0007] Import diagnostic service data through a diagnostic database generation tool, and convert the diagnostic service data into diagnostic scripts based on a preset detection process development platform. The diagnostic service data includes CDD data format, ODX data format, and Excel data format;

[0008] Deploy the diagnostic script to the on-vehicle diagnostic unit, and generate a preliminary diagnosis result based on the fault data. The fault data includes fault codes, vehicle condition data, and environmental data;

[0009] Send the preliminary diagnosis result and the fault data to the regional diagnosis center, match the corresponding computing resources to construct a vehicle diagnosis cluster for coordinated analysis, and generate an intermediate diagnosis plan;

[0010] When the confidence level of the intermediate diagnosis plan is lower than the preset threshold, submit the preliminary diagnosis result, the fault data, and the intermediate diagnosis plan to the cloud server for in-depth analysis to obtain an optimized diagnosis strategy. The cloud server includes a deep learning model training center, a knowledge graph builder, and an expert experience library;

[0011] Send the optimized diagnosis strategy to the temporary knowledge bases of the on-vehicle diagnostic unit and the regional diagnosis center respectively to complete collaborative diagnosis.

[0012] Through the above embodiments, the vehicle diagnosis system constructs a three-level diagnosis architecture of "on-vehicle diagnostic unit - regional diagnosis center - cloud server", which specifically solves the problem of low efficiency in diagnosing resource allocation in the existing system. Specifically, the standardized diagnostic service data is converted into diagnostic scripts and deployed to the on-vehicle side, enabling simple faults to be quickly processed locally and avoiding unnecessary remote requests; secondly, the regional diagnosis center is introduced as an intermediate layer, and through the dynamic matching of computing resources and cluster collaborative analysis, the decentralized processing of medium-complexity faults is realized, alleviating the pressure on the remote platform; finally, the hierarchical processing mechanism based on confidence ensures that only the most complex faults will be submitted to the cloud server for analysis through deep learning and knowledge graphs, realizing the reasonable allocation of computing resources and improving the overall diagnosis efficiency.

[0013] In some embodiments, the step of deploying the diagnostic script to the on-vehicle diagnostic unit and generating a preliminary diagnosis result based on the fault data specifically includes:

[0014] When a fault trigger event is detected, start a hierarchical progressive data acquisition mechanism to obtain the first batch of fault data, and establish a fault feature model based on the first batch of fault data. The fault feature model is used to describe the development trend of the fault;

[0015] According to the analysis result of the fault feature model, determine the list of fault-related components, and calculate the sampling priority of each related component. The sampling priority determines the data sampling frequency of the related component;

[0016] Determine the vehicle historical operation data for expanding the data sampling range according to the sampling priority and the fault feature model. The time span of the vehicle historical operation data is determined by the fault feature model;

[0017] Perform time-series correlation analysis on the first batch of fault data, the sampling data of the related components, and the vehicle historical operation data to generate a preliminary diagnosis result including the fault propagation path.

[0018] Through the above embodiments, the vehicle diagnosis system realizes the accurate acquisition of fault data through a hierarchical progressive data acquisition mechanism. Dynamically determining the sampling range and priority based on the fault feature model avoids the waste of resources caused by a large amount of redundant data acquisition in traditional methods. At the same time, through the calculation of the sampling priority of associated components and the selective acquisition of historical operation data, the timely acquisition of key data is ensured. Finally, the fault propagation path generated through time-series correlation analysis provides a reliable data basis for subsequent diagnostic analysis, improving the accuracy of preliminary diagnosis on the vehicle side.

[0019] In some embodiments, the step of constructing a vehicle diagnosis cluster by matching corresponding computing resources for coordinated analysis and generating an intermediate diagnosis scheme specifically includes:

[0020] Extract features from the preliminary diagnosis result and the fault data to generate a multi-dimensional fault feature vector including fault type, fault severity, and fault development trend;

[0021] According to the calculation result of the multi-dimensional fault feature vector, match corresponding heterogeneous computing resources from the computing resource pool and form them into a diagnosis cluster;

[0022] Through the diagnosis cluster, parallel processing is performed on the diagnosis requests of fault feature vectors with a similarity lower than a preset similarity threshold to generate an intermediate diagnosis scheme.

[0023] Through the above embodiments, the vehicle diagnosis system provides efficient cluster diagnosis capabilities through the intelligent combination of multi-dimensional fault feature vectors and heterogeneous computing resources. The feature vector includes fault type, severity, and development trend, providing a comprehensive decision-making basis for resource matching. At the same time, the repetitive diagnosis is avoided through the similarity threshold filtering mechanism, and combined with the parallel processing technology, the optimal utilization of computing resources is achieved, greatly improving the processing efficiency of the regional diagnosis center.

[0024] In some embodiments, the step of performing parallel processing on the diagnosis requests of fault feature vectors with a similarity lower than a preset similarity threshold through the diagnosis cluster to generate an intermediate diagnosis scheme specifically includes:

[0025] Monitor the task queue and resource occupancy rate of each node in the diagnosis cluster. When the length of the task queue exceeds the first preset threshold or the resource occupancy rate exceeds the second preset threshold, trigger the task reallocation mechanism;

[0026] Based on the computational complexity of the multi-dimensional fault feature vector, divide the diagnosis requests into lightweight task packets and heavyweight task packets, where the computational complexity is determined by the computing resources required for fault feature similarity calculation;

[0027] Allocate the heavyweight task packages to a sub-cluster composed of high-performance computing nodes for processing, and at the same time allocate the lightweight task packages to ordinary computing nodes for processing;

[0028] Perform chronological merging on the diagnostic results of the sub-cluster and the ordinary computing nodes to generate an intermediate diagnostic plan.

[0029] Through the above embodiments, the vehicle diagnostic system introduces a task grading processing mechanism. Through task queue monitoring and dynamic load balancing, the efficient operation of the diagnostic cluster is ensured. Based on the task classification and node matching strategy of computational complexity, waste of high-performance computing resources is avoided. At the same time, the consistency of distributed processing results is ensured through the chronological merging mechanism, providing technical guarantee for quickly generating reliable intermediate diagnostic plans.

[0030] In some embodiments, the step of separately sending the optimized diagnostic strategy to the temporary knowledge bases of the on-vehicle diagnostic unit and the regional diagnostic center to complete collaborative diagnosis specifically includes:

[0031] Establish a diagnostic knowledge cache pool for storing local diagnostic experience in the on-vehicle diagnostic unit, where the local diagnostic experience includes fault characteristics, diagnostic paths, and repair plans;

[0032] When the update frequency of the diagnostic knowledge cache pool is lower than a preset frequency threshold, upload the local diagnostic experience to the temporary knowledge base of the regional diagnostic center to generate a knowledge update package, where the knowledge update package includes a priority label and a resource requirement index;

[0033] Calculate a resource status index based on the storage capacity and processing capacity of the on-vehicle diagnostic unit itself, and screen the knowledge update package based on the resource status index to achieve asynchronous update of the diagnostic knowledge in the diagnostic knowledge cache pool.

[0034] Through the above embodiments, the vehicle diagnostic system realizes the efficient management and sharing of diagnostic knowledge by establishing a hierarchical knowledge storage architecture. The design of the diagnostic knowledge cache pool enables the on-vehicle side to quickly respond to common faults. Through the knowledge synchronization mechanism based on the update frequency and the screening strategy of the resource status index, it is ensured that knowledge updates do not affect system performance. This asynchronous update mechanism significantly improves the system's response speed and provides reliable knowledge support for collaborative diagnosis.

[0035] In some embodiments, after any of the preliminary diagnostic results, the intermediate diagnostic plan, and the optimized diagnostic strategy are generated, the method further includes:

[0036] If the current diagnostic result includes multiple optional diagnostic solutions, the repair instructions corresponding to each diagnostic solution are executed in sequence or a repair operation prompt is sent to the driver. The diagnostic result includes the preliminary diagnostic result, the intermediate diagnostic solution, and the optimized diagnostic strategy;

[0037] Obtain the execution result of the repair instruction or the feedback information of the repair operation, and determine whether the fault is resolved according to the execution result or the feedback information;

[0038] If the fault has been resolved, terminate the diagnostic process; if the fault has not been resolved, continue to generate the next diagnostic result after updating the current diagnostic result until the optimized diagnostic strategy is generated.

[0039] Through the above embodiments, the vehicle diagnostic system immediately verifies after generating the diagnostic result at each diagnostic level, and decides whether to call higher-level diagnostic resources according to the verification result, realizing the on-demand allocation and hierarchical call of diagnostic resources, avoiding the problem of blindly transmitting diagnostic data and occupying computing resources between the in-vehicle diagnostic unit, the regional diagnostic center, and the cloud server, thereby improving the allocation efficiency of diagnostic resources in the entire vehicle diagnostic system.

[0040] In some embodiments, the step of screening the knowledge update package based on the resource status index to realize the asynchronous update of diagnostic knowledge in the diagnostic knowledge cache pool specifically includes:

[0041] Evaluate the reliability of the diagnostic knowledge in the screened knowledge update package to generate a performance index matrix including diagnostic accuracy and repair efficiency;

[0042] Based on the performance index matrix, divide the diagnostic knowledge in the diagnostic knowledge cache pool into a reserved area and a to-be-replaced area, and the reserved area stores diagnostic knowledge with high performance indicators;

[0043] Select the diagnostic knowledge with performance indicators higher than those in the to-be-replaced area from the knowledge update package for update, so as to maintain the optimal diagnostic strategy combination in the diagnostic knowledge cache pool.

[0044] Through the above embodiments, the vehicle diagnostic system introduces a knowledge quality evaluation mechanism to realize the dynamic optimization management of diagnostic knowledge. By generating a performance index matrix through reliability evaluation and combining the partition storage strategy of the reserved area and the to-be-replaced area, the continuous accumulation of high-quality diagnostic knowledge is ensured. This performance-based selective update mechanism not only improves the practicality of diagnostic knowledge but also improves the storage efficiency through precise update, providing technical support for maintaining the optimal diagnostic strategy combination.

[0045] In a second aspect, the present application provides a vehicle diagnostic system, which includes: one or more processors and a memory;

[0046] The memory is coupled to the one or more processors, and the memory is used to store computer program code. The computer program code includes computer instructions, and the one or more processors call the computer instructions so that the vehicle diagnostic system can implement a combined vehicle diagnosis and remote diagnosis method provided in the above embodiments, which will not be elaborated here.

[0047] In a third aspect, the present application provides a computer-readable storage medium, including instructions, which, when running on a vehicle diagnostic system, enable the vehicle diagnostic system to implement a combined vehicle diagnosis and remote diagnosis method provided in the above embodiments, which will not be elaborated here.

[0048] In a fourth aspect, the present application provides a computer program product, which, when running on a vehicle diagnostic system, enables the vehicle diagnostic system to implement a combined vehicle diagnosis and remote diagnosis method provided in the above embodiments, which will not be elaborated here.

[0049] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0050] 1. Through the hierarchical architecture of "vehicle diagnostic unit - regional diagnostic center - cloud server" and combined with the confidence-based task distribution strategy, intelligent shunting of diagnostic tasks is achieved. Simple faults are processed at the vehicle end, medium-complexity faults are jointly processed by the computing clusters of the regional diagnostic center, and the most complex faults are only submitted to the cloud for in-depth analysis, effectively solving the problem of low diagnostic resource allocation efficiency in traditional systems. This hierarchical processing mechanism not only avoids the over-concentration of computing resources but also ensures that different complexity faults can be processed in the most suitable way, significantly improving the overall diagnostic efficiency.

[0051] 2. A real-time sharing mechanism for the diagnostic execution task list and intermediate diagnostic status is proposed. Through the two-way real-time interaction between the vehicle end and the regional diagnostic center, dynamic optimization of the diagnostic process is achieved. The system dynamically adjusts the sampling strategy through hierarchical progressive data collection and time-series correlation analysis, combined with the fault feature model, to ensure the accurate acquisition of key data. At the same time, the regional diagnostic center can conduct parallel analysis based on the intermediate diagnostic status and provide real-time optimization suggestions, forming a continuously optimized closed-loop diagnostic system.

[0052] 3. By establishing a hierarchical storage architecture of a diagnostic knowledge cache pool and a temporary knowledge base, and combining a knowledge evaluation mechanism based on a performance metric matrix, intelligent management and optimized update of diagnostic knowledge are achieved. The system stores knowledge in partitions through reliability evaluation and performs selective asynchronous updates based on the resource status index, which not only ensures the continuous accumulation of high-quality diagnostic knowledge but also avoids the impact of frequent updates on system performance. This performance-based knowledge management mechanism provides strong support for maintaining the optimal diagnostic strategy combination. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 is a schematic flowchart of a method for combining on-vehicle diagnosis and remote diagnosis in an embodiment of the present application;

[0054] Figure 2 is a schematic flowchart of an on-vehicle diagnosis unit generating a preliminary diagnosis plan in an embodiment of the present application;

[0055] Figure 3 is a schematic structural diagram of an entity device of a vehicle diagnosis system in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0056] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and appended claims of the present application, the singular forms "a", "an", "the", "above", "said", "this" are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in the present application refers to any and all possible combinations including one or more of the listed items.

[0057] Hereinafter, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "plural" is two or more.

[0058] For ease of understanding, the method provided in this embodiment is described in terms of a process below. Please refer to Figure 1 , which is a schematic flowchart of a method for combining on-vehicle diagnosis and remote diagnosis in an embodiment of the present application.

[0059] S101. Import diagnostic service data through a diagnostic database generation tool and convert the diagnostic service data into a diagnostic script based on a preset detection process development platform.

[0060] Among them, the diagnostic service data covers data sets from different channels and in various formats, including but not limited to CDD (Component Description Definition) files, which are used to describe the internal functions and data structures of automotive electronic control units (ECUs); ODX (Open Diagnostic Data Exchange) files, which are standardized diagnostic data exchange formats widely used in the automotive diagnostic field; Excel files, which contain custom diagnostic-related configuration information or data mapping tables, etc. These data provide key bases for vehicle diagnosis.

[0061] Specifically, the vehicle diagnostic system first conducts data collection and collation work. Collect diagnostic service data in CDD, ODX, and Excel formats from multiple channels. During the collection process, ensure the integrity and accuracy of the data, and mark and correct missing or incorrect data. Then, since these data are in different formats with different structures and specifications, data format adaptation processing is required. For CDD and ODX data, parse and convert them according to their respective standard specifications to ensure that data elements can be correctly identified and extracted; for Excel files, organize them into a format that meets the import requirements of the diagnostic database generation tool according to predefined templates and rules, such as specific column order, data type, etc. After completing the format adaptation, use the import function of the diagnostic database generation tool to import the processed data into it. Pay close attention to the import log during import and promptly handle errors such as data duplication and format mismatch. After the import is completed, conduct a preliminary check on the data to ensure that the data is successfully loaded and its integrity is not affected.

[0062] Then open the diagnostic database generation tool and configure it according to the specific requirements and goals of the automotive diagnostic project, including selecting a diagnostic database template, setting the storage path, defining the data encoding format, etc. At the same time, set the generation parameters according to the characteristics of the automotive ECU and the requirements of the diagnostic protocol, such as diagnostic service mapping rules, data verification methods, etc. After the configuration is completed, start the generation process of the diagnostic database runtime file. The tool will conduct complex analysis, processing, and integration of the imported data to build a diagnostic database structure that meets the automotive diagnostic standards and actual application requirements. After the generation is completed, verify the integrity and accuracy of the file. If there are problems, return to check the parameter settings or data import situation and regenerate. After it is correct, optimize it according to the actual application scenario and performance requirements, such as compressing the file size, optimizing the data storage structure, etc.

[0063] Finally, use the VMDSModel platform to build a development environment, install and configure the platform software to ensure its compatibility with the operating system, database, and other related software tools, and configure development parameters according to the diagnostic project requirements, such as the script language version, code generation rules, debugging options, etc. Based on the functional requirements and diagnostic process of the vehicle diagnostic system, use the provided script language and development tools on the platform to design and develop diagnostic scripts according to the structured and modular programming ideas, write code to implement various diagnostic functions, and obtain the diagnostic scripts after testing and verification.

[0064] It should be noted that the diagnostic database generation tool is a software tool used to process the collected and sorted diagnostic service data to generate a database and related files for use by the vehicle diagnostic system. It has functions such as data import, format conversion, and database construction; in the embodiment of the present application, the preset detection process development platform can select the VMDSModel (Vehicle Measurement and Diagnostic Scripting Model) platform, which is a platform specifically for developing diagnostic scripts. By configuring relevant parameters and using the provided script language and development tools, it can generate diagnostic scripts according to the functional requirements and diagnostic process of the vehicle diagnostic system.

[0065] S102. Deploy the diagnostic script to the on-vehicle diagnostic unit and generate a preliminary diagnostic result based on the fault data.

[0066] Among them, the on-vehicle diagnostic unit is a device installed on the vehicle for real-time monitoring of the vehicle operation status, collecting fault data, and performing preliminary diagnosis; the fault data refers to the data generated when the vehicle has an abnormality, including fault codes, vehicle condition data (such as vehicle speed) and environmental data (such as outside temperature).

[0067] Specifically, the vehicle diagnostic system deploys the diagnostic script generated in step S101 to the on-vehicle diagnostic unit. When the on-vehicle diagnostic unit detects a fault trigger event (such as receiving a fault code signal), it starts the data collection mechanism to collect fault data such as fault codes, vehicle condition data, and environmental data. Then, the on-vehicle diagnostic unit analyzes and processes these fault data according to the diagnostic logic in the diagnostic script, thereby generating a preliminary diagnostic result and initially judging information such as the possible cause and severity of the fault.

[0068] Optionally, after detecting a fault trigger event, the on-vehicle diagnostic unit activates a hierarchical progressive data acquisition mechanism to first obtain the first batch of key fault data, such as fault codes and vehicle condition data directly related to the fault. Based on this data, a simple fault feature model is established to preliminarily determine the possible scope of the fault. Then, according to the analysis results of the model, a list of fault-related components is determined, and the sampling priorities of each related component are calculated. Data sampling is performed on the related components according to the priorities, and the vehicle historical operation data is obtained simultaneously. Finally, the time-series correlation analysis is performed on all the collected data to obtain a preliminary diagnosis result.

[0069] Optionally, after receiving a fault trigger signal, the on-vehicle diagnostic unit quickly collects fault data and compares the data with a pre-stored common fault mode database. If a similar fault mode is matched, a preliminary diagnosis result is directly obtained. If no match is found, the in-depth analysis program in the diagnostic script is activated to perform detailed feature extraction and logical reasoning on the fault data, and combined with the vehicle historical data, a preliminary diagnosis result is generated. It can be understood that other methods can also be used to achieve the preliminary diagnosis, such as using machine learning algorithms to classify and predict the fault data to obtain the preliminary diagnosis result, which is not limited here.

[0070] S103. Send the preliminary diagnosis result and the fault data to the regional diagnosis center, and match the corresponding computing resources to construct a vehicle diagnosis cluster for coordinated analysis to generate an intermediate diagnosis plan.

[0071] Among them, the regional diagnosis center is a component of the vehicle diagnosis system and is a subsystem responsible for centrally analyzing and processing the fault data and preliminary diagnosis results uploaded by multiple on-vehicle diagnostic units; the computing resource pool is a set of deployable computing resources owned by the regional diagnosis center, including computing devices and storage devices with different performances, etc.; the vehicle diagnosis cluster refers to a group of computing devices formed by selecting appropriate computing resources from the computing resource pool and used for collaborative vehicle fault diagnosis analysis.

[0072] Specifically, the on-vehicle diagnostic unit sends the preliminary diagnosis result and the collected fault data to the regional diagnosis center. After receiving the data, the regional diagnosis center performs feature extraction on the preliminary diagnosis result and the fault data to generate a multi-dimensional fault feature vector containing information such as the fault type, fault severity, and fault development trend. According to the calculation results of the vector, the corresponding heterogeneous computing resources are matched from the computing resource pool to form a vehicle diagnosis cluster. Then, the diagnostic cluster is used to parallelly process the diagnostic requests for the fault feature vectors with a similarity lower than the preset similarity threshold, and an intermediate diagnosis plan is obtained through comprehensive analysis.

[0073] Optionally, after receiving the data, the regional diagnostic center first standardizes the fault data and preliminary diagnostic results and unifies the data format. Then, a feature extraction algorithm is used to generate a multi-dimensional fault feature vector. Based on the vector features, computing resources that meet the requirements are screened out from the computing resource pool, such as selecting CPUs and GPUs with different performance based on the computational complexity of the fault. The selected computing resources are organized into a diagnostic cluster to process diagnostic requests in parallel. During the processing, the task queues and resource occupancy rates of each node in the cluster are monitored in real time. When there is a backlog of tasks or resource shortages (the length of the task queue exceeds the first preset threshold or the resource occupancy rate exceeds the second preset threshold), tasks are reallocated. Finally, the diagnostic results of each node are summarized and merged in time series to generate an intermediate diagnostic plan.

[0074] Optionally, the regional diagnostic center can also establish a resource scheduling model, and after receiving the data, input the fault data and preliminary diagnostic results into the model. The resource scheduling model can automatically match computing resources from the computing resource pool to form a diagnostic cluster based on historical diagnostic data and current resource status. The diagnostic cluster uses a distributed computing framework to perform parallel analysis on diagnostic requests. During the analysis process, the task classification mechanism is used to divide the diagnostic requests into lightweight and heavyweight task packages, which are respectively assigned to computing nodes with different performance (including subclusters composed of high-performance computing nodes and ordinary computing nodes) for processing. After the processing is completed, the results of each node are time-series integrated and optimized to generate an intermediate diagnostic plan. It is understandable that other methods can also be used to implement cluster diagnosis, such as using the elastic computing resources of the cloud computing platform to form a diagnostic cluster, which is not limited here.

[0075] S104: When the confidence level of the intermediate diagnosis plan is lower than a preset threshold, the preliminary diagnosis results, fault data, and the intermediate diagnosis plan are submitted to the cloud server for in-depth analysis to obtain an optimized diagnosis strategy.

[0076] The preset threshold is a standard value set by relevant technical personnel to determine the reliability of the intermediate diagnostic solution. When the confidence level is lower than this threshold, it indicates that the intermediate diagnostic solution may be uncertain and requires further analysis. The Deep Learning Model Training Center is a functional module in the cloud server used to train deep learning models. It trains the model with a large amount of historical fault data, enabling it to analyze complex faults. The Knowledge Graph Builder is a tool used to construct a vehicle fault knowledge graph. It organizes various information related to vehicle faults (such as fault causes, fault symptoms, and repair methods) in the form of a graph to facilitate correlation analysis. The Expert Experience Library is a database that stores the experience and knowledge of vehicle diagnostic experts, including treatment methods and suggestions for various faults.

[0077] Specifically, after generating the intermediate diagnosis plan, the regional diagnosis center will evaluate its confidence level. If the evaluation result shows that the confidence level is lower than the preset threshold, the regional diagnosis center will submit the preliminary diagnosis result, fault data, and intermediate diagnosis plan to the cloud server together. After receiving the data, the cloud server uses the model trained by the deep learning model training center, the knowledge graph constructed by the knowledge graph builder, and the knowledge in the expert experience database to deeply analyze this data, comprehensively consider various factors, and obtain an optimized diagnosis strategy.

[0078] Optionally, after receiving the data, the cloud server first preprocesses the data to extract key information. Then, it inputs the data into the deep learning model trained by the deep learning model training center for analysis. The model predicts and judges the current fault based on the fault patterns and rules learned from a large amount of historical data. At the same time, it uses the knowledge graph builder to search for information related to the current fault in the knowledge graph for correlation analysis. Finally, combining the empirical knowledge in the expert experience database, it comprehensively evaluates and optimizes the analysis results of the deep learning model and the knowledge graph to obtain an optimized diagnosis strategy.

[0079] Optionally, the cloud server uses a multi-model fusion method for in-depth analysis. It inputs the preliminary diagnosis result, fault data, and intermediate diagnosis plan into different deep learning models and machine learning algorithms for analysis respectively. Each model and algorithm judges the fault from different perspectives. Then, it fuses the results of each model and algorithm, and combines the knowledge graph and expert experience database for secondary analysis and optimization to finally obtain an optimized diagnosis strategy.

[0080] S105. Send the optimized diagnosis strategy to the on-vehicle diagnosis unit and the temporary knowledge base of the regional diagnosis center respectively to complete collaborative diagnosis.

[0081] Among them, the temporary knowledge base is a storage area in the regional diagnosis center and the on-vehicle diagnosis unit for temporarily storing the optimized diagnosis strategy and other diagnosis knowledge, which is convenient for quick invocation during the diagnosis process.

[0082] Specifically, the cloud server sends the generated optimized diagnosis strategy to the on-vehicle diagnosis unit and the regional diagnosis center respectively. After receiving the optimized diagnosis strategy, the on-vehicle diagnosis unit first stores it in a locally established diagnostic knowledge cache pool. This cache pool is used to store local diagnostic experience, including fault characteristics, diagnostic paths, and repair plans, etc., which is convenient for subsequent quick invocation.

[0083] During the operation of the on-vehicle diagnostic unit, the update frequency of the diagnostic knowledge cache pool is continuously monitored. When the update frequency is lower than the preset frequency threshold, the on-vehicle diagnostic unit sorts out and uploads the local diagnostic experience to the temporary knowledge base of the regional diagnostic center, and at the same time generates a knowledge update package, which carries a priority label and a resource requirement indicator, facilitating the regional diagnostic center to manage and classify these update contents.

[0084] Next, the on-vehicle diagnostic unit calculates the resource status index based on its own storage capacity and processing power. Based on this index, the knowledge update packages returned by the regional diagnostic center are screened. When screening, first evaluate the reliability of the diagnostic knowledge in the screened knowledge update packages, and generate a performance index matrix including diagnostic accuracy and repair efficiency. Then, divide the diagnostic knowledge in the diagnostic knowledge cache pool into a reserved area and a to-be-replaced area according to the performance index matrix. The reserved area is specifically used to store diagnostic knowledge with high performance indicators. Finally, select the diagnostic knowledge with performance indicators higher than those in the to-be-replaced area from the knowledge update package to asynchronously update the diagnostic knowledge cache pool, which can ensure that the optimal diagnostic strategy combination is always maintained in the diagnostic knowledge cache pool.

[0085] After receiving the optimized diagnostic strategy, the regional diagnostic center stores it in its own temporary knowledge base. During subsequent diagnostic processes, the on-vehicle diagnostic unit and the regional diagnostic center jointly diagnose and handle vehicle faults based on these optimized diagnostic strategies, combined with the data and diagnostic experience collected by themselves, to achieve collaborative diagnosis. For example, when the on-vehicle diagnostic unit encounters a fault, it first makes a preliminary diagnosis by referring to the optimized diagnostic strategy in the diagnostic knowledge cache pool and local diagnostic experience, and sends the diagnostic results and relevant data to the regional diagnostic center. The regional diagnostic center then conducts further analysis and verification based on the strategies in the temporary knowledge base and the data uploaded by the on-vehicle diagnostic unit, and gives more accurate diagnostic suggestions. The two parties complete the entire diagnostic process through information interaction and collaboration.

[0086] Optionally, the cloud server sends the optimized diagnostic strategy to the on-vehicle diagnostic unit and the regional diagnostic center through a secure network channel. After receiving the strategy, the on-vehicle diagnostic unit first verifies and decrypts it (if encrypted), and then stores it in the diagnostic knowledge cache pool. A timer is set inside the on-vehicle diagnostic unit to regularly check the update frequency of the diagnostic knowledge cache pool. When the update frequency is lower than the preset frequency threshold, the local diagnostic experience is packaged in a specific data format, and a priority label (such as determining the priority according to the severity and occurrence frequency of the fault) and a resource requirement indicator (such as the estimated occupied storage space, processing time, etc.) are added to generate a knowledge update package and upload it to the regional diagnostic center.

[0087] The on-vehicle diagnostic unit calculates the resource status index by monitoring the remaining space of its own storage device and the usage rates of resources such as CPU and memory. After receiving the knowledge update package, the regional diagnostic center stores it in the temporary knowledge base and filters out the knowledge update package suitable for the on-vehicle diagnostic unit according to the resource status index and returns it. After receiving the returned knowledge update package, the on-vehicle diagnostic unit conducts a reliability assessment on the diagnostic knowledge in it, calculates the diagnostic accuracy rate (for example, calculating the proportion of correct diagnoses by comparing with historical diagnostic data) and the repair efficiency (such as the average time required to repair a fault), and generates a performance index matrix. According to the performance index matrix, the knowledge in the diagnostic knowledge cache pool is divided into a reserved area and a to-be-replaced area, and the knowledge with performance indexes higher than those in the to-be-replaced area is selected from the knowledge update package to asynchronously update the diagnostic knowledge cache pool. During collaborative diagnosis, when the on-vehicle diagnostic unit encounters a fault, it preferentially obtains the diagnostic strategy from the diagnostic knowledge cache pool for preliminary diagnosis, and sends the preliminary diagnosis result, relevant fault data, and its own resource status to the regional diagnostic center. The regional diagnostic center conducts in-depth analysis by combining the strategies in the temporary knowledge base and the received data and returns more complete diagnostic suggestions, and the two parties complete the collaborative diagnosis.

[0088] In addition, when the vehicle diagnostic system generates preliminary diagnosis results, intermediate diagnosis plans, and optimized diagnostic strategies, if the obtained diagnosis results are not uniquely determined but there are multiple alternative diagnostic plans, if the vehicle has the ability to automatically execute repair operations (such as some vehicles with a higher degree of intelligence), the system will sequentially execute the repair instructions corresponding to each diagnostic plan, and let the relevant equipment or systems inside the vehicle perform repair operations according to the instructions; if the vehicle does not have the ability of automatic repair, or some repair operations require the driver's cooperation to complete, the system will send a repair operation prompt to the driver, informing the driver of the specific repair operation steps and precautions under different diagnostic plans.

[0089] The vehicle diagnostic system actively collects the execution results of repair instructions (such as re-obtaining new fault data to determine the execution results of repair instructions). For the driver's repair operation feedback information, the system receives it through the vehicle human-machine interface. For example, the driver selects the option of whether the fault is eliminated on the central control display screen, or feeds back the current condition of the vehicle through voice input. After the system obtains this information, it compares and analyzes it with the standard parameters and fault code status when the vehicle is running normally, so as to judge whether the fault is solved. If the parameters of the vehicle return to normal and the fault code disappears, the system determines that the fault has been solved; otherwise, it is considered that the fault has not been solved.

[0090] Further, when the vehicle diagnostic system determines that the fault has been resolved, all operations related to the current fault diagnosis are stopped, including data collection, analysis and calculation, etc., and the current diagnostic process ends. If it is determined that the fault has not been resolved, the system updates the current diagnostic result based on the existing information. For example, new problems found during the repair process and new data obtained are incorporated into the current diagnostic result, and the cause of the fault and possible solutions are re-evaluated. Then, according to the diagnostic process, the system continues to generate the next diagnostic result using the on-vehicle diagnostic unit, regional diagnostic center or cloud server based on the updated diagnostic result. This process will be repeated continuously until an optimized diagnostic strategy is generated to ensure that the vehicle fault is completely resolved.

[0091] In the above embodiment, the vehicle diagnostic system constructs a three-level diagnostic architecture of "on-vehicle diagnostic unit - regional diagnostic center - cloud server", which specifically solves the problem of low efficiency in diagnosing resource allocation in the existing system. Specifically, the standardized diagnostic service data is converted into diagnostic scripts and deployed to the vehicle side, enabling simple faults to be quickly processed locally and avoiding unnecessary remote requests; secondly, the regional diagnostic center is introduced as an intermediate layer, and through the dynamic matching of computing resources and cluster collaborative analysis, the decentralized processing of medium-complexity faults is realized, alleviating the pressure on the remote platform; finally, the hierarchical processing mechanism based on confidence ensures that only the most complex faults are submitted to the cloud server for analysis through deep learning and knowledge graphs, realizing the reasonable allocation of computing resources and improving the overall diagnostic efficiency.

[0092] The following is a further and more specific process description of the method provided in this embodiment. Please refer to Figure 2 , which is a schematic flowchart of a process for the on-vehicle diagnostic unit in the embodiment of the present application to generate a preliminary diagnostic plan.

[0093] S201. When a fault trigger event is detected, start a hierarchical progressive data collection mechanism to obtain the first batch of fault data, and establish a fault feature model based on the first batch of fault data.

[0094] Specifically, after detecting a fault trigger event, the on-vehicle diagnostic unit immediately starts a hierarchical progressive data collection mechanism. According to the preset collection rules, key data directly related to the fault is preferentially obtained to form the first batch of fault data. After these data are quickly collected, the on-vehicle diagnostic unit uses specific algorithms and data analysis techniques to construct a fault feature model based on the first batch of fault data. This model attempts to find out the potential rules and development directions of the fault through the analysis and processing of the data.

[0095] Optionally, multiple data acquisition modules are preset in the on-vehicle diagnostic unit, each corresponding to a different type of fault trigger event. When a fault trigger event is detected, the corresponding data acquisition module is activated. For example, the acquisition module for engine faults will quickly collect data such as the engine fault code, current speed, and intake air temperature as the first batch of fault data. Then, the on-vehicle diagnostic unit uses machine learning algorithms to perform feature extraction and pattern recognition on the first batch of fault data, constructs a fault feature model based on a neural network, and allows the model to learn the internal relationships between the fault data through training, so as to describe the development trend of the fault.

[0096] S202. According to the analysis result of the fault feature model, determine the list of fault-related components and calculate the sampling priority of each related component.

[0097] Specifically, the on-vehicle diagnostic unit deeply analyzes the established fault feature model. Through information such as the fault mode and data association relationship reflected in the model, determine the vehicle components that may be related to the fault, and generate a list of fault-related components. Then, according to factors such as the importance of each related component in the occurrence and development of the fault and the degree of association with the fault, calculate the sampling priority of each related component. For example, if the fault feature model shows that the abnormal data of a certain sensor is closely related to the fault, the component corresponding to the sensor will obtain a higher weight in the calculation of the sampling priority.

[0098] Optionally, the on-vehicle diagnostic unit uses the data association rules in the fault feature model to traverse the vehicle component database. The database stores the functions, mutual relationships of vehicle components, and the associated information with common faults. According to the fault data in the model, match it with the information in the database to find all possible related components and generate a list of fault-related components. For the calculation of the sampling priority, the analytic hierarchy process (AHP) is used. First, construct a judgment matrix, compare the influence degree of each related component on the fault, and determine the sampling priority of each component by calculating the weight vector.

[0099] S203. Determine the vehicle historical operation data used to expand the data sampling range according to the sampling priority and the fault feature model.

[0100] Among them, the vehicle historical operation data represents the operation status records of the vehicle in the past period of time, including information such as vehicle speed, engine working conditions, and working parameters of each component.

[0101] Specifically, the on-vehicle diagnostic unit determines the range and time span of the vehicle historical operation data that needs to be obtained according to the calculated sampling priority and the analysis result of the fault feature model. For related components with a high sampling priority, more extensive and longer-time-span historical operation data will be obtained; for components with a relatively low sampling priority, relatively less data will be obtained.

[0102] Optionally, the on-vehicle diagnostic unit is connected to the historical data storage module of the vehicle, which stores the operation data of the vehicle in chronological order. The on-vehicle diagnostic unit generates a data query instruction according to the sampling priority and the fault feature model. The instruction contains information such as the component identifier and the time range of the data to be acquired. For example, for components with high priority, the query instruction may require acquiring data every hour in the past 7 days; for components with low priority, acquiring data every 4 hours in the past 24 hours. The storage module retrieves and returns the corresponding historical operation data according to the query instruction.

[0103] S204. Construct a diagnostic execution task table based on the time-series correlation analysis results of the first batch of fault data, the sampling data of associated components, and the historical operation data of the vehicle.

[0104] Among them, the diagnostic execution task table is a task list generated according to the time-series correlation analysis results, and contains multiple diagnostic subtasks. Each diagnostic subtask corresponds to a specific diagnostic operation, which is used to analyze the fault in depth step by step to determine the cause of the fault and the solution.

[0105] Optionally, the on-vehicle diagnostic unit uses the recurrent neural network (RNN) in deep learning to analyze the time-series data. RNN can handle time-series data well and learn the long-term dependencies between data. By training the RNN model, it analyzes the data and outputs diagnostic suggestions. According to these suggestions, combined with the actual diagnostic process of the vehicle, a diagnostic execution task table is constructed. For example, if the RNN model outputs that a certain component may have a fault, then the task table will contain detailed detection tasks for that component and subsequent tasks for checking related systems. It can be understood that other methods can also be used, such as using Bayesian networks for time-series correlation analysis and task table construction, which are not limited here.

[0106] S205. Execute the diagnostic subtasks and generate an intermediate diagnostic status, and send the intermediate diagnostic status to the regional diagnostic center in real time.

[0107] Among them, the intermediate diagnostic status is the result obtained by the on-vehicle diagnostic unit's phased analysis of the fault during the execution of the diagnostic subtasks. It reflects the progress of the current diagnosis, including information such as the completed diagnostic operations, the discovered abnormal situations, and the preliminary diagnostic conclusions.

[0108] Specifically, the on-vehicle diagnostic unit sequentially executes each diagnostic subtask according to the order in the diagnostic execution task table. During the execution of each subtask, the on-vehicle diagnostic unit detects and analyzes the relevant components and systems of the vehicle, and records the detection results. According to these results, an intermediate diagnostic status is generated.

[0109] Optionally, the on-vehicle diagnostic unit executes diagnostic subtasks one by one according to the order of the diagnostic execution task list. During the execution process, a dedicated diagnostic log is used to record the execution situation and results of each subtask. When a subtask is completed, an intermediate diagnostic status is generated based on the diagnostic log. To achieve real-time transmission, the on-vehicle diagnostic unit adopts the message queue technology, puts the intermediate diagnostic status into the message queue, and the message queue is responsible for sending the data to the regional diagnostic center. The message queue can ensure the reliable transmission of data and avoid data loss. It can be understood that other methods can also be adopted, such as using the combination of Bluetooth and in-vehicle network for data transmission, which is not limited herein.

[0110] S206. Update the diagnostic execution task list according to the real-time optimization suggestions returned by the regional diagnostic center until the final preliminary diagnostic result is generated.

[0111] Specifically, after the on-vehicle diagnostic unit receives the real-time optimization suggestions returned by the regional diagnostic center, it analyzes and interprets these suggestions. According to the content of the suggestions, the diagnostic execution task list is updated. For example, if the regional diagnostic center suggests adding a detection item for a certain component, the on-vehicle diagnostic unit will add the corresponding subtask to the diagnostic execution task list. Then, the on-vehicle diagnostic unit continues to execute the diagnostic subtasks according to the updated diagnostic execution task list, generates the intermediate diagnostic status again and sends it to the regional diagnostic center. This process repeats continuously, constantly optimizing the diagnostic process according to the suggestions of the regional diagnostic center until the on-vehicle diagnostic unit believes that it has comprehensively analyzed the fault situation and obtains the final preliminary diagnostic result, including information such as the cause of the fault, the severity of the fault, and possible solutions.

[0112] In the above embodiment, the vehicle diagnostic system formulates a diagnostic execution task list mechanism, realizing the intelligent collaboration between the on-vehicle side and the regional diagnostic center. Specifically, through the division of diagnostic subtasks and the real-time sharing of intermediate diagnostic status, the regional diagnostic center can intervene in a timely manner and provide optimization suggestions. This real-time interaction mechanism not only breaks the information barrier in the traditional diagnostic mode, but also significantly improves the diagnostic efficiency through parallel analysis and dynamic optimization, providing technical support for the rapid diagnosis of complex faults.

[0113] It should be noted that the above steps S205 and S206 are an implementable way for the on-vehicle diagnostic unit and the regional diagnostic center to collaboratively generate the preliminary diagnostic result, and will not limit any of the embodiments of steps S101 to S105 in this application.

[0114] The vehicle diagnostic system of the embodiment of the present invention is an electronic device, Figure 3 showing a schematic architecture diagram of an electronic device suitable for implementing the embodiment of the present invention.

[0115] It should be noted thatFigure 3 The illustrated electronic device is only an example and should not impose any limitations on the functions and scope of use of the embodiments of the present invention.

[0116] Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructions (computer programs), or the relevant hardware can be controlled by instructions (computer programs). The instructions can be stored in a computer-readable storage medium and loaded and executed by a processor. The electronic device of this embodiment includes a storage medium and a processor. Among them, multiple instructions are stored in the storage medium, and the instructions can be loaded by the processor to execute any step of the method provided by the embodiments of the present invention.

[0117] Specifically, the storage medium and the processor are directly or indirectly electrically connected to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more signal lines. The storage medium stores computer execution instructions for implementing the data access control method, including at least one software function module that can be stored in the storage medium in the form of software or firmware. The processor executes various functional applications and data processing by running the software programs and modules stored in the storage medium. The storage medium can be, but is not limited to, a random access storage medium (Random Access Memory, abbreviated as RAM), a read-only storage medium (Read Only Memory, abbreviated as ROM), a programmable read-only storage medium (Programmable Read-Only Memory, abbreviated as PROM), an erasable read-only storage medium (Erasable Programmable Read-Only Memory, abbreviated as EPROM), an electrically erasable read-only storage medium (Electric Erasable Programmable Read-Only Memory, abbreviated as EEPROM), etc. Among them, the storage medium is used to store the program, and the processor executes the program after receiving the execution instruction.

[0118] Further, the software programs and modules in the above storage medium may further include an operating system, which may include various software components and / or drivers for managing system tasks (such as memory management, storage device control, power management, etc.), and may communicate with various hardware or software components to provide a running environment for other software components. The processor may be an integrated circuit chip with signal processing capabilities. The above-mentioned processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, abbreviated as: CPU), a network processor (Network Processor, abbreviated as: NP), etc., which can implement or execute the various methods, steps, and logic flow block diagrams disclosed in this embodiment. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0119] Since the instructions stored in this storage medium can execute the steps in any of the methods provided in the embodiments of the present invention, the beneficial effects of any of the methods provided in the embodiments of the present invention can be achieved. For details, see the previous embodiments and will not be repeated here.

[0120] The above is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present invention should be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. A method combining on-vehicle diagnosis and remote diagnosis, which is applied to a vehicle diagnosis system. The vehicle diagnosis system includes an on-vehicle diagnosis unit, a regional diagnosis center, and a cloud server, and is characterized in that, The method includes: Importing diagnostic service data through a diagnostic database generation tool, and converting the diagnostic service data into diagnostic scripts based on a preset detection process development platform, where the diagnostic service data includes CDD data format, ODX data format, and Excel data format; Deploying the diagnostic scripts to an on-vehicle diagnostic unit, and generating a preliminary diagnostic result based on fault data, where the fault data includes fault codes, vehicle condition data, and environmental data; the step of deploying the diagnostic scripts to the on-vehicle diagnostic unit and generating a preliminary diagnostic result based on fault data includes, when a fault trigger event is detected, starting a hierarchical progressive data acquisition mechanism to obtain a first batch of fault data, and establishing a fault feature model based on the first batch of fault data, where the fault feature model is used to describe the development trend of the fault; Based on the analysis result of the fault feature model, determining a list of fault-related components, and calculating the sampling priority of each related component, where the sampling priority determines the data sampling frequency of the related component; Determining vehicle historical operation data for expanding the data sampling range based on the sampling priority and the fault feature model, where the time span of the vehicle historical operation data is determined by the fault feature model; Performing time-series correlation analysis on the first batch of fault data, the sampling data of the related components, and the vehicle historical operation data, and generating a preliminary diagnostic result including a fault propagation path; Sending the preliminary diagnostic result and the fault data to a regional diagnostic center; Extracting features from the preliminary diagnostic result and the fault data, and generating a multi-dimensional fault feature vector including fault type, fault severity, and fault development trend; According to the calculation result of the multi-dimensional fault feature vector, matching corresponding heterogeneous computing resources from a computing resource pool and forming a diagnostic cluster; Parallelly processing diagnostic requests for fault feature vectors with a similarity lower than a preset similarity threshold through the diagnostic cluster, and generating an intermediate diagnostic plan; When the confidence level of the intermediate diagnostic plan is lower than a preset threshold, submitting the preliminary diagnostic result, the fault data, and the intermediate diagnostic plan to a cloud server for in-depth analysis to obtain an optimized diagnostic strategy, where the cloud server includes a deep learning model training center, a knowledge graph builder, and an expert experience library; Distributing the optimized diagnostic strategy to the temporary knowledge bases of the on-vehicle diagnostic unit and the regional diagnostic center respectively to complete collaborative diagnosis.

2. The method according to claim 1, characterized in that, The step of parallelly processing diagnostic requests for fault feature vectors with a similarity lower than a preset similarity threshold through the diagnostic cluster and generating an intermediate diagnostic plan specifically includes: Monitoring the task queue and resource occupancy rate of each node in the diagnostic cluster, and triggering a task reallocation mechanism when the task queue length exceeds a first preset threshold or the resource occupancy rate exceeds a second preset threshold; Dividing the diagnostic requests into lightweight task packages and heavyweight task packages based on the calculation complexity of the multi-dimensional fault feature vector, where the calculation complexity is determined by the computing resources required for fault feature similarity calculation; Allocate the heavyweight task packages to a sub-cluster composed of high-performance computing nodes for processing, and at the same time allocate the lightweight task packages to ordinary computing nodes for processing; Perform temporal merging on the diagnostic results of the sub-cluster and the ordinary computing nodes to generate an intermediate diagnostic plan.

3. The method according to claim 1, wherein The method further includes: Establish a diagnostic knowledge cache pool for storing local diagnostic experience in the vehicle diagnostic unit, where the local diagnostic experience includes fault characteristics, diagnostic paths, and repair plans; When the update frequency of the diagnostic knowledge cache pool is lower than a preset frequency threshold, upload the local diagnostic experience to the temporary knowledge base of the regional diagnostic center to generate a knowledge update package, where the knowledge update package includes a priority tag and a resource requirement indicator; Calculate a resource status index based on the storage capacity and processing capacity of the vehicle diagnostic unit itself, and screen the knowledge update package based on the resource status index to achieve asynchronous update of the diagnostic knowledge in the diagnostic knowledge cache pool.

4. The method according to claim 3, wherein The step of screening the knowledge update package based on the resource status index to achieve asynchronous update of the diagnostic knowledge in the diagnostic knowledge cache pool specifically includes: Perform a reliability assessment on the diagnostic knowledge in the screened knowledge update package to generate a performance index matrix including diagnostic accuracy and repair efficiency; Divide the diagnostic knowledge in the diagnostic knowledge cache pool into a reserved area and a to-be-replaced area based on the performance index matrix, where the reserved area stores diagnostic knowledge with high performance indicators; Select diagnostic knowledge with performance indicators higher than those in the to-be-replaced area from the knowledge update package for update, so as to maintain an optimal diagnostic strategy combination in the diagnostic knowledge cache pool.

5. The method according to claim 1, characterized in that After any one of the preliminary diagnostic results, the intermediate diagnostic plan, and the optimized diagnostic strategy is generated, the method further includes: If the current diagnostic result includes multiple optional diagnostic plans, sequentially execute the repair instructions corresponding to each diagnostic plan or send a repair operation prompt to the driver, where the diagnostic result includes the preliminary diagnostic result, the intermediate diagnostic plan, and the optimized diagnostic strategy; Obtain the execution result of the repair instruction or the feedback information of the repair operation, and determine whether the fault is resolved based on the execution result or the feedback information; If the fault has been resolved, terminate the diagnostic process; if the fault has not been resolved, continue to generate the next diagnostic result after updating the current diagnostic result until the optimized diagnostic strategy is generated.

6. A vehicle diagnostic system, characterized in that, The vehicle diagnostic system includes: one or more processors and a memory; The memory is coupled to the one or more processors, and the memory is used to store computer program code, where the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the vehicle diagnostic system to execute the method according to any one of claims 1-5.

7. A computer-readable storage medium, comprising instructions, characterized in that, When the instruction runs on the vehicle diagnostic system, it causes the vehicle diagnostic system to execute the method according to any one of claims 1-5.

8. A computer program product, characterized in that, When the computer program product runs on the vehicle diagnostic system, it causes the vehicle diagnostic system to execute the method according to any one of claims 1-5.

Images