Civil aircraft phm full-element screening method based on configuration input

Abstract

The application provides a civil aircraft PHM full-element screening method based on configuration input, relates to the field of civil aircraft prediction and health management, and comprises the following steps: S1: performing hierarchical decomposition, parameter extraction, standardized mapping and constraint number binding on initial configuration input; S2: matching core operation scenes that should be covered by the configuration characteristics; S3: completing PHM function matching, priority sorting and compliance checking; S4: completing exclusive subgraph locking on a basic knowledge graph library; S5: generating constraints of PHM data requirements; and S6: editing, rule checking and version management are performed on an operation scene list, a PHM function list and a PHM data requirement model. The application takes civil aircraft configuration as a core constraint, takes a civil aircraft PHM knowledge graph as a deterministic knowledge carrier, and realizes configuration analysis, scene matching, PHM function generation and data requirement output by combining constrained semantic analysis, rule checking and graph calculation path searching.

Description

Technical Field

[0001] This invention relates to the field of predictive and health management technology for civil aircraft, specifically to the field of intelligent generation technology of data requirements in the full life cycle design of civil aircraft PHM systems, and particularly to a method for screening all elements of civil aircraft PHM based on configuration input. Background Technology

[0002] Predictive Fault and Health Management (PHM) is a core technology for ensuring flight safety, reducing maintenance costs, and meeting civil aviation airworthiness requirements in civil aircraft. PHM data requirement design is the source and core foundation for the entire lifecycle construction of a civil aircraft PHM system. Its design quality directly determines the PHM system's fault detection capabilities, health assessment accuracy, and engineering application effectiveness. It emphasizes state awareness in asset and equipment management, monitoring equipment health status, fault-prone areas and cycles, and predicting fault occurrences through data monitoring and analysis, thereby improving maintenance efficiency. As the complexity of civil aircraft systems continues to increase, the industry is placing higher demands on the efficiency, matching accuracy, and compliance of PHM data requirement design.

[0003] In existing designs, the design of PHM data requirements for civil aircraft is mainly based on a manual mode led by senior experts. The manual mode has the advantages of being able to meet the airworthiness and safety requirements of civil aircraft, balance data collection costs and airborne resource constraints, and adapt to the operation and maintenance needs of civil aircraft throughout their entire life cycle. It is widely used in the current civil aircraft field.

[0004] However, the manual mode also has the following engineering and technical problems: First, the design process is highly dependent on expert experience, the talent training cycle is long, the manual design is inefficient and prone to omissions of requirements; Second, the existing rule-based matching scheme usually requires manual step-by-step selection of operating scenarios, PHM functions and data requirements, which makes it difficult to form a design process continuously driven by configuration constraints and has insufficient adaptability to new configurations and scenarios; Third, the existing general intelligent generation scheme lacks deterministic knowledge, airworthiness basis and engineering rule constraints in the civil aircraft field, which may lead to uncertain output results, incomplete basis or untraceable process, making it difficult to meet the requirements of civil aircraft PHM design data archiving and airworthiness compliance analysis. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention aims to provide a full-element screening method for civil aircraft PHM based on configuration input. This method solves the engineering problems in existing civil aircraft PHM data requirement design technologies, such as high reliance on domain expert experience, the need for manual matching of operating scenarios and PHM functions, low matching degree between civil aircraft configurations and PHM requirements, and weak adaptability to new configurations. The invention provides a screening scheme that uses user-inputted civil aircraft configuration information as initial configuration input and core constraints to automatically generate a full lifecycle operating scenario list, a standardized PHM function list, and a PHM data requirement model matching the configuration. This improves the efficiency of civil aircraft PHM system design, the traceability of airworthiness criteria, and engineering adaptability.

[0006] Specifically, this invention provides a full-element screening method for the PHM (Profile Management Model) of civil aircraft based on configuration input, which includes the following steps: S1: Receive civil configuration information as initial configuration input, perform hierarchical decomposition, parameter extraction, standardization mapping and constraint number binding on the initial configuration input, and output standard configuration features; S2: Based on the output of S1, match the core operating scenarios that the configuration feature should cover, and output a standardized list of operating scenarios, a set of scenario constraint parameters, and scenario priority results; S3: Taking the outputs of S1 and S2 as input, complete PHM function matching, priority sorting and compliance verification, and output the PHM function list matching the target configuration, function priority results and function coverage verification results; S4: Taking the output results of S1 to S3 as input, complete the exclusive subgraph locking, missing content completion and dynamic incremental update of the basic knowledge graph library, and output the verified exclusive knowledge subgraph. S5: Generate constraints for PHM data requirements, and output a standardized data requirement list, parameter configuration results, and supporting records; S51: Extract the output results from S1 to S4, complete multi-path recall by cosine similarity calculation, and output the initial candidate data requirement item set; S52: Based on the output of S51, perform path filtering and candidate path solving on the dedicated knowledge subgraph, and output the candidate path set and basic data requirement framework. S53: Taking the output of S52 as input, the method of combining gating verification, information support strength calculation and residual oversight risk minimization optimization is adopted to realize the constraint generation of PHM data requirements, and output the standardized PHM data requirement recommendation model, standardized data requirement list, parameter configuration results and their basis records. S6: Using the output of S5 as the object, edit, verify rules and manage versions of the running scenario list, PHM function list and PHM data requirement model, and output the reviewed full PHM solution.

[0007] Furthermore, it also includes S7: taking the output of S6 as input, it realizes the import and export function of the full PHM solution in XML format, and completes the standardized storage and cross-system data exchange of the running scenario list, PHM function list, and PHM data requirement model.

[0008] Furthermore: S1 includes the following steps: S11: Receive civil aircraft configuration information in any form, such as civil aircraft model, system / subsystem name, component list, configuration technical document, etc., input by the user; S12: Automatically decompose the input configuration information into a hierarchical structure at the whole machine level, system level, subsystem level, and component level, and extract the core feature parameters of each configuration node; S13: Standardize and match the disassembled configuration information with the full-level configuration library of civil aircraft, lock the civil aircraft configuration node corresponding to the current design as the core constraint, and at the same time complete the compliance verification of configuration parameters and the completion of missing information, and output standard configuration features. Standard configuration features include the standard configuration node set, configuration parameter set, and core constraint identifier.

[0009] Furthermore: S2 includes the following steps: S21: Based on the standard configuration features output by S1, automatically match the core operational scenarios that the configuration should cover from the civil aircraft full life cycle scenario library to form an initial scenario list; S22: Based on the configuration's design envelope, fault mode library, and historical operating data, generate special operating condition candidate scenarios for this configuration through restricted reasoning; S23: Calculate the matching degree of candidate scenes The process involves recalling, compressing, and initially ranking candidate scenarios. Scenarios below a preset screening threshold and not belonging to mandatory coverage scenarios are eliminated or transferred for manual confirmation. The remaining scenarios are arranged in descending order of matching degree, forming a candidate scenario set. (The text then abruptly shifts to a different topic: the matching degree of candidate scenarios.) The calculation method is as follows: ; in, This indicates the target civil system type output by S1. This represents the i-th candidate running scenario; Indicates configuration level matching item, This indicates items covered during the flight or maintenance phase. Indicates the scenario-related fault mode coverage items. This indicates an airworthiness or engineering basis binding item; , , and The values ​​of all values ​​are in the range [0,1]; weight , , and Based on the system security level and design phase, preset or configured; when Furthermore, when this scenario involves safety-critical components, the scenario... Enter the manual confirmation queue; Based on the established airworthiness specifications and system design standards, the system performs operational condition coverage verification and airworthiness basis binding verification on the candidate scenario set, and outputs a standardized operational scenario list and constraint parameters.

[0010] Furthermore: S3 includes the following steps: S31: Based on the target configuration features output by S1 and the standardized operational scenario list output by S2, the standardized mapping relationship between configuration, scenario and function in the civil aircraft PHM knowledge graph is invoked to complete the automatic matching of core functional requirements and form an initial PHM function list. S32: Calculate PHM function priority A list of candidate functions is generated and categorized. Functions reaching the first set threshold are marked as mandatory core functions, functions reaching the second set threshold but not the first threshold are marked as optional extended functions, and functions below the second threshold are eliminated or transferred for manual confirmation. PHM function priority is established. The calculation method is as follows: ; in, Indicates the configuration-function mapping strength. Indicates the set of selected scenes The trigger strength of this function Indicates the security level of associated components. Indicates whether the function is tied to airworthiness or engineering criteria; weight. , , and Pre-set or configured according to the system security level and design phase; Based on the scenario coverage and system adaptability of the civil aircraft airworthiness specification verification function list, it is used to check the functional coverage of safety-critical systems and output a standardized PHM function list.

[0011] Furthermore: S4 includes the following steps: S41: Based on the civil aircraft configuration features output by S1, the standardized operation scenario list output by S2, and the PHM function list output by S3, the civil aircraft PHM knowledge graph is invoked to extract the six-dimensional standardized relationships of civil aircraft configuration, operation scenario, PHM function, failure mode, data requirements, and airworthiness constraints, forming a unique knowledge subgraph. S42: Based on the exclusive knowledge subgraph formed by S41 and the configuration, scenario and functional constraints of this design, complete the entity and relationship retrieval within the exclusive knowledge subgraph, identify uncovered missing entities, missing relationships or missing evidence, and trigger the graph content completion process; S43: Through a restricted reasoning module adapted for the civil aircraft field, based on preset engineering specifications and airworthiness standards, generate candidate tuples q for missing content, and perform verification before the candidate tuples q enter the knowledge graph; S44: Perform a dual-track compliance check on the completed content. After automated rule verification and manual confirmation, complete the dynamic incremental update of the knowledge graph.

