A multi-source heterogeneous data integration and tracing method and system for modeling and simulation analysis in the aviation field

Abstract

The application discloses a kind of multi-source heterogeneous data integration tracing methods and systems for modeling simulation analysis in aviation field.The method comprises the following steps: step S1: constructing multi-source heterogeneous data specification system;Step S2: realizing the unified representation of SysML model based on aviation field special metamodel;Step S3: constructing the bidirectional traceable modeling of function-physical domain interface;Step S4: tool chain data transmission and tracing.This application realizes the standardized processing, unified representation, element-level tracing and global change synchronization of data, significantly improves the efficiency of modeling simulation analysis in aviation field and data consistency, full life cycle model integration and tracing capability, reduces the integration cost of tool chain, and eliminates the data barrier between tools.

Description

Technical Field

[0001] This invention belongs to the field of aviation systems engineering technology, specifically relating to a method and system for integrating and tracing multi-source heterogeneous data for modeling and simulation analysis in the aviation field. Background Technology

[0002] In advancing Model-Based Systems Engineering (MBSE) in the aerospace field, the first step is to clarify its core object—multi-source heterogeneous models. Multi-source heterogeneous models refer to the collection of various models generated by different sources and types of tools throughout the entire lifecycle of an aerospace product (from requirements definition, functional design, physical modeling to simulation verification).

[0003] The multi-source nature of the models is manifested in their origins from different design phases, business teams, or vendors' tools. Examples include structured requirements tools (such as Doors) from the requirements phase, modeling tools (such as Catia Magic) from the functional design phase, and 3D design tools (such as CAD) from the physical simulation phase. The heterogeneity manifests in significant differences in data formats (such as XML, JSON, and custom binary formats), modeling logic (such as function-oriented block diagram modeling versus physics-oriented parametric modeling), and data dimensions (such as geometric data, performance simulation data, and security analysis data). These differences are the fundamental obstacles to achieving cross-phase collaboration in MBSE technology.

[0004] Currently, the MBSE technology system still has significant room for improvement in meeting user needs for efficiency and quality, specifically in three core areas: First, there is a lack of unified and deeply compatible industry standards.

[0005] Currently, the aviation MBSE (Model-Based SE) field lacks a comprehensive data and model standard system covering the entire process, resulting in fundamental obstacles to cross-stage and cross-system collaboration. On one hand, international standards fail to deeply integrate modeling requirements: while standards such as ISO / TS 10303 (STEP, Standard for the Exchange of Product model data) AP233 and AP209 define some basic data formats, they only focus on the data itself and are not deeply integrated with the structure, logic, and relationships of the MBSE model, thus failing to support the integrated flow of model and data. On the other hand, there are significant gaps in domestic standards: standards related to complex product digital models are lacking, and each manufacturer develops its own proprietary specifications based on its own technical path. This directly exacerbates the collaboration barriers between PLM (Product Lifecycle Management) systems and professional design tools (such as requirements definition tools and physical simulation tools) and simulation systems, forcing companies to invest heavily in developing customized interfaces, significantly increasing the cost of technology implementation.

[0006] Second, the upstream and downstream of the toolchain are difficult to integrate, relying on each software to develop compatible functions, resulting in low collaboration efficiency.

[0007] like Figure 1 As shown, the existing aerospace MBSE toolchain covers multiple stages, including requirements definition, functional modeling, physical simulation, and safety analysis (e.g., Doors for requirements, Catia Magic for functional modeling, Modelica for physical simulation, and Medini for safety analysis). The lack of a unified data transfer standard between upstream and downstream tools, relying entirely on data compatibility features independently developed by each software vendor, results in an inefficient and fragile collaborative model. Specifically, tools at different design stages operate in silos, with significant differences in data formats and database dependencies. Inter-tool interaction requires the development of specific point-to-point interfaces, leading to high development costs and difficulty in handling compatibility issues after tool upgrades or replacements. The ideal collaborative model should be a bus-based interaction, where tools achieve standardized data transmission through a unified bus, rather than point-to-point connections. More importantly, this reliance on software compatibility causes frequent data transmission breakpoints throughout the requirements-design-simulation process, preventing the formation of a continuous digital thread and severely hindering the implementation of the entire MBSE process.

[0008] Third, similar software lacks standardized business data definitions, has rampant custom formats, and suffers from insufficient product interchangeability.

[0009] Even among SysML modeling tools focusing on the same business domain, the lack of a unified standard for defining business data significantly reduces model interchangeability and reusability. Mainstream tools such as IBM Rhapsody, Catia Magic, and SysDeSim, while claiming support for the SysML specification, introduce numerous custom data formats in their actual implementations—including attribute definitions for model elements, association rules, and rendering logic. This necessitates manual format adjustments and display corrections during cross-tool model migration, increasing manual costs and increasing the risk of data errors. Furthermore, custom formats make metadata generated by different tools (such as ID rules for model elements and version management logic) difficult for other tools to recognize and understand, severely hindering model reuse across different teams and projects, significantly reducing team collaboration efficiency, and increasing the difficulty of model consistency verification.

[0010] In summary, the aforementioned issues collectively hinder the effective integration and end-to-end traceability of multi-source heterogeneous data, impeding the full-process implementation of aviation MBSE technology. Therefore, an improved solution is urgently needed to address the shortcomings of existing technologies. Summary of the Invention

[0011] In view of the above-mentioned deficiencies of the prior art, the first aspect of the present invention provides a method for integrating and tracing multi-source heterogeneous data for modeling and simulation analysis in the aerospace field, comprising the following steps: Step S1: Construct a multi-source heterogeneous data standardization system; through a two-layer architecture of international standard adaptation and custom encapsulation supplement, eliminate data barriers between tools and standardize all types of data, including structured data, semi-structured data, unstructured data, and gray-box / black-box models. Step S2: Implement a unified representation of SysML models based on aerospace-specific meta-models; Specifically, by defining a dedicated meta-model for the aerospace field and storing it serially, it ensures that different modeling tools can parse and exchange SysML model instances based on the same meta-model; at the same time, a tool adaptation layer is established to automatically convert the unique private formats of each modeling tool. Step S3: Construct bidirectional traceable modeling for the functional-physical domain interface; The interface features are described graphically, the mapping relationship between the functional parameters of the functional requirements and the physical attributes of the physical implementation is established, and the element-level traceability of the functional interface and the physical interface is realized through a unique ID. Step S4: Toolchain data transfer and traceability; with a centralized data warehouse as the core, multimodal data and their relationships are stored in a unified manner, data flow paths are designed, and global change synchronization is performed during change traceability.

[0012] In the multi-source heterogeneous data integration and traceability method described above, optionally, the structured data includes at least one of the following: requirement entries, SysML model elements, and data in a relational database; the semi-structured data includes at least one of the following: XML or JSON format configuration files or exchange files; the unstructured data includes at least one of the following: design documents, simulation reports, PDF review reports, simulation logs, and test reports; and the gray-box / black-box model includes at least one of the following: FMU (Functional Mock-up Unit), Simulink model, and Modelica model.

[0013] In the multi-source heterogeneous data integration and traceability method described above, optionally, in step S1, the ReqIF (Requirements Interchange Format) requirement exchange format standard is used for structured exchange of requirement data; The model is represented in a structured manner through the Meta-Object Facility (MOF) and the XML Metadata Interchange (XMI) standard; and the simulation model is integrated across tools by relying on the Functional Model Interface (FMI). For black-box models, the Functional Model Interface (FMI) standard is adopted, and the model is directly mounted as a standardized component to the co-simulation platform without the need to parse its internal logic. For gray-box models, the System Structure and Parameters Standard (SSP) is adopted to define the model encapsulation specification, and the packaging format of XML and model files is designed. The structural parameters, configuration information and resource associations of the gray-box model are recorded through XML index. For unstructured data, XML indexes are used to record its association with structured data and version information, replacing the point-to-point interface development model between tools.

[0014] In the multi-source heterogeneous data integration and tracing method described above, optionally, in step S2, a special meta-model for the aviation field is defined based on the Meta Object Facility (MOF), which clarifies the attributes and association rules of elements including at least requirements, components, and interfaces, and fully aligns with the core elements of the SysML specification. The aviation-specific meta-model is serialized and stored using the XMI metadata exchange standard to ensure that different modeling tools can parse and exchange SysML model instances based on the aviation-specific meta-model at the grammatical level. Establish a tool adaptation layer, design an incremental import / export mechanism for the unique extensions of each modeling tool, and automatically convert the tool's private format through predefined mapping rules.

