Ontology-based unified description method, device and equipment for heterogeneous modeling language

Abstract

The embodiments of the present application provide a method, device and equipment for unified description of heterogeneous modeling languages ​​based on ontology. The method obtains the heterogeneous modeling language used by the multi-architecture model. The heterogeneous modeling language is analyzed and disassembled based on the element categories of the multi-architecture model ontology to obtain the target element; the multi-architecture model ontology is a predefined standard semantic architecture. The target element is mapped and saved to the multi-architecture model ontology according to the mapping rules, and the element name of the target element is determined; the mapping rules are used to indicate the correspondence between the standard semantic architecture and the heterogeneous modeling language. The heterogeneous modeling language is uniformly described according to the element name. The method realizes interoperability and information consistency between models by uniformly processing the heterogeneous modeling language in the multi-architecture model.

Description

Technical Field

[0001] The present application relates to the technical field of modeling languages, and in particular to a method, apparatus, and device for unified description of heterogeneous modeling languages ​​based on ontology. Background Art

[0002] Model-based systems engineering (MBSE) is a new trend in complex system design and has been widely applied in various fields. MBSE, with models at its core, runs throughout the entire system lifecycle, enhancing design visualization, collaboration, automation, and traceability, making complex systems easier to understand, manage, and optimize.

[0003] To address the integration of multiple modeling languages ​​in MBSE, solutions such as language conversion tools, model integration platforms, and modeling language meta-metamodels have emerged. Language conversion tools enable automatic conversion between models, model integration platforms support collaborative modeling in multiple languages, and meta-metamodels attempt to achieve cross-language integration through a unified framework.

[0004] While existing technologies attempt to address the integration of MBSE modeling languages, challenges remain. Most language conversion tools only achieve syntax-level conversion. While model integration platforms provide a collaborative modeling environment, interoperability is limited. While meta-metamodel frameworks unify model representations, the mapping process is complex and the unique semantics of different languages ​​are difficult to fully preserve. Summary of the Invention

[0005] The embodiments of the present application provide a unified description method, apparatus, and device for heterogeneous modeling languages ​​based on ontology, so as to solve the problems of poor semantic consistency and insufficient interoperability among cross-domain modeling languages ​​in the prior art.

[0006] In a first aspect, embodiments of the present application provide a unified description method for heterogeneous modeling languages ​​based on ontology, including:

[0007] Obtain heterogeneous modeling languages ​​used by multi-architecture models;

[0008] Analyzing and decomposing the heterogeneous modeling language based on the element categories of the multi-architecture model ontology to obtain target elements; the multi-architecture model ontology is a predefined standard semantic architecture;

[0009] Mapping the target element to the multi-architecture model ontology according to a mapping rule, and determining the element name of the target element; the mapping rule is used to indicate the correspondence between the standard semantic architecture and the heterogeneous modeling language;

[0010] The heterogeneous modeling language is uniformly described according to the element names.

[0011] Optionally, before obtaining the heterogeneous modeling language used by the multi-architecture model, the method further includes:

[0012] Casting mid-level ontology based on formal ontology and industrial ontology, and building a unified semantic standard framework;

[0013] Under the semantic standard framework, based on the meta-metamodel and meta-object mechanism, a multi-architecture model ontology is designed;

[0014] Based on the meta-object mechanism, a mapping rule from the multi-architecture model to the multi-architecture model ontology is defined.

[0015] Optionally, the method of casting a mid-level ontology based on the formal ontology and the industrial ontology to build a unified semantic standard framework includes:

[0016] Obtain the first basic framework of the formal ontology and the second basic framework of the industrial ontology casting middle-level ontology respectively;

[0017] Filtering the first basic framework to obtain a first semantic framework, where the first semantic framework is used to indicate basic categories and relationships required for semantic conversion into ontology elements;

[0018] The second basic frame is filtered based on the semantic frame to obtain a second semantic frame; the second semantic frame is a content framework related to the first semantic frame;

[0019] Constructing a mapping relationship between the first semantic framework and the second semantic framework, wherein the mapping relationship is used to indicate that a general concept in the first semantic framework is associated with a preset concept in the second semantic framework;

[0020] The first semantic framework and the second semantic framework are fused according to the mapping relationship to obtain the semantic standard framework.

[0021] Optionally, under the semantic standard framework, based on the meta-metamodel and meta-object mechanism, a multi-architecture model ontology is designed, including:

[0022] Determining ontology elements according to the semantic standard framework, wherein the ontology elements are used to indicate element categories and element meanings during semantic description;

[0023] Constructing a meta-model based on the meta-object mechanism and the ontology elements;

[0024] Obtaining a first element of the meta-meta-model;

[0025] The meta-model is mapped and defined according to the first element to obtain the multi-architecture model ontology.

[0026] Optionally, the elements of the metamodel include: classes, subclasses, instances, annotation attributes, and object attributes; the first elements include: object elements, role elements, attribute elements, relationship elements, and extension elements; and the mapping definition processing of the metamodel according to the first elements to obtain the multi-architecture model ontology includes:

[0027] defining classes and subclasses in the metamodel according to the object elements and the role elements;

[0028] Based on the defined class, create an instance, where the instance is used to indicate a specific object in the metamodel;

[0029] Defining annotation attributes and object attributes in the meta-model according to the attribute elements and the relationship elements;

[0030] defining connection constraints between the metamodel elements according to the extended elements;

[0031] The defined meta-model is checked and verified to obtain the multi-architecture model ontology.

[0032] Optionally, the mapping rule of defining the multi-architecture model to the multi-architecture model ontology based on the meta-object mechanism includes:

[0033] Constructing a mapping relationship between the modeling language of the multi-architecture model and the subclass;

[0034] Constructing a mapping relationship between the element relationship of the multi-architecture model and the object attributes;

[0035] Constructing a mapping relationship between the inherent attributes of the multi-architecture model and the annotation attributes;

[0036] The mapping relationship is saved to obtain a mapping rule.

[0037] In a second aspect, an embodiment of the present application provides a unified description device for heterogeneous modeling languages ​​based on ontology, comprising:

[0038] An acquisition module is used to obtain the heterogeneous modeling language used by the multi-architecture model;

