Data display method, program product, electronic equipment and storage medium

Abstract

The invention provides a data display method, a program product, electronic equipment and a storage medium, the method is applied to a digital main line, and the method comprises the following steps: sending a data acquisition signal to a domain system, and acquiring a domain data file; the domain system comprises an architecture design domain and a service domain; the business field comprises at least one of a simulation model field, a simulation verification field, a system test data field, an IDS system and a three-dimensional collaborative management system; respectively constructing a model tree corresponding to each field data, and creating an index of a data object in each model tree in the digital main line; associating nodes in the model tree corresponding to the service field with system structure nodes corresponding to the architecture design field to obtain an associated network; mounting a data object corresponding to the domain data to a system structure node based on the data features of the association network and / or the domain data, and generating a converged data model; and displaying the domain data in the domain system. And convergence and display of cross-domain data are realized.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a data display method, program product, electronic device, and storage medium. Background Technology

[0002] In the development of complex equipment such as spacecraft, aviation, and automobiles, multiple professional fields are usually involved. Each field uses different modeling tools and data formats. The data sources are diverse and the formats are inconsistent. The lack of a unified aggregation and organization mechanism leads to serious data silos, making it difficult to achieve unified management and traceability of cross-domain data. Summary of the Invention

[0003] The purpose of this application is to provide a data display method, program product, electronic device, and storage medium to improve the above-mentioned problems.

[0004] In a first aspect, embodiments of this application provide a data display method applied to a digital mainline. The method includes: sending a data acquisition signal to a domain system to acquire a domain data file; the domain system includes an architecture design domain and a business domain; the business domain includes at least one of a simulation model domain, a simulation verification domain, a system test data domain, an IDS system, and a 3D collaborative management system; parsing the domain data file, constructing a model tree corresponding to each domain data, and creating an index of the data objects in each model tree in the digital mainline; the index is used to query the data objects of the domain data through the digital mainline; wherein, the nodes of the model tree are entities in the domain data; associating the nodes representing the product composition structure in the model tree corresponding to the business domain with the unique system structure node defined by the model tree corresponding to the architecture design domain for global navigation, to obtain an association network centered on the system structure node; based on the association network and / or the data characteristics of the domain data, mounting the data objects corresponding to the domain data to the system structure node to generate a converged data model; and displaying the domain data in the domain system based on the converged data model.

[0005] In the aforementioned implementation process, standardized data acquisition and index creation enabled unified acquisition and synchronization of dispersed and heterogeneous data without migrating the original data. By constructing a network and mounting mechanism centered on the product system structure, data from the entire lifecycle, including requirements, design, simulation, testing, and production, were linked together to form a complete and traceable data link, which was then displayed in multiple dimensions. This improved the retrieval efficiency, depth of understanding, and utilization value of cross-domain data; enhanced the collaborative capabilities between different professional teams; supported cross-unit, multi-professional, and wide-area collaborative development; and achieved the interconnection and traceability of core business data within the model development scheme and detailed design. It effectively connected the data links of business processes such as spacecraft support scheme design, detailed design, process design, production and manufacturing, final assembly and integration testing, and on-orbit testing and maintenance. Furthermore, it provided solid data support for model-based systems engineering practices and powerfully promoted the development of complex products towards digitalization, networking, and intelligence.

[0006] Optionally, in this embodiment, the model tree corresponding to the business domain includes a first type of node and a second type of node; the first type of node represents the system, subsystem, and / or stand-alone device of the product within the corresponding domain; associating the nodes representing the product composition structure in the model tree corresponding to the business domain with the unique system structure node defined in the model tree corresponding to the architecture design domain for global navigation to obtain an association network centered on the system structure node includes: associating the first type of node in the model tree corresponding to the business domain with the system structure node in the model tree corresponding to the architecture design domain to obtain a first association relationship; the first association relationship is used to provide a reference for the association process of the second type of node; based on the first association relationship and / or the data characteristics of the domain data, associating the second type of node in the model tree corresponding to the business domain with the system structure node in the model tree corresponding to the architecture design domain to obtain a second association relationship; summarizing the first association relationship and the second association relationship to obtain an association network centered on the system structure node.

[0007] In the aforementioned implementation process, a node classification and hierarchical association mechanism decomposes the chaotic cross-domain data association problem into a clear process of "first aligning the structural framework, then aggregating specific content," reducing the complexity of the association logic and the difficulty of implementation. By establishing a stable primary association relationship as a global reference, the uniqueness and consistency of the data aggregation benchmark are ensured; the secondary association relationship built on this basis can flexibly and efficiently handle the mounting requirements of massive heterogeneous business data. The final generated association network is not only a static graph of data relationships, but also a core infrastructure supporting dynamic and intelligent data services, laying a solid and flexible foundation for subsequent accurate data retrieval, comprehensive display, and in-depth analysis.

[0008] Optionally, in this embodiment of the application, sending a data acquisition signal to the domain system to acquire a domain data file includes: sending a data acquisition signal to each domain system to acquire a domain data file returned by the domain system, which is generated based on the signed and approved model or stable state data; the signed and approved model is used to manage the signed and approved data; the domain data file includes basic information, hierarchical structure relationships and / or index link organization.

[0009] In the aforementioned implementation process, automated data acquisition through timed triggering, state-driven mechanisms, and standardized encapsulation provides high-quality, reliable data for the entire digital backbone system. This ensures that all data fed into the digital backbone originates from valid versions confirmed within each domain's internal processes, improving data validity and consistency from the source. A lightweight encapsulation strategy reduces unnecessary data transmission and storage overhead while meeting cross-system data indexing and association requirements, thus improving overall system performance. Furthermore, standardized interfaces and file formats reduce coupling to heterogeneous source systems, enhancing the scalability and adaptability of the digital backbone architecture and laying a solid and reliable foundation for subsequent data integration and organization.

[0010] Optionally, in this embodiment of the application, after parsing the domain data file and constructing the model tree corresponding to each domain data, the method further includes: adding an acquisition identifier to the data in the acquired domain data file; wherein the acquisition identifier is used to indicate that the corresponding data has been acquired by the digital mainline; sending an acquisition data signal to the domain system again according to a preset rule to acquire the target domain data file returned by the domain system; if it is determined that the data in the target domain data file does not have an acquisition identifier, generating an updated domain data file based on the data without an acquisition identifier; and incrementally updating the model tree based on the updated domain data file to obtain the updated model tree.

[0011] In the above implementation process, an efficient and reliable data synchronization method is constructed by setting an "acquired flag" for the acquired data and using a request-driven incremental comparison mechanism. This ensures that the digital mainline only transmits and processes newly added data that has changed, greatly reducing network bandwidth consumption, server processing pressure, and data refresh latency, thus improving the overall system performance and response efficiency. Furthermore, through status judgment and flag management, the accuracy of data synchronization behavior and data consistency are improved, reducing data omissions or duplications.

[0012] Optionally, in this embodiment of the application, parsing the domain data file, constructing a model tree corresponding to each domain data, and creating an index of the data objects in each model tree in the digital mainline includes: parsing the domain data file, extracting the attributes of the data objects and the hierarchical relationship between the data objects; constructing a model tree reflecting the internal organizational structure of the domain data based on the hierarchical relationship; and creating a corresponding index for each data object in the model tree in the digital mainline according to the attributes; the index includes basic information for uniquely identifying the data object, and jump links for accessing the complete content of the data object in the domain system.

[0013] In the aforementioned implementation process, through standardized parsing, structured modeling, and reference-based index creation, raw data from heterogeneous systems is efficiently transformed into knowledge units that can be uniformly operated within the digital backbone. This separates physical storage from logical management of the data, preserving the integrity of the source system's data while constructing a lightweight, flexible, and semantically rich indexing system.

[0014] Optionally, in this embodiment, associating nodes of the model tree corresponding to the business domain with system structure nodes of the model tree corresponding to the architecture design domain includes: obtaining a pre-set relationship rule script, parsing and transforming the relationship rule script using a rule parser to generate matching logic; matching the unique identifiers of the nodes of the model tree corresponding to the business domain with the unique identifiers of the system structure nodes based on the matching logic, and establishing an association relationship based on the matching results; or; providing a user interface, and in response to the user's association operation on the user interface between the model tree nodes of the business domain and the system structure nodes, establishing an association relationship between the nodes of the model tree corresponding to the business domain and the system structure nodes of the model tree corresponding to the architecture design domain; or; comparing the attribute information of nodes in the business domain model tree with the attribute information of system structure nodes based on semantic similarity analysis, and recommending and establishing an association relationship based on the comparison results.

[0015] In the aforementioned implementation process, a flexible, robust, and scalable cross-domain data association framework was constructed by providing a diversified association approach that combines rule-driven, manual intervention, and intelligent assistance. This framework can handle large-scale, standardized association tasks through preset rules, ensuring efficiency and consistency; it can also handle complex special cases through manual mapping, guaranteeing the integrity and accuracy of associations; and the intelligent recommendation function further reduces the burden of manual operation and improves the depth of association discovery. These three approaches complement each other, jointly ensuring that dispersed business domain data can be effectively associated onto a unified system architecture framework under different data conditions and business needs, laying a crucial technical foundation for forming a complete and reliable data aggregation network.

[0016] Optionally, in this embodiment of the application, based on the data characteristics of the associated network and / or domain data, the data object corresponding to the domain data is mounted to the system structure node to generate the aggregated data model, including: based on the data characteristics of the associated network and / or domain data, the corresponding mounting logic is used to establish an association between the data object and the system structure node to generate the aggregated data model; wherein, the mounting logic includes link mounting, identifier matching mounting, and / or parameter mounting.

[0017] In the aforementioned implementation process, a multi-layered data object mounting system was constructed by providing three mounting logics: link tracing, identifier matching, and parameter extraction. This fully leverages the existing network of connections and the inherent characteristics of the data itself, flexibly adapting to the mounting needs of different types and structures of business data. This ensures that various forms of domain data can be accurately and systematically organized into a unified product structure framework, thereby forming a complete, consistent, and deeply traceable aggregated data model.

[0018] Optionally, in this embodiment, the mounting logic includes link mounting; the data object includes requirement information; the data characteristics of the domain data include the relationship links of the data objects; and the corresponding mounting logic is used to establish an association between the data object and the system structure node, including: obtaining the relationship links corresponding to the requirement information; the relationship links corresponding to the requirement information include the association between design requirements and design functions, and between design functions and system architecture; and establishing an association between the requirement information and the system structure node based on the relationship links.

[0019] In the above implementation process, by tracing the existing design logic chain, the abstract design requirements (needs) are accurately matched to the specific product structure. The whole process is completed automatically by the system, realizing the connection between design intent and product entity, and to a certain extent realizing the traceability of design intent.

