Data access method, program product, storage medium and electronic device

Abstract

The present application relates to the field of engineering technology, and provides a data access method, program product, storage medium and electronic device. Among them, the data access method includes: obtaining a metamodel of a product to be developed, the metamodel at least including: a domain model for designing the product to be developed, entities included in each domain model and the relationship between each entity; determining the interface configuration corresponding to the domain model according to the metamodel; accessing the model data of the domain model according to the interface configuration; based on the model data, instantiating the relationship in the metamodel under the guidance of the unified semantic framework of the product to be developed, and obtaining a unified semantic model of the product to be developed, the unified semantic framework at least including: elements, attributes and relationships constituting the product to be developed, and the unified semantic model at least including: triples consisting of entities, relationships and facts. This method realizes the unified description and standardized management of model data of different domain models, laying a solid foundation for the subsequent use of these data.

Description

Technical Field

[0001] The present application relates to the field of engineering technology, and in particular to a data access method, a program product, a storage medium, and an electronic device. Background Art

[0002] During the development of complex industrial products (such as spacecraft, aircraft, automobiles, ships, and robots), R&D engineers design domain models for different business areas to describe product characteristics at different stages of development. These models may include requirements models, system models, product models, and implementation models. However, these domain models exhibit diversity and discrepancies in model standards, data structures, and software vendors. This leads to fragmented distribution and siloed management of product data, a lack of global, unified data governance capabilities, and hinders data exchange and sharing across business areas. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a data access method, a program product, a storage medium, and an electronic device to improve at least some of the above-mentioned technical problems.

[0004] To achieve the above objectives, this application provides the following technical solutions:

[0005] In a first aspect, an embodiment of the present application provides a data access method, the method comprising: obtaining a metamodel of a product to be developed; wherein the metamodel includes at least a domain model for designing the product to be developed, entities included in each domain model, and the relationship between each entity; determining an interface configuration corresponding to the domain model according to the metamodel; accessing model data of the domain model according to the interface configuration; instantiating the relationship in the metamodel under the guidance of a unified semantic framework of the product to be developed according to the model data to obtain a unified semantic model of the product to be developed; wherein the unified semantic framework includes at least elements, attributes and relationships constituting the product to be developed, the unified semantic model includes at least a triple consisting of entities, relationships and facts, the entities in the unified semantic model are obtained based on the merger of entities within each domain model, and the relationships in the unified semantic model include relationships between entities within each domain model, and relationships between entities of different domain models.

[0006] In this method, the metamodel of the product to be developed is first used to describe each domain model, the entities within each domain model, and the relationships between these entities. The specific model data of the domain model is then accessed and used to instantiate the relationships in the metamodel, resulting in a unified semantic model for the product to be developed. This achieves unified description and standardized management of model data from different domain models.

[0007] Moreover, the unified semantic model fully explores and integrates the relationships between entities in the domain model and the relationships between entities in cross-domain models, thereby assisting R&D engineers in obtaining the true status of the product to be developed and mastering massive amounts of product information. It can also automatically generate downstream models using the confirmed relationships between domain models and upstream model data, thereby supporting cross-disciplinary, cross-domain, and cross-system upstream and downstream product development data collaboration, laying the foundation for a trusted data source for subsequent intuitive, efficient, and multi-dimensional global visualization of the entire life cycle.

[0008] In an implementation of the first aspect, if the product to be developed is a mature product, the metamodel of the product to be developed is obtained based on the metamodel of an existing product that is directly accessed; if the product to be developed is a new product, the metamodel of the product to be developed is obtained based on model data analysis of the domain model of the product to be developed.

[0009] In the above implementation, two situations for obtaining the metamodel are given: if the product to be developed is a mature product, a metamodel has been constructed for similar products before, which can be used directly or adjusted appropriately without completely rebuilding the metamodel; if the product to be developed is a new product, no metamodel has been constructed for similar products before, and it is not clear how the metamodel should be constructed. At this time, the model data of a part of the domain model can be connected first, and then the composition of this data can be analyzed to determine how to construct the metamodel, because the metamodel is an abstract representation of these model data, and the initial metamodel can be used to connect new model data to continuously optimize the design of the metamodel.

[0010] In an implementation of the first aspect, after the model data of the domain model is accessed according to the interface configuration, the method further includes: parsing and rule-verifying the accessed model data; if the verification passes, the parsed model data is distributedly indexed and stored according to the instructions of the meta-model.

[0011] In the above implementation, the model data being accessed is first subject to rule verification, which helps improve the quality and integrity of the data being accessed, thereby enhancing the quality of the resulting unified semantic model. Secondly, the model data that passes verification is distributedly indexed and stored, which helps improve data storage uniformity, speeds up data access, and supports the processing of massive amounts of data. Furthermore, because data indexing is performed under the guidance of the metamodel, it helps preserve the logical relationships between model data.

[0012] In an implementation manner of the first aspect, the rule includes at least one of a business rule, a model rule, and a data rule.

[0013] In the above implementation method, model data can be verified from three dimensions: business, model, and data. This method has high flexibility, is conducive to meeting different verification requirements, and realizes comprehensive data verification.

[0014] In an implementation of the first aspect, the meta-model includes multiple levels of nodes, wherein the first-level nodes represent physical storage nodes, each first-level node corresponds to a type of domain model, and the second-level or higher-level nodes represent logical nodes, each second-level or higher-level node corresponds to an entity under a type of domain model; the distributed indexing of the parsed model data according to the instructions of the meta-model includes: indexing the model file containing the model data to the first-level node, and indexing the parsed model data to the second-level or higher-level nodes according to its content.

[0015] In the above implementation, the metamodel's first-level nodes represent physical storage nodes, used to indicate the physical storage location of model files. Second-level and higher-level nodes represent logical nodes, used to indicate the logical storage location of model entities. By designing the metamodel as a tree structure, the logical relationships between different entities in the domain model can be expressed through the hierarchical relationships between nodes. This relationship is then preserved when storing the domain model's model data, providing a foundation for subsequent data integration and analysis.

[0016] In an implementation of the first aspect, indexing the parsed model data to the secondary or higher-level node according to its content includes: indexing the parsed model data to the secondary or higher-level node according to its content, the product development stage to which it belongs, and the historical version to which it belongs.

[0017] In the above implementation, when indexing model data, the product development stage and historical version information are also taken into consideration, thereby supporting the indexing of model data at different product development stages and different historical versions. This makes it easier to trace back to the data modification information at a specific development stage and a specific historical version based on the index information when a problem occurs with the product.

[0018] In an implementation of the first aspect, the method further includes: indexing the horizontal relationships between model data of different domain models.

[0019] In the above implementation method, it also supports indexing the horizontal relationships (rather than hierarchical relationships) between model data, so as to more comprehensively display the correlation between data and provide a basis for subsequent data integration and analysis.

[0020] In an implementation of the first aspect, after accessing the model data of the domain model according to the interface configuration, the method further includes: creating a data interaction service to provide access to the accessed model data and / or the interface interaction data formed after processing the model data.

[0021] In the above implementation, by publishing the model data and / or interface interaction data as a data interaction service, the data can be accessed externally, thereby meeting the data usage needs of users.

[0022] In an implementation of the first aspect, after the model data of the domain model is accessed according to the interface configuration, the method further includes: backfilling data to the domain system that obtained the model data by configuring a callback address, so that the domain system improves the model data according to the backfilled data.

[0023] In the above implementation, it not only supports accessing model data from the domain system, but also supports backfilling data to the domain system using the callback address, which is conducive to improving the model data in the domain system and enhancing data quality.

[0024] In an implementation of the first aspect, after obtaining the unified semantic model of the product to be developed, the method further includes: saving the unified semantic model to a graph database, and providing query capabilities based on the unified semantic model.

[0025] In the above implementation, since the unified semantic model is expressed based on triples consisting of entities, relationships, and facts, it can be regarded as a logical graph structure, and thus saved in a graph database, which is conducive to efficient query of information in the unified semantic model.

[0026] In a second aspect, an embodiment of the present application provides a data access device, comprising: a metamodel access unit for obtaining a metamodel of a product to be developed; wherein the metamodel includes at least a domain model for designing the product to be developed, entities included in each domain model, and the relationship between each entity; an interface configuration unit for determining an interface configuration corresponding to the domain model based on the metamodel; a data access unit for accessing model data of the domain model based on the interface configuration; a semantic model construction unit for instantiating the relationship in the metamodel based on the model data under the guidance of a unified semantic framework of the product to be developed to obtain a unified semantic model of the product to be developed; wherein the unified semantic framework includes at least elements, attributes, and relationships constituting the product to be developed, the unified semantic model includes at least a triple consisting of entities, relationships, and facts, the entities in the unified semantic model are obtained based on the merger of entities within each domain model, and the relationships in the unified semantic model include relationships between entities within each domain model, and relationships between entities of different domain models.

[0027] In a third aspect, an embodiment of the present application provides a computer program product, comprising computer program instructions, which, when read and executed by a processor, execute the method provided by the first aspect or any possible implementation of the first aspect.

[0028] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are read and run by a processor, the method provided by the first aspect or any possible implementation of the first aspect is executed.

[0029] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising: a memory and a processor, wherein the memory stores computer program instructions, and when the computer program instructions are read and run by the processor, the method provided in the first aspect or any possible implementation of the first aspect is executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0031] Figure 1 Shows the relationship between the digital thread and each domain model;

