Simulation method, system, equipment and medium for extending virtual integrated system metamodel

Abstract

The present invention relates to the field of simulation technology, and in particular, to a simulation method, system, device, and medium for extending a virtual integrated system metamodel. The method provided by the present invention is used to plug in the mechanism of the extended metamodel, separate the simulation modeling and operation scheduling interfaces, and reduce the degree of coupling between the plug-in functional modules. The modeling scheduler and the engine scheduler can be integrated into the simulation modeling platform and the scheduling platform respectively. After the modeling work is completed in the simulation modeling platform, both local simulation and distributed simulation within a computer cluster can be performed. The modeling scheduler and the engine scheduler interact with the parser and executor in the extended plug-in respectively through interfaces. The two have their own functional responsibilities and create and destroy corresponding instance handles through different export functions. Under the premise of being compatible with the old interface, the interface can be expanded according to demand to achieve functional iteration.

Description

Technical Field

[0001] The present invention relates to the field of simulation technology, and in particular to a simulation method, system, device and medium for extending a virtual integrated system metamodel. Background Art

[0002] With the continuous development of industrial complex systems, especially in multi-domain and interdisciplinary engineering systems, simulation technology has become a crucial tool for solving complex system problems. As modern industry advances toward intelligentization, automation, and digitalization, it increasingly relies on simulation technology to verify, optimize, and improve the design and operational performance of various products and systems. Among the numerous simulation systems, establishing an efficient and reliable integrated system simulation platform has become crucial for solving complex system problems. Current integrated simulation modeling systems, particularly in high-end fields such as industrial automation, production control, intelligent manufacturing, and energy management, often require the integration of multiple modules and diverse modeling and simulation tools for collaborative simulation. This requires simulation platforms to possess not only high scalability, flexible modeling capabilities, and robust simulation execution capabilities, but also support the interoperability of diverse software, algorithms, and models, enabling cross-disciplinary and cross-platform collaborative simulation and multi-dimensional data exchange.

[0003] However, traditional simulation platforms often face limitations when addressing this demand. In particular, in terms of flexibility and scalability, traditional platforms often rely on fixed modules and architectures, making them inadequate for addressing diverse domains and ever-changing needs. In particular, their ability to customize and expand for specific needs is weak, making it difficult to quickly introduce new algorithms, models, and external tools based on the needs of different users. This significantly reduces the platform's adaptability and sustainability. Furthermore, many traditional simulation platforms have limited secondary development capabilities and lack effective interfaces and extension mechanisms. Users often face complex technical challenges and high development costs when conducting customized development, and may even need to undergo large-scale platform reconstruction. Whether it is for refined control of simulation calculations or the introduction of new technologies, models, and tools, the shortcomings of traditional platforms are particularly prominent. Summary of the Invention

[0004] The purpose of the present invention is to provide a simulation method, system, device and medium for extending a virtual integrated system metamodel to solve the above-mentioned problems in the prior art.

[0005] The present invention is achieved through the following technical solutions:

[0006] In a first aspect, the present invention provides a simulation method for an extended virtual integrated system metamodel, comprising:

[0007] Set up the parser and executor within the extension plugin and write the plugin code;

[0008] Compile the plug-in into a library file and place it in the simulation environment directory;

[0009] Perform functional modeling in the simulation modeling platform, including loading extension plug-ins through the modeling scheduler, calling functions in the parser in a certain sequence, and extending the metamodel;

[0010] Start the execution engine for simulation, including starting the local or remote execution engine, deploying the model project to the execution engine, and the execution engine loading the extension plug-in through the engine scheduler, calling the functions in the executor in a certain sequence, and performing I / O reading and writing and logic processing.

[0011] Preferably, the loading of the extension plug-in by the modeling scheduler and calling the functions in the parser in a certain sequence include:

[0012] Get the extension plug-in to be used and load the extension plug-in dynamic library through the modeling scheduler;