[0012] Furthermore: In S43, the verification method for candidate tuple q is as follows: ; in, This indicates entity type validity verification. This indicates the validation of the relationship validity. This indicates that the integrity of the source is verified. This indicates that the airworthiness terms are bound for verification. Indicates repeatability and conflict checks; , , , and All are binary check items, with values ​​of 0 or 1; This represents the comprehensive legality gating check result of candidate tuple q before it enters the knowledge graph. At that time, candidate tuples Returned to the manual confirmation queue; when At that time, candidate tuples pass the basic legality check before entering the knowledge graph.

[0013] Furthermore, in S52, the methods for performing path filtering and candidate path solving include: constructing and solving for complete paths on a dedicated knowledge subgraph. ; ; in, This represents a complete path that starts from the configuration node, passes through the scenario node, PHM function node, fault mode node, data requirement node, and ends at the airworthiness basis node. , , , , and These are graph nodes representing configuration nodes, scenario nodes, PHM function nodes, failure mode nodes, data requirement nodes, and airworthiness basis nodes, respectively. Represents the total cost of the path. Represents the edges in the path The cost, This indicates that the required functions do not cover the penalty items. This indicates a penalty for missing airworthiness criteria. This indicates a penalty for duplicate data requirements; , The corresponding penalty item weights are configured based on the degree of safety criticality and the design phase; Paths that do not meet the set hard constraints are deleted. For paths that share the same monitoring parameters and can cover multiple failure modes at the same time, only the path with the minimum total cost is retained to enter the candidate result set. When a candidate path meets the hard constraints at the same time, the candidate path enters the candidate framework generation and combination optimization recommendation process. If the candidate path set after hard constraint filtering is empty, or if the coverage of any of the required core functions, high-risk failure modes, or key operating scenarios is lower than the corresponding threshold, a gap list is generated, including uncovered configuration nodes, scenario nodes, PHM function nodes, failure mode nodes, data requirement nodes, and basis gaps, and execution returns to steps S42 to S44.

[0014] Furthermore: In S53, the standardized PHM data requirement recommendation model is as follows: ; in, This represents the number of candidate data requirements to be optimized after candidate recall and constraint path construction. Indicates by A selection vector consisting of the selection variables for each candidate data requirement item; and Both represent indexes of candidate data requirement items, and , The range of values ​​is to ; This indicates the result of selecting the optimal data requirement item; Indicates the target configuration The number of PHM requirement units; Representing the demand unit Importance; Indicates candidate data requirement items For demand unit The strength of information support; Indicates candidate data requirement items The gating verification result is used when the candidate data requirement item passes the rule verification and its corresponding constraint path satisfies the hard constraints. ,otherwise ; Indicates candidate data requirement items and Redundancy correlation between them; Indicates candidate data requirement items The burden of data acquisition; This indicates the maximum allowed data acquisition burden; express The path cost corresponding to the constraint path; This represents the data acquisition burden penalty coefficient. This represents the path cost penalty coefficient.

[0015] Furthermore, S6 includes the following steps: Through a visual design canvas, using the standardized data requirement list, parameter configuration results, and basis records output by S5 as objects, users can edit, modify, manage versions, and optimize solutions under rule constraints; when users modify entities or relationships, the system simultaneously triggers rule verification, airworthiness basis binding verification, and version records; finally, the reviewed PHM full solution is output.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention takes the civil aircraft configuration as the core constraint input, uses the pre-deployed civil aircraft PHM knowledge graph as the deterministic knowledge carrier, and uses a dedicated functional processing unit as the execution core. It combines constrained semantic parsing, rule verification, and graph computation path search to realize configuration parsing, scene matching, PHM function generation, and data requirement output. Therefore, it has a strong adaptability to new configurations and new scenes. The semantic parsing and missing completion modules operate only within the preset interface, output fields, and graph boundaries. Their output is constrained by a dedicated knowledge subgraph, airworthiness clauses, and rule validation. Recommendation results are jointly determined by configuration constraint propagation, graph mapping, and rule validation. Therefore, the technical essence of this invention lies in triggering six-dimensional knowledge constraints with configuration input, and completing candidate recall, path solving, parameter completion, and basis binding within these constraints. It has a low dependence on expert experience, solving the pain points of low efficiency and easy omission of requirements in manual design, and avoiding problems of uncertain output results or untraceable processes. Attached Figure Description

[0017] Figure 1 The overall flowchart of the civil aircraft PHM full-element screening method based on configuration input provided by the present invention is shown in the figure. Detailed Implementation

[0018] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

[0019] This invention uses the civil aircraft configuration as the core constraint input, a pre-deployed civil aircraft PHM knowledge graph as the deterministic knowledge carrier, and a dedicated functional processing unit as the execution core. It combines constrained semantic parsing, rule verification, and graph computation path search to achieve configuration parsing, scene matching, PHM function generation, and data requirement output. The semantic parsing and missing information completion modules operate only within preset interfaces, output fields, and graph boundaries. Their output is jointly constrained by the dedicated knowledge subgraph, airworthiness clauses, and rule verification. The recommendation result is jointly determined by configuration constraint propagation, graph mapping, and rule verification. Therefore, the technical essence of this invention lies in triggering six-dimensional knowledge constraints with configuration input, and completing candidate recall, path solving, parameter completion, and basis binding within these constraints.

[0020] In the implementation method, the parsed target configuration and the civil aircraft PHM knowledge graph can be represented as follows: ; ; in, Indicates the hierarchy of whole machine / system / subsystem / component. Indicates the system category, Represents a collection of components. This indicates configuration parameters such as pressure, temperature, and operating stage. Indicates interface relationships; Represents a set of nodes. Denotes the set of edges. It represents the source, applicable boundary, weight, and verification status of the edge.

[0021] The recommendation process is limited to the subgraphs hit by C. Proceed. Any output data requirement d should satisfy the following constraints: ; in, For the operating scenario, For PHM function, This is a fault mode. For airworthiness or engineering purposes. If this constraint is missing, then the data requirement item... Only as a candidate for inclusion in the completion, binding, and verification process, and must not be included in the standardized data requirement list without verification; if the constraints are complete and meet the subsequent rule verification, path hard constraints, and airworthiness binding requirements, then the data requirement item can be included in the recommended set.

[0022] This invention uses the above constraints as the basic conditions for the acceptability of the recommendation results, so that each data requirement item can be traced back to the target configuration, triggering scenario, PHM function, failure mode and airworthiness or engineering basis, thereby forming an interpretable recommendation that is different from simple similar case retrieval or open generation results.

[0023] Based on the above constraints, the user input is first converged to the target configuration. , and by The exclusive knowledge subgraph of the hit Limiting the scope of candidate recall; operational scenarios PHM function Failure Mode Data requirements and basis Together, they constitute the acceptable boundary of data requirements. Candidates are only included in the subsequent ranking and recommendation process after they are complete, pass rule verification, and meet hard path constraints. The supplementary content after manual confirmation is incrementally written back to the knowledge graph in the form of source, version, and confirmation record for reuse and re-verification of similar configurations.

[0024] To achieve the above objectives, such as Figure 1 As shown, this invention provides a full-element recommendation method for civil aircraft PHM based on configuration input, and uses a pre-deployed civil aircraft PHM basic knowledge graph library as a deterministic knowledge foundation. This foundation pre-constructs six-dimensional standardized correlation relationships of civil aircraft configuration, operating scenarios, PHM functions, failure modes, data requirements, and airworthiness constraints, providing basic rules and knowledge support for the recommendation process. Specifically, it includes the following steps: S1: The configuration parsing processing unit receives the civil configuration information input by the user as the initial configuration input, performs hierarchical decomposition, parameter extraction, standardization mapping and constraint number binding on the initial configuration input, and outputs the standard configuration node set, configuration parameter set and core constraint identifier as the core constraint basis for the subsequent recommendation process. The standard configuration node set, configuration parameter set and core constraint identifier are used as the common input for S2 scene matching and S3 function generation.

[0025] The configuration analysis processing unit generates the target configuration constraint fingerprint after completing hierarchical decomposition and parameter extraction. . From configuration level System Category Component collection Configuration parameters Interface relationships The applicable scenario boundaries and airworthiness criteria are jointly encoded based on the binding status, used to distinguish between systems with the same name, similar configurations, and configuration variants at different design stages. Subsequent scenario matching, function generation, knowledge subgraph locking, and data requirement recommendation are all based on this. As a consistency verification identifier; if the configuration fingerprint corresponding to the candidate scenario, function, or data requirement item matches... If there is a discrepancy, the item should not be directly included in the recommendation set.

[0026] For the target configuration The derived consistency check identifier does not replace... The configuration hierarchy, component sets, parameter sets, and interface relationships within the target configuration. When changes occur, the system is regenerated. And relock The scenario list, PHM function list, and data requirement recommendation results that were already formed before the change are only retained as historical versions and must not be used without re-verification.

[0027] S1 specifically includes: S11 to S13 sequentially complete configuration input reception, hierarchical decomposition, and normalization locking; the output of S13 serves as the configuration constraint input for S2 and S3. S11: Receive civil aircraft configuration information in any form, such as civil aircraft model, system / subsystem name, component list, configuration technical document, etc., input by the user.

