JP6647295B2 - Apparatus, method, and non-transitory computer readable medium for calculating proxy restrictions to support cascaded model predictive control (MPC) - Google Patents

Description

CROSS REFERENCE TO RELATED APPLICATIONS AND CLAIM OF PRIORITY This application is a continuation-in-part of U.S. Patent Application No. 14 / 336,888, filed July 21, 2014, which is hereby incorporated by reference in its entirety. , Claim priority under 35 USC 120.

  The present disclosure relates generally to industrial process control and automation systems. More specifically, the present disclosure relates to an apparatus and method for calculating proxy restrictions 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 may include devices that perform process control functions and model predictive control (MPC) operations, while the upper layer may include devices that provide a plant-wide optimization solution.

  Ideally, control and plant-wide optimization would be designed in one, but how to achieve 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 top-level diagram removes foliage 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, significant optimization benefits remain out of reach.

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

  In a first embodiment, a method comprises 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 indicating to what extent multiple manipulated variables can be changed in each of the multiple directions in the variable space. The method also includes estimating, using the information, an executable region associated with the slave MPC controller, wherein the executable region defines a portion of a variable space where a combination of manipulated variable values satisfies a process variable constraint. Identifying, including steps. In addition, the method includes performing a whole plant optimization on the master MPC controller using the feasible region, wherein the solution generated during the whole plant optimization comprises: Including one of the combinations of manipulated variable values.

  In a second embodiment, an 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 so that the information can be transmitted to the slave MPC controller in multiple directions in the variable space without violating the process variable constraints of the slave MPC controller. Indicate that a plurality of manipulated variables can be changed in each of. The at least one processing device is configured to use the information to estimate an executable region associated with the slave MPC controller, wherein the executable region is a portion of a variable space where a combination of manipulated variable values satisfies a process variable constraint. To identify. The at least one processing device is also configured to perform a plant-wide optimization using the feasible region, wherein the solution generated during the plant-wide optimization is configured to include the manipulated variable values in the feasible region. In 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 the plurality of manipulated variables in each of the plurality of directions in the variable space without violating the process variable constraints of the slave MPC controller. Includes computer readable program code for receipt at the master MPC controller from the MPC controller. The computer program also includes computer readable program code for estimating an executable region associated with the slave MPC controller using the information, wherein the executable region is a variable space of a variable space where the combination of manipulated variable values satisfies the process variable constraints. Identify some. The computer program further comprises computer readable program code for performing a plant-wide optimization on the master MPC controller using the executable region, wherein the solution generated during the plant-wide optimization comprises the executable region Include one of the combinations of the manipulated variable values in.

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

