Vehicle diagnosis function construction method and device based on multi-source data and intelligent analysis

Abstract

The invention relates to the technical field of data processing, and discloses a vehicle diagnosis function construction method based on multi-source data and intelligent analysis and related equipment, and the method comprises the steps: collecting original diagnosis data for a target vehicle diagnosis function from at least two mutually independent compliance data sources; standardizing the original diagnostic data to generate a unified standardized diagnostic data description file; the standardized diagnosis data description file is input into an intelligent analysis center for reasoning and verification, and verified diagnosis function logic is obtained; and according to the verified diagnosis function logic, automatically generating a diagnosis function framework for integrated use of the diagnosis platform. According to the invention, compliance and efficient development of the vehicle diagnosis function can be realized, and the problems of low development efficiency and insufficient law compliance in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method and apparatus for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis. Background Technology

[0002] With the increasing level of automotive electronics and intelligence, vehicle diagnostic functions have become crucial to ensuring the safe operation of vehicles. The market demand for the rapid development and large-scale application of cross-brand and multi-model diagnostic functions is becoming increasingly urgent.

[0003] Currently, the development of existing vehicle diagnostic functions mainly relies on reverse engineering. This involves listening to vehicle bus messages and manually analyzing them to infer the communication protocols and diagnostic logic of the ECU (Electronic Control Unit). However, this method requires reverse engineering for each vehicle model and each ECU individually, resulting in long development cycles and low efficiency for individual diagnostic functions, making it difficult to meet the market's demands for rapid response and large-scale coverage. Furthermore, unauthorized protocol analysis can infringe on the intellectual property rights of OEMs, posing significant legal and compliance risks and thus limiting the market promotion of diagnostic products. In summary, existing technologies suffer from low development efficiency and insufficient legal compliance, failing to meet the rapidly evolving diagnostic technology needs of the automotive industry.

[0004] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0005] This application provides a method and apparatus for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis, which can realize the compliant and efficient development of vehicle diagnostic functions and solve the problems of low development efficiency and insufficient legal compliance in existing technologies.

[0006] In a first aspect, embodiments of this application provide a method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis, including: Collect raw diagnostic data for the target vehicle's diagnostic functions from at least two independent, compliant data sources. The original diagnostic data is standardized to generate a unified standardized diagnostic data description file; The standardized diagnostic data description file is input into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic. Based on the verified diagnostic function logic, a diagnostic function framework for integration into the diagnostic platform is automatically generated.

[0007] Furthermore, in some embodiments of this application, the step of collecting raw diagnostic data for the target vehicle's diagnostic functions from at least two independent compliant data sources includes: Collect the first raw data generated from the standard diagnostic process using original equipment manufacturer (OEM) authorized diagnostic equipment; Secondary raw data is collected from market-proven third-party diagnostic equipment to test the diagnostic functions of the same target vehicle. Obtain de-identified historical data related to the diagnostic function of the target vehicle from a legally authorized third-party data service provider, as the third original data.

[0008] Furthermore, in some embodiments of this application, the standardization processing of the original diagnostic data to generate a unified standardized diagnostic data description file includes: All collected raw diagnostic data are cleaned and parsed to extract diagnostic logic elements that constitute the diagnostic logic function. The diagnostic logic elements include diagnostic service sequence, diagnostic service parameters, and diagnostic response information. The diagnostic logic elements are converted into a standardized diagnostic data description file according to a preset automotive diagnostic data description standard.

[0009] Furthermore, in some embodiments of this application, the step of inputting the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic includes: Multiple analysis models in the intelligent analysis center are invoked to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary reconstruction of the diagnostic function logic; wherein, the multiple analysis models analyze the standardized diagnostic data description file in sequence, and the analysis result of the previous model is used as the input of the next model; The verification model in the intelligent analysis center is invoked, and the original diagnostic data or known diagnostic logic from different data sources are used to perform cross-validation and integrity checks on the initially restored diagnostic function logic to obtain the verification results. Based on the verification results, the logical deficiencies or conflicts existing in the initially restored diagnostic function logic are supplemented and corrected to form the verified diagnostic function logic.

[0010] Furthermore, in some embodiments of this application, the step of calling multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary restored diagnostic function logic includes: The standardized diagnostic data description file is analyzed by calling the protocol identification model to identify the communication protocol and vehicle platform followed, and the protocol identification result is obtained. Based on the protocol identification results, the state machine restoration model is called to analyze the diagnostic service sequence in the standardized diagnostic data description file, and the state transition logic of the target vehicle's diagnostic function is restored. The semantic understanding model is invoked to perform functional semantic annotation on the diagnostic identifiers and diagnostic service parameters in the state transition logic.

[0011] Furthermore, in some embodiments of this application, the step of calling multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary restored diagnostic function logic further includes: During the restoration of state transition logic and / or the semantic annotation of diagnostic identifiers and diagnostic service parameters, a knowledge transfer model is invoked. Based on a pre-built diagnostic knowledge graph, diagnostic logic templates from similar vehicle platforms are recommended for the diagnostic functions of the target vehicle being analyzed, in order to assist in the restoration of state transition logic and the semantic annotation of diagnostic service parameters.

[0012] Furthermore, in some embodiments of this application, the step of automatically generating a diagnostic function framework for integration into a diagnostic platform based on the verified diagnostic function logic includes: Based on the verified diagnostic function logic, a diagnostic data module conforming to a standard format is generated. The diagnostic data module is used to import into the diagnostic platform for direct execution. Based on the verified diagnostic function logic, corresponding application programming interface (API) code is generated, which is used by developers for secondary integration and invocation.

[0013] Furthermore, in some embodiments of this application, the step of automatically generating a diagnostic function framework for integration into a diagnostic platform based on the verified diagnostic function logic further includes: Based on the verified diagnostic function logic, a graphical configuration interface file is generated. The graphical configuration interface file is used by the user to adjust the control parameters and thresholds in the diagnostic function logic in a visual manner.

[0014] Furthermore, in some embodiments of this application, if the target vehicle diagnostic function is a battery management system (BMS) calibration function, then the step of inputting the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic further includes: After obtaining the verified diagnostic function logic, based on historical data containing typical failure modes collected from the compliant data source, corresponding security protection rules are injected into the verified diagnostic function logic.

[0015] Secondly, embodiments of this application provide a vehicle diagnostic function construction device based on multi-source data and intelligent analysis, comprising: The data acquisition module is used to collect raw diagnostic data for the target vehicle's diagnostic functions from at least two independent, compliant data sources. The data processing module is used to standardize the raw diagnostic data and generate a unified standardized diagnostic data description file. The reasoning and verification module is used to input the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification, and to obtain the verified diagnostic function logic. The framework generation module is used to automatically generate a diagnostic function framework for integration into the diagnostic platform based on the verified diagnostic function logic.

[0016] This application provides a method and apparatus for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis. First, by collecting raw diagnostic data from at least two independent and compliant data sources, unauthorized parsing protocols in existing technologies are avoided from the development source, fundamentally ensuring the legal compliance of diagnostic function development and mitigating subsequent intellectual property infringement risks. Simultaneously, the raw data is standardized to form a unified description file, which is then inferred and verified by an intelligent analysis center. Finally, a functional framework that can be directly used for integration into a diagnostic platform is automatically generated. This entire process replaces the traditional manual reverse analysis and the cumbersome development model of each vehicle model and ECU, thereby reducing the inefficiency of manual intervention, enabling rapid construction of vehicle diagnostic functions, and effectively balancing development legality and efficiency, meeting the market's demand for compliant and efficient development of diagnostic functions. Attached Figure Description

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

[0018] Figure 1 This is an application environment diagram of the vehicle diagnostic function construction method based on multi-source data and intelligent analysis provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of the vehicle diagnostic function construction device based on multi-source data and intelligent analysis provided in the embodiments of this application; Figure 4This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0020] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0021] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0022] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0023] To address the aforementioned technical problems and overcome the shortcomings of existing technologies, this application provides a method and apparatus for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis. This method enables the compliant and efficient development of vehicle diagnostic functions, solving the problems of low development efficiency and insufficient legal compliance in existing technologies.