[0013] Call the export function of the extension plug-in to create the parser;

[0014] Detect the interface version used by the current extension plug-in to determine whether it belongs to the supported version set. If not, destroy the parser and uninstall the plug-in library to end the process;

[0015] If yes, get the plugin name, base64 encoding of the icon and plugin description;

[0016] Register the log service to the plug-in, and the logs output by the plug-in through the logger are taken over by the modeling scheduler;

[0017] Detect the running environment and determine whether the running conditions are met. If not, destroy the parser and uninstall the plug-in library to end the process;

[0018] If so, set the resource path and obtain the model attributes to determine whether there are model attributes that need to be preprocessed. If not, obtain the model variables. If so, set the model attributes and then obtain the model variables.

[0019] Call the export function of the extension plug-in to destroy the parser, destroy the parser, uninstall the extension plug-in dynamic library, and end the process.

[0020] Preferably, the execution engine loads the extension plug-in through the engine scheduler, and calls the functions in the executor in a certain sequence, including:

[0021] After receiving the control command to start the simulation execution, the extension plug-in dynamic library is loaded through the engine scheduler;

[0022] Call the export function of the extension plug-in to create the executor to create the executor;

[0023] Detect the interface version used by the current extension plug-in to determine whether it belongs to the supported version set. If not, destroy the executor and uninstall the plug-in library to end the process;

[0024] If so, register the status monitoring callback function and plugin metadata to the plugin;

[0025] Register the log service with the plug-in. The logs output by the plug-in through the logger are taken over by the engine scheduler.

[0026] Detect the operating environment and determine whether the operating conditions are met. If not, destroy the executor and uninstall the plug-in library to end the process;

[0027] If available, the port data definition parser is registered and the plug-in obtains the memory layout of the data block through the data definition parser;

[0028] Register the resource path to the plug-in. The plug-in locates the physical storage location of the file through the resource path and the file relative path property configured during modeling.

[0029] Set the input and output port fields and register data readers and writers;

[0030] Set the plug-in switching state from initialization or stop to running, triggering the state callback;

[0031] Execute data simulation to determine whether it is periodically scheduled. If so, return to the trigger state callback. If not, call the export function of the extension plug-in to destroy the executor, destroy the executor, and uninstall the extension plug-in dynamic library to end the process.

[0032] Preferably, the resource path includes a workspace, a project path and a plug-in path.

[0033] Preferably, the detection operating environment includes:

[0034] If an external service is introduced into the plug-in, this interface will determine whether the external service is callable and return a Boolean value.

[0035] Preferably, the setting of the input and output port domains includes:

[0036] The engine scheduler sets the data address, data block size, and port name description information of the I / O port to the plug-in. The plug-in will read input data from the data address or write output data to the data address.

[0037] Preferably, the registration data reader / writer includes:

[0038] The plug-in can obtain or set the data value of the data block or the signal in the data block through the data address and reader / writer;

[0039] The data structure of the data block includes the data address of the data block, the data block length, the signal byte offset, the signal word offset, the signal length, and the signal initial value.

[0040] In a second aspect, the present invention further provides a simulation system for extending a virtual integrated system metamodel, comprising a modeling scheduler, an engine scheduler, and an extension plug-in module, wherein the modeling scheduler and the engine scheduler are respectively connected to the extension plug-in module, the modeling scheduler comprises a parser, the engine scheduler comprises an executor, and the executor comprises an input port and an output port;

[0041] It also includes a main control module connected with the modeling scheduler, engine scheduler and extension plug-in module, and used for executing the above-mentioned simulation method of an extended virtual integrated system metamodel.

[0042] In a third aspect, the present invention also provides an electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned simulation method of an extended virtual integrated system metamodel when executing the computer program.

[0043] In a fourth aspect, the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to perform the above-mentioned simulation method of an extended virtual integrated system metamodel.

[0044] The technical solution of the present invention has at least the following advantages and beneficial effects:

