JP2017534984A - Apparatus and method for calculating proxy limits to support cascaded model predictive control (MPC) - Google Patents

Abstract

The method includes a step (1908) of receiving information from a slave MPC controller (304a-304n) at a master model predictive control (MPC) controller (302), wherein the information is a process variable of the slave MPC controller. Step (1908) is shown which indicates to what extent a plurality of manipulated variables can be changed in each of a plurality of directions (I706a-I706d, 1806) in the variable space without violating the constraints. The method also uses the information to estimate an executable region (1402, 1702, 1802) associated with the slave MPC controller (1912), wherein the executable region is a combination of manipulated variable values. Step (1912) is included to identify a portion of the variable space that satisfies the variable constraints. In addition, the method is a step (1914) of performing plant-wide optimization with a master MPC controller using the feasible region, so that the solution generated during plant-wide optimization is feasible. Step (1914) is included that includes one of the combinations of manipulated variable values in the region.

Description

CROSS REFERENCE TO RELATED APPLICATIONS AND PRIORITY CLAIM This application is a continuation of US patent application Ser. No. 14 / 336,888 filed Jul. 21, 2014, which is incorporated herein by reference in its entirety. Claims priority under Section 120 of the US Patent Act.

  The present disclosure relates generally to industrial process control and automation systems. More particularly, this disclosure relates to an apparatus and method for calculating proxy limits to support cascaded model predictive control (MPC).

  Processing equipment is often managed using industrial process control and automation systems. Many control and automation systems include multiple hierarchical layers that perform various functions. For example, the lower layer can include devices that perform process control functions and model predictive control (MPC) operations, while the upper layer can include devices that provide plant-wide optimization solutions.

  Ideally, control and plant-wide optimization will be designed as one, but how to provide decentralized control at a lower level and centralized optimization at a higher level simultaneously One problem arises. Distributed MPC solutions are often more desirable due to their operability and flexibility in dealing with process upsets, equipment failures, and maintenance. Centralized planning optimization is often more desirable because its high-level diagram removes branches or obscure details. However, one drawback of conventional control and automation systems is the lack of consistency of guaranteed solutions across multiple layers. In practice, plant-wide planning optimization is rare, even if implemented as part of a closed-loop control system. As a result, a significant amount of optimization profit remains out of reach.

  The present disclosure provides an apparatus and method for calculating proxy limits to support cascaded model predictive control (MPC).

  In the first embodiment, the method is a step of receiving information from a slave MPC controller at a master model predictive control (MPC) controller, wherein the information violates a process variable constraint of the slave MPC controller. And including a step indicating to what extent a plurality of manipulated variables can be changed in each of a plurality of directions in the variable space. The method also uses information to estimate an executable region associated with the slave MPC controller, where the executable region is a portion of the variable space for which the combination of manipulated variable values satisfies the process variable constraint. Identifying, including steps. In addition, the method includes the step of performing plant-wide optimization on the master MPC controller using the feasible region, so that the solution generated during plant-wide optimization is within the feasible region. Including a step including one of a combination of manipulated variable values.

  In a second embodiment, the apparatus includes a master MPC controller that includes at least one network interface and at least one processing device. The at least one network interface is configured to receive information from the slave MPC controller, and the information is in multiple directions in the variable space to what extent the slave MPC controller does not violate the process variable constraints of the slave MPC controller. Indicates whether a plurality of manipulated variables can be changed. At least one processing device is configured to use information to estimate an executable region associated with the slave MPC controller, where the executable region is a portion of a variable space in which a combination of manipulated variable values satisfies a process variable constraint Is identified. The at least one processing device is also configured to perform plant-wide optimization using the feasible region, and the solution generated during plant-wide optimization is the manipulated variable value in the feasible region. One of the combinations.

  In a third embodiment, the non-transitory computer readable medium embodies a computer program. The computer program stores information indicating to what extent the slave MPC controller can change a plurality of operation variables in each of a plurality of directions in the variable space without violating the process variable constraints of the slave MPC controller. Contains computer readable program code for receiving at the master MPC controller from the MPC controller. The computer program also includes computer readable program code for using information to estimate an executable region associated with the slave MPC controller, where the executable region is a variable space of which a combination of manipulated variable values satisfies a process variable constraint. Identify some. The computer program further includes computer readable program code for performing plant-wide optimization on the master MPC controller using the executable region, and the solution generated during plant-wide optimization is the executable region One of the combinations of the manipulated variable values.

Other technical features will be readily apparent to one skilled in the art from the following figures, detailed description, and claims.
For a fuller understanding of the present disclosure, reference is now made to the following detailed description, taken in conjunction with the accompanying drawings, in which:

