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

Abstract

The embodiment of the invention provides an ontology-based heterogeneous modeling language unified description method, device and equipment. According to the method, a heterogeneous modeling language used by a multi-architecture model is obtained; carrying out analysis and disassembly processing on the heterogeneous modeling language based on the element category of the multi-architecture model ontology to obtain a target element; the multi-architecture model ontology is a predefined standard semantic architecture. Mapping and storing the target element into the multi-architecture model body according to a mapping rule, and determining an element name of the target element; the mapping rule is used for indicating a corresponding relationship between the standard semantic architecture and the heterogeneous modeling language. And performing unified description on the heterogeneous modeling language according to the element names. According to the method, the interoperability and the information consistency among the models are realized by uniformly processing heterogeneous modeling languages 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 unified description method, apparatus and device for 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 used in many fields. MBSE takes the model as the core and runs through the entire life cycle of the system, improving the visualization, collaboration, automation and traceability of the design, making complex systems easier to understand, manage and optimize.

[0003] In order to solve the integration problem of multiple modeling languages ​​in MBSE, there are already solutions such as language conversion tools, model integration platforms and modeling language meta-meta models. Language conversion tools realize automatic conversion between models, model integration platforms support collaborative modeling in multiple languages, and meta-meta models attempt to achieve cross-language integration through a unified framework.

[0004] Although existing technologies attempt to solve the integration problem of MBSE modeling languages, challenges remain. Most language conversion tools only achieve conversion at the syntax level. Although model integration platforms provide a collaborative modeling environment, their interoperability is limited. Although 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, an embodiment of the present application provides a unified description method of heterogeneous modeling languages ​​based on ontology, comprising:

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

[0008] The heterogeneous modeling language is analyzed and decomposed 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;

[0009] The target element is mapped and saved into the multi-architecture model ontology according to a mapping rule, and the element name of the target element is determined; the mapping rule is used to indicate the corresponding relationship between the standard semantic architecture and the heterogeneous modeling language;

[0010] The heterogeneous modeling languages ​​are described uniformly 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 middle-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 middle-level ontology based on the formal ontology and the industrial ontology to build a unified semantic standard framework includes:

[0016] respectively obtaining a first basic framework of the formalized ontology and a second basic framework of the industrial ontology casting middle-level ontology;

[0017] Screening 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 screened based on the semantic frame to obtain a second semantic frame; the second semantic frame is a content frame 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-meta model 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] Based on the meta-object mechanism and the ontology elements, a meta-model is constructed;

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

[0025] The metamodel 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] According to the extended elements, defining connection constraints between the metamodel elements;

[0031] The defined metamodel 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 attribute;

[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 of heterogeneous modeling language based on ontology, comprising:

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

[0039] A processing module, used for 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;

[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 corresponding relationship 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 construction module is used to build a unified semantic standard framework by casting a middle-level ontology based on the formal ontology and the industrial ontology;

[0044] The determination module is further used 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 used 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 used to filter 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;

[0048] The processing module is further used 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 used to construct 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;

[0050] The processing module is further used 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 determination module is further used 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 used to acquire the first element of the meta-meta-model;

[0054] The processing module is further used 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 used to define classes and subclasses in the meta-model according to the object elements and the role elements;

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

[0057] The definition module is further used 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 used to define connection constraints between the metamodel elements according to the extension elements;

[0059] The processing module is also 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 used to construct a mapping relationship between the element relationship of the multi-architecture model and the object attribute;

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

[0063] The processing module is further used 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 of a heterogeneous modeling language based on ontology, including: 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 implementations 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 multi-architecture model ontology corresponding to the multi-architecture model is designed using the GOPPRR-E meta-metamodel and MOF mechanism. Based on the MOF mechanism, the mapping rules from 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 the target elements, and then maps these elements to the multi-architecture model ontology according to the predefined mapping rules, and determines the element name, thereby realizing the 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 a unified description method of heterogeneous modeling language based on ontology provided in this application Figure 1 ;

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

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

[0074] Figure 4 A schematic diagram of a 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 A schematic diagram of a unified description of a device structure using an ontology-based heterogeneous modeling language provided in this application.

[0077] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0078] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some 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): is a top-level ontology that aims 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 IOF-Core. It is a modular and universal industrial ontology that provides unlimited possibilities for cross-domain reuse. IoF has a clear hierarchy, including domain-independent general ontologies (such as time, measurement, etc.), segmented ontologies for specific industrial fields, and extension modules built for application needs.

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