[0015] In the multi-source heterogeneous data integration and tracing method described above, optionally, in step S3, a SysML Block Definition Diagram (BDD) and an Internal Block Diagram (IBD) are used to jointly describe the interface characteristics, wherein the Block Definition Diagram (BDD) defines the interface type and performance parameters, and the Internal Block Diagram (IBD) clarifies the signal flow and connection relationship. The mapping relationship between functional parameters of functional requirements and physical properties of physical implementation is established through two types of rules: direct binding of attribute-value pairs, and dynamic derivation by production rules. Based on the element-level traceability mechanism, the functional parameters and physical attributes are associated with a unique ID to obtain a unified expression framework for the function-physical domain interface, which supports the structured expression of the function-physical domain interface and its traceability relationship.

[0016] In the multi-source heterogeneous data integration and traceability method described above, optionally, in step S4, a centralized data warehouse is constructed, a hybrid storage architecture is adopted to uniformly store structured and unstructured multimodal data, and the traceability relationship associated with the unique ID in step S3 is stored. Establish standardized service interfaces to enable data interaction between the demand management tools, architecture modeling and simulation tools, collaborative simulation tools, security analysis tools, and ICD management tools and the centralized data warehouse; Design a data flow path to establish a closed loop: importing demand data into a centralized data warehouse, architecture tools generating models based on demand, simulation tools calling the Functional Model Interface (FMI) for model calculation, and the results flowing back to the centralized data warehouse.

[0017] In the multi-source heterogeneous data integration and tracing method described above, optionally, during change tracing, an impact analysis engine is developed to construct a network relationship graph based on the tracing relationship associated with the unique ID in step S3, automatically locate the scope of the change's impact, and perform real-time synchronization and end-to-end tracing of data throughout the entire lifecycle.

[0018] To achieve the above objectives, a second aspect of the present invention provides a multi-source heterogeneous data integration and tracing system for modeling and simulation analysis in the aviation field, wherein the method for multi-source heterogeneous data integration and tracing for modeling and simulation analysis in the aviation field as described in any one of the first aspects includes: The multi-source heterogeneous data standardization system construction module is configured as a two-layer architecture that combines international standard adaptation with custom encapsulation to eliminate data barriers between tools and standardize all types of data, including structured data, semi-structured data, unstructured data, and gray-box / black-box models. The SysML model unified representation module is configured to define aerospace-specific meta-models and serialize and store them to ensure that different modeling tools can parse and exchange SysML model instances based on the same meta-model; the SysML model unified representation module also includes a tool adaptation layer for automatically converting the unique private formats of each modeling tool. The bidirectional traceability modeling module for the functional-physical domain interface is configured to describe interface features in a graphical way, establish a mapping relationship between functional parameters of functional requirements and physical attributes of physical implementation, and realize element-level traceability between functional interfaces and physical interfaces through a unique ID. The toolchain data transfer and traceability module is based on a centralized data warehouse and is configured to uniformly store multimodal data and their relationships, design data flow paths, and perform global change synchronization during change traceability.

[0019] To achieve the above objectives, a third aspect of the present invention also provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor runs the program, it implements the multi-source heterogeneous data integration and traceability method as described in any of the embodiments of the first aspect above.

[0020] To achieve the above objectives, a fourth aspect of the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions or a computer program, which, when processed and executed by a processor, implement the multi-source heterogeneous data integration and traceability method as described in any of the embodiments of the first aspect.

[0021] This invention addresses the shortcomings of existing aviation MBSE technology systems, such as lack of standards, inefficient toolchain collaboration, insufficient model interchangeability, and broken data traceability. It precisely solves the following four key technical problems and achieves significant beneficial effects: (1) It solves the problem of unified standardization of multi-source heterogeneous model data, significantly improves the collaborative efficiency of heterogeneous models, and reduces integration costs: This invention, based on the SSP standard, adopts an XML + model file packaging format to structurally describe the core parameters and interaction rules of gray-box / black-box models (such as FMU and Simulink). It establishes a unified specification covering structured (such as requirement models), semi-structured (such as XML / JSON), and unstructured (such as Modelica / Simulink / FMU models). This completely eliminates data silos caused by the lack of standards, replaces the inefficient development model of existing point-to-point interfaces, significantly reduces the development and maintenance costs of multi-source heterogeneous model collaboration, and enables plug-and-play models.

[0022] (2) It solves the problem of unified representation of SysML models across tools, and achieves cross-tool consistency and lossless transfer: This invention defines the SysML metamodel structure and serialization format based on the MOF / XMI standard, unifying the storage and parsing logic of model elements (attributes, association rules, version information, etc.). Beneficial effects: It eliminates implementation differences in rendering, display, and data formats between different tools (such as IBM Rhapsody, Catia Magic, etc.), ensuring complete interoperability of model elements at the data level, achieving cross-tool portability, and completely solving the collaboration barriers and reuse problems caused by custom formats.

[0023] (3) The problem of bidirectional mapping and traceability between the function and physical domain interfaces was solved, and a bidirectional traceability link between function and physical was established: This invention pioneers a fusion framework of attribute-value mapping and production rules, deeply binding key attributes of functional requirements with technical parameters of physical implementation. It constructs a precise association between functional modules and physical components, and a mechanism for tracing the impact of requirement changes on physical design. Breaking down the tool barriers between the functional and physical domains, it achieves element-level traceability of cross-domain interface models, solving the problems of inefficient iteration and difficult verification caused by data fragmentation. This significantly improves the response speed for requirement satisfaction verification and design change handling, supporting the traceability requirements throughout the entire civil aircraft development process.

[0024] (4) Solve the problem of data transmission and traceability throughout the toolchain process, connect the data links throughout the process, and support the digital mainline driving: This invention, based on internationally recognized standards such as XMI and ReqIF, designs a complete data flow path and constructs a digital mainline supported by a centralized data warehouse, connecting model data at each stage of requirements, architecture, design, and simulation. It solves the data breakpoint problem caused by the lack of a unified transmission standard in existing systems. Through visual traceability, it constructs an end-to-end data link, achieving full-cycle traceability from the source of requirements to simulation verification. This promotes the continuity of the digital mainline and fundamentally solves the obstacles to implementation in traditional toolchains, such as frequent data transmission breakpoints and the inability to achieve end-to-end traceability. It provides a complete data closed loop for the efficient implementation of aviation MBSE technology throughout the entire process.

[0025] (5) Through multi-dimensional collaborative optimization of technology, economy, and engineering, the integrated modeling and simulation efficiency of multi-source heterogeneous models in the aerospace field is significantly improved: Technical aspects: A unified data specification and a two-way mapping mechanism between the function and physical domain ensure the consistency and accuracy of multi-source data and improve the coverage of interface traceability; based on standard model exchange formats and unified modeling languages ​​(such as XMI, OSLC (Open Services for Lifecycle Collaboration), ReqIF, etc.), it supports the integration of tools in the upstream and downstream of the toolchain and the interoperability of data, reduces the impact of changes on analysis response time, and significantly reduces data inconsistency errors compared with traditional document-driven methods.

[0026] From an economic perspective: By unifying data standards, the development of customized interfaces is reduced, and the cost of toolchain integration is significantly reduced; centralized data warehouses reduce redundant storage and lower hardware costs; multi-source heterogeneous model collaboration and virtual verification can identify design defects in advance, shortening the product development cycle and reducing the number of physical prototypes.

[0027] At the engineering level: It achieves the integration of requirements, functions, physics, and simulation models, meets the requirements of the ARP4754A standard for aviation development processes, and supports collaboration in more than 10 professional fields such as flight control and hydraulics; it adopts international standards such as SSP to build an open architecture, is compatible with mainstream tools such as Magic, Rhapsody, and Simulink, and effectively promotes the standardization and openness of models in the aviation field.

[0028] In summary, the multi-source heterogeneous data integration and traceability method and system provided by this invention for modeling and simulation analysis in the aviation field achieves standardized data processing, unified representation, element-level traceability, and global change synchronization. It significantly improves the efficiency and data consistency of modeling and simulation analysis in the aviation field, enhances the full lifecycle model integration and traceability capabilities, reduces toolchain integration costs, and eliminates data barriers between tools. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of the present invention, the concept, specific structure and technical effects of the present invention will be further explained below in conjunction with the accompanying drawings, so as to fully understand the purpose, features and effects of the present invention.

[0030] Figure 1 This is a business scenario diagram of the aviation MBSE toolchain; Figure 2 This is a flowchart illustrating an embodiment of a multi-source heterogeneous data integration and tracing method for modeling and simulation analysis in the aviation field provided by the present invention. Figure 3 yes Figure 2 A schematic diagram of the architecture of an embodiment of bidirectional traceable modeling of the physical domain interface in step S3; Figure 4This is a schematic diagram illustrating the unified flow path of requirements-model-security-ICD-simulation data for a multi-source heterogeneous data integration and traceability system for modeling and simulation analysis in the aviation field, provided by this invention. Detailed Implementation

[0031] In this document, to make the technical means, inventive features, achieved objectives and effects of the invention readily understandable, the invention is further described below with reference to specific illustrations. However, the invention is not limited to the embodiments described below.