1 illustrates an exemplary industrial process control and automation system in accordance with the present disclosure. FIG. FIG. 2 illustrates an exemplary planning and model predictive control (MPC) model used to support a cascaded MPC approach in an industrial process control and automation system according to the present disclosure. FIG. 2 illustrates an exemplary planning and model predictive control (MPC) model used to support a cascaded MPC approach in an industrial process control and automation system according to the present disclosure. FIG. 3 illustrates an exemplary cascaded MPC architecture for an industrial process control and automation system according to the present disclosure. FIG. 3 illustrates an exemplary cascaded MPC architecture for an industrial process control and automation system according to the present disclosure. FIG. 3 illustrates an exemplary cascaded MPC architecture for an industrial process control and automation system according to the present disclosure. FIG. 3 illustrates an exemplary use of proxy restrictions in a cascaded MPC architecture according to this disclosure. FIG. 3 illustrates an exemplary graphical user interface (GUI) for use with a cascaded MPC architecture in accordance with the present disclosure. FIG. 3 illustrates an exemplary technique for using contribution values and contribution costs with a cascaded MPC architecture in accordance with the present disclosure. FIG. 3 illustrates an exemplary base model for forming a planning model in a cascaded MPC architecture according to this disclosure. FIG. 3 illustrates an exemplary base model for forming a planning model in a cascaded MPC architecture according to this disclosure. FIG. 3 illustrates an exemplary base model for forming a planning model in a cascaded MPC architecture according to this disclosure. FIG. 4 illustrates an example technique for validating a planning model in a cascaded MPC architecture according to this disclosure. FIG. 3 illustrates an example technique for linking variables in a master MPC controller and a slave MPC controller in a cascaded MPC architecture according to this disclosure. FIG. 3 illustrates an exemplary technique for linking variables in a master MPC controller and a slave MPC controller in a cascaded MPC architecture according to this disclosure. FIG. 4 illustrates an exemplary method of using a cascaded MPC controller in an industrial process control and automation system according to the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPCs in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPCs in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPCs in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPCs in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPCs in accordance with the present disclosure. FIG. 6 illustrates an exemplary method for calculating proxy limits to support cascaded MPCs in accordance with the present disclosure.

  The various embodiments used to illustrate the principles of the present invention in FIGS. 1-19 described below, as well as in this patent document, are merely exemplary and the scope of the present invention in any form. Should not be construed as limiting. Those skilled in the art will appreciate that the principles of the invention may be implemented in any type of appropriately configured device or system.

  FIG. 1 is a diagram illustrating an exemplary industrial process control and automation system 100 in accordance with the present disclosure. As shown in FIG. 1, the system 100 includes various components that facilitate the production or processing of at least one product or other material. For example, the system 100 is used herein to facilitate control over components in one or more plants 101a-101n. Each plant 101a-101n corresponds to one or more processing facilities (or one or more portions thereof), such as one or more manufacturing facilities for producing at least one product or other material To do. In general, each plant 101a-101n may implement one or more processes and may be referred to individually or collectively as a process system. A process system generally represents any system or portion thereof that is configured to process one or more products or other materials in some way.

  In FIG. 1, the system 100 is implemented using a process control Purdue model. In the Purdue model, “level 0” may include one or more sensors 102a and one or more actuators 102b. Sensor 102 and actuator 102b represent components in the process system that can perform any of a wide variety of functions. For example, the sensor 102a can measure a wide variety of characteristics in the process system such as temperature, pressure, or flow rate. The actuator 102b can correct various characteristics in the process system. Sensor 102a and actuator 102b may represent any other or additional component in any suitable process system. Each of the sensors 102a includes any structure suitable for measuring one or more characteristics in the process system. Each of the actuators 102b includes any structure suitable for operating under or affecting one or more conditions in the process system.

  At least one network 104 is coupled to the sensor 102a and the actuator 102b. Network 104 facilitates interaction with sensor 102a and actuator 102b. For example, the network 104 can transmit measurement data from the sensor 102a and provide control signals to the actuator 102b. Network 104 may correspond to any suitable network or combination of networks. As a specific example, network 104 may correspond to an Ethernet network, an electrical signaling network (such as a HART or FOUNDATION Fieldbus network), an air control signaling network, or any other or additional type of network.

  In the Purdue model, “Level 1” may include one or more controllers 106 coupled to 104 in the network. Each controller 106 may specifically control the operation of one or more actuators 102b using measurements from one or more sensors 102a. For example, the controller 106 can receive measurement data from one or more sensors 102a and use the measurement data to generate control signals for one or more actuators 102b. Each controller 106 includes any structure suitable for interacting with one or more sensors 102a and controlling one or more actuators 102b. Each controller 106 is, for example, a multivariable controller such as a robust multivariable predictive control technology (RMPCT) controller, or a model predictive control (MPC), dynamic matrix control (DMC), or dynamic matrix control (DMC). It may represent Shell Global Solution Multivariable Optimization and Control (SMOC), or other types of controllers that implement other advanced predictive control (APC). As a specific example, each controller 106 may represent a computing device running a real-time operating system.

  The two networks 108 are coupled to the controller 106. The network 108 facilitates interaction with the controller 106, such as by exchanging data with the controller 106. Network 108 may correspond to any suitable network or combination of networks. As a specific example, network 108 corresponds to a redundant pair Ethernet network, such as a Fault Tolerant Ethernet (FTE) network from Honeywell International Inc. can do.

  At least one switch / firewall 110 couples network 108 to two networks 112. The switch / firewall 110 may carry traffic from one network to the other network. The switch / firewall 110 may also prevent traffic on one network from reaching the other network. The switch / firewall 110 includes any structure suitable for providing communication between networks, such as a Honeywell Control Firewall (CF9) device. The network 112 can correspond to any suitable network such as an FTE network.

  In the Purdue model, “Level 2” may include one or more machine level controllers 114 coupled to the network 112. The machine level controller 114 has various functions to support the operation and control of the controller 106, sensor 102a, and actuator 102b that can be associated with specific industrial equipment (such as a boiler or other machine). Fulfill. For example, the machine level controller 114 may create a log of information collected or generated by the controller 106, such as measurement data from the sensor 102a or control signals for the actuator 102b. The machine level controller 114 may also execute applications that control the operation of the controller 106 and thereby control the operation of the actuator 102b. In addition, the machine level controller 114 can provide secure access to the controller 106. Each of the machine level controllers 114 includes any structure suitable for providing access to one machine or other individual equipment, for controlling them, or for operations relating thereto. Each of the machine level controllers 114 may correspond to, for example, a server computing device that runs a Microsoft Windows operating system. Although not shown, various machine level controllers 114 may be used to control various instruments in the process system (in which case each instrument is 106, sensor 102a, And associated with the actuator 102b).

  One or more operator stations 116 are coupled to the network 112. The operator station 116 provides computing access to the machine level controller 114, thereby providing user access to the controller 106 (and possibly sensors 102a and actuators 102b). Corresponds to a communication device. As a specific example, operator station 116 allows a user to review the operational history of sensor 102a and actuator 102b using information collected by controller 106 and / or machine-level controller 114. be able to. Operator station 116 may also allow a user to adjust the operation of sensor 102a, actuator 102b, controller 106, or machine level controller 114. In addition, operator station 116 can receive and display warnings, alarms, or other messages or displays generated by controller 106 or machine level controller 114. Each operator station 116 includes any structure suitable to support user access and control of one or more components within the system 100. Each of the operator stations 116 may correspond to, for example, a computing device that runs a Microsoft Windows operating system.

  At least one router / firewall 118 couples network 112 to two networks 120. The router / firewall 118 includes any structure suitable for providing communication between networks, such as a secure router or a combined router / firewall. The network 120 may correspond to any suitable network such as an FTE network.

  In the Purdue model, “Level 3” may include one or more unit level controllers 122 coupled to the network 120. Each unit level controller 122 is typically associated with a unit in a process system that represents a collection of various machines that work together to implement at least a portion of a process. The unit level controller 122 serves various functions to support the operation and control of the components in the lower levels. For example, the unit level controller 122 creates a log of information collected or generated by the components in the lower level, runs an application that controls the components in the lower level, and goes to the components in the lower level. Secure access can be provided. Each of the unit level controllers 122 has any structure suitable for providing control to, or operation with, one or more machines or other equipment within a process unit. Including. Each of the unit level controllers 122 may correspond to, for example, a server computing device that runs a Microsoft Windows operating system. Although not shown, various unit level controllers 122 may be used to control various units within a process system (in which case each unit may include one or more machine level controllers 114). , Associated with controller 106, sensor 102a, and actuator 102b).

  Access to the unit level controller 122 may be provided by one or more operator stations 124. Each operator station 124 includes any structure suitable to support user access and control of one or more components within the system 100. Each of the operator stations 124 may correspond to, for example, a computing device that runs a Microsoft Windows operating system.

  At least one router / firewall 126 couples network 120 to two networks 128. This router / firewall 126 includes any structure suitable for providing communication between networks, such as a secure router or a combined router / firewall. The network 128 may correspond to any suitable network such as an FTE network.

  In the Purdue model, “level 4” may include one or more plant level controllers 130 coupled to the network 128. Each plant level controller 130 is typically associated with one of the plants 101a-101n, which may include one or more process units that implement the same, similar, or various processes. The plant level controller 130 performs various functions to support the operation and control of the components in the lower levels. As a specific example, the plant level controller 130 may execute one or more manufacturing execution system (MES) applications, scheduling applications, or any other or additional plant or process control applications. it can. Each of the plant level controllers 130 includes any structure suitable for providing control to, or operation with, one or more process units within a process plant. Each of the plant-level controllers 130 may correspond to, for example, a server computing device that runs a Microsoft Windows operating system.

  Access to the plant level controller 130 may be provided by one or more operator stations 132. Each of the operator stations 132 includes any structure suitable to support user access and control of one or more components within the system 100. Each of the operator stations 132 may correspond to, for example, a computing device that runs a Microsoft Windows operating system.

  At least one router / firewall 134 couples network 128 to one or more networks 136. The router / firewall 134 includes any structure suitable for providing communication between networks, such as a secure router or a combined router / firewall. Network 136 may correspond to any suitable network, such as an enterprise-wide Ethernet or other network, or all or part of a larger network (such as the Internet).

  In the Purdue model, “Level 5” may include one or more enterprise level controllers 138 coupled to the network 136. Each enterprise level controller 138 typically performs planning operations for multiple plants 101a-101n and can control various aspects of those plants 101a-101n. The enterprise level controller 138 also performs various functions to support the operation and control of the components in the plants 101a-101n. As a specific example, an enterprise-level controller 138 may include one or more order processing applications, enterprise resource planning (ERP) applications, advanced planning and scheduling (APS) applications, or other Or additional enterprise control applications can be run. Each of the enterprise level controllers 138 includes any structure suitable for providing control to, or related to, the operation of one or more plant controls. Each of the enterprise level controllers 138 may correspond to, for example, a server computing device that runs a Microsoft Windows operating system. In this document, the term “enterprise” refers to an organization having one or more plants or other processing facilities to be managed. Note that if one plant 101a is to be managed, the functionality of the enterprise level controller 138 can be incorporated into the plant level controller 130.

  Access to the enterprise level controller 138 may be provided by one or more operator stations 140. Each of the operator stations 140 includes any structure suitable to support user access and control of one or more components within the system 100. Each of the operator stations 140 may correspond to, for example, a computing device that runs a Microsoft Windows operating system.

  Various levels of the Purdue model can include other components such as one or more databases. The database associated with each level may store any suitable information associated with that level of system 100 or one or more other levels. For example, a historian 141 can be coupled to the network 136. The historian 141 can correspond to a component that stores various information about the system 100. The historian 141 can store information used, for example, during production scheduling and optimization. The historian 141 corresponds to any structure suitable for storing information and facilitating information retrieval. Although the historian 141 is shown as a single centralized component coupled to the network 136, it can be located elsewhere in the system 100, or multiple historians can be located in the system 100. Can be distributed to various locations within.

  In certain embodiments, the various controllers and operator stations in FIG. 1 may correspond to computing devices. For example, each of the controllers 106, 114, 122, 130, 138 is one or more processing devices 142 and one for storing instructions and data used, generated or collected by the processing devices 142. Or a plurality of memories 144 can be included. Each of the controllers 106, 114, 122, 130, 138 may also include at least one network interface 146, such as one or more Ethernet interfaces or wireless transceivers. Each of the operator stations 116, 124, 132, 140 may also have one or more processing devices 148 and one or more for storing instructions and data used, generated or collected by the processing devices 148. A plurality of memories 150 can be included. Each of the operator stations 116, 124, 132, 140 may also include at least one network interface 152, such as one or more Ethernet interfaces or wireless transceivers.

  Over the past decades, MPC has become a standard multivariable control solution for many industries. The widespread use of MPC has provided a solid foundation for more economically meaningful progress, namely the optimization of the entire closed-loop plant. However, there are many technical, workflow, and user experience challenges in trying to provide closed-loop plant-wide optimization for most industries. As a result, optimization of the entire open loop plant, commonly known as production planning, is still performed. In practice, plant-wide planning optimization is rare, even if implemented as part of a closed-loop control system. In fact, in many industries, planning results are often adjusted manually (and thus non-optimally) through intermediary means such as daily operator instructions. For this reason, a significant amount of manufacturing profit remains unobtainable.

  In some industries, intermediary solution layers such as open-loop production schedulers have been devised to divide production plans into smaller executable parts. This scheduler assists in converting the planning solution to operator action, but does not eliminate manual adjustments. In other industries, open loop production schedulers are used instead of production planning, but their output targets are often manually adjusted as well.

  The practice of manually adjusting the open loop solution is (i) disturbances to production inventory or product quality to meet lower level (possibly safety related) control constraints within the process unit. (In planning terminology, called “unexpected events”) is often due to the need to transform or review higher-level production targets. The technical difficulties associated with manual conversion largely coincide with the difficulties associated with integrating multi-level solutions using models at various scales.

  The present disclosure provides a cascaded MPC solution for plant-wide control and optimization that helps to provide plant-wide optimization as part of an automated control and automation system. As described below, the “master” MPC controller is configured to use a planning model, such as a single-period planning model, or other suitable reduced model as a seed model. The master MPC controller uses its optimizer to control production inventory, manufacturing activities, or product quality within the plant to achieve economic optimization of the entire plant. The master MPC controller is cascaded over one or more slave MPC controllers. A slave MPC controller can correspond to, for example, a controller at the unit level (level 3) of the system, and each slave MPC controller provides its operating state and constraints to the master MPC controller. For this reason, the plant-wide optimization solution from the master MPC controller can comply with all unit level operating constraints from the slave MPC controller. Together, the MPC cascade provides both decentralized control (such as at the unit level) and centralized plant-wide optimization (such as at the plant level) simultaneously in one consistent control system. The phrase “plant-wide optimization” or “plant-wide control” refers to whether multiple units in an industrial facility correspond to any unit in the industrial facility. Rather, optimization or control.

  In this way, the MPC cascade solution allows the embedded real-time planning solution to comply with lower level operating constraints. By cross-levering both planning and control models online, the MPC Cascade Solution can perform a “retreat horizon” form of planning optimization in a closed-loop control system in real time. Enable. The MPC cascade solution can be used to automatically execute a just-in-time production plan, especially through its slave MPC controller. The formula for backward horizon planning optimization in the master MPC controller is that of planning optimization in a single period, but usually in its shortened time horizon, such as the range of 1 to 14 days, as used in offline planning tools. It can be the same as or the same as the formula.

  The rest of the description in this patent document is divided as follows. A multi-scale model that can be used in the context of industrial process control and automation is described, and an MPC cascade solution using the multi-scale model is provided. A conduit for merging multi-scale models is described in the form of proxy restrictions, providing a multi-scale solution for enhancing the user experience. In addition, the use of contribution values and contribution costs is disclosed as a way to cast the central economic objective function to intermediate stream prices / expenses, and model structures that can be used in certain systems using MPC cascade solutions are described. Is done. Finally, model validation techniques are provided, techniques for dealing with master-slave variables in MPC cascade solutions are disclosed, and techniques for estimating feasible regions where industrial processes can be tuned are provided.

  Although FIG. 1 illustrates one example of an industrial process control and automation system 100, various changes may be made to FIG. For example, the control and automation system can include any number of sensors, actuators, controllers, servers, operator stations, networks, and other components. Also, the configuration and arrangement of the system 100 in FIG. 1 is merely exemplary. Components can be added, excluded, combined, or arranged in any other suitable configuration according to particular needs. Further, specific functions are described as being performed by specific components of system 100. This is merely an example. In general, the control and automation system is highly configurable and can be configured in any suitable manner according to the needs of the characteristics. In addition, FIG. 1 illustrates an exemplary environment in which an MPC cascade solution can be used. This functionality can be used in any other suitable device or system.