[0024] Figure 1 This is an application environment diagram of a vehicle diagnostic function construction method based on multi-source data and intelligent analysis in one embodiment. (Refer to...) Figure 1This method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis is applied to a system for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis. The system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal, specifically a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The server 120 is configured to execute the aforementioned method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis, including: collecting raw diagnostic data for the target vehicle diagnostic function from at least two independent compliant data sources; standardizing the raw diagnostic data to generate a unified standardized diagnostic data description file; inputting the standardized diagnostic data description file into an intelligent analysis center for reasoning and verification to obtain verified diagnostic function logic; and automatically generating a diagnostic function framework for integration into the diagnostic platform based on the verified diagnostic function logic.

[0025] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis, provided in an embodiment of this application. This embodiment primarily uses the application of this method to a server as an example. Specifically, the method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis provided in this application may include the following steps: To facilitate understanding of the vehicle diagnostic function construction method based on multi-source data and intelligent analysis provided in this embodiment, this embodiment will be described in detail with specific examples.

[0026] S1. Collect raw diagnostic data for the target vehicle's diagnostic functions from at least two independent, compliant data sources; Specifically, for step S1, obtain legal, diverse, and focused original diagnostic data for the target vehicle's diagnostic functions. This ensures the compliance of data sources while avoiding the limitations of a single data source through multi-source complementarity. The data sources must meet both the requirements of mutual independence and compliance. Mutual independence means that the data acquisition channels and generating entities do not overlap, and that the data can cover diagnostic data in different scenarios. Compliance means that all data collection is based on legal authorization and does not involve unauthorized protocol parsing or data theft. The collected original diagnostic data must accurately match the target vehicle's diagnostic functions; that is, the original diagnostic data must directly correspond to the specific diagnostic needs to be developed (such as brake system fault diagnosis, transmission condition testing, etc.) to ensure the data's relevance.

[0027] For example, if the target diagnostic function is to diagnose a fault in the braking system of a certain vehicle model, communication interaction data generated by the execution of standard fault detection procedures can be collected from diagnostic equipment approved by the OEM; at the same time, the actual operation records of the braking system fault diagnosis of that vehicle model can be obtained from an automotive repair service platform with legal data collection qualifications. The two types of data sources are independent of each other and the collection behavior is legal, together constituting the original diagnostic data.

[0028] S2. Standardize the raw diagnostic data to generate a unified standardized diagnostic data description file; Specifically, for step S2, all raw diagnostic data is first preprocessed: invalid data (such as garbled characters caused by equipment malfunctions or incomplete records due to test interruptions) and duplicate data are removed. Then, core information directly related to the diagnostic logic, such as the diagnostic service call order, service parameters, and vehicle response results, is extracted through parsing. Following a pre-defined general specification for automotive diagnostic data, the extracted core information is formatted to ensure that the converted data file has a unified structure, standardized fields, and is both universal and parsable.

[0029] For example, for the raw data collected for brake system fault diagnosis, invalid messages caused by unstable equipment connection and duplicate test records are first removed. The service sequence of "fault code reading → brake pressure detection → brake pedal travel monitoring → fault confirmation", the instruction parameters of each step, the pressure values ​​and fault status codes fed back by the vehicle, etc. are extracted. Then, this information is integrated into a standardized data description file with a consistent format according to a unified standard.

[0030] S3. Input the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic; Specifically, for step S3, the standardized data description file is first input into the intelligent analysis center. The center, through its built-in analysis mechanism, combines general rules and data characteristics from the vehicle diagnostics field to reconstruct the preliminary diagnostic function logic (including diagnostic process steps, triggering conditions for each step, parameter constraints, etc.). Then, through the intelligent analysis center's verification mechanism, the preliminary logic is cross-validated using raw data from different data sources or known mature diagnostic logic to check for logical gaps, parameter conflicts, or process loopholes. Finally, based on the verification results, the preliminary logic is corrected and completed to form the final verified diagnostic function logic.

[0031] The Intelligent Analysis Center integrates core processing modules for specialized analysis and verification mechanisms in the vehicle diagnostics field. It performs in-depth analysis, logical reconstruction, and precise verification of standardized diagnostic data description files. Essentially, it is an intelligent processing system with capabilities for data analysis, logical reasoning, cross-validation, and correction and optimization. The Intelligent Analysis Center incorporates data analysis rules, diagnostic logic reconstruction algorithms, and verification mechanisms adapted to automotive diagnostic scenarios. It can automatically complete the transformation and verification from standardized data to complete diagnostic function logic without manual intervention, serving as the core hub for automated diagnostic function development.

[0032] Regarding the reasoning process, it primarily relies on diagnostic elements from standardized data. Combined with general rules and data characteristics in the automotive diagnostics field, it automatically reconstructs diagnostic functions. The intelligent analysis center first automatically identifies and extracts core elements such as diagnostic service sequences, service parameters, and response information from the standardized diagnostic data description file. Through a pre-set diagnostic domain rule base, it establishes a correspondence between these elements and diagnostic operations. Based on the general process logic of vehicle diagnostic functions, it performs temporal and causal correlation analysis on the extracted diagnostic elements, clarifying the execution order, triggering conditions, and parameter dependencies of each diagnostic service. The correlated elements and relationships are then integrated into a preliminary diagnostic function logic with a complete process. This determines the steps and nodes of the diagnostic process, the parameter configurations for each node, the state transition rules, and the anomaly response mechanism, forming a logical framework that covers the core operations of the target diagnostic function.

[0033] The verification process primarily involves multi-source data comparison and logical verification to identify loopholes and deviations in the initial reasoning logic, ensuring the completeness and accuracy of the final logic. Raw diagnostic data collected from different independent and compliant data sources is retrieved and compared step-by-step with the initially reconstructed diagnostic function logic. By verifying the consistency of diagnostic steps, parameter configurations, and response results across different data sources, discrepancies between the initial logic and actual data are identified. Based on general standards in the automotive diagnostics field or known mature diagnostic logic templates, the initial logic is verified to have issues such as missing necessary steps, contradictory process sequences, and unreasonable parameter thresholds. For problems discovered during cross-comparison and logical verification, the initial logic is corrected and supplemented by considering the common characteristics of multi-source data and domain standards, ultimately resulting in a verified diagnostic function logic without logical loopholes and highly consistent with actual diagnostic scenarios.

[0034] For example, the standardized data description file for brake system fault diagnosis is input into the intelligent analysis center. The center first reconstructs the preliminary process of "fault code reading → pressure detection → stroke monitoring → fault confirmation" and the parameters of each step. Then, it uses historical diagnostic data from a third-party platform for verification and finds that the preliminary logic is missing the "secondary re-inspection when pressure is abnormal" step. This step and the corresponding parameter threshold are then added to form a complete diagnostic function logic.

[0035] S4. Based on the verified diagnostic function logic, automatically generate a diagnostic function framework for integration with the diagnostic platform; Specifically, for step S4, based on the verified diagnostic function logic, an automated generation mechanism directly outputs a functional framework adaptable to the diagnostic platform. This framework eliminates the need for extensive manual coding of basic code and directly meets the integration requirements of the diagnostic platform. The diagnostic function framework is a standardized, modular, and directly adaptable complete functional carrier automatically generated based on the verified diagnostic function logic. It integrates diagnostic processes, parameter configurations, interaction rules, and integration interfaces into a "plug-and-play" functional set. Its main purpose is to allow the diagnostic platform to quickly acquire the ability to execute target vehicle diagnostic functions (such as BMS calibration and engine fault diagnosis) by directly integrating this framework, without needing to develop diagnostic logic from scratch.

[0036] For example, based on the verified braking system fault diagnosis logic, a functional framework containing a complete diagnostic process, parameter configuration, and response handling mechanism is automatically generated. This framework can be directly imported into mainstream automotive diagnostic software platforms, enabling the platforms to quickly acquire the capability to diagnose braking system faults for that vehicle model.

[0037] This embodiment utilizes a coherent process of compliant multi-source data collection, standardized processing, intelligent analysis and verification, and automated framework generation. This approach avoids the legal risks of illegal data collection, significantly reduces manual intervention, improves the development efficiency of vehicle diagnostic functions, and achieves both compliance and high efficiency in diagnostic function development.