[0032] Figure 2The following illustrates a possible process of the data access method provided in an embodiment of the present application;

[0033] Figure 3 shows a schematic diagram of the data access process;

[0034] Figure 4 A compressed package containing a metamodel is shown;

[0035] Figure 5 It shows the possible logical structure of the metamodel;

[0036] Figure 6 It shows the process of instantiating relations in the metamodel;

[0037] Figure 7 The process of data indexing using the metamodel is shown;

[0038] Figure 8 shows the SysML view of the satellite's system model;

[0039] Figure 9 The three-dimensional structure of the satellite product model is shown;

[0040] Figure 10 shows the model flow view provided by the digital thread;

[0041] Figure 11 One of the interfaces of the domain interface configuration module of the digital main line is shown;

[0042] Figure 12 The second interface of the domain interface configuration module of the digital main line is shown;

[0043] Figure 13 The data mapping interface of the digital main line is shown;

[0044] Figure 14 The following shows the functional modules that may be included in the data access device provided in the embodiment of the present application;

[0045] Figure 15 The figure shows a possible structure of the electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings. It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0047] The terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0048] The terms "first," "second," etc. are only used to distinguish one entity or operation from another entity or operation, and are not to be understood as indicating or implying relative importance, nor are they to be understood as requiring or implying any actual relationship or order between these entities or operations.

[0049] During the development of complex industrial products (e.g., spacecraft, aircraft, automobiles, ships, robots, etc.), R&D engineers design domain models for different business areas to describe the characteristics of the product at different development stages. For example, domain models may include, but are not limited to, requirement models, system models, product models, and implementation models. These models may be defined as follows:

[0050] The requirement model is a model that describes user requirements and system / subsystem / stand-alone test requirements in an itemized and structured manner, supporting the entire requirement management process including requirement definition, decomposition, traceability, and analysis.

[0051] System models can be divided into system design models and system simulation models. System design models are graphical digital models that describe design states, including the generation and evolution of system requirements, system behavior, composition, internal and external interface relationships, information transmission methods / paths, parameter relationships, and their distribution and traceability. System design models are primarily constructed using the SysML language. System simulation models describe system functional performance and enable multidisciplinary integrated simulation verification of key aspects of a product's functional decomposition or operational processes. System simulation models are primarily constructed using the Modelica language.

[0052] The product model is used to describe the actual shape of the product. The product model can be a three-dimensional geometric model or a model obtained by three-dimensional subject simulation.

[0053] The implementation model can be a modified system model and / or product model, focusing on describing the specific technical details and methods in the actual construction and implementation process of the product or system.

[0054] However, these domain models have diversity and differences in model standards, data structures, software vendors, etc., resulting in scattered distribution and siloed management of product data, lack of global and unified data governance capabilities, and hindering data exchange and sharing between various business areas.

[0055] The present embodiments provide a digital mainline system (a software system, referred to as a digital mainline) that improves the aforementioned technical issues by implementing the data access methods provided in the present embodiments. It should be understood that the functionality of a digital mainline is not limited to data access; data access is only a portion of its functionality. Furthermore, the data access methods provided in the present embodiments are not limited to application within a digital mainline. The digital mainline is used as an example in the following text for ease of understanding.

[0056] In engineering practice, the digital thread is an extensible and configurable agent-based enterprise-level analytical framework. Based on the digital system model template, it seamlessly builds the controlled interaction of authoritative data, information and knowledge in the enterprise data system, thereby providing decision makers with the ability to access, integrate and transform different data into actionable information, and realize data source management throughout the system life cycle.

[0057] The digital thread has two main application levels in engineering fields such as aviation, aerospace, and automobiles: one is the means level, which uses the digital engineering ecosystem to build interactive relationships between methods, processes, tools, technologies, data, and people, build stable internal functional performance of the system and reliable external interactive relationships, and form solid and reliable equipment quality; the other is the data level, which horizontally forms a data network through the digital thread for activities at different stages of the life cycle, and vertically forms a model application network through the integration, interoperability, and combination of models.

[0058] The Digital Thread can be applied to the development of various complex industrial products. For ease of illustration, the following text uses the case of a spacecraft as an example. Examples of spacecraft include satellites, manned spacecraft, cargo spacecraft, space stations, space probes, and launch vehicles.

[0059] Specifically for this application, the digital thread enables access and association of model data for the four aforementioned domain models (requirement model, system model, product model, and implementation model). The digital thread parses model data, including text, SysML views, Modelica modules, interface data sheets (IDS), electronic data sheets (EDS), and 3D computer-aided design / computer-aided engineering (CAD / CAE) data, within the domain models. Based on the spacecraft-defined metamodel rules, the digital thread verifies and converts these data into the digital thread's standardized entity, relationship, and fact triples. The digital thread assists engineers in understanding the true state of the spacecraft and mastering vast amounts of product information. It also leverages validated relationships between models and upstream model data to automatically generate downstream models, supporting cross-disciplinary, cross-domain, and cross-system collaboration across upstream and downstream spacecraft development. This provides the foundation for a trusted data source for intuitive, efficient, and multi-dimensional visualization of the entire lifecycle.

[0060] Note that the terms "upstream model" or "downstream model" above refer to certain domain models. For example, in the case of the requirements model and system model, requirements drive system design, while system design in turn complements requirements. Therefore, requirements and design are mutually upstream and downstream, forming a cycle. Although the requirements model logically precedes the system model, in the actual development process, the order of priority is not always clear at different stages of development, hence the term upstream model and downstream model.

[0061] Figure 1 The relationship between the digital main line and each domain model provided by the embodiment of the present application is shown. Figure 1 The domain model is above the dotted line, and the digital thread is below it. The text, diagrams, and other information in the domain model represent the specific model data of the domain model. This data is connected to the digital thread, as indicated by the arrows. For example, the system design model can access model data including requirements information, functional information, interface information, SysML parameters, and related models.

[0062] Domain models are designed using independent software, such as requirements management (TRM) software, system modeling software (Magic), and 3D modeling (CAD) software. Although these models have causal relationships and influence each other in business, this correlation is not intuitively apparent. These software or the systems they reside in are also referred to as domain systems. After the digital thread accesses the model data of the domain model, it generates triples of relationship rules in the backend. These triples can be displayed through the UI, allowing engineers to intuitively see the rich connections between domain models.

[0063] Figure 2 The following shows a possible process of the data access method provided in the embodiment of the present application. Figure 2 , the method comprising:

[0064] Step S110: Obtain the meta-model of the product to be developed.

[0065] Products to be developed include spacecraft such as satellites and manned spacecraft. A metamodel is a model that includes at least the following information: the domain models used to design the products to be developed, the entities within each domain model, and the relationships between these entities. Specific examples of metamodels will be provided later.

[0066] Figure 3 Figure 2 shows a schematic diagram of the data access process. Figure 3 The two boxes on the left represent the exterior of the digital mainline, while the four boxes on the right represent the digital mainline. The metamodel of the product to be developed can be built using a dedicated language. The modeling results can include both an IDS data model and a Modelica data model. Once modeled, they are then integrated into the digital mainline. The boxes in the IDS data model represent IDS interface definition elements, while the circles in the Modelica data model represent interface functions for disciplines such as mechanical, thermal, and electromagnetic. Dark circles represent one discipline, while light circles represent another. The dotted line between the boxes and circles represents the mapping relationship between the two described in the metamodel. Figure 4 The figure shows a compressed package containing metamodels, such as mdzip data packets or files. The HL-2 metamodel refers to the metamodel corresponding to the HL-2 satellite (a product under development). The digital mainline can access the metamodel by accessing the mdzip package. The metamodel within the mdzip package can be in the form of a SysML diagram, for example, but can also include configuration files in other formats.

[0067] Figure 5 shows the possible logical structure of the metamodel. Figure 5 ,The meta-model can be logically viewed as a tree structure containing multiple levels of nodes.,Among them, the core nodes represent the products to be developed corresponding to the meta-model,,e.g. Figure 5 It is the core of the spacecraft metamodel. Metamodels also have different levels of abstraction. For example, the top-level metamodel can be for any product to be developed. After instantiating the metamodel with configuration information, it can be further converted into a spacecraft metamodel. After instantiating the spacecraft metamodel with configuration information, it can be further converted into a satellite metamodel or a spacecraft metamodel. After instantiating the satellite metamodel with configuration information, it can be further converted into the HL-1 metamodel or the HL-2 metamodel, and so on.

[0068] In the meta-model, the level of the node increases by 1 for each additional edge from the core node. Each level-one node in the meta-model corresponds to a type of domain model, for example, Figure 5 The demand model corresponds to a first-level node, the system model corresponds to a first-level node, and so on. The number of first-level nodes can be dynamically expanded according to the different stages of product development. Each second-level (or higher-level) node in the metamodel corresponds to an entity under a type of domain model, for example, Figure 5 The product model can further include a geometric model and a professional simulation model, that is, two entities. These two entities correspond to the two second-level nodes under the first-level node of the product model and are connected to the product model to express the subordinate relationship between these two models and the product model. Optionally, A and B are two nodes in the metamodel, A is a second-level (or higher-level) node under a first-level node A1, and B is a second-level (or higher-level) node under a first-level node B1. Nodes A and B can also be connected to express the relationship between entities A and B.

