Greg: Unit operations are affected by other upstream and downstream unit operations. That’s why plantwide control is necessary, so unit operations work together toward the common goals of greater plant capacity utilization and efficiency. We’re fortunate to have Vivek R. Dabholkar’s insightful and extensive experience to provide practical techniques to eliminate compartmentalization of multivariable control.
He started as a pyrolysis modeler/APC engineer at Stone & Webster Corp. before working for Setpoint, a consulting firm acquired by Aspen Tech. Later, he was hired as the first employee at Applied Manufacturing Technologies. In addition, he has 15 years of operating experience as a senior staff engineer at ExxonMobil’s olefins plant in Baytown, Texas, and at ExxonMobil and Saudi Basic Industries Corp.’s (SABIC) joint venture, Kemya, where he improved bottom-line profitability by improvising and implementing plantwide dynamic matrix control (DMC) by more than $35 million per year. Following a short stay at Shell Polymers’ new cracker in Monaca, Pa., he improved the performance of the composite at Dow Chemicals by retesting and reidentifying the cold side of an olefins plant in Canada, enabling it to push-feed against changing backend plant constraints, making more than $10 million per year. He also improved Ineos’ olefins plant-2, substantially, making more than $2 million per year by improving two C2-splitter operations and substantially reducing bottoms ethylene loss and stabilizing 900# steam header within three months. He is currently an Independent APC consultant.
Vivek, what are the problems with many present approaches for plantwide multivariable control?
Vivek: Before we discuss a solution, it may be useful to discuss the sub-controllers in a large multivariable controller (MVC). Communication among sub-controllers in the same master controller is seamless. A sub-controller is just a software trick to turn off a group of manipulated and controlled variables, perhaps belonging to one distillation column in a distillation column train, with the stipulation that each manipulated variable can only be part of one sub-controller, while the controlled variables can be shared among more than one sub-controller.
Communication across standalone (separate) controllers (each of which may or may not contain sub-controllers) is strictly forbidden. Currently, no controller-context memory sharing is allowed. In short, what a furnace says an F-101 APC controller is doing can’t be known by an F-102 APC controller at the same point in time
Not all plants need a plantwide MVC. An olefins plant is an excellent example of how plantwide MVC can be exceptionally beneficial. In an olefins plant, control complexity is enormous. Typically, there are 10 or more furnaces, with two or three processing different feed-types, as well as recycle furnace(s) that process recycled ethane feed from C2-splitter bottoms. You can add to that the compressors/turbines, cascaded propylene/ethylene (sometimes methane refrigeration), a primary fractionator, quench water towers, and a distillation train consisting of five or six columns, and hydrogenation reactors. The scope is enormous. The combined scope may have upwards of 500-600 controlled variables and about 150 manipulated variables.
Greg: Why can’t there be a very large dynamic matrix control (DMC) for each furnace, refrigeration unit and column?
Vivek: This simply isn’t practiced due to the enormous scope and computational difficulty of real-time execution within one minute. There’s one place in the world, Kemya, that has the largest DMC with several sub-controllers in one application due to a smaller number of furnaces with less passes and complexity. It may seem very attractive to have such a well-coordinated application, but trying to simulate it with a DMC is quite a challenge due to the enormous size and sluggish simulator response.
Greg: What’s the next best approach for communicating among standalone MVCs?
This is where the composite linear program (CLP) comes into play, though it was later simply called “composite” when quadratic program (QP) replaced the LP. It was invented for DMC by the late John Ayala, and was implemented for the first time in Japan in the 1990s by Ayala and fellow Aspen Tech APC engineer Doug Raven.
History was made for the plantwide control of an olefins plant, so the front-end furnace feed could be pushed against the back-end distillation tower delta-P or compressor turbine constraints. If the feed limiting constraints are in the front-end (furnaces), the utility of composite is diminished considerably. The challenges must have been enormous based on what we know and take it for granted today. There were no double-precision control calculations or much appreciation for relative gain array (RGA)/singular value decomposition (SVD) analysis. You had to make sure to let a sick furnace to run DMC “ON,” but not participate in feed-pushing ability via composite.
The next challenge is to coordinate communication among different standalone controllers running at different offsets from the top of the minute cycle. The idea is to declare total furnace feed for each feed type as a feedforward (FF) in the backend, cold-side controller. Next, there’s the composite.ini file or equivalent to configure each back-end FF into a front-end furnace pass flow. Composite software would replace each curve relating to total furnace feed for each feed type by appropriate furnace pass flow, and this is how a plantwide controller gain matrix is set up internal to the software before solving for plantwide, steady-state targets. Next, each front-end controller’s entire move plan (not just the one time-step value) is passed on to the back-end controllers.
Things get lot more complicated if there are multiple feed types among different furnaces and if the same furnace can crack multiple feed types through a same pass flow tag at different times. This is either handled by Control Configuration File Switcher software (written by Ramesh Rao while at AspenTech) or by dynamic aliasing.
It’s possible in principle to declare a very large number of FFs, one for each furnace and feed type, and then turning off inapplicable FFs depending on individual furnace feed type making it a clumsy controller. However, it’s not possible in this Control Talk column to describe all the intricacies involved in composite implementation. One needs to work on a few composites to get a feel for it, and not just copy-paste from other sites.
Vivek, how do users implement feed pushing capability if they don’t have composite or can’t implement a very large controller?
Vivek: In this case, feed pushing capability is severely impaired. Most commercial control software, except PACE, has feed-pushing capability. A user must create dummy manipulated variables representing total feed of each feed type in the back-end controller. If front-end furnaces (due to lack of availability) can’t deliver maximum feed, then the dummy total feed (for chosen feed type) high limit or external target in the back-end controller must be restricted for each cycle. Also, the dummy total furnace feed steady-state target from the back-end controller must set the total feed for a chosen feed type for the front-end furnace controllers to meet, while none of them know each other’s steady-state targets unless communicated by external means. This is a total mess that’s uncalled for 2024.
Greg: What is a material balance controller and what’s its role in the composite?
Vivek: In most olefins plants, APC engineers want to take advantage of large feed-drums and column-bottom levels for the surge capacity, without extending the steady-state time of overall controller due to long level controller dynamics (if tuned to take advantage of surge capacity). I've witnessed many incorrect composite designs, where front-end, column-bottom levels or feed-drum levels are in a separate sub-controller. It becomes an issue when sub-controllers between the levels are “off” due to critical analyzer failure or some other process reason. In this case, material balance link between front-end feed and back-end constraints is broken, and composite can’t backout feed. For example, this can happen to a high DeEthanizer delta-P if the DeMeth sub-controller is “off,” and its level isn’t within a common material balance controller.
Greg: What about gap level controllers in a distributed control system (DCS) and their role in the composite?
Vivek: For levels controlled at the DCS due to small surge capacity or otherwise, a gap controller engages in different control action for large versus small deviations. What’s considered clever in a DCS control engineer’s mind can create issues with the workings of the MVC due to inconsistent, dynamic behavior that’s not accounted for in the controller dynamic models. It will lead to inferior MVC performance. Gap controllers can be eliminated without reconfiguring/downloading the loop by setting internal parameters appropriately.
Greg: How does a linear multivariable controller handle fast (front-end)/slow (back-end) dynamics, for example, in an olefins plant where composite/CLP is implemented?
Vivek: This was discussed in Control Talk, April ’23, “Machine learning, deep learning and nonlinear controls".
Greg: How does one push preferred feed on a preferred furnace type in composite?
Vivek: This important control problem didn’t have an elegant solution prior to 2000. Often, LP costs were adjusted to drive desired composite behavior. Though he remained unknown in publications, Doug Raven came up with the idea for a horizontal, “cone-shaped” composite ranking with feed type and furnace types on the x-axis and composite ranks on the y-axis. This new idea was first implemented at Huntsman Chemicals in Port Arthur, Texas, along with help from AspenTech consultant, Doug Robertson Jr. (now retired, who last worked for Marathon Petroleum).
The high limits for total feed were ranked in a downward-sloping line, starting from most preferred feed, so furnaces cracking most preferred feed would cut last when above the high limit due to large numerical rank (least preferred). The low limits were ranked in an upward-sloping line, so lower numerically ranked (most preferred) furnaces would get pushed first. When you think of this scheme in the context of total feed as a setpoint, it certainly creates uneasiness in the mind at first. However, the concept works like a charm, and is currently used by several practitioners, perhaps without knowing the originator! Preferred furnace type is another nuance imposed on “cone-shaped” rankings.
Greg: How does one avoid cutting lighter feed on furnaces for, say, delta-P constraints on distillation columns separating heavier molecules?
Vivek: Thermal cracking of ethane versus propane or heavier feed produces small amount of C3 and higher components. Since the total furnace feed “travels through” feed drum levels and column bottoms level to back-end columns, we can’t zero out lighter feed ramp models in the cold-side controller as it affects front-end columns significantly.
On the other hand, if we kept these models, then ethane furnaces would be yanked out of feed beyond recognition to control, for example, depropanizer delta-P while a small cut in propane feed would have been appropriate to address the issue. The solution is to search for a direct compositional model that has negative ramp rate on, say, DeEthanizer bottoms level from total ethane feed with the value of ramp rate, such that net change in DeEthanizer bottoms flow is zero. In other words, if thru-balancing of several ramps (feed drum levels, column bottoms levels) the net effect of total ethane feed on DeEthanizer bottoms level is R1 %/min/delta-flow, then the direct model of total ethane feed on DeEthanizer bottoms would be set to minus R1 %/min/delta-flow with, of course, appropriately estimated dead time and lag.
Often, these long dynamics models are very hard to identify, and some engineering judgement is required. Things would get lot more involved if, say, the bottom section tray-TC has a non-zero ramp rate model to column bottoms level, and would require detailed, closed-loop spreadsheet calculations.
