A spacecraft electrical system interconnection component principle data optimization method and system

Abstract

The present application relates to the technical field of electrical system design, and more particularly to a spacecraft electrical system interconnection component principle data optimization method and system. The method comprises the following steps: obtaining interconnection component data; structurally deconstructing the interconnection component data to obtain principle unit data; constructing cross-task inheritance paths and extracting assumption constraints based on the principle unit data to obtain cross-task inheritance path data and assumption constraint data, respectively; performing cross-generation principle consistency verification based on the cross-task inheritance path data and the assumption constraint data to obtain distortion unit data; and performing distortion accumulation evaluation on the distortion unit data to obtain distortion accumulation data to assist interconnection component optimization work. By constructing a cross-task inheritance path and principle assumption bearing mapping relationship, the present application can effectively identify implicit principle faults in the electrical system caused by structural pruning or inheritance distortion, and improve the reuse reliability of principle data in multiple generations of space missions.

Description

Technical Field

[0001] This invention relates to the field of electrical system design technology, and in particular to a method and system for optimizing the principle data of interconnection components in a spacecraft electrical system. Background Technology

[0002] With the deepening trend of platform-based design and multi-mission reuse in spacecraft, interconnecting components in electrical systems (such as electrical connectors, distribution nodes, and wiring harness interface modules) are increasingly being shared across generations across multiple mission models. To support multi-mission reuse, design teams typically copy and tailor the principle data from the previous generation of missions, enabling rapid configuration. However, in actual engineering practice, the evolution of principle data is not a linear inheritance but is constrained by the combined effects of multiple factors, including errors in the inheritance of manual parameters, asynchronous adjustment of constraint logic, and failure to promptly remove principle assumptions. During mission customization, although the component hardware itself remains unchanged, its principle-level configurations, such as signal interfaces, electrical isolation, and redundancy modes, undergo profound changes. This not only affects design reliability but also introduces system vulnerabilities during flight missions, representing a critical weakness that urgently needs to be addressed in current aerospace electrical system design. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention proposes a method and system for optimizing the principle data of interconnection components in a spacecraft electrical system, thereby resolving at least one of the aforementioned technical problems.

[0004] This application provides a method for optimizing the principle data of interconnection components in a spacecraft electrical system, including the following steps:

[0005] Obtain interconnect component data; deconstruct the interconnect component data to obtain the principle unit data;

[0006] Based on the principle unit data, cross-task inheritance path construction and hypothesis constraint extraction are performed to obtain cross-task inheritance path data and hypothesis constraint data, respectively.

[0007] Based on cross-task inheritance path data and assumption constraint data, cross-generational principle consistency verification is performed to obtain distorted unit data.

[0008] The distortion unit data is evaluated to obtain cumulative distortion data, which is then used to assist in the optimization of interconnect components.

[0009] This invention achieves consistency and reliability control of principle assumptions during multi-mission reuse by structurally deconstructing and cross-mission evolution analysis of the principle data of interconnection components in spacecraft electrical systems. By decomposing the interconnection component principle data into computable principle units and constructing cross-mission inheritance paths and assumption constraint relationships, principle assumptions originally implicit in design documents can be explicitly expressed and tracked in data form, effectively avoiding the problem of accumulated distortion of principle assumptions caused by manual copying or partial modification. Through cross-generation principle consistency verification, this invention can identify implicit failures where principle assumptions still exist in form but their structural load-bearing objects have been missing or broken, thus overcoming the shortcomings of existing technologies that can only perform single-mission, single-version verification. By conducting multi-dimensional cumulative distortion assessment of distorted units, principle distortion is transformed from static judgment into quantifiable and graded risk data.

[0010] Preferably, obtaining interconnect component data specifically involves:

[0011] Acquire spacecraft mission data;

[0012] The interconnect component range is determined based on spacecraft mission data, resulting in interconnect component range data.

[0013] Interconnection component data is obtained by collecting interconnection component data based on the interconnection component range data.

[0014] This invention uses spacecraft mission data as the starting point for acquiring interconnect component data, achieving a precise correlation between the interconnect component data acquisition process and specific mission configuration. By defining the scope of interconnect components during the data acquisition phase, it is possible to effectively filter interconnect components participating in the current mission under constraints such as mission trimming, function activation / deactivation, and redundant configuration. This avoids including the principle data of components not involved in the current mission in the analysis, reducing data redundancy and invalid interference from the source. Targeted data acquisition based on the defined scope of interconnect components ensures that the acquired interconnect component data maintains consistency and traceability in terms of mission semantics, configuration status, and version relationships.

[0015] Preferably, the structured decomposition specifically includes:

[0016] Based on the interconnected component data, the principle type is divided to obtain the principle type data;

[0017] Based on the principle type data, interface signal relationship deconstruction, parameter assumption deconstruction, redundant logic deconstruction, and constraint dependency extraction are performed to obtain signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data, respectively.

[0018] The signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data are encapsulated into principle unit data.

[0019] This invention categorizes interconnect component data by principle type, distinguishing the originally mixed and semantically intertwined principle information into different principle types such as interface signal relationships, parameter assumptions, redundant logic, and constraint dependencies. This effectively avoids the semantic ambiguity and analytical coupling problems caused by processing principle data as a whole in traditional methods. For each principle type, interface signal relationship deconstruction, parameter assumption deconstruction, redundant logic deconstruction, and constraint dependency extraction are performed separately. This allows various principle information types in interconnect components to be expressed as independent and computable data units, thereby transforming the implicit relationships at the principle diagram level into structured data representations. By uniformly encapsulating the various deconstruction results into principle units, the association relationships between different principle elements are established, ensuring that principle units maintain necessary independence while possessing complete semantic expression capabilities.

[0020] Preferably, the construction of the cross-task inheritance path specifically involves:

[0021] Based on the principle unit data, the principle unit evolution identifier is generated to obtain the evolution identifier data;

[0022] Evolutionary identifier data is mapped across task units to obtain inheritance mapping data;

[0023] Inheritance behavior type identification is performed on the inheritance mapping data to obtain inheritance behavior type data;

[0024] By tracing the underlying assumptions and carrying relationships of inheritance behavior type data, we can obtain the assumed carrying status data.

[0025] Based on inheritance mapping data, inheritance behavior type data, and assumed carrying state data, a path graph is constructed to obtain cross-task inheritance path data.

[0026] This invention generates evolutionary identifiers for principle unit data, unifying the functional semantics, interface features, and hypothesis dependency information of principle units across different tasks, thus avoiding mismatches caused by judging inheritance relationships solely based on name or version number. By establishing actual inheritance relationships between principle units through cross-task unit mapping, the evolutionary relationships of principle data under different task configurations can be accurately identified. Through inheritance behavior type identification, different inheritance methods such as full inheritance, trimmed inheritance, and overriding inheritance are distinguished, enabling subsequent analysis to employ differentiated processing strategies for different evolutionary methods. By tracing the principle hypothesis-carrying relationships through inheritance behavior type data, it can be determined whether the principle hypothesis still possesses valid structural carrying conditions during the inheritance process, thus preventing implicit hypothesis failures from being ignored in cross-task reuse. By combining inheritance mapping, inheritance behavior types, and hypothesis-carrying states to construct a cross-task inheritance path graph, the evolutionary trajectory of principle units in a multi-task environment has clear visualization and traceability.

[0027] Preferably, the assumption constraint extraction specifically involves:

[0028] Structural role data is obtained by parsing the principle unit data;

[0029] Implicit prerequisite trigger points are identified in the structural role data to obtain implicit prerequisite trigger point data;

[0030] Based on the implicit premise trigger point data, the principle unit data is reverse-bound to the hypothetical dependency object to obtain the hypothetical dependency object data;

[0031] Based on the hypothesis dependency object data, hypothesis validity condition data is obtained by processing the hypothesis validity conditions.

[0032] Cross-cell hypothesis merging is performed on the hypothesis validity condition data to obtain hypothesis constraint data.

[0033] This invention clarifies the functional position and interdependencies of each principle unit in the interconnection relationship by performing structural role analysis on the principle unit data. Through implicit premise trigger point identification, it can uncover unstated but crucial implicit preconditions that significantly influence the validity of the principle from the principle structure and connection relationships, thus avoiding the omissions caused by traditional methods that rely solely on parameters or rule text. By reverse-binding the implicit premise trigger points to their dependent objects, a clear association is established between the principle assumptions and their dependent interfaces, signals, or redundant structures, providing a traceable and verifiable structural foundation for the validity of the principle assumptions. By processing the assumption validity condition data of the dependent objects, the originally implicit or ambiguous principle assumptions are transformed into formalized descriptions of validity conditions. Through cross-unit assumption merging, duplicate or conflicting assumption constraints in different principle units are eliminated, ensuring consistency and integrity of the assumption constraint data at the global level, thereby improving the systematic nature and engineering controllability of interconnection component principle assumption management.

[0034] Preferably, the cross-generational principle consistency verification specifically includes:

[0035] Inheritance path data is segmented based on cross-task inheritance path data to obtain intergenerational inheritance segment data;

[0036] The hypothetical constraint data is mapped to the intergenerational inheritance segment data to obtain the intergenerational hypothesis data;

[0037] Based on intergenerational hypothesis data, cross-generational consistency failure is determined, and cross-generational distortion identification data is obtained.

[0038] The cross-generational distortion identifier data is aggregated to obtain distortion unit data.

[0039] This invention segments the cross-task inheritance path data, refining the evolutionary relationship of principle units in multi-task reuse into inheritance segments between adjacent generations. This avoids mixing the principle states of different task stages for analysis, improving the targeting and accuracy of consistency verification. By mapping hypothesis constraint data to each generational inheritance segment, principle hypotheses can be verified segment by segment within specific generational contexts, avoiding static judgments at the global level that ignore changes in the conditions for hypothesis validity during evolution. By determining cross-generational consistency failures based on generational hypothesis data, it can identify implicit failures where principle hypotheses still exist in form but their structural support conditions have been missing or broken, thus overcoming the shortcomings of existing technologies in detecting cross-generational principle distortions. By aggregating cross-generational distortion identification data to form distortion unit data, principle failures can be accurately located to specific principle units and evolutionary stages.