[0069] By designing the metamodel as a tree structure, it is helpful to express the logical relationship between different entities in the domain model through the hierarchical relationship between nodes, so that this relationship can be retained when storing the model data of the domain model, providing a basis for subsequent data integration and analysis.

[0070] Figure 5 The hierarchical metamodel structure is a logical structure, or it can be considered as the effect of intuitively displaying the metamodel. Figure 6 shows the instantiation process of relations in the metamodel, Figure 6 The meta-model in is expressed from the perspective of actual data organization. Figure 6 On the left is the Digital Mainline basic relationship metamodel, which is the metamodel at the top of the abstraction hierarchy mentioned above. This metamodel uses the From, To, Attr, and Type fields to express relationships between entities, but does not correspond to specific products:

[0071] From: indicates the starting point of the relationship, which can be an entity;

[0072] To: indicates the end point of the relationship, which can be an entity;

[0073] Attr: The attributes of the relationship, such as the specific top-level relationship, such as "has", "depends on", etc.

[0074] Type: The check type of the relationship, whether to check this relationship.

[0075] Based on the satellite configuration information, the digital main line basic relational metamodel can be instantiated into a satellite specific relational metamodel. For example, the digital main line basic relational metamodel is initially stored on the digital main line, and then accessed. Figure 4 The mdzip package of the HL No. 2 metamodel in the .mdzip package is used to instantiate the digital mainline basic relational metamodel into the HL No. 2 metamodel according to the configuration information in the mdzip package.

[0076] Continue to refer to Figure 6 In the satellite deterministic relational metamodel, the relationships in Attr have been instantiated into more specific relationships within the satellite product. For example, dependency relationships can be instantiated into satisfy and reference relationships. Both From and To refer to specific entities in the satellite development process, such as a requirement (Req), a function (Fun), or a logical component (Logical). Optionally, some relationships do not include a To field. For example, a structural plate on a satellite weighs 5 kg. This is a relationship in which 5 kg is not an entity but a value. This relationship is used to express a fact.

[0077] contrast Figure 5 and Figure 6 The metamodel in Figure 5 The nodes in can correspond to Figure 6 The entity in the From or To Figure 5 The edges between the nodes in can be mapped to Figure 6 The relationship between.

[0078] The above briefly introduces the concept of the metamodel of the product to be developed. More details about the metamodel will be further introduced in the subsequent steps of using the metamodel.

[0079] Depending on the product to be developed, there are different implementations of step S110. In one implementation, if the product to be developed is a mature product, the metamodel of the product to be developed can be obtained based on the metamodel of an existing product that is directly accessed.

[0080] For mature products, metamodels that have been built for similar products can be used directly or adjusted appropriately without completely rebuilding the metamodel. This can reduce the burden on engineers and improve the efficiency of subsequent data access.

[0081] For example, if Satellite 1 has been manufactured, Satellite 2 of the same model is manufactured. Although Satellite 2 may not be exactly the same as Satellite 1, the overall architecture is the same. Therefore, the metamodel of Satellite 2 can directly copy the metamodel of Satellite 1, or make a small adaptive modification based on the metamodel of Satellite 1.

[0082] In one implementation, if the product to be developed is a new product, the meta-model of the product to be developed may be obtained based on model data analysis of the domain model of the product to be developed.

[0083] For new products, there is no metamodel built for similar products before, and engineers may not know how to build the metamodel. In this case, you can first connect to some of the model data of the domain model (for information on connecting the model data of the domain model, please refer to the following steps), and then analyze the composition of this data to determine how to build the metamodel. This is because the metamodel is an abstract representation of these model data. Once the initial metamodel is built, it can be used to connect new model data, thereby iteratively optimizing the design of the metamodel and ultimately obtaining a more mature metamodel.

[0084] For example, if we are currently manufacturing a new model of Satellite 3, there is no existing metamodel available. However, two software packages each provide a requirements model. We can choose one of these to first access the model data from the requirements model, then parse this data to determine the structure of the metamodel. Once the metamodel is designed, we can then access the model data from the requirements model in the other software package.

[0085] Step S120: Determine the interface configuration corresponding to the domain model according to the meta-model.

[0086] Step S130: Accessing the model data of the domain model according to the interface configuration.

[0087] The above two steps are combined to explain how to import the model data of the domain model from the domain system to the digital main line. Figure 3 Data access in .

[0088] The model data of the domain model exists in the model file, and the model file exists in the domain system software. Each model file can include one or more domain models. In a simplified implementation, each model file can only include one domain model.

[0089] The digital backbone must connect to the software in the domain system to access the model files containing the domain model. The interface configuration describes the necessary information to obtain the model files from the interface provided by the domain system. The metamodel constrains the model data to be accessed. On the one hand, it restricts the data to be accessed, that is, the physical composition of the product to be developed at the data level, and on the other hand, it constrains how the product to be developed is composed of various data, that is, the logical relationships between the data. Based on the metamodel, the interface configuration corresponding to the domain model can be determined.

[0090] For example, the software used to access the model files for the requirements model may vary depending on the product being developed. For example, a spacecraft docks with TRM software, while a satellite docks with Magic software. Depending on the docking software, the file format and / or content may also differ. This correspondence between the spacecraft / satellite and the software is one of the elements of interface configuration. Other configurable elements include one or more items such as the domain system's interface address, interface request parameters, and the type of data returned by the interface.

[0091] For example, if you access a requirements model from TRM software, the interface configuration might result in a DLL (dynamic link library). At runtime, this DLL will POST (possibly HTTP POST) a request to the domain system. After receiving the returned data, it will POST another request, repeating this process several times to obtain the complete requirements model. If you access a requirements model from Magic software, the interface configuration might result in a DLL. At runtime, this DLL will initiate a file call to the domain system, receive the returned zip file, and then parse the file contents.

[0092] For example, the requirements in the requirements model can be layered, such as L1 to L7. If the requirements model is accessed from the TRM software, the model data is connected to the digital main line through the Uniform Resource Locator (URL) (the URL can be converted into an XML file). If the interface configuration includes L1, it means that the domain system needs to return the model data of the L1 layer requirements. If it includes L1 to L5, it means that the domain system needs to return the model data of the L1 to L5 layer requirements. Optionally, in the TRM software, L1 to L7 may be used to represent requirements, and in the metamodel, requirements are represented according to logical meaning. When configuring the interface, the requirement representation in the metamodel needs to be converted to the requirement representation in the TRM. For example, L1 corresponds to task requirements, L2 to L3 correspond to system requirements, L4 to L5 correspond to capability requirements, and so on.

[0093] If you access the demand model from the Magic software, the domain system will return a zip package. The digital mainline will need to parse the zip package to obtain the model data for the L1 layer requirements, or the model data for the L1 to L5 layer requirements.

[0094] Interface configuration can be achieved using a software module, called an interface configurator. The interface configurator can provide a configuration interface for engineers to configure the interface. Of course, it is not ruled out that the digital main line automatically performs all or part of the interface configuration.

[0095] Optional: Due to the extremely complex internal configuration of the Digital Mainline, interface configuration capabilities are typically not exposed to the outside world to prevent configuration errors from negatively impacting product development. However, sometimes engineers need to perform tasks such as remote testing that require interface configuration. Since there's no way to grant engineers low-level permissions to directly access the Digital Mainline backend for configuration, remote configuration permissions can be granted. This allows engineers to submit configuration information to the Digital Mainline via a URL or other method. The Digital Mainline can then read this information through the standard configuration port to generate the interface configuration.

[0096] After the interface configuration is completed, the digital main line only needs to call the interface provided by the domain system according to the interface configuration to obtain the model data of the domain system.

[0097] Optionally, after step S120, a callback address can be configured in the digital mainline. The digital mainline can use this callback address to backfill data to the domain system that obtained the model data, so that the domain system can improve the model data based on the backfilled data. The backfilled data can be model data modified by the digital mainline or model data that the original domain system does not have.

[0098] For example, the TRM software includes model data for L1 to L5 layer requirements, and the Magic software includes model data for L6 to L7 layer requirements. After the digital main line is connected to the model data of the TRM software and Magic software respectively, the digital main line confirms that the requirement model is complete. Therefore, the model data of the L6 to L7 layer requirements can be backfilled into the TRM software (which can be understood as the domain system here) through the pre-configured callback address, so that the TRM software also contains the model data of the complete requirement model, which facilitates the TRM software to generate corresponding reports (the reports generated by the digital main line itself may not meet the requirements).

[0099] It should be understood that the digital thread determines what data to backfill, and is not limited to the data completion case in the above example. For example, after accessing the model data, the digital thread can also return identification information of the accessed data to the domain system, so that the domain system knows which data has been connected to the digital thread and which data has not been connected to the digital thread, so as to perform corresponding processing and coordination.

[0100] This option not only supports accessing model data from the domain system but also supports backfilling data to the domain system using callback addresses. This enables bidirectional data flow, enhancing the interaction between the domain system and the digital backbone. For example, backfilling model data can improve model data in the domain system and enhance data quality.

[0101] Optionally, after step S120, the digital main line may also publish the received model data and / or the interface interaction data formed after processing the model data as a data interaction service, so that the data can be accessed outside the digital main line, thereby meeting the user's data usage needs.

