e
Computers and Chemical Engin eering Supplem ent (1999) 5547-5550 iD 1999 Elsevier Science Ltd. All rights reserved PH: 5009 8·135 4199100234-3
Pergamon
Integrated Decision Support in Flexible Multipurpose Plants Julian G. Rickard, Sandra Macchietta and Nilay Shah" Centre for Process Systems Engineering Imperial College of Science, Technology and Medicine London SW7 £BY, U.K.
Abstract. This paper describes the initial development of an integrated system for the scheduling and supervisory control of flexible multipurpose plants. The approach is based upon a single data model containing all the information required to support these activities. From this single model the submodels required to perform scheduling and supervisory control are created, and since the information in each model has come from a single source, it can be translated through the use of the overall model to integrate these two operations. An example is shown to demonstrate the concept. Keywords: Flexible Mulitpurpose Plants; Scheduling; Supervisory control; Integration;
Intra d uction Many papers have highlighted the advantages of multipurpose flexible batch chemical plants and their ability to react to changes in markets and products. This flexibility requires careful management to obtain maximum benefits . Many authors illustrate the management of these plants as a hierarchy of operations, where each level of operation considers a different level of detail of the. plant and recipes and at a different time span. The exact terminology differs among authors, but an example is Figure 1.
dr activities to fulfil an order slate or some other objective. The gBSS package, based on the work of (Kondili et al., 1993), carries out such a function. At the highest level, a planning function may distribute production among sites and set targets for each, looking at a time horizon of perhaps a few months. Much work has gone into developing packages for carrying out each individual function, but less at-
At the bottom the plant is controlled by a distributed control system, (DeS), or programmable logic controller, (PLC). Above this a supervisory level implements a schedule in the control system by triggering actions and responding to their completion, while resolving resource conflicts . An example of this type of system is the SUPERBATCH system initially developed by Cott (1989). The order of batches used at the supervisory control level is created by the short-term scheduling function. This looks at a time span of perhaps a week and attempts to find a sequence of batches • Author to whom all correspondence should be addressed; e-mail: n.shah0ic.ac.uk Fax : (44)-171.594.6606
Th.Plan.
Figure 1: Hierarchy of Batch Operations Management
5548
Computers and Chemical Engineering Supplement (1999) S547-S550
tention has been paid to how these functions work together. The schedule generated by the shortterm scheduling package will only ever benefit the company if it shown to be better than the current schedule and then implemented in the supervisory control package. Similarly, the schedule may be of no use if the current plant situation, (available in the supervisory control package), is not taken as an initial condition. Therefore there is value in looking at how information flows between these functions, as well as how well each function is performed. This paper describes a new system which allows information to be automatically passed between a scheduling package and a supervisory control package.
Methodologies for integration If the models of plant equipment and product recipes used at the supervisory control and short term scheduling levels were the same, integration would be simple. However the plant and product recipes are described in different levels of detail appropriate to the time span in question.
Traditionally, integration has invloved defining the mapping between the models and writing 'translation' code to pass the information. This bespoke solution is rigid, inflexible and costly to implement or change, degrading the very flexibility that batch plants are supposed to provide. Instead, we have developed a system to sit around the short-term scheduling and supervisory functions. This system takes a single, hierarchical model describing the plant and recipes at the level of detail required by the supervisory control, together with details of how the model is aggregated at the short-term scheduling level. From this single model, the models required at the two levels can then be automatically generated. The fact that these two models have come from a single structure allows algorithms to be written that take the scheduling package output and convert it to the supervisory control input. Similarly the detailed estimates of timings generated by the supervisory control package can be passed as an initial state to the scheduling package. These algorithms work on the structure of the model, rather than the information present, and therefore can be applied to any situation that can be modelled.
scheduling model may treat them as units. ignore them or treat them as common resources, (such as in the case of routing paths). Each item is tagged as to how it is represented in the scheduling model. Materials. The gBSS package uses the StateTask Network (STN) representation, where material 'states' are transformed by tasks. Since material can undergo physical transformations without chemical change, e.g. by being weighed into a weigh tank, each material may exist as a number of states. Procedures. The SUPERBATCH package executes 'operations', (in the S88.01 sense (ISA, 1995)), in the control system', and the operations are combined to form master recipes. The tasks of the STN lie somewhere between these two, depending on the desired amount of detail required in the scheduling model. This information may then be held in an object orientated data structure, which together with algorithms for translation and a user interface form a system for supporting integrated batch operations.
Data Translation The two main information flows which must therefore be enabled are those between the supervisory layer and the scheduling layer, shown by arrows 2 and 5 in Figure 1.
implementation of generated schedule The scheduling package determines a series of tasks which satisfy constraints and arrive at an optimum inventory of states. Therefore a chronological list of tasks, the units performing those tasks, and the size of those tasks can be created. The first step in creating an ordered list of control recipes is to find a 'last' task, i.e. a task that contains one or more steps that are not prerequisites for any other step, effectively tasks where some part of the recipe is finished. Once one of these tasks is found, the other tasks in this control recipe must then be found. This is done by comparing input and output materials around this task, and if the same material occurs at the same time then this task is part of the same recipe.
Rescheduling with current position
Single data model structure The basic model can be broken into equipment, materials and actions.
In order for the schedule created off-line to be fully implementable, it must reflect the current plant position, both in terms of inventories and those control recipes currently being executed.
Equipment. Equipment items required at the supervisory level are listed in the model. The
In fact since the solution time of the off-line optimal scheduling scheduling algorithm may be of
Computers and Chemical Engineering Supplement (1999) S547-S550
5549
a significant size. In this case, the plant position taken is actual1y that expected after a specified period of time. This 'inviolate' period allows for batches to start during the solution period, and should be as long as the solution is likely to take. Current operations could either be model1edwith extensions to the off-line scheduling formulation or the optimisation model data may be modified to take account of operations that are partial1y underway at the start of the scheduling horizon. This effectively ties up equipment resources and will make material resources available after the completion of the activity.
Example of integrated operations A simple example is now demonstrated to show the principles of the prototype system. The plant consists of three major processing units, as shown in Figure 3. Two products are made within the plant, and each has it's own dedicated storage tank. Before the units can be switched from making one product to the other, they must be cleaned. The state task network for the process is shown in Figure 4. Once the overal1 model has been created and the submodels generated, then an initial schedule can be generated in gBSS. as shown in the Gantt chart in Figure 5. This can then be translated into a list of control recipes. and implemented in SUPERBATCH, as shown in Figure 6. The initial schedule was optimised based on the prices of the two products, and therefore the optimal decision was to make the more valuable product. If however we now add an order for the other less valuable product, and give this order quite a large value. (for example to model an order placed by an important customer), and now run gBSS again, then we obtain the schedule shown in Figure
Figure 2: System Flowchart.
._~. 1'_
7. Figure 3: Flowsheet of example plant. The optimum schedule is to now to try and fulfil1 the order and then revert to making the higher priced product. However if ther original schedule. (that of Figure 6). were already implemented on line, then the first batch would have already started. This batch is therefore fixed at the beginning of the schedule, and the resulting unit states and inventories are used by gBSS as an initial position. The final detailed schedule generated by SUPERis shown in Figure 8. where it can be seen that those batches of Product 1 that have already been committed to are first finished, the plant is cleaned and production switched to Product 2 until the new order date has passed, when production BATCH
Figure 4: State Task Network of example plant.
Computers and Chemical Engineering Supplement (1999) 5547-S550
5550
reverts to Product 1, again preceded by th e necessary cleaning.
....... ...
I
1_"
1<1_ _ s,....
...,......c_... "I't"
:ll \ I ~ I'ft f '
U..
__ 'wr 11_
Tw.
A N'_EXA MPLE J'LA NT
i
. 1Ct . 1
l~LLL~~LLL~~LLLL~~LLLL~LLLL~~LLLL
..
I ' .'
This sys tem now allo ws t he future study of rescheduling polic ies , decidin g whe n off-I ine optim al rescheduli ng is requi red, an d how t hese deci! sions affect the profitability of plants.
I
.~} • Dlar.t.'ll. 1
I References
."'.' 1I Cott , B. J . (1989). An Integr ated Compu ter- Aided
. u ...C"nl ... "
t
~
or ISA (SP9 5) (ISA , 1998) m ay go som e way to st an dardi sing th ese interfac es.
1
!
e
!
t
t
,
, .,
t
,
,
,
1
,
t •
, ,
r r ,
,
~
t
,
,
,
,
t
....... -~·.· I
I
~ CUA.'C_ •
Production Managem en t System for Batch Ch em ical Processes . PhD th esis. Imperial College, University of London.
• Q.LA>O.J>
•..
. . . . . . ..-
~:w:...~~~~ I_ ,:.e)
.. ..
~~ ~
M
Figure 5: Initial Optimal Schedule from gBSS
ISA (1995). S88.01-1995 Standard. Batch Control. Part 1 : Models and Terminology. ISA (1998). dS95.01 Draft 5. Ent erprise Integration . Part 1 : Models.
It:
Kondili, E., C. C. Pantelides and
., rU:UAiM
, .· · . •• .• -._. ·· -
, , , • •, ,• , , ,• , ,, , , , , , , , • • • , I •, I
.... . . . I I I I
I
0
I
0 I
I
I I I I I I I
I I
I
I
I
0 I I 0 I I
I
I 0
0 0 I I 0
0
I I 0 I
I
I I 0
I
0
I
0
W. H. Sargent (1993) . A general algorithm for short-term scheduling of batch operations - I. MILP Formulation. Compo chem. Eng. 17 .211-227.
lT nTITIT rl·nTr r n ' n ' Jl T ITIT n T I·l r ·'- .
..
w, •••••• , •••••••••••••••••••
II I'"
_
W.
.
..,_ Ir_ ...-c:......
lJN'f'l .. n,...~
1 __
rft:I
U4lo l J _
, ...
I·: !
~
e. "71JTnnnT
,. _...__._.....__. - .....- .-._._- .. -.._......-, 0 I .., , , , , I I I , I I , I ,..., I I 0 , 0 I , I , I I.. 0 0 I......... ,. ..............--.-...._-_._-....._-.-.._...................._.....__......__.
_- ----_ __ -
H~H""HHHHHHHHHHHHHH HHHHHHHH~HHHHH
~
~ - -----_. -
A...t.J EXA.MPlE Pl..ANT
~
• _lbnll ollJl I
, L LLLLLLLLLI.LI.LL LL
c..u..u.c.. L
,
: ·'1
.
.tt.
_
. . . . . . Ol l lMOOCXi.oo
•
Conclusions
•
•••
t
••
•
t
••
•
,
..
......
· 1lIII~·J I
~ ~.
: :::1 1
Figure 6: Initial Schedule implemented in SUPERBATCH The results have all been generated from data comprising the details of each recipe, the resoure requirements for each acitivity, economic/performance information such as demands and product values and the level of aggregation desired for each STN task.
•
.l:1.LNl .D
=~ ~~~~';"~~~~~o:L~~';"';"Iol.~ ~ ~..:..~
Figure 7: Reoptimised Schedule fjorn gBSS
, . . •, .. . . ., ... ., • • , .......... .-.... .. •• .
' u ot-.
",
I
I
, , ,•
It '
I
I
I
,
I
I
0 0 0 0
I
I I I
I
0 I
0
I
I
I
I
I
0 I
0
0
I
0 I
I
0 0
I 0 I It
0 I
0 0
, I It 0
,I
I I 0 It
~
I
In this paper we have described a prototype system which allo ws the generic, closed-loop integration of a scheduling package with a supervisory cont rol package . A sim ple example has shown how the system responds automatically to changes in the order slate. Although the system has been written around two sp ecific soft ware p ackages , the information flows are fairly general, and so the approach could equally be used with other similar packages by simply changing the format of the data flows. Additionally, efforts such as those initiated by PRIMA
: ! ·l r .. I T1 .... T T TrTIT1.... T I'..-T ·" I1'1·11 TI ". _
rrrrr
I
I
I
I
I
I
I
I
I
I
I
I
I
I
" rrrrl'Tf': _ .
i·n',·rr ITlTn- ·nrmnnnr_
mnlT'lTlm • h...H"""H HH HHH _..._---H"HM -_........ _-_._...................HH_--_..._-_ .--", , , ,, , ....._.._.. ._--_.._---_...........-........ ...-....._-.. , , , , , , ...................._..__._._... ..._.._-_._..............................._.. , . I
__
0
0 I
H ....... HH H H H "
HHH" to!
I I
I
I
I
I
I
I
I
I
~
I
I
_ ~
.~
~
I
....-_. Figure 8: Reoptimised Schedul e implemented in SUPERBATCII