A white-box integration method for multi-source heterogeneous models based on shared memory technology

Abstract

This invention discloses a white-box integration method for multi-source heterogeneous models based on shared memory technology. It encapsulates shared memory, clock synchronization algorithms, and data interface protocols into a shared memory FMU using the FMI protocol. This communication FMU is then imported into various simulation tools, allowing them to exchange data and thus achieve joint simulation of multi-source heterogeneous models. Compared to exporting the model to an FMU for integration, this invention allows for real-time adjustment of model parameters and observation of model output results within each software during simulation.

Description

Technical Field

[0001] This invention belongs to the field of simulation technology and relates to a white-box integration method for multi-source heterogeneous models based on shared memory technology. Background Technology

[0002] With the widespread application of computer simulation technology, model-based systems engineering is increasingly being used in product development processes. Digital modeling and simulation can comprehensively verify and optimize product design schemes, significantly shortening the development cycle and reducing costs. Due to the differences in simulation technologies across various fields, dedicated commercial simulation software has gradually developed, gaining industry recognition and widespread adoption. Currently, because commercial simulation software in different disciplines focuses on different areas, when simulating an entire system, no single software can handle the task; therefore, joint simulation using simulation tools from different disciplines is necessary.

[0003] In 2010, the European Information Aid Programme for Development (ITEA2) proposed the FMI standard. FMI defines a universal interface specification for co-simulation, enabling co-simulation of models built using different simulation tools. The specification defines two co-simulation modes: Model Exchange (ME) and Co-Simulation (CS). The difference lies in that the FMU in the ME mode does not include a model solver, while the latter does. This standard standardizes all simulation processes, allowing all modeling and simulation software to export their models as FMU (Functional Mock-up Unit) files. Other software can then parse and call these files based on the FMI standard, thus achieving co-simulation by multidisciplinary simulation software. In 2014, the standard was upgraded to FMI 2.0, featuring variable parameters during simulation execution, enhanced initialization behavior, implementation environment integration, and simulator handling, improving usability and compatibility. Currently, this standard has been adopted by over 110 commercial simulation software programs, including commonly used simulation software such as AMESim and Simulink, and is gradually developing into a widely accepted unified standard.

[0004] The essence of co-simulation of multi-source heterogeneous models is to enable different simulation tools to exchange data. In computer systems, this problem is termed inter-process communication (IPC). IPC is categorized into low-level communication (which can only transmit status and integer values) and high-level communication (which improves the efficiency of signal communication, transmits large amounts of data, and reduces program complexity) based on the amount of information exchanged and efficiency. High-level IPC includes three modes: shared memory mode, message passing mode, and shared file mode.

[0005] When handling the integrated simulation of multi-source heterogeneous models, foreign institutions generally adopt secondary development of the specific version of simulation software (commercial or open source) involved in the integrated simulation, and compile controls that match the defined data services to complete the integrated simulation of multi-source heterogeneous models.

[0006] In order to break free from the restrictions imposed by foreign simulation software companies, some domestic institutions have adopted a mainstream solution of exporting simulation models built in commercial tools as FMU files (specifically referring to Co-Simulation format, because only this format of FMU files comes with a solver; Model-Exchange format FMUs are not suitable for this method). Then, all FMU files are loaded onto a simulation platform for integrated simulation, such as Mworks software from Suzhou Tongyuan Soft Control Co., Ltd. and GCair software from Beijing Shiguan Technology Co., Ltd.

[0007] my country’s research on distributed integrated simulation began in the 20th century and the 1990s. After many years of efforts, the Chinese military has made great progress, overcome DIS and related technologies, and built a multi-weapon integrated simulation demonstration system based on a hybrid architecture of DIS and HLA. However, there is still a significant gap with the United States and Europe.

[0008] Current domestic research in this field has the following shortcomings compared to the US and Europe:

[0009] First, foreign technologies started developing earlier and have received significant military investment, and have already reached the commercialization stage. In contrast, China has remained at the level of tracking and researching, and is still limited to using standards and specifications proposed by the US military. It lacks its own independent standards and practical systems, let alone commercialization. Purchasing foreign tools is not only expensive, but we also lack independent intellectual property rights, which is inconsistent with the current national trend of supporting self-reliance.

