Modeling and Control

Training an operator on a new control system often includes hands on experience with a training system that supports dynamic process and control system simulation. The hardware for such a training system may be constructed using spare parts from the new control system. A simple simulation of the process can often be implemented using the control system tools provided to configure calculations and logic. The plant control strategies and operator interface should be used without change when create the training system. However, one of the barriers in doing this is the fact that the IO configuration used for measurement, calculations, and control strategy may need to be modified to work with a process simulation. As the Foundation Fieldbus team worked on the function block specifications, one of our objectives was to provide an easy means of integrating process simulation into measurement and control applications. Also, the ability to override IO values was something we felt that an instrument technician or control engineer would find helpful in checkout of a control strategy or a display configuration.

After some investigation, the function block team proposed that a SIMULATE parameter
be included in all IO blocks. This parameter was defined to have the following attributes:

 Simulate Enable/Disable
 Simulate Value
 Simulate Status
 Field Value
 Field Status

The actual measurement value and status of the IO block are reflected in the Field Value and Status. When the Simulate Enable/Disable attribute is changed to Enable, then the IO function block uses the Simulate Value and Status in place of the Field Value and Status. Thus, an instrument technician that is checking out a control strategy before startup can simply Enable simulate and then write to the Simulate value and status attribute. In the IO blocks, the simulated value and status are processed the same as the field element signal. Thus, when a process simulation writes calculated measurement values and status to the Simulate Value and Status attributes of IO blocks then values based on these simulated measurements will appears in the control strategy and operator screen.

When the function block team initially presented the Simulate parameter to the Fieldbus Foundation Technical Advisory team, there was much discussion about whether we should including this capability in field devices. The concern was that, in an on-line system, the operator would not know if the measurement he sees at his interface station is simulated or the true measurement value. To address this concern, the function block team added to the specification the requirement that all Foundation fieldbus devices support a physical jumper that can be used to disable the simulation capability in an on-line system. Also, an explicit alarm was added to BLK_ERR that indicates when simulation is enabled. By taking these steps, the function block team was able to include SIMULATE as a standard parameter in Fieldbus Foundation IO blocks. This capability has proven to be very valuable in system check and in enabling the development of operator training systems.

My favorite “Far Side” cartoon has Einstein at a chalk board full of derived equations ending up with the ultimate equation “time=money.” In my mind, the negative free time of the process control engineer places some doubt as to whether this endangered species still exists. There have been sightings but the uncertainty principal says we can only ascertain their location or function but not both.

Experimental models do a good job of minimizing the time and expertise required of process control engineers by not relying upon process knowledge. Since these models are identified from test data, they are consistent with the ultimate goal of matching reality even if process understanding lags behind. Each technique excels at addressing a particular aspect. For example, Neural Networks (NN), Projections to Latent Structure (PLS), and Model Predictive Control (MPC), excel at identifying the nonlinear, interdependent, and dynamic, respectively, nature of process inputs. The strong point of one method is often the weak point of others and in the end somebody with some sort of process understanding should check to make sure the models make physical sense. There are several watch outs. For example, avoid extrapolation by a NN outside of its training data range because nonlinear relationships can take off exponentially. Since PLS and MPC assume linearity, you have to be careful about deviating too far from an operating point to the point where turndown and startup may require the identification and switching of different models. NN and PLS don’t try to model the process time constant or integrating process gain, so there is a model mismatch for well mixed volumes where the residence time translates to a process time constant or a “near” or “real” integrating process gain. Also, NN and PLS are often sold based on just throwing existing historical data at them ignoring the transfer of variability by closed control loops and not perturbing process inputs. The richness of the dynamics, the rangeability, and the identification of cause and effect suffers. What has been so important to the success of MPC, seems to have been lost

What about all the other types of models?

Tiebacks are very attractive because they initially require hardly any effort. They can be automatically generated from the configuration. These are great for control system familiarization and interface improvements (e.g. operator training and critiquing of graphics) and I/O checkout. They can be used to mimic the process response by the heuristic customization of ramp rates triggered by piping path logic to test out the configuration, particularly important for complex continuous and batch control systems.