[0083] Meta-Object Facility (MOF): It is a specification proposed by OMG (Object Management Group) for defining metadata programming languages. The layered architecture of MOF includes M3-M0, which correspond 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 contains 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 other constructs.

[0084] Model-based systems engineering has become a technical trend in complex system design and has been gradually applied to a variety of fields. MBSE takes the model as the core and runs through the entire life cycle of system requirements, design, verification and confirmation, greatly improving the visualization, collaboration, automation and traceability of system design. These improvements make complex systems easier to understand, manage and optimize during the development process, while improving the communication efficiency and accuracy at each stage. However, the modeling languages ​​commonly used in the MBSE method are designed for different fields and development stages, and have their own unique syntax and semantics. This difference makes it difficult for them to seamlessly connect between different fields and stages.

[0085] In order to deal with the integration problem between multiple MBSE modeling languages, there are some attempts and solutions in the prior art, including: language conversion tools, model integration platforms, and modeling language meta-metamodels. Language conversion tools: used to automatically convert a model in a certain modeling language into a model in another language. Most of these tools achieve conversion between languages ​​at the grammatical level by writing proprietary conversion rules. Model integration platforms: Some MBSE tools provide an integrated environment to support collaborative modeling in multiple modeling languages. These tools allow users to use Systems Modeling Language (SysML), Architecture Analysis and Design Language (AADL), and Business Process Modeling and Notation (BPMN) in the same environment for modeling, and attempt to achieve model interoperability through tool-level integration. Modeling language meta-metamodel: Some platforms attempt to achieve cross-language model integration by defining a common meta-metamodel framework to map 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 problems still exist: Insufficient semantic interoperability: Although existing language conversion tools can achieve conversion at the syntax level to some extent, conversion between languages ​​such as SysML, BPMN, and AADL still faces great challenges at the semantic level. Simple syntax conversion may lead to semantic loss or misinterpretation; Lack of unified semantic standards: Since each language focuses on different fields and model perspectives, in actual projects, cross-domain modeling and verification often require the collaboration of multiple tools and platforms, resulting in complex workflows and difficult data synchronization. There is a lack of unified semantic standards between different modeling languages, and tool-level integration often fails to deeply resolve these semantic differences, increasing the complexity of cross-domain collaboration; Poor semantic consistency: Different modeling languages ​​have different semantic features and modeling paradigms. Even if the metamodels of these languages ​​are created through the meta-metamodel, the semantic differences between these languages ​​may lead to semantic inconsistency or loss in unified expression.

[0087] In response to the above problems, the unified description method of heterogeneous modeling languages ​​based on ontology provided in this application builds a unified semantic standard framework based on formal ontology and IOF-Core middle-level ontology, laying the foundation for the integration of heterogeneous MBSE modeling languages ​​corresponding to ontologies, and forming a set of standardized and extensible semantic standard frameworks. Then, under the framework, based on the GOPPRR-E meta-metamodel and MOF mechanism, a multi-architecture model ontology corresponding to the multi-architecture model built based on the heterogeneous MBSE modeling language is designed. Finally, based on the MOF mechanism, the mapping rules from multi-architecture models to ontologies are defined to achieve a unified semantic description of different modeling languages.

[0088] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. 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 to describe the common concepts and relationships in different architecture models. The collected heterogeneous modeling languages ​​are analyzed in depth, and the languages ​​are disassembled according to the element categories of the multi-architecture model ontology (such as classes, attributes, relationships, etc.). This process aims to identify the key elements in the modeling language, which will serve as the basis for subsequent mapping and unified description. Through this step, complex modeling languages ​​can be simplified 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 can be understood, mapping rules are the key to connecting the standard semantic architecture (multi-architecture model ontology) and the heterogeneous modeling language. These rules define how to correspond the target elements in the heterogeneous modeling language to the corresponding concepts in the multi-architecture model ontology. Applying these mapping rules, the decomposed target elements are mapped to the multi-architecture model ontology, and a unique element name is determined for each target element. This ensures that concepts in different modeling languages ​​can be described and compared under 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 the target elements, the last step is to unify the description of the heterogeneous modeling languages ​​based on the element names. This step aims to use the unified framework and terminology system provided by the multi-architecture model ontology to integrate the concepts and information in different modeling languages ​​into a consistent and easy-to-understand description. This unified description not only helps to eliminate barriers between different modeling languages, but also promotes communication and cooperation between different fields and projects.

