What Do I Do When MTBF is Imposed?
Abstract
Chris and Fred discuss what happens when you can’t avoid having the MTBF imposed upon you – even if it is your own organization and not the customer. Perhaps you are told that ‘our competitors quote the MTBF … so we have to as well!’ But you can (sneakily) tailor test data to get whatever MTBF you want. You can make life easy on yourself by not challenging this paradigm (noting that you will most likely get an unhappy customer). But it is almost impossible to apportion MTBF goals to individual designers that even allow the motivated ones to create a reliable system. So what do you do? Listen to this podcast to help you on your reliability journey.
Key Points
Join Chris and Fred as they discuss what you, as a reliability engineer, need to do when you are forced to be measured in terms of the MTBF and nothing else. The MTBF is usually imposed when the customer asks for it, or your organization is trying to conform with industry norms. But the problem with the MTBF is that it usually doesn’t practically mean anything for the customer … and it is difficult to assign accountability to designers.
Among other things, the MTBF (which is based on an assumption of the constant hazard rate) can’t incorporate any understanding of things that wear-in versus wear-out.
Topics include:
- Educating your boss (or your marketing team) to unveil the horrors of the MTBF. Simply demonstrating in a simple way that the MTBF is going be the point by which anywhere between 50 and 100 per cent of systems will have failed can be very enlightening.
- Educating the customer if they are simply asking for the MTBF. Customer relationships are a two way street. Engaging an ill-informed customer shows you care, and it also shows that you understand what they actually want. You can also use this conversation to demonstrate that competitors aren’t as advanced as you are if they insist on staying with the MTBF.
- … noting that most military customers are fixated on the MTBF. ‘MIL-HDBKs’ were written before we all had Microsoft Excel, meaning that the reliability tests they described had to be simple (… as in based on the MTBF). But these ‘MIL-HDBKs’ have been withdrawn and we (should) have moved on. So why do we keep using them?
- Generate a reliability requirement. If you have an idea of operational life, you should be able to convert an MTBF into a system level reliability goal.
- Don’t apportion MTBF. This doesn’t work.
- … but apportioning reliability does. This allows designers to focus on specific reliability characteristics. Which means that you allow them to be successful, and make your customers happy.
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques, to field data analysis approaches.
- Social:
- Link:
- Embed:
Show Notes
I just got around to listening to this one. As always, I agree that MTBF makes a poor quantitative specification, whether for a repairable system or for a component or non-repairable system (which doesn’t even make sense because there is no ‘between’). So I’m a follower and on your bandwagon.
However, I still think you add to the confusion somewhat by confusing MTBF and MTTF (B vs. T). Chris mentioned the central limit theorem, which is absolutely appropriate for MTTF, because it only requires a homogeneous population from any distribution, and this can often be satisfied for a population of components or non-repairable systems. However, it is not appropriate for MTBF, and yet you were discussing it at the same time as the discussion about MIL-STD-781 reliability demonstration tests which are for testing MTBF. The times BETWEEN failure for a repairable system are generally not from a homogeneous population, and it should never be assumed that they are. The hardware might be homogeneous, but not the successive times between failure, the system might be getting worse or better.
We all know that for an aging system, the times between successive failures becomes shorter (and for software being debugged longer). Therefore, the expected time for the next failure keeps getting smaller, i.e, it is not a stationary process, or it should not be assumed that it won’t.
You could correctly have a specification for MTTF for components or non-repairable systems. Fred also made the good point that some lower percentile value may be of more interest than the mean. However, NEVER have a specification for MTBF for a repairable system because the underlying assumptions are not likely to be valid.
Thanks David for listening and thanks for our comments!
I agree with you … in part. Lets start with the bits I agree with.
(1) The central limit theorem works for MTTF,
(2) Times Between Failure (TBF) are not homogenous if the system in question ages.
The bit I don’t agree with is:
(3) The central limit theorem does not work for the MTBF.
Why? Because the central limit theorem applies to any random variable (lets say … Y) that is the sum of any set of independent, individually distributed (IID) random variables. Or in other words … these random variables don’t need to be homogenous.
For example, the central limit theorem applies to a random variable (again … lets say Y) if it is the sum of lognormal, normal, exponential, Weibull, gamma, beta and any other random variable. There just needs to be lots of them that are added up.
And because the simple equation for the MTBF is the sum of all random variables (TTF #1 through to TTF #n) divided by the total number of random variables (n), the central limit theorem applies. Even if TTF#1 has different properties to TTF#n.
Please keep these questions and comments coming!