Finally, there are the models based on chemistry and physics (not necessarily popular subjects). Very sophisticated software has been developed to provide a graphical flow sheet simulation of processes. Unfortunately, these generally require a sophisticated budget and user. Most of the big players focus on continuous steady state operation, the traditional realm of chemical engineering programs. Separate special purpose packages are typically required for batch. My experience with "state of the art " process modeling software is that they do a good job of process design but are not as good as you might expect in showing the process dynamics especially considering they carry the label “high fidelity”. The process gain is off because the installed characteristic of the control valve and measurement scale are not included, the process dead time is too small because transportation and mixing delays are missing, and the process time constant is too small because thermal lags and jackets/coils are missing. To top it off, the trends are way too smooth because there is no mixing or sensor noise and no limit cycles from control valve stick-slip or backlash. For more enlightenment on the issues with dynamic process simulators see the Control magazine August 2005 article titled "The Light at the End of the Tunnel is a Train (Virtual Plant Reality)".

When you sit back (something I am getting better at being partly retired) and look at the whole picture, it seems fractured.

Why aren’t there basic generic first principal models that focus on the process dynamics without getting bogged down in the complexity needed for process design? Why aren’t there hybrid models that take advantage of the best of what each method has to offer? What would we call these models that provide the type of fidelity needed for process control? Are we stuck in a rut because each expert thinks their particular method is best? Are there people with broad enough skills and attitude to pull it off?

The virtual plant offers a break through in training and knowledge discovery but its potential depends upon the ability to develop dynamic simulations that capture the process relationships and response important for process understanding and control.

The best practice of practical real time simulation could easily fill a book but I need to wind this up and move on to other opportunities so here are a few ideas on how to make a process model more flexible in terms of cost and performance and maintainability. It is important to realize the art of simulation is simplification to what is essential.

A significant portion of the time is spent trying to decipher the intricacies of a plant’s DCS configuration and displays. If there is an accurate P&D with the relative location of every pump, fan, valve, and measurement noted along with the complete DCS tag name, and there is browser access to each tag name to assign DCS outputs as process inputs and process outputs as DCS inputs in the model, the need to dig into the configuration is vastly reduced. Note that special DCS I/O such as pulse counts must still be identified and separately addressed.

The computational requirements, numerical hazards, and data requirements on the piping system and fluid flow of a pressure-flow solver are considerable. If there are flow loops for every throttle valve, then the complexity and cost of a pressure-flow solver may be avoided. Of course, this simplification will not identify improperly sized pumps, valves, and pipes. I propose it would be better to add imbedded flow loops in the process simulation rather then venturing into a pressure-flow solver. This simplified approach uses a combination of flow loops and a pathway methodology where the 1 or 0 status of on-off valves and pumps determine an open piping path. The total flow coming out of a piping tee can be written back as the flow going into the tee. The use of flow loops reduces but does not eliminate the need to simulate valve backlash and stick-slip. If a pressure-flow solver is deemed valuable, than I suggest a sequential modular method to avoid ill conditioned matrices and numerical problems during batch operations and the startup and shutdown of equipment.

If the model starts out with initialized but settable molecular weights, densities, and heat capacities, then levels, temperatures, blending, and temperature can be simulated. If the dissociation constants for bases and pH are added, then pH can be added. For the modeling of vaporizers and evaporators, it may be sufficient to add vapor pressures and boiling points of selected components as a function of composition. For reactors, the standard form of Arrhenius and Michaelis-Menten kinetics may be sufficient. Neural networks may be able identify kinetic rates to provide a simpler and higher fidelity hybrid model. The complexity of a full blown physical property package could be reserved for more complex vapor equilibrium problems such as distillation.

Finally, it is most important to get the dynamics right. The process models from on-demand and on-line tuning packages such as DeltaV Insight and model predictive controllers such as DeltaV Predict can be used to supplement or replace first principle models for specific parts of the process.

For my virtual plant experience and top ten list check out
http://www.controlglobal.com/articles/2007/385.html
http://www.controlglobal.com/articles/2007/359.html
and the “Education” and “Process Simulation” categories on this website.