Multi-modal data storage method and system based on aviation industry

Abstract

The invention discloses a multi-modal data storage method and system based on aviation industry. The method comprises the following steps: receiving multi-source data through a data integration layer, identifying a file type through file header information, an extension name or a content sampling mode of the multi-source data, pre-extracting file basic metadata, and generating a temporary metadata record; generating a classification label by combining the data type, the business field, the access frequency and the security level of the multi-source data, and recording a classification log; carrying out analysis based on a predefined analysis strategy in unified data modeling; and the analyzed data is converted into a target data model according to a predefined mapping strategy in unified data modeling, data cleaning and verification are completed, a data entity conforming to unified data modeling specifications is created, and a storage medium is automatically selected according to a classification label. According to the method, storage management of cross-professional data in the aviation industry can be realized, and the data management capability in the aviation industry design and manufacturing process is comprehensively improved.

Description

Technical Field

[0001] This invention relates to the field of simulation data management technology in the aviation industry, specifically to a multimodal data storage method, system, electronic device, and medium based on the aviation industry. Background Technology

[0002] As the aviation industry rapidly develops towards digitalization and intelligence, the demands for efficiency and accuracy in simulation analysis during product development are continuously increasing. Modern aviation product simulation is no longer limited to a single physical field or a single scale, but rather encompasses a complex multimodal system composed of multi-source heterogeneous data, including material properties, profile specifications, composite material layup design, 3D geometric models, and computational grids. These data vary significantly in format, scale, and access characteristics. High-precision 3D model data is massive, placing stringent demands on storage capacity and loading speed; material data, due to frequent queries and calls, is extremely sensitive to data accuracy and consistency.

[0003] Currently, the methods for accessing and managing simulation data are highly fragmented. The mainstream methods include: relying on the built-in material libraries of commercial simulation software (such as ABAQUS and SolidWorks Simulation); using external databases or plugins (such as ANSYS Granta MI) to integrate with the simulation platform through an interface; or having engineers manually import local data files (such as Excel spreadsheets or BDF format models). The coexistence of these methods leads to scattered data storage and inconsistent management strategies, which seriously restricts the efficiency of data utilization.

[0004] Based on the above problems, the applicant proposes the technical solution of this application. Summary of the Invention

[0005] The purpose of this invention is to provide a multimodal data storage method, system, electronic device and medium based on the aviation industry. By constructing a UDM to standardize, classify and integrate three-dimensional heterogeneous data, it realizes the storage management of cross-professional data in the aviation industry and comprehensively improves the data management capabilities in the design and manufacturing process of the aviation industry.

[0006] To achieve the above objectives, this invention discloses a multimodal data storage method based on the aerospace industry, comprising the following steps: Multi-source data access steps: Receive multi-source data through the data integration layer. During the reception process, adopt real-time data synchronization, full synchronization, or incremental update strategies to ensure data integrity. File type identification and metadata pre-extraction steps: Identify file types by sampling file header information, extensions, or content from multi-source data; pre-extract basic file metadata based on file types; and generate temporary metadata records. The steps to generate preliminary classification labels are as follows: Combine the data type, business domain, access frequency, and security level of multi-source data to generate classification labels and record classification logs. Differential parsing processing steps: Based on the predefined parsing strategy in the unified data modeling of the metadata management layer, the multi-source data belonging to different category labels is parsed to obtain the parsed data; Standardized transformation and entity creation steps: The parsed data is transformed into the target data model according to the predefined mapping strategy in the unified data modeling, data cleaning and verification are completed, and data entities that conform to the unified data modeling specifications are created. Storage routing decision steps: Automatically select storage media based on the classification tags generated by the data integration layer. Structured data is stored in the Doris database, metadata and lineage are synchronously stored in the MySQL database, semi-structured data is stored in the MongoDB database, low-frequency access data in unstructured data is stored in object storage OSS, and high-frequency access data in unstructured data is stored in file-level storage NAS.

[0007] Preferably, prior to the storage routing decision step, the method further includes: Data lineage binding steps: Strongly logically associate the created data entities with the predefined standard model in unified data modeling, bind and record the upstream and downstream dependencies of the data, and form a traceable lineage link and link attributes; Metadata construction and extension steps: Construct complete metadata based on unified data modeling of the metadata management layer. The complete metadata includes data element attributes, data structure, aviation extended attributes, and custom supplementary attributes. Professional database allocation steps: In the data layer, data types are matched according to the predefined standard templates in unified data modeling, and data is allocated to the corresponding professional databases according to the data types to achieve data structuring.

[0008] Preferably, after the storage routing decision step, the method further includes: Storage integrity verification steps: Verify data storage results, ensure that structured data indexes are normal, semi-structured data shards are correct, unstructured data read and write is smooth, and update the storage location information in the metadata synchronously.

[0009] Preferably, after the storage integrity verification step, the method further includes: Metadata synchronization steps with the service layer: Synchronize the stored metadata to the service layer, supporting multimodal retrieval and data lineage preview.

