I describe the modelling presented on this website as “Real Enough” but what do I mean by this? It is an approach I have developed to allow quick generation of models that give me the information I need to do my job as a control engineer at a typical petrochemicals site. Note that when I say “I developed” I of course mean I have cobbled together the work of many others, pinching bits from here and there, adding my own ideas too and this has resulted in an approach that fits my needs.
Using “Real Enough” techniques allows me to quickly develop models that are good enough for the application I am looking at and from them I learn enough from to help me with the real world version.
As an example, here is the typical way I model a control valve. I grabbed this idea while watching a web-based lecture by the excellent Prof. Wolff of Michigan State University [Woolf 2006]
Take the flow range and multiply it by the characteristic e.g.
Flow through the control valve = Fmax * fn(x)
where fn(x) is the valve flow characteristic;
- f(x) = x for linear valve control
- f(x) = √ for quick opening valve control
- f(x) = Rx − 1 for equal percentage valve control
▪ R= valve design parameter (between 20 and 50)
This ignores the pressure differential but this approach can be “real enough” in situations where you are exploring control scheme ideas and concepts which is most of the work I use dynamic simulation for.
In fact, even if you had the inherent valve characteristics these will deviate from the installed characteristics due to the influence of other equipment. These could be modelled too but this all adds to the complexity. There are some situations where this is justified but there are also many real world examples where the extra effort would not be.
Here is an example of the difference between inherent and installed characteristics for a control valve [Wolff 2006];
Another example is the way I model the venerable PID control function. Most modelling platforms (MATLAB/Simulink, Scilab/Xcos etc.) come with a built in PID block that implements some kind of "control via error minimisation”, normally using a pure form of non-interacting gain, integral and derivative actions. None of these are like the ones on real control systems (I am most used to Honeywell’s AM/HPM PID algorithm) and they lack many of the extra features that are normally strong requirements in today’s control schemes (initialisation, proper anti-windup protection, equation selection etc.). However, I normally just use the “out of the box version” as it is “real enough” in most cases that I am interested in: all the extra functionality we have today in PID controllers is great and allows us to deploy more stable and more user friendly controls but at the fundamental level if a simplistic PID block won’t do the job then it is likely there is something wrong with the basic design.
So what kind of problems do I build models for? Well, it is almost always to answer one or more specific questions;
- Do I stand a chance of control scheme success with the equipment?
- What are the relative gains/sizes of the control scheme components?
- What kind of load disturbance can a particular scheme withstand?
- What parameters are the most sensitive?
What is wrong with the more rigorous modelling techniques? Why don’t I use them?
There is nothing wrong with them of course! They are very important in many areas of control theory and beyond. I am certainly not criticising their approach. However, I have struggled with the more rigorous approach for a number of reasons, which I believe many typical control engineers on plants would face;
- I only build models occasionally: I don’t want to divert my limited resources to learning and maintaining techniques that I would only rarely use
- I am dealing with real world “stuff" that is full of “issues” for which I am highly unlikely to get good data
- Often I need a quick response, or at least a good idea of whether a control scheme will work or the general reason why a scheme won’t work
From this I think you can see that my models are generally one-offs to investigate specific issues. They are only intended to be of use to myself or for demonstrations given by me. They don’t need to robust outside the domain for which they are intended and it doesn’t matter if they don’t have a stylish interface.
An often quoted phrase in the world of modelling is, “All models are wrong, some are useful” [Box 1976]. This is what I am trying to adhere too, making models that are useful to me.
A website called SemiWiki.com had an excellent analogy to further illustrate the point of useful models;
Consider a plastic model aircraft kit. This are great for getting the dimensions of the aircraft but are near useless to study aerodynamics. Now consider a paper plane. This is good for learning about aerodynamics but useless for anything else. [SemiWiki 2015]
The right model for the right context.
- [Woolf 2006] The University of Michigan Chemical Engineering Process Dynamics and Controls Open Textbook - https://controls.engin.umich.edu/wiki/index.php/Main_Page by Prof. Peter Woolf
- [Box 1976] Box, G.E.P., Robustness in the strategy of scientific model building, in Robustness in Statistics, R.L. Launer and G.N. Wilkinson, Editors. 1979, Academic Press: New York.
- [SemiWiki 2015] - All Models Are Wrong, Some Are Useful - https://www.semiwiki.com/forum/content/4973-all-models-wrong-some-useful.html by Paul McLellan