a framework for flexible simulation of batch plants

A FRAMEWORK FOR FLEXIBLE SIMULATION OF BATCH PLANTS UN ENVIRONNEMENT POUR LA SIMULATION FLEXIBLE DE PROCEDES BATCH

Martin Fritz*, Karlheinz Preuß**, and Sebastian Engell* *Process Control Group, Dept. of Chemical Engineering University of Dortmund, Emil-Figge-Str. 70, D-44221 Dortmund, Germany Tel: +49 (0)231 755 5127, E-Mail: {martin|engell}@ast.chemietechnik.uni-dortmund.de **Laboratoire de Génie Chimique - UMR CNRS 5503 Ecole Nationale Supérieure d'Ingénieurs de Génie Chimique 18 Chemin de la Loge, 31078 Toulouse cedex, France Tel: +33 (0)5 62 25 23 68, E-Mail: [email protected]

Abstract: Recipe driven production is the key technology to master complex batch processes in the process industries. Simulation of recipe driven production can support many tasks in planning and operation of such plants. In this contribution, we present a framework that integrates different simulation strategies (purely discrete, timed discrete, continuous-discrete) in order to provide the best suited one for a specific task and furthermore enables consistent modelling regardless of the simulation strategy used. Résumé: Les recettes de production constituent la technologie clé pour maîtriser la complexité de procédés batch. La simulation d'une recette peut aider lors de la planification et de l'exploitation de ces procédés. Dans cette communication, nous présentons un environnement informatique intégrant différentes stratégies de simulation (discret, a temps discret, continu-discrete). Cet environnement fournit la stratégie la plus appropriée à un cas donné, de plus il permet d'assurer une modélisation cohérente indépendamment de la stratégie utilisée.

1. INTRODUCTION Multipurpose or multiproduct batch plants allow for the economic production of different products in small quantities. To guarantee a safe and economic operation, recipe driven production has been established as the method of choice. It is supported by modern distributed control systems (DCS) and is currently under international standardisation by ISA SP88 [ISA95]. The key idea of recipe driven production is to distinguish between the plant and its equipment on one hand and the operations being performed there, described in a recipe, on the other hand. Recipes are hierarchically composed of basic building blocks, called phases, that can be mapped to elementary operations of the plant equipment which are implemented in the DCS. This separation simplifies the operation of multipurpose plants, where several different products are produced and enables the design of

generic procedures, i. e. ones that can be transferred to other plants. Many tasks in planning and operation of recipe driven production can be supported by simulation: • • • • • •

process design and optimisation, reaction to breakdowns and operator training, plant design and capacity planning, recipe design, scheduling and production planning, plant wide logistics. 2. SIMULATION TECHNIQUES FOR BATCH PROCESSES

These tasks have quite different requirements concerning the level of detail of the simulation model used, and the simulation speed and accuracy. In practice, different simulation methodologies are used for the different tasks. Three simulation methodologies can be distinguished:

Rigorous modelling of the plant and its operations usually leads to a system of differential or differential-algebraic equations. However, the discontinuous nature of batch processes as well as discontinuities in single operations (e. g. phase transitions or a vessel running empty) require switchings in the differential equation system. At a switching point, not only the describing equations of state variables, but even the number of state variables (and equations) as well as their type (differential or algebraic) may change. Hence, the model must contain a discrete part that describes the different states the model may have and the conditions for state transitions. To simulate such systems, traditional simulation techniques for ODE or DAE systems have to be extended to take the discrete aspects into account. The term hybrid (system) simulation usually refers to such simulators. They often yield results with high accuracy, giving insight in what happens in the plant, but put high demands on the level of detail of the model (often requiring information that is not available, e. g. parameters of the reaction mechanisms) and can be quite time-consuming with respect to both the time needed for building the model and for single simulation runs. They are well suited for operator training or process optimisation investigations, but the high computing time demands are in many cases intolerable for other tasks. From the modelling paradigm of discrete-event dynamic systems stems the technique of (timed) discrete-event simulation. It puts less requirements on the model (no differential equations are needed) and gives results more quickly. The accuracy of the simulation results, however, depends highly on the process being investigated and may or may not suffice for the specific task. To produce at least basic quantitative results, traditional approaches of discrete-event simulators being developed for the manufacturing industries have to be extended to calculate mass and energy balances. Information about process times can either be incorporated directly into the model or they can be calculated during the simulation; the latter improves the accuracy but increases the effort in modelling and computation time. While discrete-event simulation is used in the process industries mainly for investigations in logistics and material flow, it can also be used for more detailed process investigations, as shown below.