[0040] Preferably, the cross-generational consistency failure determination specifically involves:

[0041] Based on the intergenerational hypothesis data, hypothesis-carrying object binding is performed to obtain object binding data;

[0042] Based on the cross-task inheritance path data, the object binding data is identified to determine its persistence status, and thus the persistence status data is obtained.

[0043] Based on the existing status data, the continuity of the load is verified to obtain abnormal load continuity data;

[0044] Based on the continuous abnormal data of the bearing, the empty shell hypothesis is identified and determined, and the empty shell hypothesis identification data is obtained;

[0045] Based on the empty shell hypothesis identification data, cross-generational failure propagation is confirmed for cross-task inheritance path data, resulting in cross-generational distortion identification data.

[0046] This invention binds hypotheses to their supporting objects by performing hypothesis-carrying object binding on intergenerational hypothesis data. This establishes a clear correspondence between the principle hypotheses and the interfaces, signals, and redundant structures upon which they depend, ensuring that the validity of the principle hypotheses no longer depends solely on formal definitions but forms a traceable binding relationship with specific structural objects. By identifying the survival status of supporting objects in conjunction with cross-task inheritance path data, the invention accurately determines whether supporting objects are retained, pruned, or reconstructed in different task generations, thereby revealing the changes in the principle structure as tasks evolve. By verifying the continuity of supporting objects, potential anomalies arising from discontinuous supporting objects during cross-generational inheritance of principle hypotheses can be detected in a timely manner, preventing hypotheses from being used by default even when structural conditions are no longer met. Through the identification and judgment of empty shell hypotheses, implicitly failed hypotheses that still exist in form but have lost structural support can be identified, thereby preventing such hypotheses from continuing to propagate in subsequent tasks. By confirming cross-generational failure propagation through cross-task inheritance paths, the invention achieves accurate positioning of the scope of impact of principle failures.

[0047] Preferably, the cumulative distortion assessment specifically includes:

[0048] Distortion dimension decomposition is performed on the distorted cell data to obtain distortion feature data;

[0049] Based on the cross-task inheritance path data, the generational distortion accumulation trajectory is constructed from the distortion feature data to obtain the distortion accumulation trajectory data;

[0050] Distortion accumulation processing is performed on the distortion accumulation trajectory data to obtain distortion accumulation data, which is then used to assist in the optimization of interconnected components.

[0051] This invention decomposes the distortion unit data into distortion dimensions, breaking down the originally difficult-to-quantify principle distortion state into multiple feature dimensions with clear engineering implications. This allows the distortion problem to be expressed and analyzed in a structured data format. By constructing an intergenerational distortion accumulation trajectory using cross-task inheritance path data, the evolutionary trend of principle distortion during multi-task inheritance can be represented, avoiding one-sided judgments of principle reliability based solely on a single intergenerational state. Through distortion accumulation processing of the distortion accumulation trajectory data, principle distortion can be transformed from instantaneous anomaly judgments into cumulative data reflecting long-term evolutionary risks, thus providing a quantitative basis for the reuse and optimization of interconnect component principle data. This approach enables the early identification of principle distortion risks before they develop into explicit failures, facilitating targeted optimization of inheritance paths, principle assumptions, or structural configurations during the design phase.

[0052] Preferably, the optimization auxiliary operation for interconnected components specifically includes:

[0053] Distortion type identification data is obtained by classifying the cumulative distortion data based on the cumulative distortion data;

[0054] The distortion type identifier data is filtered for units of interest to obtain units of interest data.

[0055] Based on cross-task inheritance path data and assumption constraint data, distortion root cause correlation analysis is performed on the data of the units of interest to obtain distortion root cause correlation data.

[0056] Optimization strategies are generated based on the root cause correlation data of the distortion, resulting in optimization strategy data.

[0057] This invention categorizes cumulative distortion data to distinguish different types of principle distortions from a unified risk data set. This allows principle distortions to be managed according to different causes, such as hypothesis failure, structural evolution, or inherited superposition, thus avoiding judgment biases caused by using a single processing strategy. By filtering units of interest based on distortion type identification data, optimization targets are focused on key principle units that have a significant impact on system consistency and reliability, reducing interference from irrelevant units in optimization decisions. By combining cross-task inheritance path data and hypothesis constraint data to perform root cause correlation analysis on units of interest, the inheritance nodes and hypothesis dependencies of distortions can be accurately traced, making the causes of principle distortions clearly explainable. By generating optimization strategies based on distortion root cause correlation data, targeted suggestions are provided for the correction, inheritance constraints, or reuse control of interconnected component principle data, transforming principle optimization from experience-based judgment to a data-driven, assisted decision-making process.

[0058] Preferably, this application also provides a spacecraft electrical system interconnection component principle data optimization system for executing the spacecraft electrical system interconnection component principle data optimization method described above. The spacecraft electrical system interconnection component principle data optimization system includes:

[0059] The structure deconstruction module is used to acquire interconnect component data; based on the interconnect component data, it performs structure deconstruction to obtain the principle unit data;

[0060] The principle inheritance evolution analysis module is used to construct cross-task inheritance paths and extract assumption constraints based on principle unit data, resulting in cross-task inheritance path data and assumption constraint data, respectively.

[0061] The cross-generational principle consistency verification module is used to perform cross-generational principle consistency verification based on cross-task inheritance path data and assumption constraint data, and obtain distorted unit data.

[0062] The distortion cumulative evaluation module is used to perform distortion cumulative evaluation on the distortion unit data to obtain distortion cumulative data, which is used to assist in the optimization of interconnect components.

[0063] The beneficial effects of this invention are as follows: By acquiring interconnect component data under the constraints of specific spacecraft mission data and deconstructing it structurally, the complex principle information originally existing in the form of schematic diagrams or configurations is broken down into principle unit data with clear semantics and dependencies. The system constructs cross-mission inheritance paths for principle units and simultaneously extracts principle assumption constraints, enabling the explicit expression and tracking of the evolutionary relationships of principle units across different missions and the dependencies of principle assumptions, avoiding the uncertainty caused by relying solely on version numbers or manual annotations to determine inheritance relationships. Through cross-generational principle consistency verification, combined with inheritance paths and assumption constraints, the system determines whether principle assumptions still possess effective structural support during multi-generational mission evolution, thereby identifying implicitly failed principle units that still exist in form but have lost their support conditions, overcoming the shortcomings of existing technologies that can only perform static verification for a single mission. By performing distortion dimension decomposition and intergenerational cumulative evaluation on distorted units, the system transforms principle distortion from a one-time judgment into cumulative data reflecting long-term evolutionary risks, and generates interconnect component optimization auxiliary decision-making results based on this, providing clear data basis for principle correction, inheritance constraints, and reuse control. Attached Figure Description

[0064] Other features, objects, and advantages of this application will become more apparent from the following detailed description of the non-limiting embodiments, taken with reference to the accompanying drawings:

[0065] Figure 1 A flowchart illustrating the steps of a method for optimizing the principle data of an interconnection component in a spacecraft electrical system, according to one embodiment, is shown.

[0066] Figure 2 A flowchart illustrating the steps of an embodiment of a method for acquiring data from interconnected components is shown.

[0067] Figure 3 A flowchart illustrating the steps of a cross-task inheritance path construction method according to an embodiment is shown.

[0068] Figure 4 A flowchart illustrating the steps of a cross-generational principle consistency verification method according to an embodiment is shown.

[0069] Figure 5 A flowchart illustrating the steps of a distortion accumulation assessment method according to one embodiment is shown. Detailed Implementation

[0070] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0071] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. Functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0072] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0073] Please see Figures 1 to 5 This application provides a method for optimizing the principle data of interconnection components in a spacecraft electrical system, including the following steps:

[0074] S1. Obtain interconnect component data; deconstruct the interconnect component data to obtain the principle unit data;

[0075] In one embodiment, the system obtains spacecraft mission data from a mission configuration source. This data includes mission number, configuration version, function start / stop table, redundancy strategy, and a shaving list. Based on this mission data, the system determines the scope of interconnect components involved in the current mission. All interconnect component ports appearing in the activation list are included in the analysis scope; interconnect components explicitly appearing in the shaving list are removed; and interconnect components marked as "must-protect links" in the redundancy strategy table are retained and marked even if they do not appear in the activation list. The system collects principle-level data for each interconnect component, including port information (such as port number, signal name, signal direction and type), connection relationships (such as mapping between signal source and destination ports), parameter declarations (such as rated values, upper limits, applicable modes, etc.), redundancy relationships (primary / backup settings, switching mechanisms), and constraint configurations (mutual exclusion, mode restrictions, etc.), while simultaneously recording the data source and corresponding version fingerprint information.

[0076] The system deconstructs the original data structure into principle unit data. Based on field attributes, the data is divided into interface signal classes, parameter assumption classes, redundant logic classes, and constraint dependency classes. For interface signal classes, the system constructs signal units at the port level as the smallest granularity and establishes connection edges based on the connection relationships between ports; if multiple ports share the same signal identifier, the system merges them into the same network identifier while preserving the port mapping relationship. For parameter assumption classes, the system transforms them into parameter entries with verification conditions, including the target object (e.g., port, network, or redundant logic), key attributes, and applicable scope. For redundant logic classes, the system identifies the primary / backup configuration and its triggering mechanism, and extracts mutual exclusion relationships as independent condition items. For constraint dependency classes, the system extracts text conditions into a structured condition list, clearly defining "if...then..." triggering relationships, such as requiring a certain type of connection to be enabled or avoiding concurrency within a specific mode or parameter value range. The system encapsulates all interface signals, parameter assumptions, redundant logic, and constraint dependencies into a set of principle units and establishes explicit reference relationships between them.

[0077] S2. Based on the principle unit data, construct cross-task inheritance paths and extract assumption constraints to obtain cross-task inheritance path data and assumption constraint data respectively.