[0032] Terms such as "comprising" and "including" indicate that, in addition to the components that are directly and explicitly stated in the specification and claims, the technical solution of the present invention does not exclude the presence of other components not directly or explicitly stated. Furthermore, in the description of this application, terms such as "first" and "second" are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0033] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0034] In traditional aerospace modeling and simulation analysis, the lack of standardized interfaces between tools and the difficulty in tracing model relationships due to inconsistent formats of multi-source heterogeneous data lead to data silos throughout the entire lifecycle, low collaborative efficiency, and poor model interchangeability. Specifically, multi-source heterogeneous data includes structured, semi-structured, and unstructured data, as well as gray-box / black-box models. Differences in data formats, modeling logic conflicts, and inconsistent data dimensions hinder data exchange between tools. The toolchain relies on point-to-point interface development and lacks a unified data transfer standard, resulting in frequent data transmission breakpoints in the process from requirements to simulation. The lack of unique identification mechanisms and mapping rules makes it difficult to trace model relationships at the element level, affecting the consistency verification between functional requirements and physical implementation. Key performance indicators such as data flow continuity, model reuse efficiency, and design change response speed are all subject to targeted constraints, manifesting as increased cross-stage collaboration barriers and greater difficulty in maintaining model consistency.

[0035] For example, in the scenario of full lifecycle management of aero-engines, the requirements definition phase uses the structured requirements tool Doors to generate XML format data, the functional modeling phase uses Catia Magic to create SysML models, and the physical simulation phase relies on the Modelica tool to process parametric models. When requirements change, it is necessary to manually parse the requirement entries in Doors, manually map them to the functional parameters in Catia Magic, and adjust the physical properties in Modelica. During this process, due to data format incompatibility and interface definition differences, the requirement IDs in Doors and the model elements in Catia Magic cannot be automatically associated, resulting in data transmission breakpoints. At the same time, differences in the custom rendering logic and metadata rules of different tools for the same model element cause format anomalies, requiring additional operations to fix display errors, increasing model migration costs and introducing data error risks. Furthermore, the lack of a mapping relationship between functional parameters and physical properties in this scenario makes it impossible to synchronize requirement changes to the physical implementation layer in real time, directly affecting design iteration efficiency and team collaboration quality.

[0036] If the above problems are not addressed, the data silo phenomenon will continue to worsen, the efficiency of toolchain collaboration will be further reduced, and the model interchangeability defects will lead to the failure of cross-team reuse. Logical conflicts between functional requirements and physical implementations may not be identified in a timely manner due to the lack of a traceability mechanism, leading to design consistency errors. At the same time, the fragility of the point-to-point interface mode will exacerbate the compatibility risks when upgrading or replacing tools, restrict the continuity of the digital thread, and ultimately affect the product development cycle and quality assurance capabilities.

[0037] To address this, this application proposes a multi-source heterogeneous data integration and tracing method for modeling and simulation analysis in the aviation field, such as... Figure 2 As shown, the specific steps may include the following: Step S1: Construct a multi-source heterogeneous data standardization system. Through a two-layer architecture combining international standard adaptation and custom encapsulation, data barriers between tools are eliminated, and all types of data, including structured, semi-structured, unstructured, and gray-box / black-box models, are standardized. When constructing the data standardization system, existing international standards are prioritized for processing some data. For parts not covered or not fully applicable by international standards, custom encapsulation is used to supplement them.

[0038] To address the issue of heterogeneous data formats from multiple sources in the aviation field, this step establishes a standardized processing system for all types of data based on international standards, enabling the unified flow of demand, model, and simulation data.

[0039] This application primarily employs the ReqIF standard to achieve structured exchange of requirement data; it utilizes the MOF (Meta-Object Facility) and XMI (XML Metadata Interchange) standards to achieve structured representation of SysML models; and it leverages the FMI standard to support cross-tool integration of simulation models (e.g., interoperability between Modelica and Simulink models). For unstructured data (such as design documents and simulation reports) and gray-box / black-box models (such as FMUs), this invention innovatively introduces the SSP (System Structure and Parameters) standard, defining model encapsulation specifications and designing an XML + model file packaging format. Taking the FMU (Functional Model Unit) as an example, a layered file structure of .ssd (system structure description), .ssm (simulation parameter configuration), and .ssv (simulation result data) is adopted. Resource relationships and version information are recorded through XML indexes, ensuring complete encapsulation and cross-tool parsing of multi-source data. This solution, through a two-layer architecture of international standard adaptation and custom encapsulation supplementation, eliminates data barriers between tools, meeting the core requirement of data continuity in the digital mainstream.

[0040] Step S2: Implement a unified representation of the SysML model based on a specialized meta-model for the aerospace field. The SysML model is a model built using the Systems Modeling Language (SML). Furthermore, SysML is a graphical modeling language used for specification, analysis, design, verification, and validation of complex systems, encompassing multiple views such as requirements, behavior, structure, and parameters.

[0041] Specifically, by defining a dedicated meta-model for the aerospace field and storing it serially, it ensures that different modeling tools can parse and exchange SysML model instances based on the same meta-model; at the same time, a tool adaptation layer is established to automatically convert the unique private formats of each modeling tool.

[0042] Step S3: Construct bidirectional traceable modeling of the functional-physical domain interface. In system design, the functional-physical domain interface refers to the interface connecting the functional domain (describing what the system "does") and the physical domain (describing how the system "implements"). This interface defines the interaction points and data flow between functional requirements and physical implementation.

[0043] The interface features are described graphically, the mapping relationship between the functional parameters of the functional requirements and the physical attributes of the physical implementation is established, and the element-level traceability of the functional interface and the physical interface is realized through a unique ID.

[0044] Step S4: Toolchain data transfer and traceability.

[0045] Centered on a centralized data warehouse, multimodal data and their relationships are stored in a unified manner, data flow paths are designed, and global change synchronization is performed during change tracing.

[0046] To bridge data gaps across tools, this step established a digital backbone architecture centered around a centralized data warehouse. This data warehouse employs a hybrid storage architecture: a relational database stores structured data (such as requirement entries and SysML model elements), while Elasticsearch stores unstructured data (such as simulation logs and test reports), ensuring unified management of multimodal data.

[0047] In optional embodiments, structured data includes at least one of the following: requirement entries, SysML model elements, and data in a relational database; semi-structured data includes at least one of the following: configuration files or exchange files in XML or JSON format; unstructured data includes at least one of the following: design documents, simulation reports, PDF review reports, simulation logs, and test reports; and gray-box / black-box models include at least one of the following: FMU, Simulink model, and Modelica model.

[0048] Structured data refers to data organized according to a predefined data model or schema, possessing a fixed structure and format, and facilitating storage, retrieval, and analysis. It can be represented as requirement entries stored in tabular form in a requirement management tool, containing descriptions of requirements, attributes, and relationships; it can also be SysML model elements such as modules, ports, interfaces, and activities defined in SysML modeling tools, where these elements, their attributes, and relationships all conform to the structured definitions of the SysML specification; or it can be data such as product configuration information, test results, and bills of materials stored in a relational database, organized through tables, rows, and columns.

[0049] Semi-structured data refers to data that does not fully conform to the strict structure of relational databases or other data models, but contains tags or other markers to separate semantic elements and enforce a hierarchical data structure within records. It can take the form of XML configuration files or exchange files, defining data structures through tags to describe system configurations, data exchange protocols, or model metadata; or it can take the form of JSON configuration files or exchange files, organizing data through key-value pairs and arrays for web service interface data exchange or lightweight configuration.

[0050] Unstructured data refers to data without a predefined structure or organization, and can be in the form of text, images, audio, video, etc. It can include design documents such as Word documents or Markdown files containing design specifications and technical specifications; simulation reports such as PDF simulation result analysis reports or HTML interactive reports; PDF review reports containing annotations and modification comments; simulation logs such as simulation process records and error messages in text file format; and test reports such as test cases, test results, and defect records in Excel spreadsheets or PDF documents.

[0051] A gray-box / black-box model refers to a model in which the internal logic or implementation details are visible (gray box) or completely invisible (black box) during modeling and simulation, and the model interacts only through its input / output interfaces. It can include Functional Model Units (FMUs) conforming to the FMI standard, which can be exchanged and co-simulated between different simulation tools as black-box models; it can also be a compiled Simulink model (such as S-function, RTW generated code) or a protected model, whose internal structure may be partially or completely hidden; it can also be a compiled Modelica model or an encrypted model, whose internal implementation details may not be fully disclosed.