[0028] S12: Automatically decompose the input configuration information into a hierarchical structure at the whole machine level, system level, subsystem level, and component level, and extract the core feature parameters of each configuration node.

[0029] S13: Standardize and match the disassembled configuration information with the full-level configuration library of civil aircraft, lock the civil aircraft configuration node corresponding to the current design as the core constraint of the subsequent process, and complete the compliance verification of configuration parameters and the completion of missing information. Then output to S2 for scenario matching and output to S3 for function generation.

[0030] S2: Through the scenario matching processing unit, taking the standard configuration node set, configuration parameter set and core constraint identifier output by S1 as input, it completes the operation scenario matching, constraint parameter generation and airworthiness coverage verification, and outputs the standardized operation scenario list, scenario constraint parameter set and scenario priority result of matching target configuration, which serve as the scenario-side constraint input for S3's PHM function matching and S4's exclusive subgraph locking.

[0031] S2 specifically includes: S21 to S23 are all executed based on the target configuration locked by S1, and the standardized running scenario list and constraint parameters output by S23 are further passed to S3.

[0032] S21: Based on the locked civil aircraft configuration characteristics, automatically match the core operating scenarios that the configuration should cover from the civil aircraft full life cycle scenario library to form an initial scenario list.

[0033] S22: Based on the configuration's design envelope, fault mode library, and historical operating data, generate special operating condition candidate scenarios unique to this configuration through restricted reasoning; the completion object of this step is the operating scenario candidate, and the reasoning only calls the configuration parameters, fault modes, historical cases, and airworthiness clauses that match the target configuration in the basic knowledge graph, and does not use candidate content that is not bound to the source basis, and generates the corresponding scenario's environmental parameters, operating constraints, and scenario priority results.

[0034] S23: Based on the CCAR-25 airworthiness specifications and system design standards for civil aircraft, it performs operational condition coverage verification and airworthiness basis binding verification on the scenario list, reduces the risk of missing items in the operation scenarios of safety-critical systems, outputs a standardized operation scenario list and constraint parameters, and serves as the scenario input for S3 PHM function matching.

[0035] In one implementation, the matching degree of the candidate scene is calculated as follows: ; in, Indicates configuration level matching item, This indicates items covered during the flight or maintenance phase. Indicates the scenario-related fault mode coverage items. This indicates the airworthiness or engineering basis binding item. The values ​​for each of the above items range from [0,1]; weights... to Based on the system security level and design phase, preset or configured. When Furthermore, when this scenario involves safety-critical components, the scenario... Enter the manual confirmation queue instead of directly entering the standardized scenario list.

[0036] The scenario matching degree calculation mentioned above is used for the recall, compression, and preliminary ranking of candidate running scenarios, and is not an independent basis for data requirement items to enter the final recommendation set. Whether the candidate scenarios can support data requirement recommendations still needs to be re-verified in the subsequent dedicated knowledge subgraph path search, basis binding, rule verification, and combination optimization processes.

[0037] S3: Through the PHM function generation processing unit, taking the target configuration obtained from S1, the standardized operation scenario list output by S2, and the scenario constraint parameter set as input, it completes PHM function matching, priority sorting, and compliance verification, and outputs the PHM function list matching the target configuration, function priority results, and function coverage verification results, and uses them as the function-side constraint input for S4 knowledge graph calling and S5 data requirement recommendation.

[0038] S3 specifically includes: S31 forming functional candidates based on the target configuration of S1 and the scene output of S2; and S32 passing the verified functional results to S4. S31: Based on the target configuration output by S1 and the list of operating scenarios matched with S2, the standardized mapping relationship of "configuration-scenario-function" in the civil aircraft PHM knowledge graph is invoked to complete the automatic matching of core functional requirements and form an initial PHM function list.

[0039] S32: Based on configuration safety level and scenario monitoring priority, the function list is sorted by level. At the same time, the scenario coverage and system adaptability of the function list are verified based on civil aircraft airworthiness specifications. It is used to check the functional coverage of safety-critical systems, output a standardized PHM function list, and serve as the functional input for S4 exclusive knowledge subgraph locking and S5 requirement unit generation.

[0040] In one implementation, the priority of candidate PHM functions is calculated as follows: ; in, Indicates the configuration-function mapping strength. Indicates the set of selected scenes The trigger strength of this function Indicates the security level of associated components. This indicates whether the function is tied to airworthiness or engineering standards. The above weights... to Preset or configured according to the system security level and design phase. Functions that reach the first threshold are marked as mandatory core functions, while functions that reach the second threshold but not the first threshold are marked as optional extended functions.

[0041] The PHM function priority calculation described above is used for generating and hierarchically labeling the candidate function list, but does not directly determine the final recommended data requirement items. The final recommendation result is jointly determined by configuration constraint paths, gating verification, PHM requirement unit coverage, redundancy, and data acquisition burden.

[0042] S4: Through the knowledge graph invocation and dynamic update processing unit, taking the target configuration output by S1, the standardized operation scenario list output by S2, the PHM function list output by S3 and their verification results as input, it completes the exclusive subgraph locking, compliant completion of missing content and dynamic incremental update of the pre-deployed basic knowledge graph library. It outputs the verified exclusive knowledge subgraph, the completion candidate set and the update log, providing knowledge support within the target configuration and rule boundaries for subsequent data requirement generation. At the same time, it completes the compliance verification of the knowledge invocation process. The verified exclusive knowledge subgraph serves as the limited space for S5 candidate recall, constraint path search and combinatorial optimization.

[0043] S4 specifically includes: S41 to S44 take the output of S1 to S3 as input, first lock the exclusive knowledge subgraph, then perform restricted completion and verification on missing entities, relations and bases, and output the verified subgraph to S5.

[0044] S41: Based on the civil aircraft configuration locked by S1, the list of operating scenarios matched by S2, and the list of PHM functions generated by S3, the civil aircraft PHM knowledge graph is called to extract the six-dimensional standardized relationships of civil aircraft configuration, operating scenarios, PHM functions, failure modes, data requirements, and airworthiness constraints, forming a knowledge subgraph specific to this design.

[0045] The locking process of a dedicated knowledge subgraph is based on Using indexing criteria, nodes and edges that are inconsistent with configuration hierarchy, system category, component set, or interface relationship are first filtered out. Then, associated paths that satisfy airworthiness basis binding, scenario boundary, and functional coverage conditions are retained. This results in... It is not a simple subset of the basic knowledge graph, but a constrained recommendation space corresponding to configuration inputs, design phases, and airworthiness boundaries.

[0046] S42: Based on the exclusive knowledge subgraph formed by S41 and the configuration, scenario and functional constraints of this design, complete the entity and relationship retrieval within the exclusive knowledge subgraph, identify uncovered missing entities, missing relationships or missing evidence, and trigger the graph content completion process.

[0047] S43: Using a restricted inference module adapted for the civil aircraft domain, and based on preset engineering specifications and airworthiness standards, generate candidate tuples for missing content q=<entity type, entity name, attribute parameters, relationship, and source of evidence>. This step completes missing entities, relationships, and evidence in the dedicated knowledge subgraph. The inference template is only used to limit the calling interface, input fields, output format, and inference boundaries, and is not an independent basis for the candidate tuple generation conclusion. The generation scope, available entities, available relationships, source of evidence, and writable fields of the candidate tuples are all jointly limited by the dedicated knowledge subgraph, rule base, and airworthiness clauses. The entity type and relationship of the candidate tuple belong to... The default mode is based on the source pointing to knowledge graph entities, engineering cases, or airworthiness clauses. When a candidate tuple conflicts with a locked configuration boundary, applicable system level, or airworthiness basis binding relationship, the candidate tuple is only retained as a candidate to be confirmed and cannot be written into the knowledge graph or participate in S5's data requirement recommendation. The output of the validated candidate tuple is standardized structured content with clear reasoning basis, and reasoning logs are retained, including the knowledge graph entities called, the referenced airworthiness clauses, the matched engineering cases, and the reasoning templates, to support the retrospective lookup of the completion process.

[0048] Before a candidate tuple q enters the knowledge graph, the following verification is performed: ; in, This indicates entity type validity verification. This indicates the validation of the relationship validity. This indicates that the integrity of the source is verified. This indicates that the airworthiness terms are bound for verification. This indicates duplicate and conflict checks. (The above...) All are binary check items, with values ​​of 0 or 1; when any hour, candidate tuples Those returned to the manual confirmation queue are ineligible to participate in S5 data request recommendations; when When this occurs, it indicates that the candidate tuple has passed the basic legality check before entering the knowledge graph.

[0049] Candidate tuples returned to the manual verification queue retain their original input, hit subgraph, failed validation items, and basis gaps, but are not directly included in the recommendation calculation. Designers only verify or correct the basis source, applicable boundaries, and field values ​​of the candidate tuples; the verified content still needs to undergo a full set of validations again.

[0050] S44: Perform a dual-track compliance check on the completed content. After automated rule verification and manual confirmation, complete the dynamic incremental update of the knowledge graph. This dynamic incremental update does not directly overwrite the original knowledge graph, but rather includes at least five steps: temporary storage of candidate content, binding based on criteria, generation of version identifiers, manual confirmation and write-back, and subsequent recommendation and reuse. The incremental knowledge after write-back retains its source, version, applicable boundaries, and confirmation records, and participates again in retrieval, comparison, and verification during subsequent data requirement recommendation processes for similar configurations. The verified dedicated knowledge subgraph, completion candidate set, and update log output in this step are simultaneously used as input for data requirement recommendation in S5.