[0039] a processing module configured to analyze and decompose the heterogeneous modeling language based on the element categories of a multi-architecture model ontology to obtain target elements; the multi-architecture model ontology is a predefined standard semantic architecture;

[0040] a determination module, configured to map and save the target element into the multi-architecture model ontology according to a mapping rule, and determine the element name of the target element; the mapping rule is used to indicate the correspondence between the standard semantic architecture and the heterogeneous modeling language;

[0041] A description module is used to uniformly describe the heterogeneous modeling language according to the element names.

[0042] Optionally, the device further comprises: a construction module and a definition module;

[0043] The building module is used to cast a mid-level ontology based on the formal ontology and the industrial ontology, and to build a unified semantic standard framework;

[0044] The determination module is further configured to design a multi-architecture model ontology based on the meta-metamodel and meta-object mechanism under the semantic standard framework;

[0045] The definition module is used to define a mapping rule from a multi-architecture model to the multi-architecture model ontology based on a meta-object mechanism.

[0046] Optionally, the acquisition module is further configured to respectively acquire a first basic framework of the formalized ontology and a second basic framework of the industrial ontology casting middle-level ontology;

[0047] The processing module is further configured to filter the first basic framework to obtain a first semantic framework, wherein the first semantic framework is configured to indicate basic categories and relationships required for semantic conversion into ontology elements;

[0048] The processing module is further configured to filter the second basic frame based on the semantic frame to obtain a second semantic frame; the second semantic frame is a content framework related to the first semantic frame;

[0049] The construction module is further configured to construct a mapping relationship between the first semantic framework and the second semantic framework, wherein the mapping relationship indicates that a general concept in the first semantic framework is associated with a preset concept in the second semantic framework;

[0050] The processing module is further configured to fuse the first semantic frame and the second semantic frame according to the mapping relationship to obtain the semantic standard frame.

[0051] Optionally, the determining module is further configured to determine ontology elements according to the semantic standard framework, wherein the ontology elements are used to indicate element categories and element meanings during semantic description;

[0052] The construction module is further used to construct a meta-model based on the meta-object mechanism and the ontology elements;

[0053] The acquisition module is further configured to acquire the first element of the meta-meta-model;

[0054] The processing module is further configured to perform mapping definition processing on the meta-model according to the first element to obtain the multi-architecture model ontology.

[0055] Optionally, the definition module is further configured to define classes and subclasses in the meta-model based on the object elements and the role elements;

[0056] The building module is further used to create an instance based on the defined class, and the instance is used to indicate a specific object in the metamodel;

[0057] The definition module is further configured to define annotation attributes and object attributes in the meta-model according to the attribute elements and the relationship elements;

[0058] The definition module is further configured to define connection constraints between the metamodel elements according to the extension elements;

[0059] The processing module is further used to check and verify the defined meta-model to obtain the multi-architecture model ontology.

[0060] Optionally, the construction module is further used to construct a mapping relationship between the modeling language of the multi-architecture model and the subclass;

[0061] The construction module is further configured to construct a mapping relationship between the element relationship of the multi-architecture model and the object attributes;

[0062] The construction module is further configured to construct a mapping relationship between the inherent attributes of the multi-architecture model and the annotation attributes;

[0063] The processing module is further configured to save the mapping relationship to obtain a mapping rule.

[0064] In a third aspect, an embodiment of the present application provides a unified description device for a heterogeneous modeling language based on ontology, comprising: a memory, a processor;

[0065] The memory stores computer-executable instructions;

[0066] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0067] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementation methods of the first aspect.

[0068] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0069] The ontology-based unified description method, device and equipment of heterogeneous modeling languages ​​provided in the embodiments of the present application build a semantic standard framework based on formalized ontology and IOF-Core middle-level ontology, laying the foundation for subsequent integration. Under the framework, the GOPPRR-E meta-metamodel and MOF mechanism are used to design the multi-architecture model ontology corresponding to the multi-architecture model. Based on the MOF mechanism, the mapping rules of the multi-architecture model to the ontology are defined to ensure that different modeling languages ​​can be described in a unified semantic manner. During use, the method identifies the heterogeneous modeling language used by the multi-architecture model, analyzes and disassembles it to obtain the target elements, and then maps these elements to the multi-architecture model ontology according to predefined mapping rules, and determines the element name, thereby realizing a unified description of the heterogeneous modeling language. This method not only improves the flexibility and interoperability of MBSE modeling, but also promotes information sharing and integration between different modeling languages, and provides strong support for the semantic interoperability of complex system engineering. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0071] Figure 1 A schematic diagram of the unified description method of heterogeneous modeling language based on ontology provided in this application Figure 1 ;

[0072] Figure 2 A schematic diagram of the unified description method of heterogeneous modeling language based on ontology provided in this application Figure 2 ;

[0073] Figure 3 A schematic diagram of the unified description method of heterogeneous modeling language based on ontology provided in this application Figure 3 ;

[0074] Figure 4 A schematic diagram of the unified description method of heterogeneous modeling language based on ontology provided in this application Figure 4 ;

[0075] Figure 5 A schematic diagram of the structure of a unified description device for heterogeneous modeling language based on ontology provided in this application;

[0076] Figure 6 This application provides a structural diagram of a unified description of devices using an ontology-based heterogeneous modeling language.

[0077] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0078] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0079] First, the nouns appearing in this application are explained:

[0080] Basic Formal Ontology (BFO): A top-level ontology designed to provide a common, formalized foundation for other domain ontologies and knowledge organization systems. BFO defines a set of basic categories and relationships that can be used to build more specific ontologies.

[0081] Industrial Ontologies Foundry (IoF): Also known as the IOF-Core, this is a modular and universal industrial ontology that offers unlimited cross-domain reuse. The IoF is structured into distinct layers, encompassing domain-independent general ontologies (such as time and measurement), specialized ontologies for specific industrial domains, and extension modules tailored to meet application needs.

[0082] The meta-metamodel, also known as the GOPPRR-E meta-metamodel (Graph, Object, Property, Point, Relationship, Role, Extension, or GOPPRR-E), is a more abstract and concise model hierarchy. It defines a language for describing metamodels and uses this language to describe itself. The GOPPRR-E meta-metamodel, through its components (Graph, Object, Property, Point, Relationship, Role, Extension), provides a comprehensive description framework for metamodels.