[0010] Preferably, the file types include OP2, BDF, Excel, CSV, and TXT, and the basic file metadata includes file size, creation time, and source channel.

[0011] Preferably, for structured data, Apache POI is used for parsing to extract the table header, data type, and data range; for semi-structured data, partial parsing is performed to extract header information, data block type, and version number; and for unstructured data, lightweight parsing is performed to extract basic geometric information and format version.

[0012] This invention also discloses a multimodal data storage system based on the aviation industry, comprising an application layer, a service layer, a metadata management layer, a data integration layer, a data layer, and a storage layer; The application layer is used to provide a user interaction and business logic processing window, a data acquisition window for component applications and simulation applications in the aerospace industry, an analysis window for data reports, and a configuration window for unified data modeling. The service layer is used to provide multimodal data retrieval, metadata interface, data import, data update and batch export services; The metadata management layer is used to achieve standardized integration and semantic unification of multimodal data in the aviation industry by constructing standardized model templates for a unified data modeling framework. The data integration layer is used to provide multi-channel access points for multimodal data, and to realize real-time data synchronization, full synchronization or incremental update strategies; The data layer is used to configure multiple databases according to different simulation application scenarios and different data types, so as to realize business relevance between cross-professional data; The storage layer is used for physical storage of multimodal data in the aerospace industry. Structured data is stored in the Doris database, metadata and lineage are synchronously stored in the MySQL database, semi-structured data is stored in the MongoDB database, low-frequency access data in unstructured data is stored in object storage OSS, and high-frequency access data in unstructured data is stored in file-level storage NAS.

[0013] Preferably, the multimodal data storage system based on the aviation industry executes the aforementioned multimodal data storage method based on the aviation industry.

[0014] The present invention also discloses an electronic device, including one or more processors, a memory, and a computer program, which, when executed by the processor, is used to implement the above-described multimodal data storage method based on the aerospace industry.

[0015] The present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the above-described multimodal data storage method based on the aerospace industry.

[0016] Compared with the prior art, the present invention has the following beneficial effects: The multimodal data storage method and system based on the aviation industry provided in this invention can comprehensively improve data management capabilities in the design and manufacturing processes of the aviation industry. Based on data type, business domain, and access frequency, it designs multi-database collaborative storage, standardizing and integrating multi-source heterogeneous data unique to the aviation industry, avoiding data silos and collaboration difficulties, significantly improving cross-disciplinary data management and collaborative use, providing a unified data foundation for simulation analysis, and effectively improving the efficiency and quality of simulation analysis. Through UDM (User Data Management) with preset aviation professional templates and support for custom extended fields, it records detailed data attribute information and achieves multi-dimensional metadata control. It implements differentiated parsing for aviation-specific format files, automatically extracting key metadata and mapping it to the UDM, effectively improving parsing efficiency and providing support for unified data semantics for cross-disciplinary collaboration.

[0017] The following will further explain the concept, specific structure, and technical effects of the present invention in conjunction with the accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the multimodal data storage method based on the aerospace industry in this invention.

[0019] Figure 2 This is a schematic diagram of the processing flow of OP2 files in the multimodal data storage method based on the aviation industry in this invention.

[0020] Figure 3 This is a schematic diagram of the framework structure of the multimodal data storage system based on the aviation industry in this invention. Detailed Implementation

[0021] To make the technical means, inventive features, objectives, and effects of the invention readily understandable, the invention is further illustrated below with reference to specific figures. However, the invention is not limited to the embodiments described below.

[0022] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings of this specification are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0023] The core problems currently facing multimodal data management in the aviation industry are the lack of data standardization, severe data silos, weak version control, difficulties in data traceability, and insufficient industry adaptability. The lack of data standardization manifests as a lack of standardized and unified data storage, with diverse data sources and scattered storage locations. Commercial software's built-in libraries have limited coverage, failing to meet the specialized needs of aviation materials and other specialties; external databases rely on networks and are constrained by plugin compatibility; manual import methods require repeated format conversions, resulting in low operational efficiency and high management costs. Severe data silos are manifested in the significant differences in data formats between cross-disciplinary software (such as NASTRAN and ABAQUS) (e.g., Excel, BDF, OP2), leading to high barriers to cross-disciplinary data reuse and the formation of isolated data islands. Weak version control is manifested in frequent simulation iterations but a lack of a unified version control mechanism, easily leading to data redundancy and version conflicts, affecting the reliability of the R&D process. Difficulties in data traceability are manifested in the fact that binary result files (such as OP2), due to their encapsulation characteristics, lack readable metadata, making it difficult to trace the data generation path and relationships, posing a significant challenge to simulation result verification and problem troubleshooting. The lack of industry adaptability is manifested in the aviation industry's extremely high requirements for data specialization (such as parameters of special materials), update frequency, and security levels. Existing general-purpose commercial databases have significant shortcomings in data classification, update mechanisms, and security control. Therefore, there is an urgent need to build a simulation data management system that can integrate multimodal data, support efficient access, ensure version consistency and data traceability, and meet the specific needs of the aviation industry, in order to overcome current technological bottlenecks and support the intelligent development of the aviation industry.