[0051] The conflict resolution process employs a tiered priority rule: airworthiness provisions and mandatory engineering specifications take precedence over enterprise design specifications; enterprise design specifications take precedence over verified engineering cases; and verified engineering cases take precedence over historical operational data and similar case recall results. Represents any candidate data requirement item. This indicates the rule verification result of the candidate. It is set to 1 when the parameter name, unit, sampling frequency, airworthiness basis binding and conflict verification all pass, otherwise it is set to 0.

[0052] S5: Through the data requirement recommendation processing unit, with the civil engineering model as the core constraint, and combining the scenario list automatically generated by S2, the PHM function list automatically generated by S3, and the dedicated knowledge subgraph output and verified by S4, a combined optimization method of candidate recall, constraint path search, gating verification, information support strength calculation, and residual oversight risk minimization is adopted to generate constraints for PHM data requirements. A standardized data requirement list, parameter configuration results, and their supporting records are output, serving as the objects for S6 visualization review and S7 scheme exchange. The candidate recall process is limited to the scope of the dedicated knowledge subgraph. The recall objects include nodes, edges, rule items, and airworthiness criteria. The recall results only serve as intermediate inputs for path filtering, conflict verification, and criterion completion, and are not directly used as output conclusions.

[0053] S5 specifically includes: S51 generating an initial candidate set within the scope of the dedicated knowledge subgraph output by S4; S52 performing path hard constraint filtering on the candidate set; and S53 performing parameter completion and combination optimization based on the filtering results.

[0054] S51: Extract the constraints such as target configuration, scenario, PHM function, failure mode and airworthiness basis formed by S1 to S4 and complete the vectorization representation. Perform multi-path recall through cosine similarity calculation to form an initial candidate data requirement set with high matching degree, and input the set into S52 for constraint path search.

[0055] In one implementation, instead of directly performing a simple weighted sort on individual candidate data requirements, the system first sorts the target configuration. The PHM design goals are represented as several PHM requirement units. Each PHM requirement unit consists of the operating scenario, PHM function, failure mode, and supporting requirements. ; in, Indicates the first The operational scenarios corresponding to each demand unit This indicates the corresponding PHM function. Indicates the corresponding fault mode. This indicates the airworthiness or engineering basis that this requirement unit should be linked to. (Requirement Unit) The importance is determined by the scenario importance, PHM function importance, failure mode severity, configuration triggering factor, and the requirements: ; in, Indicates the importance of the runtime scenario. Indicates the importance of PHM functions. Indicates the severity of the failure mode. Representing the demand unit In the target configuration The configuration triggering coefficient, This indicates that the binding requirements are being followed. All of the above parameters are limited to the target configuration. The exclusive knowledge subgraph of the hit Generated within the scope of the rule base and airworthiness criteria. or If the requirement unit is not met, it cannot be used as a standard recommendation and will only enter the confirmation or supplementation process.

[0056] In one implementation, constraints such as target configuration, scenario, PHM function, failure mode, and airworthiness criteria are encoded into recall vectors and multiplexed recall is performed. The recall vectors are only used for candidate set compression and do not replace subsequent constraint path search and combinatorial optimization solutions. ; ; in, Represents the configuration parameter vector. Represents the scenario constraint vector. Represents the PHM function vector. Represents the fault mode vector. Indicates the airworthiness basis vector; , , , , These represent the candidate data requirement items respectively. Similarity score in the corresponding dimension. to The corresponding dimension weights can be configured according to the system security level, design stage, and data completeness, and can be normalized to ensure that their sum is 1.

[0057] when Below the screening threshold At that time, candidate data requirements Eliminated when candidates involve safety-critical components and If the candidate is invalid, it is directly determined as an invalid candidate; the selected candidates form an initial candidate set and enter the constraint path search process of S52.

[0058] The above Used only from a dedicated knowledge subgraph The initial candidate data requirements are recalled and the candidate set is compressed. Candidates that pass the similarity screening still need to be processed. The optimization process includes gating verification, constraint path search, and minimizing residual oversight risk. Candidates with high similarity but lacking supporting evidence, inconsistent configurations, or unmet hard path constraints are excluded from the final recommendation set.

[0059] For the target configuration Candidate data requirements below and PHM demand unit The system further establishes information support relationships between data requirement items and requirement units. These relationships include at least configuration constraints, scenario applicability, functional adaptability, fault mechanism sensitivity, reliability, and timeliness contribution. ; in, Indicates candidate data requirement items Does it meet the target configuration? Configuration constraints, express In the running scenario Applicability to various scenarios express PHM function Functionality compatibility express Failure modes Mechanism sensitivity express Support demand unit Based on credibility, express Support demand unit The contribution to timeliness. All the above parameters are values ​​in the range of 0 to 1.

[0060] To avoid insufficient discrimination of ordinary product indicators in high support intervals, the system will Transformed into information support strength: ; in, Indicates candidate data requirement items For demand unit Information support strength To prevent abnormally small positive numbers in logarithmic operations. When any critical constraint term is 0, When the configuration adaptation, scenario applicability, functional adaptation, fault mechanism sensitivity, reliability of basis and timeliness contribution are all high, the information support strength increases nonlinearly.

[0061] S52: Aiming to meet PHM functionality, scenario constraints, and airworthiness requirements, and to reduce redundant monitoring parameters, path filtering and candidate path solving are performed on a dedicated knowledge subgraph based on the initial set of candidate data requirements formed in S51. The reason for using a six-layer directed graph is that configuration, scenario, function, failure mode, data requirements, and airworthiness criteria correspond to different semantic levels. Using a hierarchical path solving method can avoid the path incomprehensibility problem caused by directly mixing constraints at different levels.

[0062] ; ; in, This represents a complete path that starts from the configuration node, passes through the scenario node, PHM function node, fault mode node, data requirement node, and ends at the airworthiness basis node. , , , , and These represent the six types of graph nodes mentioned above, distinct from those in the recall vector. , , , and When this path corresponds to a candidate data requirement item When, recorded as . Represents the total cost of the path. Represents the edges in the path The cost, This indicates that the required functions do not cover the penalty items. This indicates a penalty for missing airworthiness criteria. This indicates a penalty for duplicate data requirements; to The corresponding penalty weights can be configured based on the degree of safety criticality and the design phase.

[0063] Before solving, delete paths that do not meet the hard constraints. Hard constraints must include at least: mandatory core function coverage must be no less than a threshold. The paths corresponding to safety-critical components should meet the following requirements. The number of repeated data collection items for the same physical parameter does not exceed the threshold. High-risk failure mode set The coverage rate is not lower than the threshold. Key operational scenario set The coverage rate is not lower than the threshold. For paths that share the same monitoring parameters and can simultaneously cover multiple failure modes, only paths with lower total costs are retained in the candidate result set.

[0064] in, Indicates the airworthiness or engineering basis binding status. This represents the set of high-risk failure modes. This represents a set of key operational scenarios.

[0065] The above path hard constraint verification results are denoted as When candidate paths When all the above hard constraints are met simultaneously The value is 1; when any of the above conditions are not met, If the value is 0, the candidate path must not enter the candidate framework generation and combination optimization recommendation process.

[0066] If the candidate path set after hard constraint screening is empty, or if the coverage of any of the required core functions, high-risk failure modes, or key operating scenarios is lower than the corresponding threshold, the system will not use similar cases to forcibly fill in the recommended results. Instead, it will generate a gap list, which will include at least the uncovered configuration nodes, scenario nodes, PHM function nodes, failure mode nodes, data requirement nodes, and basis gaps, and trigger the missing content identification, limited completion, and manual confirmation process in S42 to S44.

[0067] S53: Through the constrained parameter completion and basis completion module, taking the candidate path set and basic data requirement framework output by S52 as input, it recalls the corresponding engineering design specifications, fault handling experience and parameter configuration rules, and performs parameter completion, redundancy trimming and basis completion on the basic framework; the completed sampling frequency, accuracy and judgment basis are used as fields to be verified. After passing the rule verification, a candidate model of data requirement to be optimized is first formed, and then combined with the information support strength, gating verification results, data acquisition burden and redundancy relevance to perform combinatorial optimization, forming the final standardized PHM data requirement recommendation model, and outputting it to S6 for visualization verification.

[0068] In one implementation, the inputs to the constrained parameter completion and basis completion modules are limited to: the basic data requirement framework output by S52, the associated nodes and edges in the dedicated knowledge subgraph corresponding to the target configuration, the verified engineering rules, and the bound airworthiness criteria; its output is limited to sampling frequency, sampling accuracy, parameter upper and lower limits, judgment basis completion text, and redundancy pruning suggestions. Rule verification includes at least parameter name validity verification, parameter unit consistency verification, sampling frequency and component dynamic characteristic matching verification, airworthiness criterion binding verification, and conflict verification with existing mandatory data requirement items. If the generated result contains monitoring parameters that do not appear in the dedicated knowledge subgraph, or deletes data requirement items corresponding to mandatory core functions, the output is directly determined to be invalid and returned to the manual confirmation queue. After passing the rule verification, the completion result is written into the basic data requirement framework as a candidate input for subsequent combination optimization.