[0020] Optionally, in this embodiment, the mounting logic includes identifier matching mounting; the data object includes IDS information; and the corresponding mounting logic is used to establish an association between the data object and the system structure node, including: obtaining the device code of the single device from the IDS information; matching the device code with the device code of the system structure node, and mounting the IDS information to the matching system structure node according to the category of the single device.

[0021] In the aforementioned implementation process, efficient direct matching of identifiers and structured classification are used to systematically integrate disorganized equipment parameter data into the product framework, improving the direct usability of the data. During display, users can quickly locate the required parameters according to their professional needs, enhancing convenience.

[0022] Optionally, in this embodiment, the mounting logic includes parameter mounting; the data object includes simulation parameter information; the corresponding mounting logic is used to establish an association between the data object and the system structure node, including: after the simulation model node in the simulation model field is associated with the system structure node, parameter information is extracted from the simulation model node; the parameter information includes mechanical load, resistive load, thermal load, telemetry parameters and remote control command information; the simulation parameter information is mounted to the system structure node according to the extracted parameter information.

[0023] In the above implementation process, by deepening model analysis, the deep parameter knowledge in the model file is extracted and presented, enhancing the readability and analytical value of the data. This allows users not only to know that a certain component has a simulation model, but also to directly see the key performance and interface parameters defined by that model.

[0024] Optionally, in this embodiment of the application, the domain data in the domain system is displayed based on the aggregated data model, including: displaying the domain data in the domain system according to the time dimension based on the time information recorded in the aggregated data model; and / or, displaying the domain data in the domain system according to the hierarchical dimension based on the hierarchical information of the model tree corresponding to the architecture design domain in the aggregated data model; and / or, obtaining scenario classification by dividing the model tree corresponding to each domain data in the aggregated data model according to the business application scenario; and displaying the domain data in the domain system according to the scenario classification.

[0025] In the aforementioned implementation process, an intelligent data display system was constructed by organically combining three dimensions: time, hierarchy, and business scenario. The time dimension allows users to precisely control the timeliness and historical evolution of data; the hierarchy dimension provides data navigation and aggregation paths centered on physical products and conforming to natural thinking; and the business scenario dimension achieves clear isolation and parallel in-depth analysis of multi-disciplinary data. These three dimensions work together to transform the originally scattered, heterogeneous, and multi-version complex data stream into a unified and intuitive display interface, improving the efficiency and accuracy of users' retrieval and access to cross-system data.

[0026] Optionally, in this embodiment of the application, displaying domain data in the domain system based on the aggregated data model further includes at least one of the following: when displaying domain data, highlighting data objects associated with the currently selected system structure node; providing an interface to display detailed attribute information of the selected data object and information of other data objects associated with it; providing controls for users to switch between different development stages or versions to view the corresponding historical domain data; providing links at the displayed data objects to jump to their original domain system for viewing; and visually displaying the horizontal associations across development stages and the vertical associations across system levels between different data objects.

[0027] In the aforementioned implementation process, a deeply interactive and intelligently guided data visualization environment was constructed through the five display schemes described above. This allows users to quickly focus on key information and gain insights into details; spatiotemporal version switching provides a dynamic perspective on data evolution; source data navigation ensures data traceability; and visualization of relationships displays data links across stages and levels. These features collectively transform the aggregated static data model into an easily understandable dynamic knowledge network, improving the efficiency and depth of users' retrieval, analysis, and decision-making in complex cross-domain data.

[0028] Secondly, embodiments of this application also provide a computer program product, including computer program instructions, which are executed by a processor to perform the method provided in the first aspect or any implementation thereof.

[0029] Thirdly, embodiments of this application also provide an electronic device, including: a processor and a memory, the memory storing computer program instructions, which are executed by the processor to perform the method provided in the first aspect or any implementation thereof.

[0030] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, perform the method provided in the first aspect or any implementation thereof.

[0031] This application utilizes a data visualization method, program product, electronic device, and storage medium. Through standardized data acquisition and index creation, it achieves unified acquisition and synchronization of dispersed and heterogeneous data without relocating the original data. By constructing a relational network and mounting mechanism centered on the product system structure, it connects data across the entire lifecycle, including requirements, design, simulation, testing, and production, forming a complete and traceable data link for multi-dimensional visualization. This improves the retrieval efficiency, understanding depth, and utilization value of cross-domain data; enhances the collaborative capabilities between different professional teams; supports cross-unit, multi-professional, and wide-area collaborative development; realizes the interconnection and traceability of core business data within model development schemes and detailed designs; effectively connects data links in business processes such as spacecraft support scheme design, detailed design, process design, manufacturing, assembly integration testing, on-orbit testing, and maintenance; and provides solid data support for model-based systems engineering practices, powerfully promoting the development of complex products towards digitalization, networking, and intelligence. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 A flowchart illustrating a data display method provided in an embodiment of this application; Figure 2 This application provides a schematic diagram illustrating demand data in an embodiment. Figure 3 This is a schematic diagram illustrating the display of demand data attributes provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the display of indicator data attributes provided in an embodiment of this application; Figure 5 A schematic diagram illustrating functional information provided in an embodiment of this application; Figure 6 A schematic diagram illustrating architectural information provided in an embodiment of this application; Figure 7 A schematic diagram illustrating the architecture design parameters provided in this application embodiment; Figure 8 This is a schematic diagram illustrating model information provided in an embodiment of this application; Figure 9 A schematic diagram illustrating system simulation parameters provided in this application embodiment; Figure 10This is a schematic diagram illustrating IDS parameters provided in an embodiment of this application; Figure 11 This is a schematic diagram illustrating model information provided in an embodiment of this application; Figure 12 This is a schematic diagram illustrating EBOM information display provided in an embodiment of this application; Figure 13 This is a schematic diagram illustrating historical data retrieval provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0035] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this application.

[0036] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0037] While existing digital mainline systems can be used to build enterprise-level data integration frameworks, the following problems still exist in actual engineering: data sources are diverse and formats are inconsistent, lacking a unified aggregation and organization mechanism; cross-system and cross-domain data association is difficult, making it hard to achieve a global view; the data update mechanism is unclear, making it difficult to guarantee the authority and timeliness of the data; and there is a lack of user-oriented data display and retrieval capabilities, affecting decision-making efficiency.

[0038] In engineering practice, the Digital Mainline System is generally considered to be a scalable and configurable agent enterprise-level analysis framework. Based on digital system model templates, it seamlessly builds the controlled interaction of authoritative data, information and knowledge in enterprise data systems, thereby providing decision-makers with the ability to access, integrate and transform different data into actionable information, and realize data source management throughout the system lifecycle.

[0039] The digital framework has two main application categories in the aerospace, military, and automotive industries, as follows: First, at the methodological level, it builds interactive relationships among methods, processes, tools, technologies, data, and people through a digital engineering ecosystem. This establishes stable internal functional performance and reliable external interactions, resulting in robust and reliable equipment quality. Second, at the data level, it horizontally connects activities at different stages of the lifecycle into a data network through the digital framework, and vertically, through model integration, interoperability, and combination, forms a network of model applications.

[0040] Digital Mainline, as a platform aggregating data from a large number of professional fields, proactively acquires data from various domains. Digital Mainline indexes and interprets text, SysML views, Modelica modules, IDS (Interface Data Sheet) interface tables, EDS (Electronic Data Sheet) structured data, 3D CAD / CAE model information, etc., in the original models. Based on the meta-model rules defined for satellites and other spacecraft, it verifies and transforms this information into a unified and standardized entity, relation, and fact triple representation. After the data and relational foundation of Digital Mainline is established, upper-layer applications are built upon this foundation. One of the purposes of Digital Mainline is to associate and centrally present trusted data from various fields to support user decision-making. This application's embodiments will illustrate the capabilities and application scenarios of the data aggregation and organization module, mainly including the system structure definition supporting data aggregation, the data association system structure, and data display. The design concept is as follows: First, establish a system structure to represent the product model, which will serve as a "bridge" for data association and display in various fields; Secondly, the data obtained from the digital mainline is associated with system nodes through relational rules to complete data aggregation; Finally, the collected data is displayed according to different fields and business usage scenarios to support users in viewing, searching, and applying it.

[0041] The following describes the application scenarios of this application: Requirement text, SysML views, Modelica modules, IDS interface tables, EDS structured data, and 3D CAD / CAE model data from different domain models are converted, organized, and integrated through a unified data interface according to a unified standard and validity check, thus constructing a semantic model based on unified semantics. The methods for constructing the semantic model include: (1) Defining a unified semantic framework: Creating an ontology for the spacecraft domain, defining spacecraft elements (such as solar panels, antennas, batteries, etc.), attributes (such as size, weight, etc.), and relationships (such as connections, inclusion, etc.). (2) Extracting semantic information: Performing NLP processing on the textual requirement model to extract user requirements and design goals. Performing graphical parsing on the graphical system model to extract information such as blocks, activities, and attributes defined in the view. Extracting geometric features from the 3D product model to obtain the 3D structure and material information of the spacecraft. (3) Mapping to the semantic framework: Mapping the requirement items in the requirement model to the "design goal" concept in the ontology. Mapping the spacecraft composition architecture of the system model to the spacecraft logical entities and their attributes in the ontology. (4) Construct a semantic model: Use SysML modeling tools to organize all extracted semantic information into a graph structure to form a complete spacecraft semantic model.

[0042] One objective of this application is to refine the information acquisition and data synchronization methods for various domain models based on semantic models, establish a unified spacecraft system model after the convergence of models from various domains, and comprehensively display the view based on the fused data. In spacecraft development, the business operations of various domains are reconstructed and aggregated from the perspective of business applications and model systems to achieve data and business integration, provide users with a comprehensive global data display view, and solve the problem of difficulty in retrieving and viewing data across domains and systems.

[0043] Please see Figure 1 The illustration shows a flowchart of a data display method provided in an embodiment of this application. The data display method provided in this embodiment can be applied to digital mainlines. The data display method may include: Step S110: The digital mainline sends a data acquisition signal to the domain system to acquire the domain data file; the domain system includes the architecture design domain and the business domain; the business domain includes at least one of the following: simulation model domain, simulation verification domain, system test data domain, IDS system, and 3D collaborative management system; Step S120: The digital master line parses the domain data file, constructs a model tree corresponding to each domain data, and creates an index of the data objects in each model tree in the digital master line; the index is used to query the data objects of the domain data through the digital master line; wherein, the nodes of the model tree are the entities in the domain data; Step S130: The digital thread associates the nodes representing the product composition structure in the model tree corresponding to the business domain with the unique system structure node defined in the model tree corresponding to the architecture design domain for global navigation, to obtain an association network centered on the system structure node. Step S140: Based on the data characteristics of the associated network and / or domain data, the digital mainline attaches the data objects corresponding to the domain data to the system structure nodes to generate the aggregated data model; Step S150: Based on the aggregated data model, the digital thread displays the domain data in the domain system.

