Tài liệu Object-Oriented Modeling pptx

© 2001 by CRC Press LLC6 Object-Oriented Modeling and Simulation of Multipurpose Batch Plants 6.1 IntroductionModeling and Simulation of Batch Plants 6.2 Multipurpose Batch Plants 6.3 Re

© 2001 by CRC Press LLC

6

Object-Oriented Modeling and Simulation

of Multipurpose

Batch Plants

6.1 IntroductionModeling and Simulation of Batch Plants

6.2 Multipurpose Batch Plants

6.3 Recipe-Driven Production

6.4 Requirements for Simulation Tools forBatch Processes

6.5 BASIP: The System Architecture

6.6 Graphical Model Building

6.7 Hybrid Simulation

6.8 Discrete-Event Simulation

6.9 Integrating General Simulation Tools

6.10 Handling of Resource Conflicts

6.11 Visualization

6.12 Example 1: A Simple Batch Process

6.13 Example 2: Combining Scheduling and Simulation

Advanced automation techniques are needed to fully exploit the capabilities and to guarantee the safeoperation of these versatile and complex plants Recipe-driven production, now realized by many moderndistributed control systems (DCS), is the key technology to achieve these goals

While for the actual operation of the plant a high degree of automation can be realized by usingcommercially available technologies, many high-level tasks, such as scheduling and capacity planning,still lack support by appropriate computer tools.

Modeling and Simulation of Batch Plants

Simulation has been established as a means to provide better insight into complex processes As thecomplexity of batch process makes them hardly tractable for rigorous mathematical analysis, simu-lation is the basis for decision support systems for high-level tasks in batch plant operation andplanning

While simulation has been applied to certain aspects of batch processes in industry in the last decade,

no single simulation program, not even a common approach, has been established as a standard or de facto standard so far This is mainly due to the fact that no single simulation program can address thewide range of possible applications of simulation in batch production Specialized solutions for specificareas exist, but these are not suitable for other problem domains

A software package that tries to overcome these shortages is presented in the remainder of this contribution.Its main idea is not to develop “universal” simulator which solves all problems, but to provide a flexibleframework where the components best suited for a specific application can be combined without much effort.This framework includes a graphical model interface for the construction of simulation models in arepresentation the practitioner is used to, not requiring in-depth simulation knowledge

Several different simulation strategies are provided, giving the user the freedom to choose the onewhich is best suited for his problem

Visualization of the simulation results is another important aspect of a simulation package Theflexibility of the architecture makes it possible to include advanced data analysis and visualization tools.Two examples (of Sections 6.2 and 6.3) in which simulation is used for different tasks show theapplicability of the approach The appendix gives a short introduction into the concepts and notations

of object-oriented design that are used throughout this contribution

6.2 Multipurpose Batch Plants

From a system analysis point of view, multipurpose batch plants are one of the most complex and mostdifficult classes of production systems Figure 6.1 indicates the position of multipurpose batch plants inthe taxonomy of production systems

Having properties of both the process industry and the manufacturing industry, batch processes exhibitthe following characteristics that do not occur in typical manufacturing processes:

• The substances involved in the production process mostly have a fluid character No entities ofproduced goods can be identified trivially; transport phenomena are a crucial factor in processoperation

• Often cyclic material flow occurs, creating interdependencies that cannot be resolved easily

• Coupled production is standard By-products must be processed further, or at least be disposed

of, in a defined way This increases the complexity of production planning

In contrast to classical continuous production, batch processes where the process stages are performedstep by step do not have a steady state; instead, the operation conditions change frequently In conse-quence, there are more degrees of freedom for control, thus again increasing the complexity

In a single or multi-product plant, the number and the order of the process stages by which allproducts are produced is the same, potentially offering several parallel equivalent lines In the (still rare)case of a multipurpose plant, in contrast there are hardly any constraints for the path a product cantake through the plant, including cycles in the processing sequence In a multiproduct plant, all batchespass through the same stages in the same order The products are usually quite similar, e.g., paints of

different colors In a multipurpose plant, a batch can pass through the process stages of the plant in anarbitrary order.