[0078] In one embodiment, the system generates a unique evolutionary identifier for each principle unit. This identifier includes three parts: structural fingerprint, semantic fingerprint, and dependency fingerprint. The structural fingerprint generates a hash value based on the port set and connection relationship. The semantic fingerprint is formed by standardizing signal names, types, and directions (i.e., interface signal classes). The dependency fingerprint represents the set of parameter keys and constraint types (i.e., constraint dependency classes). When constructing cross-task unit mapping relationships, the system compares the principle units in the preceding and following tasks. If their structure and semantics are completely consistent, it is considered a hard match; if both the structural similarity and semantic consistency rate reach a set threshold, it is considered a soft match, forming an inheritance mapping. The system determines the inheritance behavior type based on the mapping results (including hard matching and soft matching), including full inheritance, trimmed inheritance, overriding inheritance, and refactoring inheritance, and outputs inheritance type labels. Full inheritance occurs when the port set is not reduced and the constraint / parameter key set is maintained. Trimmed inheritance occurs when the port set or connection edges are reduced, resulting in partial structural loss, but the functional semantics remain consistent. Overriding inheritance occurs when the structure is maintained, but the original parameters or constraints are replaced by other values ​​or expressions, such as modifying only default values ​​or logical conditions. Refactoring inheritance occurs when the structure changes significantly but the semantics remain (soft matching is valid and new connection edges appear). The system tracks and judges the carrying status of the original parameter assumptions and constraints. If the associated objects still exist in the task, they are marked as maintained; if objects are missing or connections are interrupted due to structural trimming, they are marked as weakened or lost. The system constructs a path graph containing inheritance behavior and carrying status attributes, using principle units as graph nodes and inheritance mappings as graph edges, to achieve cross-task structural logic evolution tracking and obtain cross-task inheritance path data.

[0079] For extracting assumption constraints, the system assigns structural role labels to signal units (interface signals) and redundant logic units / principle units, including source nodes, sink nodes, relay nodes, redundancy guarantee units, and isolation boundaries. The system identifies potential implicit prerequisite trigger points, including two categories: topology triggers (e.g., redundant logic exists but the number of backup links is insufficient) and parameter triggers (e.g., upper limit constraint parameters exist but the relevant ports are not enabled). For each trigger point, the system traces back its dependent object set along connection relationships and reference links, including ports, associated links, redundant logic, and related constraints. The system transforms the dependency set into formalized condition units, obtaining assumption constraint data. Each condition unit contains the prerequisites and violation conditions required for the assumption to be true. Prerequisites include logical expressions such as the existence, activation status, and connectivity of ports / units; for example, the redundancy assumption requires both the existence and activation of backup links. If the prerequisites of multiple condition units are highly overlapping and act on the same component or redundancy domain, the system can merge them; if mutually exclusive conditions are found, conflict marking is performed.

[0080] S3. Perform cross-generational principle consistency verification based on cross-task inheritance path data and assumption constraint data to obtain distorted unit data;

[0081] In one embodiment, the system performs cross-generational principle consistency verification based on the aforementioned cross-task inheritance path data and hypothesis constraint data to identify logical distortions introduced during structural evolution. The system segments the inheritance path graph according to task time sequence, constructing intergenerational inheritance segments composed of the evolutionary relationships of principle units between adjacent tasks. Each intergenerational segment consists of units from the previous task and corresponding units from the next task, along with inheritance type and path edge attribute information. For each intergenerational segment, the system searches for hypothesis constraints related to the structural unit. By comparing the scope and dependent objects of the hypothesis units, the system filters out the set of hypotheses related to the intergenerational segment and associates them with path information to form intergenerational hypothesis data. The system performs consistency verification on the hypotheses / intergenerational hypothesis data carried by each intergenerational segment. The system checks whether the preconditions defined in the hypotheses (such as whether dependent objects exist, are enabled, or remain connected) are satisfied in both generations of tasks. If an assumption is found to be satisfied in a previous generation of tasks but no longer satisfied in a subsequent generation, and this assumption is still explicitly defined in the subsequent generation (i.e., structurally retained but without supporting conditions), it is judged as a shell assumption. If the structural object on which this shell assumption depends plays a critical role, such as a redundancy protection path or signal source port, the system marks it as a cross-generational failure. The system aggregates and organizes all cross-generational failure information, classifies it according to structural units, and generates distortion unit data. This data records the generation segment in which each distortion unit first fails, the list of shell assumptions involved, and the type of structural loss corresponding to the failure (e.g., port loss, link interruption, or redundancy mechanism failure).

[0082] S4. Perform cumulative distortion assessment on the distorted unit data to obtain cumulative distortion data, which will be used to assist in the optimization of interconnected components.

[0083] In one embodiment, the system performs a cumulative distortion assessment across tasks based on identified distortion unit data. The system performs characterization analysis on each distortion unit, extracting representational indicators from multiple dimensions, including the number of generations the unit has traversed from its first failure to the current task (i.e., generational depth), the number of carrier objects involved in the failure and whether it contains critical structures (such as redundant paths, isolation boundaries, or parameter upper limit objects), the importance level of the assumption itself (whether it belongs to a critical system assumption), and the extent to which the distortion propagates downstream (i.e., the number of structures reachable by the unit in the inheritance graph). A distortion feature vector for each unit is constructed using these dimensions. Based on the inheritance path graph, the system concatenates the distortion feature vectors of each unit across generations to form a cross-generational evolutionary trajectory. For example, if no distortion is detected in a certain generation of tasks, this segment is still marked in the trajectory and filled with zero-intensity placeholder data, while also being labeled as a recovery segment. After constructing the distortion trajectory / cross-generational evolution trajectory, the system performs a cumulative distortion level assessment and generates operational suggestions. For example, if the same unit has missing key structural objects in two or more consecutive generations, its cumulative level is determined to be high; if structural recovery occurs in a generation, but the empty shell assumption still exists, the level is not lowered; if the downstream structural range affected by the unit continuously expands in two consecutive generations, its level is further adjusted upwards, such as from low to medium, or medium to high. Based on the above judgment logic, the system outputs the cumulative distortion level of each structural unit, an explanation of the cause, and suggested auxiliary processing measures. The auxiliary processing suggestions do not directly change the design scheme but are provided to designers for optimization reference. Suggestions include: interrupting the unit's inheritance path in subsequent tasks, reconstructing the assumption logic it undertakes, supplementing its missing redundant structures, or restoring overridden key parameter settings, etc.

[0084] Preferably, obtaining interconnect component data specifically involves:

[0085] S11. Acquire spacecraft mission data;

[0086] In one embodiment, the system extracts the configuration information of the current spacecraft mission from the mission configuration management platform or the mission initialization input file. The system only accepts data versions whose mission status is frozen or released, and automatically filters mission data in the planning or draft stage. The extracted mission configuration information includes at least the following: a unique identifier for the mission (task_id) to identify the mission instance; a configuration version number (config_ver) to track the specific version of the mission data; a function enable table (function_enable_map) to record the function module numbers and their statuses enabled in this mission; a redundancy policy table (redundancy_policy_table) to define the mission-level redundancy protection policy, including information on redundant links that must be forcibly retained; an interface pruning list (interface_prune_list) to list interfaces, ports, or signal items that are disabled according to mission customization rules; a mission execution mode (mode_profile), such as cold standby / hot standby, high power / low power consumption, and other operating characteristics; and a spacecraft platform model or variant identifier (platform_variant) for interconnect component screening and adaptation operations. The system encapsulates the above information into a unified mission context object (task_ctx) / spacecraft mission data.

[0087] S12. Determine the interconnection component range based on spacecraft mission data to obtain interconnection component range data;

[0088] In one embodiment, the system performs a filtering operation on all components in the standard principle component library based on the function activation table, interface shaving list, and platform model information in the spacecraft mission data to determine the scope of interconnect components applicable to the current mission. The system obtains a complete list of components from the standard principle component library. Each component contains a unique component identifier (comp_id), port information (including port number, direction, and signal type), a function tag (functional_tag, such as "power distribution," "interface connection," or "redundancy switching"), and an applicable platform model scope (platform_scope). The system filters components one by one as follows: if any port of a component appears in the interface shaving list in the mission data, the component is directly removed; if the function corresponding to the component's function tag is not enabled in the mission function activation table, the component is temporarily not included in the current mission scope; if a component appears in the mandatory retention link in the mission redundancy policy table, the component is forcibly retained even if its function is not enabled; if the applicable platform scope of a component does not include the platform model specified for the current mission, it is also not included. The system records each included or excluded component and its corresponding reason label, including inclusion due to feature enabling (enabled_function), mandatory inclusion due to redundancy protection (redundancy_protected), and exclusion due to interface pruning rules (excluded_by_prune). The system outputs a set of components that meet the requirements of the current task.

[0089] S13. Collect interconnect component data based on the interconnect component range data to obtain interconnect component data.

[0090] In one embodiment, the system performs principle data acquisition operations on each component in a defined set of components, with data sources including a component principle database and an integrated CAD design system. This acquisition process includes component structural definitions, connection relationships, design assumptions, redundant logic, and version traceability information, forming a component principle data set. The system acquires interface definition data for each component, including the signal name, signal direction (e.g., input, output, or bidirectional), electrical attributes (e.g., analog signal, digital signal, or power port), and the network number (net_id) of each port. The system extracts structural constraint information for the ports, such as isolation requirements, voltage level limits, and optional parameter ranges, such as current limits or matching conditions. The system acquires connection relationship data for the components, clarifying the signal transmission path between each pair of ports, recording it as a port pair and its network number; for connections involving special functions, such as channels for loop protection or automatic switching control signals, the system identifies and records them through annotation. In the assumption statement / design assumption section at the principle level, the system extracts the logical constraints and applicable prerequisites attached to the component design, such as a signal must come from a specific isolation source, or a logical condition is only valid in a specific operating mode. Relevant content can be obtained from the structured rule base or schematic annotation files. For components supporting redundant design, the system collects their redundant logic description information, including whether they have primary and backup channel configurations, primary and backup port groupings, and their switching trigger mechanisms, ensuring that the structure of the primary signal channel and backup path is clear, and extracting the auxiliary control signals they depend on. The system appends the source file path or number, data extraction timestamp, schematic version number or hash checksum, and the version of the currently used data extraction module to each component data item. During the acquisition process, the system automatically performs data integrity checks, including but not limited to whether all ports are defined, whether connections are closed, and whether redundant logic is fully defined, and records potential anomalies. The system outputs interconnect component data.

