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

30 Chapter Two

The logic behind using a mathematical model to gain insight
into a difficult process problem or develop a control algorithm
should be faulty on its face. The model is going to be based on the
problem-solving group's best knowledge and understanding of the
process. Unfortunately, the problem is present because that knowl-
edge and understanding is insufficient. In cases like these, the
answer to the problem lies in the process and its discovery almost
always requires disturbing the process in a manner similar to that
presented in Sec. 2-2.
You, as a manager, should always carefully question the basis for
your charges embarking on a mathematical simulation. It can waste an
enormous amount of engineering time. I, as a mathematical modeler,
never had any problem demonstrating how wonderful and useful my
model was and I wasted a lot of the company's money doing it. On the
other hand, using a mathematical model to debug a control algorithm
is an entirely different matter-see in the following sections.
These last handful of paragraphs have in large part been a regur-
gitation of earlier material. Sorry, but it's really important.

At Last-Busted!
In my new job, I escaped practical projects for a couple of years but
eventually I was given responsibility for putting in a new instru-
mentation control room for a new process. I was awed by my lack of
ability in the hands-on aspect of instrumentation. Consequently I
resorted to obsessive planning, preliminary debugging, and exten-
sive use of competent resources (such as the hourly instrument
technicians). The instrumentation included a data-logging com-
puter (called minicomputers in those days). To cover myself, I broke
all inputs and inserted test voltages to simulate real conditions. I
also wrote little subroutines to generate fake signals to the data-
logging algorithms. I found many problems and enlisted the aid of
talented associates to solve them. The list of debugging tricks could
go on but to make a long story short, when it came time for the pro-
cess to start up, all my stuff worked and there was no opportunity
for SMILH-which was a good thing because I simply was not cut
out for that kind of thing anyway.
My "customers," the boys who designed and would run the pro-
cess, were astounded. It was the early days of using computers to
monitor industrial processes and they had been conditioned to bring
their new processes in without the aid of the data-logging computer
for a simple reason: The engineers doing the instrumentation hard-
ware and software were experienced, talented, and confident that
they could solve any problems that would come up so they avoided
any extensive pre-bring-in debugging and left any problems that
would crop up to SMILH.
Although I gained points with my boss over the success of the
project, I concluded that large-scale instrumentation installation