Automatic generation method of MBSE system model and AMESim simulation model

Abstract

According to the automatic generation method of the MBSE system model and the AMESim simulation model, the meta-model in the AMESim simulation model is designed based on a GOPPRR-E method, and the consistency of the MBSE system model and the AMESim simulation model in structure and semantics is ensured. And by defining a detailed ontology mapping rule, seamless conversion between the AMESim system model and the AMESim simulation model is realized. And meanwhile, a special automatic plug-in is developed, so that automatic generation from an MBSE system model to an AMESim simulation model can be realized according to a defined mapping rule and an AMESim meta-model.

Description

Technical Field

[0001] The invention relates to the technical field of system engineering, simulation and modeling, and complex system design, and in particular to a method for automatically generating an MBSE system model and an AMESim simulation model. Background Art

[0002] Model-based Systems Engineering (MBSE) is an engineering approach that uses models to support the design, development, verification, and maintenance of complex systems. Unlike traditional document-driven methods, MBSE describes all aspects of the system through a unified system model (such as SysML), providing full lifecycle support from requirements analysis to design verification. In the MBSE process, design and verification often rely on domain-specific physical simulation tools, such as AMESim. AMESim is an integrated platform for modeling and simulating multi-physical systems, especially suitable for dynamic performance simulation of hydraulic, control, electromechanical and other systems. With AMESim, engineers can simulate complex systems with high precision to verify the performance, stability, and safety of the system under various working conditions. By integrating the MBSE system model with the AMESim simulation model, engineers can achieve comprehensive verification of system functions and physical behaviors in the early stages of design, improving the accuracy, efficiency, and reliability of system design.

[0003] However, since the MBSE system model and the AMESim simulation model use different modeling languages ​​and tools, there are incompatibilities between the two in terms of data structure, model interface, file format, etc. For model integration, such differences can lead to loss or misunderstanding of information during transmission. At the same time, since MBSE models focus on the functions, structure, and requirements of the system, these models emphasize a high-level view of the system to facilitate stakeholders' understanding. AMESim models, on the other hand, focus on the dynamic response and behavior of the physical system, which is implemented through hydraulic, control, and mechanical models. There are significant differences in the modeling semantics of the two, which may lead to inconsistencies in the models at the system level and the physical level. In addition, the parameters in the MBSE system model more reflect the system's functions, performance indicators (such as flow, pressure range, and response time), and design constraints, while the AMESim model requires more precise physical parameters (such as pump displacement, liquid viscosity, and valve characteristics). When integrating MBSE and AMESim models, how to map abstract functional requirements to physical parameters is crucial to achieving consistency between the functional verification and physical simulation of the system.

[0004] There are some attempts and solutions in the prior art:

[0005] (1) Manual mapping and conversion: Currently, engineers usually rely on manual operations to build simulation models based on MBSE system models. Manual conversion requires engineers to understand and map the functional structure in the system design with the physical behavior in the simulation model. Due to the differences in model description methods, parameters, and logical relationships between different platforms, this process is complex and prone to errors, especially when it comes to large-scale complex systems. Due to the differences in model description methods, parameters, and logical relationships between different platforms, manual mapping and conversion is not only time-consuming and labor-intensive, but also difficult to ensure the accuracy and consistency of model conversion, and cannot meet the needs of rapid iteration and automated simulation in complex system design.

[0006] (2) Model converter: Some integrated tools support exporting SysML models to AMESim-compatible formats by developing model converters. The interface definitions of SysML and AMESim are gradually supported in integrated tools. However, since MBSE and AMESim use different modeling languages ​​and data structures, the converter may not be able to fully capture the differences between the two, and data and semantics may be lost or incomplete during the conversion process. This may cause distorted or inaccurate model behavior in AMESim simulation, making it difficult to verify the functionality of the system.

[0007] (3) Intermediate Model: In order to achieve better integration between the MBSE system model and the AMESim simulation model, some solutions have proposed the use of an intermediate model as a bridge. The intermediate model usually adopts a standardized representation method (such as FMI - Functional Mock-up Interface), which can convert the functional and structural information in the MBSE model into a format that can be understood by AMESim. In this process, the MBSE system model is first converted into an intermediate model, and then converted from the intermediate model to the AMESim model, reducing the data loss or semantic inconsistency problems that may occur during the direct conversion process. However, although the intermediate model method has improved the degree of automation of the conversion to a certain extent, since the intermediate model needs to bidirectionally support the modeling language and semantics of two different platforms, the cost of developing and maintaining the intermediate model is high, and there is still a risk of loss of accuracy and details.

[0008] (4) Unified model approach based on semantic standards: In recent years, with the development of semantic modeling technology, some researchers have proposed a model integration method based on unified semantic standards, using semantic languages ​​such as OWL (Web Ontology Language) to construct a shared ontology for MBSE system models and AMESim simulation models. This method aims to solve the problem of differences in model semantics by building a unified semantic layer to describe and align models on different platforms. By sharing the ontology, the model can transmit and interpret information more consistently, achieving cross-platform integration and verification. However, the unified model approach based on semantics is still in the research stage. The development of efficient semantic alignment algorithms and ontology mapping tools is its main technical difficulty, and its actual implementation in industrial applications still needs further verification.

