WO2014146686A1 - Tool and method for simulating a technical installation - Google Patents

Abstract

The invention relates to a tool and method for simulating a technical installation having at least one simulator instance (1, 10), which comprises a plurality of components (2…8, 15, 16, 18) each realised as at least as one application. A plurality of components (3…8, 15, 18) carry out a model-based cyclic calculation of their new output values according to the particular input values. In order to avoid a central sequential control, the sequence is controlled in a data flow-oriented manner, by allocating each component input a memory cell which indicates whether a new input vale has already been processed or not. Newly calculated output values are transferred to component inputs in accordance with the stored data flow only when the component inputs are in the "processed" state. A parallelisation and especially efficient implementation of the calculations is advantageously rendered possible, wherein components can be distributed to local computers and/or across an entire network.

Description

description

Tool and method for simulating a technical plant

The invention relates to a tool for simulating a technical installation with at least one simulator instance comprising a plurality of components each realized as at least one application, wherein several of these components have inputs and outputs and for model-based, cyclical calculation of new output values in each simulation cycle Dependent on the respective input values are formed. In the construction of technical systems, especially in process plant engineering, the desire for integrated digital planning of the system to be realized is growing. Shortening the planning and construction phase while at the same time increasing quality means a lower return of investment for the plant operator. The digital planning of a virtual plant and its simulation makes it possible to test the planning results in order to avoid any unpleasant surprises during the later realization on the construction site and in the commissioning phase. Through simulation an attempt is made to get the most realistic possible test.

However, the use of system simulation does not end with the start of production on the system. For example, personnel can be trained on a virtual system during operation, regardless of the current production. In addition, optimizations and tests on the virtual system are possible without disturbing the real production. The simulation of the technical system then serves to optimize the operation of the plant or to improve the quality of the product produced on the plant.

The construction of a facility involves different trades, all of which have their own models and simulators. The operation of the simulators and the determination of the application limits The models require a deep understanding of the trades. Depending on the application and the test scenario, the necessary simulation models often vary. Process engineering plants are required for production in many different branches of industry. In addition to classical chemistry, for example, the pharmaceutical industry, food and beverage industry and the field of water and wastewater are mentioned. Depending on the application, domain-specific models and simulators are used for the simulation. Last but not least, every procedural plant is unique in its detail.

So far, models required for system simulation are often newly developed, regardless of the fact that models have already been developed in the planning. Usually only a simulation tool with a model for the entire system is used. Existing models and simulators will no longer be used. If, for example, existing models are still to be used from the planning, they must be transformed into suitable formats. In an automated way, this rarely succeeds. Manual transmission of the models, however, is time-consuming and prone to error. Simulation models contain process know-how and thus describe a substantial part of the capital of the plant operator. These models are kept under lock and key to protect the knowledge from imitators. For a simulation then only the externally recognizable behavior in the manner of a black box is available.

In order to be able to use existing models with the different domain-specific and trade-specific simulators, an attempt is made to couple the simulation tools. A point-to-point link between two simulators only solves the problem singularly. Such a solution is very static and often suitable only for a specific application. Changes to the boundary conditions cause a program change in the coupling. Model changes or even model reconfigurations for the simulation runtime are against this background hardly realizable. To coordinate the simulators involved in a co-simulation and to exchange data, a central sequential control system is required, which, due to its proprietary character, is subject to various adaptations due to test and application circumstances. A very important component in the interaction of the participating simulators is the avoidance or at least detection of a real-time violation.

The invention has for its object to provide a tool and a method for simulating a technical system, which allow in a simple way an improved interaction of several simulators involved in the simulation. To solve this problem, the new tool of the type mentioned in the features specified in claim 1. Advantageous developments of the tool are described in the dependent claims, a method for simulating a technical system in claim 10, a computer program and a digital storage medium in claims 11 and 12, respectively.