FIG. 1 illustrates an exemplary 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. 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. 1 illustrates an exemplary cascaded MPC architecture for an industrial process control and automation system according to the present disclosure. FIG. 1 illustrates an exemplary cascaded MPC architecture for an industrial process control and automation system according to the present disclosure. FIG. 1 illustrates an exemplary cascaded MPC architecture for an industrial process control and automation system according to the present disclosure. FIG. 4 illustrates an exemplary use of proxy restrictions in a cascaded MPC architecture, in accordance with the present disclosure. FIG. 3 illustrates an exemplary graphical user interface (GUI) for use with a cascaded MPC architecture, in accordance with the present disclosure. FIG. 4 illustrates an example technique for using contribution value and contribution cost with a cascaded MPC architecture, in accordance with the present disclosure. FIG. 4 illustrates an exemplary base model for forming a planning model in a cascaded MPC architecture according to the present disclosure. FIG. 4 illustrates an exemplary base model for forming a planning model in a cascaded MPC architecture according to the present disclosure. FIG. 4 illustrates an exemplary base model for forming a planning model in a cascaded MPC architecture according to the present disclosure. FIG. 4 illustrates an exemplary technique for validating a planning model in a cascaded MPC architecture, in accordance with the present disclosure. FIG. 4 illustrates an example technique for linking variables at a master MPC controller and a slave MPC controller in a cascaded MPC architecture, in accordance with the present disclosure. FIG. 4 illustrates an example technique for linking variables at a master MPC controller and a slave MPC controller in a cascaded MPC architecture according to the present disclosure. FIG. 3 illustrates an exemplary use of 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 MPC in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPC in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPC in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPC in accordance with the present disclosure. FIG. 4 illustrates an example technique for generating proxy restrictions associated with an executable region to support cascaded MPC in accordance with the present disclosure. FIG. 4 illustrates an exemplary method for calculating proxy restrictions to support cascaded MPC in accordance with the present disclosure.

  The various embodiments used to illustrate the principles of the present invention in FIGS. 1-19 described below and in this patent document are merely exemplary, and the scope of the present invention is not limited in any way. Should not be construed as limiting. Those skilled in the art will appreciate that the principles of the present 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 according to the present disclosure. As shown in FIG. 1, 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 within one or more plants 101a-101n. Each plant 101a-101n represents 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. I do. Generally, each plant 101a-101n may implement one or more processes, and may be individually or collectively referred to as a process system. A processing system generally corresponds to any system or portion thereof configured to process one or more products or other materials in some manner.

  In FIG. 1, system 100 is implemented using a Purdue model of process control. 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 a 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 a process system, such as temperature, pressure, or flow. Also, the actuator 102b can modify a wide variety of characteristics in the process system. Sensor 102a and actuator 102b may represent any other or additional components in any suitable processing system. Each of the sensors 102a includes any structure suitable for measuring one or more properties in the processing 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 sensor 102a and actuator 102b. Network 104 facilitates interaction with sensors 102a and actuators 102b. For example, network 104 can transmit measurement data from sensor 102a and provide control signals to 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), a pneumatic control signaling network, or any other or additional network.

  In the Purdue model, “Level 1” may include one or more controllers 106 coupled to the network 104. Each controller 106 may specifically control the operation of one or more actuators 102b using measurements from one or more sensors 102a. For example, 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, a model predictive control (MPC), a dynamic matrix control (DMC), or the like. Shell Global Solutions' Multivariable Optimization and Control (SMOC), or other types of controllers that implement other advanced predictive control (APC) may be represented. As a particular 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. Network 108 facilitates interaction with controller 106, such as by exchanging data with controller 106. Network 108 may correspond to any suitable network or combination of networks. As a specific example, network 108 is equivalent to a redundant pair of Ethernet networks, 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 transmit traffic from one network to another 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. Network 112 may 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. Machine level controller 114 has various functions to support the operation and control of controller 106, sensors 102a, and actuators 102b, which can be associated with a particular industrial device (such as a boiler or other machine). Fulfill. For example, the machine-level controller 114 can 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 control the operation of the controller 106 and thereby execute an application that controls the operation of the actuator 102b. Further, 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, controlling, or operating on one machine or other individual device. Each of the machine-level controllers 114 may correspond to, for example, a server computing device running a Microsoft Windows operating system. Although not shown, various machine-level controllers 114 may be used to control various devices in the process system (where each device has one or more controllers 106, sensors 102a, And the actuator 102b).

  One or more operator stations 116 are coupled to network 112. The operator station 116 provides user access to the machine-level controller 114, thereby providing user access to the controller 106 (and, in some cases, the sensors 102a and actuators 102b), computing or It corresponds to a communication device. As a specific example, operator station 116 allows a user to review the operational history of sensors 102a and actuators 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. Further, operator station 116 may receive and display warnings, alerts, or other messages or indications generated by controller 106 or machine-level controller 114. Each of the operator stations 116 includes any structure suitable for supporting 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 running 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. 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 one unit in the process system, representing a collection of various machines working together to implement at least a portion of one process. Unit level controller 122 performs various functions to support the operation and control of components within lower levels. For example, the unit-level controller 122 may log information collected or generated by components in lower levels, execute applications that control components in lower levels, and to components in lower levels. Secure access can be provided. Each of the unit-level controllers 122 provides any structure suitable for providing access to, controlling, or operating on, 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 running a Microsoft Windows operating system. Although not shown, various unit-level controllers 122 may be used to control the various units in a process system (where each unit has one or more machine-level controllers 114 , 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 of the operator stations 124 includes any structure suitable for supporting 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 running a Microsoft Windows operating system.

  At least one router / firewall 126 couples network 120 to two networks 128. The router / firewall 126 includes any structure suitable for providing communication between networks, such as a secure router or a combined router / firewall. 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 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 implementing the same, similar, or various processes. The plant level controller 130 performs various functions to support the operation and control of components within lower levels. As a particular 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 access to, for controlling, or operating on 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 running 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 for supporting 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 running 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 network 136. Each enterprise-level controller 138 typically performs planning operations for a plurality of 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 components within the plants 101a-101n. As a specific example, an enterprise-level controller 138 may include one or more order processing applications, an enterprise resource planning (ERP) application, an advanced planning and scheduling (APS) application, or other. Or run additional enterprise control applications. Each of the enterprise-level controllers 138 includes any structure suitable for providing access to, control of, or operation with, one or more plant controls. Each of the enterprise-level controllers 138 may correspond to, for example, a server computing device running a Microsoft Windows operating system. In this document, the term "enterprise" refers to an organization that has 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 for supporting 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 running a Microsoft Windows operating system.

  The various levels of the purdue model may include other components, such as one or more databases. The database associated with each level may store any suitable information associated with that level or one or more other levels of system 100. For example, a historian 141 can be coupled to the network 136. The historian 141 can be a component that stores various information about the system 100. The historian 141 can store information used during, for example, production scheduling and optimization. The historian 141 corresponds to any structure suitable for storing information and facilitating information retrieval. Although historian 141 is shown as a single centralized component coupled to network 136, it may be located elsewhere in system 100 or multiple historians may be Can be distributed at 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 includes one or more processing devices 142 and one for storing instructions and data used, generated, or collected by the processing devices 142. Alternatively, a plurality of memories 144 may 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. Also, each of the operator stations 116, 124, 132, 140 may include 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 the standard multivariable control solution for many industries. The widespread use of MPC has provided a solid basis for more economically meaningful progress, ie, closed-loop plant-wide optimization. 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, open-loop plant-wide optimization, commonly known as production planning, still occurs. 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 intermediaries such as daily operator invoices. From this, a considerable 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 into operator actions, but does not eliminate manual coordination. In other industries, open-loop production schedulers are used instead of production planning, but their output targets are often also manually adjusted.

  The practice of manually adjusting an open loop solution is to (i) meet lower level (possibly safety related) control constraints within the process unit, (ii) disturbances on the production inventory or product quality. It often results from the need to translate or review higher-level production goals to compensate for (in planning jargon, called "unexpected events"). The technical difficulties associated with manual conversion generally coincide with the difficulties involved in integrating multi-level solutions that use models at different scales.

  The present disclosure provides a cascaded MPC solution for plant-wide control and optimization that helps 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 the production inventory, manufacturing activity, or product quality inside the plant and to achieve economic optimization of the entire plant. The master MPC controller is cascaded over one or more slave MPC controllers. The slave MPC controllers can correspond to, for example, controllers at the unit level (level 3) of the system, and each slave MPC controller provides its master MPC controller with its operating state and constraints. For this reason, the plant-wide optimization solution from the master MPC controller can adhere to all unit-level operating constraints from the slave MPC controller. Together, the MPC cascade simultaneously provides both distributed control (eg, at the unit level) and centralized plant-wide optimization (eg, at the plant level) in one consistent control system. The phrase “plant-wide optimization” or “plant-wide control” refers to the number of units in an industrial facility that may or may not correspond to any and all units in the industrial facility. And refers to optimization or control.

  In this way, the MPC cascade solution allows an embedded real-time planning solution to adhere to lower-level operating constraints. By cross-leveling both the planning model and the control model online, the MPC cascade solution implements a "reverse horizon" form of planning optimization in a real-time closed-loop control system. Enable. The MPC cascade solution can be used, in particular, to automatically execute just-in-time production planning through its slave MPC controller. The formulation of the regression horizon planning optimization in the master MPC controller is a single-period, but typically shortened time horizon planning optimization as used in offline planning tools, such as in the range of 1-14 days. It can be the same as or the same as the formula.

  The remaining 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. Conduits for merging multi-scale models are described in the form of proxy restrictions to provide a multi-scale solution for enhancing the user experience. In addition, the use of contribution values and contribution costs is disclosed as a method of casting the central economic objective function to intermediate stream prices / expenses, and describes a model structure that can be used in certain systems using MPC cascade solutions. Is done. Finally, a model verification technique is provided, a technique for addressing master-slave variables in an MPC cascade solution is disclosed, and a technique for estimating a workable area where an industrial process can be tuned is 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, a 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 system 100 in FIG. 1 is for illustration only. Components can be added, excluded, combined, or arranged in any other suitable configuration, according to particular needs. Further, certain functions have been described as being performed by certain components of the system 100. This is merely illustrative. In general, control and automation systems are highly configurable and can be configured in any suitable manner, depending on the needs of the property. Further, FIG. 1 shows 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 a lower level, each unit needs to be properly controlled to ensure safety within the plant and smooth and efficient operation of the unit.

  Planning and MPC models are examples of a set of multi-scale models that can be used to solve multi-level problems in a cascaded MPC architecture. 2A and 2B illustrate exemplary planning and MPC models used to support a cascaded MPC approach in an industrial process control and automation system according to the present disclosure. Specifically, FIG. 2A illustrates a planning model 200 based on yield, and FIG. 2B illustrates 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 that operate to convert are identified. 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 can be used to store one or more of the intermediate products 208. As shown in FIG. 2B, MPC model 250 identifies a plurality of components 252 of one unit. Various valves and other actuators 254 can be used to regulate operation inside the unit, and various APCs and other controllers 256 can be used to control the actuators inside the unit.

  Generally, the planning model 200 corresponds to an individual unit on a coarse scale, as the whole plant (or a part thereof) is viewed in a “bird's eye” view. The planning model 200 focuses on the unit production, product quality, material and energy balances inside the plant, and the steady state relationships between units associated with manufacturing activities. The planning model 200 typically (but not necessarily) consists of a process yield model and product quality characteristics. The planning model 200 may be built from a combination of various sources, such as planning tools, scheduling tools, yield verification tools, and / or historical motion data. However, MPC model 250 represents at least one unit on a finer scale. The MPC model 250 is a unit between a control variable (CV: Controlled Variable), an operation variable (MV: Manipulated Variable), and a disturbance variable (DV: Disturbance Variable) associated with 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 time horizon of the MPC model typically ranges from minutes to hours, while the time horizon of the planning model typically ranges from days to months. "Control variable" generally refers to a variable whose value is controlled to be at or near a set value or within a desired range, while "manipulated variable" generally refers to the value of at least one control variable. Note that it represents a variable that is adjusted to modify. A “disturbance variable” generally refers to a variable whose value is taken into account but may not be controlled or adjusted.

  The planning model 200 can and often needs to exclude non-production related or non-economically related variables, such as pressure, temperature, tank level, and valve opening inside each unit. . Instead, the planning model 200 can simplify one process unit to one or several material or energy yield vectors. MPC model 250, on the other hand, 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 a fluidized catalytic cracking unit (FCCU) of an oil refinery can include about 100 CV (output) and 40 MV (input). The planning model 200 of the same unit can focus only on the important consequences of raw material quality and operating mode (as input) and FCCU product yield and quality (as output), whereby the planning model 200 , 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, comparing the normal focus of the two models 200,250.

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

  The compact and robust planning model 200 allows the planning problem to be easily set up, displayed clearly and solved quickly, but it has its drawbacks, namely, the visibility of detailed variables inside any unit. I have nothing. Many of these detailed variables may be of little relevance to higher-level production planning, but a small subset usually does. If the planning model 200 does not have visibility inside any lower level units, this model will ensure that the solution respects the lower level constraints of all units, whether optimal or not. Cannot be guaranteed. This means that traditional planning solutions often need to be converted or reviewed manually to take into account operating constraints inside the unit, and significant margins can be lost during the conversion That's one reason. The same is true for the scheduling solution if it uses the yield-based planning model 200 on a coarse scale.

  From a holistic perspective, optimization or control problems formulated with a higher-level yield-based planning model 200 can benefit from lower-level MPC models 250. The rationale is that the specifics used to guarantee constraint satisfaction within the unit are usually already in the unit's MPC model 250, although these specifics are not necessarily organized into the proper model format. is there. Ideally, the MPC model 250 can be used to supplement the details of unit constraints for planning, if needed. The cascaded MPC approach described below is used effectively by MPC models to provide lower-level fine-scale model information to an upper-level coarse-scale plant-wide optimization or control formulation. To provide a structural framework where possible. The cascaded MPC approach described below can utilize the planning model 200 and the MPC model 250 to provide this functionality.

Cascaded MPC solution using multi-scale models Control and planning are often combined from a plant-wide perspective. Planning usually relies on controls to establish a workable area for optimization, while controls typically coordinate units at their most profitable operating points to operate the entire plant. Rely on planning. Thus, planning often relies on MPC controllers that constrain the constraints within each unit to create a larger work area for plant-wide optimization. On the other hand, the MPC controller must plan before knowing which constraints are really plant-wide obstacles and therefore need to be pushed out, and which constraints are not invalid and may remain invalid. Often rely on guidance from Therefore, these two solution layers are co-dependent on each other and need to be handled simultaneously.

  One way to solve this coupling problem is to design the control and optimization of the whole plant in one. Because 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 integrated, uncompromising MPC solutions have various disadvantages. One challenge with any integrated design approach is that it has simultaneously provided 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 the present 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. Remainer 310 of the plant may include level 1 controllers, sensors, actuators, and other lower-level components. Master MPC controller 302 generally operates in a master control loop, while each slave MPC controller 304a-304n generally operates in 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 provides an initial steady state gain matrix using the planning model 200 (e.g., a yield-based single-period planning model), and the associated model dynamics determines the plant operating data (e.g., historical data). Can be determined using The master MPC controller 302 operates to control production inventory, manufacturing activity, or product quality inside the plant. Thus, with the same planning model structure and economy, the embedded economic optimizer of the master MPC controller 302 can reproduce a single-period offline planning optimization, but in an online real-time manner. .

  The master MPC controller 302 cascade-connects with n slave MPC controllers 304a to 304n (n is an integer of 1 or more). The slave MPC controllers 304a-304n provide the master MPC controller 302 with future predictions and operating constraints for each unit of the plant. With this information, a real-time planning solution from the cascaded architecture 300 mitigates or eliminates the disadvantages described above. Collectively, the MPC controllers 302, 304a-304n provide distributed control at the lower level in the fine-scale MPC model 250 and upper level in the coarse-scale planning model 200, all in one consistent cascaded control system. At the same time to optimize the entire centralized plant.

  Another reason that production plans often need to be manually translated into a set of operating instructions is that open-loop planning solutions typically range in time from several days to one month (in one period). Having a horizon, and that the solution is usually run only once a day or only once every few days. Thus, it lacks effective feedback mechanisms to address uncertainties such as changes in raw material quality or ambient conditions, malfunctions in process units, limits on heating or cooling capacity, and maintenance. To assist in dealing 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 an hour. Can be performed. 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. When a deviation from the original optimal plan is detected, re-optimization of the entire plant can be performed immediately. Thereafter, the new optimal production goals are transmitted to the slave MPC controllers 304a-304n and will be executed by those controllers, which may reduce or eliminate 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 the traditional MPC approach and the cascaded MPC solution may include:

-The objective function can remain the same as that of the 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 (especially multi-period) planning be able to.

  Tuning can be set to gain more in the form of just-in-time manufacturing. Tuning considerations include (for example) how far to place a pre-order for a product, fluctuations in product orders (both in quantity and grade), what additional purchase / sales opportunities can be pursued, and what half The finishing component may include whether it can be exchanged with a business partner or purchased / sold in a spot market.

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

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

  Cascaded architecture 300 provides a control hierarchy diagram 350, as shown in FIG. 3C. Cascaded architecture 300 breaks the dividing lines in conventional control and automation systems by obtaining a copy of planning model 200 and adding it to the MPC controller, adding delays and ramps. The unit supply can be used as the MV, and the production inventory can be used as the CV in the master MPC controller 302. The master MPC controller 302 is a real-time planning 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 work with the slave MPC controllers 304a-304n to optimize the plant and generate the best achievable plan while complying with all unit constraints.

  The planning model 200 used by the master MPC controller 302 comprises 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). )). The master MPC controller 302 utilizes MPC feedback to increase the accuracy of offline planning optimization, thereby incorporating previously unavailable real-time information so that it is closer to the original plan for real-time understanding. 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 / characteristics control in a closed loop. This allows the master MPC controller 302 to execute in a closed loop, since the control and optimization solution from the master MPC controller 302 adheres to the operating constraints from the slave MPC controllers 304a-304n, and the MPC cascade. Enable. This is done while providing both centralized compact plant level optimization and unit level decentralized MPC control.

  The multi-variable control functionality of the master MPC controller 302 may correspond to a 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). , Refers to the cumulative amount of matter / energy / etc. In the expected 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 to 304n, or indirectly through the process controllers 306a to 306m (such as an RMPCT controller). Can be done. Each slave MPC controller 304a-304n can predict the "room" within the amount of change for each unit (via proxy restrictions described below), and the master MPC controller 302 cannot accept the unit You can refrain from requesting a change amount. Master MPC controller 302 may further include CVs 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 another 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 a controller with another number of inputs and outputs.