[0069] Unlike calculating recommendation scores for individual candidates, this step optimizes the set of candidate data requirements. The goal is to select a set of data requirements that minimizes the risk of remaining oversights, while satisfying constraints such as gating verification, key requirement coverage, and data acquisition burden. After completing candidate path search, gating verification, and information support strength calculation, the system transforms the data requirement recommendations into a target configuration. The problem of minimizing residual oversight risk. Residual oversight risk refers to the risk that PHM demand units, even after being supported by the current selected data demand set, will not be effectively observed, diagnosed, or predicted. Let... Candidate data requirement items The choice variable, when When it indicates that the data requirement item is recommended, when A time interval indicates that a recommendation is not recommended. The recommendation set is determined using the following optimization model: ; in, This represents the number of candidate data requirements to be optimized after candidate recall and constraint path construction. Indicates by A selection vector consisting of the selection variables for each candidate data requirement item; and Both represent indexes of candidate data requirement items, and , The range of values ​​is to . This indicates the result of selecting the optimal data requirement item; Indicates the target configuration The number of PHM requirement units; Representing the demand unit Importance; Indicates candidate data requirement items For demand unit The strength of information support; Indicates candidate data requirement items The gating verification result is used when the candidate data requirement item passes the rule verification and its corresponding constraint path satisfies the hard constraints. ,otherwise ; Indicates candidate data requirement items and Redundancy correlation between them; Indicates candidate data requirement items The burden of data acquisition; This indicates the maximum allowed data acquisition burden; express The path cost corresponding to the constraint path; This represents the data acquisition burden penalty coefficient. This represents the path cost penalty coefficient.

[0070] The first term in the above optimization model represents the target configuration. The remaining risk of oversight for each PHM demand unit is calculated. When a demand unit lacks effective data demand items, the corresponding exponential term is large, indicating that the demand still has a high risk of oversight. As the information support strength of the selected data demand items for the demand unit increases, the remaining risk of oversight for the demand unit decreases exponentially. The redundancy correction term in the denominator is used to reduce the support contribution of each candidate data demand item, avoiding highly relevant data demand items from being repeatedly included in effective support. The second term is used to control the data acquisition burden, and the third term is used to control the constraint path cost.

[0071] The above optimization model must satisfy at least the following constraints: ; ; ; The first constraint states that data requirements that fail the gating check cannot be recommended; the second constraint states that the data acquisition burden of the recommended set cannot exceed the allowed upper limit; and the third constraint states that key PHM requirement units must reach the minimum coverage threshold. Indicates the first Minimum coverage threshold for each key PHM requirement unit This represents the set of key PHM requirement units.

[0072] The above-mentioned combinatorial optimization model can be solved using integer programming, greedy initialization combined with branch and bound, or heuristic iterative search when the candidate size is large; the solution process always maintains The candidate options are not selectable. The final recommended data requirement set is as follows: .

[0073] In one implementation, for data requirement items already selected by the residual oversight risk minimization model, a recommendation score can be further calculated for display purposes, used for sorting, interpretation, and manual review in the visualization design canvas; this score is not used as the basis for generating the final recommendation set. ; The above formula This is only used to display recommendation priority, sorting criteria, and human confirmation order; it does not change the... A defined set of recommendations is required, and those that do not pass are not allowed. The data requirements for gating verification are included in the recommendation results. Among them, Indicates candidate data requirement items In the target configuration The displayed score; , , , , and These represent configuration matching degree, scenario priority, functional priority, airworthiness basis binding completeness, constraint path cost, and candidate redundancy, respectively. , , , , and This determines the ranking weight for the corresponding metric. This display score is only used for... The selected set of recommendations is displayed, sorted, and explained.

[0074] Threshold and weight configurations should not be used as independent recommendations detached from configuration constraints. , , , and The parameter configuration identifier is determined by the edge attributes of the configuration knowledge graph, data resource metadata, PHM function template, historical model reuse records, and expert configuration records, forming a traceable identifier. When the user adjusts the threshold or weight, the system re-executes the combinatorial optimization within the candidate set that has passed the gating verification, and does not allow candidates that have not passed the gating verification to enter the recommendation set.

[0075] S6: Through a visual design canvas, using the standardized data requirement list, parameter configuration results, and basis records output by S5 as objects, users can perform secondary editing, rule verification, and version management on the automatically generated running scenario list, PHM function list, and PHM data requirement model, and transfer the reviewed PHM solution to S7 for storage and exchange.

[0076] S6 specifically includes: receiving the recommended model and its basis records output by S5, and using the user-confirmed or adjusted version as the scheme object for import and export in S7.

[0077] The visual design canvas is based on the civil aircraft topology, showing the relationships between civil aircraft components, operating scenarios, PHM functions, and monitoring parameters. It also provides a structured editing interface, supporting users to edit, modify, manage versions, and optimize solutions under rule constraints. When users modify entities or relationships, the system simultaneously triggers rule verification, airworthiness basis binding verification, and version recording.

[0078] The recommendation results should simultaneously display, on the visualization design canvas, at least the recommendation source path, PHM demand unit coverage relationship, information support strength, remaining oversight risk reduction, recommendation score for display, gating verification results, redundancy correction reasons, data acquisition burden, and basis status. When a user adjusts a monitoring parameter or deletes a candidate, the system recalculates the affected path based on the adjustment. , , and The verification result is then saved as part of the version record.

[0079] When a user modifies the configuration hierarchy, component collection, interface relationship, or airworthiness basis binding status in the visual design canvas, the system recognizes the modification as the target configuration. The change, and trigger and The system regenerates the data; when the user only adjusts the sampling frequency, sampling precision, or display order, the system retains the original data. and re-execute the affected data requirement items. , , and Review.

[0080] S7: Taking the PHM full solution reviewed by S6 as input, implement the import and export function of the PHM full solution in XML format, and complete the standardized storage and cross-system data exchange of the running scenario list, PHM function list, and PHM data requirement model.

[0081] S7 specifically includes: taking the PHM full scheme reviewed by S6 as the exported object, and returning to the current configuration constraints to perform consistency verification when importing and reusing.

[0082] S71: Export the entire PHM solution generated under constraints as a standard XML format file. Before exporting, complete format verification, data integrity verification, airworthiness basis binding verification, and engineering rule consistency verification. The exported file meets the preset civil aircraft PHM data exchange format requirements.

[0083] S72: Supports the import, parsing, and reuse of XML format scheme files, and automatically performs file format verification and data integrity checks during import.

[0084] S73: Perform configuration consistency re-verification on the imported scheme; the system converts the data requirement items in the imported XML into a candidate set, and uses the current target configuration. Re-execute configuration level matching and airworthiness basis binding. Checksum Verification. Data requirements in the imported file that are inconsistent with the current configuration stress level, component level, scene boundary, or airworthiness basis must not be reused directly and should only be entered into the manual verification queue as candidates for confirmation.

[0085] S74: The exported XML file can be connected to the civil aircraft PHM system design platform, airborne health management system, and ground maintenance management system through standardized interfaces to achieve cross-system data interaction and engineering data docking.

[0086] In addition to recording the target configuration, scenario list, PHM feature list, and data requirement model, the exported file also records the source path corresponding to each data requirement item. Gating verification results Information support strength The PHM demand units covered Optimize the selection of variables The system incorporates redundancy correlation, data acquisition burden, status, version identifier, and manual confirmation status to ensure that import and reuse processes are reviewed according to the same constraint optimization logic.

[0087] The following describes the implementation method using the PHM (Prognostics and Management) full-element intelligent design of a civil aircraft hydraulic system as an example. In this embodiment, each step is executed sequentially in the order of configuration analysis, scene generation, function generation, dedicated knowledge subgraph locking, data requirement recommendation, canvas verification, and XML exchange. The output of the previous processing unit is used as the input constraint for the next processing unit.

[0088] Example In this embodiment, the aforementioned recall vectors correspond one-to-one with specific objects in the hydraulic system: It consists of configuration information including hydraulic system, 3000psi working pressure, power source subsystem, control subsystem, and execution subsystem. It consists of scenario information including pre-flight checks, climb phase, cruise phase, descent and landing, and ground maintenance. It consists of functional items such as overall health status assessment of the hydraulic system and health assessment of hydraulic pump operating efficiency. The failure modes consist of hydraulic pump wear, overflow valve sticking, and hydraulic oil leakage. It consists of CCAR-25.1309, CCAR-25.1301 and the corresponding engineering rules.

[0089] S1: Through the configuration analysis processing unit, the hydraulic system configuration is disassembled, standardized, mapped, and the core constraints are locked.

[0090] This step uses the target configuration information input by the user as the initial configuration input. The processing unit completes the configuration node identification, parameter extraction and constraint binding, providing core constraints for subsequent scene matching and function generation. The target configuration of the hydraulic system and the configuration constraint fingerprint are output to S2 and S3.

[0091] S11: Receive multi-configuration input: Users can input hydraulic system configuration information through the system input interface (supporting multiple input formats; this embodiment uses a combination of hydraulic system technical document fragments and component lists for input). Specific input content includes: hydraulic system, including core components such as power source subsystem (hydraulic pump, hydraulic motor), control subsystem (relief valve, throttle valve), and actuation subsystem (hydraulic cylinder), with a working pressure of 3000psi, suitable for all flight phases including takeoff, cruise, and landing.