[0009] Existing technologies support the integration of MBSE system models and AMESim simulation models to a certain extent, but the following problems still exist:

[0010] (1) Manual mapping and conversion

[0011] Complexity and error-proneness: The manual mapping and conversion process requires engineers to have a deep understanding of the semantics and structure of the MBSE system model and the AMESim simulation model. Especially when it comes to large-scale complex systems, this manual conversion process is both complex and error-prone.

[0012] Low efficiency: Manual operations are time-consuming and labor-intensive, and are difficult to adapt to the rapid iterations in complex system design. Especially in scenarios with high-frequency demand changes or system optimization, manual conversion cannot meet the needs of automated simulation.

[0013] Consistency issues: Due to human factors in the conversion process, inconsistencies may occur between models, especially when mapping between system functions and physical behaviors, which can easily lead to loss of important information or misunderstanding.

[0014] (2) Model Converter

[0015] Data loss and incompleteness: When converting SysML models to AMESim format, due to differences in modeling languages ​​and data structures, some data and semantics may be lost or incomplete during the conversion process. This will cause the AMESim simulation model to behave inaccurately and fail to fully verify system functions.

[0016] Insufficient conversion accuracy: Due to the different semantics of MBSE and AMESim, the converter cannot guarantee that all system parameters are accurately mapped between the two. Especially for complex physical characteristics, the model converter often cannot capture enough details, affecting the simulation accuracy.

[0017] (3) Intermediate Model

[0018] High development and maintenance costs: Although the integration method using intermediate models reduces the difficulty of direct conversion, creating and maintaining intermediate models that support two-way conversion requires additional development work, and as the complexity of the system increases, the maintenance cost will also increase significantly.

[0019] Risk of information loss: Although the intermediate model is designed to reduce the risk of data loss, it is essentially a form of conversion and the risk of information loss or inconsistency still exists.

[0020] (4) Methods based on semantic standards

[0021] Limitations of industrial applications: The unified model integration of semantic standards is still in the research stage. Although it can solve semantic differences in theory, there are great challenges in the implementation of this method in actual industrial applications, especially when developing efficient semantic alignment tools and algorithms.

[0022] In summary, the most pressing issues in the integration process of MBSE system models and AMESim simulation models are semantic inconsistency, data loss, and challenges in automated integration. Summary of the invention

[0023] In view of this, the present invention provides an automatic generation method of MBSE system model and AMESim simulation model, which can solve the problems of inconsistent semantics and data loss in model integration in the prior art, and realize efficient and automatic integration of MBSE system model to AMESim simulation model.

[0024] In order to solve the above technical problems, the present invention is implemented as follows.

[0025] A method for automatically generating an MBSE system model and an AMESim simulation model, comprising:

[0026] Step 1: Design the meta-model in the AMESim simulation model based on the GOPPRR-E method to ensure the consistency of the MBSE system model and the AMESim simulation model in structure and semantics;

[0027] The core elements of the AMESim simulation model are modeled using the GOPPRR-E method to obtain a meta-metamodel; based on the meta-metamodel, the AMESim metamodel corresponding to each library in AMESim is constructed based on the GOPPRR-E method, and the attributes and structure of the AMESim metamodel are defined;

[0028] Step 2: Define the mapping rules from MBSE system model to ontology and ontology to AMESim simulation model;

[0029] Step 3: Develop an automation plug-in for automatically extracting data and semantics from the MBSE system model to generate an ontology, and generate an AMESim simulation model according to the mapping rules.

[0030] Preferably, in step 1, the core elements in the AMESim simulation model are modeled using the GOPPRR-E method to obtain a meta-meta-model:

[0031] The core elements “Component” and “submodel” in AMESim are mapped to the “Object” object meta-metamodel in the GOPPRR-E method;

[0032] The core element “Connect A and B with a line” in AMESim is mapped to the “Relationship” relational meta-model in the GOPPRR-E method;

[0033] The core element “parameters” in AMESim is mapped to the “Property” attribute meta-metamodel in the GOPPRR-E method;

[0034] The core element "Variable" in AMESim is mapped as part of the "Property" attribute meta-model.

[0035] Preferably, in step 1, the AMESim metamodel corresponding to each library in AMESim constructed based on the GOPPRR-E method is:

[0036] The object metamodels corresponding to the mechanical library include "gravityicon", "zeroforcesource",

[0037] "zerospeedsource", "forcecon", "linearvcon", "linearxvfromvcon",

[0038] "linearvxcon", "mass_envelop";

[0039] The object metamodel corresponding to the hydraulic library includes "pump", "accumulators", "hydraulic tanks", "actuators", "filters", and "sensors";

