- Email: [email protected]
Integration of available CAPE tools for real time optimisation systems
European Symposmm on Computer Aided Process Engineering - 11 R. Gani and S.B. Jorgensen (Editors) 9 2001 Elsevier Science B.V. All rights reserved.
1077
Integration of available CAPE tools for R e a l T i m e Optimisation systems Sebasti~m Eloy Sequeira, Mois6s Graells, Luis Puigjaner. Chemical Engineering Department, Universitat Polit6nica de Catalunya, Av Diagonal 647 Pav. G, 2~ Spain
Keywords. RTO, Optimisation, CAPE. This paper addresses the communication of present CAPE tools as the way for achieving integrated systems supporting Real Time Optimisation. The work primarily focuses on integration of such tools in order to facilitate the implementation of RTO systems. Scheme and architecture proposed are validated with two case studies and the arising difficulties are discussed. First case study is based in a typical plant scheme where the recycle flow constitutes the decision variable and the plant profit the objective function. The economic model of the system is implemented on a spreadsheet while a commercial process simulator (HYSYS.Plant a) provides the simulation of the physical behaviour of the plant. The more complex second case includes several decision variables. Therefore, a solver function of a mathematics simulator was used (Matlabb). The communication between all these tools is established by means of COM (Component Object Model) and DDE (Dynamic Data Exchange) technologies, thus constituting a hybrid distributed model of the system. Finally, computational advantages of such an aggregated model are discussed as well as the improvement possibility of the optimisation procedures performance. a Hysys.Plant is a trademark of Hyprotech
b Matlab is a trademarkof MathWorks 1. INTRODUCTION Real Time Optimization (RTO) has been receiving increasing attention as communication technologies allow having computer aided decision-making tools connected on-line with the plant or the system to be managed. Software tools and system architectures employed show that RTO systems are designed for providing different information supplying features and for satisfying different goals, Gross Error Detection, Data Reconciliation and Parameter Estimation (PEDR), and Optimisation ([1], [2] and [3]). The main functionality is doubtless the optimisation. This is usually carried out using a simulation model, which incorporates an optimisation tool. Lots of different software tools are currently available for managing some of these features and goals. However, most of these tools are presently used for different activities in an independent way. Hence, the opportunity of using these software tools within an integrated environment should be investigated in order to enhance their performance in a synergetic way, taking advantage of the developments in each specific area and combining them, thus making the best as a whole.
1078 This work introduces a starting point in this direction that is based on the use of commercial software tools (such as simulation and optimisation packages, as well as spreadsheets, which are very familiar to process engineers). Such tools are later integrated into a distributed system with the aid of the presently available communication technologies (COM, DDE). The basic static and dynamic structures are next introduced. 2. SYSTEM ARCHITECTURE Optimisation is the core and main functionality of the RTO system. However, the tasks the system is also expected to manage the data coming from and going back to the plant. Hence, the following modules are proposed: 9 D a t a M a n a g e m e n t : This module receives data from the plant (but previously filtered by the gross error detection and PEDR systems). After optimisation this module sends back the set points (SP' s) to the control system. This should also allow an off-line analysis. 9 O p t i m i s a t i o n : This module consists of the following elements: The process model (constraints), the economic model (objective function) and the search engine (solver). The associated static structure is shown in Figure 1:
Figure 1" Basic static architecture. This is, the Data Manager (DM) is the system's executive, while the remaining elements are interfaced to the DM but not between themselves. The double arrow line in Figure 1 shows that the communication is reciprocal. The process and economic models are basically black box simulators, in the sense that they produce an answer when perturbed by an input, under certain model parameter conditions. On other hand, Figure 2 gives the corresponding dynamic structure:
I IVI~NAC-~R DATA o A ~ , ~ E ~ s ,CONDn',~
I
s~"
l
I '
I ECONOMIC MODEL
I PR~ MOOEL I
INV(~.ATION
.,,,..._ r
For each iteration
INVOCATION RESULTS INVOCATION
E " REsPoNs~ NEW CONDITIONS .=f
OPT OLRPUT
Figure 2" Dynamic Architecture.
RESLLTS
71
1079 Following the scheme in Figure 2, as the DM receives the new plant conditions the solver (OPT) is invoked for optimisation. The OPT will then perturb the model and wait for response the time needed for the corresponding algorithm to converge. This is a non-direct perturbation since the data are sent to the process model (PM) trough the DM. Once the PM gets the results, these results are sent to the economic model (EM) again trough the DM. Off-line analysis is also possible within the same structure. The OPT may be replaced or complemented by any other module since the only requirement for the new component to be plugged into the system is to have the same dynamic behaviour as the OPT module. Thanks to this architecture, the use of different algorithms and modules is extremely easy and helpful. Sensibility analysis is an example of off-line process that may be included in this framework as it will be shown later on. 3. I M P L E M E N T A T I O N Next step is the software election for the Figure 1 functionality. The different choices are next explained: Process Model was developed using the sequential-modular simulation package HYSYS.Plant since it offers very good communication capabilities. On other hand, the Economic Model was implemented on a MSExcel's spreadsheet. Excel c also has an open architecture allowing very easy communication with HYSYS via ActiveX. Additionally, it is a tool that may be considered as a customisable user interface for the system. The economic model implemented includes the investment calculation, the operating cost, and the revenues. The performance measure selected for the problem was the Present Value (PV). In Case A, given that the optimisation involves only one decision variable, the Optimisation algorithm was written in Visual Basic for Applications (VBA), a simple programming language, easily linked with Excel. The algorithm used was the golden section because of its robustness. On other hand, in Case B as the optimisation involves more decision variables no algorithm was written. Instead, the "constr" Matlab function was used. This optimisation algorithm is an implementation of sequential quadratic programming (SQP). Other solvers (public domain, in house, etc.) may be also plugged in this scheme thanks to the modular approach. The Data Manager chosen for this specific implementation was Excel again. It allows the easier communication according the previous choices, and this is the main job of the DM [4]. 4. COMMUNICATION Given all the elements of the system, communication between them is needed. Regarding the tools selected for the specific implementation presented the simplest way is to use VBA and the interfaces available for Excel and HYSYS. In order to communicate the algorithm in Matlab with the DM in Excel, the Dynamic Data Exchange (DDE) service was used. 5. CASE STUDIES For evaluation of the system architecture two scenarios are presented. In the first case study, a typical plant scheme is considered: a plant with a reactor, a separator and a recycle stream. In this case the single decision variable is the recycle flow and the objective function is the plant profit. For the second example more decision variables are contemplated. Both cases are from [5]. c Excel is a trademark of Microsoft
1080 Case A. The problem.
The process under study is the ethyl chloride production according to the process flowsheet shown in Figure 3. A conversion reactor produces a mixed output that is separated into a product stream (P) and the stream ($4) to be recycled. A purge stream (W) prevents the accumulation of inert components in the system. Hence, changes on W flow affect the recycle and thus the process economy. Increasing the recycle increases energy cost, but raw materials cost is reduced instead. Therefore, the flow W constitutes a decision variable, and should be adjusted to produce the best operation point according to the changing feed conditions, market prices and resources cost.
Figure 3: Ethyl Chloride Process Flowsheet. Case A. Results.
System performance is verified varying the feed conditions and the market prices. When input changes occur, the new model response (simulation according to the new plant data) and the last model response are compared. If the changes are significant, the optimisation takes place. After optimisation is done, the DM exposes the new set's points to the control system. Figure 4 shows a screenshot of the DM's main page. Row divisions show to the different input/output sets, input parameters, manipulated variable, objective function and main process model outputs. The first column is for the variable name, next column (Plant) contains the plant data and the simulation results obtained from those data. The last column (Last Model) gives the last optimisation conditions and results. Finally, the centre column gives the difference between the previous values, used for deciding if next optimisation will be done. For time consumption evaluation, random feed conditions were generated for ten scenarios and the average optimisation time was 23.4 seconds (std. deviation 23.5 %) in a PC Pentium Family AT 350 MHz - Ram 128 KB. This is similar to the time required by the HYSYS optimiser, but this approach allows in addition to deal with a more open and flexible model. The same framework may offer other decision-making tools such as off-line sensitivity analysis. Figure 5 shows a screenshot of the page used for this purpose. The chart shows the effect of the W stream flow on the Present Value. This kind of study can be very useful when the calculated optimum can not be achieved for practical reasons not contemplated in the model and for bottleneck identification as well.
1081
Figure 4: DM's main page.
Figure 5: Page for sensibility studies.
Case B. The problem. The system considered next is the separation of a mixture of Hydrogen Chloride (HC1), Benzene (Bz), and MonoChloroBencene (MCB), which is the output of a reactor producing MCB by the chlorination of benzene. The process flowsheet is shown in Figure 6.
Figure 6: Bz-MCB separation process.
Figure 7: Page for sensibility studies.
Consider the influence of temperature in stream S 14, which is given by MCB final cooling. A temperature increase will produce on one hand a better Bz recovery, but on other hand will increase the refrigeration cost. Another interesting trade-off is given by the split fraction of S 14 in separator S-1. As the recycle grows, more Bz will be again recovered, but the energy cost is increased (heating in D-1 and T-l). Finally, another operation decision variable is the Reflux Ratio in tower D-l, which may be adjusted to satisfy the flow and purity of products directly in HYSYS. Hence the problem arising is the determination of the optimum values of these variables once that feed conditions and market prices are given.
1082
Case B. Results. Once again, the system performance is tested varying feed conditions and market prices. The DM structure is the same showed in Case A. Figure 9 shows a screenshot of the page used for sensibility studies. The chart shows the effect of the decision variables on PV: the strong effect of the temperature, and the minor effect of the split fraction. Time consumption was measured in ten scenarios for which random feed conditions were generated. The average optimisation time was 66.7 seconds (std. deviation 19.5 %) in a PC 350 M H z - Ram 128 KB, which is of the same order than that required by HYSYS optimisers. However, the modular approach also allows using different optimisation techniques, which may improve the performance by manipulating the aggregated model. The recycle stream for instance, may be considered at the upper economic model by adding new decision variables and new constraints. This is, the recycle stream may be ignored in HYSYS, while the recycle stream may be considered as manipulated variable. Hence, by adding the recycle convergence as a set of constrains, the solver can optimise the process while converging the flowsheet. Thus, there is no need to wait HYSYS to converge the recycle for each solver iteration. Using this strategy on ten scenarios, the average optimisation time was 132.5 seconds (std. deviation 10.3 %) on the same PC, which is certainly higher than for the original model. However, it will not be the case as more decision variables are implicated. 6. CONCLUSIONS A simple framework for the development and implementation of the essential elements of a RTO system has been introduced. The advantages of the proposed architecture are that known tools for the chemical engineer are the main elements used. Besides, the engineer effort is mainly focused on the system communication and the decision making, but not in the development of its constitutive parts. Experience and development in the areas of optimisation and simulation may be included in the system by communicating the corresponding software packages. Additionally, a modular approach allows the use of plug and play philosophy. This means easily construction and maintenance. Therefore, future work will include the implementation of other components (PEDR, etc.) in the system. Finally, the communication effort is expected to be significantly reduced after GCO standardisation.
Acknowledgements Financial support from the European Community is gratefully acknowledged (project Global-Cape-Open-IMS 26691). Sebastian Eloy Sequeira wishes to acknowledge to Spanish "Ministerio de Educaci6n, Cultura y Deporte" for the financial support (grant FPI). References 1. Z. Zhang, R. W. Pike and T. A. Hertwig, "An approach to on-line optimization of chemical plants", Computers Chem. Engng., vol. 19. Suppl., pp. $30-$310, 1995. 2. S. Yoon, S. Dasgupta and G. Mijares, "Real-Time optimization boosts capacity of Korean olefins plant", Oil & Gas Journal, vol. 94, pp. 36, 1996. 3. K. Chin, "Maximize Profits Plantwide", Chem. Eng., vol. 105-3, pp. 143, 1998. 4. E. M. Rosen, L. R. Partin, "A perspective: The use of the Spreadsheet for Chemical Engineering Computations", Ind. Eng. Chem. Res., vol. 39, pp. 1612-1613., 2000. 5. W. D. Seider, J. D. Seader and D. R. Lewing, "Process Design Principles: Synthesis, Analysis, and Evaluation". John Wiley & Sons, Inc. 1999.
1077
Integration of available CAPE tools for R e a l T i m e Optimisation systems Sebasti~m Eloy Sequeira, Mois6s Graells, Luis Puigjaner. Chemical Engineering Department, Universitat Polit6nica de Catalunya, Av Diagonal 647 Pav. G, 2~ Spain
Keywords. RTO, Optimisation, CAPE. This paper addresses the communication of present CAPE tools as the way for achieving integrated systems supporting Real Time Optimisation. The work primarily focuses on integration of such tools in order to facilitate the implementation of RTO systems. Scheme and architecture proposed are validated with two case studies and the arising difficulties are discussed. First case study is based in a typical plant scheme where the recycle flow constitutes the decision variable and the plant profit the objective function. The economic model of the system is implemented on a spreadsheet while a commercial process simulator (HYSYS.Plant a) provides the simulation of the physical behaviour of the plant. The more complex second case includes several decision variables. Therefore, a solver function of a mathematics simulator was used (Matlabb). The communication between all these tools is established by means of COM (Component Object Model) and DDE (Dynamic Data Exchange) technologies, thus constituting a hybrid distributed model of the system. Finally, computational advantages of such an aggregated model are discussed as well as the improvement possibility of the optimisation procedures performance. a Hysys.Plant is a trademark of Hyprotech
b Matlab is a trademarkof MathWorks 1. INTRODUCTION Real Time Optimization (RTO) has been receiving increasing attention as communication technologies allow having computer aided decision-making tools connected on-line with the plant or the system to be managed. Software tools and system architectures employed show that RTO systems are designed for providing different information supplying features and for satisfying different goals, Gross Error Detection, Data Reconciliation and Parameter Estimation (PEDR), and Optimisation ([1], [2] and [3]). The main functionality is doubtless the optimisation. This is usually carried out using a simulation model, which incorporates an optimisation tool. Lots of different software tools are currently available for managing some of these features and goals. However, most of these tools are presently used for different activities in an independent way. Hence, the opportunity of using these software tools within an integrated environment should be investigated in order to enhance their performance in a synergetic way, taking advantage of the developments in each specific area and combining them, thus making the best as a whole.
1078 This work introduces a starting point in this direction that is based on the use of commercial software tools (such as simulation and optimisation packages, as well as spreadsheets, which are very familiar to process engineers). Such tools are later integrated into a distributed system with the aid of the presently available communication technologies (COM, DDE). The basic static and dynamic structures are next introduced. 2. SYSTEM ARCHITECTURE Optimisation is the core and main functionality of the RTO system. However, the tasks the system is also expected to manage the data coming from and going back to the plant. Hence, the following modules are proposed: 9 D a t a M a n a g e m e n t : This module receives data from the plant (but previously filtered by the gross error detection and PEDR systems). After optimisation this module sends back the set points (SP' s) to the control system. This should also allow an off-line analysis. 9 O p t i m i s a t i o n : This module consists of the following elements: The process model (constraints), the economic model (objective function) and the search engine (solver). The associated static structure is shown in Figure 1:
Figure 1" Basic static architecture. This is, the Data Manager (DM) is the system's executive, while the remaining elements are interfaced to the DM but not between themselves. The double arrow line in Figure 1 shows that the communication is reciprocal. The process and economic models are basically black box simulators, in the sense that they produce an answer when perturbed by an input, under certain model parameter conditions. On other hand, Figure 2 gives the corresponding dynamic structure:
I IVI~NAC-~R DATA o A ~ , ~ E ~ s ,CONDn',~
I
s~"
l
I '
I ECONOMIC MODEL
I PR~ MOOEL I
INV(~.ATION
.,,,..._ r
For each iteration
INVOCATION RESULTS INVOCATION
E " REsPoNs~ NEW CONDITIONS .=f
OPT OLRPUT
Figure 2" Dynamic Architecture.
RESLLTS
71
1079 Following the scheme in Figure 2, as the DM receives the new plant conditions the solver (OPT) is invoked for optimisation. The OPT will then perturb the model and wait for response the time needed for the corresponding algorithm to converge. This is a non-direct perturbation since the data are sent to the process model (PM) trough the DM. Once the PM gets the results, these results are sent to the economic model (EM) again trough the DM. Off-line analysis is also possible within the same structure. The OPT may be replaced or complemented by any other module since the only requirement for the new component to be plugged into the system is to have the same dynamic behaviour as the OPT module. Thanks to this architecture, the use of different algorithms and modules is extremely easy and helpful. Sensibility analysis is an example of off-line process that may be included in this framework as it will be shown later on. 3. I M P L E M E N T A T I O N Next step is the software election for the Figure 1 functionality. The different choices are next explained: Process Model was developed using the sequential-modular simulation package HYSYS.Plant since it offers very good communication capabilities. On other hand, the Economic Model was implemented on a MSExcel's spreadsheet. Excel c also has an open architecture allowing very easy communication with HYSYS via ActiveX. Additionally, it is a tool that may be considered as a customisable user interface for the system. The economic model implemented includes the investment calculation, the operating cost, and the revenues. The performance measure selected for the problem was the Present Value (PV). In Case A, given that the optimisation involves only one decision variable, the Optimisation algorithm was written in Visual Basic for Applications (VBA), a simple programming language, easily linked with Excel. The algorithm used was the golden section because of its robustness. On other hand, in Case B as the optimisation involves more decision variables no algorithm was written. Instead, the "constr" Matlab function was used. This optimisation algorithm is an implementation of sequential quadratic programming (SQP). Other solvers (public domain, in house, etc.) may be also plugged in this scheme thanks to the modular approach. The Data Manager chosen for this specific implementation was Excel again. It allows the easier communication according the previous choices, and this is the main job of the DM [4]. 4. COMMUNICATION Given all the elements of the system, communication between them is needed. Regarding the tools selected for the specific implementation presented the simplest way is to use VBA and the interfaces available for Excel and HYSYS. In order to communicate the algorithm in Matlab with the DM in Excel, the Dynamic Data Exchange (DDE) service was used. 5. CASE STUDIES For evaluation of the system architecture two scenarios are presented. In the first case study, a typical plant scheme is considered: a plant with a reactor, a separator and a recycle stream. In this case the single decision variable is the recycle flow and the objective function is the plant profit. For the second example more decision variables are contemplated. Both cases are from [5]. c Excel is a trademark of Microsoft
1080 Case A. The problem.
The process under study is the ethyl chloride production according to the process flowsheet shown in Figure 3. A conversion reactor produces a mixed output that is separated into a product stream (P) and the stream ($4) to be recycled. A purge stream (W) prevents the accumulation of inert components in the system. Hence, changes on W flow affect the recycle and thus the process economy. Increasing the recycle increases energy cost, but raw materials cost is reduced instead. Therefore, the flow W constitutes a decision variable, and should be adjusted to produce the best operation point according to the changing feed conditions, market prices and resources cost.
Figure 3: Ethyl Chloride Process Flowsheet. Case A. Results.
System performance is verified varying the feed conditions and the market prices. When input changes occur, the new model response (simulation according to the new plant data) and the last model response are compared. If the changes are significant, the optimisation takes place. After optimisation is done, the DM exposes the new set's points to the control system. Figure 4 shows a screenshot of the DM's main page. Row divisions show to the different input/output sets, input parameters, manipulated variable, objective function and main process model outputs. The first column is for the variable name, next column (Plant) contains the plant data and the simulation results obtained from those data. The last column (Last Model) gives the last optimisation conditions and results. Finally, the centre column gives the difference between the previous values, used for deciding if next optimisation will be done. For time consumption evaluation, random feed conditions were generated for ten scenarios and the average optimisation time was 23.4 seconds (std. deviation 23.5 %) in a PC Pentium Family AT 350 MHz - Ram 128 KB. This is similar to the time required by the HYSYS optimiser, but this approach allows in addition to deal with a more open and flexible model. The same framework may offer other decision-making tools such as off-line sensitivity analysis. Figure 5 shows a screenshot of the page used for this purpose. The chart shows the effect of the W stream flow on the Present Value. This kind of study can be very useful when the calculated optimum can not be achieved for practical reasons not contemplated in the model and for bottleneck identification as well.
1081
Figure 4: DM's main page.
Figure 5: Page for sensibility studies.
Case B. The problem. The system considered next is the separation of a mixture of Hydrogen Chloride (HC1), Benzene (Bz), and MonoChloroBencene (MCB), which is the output of a reactor producing MCB by the chlorination of benzene. The process flowsheet is shown in Figure 6.
Figure 6: Bz-MCB separation process.
Figure 7: Page for sensibility studies.
Consider the influence of temperature in stream S 14, which is given by MCB final cooling. A temperature increase will produce on one hand a better Bz recovery, but on other hand will increase the refrigeration cost. Another interesting trade-off is given by the split fraction of S 14 in separator S-1. As the recycle grows, more Bz will be again recovered, but the energy cost is increased (heating in D-1 and T-l). Finally, another operation decision variable is the Reflux Ratio in tower D-l, which may be adjusted to satisfy the flow and purity of products directly in HYSYS. Hence the problem arising is the determination of the optimum values of these variables once that feed conditions and market prices are given.
1082
Case B. Results. Once again, the system performance is tested varying feed conditions and market prices. The DM structure is the same showed in Case A. Figure 9 shows a screenshot of the page used for sensibility studies. The chart shows the effect of the decision variables on PV: the strong effect of the temperature, and the minor effect of the split fraction. Time consumption was measured in ten scenarios for which random feed conditions were generated. The average optimisation time was 66.7 seconds (std. deviation 19.5 %) in a PC 350 M H z - Ram 128 KB, which is of the same order than that required by HYSYS optimisers. However, the modular approach also allows using different optimisation techniques, which may improve the performance by manipulating the aggregated model. The recycle stream for instance, may be considered at the upper economic model by adding new decision variables and new constraints. This is, the recycle stream may be ignored in HYSYS, while the recycle stream may be considered as manipulated variable. Hence, by adding the recycle convergence as a set of constrains, the solver can optimise the process while converging the flowsheet. Thus, there is no need to wait HYSYS to converge the recycle for each solver iteration. Using this strategy on ten scenarios, the average optimisation time was 132.5 seconds (std. deviation 10.3 %) on the same PC, which is certainly higher than for the original model. However, it will not be the case as more decision variables are implicated. 6. CONCLUSIONS A simple framework for the development and implementation of the essential elements of a RTO system has been introduced. The advantages of the proposed architecture are that known tools for the chemical engineer are the main elements used. Besides, the engineer effort is mainly focused on the system communication and the decision making, but not in the development of its constitutive parts. Experience and development in the areas of optimisation and simulation may be included in the system by communicating the corresponding software packages. Additionally, a modular approach allows the use of plug and play philosophy. This means easily construction and maintenance. Therefore, future work will include the implementation of other components (PEDR, etc.) in the system. Finally, the communication effort is expected to be significantly reduced after GCO standardisation.
Acknowledgements Financial support from the European Community is gratefully acknowledged (project Global-Cape-Open-IMS 26691). Sebastian Eloy Sequeira wishes to acknowledge to Spanish "Ministerio de Educaci6n, Cultura y Deporte" for the financial support (grant FPI). References 1. Z. Zhang, R. W. Pike and T. A. Hertwig, "An approach to on-line optimization of chemical plants", Computers Chem. Engng., vol. 19. Suppl., pp. $30-$310, 1995. 2. S. Yoon, S. Dasgupta and G. Mijares, "Real-Time optimization boosts capacity of Korean olefins plant", Oil & Gas Journal, vol. 94, pp. 36, 1996. 3. K. Chin, "Maximize Profits Plantwide", Chem. Eng., vol. 105-3, pp. 143, 1998. 4. E. M. Rosen, L. R. Partin, "A perspective: The use of the Spreadsheet for Chemical Engineering Computations", Ind. Eng. Chem. Res., vol. 39, pp. 1612-1613., 2000. 5. W. D. Seider, J. D. Seader and D. R. Lewing, "Process Design Principles: Synthesis, Analysis, and Evaluation". John Wiley & Sons, Inc. 1999.