Multi-scale model Consider an industrial plant with multiple units. At a higher level, an overall material, component, and energy balance between all process units needs to be established. At the lower level, each unit needs to be properly controlled to ensure safety in the plant and smooth and efficient operation of the unit.

  Planning and MPC models are examples of multi-scale model sets that can be used to solve multi-level problems in cascaded MPC architectures. 2A and 2B illustrate exemplary planning and MPC models used to support cascaded MPC approaches in industrial process control and automation systems according to this disclosure. Specifically, FIG. 2A represents a planning model 200 based on yield and FIG. 2B represents an MPC model 250.

  As shown in FIG. 2A, the planning model 200 generally converts one or more input streams 204 of feed material into one or more output streams 206 of processed material. A plurality of units 202 are identified that operate to convert. In this example, unit 202 represents a component in an oil and gas refinery that converts one input stream 204 (crude oil) into multiple output streams 206 (various refined oil / gas products). Various intermediate products 208 are created by the unit 202 and one or more storage tanks 210 may be used to store one or more of the intermediate products 208. As shown in FIG. 2B, the MPC model 250 identifies multiple components 252 of a unit. Various valves and other actuators 254 can be used to coordinate operation within the unit, and various APCs and other controllers 256 can be used to control the actuators within the unit.

  In general, the planning model 200 corresponds to individual units on a coarse scale because the entire plant (or a part thereof) is viewed in a “bird's eye view”. The planning model 200 focuses on unit production within the plant, product quality, material balance and energy balance, and steady state relationships between units associated with manufacturing activities. The planning model 200 is usually (but not necessarily) composed of a process yield model and product quality characteristics. The planning model 200 may be constructed from a combination of various sources, such as planning tools, scheduling tools, yield verification tools, and / or historical operational data. However, the MPC model 250 corresponds to at least one unit on a finer scale. The MPC model 250 is a unit between a control variable (CV), an operation variable (MV), and a disturbance variable (DV) associated with a safe, smooth, and efficient operation of the unit. Focus on internal dynamic relationships. The time scales of the two models 200, 250 are also different. The MPC model time horizon is typically in the range of minutes to hours, while the planning model time horizon is typically in the range of days to months. A “control variable” generally represents a variable whose value is controlled such that its value is at or near a set value or within a desired range, while an “operating variable” generally represents the value of at least one control variable. Note that it represents a variable that is adjusted to correct. A “disturbance variable” generally represents a variable whose value is considered but may not be controlled or adjusted.

  The planning model 200 can and should exclude non-production related or non-economic related variables such as pressure, temperature, tank level, and valve opening inside each unit. . Instead, the planning model 200 can simplify one process unit into one or several material or energy yield vectors. On the other hand, the MPC model 250 typically includes all of the operating variables for control to help ensure safe and efficient operation of the unit. As a result, the MPC model 250 includes more variables for one unit than the planning model 200. As a specific example, an MPC model 250 for an oil refinery fluidized catalytic cracking unit (FCCU) may include about 100 CV (output) and 40 MV (input). The same unit planning model 200 can focus only on the important causal relationship between raw material quality and operating mode (as inputs) and FCCU product yield and quality (as outputs), so that the planning model 200 is Can have as few as 3 or 4 inputs and 10 outputs. This variable difference has traditionally been an obstacle to effectively integrating multi-level solutions. The additional differences are summed in Table 1 below, which compares the normal focus of the two models 200, 250.

  There are several advantages of using the coarse scale planning model 200. For example, the economic optimization of the entire plant can be formulated compactly and clearly using the planning model 200 without entanglement with possibly obscure details within any one process unit. Also, a split-governance approach can be employed to first solve the high-level optimization problem and then find a way to inherit the solution to each unit.

  The compact and robust planning model 200 allows planning problems to be easily set up, clearly displayed and quickly solved, but it comes with drawbacks, ie, the visibility of detailed variables within any unit. There is no waste. Many of these specific variables may have little to do with high-level production planning, but a small subset is usually associated with it. If planning model 200 has no visibility inside any lower level units, this model will ensure that the solution adheres to the lower level constraints of all units, whether optimal or not. There is no guarantee that This means that traditional planning solutions often need to be manually converted or reconsidered to take into account internal unit operating constraints, and significant margins can be lost during the conversion This is one reason. The same is true for the scheduling solution if it uses a planning model 200 based on yield at a coarse scale.

  From an overall perspective, the optimization or control problem formulated in the planning model 200 based on higher level yields can benefit from the lower level MPC model 250. The rationale is that the details used to ensure constraint satisfaction within the unit are not already organized into the proper model form, but are usually already in the unit's MPC model 250. is there. Ideally, the MPC model 250 can be used to supplement the unit constraint details for planning as needed. The cascaded MPC approach described below is effectively used by the MPC model to provide lower level fine scale model information to an upper level coarse scale plant-wide optimization or control formulation. Provide a structural framework that can. The cascaded MPC approach described below can utilize this planning model 200 and MPC model 250 to provide this functionality.