Purely discrete-event simulation without the notion of time can be helpful in early stages of a planning task e. g. in logistics examinations or operation scheduling. Its main advantage are the little requirements that are put on the model (only structural information is needed), thus yielding simulation results quickly. Quantitative conclusions should only be drawn with care from such simulation experiments. In a conventional approach, these simulation methodologies are realised by stand-alone tools, each requiring its own simulation model. The same process has to be modelled again for each used simulator. This leads to an increased effort for model building and produces redundant and possibly inconsistent data. 3. BASIP: A FRAMEWORK FOR BATCH PROCESS MODELLING AND SIMULATION An alternative approach is to develop an open software framework that integrates different simulators, but has one consistent modelling interface, thus reducing the modelling effort considerably. Such a framework, called BASIP (Batch Simulation Package) is currently developed at the Process Control Group, University of Dortmund (Fig. 1). Its key idea is to encapsulate the main components of a simulation tool, i. e. modelling, simulation, and visualisation, thus making them exchangeable without much effort [FE97]. To reach this goal, the simulation model has to be divided into a generic and a simulator-specific part. The generic, i. e. simulator-independent part consists mainly of structural information. This includes the structure of the recipe, usually described in a graphical notation, and the interconnections of the plant units by means of energy and mass flows. Generic information furthermore includes high-level and easy accessible model parameters like equipment names, vessel geometry, etc. In contrast, the specific model part contains model descriptions following a certain modelling paradigm, e. g. differential equations or finite automata. Keeping the modelling section completely free from specific model information enables the creation of models that can be simulated by simulators based on different modelling paradigms. However, a specific model still has to be constructed in order to simulate the model with a specific simulator. Automating this task, i. e. generating models from generic models using

Fig. 1. The BASIP architecture specific model block libraries can take this burden mostly off the user of the simulation program. A high-level interface between the modelling and the simulation component of BASIP prevents the dependency on a specific representation format for the structure of the generic model. Thus, models from different sources can be incorporated without much effort. BASIP provides comfortable, user-friendly graphical editors for master recipes and plants to generate a conforming textual model representation [FSW95]. Recipes are represented as sequential function charts, as recommended by NAMUR [NAM92] and SP88 [MNC+94]. Plants are modelled in a flow sheet style, additionally the phases and operations of units and equipment can be defined. Both editors support the creation of hierarchical structures, thus keeping the models clear and modular. For the visualisation of simulation results, the architecture enables the incorporation of several, possibly external, components. A well-defined protocol of so-called messages between the simulator and the visualisation component decouples the two parts in order to provide the desired flexibility. An online animation of the simulation, using the graphical editors, could be realised that way, too.

4. THE SIMULATORS OF BASIP By now, three simulators are integrated into BASIP: Two in-house developments, one coming from the continuous domain, the other from the discreteevent side, and an interface to gPROMS, a generalpurpose modelling and simulation tool for hybrid systems. They are described in detail in the remainder of this section. 4.1 The hybrid simulator From the continuous simulation domain, one approach to cope with the discontinuous nature of the system is to partition the simulation time into intervals for which the system structure remains constant and the system input is continuous. The resulting differential equation system can then be solved with a common numerical solver for that interval. The key problem of this approach is, of course, to find a suitable partition which corresponds to the problem of event detection. The majority of events in batch process simulation are state events for which the point of time where the event occurs depends on the values of state variables. The other type of events, time events (if the time an event occurs is known in advance), are induced e. g. by a recipe step with a fixed duration. Time events are easy to handle in a simulation program. For state events, on the other hand, special methods are necessary to determine the exact time when the event occurs [EFS+95].

The whole simulation algorithm is shown in Fig. 2 [Wöl95]. In the first step after initialisation, the state vector, consisting of the state variables and their derivatives, is reconfigured, i. e. the currently active state variables are determined and inserted in the vector. This step is repeated after each successful event detection. Note that in this reconfiguration step the number of state variables in the state vector can change and even discontinuities in the values of state variables are allowed. By this dynamic reconfiguration, the size of the state vector is kept minimal, eliminating unnecessary, i. e. not affected state variables; thus keeping the numerical integration efficient [WFS+96].