[0045] By adopting the method provided by the present invention, the mechanism of the extended metamodel is plug-inized, the simulation modeling and operation scheduling interfaces are separated, and the coupling degree between the plug-in functional modules is reduced. The modeling scheduler and the engine scheduler can be integrated into the simulation modeling platform and the scheduling platform respectively. After the modeling work is completed in the simulation modeling platform, both local simulation and distributed simulation within a computer cluster can be performed. The modeling scheduler and the engine scheduler interact with the parser and executor in the extended plug-in respectively. The two have their own functional responsibilities and create and destroy corresponding instance handles through different export functions. Under the premise of being compatible with the old interface, the interface can be expanded according to demand to achieve functional iteration.

[0046] This application provides flexible function configuration and port management during simulation modeling. Plug-in writers provide key necessary configurations, and plug-in users dynamically update and extend them as needed, improving the applicability of plug-ins in different scenarios and reducing development and maintenance costs.

[0047] Furthermore, version management ensures compatibility across interface iterations. The modeling scheduler and engine scheduler provide long-term support for extensions developed based on both new and old interface versions. Data management organizes I / O port data using data blocks. Each port can be bound to a data block, which can contain multiple variables of any basic type. Defining a data block format once allows for multiple references across different functional modules. This unified data format reduces the complexity of configuring variable ports. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0049] Figure 1 It is the overall control flow chart of the present invention;

[0050] Figure 2 A flow chart for modeling the interaction between the scheduler and the extension plug-in of the present invention;

[0051] Figure 3 A flow chart showing the interaction between the engine scheduler and the extension plug-in of the present invention;

[0052] Figure 4 This is a schematic diagram of module connection of the present invention;

[0053] Figure 5 Schematic diagram of a data block of the present invention. DETAILED DESCRIPTION

[0054] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations.

[0055] The division of modules in this application is a logical division. In actual application, there may be other division methods. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0056] In addition, the connection, coupling or communication in this application may be a direct connection, coupling or communication between related objects, or an indirect connection, coupling or communication through other devices. In addition, the connection, coupling or communication between objects may be electrical or other similar forms, which are not limited in this application.

[0057] Independently described modules or submodules may or may not be physically separate; they may be implemented in software or hardware. Some modules or submodules may be implemented in software, with the processor invoking the software to implement the functionality of these modules or submodules, while other modules or submodules may be implemented in hardware, such as hardware circuits. Furthermore, some or all of the modules may be selected based on actual needs to achieve the objectives of the present application.

[0058] Please refer to Figure 1-Figure 5 The present invention provides a simulation method for an extended virtual integrated system metamodel, comprising:

[0059] Step S101: Set the parser and executor in the extension plug-in and write the plug-in code;

[0060] The parser is the component within the extension responsible for parsing input data or configuration, converting raw data (such as configuration files, user input, and external requests) into structured data that the extension can understand and operate on. The executor is the component within the extension responsible for executing business logic. Based on the parser's output, it invokes specific operations (such as calling APIs, modifying system status, and rendering UI) to complete the core functionality of the extension.

[0061] Next, determine the requirements and write the plug-in code. This code can include external services to implement co-simulation. The interface file provides a runtime environment detection interface, which detects the presence of external services and provides a prompt when the user attempts to use the plug-in.

[0062] Step S102: compile the plug-in into a library file and place it in the simulation environment directory;

[0063] Based on the system platform requirements for running the simulation, a dynamic library of the corresponding architecture is compiled on the corresponding platform. To meet the simulation requirements, the engine scheduler can identify the system architecture on the desktop system or real-time system and load the dynamic library for simulation.

[0064] Step S103: performing functional modeling in the simulation modeling platform, including loading extension plug-ins through the modeling scheduler, calling functions in the parser in a certain sequence, and extending the metamodel;