[0091] Preferably, the structured decomposition specifically includes:

[0092] Based on the interconnected component data, the principle type is divided to obtain the principle type data;

[0093] In one embodiment, the system parses and classifies the raw principle data of interconnected components. Based on field attributes and context labels, the principle information is divided into: interface signal type, parameter assumption type, redundant logic type, and constraint dependency type, thus forming principle type data. The system identifies interface signal type information, which mainly includes the definition information of component ports, such as port number, signal direction, signal name, and network number, used to describe the connection structure and signal flow between components. For fields with numerical range, applicable mode, or functional limitation descriptions, the system classifies them as parameter assumption type, such as a current limit of 2A, applicability to low-power mode, or need to meet insulation requirements, etc. This type of information expresses the usage limitations or performance boundaries of the component under specific conditions. Fields involving the relationship between primary and backup channels, switching mechanisms, or redundancy control conditions, such as primary channel being CH1, backup being CH2, or switching triggered when the voltage is below 4.5V, are identified as redundant logic type information, used to describe the system's redundant protection structure and its triggering conditions. For expressions with clear conditional dependencies, such as the logic that module B is available when module A is enabled, or function D is disabled when C exists, the system classifies them as constraint dependencies, used to represent the mutual dependence between functions or structural triggering conditions. During the classification process, the system automatically identifies and categorizes based on keywords, sentence structure, and their contextual semantics in the fields. The system outputs the principle type data for each component in a structured format, clearly defining the scope and quantity distribution of each type of information.

[0094] Based on the principle type data, interface signal relationship deconstruction, parameter assumption deconstruction, redundant logic deconstruction, and constraint dependency extraction are performed to obtain signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data, respectively.

[0095] In one embodiment, the system performs structured parsing of various types of information based on principle type data, completing interface signal relationship deconstruction, parameter assumption deconstruction, redundant logic deconstruction, and constraint dependency extraction operations respectively, thereby obtaining four types of principle unit data: signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data. During interface signal relationship deconstruction, the system generates structured signal units for the port information of each component. Each signal unit records its unique port identifier, standardized signal name (normalizing different abbreviations or aliases), signal direction (e.g., input, output, bidirectional), signal type (e.g., analog, digital, power), and its network number. Simultaneously, the system automatically determines the upstream and downstream connection structure of the port based on the connection relationship and infers its role in the network based on its connectivity and signal direction, such as signal source, signal sink, or relay node. During parameter assumption deconstruction, the system extracts the constraint information related to ports or signals from the principle description and uniformly converts it into a key-value pair structure. Each parameter assumption includes the target identifier, parameter key name (e.g., voltage, current limit, insulation class, etc.), value range (numerical range or Boolean value), applicable operating mode (e.g., low power mode), and the source location of the original declaration. For entries without specified applicable modes, the system defaults to general applicability. Third, the system identifies the primary and backup channel configurations and switching control logic within the components, extracts and generates redundant logic units. These units include the definitions of the primary and backup port groups, switching trigger conditions (e.g., voltage threshold, temperature change, or failure signal), switching modes (e.g., manual switching, automatic switching, or asynchronous switching), and the coverage of the redundancy structure (e.g., functional redundancy, power redundancy, etc.). If the backup channel configuration is incomplete or the switching conditions are not clearly defined, the system automatically marks it as incomplete redundancy. During constraint dependency extraction, the system parses the conditional trigger structures in the principle logic, standardizing logical descriptions such as "when condition A is met, object B is available / disabled" into constraint units. Each constraint unit contains a set of preconditions, the corresponding operational constraint effect (such as allowing use, prohibiting concurrency, requiring activation, etc.), the identifier of the constrained object, the applicable mode, and the constraint level (such as soft or hard constraints). Through this type of structured processing, the system can accurately identify cross-functional dependency logic in the schematic diagram, improving the automation and rigor of task configuration verification.

[0096] The signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data are encapsulated into principle unit data.

[0097] In one embodiment, the system generates a principle encapsulation object, or ComponentUnit, for each component, containing all types of principle units under that component. Here, signal_units represents the complete list of interface signal units for that component, param_assump_units represents the set of parameter assumption units, redund_logic_units contains redundant logic-related content, and constraint_units describes functional dependencies and condition constraints. In addition to these four basic data categories, the system also establishes logical reference relationships between various principle units and stores them uniformly in the refs field. The establishment of reference relationships follows these steps: When multiple parameter assumptions or constraints act on the same port, the system establishes a one-to-many or many-to-one association in the "assump→signal" mapping (assump / parameter assumption unit and signal / structure signal unit); if a redundant logic unit involves a specific primary / backup port configuration, its port reference is recorded in "redund→port" (redund / redundant logic and port / port identifier); when a constraint condition depends on the simultaneous fulfillment of multiple parameter assumptions, the system explicitly marks the corresponding many-to-many relationship in "constraint→assump" (constraint / functional dependency and condition constraint and assumption / parameter assumption unit). Through the above encapsulation, the system outputs principle unit data in component-based units.

[0098] Preferably, the construction of the cross-task inheritance path specifically involves:

[0099] S21. Generate the evolution identifier of the principle unit based on the principle unit data to obtain the evolution identifier data;

[0100] In one embodiment, the system generates a unique evolution identifier for each principle unit (including interface signal units, parameter assumption units, redundant logic units, and constraint dependency units) based on principle unit data, which is used to identify its functional equivalence and structural inheritance in multi-task or cross-generational structures. The evolutionary identifier consists of the following parts: First, the system generates a semantic fingerprint (semantic_hash), which is generated based on semantic features such as the unit's functional description, signal name, or redundancy configuration. All signal names and port identifiers must undergo semantic normalization beforehand to ensure that units with consistent semantics but different names can be correctly classified. This semantic normalization process involves standardizing the semantic fields such as signal names, parameter names, port identifiers, and constraint expressions involved in the principle unit before generating the semantic fingerprint (semantic_hash). Second, the system generates a structural fingerprint (struct_hash), which serializes the port connection structure of the principle unit and its topological relationship in the network using a graph structure, forming a unique structural feature to identify the inheritance characteristics of the physical connection layer. Third, the system generates a dependency profile (dependency_profile), which records the identifiers of other principle units that the unit depends on, such as dependent ports, parameter assumptions, or redundancy switching conditions. If the unit has no dependencies, this field can be omitted. Finally, the system records the origin component identifier (origin_comp_id), which identifies the source component to which the unit belongs. The system outputs a set of evolution identifier data.

[0101] S22. Perform cross-task unit mapping on the evolutionary identifier data to obtain inheritance mapping data;

[0102] In one embodiment, the system performs cross-task matching based on Evolutionary Identifiers (EIDs) for the set of principle units contained in two task versions (e.g., task A and task B), generating unit-level inheritance mapping relationships. The system identifies the correspondence between principle units across tasks: if the semantic fingerprints (semantic_hash) and structural fingerprints (struct_hash) of two principle units are completely identical, the system determines it as full inheritance, meaning that the unit in task B is a direct continuation of the unit in task A; if only the semantic fingerprints are the same, but the matching similarity between the structural fingerprints reaches a set threshold (e.g., the average similarity calculated between port set similarity and topology edit distance is not less than 0.8), it is determined as structural reconstruction inheritance, indicating that the unit has undergone structural adjustment while maintaining functional semantic consistency; based on structural matching, the system further analyzes the dependency overlap... To aid in the judgment, if the dependency profiles of two units have a high degree of overlap (e.g., above 75%), their inheritance credibility is enhanced. The inheritance credibility is generated as follows: if semantic consistency (semantic fingerprint similarity) is perfect, and both structural similarity and dependency overlap exceed a set threshold, the inheritance credibility is "high"; if semantic consistency is satisfied, but only one of structural or dependency overlap is satisfied, it is "medium"; if semantic consistency is not satisfied, or only one of the three is satisfied, it is "low"; if the structural differences are large and the dependencies have virtually no overlap, the system does not establish a mapping relationship. In cases where no matching object can be found in Task B for a principle unit in Task A, the system treats it as a newly added unit and temporarily excludes it from the evolution path graph construction to avoid introducing incorrect inheritance relationships. The system outputs inheritance mapping data, with each mapping record including the unique identifier of the corresponding unit in Task A and Task B, the matching type (e.g., full inheritance, structural reconstruction inheritance), and the matching similarity.

[0103] S23. Perform inheritance behavior type identification on the inheritance mapping data to obtain inheritance behavior type data;

[0104] In one embodiment, the system analyzes the differences in content between the principle units in Task A and Task B based on the generated inheritance mapping data, thereby identifying the inheritance behavior type of each mapping pair and outputting the inheritance classification result. The system compares and analyzes each mapping pair (inherit_pair), and the identification rules are as follows: if the principle unit has no changes in structural connections, parameter assumptions, and interface signals, it is determined to be a full inheritance; if some ports or connection relationships of the unit are pruned, but the overall functional semantics are still maintained, it is determined to be a pruned inheritance; if the structure remains the same, but the key parameter values ​​or assumptions change, such as the interface voltage limit being changed from 5V to 3.3V, it is determined to be an overridden inheritance; if there are significant adjustments to the structural connections, such as topology optimization or changes in physical distribution, but the semantics remain unchanged, it is considered a reconstructed inheritance; if the two are semantically similar but have completely different dependent objects, or if the assumptions in Task B are newly defined and have no reference relationship with Task A, the system identifies them as pseudo inheritance, and considers them as logically discontinuous units. The system uses component logical integrity and structural dependency consistency as criteria, combined with field-level comparison and dependency tracing analysis, to automatically output the inheritance behavior type for each pair of units. The system outputs inheritance behavior type data.