[0038] Furthermore, in some embodiments, step S1, "collecting raw diagnostic data for the target vehicle's diagnostic functions from at least two independent compliant data sources," may specifically include: S11. Collect the first raw data generated by performing the standard diagnostic process from the original diagnostic equipment authorized by the OEM; Specifically, for step S11, the original equipment manufacturer (OEM) diagnostic equipment must be officially authorized by the OEM and have the legal authority to perform diagnostic functions on the target vehicle. Its diagnostic process follows the OEM's pre-set standard procedures, ensuring that the collected data accurately reflects the vehicle's design-level diagnostic logic, communication interaction rules, and parameter configurations. The data collection process must strictly adhere to the standard diagnostic procedure's operating specifications, without adding any custom operations or additional interventions. It must fully record all interaction information between the equipment and the vehicle's electronic control unit (ECU) during the diagnostic process, including command transmission, response feedback, and status switching data.

[0039] For example, if the target diagnostic function is the charge and discharge calibration function of the Battery Management System (BMS) of a certain brand of new energy vehicle, the diagnostic equipment authorized by the OEM will be used to perform operations such as safe access seed exchange, charge and discharge cycle start-up, real-time voltage and temperature monitoring, and SOC (State of Charge) calibration trigger in sequence according to the standard process. At the same time, complete communication logs such as every control command sent by the equipment, seed value returned by the ECU, voltage data, and calibration status code will be collected to form the first raw data.

[0040] S12. Collect second raw data from market-proven third-party diagnostic equipment generated by testing the diagnostic functions of the same target vehicle; Specifically, for step S12, the third-party diagnostic equipment must have undergone long-term market application verification, possessing stable performance and broad compatibility. Its test data should reflect operational differences, environmental impacts, and equipment-vehicle compatibility details that may occur in actual diagnostic scenarios. The data collection target must be strictly limited to "diagnostic functions of the same target vehicle" to ensure direct comparability with the original factory data collected in the first step. This data should be able to verify the core links of the diagnostic logic from the perspective of different equipment, while supplementing data on simplified operations and rapid tests not covered by the original factory process.

[0041] For example, regarding the aforementioned BMS charging and discharging calibration function, a reputable third-party diagnostic device widely used in the automotive repair market was used to test this function on the same model of new energy vehicle. The simplified calibration instructions sent by the device during the test, the differentiated response data of the ECU, and the abnormal prompts during the test were collected to form the second set of raw data, which provides a reference for subsequent verification of the compatibility of the diagnostic logic.

[0042] S13. Obtain de-identified historical data related to the diagnostic functions of the target vehicle from a legally authorized third-party data service provider as third-party raw data; Specifically, for step S13, the third-party data service provider must obtain legal authorization to ensure that the historical data it provides is from compliant sources and does not involve intellectual property infringement or user privacy leaks. Simultaneously, the data must undergo anonymization processing, removing sensitive content such as vehicle identification numbers, user information, and repair shop information, retaining only core data directly related to the diagnostic function. Historical data must be highly relevant to the target vehicle's diagnostic function, covering diagnostic records under different years of use, different fault states, and different operating scenarios, including successful cases, failed cases, and anomaly handling processes, providing data support for identifying edge cases and refining logical details.

[0043] For example, continuing with the aforementioned BMS charging and discharging calibration function, we obtain anonymized historical data from a legally authorized automotive repair data cloud platform. This data includes thousands of BMS calibration cases for this model of vehicle and similar models, covering diagnostic logs, parameter change curves, and troubleshooting results for various scenarios such as voltage imbalance, calibration failure, and calibration anomalies under low temperature conditions. This forms the third set of raw data, providing a basis for subsequently supplementing the anomaly handling rules in the diagnostic logic.

[0044] This embodiment collects raw data through three independent and compliant data sources, which not only ensures the legality of data acquisition from the source, but also improves the comprehensiveness, authority and reliability of the raw data through the complementary verification of original manufacturer standard data, third-party test data and massive historical data, thus laying a solid data foundation for the accurate development of subsequent diagnostic functions.

[0045] Furthermore, in some embodiments, step S2, "standardizing the raw diagnostic data to generate a unified standardized diagnostic data description file," may specifically include: S21. Perform data cleaning and parsing on all collected raw diagnostic data to extract diagnostic logic elements used to constitute diagnostic logic functions. Diagnostic logic elements include diagnostic service sequences, diagnostic service parameters, and diagnostic response information. Specifically, for step S21, all collected raw diagnostic data undergoes data cleaning and parsing. Effective information is filtered from the messy raw data, interference is removed, and the core components for constructing diagnostic logic are extracted, providing high-quality material for subsequent standardized processing. Regarding data cleaning, for raw diagnostic data from different sources and in various formats, meaningless invalid data (such as garbled messages generated by device communication interruptions, electromagnetic interference data in the test environment), duplicate data (such as multiple repeated records of the same operation), and redundant data unrelated to the target diagnostic function are removed, ensuring the purity and effectiveness of the data are preserved. Regarding data parsing, the cleaned effective data is deeply decomposed, accurately extracting three types of core diagnostic logic elements from complex interaction records: the diagnostic service sequence refers to the order in which various services are called during the diagnostic process (e.g., "request for secure access → read execution parameters → feedback diagnostic results"); diagnostic service parameters are the specific configuration information when executing each diagnostic service (e.g., instruction codes, threshold settings, operation duration, etc.); and diagnostic response information is the feedback result of the vehicle electronic control unit (ECU) to the diagnostic service (e.g., status confirmation code, measured data value, fault indication signal, etc.).

[0046] For example, if the original data is the interactive log of the engine idle speed control diagnosis of a certain model, first remove the incomplete messages caused by the power failure of the device and the repeatedly uploaded test records, and then parse the diagnostic service sequence of "idle speed request → speed monitoring → fuel injection pulse width adjustment → idle speed stability confirmation" from the valid data. Extract the instruction code (such as idle speed request instruction 0x310x02), speed threshold (such as 750±50rpm) and other diagnostic service parameters in each step, as well as the actual speed value returned by the ECU (such as 730rpm) and adjustment confirmation code (such as 0x78) and other diagnostic response information.

[0047] S22. Convert the diagnostic logic elements according to the preset automotive diagnostic data description standard to generate a standardized diagnostic data description file; Specifically, for step S22, the preset automotive diagnostic data description standard is an industry-standard or widely recognized unified specification that clarifies the data's structural framework, field definitions, encoding formats, and representation rules. This ensures that the converted data file possesses universality and parsability, allowing it to be directly recognized and processed by subsequent analysis systems. During the format conversion process, the extracted diagnostic service sequences, diagnostic service parameters, and diagnostic response information must be categorized, arranged, matched, and format-adapted according to the standard requirements. This ensures that all elements are logically clear and uniformly expressed in the file, avoiding analytical obstacles caused by format differences.

[0048] For example, the core elements extracted from the engine idle speed control diagnosis are formatted according to preset standards: the diagnostic service sequence is entered using the standard field of "step number-service name-execution order"; parameters such as instruction codes and speed thresholds are encoded according to standard data formats; and response information such as actual speed values ​​and confirmation codes are organized according to the structure of "parameter name-value-unit-feedback status". This ultimately generates a standardized diagnostic data description file with a unified structure and standardized format, making diagnostic elements from different sources a unified data carrier that can be directly used for subsequent analysis. Specifically, the standardized diagnostic data description file can be in formats such as XML (Extensible Markup Language), JSON (JavaScript Object Notation), ASAM MDF (Measurement Data Format), DBC (Data Base CAN), and CSV (Comma-Separated Values). These formats are structured, machine-parsable, and cross-platform compatible, meeting the standardized storage and intelligent analysis needs of automotive diagnostic data.

[0049] This embodiment extracts core diagnostic elements through data cleaning and parsing, and then converts them into standardized formats. This effectively solves the problems of disorganized and incompatible formats of multi-source raw data. The generated standardized data description file provides a clean, unified, and parsable data foundation for subsequent intelligent analysis, ensuring the smoothness and accuracy of diagnostic logical reasoning.

[0050] Furthermore, in some embodiments, step S3, "inputting the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic," may specifically include: S31. Call multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary restored diagnostic function logic; wherein, multiple analysis models analyze the standardized diagnostic data description file in sequence, and the analysis result of the previous model is used as the input of the next model; Specifically, for step S31, multiple analysis models need to operate in a preset order, forming a "relay" analysis process. The output of the previous model directly serves as the input for the next model, avoiding disjointed analysis and ensuring logical coherence in each step. The core objective of collaborative analysis is to extract key information such as diagnostic processes, parameter constraints, and state transitions from standardized data, constructing a preliminary framework that reflects the core logic of the target diagnostic function, without omitting key operational steps and interaction relationships.