[0065] In this example, an extension plug-in is an add-on component used to add new functionality or modify existing behavior to existing software or platforms without modifying the core system. It interacts with the main program through standardized interfaces or APIs, adhering to specific development specifications. A metamodel is a "model of models," used to define the structure, rules, and constraints of other models. At a higher level of abstraction, it provides modeling specifications for a specific domain or system, ensuring model consistency.

[0066] Step S104: Start the execution engine for simulation, including starting the local or remote execution engine, deploying the model project to the execution engine, the execution engine loading the extension plug-in through the engine scheduler, calling the function in the executor in a certain sequence, and performing I / O reading and writing and logical processing.

[0067] Secondly, the functions in the executor or the functions in the parser can be understood as corresponding control instructions, and the corresponding steps are implemented by calling different functions.

[0068] By adopting the method provided by the present invention, the mechanism of the extended metamodel is plug-inized, the simulation modeling and operation scheduling interfaces are separated, and the coupling degree between the plug-in functional modules is reduced. The modeling scheduler and the engine scheduler can be integrated into the simulation modeling platform and the scheduling platform respectively. After the modeling work is completed in the simulation modeling platform, both local simulation and distributed simulation within a computer cluster can be performed. The modeling scheduler and the engine scheduler interact with the parser and executor in the extended plug-in respectively. The two have their own functional responsibilities and create and destroy corresponding instance handles through different export functions. Under the premise of being compatible with the old interface, the interface can be expanded according to demand to achieve functional iteration.

[0069] In an exemplary embodiment of the present invention, the modeling scheduler is used to load the extension plug-in, and the functions in the parser are called in a certain sequence, including:

[0070] Get the extension plug-in to be used, and load the extension plug-in dynamic library through the modeling scheduler; call the extension plug-in's export function to create the parser to create the parser; detect the interface version used by the current extension plug-in to determine whether it belongs to the supported version set. If not, destroy the parser, uninstall the plug-in library and end the process; if so, obtain the plug-in's name, base64 encoding of the icon and the plug-in's description information; register the log service to the plug-in, and the log output by the plug-in through the recorder is taken over by the modeling scheduler; detect the running environment and determine whether the running conditions are met. If not, destroy the parser, uninstall the plug-in library and end the process; if so, set the resource path and obtain the model attributes, determine whether there are model attributes that need to be preprocessed, if not, obtain the model variables, if so, set the model attributes and then obtain the model variables; call the extension plug-in's export function to destroy the parser, and uninstall the extension plug-in dynamic library to end the process.

[0071] In this embodiment, an actual usage process of the interaction between the modeling scheduler and the extension plug-in is given as an example:

[0072] Step S201: When performing function modeling, the user selects an extension plug-in to be used from a plug-in list, and the modeling scheduler loads the extension plug-in dynamic library.

[0073] Step S202: The modeling scheduler calls the "create parser" export function of the extension plug-in to obtain the pointer handle handle of the parser class instance. All logical processing functions are implemented by calling the corresponding interface through the handle.

[0074] Step S203: The modeling scheduler calls the "get plugin version" interface pointed to by the handle to detect the interface version used by the current extension plugin to ensure compatibility between different versions of the interface.

[0075] Step S204: Check whether the plug-in version belongs to the supported version set. If yes, jump to step S205; otherwise, jump to step S214.

[0076] Step S205: The modeling scheduler calls the "Get Plugin Name" interface pointed to by handle to obtain the plug-in name; calls the "Get Icon" interface to obtain the base64 encoding of the plug-in icon; calls the "Get Description" interface to obtain the description information of the plug-in; this information is used for interface display and resource management.

[0077] Step S206: The modeling scheduler calls the "register log recorder" interface pointed to by handle, and the modeling scheduler registers the log service to the plug-in. The logs output by the plug-in through the recorder are taken over by the modeling scheduler, which facilitates unified management of the logs.

[0078] Step S207: The modeling scheduler calls the "detect running environment" interface pointed to by handle. If external services (such as MATLAB, Inchron, etc.) are introduced into the plug-in, it will determine whether the external services can be called in this interface and return a Boolean value.