Proxy Restrictions 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 adheres to 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 multi-scale models. Proxy restrictions are an alternative representation of the constraints of the slave MPC controller in the space of the master MPC controller. Proxy restrictions may be displayed as conduits between individual slave MPC controllers and the master MPC controller to "transfer" slave MPC controller constraints to the master MPC controller. Proxy restrictions from multiple slave MPC controllers 304a-304n may be combined and included in the control and economic optimization formulation of the master MPC controller.

  Proxy restrictions 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 travel before reaching their operating limits. be able to. If more than one MV from master MPC controller 302 is associated with slave MPC controllers 304a-304n, the proxy restrictions may be multivariate in nature.

  FIG. 4 illustrates an exemplary use of proxy restrictions in a cascaded MPC architecture according to the present disclosure. Specifically, FIG. 4 illustrates an exemplary use of proxy restrictions in a cascaded architecture for FCCUs, where one proxy restriction fully represents the entire unit. Assume that the FCCU raw material is configured as MV4 in planning model 200 for master MPC controller 302 and as MV9 in MPC model 250 for slave MPC controller 304a. Also assume that the current supply to the unit has a value of 33.5. Further, the slave MPC controller 304a determines that the feed rate will be 38.1 before the one or more slave CVs and / or MVs reach one or more limits, as shown in Table 402. Suppose we expect to be able to increase to the maximum value. Table 402 shows the various CVs controlled by slave MPC controller 304a herein and the various MVs used by slave MPC controller 304a to control those CVs. The maximum boundary value of 38.1 is accepted by the master MPC controller 302 and used as a high proxy limit for the master MPC controller MV4.

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

  One feature of the proxy restriction is that all slave MPC constraints in the unit can be made one or several proxy restrictions, removing unnecessary elements. Accordingly, the proxy restriction functions as a binding mechanism for the master MPC controller 302 to hold the coarse scale model 200 intact while effectively merging it with the fine scale slave MPC model 250. In other words, this means that the plant-wide optimization problem inside the master MPC controller 320 can be reduced to its original compact planning Allows to keep in form.

  With the help of proxy restrictions, an integrated optimization solution using a cascaded MPC approach offers various benefits. For example, the embedded real-time planning solution adheres to unit-level operating constraints on the slave MPC controllers 304a-304n, while the master MPC controller 302 uses ) Is dynamically controlled. Virtually all relevant MPC constraints in the unit are stripped of unnecessary elements and placed into one or more proxy restrictions, which in turn are included in the optimization of the master MPC controller. In addition, the proxy restrictions make the optimization of multi-layers more efficient than one layer. Further, the practice of manual adjustment or conversion of an open loop optimization solution can be reduced or eliminated. By cross-utilizing both the planning model and the control model online, the cascaded MPC approach enables real-time optimization of the entire plant in a closed loop control system. Thus, the cascaded MPC approach simultaneously provides centralized optimization with the coarse-scale planning model 200 at the plant level and distributed control with the fine-scale MPC model 250 at the unit level.

  Note that the concept of MPC cascading with proxy restrictions has been described as being performed with a Level 3 MPC controller as a slave controller. However, this concept can be used at, or extend to, various levels of control and automation systems. For example, a master MPC controller in multiple cascaded architectures 300 in a plant can form a slave MPC controller for a plant-level master MPC controller. As a specific example, a plant-level master MPC controller for an oil / gas refinery may use simple yield vectors (crude oil as one input feedstock, refined product as multiple output feedstocks). Similarly, a plurality of master MPC controllers at the plant level can function as slave MPC controllers with respect to the master MPC controller at the enterprise level. As a specific example, where different refineries are associated with different markets, an enterprise-level master MPC controller across multiple refineries may be based on regional product supply / demand and production capacity of each refinery. , The overall optimum 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 according to the present disclosure. GUI 500 includes various icons 502 that identify various units 202 in 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, expense structures, gross margins, each unit's contribution to that margin, and other relevant information pertaining to real-time execution of production planning. can do.

  The master MPC controller 302 also allows the operator to easily identify which units are obstructing the entire plant by looking at the proxy restrictions of those units, within the GUI 500. If the unit 202 has at least one valid proxy limit, this is a total impediment, such as when the throughput of the unit 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 failed unit and may indicate the increase in profit that the plant can achieve if the throughput of the unit is increasing.

  An operator (such as a production manager or planner) can use the GUI 500 to drill down to the failed unit. For example, when a particular icon 502 is selected on the GUI 500, an MPC model 250 for the selected unit 202 may be displayed to an operator. The displayed MPC model 250 corresponds to the GUI of the slave MPC controller, showing the effective constraints currently limiting 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.) may be identified using indicators 506 (such as colored circles). When 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 to display a maintenance GUI 508 for that valve. The maintenance GUI 508 can indicate that the valve is scheduled for maintenance within two weeks. Like the master MPC controller 302, the slave MPC controllers 304a-304n provide the additional gain that the plant can achieve if the constraint is removed (which in turn is expected to help increase throughput). May be displayed next to each active constraint in the table 402.

  In complex installations, there are typically a series of actuators and other equipment that need to be addressed at any given time. Maintenance personnel often do not have the appropriate guidance to prioritize their maintenance activities. The same is true for APC maintenance work and other maintenance work. In the method shown in FIG. 5, each maintenance operation can be tagged with an incremental 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 long periods of time, since no one knows the price of not repairing those items. In the case of the multi-layer control system GUI, maintenance tasks can be easily sorted by their economic impact, and a new, economy-centric, automated maintenance framework can be established.