[0044] As the central hub for data aggregation and organization, the digital thread proactively acquires authoritative data from various dispersed domain systems. In step S110, the digital thread sends standardized data acquisition request signals to systems encompassing the architecture design domain and multiple business domains through a predetermined scheduling mechanism, such as scheduled tasks. These business domains include at least one of the following: simulation model domain, simulation verification domain, system test data domain, IDS system, and 3D collaborative management system.

[0045] Upon receiving a request, each business domain system, according to the pre-agreed interface specifications with the digital mainline, lightweight encapsulates the stable data it manages. The criteria for determining a stable state vary across different domains. For example, in the architecture design and simulation model domain, it refers to the model having completed the approval process; in the IDS system, it refers to the single-machine parameter form being in the database; and in the system testing domain, it refers to the root node of the test management tree reaching the "released" stage. This stable state data, along with its hierarchical relationships, unique identifiers, and links to detailed information from the source system, is organized into structured domain data files. These domain data files can be in XML or JSON format; for example, the simulation model domain uses JSON. The acquisition and synchronization process for the architecture design domain and each business domain will be explained later.

[0046] The data acquired by the digital backbone is a trusted snapshot of data verified through business processes in various fields. At the same time, it reduces network and processing pressure by transmitting only the necessary metadata and links.

[0047] In step S120, after receiving the structured domain data files from each domain, Digital Mainline converts and maps the fields and structures in the files to a unified data model within Digital Mainline according to the pre-configured data mapping rules for each domain. For example, Digital Mainline identifies and extracts entities, entity attributes, and hierarchical relationships between entities from the data files. An entity can be a requirement, a simulation task, or a single device; entity attributes include name, code, version, and creation time; and hierarchical relationships between entities include parent-child relationships or other subordinate relationships. Based on the extracted hierarchical relationships, Digital Mainline dynamically constructs a model tree in memory that reflects the organizational structure of the architecture design domain or each business domain, such as the RFL (Requirements-Functions-Logic) structure tree for architecture design and the EBOM (Essential Business Objects) structure tree for 3D design.

[0048] It's important to note that the Digital Master does not store the source data locally in its entirety. Instead, it creates an index object for each data object in the model tree. This index object can include: 1. Metadata: Basic information describing and identifying the object, such as title, type, device code, and model number; 2. Links: A URL that directly accesses the complete details page of the data object in the original domain system. The index objects and their relationships are uniformly stored and managed at the underlying level using knowledge graph technology. Therefore, the model tree is a dynamically generated view from the knowledge graph, oriented towards a specific business perspective, while the index system constitutes a global map for the Digital Master to know "where the data is, what it is, and how it is related." The correspondence between data types and attributes in the domain data files and the Digital Master data will be introduced later.

[0049] In step S130, after generating independent model trees for each domain, a relational network centered on system structure nodes needs to be established to achieve cross-domain data aggregation. The system structure nodes originate from model trees in the architecture design domain that have undergone rigorous and authoritative verification. Specifically, Digital Mainline obtains system architecture models whose lifecycle status is approved and whose version identifier is the current valid baseline version, and extracts nodes representing the physical or logical decomposition of the product, such as logical nodes at the system, subsystem, and single-machine device levels, as the skeleton for the entire Digital Mainline data display and navigation.

[0050] First, nodes representing the same product composition structure in the model trees of each business domain, such as system model nodes in the simulation model tree, single-machine device nodes in the IDS tree, and assembly nodes in the EBOM tree, are associated with system structure nodes. This association can be achieved in two ways: First, relationship rule matching: using unique identifiers defined on each node, including device codes and project numbers, the rule engine automatically matches and associates them. Second, manual relationship mapping: for cases lacking clear identifiers or where rules cannot cover them, a visual interface is provided for users to manually establish associations.

[0051] For the second association method, association rule scripts can be written, verified, and tested using a rule parser to achieve manual mapping. Through the constructed association network, an association relationship "representing the same entity" is established between index objects in different domains in the underlying knowledge graph, thereby connecting data scattered in various places that point to the same product component to a unified system structure node.

[0052] When Digital Mainline acquires data from the architecture design domain, it specifies the system architecture model whose lifecycle status is signed and approved, and whose version identifier is the current valid baseline version. This model typically represents a top-level design decomposition of the product that has undergone formal review and confirmation. Digital Mainline parses this model, extracting the defined hierarchical relationships and unique identifiers (such as node IDs and codes) of systems, subsystems, and individual devices to form a baseline set of system structure nodes. When the architecture design model changes and a new version is generated, Digital Mainline updates this system structure according to a preset strategy (such as only synchronizing the latest signed and approved version).

[0053] In step S140, mounting refers to establishing a directional relationship from a system structure node to a business data object index. Depending on the characteristics of the domain data, the mounting method varies. The mounting methods corresponding to different data characteristics are described below, and the mounting process for each type of data will be explained later.

[0054] For data such as requirements and functions within the architecture design domain, although these data do not have direct product structure attributes, they are already associated with the source of system structure nodes in the RFL model. The system traces along the existing link of "requirements to functions to logical architecture", and ultimately indirectly attaches requirement and function data to the corresponding system structure nodes through the association between logical architecture nodes and system structure nodes.

[0055] For data centered on a single machine, such as IDS parameters and EDS information, we directly use their unique identifiers, such as "device code", to match and mount them to system structure nodes (single machine device nodes) with the same identifier.

[0056] For simulation models or design models that are already associated with system structure nodes, specific simulation parameters and design parameters are further extracted from their model content and classified according to professional categories (such as mechanical, thermal, and electrical) and attached to the same node as derived data.

[0057] For EBOM information, its tree nodes have a clear hierarchical correspondence with the system structure, and the association and mounting of the overall structure are achieved through node identifier matching. Through the above multiple mounting methods, relevant data from all domains are logically organized under a unified system structure tree, forming a complete and traceable aggregated data model.

[0058] In step S150, based on the aggregated data model, Digital Mainline provides users with an integrated and intelligent data display interface. It can display domain data through multiple dimensions, such as the time dimension: showing the latest controlled version of the latest development stage of data in each domain, ensuring that what the user sees is the current state. It also provides a stage and version selector, allowing users to easily trace historical data and observe the design evolution process.

[0059] For example, consider the hierarchical display: the left side of the interface uses a system structure tree as the core navigation bar, clearly presenting the hierarchy from system, subsystem to standalone device. Clicking on any node indicates that the user is viewing the product's components from that perspective.

[0060] For example, the display of the model (business) dimension: On the right side of the interface, multiple tabs will be divided according to business scenarios, such as requirements, functions, models, simulation parameters, IDS parameters, EBOM, etc. When the user selects a node (such as "Battery Standalone") in the left navigation tree, all tabs on the right will refresh in tandem, displaying all relevant data from different fields that have been attached to that node through step S140.

[0061] As one implementation method, intelligent highlighting can showcase data entries directly and strongly related to the currently selected node within each tab; users can click on any data object to view its complete attributes and related information; data tracing provides the ability to jump to the source system with one click through the jump links in the index to view the most original and detailed data. This display method transforms complex data relationships across systems and domains into an intuitive view centered on the product structure and conforming to the thinking habits of engineers.

[0062] In the implementation of the above embodiments: through standardized data acquisition and index creation, unified acquisition and synchronization of scattered heterogeneous data were achieved without relocating the original data. By constructing an association network and mounting mechanism centered on the product system structure, data from the entire lifecycle, including requirements, design, simulation, testing, and production, were linked together to form a complete and traceable data link, which was then displayed in multiple dimensions. This improved the retrieval efficiency, understanding depth, and utilization value of cross-domain data; enhanced the collaborative capabilities between different professional teams; supported cross-unit, multi-professional, and wide-area collaborative development; and achieved the interconnection and traceability of core business data within the model development scheme and detailed design. This effectively connected the data links of business processes such as spacecraft support scheme design, detailed design, process design, production and manufacturing, final assembly and integration testing, on-orbit testing and maintenance. It provided solid data support for model-based systems engineering practices and powerfully promoted the development of complex products towards digitalization, networking, and intelligence.

[0063] Optionally, in this embodiment of the application, the model tree corresponding to the business domain includes a first type of node and a second type of node; the first type of node is a node that represents the product in the corresponding domain as a system, subsystem and / or stand-alone device.

[0064] The distinction between first-class and second-class nodes in the business domain model tree is based on whether the node directly represents an identifiable component of the product in the physical or logical decomposition structure.

[0065] The first type of node refers to nodes in the data of various business domains that can directly represent the physical composition or logical architecture of a product. For example, in the field of simulation models, there are nodes representing "satellite power system simulation models" or "battery unit simulation models"; in the IDS system, there are equipment nodes representing "battery units"; and in the field of 3D design (EBOM), there are assembly nodes representing "satellite modules," "power supply subsystems," or "battery unit parts." Their common characteristic is that they usually have clear and unique identifiers corresponding to the product design, such as equipment codes, material codes, or project structure codes.

[0066] The second type of node is the specific business data node, which refers to the detailed business data object attached to the first type of node or describing its specific attributes. They do not directly represent a decomposable part of the product, but rather describe a certain characteristic or requirement. Examples include IDS parameters attached to the "Battery Unit" node, such as rated voltage, operating temperature, simulation parameters, test cases, and requirement items and functional activities from the architecture design domain.

[0067] The association process employs a hierarchical strategy, first associating the first type of nodes, then associating the second type of nodes. That is, it first establishes associations between systems, subsystems, and individual devices within the domain and system structure nodes, and then establishes associations between data from other domains and system structure nodes. The implementation method is described below.

[0068] Associating the nodes representing the product composition structure in the model tree corresponding to the business domain with the unique system structure node defined in the model tree corresponding to the architecture design domain for global navigation, yields an association network centered on the system structure node, including: (1) Associate the first type of node in the model tree corresponding to the business domain with the system structure node in the model tree corresponding to the architecture design domain to obtain the first association relationship; the first association relationship is used to provide a reference for the association process of the second type of node.

[0069] Establish a mapping between the first-class nodes in each business domain and the unified "navigation skeleton" (system structure nodes in the architecture design domain model tree) of the digital mainline. Automated matching can be achieved through a relational rule engine. Pre-configure rules extract the "unique identifier" of the first-class nodes and compare it with the identifiers of the system structure nodes. For example, automatically associate a single-machine node with the device code "BAT-001" in the IDS system with a battery single-machine node with the same code "BAT-001" in the system structure tree. For cases where automatic matching is not possible, the system provides a visualization tool for users to manually establish the mapping. This first association establishes consistency in the referencing of the same physical entity across different data sources, providing a global and stable reference system for the subsequent aggregation of all data.