[0040] The object metamodels corresponding to the control library include "sim_params", "runstats", "print_interval", "print_interval_signal", "timesync", "externinput", "super_enable",

[0041] "reset_outport_signal";

[0042] The corresponding point metamodels of supercomponent ports include "lshaft", "rshaft", "signal", "hflow", "pflow", and "rope";

[0043] The relationships between AMESim components correspond to the relational metamodel "connect".

[0044] Preferably, in step 1, the properties and structure of the AMESim metamodel are defined as follows: defining properties for each component, sub-model and super-component port of the AMESim metamodel to ensure that the behavior in the simulation meets expectations, and implementing the structure definition through the relationship and hierarchy between components; wherein

[0045] (1) Metamodel attribute definition

[0046] The mechanical library component properties include: Mass: used to describe the inertial characteristics of mechanical parts, the unit is usually kilograms; Damping Coefficient: Damping characteristics that affect dynamic response, the unit is Newton·second / meter; Stiffness: describes elastic characteristics, the unit is Newton / meter;

[0047] The properties of hydraulic library components include: Valve Rated Current: indicates the rated current obtained by the reversing valve during operation, which affects the opening amplitude and response time of the reversing valve, and the unit is milliampere; Valve Working Pressure: the pressure of the component in the working state, the unit is bar or MPa; Hydraulic Fluid Index: indicates the type of hydraulic fluid used by each component, which helps to create the same hydraulic environment; Density: the density of the hydraulic fluid, which affects the movement characteristics of the fluid, the unit is kilograms per cubic meter;

[0048] The control library component properties include signal gain value Value Of Gain: the signal is amplified or reduced through gain and then passed to the component; switch threshold Switch Threshold: the flow parameters of the control signal selection switch, etc.

[0049] Other common attributes include Component: the identifier of a component or model, which is convenient for reference in simulation; Description: a brief description of the function or purpose of the component; Version: identifies the version information of the model or component, which is convenient for management and update, etc.

[0050] These attributes are defined as attribute metamodels and configured to the corresponding components, submodels, and other object metamodels as well as supercomponents;

[0051] (2) Metamodel structure definition

[0052] Component hierarchy: Determine the hierarchical relationship of each component in the system and make it clear whether the component belongs to a component or a sub-model;

[0053] Connection and interaction: Use wires to define connections between components, i.e., relational metamodel; each connection relationship describes physical connectivity and specifies how fluids or signals are transmitted;

[0054] Modular design: Encapsulate common functions or subsystems into sub-models.

[0055] Preferably, the step 2 is:

[0056] Step 2.1: Based on the meta-metamodel-metamodel-model three-layer structure in the MOF standard, define the mapping rules from the MBSE system model to the ontology as follows:

[0057] (1) Meta-metamodel layer mapping: Map the GOPPRR-E meta-metamodel to the Graph, Object, Point, Property, Relationship, Role, and Connector classes in the ontology;

[0058] (2) Metamodel layer mapping: AMESim simulation model type is mapped to the subclass "AMESim_Diagram" of the "Graph" class; the relationship "connect" between the mechanical library object metamodel, hydraulic library object metamodel, control library object metamodel, super component port point metamodel, and AMESim components in AMESim; the relationship start and end between AMESim components are mapped to the subclasses of the corresponding Object, Point, Relationship, and Role classes; metamodel attributes are mapped to the subclasses of the Property class; the connection constraints between components, super components, and submodels are mapped to the subclasses of the Connector class;

[0059] (3) Model layer mapping: Create specific instances for each component based on the defined AMESim metamodel;

[0060] Step 2.2: Define the mapping rules from ontology to AMESim simulation model:

[0061] Mapping of ontology instances to AMESim models: Graph subclass instances are mapped to the overall representation of the AMESim simulation model; Object subclass instances are mapped to specific "Component" or "submodel" in the AMESim simulation model; Point subclass instances are mapped to specific ports in the AMESim simulation model, representing the connection points between components; Property subclass instances are mapped to specific parameters and variables of specific components in the AMESim simulation model; Relationship subclass instances are mapped to physical or logical connections between AMESim components, defining their interaction methods and dependencies, represented by lines; Role subclass instances are mapped to the terminals and starting points of lines between AMESim components, representing the direction of the relationship; Connector subclass instances are mapped to connection constraints in AMESim, defining the connection rules and restrictions between components;

[0062] This step maps the instances in the ontology to AMESim simulation models, which will be simulated through the AMESim simulation engine to ensure that the system behaves as expected in the simulation.

[0063] Preferably, the step 3 is:

[0064] The design automation plug-in consists of four functional modules: system model parsing module, model conversion module, ontology parsing module, and ontology conversion module;