[0083] Meta-Object Facility (MOF): A specification proposed by the Object Management Group (OMG) for defining a metadata programming language. MOF's layered architecture consists of M3-M0, corresponding to metamodel rules, metadata metamodel, data metamodel, and data, respectively. The MOF specification aims to provide open information modeling capabilities and defines a core MOF model, which consists of a relatively small set of object-oriented information modeling constructs that can be extended through inheritance and composition to facilitate the definition of richer information models that support additional constructs.

[0084] Model-based systems engineering (MBSE) has become a technological trend in complex system design and is now being gradually applied in a wide range of fields. MBSE, with models at its core, runs through the entire lifecycle of system requirements, design, verification, and validation, significantly enhancing system design capabilities such as visualization, collaboration, automation, and traceability. These improvements make complex systems easier to understand, manage, and optimize during the development process, while also improving communication efficiency and accuracy at all stages. However, the modeling languages ​​commonly used in MBSE methods are designed for different domains and development stages, each with its own unique syntax and semantics. This difference makes seamless integration across different domains and stages difficult.

[0085] To address the integration issues between multiple MBSE modeling languages, several attempts and solutions have been proposed in the prior art, including language conversion tools, model integration platforms, and modeling language meta-metamodels. Language conversion tools are used to automatically convert models in one modeling language into models in another language. Most of these tools implement conversion between languages ​​at the syntactic level by writing proprietary conversion rules. Model integration platforms: Some MBSE tools provide an integrated environment that supports collaborative modeling in multiple modeling languages. These tools allow users to model using Systems Modeling Language (SysML), Architecture Analysis and Design Language (AADL), and Business Process Modeling and Notation (BPMN) in the same environment, and attempt to achieve model interoperability through tool-level integration. Modeling language meta-metamodels: Some platforms attempt to achieve cross-language model integration by defining a common meta-metamodel framework that maps multiple modeling languages ​​into a unified metamodel.

[0086] Existing technologies support the integration of multiple MBSE modeling languages ​​to a certain extent. However, the following issues remain: Insufficient semantic interoperability: While existing language conversion tools can achieve some degree of conversion at the syntactic level, conversion between languages ​​such as SysML, BPMN, and AADL at the semantic level remains a significant challenge. Simple syntactic conversion can lead to semantic loss or misinterpretation. Lack of unified semantic standards: Because each language focuses on different domains and model perspectives, cross-domain modeling and verification in real projects often require the collaboration of multiple tools and platforms, resulting in complex workflows and difficult data synchronization. The lack of unified semantic standards across different modeling languages ​​means that tool-level integration often fails to fully address these semantic differences, increasing the complexity of cross-domain collaboration. Poor semantic consistency: Different modeling languages ​​have different semantic characteristics and modeling paradigms. Even if metamodels for these languages ​​are created through a meta-metamodel, the semantic differences between these languages ​​can lead to inconsistencies or loss of semantics when unified expression is achieved.

[0087] To address the above issues, this application proposes an ontology-based unified description method for heterogeneous modeling languages. Based on formalized ontologies and the IOF-Core mid-level ontology, this method constructs a unified semantic standard framework, laying the foundation for the integration of ontologies corresponding to heterogeneous MBSE modeling languages ​​and forming a standardized and scalable semantic standard framework. Within this framework, based on the GOPPRR-E meta-metamodel and the MOF mechanism, a multi-architecture model ontology corresponding to the multi-architecture model constructed based on heterogeneous MBSE modeling languages ​​is designed. Finally, based on the MOF mechanism, mapping rules from multi-architecture models to ontologies are defined, achieving a unified semantic description for different modeling languages.

[0088] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0089] Figure 1 A schematic diagram of a unified description method of heterogeneous modeling language based on ontology provided in an embodiment of the present application Figure 1 ,like Figure 1 As shown, the method includes:

[0090] S101: Obtain a heterogeneous modeling language used by a multi-architecture model.

[0091] Among them, heterogeneous modeling languages ​​refer to the diverse modeling languages ​​used in different fields or projects to describe the structure, behavior or properties of a system or model.

[0092] It is understandable that different architectural models use different modeling languages. These languages ​​may be based on graphics, text, or a hybrid form. Each language has its own unique grammatical and semantic rules. In this step, it is necessary to collect and understand these different modeling languages ​​to lay the foundation for subsequent analysis and processing.

[0093] S102: Analyze and decompose the heterogeneous modeling language based on the element categories of the multi-architecture model ontology to obtain target elements.

[0094] Among them, the multi-architecture model ontology is a predefined standard semantic architecture.

[0095] As can be understood, the Multi-Architecture Model Ontology provides a unified framework for describing common concepts and relationships across diverse architectural models. We conduct an in-depth analysis of the collected heterogeneous modeling languages, breaking them down according to the element categories (such as classes, attributes, and relationships) of the Multi-Architecture Model Ontology. This process aims to identify key elements within the modeling languages, which will serve as the foundation for subsequent mapping and unified description. This step simplifies complex modeling languages ​​into target elements that are easier to understand and process.

[0096] S103: Mapping the target element to the multi-architecture model ontology according to the mapping rule, and determining the element name of the target element.

[0097] The mapping rules are used to indicate the correspondence between the standard semantic architecture and the heterogeneous modeling language.

[0098] As you can understand, mapping rules are key to connecting the standard semantic architecture (multi-architecture model ontology) and heterogeneous modeling languages. These rules define how to map target elements in the heterogeneous modeling language to corresponding concepts in the multi-architecture model ontology. Applying these mapping rules, the decomposed target elements are mapped into the multi-architecture model ontology, and each target element is assigned a unique element name. This ensures that concepts in different modeling languages ​​can be described and compared within a unified framework.

[0099] S104: Unify the description of the heterogeneous modeling language according to the element names.

[0100] As you can understand, after completing the mapping and naming of target features, the final step is to unify the description of heterogeneous modeling languages ​​based on feature names. This step aims to leverage the unified framework and terminology provided by the multi-architecture model ontology to integrate concepts and information from different modeling languages ​​into a consistent and easy-to-understand description. This unified description not only helps eliminate barriers between different modeling languages ​​but also promotes communication and collaboration across different fields and projects.