[0070] (2) Based on the data characteristics of the first association relationship and / or domain data, associate the second type of node of the model tree corresponding to the business domain with the system structure node of the model tree corresponding to the architecture design domain to obtain the second association relationship.

[0071] Many second-type nodes are already associated with a first-type node in their original domain model tree through parent-child, subordinate, or other relationships. For example, a "battery range requirement" has been assigned to the "battery standalone" logical node in the requirement model. Using the established "first association," the association between the battery standalone logical node and the system structure battery standalone node is confirmed, and the requirement node is automatically attached to the aforementioned system structure battery standalone node as well.

[0072] For some data with self-describing characteristics, direct matching is possible. For example, the IDS parameter table itself contains a "device code" field. The system can directly use this code to bypass the IDS device node to which it belongs, and use the identifier mapping table established by the first association relationship to find the corresponding system structure node to complete the mounting.

[0073] (3) Summarize the first and second association relationships to obtain the association network centered on the system structure nodes.

[0074] The first and second relationships are summarized and integrated in the knowledge graph of the digital mainline. The final result is a relational network centered on system structure nodes, which is a queryable graph data structure. In this relational network, each system structure node becomes a connection hub, linking not only nodes from different domains that point to the same entity, but also all detailed cross-domain business data related to that entity.

[0075] In the implementation of the above embodiments: through node classification and hierarchical association mechanisms, the chaotic cross-domain data association problem is decomposed into a clear process of "first aligning the structural framework, then aggregating specific content," reducing the complexity and implementation difficulty of the association logic. By establishing a stable first association relationship as a global reference, the uniqueness and consistency of the data aggregation benchmark are ensured; the second association relationship built on this basis can flexibly and efficiently handle the mounting needs of massive heterogeneous business data. The final generated association network is not only a static graph of data relationships, but also a core infrastructure supporting dynamic and intelligent data services, laying a solid and flexible foundation for subsequent accurate data retrieval, comprehensive display, and in-depth analysis.

[0076] Optionally, in this embodiment of the application, sending a data acquisition signal to the domain system to acquire a domain data file includes: Send data acquisition signals to various domain systems to acquire domain data files generated by the domain systems based on approved models or stable state data; the approved models are used to manage approved data; the domain data files include basic information, hierarchical structure relationships and / or index link organization.

[0077] The digital mainline system has a built-in timed task scheduler that automatically sends data acquisition request signals to designated application programming interfaces (APIs) of business systems such as architecture design, simulation model, simulation verification, system test data, IDS system, and 3D collaborative management system according to a preset cycle.

[0078] Upon receiving a request, each domain system needs to determine which data has reached a "stable state" suitable for external distribution. For example, in fields like architecture design, "model review" refers to a model that has undergone a complete verification, review, and approval process, and its status changes to "signed and approved," signifying that its content is in a stable state. Stable state data has different meanings in different domains. For instance, in an IDS system, it refers to the lifecycle status of a single-machine interface data form being "stored"; in system testing, it refers to the root node of the test requirement tree being "released"; and in 3D design (EBOM), it's typically judged based on the fact that an assembly node and all its child nodes are "controlled." Only data that meets these stability criteria will be included in subsequent processing.

[0079] For these selected stable data, the domain system performs lightweight encapsulation according to the data interface specifications pre-defined with the Digital Mainline. The encapsulation process extracts the following data elements: 1) Basic information: metadata that uniquely identifies and describes the data object, such as title, name, equipment code, model, version, creation time, development stage, responsible organization, etc.; 2) Hierarchical structure: clarifying the data object's position in its domain model tree, such as its parent and child nodes, to preserve its original business context and attribution; 3) Index link: generating a hyperlink (URL) that can be directly accessed in a browser, pointing to the data object's details page within its source system. This information is organized into standard structured data files, primarily in XML format (JSON format is also used in the simulation model domain), and returned to the Digital Mainline via an API interface.

[0080] Understandably, different business domains, due to differences in their core data types and business logic, will provide domain data files to the digital mainline with varying internal structures. These differences include file formats (XML / JSON), internal tag definitions, and data organization methods. For example, XML files in the architecture design domain focus on expressing the hierarchical structure and relationships between requirements, functions, and logic, and often use... <dcterms:name> 、 <dcterms:classid>Semantic tags are used to distinguish object types, and nested structures or reference attributes are used to represent the parent-child relationship in the RFL tree. The XML files of the IDS system revolve around the parameter list of a single device, and their structure is typically flat, using... <device>As the root tag describes device attributes, multiple parameter key-value pairs need to be established. XML files in the 3D design (EBOM) domain primarily describe the product's assembly hierarchy and geometric / attribute information; their structural depth reflects the product BOM and includes design-specific data blocks such as driving parameters and layout elements. In contrast, the simulation model domain may use JSON, a format more suitable for describing nested objects and arrays, organizing model levels and parameter sets using keys such as "equipments" and "parameters." These structural differences are precisely the concrete manifestation of data semantics in each domain. Digital Mainline accurately identifies and extracts basic information, hierarchical relationships, and jump links from different file structures by pre-configuring corresponding parsing rules and mapping schemes for each domain type, thereby normalizing them into an internally unified index model.

[0081] In the implementation of the above embodiments: by establishing a timed, state-driven, and standardized encapsulation-based automated data acquisition system, high-quality and reliable data is provided for the entire digital mainline system. This ensures that all data imported into the digital mainline originates from valid versions confirmed within the internal processes of each domain, improving data validity and consistency from the source. Through a lightweight encapsulation strategy, unnecessary data transmission and storage overhead are reduced while meeting cross-system data indexing and association requirements, thus improving overall system performance. Furthermore, standardized interfaces and file formats reduce coupling to heterogeneous source systems, enhancing the scalability and adaptability of the digital mainline architecture and laying a solid and reliable foundation for subsequent data integration and organization.

[0082] Optionally, in this embodiment of the application, after parsing the domain data file and constructing the model tree corresponding to each domain data, the method further includes: Add an "acquired" flag to the data in the acquired domain data files; the "acquired" flag indicates that the corresponding data has been acquired by the digital mainline.

[0083] When a domain system responds to a digital master's acquisition request, successfully packages lightweight information of the stable state data into a domain data file and returns it, the domain system immediately records an acquisition identifier for this batch of data internally. The acquisition identifier marks that this specific version of data has been successfully received and indexed by the digital master. This identifier prevents the same data from being repeatedly packaged and transmitted in subsequent synchronization cycles.

[0084] According to the preset rules, the data acquisition signal is sent to the domain system again to acquire the target domain data file returned by the domain system; if it is determined that the data in the target domain data file does not have an acquired identifier, an updated domain data file is generated based on the data without an acquired identifier.

[0085] According to preset scheduling rules, such as fixed time intervals or event triggers, the digital mainline sends a data acquisition signal to each domain system again. Upon receiving the request, each domain system performs an incremental comparison within its internal data processing logic. The system scans all newly reached stable data records since the last synchronization and checks if they have been marked with an "acquisition flag." New data without this flag is filtered out. The domain system organizes this newly added, unsynchronized data according to its inherent hierarchical structure into a new, typically smaller target domain data file (i.e., an update package), and returns it to the digital mainline via an interface. This file, known as the "updated domain data file," contains only the incremental portion and excludes previously synchronized historical data.

[0086] The model tree is incrementally updated based on the updated domain data file to obtain the updated model tree.

[0087] Upon receiving the incremental update file, the parser parses it. The parsing process identifies the operation type of each data object in the file and its precise location within the model tree. This precise location information can be determined through hierarchical relationships such as parent node references. The model tree update engine is then invoked to locate the existing model tree structure in memory or persistent storage based on the precise location information. A new data object node is incrementally created under the corresponding node, or the attributes of an existing node are updated. For example, a newly approved model version node is added to the simulation model tree. This process is called "incremental update," which efficiently generates an updated model tree by locally modifying and expanding the tree structure, keeping it synchronized with the data state of the source system without rebuilding the entire tree.

[0088] In the implementation of the above embodiments, an efficient and reliable data synchronization method is constructed by setting an acquired identifier for the acquired data and using incremental updates. This ensures that the digital mainline only transmits and processes newly added data that has changed, reducing network bandwidth consumption, server processing pressure, and data refresh latency, thereby improving the overall system performance and response efficiency. Furthermore, through status judgment and identifier management, the accuracy of data synchronization behavior and data consistency are improved, reducing data omissions or duplications.

[0089] Optionally, in this embodiment of the application, parsing the domain data file, constructing a model tree corresponding to each domain data, and creating an index of the data objects in each model tree in the digital master line includes: Parsing domain data files extracts the attributes of data objects and the hierarchical relationships between them. For example, a parser can parse a domain data file, the parsing process including structural transformation and semantic mapping. Based on configuration rules, the parser identifies specific tags or key-value pairs in the file, extracting two types of key information: first, the attributes of the data objects, i.e., metadata describing the characteristics of the object, such as title, device code, version number, creation time, development stage, etc.; second, the hierarchical relationships between data objects, for example, by analyzing nested tags representing parent-child relationships or specific parent-child ID reference fields, determining which objects are children or parents of other objects, thereby reconstructing the complete organizational structure of the domain data within its native system.

[0090] Based on hierarchical relationships, a model tree reflecting the internal organizational structure of the domain data is constructed. The construction process begins with the identified root node, recursively creating child nodes according to parent-child relationships, and attaching its corresponding attribute set to each node. The final model tree is a logical projection of the internal organizational structure of the source domain data onto the digital mainline. For example, an RFL structure tree can be constructed from an architecture design XML file, and a product assembly structure tree can be constructed from an EBOM XML file.

[0091] Based on the attributes, create a corresponding index for each data object in the model tree within the digital thread; the index includes basic information to uniquely identify the data object, as well as jump links to access the complete content of the data object in the domain system.

[0092] For each data object node in the model tree, Digital Mainline does not store its detailed design documents and 3D model files. Instead, it creates a lightweight index object. The index object includes a unique identifier and basic information. All created index objects are systematically stored and managed within Digital Mainline's underlying data platform, such as a knowledge graph or index database. Therefore, the model tree is an application-oriented logical view, while the index system is an addressable directory for associations and access.

[0093] In the implementation of the above embodiments: through standardized parsing, structured modeling, and reference-based index creation, raw data from heterogeneous systems is efficiently transformed into knowledge units that can be uniformly operated within the digital backbone. The physical storage and logical management of data are separated, preserving the integrity of the source system data while constructing a lightweight, flexible, and semantically rich indexing system.

[0094] Optionally, in this embodiment, the nodes of the model tree corresponding to the business domain are associated with the system structure nodes of the model tree corresponding to the architecture design domain, including the following methods: The first method involves obtaining a pre-set relationship rule script, parsing and transforming the relationship rule script using a rule parser to generate matching logic; based on the matching logic, matching the unique identifier of the node in the model tree corresponding to the business domain with the unique identifier of the system structure node, and establishing an association relationship based on the matching result.