[0051] Specifically, the multiple analysis models may include protocol identification models, state machine reconstruction models, and semantic understanding models.

[0052] The protocol recognition model employs a deep learning structure comprising an input layer, a feature extraction layer, a feature fusion layer, and an output layer. The input layer receives structured features (such as instruction code byte sequences, response field lengths, and interaction timing intervals) from a standardized diagnostic data description file and normalizes them into a fixed-dimensional feature vector. The feature extraction layer consists of two convolutional neural network layers and a pooling layer. The first convolutional neural network extracts local features of the instruction format, the second convolutional neural network extracts global interaction features, and the pooling layer uses max pooling to reduce dimensionality. The feature fusion layer is a single fully connected layer that fuses the local and global features extracted by the convolutional layers, outputting a high-dimensional comprehensive feature vector. The output layer consists of two parallel fully connected classification sublayers, outputting the classification results for protocol type and vehicle platform, respectively. The training data for the protocol recognition model consists of standardized diagnostic data from mainstream automotive diagnostic protocols and different vehicle platforms collected within the industry. Protocol types and vehicle platform labels are annotated to construct a labeled dataset containing samples, which is then divided into training, validation, and test sets in a 7:2:1 ratio. The optimizer used in the training parameters is the Adam optimizer, the loss function is the cross-entropy loss function (adapted to multi-classification tasks), the batch size is set to 32, the number of training epochs is 50, and L2 regularization is used to avoid overfitting. During training, automotive diagnostic protocol specifications are incorporated as prior knowledge, and incorrectly labeled samples are manually cleaned to ensure the accuracy of the training data.

[0053] For the state machine reconstruction model, the model structure includes a temporal modeling structure of "input layer, temporal feature encoding layer, attention layer, and output layer". The input layer receives protocol rules and diagnostic service sequence features from standardized data output by the protocol recognition model, transforming them into a temporal input sequence. The temporal feature encoding layer consists of two layers of bidirectional long short-term memory networks, each with 128 hidden units and a dropout rate of 0.2, used to capture the forward and backward temporal dependencies of the diagnostic services. The attention layer employs the Bahdanau attention mechanism, assigning weights to the temporal features output by the bidirectional long short-term memory network, focusing on key service steps for state transitions. The output layer is a single fully connected layer and a softmax activation function, outputting the diagnostic service sequence. The time-series correlation probability matrix of the services was used to clarify the execution order and triggering conditions of each service. The training process included: collecting standard diagnostic process data for different diagnostic functions, labeling the sequence order and triggering conditions of the service sequences, and constructing a time-series sample dataset; the optimizer used was the RMSprop optimizer, the loss function was the time-series classification loss function (CTC loss), adapted for training of variable-length time-series sequences, the batch size was set to 16, the number of training epochs was 40, and an early stopping strategy was adopted (training was stopped if the validation set loss did not decrease for 5 consecutive epochs); the general process rules of automotive diagnostics were incorporated into the training process as constraints to filter abnormal time-series samples and improve the model's learning effect on reasonable time-series logic.

[0054] For the semantic understanding model, a domain semantic understanding structure is adopted, consisting of an input layer, an embedding layer, a feature encoding layer, a semantic mapping layer, and an output layer. The input layer receives textual / numerical features of diagnostic identifiers and service parameters, transforming them into input vectors that the model can process. The embedding layer maps discrete identifiers into 32-dimensional dense vectors, integrating them into a vocabulary specific to automotive diagnostics. The feature encoding layer is a single-layer Transformer encoder that captures the semantic relationships between identifiers and parameters. The semantic mapping layer comprises a fully connected layer and a domain knowledge graph mapping layer, matching the encoded features with a pre-constructed automotive diagnostic knowledge graph. The output layer uses a softmax activation function to output the semantic interpretations corresponding to the diagnostic identifiers and parameters. The training process includes: constructing a semantic annotation dataset for the automotive diagnostics domain, containing key-value pairs of diagnostic identifiers, parameters, and corresponding semantic definitions, with data sources being compliant original equipment manufacturer (OEM) diagnostic manuals and industry standard documents; using the AdamW optimizer (learning rate 0.0005, weight decay coefficient 0.0001), the cross-entropy loss function, a batch size of 64, and 30 training epochs; introducing domain knowledge graph constraints during training (such as limiting the matching range between identifiers and semantic definitions), and employing semi-supervised learning to supplement unlabeled domain data to improve the model's semantic parsing ability for niche identifiers.

[0055] For example, if the target diagnostic function is gear shift calibration for a certain vehicle model, after the standardized data description file is input into the intelligent analysis center, the first model first analyzes the communication characteristics in the data to identify the corresponding diagnostic protocol type and vehicle platform information; the identification result is directly input into the second model, which parses the service call sequence of gear shift calibration based on the protocol rules (such as "wake up ECU → secure access → read shift parameters → issue calibration command → result feedback"); this service sequence is then input into the third model to further extract the parameter configurations corresponding to each service (such as calibration threshold, execution time), and finally form the preliminary diagnostic function logic that includes process, parameters, and interaction relationships.

[0056] S32. Call the verification model in the intelligent analysis center, and use the original diagnostic data or known diagnostic logic from different data sources to perform cross-validation and integrity checks on the initially restored diagnostic function logic to obtain the verification results; Specifically, for step S32, the core functions of the verification model are "cross-validation" and "completeness check." Cross-validation refers to comparing the initial logic with raw data from different data sources (such as original equipment manufacturer data and third-party test data) to verify whether each step is consistent. The completeness check involves comparing the initial logic with known diagnostic logic (such as industry-standard diagnostic specifications and mature logic for similar functions) to check whether the initial logic is missing necessary steps or constraints. The verification results must clearly indicate the compliance status of the initial logic: including steps without problems, conflicting parameters, missing steps, and logically contradictory nodes, providing a clear basis for subsequent corrections.

[0057] For example, regarding the preliminary logic of the aforementioned transmission shift calibration, the verification model first calls the raw data collected by the third-party diagnostic equipment. The comparison reveals that the preliminary logic does not include the "transmission oil temperature detection before calibration" step. Then, by comparing with the known logic of shift calibration for similar models, it is confirmed that oil temperature detection is a necessary prerequisite. At the same time, it is found that a certain calibration threshold in the preliminary logic conflicts with the actual adaptation value fed back by the third-party data, ultimately forming the verification result of "missing oil temperature detection step and conflicting calibration threshold".

[0058] S33. Based on the verification results, fill in and correct the logical omissions or conflicts in the initially restored diagnostic function logic to form the verified diagnostic function logic; Specifically, for step S33, if there are missing logical steps, supplement the necessary steps and related parameters (such as pre-detection and anomaly feedback). If there are logical conflicts, combine multi-source data and known logic to adjust conflicting parameters or optimize the process sequence to eliminate contradictions. The correction process must maintain the overall logical coherence, and the supplemented or adjusted parts must be seamlessly connected with the original reasonable steps without disrupting the core logical chain of the diagnostic process.

[0059] For example, based on the verification results, an "oil temperature detection" step was added to the initial logic of the transmission shift calibration, clarifying the detection threshold (such as 25℃-90℃) and the abnormal handling rules (pause calibration and issue a prompt when the oil temperature exceeds the range); at the same time, referring to third-party data and known logic, the conflicting calibration threshold was adjusted from "0x05" to "0x07" to adapt to the actual working conditions, and finally a complete and conflict-free post-verification diagnostic function logic was formed.

[0060] This embodiment restores the initial logic through multi-model collaborative analysis, and then performs cross-validation and targeted correction, effectively ensuring the integrity, accuracy and rationality of the diagnostic function logic, and providing a reliable core basis for the subsequent automated generation of the diagnostic function framework.

[0061] Furthermore, in some embodiments, step S32, "calling multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary restored diagnostic function logic," may specifically include: S321. The protocol identification model is invoked to analyze the standardized diagnostic data description file, identify the communication protocol and vehicle platform followed, and obtain the protocol identification result; Specifically, for step S321, the protocol identification model must have the ability to identify the features of various automotive diagnostic communication protocols (such as UDS, DoIP, etc.), extract key features from the field structure, command format, and interaction rules of standardized data, and match the corresponding protocol type. Simultaneously, based on information such as vehicle-specific identifiers and ECU models contained in the data, it must pinpoint the vehicle platform to which the data belongs. The identification results must be clear and unambiguous, including both the communication protocol type and vehicle platform information, providing a clear technical basis for subsequent model analysis and avoiding analytical bias due to protocol or platform confusion.