[0024] To address the aforementioned technical problems and avoid issues such as fragmented data storage, version inconsistencies, difficulty in tracing origins, inconvenient cross-disciplinary collaboration, low data reusability, and poor data consistency in the aviation industry, the first embodiment of this invention provides a multimodal data storage method based on the aviation industry, such as... Figure 1 As shown, the method includes the following steps: Step S1, Multi-source data access step: Receive multi-source data through the data integration layer. During the reception process, adopt real-time data synchronization, full synchronization or incremental update strategies to ensure data integrity.

[0025] Specifically, multi-source data access involves receiving data from multiple sources through a data integration layer, such as data uploaded locally or accessed from external systems. Real-time data synchronization, full synchronization, or incremental update strategies are employed to ensure data integrity. After receiving the file, a dynamic classification engine is invoked to identify the data type based on file characteristics, triggering the corresponding processing flow.

[0026] Step S2, File Type Identification and Metadata Pre-extraction: Identify file types by sampling file header information, extensions, or content from multiple sources, pre-extract basic file metadata based on file types, and generate temporary metadata records.

[0027] Specifically, the identified file types include OP2, BDF, Excel, CSV, and TXT, identified through file header information and file extensions. For more accurate file type identification, content sampling is also used. Afterward, basic file metadata is extracted and a temporary metadata record is generated and stored. This basic file metadata includes file size, creation time, and source.

[0028] Step S3, generating preliminary classification labels: Combine the data type, business domain, access frequency, and security level of multi-source data to generate classification labels and record classification logs.

[0029] Specifically, classification labels such as material-structured-high-frequency patterns are generated by combining data type, business domain, access frequency, and security level. Classification decision logs are recorded while generating classification labels to facilitate subsequent optimization and auditing.

[0030] Step S4, Differential parsing processing step: Based on the predefined parsing strategy in the unified data modeling of the metadata management layer, the multi-source data belonging to different category labels is parsed to obtain the parsed data.

[0031] Specifically, by differentiating category labels, different types of data are parsed differently. Structured data, such as Excel material tables, is parsed using Apache POI to extract headers, data types, and data ranges. Semi-structured data, such as OP2 binary files, is partially parsed to extract header information, data block types, and version numbers. Unstructured data, such as 3D model files, is parsed using lightweight parsing to extract basic geometric information and format version.

[0032] Step S5, Standardization Transformation and Entity Creation: The parsed data is transformed into the target data model according to the predefined mapping strategy in the unified data modeling, data cleaning and verification are completed, and data entities that conform to the unified data modeling specifications are created.

[0033] Specifically, the parsed data obtained in step S4 is converted into the target data model according to the predefined mapping rules in Unified Data Modeling (UDM). Then, data cleaning and verification are performed to ensure compatibility of multi-source data and to create data entities that conform to UDM specifications.

[0034] Unified Data Modeling (UDM) is used to standardize the transformation of multi-source heterogeneous data. The main functions of Unified Modeling include: defining a core set of data attributes, including data ID, name, type, source, version, and creation time; supporting extended attribute fields, such as those specific to various data types, like the elastic modulus of materials or the number of meshes in a model; supporting two types of models: general models and ordinary models. General models provide common fields for integration, supporting parent-child and sibling model structures, object field types, and supporting all data types, including structured, unstructured, and semi-structured models; the overall model storage structure is a binary tree node structure, with clear relationships between models, and the current node can support multiple versions. Based on these main functions, general data import is further implemented. Imported source data is primarily in JSON format, adapted to the corresponding model. After general validation, the JSON data is stored in the corresponding MongoDB database according to the matched fields. General validation includes complete field matching and value type matching between the model and data.

[0035] Step S6, Storage Routing Decision Step: Automatically select storage media based on the classification tags generated by the data integration layer. Structured data is stored in the Doris database, metadata and lineage are synchronously stored in the MySQL database, semi-structured data is stored in the MongoDB database, low-frequency access data in unstructured data is stored in object storage OSS, and high-frequency access data in unstructured data is stored in file-level storage NAS.

[0036] Specifically, taking the classification label "Materials-Structured-High Frequency" generated by the data integration layer as an example, the file is divided into structured data and stored in the corresponding storage media. Structured data such as material properties and load parameters are stored in the MPP Doris database. Semi-structured data such as OP2 files and XML configurations are stored in the MongoDB database, and managed by fragmentation according to the simulation task and data type to which the file belongs. Low-frequency access unstructured data such as historical archive models are stored in Object Storage Service (OSS). High-frequency access unstructured data such as the current design version's 3D model is synchronized to file-level storage (NAS) using automated synchronization tools. To enhance the security of data storage, sensitive data is encrypted and access logs are recorded.

