Parameter verification methods, devices, equipment and media

Abstract

This application relates to the technical field of automotive electronic control, and in particular to parameter verification methods, devices, equipment, and media. The method includes: in response to a user-defined verification requirement, acquiring a calibration parameter package and real-time operating condition data; parsing the calibration parameter package to obtain operating condition requirements; determining a verification strategy based on the operating condition requirements and a preset operating condition model matching relationship, wherein the preset operating condition model matching relationship characterizes different verification models corresponding to different operating conditions, and the verification strategy characterizes the use of different verification models according to different operating condition requirements; performing data-driven verification based on the verification strategy to obtain data-driven results; and performing parameter verification based on the data-driven results and the real-time operating condition data to obtain verification results. This method can automate parameter verification, improving its efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the technical field of automotive electronic control, and in particular to parameter verification methods, devices, equipment, and media. Background Technology

[0002] As the automotive industry moves towards intelligent and low-carbon development, the electronic control system of the engine (or the powertrain of new energy vehicles) has become the core factor determining vehicle performance (such as power, economy, and emission compliance). The electronic control system uses embedded software (ECU, Electronic Control Unit) to control key actuators (such as fuel injectors, throttle body, and ignition coils) in real time. The accuracy of this control depends on "calibration parameters"—a series of preset values ​​in the ECU (such as injection pulse width, ignition advance angle, and air-fuel ratio). These parameters need to be dynamically adjusted according to engine characteristics, operating conditions (such as idling and acceleration), and environmental factors (such as temperature and altitude). The accuracy of these calibration parameters directly affects vehicle performance: an excessively large injection pulse width may lead to increased fuel consumption and excessive emissions; an improper ignition advance angle may cause engine knocking or insufficient power.

[0003] Currently, when calibrating parameters, engineers typically use calibration tools to import the calibration parameter package to be verified, and then manually select the working conditions to be verified from a preset working condition library based on experience in order to calibrate and verify the parameters. In this process, parameter calibration and verification both rely on manual analysis by engineers, resulting in low verification efficiency. Summary of the Invention

[0004] This application provides a parameter verification method, apparatus, device, and medium that can automate parameter verification and improve its efficiency and accuracy.

[0005] On the one hand, embodiments of this application provide a parameter verification method, the method including:

[0006] In response to user-defined verification requirements, obtain calibration parameter packages and real-time operating condition data;

[0007] The calibration parameter package is parsed to obtain the operating condition requirements;

[0008] Based on the working condition requirements and the matching relationship of the preset working condition model, a verification strategy is determined. The preset working condition model matching relationship is used to represent that different working conditions correspond to different verification models. The verification strategy is used to represent that different verification models are adopted according to different working condition requirements.

[0009] Data-driven results are obtained based on the aforementioned verification strategy.

[0010] Based on the data-driven results and the real-time operating data, parameter verification is performed to obtain the verification results.

[0011] Optionally, obtaining the calibration parameter package includes:

[0012] In response to the user-defined verification requirements, a verification task document is extracted from the verification requirements;

[0013] Parameters are extracted from the verification task document to obtain multiple dynamic parameters;

[0014] The dynamic parameters are combined using a preset dynamic parameter template to obtain a calibration parameter package.

[0015] Optionally, the method of extracting parameters from the verification task document to obtain multiple dynamic parameters further includes:

[0016] The verification task document is preprocessed to obtain a standard task document;

[0017] Based on the standard task document, an initial graph structure is constructed, which includes multiple nodes;

[0018] Based on a preset structural entropy formula, the structural entropy of each node in the initial graph structure is determined. The structural entropy is used to characterize the complexity and information content of the node in the initial graph structure.

[0019] The importance of the multiple nodes is ranked using a preset graph neural network to obtain the node importance order;

[0020] Based on the structural entropy, the order of node importance, and preset filtering conditions, the multiple nodes are filtered to obtain key nodes;

[0021] The initial graph structure is processed based on the key nodes to obtain the final graph structure;

[0022] Based on the final graph structure, parameters of the verification task document are extracted to obtain multiple dynamic parameters.

[0023] Optionally, before combining the dynamic parameters using a preset dynamic parameter template to obtain a calibration parameter package, the method further includes:

[0024] Data is extracted from the verification task document to obtain the constraints and parameter variables;

[0025] Based on the constraints and parameter variables, construct the constraint satisfaction problem;

[0026] Solve the constraint satisfaction problem to obtain the template structure and parameter list;

[0027] A preset dynamic parameter template is generated based on the template structure and parameter list using a preset time series detection algorithm.

[0028] Optionally, before determining the verification strategy based on the matching relationship between the working condition requirements and the preset working condition model, the method further includes:

[0029] Based on the aforementioned operating condition requirements, extract at least one operating condition feature;

[0030] The operating condition features are matched with the preset operating condition model matching relationship to obtain the verification model identifier corresponding to the at least one operating condition feature. The preset operating condition model matching relationship includes the correspondence between multiple operating condition features and verification model identifiers.

[0031] The corresponding verification model is determined based on the matched verification model identifier;

[0032] Based on the verification model and the operating conditions, a verification strategy is generated, which includes a verification model, verification parameters, and a verification process.

[0033] Optionally, before matching the working condition feature with a preset working condition model matching relationship to obtain a verification model identifier corresponding to the at least one working condition feature, the method further includes:

[0034] Obtain historical operating condition data and corresponding verification model usage records;

[0035] Feature extraction is performed on the historical operating condition data to obtain historical operating condition features;

[0036] Based on the historical operating condition features and the corresponding verification model usage records, a classification model is trained to obtain the matching relationship of the preset operating condition model.

[0037] Optionally, the step of performing parameter verification based on the data-driven result and the real-time operating condition data to obtain the verification result includes:

[0038] Based on the real-time operating data, the real-time physical drive result is determined;

[0039] If the real-time physics-driven result is determined to be a violation of a preset rule, the verification result is determined to be an invalid parameter;

[0040] If the real-time physical drive result is determined to be a pass and the data drive result is determined to be a preset performance indicator exceeding a preset threshold, the verification result is determined to be a parameter that needs to be optimized.

[0041] If both the real-time physical drive result and the data drive result are determined to be driving successfully, the verification result is determined to be verification successful.

[0042] On the other hand, embodiments of this application provide a parameter verification device, the device comprising:

[0043] The acquisition module is used to acquire calibration parameter packages and real-time operating condition data in response to user-defined verification requirements.

[0044] The parsing module is used to parse the calibration parameter package to obtain the operating condition requirements;