[0052] The following is a concrete example. In an aero-engine R&D project, the requirements management department used requirements management tools to generate a large number of requirements items, which were identified and processed by the system as structured data. The system architect used SysML modeling tools to build the engine's system architecture model, and the SysML model elements contained therein were also considered structured data. Meanwhile, simulation engineers wrote multiple XML configuration files to configure the simulation environment; these files were parsed by the system as semi-structured data. During the design process, a large number of PDF design documents and simulation reports were generated; this unstructured data was indexed and correlated by the system. In addition, the supplier provides an FMU model for engine control algorithms and a Simulink model for performance analysis. These are integrated into the simulation platform as gray-box / black-box models. By clearly classifying these different types of data, the multi-source heterogeneous data standardization system can adopt different processing strategies. For example, structured data can be directly mapped to a unified meta-model for storage and exchange; semi-structured data has key information extracted by a parser and associated with structured data; unstructured data is linked to model elements through metadata indexing and content analysis; and gray-box / black-box models are integrated through their standard interfaces without needing to delve into their internal logic.

[0053] Through the aforementioned technical solution, this approach clarifies the specific types and carrier forms of multi-source heterogeneous data in aerospace modeling and simulation analysis, providing clear boundaries and implementation targets for constructing a standardized system for multi-source heterogeneous data. This effectively solves the problems of difficulty in implementing the standardized system and incomplete data coverage caused by the complexity and lack of clear definitions of data types. By finely classifying structured data, semi-structured data, unstructured data, and gray-box / black-box models, it ensures that data exchange between different tools can be effectively parsed and compatible, thereby truly eliminating data barriers between tools and improving the comprehensiveness and accuracy of data integration and traceability.

[0054] Furthermore, in an optional embodiment, in step S1, the ReqIF requirement exchange format standard is explicitly adopted for structured exchange of requirement data. The Meta-Object Facility (MOF) and the Metadata Exchange Standard (XMI) are used to achieve structured representation of the model; the Functional Model Interface (FMI) supports cross-tool integration of simulation models. For black-box models, the FMI standard is used, and the model is directly mounted to the co-simulation platform as a standardized component without parsing its internal logic. For gray-box models, the System Structure and Parameters (SSP) standard is used to define model encapsulation specifications, design the packaging format for XML and model files, and record the structural parameters, configuration information, and resource relationships of the gray-box model through an XML index. For unstructured data, its association with structured data and version information are recorded through an XML index, thus replacing the point-to-point interface development mode between tools.

[0055] Specifically, the ReqIF requirement exchange format standard is an open XML-based standard used to exchange requirement data between different requirement management tools. It defines a structured representation of requirement items, attributes, relationships, and other information, aiming to ensure semantic consistency and integrity of requirement data during transmission between different tools, avoiding information loss or misunderstanding. Implementation can be achieved by developing a ReqIF adapter to export requirement data from specific requirement management tools (such as IBM DOORS and PTC Integrity) into ReqIF files, or by importing ReqIF files into these tools; alternatively, a central ReqIF server can be built, with each requirement tool interacting with the server through an API interface to achieve real-time synchronization and exchange of requirement data.

[0056] The Meta-Object Facility (MOF) is a meta-modeling standard defined by the OMG for defining meta-models, while the Metadata Exchange Standard (XMI) is an XML-based standard defined by the OMG for serializing and exchanging MOF meta-models and their instances. Together, they provide a unified mechanism for defining meta-models and exchanging model instances across different modeling tools, eliminating interoperability barriers caused by proprietary formats. This can be achieved by defining aerospace-specific meta-models using MOF, then serializing these meta-models and their SysML model instances into XML files for storage and exchange via XMI; or by integrating MOF / XMI parsers and generators into modeling tools, enabling them to directly read and write model data conforming to MOF / XMI specifications, achieving seamless model migration between different tools.

[0057] The Functional Model Interface (FMI) is a tool-independent open standard for exchanging dynamic system models between different simulation tools. It defines the interface specification for Functional Model Units (FMUs), allowing models to be encapsulated as executable units for co-simulation. This supports the integration and collaboration of simulation models across different simulation platforms and tools, reducing the complexity of setting up simulation environments. For example, simulation models developed in tools such as Simulink and Modelica can be exported as FMUs and then loaded and run on other co-simulation platforms (such as Dymola and AMESim). Alternatively, FMI-compatible simulation solvers can be developed to directly parse and execute FMI-compliant FMUs, enabling co-simulation of multi-domain models.

[0058] For black-box models, the FMI standard is adopted, allowing simulation models with opaque internal logic (such as proprietary algorithm models provided by third parties) to be directly integrated into the co-simulation environment as standardized components without needing to understand their internal implementation details, thus simplifying the integration process. This can be achieved by converting the black-box model (e.g., a control algorithm library written in C++) into an FMU using an FMI wrapper tool, and then directly importing the FMU into the co-simulation platform for use; or by providing an FMI interface in the co-simulation platform, allowing users to directly specify the FMU file path, and the platform automatically loads and manages the input / output variables and simulation steps of the black-box FMU.

[0059] For gray-box models, the System Structure and Parameters Standard (SSP) is adopted to define model encapsulation specifications. An XML and model file packaging format is designed, and an XML index records the structural parameters, configuration information, and resource relationships of the gray-box model. SSP is a supporting standard for FMI, used to describe and exchange the system structure and parameterized information of multiple FMUs. It provides a standardized encapsulation and configuration management mechanism for gray-box models, giving them better configurability and traceability in co-simulation environments. For example, the structural information, configurable parameters, and related resources (such as lookup tables and external data files) of a gray-box model (e.g., a Modelica model composed of multiple subsystems) can be defined as XML files using the SSP standard and packaged together with the model files. The XML index records the names, types, default values, and mapping relationships of these parameters to internal model elements. Alternatively, an SSP-compatible model packaging tool can be developed to automatically parse the internal structure of the gray-box model, generate an XML description file conforming to the SSP specification, and package it together with the model binary file or source code file, facilitating exchange and configuration between different tools.

[0060] For unstructured data, XML indexes are used to record its association with structured data and version information. This aims to establish a clear link between previously isolated unstructured documents (such as design reports and test logs) and structured model data, and manage their versions, thereby achieving unified traceability across all data types. This can be achieved by creating a corresponding XML index file for each unstructured data file (such as a PDF design document), containing the document's unique identifier, version number, storage path, and a reference link to related structured data (such as a requirement element or component in a SysML model); or by maintaining a metadata management module in the data warehouse, which automatically generates or manually edits the XML index when unstructured data is uploaded, and associates it with structured data (such as requirement items and SysML model elements) using a shared unique ID, while also recording its version history. These techniques work together, introducing a unified, standardized data exchange and encapsulation mechanism, avoiding the tedious work of developing customized interfaces for each pair of tools, significantly reducing integration costs and maintenance complexity.

[0061] Through the above technical solution, this application effectively addresses the problem of the lack of unified standardized exchange and encapsulation specifications for multi-source heterogeneous data in aerospace modeling and simulation analysis. Specifically, by introducing corresponding international standards (ReqIF, MOF / XMI, FMI, SSP) and a custom XML indexing mechanism for different types of data (requirements, models, simulation models, unstructured data), this solution constructs a comprehensive and refined data specification system. This enables the structured and semantically consistent exchange and integration of heterogeneous data that was originally scattered across different tools, fundamentally eliminating data barriers between tools. Compared to the traditional development model that relies on point-to-point interfaces, this solution significantly reduces the complexity and cost of system integration and improves the efficiency and accuracy of data flow.

[0062] In an optional embodiment, in step S2, an aviation-specific metamodel is defined based on the Meta-Object Facility (MOF), specifying the attributes and association rules of elements including at least requirements, components, and interfaces, fully aligning with the core elements of the SysML specification; the aviation-specific metamodel is serialized and stored using the Metadata Exchange Standard (XMI) to ensure that different modeling tools can parse and exchange SysML model instances based on the aviation-specific metamodel at the syntax level; a tool adaptation layer is established, and an incremental import / export mechanism is designed for the unique extensions of each modeling tool, automatically converting the tool's private format through predefined mapping rules.

[0063] Meta-Object Facility (MOF) is an international standard for defining, storing, and managing meta-models. It provides a general, extensible framework for defining and managing various models. Possible implementations include: using the Eclipse Modeling Framework (EMF) to implement the MOF specification and defining the meta-model through Ecore models; or utilizing the OMG's MOF standard toolset to define the meta-model through XML Schema or UML Profiles. Aerospace-specific meta-models are customized for the specific modeling needs of the aerospace domain. Their role is to provide a unified, semantically rich abstraction layer for modeling complex systems in the aerospace domain. Possible implementations include: collaborating with domain experts and modeling experts to identify core aerospace concepts and formally defining them using MOF tools; or adding aerospace-specific elements and constraints to the existing SysML meta-model through extension mechanisms. Clearly defining the attributes and association rules of elements, including at least requirements, components, and interfaces, in the aerospace-specific meta-model means providing a detailed definition of core modeling elements, including their internal attributes and the relationships between these elements, to ensure semantic clarity and consistency of model elements and support effective traceability and analysis between models. Possible implementation methods include: adding specific attribute fields for each element type and defining reference relationships between elements in the metamodel definition; or defining the validity conditions of these attributes and association rules through a constraint language. Full alignment with the core elements of the SysML specification means that the defined aerospace-specific metamodel maintains a high degree of consistency with the core concepts of SysML in structure and semantics, ensuring compatibility with widely adopted SysML tools and methods, reducing learning costs, and promoting cross-domain collaboration. Possible implementation methods include: directly inheriting or mapping core SysML concepts such as Block, Port, Requirement, and ConstraintBlock when designing the aerospace-specific metamodel; or adding aerospace-specific semantic extensions to the standard SysML model through the SysML Profile mechanism while maintaining compatibility with the basic SysML specification.