[0092] S12: Automatic Decomposition and Feature Extraction of Configuration Hierarchy: The configuration parsing and processing unit calls the restricted semantic parsing module adapted for the civil aircraft domain to standardize the input information, automatically decompose it into a hierarchical structure at the whole-machine level, system level, subsystem level, and component level, and extract core feature parameters:

[0093] S13: Normalization Mapping and Constraint Locking: The processing unit matches the disassembled configuration information with the full-level configuration library of civil aircraft, locks the relevant configuration nodes of the hydraulic system, and simultaneously completes the parameter compliance verification and airworthiness basis binding verification (such as the correspondence between working pressure, component configuration and relevant engineering rules and CCAR-25.1309 clauses). It also completes the standardized data such as hydraulic system interface relationships and design constraints, and uses this configuration node as the core constraint of the subsequent process, synchronizing it to the scenario matching processing unit and the PHM function generation processing unit. The output synchronized to the scenario matching processing unit is used for S21 to S23, and the output synchronized to the PHM function generation processing unit is used for S31 to S32.

[0094] In this embodiment, the processing unit generates a hydraulic system configuration constraint fingerprint based on the hydraulic system, 3000psi working pressure, power source subsystem, control subsystem, execution subsystem, hydraulic pump, relief valve, hydraulic cylinder, and their interface relationships. When subsequently recalling mature hydraulic system cases of the same pressure level, the system first compares the configuration fingerprint of the candidate case with the constraint fingerprint in terms of hierarchy, components, and interfaces, and then proceeds to the scenario, function, and data requirement matching process.

[0095] S2: Generate a list of operating scenarios for the entire lifecycle of the hydraulic system through the scenario matching processing unit: This step, based on the configuration features locked by S1, completes scenario matching, special working condition completion, and airworthiness basis binding verification, outputs a standardized scenario list, scenario constraint parameters, and scenario priority results, and passes them to S3 for PHM function generation.

[0096] S21: Automatic matching of core operating scenarios: Based on the configuration characteristics of the hydraulic system, the scenario matching and processing unit automatically retrieves suitable core operating scenarios from the pre-deployed civil aircraft full lifecycle scenario library. Taking the full lifecycle operating scenario library of the configuration hydraulic system as an example, an initial scenario list is formed:

[0097] S22: Candidate Scenario Completion for Special Operating Conditions: The processing unit invokes the restricted inference module, which, based on the hydraulic system design envelope, a fault mode library for similar aircraft models, and historical operating data, generates candidate scenarios for special operating conditions within the knowledge range of the basic knowledge graph that matches the hydraulic system configuration. For each candidate scenario, the source entity, associated fault mode, suggested monitoring parameters, and airworthiness basis are recorded. Candidate scenarios that pass rule validation are added to the scenario list; those that fail validation are added to the manual confirmation queue.

[0098] S23: Scene Coverage Airworthiness Verification and Output: Based on relevant airworthiness regulations and civil aircraft hydraulic system design standards, the processing unit automatically verifies the completeness of the scenario list. Based on airworthiness provisions such as CCAR-25.1309 (Equipment, Systems and Installations) and CCAR-25.1301 (Functions and Installations), it re-confirms the established core operating scenarios and checks whether special operating conditions cover the main lifecycle stages related to the hydraulic system in the preset scenario library, reducing the risk of omissions in safety-critical subsystems (hydraulic pumps, relief valves). A standardized scenario list is output, including scenario type, compatible components, environmental parameters, monitoring priority, and airworthiness basis information, and is synchronized to the PHM function generation processing unit as the scenario input for S31 to invoke the "configuration-scenario-function" mapping relationship.

[0099] S3: Generate a PHM function list for the hydraulic system through the PHM function generation processing unit. This step, based on the dual constraints of target configuration and automatic matching of the runtime scenario, completes function matching, priority sorting and compliance verification, outputs a standardized function list, function priority results and function coverage verification results, and passes them to S4 for dedicated knowledge subgraph locking.

[0100] S31: PHM function automatic matching: The PHM function generation and processing unit, based on the hydraulic system configuration node locked by S1 and the scenario list output by S2, calls the standardized mapping relationship of "configuration-scenario-function" in the pre-deployed civil aircraft PHM knowledge graph, automatically matches the appropriate PHM functions, and forms an initial PHM function list.

[0101] S32: Functional Prioritization and Compliance Verification: The processing unit hierarchically sorts the initial function list based on the safety level of hydraulic system components and the priority of scenario monitoring, marking mandatory core functions and optional extended functions. Simultaneously, it verifies the scenario coverage and system adaptability of the function list based on civil aircraft airworthiness standards. This is used to check the functional coverage of safety-critical systems, outputting a standardized PHM function list, and simultaneously outputting the functional coverage verification results to S41.

[0102] S4: Through the knowledge graph invocation and dynamic update processing unit, the standardized invocation of the six-dimensional enhanced knowledge graph of the civil aircraft PHM is completed, along with the completion of missing entity relationships and basis, and dynamic incremental updates, providing deterministic knowledge support for the generation of subsequent PHM data requirements in six dimensions. This step, based on the previously locked hydraulic system configuration, operating scenario, PHM function, and other constraints, completes the knowledge graph call and integrity verification, and performs compliant completion of entities, relationships, or bases not covered by the dedicated knowledge subgraph, providing knowledge support within a limited scope for subsequent data requirements. Its output dedicated knowledge subgraph, completion candidate set, and update log serve as inputs to S5.

[0103] S41: Standardized Knowledge Graph Calling and Dedicated Subgraph Locking: Based on the hydraulic system configuration node locked by S1, the full life cycle operation scenario list output by S2, and the PHM function list output by S3, the processing unit calls the pre-deployed civil aircraft PHM six-dimensional enhanced knowledge graph to retrieve and extract the six-dimensional standardized relationship of "civil aircraft configuration - operation scenario - PHM function - failure mode - data requirement - airworthiness constraint". At the same time, the graph filtering mechanism filters out irrelevant entities and redundant relationship information such as engine and air conditioning system, and locks the knowledge subgraph dedicated to this hydraulic system design as the knowledge base for subsequent completion and data generation.

[0104] S42: Missing content identification and completion process triggered: Based on the configuration, scenario, and functional constraints of this design, the processing unit completes entity, relationship, and basis retrieval and integrity verification for the locked exclusive knowledge subgraph. Taking the six-dimensional relationship loop of "configuration-scenario-function-failure mode-data requirement-airworthiness constraint" as the core judgment standard, it identifies missing entities and relationships not covered by the graph. In this example, the special working condition scenario of "cold start of hydraulic pump under extreme low temperature environment" completed by S2 has no corresponding fault mode-monitoring parameter association mapping, which meets the triggering conditions and automatically starts the graph content completion process.

[0105] S43: Restricted compliance reasoning completion for missing content: The processing unit invokes a restricted inference module adapted for the civil aircraft domain. Based on preset civil aircraft hydraulic system design specifications, CCAR-25 airworthiness standards, and mature engineering cases of similar 3000psi pressure-level civil aircraft hydraulic systems, it generates candidate tuples for missing content, q=<entity type, entity name, attribute parameters, association relationships, and source of reference>. In this embodiment, the templated constraint rules are only used to limit the input fields, output format, and inference boundaries, and do not directly determine the completion result; whether the candidate tuple is valid is still determined by the entity relationships in the dedicated knowledge subgraph, the binding status of airworthiness clauses, and the rule verification results.

[0106] This data completion uses a pre-defined "scenario-failure mode-data requirement" template constraint rule, which includes at least the following: 1. The knowledge boundary is limited to the graph entities related to the cold start of hydraulic systems.

[0107] 2. It should be bound to relevant airworthiness provisions, such as CCAR-25.1309.

[0108] 3. The output should follow the standardized format of "entity name-attribute parameter-relationship-reasoning basis" and should not be generated arbitrarily without basis.

[0109] 4. Candidate tuple q is only allowed to enter the graph incremental update process if the entity type belongs to the preset six-dimensional graph mode, the relationship can be accessed to the hydraulic system's dedicated knowledge subgraph, and the source can point to CCAR-25.1309 or a verified engineering case.

[0110] 5. In this embodiment, CCAR-25.1309, CCAR-25.1301, and their corresponding mandatory engineering specifications are used as the highest priority. Mature engineering cases of similar 3000psi hydraulic systems are only used for candidate recall and parameter value reference, and cannot replace airworthiness clauses. If the monitoring parameters or sampling frequency given in historical cases are inconsistent with the applicable clauses, working pressure, or component interface relationships of the hydraulic system, the processing unit marks the candidate as a conflicting item and returns it to the manual confirmation queue.

[0111] S44: Dual-track compliance verification and incremental knowledge graph update: A dual-track compliance verification process is implemented for the supplementary content. First, an initial verification of the compliance and airworthiness of the automation engineering is completed through a pre-set expert rule base for civil aircraft hydraulic systems. The verification standards are as follows: 1. Complete the content and bind it to the clear CCAR-25.1309 airworthiness clause.

[0112] 2. The feature similarity with similar mature engineering cases reaches a preset threshold, which is 90% in this embodiment.

[0113] 3. The entity relationships conform to the underlying logic of a six-dimensional knowledge graph.

