Comment

01 November 2002

Making the model react

By Dirk Thiele and Ron Ottenbacher

Simulation helps users understand the different process interactions.

Simulating controller performance before commissioning a process can cut commissioning cost tremendously. Through simulation, one can reduce the risk of control failures due to configuration errors and, most importantly, save time without disturbing the process.

This is true for proportional-integral-derivative (PID) controllers and especially true for multiple-input, multiple-output control applications one would like to simulate off-line before downloading in the field.

Overlooking the complexity of a multivariable control network as well as eliminating waiting time on slow processes are enough justification for the existence of today's simulation packets.

However, real savings are apparent when the simulation tool implements into the configuration tool, eliminating the need for a third-party product and the need for configuration of a simulation.

One can quickly manipulate the tuning to optimize control performance without maintaining one configuration for the simulation tool and one for the real process. Here are the requirements and implementation techniques for embedded, multivariable, model predictive control (MPC) simulations without configuration.

RETHINKING ASSUMPTIONS

In many applications it is desirable to simulate the general behavior as well as the performance of a control strategy before commissioning it. A number of PID loop tuning tools offer plots of simulated set point and disturbance changes.

When trying to simulate a multivariable process with many inputs and outputs, static response plots are not an option anymore. The best way to test the dynamic behavior of a multivariable system is a live and interactive simulation.

If the current process has been run under manual control or using PID networks, a user often doesn't have a complete understanding of all process interactions. Operating the multivariable simulation allows the user to verify the configuration and possibly rethink assumptions based on PID control experience before actually downloading the configuration to the field.

SIMULATE LOAD DISTURBANCES

This embedded tool allows the simulation of eight inputs and eight outputs without any extra configuration. A closed loop simulation "soft wires" with a mouse click and runs in a local workstation of the process system.

Soft-wired process blocks — a simulation

The simulation loop consists of three main parts: blocks. The MPC controller block initializes using the process model and controller matrix data. The controller works exactly like the controller function block that controls a real process.

The MPC simulator block initializes with model data from the model undergoing the test. The automatically identified process model goes here. By choosing different models that can change, one can create a model mismatch and get a feeling for performance degradation that could result from the drifting of plant characteristics.

The user sets up the noise generator block during the simulation to simulate the addition of unmeasured load disturbances. The unmeasured load disturbance value adds to the normal value and can individually enter as part of all controlled, constraint, and measured disturbance variables. After every execution of the loop, the simulation display refreshes, and any user entries process.

COMMISSIONING PROCESS

When implementing MPC, one follows an iterative procedure, from the defining and wiring of the function blocks to the final commissioning of a satisfactorily simulated control behavior. These steps may include the following:

• Setup of process I/O connections
• Identification of the process
• Creation of a process model
• Verification of the created process model
• Generation of a controller matrix that matches the verified process model
• Simulation of controller matrix against the verified process model or not-matching models
• Possible modification of process model and/or controller matrix
• Resimulation
• Commission of controller

Upon launching the simulation, the application plots the history as well as the predicted future responses of selected variables. The controlled, manipulated, constraint, and measured disturbance variables all appear on the same screen display.

The future area on the graph shows the predicted values over the next time-to-steady-state increment. Initial checkout can take place with the controller in manual mode. By changing manipulated variables manually, one can test whether the predicted future values deviate from the simulated process values that move into the historical trend.

The overall control performance can be simulated at real-time speed, but if a lengthy deadtime or time constant exists, one can select a faster than real time execution rate to speed testing. Alternatively, the execution mode can change to pause or single step to run slower than real time for detailed analysis.

Other tests can take place to determine relationships among constraint, manipulated, and controlled variables. A relationship exists when changing the set point on the controlled variable causes the manipulated variable to move, which normally results in pushing the constraint variable out of its limits.

When driving the constraint variables close to their allowable limits, one can observe how the working set point of related controller variables starts deviating from the operator set point.

This is the result of an optimization algorithm adjusting the set point to prevent future limit. If constraint limits or set points of other variables are manually modified, one can observe how the predictive trend of a constraint shows a future violation but then initiates corrective actions to prevent violation.

Simulation application

The past (history) is the grey area on the left. The predicted future is the yellow area on the right. The six colored lines are variables: controlled, manipulated, constraint, or disturbance

As with the constraint limit simulation, one can observe the effect of limited manipulated variables (e.g., an actuator reaches the end of its allowable range). One can select which one of the set points one would rather give up while maintaining others and observe the resulting performance instantly.

Adding unmeasured load disturbances determines how well the controller corrects the prediction and maintains control. Other signal generators include square wave and random noise.

Adding these generators lets users set up ramping of all possible values to determine effects. The signal generator values can save to memory for the next simulation and save when the signal generator temporarily turns off during testing.

After running the simulation, one might want to modify certain model or controller characteristics, such as step response gains and penalty factors in the configuration tool, without stopping the simulation application.

It is possible to switch among multiple simulations. When simulation with a new model takes place, a vertical line on the graph separates the simulation done on the previous model from the new model. The process model and/or controller matrix refresh in the algorithm, and the dynamic behavior resets, but all previous simulation results retain to memory to allow the comparison of the results from the new simulation.

IMPLEMENTATION CHALLENGES

The same function block software used in the controller during operation also runs in the simulation application. Sharing the code between these two different projects simplified the actual MPC algorithm development.

The final product represents a multivariable simulation tool for the control engineer as well as an MPC algorithm development tool for our software developers.

Running faster than real time presented several implementation challenges. Historical values just get added to the chart, but future values are added, then removed and readded after each sample because future values change entirely after every scan.

This can use a lot of CPU power at higher speeds. Decoupling the addition of historical and future values to the display solved this problem. The values recalculate every cycle but update on the display only once per second. For example, at 10 times real time, 10 new historical values add into the chart each second, but only one new set of future values updates.

Updating all historical data was another challenge. For example, when changing a set point, if displaying values on every scan while the values are ramping up is necessary, CPU limitations prevent running at speeds beyond 100 times real time. Displaying fewer values (for example, adding just every 100th value at 100 times real time), however, allowed speeds up to 2,000 times real time with reasonable CPU loading.

While implementing this sort of multivariable MPC solution can be a long, iterative process, the benefits of simulating with an altered process model eliminates the need for special configurations, and operator training proceeds without control or process hardware. IT

Behind the byline

Dirk Thiele and Ron Ottenbacher are software engineers with Fisher-Rosemount Systems in Austin, Texas.

Related Links