[0010] Secondly, the shortcomings of the methods described above are obvious. The biggest drawback of the methods used by foreign institutions is that when the simulation software version is upgraded, the existing integrated simulation client controls may become invalid, requiring redevelopment, which is a significant workload and causes trouble for the use, maintenance, and after-sales service of the integrated simulation software. Furthermore, purchasing foreign tools is not only expensive, but we also lack independent intellectual property rights, which is inconsistent with the current national trend of supporting self-reliance. As for the methods used by domestic institutions, their biggest limitation is that the simulation tool must support exporting Co-Simulation format FMUs in order to integrate the models built within them. However, a search on the FMI website reveals that very few simulation tools support Co-Simulation format FMU export. Many mainstream simulation tools, for commercial interests and intellectual property considerations, prefer to import FMU models from other tools rather than export their own models. Secondly, the exported model is a black-box model. During the simulation process on the target simulation platform, it is impossible to view the intermediate variables of the model, and debugging the model is extremely inconvenient. Frequent import and export of the model is required. Finally, due to differences between simulation tools, some models imported from FMU into other simulation tools may not be calculated correctly. Summary of the Invention

[0011] The technical problem solved by this invention is to provide a white-box integration method for multi-source heterogeneous models based on shared memory technology, which solves the problems of multi-disciplinary and cross-platform model integration and joint simulation.

[0012] This invention is achieved through the following technical solution:

[0013] A white-box integration method for multi-source heterogeneous models based on shared memory technology includes the following operations:

[0014] 1) The shared memory FMU is encapsulated through the FMI protocol, which includes the FMI description file and the executable file, and gives the shared memory, clock synchronization and data interface protocols that the software participating in the simulation must follow;

[0015] The shared memory is a method of inter-process communication. By mapping the address space of the same physical memory to the address spaces of different processes, communication between different processes can be achieved by directly modifying the memory in the address space.

[0016] The clock synchronization setting determines the communication step size for synchronization among the various simulation software in the co-simulation.

[0017] The data interface relationship protocol established is a unified interface protocol between various simulation tools. It includes adding "_in" to the name of the input signal in each subsystem and adding "_out" to the name of the output signal. The signals are separated by commas (,) and the total input and output signals are separated by semicolons (;). The name of each signal cannot be repeated. This information is composed of the interface information of each subsystem in the form of a string, which provides support for the FMU to process interface relationships.

[0018] The shared memory FMU reserves a port for users to set the communication step size for interface protocols and model interactions;

[0019] 2) Then, the shared memory FMU is imported into each simulation tool participating in the simulation, allowing the simulation tools to exchange data through the shared memory FMU.

[0020] After importing the FMU into the simulation software, the parameters defined as model variables can be displayed and modified in the FMU's parameter setting interface;

[0021] 3) According to the FMI simulation process, after setting the FMU parameter information, the simulation software calls the FMI interface function during the FMU initialization process to pass the above information to the executable file in the FMU;

[0022] The executable file parses the interface parameters set, creates or reads shared memory based on the input and output parameters in the interface information; at a specific communication step, it writes the output data of this model into the shared memory according to the interface protocol; at the same time, it waits for other models to write the input data required by this model into the shared memory before reading it; then it enters the next communication step, and repeats until all simulations are completed.

[0023] The FMI description file provides a detailed description of the FMU model's attribute information, including the structure and content of the model framework; simulation tools parse and read the model configuration information from it.

[0024] The executable file specifies the interfaces of all the functions required in the co-simulation, and is used for basic configuration before simulation execution;

[0025] By writing the model description file of the FMU, the interface information of the subsystem and the communication step size of the model interaction are left to the user to set;

[0026] ModelVariables in the model description file can be used to define model variables; write the XML of the model description file to define interface information, communication step size, and the number of inputs and outputs as model variables.

[0027] The clock synchronization is achieved using data mutexes and simulated time synchronization:

[0028] First, the total simulation time of all models in the co-simulation must be consistent;

[0029] Secondly, the input data of a certain model must come from the output of other models. At time T, model A writes the output data and its own simulation time T into the shared memory named after the data. When model B reaches time T, it first checks whether there is a shared memory with the data name. If not, the interface information is set incorrectly.

[0030] Then, read the current shared memory time. If it matches, read the data directly. If the current shared memory time is T-1, it is the data of the previous communication step. You need to wait for the simulation software A to refresh the time and data before reading.

[0031] Compared with the prior art, the present invention has the following beneficial technical effects:

[0032] This invention eliminates the need for importing and exporting models via the FMI interface in multi-source heterogeneous model integration. Instead, it encapsulates shared memory, clock synchronization algorithms, and data interface protocols into a unified FMU through the FMI protocol. This FMU is then imported into various simulation tools, allowing them to exchange data and thus achieve joint simulation of multi-source heterogeneous models. Furthermore, compared to the drawbacks of exporting models to FMUs for integration, this invention allows each model to run in its own matching simulation software. Internal parameters can be modified within each simulation software, and simulations can be immediately restarted after modification. The model output results can be observed in each simulation software, and this process can be iterated. This heterogeneous model integration method, which allows for real-time adjustment of model parameters and observation of output results during simulation, is a white-box integration simulation method that significantly improves simulation efficiency.

