The basics of model-following control
All feedback controllers are designed to eliminate discrepancies between the process variable and the setpoint. Model-following controllers do so by forcing the process variable to reach the setpoint along a specified trajectory.
The user specifies the desired trajectory by creating a mathematical model that represents an idealized process that would provide a more desirable response to a setpoint change if it could somehow be substituted for the real process. The controller then measures the model’s output rather than the actual process variable and tries to drive the model’s output towards the setpoint along the desired trajectory.
Doing so achieves the specified closed-loop behavior for the idealized process, but it does nothing for the actual process by itself.
A second controller is required to simultaneously force the actual process variable to match the model’s output, thereby forcing the actual process to mimic the behavior of the idealized process. If both controllers can achieve their respective objectives, the actual process variable will end up following the desired trajectory towards the setpoint.
How model following works
Figure 1 shows how this algorithm, known as “model following,” can be accomplished with two proportional-integral-derivative (PID) controllers. In the top loop, known as the “model loop,” the “model controller” applies its corrective efforts or “model control signal” to the mathematical model as if it were a real process. The model’s output is fed back and subtracted from the setpoint to generate the error signal that feeds into the model controller.
The model control signal is also applied to the real process with the addition of a “correcting signal” generated by the “correcting loop.” The error signal for this loop is the difference between the model’s output and the actual process variable. That difference is fed into the “correcting controller” to generate the correcting signal which is added to the model control signal. That sum serves as the control effort applied to the actual process.
The model controller is designed to achieve whatever trajectory the user wants the model’s output to follow in response to a setpoint change. This is a straightforward exercise since the behavior of the idealized process is already known, having been defined by the user. Any number of loop-tuning rules could be used to translate the gains and time constants of the idealized process model into tuning parameters for the model controller.
Tuning the correcting controller can be trickier, especially if the gains and time constants of the real process are unknown or time-varying. The correcting loop is also subject to real-world load disturbances plus artificial disturbances caused by the model control signal.
On the other hand, the correcting controller should not require precise tuning if the process is fast enough to quickly respond to the controller’s efforts. Discrepancies between the model output and the process variable will be short-lived anyway, which means the correcting controller’s tuning should be relatively unimportant.
An astute reader might wonder why the model controller is required at all. After all, the model loop in Figure 1 has no disturbances to counteract because the entire loop is a purely mathematical construct that exists only in the controller. The real-life disturbances that affect the actual process variable enter only into the correcting loop.
The model loop might as well be run in open-loop mode with the model controller and feedback path removed as shown in Figure 2. Re-arranging the remaining blocks into the layout shown in Figure 3 reveals this simplified model-following controller is actually a traditional feedback controller equipped with a setpoint filter and a feedforward path that treats setpoint changes as disturbances. For more on these control techniques see “The Basics of Numerical Filtering,” Control Engineering, October 2008, and “Understanding Feedforward Control,” Control Engineering, April 2019.
That’s not to suggest, however, any setpoint filter could be used to endow a feedforward/feedback controller with model-following capabilities. The filter’s input/output equation must represent the behavior of the idealized process. A noise-dampening filter wouldn’t work except by sheer coincidence.
The idealized process model is also not included in the feedforward path the way a feedforward filter might otherwise be configured when compensating for a measurable disturbance. To make figure 2 or 3 work as a model-following controller, there can be no filter on the feedforward path; only on the path leading into the correcting controller.
Choose one control
So which version of model-following control is best? Is it the original version shown in figure 1 or the simplified version shown in figures 2 and 3? That depends, in large part, on the designer’s expertise.
Both versions require process modeling and loop tuning skills. For examples of each, see “Models Aid Controller Design,” Control Engineering, March 2008 and “Loop Tuning Fundamentals,” Control Engineering, July 2003.
However, the performance of the original model-following controller depends less on the design of the idealized process model than the simplified version does. That’s because the model controller in figure 1 shoulders much of the responsibility for shaping the model loop’s response to a setpoint change. The idealized process model need not be as sophisticated or accurate in figure 1 as in figure 2 since the model controller can take up the slack if the model isn’t quite right. In figure 2, the model loop’s performance depends on the process model’s design.
All things being equal, a control designer who is more comfortable with loop tuning will likely find the original version of model-following control easier; a designer with more model design experience might find the simplified version easier. Designers experienced in both disciplines can design the correcting controller for optimal disturbance rejection and the mathematical model to achieve an optimal setpoint response. See “Disturbance-Rejection vs. Setpoint-Tracking Controllers,” Control Engineering, September 2011.
Model-following controllers have proven useful for applications where robustness is required. They tend to be less sensitive to behavior variations of the controlled process than traditional single-loop control strategies.
The user-defined trajectory feature also is beneficial for control problems where eliminating the error between the setpoint and the process variable is only half the battle. If the controller also must guide the process variable along a particular path on the way to the setpoint, model-following can help.
A robot arm, for example, must travel a prescribed path from point A to point B to avoid collisions. The oven temperature in ramp/soak heat-treating operation must rise at a prescribed rate. A self-driving car must stay on the road at all times on the way to its destination. In applications like these, the idealized process model is sometimes called the “trajectory planner.”
There also are applications where model-following control would not be particularly effective. If the actual process isn’t significantly faster than the idealized process, the correcting loop will not be able to keep the process variable on the desired trajectory. The worst case would be a process model faster than the process itself. A gain-only model, though simple to implement, would be the worst of all.
The model must be designed to make abrupt changes in the setpoint appear more gradual to the controller. If the actual process is slow, the model must be glacial. That can make the closed-loop system rather sluggish, but if it’s important to get the process variable to the setpoint without hunting or overshoot, model-following may be the best choice.
This Control Engineering tutorial was edited by Mark T. Hoske, content manager, Control Engineering, CFE Media and Technology, email@example.com.
KEYWORDS: PID, model-following controller
Model-following controller explained
Simplification of model-following controller
Do you have an application that could benefit from use of model-following control?