I'm not sure if they are regulatory standards but there are:
1. Standard PID equations available in each controller
2. Local naming conventions
3. At least local conventions on color usage on a display
4. Some standards on how well the system will work for process safety.
5. Some standards on safety interlocks, and other details
6. Several standard methods for tuning.
but overall, there is no standard that I know of which says to use a
particular algorithm in a particular place.
Not really. But a good place to start is the algorithms available within
Foundation Fieldbus. I have a feeling FF is going to standardize a lot more
than just the signal levels on pair of wires.
I don't believe this question is specific enough to yield an answer.
It happens all the time with this newsgroup.
If you want a picture of generally accepted concepts and terminology
used in the many thousands of industrial PID loops world-wide see:
http://www.eurotherm.com/training/tutorial/tutor.htm - and select
This example is a temperature loop but it deals with the basics of PID
control. It is just one of hundreds of articles to be found on PID on
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.
Someone admits the truth!
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"
make good use of the general ignorance by selling the magic packages that
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
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
I wasn't implying the auto tuning software is lousy. I was just saying
it the auto tuning software appears to be magic to most people. If auto
software was understood then people would be doing their own calculations
the gains. As for tweaking, why not calculate gains continuously and truly
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.
Re: auto-auto tuning.
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."
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.