Page 43 - Practical Control Engineering a Guide for Engineers, Managers, and Practitioners

18 Chapter Two

worked with scores of SMILHers. One of the first ones, a great guy
named Fred, was the hardware designer while I was the algorithm/
software guy. I would program the minicomputer in some combina-
tion of FORTRAN and assembly language to (1) act on the inputs
served up by Fred's hardware and to (2) send the commands to the
output drivers, again provided by Fred. Fred also designed the elec-
trical hardware to connect the operator's panel to the computer. Our
trips to the customer's plants had a depressing similarity. We would
fire up the system, watch it malfunction, and then I would proceed to
find ways to amuse myself, sometimes for days, while Fred dug into
the hardware to fix the problems. He was indeed heroic, often putting
in "all-nighters." Fred never upset the project manager who thought
the world of him ... actually, as did everyone, including myself.
Nobody ever asked "Fred, why don't you do a more thorough job of
debugging the system before it goes out to the field or a better job of
design in the first place?" Fred went on to be a successful manager.
2·1·2 A Priori First Principles
Some processes invite mathematical modeling up front. The idea,
often promulgated by an enlightened (or at least trying to appear
enlightened) manager, requires that some mathematically gifted
engineer develop a mathematical model of the process based on first
principles. Proposed algorithms are then tested via simulation using
the mathematical model of the process. This approach is extremely
attractive to many people, especially the mathematical modeler who
will get a chance to flex his intellectual muscles. Early in my career
this was my bag. In retrospect, it makes sense that I would be rela-
tively good at it. I was fresh out of graduate school and knew practi-
cally nothing about real-life engineering or manufacturing processes
but I did know a little mathematics and I was quite full of myself-a
perfect combination.
Success depends mostly upon the style with which the modeler
applies himself and presents his results. Many times I have seen beau-
tiful computer graphics generated from modeling efforts that, when
stripped of all the fanfare, were absolutely worthless ... but impres-
sive. Later on, if the algorithm does not work as predicted by the mod-
eling there were always a host of excuses that the modeler could cite.
At least in my experience, a priori mathematical modeling, espe-
cially transient time domain modeling, is almost always a waste of
time and money. The real goal of this approach should be the gaining
of some unexpected insight into how the process works. Unfortunately,
mathematical modeling rarely supplies any unexpected performance
characteristics because the output is, after all, the result of various pos-
tulates and assumptions put together by the modeler at the outset.
Often one could just look at the basis for the model, logically conclude
how the process was going to behave and develop a control approach
based on those conclusions without doing any simulation.