[0095] Relationship rule scripts are pre-written using a scripting language based on business logic. These scripts define matching conditions and logic; for example, a match is determined when the 'device code' attribute of a business model tree node completely matches the 'code' attribute of a system structure node. The rule parser in the digital mainline loads and processes these scripts: performing syntactic and semantic analysis, checking the correctness and logical completeness of the rules, and then converting them into efficient matching logic that can be executed internally. During actual association, this matching logic is invoked to automatically extract the specified unique identifier of the business domain model tree node and the corresponding identifier of the system structure node, and compare them. When the comparison is successful, an association is created in the background data relational database, connecting the two nodes. This approach is suitable for scenarios with clear identifiers and well-defined rules, offering high efficiency and good consistency.

[0096] Alternatively, the second approach involves providing a user interface that, in response to user interactions with the model tree nodes and system structure nodes in the business domain, establishes the association between the model tree nodes corresponding to the business domain and the system structure nodes in the model tree corresponding to the architecture design domain.

[0097] For situations lacking clear and unique identifiers, or where matching rules are exceptionally complex and difficult for automated rules to cover, a visual user interface can be provided to achieve association. This interface can display the business domain's model tree view and the system's structure tree view side-by-side. Users can manually specify the pairs of nodes to be associated in the two trees through interactive operations such as dragging, selecting, and right-clicking. After the front-end interface captures the user's association command, it sends a request to the back-end service, carrying the internal ID of the selected node. The back-end service responds to this request and formally establishes the association between the two nodes in persistent storage. This approach gives operators greater flexibility and control, enabling them to handle edge cases or special mapping needs that are difficult for automation to address.

[0098] Alternatively, a third approach is to compare the attribute information of nodes in the business domain model tree with the attribute information of system structure nodes based on semantic similarity analysis, and recommend and establish associations based on the comparison results.

[0099] The third approach utilizes semantic similarity analysis to facilitate association. Natural Language Processing (NLP) or text similarity algorithms are used to vectorize and compare key attribute information of business domain nodes and system structure nodes, such as node names, descriptions, and types. The calculated semantic similarity score is used to assess the semantic relevance between two nodes. A threshold can be set; when the similarity exceeds this threshold, association pairs are automatically recommended. Alternatively, an assisted association interface can present a list of candidate system structure nodes with the highest similarity to the user for confirmation or selection. After user confirmation, the system establishes the association. This approach can uncover potential associations that cannot be found based on literal identifier matching, improving the comprehensiveness and intelligence of association coverage.

[0100] In the implementation of the above embodiments, a flexible and scalable cross-domain data association framework is constructed by providing a diversified association approach that combines rule-driven, manual intervention, and intelligent assistance. This framework can handle large-scale, standardized association tasks through preset rules, ensuring efficiency and consistency; it can also handle complex special cases through manual mapping, guaranteeing the integrity and accuracy of associations; and the intelligent recommendation function further reduces the burden of manual operation and improves the depth of association discovery. These three approaches complement each other, jointly ensuring that dispersed business domain data can be effectively associated onto a unified system structure framework under different data conditions and business needs, laying a crucial technical foundation for forming a complete and reliable data aggregation network.

[0101] Optionally, in this embodiment, based on the data characteristics of the associated network and / or domain data, the data objects corresponding to the domain data are mounted to the system structure nodes to generate a converged data model, including: Based on the data characteristics of associated networks and / or domain data, corresponding mounting logic is used to establish associations between data objects and system structure nodes, generating a converged data model; wherein, the mounting logic includes link mounting, identifier matching mounting, and / or parameter mounting.

[0102] Link mounting is mainly applied to data objects that have been associated with a first-class node in their own domain model tree through a clear business logic relationship.

[0103] Identifier matching is suitable for data that carries its own unique identifier that can be directly mapped to the product structure. It uses the unique identifier contained in the data object itself to match the corresponding identifier of the system structure node.

[0104] Parameter mounting is suitable for model data objects that are already associated with system structure nodes as a whole, but require further decomposition and categorization of their internal detailed parameter information. Once the model as a whole is associated with a system structure node in the aforementioned manner, the system calls the corresponding model parser to extract specific parameter information from the model file according to predefined rules. These rules are configured in the digital master line and are primarily based on the data object's type attribute or its source domain attribute. Then, the system categorizes the parameters according to their professional category and groups parameters of the same category together, mounting them as derived data under the same system structure node.

[0105] In the implementation of the above embodiments, a multi-layered data object mounting system is constructed by providing three mounting logics: link tracing, identifier matching, and parameter extraction. It fully utilizes the existing network of connections and the inherent characteristics of the data to flexibly adapt to the mounting needs of different types and structures of business data. This enables various forms of domain data to be accurately and orderly organized into a unified product structure framework, thereby forming a complete, consistent, and deeply traceable aggregated data model.

[0106] The three mounting processes are described below.

[0107] Optionally, in this embodiment, the mounting logic includes link mounting; the data object includes requirement information; the data characteristics of the domain data include the relationship links of the data objects; and the corresponding mounting logic is used to establish an association between the data object and the system structure node, including: Obtain the relationship links corresponding to the requirements information; the relationship links corresponding to the requirements information include the relationship between design requirements and design functions, and the relationship between design functions and system architecture; based on the relationship links, establish the relationship between the requirements information and the system structure nodes.

[0108] Relationship chains can originate from established model relationships within the model tree (RFL structure tree) of the architecture design domain. For example, in a SysML system model, the design requirement of "battery life greater than XX hours" is assigned to the design function "energy management"; the "energy management" function is further assigned to the system structure node "power subsystem," i.e., a first-type node, thus forming a relationship chain. When mounting is executed, based on the ID of the requirement information, the database or relational database is traced backwards to find its associated functional nodes and the system structure nodes associated with those functional nodes, and then the requirement is mounted to the queried system structure nodes.

[0109] In the implementation of the above embodiments: by tracing the existing design logic chain, the abstract design requirements (demands) are accurately matched to the specific product structure. The whole process is completed automatically by the system, realizing the connection between design intent and product entity, and to a certain extent realizing the traceability of design intent.

[0110] Optionally, in this embodiment, the mounting logic includes identifier matching mounting; the data object includes IDS information; and the corresponding mounting logic is used to establish an association between the data object and the system structure node, including: Obtain the device code of the standalone device from the IDS information; match the device code with the device code of the system structure node, and attach the IDS information to the matching system structure node according to the category of the standalone device.

[0111] IDS information typically exists in form, with each record clearly belonging to a single device and containing the device's code and parameters from multiple disciplines such as mechanical, thermal, and electrical characteristics. During system mounting, the IDS information is first parsed to obtain the device code. An identifier matching query is performed within the established associated network or system structure node index to find system structure nodes with identical device codes. Upon successful matching, the IDS record is further parsed, and the parameters are categorized according to preset professional classification rules. Ultimately, instead of mounting the entire IDS record as a fuzzy whole, the categorized parameter sets are mounted separately to the corresponding single-device system structure node based on detailed categories such as "mechanical characteristics," "thermal characteristics," and "electrical characteristics."

[0112] In the implementation of the above embodiments: through efficient direct matching of identifiers and structured classification, the messy equipment parameter data is systematically integrated into the product framework, improving the direct usability of the data. During display, users can quickly locate the required parameters according to professional dimensions, improving convenience.

[0113] Optionally, in this embodiment, the mounting logic includes parameter mounting; the data object includes simulation parameter information; and the corresponding mounting logic is used to establish an association between the data object and the system structure node, including: After the simulation model node and the system structure node are associated in the simulation model field, parameter information is extracted from the simulation model node. The parameter information includes mechanical load, resistive load, thermal load, telemetry parameters and remote control command information. Based on the extracted parameter information, the simulation parameter information is attached to the system structure node.

[0114] The simulation model itself, as a first-class node or a complete data object, has already established associations with system structure nodes through methods such as identifier matching. Subsequently, the system triggers a model parameter parsing process. The digital thread extracts detailed simulation parameter information from the associated simulation model nodes, either through integration with the simulation tool's backend or by reading parsed standardized intermediate files. Simulation parameter information includes mechanical loads (such as force and torque), resistive loads (such as power consumption), thermal loads (such as heat generation power), telemetry parameters (such as voltage and temperature monitoring points), and remote control commands (such as power on / off commands). These parameters are identified and categorized according to predefined parameter classification patterns. For example, all parameters measured in "force" or "torque" are categorized into the "mechanical load" class, and all parameters describing heat exchange are categorized into the "thermal load" class. Finally, these categorized parameter sets, as sub-information sets with clear engineering semantics derived from the simulation model, are uniformly attached to the same system structure node associated with the simulation model.

[0115] In the implementation of the above embodiments: by deepening model analysis, the deep parameter knowledge in the model file is extracted and presented, enhancing the readability and analytical value of the data. This allows users not only to know that a certain component has a simulation model, but also to directly see the key performance and interface parameters defined by that model.

[0116] Optionally, in this embodiment of the application, based on the aggregated data model, the domain data in the domain system is displayed, including: Time Dimension: Based on the time information recorded in the aggregated data model, the domain data in the domain system is displayed according to the time dimension. For example, the display is controlled based on the time information recorded in the index of each data object in the aggregated data model, including basic creation and modification timestamps, and more importantly, development stage markers and version numbers closely related to the engineering process. Users can switch between different time periods by dragging a time progress bar to view the corresponding domain data.

[0117] And / or, hierarchical dimension: Based on the hierarchical information of the model tree corresponding to the architecture design domain in the aggregated data model, the domain data in the domain system is displayed according to the hierarchical dimension. The hierarchical information is essentially a tree-like data structure, with the root node representing the entire product, such as a satellite, and decomposed downwards level by level into system-level nodes, including propulsion and power systems, subsystem-level nodes, and individual device-level nodes. In the display interface, this hierarchical structure is rendered as an interactive tree navigation control, clearly visualizing the compositional relationships of the product.

[0118] And / or, Model (Business) Dimension: Based on the model tree corresponding to the data in each domain in the aggregated data model, the scenario classification is obtained by dividing the data according to the business application scenario; the domain data in the domain system is displayed according to the scenario classification.

[0119] Based on the "Domain Type" or "Business Type" attribute of each data object index in the aggregated data model, all data associated with the same system structure node is categorized by scenario. The categorization rules are predefined and correspond to different business application scenarios, such as requirements analysis, functional verification, simulation analysis, physical design, and test verification. In the presentation layer, each scenario category is mapped to an independent visual tab or a parallel panel. When a user selects a product node in the hierarchical navigation tree, the interface synchronously initializes multiple corresponding business scenario tabs. Each tab independently initiates a query in the background, specifically requesting data belonging to its category.

