Accepted for presentation at: PSE ’97/ESCAPE-7, 26-29 May 1997, Trondheim, Norway
An Open Software Architecture for Batch Process Simulation Martin Fritz and Sebastian Engell Process Control Group, Dept. of Chemical Engineering, University of Dortmund, D-44221 Dortmund, Germany email: fmartin|
[email protected] Abstract - Simulation of recipe driven batch processes is a complex demanding task. It can be performed either with general purpose simulators, causing a high modelling effort, or with specific tools which often lack flexibility. Neither of these approaches is appropriate in all cases. In this contribution, we outline a software architecture for batch process simulation which is flexible enough to be adapted to meet the particular requirements of the simulation problem at hand. It consists mainly of the elements model creation, output clients, simulator, and user interface. All these components are exchangeable to offer the software solution which is best suited for the specific problem. The software concepts are presented in terms of design patterns.
Recipe driven batch processes can be simulated using either continuous or discrete-event simulation tools or a few Simulation is a well-established method in almost all sci- hybrid simulators. Few simulation programs especially entific and engineering disciplines. Therefore, a large designed for batch processes exist (Clark and Joglekar, number of different simulation systems exists. Most of 1992), (Engell et al., 1995). None of them is suited for all them fall roughly in one of the two following categories: tasks listed above. General-purpose tools that are designed for a wide In this contribution, the architecture of a simulation sysarea of applications. They usually have an abstrac- tem is presented which is designed for a specific applicat modelling language or graphical model building tion (the simulation of recipe driven multipurpose batch interface whose language and notation is quite dif- plants), but has open interfaces with respect to all its comferent from the notions of a specific application do- ponents, thus combining the advantages of both approachmain. This causes a considerable effort to build a es. It is motivated by experiences made during the remodel, especially for users which are not familiar design of the B A S I P system, an environment for modwith the tool, but ensures maximal flexibility. To elling and simulation of the production process in multithis category belong e. g. SpeedUp, gPROMS (Pan- purpose batch plants (Engell et al., 1995). The software telides and Britt, 1995), or DIVA (Marquardt et al., architecture presented here is applicable to other applica1987). tion domains as well. INTRODUCTION
Programs for specific application domains. These offer special model building and presentation features similar to the concepts the practitioner is used to, but frequently lack flexibility when it comes to adding more detail to the model, incorporating models from other sources or modifying the output format.
Key structural elements are presented in terms of Design Patterns following (Gamma et al., 1994), a promising approach to extend reusability of object-oriented software systems. By design patterns one tries to capture repeating design structures in object-oriented software designs in an informal way. They consist of an expressive name, a graphical and textual description of their structure and Recipe driven batch processes are a challenging field for functionality, examples of known uses, and code examples in different object-oriented programming languages. simulation for several reasons: They are classified by their scope into class or object pat They consist of combined continuous and discrete terns and by their purpose into creational, structural, and dynamics and constitute highly structure-variable, behavioural patterns. switching systems. As in (Gamma et al., 1994), graphical descriptions are giv There are several different application areas for sim- en in the Object Modeling Technique (OMT) notation aculation which require different levels of detail in cording to (Rumbaugh et al., 1993). Code fragments for modeling, e. g. recipe verification, capacity plan- illustration are given in C++, the language that is also used ning or process optimization. for the implementation. Research supported by the Volkswagen-Stiftung, which is gratefully acknowledged.
1
User Interface
Simulation Mgr Model BuilderMgr
Output ClientMgr Simulator
PlantModel Builder
PPModel Builder
Output Client
Figure 1: The overall structure of the system
THE SYSTEM ARCHITECTURE Simulation systems can be functionally decomposed into three main components: 1. The model source, in modern systems often connected with a graphical model editor. The main purpose of this component is to generate a model description that is used by the simulator. Often, this model description is stored in an intermediate form, e. g. as an ASCII file in a specific modelling language.
To verify long-term production schedules, however, the time for a continuous simulation run usually becomes unreasonably long. Here, a fast discreteevent simulation will be more adaequate. Changing the simulator should have little or no effect on the model or the format of the generated output.
Diversity in the visualization of the simulation output has for long been a feature of commercially successful simulation tools. Adding another output format or connecting to an external visualization tool should not require major changes in the simulator.
2. The simulator that processes the simulation mod- In the following, design structures are presented to achieve el in a specific manner, using a specific continuous, this flexibility. discrete or hybrid simulation technique. Fig. 1 shows the object model of the whole system in OMT notation. The core element is the simulation manag3. The output component that prepares the results gen- er (SimulationMgr) which creates and maintains the erated by the simulator for easy investigation by the other components. The use of manager objects is conuser. Frequently, the simulation output is written to troversely discussed in the object oriented design literadisk in a specific format so it can be accessed by oth- ture. Some authors argue that the appearance of maner tools which are decoupled from the actual simu- agers in program designs is an evidence for too little “oblator, e. g. MATLAB routines. ject think” (Coad and Nicola, 1993) and reveals thinking in traditional functional structures. In this case, howAdditionaly, modern simulation systems have a graphical ever, the task of the manager here is not to do the work user interface to control the simulation session, i. e. selectof its “employees” but to enable communication between ing the model and the output formats, setting simulation them without creating too many interdependencies. Thus, parameters and starting/stopping the simulation. SimulationMgr can be regarded as an instance of the In an open and flexible simulation system, these compomediator pattern. A mediator is a structure to encapsulate nents should be decoupled as far as possible. In an ideal object interaction, thus promoting loose coupling. design, it would be possible to exchange any of these comThe classes typeset in italic in Fig. 1 are abstract classes, ponents without affecting the others. i. e. they cannot be instantiated. Instead, concrete classes Flexibility is desirable in many respects: have to be derived from them. These provide implemen Building simulation models and acquiring model tations for specific simulators, output clients, etc. data is usually by far the most difficult and expen- While the user should know about the existing classes to sive step in simulation. Acceptance of new simula- be able to select the appropriate ones for a simulation run, tion tools is increased drastically if existing model- the rest of the program should not use knowledge about s can be reused. A flexible model interface can ac- them, because otherwise it gets difficult to change them. An elegant solution to this problem is provided by the complish this task. abstract factory pattern. A factory class encapsulates all Different problems require different simulation knowledge about derived subclasses from a given abstracmethodologies. For process optimization, an in- t class. The factory can create instances of all classes it depth simulation of the plant behaviour is required, knows about. Thus, new derived classes only have to regwhich can only be achieved with a continuous or ister themselves on the the appropriate factory to be usable hybrid simulator solving DAE systems. by the entire application. Putting those derived classes in a
PlantModelBuilder
PlantModel
GetEquipmentIterator();
Init();
GetPhaseIterator();
BuildEquipment(tID; objID);
GetParameter( objectId, ParamName);
BuildPhase(tID, objID);
Equipment Init();
itsPlantMB;
BaSiPPlantModelBuilder
ContinuousPlantModel
GetEquipmentIterator();
BuildEquipment(tID; objID);
GetPhaseIterator();
BuildPhase(tID, objID);
GetParameter( objectId, ParamName);
itsEquipment;
itsId; MIIterator eqIter(itsPlantMB-> GetEquipmentIterator()); while (eqIter()) BuildEquipment(eqIter.key().tID(), eqIter.key().ObjID()); MIIterator phaseIter(itsPlantMB-> GetPhaseIterator()); while (phaseIter()) BuildPhase(phaseIter.key().tID(), phaseIter.key().ObjID());
theBuilder;
Reactor Init(); itsVolume;
itsPhases;
itsMaxPressure; Equipment *anEq = itsEqFactory. Build(typeId, objectId); anEq->Init(); itsEquipment.insert(anEq);
itsVolume = theBuilder-> GetParameter(itsId, "VOLUME"); itsMaxPressure = theBuilder-> GetParameter(itsId, "MAX_PRESSURE");
Figure 2: Objects involved in model building
dynamic link library (or shared library on UNIX platform- PlantModel receives its information from Plants) enables the user to add new classes without changing or ModelBuilder, an abstraction of the specific model even recompiling the rest of the application. source. PlantModelBuilder provides a narrow interface to access the model data. It reduces the model to a collection of instances of the class ModelItem which MODEL BUILDERS consists of a type id, an object id, a name, and a set of Decoupling the model source and the simulator is the most Parameters. A Parameter has a name, a value and a complicated issue in building a flexible system. The sim- unit. The value can be of (almost) arbitrary type, including ulation model depends both on the model source (i. e. the ModelItem, thus enabling hierarchical structures. Contextual representation of the model) and the simulator. To crete subclasses of PlantModelBuilder now impleprovide only a single simulation model for all simulators ment this interface by parsing files in B A S I P format or is a possible approach, but it leads to inflexibility and most other possible formats. likely to an enormous overhead of semantically meaning- PlantModelBuilder gives access to its model inforless information in the model. Therefore, each simula- mation by means of iterators, another common pattern. tor should have its own model. This poses the problem Iterators provide access to every element of a container of combinatorical explosion when every possible model class without giving information about the container itself. Thus, the container may be a internal list built during parssource is combined with every possible simulator. ing or a remote database. A common approach to solve this problem is the bridge pattern which serves to separate an interface from its im- From the abstract structures of ModelItems and their plementation. In this case, this pattern is combined with Parameters, ContinuousPlantModel can now another pattern, the builder which separates the construc- build a model suitable for continuous simulation. It creates therefore instances of subclasses of Equipment, tion of the model from its function. e. g. Reactor (using the factory pattern again) and sets Fig. 2 shows the object model for the model building their necessary parameters. components in the case of the plant model. Fig. 3 describes the process to build and to initialize a model. At Other simulators may trigger the construction of simplifirst, the simulation manager creates the model builder fied models, e. g. by using only one type of equipment and and the simulator. When the simulation is started, the ignoring most of the physical parameters. model builder is initialized, which consists e. g. of parsing the model description files. Then the simulator is initialized which in turn creates its plant model and calls its Init() method. Though PlantModel is an abstract class, it provides an implementation for Init(), which subsequently calls other methods of PlantModel like BuildEquipment() that do the actual work. They have to be implemented by derived classes such as ContinuousPlantModel. Init() can be viewed as an example for a template method, a common pattern in object-oriented designs.
OUTPUT CLIENTS Decoupling the output component from the rest of the program is less problematic than for the model builders, as it communicates with the system only unidirectionally and often by a file or database interface (provided that no user interaction takes place during the simulation run). The problem is, however, to ensure that the simulator generates the information necessary for a specific visualization. This can be solved by creating “intelligent” output clients
the SimManager
a Simulator
a ModelBuilder
a Model
CreateSimulator()
CreateModelBuilder()
Start()
Init() Init()
CreateModel() GetPhaseIterator() GetEquipmentIterator()
Init()
Delete()
Start()
GetStartConditions()
Figure 3: The model initialization process
which can filter the necessary information out of the complete simulation output. In order to accomplish this design, a protocol of messages has to be established. These messages must be generated by all simulators and must be understood by all output clients as far as they are relevant. Messages can be divided into different categories:
possible approach are output clients which send their messages after filtering via inter process communication to a visualization server. So far, an online animation of recipe processing using the graphical recipe editor of B A S I P has been implemented. For initialization, some output clients have to know about the simulation model. Consider for example an output client that displays state variables like temperature or presTime messages just report the current simulation time to sure of the vessels in the plant. For large plants, it would be avoid repeating this information in other messages, a useful feature if only those vessels are displayed which have been selected before. Thus, the output client has to event messages are issued whenever an event in the sim- know about all vessels before the simulation starts. Output ulation occurs, e. g. a transition in the recipe fires, clients therefore need to have access to the model builders to construct their own private simple model. state messages describe the state of the simulation at the Output clients are owned by an instance of class current point of time, e. g. the temperature of a vesOutputClientMgr whose main purpose is to distribute sel, the messages received by the simulation to the active error messages are issued when an error occured either clients. This structure is captured by the observer pattern. in the execution of the model or in the simulator’s SIMULATORS program code. In both cases, on must distinguish between fatal errors that cause the simulation run to The need for different simulation engines serving differenabort and those that allow to continue the simulation t purposes was already discussed above. At present, three after issuing a warning. different simulators are incorporated or will be incorporatInfo messages give information about internal simulator ed in the near future: or other components’ actions and are merely for de1. A discrete event simulator, extended by compobug purposes. nents for tracking of mass and energy (Drumann and Kr¨amer, 1996); A simple output client like a logfile would now just call the Print method of each received message. More sophisticated output clients have to filter the incoming messages and extract the information of the relevant ones. For this purpose, messages have a category tag for unique identification. While most output clients rather do text processing with the simulation output to produce file formats readable by other tools, online visualization requires more effort. A
2. A hybrid (combined discrete-continuous) simulator, using a dynamic reconfiguration of the simulation model to efficiently handle highly structure-variable systems (W¨ollhaf et al., 1996); 3. An interface to gPROMS, a general-purpose simulation tool for the simulation of hybrid systems (Winkel et al., 1995).
Because the first two simulators are own developments, it poses no particular problems to integrate them into the system architecture. The integration of third-party tools like gPROMS, however, requires an interface to the simulation process to be able to generate the messages needed for output generation. The foreign process interface of gPROMS enables the design of such an interface. Not every output client can interact with every simulator. A stochastic analysis module for instance makes little sense for a simulator without stochastic components. To prevent such meaningless combinations, output clients should know whether the selected simulator can provide the data they need and otherwise disable themselves. To maintain flexibility, the output clients should not know about the explicit type of the simulator but instead query its capabilites via a set of methods defined in the interface of the abstract base class Simulator, e. g. CanDoStochasticSimulation(). THE USER INTERFACE
The output clients that are responsible for displaying, animating, and recording the simulation outputs. They have to collaborate with the model builders and the simulator by special mechanisms. The user interface which allows the user to control the simulation run. Several design patterns (those mentioned above are by far not exhaustive) could be identified in this architecture. Their use enables a truly flexible software design. The applicability of the presented architecture was proven by the existing implementation of B A S I P. However, only adding more, especially components from other sources can truly prove the quality of the design. REFERENCES Clark, S. M. and Joglekar, G. S. (1992). Simulation software for batch process engineering. Proc. of the NATO Advanced Study Institute, Antalya, Turkey.
Coad, P. and Nicola, J. (1993). Object-Oriented ProgramNo state-of-the-art software product can come without a ming. Prentice–Hall, Englewood Cliffs, NJ. graphical user interface adapted to the look-and-feel of the particular operating system. However, the need for flexi- Drumann, H. and Kr¨amer, I. (1996). Diskrete Simulation und Visualisierung von verfahrenstechnischen bility applies also to this part of the system. It may be necMehrproduktanlagen (Discrete simulation and visuessary for instance to switch off the user interface and run alization of multiproduct batch plants). Master’s thethe simulator in “batch” mode, triggered by another applisis, University of Dortmund. cation, e. g. a scheduling tool that needs to verify its generated schedules by simulation. In this case, one should be Engell, S., Fritz, M., Schulz, C., and W¨ollhaf, K. (1995). able to start the programm from the command line, givHybrid simulation of flexible batch plants. Proc. Iing the necessary options (which simulator, which output FAC Symposium DYCORD+ ’95, 123–128, Helsinclients, etc.) in a configuration file. gør, Denmark. The interface does not know about the types and parameters which it offers for configuration. As a consequence, Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994). Design Patterns: Elements of Reusable all components must provide their own dialogs for paramObject–Oriented Software. Addison–Wesley, Readeter settings which then are called by the interface in reing, MA. sponse to the respective user action. CONCLUSION
Marquardt, W., Holl, P., Butz, D., and Gilles, E. D. (1987). DIVA – a flow-sheet oriented dynamic process simulator. Chem. Eng. Technol., 10:164–173.
A simulation tool which is able to meet the different demands in batch process simulation must have an open and Pantelides, C. C. and Britt, H. I. (1995). Multipurpose proflexible architecture. We have identified five main compocess modelling environments. Proc. Conf. on Founnents of this architecture: dations of Computer-Aided Process Design ’94, 128– 141. CACHE Publications. The simulation manager which coordinates all activities of the other components. He can be regarded Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1993). Object-Oriented Modeling and as an instance of the mediator pattern. Design. Prentice-Hall, Englewood Cliffs, NJ.
The model building component which is responsi- Winkel, M. L., Zullo, L. C., Verheijen, P. J. T., and Panble for the creation of the simulation model using an telides, C. C. (1995). Modelling and simulation of the abstract interface independent from a specific modoperation of an industrial batch plant using gPROMel description format. S. Comp. Chem. Engng. (ESCAPE-5), 19:571–576. The simulator which performs the actual simulation W¨ollhaf, K., Fritz, M., Schulz, C., and Engell, S. (1996). of the specific model. Here, different simulation BaSiP – Batch Process Simulation With Dynamicaltechniques or even third-party simulators are conly Reconfigured Process Dynamics. Comp. Chem. ceivable. Engng. (ESCAPE-6), 20(972):1281–1286.