Cascaded MPC solutions using multiscale models From a plant-wide perspective, control and planning are often combined. Planning usually relies on control to establish a feasible area for optimization, while control usually adjusts the unit and operates the entire plant at the operating point where it can most benefit. Rely on planning. Thus, planning often relies on MPC controllers that force constraints within each unit to create a larger feasible area for plant-wide optimization. MPC controllers, on the other hand, do planning before knowing which constraints are really plant-wide failures and therefore need to be pushed out, and which constraints are not invalid and may remain invalid. Often depends on guidance from. Therefore, these two solution layers are mutually dependent and need to be handled at the same time.

  One way to solve this coupling problem is to design control and plant-wide optimization together. Since each MPC controller has an embedded economic optimizer, one large plant-wide MPC controller can be devised that performs both plant-wide optimization and unit-level MPC control. However, such an uncompromising MPC solution has various drawbacks. One challenge with any integrated design approach is the simultaneous provision of distributed control at the lower level and centralized optimization at the higher level.

  3A-3C illustrate an exemplary cascaded MPC architecture 300 for an industrial process control and automation system according to this disclosure. As shown in FIGS. 3A and 3B, the cascaded architecture 300 includes a master MPC controller 302 and one or more slave MPC controllers 304a-304n. Slave MPC controllers 304a-304n interact with one or more regular process controllers 306a-306m associated with one or more processes 308a-308n in the plant. Slave MPC controllers 304a-304n may represent level 3 controllers, while process controllers 306a-306m may represent level 2 controllers. The plant's retainer 310 may include level 1 controllers, sensors, actuators, and other lower level components. Master MPC controller 302 generally operates within a master control loop, while each slave MPC controller 304a-304n generally operates within a slave control loop. There may be one or more slave control loops within a single master control loop.

  Each MPC controller 302, 304a-304n supports economic optimization and multivariable control functions. The master MPC controller 302 uses the planning model 200 (such as a single period planning model based on yield) to provide an initial steady state gain matrix, and the associated model dynamics provide plant operating data (such as historical data). Can be determined using. Master MPC controller 302 operates to control production inventory, manufacturing activities, or product quality within the plant. Thus, the embedded economic optimizer of the master MPC controller 302 with the same planning model structure and economy can reproduce the single-period offline planning optimization, but in an online real-time method. .

  The master MPC controller 302 is cascade-connected on n slave MPC controllers 304a to 304n (n is an integer value of 1 or more). Slave MPC controllers 304a-304n provide master MPC controller 302 with future predictions and operating constraints for each unit of the plant. With this information, the real-time planning solution from the cascaded architecture 300 alleviates or eliminates the above-mentioned drawbacks. Integrally, the MPC controllers 302, 304a-304n are all in one consistent cascaded control system, with distributed control at the lower level with the fine scale MPC model 250 and higher level with the coarse scale planning model 200. Brings about optimization of the entire centralized plant at the same time.

  Another reason that production plans often need to be manually converted into a set of operating instructions is the time that open loop planning solutions typically range from a few days to a month (in one period). It has horizons and this solution is usually run only once a day or once every few days. Thus, it lacks an effective feedback mechanism to address uncertainties such as changes in raw material quality or ambient conditions, process unit malfunctions, heating or cooling capacity limits, and maintenance. To help deal with these situations, an optimizer is embedded in the master MPC controller 302, which optimizes at a user-defined frequency, such as a frequency ranging from once every few minutes to once every hour. Can be executed. Both the production quantity and product quality of each unit can be measured or estimated at that frequency, and the prediction error can be bias corrected in the master MPC controller 302 as any standard MPC. If a deviation from the original optimal plan is detected, re-optimization of the entire plant can be performed immediately. New optimal production targets are then sent to and executed by the slave MPC controllers 304a-304n, reducing or eliminating the need for manual conversion or adjustment.

  Certain optimization situations can also be modified from conventional MPC optimization situations to gain additional benefits in real time. Some similarities and differences between conventional MPC approaches and cascaded MPC solutions may include:

• The objective function can remain the same as applicable for offline planning.
The time horizon in the master MPC controller 302 can be an online tuning parameter, such as in the range of hours to days or weeks, and is shorter than the time horizon used in offline (particularly multi-period) planning. be able to.

  Tuning can be set to gain more profit in the form of just-in-time manufacturing. The points to note for tuning are (for example) how far ahead the product pre-orders are set, product order variability (in both quantity and grade), what additional purchase / sales opportunities can be pursued, Finishing components may include whether they can be exchanged with trading partners or purchased / sold in the spot market.

Production inventory and product quality can be dynamically controlled using real-time measurement feedback.
Product orders in the time horizon range are known, as opposed to being estimated for offline equivalents. The master MPC controller 302 can create a just-in-time production plan as opposed to a plan based on a hypothetical order.

  The planning model 200 used in the master MPC controller 302 can be updated in real time using a yield verification mechanism associated with the slave MPC controllers 304a-304n. After cross-validation (such as with respect to measurement error), the measured yield can be used to update the planning model 200, and the master MPC controller 302 can provide a more accurate and useful production. A plan can be generated.

  Cascaded architecture 300 provides a control hierarchy diagram 350 as shown in FIG. 3C. The cascaded architecture 300 breaks the dividing line in conventional control and automation systems by taking a copy of the planning model 200 and adding it to the MPC controller, adding delays and ramps. The unit supply can be used as MV, and the production inventory can be used as CV in the master MPC controller 302. The master MPC controller 302 is a real-time plan executor that understands the overall picture from the planning model 200 and uses the MPC model 250 per unit for advanced process control. Thus, the master MPC controller 302 can optimize the plant in cooperation with the slave MPC controllers 304a-304n to generate the best achievable plan while complying with all unit constraints.

  The planning model 200 used by the master MPC controller 302 has two parts: (i) a dynamic model for MPC control, (ii) a steady state model for economic optimization (in the steady state part of the dynamic model). A). Master MPC controller 302 takes advantage of MPC feedback to improve the accuracy of offline planning optimization, thereby incorporating real-time information that was previously unavailable so that it is closer to the original plan as understood in real time. Reproduce offline planning optimization. The dynamics of the master MPC controller model 200 can be determined from plant operating data, and the master MPC controller 302 can provide the desired inventory / characteristic control in a closed loop. Since the control and optimization solution from the master MPC controller 302 observes the operating constraints from the slave MPC controllers 304a-304n, this allows the master MPC controller 302 to run in a closed loop, and the MPC cascade Enable. This is done while providing both centralized compact plant level optimization and unit level distributed MPC control.

  The multi-variable control functionality of the master MPC controller 302 can correspond to a certain type of production controller, or an inventory controller that uses inventory levels as its primary CV (“inventory” is used herein to refer to the current state , And refers to the cumulative amount of material / energy / etc. In the anticipated future state or both). Each unit change amount (or MV) is configured directly through the master MPC controller 302, indirectly through the slave MPC controllers 304a-304n, or indirectly through the process controllers 306a-306m (such as RMPCT controller). Can be done. Each slave MPC controller 304a-304n can predict "room" within the amount of change for each unit (via proxy restrictions described below), and the master MPC controller 302 cannot be accepted by the unit. You can refrain from requesting changes. The master MPC controller 302 may further include a CV for material / energy balance (model / constraint).

  Master MPC controller 302 includes any structure suitable for performing economic optimization operations using a planning model. The master MPC controller 302 corresponds to, for example, a single-input single-output (SISO) controller, a multiple-input multiple-output (MIMO) controller, or a controller having a number of inputs and outputs. can do. Each slave MPC controller 304a-304n includes any structure suitable for interacting with a master MPC controller. Each slave MPC controller 304a-304n may correspond to, for example, a SISO controller, a MIMO controller, or other controller with a number of inputs and outputs.