time of the event coincides with the end of the interval. Though it is not equivalent in all cases, it usually suffices to test if the value of the threshold that was crossed is still sufficiently close to zero. If this is the case, the event is valid and the model can be switched, i. e. the discrete part of the model is reevaluated. Otherwise, one tries to get an estimation for the time of the first event (there might have occurred more than one event in an interval) that occurred. The end time is set to the estimated time and the interval is integrated again. If the estimation was good enough, the event time will coincide with the end of the interval and the event will be declared valid. Otherwise, this procedure has to be iterated until the end point of the interval is close enough to the event time or the interval width is below a predefined limit. 4.2 The discrete-event simulator Another approach to cope with the hybrid nature of batch processes relies on the discrete-event modeling and simulation paradigm. The main concern of a discrete-event simulator is to determine the order of state changes which a system performs due to its internal dynamics and external inputs, starting from a given initial state. In timed models, the time for which the system remains in each state is also of interest. Thus, a discrete-event simulator only evaluates the system at the points of time where state changes occur.

Fig. 2. Algorithm for hybrid simulation

Next, the integration interval is set using a maximum step size . The integration routine in the next step evaluates the evolution of the system in this interval. It may use internally a smaller, or variable step width. After every integration step, it has to be checked whether an event has occurred. This is the task of the discrete model part. It is realised by a set of state graphs, consisting of states which represent a set of equations valid in this state and transitions between these states. Each transition is related to a threshold function that describes the condition which makes the transition valid. The thresholds of all transitions starting from active steps are checked in the event detection step. If no event has occurred, the system can be integrated over the next interval. Else, the validity of the event is checked, i. e. it is tested, whether the

Fig. 3 shows the simulation algorithm of a conventional discrete-event simulator. Central to the algorithm is the event list, a data structure containing all future events sorted by the time they are expected to occur. The simulation algorithm mainly consists of a loop that takes the first event in the event list, removes it from the list, sets the simulation time to the time of the event, and performs the action associated with this event. This action may involve the generation of new events that are inserted in the event list. Their associated time must not lie before the current simulation time. If the event list is empty or some other termination condition is fulfilled (e. g. a maximum simulation time is reached), the simulation is terminated. It is noteworthy that the notion of event generation, that usually constitutes the main part of a discreteevent simulator, is semantically equivalent to event detection as explained above for hybrid simulation. The difference lies rather in the point of view, whether events are something inherently contained in the system model and have to be "discovered", or whether they are created by the simulation program itself. Thus, both approaches have more in common

than the traditional dichotomy between continuous and discrete-event simulation seems to imply. The term "event-based simulation" could be used as a generic term for both approaches.

However, the calculation of event times is not a trivial task. It requires that the changes of the state variables can be described by algebraic equations or at least by analytically solvable differential equations, e. g. simple integrators. At the start of each recipe step (the activation of a step event in technical terms), its duration is calculated, i. e. the switching time of the following transition. A transition event is inserted into the event list at that time. If no time can be computed at this point, the event is temporarily deferred until the end of the simulation horizon. It may happen that the activation of another event (e. g. the start of another recipe step) enables that calculation. Thus, after each activation of an event, the times of all pending transition events are recalculated. This approach guarantees that no events are missed.

Fig. 3. Algorithm for discrete-event simulation

Another difficulty arises, when equations describing a state variable change independently of (external) events arising from the execution of the recipe. An example is a substance that reaches its boiling point in a heated vessel. In the calculation of the duration of the heating step (or any operation that affects the energy balance) care has to be taken to examine this case. If it happens, a so-called internal event is generated (in this example, at the time the boiling temperature is reached). When this event is activated the evaporation of that substance has to be considered thereafter. 4.3 The gPROMS interface

In the case of batch processes, the simulation is mainly driven by the execution of the recipes. Recipes are, however, in syntax and semantics nearly identical to a special class of Petri nets, so called Predicate/Transition (Pr/T) nets [HGW94]. Steps in the recipes correspond to states of the system. The events the simulator has to generate are mainly the switching times of the recipe transitions (there might be additional internal events to reflect structural changes in the plant, as explained below). Thus, if a discrete-event simulator is able to compute the points of time when recipe transitions occur, combined with an adequate checking of limitations in the plant, no loss of accuracy compared to the hybrid/continuous approach presented in the previous section is expected. The only difference is in a reduced output generation because no information is available about the system state between events. This is usually offset by a considerable acceleration of the simulation with respect to CPU time, not seldom shortening response times by orders of magnitude.