[0045] The determination module is used to determine the verification strategy based on the working condition requirements and the preset working condition model matching relationship. The preset working condition model matching relationship is used to characterize that different working conditions correspond to different verification models, and the verification strategy is used to characterize that different verification models are adopted according to different working condition requirements.

[0046] The data-driven module is used to perform data-driven operations based on the verification strategy and obtain data-driven results.

[0047] The verification module is used to perform parameter verification based on the data-driven results and the real-time operating condition data, and obtain the verification results.

[0048] In another aspect, embodiments of this application provide an electronic device, the device including: a processor and a memory storing computer program instructions;

[0049] When the processor executes the computer program instructions, it implements the parameter verification method as described in the first aspect.

[0050] In another aspect, embodiments of this application provide a computer storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, they implement the parameter verification method as described in the first aspect.

[0051] The parameter verification method, apparatus, device, and medium of this application embodiment can analyze the requirements of the calibration parameter package input by the user, analyze the working condition requirements from the calibration parameter package, and then determine the verification strategy by matching the working condition requirements with the preset working condition model. That is, it realizes the automation of calibration parameters and the collaborative verification and continuous optimization of the model. Then, it performs data-driven operation according to the verification strategy to obtain the theoretical data-driven result. Then, it performs parameter verification by comparing the data-driven result with real-time working condition data. Based on the verification result, it realizes the automated verification of parameters, which not only improves the efficiency of parameter verification but also greatly improves the accuracy of data verification. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the structure of a parameter verification system provided in an embodiment of this application;

[0053] Figure 2 This is a flowchart illustrating a parameter verification method provided in an embodiment of this application;

[0054] Figure 3 This is a structural block diagram of a parameter verification device provided in an embodiment of this application;

[0055] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0056] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0057] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such 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..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0058] To address the problems of existing technologies, embodiments of this application provide a parameter verification method, apparatus, device, and medium. In these embodiments, a requirement parsing process is performed on a user-input calibration parameter package to analyze operating condition requirements. Then, a verification strategy is determined by matching these operating condition requirements with a preset operating condition model. This automates the calibration parameter verification process, enabling collaborative model verification and continuous optimization. Following the verification strategy, data-driven analysis is performed to obtain theoretical data-driven results. Finally, parameter verification is achieved by comparing these data-driven results with real-time operating condition data. The verification results enable automated parameter verification, significantly improving both the efficiency and accuracy of data verification.

[0059] The parameter calibration system provided in the embodiments of this application will be introduced first below.

[0060] Figure 1 A schematic diagram of the structure of a parameter calibration system according to an embodiment of this application is shown, as follows: Figure 1 As shown, the parameter calibration system may include:

[0061] The system comprises an intelligent scheduling layer 101, a multi-model encapsulation layer 102, and a data closed-loop layer 103. The multi-model encapsulation layer 102 is communicatively connected to the intelligent scheduling layer 101 and the data closed-loop layer 103, respectively.

[0062] In this embodiment, the intelligent scheduling layer 101 may include a requirement parsing module, a working condition-model matching model, and a result adjudication module. The requirement parsing module can automatically parse the calibration parameter package and verification requirements, call the model interface of the multi-model encapsulation layer 102 downwards, and accept user input upwards to realize bidirectional data interaction. The working condition-model matching module can call the model interface of the multi-model encapsulation layer 102 downwards to obtain working condition data. The result adjudication module can be used to receive the calculation results of the multi-model encapsulation layer 102 downwards and store the verification results.

[0063] The multi-model encapsulation layer 102 can be used to manage the basic model library downwards and provide model calling services upwards, and receive iterative data from the data closed-loop layer 103.

[0064] The data closed-loop layer 103 may include a model version management module and a feedback iteration module. The model version management module can provide model version data to the multi-model encapsulation layer 102 and receive model iteration information from the multi-model encapsulation layer 102. The feedback iteration module can be used to push iteration data to the multi-model encapsulation layer 102 and can also receive verification results and real-time operating data of the actual vehicle.

[0065] In this embodiment, each module is described below:

[0066] The requirement analysis module is implemented by using the task module and task dcm result submission module of the electrical control data management system to extract the corresponding task requirements and the engineer's delivery results, and converting the delivery results dcm into data tuples, i.e., parameter packages.

[0067] The implementation method of the operating condition-model matching module is as follows: A three-dimensional knowledge base of "parameter-operating condition-model" is constructed (stored using the graph database Neo4j). Nodes represent parameter types (e.g., injection pulse width), operating conditions (e.g., -30℃ cold start + rapid acceleration), and models (e.g., GT-Power physical model, LSTM data-driven model). Edges represent adaptation weights (obtained through training based on historical verification success rates). After inputting structured task instructions, the optimal operating condition-model combination path is calculated using the Dijkstra algorithm, generating a calling strategy (e.g., "injection pulse width parameter → high-altitude rapid acceleration operating condition → first call GT-Power to verify combustion rules, then call LSTM to verify historical data matching degree").

[0068] Implementation method of the result adjudication module: Design a multi-model result fusion rule engine and set up three-level adjudication logic:

[0069] ① If the physical model outputs "violation of engineering rules" (e.g., injection pulse width > valve opening time), the parameter is directly determined to be invalid; ② If the physical model passes, the data-driven model outputs "predictive performance index exceeds threshold", and the parameter is determined to be in need of optimization.

[0070] ③ If both pass, the similarity to historical real-vehicle data is considered (≥90% is considered passing). The rule engine is implemented using the drools framework, supporting visual configuration of the adjudication logic, which is convenient for engineers to adjust according to the needs of different vehicle models.

[0071] The standardized interface module for models is implemented as follows: A unified RESTful API protocol is defined, with parameters including "model type (physics / data-driven), input parameter set (operating conditions + parameters to be verified), computational accuracy requirements, and timeout." The output format is uniformly JSON (containing "model name, version, computational results, and confidence level"). Adapters are developed for existing physics models (such as GT-Power) to convert their native interfaces (such as TCP / IP protocol) into standardized APIs. For data-driven models (such as LSTM), they are deployed as API services via TensorFlow Serving, enabling "one-click invocation."

[0072] The multi-model collaborative computing module is implemented using the Celery task scheduling framework to achieve parallel / serial model computation. For "basic operating conditions + simple parameters" (such as fuel injection pulse width under idling conditions), serial computation is used (the physical model verifies the rules first, and then the data model verifies the deviations); for "complex multi-operating conditions + related parameters" (such as joint verification of ignition advance angle under idling and rapid acceleration), parallel computation is used (models under different operating conditions are started simultaneously, and the calculation results are aggregated and then decided). Computational resource scheduling is implemented through Kubernetes, which automatically allocates CPU / memory resources according to the model's computational load (e.g., 8 CPU cores for the physical model and 16GB of memory for the data-driven model) to ensure computational efficiency.