Contribution Values and Contribution Costs Referring back to FIG. 2A, as shown above, the process units 202 shown in the planning model 200 generally include 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-304n may use contribution values and / or expenses when performing their control or optimization operations.

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

Here, n represents the number of final products that can be produced using the intermediate products. Also, Contribution _i represents the proportion of intermediate products dedicated to producing the i-th end product, and ProductPrice _i represents the predicted or current market price for the i-th end product. In addition, FurtherProcessingCost _i represents the additional processing cost required to produce the ith end product (optional, may be omitted or set to zero).

  In another embodiment, the contribution value of the intermediate product is calculated as follows.

Here, the product price for the ith end product may be adjusted to make corrections for various overproduction and underproduction scenarios, or other situations. For example, if the planned production of the i-th end product exceeds that plan, the price of the end product can be reduced, taking into account storage costs and future order risks. If the planned production of the ith end product is below that plan, the price of the end product can be increased if there is a penalty for not meeting the deadline for the order.

  Also note that various adjustments can be made to the contribution values. For example, where storage is possible, usually expensive intermediate products are stored and retained (rather than reducing their contribution in the current period) for the next planning period. As another example, if excess intermediate products can be sold in the spot market, higher contribution values can be assigned to intermediate products. Further, it should be noted that the contribution values can be tied together for the current planning period and for the next planning period, which can help reduce undesirable reduction of the horizon effect at the end of the current period. .

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