[0062] For example, if a standardized diagnostic data description file corresponds to the air conditioning system fault diagnosis function of a certain brand's hybrid vehicle, the protocol recognition model identifies the communication protocol followed as the UDS (Unified Diagnostic Services) protocol by analyzing the instruction format such as "0x100x03" and "0x270x01", the length of the response field, and the interaction timing in the data. Then, by using the vehicle model code and ECU hardware version information implicit in the data, it determines that the corresponding vehicle platform is the brand's hybrid-specific platform, ultimately forming a protocol recognition result that includes "UDS protocol + hybrid-specific platform".

[0063] S322. Based on the protocol identification results, call the state machine restoration model to analyze the diagnostic service sequence in the standardized diagnostic data description file, and restore the state transition logic of the target vehicle's diagnostic function. Specifically, for step S322, the state machine restoration model needs to be based on the protocol identification results, follow the interaction specifications of the corresponding protocol, and extract the complete diagnostic service sequence from the standardized data (such as "wake up ECU → secure access → fault data reading → functional testing → exit diagnosis"). The core task is to restore the state transition logic, that is, to clarify the connection relationship between each diagnostic service, the triggering conditions (such as entering the next service after meeting a certain parameter threshold), and the abnormal jump rules (such as the retry or exit mechanism when the service execution fails), forming a state transition framework that can reflect the complete process of the diagnostic function.

[0064] For example, based on the identification results of "UDS protocol + hybrid dedicated platform", the state machine restoration model extracts the service sequence for air conditioning system fault diagnosis from standardized data: "0x100x03 (wake up ECU) → 0x270x01 (request secure access) → 0x270x02 (submit security key) → 0x190x02 (read air conditioning system fault code) → 0x2F0x01 (test air conditioning compressor operation) → 0x100x04 (exit diagnosis)"; at the same time, it restores the state transition conditions, such as "only when secure access is passed (ECU returns confirmation code 0x670x02) can the fault code reading step be entered" and "if the compressor operation test has no response, directly jump to the exit diagnosis step and report the fault", and finally form a complete state transition logic.

[0065] S323. Call the semantic understanding model to perform functional semantic annotation on the diagnostic identifiers and diagnostic service parameters in the state transition logic; Specifically, for step S323, the semantic understanding model needs to perform precise functional semantic annotations on vehicle diagnostic-specific identifiers (such as SID, DID, RoutineID, etc.) and various service parameters (such as thresholds, instruction codes, and response codes), combined with the vehicle platform's technical specifications and the application scenarios of diagnostic functions. The annotation content must be clear and easy to understand, clearly defining the specific function corresponding to each identifier and the physical meaning of each parameter (such as numerical units and the actual operating conditions corresponding to threshold ranges), ensuring that the core role of each step can be directly understood during subsequent use.

[0066] For example, regarding the state transition logic for fault diagnosis of air conditioning systems, the semantic understanding model annotates the diagnostic identifiers and parameters: SID "0x190x02" is annotated as "reading air conditioning system fault code", DID "0x2F01" is annotated as "air conditioning compressor operation test status", parameter "threshold 0x01" is annotated as "compressor operation is normal" and "threshold 0x00" is annotated as "compressor operation is abnormal", and response code "0x78" is annotated as "service is executing". Finally, the annotated state transition logic is formed, making the actual function corresponding to the abstract code clear at a glance.

[0067] This embodiment uses three progressive steps—protocol identification to clarify the analysis basis, state machine reconstruction to sort out the core process, and semantic annotation to give it practical meaning—to accurately reconstruct the diagnostic function logic that is complete, logical, and readable. This effectively solves the problems of ambiguous diagnostic process and uninterpreted identifiers, and provides a clear and usable core basis for the subsequent generation of the diagnostic function framework.

[0068] Furthermore, in some embodiments, step S32, "calling multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary restored diagnostic function logic," further includes: S324. During the restoration of state transition logic and / or the semantic annotation of diagnostic identifiers and diagnostic service parameters, the knowledge transfer model is invoked to recommend diagnostic logic templates of similar vehicle platforms for the diagnostic function of the target vehicle being analyzed, based on the pre-built diagnostic knowledge graph, in order to assist in the restoration of state transition logic and the semantic annotation of diagnostic service parameters. Specifically, for step S324, in steps S322 and / or S323, when the core analysis work progresses to the stage of clarifying the relationships in the diagnostic process or assigning practical meaning to abstract code and parameters, the knowledge transfer model is activated to avoid interference from premature intervention or loss of auxiliary value from intervention too late. Model invocation needs to be linked in real-time with the core analysis process to ensure that the recommended reference templates can provide timely support for the current analysis stage and remain consistent with the core work progress.

[0069] A pre-built diagnostic knowledge graph forms the core data foundation. It contains a massive amount of validated diagnostic-related information, specifically covering different vehicle platforms (e.g., various platforms for gasoline and new energy vehicles), various diagnostic functions (e.g., powertrain and control system diagnostics), complete diagnostic logic flows (including state transition relationships and triggering conditions), and standard interpretations of diagnostic identifiers and parameters. Clear relationships are established between each information node (e.g., "Vehicle platform - Diagnostic function - Corresponding logical framework - Meaning of related identifiers"). The knowledge graph requires continuous accumulation and validation to ensure the accuracy and standardization of the stored diagnostic knowledge, providing effective reference for the analysis of new diagnostic functions and avoiding misleading the analysis process with erroneous knowledge.

[0070] The knowledge transfer model analyzes the core characteristics of the target diagnostic function (such as its system, diagnostic objective, technical principles, and core components involved) and searches the diagnostic knowledge graph for vehicle platforms with similar technical backgrounds (such as those with the same technical architecture, common core components, and similar diagnostic requirements). From the matched similar vehicle platforms, mature and validated corresponding diagnostic function logic templates are extracted. These templates must include a complete state transition framework (such as step sequence, triggering conditions, and exception jump rules), diagnostic identifiers, and parameter annotation specifications to ensure direct reference value.

[0071] Specifically, for the knowledge transfer model, a deep learning architecture is adopted, including an input layer, a feature embedding layer, a knowledge association encoding layer, a similarity matching layer, and a template output layer. The input layer receives two types of core inputs: ① core features of the target diagnostic function; ② structured data of a pre-constructed diagnostic knowledge graph, which is uniformly converted into a vector format that the model can process.

[0072] The feature embedding layer maps the input discrete features into a 64-dimensional dense vector. The node features of the diagnostic knowledge graph are pre-trained using the GraphSAGE algorithm to obtain initial embedding vectors. The embedding vectors of the target diagnostic features are aligned with the knowledge graph node vectors in the same dimensional space to ensure the effectiveness of subsequent similarity calculations. The knowledge association encoding layer consists of one Transformer encoder and one fully connected layer. The Transformer encoder captures the cross-dimensional associations between the target diagnostic features and each node in the knowledge graph. The fully connected layer further fuses the associated features, outputting a high-dimensional comprehensive feature vector. The similarity matching layer employs cosine similarity calculation and attention weighting. It first calculates the cosine similarity between the comprehensive feature vector of the target diagnostic features and the feature vectors of all diagnostic logic templates in the knowledge graph. Then, it weights the similarity results through an attention mechanism to select the top-N candidate templates. The template output layer consists of one fully connected layer and a sigmoid activation function to validate the candidate templates. Finally, it outputs adapted similar diagnostic logic templates, including a complete state transition framework and semantic annotation specifications. The training process is as follows: A core dataset is constructed, including a pre-built automotive diagnostic knowledge graph and paired labeled samples, divided into training, validation, and test sets in a 7:2:1 ratio. Feature normalization is performed on the labeled samples, and deduplication and association strengthening are applied to knowledge graph nodes to ensure data consistency. The optimizer used is the AdamW optimizer (initial learning rate 0.0006, weight decay coefficient 0.0001), adapted to the small sample size scenario in the domain, balancing training speed and generalization ability; the loss function is the contrastive loss function, which improves template matching accuracy by narrowing the distance between the target feature and similar template features, and widening the distance between the target feature and dissimilar template features; training hyperparameters include batchsize=64, number of training epochs=35, dropout rate=0.2 (encoding layer), and similarity threshold=0.7 (candidate template selection); L2 regularization and an early stopping strategy (training stops if the validation set loss does not decrease for 6 consecutive epochs) are combined to avoid model overfitting. During training, prior rules from the automotive diagnostics domain are incorporated to guide the model to focus on key matching dimensions; new pairing samples are generated through template feature fine-tuning to expand the diversity of training data; and template matching error cases are fed back in real time during training to supplement missing association edges in the knowledge graph and continuously optimize the model's association encoding capabilities.