[0073] The full-condition database implementation method is as follows: a secondary storage system is built based on MySQL and Redis. MySQL stores the full range of condition data (including 20 common conditions and 80+ edge conditions, such as -30℃ cold start, 4000m altitude plateau, and high-frequency urban congestion). Each condition record includes "environmental parameters (temperature / altitude / humidity), operating parameters (RPM / load), and performance thresholds (fuel consumption / emissions)". Redis caches frequently accessed conditions (such as urban congestion and highway cruising) to improve read speed. Condition data acquisition is completed through bench testing (covering extreme environment chamber simulation) and real vehicle road testing (road conditions in different regions of the country) to ensure data authenticity.

[0074] The feedback iteration module is implemented by constructing a "verification result - real vehicle data" association table, binding the parameter ID of each verification with subsequent data collected by the real vehicle's OBD (On-Board Diagnostics) system (such as actual fuel consumption and fault codes). The OLAP database Doris is used to store real vehicle time-series data. A Python script periodically (e.g., daily at midnight) calculates the model prediction error (e.g., the difference between predicted and actual fuel consumption). When the error exceeds 5%, model iteration is automatically triggered: new data is input to drive incremental model training (using a fine-tuning approach, updating only the last two layers of the model). After training, the model is automatically registered to the standardized interface module, and older versions are archived to the version management module.

[0075] The parameter verification method provided in the embodiments of this application is described below.

[0076] Figure 2 A flowchart illustrating a parameter verification method provided in one embodiment of this application is shown. Figure 2 As shown, the parameter verification method may include S201-S205:

[0077] S201, in response to user-defined verification requirements, acquires calibration parameter packages and real-time operating condition data.

[0078] In this embodiment, during parameter verification, the user imports the calibration parameter package for the ignition advance of the hybrid vehicle. This calibration parameter package can be in .a2l format, and the user manually inputs requirements, such as verifying whether the parameters meet the power and emission requirements under rapid acceleration conditions. At this time, real-time operating condition data can also be obtained through the data iteration layer for subsequent parameter verification.

[0079] S202, perform requirement analysis on the calibration parameter package to obtain the operating condition requirements.

[0080] In this embodiment, the calibration parameter package can be analyzed using a data parsing tool to extract the ignition advance angle range. Then, the requirements are parsed into structured instructions to obtain the operating condition requirements. At the same time, the parameter type is ignition advance angle, the operating condition type is hybrid rapid acceleration, and the indicators are torque ≥250N-m and NO emission ≤50mg / km.

[0081] S203, based on the matching relationship between working condition requirements and preset working condition models, determine the verification strategy.

[0082] In this embodiment, the associated paths of ignition advance angle and hybrid rapid acceleration can be queried from the graph database through the preset operating condition model matching relationship to generate a verification strategy. The preset operating condition model matching relationship is used to characterize different operating conditions corresponding to different verification models, and the verification strategy is used to characterize the use of different verification models according to different operating condition requirements.

[0083] S204, based on the verification strategy, performs data-driven processing to obtain data-driven results.

[0084] In this embodiment, a verification strategy can be executed in the parameter verification system to perform data-driven simulation and obtain data-driven results. That is, collaborative calculation is performed in the multi-model encapsulation layer according to the working condition requirements to obtain data-driven results.

[0085] S205 performs parameter verification based on data-driven results and real-time operating condition data to obtain verification results.

[0086] In this embodiment, the calibration parameter package input by the user can be parsed to determine the operating conditions. Then, the verification strategy is determined by matching the operating conditions with the preset operating condition model. This achieves the automation of calibration parameters, as well as model collaborative verification and continuous optimization. After that, data-driven operation is performed according to the verification strategy to obtain the theoretical data-driven results. Then, the parameters are verified by comparing the data-driven results with real-time operating condition data. The verification results enable automated parameter verification, which not only improves the efficiency of parameter verification but also greatly improves the accuracy of data verification.

[0087] In some embodiments, S201 may include:

[0088] In response to the user's defined verification requirements, extract the verification task document from the verification requirements;

[0089] Parameters are extracted from the verification task document to obtain multiple dynamic parameters;

[0090] The dynamic parameters are combined using a preset dynamic parameter template to obtain a calibration parameter package.

[0091] In this embodiment, in response to user-defined verification requirements, a verification task document is extracted from these requirements. This aims to transform the user's high-level verification intent into an operable, structured task description. User-defined verification requirements can take various forms, such as natural language descriptions, graphical interface input, and configuration file selection. Extracting the verification task document involves identifying and generating a unified-format document from these diverse input requirements. This document details the specific objectives, scope, constraints, and parameter types required for the verification. This process can utilize Natural Language Processing (NLP) technology to parse the user-input text requirements, identifying keywords, phrases, and syntactic structures to construct the task document. Alternatively, if the user selects preset verification scenarios or configuration items through a graphical interface, the system can automatically generate a corresponding structured task document based on these selections, such as an XML or JSON file, or an internal data structure. This document serves as the basis for subsequent parameter extraction and parameter package generation.

[0092] The goal of this step is to extract parameters from the validation task document to obtain multiple dynamic parameters. The objective is to accurately identify and extract all the variable parameters actually needed for this validation, i.e., the "dynamic parameters," from the validation task document. These dynamic parameters are the core elements for building the calibration parameter package. Their values ​​or types may change in different validation tasks. Pattern matching, regular expressions, semantic analysis, or rule-based parsers can be used to scan the validation task document. For example, a set of rules can be predefined to identify the parameter names and their potential value ranges indicated by specific tags, fields, or syntactic structures in the document. For more complex documents, machine learning models (such as named entity recognition models) can be used to identify the various parameters mentioned in the document. The extracted dynamic parameters can be a list or dictionary containing attributes such as parameter name, type, default value, and value range.

[0093] The calibration parameter package is obtained by combining dynamic parameters using a preset dynamic parameter template. This step uses a preset template to organize and fill the previously extracted dynamic parameters according to a specific structure and format, thereby generating a complete and executable calibration parameter package. This template defines the overall structure of the calibration parameter package, the position of each parameter, the data type, and the logical relationships between them. The preset dynamic parameter template can be an XML Schema, JSON Schema, database table structure definition, or a class definition in a programming language. The system maps the extracted dynamic parameters to the corresponding fields or positions in the template. For example, the template may contain fields such as "sensor type", "sampling frequency", "threshold setting", and "test sequence". The system fills the extracted dynamic parameters (such as "temperature sensor", "100Hz", "upper limit 50, lower limit -10", "start-run-stop") into these fields. The final generated calibration parameter package is a structurally complete and semantically clear data file that can be directly used by subsequent verification processes.