The invention has the advantage that a wide variety of industry-specific and domain-specific simulation models and simulators can each interact as components of a simulator instance. This makes it possible to model and simulate a technical system from a holistic point of view. In this case, no central sequence control for coordinating the components involved in the simulation is required in an advantageous manner, which would mean increased control and communication effort. Rather, the process is controlled by the processing of the data from the components according to the component dependencies specified in the data flow, so that it is possible to speak of a data flow-controlled process.

In an advantageous development, the simulation cycles have a nearly constant cycle duration and a component is designed as a so-called master to simulate simulation cycles. In each case, a time slice memory cell assigned to an input of a component is set to the status "not processed" and the components are informed of the valid system time.With virtually constant cycle time, the model-based calculations of the components are simplified and simulation calculations In the normal case, that is, if there is no real-time violation, the time-slot memory cell is in the "processed" state before a new simulation cycle is started by the master. However, if a real-time simulation by the master attempts to initiate a new simulation cycle, even though the time slice memory cell is still in the "not processed" state, there is a real-time violation and it is displayed as an error, although the simulators involved do not process the simulation Controlled by a central flow control, real-time violations can be detected and reported in a particularly effective and simple manner by this procedure, which would otherwise remain undetected and would result in an uncontrolled simulator behavior.

In a further advantageous refinement, a so-called manager component is provided for storing the data flow to be executed, in which the data flow is stored as a list of images of in each case one component output on one or more component inputs, wherein the illustrations additionally show the component input or the component inputs, respectively Identify associated memory cell. The data flow-oriented sequence control can thus be managed more easily since the memory cells and data connections assigned to the component inputs are stored in the same list.

When using a suitable framework to implement the tool, components of a simulator instance can added, removed or replaced at runtime. In order to avoid inconsistencies in the exchange of components, for example jumps in output values, it is necessary for components with memory, for example if a model-based computation has an integrator, to save the state of the component before replacement, and then to transition it to be able to restore. In an advantageous manner, the requisite storage required for this purpose can likewise be realized in the manager component.

In a particularly advantageous embodiment, a component for simulation coupling is provided, which is suitable for the application of any plant simulators to the simulator instance or supports the use of existing and specific plant models. Components for simulation coupling are therefore not only suitable for the connection of plant simulators, but also for the connection of other applications, such as executable models. Executable models may include different ones

Simulators are generated or simply developed by hand in any programming language.

If the interface of a system simulator or an executable model to be connected is not present in the Java programming language, but in C / C ++, the Java Native Interface (JNI) can advantageously be used for connection to the component for simulation coupling. This is advantageously not bound to platform-specific functions, for example Windows shared memory.

Advantageously, a distribution of simulator components on several simulator instances is made possible if each instance is provided with a component for simulation coupling remotes, by means of which the coupling between the instances can be realized.

In principle, different runtime frameworks are suitable for realizing the simulation tool, for example the Service Oriented Framework (SOF). However, the realization of a simulator instance as a co-simulation framework on the OSGI service platform has proven to be particularly advantageous. All components are dynamically integrated as so-called bundles by an OSGI framework. The OSGI framework is based on the Java programming language and is a modular and component-oriented software standard whose services can be offered locally and network-wide through a dynamic runtime system. Services are provided by the smallest modular unit of the OSGI framework, the so-called

 Bundles provided. Advantageously, the bundles of an OSGI framework can be dynamically installed, uninstalled, or even updated without having to pause or restart the system.

The invention is preferably implemented by loading suitable software onto one or more arithmetic units. The invention is thus on the one hand also a computer program with executable by a computer program code instructions and on the other hand, a storage medium with such a computer program, so a computer program product with program code means, as well as a tool for simulating a technical system, which is implemented with arithmetic units in their memory as means for Implementation of the simulation and its embodiments such a computer program is loaded or loadable.

With reference to the drawings, in which an embodiment of the invention is shown, the invention and refinements and advantages are explained in more detail below.

Show it:

Figure 1 is a block diagram of a tool for

 Simulation of a technical plant,

FIGS. 2A to 2D show a component network in each case in one of four states for illustrating a nes event-driven execution of a simulation cycle and

