Vehicle-mounted diagnosis and remote diagnosis combined method and system

Abstract

The invention provides a vehicle-mounted diagnosis and remote diagnosis combination method and system, and relates to the technical field of vehicle fault diagnosis, and the method comprises the steps: converting diagnosis service data into a diagnosis script, and deploying the diagnosis script to a vehicle-mounted diagnosis unit for generating a preliminary diagnosis result according to fault data; sending the preliminary diagnosis result and the fault data to a regional diagnosis center to match corresponding computing resources for coordinated analysis, and generating an intermediate diagnosis scheme; and when the confidence coefficient of the middle-level diagnosis scheme is lower than a preset threshold value, submitting the preliminary diagnosis result, the fault data and the middle-level diagnosis scheme to a cloud server for deep analysis to obtain an optimized diagnosis strategy, and respectively issuing the optimized diagnosis strategy to a vehicle-mounted diagnosis unit and a regional diagnosis center to complete collaborative diagnosis. By implementing the method, the three-level diagnosis architecture is constructed, and different architectures complete fault diagnosis of different complexity degrees, so that the pressure of a remote platform is relieved, reasonable allocation of computing resources is realized, and the overall diagnosis efficiency is improved.

Description

Technical Field

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

[0002] With the continuous improvement of the degree of vehicle electrification, the complexity of vehicle fault diagnosis has also increased. To accurately identify and timely process 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 combining 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, combining historical maintenance cases and expert experience, a diagnosis plan 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 have complex faults that require remote diagnosis, all diagnosis requests are directly sent to the remote platform, causing serious backlog of remote computing resources. In addition, each diagnosis request requires a complete remote diagnosis process. Even for common faults with high repetition, 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 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 combining on-vehicle diagnosis and remote diagnosis, which is applied to a vehicle diagnosis system. The method includes: Import diagnosis service data through a diagnosis database generation tool, and convert the diagnosis service data into diagnosis scripts based on a preset detection process development platform. The diagnosis service data includes CDD data format, ODX data format, and Excel data format; Deploy the diagnosis scripts to the on-vehicle diagnosis unit, and generate a preliminary diagnosis result based on the fault data. The fault data includes fault codes, vehicle condition data, and environmental data; 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; When the confidence level of the intermediate diagnosis solution is lower than a preset threshold, the preliminary diagnosis result, the fault data, and the intermediate diagnosis solution are submitted to a 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; The optimized diagnosis strategy is respectively sent to the temporary knowledge bases of the vehicle diagnostic unit and the regional diagnosis center to complete collaborative diagnosis.

[0007] Through the above embodiments, the vehicle diagnosis system constructs a three-level diagnosis architecture of "vehicle diagnostic unit - regional diagnosis center - cloud server", and specifically solves the problem of low efficiency in the allocation of diagnostic resources in the existing system. Specifically, the standardized diagnostic service data is converted into diagnostic scripts and deployed to the vehicle-mounted side, enabling simple faults to be quickly processed locally and avoiding unnecessary remote requests; secondly, a 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.

[0008] In some embodiments, the step of deploying the diagnostic script to the vehicle diagnostic unit and generating a preliminary diagnosis result based on the fault data specifically includes: When a fault trigger event is detected, a hierarchical progressive data acquisition mechanism is started to obtain the first batch of fault data, and a fault feature model is established based on the first batch of fault data. The fault feature model is used to describe the development trend of the fault; According to the analysis result of the fault feature model, a list of fault-related components is determined, and the sampling priority of each related component is calculated. The sampling priority determines the data sampling frequency of the related component; The vehicle historical operation data for expanding the data sampling range is determined based on the sampling priority and the fault feature model. The time span of the vehicle historical operation data is determined by the fault feature model; The first batch of fault data, the sampling data of the related components, and the vehicle historical operation data are subjected to time-series correlation analysis to generate a preliminary diagnosis result including the fault propagation path.

[0009] 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 and improves the accuracy of preliminary diagnosis on the vehicle side.

[0010] 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: 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; 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; 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.