Proxy Restriction Master MPC controller 302 is an independent MPC controller that uses a reduced model. Because the master MPC controller 302 cascades across the slave MPC controllers 304a-304n, the master MPC controller 302 complies with the constraints of the slave controllers 304a-304n, otherwise the entire combined solution is implemented. It may not be optimal or even feasible. To help avoid this situation, proxy restrictions are used to merge multiscale models. Proxy restrictions are an alternative representation of the constraints of a slave MPC controller in the master MPC controller space. Proxy restrictions may be displayed as a conduit between an individual slave MPC controller and the master MPC controller to “transfer” the constraints of the slave MPC controller to the master MPC controller. Proxy restrictions from multiple slave MPC controllers 304a-304n may be combined and included in master MPC controller control and economic optimization formulas.

  Proxy limits may be displayed in the MV space of the master MPC controller 302, but their boundary values may be calculated in the MV space of the slave MPC controllers 304a-304n. For each MV of the master MPC controller 302, each of its downstream slave MPC controllers predicts the distance that one or more slave CVs or MVs can move before they reach their operating limits. be able to. If more than one MV from the master MPC controller 302 is associated with the slave MPC controllers 304a-304n, the proxy limit may be multivariate in nature.

  FIG. 4 illustrates an exemplary use of proxy restrictions in a cascaded MPC architecture according to this disclosure. Specifically, FIG. 4 illustrates an exemplary use of proxy restrictions in a cascaded architecture for FCCUs where one proxy restriction is sufficient to represent the entire unit. It is assumed that the FCCU raw material is configured as MV4 in the planning model 200 for the master MPC controller 302 and as MV9 in the MPC model 250 for the slave MPC controller 304a. Also assume that the current supply to the unit has a value of 33.5. In addition, slave MPC controller 304a may provide a supply of 38.1 before one or more slave CVs and / or MVs reach one or more limits, as shown in table 402. Assume that it is predicted that it can be increased to the maximum value. Table 402 herein shows the various CVs controlled by slave MPC controller 304a and the various MVs used by slave MPC controller 304a to control those CVs. A maximum boundary value of 38.1 is accepted by the master MPC controller 302 and used as a high proxy limit for MV4 of the master MPC controller.

  Regardless of how many slave constraints in each unit can limit the MV (unit supply, etc.) of the master MPC controller, only the master MPC controller 302 should stop forcing the MV. (Otherwise, some lower level constraint violations may occur). This stopping point is consistent with the proxy limit, which corresponds to the entire set of valid slave constraints in the corresponding lower level unit that can limit the MV of the master MPC controller. In the specific example above, multiple proxy restrictions may also be used, but only one proxy restriction is required for all slave constraints in the lower level FCCU unit.

  One feature of proxy restrictions is that all slave MPC constraints in a unit can be made one or several proxy restrictions, removing unnecessary elements. Therefore, the proxy restriction functions as a bundling mechanism for holding the coarse scale model 200 in the master MPC controller 302 as it is while effectively merging it with the fine scale slave MPC model 250. In other words, this translates the plant-wide optimization problem within the master MPC controller 320 into its original compact planning without allowing the coarse scale model 200 to be expanded to a compatible fine scale model. Allows you to keep it in a form.

  With the help of proxy restrictions, an integrated optimization solution that uses a cascaded MPC approach offers various benefits. For example, the embedded real-time planning solution complies with unit level operating constraints in the slave MPC controllers 304a-304n, and the master MPC controller 302 uses the same set of variables (such as inventory or quality) that the offline planning tool is expected to manage in an open loop. ) Dynamically. Virtually all relevant MPC constraints in the unit are removed in unnecessary elements and made into one or more proxy restrictions, which in turn will be included in the optimization of the master MPC controller. In addition, proxy restrictions make multi-layer optimization more noticeable than a single layer. Furthermore, the manual adjustment or conversion practices of open loop optimization solutions can be reduced or eliminated. By cross-utilizing both the planning model and the control model online, the cascaded MPC approach allows the entire plant optimization within the closed loop control system to be performed in real time. Thus, the cascaded MPC approach simultaneously provides centralized optimization with a coarse scale planning model 200 at the plant level and distributed control with a fine scale MPC model 250 at the unit level.

  Note that the concept of MPC cascading with proxy restrictions has been described as being done with a level 3 MPC controller as a slave controller. However, this concept can be used at various levels of control and automation systems or can extend to those levels. For example, a master MPC controller in multiple cascaded architectures 300 in a plant can form a slave MPC controller relative to a plant level master MPC controller. As a specific example, a plant level master MPC controller for an oil / gas refinery can use a simple yield vector (crude oil as one input raw material, refined product as multiple output raw materials). Similarly, multiple plant level master MPC controllers may function as slave MPC controllers relative to enterprise level master MPC controllers. As a specific example, if different refineries are involved in different markets, an enterprise-level master MPC controller across multiple refineries can be based on local product demand / supply and the capacity of each refinery. The overall optimal value can be calculated in real time.

Multi-scale solution to enhance user experience Because the cascaded MPC architecture 300 uses a set of models, the planning model 200 naturally has a graphical user interface (GUI) with a clear bird's-eye view of the plant. ) Can be used. FIG. 5 illustrates an exemplary GUI 500 for use with a cascaded MPC architecture in accordance with this disclosure. The GUI 500 includes various icons 502 that identify various units 202 within the planning model 200. The master MPC controller 302 can provide various information in the GUI 500. For example, the master MPC controller 302 provides unit production, available inventory, planned product shipments, cost structure, gross margins, each unit's contribution to that margin, and other relevant information associated with real-time execution of the production plan. can do.

  The master MPC controller 302 also allows the operator to easily identify within the GUI 500 which units are faults in the plant by looking at the proxy limits of those units. For a unit 202 with at least one valid proxy limit, this is an overall obstacle, such as when the unit's throughput is actually constrained by lower level constraints within its slave MPC controller. These units can be identified graphically using an indicator 504 such as a colored circle in the GUI 500 that provides a clear “clear” view. The marginal profit value is optionally displayed next to each faulty unit and can indicate the increase in profit that the plant can achieve if the unit throughput is increasing.

  An operator (such as a production manager or planner) can use the GUI 500 to drill down to a faulty unit. For example, when a particular icon 502 is selected in the GUI 500, the MPC model 250 for the selected unit 202 may be displayed to the operator. The displayed MPC model 250 corresponds to a GUI of a slave MPC controller that indicates an effective constraint that currently limits the production throughput of the unit. When a particular controller is selected in MPC model 250, table 402 may be displayed to the operator.

  Variables in table 402 that are currently valid as constraints (due to equipment or maintenance issues, etc.) can be identified using indicators 506 (such as colored circles). Once a particular variable in table 402 is selected by the operator, a maintenance GUI 508 or other interface may be presented to the operator. For example, the operator can select a valve constraint and display a maintenance GUI 508 for that valve. The maintenance GUI 508 can indicate that the valve is scheduled for maintenance in two weeks. Similar to the master MPC controller 302, the slave MPC controllers 304a-304n can increase the profit that the plant can achieve if the constraints are removed (thus, this time will help increase throughput). Can be displayed next to each active constraint in the table 402.

  In complex installations there are usually a line of actuators and other equipment that needs to be addressed at any given time. Maintenance personnel often do not have adequate guidance to prioritize their maintenance work. The same is true for APC maintenance and other maintenance inspection work. In the method shown in FIG. 5, each maintenance task can be tagged with an increased profit, and the work list can be easily sorted by profit impact rather than by service request time. Failures are often caused by simple maintenance problems at the unit. Items that affect some benefits may be left unrepaired for a long time because no one knows the price of not repairing those items. In the case of a multi-layer control system GUI, maintenance work can be easily sorted by their economic impact and a new economic-centric automated maintenance inspection framework can be established.

Contribution Value and Contribution Cost Referring back to FIG. 2A, as indicated above, the process unit 202 shown in the planning model 200 generally produces one or more input streams while creating various intermediate products 208. Operate to convert 204 into one or more output streams 206. The master MPC controller 302 or the slave MPC controllers 304a to 304n can use the contribution value and / or contribution cost when performing their control or optimization operations.

  Each contribution value may be associated with an intermediate product that is used to produce one or more final products, where the final product corresponds to a product produced by the process system. A contribution value can be calculated using each intermediate product and its contribution to the price of each final product. In some embodiments, the contribution value of the intermediate product is calculated as follows.

Here, n represents the number of final products that can be produced using the intermediate product. Also, Contribution _i represents the percentage of intermediate products dedicated to producing the i th final product, and ProductPrice _i represents the predicted or current market price for the i th final product. Furthermore, FurtherProcessingCost _i represents additional processing costs required to produce the i th final product (optionally may be omitted or set to zero).

  In other embodiments, the contribution value of the intermediate product is calculated as follows.

Here, the product price for the i th final product may be adjusted to make corrections for various overproduction and underproduction scenarios, or other situations. For example, if the planned production volume of the i th final product exceeds that plan, the price of the final product can be lowered considering storage costs and future order risk. If the planned output of the i-th final product is below that plan, the price of the final product can be increased if there is a penalty for not meeting the deadline of the order.

  It should also be noted that various adjustments can be made to the contribution value. For example, if storage is possible, the normally expensive intermediate product is stored and retained for the next planning period (rather than lowering its contribution over the current period). As another example, if an excess of intermediate product can be sold in the spot market, a higher contribution value can be assigned to the intermediate product. Furthermore, it should be noted that the contribution values can be tied together for the current planning period and for the next planning period, and can help to reduce the undesirable reduction of the horizon effect at the end of the current period. .

  Each contribution cost may be associated with an intermediate product that is produced using one or more raw material products (a raw material product represents a material that is input into the process system). The contribution cost can be calculated using the use of that raw product for each raw material product and the price of each raw material product. In some embodiments, the contribution cost of the intermediate product is calculated as follows:

Here, m represents the number of raw material products used to produce the intermediate product. Also, Contribution _i represents the percentage of the i-th raw material product dedicated to producing the intermediate product, and FeedCost _i represents the predicted or current market price for the i-th raw material product. Furthermore, UpstreamProcessingCost _i processes the i-th raw product, represents a processing cost required to produce an intermediate product (optionally may be set may be omitted, or zero).

  In other embodiments, the contribution cost of the intermediate product is calculated as follows:

Here, the cost for the i-th raw material product can be adjusted to make corrections for various overproduction and underproduction scenarios, or other situations. For example, if the planned inventory of an i-th raw material product exceeds its planned or storage capacity, its adjusted cost can be reduced to facilitate consumption. If the planned inventory of the i th raw material product falls below its planned or storage capacity, its adjusted cost can be increased to reduce consumption. It should also be noted that various adjustments can be made to the contribution costs. For example, if the adjusted cost of a raw material product is higher than its spot market price, “in-house vs. external procurement” to determine whether it is more economical to purchase an intermediate product instead of producing it. Analysis can be used.

  FIG. 6 illustrates an exemplary technique for using contribution values and contribution costs with a cascaded MPC architecture according to this disclosure. In this example, the master MPC controller 302 converts (i) contribution values and contribution costs based on data from its planning model, its economics, and previous iterations to (ii) contribution values and contribution costs and proxy values. Operate to iteratively identify the yield of predictions based on it. Contribution values and contribution costs can be provided to slave MPC controllers for their local optimization needs. Once an optimal solution (such as an optimized plan) is found, the master MPC controller 302 provides optimized economy to the slave MPC controllers 304a-304n. Additional details regarding the operation of the master MPC controller 302 in connection with using contribution values can be found in US Patent Application Publication No. 2011/0040399, which is incorporated herein by reference in its entirety.

Exemplary Planning Model Structure In some embodiments, the planning model 200 for the master MPC controller 302 may be formed using one or more base models. For example, two base models (processing unit model and pool tank model) can be provided in forming the planning model. The processing unit may be modeled as one or more input raw materials and one or more output raw materials. Pool tanks can be modeled as mixed tanks or unmixed (storage only) tanks. Note that other or additional base models may be used, depending on the implementation.

  FIGS. 7-9 illustrate an exemplary base model for forming a planning model in a cascaded MPC architecture according to the present disclosure. 7 and 8 show an exemplary model for the processing unit, and FIG. 9 shows an exemplary model for the pool tank.

  As shown in FIG. 7, the following transfer function can be used for mass balance between one input raw material and multiple output products.

Here, y _i is the base yield for the i-th product, and Δy _i is a vector (of m ₁ elements). Also,

Where vg is the volume gain, where

This model format matches the structure commonly used in planning models. Strictly speaking, this model form is not a linear model such that it has linear dynamics at second-order gain. The model has one input raw material per unit, and each characteristic of the output product has a time constant and delay similar to the product draw. Table 2 shows a steady state gain matrix for one raw material flow that can naturally span multiple raw materials using the same approach.

  As shown in FIG. 8, the following transfer function can be used to convert the i th characteristic of the input raw material to the i th characteristic of the j th product.

Where G _cj is a vector (m ₂ elements) and G ⁰ _J is a “pass” DV gain. This approach assumes that each characteristic of the product has a time constant and delay similar to the product draw, and that each characteristic can be set to the same value by initialization. This approach also assumes that the characteristics can be influenced (or controlled) by the MPC controller. Table 3 shows a steady state gain matrix for both the material flow and properties of one raw material, although it is possible to naturally span multiple raw materials again using the same approach.

  Various techniques can be used to obtain the dynamics of the processing unit model defined in this way. For example, dynamics can be estimated from historical data, verified with engineering knowledge, identified during a short step-by-step test, or estimated during operation. Bias updates and yield verification can also occur, such as when the processing unit's lumped yield (rather than the base yield) is updated in real time. Various error correction schemes may also be used in the master MPC controller planning model. In the first error correction scheme, the yield can be calculated directly from the input flow, and the average yield (within the past time window range) is used to predict future average yield over a similar time window. It can be estimated and used (the width of the time window can be tunable). Note that the estimated yield may have to pass an internal predictability threshold (possibly tunable) before the concentrated yield value is updated. Gain updates can increase model prediction accuracy and verified gains can have better predictability in future concentrated yields. In the second error correction scheme, a bias update mechanism can be used to update the bias within the master MPC model prediction.

  FIG. 9 shows an exemplary modeling of a general pool tank 900. Pool tank 900 represents a structure used to store materials (such as one or more intermediate products) that are manufactured in an installation. The storage tank 210 shown in FIG. 2A above is an example of a pool tank. Multiple streams of material (Fin) flow into the tank 900, each stream having r characteristics. Also, multiple streams (Fout) of material flow out of the tank 900 and all streams have the same characteristics. The current quantity is represented by V, and it can be assumed that input streams with similar characteristics are pooled together in the pool tank 900. Note that the model described below is for a tank used to pool intermediate products and may or may not be suitable for blending the final product. Other techniques (such as those using non-linear correction terms or non-linear blending methods) may also be used, but the input stream is equally sufficient so that the linear mixing rule is sufficiently accurate for the measurement feedback. Note that this is possible.

  In the pool tank 900 model, the following mass balance equation may be used.

The following formula can be used to represent the blending of the i th quantitative characteristic.

The following can be obtained using Laplace transform and reorganization.

Blending bonuses can also be used in oil and gas systems as follows.

Table 4 summarizes the general pool tank modeling.

The assumption here includes that the input flow fluctuates more frequently than their characteristics and that the input-output variables can be appropriately measured (in an automated method or laboratory).
In particular, the advantages of using a base model structure include designing a limited number of base structures (such as two in the above example), in which case the base structure Provides flexibility in terms of how they are connected. For example, processing units and pool tanks can be fixed after configuration, and inventory / property status can be dynamically tracked. The connection between the processing unit and the pool tank is stateless and can be changed on the fly. Moreover, the planning model for the master MPC controller can be configured on the fly. In addition, the cascaded architecture can easily exploit intermediate feedback as long as the intermediate input-output signal can be properly measured, and this approach matches the structure more naturally with the actual processing unit. As such, improved model updates can be supported.

Model Verification Techniques The master MPC controller 302 or other component of the control and automation system can implement verification techniques to verify the planning model used by the master MPC controller 302. FIG. 10 illustrates an example technique for validating a planning model in a cascaded MPC architecture according to this disclosure. In FIG. 10, the hierarchy of controllers and other devices is shown when each slave MPC controller 304a-304n is associated with at least one process element (processing unit or pool tank) 1002a-1002r. Each process element 1002a-1002r has an associated yield verification block 1004a-10004r, respectively.

  In particular, yield verification blocks 1004a-100r support model verification including envelope calculations of material balance, energy balance, product characteristics or other modeling updates. The planning model can be verified by checking that material, energy, or other factors are balanced in the model. Envelope calculations can be performed in weight or equivalent values, and the results can be presented in various units (such as weight or volume) based on the user's choice. A temperature / density correction factor can be used and the value can be converted to a common unit (such as barrel or ton). Commonly used practices in material metering in specific industries can be supported.

  Various other design issues can be considered during verification. For example, some measurements may be intermittent, inadequate, non-periodic, missing, postponed, or partially fictitious, and schemes (such as filtering or bias updates) may be Can be used to deal with anomalies. Also, in some cases, substances may not be balanced if there is non-standard material recycling (unplanned or unmeasurable) and will be dealt with in any appropriate way (based on user input, etc.) obtain. In addition, the yield of some streams may be significantly different from their “normal” values over a period of time due to maintenance or abnormal process conditions, and again in any suitable way (such as user input) Based).

  Yield verification blocks 1004a-1004r may also support concentrated yield bias update and yield verification as described above. For example, yield verification blocks 1004a-100r can measure real-time yields and cross-validate them by adding mass balances and volume / temperature corrections. Yield verification blocks 1004a-100r may also perform the first error correction scheme described above.

Techniques for Dealing with Master-Slave Variables The proxy restrictions described above allow constraints from slave MPC controllers 304a-304n to be accepted by master MPC controller 302. FIGS. 11 and 12 illustrate exemplary techniques for linking variables in a master MPC controller and a slave MPC controller in a cascaded MPC architecture according to this disclosure. This technique allows the master MPC controller 302 to consider the constraints of the slave MPC controllers 304a-304n during its operation. However, it should be noted that other approaches may be used.

  As shown in FIG. 11, the master MPC controller 302 has an MV / DV indicator 1102 that identifies various MVs or DVs used by the master MPC controller 302. Various CVs 1104 controlled by the master MPC controller 302 can be affected by their MV or DV. There is also an MV / DV indicator 1106 that identifies the various MVs or DVs used by the slave MPC controllers 304a-304b. The various CVs 1108-1110 controlled by the slave MPC controllers 304a-304b may be affected by their MV or DV. The conjoint variable corresponds to the same variable in both the master MPC controller and the slave MPC controller (MV4 in the master controller, MV9 in the slave controller, etc. as described above). The conjoint variable can be configured as MV or DV in the master and slave MPC controllers.

  Master and slave CV constraints can be combined by associating values at the MV / DV index 1102 with corresponding values at the MV / DV index 1106. This indicates that the variable specified by the MV / DV in index 1102 and the MV / DV index 1106 is a conjoint variable. This allows the master MPC controller 302 to optimize the entire plant to include some or all of the CV constraints from the slave MPC controllers 304a-304b.

  As shown in FIG. 12, when the slave MPC model matrix is negligible, at least one CV of the slave MPC controller can be “promoted” to the master MPC controller via proxy restrictions. Proxy restrictions appear in the column of the MV / DV index 1102 associated with the corresponding column of the MV / DV index 1106. For example, assume that the CV constraint in the slave MPC controller is expressed as:

