Nearly everyone I’ve ever met doesn’t want or like their toaster to fail.
It will, and that is a bummer, as the quick and easy way to warm up the morning toast will be thwarted.
Failures happen. As reliability engineers, we know that failures happen. Helping others to identify potential failures, to avoid failures or to minimize failures is what we do best.
It is our ability to teach others about reliability engineering that allows us to be successful.
Reliability Goals and Models
Someone on the project is going to ask, “How long should this work?”. Meaning what duration would be typical, and we expect this thing to work without failure over that duration.
Someone else will answer, not the reliability engineer, that 5 years seems like a good reliability goal. Thus it is so.
Our role as a reliability engineer becomes a teacher. We explain that the duration (or MTBF) is not a reliability goal. We need to define
- the function,
- the environment,
- the duration,
- and the probability of success.
In short, we need to help our team fully understand the four elements that make up a complete reliability goal.
The system goal is a start. Then we can use simple reliability models (in most cases) to explain how the goal breaks down to the various subsystems and major components.
All this explaining around goals and models allows us to compare estimates, vendor predictions, and test results to those goals within the model. This then should become a rather obvious way to prioritize efforts to improve the system’s reliability performance.
Reliability Estimates and Test Results
When was the last time someone asked you for a reliability estimate? Probably not long ago. Likewise, you likely experience cuts to the reliability testing sample size or budget. How about receiving instructions that your testing may not harm the product. I once was told prior to HALT to “not break it, we need to ship the unit for beta testing.”
Our teaching role comes out as we explain the random values we make up for estimates are little more than educated guesses. The results of a set of well designed and executed life tests provide insights about the reliability performance of the product. The former is nearly free, the later provides action and useful information.
Maybe it’s just me, yet I’m tired of explaining that a 17-year-old table of failures rates for 25-year-old technology is just not representative, nor capable of projecting the reliability performance of our new home appliance, or whatever.
Then later in the day finding half the power supplies for life testing have been diverted to meet early production requirements. We know there is a major reliability risk with the power supplies, yet rather than using enough samples to actually get a meaningful life distribution, it’s more important to ship early. At this point, your grasp of statistics will define how well you teach and convince.
There is one more item to prepare a well thought out lesson plan. What do the life test results mean? Is the design going to meet the reliability targets? If you only tested 3 units for a few hours and none failed, well what are you going to say?
If were fortunate enough to have sufficient samples and the testing runs most of the units to failure, can you explain the resulting life distribution and how to translate it to a projection of future field failures? Also, can you explain how the results help your team make decisions concerning product readiness for production?
Teaching Reliability Today
Any engineer or scientist is likely in a similar situation. With specialized knowledge, we see connections, ramifications, consequences, and solutions that other do not see immediately. We have to explain how we formed our conclusion.
Teaching reliability engineering in this manner is not to provide a degree or certification, rather it helps others understand the world as we do, given our reliability engineering training and skills. We are trying to convey enough information to help others grasp what and how HALT is useful and breaking the prototype is a necessary endeavor.
We know we’re being successful when the questions we’re asked probe complex aspects of reliability engineering. They get the basic stuff, now want to learn a bit more. We’re successful when the rest of our team makes decisions fully considering reliability aspects of the information.
It’s your mastery of the subject of reliability engineering that enables you to quickly help someone understanding acceleration factors or the perils of MTBF.
What have you been teaching lately? Leave a note or comment and let’s see if there are a few common topics we regularly have to ‘teach’.
Since it’s the design teams that really control the reliability by their part & material selections, stress analysis and testing, I focus on teaching them. Getting down to the physical failure mechanisms and physics of failure are concepts they can understand and relate to. I emphasize that if they get those right, they’ll get the reliability. If they don’t it will never happen. Get them past the mystical MTBF and onto what they do best.
Good note Kevin, thanks!