When I eventually encountered formal troubleshooting procedures, the most obvious thing that struck me was that it's basically reversing the process of setting up the equipment, so you simply follow a logical order.
@Ann: Glad you liked the article. Actually, I was recently re-reading the Sherlock Holmes books; there are definitely a lot of Holmes' methods that can be applied to engineering. And you're right that checking the obvious things first (i.e. is it plugged in?) is an important step that is sometimes overlooked by otherwise smart people.
Thanks for an interesting and thoughtful essay, Dave. I hadn't thought about the similarity with a doctor's process for troubleshooting, but I have thought about the similarity with Sherlock Holmes' methods. In fact, that's probably where I started learning how to think analytically to solve problems in mechanical or electrical systems. The next stage was much later as a young adult, working with my stereo system, when I encountered the basic rules of troubleshooting electrical systems, with the first steps always being: Is it plugged into the wall? Is it switched on? Are all the cords hooked together correctly and are any of them frayed or defective?
It seems that the more valuable doctor of engineering would be the doctor of science of engineering, as opposed to the doctor of philosophy type doctor. You may have noticed that your medical and dental doctors hold a doctor of science degree, while the HR troll may hold a doctor of philosophy degree in finance or management, or basketweaving. What the PHD means is that they have completed some research project, it does not mean that they have developed any insight or understanding. Some do, many don't.
My diagnostic technique is a bit different: First observe how the system is functioning while understanding how the system should be functioning. Often this does require making measurements and collecting a bit of data. second, given that the area of malfunction is observed, consider which portions of the system affect that function, and observe how they are functioning compared to how they should be functioning. With adequate understanding of the system operation this should point to the source of the problem.
The challenge being that this method of diagnostics requires a great deal of understanding and insight, and so it is not simple to use by the unknowing.
@streetrodder: Great comments. Clearly, there are limitations to the analogy between engineers and doctors. What impressed me, though, is that doctors are explicitly trained in a disciplined problem-solving methodology. This isn't usually done in engineering education. In engineering school, there is often little or no discussion of how to approach and solve problems generally, and a lot of focus on tools for specific kinds of problems.
To some extent, this is because disciplined problem-solving is second nature to most engineers, as you and other commenters have pointed out. However, I think there's a lot of value in having a clear framework for thinking about the process of problem solving.
Yes, we usually assume it was working prior to breaking down. My first days at the E company. They wanted me to fix the ATE without opening the patient. I soon convinced them and a bond of trust developed.
I found the blog and comments interesting. Not surprising and somewhat limited, though.
I recently retired as a biomedical engineer working for a very large healthcare system. I found first hand the limitations of the medical school model. First and foremost, it's based on the assumption that there's prior history of the problem. In field service, that's the case only for obvious failures. For those tricky problems. there often is no prior history. Also, documentation on the system under analysis is limited - equipment documentation is only available if it was a requirement at the time of purchase (imagine, if you will, that the patient refuses to tell you what's wrong, and there's no access to the equipment equivalent of anatomy and physiology books). Now, imagine being in the OR, trying to diagnose and fix the problem, while the 'parent is looking over your shoulder asking "What's wrong, how soon will it be fixxed?" The very talented technician is a far better problem solver than a doctor.
I recall in incident at one hospital where an invasive radiology system went down. Our tech is in there troubleshooting away (fully aware that the failure is delaying patient care). The Chief of Radiology is asking why he hasn't identified the problem and fixxed it. That's when it hit me: Doctors are trained on prior knowledge - there is a limited number of failures (illnesses) they need to focus on. If there's an illness outside of their knowledge base, they perform extensive research and/or referral the patient. And take several days/weeks/months/years to fix the problem.
In field service, the techs need to diagnose and repair problems that may have never occured before, with limited knowledge and often limited/non-existent documentation of the "patient's" anatomy and physiology. All within, at best, a few hours, while the 'parent' is looking over their shoulder..
Truchard will be presented the award at the 2014 Golden Mousetrap Awards ceremony during the co-located events Pacific Design & Manufacturing, MD&M West, WestPack, PLASTEC West, Electronics West, ATX West, and AeroCon.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
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.