3 shows a section of a component network with concurrent processing.

The exemplary embodiment explained below shows a tool for simulating a technical system, which is implemented on the basis of the software platform of the OSGIAlliance. Alternatively, other runtime frameworks are suitable, for example the so-called service-oriented framework

 (SOF). However, the use of the OSGI Alliance platform proved particularly advantageous. As shown in FIG. 1, a simulator instance 1, which can also be referred to as a co-simulation framework 1, is composed of different components 2. The components 2 ... 8 are dynamically integrated as so-called bundles 2 ... 8 by an OSGI framework 9. The OSGI framework 9 is based on the Java programming language and is a modular and component-oriented software standard of the OSGI

Alliance, whose services can be offered locally and network-wide through a dynamic runtime system. Services are provided by the smallest modular unit of co-simulation framework 1, the Bundles 2 ... 8. This has the advantage that the bundles 2 ... 8 can be dynamically installed, uninstalled or even updated without having to stop or restart the system. The components 2... 8 of the simulator instance 1 realized as a co-simulation framework comprise a manager component 2, which can also be referred to as a simulation framework manager, components 3, 7 and 8 for simulation coupling, hereinafter also referred to as simulation couplings, of which the component 8 as Simulation coupling Remote for coupling the simulator instance 1 with another simulator instance 10 is used, as well as components 4, 5 and 6, which themselves contain models of sections of the technical system. The components 2... 8 have inputs and outputs which are not shown further in the figure and are used to model supported, cyclic calculation of new output values in each simulation cycle as a function of the respective input values. Internal models, as in components 4, 5 and 6, external models 11 and 12, as in components 3 and 7, or an external simulator instance 10 in component 8, which serves for remote simulation coupling, can be used.

The manager component 2 is responsible for the management of the simulator instance 1 and contains information about interdependencies of the components 3... 8 with one another and about their states. Due to the component dependencies, the sequence of simulation processing is defined as a function of the concatenation of the inputs and outputs of components 3 ... 8 to form a data flow path. Supported by the OSGI standard, the components 3 ... 8 of the simulator instance 1 can be added, removed or replaced at runtime. In order to avoid inconsistencies when exchanging components, for example jumps in the newly calculated values of outputs, for the components with memory, for example for the state of an integrator contained in a component, the state of the component before the exchange is stored in a state memory Managerkomponente 2 held in order to restore the state after replacement seamlessly. This state memory is advantageously also realized by the manager component 2.

Components 3 and 7 for simulation coupling can be used to connect any plant simulator to the OSGI Framework 9 and support the integration of existing and specific plant models. As an example, in Figure 1 by the component 3 in Figure 1, the simulation tool SIMIT, which is available from Siemens AG, connected as a system simulator 11. However, simulation coupling components can not only be used to connect to plant simulators, but also to couple other applications, such as executable models, to the OSGI framework 9. For example, executable models can be used by different simulators. be developed or simply developed by hand in any programming language. In the illustrated embodiment, the executable model 12 is connected to the OSGI framework 9 by the simulation coupling component 7. In order to realize a communication connection between component 3 and simulator 11 or between component 7 and executable model 12, various types of interfaces are available in principle. These include, for example, the OPC (Object Linking and Embedding for Process Control) standard, which is supported by many plant simulators. As a standardized model interface, for example, an FMI (Functional Mock-Up Interface) -conforming simulation coupling can be used. FMI is a standardized one

Interface for computer-aided simulations to develop complex systems with a model-based approach. Simulators are thus able to export executable models, so-called FMUs (Functional Mock-Up Units) with an FMI interface for coupling to other models. In the exemplary embodiment shown, two interfaces 13 and 14, which serve to connect the SIMIT simulator 11 or the executable model 12, are designed as JNI (Java Native Interface). This has the advantage that the interfaces 13 and 14 can be used for simulators or models that are not available in the Java programming language, for example in the C programming language. Moreover, they are not bound to platform-specific functions, for example Windows shared memory.