The strength of the BASIP architecture is its flexibility that enables the incorporation of other components. An example is the integration of the simulation tool gPROMS. gPROMS (general PROcess Modeling System) is a multipurpose modeling, simulation, and optimization tool for hybrid systems [PB95]. It supports modular modeling and provides numerical solution routines for systems of differentialalgebraic equations (DAE) as well as for partial differential equations. gPROMS provides its own data visualization tool, gRMS (gPROMS result management system). The optimization component of gPROMS, gOPT, is not used in BASIP so far. The main disadvantage of gPROMS is its purely textual model interface. gPROMS models are formulated in the gPROMS modeling language and stored in files in ASCII format which serve as input for the simulator. Despite of the modular structure of this language, an in-depth knowledge of the language syntax and semantics as well as the the

underlying modeling and simulation principles are necessary to create gPROMS models. In consequence, batch processes cannot easily be modeled in terms of recipes or equipment, instead these have to be translated into the gPROMS language elements. Thus, it is an obvious idea to combine the graphical modeling facilities of BASIP with the numerical power of gPROMS [Pre97]. The idea is to automatically generate gPROMS input files from models created with the BASIP graphical editors. A model converter reads model descriptions and produces a file containing the model in the gPROMS modeling language. Because BASIP models do not contain simulator-specific information, the converter has to add additional information, taken from a library of basic blocks, e. g. equipment and phase types. The results can be displayed using gPROMS’s native gRMS interface or via an adapter that uses gPROMS foreign process interface (FPI). This adapter takes the intermediate results produced by gPROMS and forwards them to the visualisation components of BASIP in the specified format.

5. EXAMPLES 5.1 A simple single-product process The first example to be considered is a simple batch plant at the University of Dortmund that is used for research and teaching purposes. The plant flow sheet model, created with the BASIP plant editor, is shown in Fig. 4. The process consists of several steps. At first, highly concentrated saline solution is discharged from vessel B1 to B3 where it is diluted with water from B2 until a given concentration is reached. Via buffer vessel B4, the contents are released into the evaporator B5. There, the solution is electrically heated and the water is evaporated until the salt concentration in the remaining solution has reached a certain level. The steam is condensed in a cooling coil and the condensation is collected in vessel B6. In the next step, the contents of B5 are discharged into B7 where they are cooled. At the same time, the water in B6 is cooled down. To save raw materials, both substances are pumped back into their respective storage vessels B1 and B2. The

Fig. 4. A simple batch plant

recipe describing this process is omitted due to space constraints. This model can be simulated with all simulators contained in BASIP. A comparison of the results reveals that the results match exactly. The simplifications taken in the discrete-event simulator to not affect the accuracy of the simulation in this case. The only difference in output is the non-linear trajectory of the temperature in vessel B6 which is not reflected in the output of the discrete-event simulator since no event took place while the temperature was rising. Additionally, the discreteevent model does not consider heat losses to the environment, in contrast to the hybrid model. 345

Fig 6. Plant containing cycles

"B6-ksim" "B6-dsim"

340 335

Temperature [K]

330 325 320 315 310 305 300 295 290

0

2000

4000

6000 time [sec]

8000

10000

12000

Fig. 5. Comparison of hybrid and discrete-eventsimulation 5.2 Where discrete-event simulation fails

While the hybrid simulator computes the correct solution without difficulties (cf. Fig. 8), the discreteevent simulator fails to complete the simulation at all. This is due to the fact that the cycle induces an algebraic loop in the discrete-event simulation model that the simulator is not able to detect nor to solve. The problem would not occur, however, if the cycle was split into two sequential steps, e. g. first filling from B1 to B2 and then vice versa.

Fig. 7. Recipe containing cyclic flow 10 "B2-a" "B2-b" "B2-c"

8

6 Mass [kg]