[0101] The ontology-based unified description method of heterogeneous modeling languages ​​provided in this embodiment is achieved by obtaining the heterogeneous modeling languages ​​used by the multi-architecture model. The heterogeneous modeling languages ​​are analyzed and disassembled based on the element categories of the multi-architecture model ontology to obtain the target elements; the multi-architecture model ontology is a predefined standard semantic architecture. The target elements are mapped and saved to the multi-architecture model ontology according to the mapping rules, and the element names of the target elements are determined; the mapping rules are used to indicate the correspondence between the standard semantic architecture and the heterogeneous modeling languages. The heterogeneous modeling languages ​​are uniformly described according to the element names. This method achieves interoperability and information consistency between models by uniformly processing the heterogeneous modeling languages ​​in the multi-architecture model.

[0102] Figure 2 A schematic diagram of a unified description method of heterogeneous modeling language based on ontology provided in an embodiment of the present application Figure 2 ,like Figure 2 As shown, this embodiment Figure 1 Based on the embodiment, a method for constructing a multi-architecture model ontology is described, and the method includes:

[0103] S201: Cast a mid-level ontology based on formal ontology and industrial ontology, and build a unified semantic standard framework.

[0104] As you can see, a unified semantic standard framework is built based on the top-level ontology BFO and the mid-level ontology IOF-Core. BFO provides a universal high-level semantic foundation, while IOF-Core provides mid-level semantic support specific to the industry domain. This framework will serve as the foundation for semantic alignment across different MBSE modeling languages, ensuring consistency in fundamental concepts and relationships across cross-domain models.

[0105] In the BFO ontology, a general dependent persistence refers to a persistence that depends on one or more non-dependent persistences as its carriers and can be transferred between carriers. For example, the requirements of a car's driving system depend on the car and can be transferred and reused between cars during the design process. The middle-level ontology of the semantic standard framework, IOF-Core, mainly designs the standard framework from top to bottom around the general dependent persistence in the top-level ontology BFO. The IOF-Core ontology covers information content entities, including descriptive information content entities, specified information content entities, instruction information content entities, measurement information content entities, as well as core content such as requirement specifications, design specifications, plan specifications, action specifications, and target specifications.

[0106] Among them, design specifications refer to the information content entities that specify the design model, including the concepts, attributes, relationships involved in the model and how these elements interact and combine with each other.

[0107] S202: Under the semantic standard framework, based on the meta-metamodel and meta-object mechanism, a multi-architecture model ontology is designed.

[0108] Under the unified semantic standard framework, we can understand that based on the MOF mechanism and the GOPPRR-E meta-metamodel, we design a multi-architecture model domain ontology, covering ontology elements such as classes, subclasses, instances, annotation attributes, and object attributes. The classes in the multi-architecture model domain ontology are constructed based on the GOPPRR-E meta-metamodel, corresponding to the modeling language meta-metamodel, covering graphs, objects, attributes, nodes, relationships, roles, and the connection constraints between the model elements corresponding to the extensions.

[0109] S203: Based on the meta-object mechanism, define mapping rules from the multi-architecture model to the multi-architecture model ontology.

[0110] As can be understood, based on the designed multi-architecture model domain ontology and MOF mechanisms, mapping rules are defined between architecture models constructed using heterogeneous MBSE modeling languages ​​and the multi-architecture model domain ontology. Heterogeneous modeling languages ​​are mapped into subclasses of seven major categories: graphs, objects, attributes, nodes, relationships, roles, and connectors. Models are mapped into instances of corresponding subclasses. Relationships between elements within the model are mapped into object properties of the corresponding classes or instances. Furthermore, inherent attributes of the model are mapped into annotation attributes of the instances. This ensures correct understanding of the semantics of the heterogeneous modeling languages.

[0111] Optionally, a mapping relationship between the modeling language of the multi-architecture model and the subclass is constructed.

[0112] Understandably, the first step is to determine the correspondence between each heterogeneous MBSE (Model-Based Systems Engineering) modeling language and the seven major subclasses (diagram, object, attribute, node, relationship, role, and connector) in the multi-architecture model domain ontology. This process typically involves a deep understanding of the syntax and semantics of each modeling language and how the elements they use to describe system architectures match the subclasses in the domain ontology.

[0113] A mapping relationship between the element relationship of the multi-architecture model and the object attributes is constructed.

[0114] As you can understand, after determining the mapping between the modeling language and subclasses, the next step is to map the relationships between the various elements within the model to the object properties in the domain ontology. These relationships may include connections, dependencies, and inheritance between components. In the domain ontology, these relationships are typically expressed through object properties.

[0115] A mapping relationship between the inherent attributes of the multi-architecture model and the annotation attributes is constructed.

[0116] As you can understand, in addition to relationships between elements, each element in the model may also have inherent properties, such as name, type, and version. These inherent properties are typically expressed in the domain ontology through annotation attributes. Therefore, establishing a mapping relationship between inherent properties and annotation attributes is to ensure that these inherent properties of each element in the model are correctly mapped to the corresponding annotation attributes in the domain ontology.

[0117] The mapping relationship is saved to obtain a mapping rule.

[0118] As you can understand, after constructing the mapping relationships described above, they need to be saved for easy use and reference in subsequent work. This process can involve various methods, such as storing the mapping relationships in a database or generating documentation or code for the mapping rules. Regardless of the method used, the goal is to ensure the accuracy and accessibility of the mapping relationships, thereby supporting subsequent work such as semantic understanding and model conversion in heterogeneous MBSE modeling languages.

[0119] This embodiment provides a unified description method for heterogeneous modeling languages ​​based on ontology. By integrating formalized ontologies with the industrial ontology foundry mid-level ontology, a unified semantic standard framework is constructed. Within this framework, a multi-architecture model ontology is designed using the meta-metamodel and meta-object mechanism. Furthermore, based on the meta-object mechanism, specific rules for mapping multi-architecture models to this ontology are clarified. This technology significantly improves interoperability and data consistency between models, providing a solid foundation for cross-architecture information integration and sharing.

[0120] Figure 3 A schematic diagram of a unified description method of heterogeneous modeling language based on ontology provided in an embodiment of the present application Figure 3 ,like Figure 3 As shown, this embodiment Figure 1 Based on the embodiment, a method for constructing a semantic standard framework is described, which includes:

[0121] S301: Obtain the first basic framework of the formal ontology and the second basic framework of the industrial ontology casting middle-level ontology respectively.

[0122] As you can understand, we first extract the foundational framework from two different ontology sources. The first foundational framework comes from a formal ontology. This may be a more general or abstract ontology that provides the basic concepts and relationships needed to build other ontologies. This foundational framework may include basic concepts such as entities, attributes, and relationships, as well as the logical relationships between these concepts. The second foundational framework comes from the industrial ontology casting mid-level ontology. This is a more specific and specialized ontology focused on the pre-defined concepts and relationships of the foundry industry. This foundational framework may include professional terms and concepts related to casting processes, materials, equipment, and procedures.

[0123] S302: Filter the first basic frame to obtain a first semantic frame.

[0124] The first semantic framework is used to indicate the basic categories and relationships required for semantic conversion into ontology elements.

[0125] As you can understand, after obtaining the first basic framework, it needs to be filtered to extract the basic categories and relationships that are crucial for semantic conversion into ontology elements. This process involves filtering, classifying, and reorganizing the concepts in the basic framework to form a more streamlined and targeted semantic framework.

[0126] S303: Filtering the second basic frame based on the semantic frame to obtain a second semantic frame.

[0127] The second semantic frame is a content framework related to the first semantic frame.

[0128] As you can understand, the first semantic framework serves as a guide for further filtering of the second foundational framework. The goal of this process is to extract content related to the first semantic framework from the second foundational framework, forming a second semantic framework that is closely connected to the first semantic framework. This second semantic framework will contain pre-defined concepts and relationships relevant to the foundry industry, but has been filtered to ensure consistency with the common concepts and relationships in the first semantic framework.

[0129] S304: Constructing a mapping relationship between the first semantic frame and the second semantic frame.

[0130] The mapping relationship is used to indicate that the general concept in the first semantic framework is associated with the preset concept in the second semantic framework.

[0131] As can be understood, after obtaining the two semantic frames, a mapping relationship is constructed to indicate the conceptual correspondence between the two frames. This mapping relationship will help us understand how the general concepts in the first semantic frame find specific counterparts in the second semantic frame.

[0132] S305: The first semantic frame and the second semantic frame are merged according to the mapping relationship to obtain a semantic standard frame.

[0133] As can be understood, mapping relationships are used to fuse the first and second semantic frameworks to form a unified semantic standard framework. This fusion process may involve merging, reorganizing, and expanding concepts from the two frameworks to form a complete framework that encompasses both common and predefined concepts. This semantic standard framework will serve as the foundation for subsequent semantic processing and ontology construction, helping us better understand and process semantic information related to the foundry industry.

[0134] This embodiment provides a unified description method for heterogeneous ontology-based modeling languages. By acquiring the foundational frameworks of the formal ontology and the industrial ontology foundry mid-level ontology, the method filters out the semantic frameworks of each ontology, establishes a mapping relationship between the two, and ultimately merges them into a unified semantic standard framework. This process improves the accuracy and interoperability of ontology models and promotes cross-domain information sharing.

[0135] Figure 4 A schematic diagram of a unified description method of heterogeneous modeling language based on ontology provided in an embodiment of the present application Figure 4 ,like Figure 4 As shown, this embodiment Figure 1 Based on the embodiment, a method for constructing a multi-architecture model ontology is described in detail. The method includes:

[0136] S401: Determine ontology elements based on the semantic standard framework.

[0137] Among them, ontology elements are used to indicate element categories and element meanings during semantic description.

[0138] As you can understand, the semantic standard framework provides a baseline for building domain ontologies, ensuring that all defined concepts and relationships are semantically consistent. Based on this framework, we identify ontological elements, which form the foundation for building domain ontologies. These elements include classes, subclasses, instances, annotation attributes, and object properties. Ontological elements not only represent the entities and concepts in the model but also clarify the categories and meanings of these entities and concepts when used in semantic descriptions.

[0139] S402: Construct a meta-model based on the meta-object mechanism and ontology elements.

[0140] As you can understand, the meta-object mechanism is a method for defining and managing model elements, providing a description method at an abstract level. After determining the ontology elements, we use the meta-object mechanism to construct a metamodel. The metamodel is a high-level representation of the domain ontology, defining the structure and behavior of various elements in the model. By combining ontology elements with the meta-object mechanism, we can ensure that the metamodel not only meets the requirements of the semantic standard framework but also accurately represents the concepts and relationships in the domain.

[0141] S403: Obtain the first element of the meta-meta model.

[0142] As you can understand, the meta-metamodel is the model that defines the metamodel. It provides the basic concepts and rules required to build the metamodel. These first elements include graphs, objects, attributes, nodes, relationships, roles, and extensions, which constitute the basic structure of the metamodel.

[0143] S404: Define classes and subclasses in the metamodel based on object elements and role elements.

[0144] As you can understand, in the metamodel, classes and subclasses are used to represent entities and concepts at different levels. We define classes and subclasses in the metamodel based on object elements (representing specific entities or concepts) and role elements (describing the roles of entities in specific relationships). Object elements provide specific instances of classes, while role elements help us understand the functions and roles of these instances in the model. By defining classes and subclasses, we can build a metamodel with a clear hierarchy and a well-structured structure.

[0145] S405: Based on the defined class, create an instance, where the instance is used to indicate a specific object in the meta-model.

[0146] As you can understand, after defining classes and subclasses, we need to create instances to represent concrete objects of these classes. Instances are concrete elements in the metamodel, representing real-world entities or concepts. By creating instances, we can concretize abstract concepts and relationships, making the model more realistic for real-world applications.

[0147] S406: Based on the attribute elements and the relationship elements, define the annotation attributes and object attributes in the meta-model.

[0148] As you can understand, attributes are used to describe the characteristics of classes and instances. We define annotation attributes and object properties in the metamodel based on attribute elements (describing the characteristics of a class or instance) and relationship elements (describing the relationships between classes or instances). Annotation attributes provide additional descriptive information about classes and instances, helping to understand their meaning and purpose; object attributes, on the other hand, describe the relationships between classes or instances and are a crucial component of the model.

[0149] S407: Based on the extended elements, define connection constraints between metamodel elements.