[0102] For example, the digital main line is connected to the model data of the demand model. By creating interactive services, the model data can be published, allowing external parties to add, delete, modify, and query these data, as well as perform more complex operations, thereby making it easier for users to use the data.

[0103] Step S140: the received model data is parsed and rule-verified. If the verification passes, the parsed model data is distributedly indexed and stored according to the instructions of the meta-model.

[0104] When model data is indexed and stored, it is done according to the logical relationship indicated by the metamodel. Therefore, the parsing of model data is also done according to the structure of the metamodel, or in other words, the data corresponding to the nodes of the metamodel is parsed, so that the corresponding data can be indexed and stored according to the instructions of these nodes.

[0105] Rule validation is used to determine whether the parsed data meets the data access requirements. Rule validation can be performed after data parsing or during the data parsing process. For the latter, the rules used for data parsing and validation can be integrated.

[0106] For example, the meta-model includes task requirements, system requirements, and capability requirements nodes, which constrains the model data to include these three types of requirements. Assuming that the model data obtained now does not include capability requirements, this data missing should be verified through rule verification. This is one of the basic functions of rule verification.

[0107] Verification rules can be divided into two parts: one defined in the metamodel and the other defined in the digital thread (the software portion of the digital thread excluding the metamodel). For example, in the example above, the requirement data must fully include task requirements, system requirements, and capability requirements. This is a rule defined or implied in the metamodel. Another example is that when configuring an interface URL, it should begin with http instead of https. This rule is definitely not included in the metamodel and is a rule configured in the digital thread.

[0108] In practice, only rules on the digital mainline (such as low-code forms) can be executed. Rules in the metamodel may be diagrams (such as SysML diagrams) and cannot be executed directly. Therefore, all rules can also be defined on the digital mainline, but some of the rules in this case are actually equivalent forms of the rules in the metamodel, and their correctness can be verified using the semantic information in the metamodel.

[0109] The Digital Thread provides an environment for building, executing, and verifying rules. Rules in the Digital Thread are not hard-coded but hot-swappable, allowing rule modifications without code modifications or recompiling the Digital Thread. Engineers can manage rules like data, performing operations such as querying, adding, and updating.

[0110] Optionally, the above rules may include at least one of business rules, model rules, and data rules, supporting validation of model data from three dimensions: business, model, and data. This provides high flexibility, helps meet different validation requirements, and enables comprehensive data validation. The following introduces these three rules:

[0111] Business rules: rules determined based on business needs, such as checking whether a certain operation is performed at a specific time, or the order in which the demand model and business model are generated.

[0112] Model rules: These include checks on the connected model itself, such as checks on the operations that the model is expected to perform. For example, a normal battery must have charging and discharging functions, so the connected battery model is checked to ensure that these functions are included.

[0113] Data rules: include checks on accessed data. For example, if the value of a certain attribute of the model has a certain range, check whether the accessed attribute value is within this range.

[0114] Business rules can be defined in the digital thread, while model rules and data rules can be defined in the metamodel.

[0115] Optionally, each rule may further include one or more information such as business rule attributes, rule type, calculation formula, operation rules, constraint rules, and operation instructions. The following further describes this information:

[0116] Business rule attributes: one or more types of information such as rule code, name, status, and creation information;

[0117] Rule type: can be one of the following types: basic rule, detection rule, conditional rule, nested rule, loop rule, regular expression, etc.

[0118] Calculation formula: Executes the calculations involved in the rule, such as difference calculation to check whether it is within the indicator range, union calculation, maximum value calculation, etc.

[0119] Operation rules: how the rules are operated, for example, detecting whether a block (which can represent a battery) has a specified attribute entry, such as charging capacity;

[0120] Constraint rules: Constraints for rule execution, such as executing once every 24 hours or at a specified time;

[0121] Operation Description: Information about the execution of the rule, such as the person who executed the rule, the server where the rule was executed, etc.

[0122] Furthermore, the above rule types may include:

[0123] Basic rules: the most basic rules, such as format check, range check, association check, etc.

[0124] Detection rules: such as format matching, semantic matching, etc.;

[0125] Conditional rules: for example, whether a numerical range or logical expression is met;

[0126] Nested rules: several rules with nested relationships;

[0127] Loop rule: a rule that is executed cyclically;

[0128] Regular expressions.

[0129] The rules designed in the above manner have good adaptability and can be arbitrarily combined and migrated in different use cases and scenarios.

[0130] The digital backbone first performs rule verification on the accessed model data before indexing and storing it, which helps improve the quality and integrity of the accessed data, thereby improving the quality of the constructed unified semantic model.

[0131] The digital thread needs to maintain a global view of model data information. The digital thread first physically indexes the model files and then logically indexes the parsed content within them. Based on the logical information of the model data within all model files, it creates the system breakdown structure (also known as the system breakdown structure) of the product to be developed, which is the so-called global view. This global view can be maintained at the underlying layer of the digital thread and presented differently at the application layer. Users with different identities (for example, chief designers and ordinary engineers) may see different content.

[0132] The purpose of indexing model data is to establish the relationship between the domain model and the global view. Indexing maps model files, the domain models within them, and the specific information within them to nodes at different levels in the global view. The index points to the location of data at each node in the global view. However, the hierarchical relationships between nodes in the global view are constrained by the metamodel. Therefore, the process of building a global view is essentially the process of indexing and storing model data based on the metamodel. The collection of stored indexed data, combined with the metamodel's description of the relationships within the model data, constitutes the global view of the model data.

[0133] The distributed data publishing indexing mechanism is a technology used to improve data query and management efficiency in a distributed database environment. It establishes indexes across multiple nodes, enabling rapid data retrieval and efficient data management. In this mechanism, data is divided into multiple partitions or shards and distributed across different servers using a distributed database system. Each server is responsible for storing and processing a specific range of data. The data within each partition or shard is indexed to improve query efficiency. Indexes can be constructed based on specific fields, such as keywords and timestamps. When a user submits a query request, the distributed database system routes the request to the appropriate node based on the index, while also utilizing parallel processing to increase query speed.

[0134] Consistent hashing is a distributed hashing technology used to efficiently distribute and access data in dynamic environments. It is a distributed data publishing indexing mechanism. It works by mapping servers and data into a circular hash space (called a hash ring). This improves data storage uniformity. When the number of servers changes, only a small amount of data needs to be redistributed, reducing system disruption and overhead.

[0135] In consistent hashing, the hash ring is a virtual ring onto which servers and data are mapped. When data needs to be stored or retrieved, the system finds the closest server clockwise on the hash ring based on the data's hash value. For example, consider a system consisting of three servers (S1, S2, and S3). Their positions on the hash ring are as follows:

[0136] - S1: Position 30

[0137] - S2: Position 70

[0138] - S3: Position 150

[0139] Suppose there is a data item with a hash value of 120. We need to find the server closest to this data item in the clockwise direction on the hash ring: starting from 120 and searching clockwise, the next position of 120 in the clockwise direction is 150 (S3). Therefore, the data item will be assigned to server S3.

[0140] The Digital Thread uses a distributed index publishing mechanism to assign physical storage nodes to the first-level nodes of the metamodel. Thus, the first-level nodes of the metamodel represent physical nodes, while the second-level and higher-level nodes of the metamodel represent logical nodes. The Digital Thread selects a primary key for the data and indexes the data using mechanisms such as consistent hashing:

[0141] (1) For the model file containing the model data, the digital mainline indexes it to the first-level node of the metamodel. The specific approach is: calculate the hash value of the model file according to the consistent hashing mechanism, and map the model file to the physical node closest to it on the hash ring in a clockwise direction according to the hash value for physical storage.

[0142] Reference Figure 5 The circle containing the word "model" represents the model file, and its storage location is determined in the clockwise direction of the hash ring. In order to ensure that each model is stored on the physical node represented by the first-level node corresponding to its own type as much as possible, only one domain model can be included in each model file. The first-level nodes in the metamodel can be generated dynamically. For example, in the early stages of product development, there are only two first-level nodes, the requirements model and the system model, and the product model node has not yet been generated. In this case, even if a model file belongs to the product model, it can only be stored on the system model node first.

[0143] (2) The parsed model data is determined by the digital main line according to its content (obtained through model data parsing) to which the secondary or higher-level node it belongs, and the model data is indexed to the node to which it belongs. For example, referring to Figure 5 ,For the indicator data under the demand model, it can be indexed to the indicator node (secondary node) under the demand model node (first-level node).

[0144] Optionally, consistent hashing can be used to index model data belonging to second-level nodes (of course, the hash ring represents logical nodes, not physical nodes). For model data belonging to third-level nodes or higher, a prefix binary tree (PBT) and pyramid technology, using the subsystem-standalone prefix, can be used to construct a multidimensional data index. These indexing mechanisms are merely examples; other distributed indexing mechanisms are also possible.

[0145] Optionally, the digital backbone can also utilize the dynamic maintenance function of data indexes to ensure load balancing of data distribution.

[0146] It should be noted that the ownership of the above model data refers to logical ownership rather than physical ownership. For example, it is possible that a certain model file is a system model and is stored on the physical node represented by the system model node (first-level node) in the meta-model. However, some of the model data in the model file is requirement data. In this case, these requirement data can be indexed into the sub-nodes under the requirement model node (first-level node), that is, the locations of the logical node and the physical node may not be together. The possible reason for this phenomenon is that in the early stages of product development, there may only be a text description of a certain requirement in the requirement model. Only in the system development stage will a modeling language description be formed for the requirement, resulting in the requirement data appearing in the model file of the system model. However, whether it is a text description or a modeling language description, both are actually for the same requirement. Therefore, when indexing data, they can be unified under the same logical node.