Here, m represents the number of raw material products used to produce an 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. In addition, UpstreamProcessingCost _i represents the processing costs required to process the i-th raw product and produce an intermediate product (optional, may be omitted or set to zero).

  In other embodiments, the contribution 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 the i-th raw material product exceeds its planning or storage capacity, its adjusted costs can be reduced to promote consumption. If the planned inventory of the i-th raw product is below its planning or storage capacity, its adjusted costs can be raised to reduce consumption. Also, note that various adjustments can be made to the contributing costs. For example, if the adjusted cost of a raw material product is higher than its spot market price, an “in-house vs. external procurement” may be used 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 the present disclosure. In this example, the master MPC controller 302 converts (i) contribution values and contribution costs based on the planning model, its economics, and data from previous iterations into (ii) contribution values and contribution costs and proxy values. It operates to repeatedly determine the yield of prediction based on the prediction yield. Contribution values and contribution costs may be provided to slave MPC controllers for their local optimization needs. When an optimal solution (such as an optimized plan) is found, the master MPC controller 302 provides optimized economics to the slave MPC controllers 304a-304n. Additional details regarding the operation of master MPC controller 302 in connection with using contribution values may 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, planning model 200 for master MPC controller 302 may be formed using one or more base models. For example, two base models (a processing unit model and a pool tank model) may 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.

  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 may be used for the mass balance between one input raw material and multiple output products.