[0101] The ontology-based unified description method of heterogeneous modeling languages ​​provided in this embodiment obtains 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, in 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 the middle-level ontology based on formal ontology and industrial ontology, and build a unified semantic standard framework.

[0104] It is understandable that a unified semantic standard framework is built based on the top-level ontology BFO and the middle-level ontology IOF-Core. BFO provides a common high-level semantic foundation, while IOF-Core provides middle-level semantic support for the industrial field. This framework will serve as the semantic alignment basis for different MBSE modeling languages ​​to ensure the consistency of cross-domain models in basic concepts and relationships.

[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 also be transferred and reused between cars during the design process. The middle-level ontology IOF-Core of the semantic standard framework 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 description information content entities, specified information content entities, instruction information content entities, measurement information content entities, as well as core contents 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] Understandably, under the unified semantic standard framework, based on the MOF mechanism and the GOPPRR-E meta-metamodel, the multi-architecture model domain ontology is designed, covering ontology elements such as classes, subclasses, instances, annotation attributes, and object attributes. Based on the GOPPRR-E meta-metamodel, the classes in the multi-architecture model domain ontology are constructed, corresponding to the modeling language meta-metamodel, covering the connection constraints between the model elements corresponding to the graph, object, attribute, point, relationship, role, and extension.

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

[0110] It can be understood that based on the designed multi-architecture model domain ontology and MOF mechanism, the mapping rules between the architecture model constructed by the heterogeneous MBSE modeling language and the multi-architecture model domain ontology are defined, and the heterogeneous modeling language is mapped into subclasses of seven major categories: graph, object, attribute, point, relationship, role, and connector. The model is mapped to an instance of the corresponding subclass. The relationship between the elements in the model is mapped to the object attributes of the corresponding class or instance. In addition, the inherent attributes of the model are mapped to the annotation attributes of the instance. This ensures that the semantic understanding corresponding to the heterogeneous modeling language is correct.

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

[0112] Understandably, it is necessary to first determine the correspondence between each heterogeneous MBSE (model-based system engineering) modeling language and the seven major subclasses (graphs, objects, attributes, nodes, relationships, roles, connectors) in the multi-architecture model domain ontology. This process usually involves a deep understanding of the syntax and semantics of each modeling language, and how the elements they use to describe the system architecture match the subclasses in the domain ontology.

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

[0114] It is understandable that after determining the mapping relationship between the modeling language and the subclass, the next thing to focus on is how to map the relationships between the various elements within the model to the object attributes in the domain ontology. These relationships may include connections, dependencies, inheritance, etc. between components. In the domain ontology, these relationships are usually expressed through object attributes.

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

[0116] It can be understood that, in addition to the relationship between elements, each element in the model may also have some inherent attributes, such as name, type, version, etc. These inherent attributes are usually expressed through annotation attributes in the domain ontology. Therefore, constructing the mapping relationship between inherent attributes and annotation attributes is to ensure that these inherent attributes of each element in the model can be correctly mapped to the corresponding annotation attributes in the domain ontology.

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

[0118] It is understandable that after completing the construction of the above mapping relationships, these mapping relationships need to be saved so that they can be easily used and referenced in subsequent work. This saving process may involve storing the mapping relationship in a database, generating documents or codes for mapping rules, and other forms. Regardless of the form used, the purpose is to ensure the accuracy and accessibility of the mapping relationship, thereby supporting subsequent work such as semantic understanding and model conversion of heterogeneous MBSE modeling languages.