[0147] Furthermore, the digital thread can index parsed model data to secondary or higher-level nodes based on its content, product development stage, and historical version. That is, when indexing model data, the digital thread considers not only its ownership but also the product development stage and historical version. This allows for indexing model data from different product development stages and historical versions. This facilitates tracing data modifications to a specific development stage and historical version based on the index information when product issues arise.

[0148] For example, the index information of the model data may include three parts: the first part is the index itself, the second part is an ID of the development stage of the product to which the model data belongs, and the third part is an ID of the historical version to which the model data belongs.

[0149] Development phases include outline design, detailed design, testing, and optimization. Outline design is further divided into sub-phases such as requirements analysis, system design, and system verification. For example, the string ZCSD can be used to represent a development phase, where Z represents formal design, C represents outline design, and SD represents system design. To conserve data, various character combinations can also be replaced with a single number (index value).

[0150] Each historical version can correspond to one or a batch of modification behaviors of the model data. For example, version numbers such as V1.02 and V1.03 can represent historical versions.

[0151] For model data with such index information, when querying, you can first find the node where the data is located in the meta-model through the index itself, and then find the data of a specific development stage and a specific historical version based on the product development stage and historical version information.

[0152] Adding product development phase and historical version information to the index doesn't solve the data storage problem. If that were the case, a simple hash value would suffice. The purpose of adding these two pieces of information is to understand at which stage and by whom the data was modified, making it easier to trace issues. Of course, when displaying data, the latest version or data from the latest development phase can be prioritized.

[0153] (3) For the model data of different domain models, the data mainline can also index the horizontal relationships (rather than hierarchical relationships) between them. This helps to more comprehensively display the correlation between data and provides a basis for subsequent data integration and analysis. Of course, the horizontal relationship here may exist in the model data of the domain model, or it may not be formed until step S150 is executed.

[0154] Figure 7 The process of using the metamodel to index data is shown. Figure 7 , the system requirement structure and system test structure on the left are the model data in the TRM software, and the right is the meta-model of the FC system (spacecraft system). For simplicity, Figure 7 Only the first-level node of the system model is shown, and the second-level nodes are omitted. The first-level nodes are directly connected to the third-level nodes. Figure 7 The instance data mounting in the figure is to index the model data into the node of the meta-model, and the "tracking" arrows on the left can be considered as the horizontal relationships between the model data. These relationships can also be indexed so that they can be queried by users.

[0155] Because distributed indexing technology is used to store model data, engineers can locate data by routing through only a few nodes without having to traverse nodes when querying data (for example, through the data interaction service mentioned above). This improves data access speed and supports the processing of massive amounts of data. Distributed indexing also facilitates more even data storage, effectively avoiding problems such as excessive server load and single points of failure, and improving the reliability and scalability of the storage system. Furthermore, because data indexing is performed under the guidance of the metamodel, it helps preserve the logical relationships between model data.

[0156] Step S140 is an optional step. If you can ensure that the model data of the domain model is complete and correct in advance, you can also not perform rule verification on the accessed model data. If you do not care about the query efficiency of the data, you can also not index the accessed model data.

[0157] Step S150: Based on the model data, the relationships in the meta-model are instantiated under the guidance of the unified semantic framework of the product to be developed, so as to obtain a unified semantic model of the product to be developed.

[0158] The model data in step S150 may be indexed and stored model data.

[0159] First, a unified semantic framework for the product to be developed needs to be defined in the digital backbone. This unified semantic framework includes at least the elements, attributes, and relationships that constitute the product to be developed. For example, within the unified semantic framework, an ontology for the spacecraft domain (such as satellites) can be created to define spacecraft elements (such as solar panels, antennas, batteries, etc.), attributes (such as size and weight), and relationships (such as connections and inclusions). In simple terms, the unified semantic framework describes the intended appearance of the product to be developed.

[0160] Then, semantic information of each domain model is extracted based on the model data. This can be accomplished by parsing and processing the model data of the domain model. For example, natural language processing can be performed on the textual requirements model to extract user requirements and design goals; graphical parsing can be performed on the graphical system model to extract information such as blocks, activities, and attributes defined in the view; and geometric feature extraction can be performed on the 3D product model to obtain the 3D structure and material information of the spacecraft.

[0161] The extracted semantic information is then mapped to a unified semantic framework. For example, the requirements items in the requirements model are mapped to the design goal concepts in the ontology; the spacecraft component architecture in the system model is mapped to the spacecraft logical entities (belonging to elements) and their attributes in the ontology; the geometric features in the 3D model are mapped to the physical entities (belonging to elements) and their attributes in the ontology, and so on.

[0162] Finally, the mapped semantic information is organized into a graph structure (for example, using SysML modeling tools) to form a unified semantic model of the product to be developed. This unified semantic model includes at least triples consisting of entities, relationships, and facts. These triples represent a unified representation of the various relationships within and between domain models.

[0163] The entities in the triples of the unified semantic model are the result of merging entities within each domain model. For example, entities unique to each domain model can be retained in the unified semantic model; entities in different domain models that refer to the same physical object can be merged into one and retained in the unified semantic model, or they can remain separate and unmerged. In other words, there can be specific strategies for merging entities within domain models.

[0164] The relationships within the triples of the unified semantic model include relationships between entities within each domain model (internal relationships within the domain model), as well as relationships between entities in different domain models (cross-domain model relationships). Internal relationships within domain models are expressed in the metamodel, instantiating the model data of the domain models accessed within the unified semantic model. Cross-domain model relationships may not be present in the metamodel (although some may exist). However, they can be constructed using relationships within the unified semantic framework.

[0165] For example, refer to Figure 6 Requirements, functions, logical components, and physical components are entities, while satisfaction and reference are relationships. Specific values ​​(for example, weight) are facts, which are typically expressed using parameters, performance, and indicators. These concepts are similar in the metamodel, but the metamodel is merely an abstract expression. Using specific model data, the metamodel's relationships are instantiated (of course, the entities and facts associated with these relationships are also instantiated). The resulting unified semantic model is then achieved.

[0166] The nodes in the graph structure above correspond to entities or facts in the unified semantic model, while the edges between nodes correspond to relationships in the unified semantic model. The unified semantic framework is primarily used to construct relationships across domain models. For example, a three-dimensional product model and a graphical system model are two independent models. By mapping them simultaneously to the unified semantic framework, the relationship between the two models can be expressed as triples, using the unified semantic framework as an intermediary. Of course, relationships already contained within the domain model can also be retained in the unified semantic model.

[0167] The following is a more specific example to illustrate the construction process of triples in the unified semantic model:

[0168] In the case where the product to be developed is a satellite, the requirements model uses words to describe the satellite's capabilities: the satellite can convert sunlight into electrical energy for use by the satellite body;

[0169] The system model uses SysML views to express satellite components, such as Figure 8 As shown;

[0170] The product model uses three-dimensional structure and finite element model to express the satellite components, such as Figure 9 shown.

[0171] The above three types of independent domain models have great differences in expression. The contents of these models should be associated and unified through a unified semantic model.

[0172] During the model data parsing phase, the digital thread identifies the content and parameters of the requirements model, SysML model, and 3D model based on the satellite semantic description. During the model data verification phase, the digital thread first uses rules to check the model content and parameter categories (e.g., Req, Fun, Logical, Physical), and then verifies the logical connections (e.g., From, To).

[0173] Items in the requirements model, blocks in SysML, and components in a 3D model are referred to as nodes in the domain model. Each node is further divided into multiple items, centered around the model's underlying structure, its main framework, and its primary structure. These items are referred to as the model's content, and each content item has corresponding parameters. Therefore, the aforementioned content and parameters refer to what is contained at the next level after expanding a model node (e.g., an item), such as capability requirements, functional requirements, and system requirements within the requirements model. Different satellites have different levels of expansion, and the exact amount of content included is defined by the satellite's metamodel. For example, for a functional requirement, the number "3" is a parameter: the manned spacecraft has a capacity of three people.

[0174] Finally, the digital thread checks, reorganizes, and / or confirms the specific relationships between each model item and parameter based on the combination rules (i.e., a combination of business rules, model rules, and data rules), combined with the previously obtained classifications and contextual relationships, i.e., the triples in the unified semantic model. The confirmation process may rely on the satellite's unified semantic framework. For example:

[0175] (1) From: Solar panel Fun in SysML, Relationship: Refinement, To: Energy conversion requirement Req in the requirement document

[0176] In SysML, the solar panel Fun is a third-level node under the system function (second-level node) under the system model (first-level node). The energy conversion requirement Req in the requirements document is a third-level node under the capability requirement (second-level node) under the requirements model (first-level node). The relationship between these two third-level nodes is expressed using refinement, which instantiates the relationship between the two third-level nodes in the metamodel. Because the system model and the requirements model are different domain models, refining this relationship requires the use of a unified semantic framework.

[0177] For example, with triple (1), future queries on energy conversion requirements will be reversed to find the function of solar panels Fun to be refined.

[0178] (2) From: Solar Panel Physical in 3D Model, Relationship: Implementation, To: Solar Panel Logical in SysML