[0073] For assisting in the restoration of state transition logic, the recommended template's state transition framework is used as a reference. By comparing the standardized data of the current target diagnostic function, the connection relationship of core steps, potential triggering conditions, and exception handling rules can be quickly located. Unknown links can be supplemented or the rationality of the initially sorted logic can be verified to avoid missing key processes.

[0074] For auxiliary semantic annotation, we refer to the standard interpretations of diagnostic identifiers and parameters in the template, and combine them with the technical characteristics of the target diagnostic function to quickly assign accurate meanings to the current abstract code and parameters, reduce the blind parsing of unknown identifiers, and ensure the standardization of annotation results.

[0075] This embodiment uses a knowledge transfer model to call similar templates in the diagnostic knowledge graph, providing accurate references for state transition logic restoration and semantic annotation. This effectively reduces the difficulty of analyzing new diagnostic functions, reduces redundant work, improves the integrity of diagnostic logic and the standardization of annotation results, and significantly improves the efficiency and accuracy of the core analysis process.

[0076] Furthermore, in some embodiments, step S4, "automatically generating a diagnostic function framework for integration with the diagnostic platform based on the verified diagnostic function logic," may specifically include: S41. Based on the verified diagnostic function logic, generate a diagnostic data module that conforms to the standard format. The diagnostic data module is used to import into the diagnostic platform for direct execution. Specifically, for step S41, the verified diagnostic function logic is transformed into standardized, directly reusable modules, ensuring that the diagnostic platform can quickly adapt to and execute the target diagnostic function. This is done in strict accordance with the standard format commonly used in the automotive diagnostic field, which must meet the import compatibility requirements of mainstream diagnostic platforms, ensuring that the modules can be recognized and called without additional modifications. The diagnostic data module must completely encapsulate the verified diagnostic function logic, including core elements such as diagnostic process steps, parameter constraints, state transition rules, and response handling mechanisms, ensuring that it can independently implement the target diagnostic function after import.

[0077] For example, if the verified diagnostic function logic is for fault diagnosis of the ignition system of a certain model engine (including the complete process and parameter thresholds of "fault code reading → ignition coil voltage detection → spark plug status judgment → fault location feedback"), a diagnostic data module is generated in a standard format. This module contains complete information such as the process execution sequence, instruction codes for each step, voltage threshold range (e.g., normal ignition coil voltage 12-14V), and fault judgment rules. It can be directly imported into mainstream automotive diagnostic software platforms, and the fault diagnosis process of the engine ignition system of this model can be started without additional configuration.

[0078] S42. Based on the verified diagnostic function logic, generate the corresponding application programming interface (API) code. The API code is used by developers for secondary integration and invocation. Specifically, for step S42, developers are provided with flexible integration tools to support the rapid embedding of target diagnostic functions into custom development scenarios, meeting diverse secondary development needs. The API code must fully match the verified diagnostic function logic, accurately mapping the core operations of the diagnostic function (such as starting diagnosis, reading parameters, and obtaining results), ensuring that developers can achieve complete control over the diagnostic function simply by calling the API. The code must have good readability and compatibility, follow general programming standards, support adaptation to different development environments and programming languages, and lower the technical threshold for secondary integration.

[0079] For example, corresponding API code is generated for the above-mentioned engine ignition system fault diagnosis logic, including core interfaces such as "StartDiagnosis()", "GetIgnitionVoltage()", and "GetFaultResult()". When developing custom diagnostic tools, developers only need to call these API interfaces to quickly integrate the ignition system fault diagnosis function into their own software without rewriting the diagnostic logic code, greatly simplifying the integration process.

[0080] This embodiment achieves "ready-to-use" and flexible integration of diagnostic functions by generating standard format diagnostic data modules and reusable API code. This reduces the difficulty of adapting to the diagnostic platform and provides convenient tools for secondary development, significantly improving the efficiency of implementing diagnostic functions and the flexibility of application.

[0081] Furthermore, in some embodiments, step S4, "automatically generating a diagnostic function framework for integration with the diagnostic platform based on the verified diagnostic function logic," further includes: S43. Based on the verified diagnostic function logic, generate a graphical configuration interface file. The graphical configuration interface file is used by users to adjust the control parameters and thresholds in the diagnostic function logic in a visual way.

[0082] Specifically, for step S43, from the verified diagnostic function logic, identify all control parameters (such as the execution time of diagnostic operations, data acquisition intervals, component action triggering conditions, etc.) and thresholds (such as voltage safety thresholds, temperature warning thresholds, fault judgment thresholds, etc.) that affect the diagnostic process and results. Clarify the physical meaning, default value, and reasonable adjustment range of each parameter and threshold to avoid irrelevant or unadjustable redundant items. The sorting process needs to be combined with the actual application scenarios of the diagnostic function, prioritizing the selection of elements that users may need to flexibly adjust under different operating conditions, ensuring that the interface adjustment function fits the actual usage needs.

[0083] For different types of control parameters and thresholds, corresponding visualization components should be matched: for numerical thresholds (such as pressure and temperature), sliders and numeric input boxes should be designed; for time-related parameters (such as detection intervals and acquisition durations), adjustment boxes with unit selection should be designed; for status-related parameters (such as whether to enable secondary verification), check boxes should be designed, ensuring that the components are adapted to the adjustment requirements. The interface framework should be logically clear, with layouts divided by diagnostic function modules or parameter types (such as "Basic Parameter Configuration Area" and "Safety Threshold Configuration Area"), accompanied by clear text descriptions (such as parameter meaning, unit, and default value), allowing users to quickly locate the content that needs adjustment and avoiding operational confusion.

[0084] Data interaction logic is embedded in the graphical configuration interface file. When a user modifies parameters or thresholds through interface components, the system can automatically capture the adjusted values ​​and synchronously update the corresponding core parameters in the diagnostic function logic according to preset rules, without requiring manual coding or configuration commands. The correlation process must ensure the accuracy and real-time performance of data transmission to avoid inconsistencies between the adjusted values ​​and the values ​​actually called by the diagnostic logic. A data validation mechanism is also set up (e.g., prompting "Invalid value, please re-enter" when the value exceeds a reasonable range) to ensure the validity of the adjustment operation.

[0085] This embodiment generates a graphical configuration interface file, transforming abstract diagnostic parameters and thresholds into intuitive visual operations. These parameters can be flexibly adjusted without requiring professional programming knowledge, significantly reducing the technical threshold for parameter adjustment, improving the adaptability of the diagnostic function to different usage scenarios, and ensuring the targeted nature and optimization efficiency of the diagnostic results.

[0086] Furthermore, in some embodiments, if the target vehicle's diagnostic function is a battery management system (BMS) calibration function, then the standardized diagnostic data description file is input to the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic, which also includes: After obtaining the verified diagnostic function logic, based on historical data containing typical failure modes collected from compliant data sources, corresponding security protection rules are injected into the verified diagnostic function logic.

[0087] Specifically, if the target vehicle's diagnostic function is the Battery Management System (BMS) calibration function, the BMS calibration function covers core diagnostic operations related to battery state regulation, such as charge and discharge calibration, SOC (State of Charge) calibration, and single cell equalization calibration. These functions are directly related to battery safety, and the need for safety protection rules is particularly urgent.

