Multivariable control has become an enigma. On one hand, it is logically the centerpiece of process control—veritably “the robotics” of process automation. But on the other hand, even as parallel process control technologies, such as alarm management, safety systems, and cybersecurity, continue to evolve swiftly, multivariable control’s progress stalled sometime in the past decade. This is all the more puzzling because several basic multivariable control issues, such as cost, maintenance, and performance, remain unresolved, and many potential applications remain to be addressed—the “application gap.”

This post does not endeavor to explain exactly where industry now finds itself, but only to put forth some of the features of the multivariable control landscape that have emerged with experience, especially where those features are ambiguous or unexpected relative to original industry expectations. With a more accurate picture and wider shared understanding of the prominent features of the multivariable control landscape, hopefully forward progress may resume.

What is advanced process control?

In recent decades, the term advanced process control (APC) has often been used synonymously with model-based predictive multivariable control (MPC), but for the purposes of this post, and for the purposes of moving industry forward, it helps to maintain distinctions.

Advanced process control is an umbrella term that can refer to any of a number of process control technologies and techniques. Functionally, advanced process control is best defined in contrast to basic process control. Basic (or base-layer) controls are normally part of initial plant design, construction, and commissioning, to facilitate basic plant operation, automation, and reliability. Advanced process controls, on the other hand, are most often added after the plant is up and running, often over the course of many years, to address economic or operational improvement opportunities that become apparent in the course of ongoing operation.

In terms of tools or technologies, APC comprises many, of which multivariable control is one. Other advanced control techniques include advanced regulatory control (ARC), inferential control, and sequential control.

What is multivariable control?

Multivariable control is usually viewed as something new, complex, and powerful. It is usually explained in terms of its technology (its models, control solver, and optimization methods), rather than in terms of the automation role it actually fills in industrial process operation. Consequently, from operators to managers, and even to control engineers themselves in many cases, people have often misunderstood exactly the role and value that multivariable control brings to process operation.

With the benefit of several decades of experience, multivariable control can now be widely understood in a more practical, even obvious way. This will help operators understand and use it more effectively. It will help managers and decision-makers better understand its role, value, and limitations. And it will help control engineers design and build more effective and reliable controllers.

Multivariable control is not new. It is as old as industry itself (much older than computers). Multivariable control has always been a prominent aspect of essentially every industrial process operation. Operators adjust valves and controllers to keep processes within constraint limits, to (locally) optimize economic performance, and—this aspect has been crucially missing from most discussions—to ensure process reliability (i.e., to avoid or minimize the risk of a process upset or abnormal situation).

That is the essence of multivariable control. It is mainly carried out by operators, who may be thought of as “boots on the ground.” But overall strategy and tactics are the product of the greater operating team, especially including production planners and process engineers, but also including nearly every other group whose areas of responsibility may intersect with ongoing operation, such as maintenance, equipment reliability, and process technologists. Constraint limits and operating tactics can be highly dynamic and may change or be updated hourly or daily from throughout the operating team. Multivariable control may or may not be partially automated in the form of an MPC application, but it is a prominent, dynamic aspect that is ongoing 24/7 in essentially every industrial process operation.

An important aspect of this generic functional definition of multivariable control is that it is independent of the technology or methodology being employed—manually by the operating team, automatically by a model-based controller, or automatically by a “model-less” controller, which is an alternative emerging technology. For example, the iconic multivariable control “constraint corner” diagram shown in figure 1 is recast as the difference between automated versus manual multivariable control, with benefits accruing by function, not method.

Figure 1. Automated multivariable control brings the usual automation benefits of greater consistency and timeliness, plus the traditional multivariable control benefits of increased capacity, efficiency, and quality. These benefits derive from reliably closing the constraint control and optimization loops, although not necessarily from using models to do so.

Is multivariable control “optimization”?

Multivariable control is often described as optimization, but this does not help operators, engineers, and managers understand its role or value, or distinguish it from other technologies that claim this term. Possibly the best term for multivariable control is local optimizer. In mathematics, a local optimizer finds an optimum that is geographically nearby or is based on only a subset of relevant inputs, and care is always taken to distinguish a local optimum from a global one.

Local optimization is an important and appropriate part of multivariable control, because the nature of multivariable control mechanics is that it normally has “left over” degrees of freedom (after first tending to constraint control) that can be readily applied toward optimization. Albeit local, this optimization can be operationally and economically important and worthwhile.

That said, multivariable control automation is partial and its optimization is local, so that it is a mistake to conflate it with the much larger job being carried out by the greater operating team. Automated multivariable control is limited to the subset of inputs available to the controller, which are limited to measured variables (those with transmitters), local variables (those available to the local distributed control system), and known variables (the greater operating team fields a continuous stream of asynchronous unplanned inputs from throughout the plant organization).