[0064] The Metadata Exchange Standard (XMI) is an XML-based standard defined by the OMG for exchanging metadata and models between different tools. Its purpose is to provide a universal, parsable text format for cross-tool exchange of model data. Possible implementations include: using the XMI serializer provided by EMF to save Ecore model instances as XMI files; or using a custom XMI parser and generator to convert in-memory model objects into XML documents conforming to the XMI specification, or to parse XMI documents into model objects. Serializing and storing the aerospace-specific metamodel refers to converting the definition of the aerospace-specific metamodel itself and the model instances created based on it into XMI format for persistent storage, enabling the metamodel and model instances to be transferred and shared between different systems or tools. Possible implementations include: saving both the metamodel definition and model instances in XMI format to a file system or database; or transmitting XMI format model data between different services via network protocols. Ensuring that different modeling tools can parse and exchange SysML model instances at the grammatical level based on the aerospace-specific metamodel means that all participating modeling tools can understand and process the aerospace-specific metamodel in XMI format, and correctly parse and generate SysML model instances based on this metamodel. This provides a foundation for cross-tool model interoperability and eliminates parsing errors caused by data format incompatibility. Possible implementation methods include: each modeling tool having a built-in XMI parser and loading the aerospace-specific metamodel as parsing rules; or providing an XMI-based model import / export API through a unified model service layer for each tool to call.

[0065] The tool adaptation layer is a software module located between modeling tools and the core data warehouse or unified model representation layer. Its role is to act as a translator between different tools and the unified metamodel, handling the unique data formats and semantic differences of each tool. Possible implementation methods include: developing independent microservice modules, each responsible for adapting to a specific modeling tool; or integrating a configurable adapter framework into the unified data platform, allowing dynamic loading of adapter plugins for different tools. Incremental import / export mechanisms are designed for the unique extensions of each modeling tool. This means that during model data exchange, only the changed parts are processed, rather than transmitting the entire model each time, to improve data exchange efficiency and ensure that only necessary changes are synchronized during model evolution, reducing data redundancy and conflicts. Possible implementation methods include: generating an incremental change set by comparing model version differences and transmitting only this change set; or maintaining a change log in the tool adaptation layer to record each model modification and synchronizing based on the log during import / export. Automatic conversion of proprietary tool formats using predefined mapping rules refers to a set of pre-defined conversion rules used to map the proprietary data formats or semantics of a specific modeling tool to the standard formats and semantics defined by the aerospace-specific meta-model, and vice versa. This achieves automated data conversion between different tools, reduces manual intervention, and improves data consistency. Possible implementation methods include: defining mapping rules using XML Schema Transformation (XSLT) or other data transformation languages; or defining the correspondence between proprietary and standard attributes, as well as the conversion logic between proprietary and standard elements, in a configuration-based manner within the tool adaptation layer.

[0066] In this embodiment, to address the issue of differing parsing of SysML models by different tools, this step constructs a triple consistency guarantee system based on metamodel standardization, encompassing syntax, semantics, and explicitness: The syntax and semantic layers uniformly adopt MOF 2.5 and above (Meta-Object Facility) to define a SysML metamodel specifically for the aviation field. This clearly defines the attributes (such as weight and center of gravity constraints) and association rules (such as «satisfy», «verify», and other traceability relationships) of model elements such as requirements, components, and interfaces, fully aligning with the core elements of the SysML specification. At the same time, the serialization and storage of this metamodel are achieved through the XMI 2.5.1 (XML Metadata Exchange) standard, ensuring the parsing consistency of mainstream SysML tools such as IBM Rhapsody and CatiaMagic at the model syntax level.

[0067] To ensure consistency in the display layer and address rendering differences caused by display extensions specific to different tools (such as custom stereotypes and view configuration parameters), this invention develops a tool adaptation layer with an incremental import / export mechanism. Through predefined mapping rules, it automatically converts the private formats of each tool (such as the view layout parameters of Rhapsody), thereby eliminating model display distortion caused by differences in rendering engines.

[0068] The aforementioned solution, based on the three-layer metamodel architecture theory (meta-meta-layer - metamodel layer - instance model layer), addresses the long-standing challenge of heterogeneous display layers in cross-tool collaboration of aerospace SysML models (different tools have private extensions to the rendering layout, view configuration, and custom stereotypes of the same model element). It pioneers a triple consistency guarantee system integrating a standardized metamodel (unified syntax / semantic layer) and a tool adaptation layer (incremental transformation of the display layer). Specifically, the tool adaptation layer, through predefined mapping rules and incremental import / export mechanisms, achieves for the first time automatic conversion of private display parameters of mainstream tools such as Rhapsody and Magic, eliminating model distortion caused by differences in rendering engines. This solution overcomes the industrial bottleneck of existing technologies that rely solely on basic standards (such as XMI) to solve display layer interoperability issues, providing an unprecedented technical benchmark for the field. From a scientific perspective, this solution strictly adheres to the theoretical foundation of layered abstraction of the metamodel, ensuring the mathematical rigor of model semantics; more importantly, it translates theory into a practically usable industrial-grade solution through systematic engineering innovation, producing unexpected technical effects.

[0069] Therefore, this application effectively solves the problems of reduced model interchangeability and reusability caused by proprietary extensions of different modeling tools, as well as the difficulty in achieving consistent parsing of model instances at the syntactic level. The definition of an aviation-specific metamodel provides a unified semantic foundation and core specification alignment for aviation system modeling, eliminating discrepancies in conceptual understanding between different tools. XMI serialization storage ensures the structural integrity and syntactic consistency of model instances during cross-tool transmission, enabling each tool to parse based on common rules. The introduction of a tool adaptation layer further bridges the gap between proprietary extensions of various tools and the standard metamodel, achieving smooth and efficient conversion from proprietary to standard formats through automated mapping and incremental mechanisms. This significantly improves the efficiency of seamless transfer, interchange, and reuse of complex aviation models across different design stages, teams, and tools, providing solid technical support for building a continuous digital framework.

[0070] In an optional embodiment, in step S3, the interface features are jointly described using a SysML Module Definition Graph (BDD) and an Interface Block Graph (IBD). The BDD defines the interface type and performance parameters, while the IBD clarifies the signal flow and connection relationships. A mapping relationship between functional parameters of functional requirements and physical attributes of physical implementation is established through two types of rules: direct binding of attribute-value pairs and dynamic derivation using production rules. Relying on an element-level traceability mechanism, the functional parameters and physical attributes are associated with unique IDs to obtain a unified expression framework for the functional-physical domain interface, supporting the structured expression of the functional-physical domain interface and its traceability relationships.

[0071] SysML Module Definition Diagram (BDD) is a SysML diagram used to define system structure, interfaces, attributes, and operations, focusing on the static structure and components of the system. Interface Diagram (IBD), on the other hand, describes the internal connections, ports, and data or signal flow of a module, focusing on the dynamic interactions and interface implementation within the module. Using these two types of diagrams together to describe interface characteristics allows for a comprehensive and accurate portrayal of system interfaces from both static definition and dynamic interaction dimensions, ensuring the completeness and consistency of the interface description. For example, BDD can be used to define the type, data structure, and performance constraints of an interface, while IBD can be used to show the specific connection points and data exchange paths of these interfaces within or between systems.

[0072] Establishing a mapping relationship between functional parameters and physical properties is key to linking functional and physical domains. This requires a flexible and robust rule system to handle mapping scenarios of varying complexity. These rules can be predefined or dynamically generated based on system characteristics. For example, a rule engine-based mapping mechanism can be used to automatically map based on preset conditions and actions; or machine learning algorithms can be used to automatically learn and establish mapping relationships through training data.

[0073] A unique ID is an identifier used to uniquely identify each system element throughout its entire lifecycle. It can be a globally unique string, a sequence of numbers, or a GUID (Globally Unique Identifier). By assigning unique IDs to functional parameters and physical attributes, it ensures that elements from different sources and of different types can be accurately identified and associated in complex, heterogeneous data environments, thereby achieving precise element-level traceability. For example, a UUID can be used as a unique ID to guarantee its global uniqueness.