[0094] In this embodiment, when responding to a user-defined verification request, instead of simply obtaining a preset calibration parameter package, the system first extracts a verification task document from the verification request, then identifies and extracts multiple dynamic parameters from the document, and subsequently uses a preset dynamic parameter template to structurally combine these dynamic parameters, ultimately generating a customized calibration parameter package. This approach overcomes the limitations of traditional methods where calibration parameter packages may be fixed or require manual adjustment, significantly improving the flexibility and automation of the parameter verification process. It enables the system to dynamically and accurately construct the required calibration parameter package according to the user's diverse verification needs, thereby ensuring the relevance and effectiveness of the verification, reducing manual intervention and potential errors, and improving the overall verification efficiency and accuracy.

[0095] In the parameter verification method, in response to the verification requirements determined by the user, a verification task document is extracted from the verification requirements, and parameters are extracted from the verification task document to obtain multiple dynamic parameters. However, the verification task document often contains a large amount of unstructured text, redundant information, or multiple forms of expression, which makes it easy for direct parameter extraction to be inaccurate, incomplete, or inefficient, thereby affecting the quality of subsequent calibration parameter package generation.

[0096] Specifically, the method involves extracting parameters from the verification task document to obtain multiple dynamic parameters, and also includes:

[0097] The verification task document is preprocessed to obtain the standard task document;

[0098] Based on the standard task document, construct an initial graph structure, which includes multiple nodes;

[0099] Based on the preset structural entropy formula, the structural entropy of each node in the initial graph structure is determined. Structural entropy is commonly used to characterize the complexity and information content of a node in the initial graph structure.

[0100] A pre-defined graph neural network is used to rank the importance of multiple nodes, thus obtaining the node importance order;

[0101] Key nodes are obtained by filtering multiple nodes based on structural entropy, node importance order, and preset filtering conditions.

[0102] The initial graph structure is processed based on key nodes to obtain the final graph structure;

[0103] Based on the final graph structure, parameters from the verification task document are extracted to obtain multiple dynamic parameters.

[0104] First, the verification task document is preprocessed to obtain a standard task document. The verification task document may include unstructured text, multiple formats, or redundant information. Preprocessing aims to eliminate these heterogeneities and noise, converting it into a uniform and standardized format for subsequent structured analysis.

[0105] Specifically, Natural Language Processing (NLP) techniques, such as word segmentation, part-of-speech tagging, named entity recognition, and syntactic analysis, can be used to structure the text content. For example, comments, whitespace, and non-text elements can be removed from the document; synonyms with different expressions can be normalized; or the document content can be converted into a unified XML, JSON, or other structured data format.

[0106] Secondly, based on the standard task document, an initial graph structure is constructed, consisting of multiple nodes. Abstracting the information in the standard task document into a graph structure better represents the relationships between information. Nodes represent basic information units in the document, such as keywords, concepts, entities, sentences, or paragraphs, while edges represent the relationships between these units, such as semantic associations, citation relationships, and logical order. Specifically, the graph can be constructed by analyzing word co-occurrence frequency, semantic similarity, and syntactic dependencies in the standard task document. For example, each important noun or verb can be used as a node; if two words frequently appear in the same sentence or paragraph, an edge can be established between them.

[0107] Secondly, based on the pre-defined structural entropy formula, the structural entropy of each node in the initial graph structure is determined. Structural entropy is commonly used to characterize the complexity and information content of a node in the initial graph structure. It is an indicator that measures the information complexity and importance of a node in the graph structure. Nodes with high structural entropy usually mean stronger connectivity, greater information content, or a more critical position in the graph. By calculating structural entropy, the contribution of each node to the overall task document information structure can be quantified. The calculation of structural entropy can be based on various centrality measures in graph theory (such as degree centrality, betweenness centrality, and proximity centrality) or information theory concepts. For example, it can be defined as the number of edges connected to a node, the number of neighboring nodes connected to a node, or the frequency with which a node acts as an intermediary in the shortest path in the graph.

[0108] The preset structural entropy formula can be calculated using the structural entropy calculation formula in related technologies, and is not limited here.

[0109] Furthermore, a pre-defined graph neural network is used to rank the importance of multiple nodes, resulting in a node importance order. Graph Neural Networks (GNNs) can learn representations of nodes in a graph and capture the complex relationships between them. Ranking nodes by importance using GNNs allows for a more intelligent assessment of their criticality in the overall task, going beyond simple structural entropy calculations. Specifically, various GNN models can be used, such as Graph Convolutional Networks (GCNs) and Graph Attention Networks (GATs). GNNs can receive node features (such as word vectors and structural entropy values) and the graph's topology as input. Through multi-layer neural networks, they learn the embedding representations of nodes. Then, a classifier or regressor can be trained based on these embedding representations to predict node importance scores and rank them accordingly.

[0110] Based on this, multiple nodes are filtered according to structural entropy, node importance order, and preset filtering conditions to obtain key nodes. Combining structural entropy, GNN ranking results, and manually set filtering conditions, information units that are crucial to the verification task can be identified more accurately, and redundant or secondary information can be removed. Filtering conditions may include: nodes with structural entropy higher than a certain threshold, nodes ranked in the top N% of importance, or nodes containing specific keywords. For example, a comprehensive scoring mechanism can be set up to weight and sum the structural entropy and the importance score of the GNN, and then select the node with the highest score.

[0111] Subsequently, the initial graph structure is processed based on key nodes to obtain the final graph structure. After identifying key nodes, the original graph structure needs to be simplified or reconstructed to highlight key information and their interrelationships, forming a more focused and concise graph representation, which facilitates subsequent parameter extraction. Processing methods may include: deleting non-key nodes and their associated edges; or constructing a subgraph centered on key nodes, retaining only connections between key nodes and between key nodes and a few directly related nodes; or weighting or labeling the paths between key nodes to emphasize their important relationships.

[0112] Finally, based on the final graph structure, parameters from the verification task document are extracted, resulting in multiple dynamic parameters. From the simplified final graph structure, the parameters actually used for verification can be efficiently and accurately identified and extracted. These parameters are dynamic because they are derived from the analysis of the specific task document content.

[0113] Specifically, parameters can be extracted by traversing the key nodes and their attributes in the final graph structure. For example, if a key node represents a physical quantity, the corresponding numerical range, unit, or data type can be extracted as dynamic parameters from the node's attributes or its neighboring nodes.