[0065] The system model parsing module is responsible for parsing the MBSE system model file and extracting the system model information including the model structure, components, attributes and connection information; the model conversion module converts the parsed system model information into a structure that meets the ontology requirements according to the defined mapping rules and generates an ontology file; the ontology parsing module is responsible for loading and parsing the ontology file and extracting the class, attribute and instance information therein; the ontology conversion module converts the elements in the ontology into specific implementations in the AMESim simulation model according to the mapping rules between the ontology and the AMESim simulation model.

[0066] Beneficial effects:

[0067] (1) AMESim metamodel design: The AMESim metamodel design based on the GOPPRR-E (Graph, Object, Property, Point, Relationship, Role, Extension) method ensures the structural and semantic consistency between the MBSE system model and the AMESim simulation model. This metamodel not only solves the problem of semantic inconsistency, but also prevents information loss and misunderstanding during the integration process through standardized model alignment.

[0068] (2) Definition of ontology mapping rules: In order to achieve seamless conversion between system models and AMESim simulation models, the two are associated through the standardized semantics of the ontology. This association not only ensures the integrity and consistency of information during the model conversion process, but also avoids the understanding deviation caused by semantic differences. Ontology provides semantic support for multidisciplinary collaborative design and simulation by uniformly describing the concepts and constraints of different disciplines such as mechanics, hydraulics, and control. At the same time, as a domain knowledge base, the ontology can standardize the modeling process and contain the common semantics and rules of system modeling and simulation, thereby improving the reusability and extensibility of the model.

[0069] (3) Automated plug-in development: Develop a dedicated automated plug-in that can automatically generate the MBSE system model into the AMESim simulation model based on the defined mapping rules and the AMESim metamodel. This automated tool significantly improves integration efficiency, reduces the complexity and errors of manual conversion, and supports rapid iteration and optimization in system design.

[0070] (4) Although some conversion methods in the prior art have established mapping relationships, they are limited to structural conversion and metaclass definition in the mapping process. This application ensures accurate alignment of the system model and the simulation model in structure and semantics through AMESim metamodel design based on the GOPPRR-E (graph, object, property, point, relationship, role and extension) method, especially the semantic mapping between physical behavior and system function is more rigorous, avoiding information loss and simulation errors caused by inconsistent semantics. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 It is a flow chart of the present invention.

[0072] Figure 2 This is a structural diagram of the plug-in functional architecture.

[0073] Figure 3 This is the plug-in function module interface interaction diagram. DETAILED DESCRIPTION

[0074] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0075] Based on the above problems, the present invention proposes an ontology-based method for supporting the automatic generation of MBSE system models and AMESim simulation models, aiming to solve the problems of inconsistent semantics and data loss in model integration in the prior art, and at the same time achieve efficient and automated integration of MBSE system models and AMESim simulation models.

[0076] First, the AMESim simulation metamodel is designed based on the GOPPRR-E method to clarify the role and relationship of each component in the model, including 1) defining the basic elements of multi-physical systems such as hydraulic systems, control systems and mechanical systems, such as pumps, valves and actuators; 2) establishing the properties and structure of the AMESim metamodel to ensure that the physical behavior and functional requirements of all relevant elements can be correctly reflected in the model. Then, the mapping rules from 1) system model to ontology and 2) ontology to AMESim simulation model are defined. Finally, an automation plug-in is developed, which has the ability to 1) automatically extract data and semantics from the MBSE system model to generate ontology, and 2) generate AMESim simulation model according to predefined mapping rules. This achieves seamless integration and verification of MBSE system model to AMESim simulation model.

[0077] In GOPPRR-E (Graph, Object, Property, Point, Relationship, Role, Extension), a graph is a collection of entities such as objects, relationships, and roles, presented in a specific layout. Objects are entities that construct graphs. Properties are inherent properties of the metamodel graphs, objects, relationships, roles, and points. Points are additional ports of objects. Relationships refer to connections between points and / or objects. Roles are used to define the direction and form of expression at both ends of a relationship, and a relationship is associated with two roles. Extensions refer to constraints on which objects / points the roles at both ends of a relationship can connect to.

[0078] The specific implementation steps are as follows Figure 1 As shown:

[0079] Step 1: AMESim metamodel design

[0080] Step 1.1: AMESim metamodel definition based on GOPPRR-E meta-metamodel

[0081] In the AMESim simulation model, the core elements are modeled by the GOPPRR-E method and modeled as a meta-meta-model to achieve semantic mapping and integration of the system. Among them, the key mapping relationship is defined as follows:

[0082] The core elements in AMESim are "Component" and "submodel": These elements represent the components and submodels of the system in AMESim, and are mapped to the "Object" object meta-model in the GOPPRR-E method. Each component or submodel is regarded as an independent object with unique functions and properties.

[0083] The core element “Connect A and B with a line” in AMESim is used to represent the connection relationship between components, which is mapped to the “Relationship” meta-metamodel in the GOPPRR-E method, thereby defining the physical or logical connection between system components and ensuring that the interactivity and dependencies of different components in the simulation model are correctly expressed.