[0088] Data sources should be obtained from compliant channels, meaning legally authorized data sources that do not infringe on privacy or intellectual property rights, avoiding the use of illegally collected or unauthorized fault data. Extracted historical data should focus on "typical fault modes," i.e., data related to fault scenarios that occur frequently during BMS calibration and may pose safety risks, including key information such as fault triggering conditions, fault manifestations, and the scope of fault impact, excluding accidental or unrepresentative fault records. For each type of typical fault mode, analyze its triggering causes and risk consequences, and formulate targeted prevention or intervention rules. These rules must clearly define triggering conditions, execution actions, and feedback mechanisms to ensure they can be integrated into the BMS calibration and diagnostic logic and executed automatically. Security protection rules should primarily focus on security protection, including fault warnings, process interruptions, parameter adjustments, and emergency shutdowns, avoiding ineffective rules that only record faults without actual protective actions. The injection process must ensure seamless integration of security protection rules with the original diagnostic function logic, without disrupting the core logic of the calibration process (such as the order of calibration steps and parameter calculation methods), adding security verification and intervention mechanisms only at key nodes. The safety protection rules are automatically identified and executed by the diagnostic logic. When the rule triggering conditions are met during the calibration process, the system automatically starts the corresponding safety protection action without manual intervention, ensuring the real-time performance and effectiveness of safety protection.

[0089] This embodiment injects safety protection rules based on typical failure modes, enabling the BMS calibration and diagnostic function to have targeted safety protection capabilities. This effectively avoids safety risks such as battery overload and fault expansion during the calibration process, and significantly improves the safety and reliability of the BMS calibration function.

[0090] To facilitate understanding of the vehicle diagnostic function construction method based on multi-source data and intelligent analysis provided in this embodiment, the following will describe the specific implementation process, including the following steps: Step 1: Multi-source compliant data collection We use original equipment manufacturer (OEM) diagnostic equipment to perform standard diagnostic procedures and collect complete communication logs; we use third-party diagnostic equipment to collect data on the same functions of the same vehicle model; and we cooperate with third-party data companies to obtain massive amounts of anonymized diagnostic historical data through legal authorization.

[0091] Step 2: Data Standardization and ODX Conversion Establish a data processing center to clean and parse the raw data. Automatically convert the proprietary format raw data into ODX (Open Diagnostic Data Exchange) files that conform to the ASAMMCD-2 standard.

[0092] Step 3: AI Intelligent Reasoning and Cross-Validation 1. Collaborative analysis of standardized ODX files from five major AI models: The system uses protocol identification and classification models to determine the protocol family and vehicle platform to which the data belongs. Service call sequences are analyzed using service sequence modeling and state machine reconstruction models to reconstruct the diagnostic function state machine. Functional semantic understanding and annotation models are used to semantically annotate DID (Service Identifier) ​​and SID (Data Identifier). Cross-platform knowledge transfer and analogical reasoning models recommend diagnostic logic templates for similar platforms. Anomaly detection and integrity verification models ensure the rationality and security of the AI ​​generation process.

[0093] For example, the protocol identification and classification model quickly determines the protocol family (e.g., UDS / DoIP) and vehicle platform to which the data belongs, providing a route for subsequent analysis. The service sequence modeling and state machine reconstruction model (using Transformer / LSTM) analyzes the service call sequence in the ODX, automatically reconstructing the complete diagnostic function state machine (e.g., 1003->2701->2702->31F100->exit). The functional semantic understanding and annotation model semantically annotates DID, SID, and RoutineID (Routine Identifier) ​​(e.g., DIDF190="Total Battery Voltage"), and identifies the system and security level to which it belongs. The cross-platform knowledge transfer and analogical reasoning model (based on the constructed diagnostic knowledge graph, recommends diagnostic logic templates from similar platforms for new vehicle models or unknown functions, enabling generalization) verifies the rationality of the AI ​​generation process, detecting missing steps (e.g., no session exit), logical conflicts, or security risks.

[0094] For example, the AI ​​model analysis output can detect defects in the original manufacturer's data, such as the verification model detecting missing temperature protection rules. Then, it can extract patch rules from historical data provided by third parties and inject them into the ODX file. In addition, it can perform semantic annotation, such as annotating the hexadecimal instruction 0x310xF1A0 as "start pulse discharge" and adding the safety warning "keep the charging pile connected (>6kW)".

[0095] 2. Use third-party data to cross-validate the AI ​​inference results.

[0096] Step 4: Automated diagnostic function framework generation, filling in any missing logic to ensure the completeness and accuracy of the functions. Based on the validated diagnostic logic output by the AI ​​center, an automatically generated, ready-to-use development file library is created, including standard ODX function module packages, API interface code, and graphical configuration interface files, supporting rapid integration into the diagnostic software platform.

[0097] In summary, the vehicle diagnostic function construction method based on multi-source data and intelligent analysis provided in this embodiment collects multi-source compliant data and performs standardized processing, then completes inference verification through an intelligent analysis center, and finally automatically generates a functional framework that can be directly used for integration into the diagnostic platform. This enables the rapid construction of vehicle diagnostic functions and effectively balances development legality and efficiency, solving the problems of low development efficiency and insufficient legal compliance in existing technologies.

[0098] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0099] To facilitate better implementation of the vehicle diagnostic function construction method based on multi-source data and intelligent analysis according to the embodiments of this application, this application also provides a vehicle diagnostic function construction device based on multi-source data and intelligent analysis, which is based on the above-described vehicle diagnostic function construction method based on multi-source data and intelligent analysis. The meanings of the terms used are the same as in the above-described vehicle diagnostic function construction method based on multi-source data and intelligent analysis, and specific implementation details can be found in the descriptions in the method embodiments.

[0100] Please see Figure 3 , Figure 3 This is a schematic diagram of the vehicle diagnostic function construction device based on multi-source data and intelligent analysis provided in an embodiment of this application. Specifically, this device may include a data acquisition module 201, a data processing module 202, a reasoning and verification module 203, and a framework generation module 204, as follows: Data acquisition module 201 is used to collect raw diagnostic data for the diagnostic functions of the target vehicle from at least two independent compliant data sources. The data processing module 202 is used to standardize the raw diagnostic data and generate a unified standardized diagnostic data description file. The reasoning and verification module 203 is used to input the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification, and obtain the verified diagnostic function logic. The framework generation module 204 is used to automatically generate a diagnostic function framework for integration into the diagnostic platform based on the verified diagnostic function logic.

[0101] Furthermore, in some embodiments, the data acquisition module 201 is specifically used for: Collect the first raw data generated from the standard diagnostic process using original equipment manufacturer (OEM) authorized diagnostic equipment; Secondary raw data is collected from market-proven third-party diagnostic equipment to test the diagnostic functions of the same target vehicle. Obtain anonymized historical data related to the diagnostic functions of the target vehicle from a legally authorized third-party data service provider, as the third source data.

[0102] Furthermore, in some embodiments, the data processing module 202 is specifically used for: All collected raw diagnostic data are cleaned and parsed to extract diagnostic logic elements that constitute the diagnostic logic function. The diagnostic logic elements include diagnostic service sequence, diagnostic service parameters, and diagnostic response information. The diagnostic logic elements are converted into a standardized diagnostic data description file according to the preset automotive diagnostic data description standard.

[0103] Furthermore, in some embodiments, the inference verification module 203 is specifically used for: Multiple analysis models in the intelligent analysis center are invoked to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary reconstruction of the diagnostic function logic. Among them, multiple analysis models analyze the standardized diagnostic data description file in sequence, and the analysis results of the previous model are used as the input of the next model. The verification model in the intelligent analysis center is invoked, and the original diagnostic data or known diagnostic logic from different data sources are used to perform cross-validation and integrity checks on the initially restored diagnostic function logic to obtain the verification results. Based on the verification results, the logical deficiencies or conflicts in the initially restored diagnostic function logic are supplemented and corrected to form the verified diagnostic function logic.

[0104] Furthermore, in some embodiments, the inference verification module 203 is specifically used for: The protocol identification model is invoked to analyze the standardized diagnostic data description file, identify the communication protocol and vehicle platform followed, and obtain the protocol identification result; Based on the protocol identification results, the state machine restoration model is called to analyze the diagnostic service sequence in the standardized diagnostic data description file, and the state transition logic of the target vehicle's diagnostic function is restored. The semantic understanding model is invoked to perform functional semantic annotation on the diagnostic identifiers and diagnostic service parameters in the state transition logic.

[0105] Furthermore, in some embodiments, the reasoning verification module 203 is specifically used to: in the process of restoring the state transition logic and / or semantically annotating the diagnostic identifier and diagnostic service parameters, invoke the knowledge transfer model, and recommend diagnostic logic templates of similar vehicle models and platforms for the diagnostic function of the target vehicle being analyzed based on the pre-built diagnostic knowledge graph, so as to assist in the restoration of the state transition logic and the semantic annotation of the diagnostic service parameters.