[0114] In this embodiment, the verification task document can be preprocessed to transform it into a standard task document, and an initial graph structure can be constructed. This transforms complex unstructured information into easily analyzable structured data. Based on this, by combining the quantification of node information complexity by structural entropy and the intelligent ranking of node importance by graph neural networks, the criticality of each information unit in the document can be evaluated more comprehensively and accurately. By integrating this information and applying preset filtering conditions, the true key nodes can be efficiently identified, thereby effectively removing redundant and secondary information.

[0115] Furthermore, by processing these key nodes to obtain the final graph structure, the parameter extraction process can focus on core information, avoiding the inaccurate or missing parameter extraction problems caused by document complexity or information overload in traditional methods. Ultimately, the dynamic parameters extracted from the simplified graph structure not only improve the accuracy and efficiency of parameter extraction but also provide high-quality input for the subsequent generation of calibration parameter packages, thereby enhancing the robustness and effectiveness of the entire parameter validation method.

[0116] In some other embodiments, before combining dynamic parameters using a preset dynamic parameter template to obtain a calibration parameter package, the method further includes:

[0117] Data is extracted from the verification task document to obtain the constraints and parameter variables;

[0118] Based on the constraints and parameter variables, construct a constraint satisfaction problem;

[0119] Solve the constraint satisfaction problem to obtain the template structure and parameter list;

[0120] A preset dynamic parameter template is generated based on the template structure and parameter list using a preset time series detection algorithm.

[0121] Specifically, in the step of extracting data from the validation task document to obtain constraints and parameter variables, this step aims to systematically identify the rules, restrictions, and adjustable elements contained within the original validation task document. For example, natural language processing (NLP) techniques, such as named entity recognition, dependency parsing, or semantic role labeling, can be used to parse the document. Alternatively, regular expressions or rule-based systems can be used to extract specific patterns or keywords, which typically indicate constraints (e.g., "must be between X and Y", "must not exceed Z") and parameter variables (e.g., "engine speed", "temperature", "pressure"). Through this process, the unstructured information in the validation task document is transformed into structured constraint and parameter variable data.

[0122] In the step of constructing a constraint satisfaction problem based on constraints and parameter variables, this step involves formalizing the extracted constraints and parameter variables into a solvable mathematical or logical problem. This typically involves defining the parameter variables as variables in the problem and setting a range (domain) for each variable. Simultaneously, the extracted natural language constraints are transformed into formalized mathematical inequalities, equations, or logical predicates that must be satisfied when the variables are assigned values. For example, if a constraint is "engine speed must be between 1000 and 5000 RPM", then the constraint satisfaction problem would include a variable `engine speed` with a domain of `[1000, 5000]`.

[0123] Furthermore, in the step of solving the constraint satisfaction problem to obtain the template structure and parameter list, this step uses a constraint satisfaction problem solver to find variable assignments that satisfy all defined constraints. Commonly used solving algorithms include backtracking, local search, or constraint propagation techniques (such as arc compatibility). The solution will provide a set of valid parameter configurations (i.e., the parameter list) and an underlying structure defining how these parameters interact under given constraints (i.e., the template structure). For example, if the solution shows that when the pressure is Y, the temperature must be X, then this relationship will form part of the template structure.

[0124] Building upon this, the step of generating a preset dynamic parameter template using a preset time series detection algorithm based on the template structure and parameter list aims to transform the derived template structure and parameter list into a dynamic parameter template. This template is particularly suitable for combining dynamic parameters and can consider time series or sequential requirements. The preset time series detection algorithm can analyze the template structure and parameter list to identify temporal dependencies or sequence patterns in parameter application or change. For example, if the template structure indicates that parameter A should change before parameter B, and parameter B should follow a specific ascending curve, the time series detection algorithm formalizes these time patterns. This may involve using Hidden Markov Models (HMMs), Dynamic Time Warping (DTW), or sequence mining techniques to identify recurring time patterns or optimized sequences of parameter applications. The final generated template not only defines the parameter values ​​but also their temporal relationships and dependencies, giving it a "dynamic" characteristic.

[0125] In this embodiment, constraints and parameter variables can be systematically extracted from the verification task document and formalized as a constraint satisfaction problem for solution, thereby automatically deriving a robust and context-aware template structure and parameter list. This effectively avoids the limitations of traditionally relying on human experience or predefined rules to create templates, significantly reducing the need for human intervention and minimizing errors that may be introduced by manual operation. Furthermore, by utilizing a preset time series detection algorithm, a dynamic parameter template is generated based on the derived template structure and parameter list. This template can embed the inherent time dependencies and dynamic behaviors of the verification task. This ensures that the generated calibration parameter package not only maintains logical consistency but also dynamically adapts to temporal changes in actual operation, thereby significantly improving the accuracy, efficiency, and automation level of the parameter verification process. Ultimately, the generated dynamic parameter template is more accurate and flexible, making the combination of dynamic parameters more effective, thus obtaining a more reliable calibration parameter package.

[0126] In some other embodiments, prior to S202, the method may further include:

[0127] Extract at least one working condition feature based on the working condition requirements;

[0128] The working condition features are matched with the preset working condition model matching relationship to obtain the verification model identifier corresponding to at least one working condition feature. The preset working condition model matching relationship includes the correspondence between multiple working condition features and verification model identifiers.

[0129] The corresponding verification model is determined based on the matched verification model identifier;

[0130] Based on the verification model and operating conditions, a verification strategy is generated, which includes the verification model, verification parameters, and verification process.

[0131] In this embodiment, at least one operating condition feature is extracted based on the operating condition requirements. The aim is to identify and extract representative and discriminative key information from the original, potentially broad, operating condition requirements. For example, if the operating condition requirements are textual descriptions, specific features such as "high temperature," "high pressure," and "start-up phase" can be obtained using natural language processing techniques (such as keyword extraction and named entity recognition). If the operating condition requirements are structured data, numerical features can be extracted using feature engineering methods (such as statistical analysis and principal component analysis). These operating condition features form the basis for subsequent precise matching and strategy generation.

[0132] Subsequently, the operating condition features are matched against preset operating condition model matching relationships to obtain a verification model identifier corresponding to at least one operating condition feature. The preset operating condition model matching relationship is a pre-established knowledge base or mapping table that records in detail the correspondence between different operating condition features (or combinations thereof) and specific verification model identifiers. For example, it could be a lookup table where the key is the operating condition feature and the value is the verification model identifier; or it could be a rule-based system that derives the verification model identifier based on the combination logic of the operating condition features. This step ensures that the most suitable verification model type can be accurately located based on the actual characteristics of the current operating condition.

[0133] Next, based on the matched verification model identifier, the corresponding verification model is determined. Once the verification model identifier is obtained, the system can retrieve or load the corresponding verification model from a pre-set model library. The verification model can be a specific algorithm, mathematical formula, simulation program, or expert system, designed to perform parameter verification tasks under specific operating conditions. For example, the identifier "Model A" may correspond to a verification model based on physical equations, while "Model B" may correspond to an anomaly detection model based on machine learning.