[0033] This invention achieves white-box integration of simulation models for various heterogeneous, multi-source systems, providing a novel solution and enabling simple and convenient integration of heterogeneous models.

[0034] This invention employs heterogeneous model integration: based on the FMI protocol, shared memory and related protocols can be compiled into a general FMU through C++ programming, and imported into simulation software that requires co-simulation, thereby realizing white-box integration of multi-source heterogeneous models.

[0035] This invention employs a data interface protocol: a unified interface protocol is established based on the interactive data relationships between various simulation tools; the interface protocol consists of interface information of each subsystem in the form of strings, which is transmitted to the dynamic library in the FMU through the simulation software; the dynamic library uses the interactive signal name as an attribute to look up the value corresponding to the name; thus completing the correspondence and processing of input and output data from multiple simulation software programs.

[0036] This invention employs synchronization under shared memory: During co-simulation, the rigidity and complexity of each model are different, and the solution efficiency of each simulation software is different, which will lead to inconsistent simulation progress. Therefore, it is necessary to define a synchronization algorithm in the FMU and use data mutex locks and simulation time synchronization to ensure that the software in the co-simulation calculates synchronously. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the process of the present invention;

[0038] Figure 2 It is an interactive relationship;

[0039] Figure 3 It is a PID control model;

[0040] Figure 4 For hydraulic source model;

[0041] Figure 5 Model of a hydraulic actuator;

[0042] Figure 6 The image shows the simulation results from Amesim.

[0043] Figure 7 This is a curve showing the expected and actual values ​​of the PID. Detailed Implementation

[0044] The present invention will be further described in detail below with reference to embodiments. These descriptions are for illustrative purposes only and are not intended to limit the scope of the invention.

[0045] See Figure 1 1. A white-box integration method for multi-source heterogeneous models based on shared memory technology, characterized by including the following operations:

[0046] 1) The shared memory FMU is encapsulated through the FMI protocol, which includes the FMI description file and the executable file, and gives the shared memory, clock synchronization and data interface protocols that the software participating in the simulation must follow;

[0047] The shared memory is a method of inter-process communication. By mapping the address space of the same physical memory to the address spaces of different processes, communication between different processes can be achieved by directly modifying the memory in the address space.

[0048] The clock synchronization setting determines the communication step size for synchronization among the various simulation software in the co-simulation.

[0049] The data interface relationship protocol established is a unified interface protocol between various simulation tools. It includes adding "_in" to the name of the input signal in each subsystem and adding "_out" to the name of the output signal. The signals are separated by commas (,) and the total input and output signals are separated by semicolons (;). The name of each signal cannot be repeated. This information is composed of the interface information of each subsystem in the form of a string, which provides support for the FMU to process interface relationships.

[0050] The shared memory FMU reserves a port for users to set the communication step size for interface protocols and model interactions;

[0051] 2) Then, the shared memory FMU is imported into each simulation tool participating in the simulation, allowing the simulation tools to exchange data through the shared memory FMU.

[0052] After importing the FMU into the simulation software, the parameters defined as model variables can be displayed and modified in the FMU's parameter setting interface;

[0053] 3) According to the FMI simulation process, after setting the FMU parameter information, the simulation software calls the FMI interface function during the FMU initialization process to pass the above information to the executable file in the FMU;

[0054] The executable file parses the interface parameters set, creates or reads shared memory based on the input and output parameters in the interface information; at a specific communication step, it writes the output data of this model into the shared memory according to the interface protocol; at the same time, it waits for other models to write the input data required by this model into the shared memory before reading it; then it enters the next communication step, and repeats until all simulations are completed.

[0055] The following is a detailed explanation of each part.

[0056] The FMU under the FMI protocol is a ZIP archive with the .fmu extension. It mainly contains two files: one is an FMI description file based on XML format, which specifies the structure and content of the model framework; the other is an executable file, such as a dynamic link library (DLL) file in the Windows platform, which specifies the interface of all the functions required in the co-simulation.

[0057] The FMI model description file is an important part of the FMI standard and is used for basic configuration work before simulation execution. The XML file provides a detailed description of the FMU model's attribute information, and the simulation software reads the model configuration information by parsing the XML file.