Where y _i is the base yield for the ith product and Δy _i is the vector (of m ₁ elements). Also,

Where vg is the volume gain, where

This model type corresponds to the structure commonly used in planning models. Strictly speaking, this model form is not a linear model such that it has linear dynamics with quadratic gain. The model has one input raw material per unit, and each property of the output product has a time constant and delay similar to the product draw. Table 2 shows the steady state gain matrix for one raw material flow, which 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 ith property of the input raw material to the ith property of the jth product.

Where G _cj is the vector (of m ₂ elements) and G ⁰ _J is the “pass” DV gain. This approach assumes that the properties of the product have similar time constants and delays as the product draw, and that each property can be set to the same value by initialization. This approach also assumes that the properties can be affected (or controlled) by the MPC controller. Table 3 shows the steady state gain matrices for both material flow and properties of one raw material, which can again naturally span multiple raw materials using the same approach.

  Various techniques may 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 brief step-by-step tests, or estimated during operation. Bias updates and yield verification may also occur, such as when the processing unit's lumped yield (rather than base yield) is updated in real time. Various error correction schemes may also be used in the master MPC controller planning model. In a first error correction scheme, the yield can be calculated directly from the input flow, and the average yield (within the past time window) can be calculated 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 concentration yield value is updated. Gain updates can increase model prediction accuracy and verified gains can have better predictability in future concentrated yields. In a second error correction scheme, a bias update mechanism may be used to update the bias within the master MPC model prediction.

  FIG. 9 shows an exemplary modeling of a typical pool tank 900. Pool tank 900 represents a structure used to store materials (such as one or more intermediate products) manufactured in the facility. The storage tank 210 shown in FIG. 2A above is an example of a pool tank. A plurality of streams of material (Fin) flow into the tank 900, each stream having an r characteristic. Also, multiple streams (Fout) of the substance flow out of the tank 900, all streams having the same properties. The current volume is represented by V, and it can be assumed that input streams having similar characteristics are pooled together in pool tank 900. Note that the models described below are for tanks used to pool intermediate products and may or may not be suitable for blending of the final product. Also, other approaches (such as those using non-linear correction terms or non-linear blending methods) may be used, but the input stream should be just as sufficient so that the linear mixing rules are accurate enough for the measurement feedback. Note that this is possible.

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

The following equation may be used to represent the blending of the ith quantitative characteristic.

The following can be obtained using Laplace transform and rearrangement.

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

Table 4 summarizes the modeling of a typical pool tank.

The assumptions here include that the input flow varies more frequently than their characteristics and that the input-output variables can be measured appropriately (in an automated method or in a 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), where the base structure depends on how the units and tanks Brings flexibility in how they are connected. For example, processing units and pool tanks can be fixed after configuration, and inventory / characteristic status can be tracked dynamically. 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 the intermediate feedback as long as the intermediate input-output signal can be measured properly, and this approach is more natural in its structure to match the actual processing unit As such, improved model updates can be supported.

Model Verification Technique The master MPC controller 302 or other components 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 exemplary technique for validating a planning model in a cascaded MPC architecture according to the present disclosure. FIG. 10 shows the hierarchy of controllers and other devices 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-1004r, respectively.

  In particular, yield verification blocks 1004a-1004r support model verification including envelope calculations for material balances, energy balances, product properties or other modeling updates. The planning model can be verified by ensuring that materials, energy, or other factors are balanced in the model. Envelope calculations can be performed on weight or equivalent values, and the results can be presented in various units (such as weight or volume) based on user selection. Temperature / density correction factors can be used and values can be converted to common units (such as barrels or tons). The practices commonly used in material weighing in certain industries can be supported.

  In verification, various other design issues may be considered. For example, some measurements may be intermittent, inadequate, irregular, missing, deferred, or partially fictitious, and schemes (such as filtering or bias updates) Can be used to address various anomalies. Also, in some cases, the substance 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. Further, the yield of some streams may differ significantly from their "normal" value over time due to maintenance or abnormal process conditions, and again may be in any suitable way (such as user input). Based).

  Yield verification blocks 1004a-1004r may also support intensive yield bias update and yield verification as described above. For example, yield verification blocks 1004a-1004r can measure real-time yields and cross-validate them by adding material balances and volume / temperature corrections. Yield verification blocks 1004a-1004r 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 at a master MPC controller and a slave MPC controller in a cascaded MPC architecture, in accordance with the present disclosure. This technique allows the master MPC controller 302 to take into account the constraints of the slave MPC controllers 304a-304n during its operation. Note, however, that other approaches may be used.

  As shown in FIG. 11, master MPC controller 302 has an MV / DV index 1102 that identifies various MVs or DVs used by master MPC controller 302. The various CVs 1104 controlled by the master MPC controller 302 may 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 variables correspond to the same variables in both the master and slave MPC controllers (MV4 in the master controller as described above, MV9 in the slave controller, etc.). Conjoint variables can be configured as MV or DV at the master and slave MPC controllers.

  Master and slave CV constraints may be combined by associating a value at the MV / DV indicator 1102 with a corresponding value at the MV / DV indicator 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 plant-wide optimization of master MPC controller 302 to include some or all of the CV constraints from slave MPC controllers 304a-304b.

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

This CV constraint can be used as a CV proxy restriction at 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 the present disclosure. For simplicity, the method 1300 is described with respect to a cascaded MPC architecture 300 that can operate in the control and automation system 100. Method 1300 can 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 the 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) the slave MPC controllers can make any changes to their MV values without violating their constraints. You can request that In step 1308, the slave MPC controllers respond by sending proxy limits associated with those constraints to the master MPC controller. This may include, for example, the slave MPC controller identifying to what extent any changes can be made to their MV values and which constraints may 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 the proxy limits. This may include, for example, the master MPC controller combining proxy limits from multiple slave MPC controllers in a master MPC controller control and economic optimization formulation. At the same time, in step 1312, the MPC model is operated by the slave MPC controller during the control operation. This may include, for example, that the slave MPC controllers perform standard MPC functions whose functions are based on control and economic optimization formulations generated by the master MPC controller. In this way, at step 1314, an integrated planning / optimization and control function 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, while shown as a series of steps, the various steps in FIG. 13 can occur in duplicate, in parallel, in a different order, or any number of times.