[0120] In the implementation of the above embodiments, an intelligent data display system was constructed by organically combining three dimensions: time, hierarchy, and business scenario. The time dimension allows users to accurately control the timeliness and historical evolution of data; the hierarchy dimension provides data navigation and aggregation paths centered on physical products and conforming to natural thinking; and the business scenario dimension achieves clear isolation and parallel in-depth analysis of multi-disciplinary data. These three dimensions work together to transform the originally scattered, heterogeneous, and multi-version complex data stream into a unified and intuitive display interface, improving the efficiency and accuracy of users searching and viewing cross-system data.

[0121] Optionally, in this embodiment of the application, displaying the domain data in the domain system based on the aggregated data model further includes at least one of the following: (1) When displaying domain data, data objects associated with the currently selected system structure node are highlighted. The front-end interface listens for the user's node selection event in the system structure navigation tree and obtains the unique identifier of the node. Then, it sends a query to the back-end to request a list of indexes of all data objects associated with this node through the aggregated data model. The front-end compares the returned list with the full data list displayed in the current tab, and dynamically highlights the matching data entries by changing the background color, adding icons or borders, etc.

[0122] (2) Provide an interface to display detailed attribute information of the selected data object and information of other data objects associated with it. When a user clicks on a displayed data object (such as a highlighted requirement), the front end initiates a details query based on the object's unique identifier. The back end retrieves all metadata attributes recorded in the object's index from the aggregated data model, such as title, code, status, description, etc., and returns them. At the same time, by querying the underlying relationship graph, it obtains summary information of other objects that have a direct relationship with the object and presents them in a structured manner in the attribute panel or sidebar.

[0123] (3) Provide controls for users to switch between different development stages or versions to view corresponding historical domain data. A dropdown selection box or segmented control is provided in the display interface. The option list dynamically obtains all existing development stages and version numbers by querying the aggregated data model. When a user switches selections, the front-end submits the selected stage and version as filter parameters along with the current system structure node ID for querying. Based on these parameters, the back-end filters and returns the data object index that meets the specified temporal conditions from the data model, and the front-end refreshes the content under each business tab accordingly.

[0124] (4) Provide links at the displayed data objects to jump to their original domain system for viewing. When rendering the display row of each data object, the front end checks whether its index information contains the "jump link" attribute. If it exists, the link is parsed and rendered as a clickable hyperlink button. When the user clicks the button, the browser's navigation function is directly triggered, opening the specific data details page of the source domain system pointed to by the link in a new window or tab, thus realizing data traceability.

[0125] (5) Visualize the horizontal relationships across development stages and the vertical relationships across system levels between different data objects. Provide a dedicated relationship tracing view. When a user specifies one or a group of data objects in this view, the backend executes a graph query algorithm based on the relationships in the aggregated data model to retrieve all data objects connected to it horizontally, such as requirements-design-test, or vertically, such as system-subsystem-standalone relationship chains. The frontend uses a graph visualization engine (such as a force-directed graph) to graphically draw the returned relationship network, using nodes to represent data objects and edges to represent relationships, supplemented by clear legends to intuitively reveal the complex network between data.

[0126] In the implementation of the above embodiments: through the aforementioned multiple display schemes, a data visualization solution that enables deep interaction and intelligent guidance is formed. Users can quickly focus on key information and view details; spatiotemporal version switching provides a dynamic perspective on data evolution; and the visualization of relationships displays data links across stages and levels. These functions collectively transform the aggregated static data model into an easily understandable dynamic knowledge network, improving the efficiency and depth of users' retrieval, analysis, and decision-making in complex cross-domain data.

[0127] In an optional embodiment, the functional processes of the digital model aggregation and organization steps are as follows: I. Data Acquisition and Synchronization in Various Domains: In the field of architecture design, data (RFL structure tree, Requirement Function Logical Tree) is parsed from two types of design models: system design models and comprehensive design models. System design model parsing is primarily used for issuing technical requirements; therefore, it is parsed after approval. Comprehensive design models, on the other hand, may be used for issuing technical requirements or for simulation verification. Their parsing timing is more flexible, depending on the actual business needs. For example, to verify whether the logical parameters meet the required indicators during simulation, the model needs to be parsed first to obtain the logical parameters and requirement indicators. Only after successful verification will the model be approved. Therefore, there may be instances where unapproved models are parsed before the required approval. To ensure data authority, Digital Mainline will not acquire unapproved data.

[0128] 1. Establishing the architecture design tree: The digital mainline periodically sends data acquisition signals to the architecture design domain. Upon receiving the signals, the architecture design domain organizes the lightweight information, hierarchical structure, and jump links parsed from the approved model into an XML file and returns it to the digital mainline's interface engine through an interface. The digital mainline parses the XML file based on the configuration file and organizes and creates index objects according to the standardized hierarchical structure.

[0129] The correspondence between data types and attributes in the architecture design and the digital master data:

[0130] Once the digital masterline has created data in the architecture design domain, it still periodically sends data acquisition signals to the architecture design domain. The mechanisms for identifying whether to update the data include the following: If the architecture design business data is identified as being parsed from an approved model and no identifier has been acquired, then the RFL structure tree corresponding to the Digital Mainline needs to be updated. Because the data uploaded to the Digital Mainline uses a tiled structure, the vertical and horizontal relationships can be expressed on individual data points. Therefore, the updated data only needs to be packaged into an XML file and sent to the Digital Mainline. The Digital Mainline will then perform incremental updates.

[0131] If it is identified that the business data of the architecture design is not parsed from the approved model, or has an identifier that has already been acquired, then a signal that no update is required should be returned to the digital mainline.

[0132] 2. Simulation model data acquisition and synchronization: The digital thread interacts directly with the product lifecycle management platform, which manages the controlled records of simulation models during the evolution of the simulation model collaborative management tool. Furthermore, the digital thread can access the simulation model collaborative management tool from the product lifecycle management platform to view the simulation models. Therefore, the digital thread can obtain approved lightweight simulation model information and links to simulation entity models from the product lifecycle management platform, with the obtained simulation model links redirecting to the simulation model collaborative management tool.

[0133] The Digital Mainline simulation model tree creation process involves the Digital Mainline periodically sending data acquisition signals to the simulation model domain. The simulation model domain returns the lightweight information, hierarchical structure, and index links of the approved models to the Digital Mainline via an interface in JSON format. The Digital Mainline's interface engine parses the JSON file based on a configuration file and then creates the Digital Mainline simulation model tree. Acquired models are recorded and identified to prevent the program from repeatedly acquiring the same model.

[0134] Correspondence between simulation model data attributes and types and digital thread attributes and types:

[0135] The granularity of simulation domain control is at the level of controlled model records. Furthermore, once a version of a simulation model has been approved and signed off on by the product lifecycle management platform, it will not be deleted or modified. Once the digital masterline has created the simulation model domain's tree structure, only new data is added to the tree; deletions and changes are not allowed. The digital masterline periodically sends data acquisition signals to the simulation model domain. Upon receiving the signals, the simulation domain checks the data. If it identifies a model that has been approved but not yet acquired, it returns the new data information to the digital masterline via an interface in the form of an XML file. The digital masterline then parses the XML and incrementally creates the relevant objects in the simulation model tree.

[0136] 3. Simulation verification data acquisition and synchronization: During the system architecture design process, system simulation is used to verify the accuracy of the architecture design data. In the product lifecycle management platform, simulation verification data is divided according to simulation domains. Each simulation domain contains simulation tasks, and a simulation report is sent back upon completion of the simulation verification. The digital masterline constructs a structure tree for the simulation verification data based on the information in the XML file, organizing each simulation domain by model number and storing the unique identification information and links of the simulation tasks.

[0137] Digital Mainline's simulation verification tree creation: When a simulation report is sent back to a simulation task, it indicates that the simulation task's data has stabilized. Digital Mainline focuses on building the relationships between simulation tasks and other data. Although it identifies stable states through simulation reports, it does not retrieve simulation reports for specific simulation tasks. Digital Mainline periodically sends data acquisition signals to the simulation verification domain. The simulation verification domain uploads model information, simulation domain, basic information of the simulation task, hierarchical structure information, and links in XML format to Digital Mainline's interface engine. The interface engine parses the XML file based on the configuration file and creates Digital Mainline's simulation verification tree. Simultaneously, the acquired simulation tasks are recorded and identified to prevent the program from repeatedly acquiring the same data.

[0138] Data types and their corresponding relationships:

[0139] The simulation verification tree update process in the digital mainline is as follows: Once a simulation report for a simulation task is returned, that task will not be modified or deleted. Therefore, the simulation verification tree in the digital mainline only allows additions; deletions and modifications are not possible. The digital mainline periodically sends a data acquisition signal to the simulation verification domain. If it detects a simulation task with a returned simulation report that has not yet been acquired, the digital mainline needs to add that task. The simulation domain returns the newly added simulation task data and its unique identification information to the digital mainline via an interface. The digital mainline parses this data, acquires it, and brings it back to the digital mainline to incrementally create new simulation task objects on the simulation verification tree.

[0140] 4. System test data acquisition and synchronization: System testing is primarily used to comprehensively detect potential design flaws and various problems within the system, supporting spacecraft design verification. The system test data on the product lifecycle management platform is organized in a tree structure, with levels descending from the root node: test management, system-level testing, subsystem testing, test requirements, and test cases. Test data features complete lifecycle status and version management; the digital thread retrieves the latest version and stable state data of the system test data.

[0141] System test data creation for the Digital Mainline: When the root node of the test management tree reaches the "released" state, it signifies that the entire tree has reached a stable state. The Digital Mainline periodically sends a data retrieval signal to the system test data domain, uploading the unique identification information, hierarchical relationships, and links of the test management tree's root node, system-level tests, subsystem tests, and test requirements to the Digital Mainline's interface engine in XML file format. The interface engine parses the XML file based on the configuration file and creates the Digital Mainline's system test tree. The system test domain marks uploaded data as already retrieved to prevent duplicate uploads.

[0142] Digital Mainline System Test Data Updates: Test requirements in the test management tree may be added, deleted, or modified. When changes are needed, the test management root node will be upgraded. When the new version of the test management root node reaches its release date, it indicates that the new version of the test management tree has stabilized, and the old version will become obsolete. When the Digital Mainline sends a data acquisition signal to the system test data domain again, the Digital Mainline will recognize the latest version and return the unique identification information, links, and hierarchical structure of the test management tree without an acquired identifier to the Digital Mainline via an interface. The Digital Mainline will then parse this information and incrementally update the original tree structure.

[0143] 5. IDS Data Acquisition and Synchronization: The IDS system receives data from the upstream logical architecture design and carries the parameter information of the individual machines. The parameter information of the individual machine IDS serves as the input for the downstream 3D design and is the key information for the individual machine design. At the same time, it is used to drive the approval process and plays a vital role in the model development process.