[0037] It should be noted that UDM has an inherently logically connected model lineage system, which enables the pre-definition of lineage relationships before data is generated and the self-recording during data processing.

[0038] First, the pre-defined lineage relationship during the model design phase means that, during the unified modeling phase, when defining parent-child or sibling model relationships, this strong logical association is automatically created and persisted in the metadata management layer. For example, a 'simulation task' model can be defined as the parent model, and its output 'OP2 result file' model as the child model. This relationship between models, established based on business logic before data generation, forms the skeleton of the data lineage. It clearly defines how data should flow and derive at the business level, rather than simply passively recording the actual flow path afterward.

[0039] Secondly, data lineage is the instantiation and continuation of model relationships. When a specific data instance is imported into the database according to its model definition through a general import process, it is automatically bound to the data instance corresponding to its parent model. For example, a specific `OP2 result file` record generates a `simulation task` record for that result file. This means that from the moment each data piece is generated, it naturally inherits the upstream and downstream lineage relationships defined in the model tree through its respective model node. Data lineage is no longer a scattered, isolated metadata tag, but rather an instantiation and filling of a predefined model relationship structure, ensuring the accuracy and consistency of the lineage.

[0040] Finally, based on model node lineage tracing and impact analysis, since all data is stored in a binary tree structure, strictly belonging to a specific model node during storage, and the relationships between nodes are clear, lineage lookup becomes efficient and accurate. Whether tracing the source of data (upward tracing) or analyzing the scope of the impact of data changes (downward tracing), it can be achieved by traversing this "model tree." For example, when the data of a certain 'material' model changes, all 'simulation task' sub-models that reference that model data can be quickly located, and then the 'OP2 result file' sub-models generated by all these tasks can be located, thus achieving precise change impact analysis. This is far superior to the traditional method of keyword matching in flattened metadata.

[0041] In one example, prior to the storage routing decision step, the multimodal data storage method based on the aerospace industry also includes: Step S51, Data lineage binding step: Strongly logically associate the created data entities with the predefined standard model in unified data modeling, bind and record the upstream and downstream dependencies of the data, and form a traceable lineage link and link attributes.

[0042] Specifically, the data entities created in step S5 prepare the data for subsequent data lineage binding and persistent storage. These data entities are automatically bound to predefined strong logical associations in the UDM model; for example, the simulation task model is strongly logically associated with the OP2 result model. After the strong logical association, upstream and downstream dependencies also need to be recorded, such as using the material list as input parameters for the simulation task. Through strong logical associations and upstream and downstream dependencies, a traceable lineage is formed, and the link attributes of this lineage are recorded.

[0043] Step S52, Metadata Construction and Extension Step: Construct complete metadata based on unified data modeling of the metadata management layer. The complete metadata includes data element attributes, data structure, aviation extended attributes, and custom supplementary attributes.

[0044] Specifically, complete metadata is built based on UDM, covering data element attributes, data structure and aviation extended attributes, and additional fields can also be customized through the web interface.

[0045] Step S53, Professional Database Allocation Step: In the data layer, match data types according to the predefined standard templates in unified data modeling, and allocate data to the corresponding professional databases according to data types to achieve data structuring.

[0046] Specifically, the data layer is configured with various specialized databases, such as parameter libraries, material libraries, and calculation example libraries for processing structured data; profile libraries and fastener libraries for processing semi-structured data; and result libraries and algorithm libraries for processing unstructured data. Data types of each file are matched against the standard templates in the UDM, and the files are automatically assigned to the corresponding specialized databases based on the matching results, ensuring data structuring.

[0047] In one example, following the storage routing decision step, the multimodal data storage method based on the aerospace industry also includes: Step S61, Storage Integrity Verification Step: Verify the data storage results to ensure that the structured data index is normal, the semi-structured data sharding is error-free, the unstructured data read and write is smooth, and the storage location information in the metadata is updated synchronously.

[0048] Step S62, Metadata and Service Layer Synchronization Step: Synchronize the stored metadata to the service layer, supporting multimodal retrieval and data lineage preview.

[0049] The following detailed explanation uses the semi-structured data OP2 file as an example.

[0050] The OP2 file, a semi-structured data file, is a binary result format unique to NASTRAN simulations in the aerospace industry. It is complex in structure and high in data dimensionality, and its parsing process involves complete metadata extraction, data transformation, and storage logic. For structured data such as database tables, complex parsing is typically unnecessary; only basic operations like parsing the table header, type inference, and UDM adaptation are required. However, unstructured data, such as 3D models, skips some metadata processing steps, requiring only the extraction of basic metadata. The OP2 file processing flow is the most representative example of this.

