The careful Sherlock Ohms reader will also note another difference between engineering design in 1979 and the way things are done today (though probably in 1991, the work environment was closer to the former than the later). Namely, that pack of cigarettes. (The stack of magazines, too, come to think of it.)
Also note the engineer's dedication to sit down in front of the machine and test it yourself. To often young engineers are told how to create test requests that have others do the testing rather than sitting down in front of the machine and testing it yourself. There is a lot that can be learned by sitting down and understanding the unit and the testing yourself before having the test lab verify the results you expect. Young engineers can learn a lot from a senior engineer sitting down in front of a machine to try and discren what is really going on.
This is a very important point. Another important point is that just because you see (what appears to be) the same problem twice, don't assume the root cause is the same. In both the gyro example and the blood pressure monitor example, the symptoms were similar, but one was a hardware issue and the other was a software issue. It's human nature to generalize from one experience to the next, but sometimes this can be a trap. Many times I've heard engineers say, "We know what this is; we've seen it before!" before doing any real investigation. In fact, I've been guilty of this myself. There is no substitute for sitting down and investigating the problem for yourself. (I'd recommend against the cigarettes, though).
I know I've been guilty of thinking I "knew" what the root cause was. And rather than fully investigate we communicate to the test team that we "know" what the problem is and we have it solved with the new design. However, this often communicates to the test team that they can ignore that failure. We, as engineers, need to make sure we take every failure instance as a seriouse issue until we can prove otherwise. Not just until we feel pretty good about it. Shrugging off a failure as something we have already solved can tell the rest of the team to ignore what could be another serious issue.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.