[0084] The core element of AMESim is "parameters": These parameters are used to define the specific characteristics of components, such as flow, pressure, etc., and are mapped to the "Property" attribute meta-metamodel in the GOPPRR-E method. Through the attribute meta-metamodel, each component can be assigned physical parameters related to its function to ensure that the simulation model has the correct physical behavior.

[0085] The core element "Variable" in AMESim: represents the dynamic changes of the system during the simulation process, such as time step, input and output variables, etc., mapped as part of the "Property" attribute meta-model. As a form of attribute, variables are used to describe the dynamic characteristics of components to ensure that the real-time state changes of the system can be captured during the simulation.

[0086] The mapping relationship at the meta-metamodel level ensures that the metamodel of the AMESim simulation model is consistent with the objects, relationships, attributes and other elements in the GOPPRR-E method, thereby reducing semantic inconsistency and data loss problems during the system integration process.

[0087] On this basis, based on the GOPPRR-E method and AMESim mechanical, hydraulic, control, super component and other libraries, the AMESim metamodel is designed on the basis of the meta-metamodel. Specifically, the components, super components and sub-models in each library are modeled into metamodels according to the meta-metamodel.

[0088] Among them, the object metamodels corresponding to the mechanical library include "gravityicon", "zeroforcesource", "zerospeedsource", "forcecon", "linearvcon", "linearxvfromvcon",

[0089] "linearvxcon", "mass_envelop", etc.;

[0090] The object metamodels corresponding to the hydraulic library include "pump", "accumulators", "hydraulic tanks", "actuators", "filters", "sensors", etc.

[0091] The object metamodels corresponding to the control library include "sim_params", "runstats", "print_interval", "print_interval_signal", "timesync", "externinput", "super_enable",

[0092] "reset_outport_signal", etc.

[0093] The corresponding point metamodels of the super component port include "lshaft", "rshaft", "signal", "hflow", "pflow", "rope", etc.

[0094] The relationships between AMESim components correspond to the relational metamodel "connect".

[0095] Step 1.2: AMESim metamodel attribute and structure definition

[0096] (1) Metamodel attribute definition

[0097] When building an AMESim metamodel, specific properties need to be defined for each component and submodel, as well as the supercomponent ports, to ensure that they behave as expected in the simulation.

[0098] Among them, the mechanical library component properties include mass (Mass): used to describe the inertial characteristics of mechanical parts, the unit is usually kilograms (kg); damping coefficient (Damping Coefficient): the damping characteristics that affect the dynamic response, the unit is Newton seconds / meter (Ns / m); stiffness (Stiffness): describes the elastic characteristics, the unit is Newton / meter (N / m), etc.

[0099] The properties of hydraulic library components include electromagnetic reversing valve working current (Valve Rated Current): indicates the rated current obtained by the reversing valve during operation, which affects the opening amplitude and response time of the reversing valve, and the unit is usually milliampere (mA); valve working pressure (Working Pressure): the pressure of the component in the working state, the unit is bar (bar) or megapascal (MPa); hydraulic oil index (Index of Hydraulic Fluid): indicates the type of hydraulic oil used by each component, assists in creating the same hydraulic environment; density (Density): the density of the hydraulic fluid, which affects the movement characteristics of the fluid, the unit is kilogram cubic meter (Kg / m3), etc.

[0100] The control library component properties include signal gain value (Value Of Gain): the signal is amplified or reduced by gain and then passed to the component; switch threshold (Switch Threshold): the flow parameter of the control signal selection switch, etc. Other common properties include component (Component): the identifier of the component or model, which is convenient for reference in simulation; description (Description): a brief description of the function or purpose of the component; version (Version): identifies the version information of the model or component, which is convenient for management and update, etc.

[0101] These attributes are defined as attribute metamodels and configured to the corresponding components, submodels, object metamodels, and supercomponents.

[0102] (2) Metamodel structure definition

[0103] In AMESim, the structure is defined through the relationship and hierarchy between components. The specific steps are as follows:

[0104] ●Component hierarchy: Determine the hierarchical relationship of each component in the system, and clarify which components are main components and which are sub-models. For example, the main components of a hydraulic system may be pumps and cylinders, and the cylinder can be further decomposed into sub-components such as pistons and seals.

[0105] ● Connection and interaction: Use lines to define the connection between components (i.e., relational metamodel). Each connection relationship should not only describe the physical connectivity, but also clarify the transmission method of fluid or signal (such as flow direction, signal type, etc., i.e., the information transmitted on the point metamodel).

[0106] ● Modular design: Encapsulate common functions or subsystems into sub-models to improve the reusability of the model. For example, designing a standard hydraulic cylinder sub-model can be reused in different systems to reduce development costs.

[0107] Step 2: Ontology mapping rule definition

[0108] Step 2.1: System model to ontology mapping rule definition