Traditional multivariable control practice has basically tried to mitigate this limited geographic horizon by adopting the “big matrix” design practice, wherein nearly all identifiable inputs are included in the matrix. But MPC continues to struggle with “degraded performance.” Experience now suggests it is caused in part by including many inappropriate inputs in the matrix, such as those where immediate automatic response to a constraint violation is operationally undesirable, (i.e., “managed” variables versus “controlled” variables). This suggests that industry might be better off taking a “small matrix” approach, wherein only key variables, well-known and proven in existing operation, are included, resulting in more targeted, reliable, and intuitive performance.

Efforts to implement a less partial (i.e., “rigorous”) and less local (i.e., “global”) optimization, often known as real-time optimization (RTO), are ongoing at many plant sites and enterprises across industry. RTO attempts to automate, to the extent possible, the full optimization scope of the greater operating team (although asynchronous, unanticipated, and human-derived inputs will most likely always comprise a large part of the solution). RTO is implemented on the business side of the computer network, but also normally depends on a healthy multivariable controller on the control system side, in order to honor actual dynamic process and equipment constraints. RTO may automatically write to some of the optimization targets and constraint limits of the multivariable controller. This was once expected to become very common, but as yet in industry it remains very rare. More often, today’s RTO results are passed down to operation via the human chain of command as updated operating instructions.

Another way to appreciate the scope and value of multivariable controller optimization is to notice that few people refer to it as optimization when it is being carried out manually by the operator, without the aid of an automated multivariable controller. Yet, an operator has a much wider geographic horizon and greater number of available inputs than an online controller, by virtue of access to business network tools and direct communication with the greater operating team, including the chain of command, process engineers, and field operators. Automated multivariable control has the virtue of responding in a timely and consistent manner to the key constraints and optimization variables that are made available to it. This emphasizes the wisdom of including key variables in an automated multivariable controller, rather than all variables.

Multivariable control performance

Multivariable control performance, maintenance, and cost, which are all closely related, have posed continuing ownership concerns. The majority of industry’s installed MPC applications have “poor” performance, but a discussion and understanding of degraded performance has been mostly absent. The wider community seems reluctant to directly confront these issues, which have now persisted for decades, resulting in today’s “enigma.”

Degraded performance is basically a syndrome (a set of incompletely understood causes and symptoms) characterized by “clamped” manipulated variables (MVs), detuned control action, and many variables out of service. The problem is exacerbated by the large number of variables caused by big-matrix design practice, which often render multivariable controllers unintuitive to operators—producing a disconnect between manual and automated multivariable control, rather than a congruence. This has led to yet another emerging concern—operators who have not learned (or have forgotten) how to control and optimize their unit when the multivariable controller is unavailable or turned off.

Development of performance metrics has also stagnated, even as, by contrast, industry has widely adopted an entire suite of alarm management metrics in half the time. The majority of end-user sites still rely solely on “service factor” (simple on/off status), but the community has long realized that this metric is largely meaningless (a controller can be on, but not doing anything). Moreover, the typically high service factor values this metric reports would probably be much lower if abandoned applications were kept in the math. A limited number of end users have forged ahead with additional, more meaningful metrics, such as MV utilization, but few best practices have emerged to help users increase utilization. The author, who first published this metric in 2005, believes the low values for this metric are essentially telling industry that the lion’s share of multivariable control benefits could be captured more reliably by using small-matrix design practice.

The author also believes that performance and maintenance issues are rooted in aspects of model-based technology (such as dynamically changing models) and practice (such as big-matrix practice) that were adopted by industry early on and have not been appropriately revised based on experience. When this eventually takes place, the issue of performance will resolve itself and cease to be a major ownership concern. A basic requirement of any controller or any piece of process automation is reliability, responsiveness, stability, precaution, and intuitiveness, or, as the author has summarized it, “operational” performance (figure 2).

The APC application gap

Figure 3 illustrates the APC application gap. This area is a gap because it is not well served by existing tools or technology. ARC has all but disappeared in the wake of MPC, but MPC did not expand to fill this gap as it was expected to, due to its continuing high cost and complexity of ownership issues. Consequently, for the past couple decades, applications in this range have often gone unpursued or have stagnated in the planning and budgeting pipeline. They often represent a missed opportunity or continued unrealized operational improvements.

Figure 3. The APC application gap results because applications in this size range are not well served by any existing tools or technology. ARC all but disappeared in the wake of MPC, but MPC never expanded into this range due to persisting high maintenance and cost of ownership issues. An agile and affordable tool to address the many applications in this range would be a boon to industry.

A version of this article also was published at InTech magazine.