[0079] Step S208: Check whether the plug-in is executable. If so, jump to step S209; otherwise, jump to step S214.

[0080] Step S209: The modeling scheduler calls the "set resource path" interface pointed to by the handle. The resource path includes the workspace, project path, and plug-in path. The modeling scheduler manages the resources in a unified manner. Even if the engineering project is migrated to different platforms and different hosts, it can ensure that the plug-in can access the file resources with the correct path.

[0081] Step S210: The modeling scheduler calls the "get model attributes" interface pointed to by handle, and the modeling scheduler displays the obtained preset attributes on the interface. The user can edit the preset attributes and configure additional custom attributes.

[0082] Step S211: Check whether the attribute list needs preprocessing. If yes, jump to step S212; otherwise, jump to step S213.

[0083] Step S212: The modeling scheduler calls the "set model attributes" interface pointed to by handle, and the plug-in performs preprocessing according to the attribute list.

[0084] Step S213: The modeling scheduler calls the "get model variables" interface pointed to by handle, and the plug-in returns the I / O port information to the modeling scheduler. The plug-in is allowed to preset ports, and the user is also allowed to configure additional ports.

[0085] Step S214: the modeling scheduler calls the "destroy parser" export function of the extension plug-in to reclaim the system resources pointed to by the pointer handle handle.

[0086] Step S215: The modeling scheduler uninstalls the extension plug-in dynamic library.

[0087] In an exemplary embodiment of the present invention, the execution engine loads an extension plug-in through an engine scheduler, and calls functions in the executor in a certain sequence, including:

[0088] After receiving the control command to start the simulation execution, the extension plug-in dynamic library is loaded through the engine scheduler; the export function of the extension plug-in to create the executor is called to create the executor; the interface version used by the current extension plug-in is detected to determine whether it belongs to the supported version set. If not, the executor is destroyed and the plug-in library is uninstalled to end the process; if so, the status monitoring callback function and plug-in metadata are registered to the plug-in; the log service is registered to the plug-in, and the log output by the plug-in through the recorder is taken over by the engine scheduler; the operating environment is detected to determine whether the operating conditions are met. If not, the executor is destroyed and the plug-in library is uninstalled to end the process; If available, register the port data definition parser, and the plug-in obtains the memory layout of the data block through the data definition parser; register the resource path to the plug-in, and the plug-in locates the physical storage location of the file through the resource path and the file relative path attribute configured during modeling; set the input and output port domains and register the data reader and writer; set the plug-in switching state from initialization or stop to run, triggering the state callback; execute data simulation, and determine whether it is periodically scheduled. If so, return to the trigger state callback. If not, call the export function of the extension plug-in's destruction executor to destroy the executor, and uninstall the extension plug-in dynamic library to end the process.

[0089] In this embodiment, an actual usage process of the interaction between the engine scheduler and the extension plug-in is given as an example:

[0090] Step S301: After the user starts the simulation execution, the engine scheduler loads the extension plug-in dynamic library.

[0091] Step S302: The engine scheduler calls the "create executor" export function of the extension plug-in to obtain the pointer handle handle of the executor class instance. All logical processing functions are implemented by calling the corresponding interface through the handle.

[0092] Step S303: The engine scheduler calls the "get plugin version" interface pointed to by the handle to detect the interface version used by the current extension plugin to ensure compatibility between different versions of the interface.

[0093] Step S304: Check whether the plug-in version belongs to the supported version set. If yes, jump to step S305; otherwise, jump to step S317.

[0094] Step S305: The engine scheduler calls the "register context information" interface pointed to by the handle to register the status monitoring callback function, plug-in metadata, etc. to the plug-in.

[0095] Step S306: The engine scheduler calls the "register log recorder" interface pointed to by handle, and the engine scheduler registers the log service to the plug-in. The logs output by the plug-in through the logger are taken over by the engine scheduler, which facilitates unified management of the logs.