[0150] As you can understand, extension elements allow us to customize and extend the metamodel to meet the needs of specific application scenarios. We use these extension elements to define connection constraints between metamodel elements. These constraints ensure that elements within the model maintain structural and semantic consistency and integrity. By defining connection constraints, we ensure the stability and reliability of the model in complex scenarios.

[0151] S408: Check and verify the defined meta-model to obtain a multi-architecture model ontology.

[0152] As you can understand, after defining the metamodel, we need to thoroughly check and validate it. This process includes syntax checking, semantic validation, and consistency checks to ensure that the metamodel complies with the semantic standard framework and the GOPPRR-E meta-metamodel. Through this process, we can obtain a multi-architecture model ontology with a clear structure, accurate semantics, and practical requirements.

[0153] This embodiment provides an ontology-based unified description method for heterogeneous modeling languages. This method identifies ontological elements within a semantic standard framework to indicate semantic description categories and meanings. It then constructs a metamodel using a metaobject mechanism. Based on the metamodel's first element, it defines classes, subclasses, instances, annotation attributes, object properties, and connection constraints. Ultimately, after verification and validation, a multi-architecture model ontology is generated. This method effectively integrates semantic information from multi-architecture models, improving model consistency and interoperability, and providing strong support for modeling and knowledge sharing in complex systems.

[0154] The following example uses the intelligent electric vehicle autonomous driving system model built based on the SysML modeling language to illustrate the unified description method of the ontology-based heterogeneous modeling language. First, it is determined that the modeling language of the intelligent electric vehicle autonomous driving system model is the SysML modeling language. The language is analyzed and split to obtain multiple elements.

[0155] Among them, the mapping rules of the SysML modeling language are defined as follows:

[0156] (1) Diagram Class Mapping: Each SysML diagram (e.g., use case diagram, requirement diagram, activity diagram, etc.) is mapped to a subclass of the Diagram class in the multi-architecture model domain ontology. Instances of each Diagram class are mapped to specific modeling language constructs. For example, an instance of a Use Case Diagram in SysML will be mapped to a specific instance of the Diagram class.

[0157] (2) Object Class Mapping: Objects in SysML (such as use cases, actors, requirements, etc.) are mapped to subclasses of the object class in the domain ontology. Different object instances will correspond to different entities in the ontology. For example, the actor in the use case diagram is mapped to the "actor" subclass of the object class.

[0158] (3) Relationship Class Mapping: Relationships in different SysML diagrams (e.g., association, derived, and refinement) are mapped to subclasses of the relationship class in the domain ontology. Specific instances of each relationship are mapped in the model to instances of the relationship class in the domain ontology. For example, a derived relationship in a requirement diagram will be mapped to an instance of the "derived" subclass of the relationship class.

[0159] (4) Role Class Mapping: The roles at both ends of a relationship are mapped as subclasses of the role class. For example, in a use case diagram, the roles representing the start and end of an association relationship are mapped as specific instances of the role class, indicating the direction of the relationship.

[0160] (5) Point Class Mapping: Points involved in SysML (such as flow ports) are mapped to subclasses of the point class. Port / interface modeling elements such as flow ports can be represented by point classes to represent their location and behavior. For example, the flow port in the module definition diagram is mapped to the "flow port" subclass in the point class.

[0161] (6) Attribute Class Mapping: Attributes in SysML (such as name, description, etc.) are mapped to attribute class subclasses in the domain ontology. For example, the name of the use case will be mapped to the "name" subclass of the attribute class, and the description of the use case will be mapped to the "description" subclass of the attribute class.

[0162] (7) Connector class mapping: used to represent the connection relationship between SysML model elements. In the module definition diagram in SysML, the combination relationship between a module and its submodules will be mapped to the "Combination" subclass instance of the connector class in the ontology, representing the dependency and structural connection between modules.

[0163] (8) Annotation attribute mapping: used to describe the metadata (such as ID, type, version, etc.) of model elements in SysML. The unique identifier (ID) and type (type) of each SysML element are mapped to specific instances of the annotation attribute class. For example, the unique identifier of a use case is mapped to the "id" annotation attribute subclass, and the type is mapped to the "type" annotation attribute subclass.

[0164] (9) Object attribute mapping: used to describe the relationship between model elements in SysML. For example, the use case diagram contains objects such as use cases, executors, and system boundaries, and the use case diagram contains association relationships, which are mapped to object attributes such as "diagram contains objects" and "diagram contains relationships" and assigned to the corresponding element classes.

[0165] Through these mapping rules, elements in the SysML modeling language can be accurately mapped to corresponding elements in the domain ontology, ensuring semantic consistency and interoperability. These mapping rules not only cover the syntactic elements of SysML but also correspond to the semantics of annotation attributes and object properties in the mapped ontology. This ensures semantic consistency across different modeling languages ​​and reduces semantic loss or misunderstandings during cross-domain model integration.

[0166] Then, based on the ontology corresponding to the SysML modeling language, the mapping rules between the model built based on the SysML modeling language and the ontology are defined. Taking the smart electric vehicle autonomous driving model built with the SysML modeling language as an example, some of the mappings are as follows:

[0167] (1) Package diagram mapping: Package: used to show the system structure and the dependencies between modules, organize the various models of the autonomous driving system, and map them as instances of the object package class.

[0168] (2) Use case diagram mapping: Use case diagram: The boundary definition model of the autonomous driving system is mapped as an instance of the use case diagram class. Use case: The "Decision and Control" use case is mapped as an instance of the "Use Case" object. Actors: Roles such as the external environment, driver, and pedestrians are mapped as instances of the "Actor" object class. System boundary: Mapped as an instance of the "System Boundary" object class, representing the interaction scope of the system. Association: The association relationship between the actor "Driver" and the use case "Decision and Control" is mapped as an instance of the "Association" relationship class, representing the association relationship between objects. Connector: The actor "Driver" and the use case "Decision and Control" are connected to the "Association" relationship start role and terminal role respectively, and are mapped as instances of the connector class.

[0169] (3) Requirement Graph Mapping: Requirement Graph: The autonomous driving system requirement model is mapped as an instance of the Requirement Graph class. Requirements: The requirements of the autonomous driving system are mapped as instances of the "Requirement" object class. For example, "Autonomous Driving Requirements" is mapped as an instance of the "Requirement" object class. Derivation Relationship: The derivation relationship between "Autonomous Driving Requirements" and "Vehicle Control" requirements is mapped as an instance of the "Derivation" relationship class to ensure the hierarchical association of requirements. Constraint: The start and end of the "Derivation" relationship are connected to "Autonomous Driving Requirements" and "Vehicle Control" respectively, and are mapped as instances of the Connector class.