[0106] Furthermore, in some embodiments, the frame generation module 204 is specifically used for: Based on the verified diagnostic function logic, a diagnostic data module conforming to the standard format is generated. The diagnostic data module is used to import into the diagnostic platform for direct execution. Based on the verified diagnostic function logic, the corresponding application programming interface (API) code is generated. The API code is used by developers for secondary integration and invocation.

[0107] Furthermore, in some embodiments, the frame generation module 204 is specifically used for: Based on the verified diagnostic function logic, a graphical configuration interface file is generated. This file allows users to visually adjust the control parameters and thresholds in the diagnostic function logic.

[0108] Furthermore, in some embodiments, if the target vehicle diagnostic function is the battery management system (BMS) calibration function, the inference verification module 203 is specifically used to: after obtaining the verified diagnostic function logic, inject corresponding safety protection rules into the verified diagnostic function logic based on historical data containing typical fault modes collected from compliant data sources.

[0109] Specific limitations regarding the vehicle diagnostic function construction device based on multi-source data and intelligent analysis can be found in the limitations of the vehicle diagnostic function construction method based on multi-source data and intelligent analysis described above, and will not be repeated here. Each module in the aforementioned vehicle diagnostic function construction device based on multi-source data and intelligent analysis can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0110] The vehicle diagnostic function construction device based on multi-source data and intelligent analysis provided in this embodiment collects multi-source compliant data and performs standardized processing. Then, the intelligent analysis center completes the inference verification and finally automatically generates a functional framework that can be directly used for integration into the diagnostic platform. This enables the rapid construction of vehicle diagnostic functions and effectively balances development legality and efficiency, solving the problems of low development efficiency and insufficient legal compliance in existing technologies.

[0111] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0112] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and a vehicle diagnostic function construction method based on multi-source data and intelligent analysis by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0113] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0114] The electronic device may also include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0115] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302 to realize various functions, as follows: Raw diagnostic data for the target vehicle's diagnostic functions is collected from at least two independent, compliant data sources; the raw diagnostic data is standardized to generate a unified, standardized diagnostic data description file; the standardized diagnostic data description file is input into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic; based on the verified diagnostic function logic, a diagnostic function framework for integration into the diagnostic platform is automatically generated.

[0116] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0117] This application embodiment collects multi-source compliant data and performs standardized processing, then completes inference verification through an intelligent analysis center, and finally automatically generates a functional framework that can be directly used for integration into the diagnostic platform. This enables the rapid construction of vehicle diagnostic functions and effectively balances development legality and efficiency, solving the problems of low development efficiency and insufficient legal compliance in existing technologies.

[0118] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0119] To this end, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the vehicle diagnostic function construction methods based on multi-source data and intelligent analysis provided in embodiments of this application. For example, the instructions can execute the following steps: Raw diagnostic data for the target vehicle's diagnostic functions is collected from at least two independent, compliant data sources; the raw diagnostic data is standardized to generate a unified, standardized diagnostic data description file; the standardized diagnostic data description file is input into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic; based on the verified diagnostic function logic, a diagnostic function framework for integration into the diagnostic platform is automatically generated.

[0120] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0121] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0122] Since the instructions stored in the storage medium can execute the steps in any of the vehicle diagnostic function construction methods based on multi-source data and intelligent analysis provided in the embodiments of this application, the beneficial effects that any of the vehicle diagnostic function construction methods based on multi-source data and intelligent analysis provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0123] The foregoing has provided a detailed description of a vehicle diagnostic function construction method and apparatus based on multi-source data and intelligent analysis provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis, characterized in that, include: Collect raw diagnostic data for the target vehicle's diagnostic functions from at least two independent, compliant data sources. The original diagnostic data is standardized to generate a unified standardized diagnostic data description file; The standardized diagnostic data description file is input into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic. Based on the verified diagnostic function logic, a diagnostic function framework for integration into the diagnostic platform is automatically generated.

2. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 1, characterized in that, The process involves collecting raw diagnostic data for the target vehicle's diagnostic functions from at least two independent, compliant data sources, including: Collect the first raw data generated from the standard diagnostic process using original equipment manufacturer (OEM) authorized diagnostic equipment; Secondary raw data is collected from market-proven third-party diagnostic equipment to test the diagnostic functions of the same target vehicle. Obtain de-identified historical data related to the diagnostic function of the target vehicle from a legally authorized third-party data service provider, as the third original data.

3. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 1, characterized in that, The standardization process for the original diagnostic data to generate a unified standardized diagnostic data description file includes: All collected raw diagnostic data are cleaned and parsed to extract diagnostic logic elements that constitute the diagnostic logic function. The diagnostic logic elements include diagnostic service sequence, diagnostic service parameters, and diagnostic response information. The diagnostic logic elements are converted into a standardized diagnostic data description file according to a preset automotive diagnostic data description standard.

4. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 1, characterized in that, The process of inputting the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic includes: Multiple analysis models in the intelligent analysis center are invoked to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary reconstruction of the diagnostic function logic; wherein, the multiple analysis models analyze the standardized diagnostic data description file in sequence, and the analysis result of the previous model is used as the input of the next model; The verification model in the intelligent analysis center is invoked, and the original diagnostic data or known diagnostic logic from different data sources are used to perform cross-validation and integrity checks on the initially restored diagnostic function logic to obtain the verification results. Based on the verification results, the logical deficiencies or conflicts existing in the initially restored diagnostic function logic are supplemented and corrected to form the verified diagnostic function logic.

5. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 4, characterized in that, The step of calling multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary reconstruction of the diagnostic function logic includes: The standardized diagnostic data description file is analyzed by calling the protocol identification model to identify the communication protocol and vehicle platform followed, and the protocol identification result is obtained. Based on the protocol identification results, the state machine restoration model is called to analyze the diagnostic service sequence in the standardized diagnostic data description file, and the state transition logic of the target vehicle's diagnostic function is restored. The semantic understanding model is invoked to perform functional semantic annotation on the diagnostic identifiers and diagnostic service parameters in the state transition logic.

6. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 5, characterized in that, The step of calling multiple analysis models in the intelligent analysis center to perform collaborative analysis on the standardized diagnostic data description file to obtain a preliminary reconstruction of the diagnostic function logic also includes: During the restoration of state transition logic and / or the semantic annotation of diagnostic identifiers and diagnostic service parameters, a knowledge transfer model is invoked. Based on a pre-built diagnostic knowledge graph, diagnostic logic templates from similar vehicle platforms are recommended for the diagnostic functions of the target vehicle being analyzed, in order to assist in the restoration of state transition logic and the semantic annotation of diagnostic service parameters.

7. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 1, characterized in that, The step of automatically generating a diagnostic function framework for integration into the diagnostic platform based on the verified diagnostic function logic includes: Based on the verified diagnostic function logic, a diagnostic data module conforming to a standard format is generated. The diagnostic data module is used to import into the diagnostic platform for direct execution. Based on the verified diagnostic function logic, corresponding application programming interface (API) code is generated, which is used by developers for secondary integration and invocation.

8. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 1, characterized in that, The step of automatically generating a diagnostic function framework for integration into the diagnostic platform based on the verified diagnostic function logic further includes: Based on the verified diagnostic function logic, a graphical configuration interface file is generated. The graphical configuration interface file is used by the user to adjust the control parameters and thresholds in the diagnostic function logic in a visual manner.

9. The method for constructing vehicle diagnostic functions based on multi-source data and intelligent analysis according to claim 1, characterized in that, If the target vehicle diagnostic function is a battery management system (BMS) calibration function, then the step of inputting the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification to obtain the verified diagnostic function logic further includes: After obtaining the verified diagnostic function logic, based on historical data containing typical failure modes collected from the compliant data source, corresponding security protection rules are injected into the verified diagnostic function logic.

10. A vehicle diagnostic function construction device based on multi-source data and intelligent analysis, characterized in that, include: The data acquisition module is used to collect raw diagnostic data for the target vehicle's diagnostic functions from at least two independent, compliant data sources. The data processing module is used to standardize the raw diagnostic data and generate a unified standardized diagnostic data description file. The reasoning and verification module is used to input the standardized diagnostic data description file into the intelligent analysis center for reasoning and verification, and to obtain the verified diagnostic function logic. The framework generation module is used to automatically generate a diagnostic function framework for integration into the diagnostic platform based on the verified diagnostic function logic.

Images