[0074] In such Figure 3In the illustrated embodiment, to address the mapping gap between functional requirements and physical implementation, this step constructs a bidirectional traceable interface modeling method based on model description, rule binding, and element tracing, echoing the forward design and reverse verification logic of the System Engineering V-model. The interface characteristics are jointly described using SysML Module Definition Diagram (BDD) and Interface Block Diagram (IBD): BDD defines the interface type (e.g., electrical / hydraulic) and performance parameters (e.g., pressure, flow rate), while IBD clarifies the signal flow direction and connection relationships.

[0075] Furthermore, mapping is established through two types of rules: first, direct binding of attribute-value pairs (e.g., "functional requirement = hydraulic power supply → physical interface = 30MPa hydraulic connector"); second, dynamic derivation through production rules (e.g., "IF functional flow contains high-frequency electrical signals THEN physical interface material = shielding alloy; IF operating temperature > 150℃ THEN sealing rating = IP68"). Relying on an element-level traceability mechanism, functional parameters and physical attributes are associated through unique IDs, resulting in a unified expression framework for the functional-physical domain interface. This supports the structured expression of functional interfaces, physical interfaces, and their traceability relationships, achieving end-to-end traceability from functional requirements to physical components.

[0076] Through the above technical solutions, this application effectively solves the problems of inconsistent interface feature descriptions between functional domains and physical domains, difficulty in establishing accurate mappings, and difficulties in cross-domain traceability. By employing SysML Module Definition Graph (BDD) and Interface Block Graph (IBD) to jointly describe interface features, both the static definition and dynamic interaction logic of the interface are clearly and systematically expressed, laying a solid foundation for semantic alignment between functional and physical domains. Through a mapping rule combining direct attribute-value pair binding and dynamic derivation of production rules, flexible and accurate mapping from functional parameters to physical attributes is achieved, capable of handling various association scenarios from simple to complex. Relying on an element-level traceability mechanism, functional parameters and physical attributes are associated through unique IDs, constructing a unified expression framework for the functional-physical domain interface, establishing a fine-grained and structured traceability relationship between functional requirements and physical implementations. This not only ensures the continuity and consistency of information flow between functional and physical domains in complex system design, but also, combined with a centralized data warehouse, greatly enhances the ability to trace changes, enabling precise location and impact analysis of any changes at the functional or physical level, thereby significantly improving the efficiency and reliability of modeling and simulation analysis in the aerospace field.

[0077] In an optional embodiment, in step S4, a centralized data warehouse is constructed, employing a hybrid storage architecture to uniformly store structured and unstructured multimodal data, and storing the traceability relationship associated with the unique ID in step S3; a standardized service interface is established to realize data interaction between the requirement management tool, architecture modeling and simulation tool, co-simulation tool, security analysis tool, and ICD management tool and the centralized data warehouse; a data flow path is designed to establish a closed loop from importing requirement data into the centralized data warehouse, the architecture tool generating a model based on the requirement, the simulation tool calling the Functional Model Interface (FMI) to perform model calculations, and the results flowing back to the centralized data warehouse.

[0078] Optionally, a centralized data warehouse is the core storage entity used for unified storage and management of various types of data generated during modeling and simulation analysis in the aerospace field. It can be built on a traditional relational database management system (e.g., Oracle, PostgreSQL) to handle structured data; or on a distributed file system (e.g., HDFS) or object storage service (e.g., MinIO, Amazon S3) to store unstructured data; or it can adopt a data lake architecture to store all data in its native format and process and analyze it as needed. A hybrid storage architecture combines the advantages of different storage technologies to adapt to the storage needs of different types of data. For structured data, such as requirement entries, SysML model elements, and data in relational databases, relational databases can be used for efficient storage and querying. For semi-structured data, such as XML and JSON format configuration files or exchange files, document databases (e.g., MongoDB) or key-value stores (e.g., Redis) can be used for storage. For unstructured data, such as design documents, simulation reports, PDF review reports, simulation logs, and test reports, object storage or distributed file systems can be used for storage. For gray-box / black-box models, such as FMU, Simulink, and Modelica models, their binary files or files in specific formats can be stored in object storage, supplemented by metadata management. This hybrid storage architecture can fully leverage the characteristics of various storage technologies to achieve optimized storage and management of multimodal data.

[0079] In such Figure 4 The illustrated embodiment features a standardized data flow and traceability mechanism centered around a centralized data warehouse: Interface Specification: Develop RESTful service interfaces to achieve seamless integration between requirement management tools, architecture tools, simulation tools, and centralized data warehouses.

[0080] Flow path: Requirement data is imported into a centralized data warehouse via the ReqIF standard → Architecture tools generate SysML models based on requirements → Simulation tools call simulation models (such as FMU) under the FMI (Functional Model Interface) standard for calculation → Results flow back to the centralized data warehouse, forming a data closed loop.

[0081] Change tracking: Develop an impact analysis engine to automatically locate the affected scope through a network relationship diagram (e.g., requirement changes trigger related architectural elements, which in turn affect simulation test cases and test data in a chain reaction).

[0082] This engine can operate based on predefined rule sets, topology analysis, or machine learning algorithms. For example, an engine based on graph traversal algorithms can be used to explore change propagation paths through depth-first search or breadth-first search; alternatively, a rule-based reasoning engine can be used, pre-setting a series of logical rules such as "if A changes, then B may be affected." A network relationship graph is a data model that represents complex relationships between data in a graphical structure, where nodes represent data entities and edges represent the tracing relationships between these entities. In step S3, functional parameters and physical attributes are associated through unique IDs, and these relationships form the basis for constructing the graph. The construction process can import these unique IDs and their relationships into a graph database, which can efficiently store and query complex network relationships; alternatively, a graph structure can be simulated in a relational database through multi-table joins and recursive queries, and the graph can be represented and manipulated using in-memory data structures.

[0083] Specifically, regarding the heterogeneous format problem of multi-source data in the aviation field, such as Figure 4 As shown, this solution constructs a standardized data processing system for all types based on international standards, realizing the unified flow of requirements, models, security, ICD, and simulation data. It clearly defines data formats, transmission actions, and technical implementation details through itemized entries, ensuring deep integration with the technical solution. The requirements management tool transmits data to the architecture modeling and simulation tool: The requirements management tool exports functional requirement packages according to the ReqIF requirements exchange format and uploads them to a centralized data warehouse. The XML structured requirement files are stored in a relational database, and the unstructured attachments are stored in Elasticsearch. The architecture modeling and simulation tool pulls data from the centralized data warehouse by calling a RESTful interface through a standardized service interface. Based on the MOF meta-object facility meta-model, it automatically parses the XML files to generate SysML requirement nodes. At the same time, it adapts and processes the modeling tool's exclusive view configuration through a tool adaptation layer.

[0084] Architecture modeling and simulation tools transmit optimization suggestions to requirements management tools: The architecture modeling and simulation tools generate XML format functional design optimization reports and incremental fragments of XMI metadata exchange standards and upload them to the centralized data warehouse; The centralized data warehouse automatically verifies the compatibility of XMI incremental fragments with aviation-specific meta-models, locates the requirement nodes associated with the report through the impact analysis engine, and pushes optimization suggestions to the requirements management tools; After the requirements are revised, the centralized data warehouse synchronously updates the data versions of all associated functional models.

[0085] The collaborative simulation tool transmits simulation verification results to the requirements management tool: After the collaborative simulation tool finishes running, it generates an XML-formatted simulation verification report and a .ssv simulation result file conforming to the SSP system structure and parameter standards, and uploads them to a centralized data warehouse. The structured data of the report is stored in a relational database, and the .ssv simulation result file is stored in Elasticsearch. The centralized data warehouse automatically associates simulation test cases, functional modules, and requirement chains through an impact analysis engine, and pushes a verification failure notification to the requirements management tool along with a download link for the .ssv file. After the requirements are revised, the centralized data warehouse synchronizes the data to the collaborative simulation tool and automatically updates the simulation test case parameters.

[0086] The security analysis tool transmits security verification results to the requirements management tool: After completing the risk analysis, the security analysis tool generates an XML-formatted security requirements verification report and a Medini-specific XML risk analysis result file, and uploads them to the centralized data warehouse; the centralized data warehouse establishes a link between risk results, security requirements, and original requirements based on the function-physical domain interface element-level traceability relationship, and pushes security verification failure notifications and risk root causes to the requirements management tool; after the requirements are revised, the centralized data warehouse synchronizes the data to the security analysis tool, updates the risk analysis model input parameters, and recalculates the risk level.

[0087] The Interface Definition (ICD) management tool transmits interface compliance reports to the requirements management tool: After completing the interface development, the ICD management tool generates an XML-formatted interface compliance report and an Excel list of interface parameter deviations, and uploads them to the centralized data warehouse. The centralized data warehouse uses a network relationship graph to associate ICD interfaces, physical interfaces, functional interfaces, and corresponding requirement chains, and pushes the interface compliance report to the requirements management tool. After the requirements are revised, the centralized data warehouse synchronizes the data to the ICD management tool and the physical modeling tool to complete the parameter compliance verification.

