Computer-implemented method and orchestration system for orchestrating the configuration of simulations based on a digital twin model of a modular plant

Abstract

Modular Plant (P m Based on the digital twin models (DTM1, DTM2, DTM3) of the three systems (PM1, PM2, PM3), the Functional Mock-up Unit (FMU) is used to orchestrate the configuration of the model-based simulation so that the configuration of the simulation is automatically generated and deployed. <fmu>"Functional Mock-up Interface" combined with "FMU-T" function <fmi>Logical "System Structure and Parameterization" function (FMI-T) <ssp>Based on the SSP-T function, (1) distributed OT (Operational-Technology) applications (OTA) in modular plants d , ED1, ED2, ED3), the automation data (AD1, AD2, AD3) captured for the automation of the plant, and the simulation model components (MC s,1 , M.C. s,2 , M.C. s,3 (2) in the process of orchestrating the configuration of the simulation, deploying the model components of the simulation to distributed OT applications (dpl), and during this deployment, providing the distributed OT applications with “Functional Mock-up Units” as part of the FMI functionality. <fmu>" functions (FMU-T1, FMU-T2, FMU-T3) and, for distributed OT applications, as part of the FMI function in a server-client manner, "Remote Procedure Call" with "Proxy FMU" entities (PFMU-E1, PFMU-E2, PFMU-E3) embedded in the SSP functions and corresponding "Controlled FMU" entities (RCFMU-E1, RCFMU-E2, RCFMU-E3) running in the distributed OT applications. <rpc>" Performs technology-based proxy FMU functions (PFMU-T1, PFMU-T2, PFMU-T3).< / rpc> < / fmu> < / ssp> < / fmi> < / fmu>

Description

[Technical Field]

[0001] The present invention relates to a computer-implemented method (a method executed by a computer) for orchestrating (automating construction / operation) the configuration of a simulation based on a digital twin model of a modular plant, as set forth in the first paragraph of claim 1, and to an orchestration system for orchestrating the configuration of a simulation based on a digital twin model of a modular plant, as set forth in the first paragraph of claim 3. [Background technology]

[0002] Plants in various technology sectors, such as industrial (e.g., metal processing and chemical processing), medical, energy, and telecommunications, are becoming modular, with plant owners outsourcing the task to equipment suppliers, who provide modular equipment that incorporates all automation and analytical functions.

[0003] For plant owners, there are vendor-agnostic solutions for integrating automation (MTP, PackML, and many others) into the orchestration layer, but no solutions exist for distributed analysis and simulation at the edge of the equipment. This application addresses this issue.

[0004] There are some specific issues with distributed analysis and simulation on edge devices. Distributed simulation is not currently supported on edge infrastructures that have access to field data. Integrating these distributed edge applications into automation takes time - in most cases, it requires the Open Platform Communications Unified Architecture (OPCUA) specified by the tag. <opcua>Complex orchestrations are required to enable, connect, and validate according to tags, and synchronization routines must be developed. Excessive reliance on hardware, software and operating systems, and on simulation and simulation orchestration. Complex deployment of distributed simulations across many edge devices due to synchronization.

[0005] However, even if solutions for such applications were available today, the majority of the functionality required was developed specifically for single-use and therefore not scalable or widely replicable in volume. Furthermore, the applications require point-to-point communication and synchronization that are tightly dependent on vendor software. Summary of the Invention

[0006] The object of the present invention is to propose a computer-implemented method and an orchestration system for orchestrating the configuration of a simulation based on a digital twin model of a modular plant, whereby the configuration of the model-based simulation is automatically generated and deployed during the orchestration process.

[0007] This object is solved by the features in the particular subject matter of claim 1 with respect to a computer-implemented method as defined in the preamble of claim 1.

[0008] This object is further solved by a computer-implemented tool for executing the computer-implemented method according to claim 2.

[0009] This object is further solved by the features in the particular subject matter of claim 3 with respect to an orchestration simulator as defined in the preamble of claim 3.

[0010] The gist of the inventions of claims 1, 2 and 3 is a digital twin model of a modular plant and a "Functional Mock-up Unit" <fmu>" Functional Mock-up Interface <fmi>Logical "System Structure and Parameterization" function <ssp>" function, and to orchestrate the configuration of a simulation based on the "Functional Mock-up Unit" function, (1) for a distributed Operational-Technology (OT) application of a modular plant (the OT application is an edge device of a field device), generating a simulation (simulated) model component that includes an allocation rule for automation data captured for automation of the plant and is assigned to the distributed OT application; (2) in the process of orchestrating the configuration of the simulation, deploying the simulation model component to the distributed OT application, and in this deployment, assigning a "Functional Mock-up Unit" to the distributed OT application as part of the FMI function. <fmu>" functionality, and for distributed OT applications, as part of the server-client FMI functionality, "Proxy FMU" entities embedded in SSP functionality and Corresponding "controlled FMU" entities running in distributed OT applications "Remote Procedure Call" <rpc>” Execute technology-based proxy FMU functions, and (3) deploy automation data to distributed OT applications as a result of deployment of the simulation model components according to automation data allocation rules.

[0011] Summary of the features used: A runtime for running distributed digital twins on edge infrastructure Abstraction layer for distributed simulation and analysis - Field device and field data integration into abstraction layer "Operational-Technology" in OT infrastructure and automation systems <ot>Combining Co-Simulation Environments for the "Aspect" - Functional Mock-up Unit accessible even for remote simulation components <fmu>" in combination with the standard "Functional Mock-up Interface <fmi>(Reference: https: / / fmi-standard.org) Automatic generation and deployment of simulation components in OT infrastructure

[0012] The combination of Digital Enterprise capabilities, tools, artifacts, and elements is leveraged through the use of a distributed abstraction layer for the digital twin runtime environment.

[0013] This application allows OT Edge to interconnect standardized simulation objects that can be deployed on edge devices and harmonize them via an intelligent vendor-agnostic orchestration master algorithm (see Figures 1, 3, and 4) from the vendor.

[0014] These figures show the concept of how to execute and process an FMU call to an FMU in a remote device.

[0015] For the purposes of explaining the concepts below, assume you have a simulation in the form of an FMU called "myFmu".

[0016] Parameterized proxy FMU on the server The idea is to have a generic FMU that acts as a proxy for a remote FMU. Since this proxy is also an FMU, it must perform all the functions specified in the FMI standard. This FMU is totally generic, even if its functions do not perform the actual simulation, but only perform RPC calls to the remote FMU. Therefore, this proxy can be thought of as a remote controller for other FMUs.

[0017] There are essentially two things that make a particular instance of a proxy FMU: Remotely controlled (remotely controlled) actual simulation FMU URI to reach the remotely controlled (remotely controlled) FMU

[0018] Thus, given a "myFmu" and an empty generic proxy FMU "proxyFmu", a specific proxy FMU instance for "myFmu" can be created as follows: 1. Create a proper modelDescription.xml: The idea is that the generated proxy FMU will have exactly the same input and output information as "myFmu". This can be achieved very easily by just copying the exact same "modelDescription.xml" file from the original FMU. No other changes to this file are required. 2. Creating "proxyMyFmu": Since an FMU is just a ZIP archive, we can create a new one based on "proxyFmu" to which we have added the previously generated "modelDescription.xml" file. Furthermore, we can add any other files we need to the ZIP archive. In particular, we can use it to add a configuration file to the proxy FMU's resource folder that contains information such as where the remotely controlled FMU is located (i.e., its remote hostname) and the port that the corresponding FMU remote controller should query.

[0019] You now have a valid FMU called "proxyMyFmu" that you can use like any other to orchestrate simulations in your FMU-based simulation tool / library.

[0020] The implementation of "proxyFmu" can be totally generic since everything is basically as follows: 1. It acts as an RPC client and, upon instantiation, passes a Uniform Resource Identifier ("Uniform Resource Identifier") <uri>" given by the well-known "Remote Procedure Call <rpc>It connects to a remote RPC server of the "Remote Procedure Call" technology (see https: / / en.wikipedia.org / wiki / Remote_procedure_call, July 23, 2021 edition). As mentioned above, this URI is obtained from the dedicated file that contains it. 2. It executes all the functions specified in the FMI standard, but instead of actually doing anything in the execution of these functions, it simply serializes the function arguments and makes the corresponding RPC call to its RPC server.

[0021] Remotely controlled FMU on the device (client) The client side consists of a generic RPC server part whose role is to accept RPC calls coming from "proxyFmu" like "proxyMyFmu". It does the following: 1. Deserialize the function arguments. 2. Call the corresponding function in the actual FMU (which is nothing more than a library that implements the functions specified in the FMI standard). We need to know what the actual FMU is so that we can extract this library and load it dynamically at runtime. Therefore, this information should ideally come from the deployment step and could be given, for example, as an argument when starting the corresponding "Docker" container (see https: / / en.wikipedia.org / wiki / Docker_(software) as of July 7, 2021). 3. The result of the function call is then finally returned as the response to the RPC request. 4. Each FMU has a set of input and output definitions, each given by name and value type (e.g., integer, float, Boolean, string) in the "modelDescription.xml" file. Orchestrating a distributed simulation built from such individual FMUs (regardless of where or on which edge device the individual FMUs are running) involves connecting such inputs and outputs. Typically, the aforementioned modular plants contain data coming from field devices made available by field buses, and such data should be part of the relevant simulation in a natural way, in other words, entering the simulation model as inputs. As a result, not only do FMU inputs usually come from the outputs of other FMUs, but some also come directly as (signal) data from field devices. This is something that also needs to be configured when the entire distributed simulation is being orchestrated. To be precise, not only FMU inputs and outputs need to be mapped, but also automation data names need to be mapped to the corresponding FMU inputs. The former kind of mapping, i.e., input and output mapping, is described in the "System Structure & Parameterization" document. <ssp>(see https: / / ssp-standard.org), but there is no such standard for mapping automation data. Here we propose: During the deployment process, a data mapping is generated and placed into the remotely controlled FMU. Information in the SSP topology file can define which field signals are required by the FMU, which often allows the process to be automated. This can also be a simple configuration file such as "YAML" (see https: / / en.wikipedia.org / wiki / YAML for the June 23, 2021 version) placed inside a ZIP archive. The remote control service reads this signal mapping, periodically reads the configured data name, and passes the value to the actual FMU function call as needed. If new values ​​are memorized immediately when they arrive, it is guaranteed that the latest value will always be passed to the FMU function, and a simple subscription model is sufficient.

[0022] Like the server part, the service described here (called "fmuRemoteController") is also totally generic: the actual instance of this service only needs to know where the FMU library can call its functions (see Figure 3, which shows the sequence of RPC calls).

[0023] The disclosed orchestration system enables the deployment of a distributed OT digital twin runtime to edge devices with access to field data in modular plants.

[0024] Known applications have deep dependencies, require a lot of manual extensions, and are difficult to adapt to different applications.

[0025] The proposed concept abstracts all these aspects and allows simulation and analytical model suppliers to deploy their own OT systems as part of an Edge Ecosystem reducing their dependency footprint.

[0026] 1. The actual RPC technology is not that difficult to replace. The only parts that need to be adapted are "proxyFmu" and "fmuRemoteController". 2. Instances like "proxyMyFmu" are just regular FMUs. They do nothing different from the simulation tool's point of view. They can be orchestrated and executed just like any other, and the remote invocation part is totally hidden within them. 3. Any simulation tool or library such as "Amesim", "Simulink", "fmpy", "libcosim" can be used. 4. Remote FMI / FMU is automatically generated. 5. The FMI / FMU is automatically deployed to the corresponding OT system (depending on the field variables). 6. The SSP standard is used to connect OT signals.

[0027] Further advantageous developments of the invention are given by the independent claims.

[0028] Further advantageous developments of the invention are given by the following description of a preferred embodiment of the invention using figures 1 to 4. [Brief explanation of the drawings]

[0029] [Figure 1] A scenario for orchestrating the configuration of a model-based simulation of a modular plant. [Figure 2] A computer-executed tool, specifically the principle expression of a computer program product designed as, for example, an APP. [Figure 3] Server-client method "Remote Procedure Call" <rpc>” An illustrative message flow diagram that deploys simulated model components by executing technology-based Proxy-FMU-functions. [Figure 4] An illustration of the orchestration flow between the involved units of the "server-client" based scenario shown in Figure 1. DETAILED DESCRIPTION OF THE INVENTION

[0030] Figure 1 shows the modular structure P m This figure shows a server-client based scenario for orchestrating the configuration of a model-based simulation of a plant having a modular structure P m The plant having the above-described structure can be considered as a modular plant and includes three exemplary plant modules, a first plant module PM1, a second plant module PM2, and a third plant module PM3. The modular plants PM1, PM2, and PM3 all have the same plant configuration.

[0031] A first plant module control system CS1 belonging to a first modular plant PM1 is connected or assigned to a first digital twin model DTM1 on the one hand and to automated equipment or processes, which are shown in FIG. 1 as robots, on the other hand. The first plant module control system CS1 includes a first "Programmable Logic Controller" (PDC) as generally known. <plc>The first edge device ED1 is connected to a first field device FD1, which includes a first edge device ED1. In a preferred embodiment of the present invention, the first edge device ED1 is connected to a distributed OT application OTA d In this regard, in accordance with the objectives of the present invention, and in an orchestration process, model-based simulation configurations are automatically generated and deployed.

[0032] There is a second modular plant PM2 and a third modular plant PM3 with the same configuration.

[0033] A second plant module control system CS2 belonging to a second modular plant PM2 is again connected or assigned to a second digital twin model DTM2 on the one hand and to automated equipment or processes, which are shown in FIG. 1 as robots, on the other hand. The second plant module control system CS2 also includes a second "Programmable Logic Controller <plc>The second edge device ED2 is connected to a second field device FD2, which in a preferred embodiment of the present invention is a distributed OT application OTA d In this regard, in accordance with the objectives of the present invention, and in an orchestration process, model-based simulation configurations are automatically generated and deployed.

[0034] A third plant module control system CS3 belonging to a third modular plant PM3 is again connected or assigned to a third digital twin model DTM3 on the one hand and to automated equipment or processes, which are shown in FIG. 1 as robots, on the other hand. The third plant module control system CS3 also includes a third "Programmable Logic Controller <plc>The third edge device ED3 is connected to a third field device FD3, which includes a third edge device ED3. In a preferred embodiment of the present invention, the third edge device ED3 is connected to a third field device FD3, which includes a third edge device ED3. d In this regard, in accordance with the objectives of the present invention, and in an orchestration process, model-based simulation configurations are automatically generated and deployed.

[0035] According to FIG. 1, orchestration is performed by the orchestration system OS, which, for example, in the preferred simplest design, is an extended simulator that includes SSP functions, FMI / FMU functions, and orchestrates the configuration of simulations based on digital twin models DTM1, DTM2, and DTM3 of modular plants PM1, PM2, and PM3, and includes a server controller SCRT to configure the model-based simulation.

[0036] According to the illustrated "server-client" based scenario, the server-controller SCRT of the orchestration system OS is the "server" and the edge devices ED1, ED2, ED3 of the modular plants PM1, PM2, PM3 are the "clients".

[0037] During the orchestration process, the server controller SCRT, as part of the deployment tool DT, implements the well-known (see https: / / ssp-standard.org) logical "System Structure and Parameterization" <ssp>It includes the tool SSP-T, which logically describes how model components for simulation are connected and configured for expansion into composite components, and how model parameterization data is stored and exchanged between each model component and the composite component. <ssp>The tool SSP-T is a "ZIP archive" based "Functional Mock-up Unit" <fmu>"Functional Mock-up Interface" for sharing simulations via the tool, FMU-T packing XML files, and compiled C code <fmi>" tool FMI-T (see https: / / fmi-standard.org).

[0038] Furthermore, in the orchestration process, the server controller SCRT includes a generation unit GU, which generates OT applications OTA distributed to edge devices ED1, ED2, and ED3 of the modular plants PM1, PM2, and PM3 based on digital twin models DTM1, DTM2, and DTM3 of the modular plants PM1, PM2, and PM3, respectively. d (1) at least one first simulation model component MC for a first edge device ED1; s,1 (2) at least one second simulation model component MC for a second edge device ED2; s,2 and (3) at least one third simulation model component MC for a third edge device ED3. s,3 , generate grt.

[0039] For this purpose, the first simulation model component MC s,1 includes a first allocation rule AR1 for a first automation data AD1 that is assigned to a first edge device ED1, and a model component MC of a second simulation s,2 includes a second allocation rule AR2 for the second automation data AD2 to be allocated to the second edge device ED2, and a third simulation model component MC s,3 includes a third allocation rule AR3 for the third automation data AD3 that is allocated to the third edge device ED3.

[0040] These generated information MC s,1 , M.C. s,2 , M.C. s,3 , AR1, AR2, AR3, AD1, AD2, AD3 are OT applications distributed to edge devices ED1, ED2, ED3 of modular plants PM1, PM2, PM3, respectively. d In the server controller SCRT, the information is transferred to the deployment tool DT for deployment.

[0041] For this purpose, the deployment tool DT of the server controller SCRT deploys the OT application OTA distributed to each of the edge devices ED1, ED2, and ED3. d Simulation of model components MC s,1 , M.C. s,2 , M.C. s,3 Expand dpl. In this expansion, -FMI function FMI-T is part of the "Functional Mock-up Unit" <fmu>(1) a first “Functional Mock-up Unit” for a first edge device ED1; <fmu>(2) a second “Functional Mock-up Unit” for a second edge device ED2; <fmu>” functional FMU-T2, and (3) a third “Functional Mock-up Unit” for the first edge device ED3. <fmu>" function FMU-T3, using, OT application OTA distributed to edge devices ED1, ED2, and ED3 d Regarding the client-server FMI functionality, as part of FMI-T, the well-known "Remote Procedure Call" <rpc>" technology (see https: / / en.wikipedia.org / wiki / Remote_procedure_call, July 23, 2021 edition), a proxy FMU function is provided, (1) a first proxy FMU function PFMU-T1 having a first "proxy FMU" entity PFMU-E1 embedded in an SSP function SSP-T of a server controller SCRT and a corresponding first "remotely controlled FMU" entity RCFMU-E1 executed in a first client controller CCRT1 of a first edge device ED1, the first "proxy FMU" entity PFMU-E1 including first automation data AD1 assigned to and to be deployed on a first edge device ED1, and (2) a second "proxy FMU" entity PFMU-E2 embedded in an SSP function SSP-T of a server controller SCRT. (2) a second proxy FMU function PFMU-T2 and a corresponding second "remotely controlled FMU" entity RCFMU-E2 executed in a second client controller CCRT2 of the second edge device ED2, including second automation data AD2 allocated to and to be deployed on the second edge device ED2; (3) a third proxy FMU function PFMU-T3 having a third "proxy FMU" entity PFMU-E3 embedded in an SSP function SSP-T of the server controller SCRT, and a corresponding third "remotely controlled FMU" entity RCFMU-E3 executed in a third client controller CCRT3 of the third edge device ED3, including third automation data AD3 allocated to and to be deployed on the third edge device ED3.

[0042] Furthermore, the deployment tool DT assigns the automation data AD1, AD2, AD3 to the model component MC of the simulation according to the assignment rules AR1, AR2, AR3 for the automation data AD1, AD2, AD3. s,1 , M.C. s,2 , M.C. s,3 As a result of the deployment of dpl, an OT application OTA is distributed to each of the edge devices ED1, ED2, and ED3. d It is designed to be deployed in dpl.

[0043] Furthermore, the orchestration system OS can be designed as a hardware solution or can be realized as a software solution in which the orchestration system OS is a computer-executed tool CIT, which is nothing but a computer program (product) preferably designed as an APP, which can be uploaded to the server controller SCRT.

[0044] 2 shows a principle diagram of a computer-executed tool CIT, showing how the tool can be designed. According to the illustration, the computer-executed tool CIT comprises a non-transitory processor-readable storage medium STM containing processor-readable program instructions of a program module PGM for specifying the operation of a cyber-physical system (CPS) stored in the non-transitory processor-readable storage medium STM, and a processor PRC connected to the storage medium STM and executing the processor-readable program instructions of the program module PGM to specify the operation of the cyber-physical system.

[0045] Figure 3 starts from Figure 1 and, based on the corresponding explanation of Figure 1, shows how to use "Remote Procedure Call" in a server-client manner. <rpc>1 illustrates a message flow diagram for deploying a model component of a simulation by executing a technology-based proxy FMU function.

[0046] Starting from Fig. 1 and based on the corresponding description of Fig. 1, Fig. 4 illustrates the orchestration flow between the relevant units of the "server-client" based scenario shown in Fig. 1. The orchestration flow between the server controller SCRT, which includes the orchestration entity responsible for the orchestration, and the management client entity responsible for managing the client, is TCP / IP-based (see https: / / en.wikipedia.org / wiki / Internet_Protocol, version of July 25, 2021).< / rpc> < / rpc> < / fmu> < / fmu> < / fmu> < / fmu> < / fmi> < / fmu> < / ssp> < / ssp> < / plc> < / plc> < / plc> < / rpc> < / ssp> < / rpc> < / uri> < / fmi> < / fmu> < / ot> < / rpc> < / fmu> < / ssp> < / fmi> < / fmu> < / opcua>

Claims

1. Modular Plant (P ｍ , P.M. １ , P.M. ２ , P.M. ３ ) Digital Twin Model (DTM) １ , DTM ２ , DTM ３ 1. A computer-implemented method for orchestrating the configuration of a simulation based on: To configure model-based simulation, a) Logical "SSP: System Structure and Parameterization" function (SSP-T) a1) Logically describe the following a11) and a12). a11) how model components for simulation are connected and configured for evolution into composite components; and a12) How model parameterization data is stored and exchanged between each of the model components and the composite component. a2) Includes a "FMI: Functional Mock-up Interface" function (FMI-T) for sharing simulations via a "ZIP archive"-based "FMU: Functional Mock-up Unit" function (FMU-T) containing XML files and compiled C code; is used, b) the modular plant (P ｍ , P.M. １ , P.M. ２ , P.M. ３ ) distributed operational technology (OTA) applications ｄ , E.D. １ , E.D. ２ , E.D. ３ ), this distributed OT application is the edge device (ED) of the field device. １ , E.D. ２ , E.D. ３ ) with respect to the modular plant (P ｍ , P.M. １ , P.M. ２ , P.M. ３ Automation data (AD) captured for automation １ , A.D. ２ , A.D. ３ ) allocation rule (AR １ , A.R. ２ , A.R. ３ ) and the distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ) assigned to the simulation model component (MC ｓ，１ , M.C. ｓ，２ , M.C. ｓ，３ ) is generated (grt), c) orchestrating the configuration of a simulation, ｓ，１ , M.C. ｓ，２ , M.C. ｓ，３ ) to the distributed over-the-air (OTA) application ｄ , E.D. １ , E.D. ２ , E.D. ３ ) and during this deployment, the distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ) using the SSP function (SSP-T) having the FMU function (FMU-T) as part of the FMI function (FMI-T), and ｄ , E.D. １ , E.D. ２ , E.D. ３ ) as part of the FMI function (FMI-T) in a server-client system, A "Proxy FMU" entity (PFMU-E) embedded in said SSP function (SSP-T) １ , PFMU-E ２ , PFMU-E ３ ) and The distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ) and the corresponding "Controlled FMU" entity (RCFMU-E) １ , RCFMU-E ２ , RCFMU-E ３ ) Proxy FMU function (PFMU-T) based on "RPC: Remote Procedure Call" technology １ , PFMU-T ２ , PFMU-T ３ ) and d) the automation data (AD １ , A.D. ２ , A.D. ３ ) of the allocation rule (AR １ , A.R. ２ , A.R. ３ ) according to the model component (MC ｓ，１ , M.C. ｓ，２ , M.C. ｓ，３ As a result of the deployment (dpl) of the distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ) to the automation data (AD １ , A.D. ２ , A.D. ３ ) is expanded (dpl), 10. A computer-implemented method comprising:

2. A computer implemented tool (CIT) for executing the computer implemented method of claim 1, comprising: a non-transitory processor-readable storage medium (STM) containing processor-readable program instructions of a program module (PGM) for performing the computer-implemented method stored on the non-transitory processor-readable storage medium (STM); a processor (PRC) connected to said storage medium (STM) and executing said processor-readable program instructions of said program module (PGM) to perform the computer-implemented method of claim 1; A computer-implemented tool (CIT) including:

3. Modular Plant (P ｍ , P.M. １ , P.M. ２ , P.M. ３ ) Digital Twin Model (DTM) １ , DTM ２ , DTM ３ An orchestration system (OS) that orchestrates the configuration of a simulation based on a) Logical "SSP: System Structure and Parameterization" Tool (SSP-T) a1) Logically describe the following a11) and a12). a11) how model components for simulation are connected and configured for evolution into composite components; and a12) How model parameterization data is stored and exchanged between each of the model components and the composite component. a2) Includes a "FMI: Functional Mock-up Interface" tool (FMI-T) for sharing simulations via a "ZIP archive"-based "FMU: Functional Mock-up Unit" tool (FMU-T) containing XML files and compiled C code; a server controller (SCRT) for configuring a model-based simulation, including: b) the modular plant (P ｍ , P.M. １ , P.M. ２ , P.M. ３ ) distributed operational technology (OTA) applications ｄ , E.D. １ , E.D. ２ , E.D. ３ ), this distributed OT application is the edge device (ED) of the field device. １ , E.D. ２ , E.D. ３ ) with respect to the modular plant (P ｍ , P.M. １ , P.M. ２ , P.M. ３ Automation data (AD) captured for automation １ , A.D. ２ , A.D. ３ ) allocation rule (AR １ , A.R. ２ , A.R. ３ ) and the distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ) assigned to the simulation model component (MC ｓ，１ , M.C. ｓ，２ , M.C. ｓ，３ a generation unit (GU) that generates (grt) c) a deployment tool (DT) of said server controller (SCRT), comprising: c1) In the process of orchestrating the configuration of a simulation, a model component (MC) of said simulation is ｓ，１ , M.C. ｓ，２ , M.C. ｓ，３ ) to the distributed over-the-air (OTA) application ｄ , E.D. １ , E.D. ２ , E.D. ３ ) and during this deployment, the distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ), using the SSP tool (SSP-T) having the FMU tool (FMU-T) as part of the FMI tool (FMI-T), and ｄ , E.D. １ , E.D. ２ , E.D. ３ ) as part of the FMI tool (FMI-T) in a server-client manner, A "Proxy FMU" entity (PFMU-E) embedded in the SSP tool (SSP-T) of the server controller (SCRT) １ , PFMU-E ２ , PFMU-E ３ ) and ・Client Controller (CCRT １ , CCRT ２ , CCRT ３ ) the distributed OT application (OTA) ｄ , E.D. １ , E.D. ２ , E.D. ３ ) and the corresponding "Controlled FMU" entity (RCFMU-E) １ , RCFMU-E ２ , RCFMU-E ３ ) Proxy FMU function (PFMU-T) based on "RPC: Remote Procedure Call" technology １ , PFMU-T ２ , PFMU-T ３ ) and c2) the automation data (AD １ , A.D. ２ , A.D. ３ ) of the allocation rule (AR １ , A.R. ２ , A.R. ３ ) according to the model component (MC ｓ，１ , M.C. ｓ，２ , M.C. ｓ，３ As a result of the deployment (dpl) of the distributed OT application (OTA ｄ , E.D. １ , E.D. ２ , E.D. ３ ) to the automation data (AD １ , A.D. ２ , A.D. ３ ) to deploy (dpl) the An orchestration system (OS) comprising:

4. a non-transitory processor-readable storage medium (STM) containing processor-readable program instructions of a program module (PGM) for orchestrating the configuration of a simulation stored in the non-transitory processor-readable storage medium (STM); a processor (PRC) connected to said storage medium (STM) and configured to execute said processor-readable program instructions of said program module (PGM) to orchestrate the configuration of a simulation; 4. An orchestration system (OS) according to claim 3, characterized in that it is implemented by a computer-implemented tool (CIT) having:

Images