A multi-domain model integration method based on semantic components

Abstract

The application discloses a multi-field model integration method based on semantic components, and belongs to the technical field of complex system modeling and simulation, which comprises the following steps: defining the abstract semantics of components by using a four-layer meta-model architecture, including core entities such as components, attributes, parameters, ports, connectors and field models; abstracting integration elements such as input ports, output ports, parameters, metrics and restrictions from field languages, expressing the model integration elements by using meta-models, and defining four types of mapping relationships, i.e., dynamic port mapping, signal port mapping, parameter mapping and structure interface mapping; establishing the relationship between the components and the integration elements, defining the encapsulation specification of specific field models, and storing the components in the form of standardized compressed packages. The application uniformly expresses the component semantics and the integration relationship by using the meta-model, supports multi-fidelity model encapsulation and assembly, effectively solves the integration problem of multi-disciplinary heterogeneous models in cyber-physical systems, and significantly improves the reusability of the models and the system design efficiency.

Description

Technical Field

[0001] This invention belongs to the field of complex system modeling and simulation technology, specifically involving a multi-domain model integration method based on semantic components. This is a multi-domain model integration technology for Cyber-Physical Systems (CPS), which is particularly suitable for the unified semantic description, encapsulation, assembly and simulation verification of heterogeneous models from multiple disciplines such as mechanics, electronics, hydraulics, control, thermodynamics, gas, electromagnetics and fluid. Background Technology

[0002] Cyber-physical systems (CPS) are complex systems that deeply integrate computing, communication, and physical processes, and are widely used in fields such as intelligent transportation, aerospace, smart manufacturing, smart grids, and medical devices. The engineering development of CPS involves multiple disciplines, each typically using different modeling languages ​​and tools.

[0003] In the field of geometry: using CAD tools (such as Creo, CATIA) to create three-dimensional geometric models to describe the shape, assembly relationships and physical properties of parts;

[0004] In the field of dynamics: Modelica is used to build multi-physics domain behavioral models to describe energy transfer processes such as mechanical, electrical, hydraulic, and thermodynamic processes;

[0005] In the cyber domain: use Simulink / Stateflow to build control logic models and describe controller algorithms, state machines, and signal processing flows.

[0006] These models are heterogeneous and isolated, lacking a unified integration mechanism. Each model has its own independent syntax, semantics, and toolchain, leading to difficulties in system-level design and analysis. Specific problems include:

[0007] Semantic gap: Different domain models express the same physical quantity (such as force, voltage, temperature) in inconsistent ways;

[0008] Interface mismatch: The connection points (ports) between models lack a unified standard in terms of type, direction, and unit;

[0009] Parameter dispersion: Parameters of the same component (such as mass and moment of inertia) are repeatedly defined in multiple models, making it difficult to maintain consistency;

[0010] Difficulty in reuse: Existing model assets cannot be reused across projects and teams in a standardized manner.

[0011] Existing model ensemble methods (such as Model-Driven Architecture (MDA)) are mostly based on the Unified Modeling Language (UML), but their low level of abstraction makes it difficult to express the deep semantics of specific domains. While Model Ensemble Computation (MIC) provides a domain-oriented modeling approach, it lacks standardized mechanisms for expressing and encapsulating the semantics of multi-domain models at the component level. Therefore, there is an urgent need for a technology that can uniformly describe, encapsulate, and assemble multi-domain models. Summary of the Invention

[0012] This invention addresses the shortcomings of existing technologies in multi-domain model integration, such as heterogeneity, semantic inconsistency, and integration difficulties. It provides a multi-domain model integration method based on semantic components. By defining the abstract semantics of components through meta-models, a mapping relationship is established between components and multi-disciplinary models, enabling efficient encapsulation, assembly, and reuse of heterogeneous models.

[0013] The multi-domain model integration method based on semantic components described in this invention includes the following three core steps, each of which further comprises multiple sub-steps:

[0014] S110, Use a meta-model to define the abstract semantics of the component. The meta-model adopts a four-layer architecture and includes at least components, attributes, parameters, ports, connectors, and domain models and their static semantic constraints.

[0015] S120 abstracts integration elements such as input ports, output ports, parameters, metrics, and constraints from the domain language, uses meta-models to express model integration elements, and defines four types of mapping relationships: power port mapping, signal port mapping, parameter mapping, and structural interface mapping.