[0134] Finally, based on the verification model and operating condition requirements, a verification strategy is generated. This strategy includes the verification model, verification parameters, and verification process. This step integrates the previously determined verification model with the original operating condition requirements to form a complete and executable verification scheme. Verification parameters refer to the specific values ​​required when executing the verification model, such as thresholds, tolerances, and sampling frequencies. These parameters are dynamically adjusted according to operating condition requirements (e.g., "high-speed operation" may require stricter thresholds). The verification process defines the execution order and steps of the verification tasks, including data preprocessing, model execution, result post-processing, and anomaly handling, ensuring the standardization and completeness of the verification process.

[0135] In this embodiment, specific operating condition features are first extracted from the operating condition requirements, resulting in a more detailed and accurate understanding of the operating conditions. Subsequently, these operating condition features are matched against preset operating condition model matching relationships to accurately identify the most suitable verification model identifier for the current operating condition, thereby determining the corresponding verification model. Based on this, a complete verification strategy, including the verification model, verification parameters, and verification process, is generated by combining the determined verification model and the original operating condition requirements. This step-by-step, refined strategy generation method overcomes the strategy generalization problem that may result from direct matching, ensuring that the verification strategy can highly adapt to specific operating condition requirements. This significantly improves the targeting, accuracy, and effectiveness of parameter verification, avoiding unnecessary resource waste and verification deviations.

[0136] In some other embodiments, before matching the operating condition features with a preset operating condition model matching relationship to obtain a verification model identifier corresponding to at least one operating condition feature, the method further includes:

[0137] Obtain historical operating condition data and corresponding verification model usage records;

[0138] Feature extraction is performed on historical operating condition data to obtain historical operating condition features;

[0139] Based on historical operating condition characteristics and corresponding verification model usage records, a classification model is trained to obtain the preset operating condition model matching relationship.

[0140] The acquisition of historical operating condition data and corresponding calibration model usage records refers to the various environmental parameters, operating states, and sensor readings collected by the system during past operations, such as engine speed, throttle opening, coolant temperature, and intake pressure. Calibration model usage records indicate which calibration models the system actually used for parameter calibration under these historical operating conditions, as well as the usage status or decision results of these models. This data and records can be acquired and archived through system logs, database storage, or a dedicated data acquisition module. For example, each time parameter calibration is performed, the system automatically records the current operating condition data and the selected calibration model identifier, storing it in the historical database for subsequent analysis and learning.

[0141] Furthermore, feature extraction is performed on historical operating condition data to obtain historical operating condition features. Feature extraction involves extracting representative, discriminative, and useful information for subsequent tasks from the raw, high-dimensional historical operating condition data through data processing and analysis methods, forming a low-dimensional feature vector. These features can better characterize the essential attributes of different operating conditions. For example, statistical features (such as mean, variance, maximum, and minimum values), frequency domain features (such as the spectral energy after Fourier transform), or time domain features (such as zero-crossing rate and autocorrelation coefficient) can be extracted from time series data. For multi-dimensional sensor data, dimensionality reduction methods such as principal component analysis (PCA) can be used, or key parameters strongly correlated with operating condition classification can be directly selected as features to obtain historical operating condition features.

[0142] Based on this, a classification model is trained using historical operating condition features and corresponding verification model usage records to obtain a preset operating condition model matching relationship. The classification model is a machine learning model whose function is to learn the mapping relationship from input features to output categories. Here, the input is the extracted historical operating condition features, and the output is the corresponding verification model identifier. By using historical operating condition features as the model's input and the corresponding verification model usage records (i.e., verification model identifiers) as the model's label, supervised learning methods (such as support vector machines, decision trees, random forests, or neural networks) are used for training. After training, the classification model can predict the most suitable verification model identifier based on new operating condition features, thereby constructing a correspondence between operating condition features and verification model identifiers, i.e., the preset operating condition model matching relationship.

[0143] By employing the aforementioned technical solution, historical operating condition data and corresponding verification model usage records are acquired. Feature extraction from this historical data allows for the extraction of valuable operating condition information from a large volume of actual operational data. Based on this, a classification model is trained using these historical operating condition features and verification model usage records. This enables the system to automatically learn and establish a correspondence between operating condition features and verification model identifiers—a preset operating condition model matching relationship. This data-driven approach overcomes the limitations of traditional reliance on manual experience or static configuration, significantly improving the accuracy and adaptability of the preset operating condition model matching relationship. When new operating condition requirements arise, the system can more intelligently and accurately match the most suitable verification model based on the learned model, thereby ensuring the effectiveness and reliability of subsequent verification strategies and improving the automation and accuracy of parameter verification.

[0144] In some other embodiments, S204 may include:

[0145] Based on real-time operating data, determine the real-time physical drive results;

[0146] If the real-time physics-driven result determines that the preset rule is violated, the verification result determines that the parameter is invalid;

[0147] If the real-time physics-driven result indicates that the drive has passed, and the data-driven result indicates that the preset performance index exceeds the preset threshold, the verification result indicates that the parameters need to be optimized.

[0148] If both the real-time physical drive result and the data drive result are determined to be driving successfully, the verification result is determined to be verification successful.

[0149] In this embodiment, during parameter verification, the first step is to determine the real-time physical drive results based on real-time operating condition data. Real-time physical drive results refer to the system response or performance obtained through physical models or simulations based on actual operating condition data; they reflect the actual effect of parameters in the real physical world. For example, in vehicle control system parameter verification, real-time operating condition data may include vehicle speed, engine speed, throttle opening, ambient temperature, etc. By inputting this data into a pre-established vehicle dynamics model or engine physical model, key physical quantities such as theoretical torque output, fuel consumption, emissions, and vehicle acceleration can be simulated and calculated. These physical quantities can be compared with preset physical performance indicators or safety boundaries to determine whether the system operates according to expected physical laws and whether there are any physical anomalies.

[0150] Furthermore, when determining the verification result, a tiered judgment is made based on both real-time physics-driven and data-driven results. If the real-time physics-driven result indicates a violation of a preset rule, the verification result is determined to be an invalid parameter. Preset violation rules can be a series of hard constraints, such as: engine speed exceeding the safety limit, excessively high exhaust temperature, emission concentration exceeding regulatory limits, abnormal system pressure, vehicle instability, etc. When the real-time physics-driven result (e.g., exhaust temperature calculated by a physical model) exceeds the preset maximum allowable temperature threshold or falls below the minimum allowable temperature threshold, it is judged as a rule violation. In this case, regardless of the data-driven result, the parameter is considered invalid, indicating a serious problem with the current parameter configuration, failing to meet basic operational requirements, and requiring immediate correction.