[0088] The architecture modeling and simulation tool transmits the functional interface list to the interface definition ICD management tool: Based on the MOF meta-object facility meta-model, the architecture modeling and simulation tool exports the functional interface list in Excel format and the SysML model file in XMI format and uploads it to the centralized data warehouse; the interface definition ICD management tool pulls data from the warehouse, automatically verifies the syntax consistency of the XMI file, supplements the production rules to the ICD document, and realizes interface traceability from functional domain to physical domain through unique ID.

[0089] Architecture modeling and simulation tools pass functional dependencies and interface parameters to security analysis tools: The architecture modeling and simulation tools export XMI model files containing functional dependencies and high-risk interface parameters and upload them to a centralized data warehouse; the security analysis tools import data from the warehouse, parse functional dependencies based on aviation-specific meta-models, automatically generate fault trees, and directly use interface vulnerability parameters for failure mode and effects analysis (FMEA) occurrence calculations.

[0090] The architecture modeling and simulation tool transfers the FMU model to the co-simulation tool: The architecture modeling and simulation tool exports the FMU model conforming to the FMI functional model interface standard and the SSP system structure and parameter standard package file and uploads it to the centralized data warehouse. The SSP package file contains a system structure description file, a simulation parameter configuration file, and an XML index file. The co-simulation tool imports data from the warehouse, directly integrates the FMU model through the FMI interface, and calls the simulation parameter configuration corresponding to the SSP standard.

[0091] The co-simulation tool transfers optimized diagnostic data to the architecture modeling and simulation tool: After the co-simulation tool runs, it generates an XML format functional logic optimization report, SSP standard .ssv simulation raw data, and FMI diagnostic fragments, and uploads them to the centralized data warehouse. The centralized data warehouse automatically associates simulation use cases with functional module links through the impact analysis engine. After importing the data, the architecture modeling and simulation tool locates problem nodes through the FMI diagnostic fragments, optimizes SysML activity diagram logic or adjusts simulation parameters based on the MOF meta-object facility meta-model, updates the XMI model and synchronizes it to the centralized data warehouse. The warehouse then triggers the co-simulation tool to re-import the optimized FMI model to complete the simulation verification.

[0092] Through the above technical solutions, this application effectively solves the problems of data dispersion, low toolchain collaboration efficiency, and difficulty in ensuring data consistency in traditional aerospace modeling and simulation analysis. The construction of a centralized data warehouse enables unified storage and management of multi-source heterogeneous data, eliminating data silos and providing a reliable physical carrier for data throughout its entire lifecycle. The establishment of standardized service interfaces greatly simplifies the integration complexity between different tools, reduces system development and maintenance costs, and improves toolchain interoperability. More importantly, a clear data flow path and closed-loop mechanism ensure the continuity and consistency of data from requirements to simulation verification, enabling seamless data transfer and traceability between various stages, thus constructing a continuous digital thread. Furthermore, by developing an impact analysis engine and constructing a network relationship graph based on traceability relationships associated with unique IDs, this solution can achieve automated and precise positioning of the scope of change impact. This significantly reduces the complexity and error rate of manually investigating change impacts, avoiding rework and design defects caused by untimely or inaccurate change information transmission.

[0093] To achieve the above objectives, this application also provides a multi-source heterogeneous data integration and traceability system for modeling and simulation analysis in the aviation field. This system implements the above-mentioned multi-source heterogeneous data integration method and systematically solves the core problem of multi-source heterogeneous data fusion and traceability by constructing an integrated data management and traceability architecture.

[0094] Specifically, the multi-source heterogeneous data standardization system construction module effectively eliminates data barriers between tools through a two-layer architecture that combines international standard adaptation with custom encapsulation. This module standardizes all types of data, including structured data, semi-structured data, unstructured data, and gray-box / black-box models. For example, during the requirements definition phase, it converts the structured requirements data output by the Doors tool and the physical model attributes generated by the CAD tool into a standardized intermediate format, ensuring semantic consistency between data from different sources and laying the foundation for subsequent integration.

[0095] The SysML model unified representation module defines an aerospace-specific metamodel and serializes and stores it, ensuring that different modeling tools can parse and exchange SysML model instances based on the same metamodel. This module also includes a tool adaptation layer for automatically converting the proprietary formats of various modeling tools. For example, in functional modeling, when a SysML model instance generated by the Catia Magic tool needs to be shared with the IBM Rhapsody tool, the tool adaptation layer automatically maps proprietary extended attributes to standard fields defined in the aerospace-specific metamodel. This avoids model parsing errors caused by differences in custom formats and significantly improves model interchangeability and reuse efficiency among similar tools.

[0096] Furthermore, the functional-physical domain interface bidirectional traceability modeling module uses a graphical approach to describe interface characteristics, establishes a mapping relationship between functional parameters of functional requirements and physical properties of physical implementations, and achieves element-level traceability between functional and physical interfaces through unique IDs. In practical implementation, this module allows designers to draw the connection relationship between functional and physical interfaces through a visual interface. For example, it establishes a mathematical mapping model between the "response time" functional parameter of the flight control surface actuator system and physical properties such as "motor torque" and "gear ratio," and assigns a unique ID to each interface element. When functional requirements change, the system can automatically locate the affected physical implementation components based on the unique IDs, achieving accurate traceability from the functional domain to the physical domain.

[0097] The toolchain data transfer and traceability module is centered around a centralized data warehouse, which uniformly stores multimodal data and their relationships, designs data flow paths, and performs global change synchronization during change traceability. This module employs a hybrid storage architecture to manage heterogeneous data from the requirements definition, functional modeling, physical design, and simulation verification stages. For example, requirements data, SysML model instances, CAD model attributes, and simulation results are stored in the centralized data warehouse in the form of a relational graph. When data changes at any stage, the system automatically triggers a global synchronization mechanism based on the preset data flow path, ensuring that all related data is updated in real time, thereby maintaining the consistency and continuity of data throughout its entire lifecycle.

[0098] The following example will provide a more detailed explanation of the above technical solution: Suppose that during the development of a subsystem of an aircraft (e.g., a flight control surface actuator system), multiple teams and tools collaborate. The requirements team uses general documentation tools to record requirements, the system architecture team uses SysML modeling tools for functional and logical design, the physical design team uses CAD tools for 3D modeling, and the simulation team uses simulation tools for performance verification. In the traditional approach, the data formats of these tools differ, leading to extensive manual conversion and coordination required when transferring data between different teams and tools. This easily results in data inconsistencies and difficulties in traceability.

[0099] To address this, this application first constructs a multi-source heterogeneous data standardization system. Specifically, for requirement documents output by the general documentation tools of the requirements team, a standardized document structure and tagging system can be designed, and a parser can be developed to extract and convert the requirement items into structured data. For model files generated by the SysML modeling tools of the system architecture team, a set of general model element representation standards can be defined, and a corresponding conversion module can be developed to convert its internal proprietary formats into a unified model data format. For CAD models from the physical design team, key physical properties (such as dimensions, weight, and materials) can be extracted and converted into structured data. For simulation results and logs generated by simulation tools, a standardized output format can also be defined and uniformly processed. Thus, through a two-layer architecture supplemented by international standard adaptation and custom encapsulation, all these data from different sources and of different types are standardized, eliminating data barriers between tools.

[0100] Next, a unified representation of the SysML model is implemented based on an aviation-specific metamodel. In the actuator system example above, an aviation-specific metamodel can be defined specifically for flight control systems. This metamodel clarifies the attributes (e.g., maximum thrust, response time, weight, etc.), interface types (e.g., electrical, mechanical, data interfaces, etc.), and association rules between core components such as actuators, controllers, and sensors. This dedicated metamodel is serialized and stored, ensuring that the SysML modeling tools used by the system architecture team, as well as other potentially used SysML-compatible tools, follow the same set of semantic and syntactic rules when parsing and exchanging actuator SysML model instances. Simultaneously, a tool adaptation layer is established to automatically convert the unique proprietary formats of each modeling tool. For example, if a SysML modeling tool has custom extensions for certain attributes, the tool adaptation layer can automatically convert them to the standard format defined by the metamodel, thereby ensuring interoperability between different tools.

[0101] Subsequently, a bidirectional traceability model of the function-physical domain interface is constructed. In the actuator system, the actuator's functional requirement might include "moving the control surface by Y degrees within X milliseconds," with functional parameters including "response time X" and "angle Y." The physical implementation of the actuator involves components such as motors, gearboxes, and linkages, with physical attributes including "motor torque," "gear ratio," and "link length." Interface characteristics are described graphically; for example, block diagrams are used to clearly represent the electrical interface between the actuator and the controller, and the mechanical interface between the actuator and the control surface. Then, a mapping relationship between functional parameters and physical attributes is established; for example, "response time X" is mapped to a combination of "motor torque" and "gear ratio," and "angle Y" is mapped to "link length" and "stroke range." By assigning a unique ID to each functional and physical interface, element-level traceability between functional and physical interfaces is achieved. Thus, when functional requirements change, the affected physical implementation can be quickly located; conversely, when the attributes of physical components change, the affected functional requirements can also be traced.