[0109] In order to achieve seamless conversion between system models and AMESim simulation models, the two are linked through the standardized semantics of the ontology. This association not only ensures the integrity and consistency of information during model conversion, but also avoids the understanding deviation caused by semantic differences. The ontology provides semantic support for multidisciplinary collaborative design and simulation by uniformly describing the concepts and constraints of different disciplines such as mechanics, hydraulics, and control. At the same time, as a domain knowledge base, the ontology can standardize the modeling process and contain the common semantics and rules of system modeling and simulation, thereby improving the reusability and extensibility of the model.

[0110] Based on the meta-metamodel-metamodel-model three-layer structure in the MOF (Meta-Object Facility) standard, the mapping rules from system model to ontology are defined as follows:

[0111] (1) Meta-metamodel layer mapping: Map the GOPPRR-E meta-metamodel to the Graph, Object, Point, Property, Relationship, Role, and Connector classes in the ontology;

[0112] (2) Metamodel layer mapping: AMESim simulation model type is mapped to the subclass "AMESim_Diagram" of the "Graph" class. The mechanical library object metamodel "gravityicon" in AMESim,

[0113] "zeroforcesource", "zerospeedsource", "forcecon", "linearvcon",

[0114] "linearxvfromvcon", "linearvxcon", "mass_envelop", etc.; hydraulic library object metamodel "pump", "accumulators", "hydraulic tanks", "actuators", "filters", "sensors", etc.; control library object metamodel "sim_params", "runstats", "print_interval", "print_interval_signal", "timesync", "externinput", "super_enable",

[0115] "reset_outport_signal", etc.; metamodels of supercomponent port points "lshaft", "rshaft", "signal", "hflow", "pflow", "rope", etc.; the relationship between AMESim components "connect"; the relationship start and end between AMESim components; mapped to the subclasses (subClass) of the corresponding Object, Point, Relationship, Role classes (Class). Metamodel attributes are mapped to the subclasses (subClass) of the Property class (Class). Connection constraints between components / supercomponents / submodels are mapped to the subclasses (subClass) of the Connector class (Class).

[0116] (3) Model layer mapping: Create specific instances for each component based on the defined metamodel. For example, the specific instance of a hydraulic pump can be defined as "pump1", and its properties such as flow and pressure will be assigned. In the model, the connection relationship between components will be implemented based on the definition of the metamodel layer. Through the instantiation of the "connect" relationship, the physical or logical connection between each component is defined. In the model layer, dynamic behavior is described by changes in properties and states. For example, changes in fluid flow will affect the output flow of the pump, and these dynamic properties will be consistent with the Property class instance. Finally, the instances in the model layer will be used to perform simulations, by calling the AMESim simulation engine to simulate the behavior of the system under specific conditions.

[0117] Step 2.2: Definition of mapping rules from ontology to AMESim simulation model

[0118] Based on the above AMESim metamodel definition and the mapping rule definition from system model to ontology, the mapping rules from ontology to simulation model are defined as follows:

[0119] (1) Mapping of ontology instances to AMESim models

[0120] Instances of the Graph subclass are mapped to the overall representation of the AMESim simulation model. Instances of the Object subclass are mapped to specific "Components" or "submodels" in the AMESim model, ensuring that each object has unique functions and properties in the simulation model. Instances of the Point subclass are mapped to specific ports in the AMESim model, representing connection points between components, such as input and output ports. Instances of the Property subclass are mapped to specific parameters and variables of specific components in the AMESim model, such as flow, pressure, mass, etc., to ensure that the model has correct physical properties. Instances of the Relationship subclass are mapped to physical or logical connections between components, defining their interaction methods and dependencies, represented by lines. Instances of the Role subclass are mapped to the terminals and starting points of lines between AMESim components, indicating the direction of the relationship. Instances of the Connector subclass are mapped to connection constraints in AMESim, defining connection rules and restrictions between components.

[0121] Finally, the instances in the ontology are mapped to AMESim simulation models, which will be simulated by the AMESim simulation engine to ensure that the system behaves as expected under specific conditions.

[0122] Step 3: Automated plugin development

[0123] Step 3.1 Plugin design and function definition

[0124] Step 3.1.1 Functional Requirements Analysis

[0125] Functional requirements analysis will clarify the main functions and performance standards required by the plug-in. Specific contents include:

[0126] (1) The plug-in can accurately parse the system model structure and attributes. (2) The plug-in can automatically generate a unified ontology from the system model, thereby achieving a unified description of the system model semantics. (3) The plug-in can accurately parse the ontology semantic information. (4) The plug-in can automatically generate an AMESim simulation model from the ontology, thereby enabling the simulation engine to be called in AMESim, executing simulations and analyzing results, so that users can evaluate system performance.

[0127] Step 3.1.2 Plugin architecture design