[0011] Through the above embodiments, the vehicle diagnosis system provides an efficient cluster diagnosis ability 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 realized, greatly improving the processing efficiency of the regional diagnosis center.

[0012] 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: 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; 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; Allocate the heavyweight task packets to a sub-cluster composed of high-performance computing nodes for processing, and at the same time allocate the lightweight task packets to ordinary computing nodes for processing; Perform time-series merging on the diagnosis results of the sub-cluster and the ordinary computing nodes to generate an intermediate diagnosis scheme.

[0013] Through the above embodiments, the vehicle diagnostic system introduces a task classification and 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, the waste of high-performance computing resources is avoided. At the same time, through the timing merging mechanism, the consistency of distributed processing results is ensured, providing a technical guarantee for quickly generating reliable intermediate diagnostic solutions.

[0014] 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: 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 solutions; 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; 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 realize asynchronous update of the diagnostic knowledge in the diagnostic knowledge cache pool.

[0015] Through the above embodiments, the vehicle diagnostic system realizes efficient management and sharing of diagnostic knowledge by establishing a hierarchical knowledge storage architecture. The design of the diagnostic knowledge cache pool enables the in-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 update will not affect system performance. This asynchronous update mechanism significantly improves the response speed of the system and provides reliable knowledge support for collaborative diagnosis.

[0016] In some embodiments, after any of the preliminary diagnostic results, the intermediate diagnostic solutions, and the optimized diagnostic strategies are generated, the method further includes: If the current diagnostic result includes multiple optional diagnostic solutions, sequentially execute the repair instructions corresponding to each diagnostic solution or send a repair operation prompt to the driver, where the diagnostic result includes the preliminary diagnostic result, the intermediate diagnostic solutions, and the optimized diagnostic strategies; 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; 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.

[0017] Through the above embodiments, the vehicle diagnostic system verifies immediately after generating a 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 among 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.

[0018] 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: Evaluating the reliability of the diagnostic knowledge in the screened knowledge update package to generate a performance index matrix including diagnostic accuracy and repair efficiency; Dividing 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; Selecting 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.

[0019] Through the above embodiments, the vehicle diagnostic system introduces a knowledge quality evaluation mechanism, realizing 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 enhances the storage efficiency through precise updates, providing technical support for maintaining an optimal diagnostic strategy combination.

[0020] In a second aspect, the present application provides a vehicle diagnostic system, which 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. 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 method for combining in-vehicle diagnosis and remote diagnosis provided by the above embodiments, which will not be elaborated here.

[0021] 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 method for combining in-vehicle diagnosis and remote diagnosis provided by the above embodiments, which will not be elaborated here.

[0022] Fourthly, the present application provides a computer program product. When the computer program product runs on a vehicle diagnostic system, 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.

[0023] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. Through the hierarchical architecture of "vehicle diagnostic unit - regional diagnostic center - cloud server", combined with a 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.

[0024] 2. A real-time sharing mechanism for diagnostic execution task tables and intermediate diagnostic states 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 a 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 state and provide real-time optimization suggestions, forming a continuously optimized closed-loop diagnostic system.

[0025] 3. By establishing a hierarchical storage architecture of a diagnostic knowledge cache pool and a temporary knowledge base, combined with a knowledge evaluation mechanism based on a performance index matrix, intelligent management and optimized update of diagnostic knowledge are achieved. The system stores knowledge in partitions through reliability evaluation and selectively updates asynchronously based on the resource status index, ensuring both the continuous accumulation of high-quality diagnostic knowledge and avoiding the impact of frequent updates on system performance. This performance-based knowledge management mechanism provides strong support for maintaining the optimal diagnostic strategy combination. Description of the Drawings

[0026] Figure 1 is a flowchart of a combined vehicle diagnosis and remote diagnosis method in an embodiment of the present application; Figure 2 is a flowchart of a vehicle diagnostic unit generating a preliminary diagnostic plan in an embodiment of the present application; Figure 3 is a schematic structural diagram of an entity device of a vehicle diagnostic system in an embodiment of the present application. Detailed Embodiments