[0105] S24. Perform principle assumption bearing relationship tracing on inheritance behavior type data to obtain assumption bearing status data;

[0106] In one embodiment, the system tracks the carrying status of principle assumptions across tasks based on the inheritance behavior type data of principle units, and determines whether they are still supported by valid structural components in the target task, thereby forming assumption carrying status data. During processing, the system searches for all assumption items associated with the principle units in the source task (e.g., task A), including parameter constraints, working mode prerequisites, switching logic dependencies, etc. The system compares the inheritance unit structure in the target task (e.g., task B) to check whether the dependent objects that originally supported the assumption still exist, including ports, connection links, or redundant configurations. If the assumption itself still exists in task B, but the structural objects it depends on have been deleted or pruned (e.g., a critical port is missing), the assumption is determined to be an "empty shell assumption." If the objects that the assumption depends on still exist, but their connection relationships or semantic logic have changed (e.g., the primary and backup ports are swapped), it is considered a "weakened carrying." If the assumption content is still complete and the dependent objects have not changed, it is considered a "valid carrying." The system categorizes hypothesis carrier states into the following categories: valid: the hypothesis exists and its structural dependencies are complete; weakened: the hypothesis exists but some dependencies are missing; lost: the hypothesis exists but has completely lost its dependent objects; abandoned: the hypothesis has been deleted from the target task; reconstructed: the hypothesis's dependency structure has been replaced, and its functional semantics have shifted. The system outputs a list of corresponding missing dependency objects. Based on the above, hypothesis carrier state data is obtained.

[0107] S25. Construct a path graph based on inheritance mapping data, inheritance behavior type data, and assumed bearing state data to obtain cross-task inheritance path data.

[0108] In one embodiment, the system constructs a cross-task inheritance graph based on inheritance mapping data, inheritance behavior type data, and hypothesis carrier state data. This graph comprehensively records the structural evolution of principle units and changes in hypothesis carriers across multiple task versions. The inheritance graph uses principle units as nodes, each node bearing its assigned task identifier and component identifier. Inheritance relationships are represented by edges, with each edge corresponding to a single principle unit evolution across tasks. Each inheritance edge is appended with multiple attribute information, including the inheritance type extracted from inheritance behavior analysis (e.g., full inheritance, trimmed inheritance, reconstructed inheritance), a list of hypothesis carrier states obtained from hypothesis carrier tracking, a similarity score calculated by the system during matching (used to quantify inheritance strength), and a marker indicating whether the structure has changed (e.g., whether there is topology adjustment or port reconstruction). When constructing the inheritance graph, the system executes an edge labeling strategy based on the hypothesis carrier state: if multiple hypothesis failures or weakening states occur consecutively along an inheritance path, the system marks the path as a distortion propagation chain, indicating a risk of functional weakening or structural disconnection. If multiple tasks reuse or branch out the same structure, the system sets path branch points in the graph. The system generates cross-task inheritance path data, which includes a list of nodes and a set of inheritance edges.

[0109] Preferably, the assumption constraint extraction specifically involves:

[0110] Structural role data is obtained by parsing the principle unit data;

[0111] In one embodiment, the system performs structural role analysis on the structured principle unit data, including signal units, redundant logic units, and their related port nodes, to identify the node types that undertake key connection or logical functions in the overall system. Based on signal directionality and network topology, the system automatically determines the structural role of each port or unit, including: if a port is an output type and only has outgoing connections in the network (i.e., out-degree greater than zero, in-degree zero), it is identified as a source node, such as a main power supply port or power module output port; if a port is an input type and only has receiving connections (in-degree greater than zero, out-degree zero), it is identified as a sink node, used for control inputs or sensor sampling interfaces; if a port is bidirectional or its connections simultaneously have input and output relationships, the system identifies it as a relay node, including communication interfaces or serial signal paths. For primary or standby switching ports appearing in redundant logic units, the system marks them as redundant split points. These ports are the starting nodes of redundant paths and undertake the initiation control function of primary / standby switching. If a port is connected to multiple networks but lacks explicit constraint logic, such as a grounding terminal, shielded port, or shared reference point, the system identifies it as an isolation edge point, used to mark system boundaries or noise suppression interfaces. The system outputs the structural role identifier corresponding to each port, forming structural role data.

[0112] Implicit prerequisite trigger points are identified in the structural role data to obtain implicit prerequisite trigger point data;

[0113] In one embodiment, the system automatically identifies structural dependencies that exist but are not explicitly modeled based on structural role data and their connection context in the schematic diagram, forming implicit prerequisite trigger point data to supplement potential constraints and assumptions in the system's schematic logic. Specifically, during the identification process, the system applies a series of structural rules to analyze the schematic units. For example, when a port identified as a redundant split point has a corresponding spare branch that is not configured or is inactive, the system considers the redundant structure to lack integrity, thus triggering an implicit dependency on the redundancy premise, and recommends subsequently adding the redundant link or clarifying its configuration conditions. When an isolation edge connects to multiple highly sensitive inputs without any isolation components (such as filters or buffers) for signal protection, the system identifies it as an "isolation capability dependency" trigger point, indicating potential risks in signal interference or electrical isolation. When a sink node relies solely on a single upstream path and has no alternative path providing redundancy or failover capability, the system triggers a "path integrity assumption," recommending an assessment of its structural robustness and the necessity of alternative paths. Each trigger point data includes the trigger type, specific location (such as port number or component identifier), trigger reason description, and a list of related units that are recommended to be checked.

[0114] Based on the implicit premise trigger point data, the principle unit data is reverse-bound to the hypothetical dependency object to obtain the hypothetical dependency object data;

[0115] In one embodiment, the system performs a reverse dependency parsing operation based on the identified implicit premise trigger point data, conducts a backtracking analysis of the structural composition in the principle unit, thereby constructing the binding relationship between the hypothesis and its dependent objects, and generating hypothesis dependency object data. The system performs a source-tracing analysis on the principle logic corresponding to each trigger point, identifying the structural elements necessary for the trigger premise to be valid, covering multiple dependency types, including but not limited to port dependencies, i.e., certain input or output ports must exist and be enabled; structural link dependencies, i.e., the signal path between the trigger point and its target structure must maintain effective connectivity, and the relevant intermediate interfaces, converters, or relay nodes must all have complete functionality; redundant logic dependencies, i.e., the primary and backup structures to which the trigger point belongs must maintain configuration integrity and have switching capabilities; and parameter constraint dependencies, i.e., the parameter values ​​(such as current, voltage, etc.) configured on the upstream key ports must meet preset constraints. The system categorizes and organizes each type of dependency and outputs structured dependency object binding information. Each record includes the corresponding hypothesis identifier, trigger source location, specific dependency object list, and dependency type label corresponding to each object. Through this binding process, the system establishes an explicit mapping between the hypothetical logic and the principle structure, and obtains the hypothetical dependency object data.

[0116] Based on the hypothesis dependency object data, hypothesis validity condition data is obtained by processing the hypothesis validity conditions.

[0117] In one embodiment, the system processes the structural elements upon which each hypothesis depends, based on the hypothesis dependency object data, generating hypothesis validity condition data for automatic verification and logical reasoning, supporting task configuration consistency judgment and principle hypothesis tracing. The system transforms each dependency object and its type into a standardized logical expression structure, forming precondition statements. For example, when a hypothesis depends on the existence and activation of a specific port, the system generates corresponding "port exists" and "port is activated" conditions; if the hypothesis's validity depends on maintaining connectivity between two ports, the system constructs a "port is connected" condition; if a parameter value depends on being within a specific range, the system generates a "parameter matches" condition; if redundant structures are involved, a "redundancy integrity" judgment condition is generated, requiring both primary and backup links to be fully configured. The system combines these conditions using logical AND relationships to form a set of hypothesis validity conditions, and adds a brief description to each hypothesis, explaining its applicable background and functional intent. For example, a hypothesis for redundant power supply links might include the following condition set: port P12 must exist, port P13 must be activated, and the redundant structure corresponding to RedundUnit_5 must be fully configured. The system outputs hypothesis validity condition data, recording the identifier of each hypothesis, a list of conditional expressions that must be satisfied, and an explanation of their meaning.

[0118] Cross-cell hypothesis merging is performed on the hypothesis validity condition data to obtain hypothesis constraint data.

[0119] In one embodiment, the system categorizes and integrates the generated hypothesis validity condition data. Based on logical similarity and scope of application, the system merges and standardizes the hypothesis conditions at the component or task level to form hypothesis constraint data. The system compares the condition sets of different hypothesis entries. If the overlap rate between their logical condition sets (require_all) reaches or exceeds 80%, and the objects of application are within the same component or functional domain, the system merges them into hypothesis constraint entries, assigns a new identifier to the merged entries, and records the list of their source hypotheses. If there are only minor differences in parameter ranges between the merged candidates, such as voltage limits of 5V and 4.5V, the system breaks down these differences into multiple condition items and lists them separately, retaining a description of the parameter differences in the hypothesis constraints. During the merging process, the system also performs conflict identification. If two hypothesis entries apply to the same structural unit (such as a redundant unit) but are logically contradictory (e.g., one requires the port to exist while the other requires it not to), the system identifies them as mutually exclusive hypotheses and outputs a dedicated conflict record entry, including the identifier of the conflicting hypothesis and a description of the conflict type. The system generates assumption constraint data, including a unique number for each constraint, its scope of application (e.g., the corresponding component), the integrated set of logical conditions, the constraint level (e.g., hard constraints or optional suggestions), and source merging information.

[0120] Preferably, the cross-generational principle consistency verification specifically includes:

[0121] S31. Segment the inheritance path based on the cross-task inheritance path data to obtain the generational inheritance segment data;