[0114] The content that passes the initial verification is then highlighted on the visualization interface, with complete reasoning evidence simultaneously annotated. After manual confirmation by designers, the six-dimensional enhanced knowledge graph of the civil aircraft PHM is dynamically and incrementally updated through the unified knowledge graph storage interface. The updated knowledge subgraph retains the version identifier, write-back time, source of evidence, and manual confirmation record, and participates in retrieval, comparison, and verification again in the subsequent data requirement recommendation of similar hydraulic system configurations, thus forming a feedback loop of the completion result return to the recommendation process. The verified dedicated knowledge subgraph is synchronized to the data requirement recommendation processing unit as the knowledge scope for S51 candidate recall and S52 path solving.

[0115] S5: Through the data requirement recommendation processing unit, the constraints for the hydraulic system PHM data requirements are generated. This step uses the hydraulic system configuration as the core constraint, and combines the automatically generated list of operating scenarios, the PHM function list, and the verified dedicated knowledge subgraph. It adopts a combined optimization method of vector similarity candidate recall, constraint path search, gating verification, information support strength calculation, and residual oversight risk minimization to generate a standardized PHM data requirement recommendation model. Specifically, S51 forms the initial candidate set, S52 forms the candidate path set, and S53 forms the candidate model of data requirements to be optimized and determines the final recommendation set.

[0116] S51: Vectorized representation of multiple constraints, PHM demand unit generation and candidate recall: In this embodiment, regarding candidate data requirements We construct configuration feature vectors, scenario feature vectors, functional feature vectors, failure mode feature vectors, and airworthiness basis feature vectors, and perform dimensional similarity calculations between these vectors and the corresponding query vectors for the target configuration. This process performs targeted recall of structured candidates within the dedicated knowledge subgraph; the recall results serve as intermediate inputs for subsequent path filtering, rule validation, and combination optimization, and cannot be directly used as recommendation conclusions.

[0117] ; like Below the threshold Then the candidate Removed; if Involves safety-critical components such as hydraulic pumps and relief valves. If the candidate is not found to be valid, it is directly deemed invalid and will not be included in the candidate set. The selected candidates then proceed to the path solving process in S52.

[0118] The processing unit extracts the constraints of this design, including the core feature of the hydraulic system's 3000psi working pressure, scenario constraint parameters for all flight phases, and a list of 9 PHM functions. The constraints are vectorized using a pre-defined civil aircraft airborne system embedding model. The input fields, vector dimensions, and normalization methods of the embedding model correspond one-to-one with the configuration level, scenario type, function type, fault mode, and basis type. Five core recall dimensions are used: configuration matching degree, scenario adaptability, function adaptability, fault mode coverage, and airworthiness basis binding. Multi-path recall is performed using cosine similarity calculation. In this embodiment, a similarity of 85% (only an example and a configurable parameter) is set as an adjustable screening threshold. Mature design cases of civil aircraft hydraulic systems with the same pressure level are recalled, and candidate data requirements are extracted to form an initial candidate set with high matching degree.

[0119] In this embodiment, the 85% similarity screening threshold is saved as part of the parameter configuration identifier. This configuration simultaneously records the weight values, normalization methods, and applicable design stages for five recall dimensions: configuration matching, scenario coverage, functional coverage, failure mode coverage, and airworthiness basis binding. When the user adjusts this threshold later, it only affects the number of candidate recalls and their display order, without changing the... Consistency verification check, Checksum Gating rules.

[0120] S52: Constraint Path Search, Gated Validation, and Candidate Frame Generation In this embodiment, a six-layer directed graph consisting of configuration nodes, scenario nodes, PHM function nodes, failure mode nodes, data requirement nodes, and airworthiness basis nodes is constructed on the hydraulic system-specific knowledge subgraph. Each path represents a complete data requirement generation path. Before graph calculation, paths that do not meet the mandatory core function coverage constraint, airworthiness basis binding constraint, or duplicate data collection constraint are deleted. Then, a search is performed on the remaining paths for the path with the lowest total cost or K low-cost candidate paths to obtain a set of candidate paths.

[0121] For paths that share the same monitoring parameters and can simultaneously cover multiple fault modes such as hydraulic pump wear and overflow valve sticking, priority should be given to retaining paths with lower total cost and complete airworthiness basis binding, in order to reduce redundant monitoring parameters.

[0122] When the aforementioned candidate path set enters the candidate framework generation and combinatorial optimization recommendation process, the hydraulic system configuration matching degree, full flight phase scenario coverage, coverage of 9 PHM functions, airworthiness basis binding status, and path cost are respectively used as... , , , and Input; candidates are only available when... and Only when all requirements pass will a data requirement be included in the candidate set for combinatorial optimization as an optimizable data requirement.

[0123] In this embodiment, candidate data requirements such as hydraulic pump outlet pressure, hydraulic pump vibration, and pressure difference between the inlet and outlet of the relief valve are no longer simply ranked by their individual similarity before being included in the final list. Instead, their contribution to the coverage of PHM (Prognostics and Health Management) requirement units, including takeoff fault diagnosis, landing fault diagnosis, cruise health monitoring, and ground maintenance life prediction, is calculated simultaneously. When two pressure-related data items are highly correlated, the redundancy correlation is considered. Increasing the number of data items and adding them later weakens the effect of reducing the risk of missing data, thus avoiding duplicate data collection.

[0124] If the knowledge subgraph specific to the hydraulic system cannot form a complete path that satisfies hard constraints, such as the lack of fault modes or airworthiness basis in extreme low temperature cold start scenarios, the processing unit outputs a corresponding list and sends the scenario, fault mode and candidate monitoring parameters into the restricted compliance reasoning completion process of S43; before the completed content passes the dual-track verification, no data requirement recommendation item is generated for this part.

[0125] S53: Constrained parameter completion, information support strength calculation and combinatorial optimization recommendation: Through the constrained parameter completion and basis completion module, based on the candidate path set output by S52, the module recalls the corresponding engineering design specifications, fault handling experience, and parameter configuration rules for the hydraulic system from the pre-deployed six-dimensional enhanced knowledge graph of civil aircraft PHM. Using a preset monitoring parameter optimization template, it completes parameters such as sampling frequency / accuracy, prunes redundant monitoring parameters, and completes the basis for the basic data requirement framework. In this embodiment, the module outputs fields to be verified and pruning suggestions, rather than directly applicable data requirement conclusions. The output still needs to be jointly verified with the mandatory core function coverage results, airworthiness basis binding results, information support strength, remaining risk reduction of oversight, and conflicts with existing data requirement items. After rule verification, the completed fields first form a candidate model of data requirements to be optimized, and then the final recommended set is confirmed by combination optimization. This model includes at least the monitoring parameter name, corresponding component, adapted PHM function, sampling frequency and sampling accuracy, and judgment basis. The values ​​of each field are used as the verified recommended results, which can be subsequently confirmed and adjusted in the visual design canvas.

[0126]

[0127] The PHM data requirement recommendation model generated by S5 is synchronously pushed to the visual design canvas, allowing users to perform secondary editing, parameter adjustment, and scheme optimization under rule constraints. The version confirmed by the user is used as the scheme object exported by S7 XML.

[0128] S6: Construct a visual design canvas that allows users to edit, validate, and manage versions of the recommended results generated from configuration inputs. The canvas is initialized based on the target civil engineering configuration locked by S1 parsing, and receives the PHM data requirement recommendation model output by S5 to display the configuration components, operating scenarios, PHM functions, monitoring parameters and airworthiness basis and other entities and their relationships. When users add, edit, delete entities or adjust entity relationships, the system records the operation log synchronously and triggers rule verification, airworthiness basis binding verification, relationship legality verification and conflict verification.

[0129] In this embodiment, the visual design canvas synchronously displays the source path of each hydraulic system candidate data requirement item, the PHM requirement unit coverage relationship, the information support strength, the remaining risk reduction of oversight, the recommended score for display, the airworthiness basis binding status, the redundancy correction reason, the data acquisition burden, and the manual confirmation status. After the user adjusts the monitoring parameters, sampling frequency, or judgment criteria, the system re-executes the rule verification, combination optimization review, and version recording of the affected path.

[0130] S7: Import and export function for full PHM solution data model in XML format: The system supports exporting the PHM design scheme generated by configuration input after S6 confirmation into an XML file that meets the requirements of the preset civil aircraft PHM data exchange format. The exported content includes target configuration information, operation scenario list, PHM function list, PHM data requirement model and airworthiness basis record. Before exporting, file format verification, data integrity verification, airworthiness basis binding verification and engineering rule consistency verification are completed.

[0131] Users can import XML scheme files that conform to the standard format. After the system parses the files, it restores the corresponding civil engineering topology, operating scenarios, PHM functions, and data requirement model content in the canvas, supporting the reuse and iteration of design schemes for similar models.

[0132] Perform a two-track verification on the imported XML file: first, complete the file format specification verification and data integrity check; then, perform airworthiness basis binding verification and engineering logic verification on the parsed solution content. If the verification fails, highlight the warning and indicate the reason for the problem.

[0133] In this embodiment, if the imported historical hydraulic system scheme differs from the current hydraulic system in terms of working pressure, hydraulic pump type, relief valve configuration, or applicable flight phase, the system will mark the corresponding monitored parameters as candidates for configuration boundary inconsistency and recalculate them. , , Data acquisition burden constraints; imported items that fail gating validation, fail to meet key requirement coverage thresholds, or exceed the data acquisition burden limit shall not be directly included in the recommendation set of the current configuration.

[0134] This invention uses user-inputted civil aircraft configuration information as initial configuration input and core constraints to automatically generate a full lifecycle operation scenario list, a standardized PHM function list, and a PHM data requirement model that match the configuration. This effectively improves the efficiency of civil aircraft PHM system design, the traceability of airworthiness basis, and engineering adaptability, making it suitable for widespread use.