[0128] Design the functional architecture of the plug-in to ensure the collaboration and data flow between the various functional modules. The automation plug-in is mainly composed of four functional modules: system model parsing module, model conversion module, ontology parsing module, and ontology conversion module. Figure 2As shown. The system model parsing module is responsible for parsing the system model file and extracting the model's structure, components, attributes and connection information; the model conversion module converts the parsed system model information into a structure that meets the requirements of the ontology according to the predefined mapping rules; the ontology parsing module is responsible for loading and parsing the ontology file and extracting the class, attribute and instance information therein for subsequent model conversion; the ontology conversion module converts the elements in the ontology into specific implementations in the AMESim simulation model according to the mapping rules between the ontology and the AMESim simulation model.

[0129] Step 3.2 Plugin development and testing

[0130] Step 3.2.1 Development environment setup

[0131] First, configure the environment, determine that the integrated development environment used is Eclipse, install Java SDK and Python environment, import APIDOM for XML parsing, OWLAPI or Apache Jena for ontology processing. Then, select Java as the main programming language to design and develop the functions required by the system model parsing module, model conversion module, ontology parsing module, and ontology conversion module. Select Python as the auxiliary programming language, use Java to realize the generation of python script code from ontology to AMESim simulation model, and further generate AMESim simulation model by executing the python script code of AMESim simulation model.

[0132] Step 3.2.2 Function Implementation

[0133] (1) Module development: System model parsing module: implements the system model parsing function and parses out all the information of the model. Model conversion module: defines the mapping logic at the code level based on the mapping rules and converts the system model into ontology elements, including creating classes, attributes, relationships, and instances. Ontology parsing module: implements the loading and parsing of ontology files and extracts information such as classes, instances, and attributes. Ontology conversion module: converts ontology elements into the python script file of the AMESim model according to the mapping rules and implements it by executing the python script file.

[0134] (2) Interface design: define the interfaces between modules to ensure smooth data transmission and decoupling between modules, and facilitate subsequent functional expansion. Figure 3As shown, the specific contents are as follows: the system model parsing module transmits the parsed system model information to the model conversion module, the model conversion module converts it into ontology and transmits it to the ontology parsing module, the ontology parsing module transmits the parsed ontology information to the ontology conversion module, the ontology conversion module generates a python script file of the AMESim model, and implements it by executing the python script file.

[0135] (3) Exception handling: Implement a comprehensive error handling mechanism to ensure that various exceptions can be captured and handled during the parsing or conversion process, and provide friendly error messages.

[0136] The above specific embodiments only describe the design principle of the present invention. The shapes and names of the components in the description may be different and are not limited. Therefore, those skilled in the art in the field of the present invention may modify or replace the technical solutions recorded in the above embodiments; and these modifications and replacements do not deviate from the creative purpose and technical solutions of the present invention and should all fall within the protection scope of the present invention.

Claims

1. A method for automatically generating an MBSE system model and an AMESim simulation model, characterized in that: include: Step 1: Design the meta-model in the AMESim simulation model based on the GOPPRR-E method to ensure the consistency of the MBSE system model and the AMESim simulation model in structure and semantics; The core elements of the AMESim simulation model are modeled using the GOPPRR-E method to obtain a meta-metamodel; based on the meta-metamodel, the AMESim metamodel corresponding to each library in AMESim is constructed based on the GOPPRR-E method, and the attributes and structure of the AMESim metamodel are defined; Step 2: Define the mapping rules from MBSE system model to ontology and ontology to AMESim simulation model; Step 3: Develop an automation plug-in for automatically extracting data and semantics from the MBSE system model to generate an ontology, and generate an AMESim simulation model according to the mapping rules.

2. The method for automatically generating an MBSE system model and an AMESim simulation model according to claim 1, characterized in that: In step 1, the core elements in the AMESim simulation model are modeled using the GOPPRR-E method to obtain the meta-meta-model: The core elements "Component" and "submodel" in AMESim are mapped to the "Object" object meta-metamodel in the GOPPRR-E method; The core element "Connect A and B with a line" in AMESim is mapped to the "Relationship" relational meta-model in the GOPPRR-E method; The core element "parameters" in AMESim is mapped to the "Property" attribute meta-metamodel in the GOPPRR-E method; The core element "Variable" in AMESim is mapped as part of the "Property" attribute meta-model.

3. The method for automatically generating an MBSE system model and an AMESim simulation model as claimed in claim 2, characterized in that: In step 1, the AMESim metamodel corresponding to each library in AMESim built based on the GOPPRR-E method is: The object metamodels corresponding to the mechanical library include "gravityicon", "zeroforcesource", "zerospeedsource", "forcecon", "linearvcon", "linearxvfromvcon", "linearvxcon", "mass_envelop"; The object metamodel corresponding to the hydraulic library includes "pump", "accumulators", "hydraulic tanks", "actuators", "filters", and "sensors"; The object metamodels corresponding to the control library include "sim_params", "runstats", "print_interval", "print_interval_signal", "timesync", "externinput", "super_enable", "reset_outport_signal"; The corresponding point metamodels of super component ports include "lshaft", "rshaft", "signal", "hflow", "pflow", and "rope"; The relationships between AMESim components correspond to the relational metamodel "connect".