[0016] S130 establishes the relationship between components and integrated elements based on the component semantics defined in S110 and the mapping relationship established in S120, defines the domain model encapsulation structure to encapsulate the domain model, and stores the components in a standardized compressed package format.

[0017] Beneficial effects:

[0018] Semantic consistency: The four-layer meta-model unifies the expression of component semantics, eliminating the semantic gap between multi-domain models;

[0019] Heterogeneous integration capability: Supports unified encapsulation and assembly of models from multiple domains such as CAD, Modelica, and Simulink, and can be extended to more domains;

[0020] High reusability: Components are stored in standardized .acm packages, supporting import and export across projects, teams, and tools;

[0021] Parameter consistency: Through parameter mapping mechanisms, ensure that the parameters of the same component remain consistent across all domain models;

[0022] Multi-fidelity support: The same component can contain domain models of multiple fidelities to adapt to different needs in the early stages of design (rapid iteration) and the later stages (precise verification);

[0023] Scalability: The meta-model architecture supports future expansion to fields such as manufacturing, embedded software, and electromagnetic compatibility. Attached Figure Description

[0024] Figure 1 This is a diagram illustrating the overall architecture of the multi-domain model integration method based on semantic components described in this invention.

[0025] Figure 2 This is an example of a domain metamodel;

[0026] Figure 3 A mapping diagram showing the relationship between components and multidisciplinary models (CAD, Modelica, Simulink);

[0027] Figure 4 This is a schematic diagram of the component encapsulation package (.acm).

[0028] Figure 5 For port static constraint semantics;

[0029] Figure 6 This is a schematic diagram of the component combination. Detailed Implementation

[0030] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0031] This invention provides a method for integrating multi-domain models based on semantic components. Figure 1 The overall architecture diagram of this method is shown. (For example...) Figure 1 As shown, component A and component B are connected through component ports. The domain models A and B, encapsulated within each component, are connected via interfaces to achieve parameter / interface mapping. The source files associated with the domain models can also be encapsulated within the components. Through the semantic mapping relationship of the interface connection, the combination and transformation of domain models within the components are realized.

[0032] The method includes:

[0033] S110, Use a meta-model to define the abstract semantics of the component. The meta-model adopts a four-layer architecture and includes at least core entities such as components, attributes, parameters, ports, connectors, and domain models, as well as their static semantic constraints.

[0034] S110-1, Establish a four-layer meta-modeling architecture;

[0035] This invention employs a four-layer meta-modeling architecture to ensure the hierarchy and scalability of semantic definitions:

[0036] Meta-model layer (M3): Defines and describes the basic construction of the meta-model, including Atom, Model, Connection, Reference, Inheritance, etc.

[0037] Metamodel layer (M2): Defines the semantic framework of cyber-physical components, including component type, port type, parameter type, attribute type, domain model reference, etc.

[0038] Model layer (M1): Specific component instances built by the user, such as engine components and battery components;

[0039] User object layer (M0): Runtime simulation instances or physical entities.

[0040] S110-2, Define the core entities of the metamodel;

[0041] Define the following core entities and their relationships at the metamodel layer, for example: Figure 3 :

[0042] Component: The atomic building block of a system, possessing independent identity, interface, and behavior;

[0043] Properties: Inherent characteristics of a component (such as quality, material, efficiency), which cannot be directly modified by the user;

[0044] Parameters: Variable characteristics of a component (such as length, gain coefficient) that support design space exploration;

[0045] Port: The point of interaction between a component and the outside world, divided into power ports and signal ports; power ports refer to ports that transmit physical energy (force, voltage, flow, etc.), while signal ports refer to interfaces that transmit information / data;

[0046] Connector: An aggregation of multiple ports used to simplify the connection of complex interfaces;

[0047] Domain Model: Defines the meta-model required for integrating the domain models, defining model elements and relationships using a standard modeling language (such as UML). Taking Modelica as an example, it defines parameters (ModelicaParameter), connectors (ModelicaConnector), constraints (Limitcheck), environment (Environment), reaffirmations (ModelicaRedeclare), model types (ModelicaModelType), parameter interface mappings (ModelParameterPortMap), and relationships such as composition (solid diamond arrow), inheritance (hollow triangle arrow), and connection (no arrow). Examples are shown below. Figure 2 .

[0048] S110-3, Define static semantic constraints;

[0049] The metamodel also needs to define static semantic constraints for components, for example... Figure 5 ,For example:

[0050] Each component must contain at least one physical port or signal port;