This CV constraint can be used as a CV proxy restriction in the master MPC controller using this formula.

This represents one exemplary way in which the constraints of the slave MPC controller can be accepted and used by the master MPC controller.
Exemplary Method FIG. 13 illustrates an exemplary method 1300 for using a cascaded MPC controller in an industrial process control and automation system according to this disclosure. For ease of explanation, the method 1300 is described with respect to a cascaded MPC architecture 300 that can operate in the control and automation system 100. The method 1300 may be used in any other suitable system with any other suitable cascaded MPC architecture.

  As shown in FIG. 13, at step 1302, a planning model is obtained at the master MPC controller, and at step 1304, an MPC model is obtained at the slave MPC controller. This can include, for example, generating a planning model 200 or reusing an existing planning model 200, such as a single period planning model. This can also include generating the MPC model 250, such as by using standard techniques.

  In step 1306, during operation of the cascaded MPC architecture, a query optimization call is sent from the master MPC controller to the slave MPC controller. The query optimization call determines whether (and to what extent) slave MPC controllers can make any changes to their MV values without violating their constraints. You can ask to do it. In step 1308, the slave MPC controller responds by sending proxy limit values associated with those constraints to the master MPC controller. This can include, for example, a slave MPC controller identifying to what extent any changes can be made to their MV values and which constraints can be violated. Further details regarding these functions are provided below.

  In step 1310, the planning model is manipulated by the master MPC controller during an optimization operation using proxy limits. This can include, for example, the master MPC controller combining proxy limit values from multiple slave MPC controllers in the master MPC controller's control and economic optimization formula. At the same time, in step 1312, the MPC model is manipulated by the slave MPC controller during the control operation. This can include, for example, that the slave MPC controllers perform standard MPC functions whose functions are based on control and economic optimization formulas generated by the master MPC controller. In this method, in step 1314, integrated planning / optimization and control functions may occur in the control and automation system.

  Although FIG. 13 illustrates one example of a method 1300 for using a cascaded MPC controller in an industrial process control and automation system, various changes may be made to FIG. For example, although shown as a series of steps, the various steps in FIG. 13 may occur in duplicate, occur in parallel, occur in different orders, or occur any number of times.

Feasible Region Estimation FIGS. 14-18 illustrate exemplary techniques for generating proxy restrictions associated with a feasible region to support cascaded MPCs according to this disclosure. The slave MPC controller constraints can be incorporated into the planning operation of the master MPC controller in any suitable manner. For example, FIG. 14 shows that if the free MVs of the slave MPC controllers are fixed at their current values, the CV constraints of the slave controllers can be plotted in the MV space 1400 of the master controller. In general, the MV limit of the slave controller appears as a simple boundary in the MV space 1400 of the master controller, and the CV limit of the slave controller appears as a linear constraint. The executable area 1402 between these limits defines possible combinations of values that can be selected by the master MPC controller while meeting all the constraints of the slave MPC controller. The shape of the executable area 1402 defined by the constraints of the slave controller is generally a polygon or a polyhedron.

  As shown in FIG. 15, when the free MV of the slave MPC controller takes other values (for any reason), the shape of the executable area 1402 changes. Shaded bar 1502 shows how these constraints can shift. Similarly, if the model gain of the slave controller is updated on the fly, the slopes of these CV constraints may change accordingly.

  If there is one conjoint variable between the master MPC controller and the slave MPC controller, the size of the executable area 1402 can be reduced to the executable area 1602 shown in FIG. This can be achieved if you want to push the MV / DV of the master MPC controller in a given direction by making a small change at some point. In that case, only a narrow band of feasible space is used. The high and low values of this feasible region 1602 can be calculated by finding an appropriate location for the MV of the free slave controller. The maximum value can be calculated by a query optimization call from the master controller for the slave controller to maximize its MV2 value. The minimum value can be calculated by a query optimization call from the master controller for the slave controller to minimize its MV2 value. The maximized objective function can be increased to include product contribution values and other local optimization components. In the case of contribution values, the unit can be pushed to a more useful yield profile.

  If there are two or more conjoint variables between the master MPC controller and the slave MPC controller, the executable region 1702 may be defined as shown in FIG. Again, the executable region 1702 represents a polygon or polyhedron defined by various MV and CV restrictions of the slave MPC controller. Any point within the feasible region 1702 can be used to create an optimization solution that is feasible and can be implemented by a slave MPC controller. The current value of MV in the slave MPC controller defines the current MV point 1704 that is in the executable area 1702.

  Using the current MV point 1704, the master MPC controller can estimate the shape of the executable area 1702 as follows. In each of the plurality of directions 1706a-1706d, the master MPC controller makes an inquiry optimization call for the slave controller to maximize or minimize the MV1 or MV2 value. For example, in direction 1706a, the master MPC controller makes a query optimization call for the slave controller to maximize its MV1 value. In direction 1706b, the master MPC controller makes a query optimization call for the slave controller to minimize its MV1 value. In direction 1706c, the master MPC controller makes a query optimization call for the slave controller to maximize its MV2 value. In direction 1706d, the master MPC controller makes a query optimization call for the slave controller to minimize its MV2 value. The four points identified by these query optimization calls define an estimated feasible region 1708 that can be used by the master MPC controller when performing planning optimization. In this way, the master MPC controller helps to ensure that the identified solution can be implemented by the slave MPC controller.

  Note that in FIG. 17, the master MPC controller makes query optimization calls related to four different directions. However, the number of query optimization calls and the direction associated with those query optimization calls can vary. In general, as long as the master MPC controller makes query optimization calls related to more than two directions, the master MPC controller can specify a multi-dimensional space within the executable region of the slave MPC controller. In FIG. 18, for example, the current MV point 1804 is within the executable area 1802 of the slave MPC controller. The master MPC controller makes query optimization calls associated with eight directions 1806 at 45 ° intervals. The results of these query optimization calls define an estimated feasible region 1808 that can also be used by the master MPC controller.

  In some embodiments, query optimization calls and related functions can be implemented as follows. In response to the query optimization call, the slave MPC controller is required to minimize:

b _LO ≦ A _c x _conj + A _j x _free ≦ b _Hi (18)
d ^t x _conj = 0 (19)
However,

In the particular implementation of the example shown in FIG. 18, the master MPC controller can make the eight query optimization calls shown in Table 5 with various values of c ^t and d ^t values.

The first four calls in Table 5 can be used to make the query optimization call shown in FIG.
Note that the query optimization call shown in Table 5 defines the direction to be 45 ° apart. However, the query optimization call can be extended to define any suitable direction as follows.

here

It is defined as the null space of the vector c ^t. This definition allows query optimization calls to occur in any desired direction, and up to n query optimization calls can be made by the master MPC controller for a particular current MV point.

  The value returned in response to each query optimization call can be used as a proxy constraint by the master MPC controller as shown in FIG. For example, up to four proxy constraints can be used by the master MPC controller shown in FIG. 17, and up to eight proxy constraints can be used by the master MPC controller of FIG. These proxy constraints allow the master MPC controller to ensure that any solution specified by the master MPC controller falls within the actual executable area of the slave MPC controller.

  The above approach provides a general method for approximating the executable space defined by the CV / MV constraints of the slave MPC controller. This approach works regardless of the actual executable space shape of the slave MPC controller or the number of constraints in the slave MPC controller. However, it is also possible to select the direction associated with a particular query optimization call to help more closely estimate the actual executable region of the slave MPC controller. For example, the direction associated with a particular query optimization call can be selected to be approximately perpendicular to the CV or MV limit in the immediate vicinity of the slave MPC controller. This can be particularly useful when the slave MPC controller's CV constraint approaches its boundary, and a query optimization call can be specifically made to represent that CV constraint. Here, the query optimization call may be defined as shown in Table 7.

here,

