I only wanted to learn if there are ANY standards that PID controllers in industry must (or should) follow. Something like IEC 61499 for logic controllers (more precisely, function blocks stuff). I don't really feel my question was that vague.
Thank for a nice link. Even though it does not answer my question, I find it very nice and useful.
To the best of my knowledge, there are no implementation standards. Each manufacturer is allowed to develop whatever equations they wish, and they do. Honeywell, for example, has at least 6 different equations for PID based controls, none of which are the same as what chromolux uses.
Some use straight gains, others use inverse times, bandwidth expressions, etc. Some use absolute outputs, others use relative outputs. Some allow filtering, averaging, clamping, ramping, multiple gains, variable gains, bumpless transfer, self tuning, and others don't.
To top it off, there are also a number of different tuning standards and protocols. Some are based on quarter wave damping, some aren't. Some are based on seat of the pants operations, others more on mythology. I still haven't figured out how a few loops I've looked at were tuned (or mistuned).
There are naming conventions, often specific to an installation or a manufacturer. These change from time to time.
There are not architecture standards. You can use a database lookup, object oriented programming, top down programming, assembler, or whatever your heart desires, as long as you don't copy another vendor too closely. I've seen controllers which were fully object oriented, and some which were half oop and half top down (or bottom up).
The only things that are marginally standard is that we expect them to somehow control the process using roughly the same old control algorithms we learned in our control classes years ago, and the use of one or more of several standard input and output protocols.
One (almost) standard I've gotten used to is that the old pneumatic controllers typically required a screwdriver, and the new electronic ones typically use a keypad based input.
I hope this gave you a bit of an answer. I'm not sure it was the one you were looking for. There might be some standards, but there are enough non standard details which tend to obfuscate them.
What a business! If people really knew how little we actually knew what we were doing, they'd be scared. There is one standard that has some terminology definitions of PID control and that is ISA 51.1, Process Instrumentation Terminology. People sometimes refer to an "ISA standard controller" but there is no such thing. This spec is the closest, but all it provides is a few definitions of terms.
I just shake my head and wonder how the world turns. Fortunately the world turned before PIDs or control. I have seen statements like "gains are not calculated, they are tuned" and I shake my head. The people that make "tuning" software make good use of the general ignorance by selling the magic packages that conjures up the gains. Only the high priest hood seem to know how to wave the magic wand. Ignorance cost a lot.
This topic deserves another thread because it is off topic and a potentially big one.
While lousy software will always remain lousy software, the statement about the gains may be a little exaggerated but it has a good reason to exist. While it is possible to calculate an estimate of the PID parameters, you will almost always have to fine tune them on the actual plant. Why? Because the model you use to calculate those parameters is just an approximation of the plant's behavior. Unfortunately, the world is nonlinear, and time variant for that matter.
I wasn't implying the auto tuning software is lousy. I was just saying that it the auto tuning software appears to be magic to most people. If auto tuning software was understood then people would be doing their own calculations for the gains. As for tweaking, why not calculate gains continuously and truly put the auto into auto tuning?
Oh, I didn't mean all (auto)tuning software is lousy, either. I understand your concern about the tuning process being magic to many plant floor people. However, one needs some knowledge to perform the calculations. On the other hand the tuning can be carried out by the seat of one's pants. And many companies cannot afford having engineers on the payroll. They call up "superengineer" companies to solve problems.
This stuff is tricky, of course. It is the old good compromise between robustness and efficiency, and between stability and adaptability. Besides, the adaptation algorithm itself has to be tuned.
Don't forget the only way to check the true response of a system is to give it a little nudge/jiggle and see what it does. You're not going to gain a lot of efficiency if you jiggle things too often just to make sure you still know how it will react.
Why not generic continuously autotuning products? a) adaptive algorithms are not guaranteed stable for any plant. b) Best performance requires someone to say what best is... ie. overshoot/response time. c) Probably would have a statutory warning on the label: "WARNING: This Controller May Occasionally Cause Plant Oscillations If Steady State Plant Operation Is Too Smooth For Autotuning Algorythm"
"WARNING: Like an understimulated employee, this controller may start playing with things if it gets bored, you may disable this behaviour, however it can not be guaranteed that the controller will be awake enough to react to sudden changes."