[0179] The process of determining triple (2) can be referred to as (1) and will not be analyzed in detail. For example, after having triple (2), if the length of the solar panel in the 3D model is modified in the future, for example, from 4 meters to 3 meters, and you want to know whether it is appropriate to change to 3 meters, you should first query the relevant content in the upper layer to see if it needs to be adaptively modified. For example, based on the above implementation relationship, you can query what the solar panel Logical in SysML is like, and in this way, determine the scope affected by the length modification layer by layer.

[0180] Furthermore, some triples may not exist in the metamodel, but can be reconstructed or inferred based on existing relationships. For example, text from a requirement document can be imported into SysML to form a requirement diagram in SysML. Then, an ACT view can be used in SysML to describe a function (Fun) in the requirement diagram. When constructing a triple, the relationship between the requirement document and the requirement diagram is first checked, followed by the relationship between the requirement diagram and the ACT, and finally the relationship between the ACT and the requirement document. Initially, the relationship between the text and the requirement diagram and the ACT and the requirement document may not exist, leaving only the relationship between the requirement diagram and the ACT. Based on the relationship between the text and the requirement diagram in the metamodel, the relationship between the text and the requirement diagram in the triple is instantiated. With the relationship between the text and the requirement diagram and the relationship between the requirement diagram and the ACT, the combination of relationships can confirm that the relationship between the ACT and the text also exists.

[0181] Refer again Figure 6 , the "specific relational data" on the right is the triple obtained after instantiation, and the set of these triples constitutes a unified semantic model. Figure 6 Below, the defined relationships in the digital thread can refer to the relationships defined in the unified semantic framework. These relationships are explicit. In addition, there are some implicit or undefined types of relationships, such as the relationships implicitly expressed in the structure diagram of the domain model. These relationships can also be identified and ultimately form triples.

[0182] Each triple in the unified semantic model may exist independently, but may also be related. For example, the tail of one triple may be the head of another triple. After the triple is constructed, subsequent applications can be based on it.

[0183] For example, a user might want to know the total weight of a satellite. Based on the satellite's compositional relationships, they can determine its components. Each component has a weight attribute. The SysML view then defines the total weight as the sum of all component weights. After aggregating this information, the total weight can be calculated by adding up all component weights. This is the triple-based query reasoning process.

[0184] For example, there is a requirement that the total weight of the satellite does not exceed 450kg. A certain rule monitors the most important core indicators once a day at 0:00 to see the progress of the day. For example, if a component increases from 10kg to 12kg, after calculation, it is found that the total weight of the satellite is overweight. Combined with some constraints, the weight influence chain is determined and pushed to the designer to tell the designer which design caused the overweight.

[0185] The Digital Thread provides four views of the domain model:

[0186] (1) Model flow view, which represents the model flow in the digital main line;

[0187] (2) Tool selection view, which defines the tools corresponding to the design tasks and development models in the model flow view;

[0188] (3) Tool evaluation diagram, which defines the indicators and evaluation parameters of the tools used;

[0189] (4) Tool chain structure diagram, defining the tool elements and connection relationships in the tool chain.

[0190] in, Figure 10 Shown is the model flow view provided by the digital thread.

[0191] The following mainly explains the model flow view, which actually expresses the relationship between the model data of the domain model presented by the unified semantic model. Figure 10 Different domains represent different domain models. Below each domain are the content, parameters, and other information within the domain model. Dashed arrows represent relationships. There are two types of relationships: those automatically established by the Digital Thread and those manually established by engineers. The act of establishing a relationship is represented by a solid arrow. Furthermore, dashed arrows reflect the flow of data.

[0192] Optionally, click Figure 10 Click the arrow in the middle to view and edit the established triples.

[0193] Optionally, the Digital Thread can save the constructed unified semantic model to a graph database, providing query capabilities based on the unified semantic model. Because the unified semantic model is expressed based on triples consisting of entities, relationships, and facts, it can be viewed as a logical graph structure. Saving it in a graph database facilitates efficient querying of information in the unified semantic model.

[0194] For example, refer to Figure 3 , using the graph database Neo4j to save the unified semantic model (saved as a graph structure, such as Figure 3 As shown in the figure), the application layer can provide data query, reasoning and other functions (i.e., global tracing in the figure).

[0195] The following is a brief summary Figure 2 The method in [1] first uses the metamodel of the product to be developed to describe each domain model, the entities within each domain model, and the relationships between these entities. It then accesses the specific model data of the domain models and uses this data to instantiate the relationships in the metamodel, resulting in a unified semantic model for the product to be developed. This achieves unified description and standardized management of model data from different domain models.

[0196] Moreover, the unified semantic model fully explores and integrates the relationships between entities in the domain model, thereby assisting R&D engineers in obtaining the true status of the product to be developed and mastering massive amounts of product information. It can also automatically generate downstream models using the confirmed relationships between domain models and upstream model data, thereby supporting cross-disciplinary, cross-domain, and cross-system upstream and downstream product development data collaboration, laying the foundation for a trusted data source for subsequent intuitive, efficient, and multi-dimensional global visualization of the entire life cycle.

[0197] Based on the above embodiments, more details of the digital main line in data access are introduced below from the implementation level.

[0198] To implement data access for domain models, the digital thread can include, but is not limited to, the following modules:

[0199] (1) Domain interface configuration module (corresponding to the interface configurator mentioned above)

[0200] The Domain Interface Configuration module is the core of the Digital Mainline's access to data from multiple complex business systems. It is primarily responsible for configuring interfaces with various domain systems to ensure flexible and accurate access to required data. The Domain Interface Configuration module primarily includes the following functions:

[0201] A. Interface definition:

[0202] A1. Interface URL Definition: A URL is a necessary element for the digital thread to access various domain systems. By specifying a specific URL, the digital thread can accurately locate and access the corresponding business system interface to achieve data interaction.

[0203] A2. Open Services for Lifecycle Collaboration (OSLC) Standard or Non-OSLC Standard Interface Definition: OSLC is a set of technical specifications proposed by IBM, primarily used to address the integration of lifecycle tools. Its core concept is to link data, identifying objects through HTTP URLs, allowing users to request useful information expressed in a standard format, and supporting links between objects, enabling users to discover more information.

[0204] A3. Interface Request Type Definition: This covers common interface types such as HTTP GET, HTTP POST, WebService GET, and WebService POST. HTTP GET and POST are common HTTP request methods. GET is typically used to retrieve resources, with request parameters included in the URL, while POST is used to submit data, with request parameters in the request body. WebService GET and POST are corresponding request types within the WebService architecture. WebService is an XML-based web service that communicates over the HTTP protocol. GET and POST are also used to retrieve and submit data, respectively. Clarifying the interface request type helps determine the method and process for data interaction.

[0205] A4. Interface Address Definition: These addresses are interfaces used by domain systems to obtain data. They are not controlled by the digital mainline system, but interface requirements can be provided to these domain systems to ensure they meet the requirements of the digital mainline.

[0206] A5. Interface request parameter definition: Set interface request parameters based on the domain system interface requirements. These parameters are the information that needs to be passed when the interface is called. They are used to specify specific operations or data filtering conditions, etc., to ensure that the interface can accurately return the required data based on the request parameters.

[0207] A6. Interface data type definitions: These include XML, JSON, and other standard formats. These lightweight data exchange formats are easy to read and write, and also facilitate machine parsing and generation. The definition of the interface return data type varies depending on the format, so it is important to clearly define the interface data type to ensure correct data parsing and processing.

[0208] Figure 11 Figure 1 shows one of the interfaces of the domain interface configuration module of the digital mainline. Figure 11 , the figure shows a configuration example of the various contents in the above-mentioned interface definition.

[0209] B. Definition of general interface parsing rules

[0210] Model data based on the domain model defines parsing rules (including verification rules) in the digital mainline, covering constraint rules, basic rules, detection rules, conditional rules, nested rules, and loop rules. Figure 12 The second interface of the domain interface configuration module of the digital main line is shown. Figure 12 These parsing rules are closely related to the definition of the interface return, such as checking the returned data by identifying the type and identity, including detection rules and conditional rules; establishing nesting rules and loop rules of different levels between data in the structural relationship definition in the form of different identifiers, etc.

[0211] The digital mainline can create various indexes based on the data returned by the interface (after parsing and verification), including data indexes for object data (requirement items, logical devices, indicator parameters, etc.), indexes for structural relationships (for example, requirements under requirement specifications, sub-requirements under requirements), and indexes for horizontal relationships (requirement items-functions-logical devices). These indexes are the basis for building cross-domain model data indexes.

[0212] Specifically reflected in:

[0213] B1. Interface Return Data Type Definition: Based on different return data format standards, define the data index for the object data in the returned data. This index must be created based on the meaning of the data returned by different business systems and contain the necessary unique key value. This index is used for data index lookup using a hashing mechanism. This method enables rapid location and retrieval of specific data elements or objects, improving data processing efficiency. This index is an index into the model data itself (corresponding to a node in the metamodel).

[0214] B2. Definition of Structural Relationships Returned by Interfaces: Based on the data format standards returned by different interfaces, define the structural relationship index of each data index in the original domain system. Similarly, use the unique key as the key for subsequent data lookup. This helps accurately understand and restore the relationships between data when processing complex data structures, providing a foundation for subsequent data integration and analysis. This index represents the hierarchical relationship between model data (corresponding to the hierarchical relationship between nodes in the metamodel).