[0122] In one embodiment, the system, based on a cross-task inheritance path graph (G_inherit), decomposes the evolution path of the principle unit according to the time sequence of the tasks, forming structured intergenerational inheritance segment data. The system clearly defines the segment-by-segment inheritance relationship of the principle unit between different task versions. The system groups each pair of adjacent tasks (e.g., task Tk and task Tk+1) and divides each principle path from the previous task to the next task into an intergenerational inheritance segment. Each inheritance segment records the unique identifier of the principle unit in the preceding and following tasks (e.g., from_unit and to_unit), the inheritance behavior type (e.g., full inheritance, trimmed inheritance, overriding inheritance, etc.), and the summary information of the carrying status of each associated hypothesis in the segment (e.g., a hypothesis is "valid," "weakened," or "missing" in the segment). During processing, if a principle unit is not identified as an inheritance object in a later task (i.e., there is a generational gap), no inheritance segment is generated; however, when the same unit is inherited by multiple units in a task, the system records each branch path independently. The system attaches corresponding task time information and component affiliation identifier to each inheritance segment. The system outputs intergenerational inheritance segment data, recording the unique identifier of each segment, task source and goal, inheritance type, and assumptions about changes.

[0123] S32. Map the hypothesis constraint data to the intergenerational inheritance segment data to obtain the intergenerational hypothesis data;

[0124] In one embodiment, the system maps and verifies the assumption constraints associated with the starting unit in each inheritance path segment based on intergenerational inheritance segment data, identifies their validity status in the target task version, and thus generates intergenerational assumption data. The system extracts assumption entries (HUnits) associated with the starting unit (from_unit) of the inheritance segment from the assumption constraint library and analyzes their condition sets. Based on the dependency conditions of each assumption, the system determines whether it still has the corresponding structural support in the target unit (to_unit). For example, if the assumption condition contains "EXIST(Px)" or "ENABLED(Py)", the system will verify whether the corresponding port still exists in the target task and is in an enabled state; if it contains "COMPLETENESS(RedundUnit_A)", the system will determine whether the relevant redundant structure is configured completely and meets the switching conditions. If the target unit still explicitly declares the assumption, but its dependent objects are partially missing, the system marks it as "bearing weakening"; if the assumption is still declared in the target unit, but all dependent structures are missing, it is marked as "empty shell assumption"; if the dependent objects remain complete, it is marked as "effective bearing". The system synchronously records all missing dependency objects. The system outputs a list of generational hypothesis data, where each record corresponds to a mapping relationship between an inheritance segment and its associated hypothesis, including the inheritance segment number, hypothesis identifier, current carrying status, and a list of missing dependencies.

[0125] S33. Based on the intergenerational hypothesis data, determine the cross-generational consistency failure and obtain cross-generational distortion identification data;

[0126] In one embodiment, the system performs logical consistency analysis on the carrying status of principle units in multi-task versions based on generational hypothesis data, determines whether their effectiveness is maintained during structural evolution, thereby identifying cross-generational failure issues and generating cross-generational distortion identification data. The system focuses on the following three types of failure scenarios: First, when a hypothesis is still explicitly declared in the target unit (to_unit) of the inheritance segment, but all its dependent structures have been lost in the current task, the system determines it as a "shell hypothesis formation," that is, the hypothesis has lost structural support but still retains logical declarations, leading to misconfiguration or functional abnormalities. Second, if some dependent objects of the hypothesis still exist structurally, but are disabled, lose network connectivity, or are covered by other logical structures (such as parameter replacement or redundancy switching logic changes), the system identifies it as a structural support breakage failure, indicating that its logical basis is no longer continuous, and although the structure is visible, it no longer has functional continuity. Third, when the same assumption is weakened in two or more consecutive inheritance segments, the system considers this as a consistency degradation problem caused by continuous weakening, that is, the principle structure is continuously weakened in the evolution, evolving into a failure or distortion node. Each cross-generation distortion identification record includes the failure unit identifier, the corresponding inheritance segment number, the failure assumption number, the specific failure type (such as empty shell, breakage or weakening degradation), the scope of impact (such as affecting redundant links, parameter logic, etc.), and the cause description (such as missing backup path, port disabling, etc.).

[0127] S34. Aggregate the cross-generational distortion identifier data to obtain distortion unit data.

[0128] In one embodiment, the system aggregates failure information according to the principle unit dimension based on the identified cross-generational distortion identifier data, generating distortion unit data (DriftUnit) to describe the key structural stability issues of the system during multi-task evolution and to assist in forming a distortion diagnostic map at the principle level. During the aggregation process, the system uses the principle unit identifier (unit_id) as the core, integrating all distortion records appearing across different tasks and extracting multiple key dimension information. The system identifies the task node where the principle unit first experiences distortion, marking it as `first_failure_task`; the system calculates the generational span of the distortion's continued propagation in subsequent tasks, i.e., `failure_span`, to measure the breadth of the problem's evolution. For each distortion unit, the system simultaneously counts all involved hypothesis identifiers and their corresponding failure types, such as "empty shell hypothesis" and "load-bearing weakening," uniformly categorized into the `hypothesis_involved` field. The system calculates the structural load-bearing missing rate (structure_missing_rate) of this unit during distortion propagation, representing the proportion of its dependent structures that are pruned, disabled, or fail. After combining all distortion characteristics, the system assigns a diagnostic level to each cell, categorized into three levels: minor deviation, moderate degradation, and critical fault. The system then generates data on the distorted cells.

[0129] Preferably, the cross-generational consistency failure determination specifically involves:

[0130] Based on the intergenerational hypothesis data, hypothesis-carrying object binding is performed to obtain object binding data;

[0131] In one embodiment, the system performs structural dependency tracking analysis on each hypothesis unit (HUnit) based on intergenerational hypothesis data, identifies the key carrier objects on which its validity depends, and constructs binding relationship data between the hypothesis and the carrier objects. The system automatically identifies the structural entities involved according to the expression in the hypothesis conditions and binds them according to the following rules: when the hypothesis conditions contain the expression "EXIST(Px)" or "ENABLED(Px)" (meaning "port Px exists" or "port Px is enabled"), the system binds the relevant port Px as a carrier object; when the condition is "COMPLETENESS(RedundUnit_Y)" (meaning "redundant unit RedundUnit_Y constitutes a complete configuration"), the system binds not only the redundant unit itself, but also its configured primary and backup ports and associated switching logic signals; if the condition contains "CONNECTED(Pa,Pb)" (i.e., port Pa and port Pb are connected), the system binds the corresponding starting port and target port, and optionally binds the network connection path between them (such as relay nodes and connection edges) to represent path integrity requirements. All bound objects are recorded in a structured format, including object type (such as port, redundant unit, connection edge), unique identification information, and an indication of whether the object is enabled in the current task. The object binding data output by the system explicitly identifies the set of structural units that each hypothesis depends on, forming an explicit association between hypothesis and structure.

[0132] Based on the cross-task inheritance path data, the object binding data is identified to determine its persistence status, and thus the persistence status data is obtained.

[0133] In one embodiment, the system performs structural state analysis on the target unit (to_unit) in each generation inheritance segment based on cross-task inheritance path data. Combined with previously generated object binding data (AssumpBinding), it identifies the persistence status of the structural objects that each hypothesis depends on in the current task version, generating persistence status data. The system checks the actual configuration of each hypothesis-bound object in the task where the target unit is located. If a bound object is a port type and is not identified in the current component principle data, the system marks it as "missing," indicating that the object has been deleted or pruned by the structure. If the object exists but is configured as disabled (e.g., disabled in the task pruning list), the system marks it as "disabled." If the object exists and is in a normal enabled state, it is marked as "active," indicating that the structure supports it effectively. If the object is a redundant unit or dependency path, and although the structure itself exists, its composition or connection is incomplete (e.g., missing spare ports, unconfigured switching conditions), it is marked as "incomplete," indicating that the structure support conditions are not met. The system outputs the above status information in the form of a combination of hypothesis and inheritance segment, forming a structural carrying status list, thus obtaining persistence status data.

[0134] Based on the existing status data, the continuity of the load is verified to obtain abnormal load continuity data;

[0135] In one embodiment, the system performs continuity analysis on the assumption carrying status in each generation inheritance segment based on structural persistence status data. This determines whether the principle assumptions continue to have a structural basis for validity during task evolution, identifies potential carrying interruptions or logical gaps, and generates continuity anomaly data. The system checks the status of all bound structural objects for each assumption in the inheritance segment. If all objects are in an "active" state, the system considers the assumption to have complete structural support within that generation segment and marks it as "normal carrying." If one or more critical dependent objects are in a "missing" or "incomplete" state, meaning the structure is pruned or incomplete, the system classifies the assumption as "carrying interrupted." If some objects are "disabled," the system will consider the applicable mode (mode_scope) set for the assumption to determine whether it is reasonably disabled in the current task context to avoid misjudgment. If the system finds that an assumption carried normally in a previous task, but the related dependent structures are lost or unreachable in a subsequent task, while the assumption content is still explicitly declared and not adjusted, the system marks it as a continuity anomaly, indicating that there is a risk of logical disconnection and requiring attention. The system outputs bearer continuity anomaly data in the form of a structured list. Each record includes the inherited segment number, hypothesis identifier, anomaly type (such as bearer interruption or continuity anomaly), and related lost object information.

[0136] Based on the continuous abnormal data of the bearing, the empty shell hypothesis is identified and determined, and the empty shell hypothesis identification data is obtained;

[0137] In one embodiment, based on identified abnormal data regarding continuity, the system further verifies the consistency between the assumed content and the actual structural support to determine whether it constitutes an empty shell assumption, thereby generating empty shell assumption identification data. During the determination process, the system performs the following checks: confirming that the assumption is still referenced in the principle unit of the target task or automatically continued through inheritance; determining whether all dependent structural objects (such as ports, connections, redundant logic) have been pruned, disabled, or invalidated, paying attention to whether critical structures are completely or partially lost; checking whether the assumption is explicitly marked as "redefined" or "applicability changed"; if no such marking exists, the system defaults to its inherited state; if the lost dependent structures only involve non-core objects (such as redundant channels rather than the primary power supply link), the system classifies it as "partially empty shell," otherwise as "completely empty shell." The system outputs empty shell assumption identification data including the principle unit number to which the assumption belongs, the assumption identifier, the empty shell state type (such as fully_empty or partially_empty), and the scope of the invalidated functional domain (such as redundant links, control paths, etc.).

