Nice article, thanks. I thought this sort of problem-solving approach was second nature to engineers, but maybe I am mistaken. I was raised by a medical professional, so maybe the DDx rubbed off on me when I was a child.
What happens when the patient gets better before the doctor finishes the diagnosis? Then the doctor gets paid, anyway. In engineering, we call this an intermittent problem, which can be much more difficult to diagnose. How about writing an article about this sort of diagnosis? Customers and Management don't think highly of the engineer when the problem comes and goes.
Differential analysis is used in management and accounting as well, sometimes to find errors.
Thanks Dave for such an informative post , i totally agree with the analysis method that you have mentioned i also used to follow almost the same method of technical analysis when was working inthe engineering department .First of all we used to consider the issue that customer facing , then we try to dig out the reasons for the issues and comparing how exactly the device should work if it was working properly then testing all the possible reasons by trial and error method .Hence almost in all technical departments the same method of analysis is being followed .
When I first read the title I though this couldn't be possible. Turns out I was right, as I can conclude the same after reading the piece. However, even though the title is not right, the content is spot on. As engineers, we love to dig into the tests directly and none or very little consideration is ever given to the 'medical history' of the part we are diagnosing.
I agree. The methods described in this article is exactly the steps I used when doing a Root Cause Analysis on Electrical-Electronics Systems. A key item to this method is documentation. Without documentation, the analysis activity becomes quite difficult to initiate because of the lack of information to investigate/research. The more information gather, less chance of going down a rathole trying to resolve the problem. Very nice article indeed.
Good point, Chuck. I'm not familiar with the horses vs. zebras quote. Is that saying that it's more likely to be horses than zebras?
Talking about hoof beats. I was in southern New Mexico last week and someone was a few minutes late to a meeting because a heard of wild horses crossed the highway and he had to wait for them to pass. It's still the wild west out here.
I like the saying, "When you hear hoof beats, think horses, not zebras." It could apply to a lot of areas of life, not just engineering. But I think it's a great way of saying, "Consider the most obvious problems first." Nice article.
Nice article, Dave. It sums up very methodically, what engineering and evaluation is all about. It almost could be the "pilot" article for Sherlock Ohms. Maybe at least it could be re-printed as an introduction to engineering, perhaps on the inside cover of a curriculum syllabus. Sums it all up quite nicely.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
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 discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.