Your Reliability Engineering Professional Development Site
A series of articles devoted to the eradication of the misuse of MTBF.
ISSN 2168-4375
Plus, we explore other commonly misused or misunderstood reliability-related topics and what one should do instead. A little understanding will help you get better results with your efforts.
Note: This is a reposting with editing, updating, etc. of the articles that first appeared at NoMTBF.com.
Recently heard from a reader of NoMTBF. She wondered about a supplier’s argument that they meet the reliability or MTBF requirements. She was right to wonder.
Estimating reliability performance a new design is difficult.
There are good and better practice to justify claims about future reliability performance. Likewise, there are just plain poor approaches, too. Plus there are approaches that should never be used.
Reliability testing is expensive. The results are often not conclusive.
Yet we spend billions on environmental, accelerated, growth, step stress and other types of reliability tests. We bake, shake, rattle and roll prototypes and production units alike. We examine the collected data in hopes of glimpsing the future. [Read more…]
WIIFT is “what’s in it for them”. Similar to what’s in it for me, yet the focus is your consideration of what value are you providing your audience.
As a reliability engineer you collection, analyze and report reliability measures. You report reliability estimates or results. Do you know how your audience is going to use this information?
Consider WIIFT when reporting reliability. [Read more…]
Where do you look when hiring a new reliability engineer? Do you head to U of Maryland or other university reliability program to recruit the top talent? Or, do you promote/assign from within? Where do yo find the best reliability people? [Read more…]
Here’s a simple illustration of how MTBF oversimplifies data, concealing essential information.
By convention, we tend to use MTBF for repairable data. That is fine.
You may also be aware of my dislike for the use of MTBF, for many different reasons. If you find yourself suggesting your organization, customer, industry or whomever to stop using MTBF, you may want to use this simple example to illustrate the ‘value’ of MTBF. [Read more…]
I was preparing to write this article and wondered how many search hits would appear for MTBF? So, opened Google and did an MTBF search. It is a common if misunderstood, acronym.
Beyond the 5,200,000 Google search results, it was the first page results that got me thinking. Keep in mind that Google often serves up a combination of what it thinks you are seeking and which sites have been useful for others.
Let’s break down what you find when you do an MTBF search. [Read more…]
MTBF comes up a bit too often. When it does I have found rolling my eyes and arguing against using MTBF is not very effective.
So, what should a knowing reliability professional do instead?
Let’s explore four questions that you can ask that may help others find the value in no longer talking about MTBF. [Read more…]
Received a short question last week. The person writing seems to already know the answer, yet asked:
If we replace an item after a duration equal to the MTTF value, we would avoid failures, right?
Well, no, most likely not, was my response. What is your response? How would you answer this question? [Read more…]
We establish reliability goals and measure reliability performance.
They are not the same thing. Goals and measures, while related, are not the same nor serve the same purpose. [Read more…]
Just when I thought we had experienced every possible MTBF definition confusion, here’s another.
This one is courtesy of the thread concerning the impact on reliability when adding redundancy to a system. [Read more…]
In a Q&A forum, the response to a question concerning failure rate and repair times for a redundant system demonstrated yet another person confusing MTBF with something it is not.
The responder to the question mentioned that the reference to repair time implied the need for MTBF as a metric. Then went on to describe MTBF as the duration of repair time, which should not change given a redundant system over a non-redundant system. [Read more…]
[Note: I wrote and published this article in August 2016, almost 10 years ago. The overall house hasn’t failed yet some windows leak when it’s raining (replaced), the water heater and furnace have both failed (replaced, repaired), and we are enjoying the house as our home. And, while I do get out for walks, I do not play Pokémon Go anymore.]
Seriously, while out walking, listening to a podcast, and playing Pokémon Go, I found an open house to view. A week later our offer was accepted, and next week we close.
I would not have been out walking that Sunday afternoon if not out playing Pokémon Go.
Glad there are no dangerous cliffs nearby. [Read more…]
Spending too much on reliability and not getting the results you expect? Just getting started and not sure where to focus your reliability program? Or, just looking for ways to improve your program?
There is not one way to build an effective reliability program. The variations in industries, expectations, technology, and the many constraints shape each program. Here are three suggestions you can apply to any program at any time. These are not quick-fix solutions, nor will you see immediate results, yet each will significantly improve your reliability program and help you achieve the results you and your customers expect. [Read more…]
Have you ever heard the claim that “We use MTBF, as it’s working just fine”?
They may be profitable and successful in the marketplace. Is MTBF serving them well?
Probably not.
One way help the folks claiming MTBF is alright is to illustrate using a better reliability metric may provide an improvement over using MTBF. Asking a few questions may find the inevitable chink in the MTBF armor.
In today’s complex product environment, becoming more and more electronic, do the designers and manufacturers really understand what IS Reliability ??
It is NOT simply following standards to test in RD to focus only on Design Robustness as there is too much risk in prediction confidence, it only deals with the ‘intrinsic’ failure period and rarely has sufficient Test Strength to stimulate failures. [Read more…]