Feasible Region Estimation FIGS. 14-18 illustrate exemplary techniques for generating a proxy restriction associated with a feasible region to support cascaded MPC according to the present disclosure. Slave MPC controller constraints can be incorporated into the master MPC controller planning operation 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 slave controller's CV constraints may be plotted in the master controller's MV space 1400. In general, slave controller MV limits appear as simple boundaries in the master controller MV space 1400, and slave controller CV limits appear as linear constraints. The executable region 1402 between these limits defines possible combinations of values that can be selected by the master MPC controller, while satisfying all constraints of the slave MPC controller. The shape of the executable region 1402 defined by the constraints of the slave controller is generally a polygon or a polyhedron.

  As shown in FIG. 15, if the free MV of the slave MPC controller takes any other value (for any reason), the shape of the executable region 1402 changes. Shaded bars 1502 show how these constraints can shift. Similarly, if the model gain of the slave controller is updated on the fly, the slope 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 executable region 1402 may be reduced, such as to executable region 1602 shown in FIG. This can be achieved if one wants to push the MV / DV of the master MPC controller in a given direction by making small changes at some point. In that case, only a band with a small feasible space is used. The high and low values of this executable region 1602 can be calculated by finding the proper position for the free slave controller MV. The maximum value may be calculated by a query optimization call from the master controller for the slave controller to maximize its MV2 value. The minimum value may be calculated by a query optimization call from the master controller for the slave controller to minimize its MV2 value. The maximization objective function may be augmented to include product contribution values and other local optimization components. In the case of contribution values, units may be pushed to more profitable yield profiles.

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

  Using the current MV point 1704, the master MPC controller can estimate the shape of the executable region 1702 as follows. In each of a 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 area 1708 that can be used by the master MPC controller when performing planning optimization. In this way, the master MPC controller helps ensure that the specified solution can be implemented by a 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 involving more than two directions, the master MPC controller can identify a multidimensional space within the executable area 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 related to the eight directions 1806 at 45 ° intervals. The results of these query optimization calls define an estimated executable region 1808 that may also be used by the master MPC controller.

  In some embodiments, the query optimization call 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 may make the eight query optimization calls shown in Table 5 with various values of the ^ct and ^dt values.

The first four calls in Table 5 can be used to make the query optimization calls shown in FIG.
Note that the query optimization calls shown in Table 5 define the directions to be at 45 ° intervals. 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 may be used as a proxy constraint by the master MPC controller as shown in FIG. For example, up to four proxy constraints may be used by the master MPC controller shown in FIG. 17, and up to eight proxy constraints may 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 foregoing approach provides a general method for estimating the executable space defined by the slave MPC controller's CV / MV constraints. This approach works regardless of the actual executable space of the slave MPC controller or the number of constraints on 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 area 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 boundaries, and a query optimization call can be specifically made to represent the CV constraint. Here, the query optimization call may be defined as shown in Table 7.

here,

Is defined as the null space of a _j .
Although only one or two conjoint variables have been described above, it should be noted that the techniques 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 workable area defined by those constraints. Although the CV / MV limits of the slave MPC controller are shown here as being plotted in two dimensions, it should also be noted that the executable area for the slave MPC controller can be defined in more than two dimensions. Query optimization calls can be made in three or more dimensions to define a multidimensional space that estimates a multidimensional executable region.

  FIG. 19 shows an example method 1900 for calculating proxy restrictions to support cascaded MPC according to the present disclosure. Specifically, the method 1900 can be used at the master MPC controller to estimate the feasible area of the slave MPC controller. As shown in FIG. 19, the current operating point of the slave MPC controller is identified in step 1902. This may include, for example, a processing device within 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, a step in which a processing device in the master MPC controller 302 selects a predetermined direction or a direction perpendicular to a 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 to what extent one or more MVs of the slave MPC controller can be pushed in step 1906 in the selected direction, and to what extent the slave MPC controller A specific indication that one or more MVs of the controller can be pushed in the selected direction is received at step 1908. This is because, for example, the extent to which the processing device in the master MPC controller 302 has been selected by the slave MPC controllers 304a-304n without violating the constraints and without receiving a particular indication from the slave MPC controllers 304a-304n. It may include requiring the slave MPC controllers 304a-304n to specify whether one or more MVs can be pushed in the direction. In other words, the slave MPC controllers 304a-304n specify their proxy restrictions in the selected direction. If there are more directions to be tested in 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 executable area is generated at step 1912. This may include, for example, a processing device within the master MPC controller 302 identifying a multidimensional space defined by proxy restrictions from the slave MPC controllers 304a-304n. The feasible region of this estimation is used by the master MPC controller to identify a planning optimization solution at step 1914. Since the estimated executable area identified by master MPC controller 302 is within the actual executable area associated with slave MPC controllers 304a-304n, the solution identified by master MPC controller 302 is 304n will be executable.

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