[0102] Finally, toolchain data transfer and traceability are implemented. A centralized data warehouse serves as the core, unifying the standardized data from step S1 (requirements, SysML models, CAD model attributes, simulation results, etc.) and the mapping and traceability relationships of the function-physical domain interface established in step S3. This data warehouse employs a hybrid storage architecture, enabling efficient storage of structured and unstructured multimodal data. Data flow paths are designed; for example, requirement data is imported into the data warehouse, the system architecture tool generates a SysML model based on the requirements and stores it in the data warehouse, and the simulation tool retrieves the model from the data warehouse for computation and feeds back the results. When a requirement of the actuator system changes, for example, the response time requirement changes from X milliseconds to X' milliseconds, because all data and its relationships are stored in the centralized data warehouse and a network traceability relationship is established through unique IDs, the system can automatically identify the SysML model, physical design parameters, and simulation model affected by this requirement change. Therefore, during change traceability, global change synchronization can be performed, ensuring that all relevant data and models are updated in a timely manner, thereby maintaining the consistency of data throughout the entire system.

[0103] Through the above technical solution, this application achieves standardized fusion and closed-loop management of multi-source heterogeneous data in the aviation field. In specific implementation scenarios of aircraft subsystem development, such as the design process of flight control surface actuator systems, this system can integrate heterogeneous data generated by the requirements team, system architecture team, physical design team, and simulation team. When the "response time" parameter in the requirements document is adjusted from X milliseconds to X' milliseconds, the system automatically identifies the affected physical components based on the mapping relationship of the function-physical domain interface, and updates the relevant SysML models, CAD parameters, and simulation configurations in real time through the global change synchronization mechanism of the centralized data warehouse, avoiding data breakpoints and manual coordination costs in the traditional point-to-point interface mode.

[0104] Other specific implementation methods have been described in detail above and will not be repeated here.

[0105] To achieve the above objectives, the present invention also provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor runs the program, it can implement the steps of the multi-source heterogeneous data integration and tracing method for modeling and simulation analysis in the aviation field as described in any of the foregoing embodiments.

[0106] Processors and memory can be configured separately or integrated together, for example, integrated on a system-on-chip (SOC) in a terminal device.

[0107] To achieve the above objectives, the present invention also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when processed and executed, implement the multi-source heterogeneous data integration and tracing method for modeling and simulation analysis in the aviation field as described above.

[0108] The computer-readable storage medium is, for example, memory. Memory can be volatile or non-volatile, or it can include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0109] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0110] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A method for integrating and tracing multi-source heterogeneous data for modeling and simulation analysis in the aviation field, characterized in that, Includes the following steps: Step S1: Construct a multi-source heterogeneous data standardization system; through a two-layer architecture of international standard adaptation and custom encapsulation supplement, eliminate data barriers between tools and standardize all types of data, including structured data, semi-structured data, unstructured data, and gray-box / black-box models. Step S2: Implement a unified representation of SysML models based on aerospace-specific meta-models; Specifically, by defining a dedicated meta-model for the aerospace field and storing it serially, it ensures that different modeling tools can parse and exchange SysML model instances based on the same meta-model; at the same time, a tool adaptation layer is established to automatically convert the unique private formats of each modeling tool. Step S3: Construct bidirectional traceable modeling for the functional-physical domain interface; The interface features are described graphically, the mapping relationship between the functional parameters of the functional requirements and the physical attributes of the physical implementation is established, and the element-level traceability of the functional interface and the physical interface is realized through a unique ID. Step S4: Toolchain data transfer and traceability; with a centralized data warehouse as the core, multimodal data and their relationships are stored in a unified manner, data flow paths are designed, and global change synchronization is performed during change traceability.

2. The multi-source heterogeneous data integration and traceability method according to claim 1, characterized in that, The structured data includes at least one of the following: requirement entries, SysML model elements, and data in a relational database; the semi-structured data includes at least one of the following: XML or JSON format configuration files or exchange files; the unstructured data includes at least one of the following: design documents, simulation reports, PDF review reports, simulation logs, and test reports; the gray-box / black-box model includes at least one of the following: FMU, Simulink model, and Modelica model.

3. The multi-source heterogeneous data integration and traceability method according to claim 1, characterized in that, In step S1, the ReqIF requirement exchange format standard is used for structured exchange of requirement data. The model is structured and represented using the Meta-Object Facility (MOF) and the Metadata Exchange Standard (XMI); the simulation model is integrated across tools using the Functional Model Interface (FMI). For black-box models, the Functional Model Interface (FMI) standard is adopted, and the model is directly mounted as a standardized component to the co-simulation platform without the need to parse its internal logic. For gray-box models, the System Structure and Parameters Standard (SSP) is adopted to define the model encapsulation specification, and the packaging format of XML and model files is designed. The structural parameters, configuration information and resource associations of the gray-box model are recorded through XML index. For unstructured data, XML indexes are used to record its association with structured data and version information, replacing the point-to-point interface development model between tools.

4. The multi-source heterogeneous data integration and traceability method according to claim 1, characterized in that, In step S2, a special meta-model for the aviation field is defined based on the Meta Object Facility (MOF), which clarifies the attributes and association rules of elements that include at least requirements, components, and interfaces, and fully aligns with the core elements of the SysML specification. The aviation-specific meta-model is serialized and stored using the XMI metadata exchange standard to ensure that different modeling tools can parse and exchange SysML model instances based on the aviation-specific meta-model at the grammatical level. Establish a tool adaptation layer, design an incremental import / export mechanism for the unique extensions of each modeling tool, and automatically convert the tool's private format through predefined mapping rules.

5. The multi-source heterogeneous data integration and traceability method according to claim 1, characterized in that, In step S3, the interface features are jointly described using SysML Module Definition Diagram (BDD) and Interface Block Diagram (IBD). The Module Definition Diagram (BDD) defines the interface type and performance parameters, while the Interface Block Diagram (IBD) clarifies the signal flow and connection relationships. The mapping relationship between functional parameters of functional requirements and physical properties of physical implementation is established through two types of rules: direct binding of attribute-value pairs, and dynamic derivation by production rules. Based on the element-level traceability mechanism, the functional parameters and physical attributes are associated with a unique ID to obtain a unified expression framework for the function-physical domain interface, which supports the structured expression of the function-physical domain interface and its traceability relationship.

6. The multi-source heterogeneous data integration and traceability method according to claim 1, characterized in that, In step S4, a centralized data warehouse is constructed, and a hybrid storage architecture is used to uniformly store structured and unstructured multimodal data, and to store the traceability relationship associated with the unique ID in step S3. Establish standardized service interfaces to enable data interaction between the demand management tools, architecture modeling and simulation tools, collaborative simulation tools, security analysis tools, and ICD management tools and the centralized data warehouse; Design a data flow path to establish a closed loop: importing demand data into a centralized data warehouse, architecture tools generating models based on demand, simulation tools calling the Functional Model Interface (FMI) for model calculation, and the results flowing back to the centralized data warehouse.

7. The multi-source heterogeneous data integration and traceability method according to claim 6, characterized in that, When tracing changes, an impact analysis engine is developed to construct a network relationship graph based on the traceability relationship associated with the unique ID in step S3, automatically locate the scope of the change's impact, and perform real-time synchronization and end-to-end traceability of data throughout the entire lifecycle.

8. A multi-source heterogeneous data integration and traceability system for modeling and simulation analysis in the aviation field, characterized in that, The method for integrating and tracing multi-source heterogeneous data as described in any one of claims 1 to 7 includes: The multi-source heterogeneous data standardization system construction module is configured as a two-layer architecture that combines international standard adaptation with custom encapsulation to eliminate data barriers between tools and standardize all types of data, including structured data, semi-structured data, unstructured data, and gray-box / black-box models. The SysML model unified representation module is configured to define aerospace-specific meta-models and serialize and store them to ensure that different modeling tools can parse and exchange SysML model instances based on the same meta-model; the SysML model unified representation module also includes a tool adaptation layer for automatically converting the unique private formats of each modeling tool. The bidirectional traceability modeling module for the functional-physical domain interface is configured to describe interface features in a graphical way, establish a mapping relationship between functional parameters of functional requirements and physical attributes of physical implementation, and realize element-level traceability between functional interfaces and physical interfaces through a unique ID. The toolchain data transfer and traceability module is based on a centralized data warehouse and is configured to uniformly store multimodal data and their relationships, design data flow paths, and perform global change synchronization during change traceability.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor runs the program, it implements the multi-source heterogeneous data integration and tracing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions or computer programs, which, when processed and executed, implement the multi-source heterogeneous data integration and traceability method as described in any one of claims 1 to 7.

Images