[0151] Furthermore, if the real-time physical drive result indicates a successful drive, and the data-driven result indicates that the preset performance indicators exceed the preset thresholds, the verification result indicates that the parameters need optimization. A successful drive means that there are no violations of hard rules at the physical level, and the system can operate normally. However, the data-driven result reflects the performance of parameters under specific operating conditions. If these performance indicators (such as fuel economy, response speed, control precision, comfort, etc.) have not reached the level of "invalidity" but have exceeded the preset optimization thresholds (i.e., poor performance), it indicates that the parameters still have room for improvement. For example, the real-time physical drive result shows that the vehicle is driving normally without any physical faults, which means the drive has passed. However, the data-driven result (which may be predicted by a machine learning model) shows that under the current parameters, fuel consumption is 5% higher than the target value (exceeding the preset threshold), or the vehicle acceleration response time is 20% slower than expected. In this case, although the parameters are usable, they still need further optimization to improve performance.

[0152] Finally, if both the real-time physics-driven and data-driven results confirm a successful drive, the verification result is considered successful. This is the ideal verification result, indicating that the parameters perform well at both the physical and data-driven levels, meeting all preset rules and performance requirements. Verification is considered successful when the real-time physics-driven results do not violate any preset rules, and all performance indicators reflected by the data-driven results are within preset optimization thresholds. This means that the current parameter configuration is stable, efficient, and meets expectations. For example, the vehicle can operate stably under various operating conditions without abnormal physical phenomena, and performance indicators such as fuel economy, emissions, response speed, and driving comfort all meet or exceed target values.

[0153] In this embodiment, the parameter verification process considers not only data-driven results but also real-time physical-driven results based on real-time operating data for comprehensive judgment. This dual verification mechanism can more comprehensively and accurately evaluate the validity of parameters. Specifically, when the real-time physical-driven results show a violation of preset rules, serious defects in the parameters can be identified in a timely manner and determined to be invalid, thereby avoiding potential safety risks or system failures. When the physical drive passes but the data-driven results show that the performance indicators exceed preset thresholds, the optimization space of the parameters can be identified and determined to be optimized, providing a clear direction for subsequent parameter tuning. Only when both the physical drive and data-driven results perform well is the verification finally determined to be passed. This refined classification of verification results avoids the rough judgment of simple pass or fail in traditional verification methods, making the parameter verification results more instructive, helping to improve the quality of parameters and the overall performance of the system, and effectively reducing the iterative cost and risk of parameter tuning.

[0154] Based on the parameter verification method provided in the above embodiments, this application also provides specific implementation methods of the parameter verification device. Please refer to the following embodiments.

[0155] First see Figure 3 The parameter verification device 300 provided in this application embodiment may include:

[0156] The acquisition module 301 is used to acquire calibration parameter packages and real-time operating condition data in response to user-defined verification requirements.

[0157] The parsing module 302 is used to parse the calibration parameter package to obtain the operating condition requirements;

[0158] The determination module 303 is used to determine the verification strategy based on the working condition requirements and the preset working condition model matching relationship. The preset working condition model matching relationship is used to characterize different working conditions corresponding to different verification models, and the verification strategy is used to characterize the use of different verification models according to different working condition requirements.

[0159] The data-driven module 304 is used to perform data-driven operations based on a verification strategy and obtain data-driven results.

[0160] The verification module 305 is used to perform parameter verification based on data-driven results and real-time operating condition data, and obtain the verification results.

[0161] As an alternative implementation, the acquisition module 301 can also be used for:

[0162] In response to the user's defined verification requirements, extract the verification task document from the verification requirements;

[0163] Parameters are extracted from the verification task document to obtain multiple dynamic parameters;

[0164] The dynamic parameters are combined using a preset dynamic parameter template to obtain a calibration parameter package.

[0165] As an alternative implementation, the acquisition module 301 can also be used for:

[0166] The verification task document is preprocessed to obtain the standard task document;

[0167] Based on the standard task document, construct an initial graph structure, which includes multiple nodes;

[0168] Based on the preset structural entropy formula, the structural entropy of each node in the initial graph structure is determined. Structural entropy is commonly used to characterize the complexity and information content of a node in the initial graph structure.

[0169] A pre-defined graph neural network is used to rank the importance of multiple nodes, thus obtaining the node importance order;

[0170] Key nodes are obtained by filtering multiple nodes based on structural entropy, node importance order, and preset filtering conditions.

[0171] The initial graph structure is processed based on key nodes to obtain the final graph structure;

[0172] Based on the final graph structure, parameters from the verification task document are extracted to obtain multiple dynamic parameters.

[0173] As an alternative implementation, the acquisition module 301 can also be used for:

[0174] Data is extracted from the verification task document to obtain the constraints and parameter variables;

[0175] Based on the constraints and parameter variables, construct a constraint satisfaction problem;

[0176] Solve the constraint satisfaction problem to obtain the template structure and parameter list;

[0177] A preset dynamic parameter template is generated based on the template structure and parameter list using a preset time series detection algorithm.

[0178] As an alternative implementation, the determining module 303 can also be used for:

[0179] Extract at least one working condition feature based on the working condition requirements;

[0180] The working condition features are matched with the preset working condition model matching relationship to obtain the verification model identifier corresponding to at least one working condition feature. The preset working condition model matching relationship includes the correspondence between multiple working condition features and verification model identifiers.

[0181] The corresponding verification model is determined based on the matched verification model identifier;

[0182] Based on the verification model and operating conditions, a verification strategy is generated, which includes the verification model, verification parameters, and verification process.

[0183] As an alternative implementation, the determining module 303 can also be used for:

[0184] Obtain historical operating condition data and corresponding verification model usage records;

[0185] Feature extraction is performed on historical operating condition data to obtain historical operating condition features;

[0186] Based on historical operating condition characteristics and corresponding verification model usage records, a classification model is trained to obtain the preset operating condition model matching relationship.

[0187] As an alternative implementation, the verification module 305 can also be used for:

[0188] Based on real-time operating data, determine the real-time physical drive results;

[0189] If the real-time physics-driven result determines that the preset rule is violated, the verification result determines that the parameter is invalid;

[0190] If the real-time physics-driven result indicates that the drive has passed, and the data-driven result indicates that the preset performance index exceeds the preset threshold, the verification result indicates that the parameters need to be optimized.

[0191] If both the real-time physical drive result and the data drive result are determined to be driving successfully, the verification result is determined to be verification successful.

[0192] Figure 4 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0193] An electronic device may include a processor 401 and a memory 402 storing computer program instructions.