For multiproduct and multipurpose plants, production planning has to deal with the question of what toproduce when, and, in which quantities on which piece of equipment To achieve an optimal solution, thesequestions have to be addressed simultaneously In practice however, a sequential approach is mostly used

An example of a multiproduct batch plant is given in Figure 6.2 Here, a product has to take threeprocess stages, taking place in the equipment labeled MWx, Rx.y, and Vx, respectively There are threeidentical lines where each line is split again in the middle stage The plant equipment is stronglyinterconnected, so resource allocation decisions have to be taken in advance

6.3 Recipe-Driven Production

The key idea of recipe-driven production is to describe the chemical and physical operations for theproduction of a specific product in a plant-independent master recipe, and to derive the actual controlsequences for the execution of the production (automatically or manually) from it This technique enables

a safe and efficient usage of the plant and the production of different batches in a reproducible quality,

as well as the development of well-defined instructions on how to produce a product on possibly differentpieces of equipment

By now, all major vendors of distributed control systems have extended or developed products tosupport recipe-driven production Nevertheless, especially in older plants, a purely manual operation ofthe plant is still a common case, and often a fraction of the operations, especially solids processing, must

be performed manually

Quite early, steps to standardize recipe-driven production were taken A leading role was played byNAMUR, a German industrial consortium for process automation, which in 1992 released its recommenda-tion NE 33, “Requirements for Batch Control Systems.” [NAMUR-Arbeitskreis, 1992] Partially based on thiswork, the ISA Technical Committee SP88, in cooperation with IEC and ISO groups, has been working on

Production technology

Manufacturing industries

Batch processes

Continuous processes

Process industries

Single-product plants

Multi-product plants

Multi-purpose plants

an international standard for batch process control, whose first part, S88.01, “Models and Terminology” wasreleased in 1995 [ISA, 1994] The second part, “Data Structures and Guidelines” has not been published yet.The intent of these standards is to define reference models and notions to improve the planning andoperation of batch plants, and to facilitate communication between all participants with their differentbackgrounds from chemistry, process development, and control engineering.

Central to S88 is the so-called control activity or “cactus” model (see Figure 6.3) It structures theactivities involved in batch control into plant management functions (upper level) and batch processing(lower levels) The S88 model differentiates between the equipment on which the process is performed,the process description captured in recipes, and the process itself

The equipment needed for batch production is modeled by functional objects and is structuredhierarchically as follows [Haxthausen, 1995]

• On the lowest level is the control module It consists of a device together with the controls needed

to perform its functions A typical example is a valve Its minimal control equipment consists of

a handle to open and close it manually

• Control modules can be composed into equipment modules which are defined lay being able toperform a processing task They need a coordinating logic, called phases, to coordinate the processactions In terms of NE 33, these are called technical functions

• The level of a unit corresponds to a batch There is never more than one batch in a unit, and aunit usually processes the whole batch (though a batch may be split into several units) A unit can

execute phases, operations, and unit procedures (which in turn form a hierarchy), and is sible for the coordination of these steps

respon-• The process cell, finally, contains all the equipment needed to produce a batch It can define anumber of procedures

To produce more than one product on the same plant, recipes have to be introduced to specify howeach product is produced The recipe tells the process cell which of its procedures must be executed inwhich order This mapping may be performed on different levels, thus, the recipe can refer to procedures,unit procedures, operations, or phases This requires that the recipe has a hierarchical structure itself(see Figure 6.4)

Recipes are also categorized by their degree of abstraction A control recipe describes the execution of

an individual batch It is derived from a master recipe, which may be used on different equipment of theprocess cell, or even on different process cells, as long as they fulfill the process requirements Masterrecipes may be derived from more abstract site or general recipes which are defined in pure processingterms with no relation to specific equipment

6.4 Requirements for Simulation Tools for Batch Processes

There are many possible applications of simulation to batch processes, as mentioned in the introduction.The following listing is not comprehensive, but shows the wide range of potential applications:

• Operator training A training simulator replaces the real plant in a real process control ment

environ-• Case studies The investigation of hazardous or otherwise unusual or unwanted situations is onlypossible by simulation