4. The method for automatically generating an MBSE system model and an AMESim simulation model as claimed in claim 3, characterized in that: In step 1, the properties and structure of the AMESim metamodel are defined as follows: defining properties for each component, submodel, and supercomponent port of the AMESim metamodel to ensure that the behavior in the simulation meets expectations, and implementing the structure definition through the relationships and hierarchies between components; in (1) Metamodel attribute definition The mechanical library component properties include: Mass: used to describe the inertial characteristics of mechanical parts, the unit is usually kilograms; Damping Coefficient: Damping characteristics that affect dynamic response, the unit is Newton·second / meter; Stiffness: describes elastic characteristics, the unit is Newton / meter; The properties of hydraulic library components include: Valve Rated Current: indicates the rated current obtained by the reversing valve during operation, which affects the opening amplitude and response time of the reversing valve, and the unit is milliampere; Valve Working Pressure: the pressure of the component in the working state, the unit is bar or MPa; Hydraulic Fluid Index: indicates the type of hydraulic fluid used by each component, which helps to create the same hydraulic environment; Density: the density of the hydraulic fluid, which affects the movement characteristics of the fluid, the unit is kilograms per cubic meter; The control library component properties include signal gain value Value Of Gain: the signal is amplified or reduced through gain and then passed to the component; switch threshold Switch Threshold: the flow parameters of the control signal selection switch, etc. Other common attributes include Component: the identifier of a component or model, which is convenient for reference in simulation; Description: a brief description of the function or purpose of the component; Version: identifies the version information of the model or component, which is convenient for management and update, etc. These attributes are defined as attribute metamodels and configured to the corresponding components, submodels, and other object metamodels as well as supercomponents; (2) Metamodel structure definition Component hierarchy: Determine the hierarchical relationship of each component in the system and make it clear whether the component belongs to a component or a sub-model; Connection and interaction: Use wires to define connections between components, i.e., relational metamodel; each connection relationship describes physical connectivity and specifies how fluids or signals are transmitted; Modular design: Encapsulate common functions or subsystems into sub-models.

5. The method for automatically generating an MBSE system model and an AMESim simulation model as claimed in claim 3, characterized in that: The step 2 is: Step 2.1: Based on the meta-metamodel-metamodel-model three-layer structure in the MOF standard, define the mapping rules from the MBSE system model to the ontology as follows: (1) Meta-metamodel layer mapping: Map the GOPPRR-E meta-metamodel to the Graph, Object, Point, Property, Relationship, Role, and Connector classes in the ontology; (2) Metamodel layer mapping: AMESim simulation model type is mapped to the subclass "AMESim_Diagram" of the "Graph" class; the relationship between the mechanical library object metamodel, hydraulic library object metamodel, control library object metamodel, super component port point metamodel, and AMESim components in AMESim "connect"; the relationship start and end between AMESim components are mapped to the subclasses of the corresponding Object, Point, Relationship, and Role classes; the metamodel attributes are mapped to the subclasses of the Property class; the connection constraints between components, supercomponents, and submodels are mapped to the subclasses of the Connector class; (3) Model layer mapping: Create specific instances for each component based on the defined AMESim metamodel; Step 2.2: Define the mapping rules from ontology to AMESim simulation model: Mapping of ontology instances to AMESim models: Graph subclass instances are mapped to the overall representation of the AMESim simulation model; Object subclass instances are mapped to specific "Component" or "submodel" in the AMESim simulation model; Point subclass instances are mapped to specific ports in the AMESim simulation model, representing the connection points between components; Property subclass instances are mapped to specific parameters and variables of specific components in the AMESim simulation model; Relationship subclass instances are mapped to physical or logical connections between AMESim components, defining their interaction methods and dependencies, represented by lines; Instances of the Role subclass are mapped to the terminals and starting points of the connections between AMESim components, indicating the direction of the relationship; instances of the Connector subclass are mapped to connection constraints in AMESim, defining the connection rules and restrictions between components; This step maps the instances in the ontology to AMESim simulation models, which will be simulated through the AMESim simulation engine to ensure that the system behaves as expected in the simulation.

6. The method for automatically generating an MBSE system model and an AMESim simulation model according to claim 1, characterized in that: The step 3 is: The design automation plug-in consists of four functional modules: system model parsing module, model conversion module, ontology parsing module, and ontology conversion module; The system model parsing module is responsible for parsing the MBSE system model file and extracting the system model information including the model structure, components, attributes and connection information; the model conversion module converts the parsed system model information into a structure that meets the ontology requirements according to the defined mapping rules and generates an ontology file; the ontology parsing module is responsible for loading and parsing the ontology file and extracting the class, attribute and instance information therein; the ontology conversion module converts the elements in the ontology into specific implementations in the AMESim simulation model according to the mapping rules between the ontology and the AMESim simulation model.

Images