[0051] Power ports can only be connected to power ports of the same type (e.g., rotary to rotary, electrical to electrical).

[0052] The connection direction of the signal port must comply with the causal constraint, that is, the output port can only be connected to the input port (output → input).

[0053] Parameter names within the same component must be unique.

[0054] These constraints are described using OCL (Object Constraint Language) or a similar formal language and embedded in the metamodel.

[0055] S120 abstracts integration elements such as input ports, output ports, parameters, metrics, and constraints from the domain language, uses meta-models to express model integration elements, and defines four types of mapping relationships: power port mapping, signal port mapping, parameter mapping, and structural interface mapping.

[0056] S120-1, Extracting multi-domain model integration elements;

[0057] To avoid integration difficulties caused by the complexity of domain languages, this invention extracts only the core elements related to integration from each domain model:

[0058] Input Port: An interface for receiving external signals, such as Simulink's Inport and Modelica's Input.

[0059] Output Port: An interface for sending signals outwards, such as Simulink's Output and Modelica's Output.

[0060] Parameter: Configurable design variables, such as parameters in Modelica and drive dimensions in CAD;

[0061] Metric: Performance metrics that can be observed after simulation, such as maximum stress, torque output, and peak temperature.

[0062] Limit: Constraints that a component must meet, such as maximum rotational speed, upper temperature limit, and stress limit.

[0063] S120-2, Define the meta-model mapping relationship;

[0064] This invention defines four basic mapping relationships to connect component-level semantics with domain model-level semantics: the power port mapping defines the equivalence relationship between the component's power port and Modelica's electrical, mechanical, thermodynamic, hydraulic, and multibody ports in terms of potential and flow variables; the signal port mapping defines the numerical transfer relationship between the component's signal port and Modelica or Simulink signal ports; the parameter mapping defines the automatic overriding relationship between component parameters and domain model parameters; and the structural interface mapping defines the alignment relationship between the component's coordinate system, axes, surfaces, points, and the CAD model's datum.

[0065] PowerPortMap: Maps Modelica's electrical, mechanical, thermodynamic, hydraulic, and other power ports to a unified power port for the component;

[0066] SignalPortMap: Maps signal ports in Modelica or Simulink to signal ports of components;

[0067] ParameterPortMap: Associates the parameters of a component with the parameters of the domain model, enabling automatic parameter propagation;

[0068] Structural Interface Map: Maps the datum (axis, surface, point, coordinate system) of a CAD model to the structural interface of a component.

[0069] S120-3, Detailed semantics of port mapping;

[0070] Taking Modelica electrical port mapping as an example:

[0071] In Modelica, ElectricalPin contains two variables: potential variable v (voltage) and current variable i (current).

[0072] The component's ElectricalPowerPort also defines potential and current; ElectricalPowerPort is a custom unified electrical port type used to abstractly express voltage (potential) and current (current) at the component level in order to establish a mapping relationship with Modelica's ElectricalPin (which also defines v and i).

[0073] The mapping relationship is defined as follows: v_component = v_modelica, i_component = i_modelica. Here, v_component is the voltage value (potential variable) defined by the component, v_modelica is the voltage value in the Modelica electrical pin, i_component is the current value (current variable) defined by the component, and i_modelica is the current value in the Modelica electrical pin.

[0074] Both ElectricalPin and ElectricalPowerPort share a basic data structure: a connector containing two variables.

[0075] modelica

[0076] connector ElectricalPin

[0077] Voltage v; / / Potential variable, i.e., voltage

[0078] flow Current i; / / Flow variable, i.e., current, qualified by 'flow'.

[0079] end ElectricalPin;

[0080] By declaring the flow variable, Modelica will automatically generate an equation based on Kirchhoff's laws that makes the sum of all currents at the connection zero.

[0081] For signal ports, the mapping convention is: signal_component = signal_modelica. signal_component is the value of the component signal port, and signal_modelica is the value of the Modelica signal port.

[0082] In the Modelica standard library, signal ports are typically defined as connectors containing one or more signal variables. For example, the definition of RealOutput is simplified to:

[0083] modelica

[0084] connector RealOutput = output Real; (Defines the signal port as a real output number);

[0085] Transformation rules: The mapping rules are also direct numerical equations:

[0086] modelica

[0087] signal_component = signal_modelica; (component signal value equals model signal value);