Conclusion The present 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 the planning model to control production inventory, manufacturing activities, and product quality inside the plant. The slave MPC controllers provide their future predictions and operating constraints to the master MPC controller, such as through proxy restrictions. Real-time planning solutions embedded in a multi-layer MPC cascade adhere to lower-level operating constraints and no longer need to be converted manually. By cross-utilizing both the planning model and the control model online, the MPC cascade architecture performs real-time plant-wide optimization in a closed-loop control system and provides just-in-time production planning through a slave MPC controller. Allows you to carry out automatically. In addition, techniques are provided for enabling the master MPC controller to estimate the executable area 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, various functions described in this patent document are implemented or supported by computer programs formed from computer readable program code and embedded in computer readable media. 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” is read-only memory (ROM: Read Only Memory), random access memory (RAM: Random Access Memory), hard disk drive, compact disk (CD: Compact Disc), digital video disk (DVD: Digital) Includes 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 transitory electrical or other signals. Non-transitory computer-readable media include media on which data can be stored permanently and media on which data can be stored and later overwritten, such as rewritable optical disks or erasable memory devices.

  It may be helpful 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, associated data, or appropriate computer code (source code, object code). , Or executable code (including executable code). The term "communicate" and its derivatives include both direct and indirect communication. The terms “include”, “comprise”, and derivatives thereof, mean inclusion without limitation. The term “or” is inclusive and means “and / or”. The phrase “associated with” and its derivatives include, include, be included in, interconnect with, include, be included in, connect to, or connect with, Is associated with, is capable of communicating with, cooperates with, co-arranges, juxtaposes, is in proximity to, has, is associated with, has, has characteristics of, to Or mean having, or including the like. The phrase “at least one of (at least one)” when used in a list of items, may be used in various combinations of one or more of the listed items, and only one in the list. It 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 of the combinations of B and C.

  Although this disclosure has described certain embodiments and methods generally associated therewith, modifications and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of the exemplary embodiments does not define or limit the present 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 (5)

Sending a plurality of query optimization calls from a master model predictive control (MPC) controller to a slave MPC controller, wherein each query optimization call is associated with a different one of a plurality of directions in a variable space. things and,
Receiving information from a slave MPC controller at a master model predictive control (MPC) controller in response to each of the query optimization calls, the information being transmitted to the slave MPC controller by a process of the slave MPC controller. without violating the variable restriction, to what extent, in the variable space, each of the manipulated variables of the plurality of operation variables, indicates whether it is possible to change in a direction corresponding to each of the query optimization call, the A variable space including a first executable region defined by the process variable constraints ;
Estimating a second executable region associated with the slave MPC controller using the information, wherein the second executable region determines that a combination of manipulated variable values of the plurality of manipulated variables is the process variable; Identifying a portion of the first executable region that satisfies a variable constraint;
Performing a whole plant optimization at the master MPC controller using the second executable region, wherein the solution generated during the whole plant optimization is the second executable It comprises one of a combination of the manipulated variable values in the region, and a step seen including,
Receiving the information comprises receiving a proxy limit from the slave MPC controller in response to the query optimization call;
Each proxy limit specifies a maximum distance in one of the directions in the variable space within which the slave MPC controller can change the manipulated variable without violating the process variable constraints;
The proxy limit value in the variable space of the master MPC controller resulting from transferring a limit value associated with the process variable constraint of the slave MPC controller to the variable space of the master MPC controller. The limit value,
Method.   The method of claim 1, wherein the plurality of directions are defined with respect to a current operating point associated with the slave MPC controller, wherein the current operating point defines a particular point in the variable space. Identifying at least one of the plurality of directions,
The method of claim 1, wherein at least one of the plurality of directions comprises a direction substantially perpendicular to a linear variable limit associated with the slave MPC controller. A master model predictive control (MPC) controller, wherein the MPC controller comprises:
Sending a plurality of query optimization calls to a slave MPC controller, wherein each query optimization call is associated with a different one of a plurality of directions in a variable space;
Receiving information from the slave MPC controller in response to each of the query optimization calls , wherein the information indicates that the slave MPC controller does not violate process variables constraints of the slave MPC controller. extent in the variable space, each of the manipulated variables of the plurality of operation variables, indicates whether it is possible to change in a direction corresponding to each of the query optimization call, the variable space, by the process variable constraint Including a defined first executable region;
At least one network interface configured to perform
Using the information to estimate a second executable region associated with the slave MPC controller, wherein the second executable region is such that a combination of manipulated variable values of the plurality of manipulated variables satisfies the process variable constraint. , Identifying a portion of the first executable region ,
Using said second execution region performs optimizations of the entire plant, solutions that are produced during the optimization of the whole plant, the combination of the manipulated variable value of the second executable area including one of the,
At least one processing device , configured to :
With
The at least one processing device is configured to receive a proxy limit from the slave MPC controller in response to the query optimization call;
Each proxy limit specifies a maximum distance in one of the directions in the variable space within which the slave MPC controller can change the manipulated variable without violating the process variable constraints;
The proxy limit value in the variable space of the master MPC controller resulting from transferring a limit value associated with the process variable constraint of the slave MPC controller to the variable space of the master MPC controller. The limit value,
apparatus. A non-transitory computer readable medium comprising computer program, said computer program comprising computer readable program code, the computer readable program code is executed, to at least one processing device,
Sending a plurality of query optimization calls from a master model predictive control (MPC) controller to a slave MPC controller, wherein each query optimization call is associated with a different one of a plurality of directions in a variable space. things and,
In response to each of the query optimization call, comprising the steps of receiving information from the slave MPC controller by the master model predictive control (MPC) controller, wherein the information, the slave MPC controller, said slave MPC controller Without violating the process variable constraints, to what extent in the variable space, each manipulated variable of the plurality of manipulated variables can be changed in the direction associated with each of the query optimization calls. shown by the variable space, said defined by process variable constraint, the steps comprising a first feasible region,
Estimating a second executable region associated with the slave MPC controller using the information, wherein the second executable region is a combination of the manipulated variable values of the plurality of manipulated variables is the process variable. Identifying a portion of the first executable region that satisfies a constraint;
Performing a whole plant optimization at the master MPC controller using the second executable region, wherein the solution generated during the whole plant optimization is the second executable Including one of the combinations of the manipulated variable values in a region ;
And execute
The information includes a proxy limit from the slave MPC controller;
Each proxy limit specifies a maximum distance in one of the directions in the variable space within which the slave MPC controller can change the manipulated variable without violating the process variable constraints;
The proxy limit value in the variable space of the master MPC controller resulting from transferring a limit value associated with the process variable constraint of the slave MPC controller to the variable space of the master MPC controller. The limit value,
,
Non-transitory computer readable media.

Images