[0215] B3. Interface Return Horizontal Relationship Definition: Similar to the interface return structural relationship definition, some domain systems contain horizontal relationships between different types of data. Defining data indexes for model data horizontal relationships in this way allows for a more comprehensive presentation of data associations and supports the establishment of complete data traceability relationships. This index represents the horizontal relationships between model data (corresponding to the horizontal relationships between nodes in the metamodel).

[0216] Continue to refer to Figure 12 , Figure 12 It shows a configuration example of the above-mentioned interface return data type definition, interface return structural relationship definition, and interface return horizontal relationship definition.

[0217] C. Auxiliary Processor Definition

[0218] C1. Pre-processing program: Due to the format and differences of the data returned by the original domain system interface, it may not meet the standards for obtaining data through the digital main line. Therefore, a corresponding pre-processing program must be written in the digital main line to filter and integrate the data obtained through the interface. Figure 11 Here, you only need to select the method name of the front-end module. Through the processing of the front-end module, you can convert non-standard data into a format acceptable to the digital main line system, ensuring the accuracy and integrity of data access.

[0219] For example, the digital main line requires that systems in various fields provide authoritative and controlled data, but the interface of a certain system does not meet the requirements. In this case, a front-end module program needs to be written to filter out uncontrolled data. Alternatively, the attribute fields of a certain field system interface are incomplete, and the field information needs to be supplemented through a front-end module program.

[0220] It should be understood that when the data returned by the interface fully meets the standard requirements of the digital main line for data, there is no need to write or select the front-end module program.

[0221] C2. Post-processing program: Based on the connected model data, define the established business data relationship rule script, and establish the traceability relationship of domain data according to a certain relationship rule in the post-processing module. By further processing and handling the data, the business logic and relationship behind the data can be mined. Figure 11 , you can also select the method name of the post-module on the interface.

[0222] For example, the equipment designed subsequently has a satisfaction relationship with the requirements proposed in the early stage, and the functional points generated by functional decomposition have an allocation relationship with the specific implementation equipment or components. These relationships will establish traceability relationships in the script through rules such as consistent numbering or similarity between two attribute fields, providing more valuable information for subsequent data analysis and decision-making.

[0223] It should be understood that when the data returned by the interface does not need to establish a traceability relationship with data in other fields, there is no need to write or select the relationship rule script of the post-module.

[0224] C3. Callback Functionality: Based on the method agreed upon between the Digital Mainline and the domain system, if a callback is required (the Digital Mainline calls back to the domain system), the interface callback address is entered. This callback address transmits the acquired data index to the original domain system, which then marks which data has been accessed and which has not. This method enables two-way feedback on data interaction, allowing the original domain system to promptly understand the status of data acquisition, facilitating appropriate processing and coordination. Furthermore, previously unavailable model data can be backfilled to the original domain system, as explained above.

[0225] It should be understood that the callback function is not required by all domain systems, so it is optional and an independent function. Figure 11 , below the domain interface address, you can also fill in the interface callback address.

[0226] (2) Data unified semantic conversion module (corresponding to the manual construction of some triples in the previous article)

[0227] Although the generic parsing capabilities in the domain interface configuration have been used to convert the model data in the domain system into data indexes, this still fails to meet the requirement for a unified representation of heterogeneous data in the digital thread. It is necessary to map the index data objects to the data model (i.e., the unified semantic model) in the digital thread system, completing the conversion of the parsed domain model data by separately listing the defined index data object types and the various business data models constructed by the modeling engine in the digital thread. Optionally, this business data model can be stored in a relational database table format, encompassing the entity classes, attribute fields, internal and external primary keys, etc. of the data model. Data models defined in this manner are collectively referred to as the standard semantic representation format in the digital thread.

[0228] like Figure 13 As shown in the table, it is divided into two columns, where the index data object is constantly listed on the left. The data model in the system is selected through the drop-down list to map it. After the type mapping is completed, the field mapping under the type is performed. Click the "Attribute Field Mapping" button. Similarly, the attribute fields of the index data object are constantly listed on the left, and the attribute fields of each data model in the digital main line are mapped through the drop-down selection on the right. After the mapping is completed, the data format is expressed in the standard semantics of the system. The defined index data object type is mapped to the data model expressed in the standard semantics of the system, including the mapping of type and attribute fields. After the data type and attribute field are mapped, the unique key value judgment condition of a business data object is determined.

[0229] Note that this mapping operation is fundamentally different from the post-module. The post-module program needs to be executed after the mapping conversion of the domain model data is completed.

[0230] (3) Data instantiation and storage module

[0231] The mapped and transformed model data serves as business object data in the digital thread and is stored as elements in relational database tables. Given the digital thread's need for efficient querying of data traceability relationships, queries within the original relational database tables—for example, when querying business objects and relationships across requirement items, functions, and logical devices—often require multiple internal and external primary keys and separate tables. This presents no performance issues when the data volume is small. However, the digital thread itself integrates data from multiple business domains, encompassing an extremely large number of business objects and relationships. Continuing to use the original relational database for query performance is slow and significantly depletes computer performance. Graph databases naturally store all business object data and relationships as nodes and edges, and, combined with graph theory, offer inherent advantages in query performance and efficiency when dealing with large data volumes. Therefore, graph databases are used to store the relationships between domain data. The post-processing module relies on the graph database to establish traceability relationships between data from different domains.

[0232] Since the relevant technologies of relational databases (such as transaction processing, hot backup, distributed deployment, etc.) are already very mature, but the technology of graph databases is still under exploration and research, the technology is not particularly mature. In addition, given the extremely high security requirements for business data itself in engineering applications, the use of immature technologies will be very risky. Therefore, a copy of the object data can be retained in the relational database for timely backup and recovery.

[0233] Based on the above embodiment, a possible data access process of the digital main line is given below:

[0234] Step 1: Obtaining raw data

[0235] Based on the interface configuration, the digital main line obtains original business data (model data of the domain model) from the business domain system through HTTP requests or WebService. The original business data contains the metadata of each domain data.

[0236] The digital mainline records request logs, including request time, request address, request parameters, response status, and other information for subsequent tracking and troubleshooting.

[0237] Step 2: Pre-module processing (optional)

[0238] In response to the digital main line's requirements for data in different fields, after the original business data is directly obtained through the interface, it is filtered and processed using the front-end module program to obtain business data that can be used for analysis and conversion.

[0239] Step 3: General parsing transformation

[0240] Apply the general parsing rules in the interface configuration to parse and verify the original business data (or pre-processed business data). Convert the parsed data into an index data format recognizable by the digital mainline to ensure data accuracy.

[0241] The digital mainline records the parsing log, including parsing time, parsing results, error messages, and other information for subsequent analysis and optimization.

[0242] Step 4: Data unified semantic conversion

[0243] The digital thread maps index data to a data model with standard semantic expression in the digital thread system (a unified semantic model), achieving unified expression of heterogeneous data and ensuring seamless integration of data from systems in different business domains. This process can be completed manually with a combination of programs.

[0244] Step 5: Instantiate and store domain data

[0245] The unified semantic model data is stored in a relational database, creating business object data but not relationships. The relationships of the original domain data are stored in CSV files, which record the source (From) and destination (To) of the relationships. The source and destination identifiers here must be based on the unique code of each data entity in the relational database.

[0246] Step 6: Graph Data Synchronization

[0247] Using the Kafka mechanism, the standard semantic object data instantiated in Step 5 is seamlessly synchronized from the relational database to the graph database, ensuring efficient and reliable data synchronization between the relational database and the graph database. Seamless synchronization means that the relational database and the graph database are automatically synchronized, and external interfaces view the two databases as consistent and mutually trusted.

[0248] After synchronizing business object data, the relational data stored in the CSV file is parsed according to established rules and generated into a graph database. Leveraging the graph database's graphical representation and efficient query capabilities, rapid data access and analysis is achieved.

[0249] In different implementations, you can implement only step 5 and not step 6, with subsequent data queries performed based on the relational database. Alternatively, you can directly save the model data (including relations) converted in step 4 into a graph database without using a relational database.

[0250] Step 6: Post-module processing (optional)

[0251] After completing the operation of entering data into the graph, the relationships between the data in each field need to be established, and the relationship rule script provided by the post-module (which can be written in Python) is executed. After the relationship mining is completed, it is generated into the graph database.

[0252] Optionally, throughout the entire data access process, the digital backbone can establish exception handling and monitoring mechanisms to ensure stable data access and efficient processing.

[0253] Exception handling: Capture and handle request failures, parsing errors, storage exceptions, etc. Record exception information and provide corresponding error prompts and solutions.

[0254] Monitoring and Alarming: Through log analysis and performance monitoring, we monitor the status and performance of data access processes in real time. When anomalies or performance bottlenecks occur, we trigger alarms and take appropriate measures.

[0255] Through the above process, data is accessed from multiple complex business systems, providing complete, accurate, and consistent business instance data for the digital thread.

[0256] Figure 14 The data access device 200 provided in the embodiment of the present application may include functional units. Figure 14 , the data access device 200 includes:

[0257] The metamodel access unit 210 is configured to obtain a metamodel of the product to be developed; wherein the metamodel includes at least a domain model for designing the product to be developed, entities included in each domain model, and relationships between entities;