In order to enable the distribution of simulation components shown in FIG. 1 on two co-simulation frameworks 1 and 10, which in each case implement a simulator instance, the component 8 for simulation coupling is in the simulator instance 1 and another component 15 in the simulator instance 10 Simulation coupling provided, which are interconnected via communication interfaces. With such remote simulation coupling components, the data exchange and the communication between different simulator instances are supported computer-localized or network-wide. In the particular instance in which they are located they represent the respectively connected simulator instance. For example, in FIG. 1, the simulator instance 10 is represented by the component 8 with its data inputs and data outputs in the simulator instance 1. By way of example, the simulator instance 10 has a manager component 16, an OSGI framework 17 and a simulation coupling component 18 to which an executable model 19 is coupled via a Java native interface 20. In the components 4, 5 and 6 implemented models are directly integrated in the programming language Java and integrated by the connection of the components 4 ... 6 to the OSGI framework 9 in the data flow. In each simulator instance, the process is controlled by processing the data from the components according to the component dependencies specified in the data flow path. This has the advantage over the alternative possibility of realizing a flow control for the component involved in the simulation in a central component, that the associated control and communication overhead, which the advantages of the OSGI framework with regard to parallelization and distribution severely restricted, is avoided. Instead of a central sequence control, an event-controlled and data-flow-oriented processing is now carried out in simulator instances. Each input of a component is a vector that includes both the state of the input and its value. This is generally formulated in the following equation for an input E _{m of} a component K _n : with state e {θ; l}.

For example, the expression "value" stands for an integer variable, a vector, or an array of variables that are needed for the simulation calculations.The state of the input can be "zero" for "processed" and "1" for " not processed. "Since each component is over can have more than one input, the set of all inputs can be represented in matrix notation, as shown by the following equation:

By way of example, the formula for the component K _n with k inputs K _n Ei ".K _n E _{k is} shown. In the following, the event-driven execution, the sequence of which is based on the data flow stored in a manager component, is explained in more detail. FIGS. 2A-2D show different states of a component network with three components K _{1 (} K ₂ and K ₃ , as well as an example of a data flow based on connecting arrows between outputs which have no state and inputs with the respective marked state The input states are symbolized by circles in Figure 2, where a filled circle corresponds to a "not processed" and an empty circle corresponds to a "processed" state Since the initial values of the components K _{1 (} K ₂ and K ₃ , which are transferred in accordance with the illustrated data flow, are irrelevant to the explanation of the sequence control, these are not shown for the sake of clarity in FIG 2. Event-controlled means, for example, that each output propagates in the framework with the calculation of a new output value listen to the newly provided data and thus recognize the new egg occurred event that the respective upstream component has provided new output data as its own input data. Since this state change must be represented in an implementation by coding in some form, this is simply referred to in the context of the present application as the state of a memory cell assigned to the respective input. 2A shows the initialization of the input states of the components K _{1 (} K ₂ and K ₃₎ , which is carried out before the start of the simulation, whereby all inputs, to which outputs of follower components in the data flow are coupled, are set to the state "not processed". The state after the initialization is shown in Figure 2A Figure 2B shows the state immediately after the initiation of a simulation cycle by a time slice event in which the previously not set input ΚχΕχ was set by placing a time slice a vector, consisting of the respective state and a value, whereby the current system time is transferred here as value.In FIG. 2B, all inputs of the component Κχ are in the state "not processed." Only if the state of all inputs of a component has the value "1 ", that is, the state" not processed ", has assumed new output calculated values for their outputs and provided in the data flow next component. The following formula describes the mapping of a newly calculated value of a component output to the input of the following component:

K _n A _m (i + 1)>-> Κ _{η + 1} Ει ι) where i is a natural number. The formula means that the value of the mth output A _{m of} the nth component K _{n of} the simulation cycle No. i + 1 is mapped to, for example, the 1 th input Εχ of the (n + 1) th component K _{n + 1} in the simulation cycle i. As a result of the processing of the inputs of the component K _± is transferred to the state shown in Figure 2C, in which the inputs of the component K _{2 are} set. Component K ₂ carries out its calculations and changes to the state of the component network shown in FIG. 2D. Now, component K ₃ recalculates the value of its output. Thus, the simulation cycle is terminated and returned to the initial state shown in Figure 2A. Only when a new time slice event occurs can the next simulation cycle be started. the. Thus, as already indicated above, the processing is data flow-oriented in parallelizable processes without the need for a central sequence control. In order to avoid impermissible calculation sequences, the additional boundary condition is observed that a recalculated output value may only be transferred to an input according to the stored data flow if the state of the input is "0", ie "processed". If this is not yet the case, the data transfer must be awaited. The "accumulation" of transfers is a means of synchronizing the components with each other and is unproblematic even with real-time simulations over a certain period of time.However, in a real-time simulation, a new simulation cycle should be initiated by applying a timeslice, even though the component input ΚχΕχ of the time slice is still in the In this way, real-time violations can be reliably detected and reported without the need for central sequencing control for the calculations to be performed in the components, with the reliable detection of "1", ie "unprocessed" In the case of real-time violations, an uncontrolled behavior of the models used for the simulation is advantageously avoided As already mentioned in the introduction, a special feature of the tool described in the present application is the simulation of a technical application In the concurrent and distributed processing of calculations in components, which will now be illustrated by FIG. In contrast to a central sequence control for components to be processed sequentially, in the present application each component represents an application or an independent process, which in the embodiment shown is realized as an OSGI bundle. Several calculations can be performed at the same time in different components, provided that their inputs have all previously been in the state "1" or "not processed". Due to the parallelization, the processing is very efficient. In the part of a data flow shown as an example in FIG. 3, a start begins Part of a simulation cycle with the calculation of a new output value by a component K ₄ . This value is transferred to one input each of three components K ₅ , K ₆ and K ₇ , which can thereby begin simultaneously and in parallel with their calculations. If all the newly calculated output values of the components K ₅ , K ₆ and K _{7 are available} for the corresponding inputs of the component K ₈ , the component K ₈ can carry out its model-based calculations comparatively early. In addition, for example, the component K ₇ as a component for simulation coupling can represent a further simulator instance remotely. In summary, it is possible to process the calculations required to simulate a technical installation in parallel and distributed over several computers, which means a considerable increase in performance. Even if different time periods would elapse for the processing of the computations in the components K ₅ , K ₆ and K ₇ , the overall simulation would nevertheless remain consistent, since a synchronization takes place automatically in the component K ₈ due to the above-described data-flow-oriented processing. without requiring a central flow control would be required.

In summary, a new simulation tool and method is described in which different domain-specific and trade-specific simulators and their models can be coupled with one another. It provides the functionality required to efficiently couple distributed simulators, taking into account real-time compliance. If real-time can not be maintained in the course of the simulation, the tool provides a message about the injury that has occurred. For connecting models or simulators, a wide range of standardized interfaces is available for the tool. Furthermore, simulators and models realized dynamically as so-called bundles can be added and removed during the simulation. There is no need for central sequencing for the components implemented as stand-alone processes, which would severely limit the performance of the tool. For a prototype implementation of the tool, the SIMIT system simulator from Siemens AG was coupled with a simulator instance. The system simulator SIMIT realized the visualization of the model as well as the control algorithms for level control of a tank. The tank itself as well as the pipelines and the sensors were realized by components with integrated models within the simulator instance. For the processing of several test cases different tank models were used, which represented for example an ideal and a leaky tank. In order to evaluate the dynamic model reconfiguration of the co-simulation framework, these tank models were exchanged during the co-simulation coupled with SIMIT. Due to the above-described manager component with its properties, the signal integrity was advantageously retained despite model exchange.

Claims