[0144] The IDS system uses a flat data management structure, while Digital Mainline aims to build a data infrastructure and clearly display the relationships between data in a tree structure. Therefore, after Digital Mainline acquires the single-machine IDS files, it needs to be reorganized into a tree structure for display. Furthermore, single-machine IDS systems have lifecycle and version management; an "included" status indicates that all its content is stable and under control, while an "obsolete" status indicates that it has been deprecated. If parameter information needs to be changed, a version upgrade will be implemented.

[0145] Digital Mainline acquires IDS system data creation: When a single-unit IDS reaches the "included in database" status in its lifecycle, it signifies a stable state. Digital Mainline periodically sends data acquisition signals to the IDS system, calling the IDS's interface. The system packages the unique identification information of the included single-unit IDS forms into an XML file and returns it to Digital Mainline. Digital Mainline parses the XML file information, including model number, system, subsystem, equipment code, and development stage, and uses a relational meta-model and relational configuration to construct data relationships, ultimately organizing them into an IDS structure tree.

[0146] Data updates in the Digital Mainline IDS system: This involves scenarios where single-machine IDSs undergo changes and become obsolete within the IDS system. When the content of a single-machine IDS needs to be changed, it will be upgraded within the IDS system, and the new version's lifecycle will change to "pending submission." If a single-machine IDS needs to be obsolete, its lifecycle status will be adjusted to obsolete. When Digital Mainline sends a data retrieval signal to the IDS system again, Digital Mainline will identify data already in the database and will bring back the basic information of single-machine IDSs that do not have a retrieval identifier; if the data is obsolete, Digital Mainline will delete the corresponding single-machine IDS from the tree structure.

[0147] 6. 3D design data acquisition and synchronization: 3D design data is stored in the 3D Collaborative Management System. The EBOM data within this system has complete lifecycle management and version control. Digital Mainline retrieves basic 3D design information and links from the 3D Collaborative Management System and uploads them as XML files to its interface engine. The interface engine parses the XML files based on configuration files and creates a 3D design structure tree for Digital Mainline. When detailed 3D data is needed, users are redirected to the 3D Collaborative Management System.

[0148] Digital Masterline 3D Design Data Creation: During the model development process, each model will have an independent EBOM structure tree, which carries a lot of information on individual machines and parts. Considering the server's operating efficiency and the update frequency of digital masterline data, the EBOM uses the third-level node of each model as the identifier that the data identified by the digital masterline is under control and stable. This is because in the 3D collaborative management system, the control of parent and child assemblies means that the life cycle of all child levels has reached the controlled state.

[0149] 3D design data updates for the digital masterline: In engineering practice, when the upstream architecture design model changes or the single-machine IDS parameter information changes, the 3D design needs to be modified accordingly. These modifications include adding parts, deleting parts, and updating parts in 3D. In the 3D collaborative management system, parts need to be upgraded to complete these changes. However, the following rules must be noted: Part updates in the 3D collaborative management system do not follow the bubble upgrade principle; only the parent assembly corresponding to the addition or deletion of a part requires an upgrade. When the digital masterline sends a data acquisition signal to the 3D design domain again, the 3D collaborative management system will return the changed part information, hierarchical relationship information, horizontal relationships, and links to the digital masterline through the interface. The digital masterline parses the data according to the data correspondence in the configuration file and incrementally updates the original EBOM structure tree.

[0150] II. Establishing node relationships: After establishing the system architecture, the data from the digital mainline needs to be associated with the system architecture nodes to lay the foundation for subsequent data display. As can be seen from the spacecraft development business model, most business domains have system, subsystem, and individual device objects, which can serve as bridges connecting data between business domains and the system architecture. The implementation approach of this application is to first construct the association relationships between systems, subsystems, individual devices, and system architecture nodes within a domain, and then establish the association relationships between domain data and system architecture nodes.

[0151] There are two ways to build node relationships: matching relationship rules or manually creating relationship mappings.

[0152] Relationship rule matching: This involves defining unique identifiers for node objects in each research and development domain. For example, defining unique identifiers for data objects such as nodes in the logical architecture, IDS devices, EDS devices, and EBOM nodes, using a relationship rule engine.

[0153] Manually establish relationship mapping: For data that has not yet defined a unique identifier or cannot be matched by relationship rules, relationships between nodes can be established manually.

[0154] To support the execution and application of aggregation rules, a rule parser is built to parse the syntax and structure of the script, and to perform rule script transformation and trial runs. The main functions of the rule parser are as follows: 1. Rule Text Analysis: Based on fixed scripting language specifications, check the semantic correctness of the compiled scripts to ensure that variables, functions, and operators in the rules are valid and conform to business logic; verify whether the rule scripts meet specific business constraints and the requirements of the rule engine, such as checking for circular references or undefined variables. Simultaneously, provide clear error messages and suggestions for non-compliant rules through the interface.

[0155] 2. Rule Conversion and Feedback: After completing the text analysis, the parsed rule script is converted into an internal program form that can be understood and executed internally; at the same time, the functions that require the definition of input parameters are provided in the form of pages.

[0156] 3. Rule Preview and Trial Run: The converted rule scripts need to be tested and verified. Preview and trial run functions are provided to complete the actual rule script verification work.

[0157] III. Association between Domain Data and System Structure Nodes: The data types that the model aggregation and organization module needs to associate are shown in the following figure. The data types to be associated and their descriptions are as follows: 1. Requirements Information: This includes requirements specifications and item information, covering requirements from stakeholders, system level, subsystem level, and individual equipment. 2. Functional Information: Includes functional specifications and functional item information, covering system-level, subsystem, and standalone device functions; 3. Architecture information: including architecture components, interface information, signals and materials transmitted through the interfaces, and parameter information, covering system-level and subsystem architecture components; 4. System simulation parameter information: including mechanical load, resistive load, thermal load, telemetry parameter information, and remote control command information. Covering the system level, subsystem level, and individual device levels; 5. IDS parameter information: including mechanical, power supply and distribution, thermal control, telemetry parameters and remote control command information, covering single-unit equipment; 6. EDS related information: including telemetry parameters and remote control command information, covering single-unit equipment; 7. EBOM related information: including product design composition, number of components, list description, etc., covering system level, subsystem level, and single device; 8. System Design Model: Includes the overall system design model, system integration model, and subsystem design model of the spacecraft; if a SysML model has been issued for the overall project, it should also be associated with it.

[0158] 9. System simulation models: including system-level simulation models, subsystem-level simulation models, and single-machine-level simulation models.

[0159] The following sections will explain how the modules mount the data to the system nodes after acquiring it, based on the characteristics of the business data.

[0160] 1. Requirements Information: Requirements information includes the technical requirements / general development requirements received by the spacecraft as a whole, the system-level requirements captured by the spacecraft as a whole, and the subsystem technical requirements proposed to the subsystems. Its data format includes requirement specifications, requirement items, and indicators.

[0161] Although requirement information lacks logical or physical nodes, in the system design phase, requirements are associated with functions, and functions are associated with the system architecture. The system architecture, through a relational rule engine, constructs the system structure node relationships along a digital mainline. Therefore, requirement data can be attached to system structure nodes along this relational chain. It is worth noting that some requirement data may not yet be directly associated with functions, such as certain constraint-type requirements in the overall development requirements. If these requirements need to express their relationship with the system structure during presentation, the relationship between requirements and architecture must be established during modeling.

[0162] 2. Functional Information: Functional information refers to the product's functions captured during the system design and analysis process. It is mainly reflected in the flight procedure diagram. The current spacecraft model can improve the allocation relationship between the model flight procedure diagram and the system architecture. Once the allocation relationship is improved, this functional module can associate and display the functions of each level of the model design.

[0163] 3. Architecture Information: Architecture information is organized in the form of systems, subsystems, and standalone devices. The system structure definition in this module is the same as the architecture composition of the system design. In the relationship rule engine, the identification information of the system structure and architecture composition can be configured to complete the construction and matching of node relationships.

[0164] 4. System Design Model: The overall system design model and integrated design model are associated with system-level nodes by default. Subsystem design models need to be supplemented with identifiers defined in the SysML management module so that the subsystem design models and subsystem nodes of the system structure can be matched and associated according to the identifiers and relationship rules.

[0165] 5. System simulation model: The system-level simulation model is associated with the system-level node by default. The subsystem-level simulation model and the single-machine-level simulation model can be improved with identification numbers so that they can be matched and associated according to the identification numbers and relationship rules.

[0166] 6. System simulation parameter information: Once the system structure can be associated with the system simulation models at each level, the parameters in the models are extracted and mounted on the system structure nodes according to professional classification.

[0167] 7. IDS Information: The data provided by IDS is mostly flat, containing only single-machine data and lacking system-level and subsystem-level objects. IDS device nodes establish associations with the system structure by matching device codes with business relationship rules. Mechanical, power supply and distribution, thermal, telemetry, and remote control functions within the equipment are associated with nodes in the system structure according to their respective professional types.

[0168] 8. EDS Related Information: Although the EDS system contains information on model, subsystem, and individual device objects, telemetry information and remote control commands are only reflected in individual devices. Therefore, telemetry and remote control data should be attached to the individual device nodes of the system structure. The association between EDS individual devices and the system structure is achieved through device code association.

[0169] 9. EBOM Related Information: EBOM-related information includes the product design composition, component quantity, list description, etc., covering system-level, subsystem-level, and standalone device levels. Each level of node is associated with the system structure through a relationship rule engine. Currently, standalone devices have explicit device codes that can be directly matched with system structure codes. IV. Organization and Display of Unified and Aggregated Model Data: After the data aggregation and organization module completes the system structure construction and associates business data, it will display the data according to business domains and scenarios. The design concept of this application is to use the system structure as navigation for easy data retrieval, with each business domain displayed in a tree structure. The scope and strategy of data display are as follows: (1) In terms of time, the data displayed covers data from each development stage. As a product that undergoes multiple iterations and is launched only once, all development data for spacecraft are based on the latest controlled data. Based on this characteristic, the latest version of controlled data from the latest development stage is displayed by default when showing the data. In addition, considering the possibility of searching and browsing historical data, this module supports users to retrieve historical versions of data from previous stages.

[0170] (2) In terms of hierarchy, the system structure includes at least system-level, subsystem-level, and single-device-level nodes, with each node associated with data. When displaying the information, all structured information is presented according to the business domain, and data related to the nodes is marked with special tags for easy user access.

[0171] (3) In terms of model dimension, the data of each domain model is divided according to business application scenarios, and the data is organized in a structured form in different tab interfaces.

[0172] Please see Figure 2 The illustration shown is a schematic diagram of a requirement data display provided by an embodiment of this application.