[0051] The results library file, or OP2 file, is a binary file containing a large amount of information. These files are typically large, so performance must be considered during upload. The filename follows a specific format, revealing information such as the file's model, section, batch, and cycle. The file primarily includes node and element data, as well as the solution results. Node and element data includes node displacement, velocity, acceleration, force, and stress. Solution results include static, dynamic, frequency response, and transient response analyses. The OP2 file mainly consists of a header, data blocks, records, words, and a footer. The header contains basic file information such as version number, analysis type, data block location, and file size. It identifies the file format and provides an index for the subsequent data sections. Data blocks, as the core component of OP2 and the basic unit for storing information, contain node data (such as displacement, velocity, and acceleration), element data (such as stress and strain), and various result data (such as reaction force data, like nodal reaction force and support reaction force; vibration modes and resonant frequencies in frequency analysis; and displacement, velocity, and acceleration data over time in transient response analysis). Each data block may contain multiple records, each representing specific data. Records have fixed-length fields (such as node ID and element ID) and variable-length fields (such as numerical data like stress and displacement). A record, as the basic unit of a data block, contains a set of information about related data items. It is typically a row or a single data unit within the data block, responsible for storing specific data entries or results. A data block usually contains multiple records; for example, record 0 (header record) contains the data block's metadata, records 1 to N (data records) contain specific data items, and the tail record typically contains summary information or other content describing the end of the data block. A word is the basic unit of storage for a record, and it can contain data of different types (such as integers, real numbers, characters, etc.). Each record consists of multiple words, and each word represents a data field. A word is 4 bytes in size. The footer, as the end of the file, typically contains summary information and check and control fields for marking the end of the file and verifying data integrity in OP2 files.

[0052] like Figure 2 As shown, the specific data storage process for the OP2 file is as follows: Step A1, Upload OP2 file: Upload the local OP2 file through the front-end interface, transfer it to the back-end server, and then transfer it to the data integration layer.

[0053] Step A2, Parse Filename: Enter the metadata management layer, obtain the filename of the uploaded file, and parse it according to the pre-defined naming rules. By parsing the filename, data storage parameters such as model and section are obtained. These parameters will be associated with predefined data lineage relationships for subsequent data storage and management.

[0054] Step A3, Create the OP2 entity to store parsed data: Create an OP2 entity as a container to store the various data parsed from the OP2 file, providing a framework and carrier for subsequent data processing and storage. This entity is bound to a predefined lineage model upon creation, ensuring that all subsequent data operations inherit the lineage relationships.

[0055] Step A4, Load OP2 Data: The uploaded OP2 file is read in binary format and loaded into memory, providing the foundation for subsequent parsing of each data block of the file. During the loading process, the integrity of the file is further checked to ensure that no data is lost or corrupted during the reading process.

[0056] Step A5, Read the Header Data Block: Read the Header data block of the OP2 file. The Header data block contains important information such as the file format and OP2 version. After extracting this information, store it in the corresponding attribute fields of the previously created OP2 entity. This metadata will serve as key attributes for lineage tracing.

[0057] Step A6: Determine parsing parameters based on format / version: Based on the file format and OP2 version information obtained from the Header data block, determine the specific parameters and rules to be used when parsing other data blocks. These parameters are consistent with the predefined lineage parsing rules.

[0058] Step A7: Read the next data block: The OP2 file contains multiple data blocks, each storing different types of simulation result data. By reading these data blocks one by one, all valid information in the file is gradually obtained.

[0059] Step A8, Parse Data Blocks: For each data block read, perform detailed parsing according to the previously determined parsing parameters and rules. Extract various metadata such as header information, case information, result datasets, and unit datasets. This metadata will be automatically associated with predefined lineage paths, and the parsed metadata will be stored in the corresponding attributes and fields of the OP2 entity.

[0060] Step A9, Save the parsed data to the OP2 entity: After parsing a data block and extracting valid data, save this data to the OP2 entity. Each data saving operation updates the lineage record in real time, ensuring data integrity and orderly storage, facilitating unified management and operation of all parsed data in the entire OP2 file.

[0061] Step A10: Determine if it is the end of the file. If not, continue reading the next data block and repeat steps A7-A9 until the end of the file is encountered, thus completely reading and parsing all data blocks in the OP2 file.

[0062] Step A11: If the previous step determined that it was the end of the file, then the reading of OP2 data ends: When the current data block is detected as the end of the file, the reading operation of the OP2 file data block stops, marking the completion of the data reading phase of the OP2 file. At this time, the OP2 entity has stored all the valid data parsed from the file and its complete lineage information.

[0063] Step A12: Statistical analysis of the result data types: The result data stored in the OP2 entity is analyzed, and the statistical information is added to the lineage metadata to provide a reference for subsequent data processing and analysis.

[0064] Step A13, Obtain Subcase Information: Extract subcase information from the OP2 entity, such as the subcase number, name, and corresponding operating condition. This subcase information will be used to improve the hierarchical structure of the data lineage. This is crucial for in-depth analysis of simulation results under different operating conditions, helping users to study and compare structural performance and other data under different conditions in greater detail.