• Plant planning Exploring the necessary capacities of future or the bottlenecks of existing plants

• Recipe design Testing and validating of newly developed or modified recipes before applying them

to the plant

• Scheduling and production planning Investigating possible resource allocation conflicts or locks when executing several recipes sequentially or in parallel

dead-• Plant-wide logistics Examining the material flow through the whole production, from purchasing

to distribution

Hence, there are different requirements on the simulation and the model used:

• The necessary level of detail of the model depends on the accuracy needed for the given application.While a training simulator requires a rigorous evaluation of the chemical and physical properties

of the process, for logistics it may even be sufficient to model a reactor as a device that is justeither idle or busy

• The performance of a simulation run may be crucial for the application as well While real-timesimulation, as needed for training simulators, is usually not too hard to achieve because the processdynamics usually are rather slow, most applications demand that the simulation is running muchfaster than real time For applications in production planning, response times of seconds, or a fewminutes, can be demanded This may not be achievable with detailed models and continuoussimulation approaches

Thus, performance and accuracy are normally opposing goals, which means that in practice, thecompromise which is the best fit for the specific problem has to be chosen

There are more requirements that apply to all applications:

• User support A simulation tool should be easy to use and not require expert knowledge insimulation techniques or operating system peculiarities Therefore, a tool should have a state-of-the-art graphical user interface enabling graphical model building, configuration, and execution

of simulation runs, and monitoring and analysis of simulation results within a single environment

To achieve widespread use, it must be available on popular hardware/operating system platforms

in the PC and workstation market

• Conformance with existing standards Model building should be possible using the same conceptsand techniques as for real applications That is, the plant should be specified in a flow sheet style,while the creation of a production schedule is done in terms defined in ISA S88, i.e., master andcontrol recipes, operations, phases, etc No translation of notions of the real world into those ofthe simulation system should be necessary

• Integration into existing information systems structures A successfully used simulation systemcannot be an isolated solution, but has to be incorporated into the enterprise’s information systems.This may imply that the simulation makes use of data collected by a process monitoring system, orexports its results directly into a management support system for comparison with actual plant data

No single tool can fulfill all of these requirements What is needed instead is a software architecturethat can be configured and customized to provide the best solution to the given problem in the givenenvironment The most important property of such a framework is flexibility; it must be able to adaptitself to possible applications under certain constraints that are not known beforehand

6.5 BASIP: The System Architecture

A prototype of such a flexible, integrated modeling and simulation environment has been developed atthe Process Control Group at the University of Dortmund Germany [Wöllhaf, 1995] and [Fritz andEngell, 1997] The resulting software system is called BASIP (Batch Simulation Package) Its structure isshown in Figure 6.5 To achieve flexibility, the software package is divided into three largely independentcomponents for model building, simulation, and visualization They can be managed and configured via

a single user interface

The architecture reflects the object-oriented principles which were used for its design (as well as for itsimplementation) Interconnections between the single components are minimized and realized by abstractinterfaces Thus, the components are encapsulated and can be exchanged by alternative implementations

FIGURE 6.5 The B A S I P system architecture.

that only have to fulfill the minimum requirements which the other components put on them Thisfacilitates the integration into other software systems and the adaptation of the system to a particularapplication [Fritz and Engell, 1997].

On the modeling side, the package contains several graphical editors to easily create simulation models(Cf Section 6) The simulation engine, however, which uses the models generated with these editors,does not rely on the particular database structure or file format used to store these models Instead, itaccesses the model via a model translation component that transforms the model files into high-levelabstractions If model data from other sources must be used, e.g., to directly simulate recipes stored inthe recipe management system of a DCS, only an alternative implementation of the model translator has

to be generated; the simulator remains unchanged

Analogously, the system does not put any restrictions on the way the simulation results are displayed

to the user There is only a specification of what sort of data is available in what format A visualizationcomponent (or outputClient in BASIP’s terminology) then can be added that processes this data in itsown manner Most of the outputClients predefined in the system do not perform a lot of processingthemselves, but rather act as bridges to external data visualization or analysis software

