- Email: [email protected]
Concurrent Integrated Design of Process and Operating System
-C oncurrent Integrated Design of Process and -. Operating System D M Laing and J W Ponton Department of Chemical Engineering University of Edinburgh August 14, 1992 Abstract Resea.rchinto processes with improved operability has focussed on providing measures or indices, These are useful selecting between alternative designs, but are principally tools for analysis rather than synthesis. To achieve design for operability we generalise the established hierarchical model of process design to include the eoJ).trolsystem and operating policy. This procedure allows and encourages, exploration of both process and operating system alternatives. The latter include control in its broadest sense, development of an integrated operating strategy, and planning for expected constraints and varied demands. "
1
Introd uction
There is increasing pressure for process design to take more account of the demands of operation within a dynamic environment. Various methods have been developed to assess 'process operability', some focus on steady state feasibility [1], others on the dynamic limitations a process design imposes [2]. In general the appropriate formulation of such analyses requires soine knowledgeofthe intended control strategy. However within current 'design practice there is no suitable mechanism to provide this informati()n. To address process operability "properly we must consider the integrated design of the process and operating strategy. In proposing a framework for integrated design we follow the principles of hierarchical design already well established for proCeSS design [3]. Hierarchical design is process of stepwise refinement and decomposition of a design problem. At the early stages of design only outline structure "(e.g. major recycles) and general design properties (e.g. production rate) are considered. This phase leads to the definition of sub-designs (e.g. process sectioIls) of more detailed specification which are developed, as far as possible, independently of each other. This methodology helps to restrict the complexity of an individual design task to manageable levels. The discrete phases of refinement provide convenient junctures for process and control preferences to be negotiated. The principal limitation to hierarchical integration is the lack of a suitable hierarchical framework for the design of process control systems. In particular there is no comprehensive treatment that addresses control in its broadest sense, as an operating system to manage the process over its full regime of operation. In [4] a methodology is proposed for preliminary control analysis which while mentioning start-up and shut-down is not well suited for fully hierarchical development. In [5] the focus is on hierarchical design but focus sed purely on regulatory control structures, The rest of this paper will introduce a framework for hierarchical development of a process operating system.V\There appropriate we indicate how thisftamework facilitates the improved negotiation and integration between the process and control system design.
2
Classifying Modes of Process Operation
In hierarchical process design the hierarchy is the result of successive refinement and decomposition of the functions of process sections. In the development of the operating 87
system we employ operating modes in an analogous fashion to process sections. Each operating mode has a distinct combination of operational scope (the range of operation it is intended to manage) and process scope (the family of process units it is expected to manage). Operating modes may employ subsidiary modes to simplify their task. Operating modes may be .divided into three general classes according to their function . within the overall management of the process, viz. . . • Regulatory Modes: responsible for maintaining a process at a particular stationary state. • Transition Modes: required to manage the transition from one stationary state to another. • Executive Modes: Deeded to select the appropriate regulatory or transition mode according process state and active constraints. .
,Operating modes can be viewed as representing the strategic structure of an operating system. The following section illustrates how the range of operation can clarified by identifying the principal operating modes required.
3. Defining the Full Operating Regime An 'important aim for this framework is to address the full operating regime required from the process and operating system. It is intended to make the process engineer aware of the full range of demands that will be made of the process as early as possible indeed from the very begirming in the development of the design. While the process engineer is developing a set of preliminary fiowsheet options the 'operations engineer' can focus on defining the basic strategic modes of operation required. At its simplest level, operation involves at least two stationary states, off line and on line. We can associate two regulatory modes with these two stationary states. It is also necessary to introduce two transition modes to manage process startup and process shutdown. Finally, to determine which of these modes should be active, for example when it is necessary to initiate a shutdown, an executive mode is introduced. These. modes are a minimum requirement,it is not uncorp,mon to require special stationary states at which .the process could be held off line but close to its production conditions, a form of partial shut down. Startup and shutdown could then be managed in two steps; however for for shut ,down it may also be desirable to maintain a direct path to the cold off line state for extreme emergencies. Theresultinginitial design hierarchy is shown in figure 1. Thus from the very start of the design procedure we have achieved a more complete definition of the range of operation that must be dealt with than is normal considered in the definition of a process design .
.4
Functional Structure of Operating Modes
While the organisation of the operating modes defines the general structure of an operating strategy its detailed behaviour is dependent on the control algorithms employed to achieve its goals. To facilitate structured analysis and design of operating modes we defined a generic structure for operating modes which identifies the key functional elements of an operating mode. This structure is illustrated in figure 2 and hasJour primary elements, • Optimisation: Within all classes of operating mode safe, optimal oper(!.tionofthe system managed is the fundamental objective. • Identification: this is necessary where it is not possible to directly measure data required by the optimisation algorithm. . • Adaption: adaption of the strategic parameters of the optimiserprovides a mechanism for extending the operational range over which an operating mode may be employed. • Output Multiplexing: This system serves to transform the general operating targets derived by the optimiser into specific operating targets for each operating mode under that modes supervision .
By considering the development of the operating modes the need purpose of these four . . systems will be further clarified. 88
\ \
,, \
,,
\,....--..-~
,, ,, ,, ,,
,
\
Figure 1: Preliminary Structure of an Operating System
u
.------1 Yo
Control Multiplexing
Identification
•• •
Figure 2: Generic Structure of an Operating Mode
89
5
Development of Operating Modes
As the processfiowsheet develops in detail so .the operating modes initiallydefiiied must bed~veloped. In assessing and developing the design of an operating mode the operations . engineer must balance three principal factors. • Precision: Maintaining the process close to optimum is clearly desirable. . However trying to impose overprecise control may frequently be at the cost .of robustness and parsimony. • Robustness: Designs are limited by the aceuracy of the models available. and must have reason. able robustn~ to deal with unexpected events. • P8l'1Iimony:Excessive1y complex designsca,nbe difficult to implement and maintain. The balance between benefits of complexity and practicality can be difficult to resolve.
In balancing these issues in developing operating modes. the designer has two mechanisms: .algorithm refinement and mode decomposition . . By algorithm refinement as detail is ·addedto the process so .this .detail is inCorporated into the algorithm employed. within the operating mode. Decomposition of an operating mode involves the creation of new . subsidiary modeS each ·respqnsible for an exclusive subset of the original .scope of the . operating mode. These new modes do not replace the original·mode as this is still required to coordinate the subsidiary modes . .Decomposition may itself take two forms, viz. . • Process deco~position: The task of managing a set of units is diVided between new modes respon. sible for exclusive subsets of these units~ DUring design development it is convenient to use this to follow the development of the process hierarchy. . . ."
r-
5.1
• Operational decomposition: This is used when the operational scope of a mode is to broad to be easily encompassed within a single mode. The task of the operating mode is divided between modes _ with more focussed operational ranges. In this case the original operatin6 mode (which will be either a regulatory or transition mode) m\lstbe redefined as an executive mode that is responsible for selecting the appropriate active sub-mode.
Regulatory and Transition Modes
The general principles for the development of regulatory and transition modes arequite similar. In both cases the primary issue is to develop a strategy to counter disturbances while meeting operating tar.gets. In developing a mode we focus first on the formulation .of the optimisation. The following classes of information are associated with this formulation: • Objective Function: necessary for any optimisation and frequently incorporating penalty functions for operating targets that will be set for the operating mode. • Operating Targets: to specify desired values for specific process variables. These targets are passed down to the .mode from a supervisory mode and reflect a more generaloptimisation. These, however, are not hard constraints but guidelines for the mode. • Disturbance Sources: understanding these permits a more focussed optimisation strategy to be employed. Where little is known of the disturb(l.nce sources a more generaloptimisation strategy must be used requiring more conservative design. • System Constraints:
thes~
are hard constraints imposed by chemical and physical laws.
• Operating Restrictions: specify upper and lower bounds o~ particular process variables, based on ctiteria such as .safety and equipment limitations. These are distinct from system constraints since they are not physical restrictions on the behaviour of a process but constraints that must be . . protected by the operating system.
The above ·order is only a guideline to the order in which they should be addressed. Developing the detail on each is an opportunistitprocess. It is likely that the operations engin~r will be able to make use of d~si&n work alre~dy performed by the process engineer; who WIll have already completed prelimmary analYSIS flowsheet development and analysis. 90
At least simple models for .t he process will be available and some constrClints disturbanCe source .m ay be .already identified. 1n cOnSidering these specifications it is important to be aware of the level of design that is being addressed...In particular it is important to address distUrbances at the appropriate level of operating system hierarchy. We can identify two guidelines for this speci1ic case: 1. Magnitude: ' The effects of large disturban~ are harder to localise than thoSe of small,must thus be considered on a broader scale than small, and therefore be addressed at higher levels of the hierarchy. . 2. 'Timesca1e: At the .top of hierarchy the relevant information is available only on a longer timescaIe than .at lower levels. Top level modes tend to be more suited to long term planning, and lower levels to more immediate tactical problems. The hierarchy. th11S has a gradation of time scales: .,high levels address low frequencJ" disturban~ and low levels address high frequencies.
With some detail on the specifications for the optimisation it is possible . to formulate ,anoptimisation strategy. This ' involves selection of .appropriate decision variables, an appropriate algorithm for the actual optimisation and, in most cases, . the definition of subsidiary modes fot implementing the operating targets derived from the optimisation. As the process design develops it will become Clear that some of the information required · by an operating mode can not be directly acceSsed. Only a few of the disturbance source . may .b e measured directly and generally even then there is some form of transformation necessary to supply them in the correct form for the optimisation. The optimisation may be reformulated to use available information or to avoid excessive revision of a design an identification system maybe employed. ·In this context we refer to identification a broad sense. Identification is again a task which may be distributed through the system hierarchy. Consider an optimisation which requires an overall cost parameter for a separating system. This is passed on as an identification task to the operating'mode mailagingthe separation system. At this level the required property ~n be derived as a cumulative result of the individual costs for each cQlumn. Derivation of these column costs.is the province of each coluIl1n'sspecificoperating mode. An identification task is thus deferred until the latest stage at which the relevant information may be combined · Adaption is employed to extend the operational range over which an operating mode may be employed. For example by adapting the tuning of a simple controller it may be able to maintain acceptable control over a broader range of process behaviour. In the general sense by using adaption to adjust 'strategic' parameters of an optimisation algorithm we can extend its operational range. Adaption then is an alternative to operational decomposition. 5.2
Executive Modes
As discussed earlier executive modes arise from the operational decomposition of an operating mode. This is most common in the development of transition modes. Transition modes by their nature typically manage the process across a significant range of behaviour especially major transition modeS such as start up and shut down. It is quite common for such operations to be decomposed into stages or small steps and is the basis of operating . ' . procedure synthesis techniques [6]. . 'The executive mode has. in essence the same generic structure as transition and regu- . latory modes but its emphasis is slightly different. An executive mode must select the most appropriate mode of operation based on the active constraints and expected disturbances. Executive modes provide an construct for addressing operating restrictions as an integrated part of the operating system. The optimisation problem within an executive mode is thus more akin to a integer programming or logic problem. Also it may still require identification and adapti0n techniques though adaption will be less likely. .
91
6
Negotiation between Process and Operating System Design
To integrate the design of the operating system and the process effectively we need to establish a means for negotiation between these two aspects Qf plant design. The advantage of a hierarchical methodology is that the stepwise refinement provides convenient opportunities for such negotiati()n. · The focus in this negotiation is on balancing design requirements for the process and operatillg system against their respective cost and complexity. . . . . Consider a single phase of hierarchical development. · The proceSs engineer will have developed a range of design options. To reduce this range to eliminate the least attractive designs a rough costing will have been performed. The ·process engineer will now have a rough idea. of the optimal specification for the process design. . . For each design option that have been shQrt listed the operations engineer will refine the design of their operating systems. The knowledge 9f the operating requirements and operating strategy available to the him make it a simpler task to formulate appropriate . operability analyses Compared with what isno~ally known by a proCess engineer. This then enables the operations engineer to provide the process engineer with a more complete specification of the process design requirements. This may also help eliminate some of the ~design · options. . .
:
.
Conflicts will arise between the design preferences of the process and operations engineer. For example in planning ·.a strategy to eliminate interaction between two systems an intermediate storage tank maybe used. For feasible control the operations engineer may prefer a larger capacity than the process engineer feels is acceptable. A balance has to be struck between these two issues. Being able to put a cost on such conflicts, and here work such and [7] on ·quantifying the benefits of control is particularly valuable.
'7
Conclusions
To integrate the design of the process and operating system effectively we need to establish a means for negotiation between these two aspects of plant design. To facilitate this we have proposed a hierarchical framework for operating system design. The three claSses of operating mode set out in this framework p-e rmit process operation to be considered in its broadest sense. The ability to develop the operating system hierarchically in line with the process provides several benefits, • An operating system that reflects the intents of the process design. • More informed selection and formulation of operability analyses . • Reduced reliance on arbitrary design margins. • More effective utilisation of capital investment.
References [1] I E Grossman & R E Swaney, "An Index For Operational Flexibility in Chemical Process Design: Part 1," A. 1. Ch. E. Joilrnal31 (April 1985), 62L [2] Y Arkun, "Dynamic Process Operability: Important Problems, Recent Results, and New Challenges," in Chemical Process Control JII, Jan. 1986, 3.23. .
[3] J M Douglas, ConcepiualDesignof Chemical Processes, McGraw-Hill Book Company, 1988.
.
.
[4] J M Douglas, "Process Operability and Control of Preliminary Designs," in Chemical Process Control Il, 1982,487.
92
[5] J W Ponton & D M Laing,"A Hierarchical Approach to the Design of Process and . Control System," Ecosse Report 1991-05 (1991).
'{61 R Lajshinanan & GStephanopoulos, "Synthesis of Operating Procedures for CoI:Ilplete . Plants-I Hierarchical Structured Modeling for non-linear planning," Comp. & Cbem. . . Eng.12 (1988), 985. . . [7] T E Marlin, JD Perkins,.G W Barton & M .L Brisk, "Benefits from process control: .results of ajoint industry-university study~"J. Proc. Cont. 1 (1991),68. .
93
1
Introd uction
There is increasing pressure for process design to take more account of the demands of operation within a dynamic environment. Various methods have been developed to assess 'process operability', some focus on steady state feasibility [1], others on the dynamic limitations a process design imposes [2]. In general the appropriate formulation of such analyses requires soine knowledgeofthe intended control strategy. However within current 'design practice there is no suitable mechanism to provide this informati()n. To address process operability "properly we must consider the integrated design of the process and operating strategy. In proposing a framework for integrated design we follow the principles of hierarchical design already well established for proCeSS design [3]. Hierarchical design is process of stepwise refinement and decomposition of a design problem. At the early stages of design only outline structure "(e.g. major recycles) and general design properties (e.g. production rate) are considered. This phase leads to the definition of sub-designs (e.g. process sectioIls) of more detailed specification which are developed, as far as possible, independently of each other. This methodology helps to restrict the complexity of an individual design task to manageable levels. The discrete phases of refinement provide convenient junctures for process and control preferences to be negotiated. The principal limitation to hierarchical integration is the lack of a suitable hierarchical framework for the design of process control systems. In particular there is no comprehensive treatment that addresses control in its broadest sense, as an operating system to manage the process over its full regime of operation. In [4] a methodology is proposed for preliminary control analysis which while mentioning start-up and shut-down is not well suited for fully hierarchical development. In [5] the focus is on hierarchical design but focus sed purely on regulatory control structures, The rest of this paper will introduce a framework for hierarchical development of a process operating system.V\There appropriate we indicate how thisftamework facilitates the improved negotiation and integration between the process and control system design.
2
Classifying Modes of Process Operation
In hierarchical process design the hierarchy is the result of successive refinement and decomposition of the functions of process sections. In the development of the operating 87
system we employ operating modes in an analogous fashion to process sections. Each operating mode has a distinct combination of operational scope (the range of operation it is intended to manage) and process scope (the family of process units it is expected to manage). Operating modes may employ subsidiary modes to simplify their task. Operating modes may be .divided into three general classes according to their function . within the overall management of the process, viz. . . • Regulatory Modes: responsible for maintaining a process at a particular stationary state. • Transition Modes: required to manage the transition from one stationary state to another. • Executive Modes: Deeded to select the appropriate regulatory or transition mode according process state and active constraints. .
,Operating modes can be viewed as representing the strategic structure of an operating system. The following section illustrates how the range of operation can clarified by identifying the principal operating modes required.
3. Defining the Full Operating Regime An 'important aim for this framework is to address the full operating regime required from the process and operating system. It is intended to make the process engineer aware of the full range of demands that will be made of the process as early as possible indeed from the very begirming in the development of the design. While the process engineer is developing a set of preliminary fiowsheet options the 'operations engineer' can focus on defining the basic strategic modes of operation required. At its simplest level, operation involves at least two stationary states, off line and on line. We can associate two regulatory modes with these two stationary states. It is also necessary to introduce two transition modes to manage process startup and process shutdown. Finally, to determine which of these modes should be active, for example when it is necessary to initiate a shutdown, an executive mode is introduced. These. modes are a minimum requirement,it is not uncorp,mon to require special stationary states at which .the process could be held off line but close to its production conditions, a form of partial shut down. Startup and shutdown could then be managed in two steps; however for for shut ,down it may also be desirable to maintain a direct path to the cold off line state for extreme emergencies. Theresultinginitial design hierarchy is shown in figure 1. Thus from the very start of the design procedure we have achieved a more complete definition of the range of operation that must be dealt with than is normal considered in the definition of a process design .
.4
Functional Structure of Operating Modes
While the organisation of the operating modes defines the general structure of an operating strategy its detailed behaviour is dependent on the control algorithms employed to achieve its goals. To facilitate structured analysis and design of operating modes we defined a generic structure for operating modes which identifies the key functional elements of an operating mode. This structure is illustrated in figure 2 and hasJour primary elements, • Optimisation: Within all classes of operating mode safe, optimal oper(!.tionofthe system managed is the fundamental objective. • Identification: this is necessary where it is not possible to directly measure data required by the optimisation algorithm. . • Adaption: adaption of the strategic parameters of the optimiserprovides a mechanism for extending the operational range over which an operating mode may be employed. • Output Multiplexing: This system serves to transform the general operating targets derived by the optimiser into specific operating targets for each operating mode under that modes supervision .
By considering the development of the operating modes the need purpose of these four . . systems will be further clarified. 88
\ \
,, \
,,
\,....--..-~
,, ,, ,, ,,
,
\
Figure 1: Preliminary Structure of an Operating System
u
.------1 Yo
Control Multiplexing
Identification
•• •
Figure 2: Generic Structure of an Operating Mode
89
5
Development of Operating Modes
As the processfiowsheet develops in detail so .the operating modes initiallydefiiied must bed~veloped. In assessing and developing the design of an operating mode the operations . engineer must balance three principal factors. • Precision: Maintaining the process close to optimum is clearly desirable. . However trying to impose overprecise control may frequently be at the cost .of robustness and parsimony. • Robustness: Designs are limited by the aceuracy of the models available. and must have reason. able robustn~ to deal with unexpected events. • P8l'1Iimony:Excessive1y complex designsca,nbe difficult to implement and maintain. The balance between benefits of complexity and practicality can be difficult to resolve.
In balancing these issues in developing operating modes. the designer has two mechanisms: .algorithm refinement and mode decomposition . . By algorithm refinement as detail is ·addedto the process so .this .detail is inCorporated into the algorithm employed. within the operating mode. Decomposition of an operating mode involves the creation of new . subsidiary modeS each ·respqnsible for an exclusive subset of the original .scope of the . operating mode. These new modes do not replace the original·mode as this is still required to coordinate the subsidiary modes . .Decomposition may itself take two forms, viz. . • Process deco~position: The task of managing a set of units is diVided between new modes respon. sible for exclusive subsets of these units~ DUring design development it is convenient to use this to follow the development of the process hierarchy. . . ."
r-
5.1
• Operational decomposition: This is used when the operational scope of a mode is to broad to be easily encompassed within a single mode. The task of the operating mode is divided between modes _ with more focussed operational ranges. In this case the original operatin6 mode (which will be either a regulatory or transition mode) m\lstbe redefined as an executive mode that is responsible for selecting the appropriate active sub-mode.
Regulatory and Transition Modes
The general principles for the development of regulatory and transition modes arequite similar. In both cases the primary issue is to develop a strategy to counter disturbances while meeting operating tar.gets. In developing a mode we focus first on the formulation .of the optimisation. The following classes of information are associated with this formulation: • Objective Function: necessary for any optimisation and frequently incorporating penalty functions for operating targets that will be set for the operating mode. • Operating Targets: to specify desired values for specific process variables. These targets are passed down to the .mode from a supervisory mode and reflect a more generaloptimisation. These, however, are not hard constraints but guidelines for the mode. • Disturbance Sources: understanding these permits a more focussed optimisation strategy to be employed. Where little is known of the disturb(l.nce sources a more generaloptimisation strategy must be used requiring more conservative design. • System Constraints:
thes~
are hard constraints imposed by chemical and physical laws.
• Operating Restrictions: specify upper and lower bounds o~ particular process variables, based on ctiteria such as .safety and equipment limitations. These are distinct from system constraints since they are not physical restrictions on the behaviour of a process but constraints that must be . . protected by the operating system.
The above ·order is only a guideline to the order in which they should be addressed. Developing the detail on each is an opportunistitprocess. It is likely that the operations engin~r will be able to make use of d~si&n work alre~dy performed by the process engineer; who WIll have already completed prelimmary analYSIS flowsheet development and analysis. 90
At least simple models for .t he process will be available and some constrClints disturbanCe source .m ay be .already identified. 1n cOnSidering these specifications it is important to be aware of the level of design that is being addressed...In particular it is important to address distUrbances at the appropriate level of operating system hierarchy. We can identify two guidelines for this speci1ic case: 1. Magnitude: ' The effects of large disturban~ are harder to localise than thoSe of small,must thus be considered on a broader scale than small, and therefore be addressed at higher levels of the hierarchy. . 2. 'Timesca1e: At the .top of hierarchy the relevant information is available only on a longer timescaIe than .at lower levels. Top level modes tend to be more suited to long term planning, and lower levels to more immediate tactical problems. The hierarchy. th11S has a gradation of time scales: .,high levels address low frequencJ" disturban~ and low levels address high frequencies.
With some detail on the specifications for the optimisation it is possible . to formulate ,anoptimisation strategy. This ' involves selection of .appropriate decision variables, an appropriate algorithm for the actual optimisation and, in most cases, . the definition of subsidiary modes fot implementing the operating targets derived from the optimisation. As the process design develops it will become Clear that some of the information required · by an operating mode can not be directly acceSsed. Only a few of the disturbance source . may .b e measured directly and generally even then there is some form of transformation necessary to supply them in the correct form for the optimisation. The optimisation may be reformulated to use available information or to avoid excessive revision of a design an identification system maybe employed. ·In this context we refer to identification a broad sense. Identification is again a task which may be distributed through the system hierarchy. Consider an optimisation which requires an overall cost parameter for a separating system. This is passed on as an identification task to the operating'mode mailagingthe separation system. At this level the required property ~n be derived as a cumulative result of the individual costs for each cQlumn. Derivation of these column costs.is the province of each coluIl1n'sspecificoperating mode. An identification task is thus deferred until the latest stage at which the relevant information may be combined · Adaption is employed to extend the operational range over which an operating mode may be employed. For example by adapting the tuning of a simple controller it may be able to maintain acceptable control over a broader range of process behaviour. In the general sense by using adaption to adjust 'strategic' parameters of an optimisation algorithm we can extend its operational range. Adaption then is an alternative to operational decomposition. 5.2
Executive Modes
As discussed earlier executive modes arise from the operational decomposition of an operating mode. This is most common in the development of transition modes. Transition modes by their nature typically manage the process across a significant range of behaviour especially major transition modeS such as start up and shut down. It is quite common for such operations to be decomposed into stages or small steps and is the basis of operating . ' . procedure synthesis techniques [6]. . 'The executive mode has. in essence the same generic structure as transition and regu- . latory modes but its emphasis is slightly different. An executive mode must select the most appropriate mode of operation based on the active constraints and expected disturbances. Executive modes provide an construct for addressing operating restrictions as an integrated part of the operating system. The optimisation problem within an executive mode is thus more akin to a integer programming or logic problem. Also it may still require identification and adapti0n techniques though adaption will be less likely. .
91
6
Negotiation between Process and Operating System Design
To integrate the design of the operating system and the process effectively we need to establish a means for negotiation between these two aspects Qf plant design. The advantage of a hierarchical methodology is that the stepwise refinement provides convenient opportunities for such negotiati()n. · The focus in this negotiation is on balancing design requirements for the process and operatillg system against their respective cost and complexity. . . . . Consider a single phase of hierarchical development. · The proceSs engineer will have developed a range of design options. To reduce this range to eliminate the least attractive designs a rough costing will have been performed. The ·process engineer will now have a rough idea. of the optimal specification for the process design. . . For each design option that have been shQrt listed the operations engineer will refine the design of their operating systems. The knowledge 9f the operating requirements and operating strategy available to the him make it a simpler task to formulate appropriate . operability analyses Compared with what isno~ally known by a proCess engineer. This then enables the operations engineer to provide the process engineer with a more complete specification of the process design requirements. This may also help eliminate some of the ~design · options. . .
:
.
Conflicts will arise between the design preferences of the process and operations engineer. For example in planning ·.a strategy to eliminate interaction between two systems an intermediate storage tank maybe used. For feasible control the operations engineer may prefer a larger capacity than the process engineer feels is acceptable. A balance has to be struck between these two issues. Being able to put a cost on such conflicts, and here work such and [7] on ·quantifying the benefits of control is particularly valuable.
'7
Conclusions
To integrate the design of the process and operating system effectively we need to establish a means for negotiation between these two aspects of plant design. To facilitate this we have proposed a hierarchical framework for operating system design. The three claSses of operating mode set out in this framework p-e rmit process operation to be considered in its broadest sense. The ability to develop the operating system hierarchically in line with the process provides several benefits, • An operating system that reflects the intents of the process design. • More informed selection and formulation of operability analyses . • Reduced reliance on arbitrary design margins. • More effective utilisation of capital investment.
References [1] I E Grossman & R E Swaney, "An Index For Operational Flexibility in Chemical Process Design: Part 1," A. 1. Ch. E. Joilrnal31 (April 1985), 62L [2] Y Arkun, "Dynamic Process Operability: Important Problems, Recent Results, and New Challenges," in Chemical Process Control JII, Jan. 1986, 3.23. .
[3] J M Douglas, ConcepiualDesignof Chemical Processes, McGraw-Hill Book Company, 1988.
.
.
[4] J M Douglas, "Process Operability and Control of Preliminary Designs," in Chemical Process Control Il, 1982,487.
92
[5] J W Ponton & D M Laing,"A Hierarchical Approach to the Design of Process and . Control System," Ecosse Report 1991-05 (1991).
'{61 R Lajshinanan & GStephanopoulos, "Synthesis of Operating Procedures for CoI:Ilplete . Plants-I Hierarchical Structured Modeling for non-linear planning," Comp. & Cbem. . . Eng.12 (1988), 985. . . [7] T E Marlin, JD Perkins,.G W Barton & M .L Brisk, "Benefits from process control: .results of ajoint industry-university study~"J. Proc. Cont. 1 (1991),68. .
93