[0135] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for full-element screening of PHM (Prognostics and Health Management) for civil aircraft based on configuration input, characterized in that, It includes the following steps: S1: Receive civil configuration information as initial configuration input, perform hierarchical decomposition, parameter extraction, standardization mapping and constraint number binding on the initial configuration input, and output standard configuration features; S2: Based on the output of S1, match the core operating scenarios that the configuration feature should cover, and output a standardized list of operating scenarios, a set of scenario constraint parameters, and scenario priority results; S3: Taking the outputs of S1 and S2 as input, complete PHM function matching, priority sorting and compliance verification, and output the PHM function list matching the target configuration, function priority results and function coverage verification results; S4: Taking the output results of S1 to S3 as input, complete the exclusive subgraph locking, missing content completion and dynamic incremental update of the basic knowledge graph library, and output the verified exclusive knowledge subgraph. S5: Generate constraints for PHM data requirements, and output a standardized data requirement list, parameter configuration results, and supporting records; S51: Extract the output results from S1 to S4, complete multi-path recall by cosine similarity calculation, and output the initial candidate data requirement item set; S52: Based on the output of S51, perform path filtering and candidate path solving on the dedicated knowledge subgraph, and output the candidate path set and basic data requirement framework. S53: Taking the output of S52 as input, the method of combining gating verification, information support strength calculation and residual oversight risk minimization optimization is adopted to realize the constraint generation of PHM data requirements, and output the standardized PHM data requirement recommendation model, standardized data requirement list, parameter configuration results and their basis records. S6: Using the output of S5 as the object, edit, verify rules and manage versions of the running scenario list, PHM function list and PHM data requirement model, and output the reviewed full PHM solution.

2. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: It also includes S7: taking the output of S6 as input, it realizes the import and export function of the entire PHM solution in XML format, and completes the standardized storage and cross-system data exchange of the running scenario list, PHM function list, and PHM data requirement model.

3. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: S1 includes the following steps: S11: Receive civil aircraft configuration information in any form, such as civil aircraft model, system / subsystem name, component list, configuration technical document, etc., input by the user; S12: Automatically decompose the input configuration information into a hierarchical structure at the whole machine level, system level, subsystem level, and component level, and extract the core feature parameters of each configuration node; S13: Standardize and match the disassembled configuration information with the full-level configuration library of civil aircraft, lock the civil aircraft configuration node corresponding to the current design as the core constraint, and at the same time complete the compliance verification of configuration parameters and the completion of missing information, and output standard configuration features. Standard configuration features include the standard configuration node set, configuration parameter set, and core constraint identifier.

4. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: S2 includes the following steps: S21: Based on the standard configuration features output by S1, automatically match the core operational scenarios that the configuration should cover from the civil aircraft full life cycle scenario library to form an initial scenario list; S22: Based on the configuration's design envelope, fault mode library, and historical operating data, generate special operating condition candidate scenarios for this configuration through restricted reasoning; S23: Calculate the matching degree of candidate scenes The candidate scenarios are recalled, compressed, and initially sorted. Candidates that are below the preset screening threshold and do not belong to the mandatory coverage scenarios are eliminated or transferred to manual confirmation. The remaining candidates are sorted in descending order of matching degree to form a candidate scenario set. Candidate scene matching degree The calculation method is as follows: ； in, This indicates the target civil system type output by S1. This represents the i-th candidate running scenario; Indicates configuration level matching item, This indicates items covered during the flight or maintenance phase. Indicates the scenario-related fault mode coverage items. This indicates an airworthiness or engineering basis binding item; , , and The values ​​of all values ​​are in the range [0,1]; weight , , and Based on the system security level and pre-set or configured during the design phase; when Furthermore, when this scenario involves safety-critical components, the scenario... Enter the manual confirmation queue; Based on the established airworthiness specifications and system design standards, the system performs operational condition coverage verification and airworthiness basis binding verification on the candidate scenario set, and outputs a standardized operational scenario list and constraint parameters.

5. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: S3 includes the following steps: S31: Based on the target configuration features output by S1 and the standardized operational scenario list output by S2, the standardized mapping relationship between configuration, scenario and function in the civil aircraft PHM knowledge graph is invoked to complete the automatic matching of core functional requirements and form an initial PHM function list. S32: Calculate PHM function priority A list of candidate functions is generated and categorized. Functions reaching the first set threshold are marked as mandatory core functions, functions reaching the second set threshold but not the first threshold are marked as optional extended functions, and functions below the second threshold are eliminated or transferred for manual confirmation. PHM function priority is established. The calculation method is as follows: ； in, Indicates the configuration-function mapping strength. Indicates the set of selected scenes The trigger strength of this function Indicates the security level of associated components. Indicates whether the function is tied to airworthiness or engineering criteria; weight. , , and Pre-set or configured according to the system security level and design phase; Based on the scenario coverage and system adaptability of the civil aircraft airworthiness specification verification function list, it is used to check the functional coverage of safety-critical systems and output a standardized PHM function list.

6. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: S4 includes the following steps: S41: Based on the civil aircraft configuration features output by S1, the standardized operation scenario list output by S2, and the PHM function list output by S3, the civil aircraft PHM knowledge graph is invoked to extract the six-dimensional standardized relationships of civil aircraft configuration, operation scenario, PHM function, failure mode, data requirements, and airworthiness constraints, forming a unique knowledge subgraph. S42: Based on the exclusive knowledge subgraph formed by S41 and the configuration, scenario and functional constraints of this design, complete the entity and relationship retrieval within the exclusive knowledge subgraph, identify uncovered missing entities, missing relationships or missing evidence, and trigger the graph content completion process; S43: Through a restricted reasoning module adapted for the civil aircraft field, based on preset engineering specifications and airworthiness standards, generate candidate tuples q for missing content, and perform verification before the candidate tuples q enter the knowledge graph; S44: Perform a dual-track compliance check on the completed content. After automated rule verification and manual confirmation, complete the dynamic incremental update of the knowledge graph.

7. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 6, characterized in that: In S43, the verification method for candidate tuple q is as follows: ； in, This indicates entity type validity verification. This indicates the validation of the relationship validity. This indicates that the integrity of the source is verified. This indicates that the airworthiness terms are bound to the verification. Indicates duplicate and conflict checks; , , , and All are binary check items, with values ​​of 0 or 1; This represents the comprehensive legality gating check result of candidate tuple q before it enters the knowledge graph. At that time, candidate tuples Returned to the manual confirmation queue; when At that time, candidate tuples pass the basic legality check before entering the knowledge graph.

8. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: In S52, the methods for execution path filtering and candidate path solving include: constructing and solving the complete path on a dedicated knowledge subgraph. ； ； in, This represents a complete path that starts from the configuration node, passes through the scenario node, PHM function node, fault mode node, data requirement node, and ends at the airworthiness basis node. , , , , and These are graph nodes representing configuration nodes, scenario nodes, PHM function nodes, failure mode nodes, data requirement nodes, and airworthiness basis nodes, respectively. Represents the total cost of the path. Represents the edges in the path The cost, This indicates that the required functions do not cover the penalty items. This indicates a penalty for missing airworthiness criteria. This indicates a penalty for duplicate data requirements; , The corresponding penalty item weights are configured based on the degree of safety criticality and the design phase; Paths that do not meet the set hard constraints are deleted. For paths that share the same monitoring parameters and can cover multiple failure modes at the same time, only the path with the minimum total cost is retained to enter the candidate result set. When a candidate path meets the hard constraints at the same time, the candidate path enters the candidate framework generation and combination optimization recommendation process. If the candidate path set after hard constraint filtering is empty, or if the coverage of any of the required core functions, high-risk failure modes, or key operating scenarios is lower than the corresponding threshold, a gap list is generated, including uncovered configuration nodes, scenario nodes, PHM function nodes, failure mode nodes, data requirement nodes, and basis gaps, and execution returns to steps S42 to S44.

9. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: In S53, the standardized PHM data requirement recommendation model is as follows: ； in, This represents the number of candidate data requirements to be optimized after candidate recall and constraint path construction. Indicates by A selection vector consisting of the selection variables for each candidate data requirement item; and Both represent indexes of candidate data requirement items, and , The range of values ​​is to ; This indicates the result of selecting the optimal data requirement item; Indicates the target configuration The number of PHM requirement units; Representing the demand unit Importance; Indicates candidate data requirement items For demand unit The strength of information support; Indicates candidate data requirement items The gating verification result is used when the candidate data requirement item passes the rule verification and its corresponding constraint path satisfies the hard constraints. ,otherwise ; Indicates candidate data requirement items and Redundancy correlation between them; Indicates candidate data requirement items The burden of data acquisition; This indicates the maximum allowed data acquisition burden; express The path cost corresponding to the constraint path; This represents the data acquisition burden penalty coefficient. This represents the path cost penalty coefficient.

10. The full-element screening method for civil aircraft PHM based on configuration input as described in claim 1, characterized in that: S6 includes the following steps: Through a visual design canvas, using the standardized data requirement list, parameter configuration results, and basis records output by S5 as objects, users can edit, modify, version manage, and optimize the solution under rule constraints. When users modify entities or relationships, the system simultaneously triggers rule verification, airworthiness basis binding verification, and version records. Finally, the system outputs the reviewed PHM full solution.

Images