Even the backbone of the system, the simulator, is exchangeable Thus, different simulation ologies or different numerical solution strategies can be applied, either to increase the accuracy of thesimulation results, or to choose the simulator with the best performance for the given application

method-6.6 Graphical Model Building

A BASIP model is structured as shown in Figure 6.6 What is actually simulated is a collection of controlrecipes A control recipe contains a reference to the corresponding master recipe and to the plant onwhich production is executed or simulated Furthermore, it contains the mapping of the phases of themaster recipe to equipment phases of the plant Thus, the mapping is realized on the lowest level offered

by the S88 model

FIGURE 6.6 The B A S I P model structure.

Control recipes do not contain information about the time at which they are executed As a result, theycan be used to produce more than one batch This is a slight deviation from the S88 notion, in which acontrol recipe is linked to exactly one batch Here, information about starting times is transferred to a separatebatch object which also contains information about the products produced by this batch and the feed materialsneeded Batches can be put together into orders to reflect related production runs, e.g., of the same product

or for the saline customer On the highest level, a production plan contains all orders for a given period oftime It can be composed of other production plans to structure them with respect to time or space.For all model components, graphical model editors are provided Of particular interest are the editorsfor master recipes and plants, as they offer true graphical modeling instead of text-oriented dialogwindows While plants are represented in a flow sheet style, recipes are modeled as sequential functioncharts [IEC, 1988]as recommended by both NAMUR and ISA

Both representation forms can be abstracted to (directed) graphs with different types of nodes andedges A graphical editor to manipulate graph structures must have some advanced features compared tostandard drawing programs because they must preserve the semantic relations between nodes and edges.The editors for plant and master recipes are based on a common foundation: a framework for grapheditors called HUGE (hierarchical universal graph editor) [Fritz, Schultz, and Wöllhaf, 1995] It providesthe following features for any application derived from it

• Creating, deleting, connecting, and moving of nodes and edges

• Grouping of nodes and edges to superblocks (subgraphs), thus enabling the creation of hierarchicalstructures

• Unrestricted undo and redo of user operations

• A clipboard for cut, copy, and paste

• Persistence mechanisms to store and retrieve models to/from disk

A sequential function chart that is used for modeling master recipes consists of a sequence of steps andtransitions Every step has a corresponding action that refers to certain type of predefined recipe phasesthat can be parameterized For syntactical reasons, the null action (no operation) is also admitted.The following two types of branches are used for the structuring of recipes

• Alternative branches (“or”-branches) force the flow of control to follow exactly one of the branches,depending on the transitions at the beginning of the branch (see below)

• Parallel branches (“and”-branches) define a parallel execution of all branches between two chronization marks (parallel lines)

syn-Each step is followed by a transition containing a condition that determines when the transitionswitches If the condition is true, the preceding steps are deactivated and the subsequent ones are activated

In analogy to the switching rules of Petri nets, a transition can only switch if all of its preceding stepsare active The conditions in transitions can refer to time or to physical quantities of the plant, e.g., thelevel or the temperature of a vessel

Figure 6.7 shows the realization of this structure in BASIP’s master recipe editor REZEDIT The restrictivesyntax of a sequential function chart allows for an automatic syntax checking, thus prohibiting anysyntactical errors Also, the layout of the recipe is generated automatically, saving much of the user’s timeotherwise needed to produce “nice” drawings The recipe editor furthermore comprises a dialog box tospecify the products, educts, and their default quantities

For the plant model, care must be taken regarding on what level of detail modeling should take place.Continuous simulation techniques require the description of a model block using a set of differentialequations This notion, however, does not make sense for a discrete event simulator Furthermore, creatingmodels in terms of differential equations (or other modeling paradigms like finite state machines) requiresexpert knowledge that should not be necessary to use the simulator

Therefore, BASIP models are split into a generic and a specific part Only the generic part, i.e., theinformation that is necessary for all simulation approaches, is contained in the models created with the

model editors Generic information contains the model structure, i.e., which equipment is connectedwith each other as well as equipment parameters, e.g., vessel sizes or minimum and maximum flow rates

of a pump The specific part, different from simulator to simulator, is contained in a model library that

is specific for each simulator