[0170] (4) Activity Diagram Mapping: Activity Diagram: The vehicle control activity model of the autonomous driving system is mapped as an instance of the Activity Diagram class. Activity: The key activities in autonomous driving (including perception, decision-making, and control) are mapped as instances of the "Activity" object class. Control Flow: The process control between activities is mapped as an instance of the "Control Flow" relationship class, which represents the sequence and logical control between activities.

[0171] (5) Sequence diagram mapping: Sequence diagram: The vehicle braking sequence model of the autonomous driving system is mapped as an instance of the Sequence diagram class. Message: The interaction messages between components in the autonomous driving system are mapped as instances of the "Message" object class. Lifeline: The behavior sequence and life cycle of the components are mapped as instances of the "Lifeline" object class, representing the dynamic behavior of the system.

[0172] (6) Module Definition Diagram Mapping: The module definition diagram maps the autonomous driving system's component model to an instance of the module definition diagram class. Module: Each module of the autonomous driving system (e.g., sensor module, control module) is mapped to an instance of the "module" object class. Combination Relationship: The combination relationship between the autonomous driving system and the sensor module and control module is mapped to an instance of the "relationship" class, describing the system's component structure.

[0173] (7) Internal Module Diagram Mapping: Internal Module Diagram: The interface model within the logical components of the autonomous driving system is mapped as an instance of the Internal Module Definition Diagram class. Internal Module: The internal structure of each logical component is mapped as an instance of the "Internal Module" object class, reflecting the division of labor and collaboration within the module. For example, the perception module contains a camera submodule and a radar submodule, which are mapped in the ontology to the "Camera Submodule" and "Radar Submodule" instances of the "Internal Module" object class, respectively. Port: The data transmission interface between the perception module and the decision module is mapped as an instance of the "Data Transmission Interface" of the "Point" class.

[0174] (8) State Machine Diagram Mapping: State Machine Diagram: The state transition model of the autonomous driving system is mapped as an instance of the State Machine Diagram class. State: Each state in the autonomous driving system (including driving, parking, and obstacle avoidance) is mapped as an instance of the "State" object class, which represents the behavior of the system in different situations. Transition: The transition between different states is mapped as an instance of the "Transition" relationship class, which represents the switching logic between states.

[0175] (9) Parameter Map: The parameter model of the physical components of the autonomous driving system is mapped as an instance of the parameter map class. Parameters: Parameters in the autonomous driving system of smart electric vehicles, such as speed, acceleration, and battery power, are mapped in the ontology as instances of the attribute class "speed attribute", "acceleration attribute", and "battery power attribute". Parameter Binding Map: The relationship between the parameters in the perception module and the decision module is mapped as an instance of the relationship class "parameter binding relationship".

[0176] Figure 5 This is a schematic diagram of a unified description device for heterogeneous modeling language based on ontology provided in this application, such as Figure 5 As shown, the ontology-based heterogeneous modeling language unified description device 500 provided in this embodiment:

[0177] An acquisition module 501 is used to acquire a heterogeneous modeling language used by a multi-architecture model;

[0178] Processing module 502 is used to analyze and decompose the heterogeneous modeling language based on the element categories of the multi-architecture model ontology to obtain target elements; the multi-architecture model ontology is a predefined standard semantic architecture;

[0179] A determination module 503 is configured to map and save the target element into the multi-architecture model ontology according to a mapping rule, and determine the element name of the target element; the mapping rule is configured to indicate a correspondence between a standard semantic architecture and the heterogeneous modeling language;

[0180] The description module 504 is configured to uniformly describe the heterogeneous modeling language according to the element names.

[0181] Optionally, the apparatus further includes: a construction module 505, a definition module 506;

[0182] The construction module 505 is used to build a unified semantic standard framework based on the formal ontology and the industrial ontology to create a mid-level ontology;

[0183] The determining module 503 is further configured to design a multi-architecture model ontology based on the meta-metamodel and meta-object mechanism under the semantic standard framework;

[0184] The definition module 506 is used to define a mapping rule from a multi-architecture model to the multi-architecture model ontology based on a meta-object mechanism.

[0185] Optionally, the acquisition module 501 is further configured to respectively acquire a first basic framework of the formalized ontology and a second basic framework of the industrial ontology casting middle-level ontology;

[0186] The processing module 502 is further configured to filter the first basic framework to obtain a first semantic framework, wherein the first semantic framework is configured to indicate basic categories and relationships required for semantic conversion into ontology elements.

[0187] The processing module 502 is further configured to filter the second basic frame based on the semantic frame to obtain a second semantic frame; the second semantic frame is a content framework related to the first semantic frame;

[0188] The construction module 505 is further configured to construct a mapping relationship between the first semantic framework and the second semantic framework, wherein the mapping relationship indicates that a general concept in the first semantic framework is associated with a preset concept in the second semantic framework;

[0189] The processing module 502 is further configured to fuse the first semantic frame and the second semantic frame according to the mapping relationship to obtain the semantic standard frame.

[0190] Optionally, the determining module 503 is further configured to determine ontology elements according to the semantic standard framework, wherein the ontology elements are used to indicate element categories and element meanings during semantic description;

[0191] The construction module 505 is further used to construct a meta-model based on the meta-object mechanism and the ontology elements;

[0192] The acquisition module 501 is further configured to acquire the first element of the meta-meta-model;

[0193] The processing module 502 is further configured to perform mapping definition processing on the meta-model according to the first element to obtain the multi-architecture model ontology.

[0194] Optionally, the definition module 506 is further configured to define classes and subclasses in the meta-model based on the object elements and the role elements;

[0195] The construction module 505 is further used to create an instance based on the defined class, where the instance is used to indicate a specific object in the metamodel;

[0196] The definition module 506 is further configured to define annotation attributes and object attributes in the meta-model according to the attribute elements and the relationship elements;

[0197] The definition module 506 is further configured to define connection constraints between the metamodel elements based on the extension elements;