[0258] An interface configuration unit 220, configured to determine an interface configuration corresponding to the domain model according to the metamodel;

[0259] A data access unit 230, configured to access the model data of the domain model according to the interface configuration;

[0260] The semantic model construction unit 240 is used to instantiate the relationships in the meta-model based on the model data under the guidance of the unified semantic framework of the product to be developed, so as to obtain a unified semantic model of the product to be developed; wherein the unified semantic framework at least includes the elements, attributes and relationships that constitute the product to be developed, and the unified semantic model at least includes a triple consisting of entities, relationships and facts. The entities in the unified semantic model are obtained based on the merger of entities within each domain model, and the relationships in the unified semantic model include the relationships between entities within each domain model and the relationships between entities of different domain models.

[0261] In one implementation of the data access device 200, if the product to be developed is a mature product, the metamodel of the product to be developed is obtained based on the metamodel of an existing product that is directly accessed; if the product to be developed is a new product, the metamodel of the product to be developed is obtained based on model data analysis of the domain model of the product to be developed.

[0262] In one implementation of the data access device 200, the device also includes: a rule verification unit, which is used to parse and verify the rules of the accessed model data after the interface configuration unit 220 accesses the model data of the domain model; and a data indexing unit, which is used to distribute index and store the parsed model data according to the instructions of the meta-model after the parsed model data passes the verification.

[0263] In an implementation of the data access device 200 , the rule includes at least one of a business rule, a model rule, and a data rule.

[0264] In one implementation of the data access device 200, the meta-model includes multiple levels of nodes, wherein the first-level nodes represent physical storage nodes, each first-level node corresponds to a type of domain model, and the second-level or higher-level nodes represent logical nodes, each second-level or higher-level node corresponds to an entity under a type of domain model; the data indexing unit performs distributed indexing on the parsed model data according to the instructions of the meta-model, including: indexing the model file where the model data is located to the first-level node, and indexing the parsed model data to the second-level or higher-level nodes according to its content.

[0265] In one implementation of the data access device 200, the data indexing unit indexes the parsed model data to the secondary or higher-level node according to its content, including: indexing the parsed model data to the secondary or higher-level node according to its content, the product development stage to which it belongs, and the historical version to which it belongs.

[0266] In one implementation of the data access device 200 , the data indexing unit is further configured to index the horizontal relationships between the model data of different domain models.

[0267] In one implementation of the data access device 200, the device also includes: a service creation unit, which is used to create a data interaction service after the data access unit 230 accesses the model data of the domain model according to the interface configuration, and provides access to the accessed model data and / or the interface interaction data formed after processing the model data.

[0268] In one implementation of the data access device 200, the device also includes: a data backfilling unit, which is used to configure a callback address and use a callback function to backfill data to the domain system that obtains the model data after the data access unit 230 accesses the model data of the domain model according to the interface configuration, so that the domain system can improve the model data according to the backfilled data.

[0269] In one implementation of the data access device 200, the device also includes: a model storage unit, which is used to save the unified semantic model of the product to be developed to a graph database after the semantic model construction unit 240 obtains the unified semantic model, and provide query capabilities based on the unified semantic model.

[0270] The data access device 200 provided in the embodiment of the present application can be used to execute the data access method provided in the embodiment of the present application. Its implementation principle and the technical effects produced have been introduced in the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference can be made to the corresponding content in any of the aforementioned method embodiments.

[0271] Figure 15 FIG. 3 shows a possible structure of the electronic device 300 provided in an embodiment of the present application. Figure 15 The electronic device 300 includes a processor 310 and a memory 320 . These components are interconnected and communicate with each other via a communication bus 330 and / or other connection mechanisms (not shown).

[0272] The processor 310 includes one or more processors (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor 310 can be a general-purpose processor, including a central processing unit (CPU), a microcontroller unit (MCU), a network processor (NP), or other conventional processors; it can also be a special-purpose processor, including a graphics processing unit (GPU), a neural network processing unit (NPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors 310, some of them can be general-purpose processors, while others can be special-purpose processors.

[0273] The memory 320 includes one or more (only one is shown in the figure), which can be, but is not limited to, random access memory (RAM), read only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0274] The processor 310 and other possible components can access the memory 320 and read and / or write data therein. In particular, the memory 320 can store one or more computer program instructions, and the processor 310 can read and execute these computer program instructions to implement the data access method provided in the embodiment of the present application.

[0275] I understand. Figure 15 The structure shown is for illustration only. The electronic device 300 may also include Figure 15More or fewer components than shown, or with Figure 15 For example, if the electronic device 300 needs to communicate with other devices, it may include a communication unit, which may be a wired and / or wireless communication module.

[0276] Figure 15 Each component shown in the figure can be implemented using hardware, software, or a combination thereof. The electronic device 300 may be a physical device, such as a server, a PC, a robot, or a virtual device, such as a virtual machine or a container. Furthermore, the electronic device 300 is not limited to a single device and may also be a combination of multiple devices or a cluster consisting of a large number of devices. Optionally, the digital main line mentioned above can be deployed on the electronic device 300 to execute the data access method provided in the embodiments of the present application.

[0277] The present application also provides a computer-readable storage medium, which stores computer program instructions. When these computer program instructions are read and executed by a processor, the data access method provided by the present application is executed. For example, the computer-readable storage medium can be implemented as Figure 15 The memory 320 in the electronic device 300. For another example, the computer-readable storage medium can be implemented as an independent storage device or medium, such as a mobile hard disk, a USB flash drive, or an optical disk.

[0278] The present application also provides a computer program product, which includes computer program instructions. When these computer program instructions are read and executed by a processor, the data access method provided by the present application is executed. For example, these computer program instructions can be stored in Figure 15 The computer program instructions are stored in the memory 320 in the electronic device 300. For another example, the computer program instructions may be stored in an independent storage device or medium, such as a distributed file system, a mobile hard disk, a USB flash drive, or an optical disk.

[0279] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, various modifications and variations of the present application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A data access method, characterized in that: The method comprises: Obtaining a metamodel of the product to be developed; wherein the metamodel includes at least a domain model for designing the product to be developed, entities included in each domain model, and relationships between the entities; Determine the interface configuration corresponding to the domain model according to the metamodel; Accessing model data of the domain model according to the interface configuration; According to the model data, under the guidance of the unified semantic framework of the product to be developed, the relationships in the meta-model are instantiated to obtain a unified semantic model of the product to be developed; wherein the unified semantic framework includes at least the elements, attributes and relationships that constitute the product to be developed, the unified semantic model includes at least triples consisting of entities, relationships and facts, the entities in the unified semantic model are obtained based on the merger of entities within each domain model, and the relationships in the unified semantic model include the relationships between entities within each domain model, and the relationships between entities of different domain models.

2. The data access method according to claim 1, characterized in that: If the product to be developed is a mature product, the metamodel of the product to be developed is obtained based on the metamodel of the existing product directly accessed; If the product to be developed is a new product, the meta-model of the product to be developed is obtained based on the model data analysis of the domain model of the product to be developed.

3. The data access method according to claim 1, wherein: After accessing the model data of the domain model according to the interface configuration, the method further includes: The accessed model data is parsed and rule-verified. If the verification passes, the parsed model data is distributedly indexed and stored according to the instructions of the meta-model.

4. The data access method according to claim 3, characterized in that: The rules include at least one of business rules, model rules and data rules.

5. The data access method according to claim 3, characterized in that: The meta-model includes multiple levels of nodes, wherein the first-level nodes represent physical storage nodes, each of which corresponds to a type of domain model, and the second-level or higher-level nodes represent logical nodes, each of which corresponds to an entity under a type of domain model; The distributed indexing of the parsed model data according to the instruction of the meta-model includes: The model file containing the model data is indexed to the first-level node, and the parsed model data is indexed to the second-level or higher-level node according to its content.

6. The data access method according to claim 5, characterized in that: The step of indexing the parsed model data to the secondary or higher-level node according to its content includes: The parsed model data is indexed to the secondary or higher-level node according to its content, the product development stage to which it belongs, and the historical version to which it belongs.

7. The data access method according to claim 5, characterized in that: The method further comprises: Index the horizontal relationships between model data of different domain models.

8. The data access method according to claim 1, characterized in that: After accessing the model data of the domain model according to the interface configuration, the method further includes: A data interaction service is created to provide access to the model data that has been connected and / or the interface interaction data formed after processing the model data.

9. The data access method according to claim 1, wherein: After accessing the model data of the domain model according to the interface configuration, the method further includes: By configuring the callback address, data is backfilled to the domain system that obtains the model data, so that the domain system can improve the model data according to the backfilled data.

10. The data access method according to claim 1, wherein: After obtaining the unified semantic model of the product to be developed, the method further includes: The unified semantic model is saved in a graph database, and query capabilities based on the unified semantic model are provided.

11. A computer program product, characterized in that The method comprises computer program instructions, and when the computer program instructions are read and executed by a processor, the method according to any one of claims 1 to 10 is executed.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, and when the computer program instructions are read and executed by a processor, the method according to any one of claims 1 to 10 is executed.

13. An electronic device, characterized in that: include: A memory and a processor, wherein the memory stores computer program instructions, and when the computer program instructions are read and executed by the processor, the method according to any one of claims 1 to 10 is executed.

Images