[0088] This ensures that signal values ​​calculated internally by a component are accurately passed to downstream components, and vice versa. In some integration scenarios (such as interacting with C code), this mapping may also involve automatic data type conversion, such as mapping a Modelica Real array to a C language double array.

[0089] This mapping solves the problem of decoupling the algorithm from the physical model. The control logic is usually modeled as a pure signal flow system, connected to the physical model through signal ports, to control physical quantities such as motor speed and valve opening.

[0090] For structural interfaces, the mapping specification is: the coordinate system of the component is aligned with the reference coordinate system of the CAD model, and the relative transformation matrix is ​​automatically calculated during connection.

[0091] When components are connected, the system will automatically perform the following calculations:

[0092] Calculate the relative transformation: Based on the absolute spatial orientation of the two components (R1, R2), calculate the relative transformation R_rel = relativeRotation(R1, R2). This R_rel describes the rotation relationship from the component R1 coordinate system to the component R2 coordinate system.

[0093] Force transformation: At the connection point, the force and torque (fluid variables) also need to be mapped according to this relative transformation matrix to ensure mechanical equilibrium.

[0094] S130 establishes the relationship between components and integrated elements based on the component semantics defined in S110 and the mapping relationship established in S120. It defines the domain model encapsulation structure to encapsulate the domain model and stores components in a standardized compressed package format. The domain model encapsulation structure includes encapsulation specifications for CAD models, Modelica dynamic models, and Simulink cybernetic models.

[0095] S130-1 defines the domain model encapsulation structure;

[0096] This invention defines an encapsulation template for each type of domain model, ensuring that the component package is self-contained and portable.

[0097] CAD model packaging specifications:

[0098] File format: Supports Creo / CATIA native formats (.prt / .asm);

[0099] Unit system: Millimeters, kilograms, and seconds (mm, kg, s) are used uniformly.

[0100] View representation: Includes fully detailed views (Featured_Rep) and simplified views (Defeatured_Rep);

[0101] Reference definition: It must include at least one coordinate system for positioning, as well as necessary axis, surface, and point references;

[0102] Model maturity: The parameter MODEL_MATURITY distinguishes between conceptual models, detailed geometric models, and fully annotated models. A conceptual model, used in the demonstration and preliminary design phases, primarily expresses the overall form, proportions, spatial layout, and basic functional areas of the product. A detailed geometric model, used in the detailed design and manufacturing phases, includes precise dimensional tolerances, geometric tolerances, surface roughness, and complete process structures (such as reinforcing ribs, threads, and draft angles). A fully annotated model is the data source and sole basis for the entire product lifecycle (design, process, quality inspection, procurement), integrating all non-geometric information required for manufacturing (3D dimensioning, datum symbols, welding symbols, material heat treatment methods, technical requirements, etc.).

[0103] Mass attributes: Explicitly define parameters such as density, mass, center of mass, and moment of inertia.

[0104] Modelica dynamics model encapsulation specification:

[0105] Language version: Supports Modelica 3.x and above;

[0106] Parameter classification: common parameters (user adjustable) and protection parameters (internal fixed);

[0107] Connector types: Supports sliding flanges, rotary flanges, electrical pins, thermal ports, fluid ports, multi-body frames, etc.

[0108] Parameter mapping: The parameter values ​​of the components are automatically overwritten with the corresponding parameters in the Modelica model before simulation;

[0109] Multi-fidelity support: The same component can contain both low-fidelity (average model) and high-fidelity (detailed nonlinear model) dynamic representations.

[0110] Simulink Cyber ​​Model Packaging Specification:

[0111] File formats: Supports .mdl and .slx formats;

[0112] Port Extraction: Automatically identifies ports such as Inport, Outport, Enable, and Trigger.

[0113] Sampling time: Records the sampling period for each signal port;

[0114] Code generation: Supports calling the generated C code via the Modelica External Function Interface (EFI);

[0115] Parameter mapping: Simulink workspace variables can be bound to component parameters.

[0116] S130-2 defines the component encapsulation package format;

[0117] The components of this invention are stored in a standardized compressed file (.acm) format and contain the following:

[0118] Integration model file (.acm): XML format, describing component metadata, port definitions, parameter lists, and domain model references;

[0119] Domain model files: CAD files (.prt / .asm), Modelica files (.mo), Simulink files (.mdl / .slx);

[0120] Resource files: icons (.png), datasheets (.pdf), grid files (.stl / .obj);

[0121] Resource dependency list: Records the paths and verification hashes of all external dependencies.