[0138] Based on the empty shell hypothesis identification data, cross-generational failure propagation is confirmed for cross-task inheritance path data, resulting in cross-generational distortion identification data.

[0139] In one embodiment, the system uses empty shell hypothesis identification data to perform logical backtracking and path tracing along the cross-task inheritance path graph to determine whether a specific hypothesis persists in a failed state across multiple task versions. This identifies whether it constitutes cross-generational failure propagation and generates cross-generational distortion identification data to mark key units in the schematic diagram that have a risk of structural distortion propagation. During processing, the system identifies the following three types of distortion propagation modes: First, continuous empty shell state continuation, where the hypothesis exists in an "empty shell state" in two or more consecutive task versions (i.e., propagation length ≥ 2), such as being inherited from task T1 to T2 and then retained to T3, without restoring structural support; Second, path branch propagation, where the empty shell hypothesis propagates to multiple subsequent units in the schematic structure branch path (propagation branch number ≥ 2), indicating that it has redundant and invalid logical inheritance in multiple task configurations; Third, sensitive structural dependency, where the hypothesis depends on structures such as redundant links, isolation boundaries, or control interfaces. Once distortion continues to propagate, it will have a substantial impact on the overall stability of the system. When any of the above conditions are met, the system considers the hypothesis and its underlying principle unit to have a risk of cross-generational structural distortion, and records its propagation path, scope of impact, and risk level, such as "high risk / high" (e.g., propagation depth ≥3 and involving the main structure), "medium risk / mid" (e.g., propagation branches are numerous but the scope of impact is limited), and "low risk / low" (e.g., it is a non-critical path or has been partially repaired). The system also indicates the original unit number, relevant hypothesis identifier, list of inherited segments of the impact, distortion type, and the assessed risk level (e.g., high, medium, low).

[0140] Preferably, the cumulative distortion assessment specifically includes:

[0141] S41. Perform distortion dimension decomposition on the distorted cell data to obtain distorted feature data;

[0142] In one embodiment, the system performs a detailed analysis of the evolution of each distorted unit from three dimensions: structure, logic, and timing, based on the identified distorted unit data, and extracts distortion feature data. In the structural dimension, the system counts the number of structural objects bound to each distorted unit that have been pruned or failed, assesses whether its dependency paths are broken, and calculates the number of critical path interruptions. For redundant logically related units, the system evaluates the integrity ratio of redundant chains, forming a redundancy structure completeness index. In the logical dimension, the system counts the number of empty shell assumptions involved in the unit and whether there are any logical conflicts with other assumptions. The conflict intensity is analyzed by the system through a hypothesis graph, which calculates the conflict density and conflict level between hypotheses to form a conflict score. The hypothesis graph is a directed graph model that describes the logical dependencies and mutual exclusion relationships between hypotheses, where nodes represent specific hypotheses and edges represent dependencies, coverage, or mutual exclusion relationships. The conflict score is calculated according to the following rules: conflict density ≥ 60% is marked as "high-density conflict"; conflict density between 30% and 60% is marked as "medium-density conflict"; conflict density < 30% is marked as "low-density conflict"; high-risk behaviors such as main control link conflict, cross-module mutual exclusion, and coverage failure are marked as "severe conflict"; moderate behaviors such as inconsistent references and inherited redundancy are marked as "general conflict"; and situations with only mild redundancy or no explicit priority declaration are marked as "minor conflict". The system combines the conflict density level and the conflict level to generate a conflict score label. In terms of time sequence, the system extracts the task number where the distortion first occurred in the distorted unit, the duration of the distortion in the task evolution (measured by the number of task versions), and the task number where the distortion was most recently recorded in the unit. The system outputs distortion feature data, recording the structural missing rate, logical failure degree, and temporal evolution characteristics of each distorted unit.

[0143] S42. Based on the cross-task inheritance path data, construct the intergenerational distortion accumulation trajectory of the distortion feature data to obtain the distortion accumulation trajectory data;

[0144] In one embodiment, the system tracks and analyzes the evolution of distorted units across different task versions based on cross-task inheritance path data, constructs the intergenerational distortion accumulation trajectory of distorted units, and generates distortion trajectory data. Based on the cross-task inheritance graph, the system starts from the principle unit where distortion first appears and traces its evolution path hop-by-hop in subsequent tasks. Each inheritance relationship between tasks constitutes a time segment. The system extracts corresponding distortion feature information at each task node, including indicators such as whether it is an empty shell assumption, structural loss rate, and logical conflict strength, and records them in chronological order to form a trajectory sequence. During trajectory construction, the system can identify and mark various distortion evolution states. For example, when a principle unit's structure recovers normally in an intermediate task but distortion reappears later, this task segment is marked as a "recovery failure segment," indicating that the system's structural recovery strategy has failed to take stable effect. If the structure is permanently pruned in a task version and there is no possibility of structural recovery in the future, it is marked as an "irreversible segment," indicating that the path structure has undergone irreversible evolution. The system outputs distorted cumulative trajectory data indexed by cell number, which includes a list of the evolution states of the cell at each task node.

[0145] S43. Perform distortion accumulation processing on the distortion accumulation trajectory data to obtain distortion accumulation data for auxiliary operation of interconnection component optimization.

[0146] In one embodiment, based on the aforementioned cumulative distortion trajectory data, the system performs cumulative processing on the structural and logical degradation risks formed by the principle unit across multiple task generations, and outputs a distortion score result, i.e., cumulative distortion data. The system identifies units in the system with high distortion levels and potential threats to functional stability, and provides priority suggestions for optimization operations such as structural repair and redundancy reconfiguration. The system accumulates distortion characteristic indicators for each unit across task nodes in chronological order, based on its intergenerational trajectory. These indicators include structural loss and logical anomaly levels. The logical anomaly score comprises three factors: empty shell hypothesis factor, hypothesis conflict factor, and logical redundancy factor. Regarding empty shell hypotheses, if a distorted unit has at least one empty shell hypothesis, the system assigns a base score. When an empty shell hypothesis propagates for more than two generations during task evolution, the system considers it persistently invalid and adds an extra score. Regarding hypothesis conflicts, the system determines whether there are mutually exclusive or logical contradictions among multiple hypotheses in the unit. If structural mutual exclusion conflicts or coexistence of hypotheses without applicable constraints occur, the corresponding score is increased. Regarding logical redundancy, if a hypothesis is valid but the supporting structural object it depends on has been pruned, disabled, or lost its meaning, the system also identifies this as an anomaly and records it in the score. All of the above factors can be accumulated based on their satisfaction level. The system assigns different weighting factors to each distortion type, and calculates the overall distortion intensity score for the unit through weighted calculation or direct addition without weights and normalization. A score between 0 and 1 indicates the overall degradation level of the unit within the task inheritance path. Based on the score range, the system categorizes units into different risk levels. For example, units with a score below 0.3 are considered low-risk and can be delayed; units with scores between 0.3 and 0.7 are marked as observation targets; and units with scores above 0.7 are classified as high-risk, and the system prioritizes optimization tasks such as structural review and redundancy refactoring for them. The system-generated cumulative distortion data (DriftAggScore) includes the unit number, distortion score, risk level label, and corresponding optimization suggestions.

[0147] Preferably, the optimization auxiliary operation for interconnected components specifically includes:

[0148] Distortion type identification data is obtained by classifying the cumulative distortion data based on the cumulative distortion data;

[0149] In one embodiment, after scoring, the system classifies risk levels based on the score and further retrieves the original structural degradation information, hypothesis validity indicators, and logical conflict data to perform distortion type analysis on the scoring results. The system combines the analysis results from dimensions such as structural degradation, hypothesis validity, and logical conflict information to construct distortion type determination rules. Based on the preset classification criteria, the system can classify distortion units into the following four categories: Type T1 (Structural Support Failure Distortion): This type of unit is characterized by missing key structural components, cut-off interface ports, or severely damaged structural closure of the support path, resulting in its inability to maintain the expected principle support relationship. It appears in scenarios where redundant chains fail or connection logic is not closed. Type T2 (Abuse of Empty Shell Hypothesis Distortion): This refers to hypotheses that are repeatedly inherited across multiple task generations but whose binding structures have been lost, forming a continuous empty shell propagation phenomenon, accompanied by a high cumulative distortion score. Type T3 (Hypothesis Conflict Distortion): The system detects multiple hypotheses existing concurrently in the same task unit, but the structural support conditions they depend on are mutually exclusive, leading to logical conflicts. Type T4 (Legacy Logic Redundancy): This refers to hypotheses that are still valid in the task, but the corresponding physical logic has no practical scheduling value, belonging to the case of historical legacy structures that have not been cleaned up. The system outputs distortion type identification data in key-value pairs, recording the distortion type code and corresponding Chinese label for each unit.

[0150] The distortion type identifier data is filtered for units of interest to obtain units of interest data.

[0151] In one embodiment, the system, based on the aforementioned distortion type identification data and combined with analysis indicators from multiple task and structural dimensions, filters all distorted units and extracts data on units of interest that require key monitoring or priority optimization. During the filtering process, the system considers the following dimensions: First, distortion level, i.e., the cumulative distortion intensity exceeds a preset threshold (e.g., reaching a high-risk level); second, distortion type, such as structural load-bearing fracture (T1) or shell assumption abuse (T2), indicating higher structural impact; third, the structural level and task criticality of the component, such as being located in core functional domains like power modules or bus distributors, or carrying critical links in the main electrical topology, thus increasing its filtering priority; fourth, the system checks whether the unit has repair records in the last three generations of tasks, and if it remains unrepaired and the distortion persists, it is marked as requiring urgent handling. The system outputs data on units of interest, recording the unit number, distortion type, risk level, and associated component information.

[0152] Based on cross-task inheritance path data and assumption constraint data, distortion root cause correlation analysis is performed on the data of the units of interest to obtain distortion root cause correlation data.

