TDC

Aristotle Redux

May 1 2003 Kevin Cameron
TDC
Aristotle Redux
May 1 2003 Kevin Cameron

Aristotle redux

TDC

Kevin Cameron

DURING THE MIDDLE AGES, THE wisdom of the ancients was greatly respected. That of Aristotle became a final authority, beyond question. Debates on any subject were resolved by reference to him. Who needs original research when you already have all the answers?

We are now returning to a similar unquestioning respect for authority. The new Aristotle is computer analysis. Computers and specialized software are wonderful tools-but that is all they are. They cannot replace human understanding of physical problems. It is easy to forget that questionable assumptions may lie behind computer analysis.

Computer analysis has its place. As one older engineer I spoke to recently noted, “I can sit here at my desk, draw a connecting rod, then pass the design through my dynamic finite element pro\ gram to determine operating stress levels. If I see ‘hot spots,’ I can go back into the drawing program and increase a radius or two, then re-check it. This is wonderful. I can have a design ready before lunch.”

What is not so wonderful is that, increasingly, the computer receives more respect than the engineer. Naturally, engineering departments are under pressure to cut costs, and their managers see an easy way to do this-clear out experienced, highly paid engineers and replace them with lower-priced 25-year-olds plus lots of cheap computer power. Soon the new engine prototype is ready for test, in record time and under budget. Into the test cell it goes. Egads! There are weird vibrations from the cam drive, not seen in the computer model. Instead of clean computer images of ideal gears, cams and linkages, there are twisted metal parts embedded in the dyno room ceiling. Crisis! Very quickly all design assumptions are re-checked, the computer models are run again and again. Still the same. Time is running short-the engine business is highly competitiveearly sales must pay the interest on those R&D expenses. In desperation, phone calls go out to discarded engineers in their retirement paradises.

“What will it take to get you back up here, say, three days a week?”

Pretty quick, the grizzled old problem-solvers are back at work, performing their menu of magic tweaks that has worked many times before. They are well paid for this interruption to their golf games. Living in a motel suite, eating three restaurant meals a day isn’t cheap, either. This situation is being repeated in many branches of engineering. The models are not yet perfect.

“We can fix it!” cry the software writers. Everything the veterans do as they work through the problems of experimental mechanical engineering is written down, becoming cross-referenced tables of advice-an “expert system.” Now the software has surely become a right-answer machine that will turn future users into 30-year veterans. Who knows? Maybe we won’t need any engineers. So-called “knowledge workers” will have to hit the readjust as machinists did when CNC came in.

The problem is that reality is complicated. When an engineering device revises to behave as it should, someone must understand the physics involved in order to propose solutions. Blindly following a canned table of advice will work for simple problems-“If VCR does not operate, be sure it is plugged in...” What happens when no one in the company has any idea what the problem is, or what is causing it, much less how to fix it?

Here’s another. Company X buys a $30,000 analytical program to design its widgets. What management doesn’t know is that the program makes extensive use of infinite series in its “solver,” and that the term coefficients are arbitrary fudge factors. Making the program work is a matter of tweaking the fudge factors. Since the solver is not physics-based, it can’t help the user understand anything-it just gives “answers.” Like Aristotle.

Despite this, it seems certain that most products in the future will be designed by hands-off keyboard engineers of the variety known as “screen jockeys.” When they hit trouble that isn’t listed on their drop-down menus, management will summon consultants.

In the future, some companies will specialize in manufacturing, others in product development. A few will retain control of both activities. This is why innovation so often comes either from outside the mainstream (John Britten trained in decorative glassware design) or from companies who do their own x engineering. The mainstream will . adopt advanced concepts only when they’ve been digested into the next release of the relevant professional software. Example: A major U.S. automaker decided years ago that “plain bearings are solved” (that is, that the company would use in its engines only those bearing designs for which existing software gave solutions). Another automaker-offshore-recently spent some millions of dollars on advanced plain-bearing development. It did so because its engineers felt existing concepts were inadequate for the new engines it was developing.

Take your pick. The mainstream company builds a superb 1990-technology vehicle at an attractive price. The pioneering company delivers advanced performance, but their price includes the R&D that underlies that performance.

Virtual engines are here now. The consulting firm hands us a disc, we slip it into our automated production machinery, and engines come out. When field problems appear, or when we need a performance upgrade in a year, or have an EPA problem, we can’t fix it because we’re just a manufacturing company. Back to the consultants.

Consultants are not stupid. They don’t sell us everything they know in the first contract-that would be professional suicide. They sell us only 50 percent so they’ll have plenty more to sell when we come back, as we must. We hope the money we spend on consultants is covered by a) clearing out our engineering and test departments and b) extra sales our virtual engine enjoys because of its low price. Cross your fingers. □