[0198] The processing module 502 is further used to check and verify the defined meta-model to obtain the multi-architecture model ontology.

[0199] Optionally, the construction module 505 is further configured to construct a mapping relationship between the modeling language of the multi-architecture model and the subclass;

[0200] The construction module 505 is further configured to construct a mapping relationship between the element relationship of the multi-architecture model and the object attributes;

[0201] The construction module 505 is further configured to construct a mapping relationship between the inherent attributes of the multi-architecture model and the annotation attributes;

[0202] The processing module 502 is further configured to save the mapping relationship to obtain a mapping rule.

[0203] The ontology-based heterogeneous modeling language unified description device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effects are similar, and are not described in detail in this embodiment.

[0204] Figure 6 This application provides a structural diagram of a device that is uniformly described in an ontology-based heterogeneous modeling language. Figure 6 As shown, the electronic device 600 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 600 further includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus.

[0205] During the specific implementation process, at least one processor 601 executes the computer-executable instructions stored in the memory 602, so that the at least one processor 601 performs the above method.

[0206] The specific implementation process of the processor 601 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0207] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASICs), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0208] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0209] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0210] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0211] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0212] The readable storage medium may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0213] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0214] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0215] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0216] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0217] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of the present invention. The aforementioned storage medium includes various media that can store program code, such as USB flash drives, mobile hard drives, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0218] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0219] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A unified description method for heterogeneous modeling languages ​​based on ontology, characterized in that: include: Obtain heterogeneous modeling languages ​​used by multi-architecture models; Analyzing and decomposing the heterogeneous modeling language based on element categories of a multi-architecture model ontology to obtain target elements, wherein the multi-architecture model ontology is a predefined standard semantic architecture; Mapping the target element to the multi-architecture model ontology according to a mapping rule, and determining an element name of the target element, wherein the mapping rule is used to indicate a correspondence between a standard semantic architecture and the heterogeneous modeling language; Describing the heterogeneous modeling language uniformly according to the element names; Before obtaining the heterogeneous modeling language used by the multi-architecture model, the method further includes: Obtain the first basic framework of the formal ontology and the second basic framework of the industrial ontology casting middle-level ontology respectively; Filtering the first basic framework to obtain a first semantic framework, where the first semantic framework is used to indicate categories and relationships required for semantic conversion into ontology elements; The second basic frame is filtered based on the semantic frame to obtain a second semantic frame; the second semantic frame is a content framework related to the first semantic frame; Constructing a mapping relationship between the first semantic framework and the second semantic framework, wherein the mapping relationship is used to indicate that a general concept in the first semantic framework is associated with a preset concept in the second semantic framework; fusing the first semantic frame and the second semantic frame according to the mapping relationship to obtain a unified semantic standard frame; Under the semantic standard framework, based on the meta-metamodel and meta-object mechanism, a multi-architecture model ontology is designed; Based on the meta-object mechanism, a mapping rule from the multi-architecture model to the multi-architecture model ontology is defined.

2. The method according to claim 1, characterized in that Under the semantic standard framework, based on the meta-metamodel and meta-object mechanism, a multi-architecture model ontology is designed, including: Determining ontology elements according to the semantic standard framework, wherein the ontology elements are used to indicate element categories and element meanings during semantic description; Constructing a meta-model based on the meta-object mechanism and the ontology elements; Acquire a first element of the meta-meta model, where the first element refers to element information included in the meta-meta model; The meta-model is mapped and defined according to the first element to obtain the multi-architecture model ontology.

3. The method according to claim 2, characterized in that The elements of the meta-model include: classes, sub-classes, instances, annotation attributes, and object attributes. The first elements include: object elements, role elements, attribute elements, relationship elements, and extension elements. The mapping definition processing of the meta-model according to the first elements to obtain the multi-architecture model ontology includes: defining classes and subclasses in the metamodel according to the object elements and the role elements; Based on the defined class, create an instance, where the instance is used to indicate a specific object in the metamodel; Defining annotation attributes and object attributes in the meta-model according to the attribute elements and the relationship elements; defining connection constraints between the metamodel elements according to the extended elements; The defined meta-model is checked and verified to obtain the multi-architecture model ontology.

4. The method according to claim 3, characterized in that The mapping rules of the multi-architecture model to the multi-architecture model ontology are defined based on the meta-object mechanism, including: Constructing a mapping relationship between the modeling language of the multi-architecture model and the subclass; Constructing a mapping relationship between the element relationship of the multi-architecture model and the object attributes; Constructing a mapping relationship between the inherent attributes of the multi-architecture model and the annotation attributes; The mapping relationship is saved to obtain a mapping rule.

5. A unified description device for heterogeneous modeling language based on ontology, characterized in that: include: An acquisition module is used to obtain the heterogeneous modeling language used by the multi-architecture model; a processing module configured to analyze and decompose the heterogeneous modeling language based on the element categories of a multi-architecture model ontology to obtain target elements; the multi-architecture model ontology is a predefined standard semantic architecture; a determination module, configured to map and save the target element into the multi-architecture model ontology according to a mapping rule, and determine the element name of the target element; the mapping rule is used to indicate the correspondence between the standard semantic architecture and the heterogeneous modeling language; A description module, configured to uniformly describe the heterogeneous modeling language according to the element names; The device further comprises: a construction module and a definition module; The construction module is used to respectively obtain a first basic framework of the formal ontology and a second basic framework of the industrial ontology casting middle-level ontology; filter the first basic framework to obtain a first semantic framework, which is used to indicate the categories and relationships required for semantic conversion into ontology elements; filter the second basic framework based on the semantic framework to obtain a second semantic framework; the second semantic framework is a content architecture related to the first semantic framework; Constructing a mapping relationship between the first semantic frame and the second semantic frame, wherein the mapping relationship is used to indicate that a general concept in the first semantic frame is associated with a preset concept in the second semantic frame; fusing the first semantic frame and the second semantic frame according to the mapping relationship to obtain a unified semantic standard frame; The determination module is further configured to design a multi-architecture model ontology based on the meta-metamodel and meta-object mechanism under the semantic standard framework; The definition module is used to define a mapping rule from a multi-architecture model to the multi-architecture model ontology based on a meta-object mechanism.

6. A unified description device for heterogeneous modeling language based on ontology, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 4 when executed by a processor.

Images