[0096] Step S307: The engine scheduler calls the "detect running environment" interface pointed to by the handle. If an external service is introduced into the plug-in, it will determine whether the external service can be called in the interface and return a Boolean value.

[0097] Step S308: Check whether the plug-in is executable. If so, jump to step S309; otherwise, jump to step S317.

[0098] Step S309: The engine scheduler calls the "registered port data definition parser" interface pointed to by the handle. The I / O port transmits a data block, which contains multiple signals (variables). The plug-in can obtain the memory layout of the data block through the data definition parser.

[0099] Step S310: The engine scheduler calls the "initialization" interface pointed to by the handle, and the engine scheduler registers the resource path to the plug-in, including the workspace, project path, and plug-in path. The plug-in can locate the physical storage location of the file through the resource path and the file relative path attribute configured during modeling.

[0100] Step S311: The engine scheduler calls the "Set Input / Output Port Domain" interface pointed to by the handle. The engine scheduler sets the I / O port's data address, data block size, port name and other descriptive information to the plug-in. The plug-in will read input data from the data address or write output data to the data address.

[0101] Step S312: The engine scheduler calls the "registered data reader / writer" interface pointed to by the handle. The plug-in can obtain or set the data value of the data block or the signal in the data block through the data address and reader / writer.

[0102] Step S313: The plug-in switches state (from initialization or stop to running), triggering a state callback.

[0103] Step S314: the engine scheduler calls the "execution" interface pointed to by the handle to run the data simulation.

[0104] Step S315: The plug-in switches state (from running to stopped), triggering a state callback.

[0105] Step S316: Check whether periodic scheduling is required. If yes, jump to step S313; otherwise, jump to step S317.

[0106] Step S317: the engine scheduler calls the "destroy executor" export function of the extension plug-in to reclaim the system resources pointed to by the pointer handle handle.

[0107] Step S318: The engine scheduler uninstalls the extension plug-in dynamic library.

[0108] This application provides flexible function configuration and port management during simulation modeling. Plug-in writers provide key necessary configurations, and plug-in users dynamically update and extend them as needed, improving the applicability of plug-ins in different scenarios and reducing development and maintenance costs.

[0109] Furthermore, version management ensures compatibility across interface iterations. The modeling scheduler and engine scheduler provide long-term support for extensions developed based on both new and old interface versions. Data management organizes I / O port data using data blocks. Each port can be bound to a data block, which can contain multiple variables of any basic type. Defining a data block format once allows for multiple references across different functional modules. This unified data format reduces the complexity of configuring variable ports.

[0110] In a second aspect, the present invention further provides a simulation system for extending a virtual integrated system metamodel, comprising a modeling scheduler, an engine scheduler, and an extension plug-in module, wherein the modeling scheduler and the engine scheduler are respectively connected to the extension plug-in module, the modeling scheduler comprises a parser, the engine scheduler comprises an executor, and the executor comprises an input port and an output port;

[0111] It also includes a main control module connected with the modeling scheduler, engine scheduler and extension plug-in module, and used for executing the above-mentioned simulation method of an extended virtual integrated system metamodel.