[0153] In one embodiment, the system performs a root cause correlation analysis on the selected units of interest based on cross-task inheritance path data and hypothesis constraint data, outputting the cause and path source of the distortion state. The system constructs an evolution chain of the units of interest in each generation of tasks, forming a hypothesis-carrying chain graph. Each node corresponds to the state data of the unit in different tasks, and each edge represents the structural evolution behavior during the inheritance process, such as structural pruning, disabling, reconstruction, or automatic inheritance. The system combines hypothesis constraint data to compare the structural state of each path segment with its bound hypothesis content, identifying whether there are cases where dependent objects are deleted, disabled, or replaced in a task, but the corresponding hypothesis is not revised synchronously. If the system detects that the hypothesis still references a pruned or invalid structural node, the path segment is marked as un-sourced; if, in multiple path branches, the hypothesis is repaired in some tasks but remains distorted in others, the system marks it as branch contamination, indicating that the distortion has caused inconsistent diffusion during path propagation. The system identifies the task node that first causes the structural dependency break as the distortion inflection point.

[0154] Optimization strategies are generated based on the root cause correlation data of the distortion, resulting in optimization strategy data.

[0155] In one embodiment, based on the aforementioned distortion root cause correlation data and combined with the built-in optimization strategy library, the system automatically generates targeted repair and adjustment suggestions for each unit with a distortion root cause, forming optimization strategy data. The system analyzes the root cause type of the distorted unit, such as hypothesis failure caused by structural trimming, lack of applicable domain limitation for hypothesis conflicts, and pollution spread caused by multi-generation reuse, and matches preset strategy rules according to the corresponding type. For example, for cases where empty shell hypotheses are not updated due to structural trimming, the system recommends deleting the corresponding hypothesis, converting it into a weak constraint, or completing the structural link it depends on; for problems caused by logical inconsistencies due to hypothesis conflicts, the system suggests adding hypothesis application conditions, introducing mutual exclusion logic restrictions, or splitting hypothesis content; for path pollution caused by multi-generation task reuse, the system may suggest interrupting the inheritance path or setting revision restrictions at the inheritance entry point. The optimization strategy data output by the system includes the suggestion content, the corresponding strategy type (such as structural repair, hypothesis weakening, path blocking, etc.), and the priority level of the suggested execution. This strategy result can be integrated into the system's design review module or automatically synchronized to the schematic modeling tool for prompts.

[0156] Preferably, this application also provides a spacecraft electrical system interconnection component principle data optimization system for executing the spacecraft electrical system interconnection component principle data optimization method described above. The spacecraft electrical system interconnection component principle data optimization system includes:

[0157] The structure deconstruction module is used to acquire interconnect component data; based on the interconnect component data, it performs structure deconstruction to obtain the principle unit data;

[0158] The principle inheritance evolution analysis module is used to construct cross-task inheritance paths and extract assumption constraints based on principle unit data, resulting in cross-task inheritance path data and assumption constraint data, respectively.

[0159] The cross-generational principle consistency verification module is used to perform cross-generational principle consistency verification based on cross-task inheritance path data and assumption constraint data, and obtain distorted unit data.

[0160] The distortion cumulative evaluation module is used to perform distortion cumulative evaluation on the distortion unit data to obtain distortion cumulative data, which is used to assist in the optimization of interconnect components.

Claims

1. A method for optimizing the principle data of interconnection components in a spacecraft electrical system, characterized in that, Includes the following steps: Obtain interconnect component data; deconstruct the interconnect component data to obtain principle unit data; Based on the principle unit data, cross-task inheritance path construction and hypothesis constraint extraction are performed to obtain cross-task inheritance path data and hypothesis constraint data, respectively. Based on cross-task inheritance path data and assumption constraint data, cross-generational principle consistency verification is performed to obtain distorted unit data. The distortion of the distorted unit data is evaluated to obtain the cumulative distortion data, which is then used to assist in the optimization of interconnect components. The cross-task inheritance path construction specifically involves generating a unique evolutionary identifier for each principle unit. This identifier comprises three parts: structural fingerprint, semantic fingerprint, and dependency fingerprint. The structural fingerprint generates a hash value based on the port set and connection relationship. The semantic fingerprint is formed through standardized signal names, types, and directions. The dependency fingerprint represents the set of parameter keys and constraint types. When constructing cross-task unit mapping relationships, the system compares the principle units in the preceding and following tasks. If their structure and semantics are completely consistent, it is considered a hard match. If both the structural similarity and semantic consistency rate reach a set threshold, it is considered a soft match. The system performs inheritance mapping; based on the mapping result, it determines the inheritance behavior type, including full inheritance, trimmed inheritance, overriding inheritance, and refactoring inheritance, and outputs inheritance type labels. Full inheritance means that the port set is not reduced and the constraint / parameter key set is maintained; trimmed inheritance means that the port set or connection edge is reduced and the structural part is missing, but the functional semantics are still consistent; overriding inheritance means that the structure is maintained, but the original parameter or constraint content is replaced by other values ​​or expressions; refactoring inheritance means that the structure changes significantly but the semantics are maintained. The system tracks and judges the carrying status of the original parameter assumptions and constraints. If the associated objects still exist in the task, they are marked as maintained. If an object is missing or a connection is interrupted due to structural pruning, it is marked as weakened or lost. The system uses principle units as graph nodes and inheritance mappings as graph edges to construct a path graph containing inheritance behavior and carrying state attributes, realizes the evolution tracking of cross-task structural logic, and obtains cross-task inheritance path data.

2. The method for optimizing the principle data of interconnection components in a spacecraft electrical system according to claim 1, characterized in that, The specific steps for obtaining interconnect component data are as follows: Acquire spacecraft mission data; The interconnect component range is determined based on spacecraft mission data, resulting in interconnect component range data. Interconnection component data is obtained by collecting interconnection component data based on the interconnection component range data.

3. The method for optimizing the principle data of interconnection components in a spacecraft electrical system according to claim 1, characterized in that, The structural deconstruction specifically includes: Based on the interconnected component data, the principle type is divided to obtain the principle type data; Based on the principle type data, interface signal relationship deconstruction, parameter assumption deconstruction, redundant logic deconstruction, and constraint dependency extraction are performed to obtain signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data, respectively. The signal unit data, parameter assumption unit data, redundant logic unit data, and constraint dependency unit data are encapsulated into principle unit data.

4. The method for optimizing the principle data of interconnection components in a spacecraft electrical system according to claim 1, characterized in that, The specific process of extracting assumption constraints is as follows: Structural role data is obtained by parsing the principle unit data; Implicit prerequisite trigger points are identified in the structural role data to obtain implicit prerequisite trigger point data; Based on the implicit premise trigger point data, the principle unit data is reverse-bound to the hypothetical dependency object to obtain the hypothetical dependency object data; Based on the hypothesis dependency object data, hypothesis validity condition data is obtained by processing the hypothesis validity conditions. Cross-cell hypothesis merging is performed on the hypothesis validity condition data to obtain hypothesis constraint data.

5. The method for optimizing the principle data of interconnection components in a spacecraft electrical system according to claim 1, characterized in that, The cross-generational consistency check specifically involves: Inheritance path data is segmented based on cross-task inheritance path data to obtain intergenerational inheritance segment data; The hypothetical constraint data is mapped to the intergenerational inheritance segment data to obtain the intergenerational hypothesis data; Based on intergenerational hypothesis data, cross-generational consistency failure is determined, and cross-generational distortion identification data is obtained. The cross-generational distortion identifier data is aggregated to obtain distortion unit data.

6. The method for optimizing the principle data of spacecraft electrical system interconnection components according to claim 5, characterized in that, The specific determination of cross-generational consistency failure is as follows: Based on the intergenerational hypothesis data, hypothesis-carrying object binding is performed to obtain object binding data; Based on the cross-task inheritance path data, the object binding data is identified to determine its persistence status, and thus the persistence status data is obtained. Based on the existing status data, the continuity of the carrying capacity is verified, and abnormal data of the carrying capacity continuity are obtained. Based on the abnormal data of continuous bearing, the hollow shell hypothesis is identified and determined, and the hollow shell hypothesis identification data is obtained; Based on the empty shell hypothesis identification data, cross-generational failure propagation is confirmed for cross-task inheritance path data, resulting in cross-generational distortion identification data.

7. The method for optimizing the principle data of interconnection components in a spacecraft electrical system according to claim 1, characterized in that, The cumulative distortion assessment specifically includes: Distortion dimension decomposition is performed on the distorted cell data to obtain distortion feature data; Based on the cross-task inheritance path data, the generational distortion accumulation trajectory is constructed from the distortion feature data to obtain the distortion accumulation trajectory data; Distortion accumulation processing is performed on the distortion accumulation trajectory data to obtain distortion accumulation data, which is then used to assist in the optimization of interconnected components.

8. The method for optimizing the principle data of interconnection components in a spacecraft electrical system according to claim 1, characterized in that, The specific tasks for optimizing interconnected components are as follows: Distortion type identification data is obtained by classifying the cumulative distortion data based on the cumulative distortion data; The distortion type identifier data is filtered for units of interest to obtain units of interest data. Based on cross-task inheritance path data and assumption constraint data, distortion root cause correlation analysis is performed on the data of the units of interest to obtain distortion root cause correlation data. Optimization strategies are generated based on the root cause correlation data of the distortion, resulting in optimization strategy data.

9. A principle data optimization system for interconnection components of a spacecraft electrical system, characterized in that, For executing the spacecraft electrical system interconnection component principle data optimization method as described in claim 1, the spacecraft electrical system interconnection component principle data optimization system includes: The structure deconstruction module is used to acquire interconnect component data; based on the interconnect component data, it performs structure deconstruction to obtain the principle unit data; The principle inheritance evolution analysis module is used to construct cross-task inheritance paths and extract assumption constraints based on principle unit data, resulting in cross-task inheritance path data and assumption constraint data, respectively. The cross-generational principle consistency verification module is used to perform cross-generational principle consistency verification based on cross-task inheritance path data and assumption constraint data, and obtain distorted unit data. The distortion cumulative evaluation module is used to perform distortion cumulative evaluation on the distortion unit data to obtain distortion cumulative data, which is used to assist in the optimization of interconnect components.

Images