Is defined as the zero space of a _j .
It should be noted that although only one or two conjoint variables have been described above, the approach described herein can be extended to any number of conjoint variables. This approach allows the master MPC controller to take into account the constraints of each of its slave MPC controllers while optimizing the operation of the plant in the feasible region defined by those constraints. It should also be noted that although the slave MPC controller CV / MV limit is shown here as being plotted in two dimensions, the feasible region for the slave MPC controller may be defined in three dimensions or more. Query optimization calls can be made in three or more dimensions to define a multidimensional space that estimates the multidimensional executable region.

  FIG. 19 illustrates an example method 1900 for calculating proxy restrictions to support cascaded MPCs according to this disclosure. Specifically, the present method 1900 can be used to estimate the feasible region of a slave MPC controller with a master MPC controller. As shown in FIG. 19, the current operating point of the slave MPC controller is identified at step 1902. This may include, for example, the processing device in the master MPC controller 302 identifying the current MV value of the slave MPC controllers 304a-304n.

  The direction of movement of the slave MPC controller from the current operating point is selected at step 1904. This may include, for example, the step of a processing device in the master MPC controller 302 selecting a predetermined direction or a direction perpendicular to the line defining the MV / CV limits of the slave MPC controllers 304a-304n. A query optimization call is made to the slave MPC controller to determine how much one or more MVs of the slave MPC controller can be pushed in the selected direction at step 1906, and to what extent the slave MPC controller A specific indication of whether one or more MVs of the controller can be pushed in the selected direction is received at step 1908. For example, to what extent a processing device in the master MPC controller 302 is selected without the slave MPC controllers 304a-304n violating the constraints and receiving a specific indication from the slave MPC controllers 304a-304n. Requesting that the slave MPC controllers 304a-304n specify whether one or more MVs can be pushed in the direction. In other words, slave MPC controllers 304a-304n identify their proxy restrictions in the selected direction. If there are more directions to be tested at step 1910, the process returns to step 1904 to select another direction and issue another query optimization call.

  After all directions have been queried, an estimate of the slave MPC controller's feasible region is generated at step 1912. This may include, for example, the processing device in the master MPC controller 302 identifying a multidimensional space defined by proxy restrictions from the slave MPC controllers 304a-304n. This estimated feasible region is used by the master MPC controller in step 1914 to identify the planning optimization solution. Since the estimated feasible region identified by the master MPC controller 302 is in the actual feasible region associated with the slave MPC controllers 304a-304n, the solution identified by the master MPC controller 302 is the slave MPC controller 304a- 304n can be executed.

  FIG. 19 illustrates an example of a method 1900 for calculating proxy limits to support cascaded MPC, but various changes may be made to FIG. 19, for example, shown as a series of steps. However, the various steps of FIG. 19 may occur in duplicate, occur in parallel, occur in different orders, or occur any number of times.

CONCLUSION This disclosure has provided a novel cascaded MPC architecture that bridges the gap between planning and control. This architecture includes a master MPC controller cascaded across one or more slave MPC controllers, such as a slave MPC controller at the unit level. The master MPC controller uses a planning model to control production inventory, manufacturing activities, product quality, and the like inside the plant. The slave MPC controller provides those future predictions and operating constraints to the master MPC controller, such as through proxy restrictions. Real-time planning solutions embedded in a multi-tier MPC cascade comply with lower level operating constraints and no longer require manual conversion. By cross-utilizing both planning and control models online, the MPC cascade architecture performs real-time optimization of the entire plant in a closed-loop control system and allows just-in-time production planning through slave MPC controllers. Allows you to carry out automatically. In addition, techniques are provided to allow the master MPC controller to estimate the executable region of the slave MPC controller so that the master MPC controller can generate a solution that can be implemented by the slave MPC controller. Is done.

  In some embodiments, the various functions described in this patent document are implemented or supported by a computer program formed from computer readable program code and embedded in a computer readable medium. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer-readable medium” includes read-only memory (ROM), random access memory (RAM), hard disk drive, compact disk (CD), digital video disk (DVD). Any type of media that can be accessed by a computer, such as a Video Disc) or any other type of memory. “Non-transitory” computer-readable media does not include wired, wireless, optical, or other communication links that carry transient electrical or other signals. Non-transitory computer readable media include media on which data can be permanently stored and media on which data can be stored and later overwritten, such as rewritable optical disks or erasable memory devices.

  It may be beneficial to provide definitions of some words and phrases used throughout this patent document. The terms “application” and “program” refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, related data, or appropriate computer code (source code, object code , Or including executable code) that are adapted to their implementation. The term “communicate” and its derivatives include both direct and indirect communications. The terms “include”, “comprise” and their derivatives mean inclusion without limitation. The term “or” is inclusive and means “and / or”. The phrase “associated with” and its derivatives are included, included in, interconnected with, included in, included in, connected to, or. To or to, to, to, to, to, interleave, juxtapose, to, close to, to, or have a characteristic of to It may be meant to include or have a relationship with or. The phrase “at least one of” when used in an item list, various combinations of one or more of the listed items can be used, and only one in the list Means that the item can be needed. For example, “at least one of: A, B, and C (at least one of A, B, and C)” is A, B, C, A and B, A and C, B and C, A And any combination of B and C.

  While this disclosure has described particular embodiments and methods generally associated therewith, modifications and substitutions to these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and modifications are also possible without departing from the spirit and scope of the present disclosure as defined by the following claims.

Claims (15)

A master model predictive control (MPC) controller (302) receiving information from slave MPC controllers (304a-304n) (1908), wherein the slave MPC controller is a process variable of the slave MPC controller; Step (1908), indicating to what extent a plurality of manipulated variables can be changed in each of a plurality of directions (1706a-1706d, 1806) in the variable space without violating the constraints;
Using the information to estimate an executable region (1402, 1702, 1802) associated with the slave MPC controller (1912), wherein the executable region is a combination of manipulated variable values and the process variable constraint Identifying a portion of the variable space that satisfies (1912);
Using the feasible region to perform plant-wide optimization with the master MPC controller (1914), wherein a solution generated during the plant-wide optimization is within the feasible region And (1914) comprising one of said combinations of manipulated variable values. Sending a plurality of query optimization calls from the master MPC controller to the slave MPC controller (1906);
The method of claim 1, further comprising: receiving the information comprises receiving a proxy limit value from the slave MPC controller in response to the query optimization call.   Each proxy limit value specifies a maximum distance in one of the directions in the variable space that the slave MPC controller can change the manipulated variable without violating the process variable constraint. 2. The method according to 2.   The plurality of directions are defined with respect to a current operating point (1704, 1804) associated with the slave MPC controller, wherein the current operating point defines a particular point in the variable space. the method of.   The method of claim 4, wherein the plurality of directions are equally spaced around the current operating point associated with the slave MPC controller. The method of claim 1, further comprising identifying at least one direction of the plurality of directions.   The method of claim 6, wherein at least one of the plurality of directions comprises a direction that is substantially perpendicular to a linear variable limit associated with the slave MPC controller. Repeating the receiving and identifying steps for a plurality of slave MPC controllers (304a-304n), wherein the solution generated during the plant-wide optimization is The method of claim 1, wherein all process variable constraints are respected. A master model predictive control (MPC) controller (302), wherein the MPC controller (302)
At least one network interface (146) configured to receive information from a slave MPC controller (304a-304n), wherein the information violates a process variable constraint of the slave MPC controller. And at least one network interface (146) that indicates how far a plurality of manipulated variables can be changed in each of a plurality of directions (1706a-1706d, 1806) in the variable space,
At least one processing device (142), wherein the at least one processing device (142) comprises:
Using the information to estimate an executable region (1402, 1702, 1802) associated with the slave MPC controller, wherein the executable region includes a combination of manipulated variable values satisfying the process variable constraint Identifying, estimating a portion of a variable space, and performing plant-wide optimization using the feasible region, wherein a solution generated during the plant-wide optimization comprises: An apparatus configured to perform, including one of the combinations of the manipulated variable values in the executable region. The at least one processing device is further configured to initiate transmission of a plurality of query optimization calls to the slave MPC controller;
The at least one processing device is configured to receive a proxy limit value from the slave MPC controller in response to the query optimization call;
The apparatus according to claim 9.   The plurality of directions are defined with respect to a current operating point (1704, 1804) associated with the slave MPC controller, wherein the current operating point defines a particular point in the variable space. Equipment.   The apparatus of claim 11, wherein the plurality of directions are equally spaced around the current operating point associated with the slave MPC controller.   The apparatus of claim 9, wherein the at least one processing device is further configured to identify at least one direction of the plurality of directions.   The apparatus of claim 13, wherein at least one of the plurality of directions comprises a direction that is substantially perpendicular to a linear variable restriction associated with the slave MPC controller. A non-transitory computer readable medium embodying a computer program, the computer program comprising:
A master model predictive control (MPC) controller (302) receiving information from slave MPC controllers (304a-304n) (1908), wherein the slave MPC controller is a process variable of the slave MPC controller; Step (1908), indicating to what extent a plurality of manipulated variables can be changed in each of a plurality of directions (1706a-1706d, 1806) in the variable space without violating the constraints;
Using the information to estimate an executable region (1402, 1702, 1802) associated with the slave MPC controller (1912), wherein the executable region is a combination of manipulated variable values that defines the process variable constraint. Identifying a portion of the variable space that satisfies (1912);
Using the feasible region to perform plant-wide optimization with the master MPC controller (1914), wherein a solution generated during the plant-wide optimization is within the feasible region A non-transitory computer readable medium comprising computer readable program code for step (1914), comprising one of the combination of manipulated variable values.

Images