[0173] The specific forms of data display are as follows: Figure 2 As shown: the system structure on the left serves as a "navigation bar" for data retrieval, while the right side displays requirement information, functional information, architecture information, model information, system simulation parameters, IDS parameters, EDS information, and EBOM information.

[0174] Requirements Information Display: After selecting a node in the system structure (e.g., selecting the battery node), the requirements information interface will display all the requirements specifications of the latest version of the latest development stage by default, and the requirements items related to the battery single-unit node will be specifically marked (highlighted).

[0175] Please see Figure 3 The illustration shown is a schematic diagram of a requirement data attribute display provided by an embodiment of this application. Selecting a requirement object allows you to view detailed information about the requirement, including the requirement's title, content, type, and other information.

[0176] Please see Figure 4 The illustration shown is a schematic diagram of an indicator data attribute display provided by an embodiment of this application. The indicator information associated with the requirement can also be viewed on the requirement details page.

[0177] Please see Figure 5 The illustration shown is a schematic diagram of a functional information display provided by an embodiment of this application. Functional information display: After selecting a node in the system structure (e.g., selecting the battery node), the latest version of all functional specifications information in the latest development stage is displayed by default on the functional information interface, and the functional items related to the battery node are specifically marked (highlighted).

[0178] Please see Figure 6 The illustration shown is a schematic diagram of an architecture information display provided by an embodiment of this application. Architecture information display: After selecting a node in the system structure (e.g., selecting the battery node), the architecture information interface will display all logical architecture information and interface information of the latest version in the latest development stage by default.

[0179] Please see Figure 7 The diagram shown is a schematic representation of the architecture design parameters provided in an embodiment of this application. The interface details can display the material or energy flow information, parameters, and parameter values ​​transmitted by the interface.

[0180] Please see Figure 8 The illustration shown is a schematic diagram of a model information display provided by an embodiment of this application. Model information display: After selecting a node in the system structure interface, the system design model and system simulation model related to the node can be displayed.

[0181] Please see Figure 9 The diagram shown is a schematic representation of a system simulation parameter display provided in an embodiment of this application. System simulation parameter display: After selecting a node in the system structure interface, the system simulation parameter page displays mechanical, resistive, thermal, telemetry, and remote control parameter information related to the node.

[0182] Please see Figure 10 The illustration shown is a schematic diagram of an IDS parameter display provided by an embodiment of this application. IDS parameter display: After selecting a node in the system structure interface, the IDS parameter page can display parameter information of the mechanical, thermal, and electrical properties related to the node.

[0183] Please see Figure 11 The illustration shown is a schematic diagram of a model information display provided by an embodiment of this application. EDS Information Display: After selecting a node in the system structure interface, the telemetry information and remote control commands related to the node can be displayed on the EDS information page.

[0184] Please see Figure 12 The illustration shown is a schematic diagram of EBOM information display provided by an embodiment of this application. EBOM information display: After selecting a node in the system structure interface, the EBOM information related to the node can be displayed on the EBOM information page. The device details interface displays information such as the device name, device number, and quantity.

[0185] Please see Figure 13 The illustration shown is a schematic diagram of historical data retrieval provided by an embodiment of this application. Historical data retrieval: The interface for data aggregation and organization displays the latest version of data by default, and supports switching between development stages and version information within the interface to retrieve historical data.

[0186] Please see Figure 14 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the method described above is performed.

[0187] Figure 14 The components shown can be implemented using hardware, software, or a combination thereof. Electronic device 300 may be a physical device, such as a server or PC, or a virtual device, such as a virtual machine or virtualization container. Furthermore, electronic device 300 is not limited to a single device; it can be a combination of multiple devices or a cluster of numerous devices.

[0188] This application also provides a storage medium storing a computer program, which is executed by a processor to perform the above-described method.

[0189] The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0190] This application also provides a computer program product, including computer program instructions, which are executed by a processor to perform the method described above.

[0191] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, given the several embodiments provided in this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0192] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0193] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.< / device> < / dcterms:classid> < / dcterms:name>

Claims

1. A data presentation method, characterized by, The method is applied to a digital main line, and the method comprises: sending a data acquisition signal to a domain system to acquire a domain data file; the domain system comprises an architecture design domain and a business domain; the business domain comprises at least one of a simulation model domain, a simulation verification domain, a system test data domain, an IDS system and a three-dimensional collaborative management system; parsing the domain data file, constructing a model tree corresponding to each domain data respectively, and creating an index of a data object in each model tree in the digital main line; the index is used to query the data object of the domain data through the digital main line; wherein a node of the model tree is an entity in the domain data; associating a node representing a product composition structure in the model tree corresponding to the business domain with a unique system structure node defined by the model tree corresponding to the architecture design domain for global navigation to obtain an associated network centered on the system structure node; based on the associated network and / or data characteristics of the domain data, mounting the data object corresponding to the domain data to the system structure node to generate a converged data model; based on the converged data model, displaying the domain data in the domain system.

2. The method of claim 1, wherein, The model tree corresponding to the business domain comprises first-type nodes and second-type nodes; the first-type nodes are nodes representing products in a system, a subsystem and / or a single machine device in the corresponding domain; associating the node representing the product composition structure in the model tree corresponding to the business domain with the unique system structure node defined by the model tree corresponding to the architecture design domain for global navigation to obtain the associated network centered on the system structure node comprises: associating the first-type nodes of the model tree corresponding to the business domain with the system structure node of the model tree corresponding to the architecture design domain to obtain a first association relationship; the first association relationship is used to provide a reference for the association process of the second-type nodes; based on the first association relationship and / or data characteristics of the domain data, associating the second-type nodes of the model tree corresponding to the business domain with the system structure node of the model tree corresponding to the architecture design domain to obtain a second association relationship; summarizing the first association relationship and the second association relationship to obtain the associated network centered on the system structure node.

3. The method of claim 1, wherein, The method comprises: sending a data acquisition signal to the domain system to acquire the domain data file returned by the domain system based on a signed model or stable state data; the signed model is used to control the data that has passed the review; the domain data file comprises basic information, hierarchical structure relationship and / or index link organization.

4. The method of claim 1, wherein, After parsing the domain data file and constructing the model tree corresponding to each domain data respectively, the method further comprises: adding an acquired identifier to the data in the domain data file that has been acquired; wherein the acquired identifier is used to indicate that the corresponding data has been acquired by the digital main line. According to the preset rule, the data acquisition signal is sent to the domain system again to acquire the target domain data file returned by the domain system; If it is determined that the data in the target domain data file does not have the acquired identifier, an updated domain data file is generated according to the data without the acquired identifier; Based on the updated domain data file, the model tree is incrementally updated to obtain an updated model tree.

5. The method of claim 1, wherein, The domain data file is parsed, and a model tree corresponding to each domain data is constructed, and an index of a data object in each model tree is created in the digital main line, including: The domain data file is parsed, and the attributes of the data object and the hierarchical relationship between the data objects are extracted; Based on the hierarchical relationship, a model tree reflecting the internal organization structure of the domain data is constructed; According to the attributes, a corresponding index of each data object of the model tree is created in the digital main line; the index includes basic information for uniquely identifying the data object, and a jump link for accessing the complete content of the data object in the domain system.

6. The method of claim 1, wherein, The node of the model tree corresponding to the business domain is associated with the system structure node of the model tree corresponding to the architecture design domain, including: A pre-set relationship rule script is acquired, the relationship rule script is parsed and converted by a rule parser to generate matching logic, and based on the matching logic, the unique identifier of the node of the model tree corresponding to the business domain is matched with the unique identifier of the system structure node, and an association relationship is established according to the matching result; Or; A user operation interface is provided, and in response to a user's association operation on the model tree node of the business domain and the system structure node in the user operation interface, an association relationship between the node of the model tree corresponding to the business domain and the system structure node of the model tree corresponding to the architecture design domain is established; Or; Based on semantic similarity analysis, the attribute information of the node in the business domain model tree is compared with the attribute information of the system structure node, and an association relationship is recommended and established according to the comparison result.

7. The method of claim 1, wherein, Based on the association network and / or the data characteristics of the domain data, the data object corresponding to the domain data is mounted to the system structure node to generate a converged data model, including: Based on the association network and / or the data characteristics of the domain data, a corresponding mounting logic is used to establish an association relationship between the data object and the system structure node to generate a converged data model; wherein the mounting logic includes link mounting, identifier matching mounting and / or parameter mounting.

8. The method of claim 7, wherein, The mounting logic includes link mounting; the data object includes requirement information; and the data characteristics of the domain data include the relationship link of the data object. The data object and the system structure node are associated by using a corresponding mounting logic, including: The relationship link corresponding to the requirement information is acquired; the relationship link corresponding to the requirement information includes the association relationship from the design requirement to the design function, and from the design function to the system architecture; Based on the relationship link, the requirement information and the system structure node are associated.

9. The method of claim 7, wherein, The mounting logic includes identifying matching mounting; the data object includes IDS information; and the data object is associated with the system structure node by using corresponding mounting logic, including: Obtaining the equipment code of the single equipment from the IDS information; matching the equipment code with the equipment code of the system structure node, and mounting the IDS information to the matching system structure node according to the category of the single equipment.

10. The method of claim 7, wherein, The mounting logic includes parameter mounting; The data object includes simulation parameter information; The data object is associated with the system structure node by using corresponding mounting logic, including: After the simulation model node in the simulation model field is associated with the system structure node, parameter information is extracted from the simulation model node; the parameter information includes mechanical load, resistive load, thermal load, telemetry parameter and remote control instruction information; According to the extracted parameter information, the simulation parameter information is mounted to the system structure node.

11. The method of claim 1, wherein, Based on the converged data model, the field data in the field system is displayed, including: Based on the time information recorded in the converged data model, the field data in the field system is displayed according to the time dimension; And / or, based on the hierarchical information of the model tree corresponding to the architecture design field in the converged data model, the field data in the field system is displayed according to the hierarchical dimension; And / or, based on the model tree corresponding to each field data in the converged data model, the scene classification is obtained according to the business application scenario division; the field data in the field system is displayed according to the scene classification.

12. The method of claim 11, wherein, Based on the converged data model, the field data in the field system is displayed, including at least one of the following: When displaying the field data, the data object associated with the currently selected system structure node is highlighted; Provide an interface to display the detailed attribute information of the selected data object and the information of other data objects associated with it; Provide a control to allow users to switch between different development stages or versions to view the corresponding historical field data; Provide a link at the displayed data object to jump to the original field system where it is located for viewing; Visually display the horizontal association between different data objects across development stages and the vertical association relationship chain across system levels.

13. A computer program product, characterised in that, Computer program instructions are included, which are executed by a processor to perform the method of any one of claims 1-12.

14. An electronic device, comprising: Including: A processor and a memory, the memory storing computer program instructions, the computer program instructions being executed by the processor to perform the method of any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, which are executed by a processor to perform the method of any one of claims 1-12.

Images