[0065] Step A14: Extract unit ID data from the result data: Extract unit ID data from the result data. The unit ID is a unique identifier for each unit in the data. Extracting this data helps to classify, filter, and perform correlation analysis on the data, and establish a lineage relationship with other professional data.

[0066] Step A15, Construct a data storage entity: Construct a new data storage entity from the previously created OP2 entity and the data storage parameters. This entity fully includes the predefined lineage network to ensure the traceability of data sources, processing procedures, and flow paths.

[0067] Step A16, save the data to the database: The data enters the storage layer, and this data storage entity containing complete lineage information is stored in the MongoDB database to achieve persistent storage and management of OP2 file data, providing support for subsequent cross-disciplinary data correlation analysis, data retrieval, etc.

[0068] This embodiment achieves cross-disciplinary data storage management through unified multimodal data storage, providing a consistent data foundation for the entire simulation process and improving the efficiency and quality of data analysis. By using customized and extended unified data modeling, predefined data lineage and dynamic association mechanisms based on business logic, and differentiated analysis of aviation industry data, a multimodal data storage system adapted to the aviation industry scenario is constructed, enabling efficient data storage, cross-disciplinary collaboration, end-to-end traceability, and version control.

[0069] In multimodal data adaptation and storage, and the construction of a unified data source, a multi-database collaborative storage architecture is designed based on data type (structured / semi-structured / unstructured), business domain, and access frequency. This standardizes and integrates heterogeneous data from multiple sources, such as 3D models, OP2 files, and BDF files specific to the aviation industry. Dedicated storage models are designed for different data types, constructing a unified data source that supports application scenarios throughout the entire process from design to simulation calculation. This breaks down data silos and collaboration difficulties, significantly improving cross-disciplinary data management and collaborative reuse, providing a unified data foundation for simulation analysis, and enhancing the efficiency and quality of simulation analysis.

[0070] Metadata management and file differentiation parsing are achieved through a unified data modeling (UDM) system that uses pre-defined aviation-specific templates and supports custom extended fields. This records detailed data attribute information, such as data definition, source, creation time, and aviation-specific attributes, enabling multi-dimensional metadata control. Differential parsing is implemented for aviation-specific formats (such as OP2 binary files), automatically extracting key metadata and mapping it to the UDM model. This effectively improves parsing efficiency, standardizes the format compatibility of aviation-specific data, strengthens data relationships through metadata, and provides semantically unified support for cross-disciplinary collaboration.

[0071] In the UDM design phase, data lineage traceability and dynamic association are reflected. Based on predefined data lineage relationships according to the business logic of the aviation industry, data instantiation automatically inherits this relationship and dynamically records the flow path. This allows technicians to quickly operate through the model tree. When tracing upwards, they can accurately locate the data source, such as simulation conditions, and when analyzing downwards, they can quickly determine the scope of impact when data changes occur. This achieves traceability of sources, manageable changes, and controllable versions, effectively reducing version conflicts and thus significantly improving the efficiency and quality of simulation analysis for engineering technicians.

[0072] This embodiment enables the comprehensive improvement of data management capabilities in the design and manufacturing process of the aviation industry, specifically addresses the core pain points of multi-disciplinary data sharing and collaboration in the aviation industry, and provides key support for data accumulation and technological innovation in the aviation industry.

[0073] A second embodiment of the present invention provides a multimodal data storage system based on the aerospace industry, wherein the system executes the method of the first embodiment. Figure 3 As shown, the system includes an application layer, a service layer, a metadata management layer, a data integration layer, a data layer, and a storage layer.

[0074] The application layer provides a user interaction and business logic processing window, a data acquisition window for component and simulation applications in the aerospace industry, an analysis window for data reports, and a configuration window for unified data modeling. It also supports accessing the UDM configuration entry point via a web interface to customize supplementary fields or create new modeling templates.

[0075] The service layer provides multimodal data retrieval, offering metadata interfaces, data import, data update, and batch export services. It provides a unified retrieval system with multimodal, precise, combined, and intelligent retrieval capabilities, and supports metadata interfaces, data import, data update, and batch export services. Through a query builder, it supports the free combination of various search conditions (such as time ranges and tags) to achieve efficient retrieval under complex query logic. Through a standardized metadata model and API interface, it calls the lineage data of the metadata management layer, supporting metadata creation, reading, updating, and deletion operations. It also supports previewing and analyzing the lineage of search results, ensuring the orderly management and efficient retrieval of data assets.