[0122] The root directory of a component package must contain one and only one .acm file, which serves as the package descriptor. Figure 4The file structure example is the file organization structure of the CAD encapsulation component, which includes the domain model folder (CAD), resource folders (Doc, Images, Manufacturing <manufacturing process documents>, Test <experiment documents>), and integration model file (component.acm).

[0123] S130-3, Define component composition semantics;

[0124] This invention supports the combination of components via connectors, for example as follows: Figure 6 By combining avionics, flight control, and power system components, a complex equipment model of the entire aircraft can be assembled. The assembly rules are as follows:

[0125] When the connectors of two components are connected, all ports inside the connector are automatically matched and connected according to their type.

[0126] The connection between power ports generates a connect statement in Modelica;

[0127] Connections between signal ports generate signal flow binding;

[0128] The connections between structural interfaces generate coordinate system alignment constraints;

[0129] Compositions can be nested, meaning that component assemblies can contain other component assemblies, supporting system-of-systems (SoS) modeling.

[0130] S130-4 defines the specific syntax (visual representation);

[0131] This invention defines a specific syntax for each entity in the metamodel, including:

[0132] Component: A rectangular icon that displays the name and parameter list;

[0133] Power port: circular symbol, color distinguishes energy domain (red = electrical, blue = hydraulic, green = thermodynamic);

[0134] Signal port: triangle symbol, direction (inward / outward) indicated by arrow;

[0135] Connector: Multiple ports are enclosed in a thick outline and can be unfolded / folded;

[0136] Connection lines: Solid lines indicate power connections, and dashed lines indicate signal connections.

[0137] The mapping between concrete and abstract syntax is automatically achieved through the metamodel interpreter. Abstract syntax refers to the component structure defined by the metamodel (such as ports, parameters, and connections), while concrete syntax refers to the graphical representation as described above. The metamodel interpreter is a tool component responsible for automatically rendering the abstract model into a graphical interface or synchronizing graphical operations back to the abstract model.

[0138] The following two examples will further illustrate the above method.

[0139] Example 1: Multi-domain integration of engine components.

[0140] Taking a diesel engine as an example, the implementation process of the present invention will be described in detail.

[0141] Step 1: Define the metamodel semantics of engine components;

[0142] Component name: Engine;

[0143] Attributes: Mass (280kg), Efficiency (0.85), Displacement (6.7L);

[0144] Parameters: Maximum power (maxPower=300kW, adjustable range 200~350), peak torque (peakTorque=1200 N·m).

[0145] Step 2: Define the component's interface;

[0146] Torque OutConnector: Combines a Rotational Power Port and a Structural Interface.

[0147] Electrical control connector (ECUConnector): combines a signal input port (ThrottleSignal) and a power port (ElectricalPowerPort);

[0148] Coolant Connector: Combines one hydraulic power port and two thermal ports (In / Out).

[0149] Step 3: Encapsulate the domain model;

[0150] CAD model: Engine.prt, containing a coordinate system (mounting reference plane), four mounting points, and one output axis plane;

[0151] Modelica model: Engine.mo, which includes Rotational Flange, HeatPort_a / b, and Electrical Pin.

[0152] Simulink model: EngineController.slx, which includes throttle input (Inport), speed output (Outport), and a set of MAP parameters.

[0153] Step 4: Establish mapping relationships;

[0154] Map Modelica's RotationalFlange to the component's RotationalPowerPort;

[0155] Map Modelica's HeatPort_a / b to two hot ports in the cooling connector;

[0156] Map the Simulink Inport (throttle) to the signal input port in the ECU connector;

[0157] Map the component parameter maxPower to the parameter with the same name in Modelica.

[0158] Step 5: Generate the component package;

[0159] Create a folder named Engine_Component / ;

[0160] Place it in Engine.acm (XML integration description file);

[0161] Place it in CAD / Engine.prt;

[0162] Place it in Modelica / Engine.mo;

[0163] Place it in Simulink / EngineController.slx;

[0164] Place it in Resources / engine_icon.png;

[0165] Compress it into Engine.acm.zip.

[0166] Step 6: Component assembly;

[0167] Import the Engine component package during system-level assembly;

[0168] Connect the Engine's torque output connector to the Transmission's torque input connector;

[0169] Connect the Engine's ECU connector to the signal output of the electronic control unit (ECU);

[0170] The system automatically generates Modelica connection statements, Simulink signal bindings, and CAD assembly constraints.