[0027] 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-mentioned", "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 or all possible combinations including one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are only used for descriptive purposes and should not be construed as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, the 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 "a plurality" is two or more.

[0029] 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 combining vehicle diagnosis and remote diagnosis in an embodiment of the present application.

[0030] S101. 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.

[0031] Among them, the diagnostic service data covers a data set 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 a standardized diagnostic data exchange format widely used in the field of automotive diagnosis; Excel files, which contain custom diagnostic-related configuration information or data mapping tables, etc. These data provide key bases for vehicle diagnosis.

[0032] Specifically, the vehicle diagnostic system first conducts data collection and collation work. Diagnostic service data in CDD, ODX, and Excel formats are collected from multiple channels. During the collection process, the integrity and accuracy of the data must be ensured, and missing or incorrect data are marked and corrected. Subsequently, since these data are in different formats with diverse structures and specifications, data format adaptation processing is required. For CDD and ODX data, they are parsed and converted according to their respective standard specifications to ensure that data elements can be correctly identified and extracted. For Excel files, they are organized 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, the processed data are imported into the diagnostic database generation tool using its import function. During the import, close attention should be paid to the import log, and errors such as data duplication and format mismatch are promptly processed. After the import is completed, a preliminary check of the data is performed to ensure that the data are successfully loaded and their integrity is not affected.

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

[0034] Finally, a development environment is built using the VMDSModel platform, and the platform software is installed and configured to ensure its compatibility with the operating system, database, and other related software tools. Development parameters are configured 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, diagnostic scripts are designed and developed on the platform using the provided script language and development tools according to the structured and modular programming concepts. The code for implementing various diagnostic functions is written and, after testing and verification, the diagnostic scripts are obtained.

[0035] 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 used for developing diagnostic scripts. By configuring relevant parameters and using the provided scripting language and development tools, diagnostic scripts can be generated according to the functional requirements and diagnostic processes of the automotive diagnostic system.

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

[0037] 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. 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).

[0038] 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 acquisition 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 preliminarily judging information such as the possible cause and severity of the fault.

[0039] Optionally, after detecting a fault trigger event, the on-vehicle diagnostic unit starts a hierarchical progressive data acquisition mechanism, first obtains the first batch of key fault data, such as fault codes and vehicle condition data directly related to the fault. A simple fault feature model is established based on these data to preliminarily determine the possible scope of the fault. Then, according to the model analysis result, a list of fault-related components is determined, and the sampling priority of each related component is calculated. Data sampling is performed on the related components according to the priority, and the vehicle historical operation data is obtained at the same time. Finally, time-series correlation analysis is performed on all the collected data to obtain a preliminary diagnostic result.

[0040] Optionally, after receiving the 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 started 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 preliminary diagnosis, such as using machine learning algorithms to classify and predict the fault data to obtain a preliminary diagnosis result, which is not limited here.

[0041] 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.

[0042] 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 collection 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 and analysis.

[0043] 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 fault type, fault severity, and fault development trend. According to the calculation result of this 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 parallel 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.

[0044] Optionally, after receiving the data, the regional diagnosis center first standardizes the fault data and the preliminary diagnosis result to unify the data format. Then, a multi-dimensional fault feature vector is generated using a feature extraction algorithm. According to the vector features, the computing resources that meet the requirements are screened out from the computing resource pool, such as selecting CPUs, GPUs with different performances according to the computational complexity of the fault. The selected computing resources are formed into a diagnostic cluster to parallel process the diagnostic requests. During the processing, the task queues and resource occupancy rates of each node in the cluster are monitored in real time. When there is task backlog or resource tension (the task queue length exceeds the first preset threshold or the resource occupancy rate exceeds the second preset threshold), task reallocation is performed. Finally, the diagnostic results of each node are summarized and merged in time sequence to generate an intermediate diagnosis plan.