[0076] The metadata management layer is used to achieve standardized integration and semantic unification of multimodal data in the aerospace industry by constructing standardized model templates within a unified data modeling framework. The metadata management layer is responsible for managing metadata and recording data lineage. Its core is a metadata system built on the Unified Data Modeling (UDM) framework, achieving standardized integration and semantic unification of multimodal data in the aerospace industry. Through a set of predefined, extensible standardized model templates, the data structure, business attributes, and relationships of the data are uniformly abstracted and described. The metadata model is constructed using UDM, covering the attributes of data elements (such as name, type, length, and precision), data structure (such as table structure and field relationships), and data relationships (such as primary and foreign key relationships), and supports custom extended attribute fields to accommodate unique attributes of various data types (such as the elastic modulus of materials, the number of grids in the model, etc.). By designing metadata templates, various types of metadata can be quickly defined and entered. Templates describing the business meaning and rules for business metadata are provided to ensure data semantic consistency. A comprehensive metadata classification system is established, clearly defining classification standards and management rules. Furthermore, it supports predefined strong logical relationships between models based on business logic during the UDM modeling phase, such as simulation task models and OP2 result models. This explicitly defines the flow and derivation of data at the business level, storing model nodes in a binary tree structure, and automatically integrating relationships during data instantiation. It provides automated data lineage tracing capabilities, recording the transformation path of data from source to target, including ETL processes and data processing logic, and supports the generation and browsing of data flow diagrams. Based on data lineage and the binary tree structure, it provides change impact analysis functions, quickly identifying and locating affected data assets and downstream systems.

[0077] The data integration layer provides multi-channel access points for multimodal data, enabling real-time data synchronization, full synchronization, or incremental update strategies. It is responsible for the access and standardization of multi-source heterogeneous data, primarily sourced from local uploads and imports and external system data access. Data is integrated through real-time synchronization, full synchronization, and incremental update strategies. Based on predefined parsing rules in the Unified Data Model (UDM), such as parser type, extracted metadata fields, and lineage rules, subsequent parsing behavior is dynamically guided. By mapping to specific model nodes in the UDM, the parsed data is converted into the target data model, undergoing cleaning, format standardization, and data validation to achieve file identification, differentiated parsing, attribute association, and model matching. During parsing, predefined data lineage relationships are automatically bound. Through unified management of data sources, business personnel can efficiently define and trace data collection, ensuring data traceability and standardized management.

[0078] Upon data access, the file type (e.g., OP2, BDF, Excel, CSV, etc.) is first identified through methods such as file header information, file extension, and content sampling. Basic metadata (e.g., file size, creation time, source system, etc.) is pre-extracted, and temporary metadata records are generated. Classification tags (e.g., "Materials-Structured-High Frequency") are generated based on data type, business domain, access frequency, and security level. A classification decision log is also recorded for subsequent optimization and auditing. Further content and structure parsing is performed to achieve data standardization. Apache POI is used to parse various common formatted data such as Excel, CSV, and TXT, extracting headers, data types, and data ranges. Semi-structured data such as OP2 binary files are partially parsed, extracting header information, data block types, version numbers, etc. Lightweight parsing is used for unstructured data such as 3D model files, extracting basic geometric information and format versions.

[0079] The data layer is used to configure multiple databases according to different simulation application scenarios and data types to achieve business relevance between cross-disciplinary data. The data layer defines data models and organizes multi-disciplinary data, employing a multi-database or multi-set / table strategy within a database to correspond to different data types, including material libraries, profile libraries, model libraries, algorithm libraries, example libraries, parameter libraries, load libraries, result libraries, and fastener libraries, supporting multiple simulation application scenarios. A unified data model UDM predefined template is matched to each type of database, supporting custom extended fields in the UDM to ensure data structure. For example, the material library includes material properties (such as density and elastic modulus) and data source information; the model library focuses on geometry, topology, and mesh generation information; and the algorithm library records algorithm names, descriptions, and input / output parameters. This supports multiple simulation application scenarios and ensures cross-disciplinary data business relevance.

[0080] The storage layer is used for physical storage of multimodal data in the aerospace industry. Structured data is stored in the Doris database, metadata and lineage information are synchronously stored in a MySQL database, semi-structured data is stored in a MongoDB database, low-frequency access data in unstructured data is stored in Object Storage Service (OSS), and high-frequency access data in unstructured data is stored in File-Level Storage (NAS). The storage layer provides a dynamic adaptation mechanism for the different characteristics of structured, semi-structured, and unstructured data, enabling automatic selection of storage media based on classification tags generated by the data integration layer, thus dynamically optimizing storage strategies and improving storage efficiency. Structured data is stored in the MPP database Doris, while metadata is stored in MySQL; semi-structured document-type data is stored in MongoDB; unstructured data is first stored in OSS and then synchronized to NAS using automated synchronization tools. Models in NAS have efficient read capabilities, facilitating rapid model loading by model conversion and 3D rendering components.

[0081] Since the first embodiment corresponds to this embodiment, this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment remain valid in this embodiment, and the technical effects achievable in the first embodiment can also be achieved in this embodiment. To reduce repetition, they will not be repeated here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the first embodiment.