[0171] Simulation verification:

[0172] A hybrid simulation was performed, with Modelica calculating the engine torque output and the Simulink controller adjusting the fuel injection quantity based on the throttle signal.

[0173] After simulation, read the following metrics: maximum torque, fuel consumption rate, and exhaust temperature.

[0174] Verification restrictions: Exhaust temperature not exceeding 800℃, engine speed not exceeding 2200rpm.

[0175] Example 2: Multi-domain integration of battery components.

[0176] Similarly, construct battery modules:

[0177] Attributes: Nominal voltage (12V), capacitance (100Ah), internal resistance (0.05Ω);

[0178] Parameter: Initial state of charge (SOC_init=0.8);

[0179] CAD model: Battery casing geometry, positive and negative electrode mounting surfaces;

[0180] Modelica model: Modelica.Electrical.Analog.Batteries.BatteryCell;

[0181] Simulink model: Battery Management System (BMS) control logic;

[0182] Mapping: Positive port, negative port, Battery Management System (BMS) communication signal port.

[0183] Although the illustrative specific embodiments of the present invention have been described above to enable those skilled in the art to understand the invention, it should be understood that the invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes will be obvious as long as they are within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of the present invention are protected.

Claims

1. A multi-domain model integration method based on semantic components, characterized in that, Includes the following steps: S110, Use a meta-model to define the abstract semantics of the component. The meta-model adopts a four-layer architecture and includes at least components, attributes, parameters, ports, connectors, and domain models and their static semantic constraints. S120 abstracts integration elements such as input ports, output ports, parameters, metrics, and constraints from the domain language, uses meta-models to express model integration elements, and defines four types of mapping relationships: power port mapping, signal port mapping, parameter mapping, and structural interface mapping. S130 establishes the relationship between components and integrated elements based on the component semantics defined in S110 and the mapping relationship established in S120, defines the domain model encapsulation structure to encapsulate the domain model, and stores the components in a standardized compressed package format.

2. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, In S110, the four-layer architecture of the meta-model includes: meta-meta-model layer, meta-model layer, model layer, and user object layer.

3. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, In S120, the power port mapping defines the equivalence relationship between the component power port and the Modelica electrical, mechanical, thermodynamic, hydraulic, and multibody ports in terms of potential and flow variables; the signal port mapping defines the numerical transfer relationship between the component signal port and the Modelica or Simulink signal port; the parameter mapping defines the automatic overriding relationship between the component parameters and the domain model parameters; and the structural interface mapping defines the alignment relationship between the component coordinate system, axes, surfaces, points, and the CAD model datum.

4. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, In S130, the CAD model encapsulation specification includes: a unified unit system; view representation including fully detailed views and simplified views; datum definition: including a coordinate system for positioning and axis, surface, and point datums; model maturity parameters and quality attribute parameters.

5. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, The Modelica dynamics model packaging specification includes: support for Modelica 3.x and above; classification of common and protection parameters; support for multi-fidelity models; and connector types covering sliding flanges, rotary flanges, electrical pins, thermal ports, fluid ports, and multibody frames.

6. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, The Simulink cybernetic model encapsulation specification includes: support for .mdl and .slx formats; automatic extraction of input ports, output ports, enable ports, and trigger ports; recording the sampling period of each signal port; and support for calling the generated C code through the Modelica external function interface.

7. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, In S130, the standardized compressed package includes: an integration model file in XML format, a domain model file, and resource files and a list of resource dependencies.

8. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, The components are combined via connectors. During combination, all ports inside the connector are automatically matched and connected according to type, supporting nested component assembly and system-to-system modeling.

9. The multi-domain model integration method based on semantic components according to claim 1, characterized in that, In S130, a specific syntax is defined for each entity in the metamodel. The specific syntax includes: components are represented by rectangular icons; power ports are represented by circular symbols, and energy domains are distinguished by color; signal ports are represented by triangular symbols, and the direction is indicated by arrows; connectors are represented by thick wireframes; power connection lines are represented by solid lines; and signal connection lines are represented by dashed lines.

10. The multi-domain model integration method based on semantic components according to claim 9, characterized in that, The mapping between concrete syntax and abstract syntax is automatically achieved by the metamodel interpreter. Abstract syntax refers to the component structure defined by the metamodel. The metamodel interpreter is responsible for automatically rendering the abstract model into a graphical interface or synchronizing graphical operations back to the abstract model.

Images