[0045] 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 assigned to computing nodes with different performance (including sub-clusters 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 solution. 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.

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

[0047] Among them, the preset threshold is a standard value set in advance by relevant technical personnel to determine whether the intermediate diagnosis plan is reliable. When the confidence level is lower than the threshold, it means that the intermediate diagnosis plan may have uncertainty and needs further analysis; the deep learning model training center is a functional module used to train deep learning models in the cloud server. The model is trained through a large amount of historical fault data to enable it to analyze complex faults; the knowledge graph builder is a tool for building a vehicle fault knowledge graph, which organizes various information related to vehicle faults (such as fault causes, fault phenomena, repair methods, etc.) in the form of a graph to facilitate association analysis; the expert experience base is a database that stores the experience and knowledge of vehicle diagnosis experts, including processing methods and suggestions for various faults.

[0048] Specifically, after generating an intermediate diagnosis plan, the regional diagnosis center will conduct a confidence assessment. If the assessment result shows that the confidence is lower than the preset threshold, the regional diagnosis center will submit the preliminary diagnosis results, fault data, and intermediate diagnosis plan to the cloud server. After receiving the data, the cloud server uses the model trained by the deep learning model training center, the knowledge graph built by the knowledge graph builder, and the knowledge in the expert experience library to conduct an in-depth analysis of the data, comprehensively consider multiple factors, and come up with an optimized diagnosis strategy.

[0049] Optionally, after receiving the data, the cloud server preprocesses the data to extract key information. Then, the data is input into the deep learning model trained in the deep learning model training center for analysis. Based on the fault patterns and rules learned from a large amount of historical data, the model predicts and judges the current fault. Meanwhile, the knowledge graph builder searches for information related to the current fault from the knowledge graph for correlation analysis. Finally, combining the empirical knowledge in the expert experience library, a comprehensive evaluation and optimization are performed on the analysis results of the deep learning model and the knowledge graph to obtain an optimized diagnosis strategy.

[0050] Optionally, the cloud server performs in-depth analysis in a multi-model fusion manner. The preliminary diagnosis result, fault data, and intermediate diagnosis plan are respectively input into different deep learning models and machine learning algorithms for analysis. Each model and algorithm judges the fault from different perspectives. Then, the results of each model and algorithm are fused, and secondary analysis and optimization are carried out in combination with the knowledge graph and the expert experience library to finally obtain an optimized diagnosis strategy.

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

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

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

[0054] During the operation of the in-vehicle diagnostic unit, the update frequency of the diagnostic knowledge cache pool will be continuously monitored. When the update frequency is lower than the preset frequency threshold, the in-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.

[0055] 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 packets returned by the regional diagnostic center are screened. When screening, first, the diagnostic knowledge in the screened knowledge update packets is evaluated for reliability, generating a performance index matrix including diagnostic accuracy rate and repair efficiency. Then, according to the performance index matrix, the diagnostic knowledge in the diagnostic knowledge cache pool is divided into a reserved area and a to-be-replaced area. The reserved area is specifically used to store diagnostic knowledge with high performance indicators. Finally, the diagnostic knowledge with performance indicators higher than those in the to-be-replaced area is selected from the knowledge update packets 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.

[0056] 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 they collect and diagnostic experience, 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 strategy 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.

[0057] 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, adding a priority label (such as determining the priority according to the severity and occurrence frequency of the fault) and resource requirement indicators (such as the estimated occupied storage space, processing time, etc.), generating a knowledge update packet and uploading it to the regional diagnostic center.

[0058] 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 the 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 packages suitable for the on-vehicle diagnostic unit according to the resource status index and returns them. 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.

[0059] 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.

[0060] 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 gives feedback on the current status 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 to determine 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.

[0061] 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 is ended. 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.

[0062] 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 the allocation of diagnostic resources 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, a 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.

[0063] 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 flow diagram of an on-vehicle diagnostic unit generating a preliminary diagnostic plan in an embodiment of the present application.

[0064] 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.

[0065] Specifically, after the on-vehicle diagnostic unit detects a fault trigger event, it immediately starts a hierarchical progressive data collection mechanism. According to the pre-set 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 build a fault feature model based on the first batch of fault data. Through the analysis and processing of the data, this model attempts to find out the potential rules and development directions of the fault.

[0066] Optionally, multiple data acquisition modules are preset in the on-vehicle diagnostic unit, corresponding to different types of fault trigger events respectively. 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, intake air temperature, etc. 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 through training, enables the model to learn the internal relationships between the fault data, so as to describe the development trend of the fault.

[0067] 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 associated component.

[0068] 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 associated component in the occurrence and development of the fault and the degree of association with the fault, calculate the sampling priority of each associated 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 this sensor will obtain a higher weight in the calculation of the sampling priority.

[0069] 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 adopted. First, construct a judgment matrix, compare the influence degree of each associated component on the fault, and determine the sampling priority of each component by calculating the weight vector.

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

[0071] 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.

[0072] 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 combined with the analysis result of the fault feature model. For the associated components with a high sampling priority, more extensive and longer-time-span historical operation data will be obtained; for the components with a relatively low sampling priority, relatively less data will be obtained.

[0073] 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 1 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.

[0074] 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.

[0075] 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 gradually analyze the fault in depth to determine the cause of the fault and the solution.

[0076] 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 dependence relationship 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 this 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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 here.

[0081] 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.

[0082] Specifically, after receiving the real-time optimization suggestions returned by the regional diagnostic center, the on-vehicle diagnostic unit 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.

[0083] 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.

[0084] 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.

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

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

[0087] 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 by controlling relevant hardware through 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.

[0088] 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 computer execution instructions for implementing the data access control method are stored in the storage medium, 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 programs, and the processor executes the programs after receiving the execution instructions.

[0089] Furthermore, 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 (CPU), a network processor (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.

[0090] 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, please refer to the previous embodiments and will not be repeated here.

[0091] The above is only a preferred specific embodiment 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 for combining on-board diagnosis and remote diagnosis, applied to a vehicle diagnostic system, wherein the vehicle diagnostic system comprises an on-board diagnostic unit, a regional diagnostic center and a cloud server, characterized in that: The method comprises: Importing diagnostic service data through a diagnostic database generation tool, and converting the diagnostic service data into a diagnostic script based on a preset detection process development platform, wherein the diagnostic service data includes CDD data format, ODX data format and Excel data format; Deploy the diagnostic script to an on-board diagnostic unit and generate a preliminary diagnostic result based on fault data, the fault data including fault codes, vehicle condition data, and environmental data; Sending the preliminary diagnosis result and the fault data to the regional diagnosis center, matching the corresponding computing resources to build a vehicle diagnosis cluster for coordinated analysis, and generating an intermediate diagnosis plan; When the confidence of the intermediate diagnosis scheme is lower than a preset threshold, the preliminary diagnosis result, the fault data and the intermediate diagnosis scheme are submitted to a cloud server for in-depth analysis to obtain an optimized diagnosis strategy, wherein the cloud server includes a deep learning model training center, a knowledge graph builder and an expert experience library; The optimized diagnostic strategy is sent to the on-board diagnostic unit and the temporary knowledge base of the regional diagnostic center respectively to complete the collaborative diagnosis.

2. The method according to claim 1, characterized in that The step of deploying the diagnostic script to the on-board diagnostic unit and generating a preliminary diagnostic result based on the fault data specifically includes: When a fault triggering event is detected, a hierarchical progressive data collection mechanism is started to obtain a first batch of fault data, and a fault feature model is established based on the first batch of fault data, wherein the fault feature model is used to describe the development trend of the fault; According to the analysis results of the fault characteristic model, a list of fault-related components is determined, and a sampling priority of each associated component is calculated, wherein the sampling priority determines the data sampling frequency of the associated components; Determining vehicle historical operation data for expanding a data sampling range according to the sampling priority and the fault characteristic model, wherein a time span of the vehicle historical operation data is determined by the fault characteristic model; The first batch of fault data, the sampling data of the associated components and the historical operation data of the vehicle are subjected to time series correlation analysis to generate a preliminary diagnosis result including a fault propagation path.

3. The method according to claim 1, characterized in that The step of matching corresponding computing resources to build a vehicle diagnosis cluster for coordinated analysis and generating an intermediate diagnosis solution specifically includes: Extracting 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; According to the calculation result of the multi-dimensional fault feature vector, corresponding heterogeneous computing resources are matched from the computing resource pool and formed into a diagnosis cluster; The diagnosis cluster processes in parallel the diagnosis requests of the fault feature vectors whose similarity is lower than a preset similarity threshold, and generates an intermediate diagnosis solution.

4. The method according to claim 3, characterized in that The step of processing in parallel the diagnosis requests of the fault feature vectors whose similarity is lower than a preset similarity threshold by the diagnosis cluster to generate an intermediate diagnosis solution 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; Based on the computational complexity of the multi-dimensional fault feature vector, the diagnostic request is divided into a lightweight task package and a heavyweight task package, wherein the computational complexity is determined by the computational resources required for the fault feature similarity calculation; Allocate the heavyweight task packages to a sub-cluster consisting of high-performance computing nodes for processing, and allocate the lightweight task packages to ordinary computing nodes for processing; The diagnosis results of the sub-cluster and the common computing nodes are combined in time series to generate an intermediate diagnosis solution.

5. The method according to claim 1, characterized in that: The step of sending the optimized diagnostic strategy to the on-board diagnostic unit and the temporary knowledge base of the regional diagnostic center to complete the collaborative diagnosis specifically includes: Establishing a diagnostic knowledge cache pool in the on-board diagnostic unit for storing local diagnostic experience, wherein the local diagnostic experience includes fault characteristics, diagnostic paths and repair solutions; When the update frequency of the diagnostic knowledge cache pool is lower than a preset frequency threshold, the local diagnostic experience is uploaded to the temporary knowledge base of the regional diagnostic center to generate a knowledge update package, wherein the knowledge update package includes a priority tag and a resource demand indicator; The resource status index is calculated according to the storage capacity and processing capability of the on-board diagnostic unit itself, and the knowledge update package is screened based on the resource status index to realize the asynchronous update of the diagnostic knowledge by the diagnostic knowledge cache pool.

6. The method according to claim 5, characterized in that The step of screening the knowledge update package based on the resource status index to implement the asynchronous update of the diagnostic knowledge by the diagnostic knowledge cache pool specifically includes: Conduct reliability evaluation on the diagnostic knowledge in the screened knowledge update package and generate a performance indicator matrix including diagnostic accuracy and repair efficiency; Dividing the diagnostic knowledge in the diagnostic knowledge cache pool into a reserved area and a to-be-replaced area based on the performance indicator matrix, wherein the reserved area stores diagnostic knowledge with high performance indicators; Diagnostic knowledge with a performance index higher than that of the area to be replaced is selected from the knowledge update package for updating, so that the optimal diagnostic strategy combination is maintained in the diagnostic knowledge cache pool.

7. The method according to claim 1, characterized in that After any of the preliminary diagnosis results, the intermediate diagnosis scheme and the optimized diagnosis strategy are generated, the method further includes: If the current diagnostic result includes multiple optional diagnostic solutions, the maintenance instructions corresponding to each diagnostic solution are executed in sequence or a maintenance operation prompt is sent to the driver, wherein the diagnostic result includes the preliminary diagnostic result, the intermediate diagnostic solution and the optimized diagnostic strategy; Obtaining the execution result of the maintenance instruction or the feedback information of the maintenance operation, and judging whether the fault is solved according to the execution result or the feedback information; If the fault has been resolved, the diagnostic process is terminated; if the fault has not been resolved, the next diagnostic result is generated after the current diagnostic result is updated until the optimized diagnostic strategy is generated.

8. A vehicle diagnostic system, characterized in that: The vehicle diagnostic system includes: one or more processors and memory; The memory is coupled to the one or more processors, and the memory is used to store computer program codes, wherein the computer program codes include computer instructions, and the one or more processors call the computer instructions to enable the vehicle diagnostic system to perform the method according to any one of claims 1 to 7.

9. A computer-readable storage medium comprising instructions, characterized in that: When the instruction is executed on a vehicle diagnostic system, the vehicle diagnostic system is caused to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that When the computer program product is run on a vehicle diagnostic system, the vehicle diagnostic system is caused to execute the method according to any one of claims 1 to 7.

Images