[0119] The ontology-based heterogeneous modeling language unified description method provided in this embodiment builds a unified semantic standard framework by integrating the formal ontology and the industrial ontology casting middle-level ontology. Under this framework, a multi-architecture model ontology is designed using the meta-metamodel and meta-object mechanism. Furthermore, based on the meta-object mechanism, the specific rules for mapping the multi-architecture model to the ontology are clarified. This technology significantly improves the interoperability and data consistency between models, and provides 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, in this embodiment Figure 1 Based on the embodiment, a method for constructing a semantic standard framework is described, and the method includes:

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

[0122] Understandably, the basic framework is first extracted from two different ontology sources. The first basic framework comes from the formal ontology, which may be a more general or abstract ontology that provides the basic concepts and relationships required to build other ontologies. This basic framework may contain basic concepts such as entities, attributes, relationships, and the logical relationships between these concepts. The second basic framework comes from the industrial ontology casting mid-level ontology, which is a more specific and specialized ontology that focuses on the preset concepts and relationships of the foundry industry. This basic framework may contain professional terms and concepts related to casting processes, materials, equipment, processes, etc.

[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] It is understandable that after obtaining the first basic framework, it needs to be screened 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: Screening 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 can be understood, the first semantic framework is used as a guide to further filter the second basic framework. The purpose of this process is to extract the content related to the first semantic framework from the second basic framework to form a second semantic framework that is closely connected to the first semantic framework. This second semantic framework will contain preset concepts and relationships related to the foundry industry, but has been filtered to ensure that they are consistent with the common concepts and relationships in the first semantic framework.

[0129] S304: Construct 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] It can be understood that 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 corresponding items 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] It can be understood that the mapping relationship is used to fuse the first semantic framework and the second semantic framework to form a unified semantic standard framework. This fusion process may involve merging, reorganizing and expanding the concepts in the two frameworks to form a complete framework that contains both common concepts and preset concepts. This semantic standard framework will serve as the basis for subsequent semantic processing and ontology construction, helping us better understand and process semantic information related to the foundry industry.

[0134] The ontology-based heterogeneous modeling language unified description method provided in this embodiment obtains the basic framework of the formal ontology and the industrial ontology casting middle-level ontology, screens out the respective semantic frameworks, and constructs the mapping relationship between the two, and finally merges them into a unified semantic standard framework. This process improves the accuracy and interoperability of the ontology model 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, in this embodiment Figure 1 Based on the embodiment, a method for constructing a multi-architecture model ontology is described in detail, and the method includes:

[0136] S401: Determine ontology elements according to the semantic standard framework.

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

[0138] As can be understood, the semantic standard framework provides a benchmark for the construction of domain ontology, ensuring that all defined concepts and relationships are semantically consistent. Based on this framework, we determine the ontology elements, which are the basis for building domain ontology, including classes, subclasses, instances, annotation attributes, object attributes, etc. Ontology elements not only represent the entities and concepts in the model, but also clarify the categories and meanings of these entities and concepts in semantic description.