[0058] The executable file contains the core code required for the compiled simulation model to perform the simulation, and it exposes the external interface function names specified in the FMI standard. The model provider needs to implement all functions according to the interface definition, and the simulation software can run by calling these functions;

[0059] Specifically, the DLL file generated by FMU using the Co-Simulation method includes the solver used in the original modeling tool, meaning that no other model solver needs to be used when simulating the FMU model.

[0060] The data interface information contained in the DLL file is not quite the same in the Co-Simulation FMI standard and the Model Exchange FMI standard. When the simulation software simulates the FMU model, it repeatedly calls the algorithm logic contained in the interface function. Each step of the call needs to understand the function execution status through status information.

[0061] 1. Create a shared memory FMU

[0062] The shared memory FMU described in this invention is created based on the FMU execution process of the simulation software.

[0063] First, in the co-simulation of heterogeneous models, the data interaction between subsystems in different simulation software forms certain interface relationships. These interfaces allow each subsystem to obtain the data it needs. For example, the pressure (Ps) in the Amesim model needs to be transmitted to the SimulationX model, while the SimulationX model needs to transmit the flow rate (Q) to the Amesim model.

[0064] The interface relationship protocol of this invention stipulates that the input signal name in each subsystem is prefixed with "_in", and the output signal name is prefixed with "_out". Signals are separated by commas (,), and the total number of input and output signals is separated by semicolons (;). Duplicate signal names are not allowed. This information, presented as a string, constitutes the interface information for each subsystem, providing support for the FMU to handle interface relationships. For example, for the Amesim model, the interface information is "Q_in; Ps_out"; for the SimulationX model, the interface information is "Ps_in; Q_out".

[0065] Secondly, the shared-memory FMU needs to leave the aforementioned interface information and communication step size for model interaction to be set by the user. This requirement can be achieved by writing the FMU's model description. The ModelVariables in the model description file can be used to define model variables. By writing the XML of the model description file, interface information, communication step size, and the number of inputs and outputs can be defined as model variables.

[0066] 2. Co-simulation

[0067] After the FMU is imported into the simulation software or tool, the parameters defined as model variables can be displayed and modified in the FMU's parameter setting interface. In other words, the FMU described in this invention can be generated once and modified for use at any time.

[0068] The simulation process can be divided into four stages: instantiation, initialization, simulation run, and simulation termination. According to the above FMI simulation process, after the user sets the parameter information, the simulation software will call the FMI interface function to pass the above information to the executable file in the FMU during the FMU initialization process.

[0069] The executable file (DLL) parses the interface parameters set, and creates or reads shared memory based on the input and output parameters in the interface information. At a specific communication step, it writes the output data of this model into the shared memory according to the software interface protocol. At the same time, it waits for other models to write the input data required by this model into the shared memory before reading it. Then it enters the next communication step, looping until all simulations are completed.

[0070] 3. Data synchronization

[0071] In co-simulation, the key to integrating multi-source heterogeneous models lies in data synchronization. Data synchronization ensures the correctness of the model's calculation results. This invention uses data mutex locks and simulation time synchronization to achieve data synchronization. First, the total simulation time of each model in the co-simulation must be consistent. Second, the input data of a certain model must come from the output of other models. At time T, model A writes its output data and its own simulation time T into a shared memory named after the data. When model B reaches time T, it first checks if there is a shared memory with that data name. If not, the interface information is incorrectly set. Then, it reads the current time of the shared memory. If it matches, it reads the data directly. If the current time of the shared memory is T-1, it contains data from the previous communication step, and it needs to wait for simulation software A to refresh the time and data before reading.

[0072] The following is a specific implementation example: white-box integration example of multi-source heterogeneous models.

[0073] Hydraulic servo control systems are complex systems involving multiple disciplines and high technological density, mainly comprising mechanical, hydraulic, and control subsystems. These subsystems are coupled and interact with each other. The design of hydraulic servo control systems exhibits a distinctly multidisciplinary nature, making it a typical multidisciplinary design problem. Therefore, how to comprehensively coordinate the design of various subsystems within a multidisciplinary framework has become a key issue in the design of mechatronic systems.

[0074] Whether the optimization of a hydraulic servo control system can be achieved depends primarily on establishing a reasonable optimization model and selecting an effective optimization algorithm suitable for that model. Therefore, multidisciplinary modeling and co-simulation are necessary for the complex system design and optimization of hydraulic servo control systems.