In some cases, however, discrete-event simulation does not produce sufficiently accurate results. One example are processes with recycle streams. A simple example is shown in Fig. 7 and 7. Here, a stationary cycle is produced by filling from B1 to B2 while at the same feeding back a fraction of B2 into B1. B1 is continuously fed with substance A, while a part of the contents of B2 are discharged into B3. The rates are chosen such that the levels in B1 and B2 remain constant. Initially, B1 contains a certain amount of substance B, and B2 the same amount of substance C. The simulation shall continue until the concentration of substance A in vessel B1 falls below a certain value.

4

2

0 0

10

20

30

40 time[sec]

50

60

70

Fig. 8. Masses of A, B, and C in vessel B2

80

6. CONCLUSIONS The hybrid nature of batch processes demands a hybrid simulation approach. However, no single simulation approach is suitable for all possible applications of batch process simulation. Both the continuous and the discrete-event domain provide a sound foundation for a simulator for hybrid systems. Each approach has its specific advantages and limitations. The architecture of the BASIP framework presented in this contribution allows to integrate different simulation approaches within a single modelling environment thus reducing the modelling efforts considerably. The object-oriented approach used in designing the framework makes it quite easy to add further simulators, model sources (e. g. to couple the system directly to a recipe management system) and visualisation components. Further work will include an enhancement of the customisation possibilities of model editors and simulators and approaches to a distributed simulation of batch processes, using the simulator suited best for a specific subprocess. That will improve the usefulness of different simulation strategies even more. ACKNOWLEDGEMENT This research reported here is supported by the Volkswagen-Stiftung which is very gratefully acknowledged. REFERENCES [EFS+95] S. ENGELL, M. FRITZ, C. SCHULZ, and K. WÖLLHAF. "Hybrid Simulation of Flexible Batch Plants". In: Preprints IFAC Symposium DYCORD+ ´95, Helsingør, Denmark, 123-128, 1995. [FE97] M. FRITZ and S. ENGELL. "An Open Software Architecture for Batch Process Simulation". In: Proc. PSE ‘97/ESCAPE-7, Trondheim, Norway, Supplement to Comp. Chem. Eng. 21, 769-773, 1997. [FSW95] M. FRITZ, C. SCHULZ, and K. WÖLLHAF. "A General Graphic Editor for Complex Simulation Models". In: Proc. EUROSIM ‘95, Vienna, Austria, 141-146, 1995.

[HGW94] H.-M. HANISCH, H. GENRICH, and K. WÖLLHAF. "Verification of RecipeBased Control Procedures by Means of Predicate/Transition Nets". In: Application and Theory of Petri Nets. Lecture Notes in Computer Science, Vol. 815, 278-297, Springer, 1994. [ISA95] ISA. ISA S88.01 Batch Control, Part 1: Models and Terminology, 1995. [MNC+94] T. MÜLLER-HEINZERLING, N. HAXTHAUSEN, L. CRAIG, and D. EMERSON. Recipe Visualization - Some ways to look at SP88 recipes, technical report, 1994. [NAM92] NAMUR AK 2.3 Funktionen der Betriebsund Produktionsleitebene. NAMUR-Empfehlung 33: Anforderungen an Systeme zur Rezeptfahrweise (Requirements to be met by systems for recipe based operation), 1992. [PB95] C. C. PANTELIDES and H. I. BRITT. "Multipurpose process modelling environments". In: Proc. Conf. On Foundations of Computer-Aided Process Design ’94, 128-141, CACHE Publications, 1995. [Pre97] K. PREUSS. Modellierung und Simulation von Batchprozessen mit gPROMS (Modelling and simulation of batch processes with gPROMS). Dipl.-Ing. Thesis (in German), University of Dortmund, Dept. of Chemical Engineering, 1997. [Wöl95] K. WÖLLHAF. Objektorientierte Modellierung und Simulation verfahrenstechnischer Mehrproduktanlagen (Objectoriented modelling and simulation of chemical multipurpose batch plants). Dr.Ing. Thesis (in German), University of Dortmund, Dept. of Chemical Engineering, 1995. [WFS+96] K. WÖLLHAF, M. FRITZ, C. SCHULZ, and S. ENGELL. "BASIP - Batch Process Simulation With Dynamically Reconfigured Process Dynamics". In: Proc. ESCAPE-6, Rhodes, Greece, Supplement to Comp. Chem. Eng., 20(972), 1281-1286, 1996.