[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, which provides a description method at an abstract level. After determining the ontology elements, we use the meta-object mechanism to build a meta-model. The meta-model is a high-level representation of the domain ontology, which defines the structure and behavior of various elements in the model. By combining the ontology elements and the meta-object mechanism, we can ensure that the meta-model not only meets the requirements of the semantic standard framework, but also accurately expresses the concepts and relationships in the domain.

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

[0142] It can be understood that the meta-metamodel is a model that defines the metamodel, which 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 role 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 clear hierarchies and reasonable structures.

[0145] S405: Based on the defined class, an instance is created, 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 specific objects of these classes. Instances are specific elements in the metamodel, and they represent entities or concepts in the real world. By creating instances, we can concretize abstract concepts and relationships, making the model closer to actual application scenarios.

[0147] S406: Based on the attribute elements and the relationship elements, define the annotation attributes and the 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 attributes in the metamodel based on attribute elements (describing the characteristics of classes or instances) and relationship elements (describing the relationship between classes or instances). Annotation attributes provide additional descriptive information about classes and instances, which helps to understand their meaning and purpose; while object attributes describe the relationship between classes or instances, and are an important part of the model.

[0149] S407: Define connection constraints between metamodel elements according to the extended elements.

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

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

[0152] It is understandable that after completing the definition of the metamodel, we need to conduct a comprehensive inspection and verification process on it. This process includes syntax checking, semantic verification, consistency checking and other aspects, aiming to ensure that the metamodel conforms to the semantic standard framework and the requirements of the GOPPRR-E meta-metamodel. Through inspection and verification, we can obtain a multi-architecture model ontology with clear structure, accurate semantics and in line with actual needs.

[0153] The ontology-based heterogeneous modeling language unified description method provided in this embodiment indicates the semantic description category and meaning by determining the ontology elements under the semantic standard framework, constructs the metamodel using the metaobject mechanism, and defines the class, subclass, instance, annotation attribute, object attribute and connection constraint based on the first element of the metamodel, and finally obtains the multi-architecture model ontology after inspection and verification. This method effectively integrates the semantic information of multi-architecture models, improves the consistency and interoperability of the models, and provides strong support for the modeling and knowledge sharing of complex systems.

[0154] The following takes the intelligent electric vehicle automatic driving system model built based on the SysML modeling language as an example to describe the unified description method of the above-mentioned ontology-based heterogeneous modeling language. First, it is determined that the modeling language of the intelligent electric vehicle automatic driving system model is the SysML modeling language, and 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 type of diagram in SysML (such as use case diagram, requirement diagram, activity diagram, etc.) is mapped to a diagram class subclass of the multi-architecture model domain ontology. Instances of each diagram class are mapped to specific modeling language components. For example, a use case diagram instance in SysML will be mapped to a specific instance of a diagram class.

[0157] (2) Object class mapping: Objects in SysML (such as use cases, actors, requirements, etc.) are mapped to object class subclasses 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: The relationships in different diagrams in SysML (such as association relationships, derived relationships, and refined relationships) are mapped to the relationship class subclasses in the domain ontology. The specific instances of each relationship are mapped to instances of the relationship class in the domain ontology in the model. For example, the derived relationship in the 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 the relationship are mapped to subclasses of the role class. For example, in a use case diagram, the roles representing the start and end of the association relationship are mapped to 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 point class subclasses. 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, indicating the dependency and structural connection between modules.

[0163] (8) Annotation attribute mapping: used to describe the metadata of model elements in SysML (such as ID, type, version, etc.). The unique identifier (ID) and type (type) of each SysML element are mapped to a specific instance 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 property 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. The use case diagram contains association relationships, which are mapped to object properties such as "diagram contains objects" and "diagram contains relationships" and assigned to the corresponding element classes.

[0165] Through the above mapping rules, the elements in the SysML modeling language can be accurately mapped to the corresponding elements of the domain ontology, ensuring semantic consistency and interoperability. The mapping rules not only cover the grammatical elements in SysML, but also express the semantics of the annotation attributes and object attributes of the mapped ontology, ensuring semantic consistency between different modeling languages ​​and reducing semantic loss or misunderstanding in 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 automatic 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 display 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 requirement model of the autonomous driving system is mapped as an instance of the requirement graph class. Requirements: The requirements of the autonomous driving system are mapped as instances of the "requirements" object class. For example, "autonomous driving requirements" are mapped as instances of the "requirements" object class. Derivation relationship: The derivation relationship between the "autonomous driving requirements" and the "vehicle control" requirements is mapped as an instance of the "derived" relationship class to ensure the hierarchical association of the requirements. Constraints: The start and end of the "derived" 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 to an instance of the activity diagram class. Activity: The key activities in autonomous driving (including perception, decision-making, and control) are mapped to instances of the "activity" object class. Control flow: The process control between activities is mapped to 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 to an instance of the sequence diagram class. Message: The interaction messages between components in the autonomous driving system are mapped to an instance of the "message" object class. Lifeline: The behavior sequence and life cycle of the component are mapped to an instance of the "lifeline" object class, which represents the dynamic behavior of the system.

[0172] (6) Module definition diagram mapping: Module definition diagram: The autonomous driving system composition model is mapped to an instance of the module definition diagram class. Module: Each module of the autonomous driving system (such as 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, which describes the composition structure of the system.

[0173] (7) Internal module graph mapping: Internal module graph: The interface model inside the logical component of the autonomous driving system is mapped to an instance of the internal module definition graph class. Internal module: The internal structure of each logical component is mapped to 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 to the "camera submodule" and "radar submodule" instances of the "internal module" object class in the ontology. Port: The data transmission interface between the perception module and the decision module is mapped to 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 to an instance of the state machine diagram class. State: Various states in the autonomous driving system (including driving, parking, and obstacle avoidance) are mapped to instances of the "state" object class, which represent the behavior of the system in different situations. Transition: The transition between different states is mapped to an instance of the "transition" relationship class, which represents the switching logic between states.

[0175] (9) Parameter map: Parameter map: The parameter model of the physical components of the autonomous driving system is mapped to 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, will be mapped to instances of the attribute class "speed attribute", "acceleration attribute", and "battery power attribute" in the ontology. Parameter binding mapping: The relationship between the parameters in the perception module and the decision module is mapped to an instance of the relationship class "parameter binding relationship".

[0176] Figure 5 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] A 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 used 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 corresponding relationship between the standard semantic architecture and the heterogeneous modeling language;

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

[0181] Optionally, the device 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 cast the middle-level ontology;

[0183] The determination module 503 is further used 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 used 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 used to filter 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;

[0187] The processing module 502 is further used 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 used to construct 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;

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

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

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

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

[0193] The processing module 502 is further used 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 used to define classes and subclasses in the meta-model according to the object elements and the role elements;

[0195] The construction module 505 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;

[0196] The definition module 506 is further used 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 used to define connection constraints between the metamodel elements according to the extended elements;

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

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

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

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

[0202] The processing module 502 is further used 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 effect are similar, and this embodiment will not be described in detail here.

[0204] Figure 6 The present application provides a schematic diagram of a unified description of the structure of a device using 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] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

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

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