[0194] Specifically, the processor 401 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0195] Memory 402 may include mass storage for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 402 may include removable or non-removable (or fixed) media, or memory 402 may be non-volatile solid-state memory. Memory 402 may be internal or external to the integrated gateway disaster recovery device.

[0196] In one instance, memory 402 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0197] Memory 402 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the parameter verification method according to the first aspect of this disclosure.

[0198] The processor 401 reads and executes computer program instructions stored in the memory 402 to achieve... Figure 1 A parameter verification method is shown in the embodiment.

[0199] In one example, the electronic device may also include a communication interface 403 and a bus 404. For example, Figure 4 As shown, the processor 401, memory 402, and communication interface 403 are connected through bus 404 and complete communication with each other.

[0200] The communication interface 403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0201] Bus 404 includes hardware, software, or both, that couples components of an electronic device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 404 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0202] The electronic device can execute the parameter verification method in the embodiments of this application, thereby achieving the combination Figures 1-4The described parameter verification method and apparatus.

[0203] Furthermore, in conjunction with the parameter verification methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the parameter verification methods in the above embodiments.

[0204] In an optional embodiment, in conjunction with the parameter verification methods in the above embodiments, this application embodiment can provide a computer program product to implement the method. The instructions in the computer program product are executed by the processor of the electronic device, enabling the electronic device to implement any of the parameter verification methods in the above embodiments.

[0205] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0206] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0207] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0208] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0209] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A parameter verification method, characterized in that, include: In response to user-defined verification requirements, obtain calibration parameter packages and real-time operating condition data; The calibration parameter package is parsed to obtain the operating condition requirements; Based on the working condition requirements and the matching relationship of the preset working condition model, a verification strategy is determined. The preset working condition model matching relationship is used to represent that different working conditions correspond to different verification models. The verification strategy is used to represent that different verification models are adopted according to different working condition requirements. Data-driven results are obtained based on the aforementioned verification strategy. Based on the data-driven results and the real-time operating condition data, parameter verification is performed to obtain the verification results. The acquisition of the calibration parameter package includes: In response to the user-defined verification requirements, a verification task document is extracted from the verification requirements; Parameters are extracted from the verification task document to obtain multiple dynamic parameters; The dynamic parameters are combined using a preset dynamic parameter template to obtain a calibration parameter package; The parameter verification based on the data-driven results and the real-time operating condition data, to obtain the verification results, includes: Based on the real-time operating data, the real-time physical drive result is determined; If the real-time physics-driven result is determined to be a violation of a preset rule, the verification result is determined to be an invalid parameter; If the real-time physical drive result is determined to be a pass and the data drive result is determined to be a preset performance indicator exceeding a preset threshold, the verification result is determined to be a parameter that needs to be optimized. If both the real-time physical drive result and the data drive result are determined to be driving successfully, the verification result is determined to be verification successful.

2. The method according to claim 1, characterized in that, The method further includes extracting parameters from the verification task document to obtain multiple dynamic parameters. The verification task document is preprocessed to obtain a standard task document; Based on the standard task document, an initial graph structure is constructed, which includes multiple nodes; Based on a preset structural entropy formula, the structural entropy of each node in the initial graph structure is determined. The structural entropy is used to characterize the complexity and information content of the node in the initial graph structure. The importance of the multiple nodes is ranked using a preset graph neural network to obtain the node importance order; Based on the structural entropy, the order of node importance, and preset filtering conditions, the multiple nodes are filtered to obtain key nodes; The initial graph structure is processed based on the key nodes to obtain the final graph structure; Based on the final graph structure, parameters of the verification task document are extracted to obtain multiple dynamic parameters.

3. The method according to claim 1, characterized in that, Before combining the dynamic parameters using a preset dynamic parameter template to obtain the calibration parameter package, the method further includes: Data is extracted from the verification task document to obtain the constraints and parameter variables; Based on the constraints and parameter variables, construct the constraint satisfaction problem; Solve the constraint satisfaction problem to obtain the template structure and parameter list; A preset dynamic parameter template is generated based on the template structure and parameter list using a preset time series detection algorithm.

4. The method according to claim 1, characterized in that, Before determining the verification strategy based on the matching relationship between the operating condition requirements and the preset operating condition model, the method further includes: Based on the aforementioned operating condition requirements, extract at least one operating condition feature; The operating condition features are matched with a preset operating condition model matching relationship to obtain a verification model identifier corresponding to at least one operating condition feature. The preset operating condition model matching relationship includes the correspondence between multiple operating condition features and verification model identifiers. The corresponding verification model is determined based on the matched verification model identifier; Based on the verification model and the operating conditions, a verification strategy is generated, which includes a verification model, verification parameters, and a verification process.

5. The method according to claim 4, characterized in that, Before matching the operating condition features with the preset operating condition model matching relationship to obtain the verification model identifier corresponding to the at least one operating condition feature, the method further includes: Obtain historical operating condition data and corresponding verification model usage records; Feature extraction is performed on the historical operating condition data to obtain historical operating condition features; Based on the historical operating condition features and the corresponding verification model usage records, a classification model is trained to obtain the matching relationship of the preset operating condition model.

6. A parameter verification device, characterized in that, The device includes: The acquisition module is used to acquire calibration parameter packages and real-time operating condition data in response to user-defined verification requirements. The parsing module is used to parse the calibration parameter package to obtain the operating condition requirements; The determination module is used to determine the verification strategy based on the working condition requirements and the preset working condition model matching relationship. The preset working condition model matching relationship is used to characterize that different working conditions correspond to different verification models, and the verification strategy is used to characterize that different verification models are adopted according to different working condition requirements. The data-driven module is used to perform data-driven operations based on the verification strategy and obtain data-driven results. The verification module is used to perform parameter verification based on the data-driven results and the real-time operating condition data, and obtain the verification results. The acquisition module is also used for: In response to the user-defined verification requirements, a verification task document is extracted from the verification requirements; Parameters are extracted from the verification task document to obtain multiple dynamic parameters; The dynamic parameters are combined using a preset dynamic parameter template to obtain a calibration parameter package; The verification module is also used for: Based on the real-time operating data, the real-time physical drive result is determined; If the real-time physics-driven result is determined to be a violation of a preset rule, the verification result is determined to be an invalid parameter; If the real-time physical drive result is determined to be a pass and the data drive result is determined to be a preset performance indicator exceeding a preset threshold, the verification result is determined to be a parameter that needs to be optimized. If both the real-time physical drive result and the data drive result are determined to be driving successfully, the verification result is determined to be verification successful.

7. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the parameter verification method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the parameter verification method as described in any one of claims 1-5.

Images