[0075] The hydraulic servo control system is a closed-loop servo control system for the hydraulic cylinder position. The model shown below illustrates this, along with the interaction relationships between the models and the interface information compiled according to the aforementioned custom interface protocol. Figure 2 As shown. The PID control model was built using Open Modelica simulation software, such as... Figure 3 As shown. The hydraulic source is a model built using SimulationX simulation software, such as... Figure 4 As shown; the hydraulic control and actuator models were built using AMESim simulation software, such as... Figure 5 As shown. Compared to exporting the model to an FMU for integration, this invention allows for real-time adjustment of model parameters and observation of model output results across various software programs during simulation.

[0076] Specifically, the input target value in the PID control model is a sinusoidal signal with an amplitude of 0.02 and a frequency of 0.02 Hz. After PID calculation, the output value is transmitted to the Amesim hydraulic actuator model via a shared memory FMU. Simultaneously, the hydraulic source model in SimulationX transmits the pressure signal to the Amesim hydraulic actuator via the shared memory FMU. The Amesim hydraulic actuator then transmits its output displacement signal to the control system via the shared memory FMU. Through negative feedback and PID control, the output displacement of the hydraulic actuator is made to output the sinusoidal signal of the control system.

[0077] After simulation, the displacement curve of the hydraulic actuator model in AMESim is as follows: Figure 6 As shown, the expected value and actual motion value of the PID in Open Modelica are as follows: Figure 7 As shown.

[0078] The embodiments given above are preferred examples for implementing the present invention, and the present invention is not limited to the above embodiments. Any non-essential additions or substitutions made by those skilled in the art based on the technical features of the present invention are within the protection scope of the present invention.

Claims

1. A white-box integration method for multi-source heterogeneous models based on shared memory technology, characterized in that, Includes the following operations: 1) The shared memory FMU is encapsulated through the FMI protocol, which includes the FMI description file and the executable file, and gives the shared memory, clock synchronization and data interface protocols that the software participating in the simulation must follow; The shared memory is a method of inter-process communication. It maps the address space of the same physical memory to the address spaces of different processes, so that communication between different processes can be achieved by directly modifying the memory in the address space. The clock synchronization setting determines the communication step size for synchronization among the various simulation software in the co-simulation. The data interface protocol establishes a unified interface protocol between various simulation tools. It includes adding "_in" to the name of the input signal in each subsystem, adding "_out" to the name of the output signal, separating each signal with an English comma (,), and separating the total input signals and output signals with an English semicolon (;). The name of each signal is not allowed to be repeated. This information is composed of the interface information of each subsystem in the form of a string, which provides support for the FMU to process interface relationships. The shared memory FMU reserves a port for users to set the communication step size for interface protocols and model interactions; 2) Then, the shared memory FMU is imported into each simulation tool participating in the simulation, allowing the simulation tools to exchange data through the shared memory FMU. After importing the FMU into the simulation software, the parameters defined as model variables are displayed and modified in the FMU's parameter setting interface; 3) According to the FMI simulation process, after setting the FMU parameter information, the simulation software calls the FMI interface function during the FMU initialization process to pass the above information to the executable file in the FMU; The executable file parses the interface parameters set, creates or reads shared memory based on the input and output parameters in the interface information; at a specific communication step, it writes the output data of this model into the shared memory according to the interface protocol; at the same time, it waits for other models to write the input data required by this model into the shared memory before reading it. Then proceed to the next communication step, and repeat until all simulations are completed.

2. The white-box integration method for multi-source heterogeneous models based on shared memory technology as described in claim 1, characterized in that, The FMI description file provides a detailed description of the FMU model's attribute information, including the structure and content of the model framework; simulation tools parse and read the model configuration information from it. The executable file specifies the interfaces of all the functions required in the co-simulation, and is used for basic configuration before simulation execution.

3. The white-box integration method for multi-source heterogeneous models based on shared memory technology as described in claim 1 or 2, characterized in that, By writing the model description file of the FMU, the interface information of the subsystem and the communication step size of the model interaction are left to the user to set; ModelVariables in the model description file can be used to define model variables; write the XML of the model description file to define interface information, communication step size, and the number of inputs and outputs as model variables.

4. The white-box integration method for multi-source heterogeneous models based on shared memory technology as described in claim 1, characterized in that, The clock synchronization is achieved using data mutexes and simulated time synchronization: First, the total simulation time of all models in the co-simulation must be consistent; Secondly, the input data of a certain model must come from the output of other models. At time T, model A writes the output data and its own simulation time T into the shared memory named after the data. When model B reaches time T, it first checks whether there is a shared memory with the data name. If not, the interface information is set incorrectly. Then, read the current shared memory time. If it matches, read the data directly. If the current shared memory time is T-1, it is the data of the previous communication step. You need to wait for the simulation software A to refresh the time and data before reading.

Images