[0208] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

[0209] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or 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 above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general 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 a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: 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 only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[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 the function is implemented in the form of 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 part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0218] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0219] Finally, it should be noted that those skilled in the art will readily conceive of 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, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A unified description method of heterogeneous modeling language 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 the element categories of the 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 corresponding relationship between a standard semantic architecture and the heterogeneous modeling language; The heterogeneous modeling languages ​​are described uniformly according to the element names.

2. The method according to claim 1, characterized in that Before obtaining the heterogeneous modeling language used by the multi-architecture model, the method further includes: Casting middle-level ontology based on formal ontology and industrial ontology, and building a unified semantic standard framework; 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.

3. The method according to claim 2, characterized in that The middle-level ontology is cast based on the formal ontology and the industrial ontology, and a unified semantic standard framework is constructed, including: respectively obtaining a first basic framework of the formalized ontology and a second basic framework of the industrial ontology casting middle-level ontology; Screening 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 screened based on the semantic frame to obtain a second semantic frame; the second semantic frame is a content frame 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; The first semantic framework and the second semantic framework are fused according to the mapping relationship to obtain the semantic standard framework.

4. The method according to claim 2, characterized in that: Under the semantic standard framework, based on the meta-meta model 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; Based on the meta-object mechanism and the ontology elements, a meta-model is constructed; Acquire a first element of the meta-meta model, where the first element refers to element information included in the meta-meta model; The metamodel is mapped and defined according to the first element to obtain the multi-architecture model ontology.

5. The method according to claim 4, characterized in that 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. The mapping definition processing of the metamodel 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; According to the extended elements, defining connection constraints between the metamodel elements; The defined metamodel is checked and verified to obtain the multi-architecture model ontology.

6. The method according to claim 5, characterized in that The mapping rule of defining the multi-architecture model to the multi-architecture model ontology based on the meta-object mechanism includes: 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 attribute; 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.

7. A unified description device for heterogeneous modeling language based on ontology, characterized in that: include: An acquisition module is used to acquire the heterogeneous modeling language used by the multi-architecture model; A processing module, used for 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; 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 corresponding relationship between the standard semantic architecture and the heterogeneous modeling language; A description module is used to uniformly describe the heterogeneous modeling language according to the element names.

8. The device according to claim 7, characterized in that The device also includes: a construction module and a definition module; The construction module is used to build a unified semantic standard framework based on the formal ontology and the industrial ontology to cast the middle-level ontology; The determination module is further used 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.

9. 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 6.

10. 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 6 when executed by a processor.

Images