With the plant editor PLANTEDIT, shown in Figure 6.8, a flow sheet model of the plant can be built.Equipment can be chosen from a library of equipment types and is connected by material or energyflows Furthermore, equipment phases (technical functions) as, e.g., dosing, heating, stirring, etc can beassigned to the equipment items Each equipment item and each phase has a number of parameters thatcan be set by the user

Since an automatic routing of connections would not lead to satisfactory results in all cases, the plantlayout is under the user’s control, but is supported by several layout help functions

6.7 Hybrid Simulation

For some applications in batch process simulation, the dynamics of the plant equipment and the substancescontained cannot be ignored In contrast to the manufacturing industries, purely discrete models cannotprovide the required accuracy Thus, the dynamics are described using differential equation systems, the

FIGURE 6.7 The master recipe editor R EZ E DIT

standard modeling paradigm for continuous systems So far, only systems of ordinary differential equations(ODEs) are handled by the numerical solver The more general case of differential-algebraic equations(DAEs) is suited better to model certain phenomena that occur in batch process dynamics, but solvers forthese systems require more computational effort, especially in the case of hybrid systems.

On the other hand, batch processes are discontinuous by nature, i.e., discontinuous changes in thesystem inputs and of the system’s structure frequently occur From a system-theoretic point of view, batchprocesses belong to the class of hybrid systems Such systems have both continuous and discrete dynamicswhich are closely coupled [Engell, 1997]

Neither conventional continuous nor discrete event simulation techniques can handle such systems.New simulation approaches are necessary for an adequate treatment of hybrid systems

One approach taken in BASIP is to partition the simulation time into intervals in which the systemstructure remains constant and the system inputs are continuous The resulting differential equationsystem can then be solved by a standard numerical solver The key problem of this approach is, of course,

to find the right partition This problem is also known as event detection An event is a point of timewhere a discontinuity occurs

Events can be divided into two categories: if the time when an event occurs is known in advance, it iscalled a time event A time event is induced, e.g., by a recipe step with a fixed duration Time events areeasy to handle for a simulation program For state events, on the other hand, the point of time depends

on the values of state variables Special methods are necessary to determine the exact time at which theevent occurs This problem corresponds to finding the roots of a switching function that is, in general,given only implicitly Neither time nor state events can be determined before the simulation starts Thus,event detection is an integral part of a simulation algorithm for hybrid systems [Engell et al., 1995].The basic structure of the simulation algorithm is shown in Figure 6.9 In the first step after initializa-tion, the state vector ( ), consisting of the state variables and their derivatives, is reconfigured, i.e., the

FIGURE 6.8 The plant editor P LANT E DIT

currently active state variables are determined and inserted in the vector This step is repeated after eachsuccessful event detection step Note that in this reconfiguration step the number of state variables in thestate vector can change and discontinuities in the values of state variables are allowed By this dynamicreconfiguration, the size of the state vector is kept minimal, eliminating unnecessary, i.e., not affectedstate variables; thus keeping numerical integration efficient [Wöllhaf et al., 1996] In most simulationapproaches, the state vector is set up once at initialization time and contains all state variables, whether

or not they are active in a specific interval

Next, the integration interval is set using a maximum step width h The integration routine in the nextstep evaluates the state vector at the end of this interval It may use internally, a smaller, or even variablestep width

After every integration step, it must be checked to determine whether an event has occurred How this

is done is explained below If an integration method uses several internal steps to integrate the interval, itmight be useful to repeat the event, checking after every internal step If no event has occurred, the nextinterval can be integrated; otherwise, the validity of the event is checked, i.e., it is tested, whether the time

of the event coincides with the end of the interval Although this is not equivalent in all cases, it usuallysuffices to test if the value of the threshold crossed is still sufficiently close to zero If this is the case, theevent is valid and the model can be switched, i.e., the discrete part of the model is re-evaluated Otherwise,one tries to get an estimate for the time of the first event (there might have occurred more than one event

in an interval) that occurred This can be done by an interpolation using, e.g., regula falsi, or, if this fails