claims 1. Tool for simulating a technical system with at least one simulator instance (1, 10) comprising a plurality of components (2 ... 8, 15, 16, 18) respectively realized as at least one application, wherein a plurality of components (3 ... 8, 15, 18) have inputs and outputs and are designed for model-based, cyclical calculation of new output values in each simulation cycle as a function of the respective input values, wherein in at least one component (2, 16 ) the data flow to be executed in a simulation cycle is stored, in which for each component output it is determined to which component input or which component inputs in simulation cycles newly calculated values of the output are to be transferred as data, wherein component inputs are each assigned at least one memory cell for status indication, whether the respective input value is already "processed" or "not processed" in a simulation cycle, wherein components (3 ... 8, 15, 18) are designed to perform the calculation of their new output values as a function of their input values in simulation cycles only when the state "not processed" is set for all memory cells which are assigned to their component inputs and, after performing the calculation, setting the state "processed" at all memory cells associated with its component inputs, and wherein in simulation cycles newly calculated output values can only be transferred to component inputs according to the stored data flow and the memory cells allocated to these component inputs can be set to the state "not processed" if the "processed" state of the memory cells allocated to these component inputs was previously set. 2. Tool according to claim 1, characterized in that simulation cycles have a nearly constant cycle time and that a component (2 ... 8, 15, 16, 18) as a so-called Mas- ter is adapted to inform the other components of the system time and to start a simulation cycle by setting a time slice memory cell, which is assigned to an input of a component, to the state "not processed". 3. Tool according to claim 2, characterized in that the master is also designed to indicate a real-time violation as an error if the time slice memory cell was before the start of the simulation cycle in the state "not processed". 4. Tool according to one of the preceding claims, characterized in that for depositing the data flow to be executed, a so-called manager component (2, 16) is provided in which the data flow as a list of mappings of one component output to one or more component inputs is stored, wherein the images additionally identify the component input or the component inputs respectively associated memory cell. 5. Tool according to claim 4, characterized in that the manager component (2, 16) has a state memory for the storage of internal states of other components (3 ... 8, 15, 18). 6. Tool according to one of the preceding claims, characterized in that at least one component (3, 7, 8, 15, 18) for simulation coupling is present, through which a plant simulator (11) or an executable model (12, 19) to the Tool is attachable. 7. Tool according to claim 6, characterized in that a Java native interface (13, 14, 20) for connection to the simulation coupling component (3, 7, 18) is implemented. 8. Tool according to one of the preceding claims, characterized in that at least one component (8, 15) for Remote simulation coupling is available, by means of which a further simulator instance (10; 1) can be connected remotely to the simulation coupling by means of a component (15; 8). 9. Tool according to one of the preceding claims, characterized in that the components (2 ... 8; 15, 16, 18) of the simulator instance (1; 10) realized as OSGI bundles and by an OSGI framework (9; ) are involved. 10. A method for simulating a technical installation with at least one simulator instance (1, 10), which comprises a plurality of components (2 ... 8, 15, 16, 18) respectively realized as at least one application, wherein a plurality of components (3 .. 8, 15, 18) have inputs and outputs and carry out a model-based, cyclical calculation of new output values in each simulation cycle as a function of the respective input values, wherein in at least one component the data flow to be executed in a simulation cycle is stored, in which it is determined for each component output to which component input or which component inputs newly calculated values of the output are transferred as data in simulation cycles, wherein component inputs in each case at least one memory cell is assigned, by which the state is displayed, whether the respective input value is already "processed" or still "not processed" in a simulation cycle, whereby components (3 ... 8, 15, 18) perform the calculation of their new output values as a function of their input values in simulation cycles only if the "unprocessed" state is set for all memory cells assigned to their component inputs, and after processing the calculation, the state "processed" for all their component inputs assigned memory cells, and wherein newly calculated in simulation cycles output values according to the stored data flow to component inputs and the memory components associated with these component inputs are set to the state "not processed", if previously the state "processed" that this grain ponent inputs each assigned memory cells was set. A computer program or computer program product having program code means stored on a computer-readable medium and intended to perform all the steps of the method according to claim 10 when the program is executed on one or more technical equipment simulation units. 12. Digital storage medium with electronically readable control signals, which can interact with one or more computing units for simulation so that a method according to claim 10 is executed.