[0082] A third embodiment of the present invention provides an electronic device, including a processor, a memory, and a computer program, wherein the computer program, when executed by the processor, is used to implement the method described in the first embodiment.

[0083] A fourth embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the method described in the first embodiment.

[0084] 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 multimodal data storage method based on the aviation industry, characterized in that, Includes the following steps: Multi-source data access steps: Receive multi-source data through the data integration layer. During the reception process, adopt real-time data synchronization, full synchronization, or incremental update strategies to ensure data integrity. File type identification and metadata pre-extraction steps: Identify file types by sampling file header information, extensions, or content from multi-source data; pre-extract basic file metadata based on file types; and generate temporary metadata records. The steps to generate preliminary classification labels are as follows: Combine the data type, business domain, access frequency, and security level of multi-source data to generate classification labels and record classification logs. Differential parsing processing steps: Based on the predefined parsing strategy in the unified data modeling of the metadata management layer, the multi-source data belonging to different category labels is parsed to obtain the parsed data; Standardized transformation and entity creation steps: The parsed data is transformed into the target data model according to the predefined mapping strategy in the unified data modeling, data cleaning and verification are completed, and data entities that conform to the unified data modeling specifications are created. Storage routing decision steps: Automatically select storage media based on the classification tags generated by the data integration layer. Structured data is stored in the Doris database, metadata and lineage are synchronously stored in the MySQL database, semi-structured data is stored in the MongoDB database, low-frequency access data in unstructured data is stored in object storage OSS, and high-frequency access data in unstructured data is stored in file-level storage NAS.

2. The multimodal data storage method based on the aviation industry according to claim 1, characterized in that, Prior to the storage routing decision step, the method further includes: Data lineage binding steps: Strongly logically associate the created data entities with the predefined standard model in unified data modeling, bind and record the upstream and downstream dependencies of the data, and form a traceable lineage link and link attributes; Metadata construction and extension steps: Construct complete metadata based on unified data modeling of the metadata management layer. The complete metadata includes data element attributes, data structure, aviation extended attributes, and custom supplementary attributes. Professional database allocation steps: In the data layer, data types are matched according to the predefined standard templates in unified data modeling, and data is allocated to the corresponding professional databases according to the data types to achieve data structuring.

3. The multimodal data storage method based on the aviation industry according to claim 2, characterized in that, Following the storage routing decision step, the method further includes: Storage integrity verification steps: Verify data storage results, ensure that structured data indexes are normal, semi-structured data shards are correct, unstructured data read and write is smooth, and update the storage location information in the metadata synchronously.

4. The multimodal data storage method based on the aviation industry according to claim 3, characterized in that, Following the storage integrity verification step, the method further includes: Metadata and service layer synchronization steps: Synchronize the stored metadata to the service layer, supporting multimodal retrieval and data lineage preview.

5. The multimodal data storage method based on the aviation industry according to claim 1, characterized in that, The file types include OP2, BDF, Excel, CSV, and TXT, and the basic metadata of the files includes file size, creation time, and source channel.

6. The multimodal data storage method based on the aviation industry according to claim 5, characterized in that, For structured data, Apache POI is used for parsing to extract headers, data types, and data ranges; for semi-structured data, partial parsing is performed to extract header information, data block types, and version numbers; and for unstructured data, lightweight parsing is used to extract basic geometric information and format version.

7. A multimodal data storage system based on the aerospace industry, characterized in that, It includes the application layer, service layer, metadata management layer, data integration layer, data layer, and storage layer; The application layer is used to provide a user interaction and business logic processing window, a data acquisition window for component applications and simulation applications in the aerospace industry, an analysis window for data reports, and a configuration window for unified data modeling. The service layer is used to provide multimodal data retrieval, metadata interface, data import, data update and batch export services; The metadata management layer is used to achieve standardized integration and semantic unification of multimodal data in the aviation industry by constructing standardized model templates for a unified data modeling framework. The data integration layer is used to provide multi-channel access points for multimodal data, and to realize real-time data synchronization, full synchronization or incremental update strategies; The data layer is used to configure multiple databases according to different simulation application scenarios and different data types, so as to realize business relevance between cross-professional data; The storage layer is used for physical storage of multimodal data in the aerospace industry. Structured data is stored in the Doris database, metadata and lineage are synchronously stored in the MySQL database, semi-structured data is stored in the MongoDB database, low-frequency access data in unstructured data is stored in object storage OSS, and high-frequency access data in unstructured data is stored in file-level storage NAS.

8. The multimodal data storage system based on the aviation industry according to claim 7, characterized in that, Perform the multimodal data storage method based on the aviation industry as described in any one of claims 1 to 6.

9. An electronic device comprising one or more processors, a memory, and a computer program, wherein the computer program, when executed by the processor, is used to implement the multimodal data storage method based on the aerospace industry as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, is used to implement the multimodal data storage method based on the aerospace industry as described in any one of claims 1 to 6.

Images