[0112] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0113] If the integrated unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored on a computer-readable storage medium. This computer software product, stored on a storage medium, includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0114] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A simulation method for extending a virtual integrated system metamodel, characterized in that: include: Set up the parser and executor within the extension plugin and write the plugin code; Compile the plug-in into a library file and place it in the simulation environment directory; Perform functional modeling in the simulation modeling platform, including loading extension plug-ins through the modeling scheduler, calling functions in the parser, and extending the metamodel; Start the execution engine for simulation, including starting the local or remote execution engine, deploying the model project to the execution engine, the execution engine loading the extension plug-in through the engine scheduler, calling the function in the executor, and performing I / O reading and writing and logic processing; The method of loading the extension plug-in through the modeling scheduler and calling the function in the parser to extend the metamodel includes: Get the extension plug-in to be used and load the extension plug-in dynamic library through the modeling scheduler; Call the export function of the extension plug-in to create the parser; Detect the interface version used by the current extension plug-in to determine whether it belongs to the supported version set. If not, destroy the parser and uninstall the plug-in library to end the process; If yes, get the plugin name, base64 encoding of the icon and plugin description; Register the log service to the plug-in, and the logs output by the plug-in through the logger are taken over by the modeling scheduler; Detect the running environment and determine whether the running conditions are met. If not, destroy the parser, uninstall the plug-in library, and end the process; If so, set the resource path and obtain the model attributes to determine whether there are model attributes that need to be preprocessed. If not, obtain the model variables. If so, set the model attributes and then obtain the model variables. Call the export function of the extension plug-in to destroy the parser, destroy the parser, uninstall the extension plug-in dynamic library, and end the process.

2. The simulation method of an extended virtual integrated system metamodel according to claim 1, characterized in that: The execution engine loads the extension plug-in through the engine scheduler, calls the function in the executor, and performs I / O reading and writing and logic processing, including: After receiving the control command to start the simulation execution, the extension plug-in dynamic library is loaded through the engine scheduler; Call the export function of the extension plug-in to create the executor to create the executor; Detect the interface version used by the current extension plug-in to determine whether it belongs to the supported version set. If not, destroy the executor and uninstall the plug-in library to end the process; If so, register the status monitoring callback function and plugin metadata to the plugin; Register the log service with the plug-in. The logs output by the plug-in through the logger are taken over by the engine scheduler. Detect the operating environment and determine whether the operating conditions are met. If not, destroy the executor and uninstall the plug-in library to end the process; If available, the port data definition parser is registered and the plug-in obtains the memory layout of the data block through the data definition parser; Register the resource path to the plug-in. The plug-in locates the physical storage location of the file through the resource path and the file relative path property configured during modeling. Set the input and output port fields and register data readers and writers; Set the plug-in switching state from initialization or stop to running, triggering the state callback; Execute data simulation to determine whether it is periodically scheduled. If so, return to the trigger state callback. If not, call the export function of the extension plug-in to destroy the executor, destroy the executor, and uninstall the extension plug-in dynamic library to end the process.

3. The simulation method of an extended virtual integrated system metamodel according to claim 2, characterized in that: The resource path includes a workspace, a project path, and a plug-in path.

4. The simulation method of an extended virtual integrated system metamodel according to claim 3, characterized in that: The detection operating environment includes: If an external service is introduced into the plug-in, this interface will determine whether the external service is callable and return a Boolean value.

5. The simulation method of an extended virtual integrated system metamodel according to claim 3, characterized in that: The setting of the input and output port domains includes: The engine scheduler sets the data address, data block size, and port name description information of the I / O port to the plug-in. The plug-in will read input data from the data address or write output data to the data address.

6. The simulation method of an extended virtual integrated system metamodel according to claim 3, characterized in that: The registration data reader / writer includes: The plug-in can obtain or set the data value of the data block or the signal in the data block through the data address and reader / writer; The data structure of the data block includes the data address of the data block, the data block length, the signal byte offset, the signal word offset, the signal length, and the signal initial value.

7. A simulation system for extending a virtual integrated system metamodel, characterized in that: The system comprises a modeling scheduler, an engine scheduler and an extension plug-in module, wherein the modeling scheduler and the engine scheduler are respectively connected to the extension plug-in module, the modeling scheduler comprises a parser, the engine scheduler comprises an executor, and the executor comprises an input port and an output port; It also includes a main control module connected to the modeling scheduler, engine scheduler and extension plug-in module, and is used to execute a simulation method of an extended virtual integrated system metamodel according to any one of claims 1-6.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the simulation method of the extended virtual integrated system metamodel according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it is a simulation method for an extended virtual integrated system metamodel according to any one of claims 1 to 6.

Images