due to strong nonlinearities, the interval is simply halved The end time is set to the estimated time andthe interval is integrated again If the estimation was good enough, the event time will coincide with theend of the interval and the event will be declared valid Otherwise, this procedure has to be iterated untilthe interval end is close enough to the event time, or the interval width is below a predefined limit.Using the object-oriented approach, this algorithm call be implemented using a set of cooperatingobjects The object model of the hybrid simulator is depicted in Figure 6.10 The driving force in thisstructure is the simulator It performs its task using two components: a numerical solver, which carriesout the integration using a numerical integration method which is entirely encapsulated, and, on themodel The model is responsible for configuring the state vector, evaluating the equations, event checking,and model switching.

For simulation purposes, it does not make sense to preserve the division of the model into plant andrecipes; instead, the model has a continuous and a discrete part These two classification schemes are notequivalent, since the plant model itself may have a continuous, as well as, a discrete part, the latterstemming from physical discontinuities like phase transitions front liquid to gaseous, a vessel which runsempty, or a switched controller

In the continuous model part, there is a one-to-one mapping of equipment and phases defined in theplant model to simulation model items These objects are augmented in the simulation by differentialequations describing their behavior Each model item manages its own state variables and implements

a call method that returns the derivatives of its state variables depending on the current system state.Model items are structured further to reflect the plant structure, thus facilitating modifications orextensions Figure 6.11 shows the object model Model items are divided into equipment and equipmentphases Equipment phases are the active elements in the simulation; they force else calculation of thederivatives of the equipment they are operating on, depending on the current plant state Equipmentobjects are passive elements; their state variables are only recalculated if at least one phase operates onthem There may be exceptions, e.g., when a vessel cools down due to thermal losses to the environment.These situations have to be handled separately

The most important type of equipment is a vessel It contains a mixture of (possibly) differentsubstances The state variables for a vessel are its enthalpy and the masses of each substance it contains,separated by state, i.e., liquid and gaseous In contrast, a resource serves as a system boundary, providing

an unlimited reservoir of a certain substance

The discrete part of the model consists of a state graph containing states and transitions The stategraph consists of several parallel independent subgraphs with local states Such a subsystem can be arecipe, where as the state is composed of the steps which are currently active (and the transitionscorrespond naturally to the transitions of the recipe) It can also describe discrete behaviors of the plantequipment and the substances contained, e.g., the filling level of a vessel using the states empty, medium,and full, or the aggregate state of a substance In both cases, the transitions between the states are expressed

by conditions for the values of physical quantities

Transitions make use of threshold objects which describe the switching conditions like A(t) B(t) inthe form of switching functions h(t)  A(t)  B(t) In the event detection step of the simulationalgorithm, the state graph has to be evaluated For that purpose, the transitions following all active statesare checked to determine whether the switching function has changed its sign

In the model switching step, each switching of a transition deactivates its predecessors and activatesits successors Each affected state notifies its corresponding model item of the change so that subsequentmodel evaluations can reflect the new state

6.8 Discrete-Event Simulation

Another approach to cope with the hybrid nature of batch processes relies on the discrete-eventmodeling and simulation paradigm In a discrete-event model, a system is always in one of a (finite orinfinite) number of states A transition to another state is possible if a condition depending on externalinputs or on the internal dynamics of the system is fulfilled A state change is called an event Commonrepresentations for discrete-event systems are finite automata, state charts, Petri nets, or queuingsystems

The purpose of a discrete-event simulator is to determine the order of state changes which a systemperforms due to its internal dynamics and external inputs, starting from a given initial state In timedmodels, the duration for which the system remains in each state is also of interest Thus, a discrete-event simulator is only interested in the system at the points of time where state changes occur.

Figure 6.12 shows the simulation algorithm of a conventional discrete-event simulator Central to thealgorithm 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 associatedwith 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 someother termination condition is fulfilled, e.g., a maximum simulation time is reached, the simulation isterminated

It is noteworthy that the notion of event generation that usually takes the main part of a discrete-eventsimulator, is semantically equivalent to event detection, introduced in the section about hybrid simula-tion 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 programitself Thus, both approaches have more in common than the traditional dichotomy between continuousand discrete-event simulation implies The term event-based simulation could be applied as a genericterm to both approaches