[Hans Blom, 970408]
(Bill Powers (970401.1557 MST))
Hans' model requires that the peak output needed to produce these
"one-step" corrections be inversely proportional to the sampling
interval, leading to extremely large values of output as Dt
approaches zero. Han's comment on this "feature" of his model was
that nobody told him that infinite output was to be avoided:
"you wanted perfect control, I gave you perfect control." In some
circles, this is known as "malicious compliance."
This makes a beautiful example in my class on Expert Systems, in the
part about knowledge acquisition. Thanks.
"Class, this is what we often experience in our practice. A client
comes to us for a system design and tells us what he wants. Or
rather, thinks he wants. By now you all know that every client has a
lot of unmentioned extra conditions that he takes for granted but
does not utter even once. Those requirements are unconscious, are not
"hard" and are sometimes very difficult to unearth. Somehow clients
expect us to be mind-readers. And that is, indeed, what this class is
about: to learn a method -- we call it "rapid prototyping" -- to
investigate what somebody wants, even though that somebody may not
know what he wants himself, let alone be able to express it.
When you try to get additional information, it may be provided.
Partially. Or not at all. Sometimes with irritation: "Yes, of course.
That too. You should know that". Sometimes with surprise: "Why didn't
I mention that before? It is actually my most important requirement!"
Remember this: it is normal that people do not know what they want.
They want it, sure. They just don't know they want it. Until you ask
them. Then they may become conscious of an additional requirement.
The best method is, however, to confront them with a prototype that
fulfills all the wishes that they have uttered. That prototype is
sure to be rejected. And the important lesson is: _the reason for the
rejection is the additional knowledge that you wanted in the first
place_. But it may be a painful process, both for you, the knowledge
engineer, and for the customer. For you, because you did exactly as
the customer specified, yet he rejects your design. For the customer,
because your design confronts him with his own inadequacies. Many
customers don't take that easy. Remember that, and explain to your
client that this is _normal_ and to be expected. If you don't, you
might damage his ego and our knowledge engineering firm will have
lost a customer.
"Position control" is what he wants, says the customer. Fine. Of
course, in his application. But somehow you doubt that that will be
all. "How accurate?", you ask. Well, the motor the client has in mind
is very fast, he says. It can generate a new torque stably after 20
microseconds. You've never heard of such a fast motor and think it is
tremendous overkill. The movement is slow, after all: a rotation of
one radian is allowed to take a couple of seconds. And the motor is
expensive to boot. But the client wants it. So we incorporate the
thing in our design. And we use its properties: the system generates
rapidly fluctuating torques. Great design. Extremely accurate. Almost
perfect even. You know that this cannot be all, but you've done
exactly what the client wants.
Yet the client complains. Again, that is normal and to be expected.
He complains that the motor or the whole assembly will not survive
the rapidly fluctuating torque. You doubt it, but the client
emphasizes that he does not want his extremely fast motor to be used
for what is can do, and for what it obviously was meant to do.
Strange, but you comply. The client is the client, after all. And the
first prototype has achieved its task: it brought to light that the
client has not told you all of his requirements. Theory told us so,
but now we have experienced this in practice as well. Moreover, you
have to spare the client's feelings. He seems a bit embarrassed that
he hasn't explicitly specified that he doesn't want small high
frequency vibrations, even though they don't seem to hurt the design
in any way. But the client being a client, his ideas are _good_
ideas. He is the expert, after all. Only he knows what he wants.
That's what only _he_ is expert in. The only problem is that it is
difficult to find out _what_ it is exactly that he wants. But that's
what this class is all about: finding out what the client wants, even
though the client isn't consciously aware of what that is. Or maybe
he is, but cannot express it into words. Well, time to start your
next prototype. It, too, will probably not do what the client does,
but it will at least incorporate one additional requirement. If you
have understood the client, that is. It's not _always_ the client's
fault. In fact, we take the professional attitude that it's _never_
the client's fault. That's why we often sound like psychotherapists.
That's a joke, class...
However, you somehow start to doubt the client's whole concept: the
parts somehow don't fit together very well. But the client places the
order, so you comply. Yet with this particular client you see a long
sequence of prototypes before you. Attempt to see that in a positive
light. This client is a perfectionist, and perfectionists are the
prime source of income for our corporation.
So you get rid of the high frequency vibration and incorporate smooth
operation into the system. Let's wait and see whether the client is
satisfied now. What will he judge? The performance of the system?
Most clients do, but not perfectionists. They want to look _inside_
the system as well and see _how_ you've done it. Some even go so far
as to reject solutions that are achieved in ways that they do not
comprehend. Those are our most difficult customers. And the ones that
generate most of our firm's income. So they're very welcome. And even
though the final design won't be state of the art, they will be
exactly what the customer wants. And customer satisfaction is, after
all, what we're all about.
But you keep wondering what the client will come up with next. One
thing that he's mentioned already is the high power pulses that the
controller supplies to the motor. It may help little to insist that
the power-time product will be the same, regardless whether the power
is delivered in 1 or in 10 msec. The client may have additional
concerns. Maybe he's afraid that too high currents will generate
electromagnetic forces in the motor's stator or rotor that may
physically damage the windings. That would be a real concern. You'll
have to explain that performance may deteriorate slightly if you
limit the instantaneous power, but the client doesn't seem that much
interested in optimal performance, i.e. in an exact matching of the
design with his explicit requirements. That invariably means that the
client has many more unspoken wishes. So be prepared for a lengthy
and difficult design process. There's a lot more that needs to be
discovered before this client will be satisfied.
The most difficult clients are those who, when you're finished and
demonstrate a design that leaves nothing more to be desired, say that
the design is "nothing but" what they could have done themselves in a
short time as well. In fact, their requirements were not about the
_performance_ of the system but on _you_ doing what _they_ want. So
you may find yourself, indeed, having redesigned the exact same
system that the client already had on his shelf. But don't think that
your effort is in vain in such cases. It will have boosted the
client's self-confidence; you, an independent expert, arrived at the
exact same solution as the client had in the first place, so his must
be a _good_ design. It will also and proportionally have boosted our
firm's income. That's _good_, not _bad_. Keep that in mind. If you
don't because of all the frustrations, our firm will have lost a
valuable customer.
And what _you_, the knowledge engineer, have gained is a valuable
lesson about human nature: people want what they want, not what is
best for them. If you can't accept that elementary fact of life, you
ought to consider quitting this class."
Greetings,
Hans