Elizabeth “Reliable” https://www.flickr.com/photos/goosedancer/3733356197/in/gallery-fms95032-72157649635411636/
MTBF is the inverse of a failure rate, it is not reliability. Physics of failure (PoF) is a fundamental understanding and modeling of failure mechanisms. It’s the chemistry or physical activity that leads a functional product to fail. PoF is also not reliability.
Both MTBF and PoF have the capability to estimate or describe the time to failure behavior for a product. MTBF requires the knowledge of the underlying distribution of the data. PoF requires the use stresses and duration to allow a calculation of the expected probability of success over time.
MTBF start with a point estimate. PoF starts with the relationship of stress on the deterioration or damage to the material. One starts with time to failure data and consolidates into a single value, the other starts with determining the failure mechanism model.
Does MTBF has a Role Anymore?
Given the ability to model at the failure mechanism level even for a complex system, is there a need to summarize the time to failure information into a single value?
No.
MTBF was convenient when we had limited computing power and little understanding of failure mechanisms. Today, we can use the time to failure distributions directly. We can accommodate different stresses, different use pattern and thousands of potential failure mechanisms on a laptop computer.
MTBF has no purpose anymore. MTBF describes something we have and should have little interest in knowing.
Sure, PoF modeling takes time and resources to create. Sure, we may need complex mathematical models to adequately describe a failure mechanism. And, we may need to use simulation tools to estimate time to failure across a range of use and environmental conditions. Yet, it provide an estimate of reliability that is not possible using MTBF at any point in the process. PoF provides a means to support design and production decisions, to accommodate the changing nature of failure rates given specific experiences.
When will PoF become dominant?
When will we stop using MTBF? I think the answer to both is about the same time. It is going to happen when we, reliability minded professionals, decide to use the best available methods to create information that support the many decisions we have to make. PoF will become dominant soon. It provides superior information and superior decision, thus superior products. The market will eventually decide, and everyone will have to follow. Or, we can decide now to provide our customers reliable products.
We can help PoF become dominant by not waiting for it to become dominant.
A troublesome question arrived via email the other day. The author wanted to know if I knew how and could help them adjust the parameters of a parts count prediction such that they arrived at the customer’s required MTBF value.
Do you know what an irrational number is? It is a number that cannot be expressed as a definite number but is often a useful shortcut in performing complex mathematical calculations. Pi is an irrational number that provides a very useful shortcut in calculating the circumference, area, surface, and volume of round things. Pi happens to be my favorite irrational number because you get to celebrate it, if you follow the western calendar, every March 14th (3.14 are the first three digits in Pi) by eating a nice big piece of pie (Pi sounds like pie and pies are round).
Do you know any other irrational numbers? I do. Mean Time Between Failure (MTBF) and variants of it such as Mean Time To Failure (MTTF) are irrational numbers. But they are not irrational in a good and useful way like Pi is. Sure, MTBF once had some usefulness to it and provided a useful shortcut for some reliability, maintenance, and logistics applications, but it has become so misused that it had become irrational in the primary definition of the word irrational that MTBF is something that is not logical, not reasonable, groundless, baseless, and not justifiable.
So how did MTBF, a once useful thing, get to be so irrational?
Here are some reasons:
Apparently, to make the logistics for large populations of items simpler, people took the failure rate of the item and inverted it to create MTBF. They did this mostly out of convenience when dealing with large populations such as fleets of vehicles to address the random failures that were being experienced and to make the mathematics simple. And this approach worked fairly well before better approaches came into play. But this approach also worked fairly well because other reliability and maintainability practices were also enforced, namely planned/preventive/scheduled maintenance whereby serviceable items were serviced to keep them in proper operating condition, wearable items were replaced or restored, life limited items were replaced and good operating and failure data was kept. Without enforcing the maintainability and good data side of this, MTBF becomes very misleading.
Then people who didn’t understand that MTBF was the failure rate of an item inverted began to take the “mean time” in MTBF a bit too literally, ignoring the fact that most items have a limited useful life, and began thinking that MTBF was some sort of indication of the mean life of the item. You can have an electrolytic capacitor that has a failure rate of 0.0000001 failures per operating hour and invert that to get a MTBF of 10,000,000 hours. Does that mean that a single capacitor will last for 10,000,000 hours or 1,142 years? Of course not. Because the capacitor may only have a useful life of 5 to 20 years before it leaks and dries out and fails. Whenever you use MTBF or even Failure Rate, you not only need to know that number but you also need to know over what useful life the number is valid.
Then people started collecting failure rate data and putting it in databases and selling reliability analysis packages that enabled people to predict the MTBF of complex systems with hundreds and thousands of components in them. That made MTBF predictions very easy to do and people were too lazy in not also indicating the relevant useful life limits of life limited components in the system. But the MTBF numbers that the computer models spit out were big numbers and that made people very happy. Naïve and unaware, but happy. Except for the poor guys who had to use the systems struggled with the systems not performing as promised and then being blamed when the systems didn’t perform.
Then people stopped collecting failure rate data and now the databases underlying many of the computer models still in use today not only have misleading data but also have outdated and obsolete data.
Irrational numbers indeed. To me, a self-professed Reliability subject matter expert, MTBF just confuses me and causes confusion. So I say to stay away from it as much as you can.
So, what should you do?
The best thing to do is to not use MTBF and instead use Failure Rate. And when you use failure rate, make sure that you are using and representing it properly by stating the failure rate during the intended time period. Most of the time, people are interested in knowing the expected failure rate of something over its useful life. So, you may indicate that an item has an expected failure rate of 0.000001 failures per operating hour over its 10 year expected useful life. Some people write this as a failure rate of 1E-6 per hour over its 10 year useful life (there are other failure rate conventions used such as FIT rate that I won’t go into). If the customer knows failure rate over the expected useful life, they then know two very useful things; how long they should expect the product to last and how reliable they can expect the product to be. And if customers know these two things, they can plan for the support, spares, maintenance, and replacement of items they need to be doing to keep their products or systems up and running.
One example is that you may use a non-repairable power supply in your system that has an expected usage life of 10 years and a very low failure rate during those 10 years. But what if you need your system to run for 20 or even 30 years? You either need to find a power supply with a longer life or be prepared to replace the power supply proactively before it nears its end of life. You should also design your system so that it is easy to replace the power supply.
When repairable items are involved, the maintenance required should be indicated so that the customer knows what they need to do to preserve the performance of their product or system. One example is that you should expect your car to last for 200,000 miles, but you need to stick to the recommended maintenance schedule to ensure this. If you decide to never change the oil in your car, you should not expect it to last for 200,000 miles and certainly should not expect it to perform reliably.
How do you get failure rate?
You can get failure rate a few ways:
Most component data sheets indicate Failure Rate or how to calculate it based on certain use and environmental parameters. Some data sheets even indicate MTBF, so make sure to invert it to get Failure Rate. And do not forget to look for information that shows or explains the useful life that you can expect for the component so that you have both pieces of information that you need; failure rate over what expected useful life. This gives you a decent engineering estimate for useful life and reliability until you have actual data for your product.
You can conduct testing or even accelerated testing on products to determine their failure rate. However, you may need a lot of samples and incur a lot of cost to test to demonstrate a certain reliability or failure rate.
The best way to get failure rate, in my opinion, is to get it from your own products in service. You need to collect data either on the entire product population or a large enough sample population to know the actual number of units in service, operating hours, and failures. You can then develop your own failure rates for your products that reflect the markets you serve and how your product is used.
Move away from the irrational numbers
As you move away from the irrational numbers of MTBF and towards knowing the real failure rates and reliability of your products in the markets you serve and how your products are used, you will be better able to drive reliability improvement when needed, understand and correctly price warranties and service agreements, and provide confidence and satisfaction to your customers. You can then reward yourself with a nice piece of pie.
Let’s say you have a reliability goal for your product of 95% survive 2 years in an outdoor portable environment with the primary function of providing two way communication. There is an engineering reference specification detailing the product functions and requirements for performance. There is a complete document of environmental and use conditions . And you have similar detailed goals for the 1st month of use the expected useful life of 5 years. Continue reading Supply Chain MTBF vs Reliability Requirements→
Every now and then I receive an interesting question from a connection, colleague or friend. The questions that make me think or they discussion may be of value to you, I write a blog post.
In this case, there are a couple of interesting points to consider. Hopefully you are not facing a similar question. Continue reading How to Estimate MTBF→
How many times have you been given only MTBF, a single value? The data sheet or sales representative or website provides only MTBF and nothing more. We see it all the time, right? It is provided as the total answer to “what is the reliability performance expectation?”
So, given MTBF what do we really know about reliability?
Time to move on from Mean Time Between Failure (MTBF) and Mean Time To Failure (MTTF)
Guest Post by Dan Burrows
Reliability, Quality, Six Sigma, & Performance Improvement Leader
sean dreilinger rachel opens reliable design of medical devices – a textbook that nobody else would dare to read.
The reliability profession has historically embraced two metrics, Mean Time Between Failure (MTBF) for repairable items and Mean Time To Failure (MTTF) for non-repairable items. They did this mostly out of convenience when dealing with large populations such as fleets of vehicles to address the random failures that were being experienced and to make the mathematics simple. And this approach worked fairly well before better approaches came into play. But this approach also worked fairly well because other reliability and maintainability practices were also enforced, namely planned/preventive/scheduled maintenance whereby serviceable items were serviced to keep them in proper operating condition, wearable items were replaced or restored, life limited items were replaced and good operating and failure data was kept. Without enforcing the maintainability and good data side of this, MTBF and MTTF become misleading at the least and dangerous in many cases.
Thus, MTBF or MTTF could address the flat portion of the traditional “Bathtub Curve”. Proper maintenance could address the wearout/life limit portion of the bathtub curve. And screening and run in/burn in could mitigate the early failure portion of the bathtub curve.
Traditional Bathtub Curve
So, there are four big mistakes that people often make with MTBF and MTTF related to the bathtub curve:
Mistake #1: MTBF and MTTF are erroneously used as projections of product useful life.
Mistake #2: MTBF and MTTF assume a constant failure rate during the useful life of the item.
Mistake #3: MTBF and MTTF are given an assumption of high likelihood that the product will make it to the value.
Mistake #4: MTBF and MTTF data is assumed to be good and current.
Let’s take a closer look at these four big mistakes…
Mistake #1: MTBF and MTTF are erroneously used as projections of product useful life
Let’s take a common example. Electrolytic capacitors can have MTBF (actually should be stated MTTF since they are not repairable) values of 108 (one hundred million) or 109 (one billion) hours. If one were to divide these numbers by hours in a year to project useful life, this would result in a useful life of 11,415 to 114,155 years! In reality, electrolytic capacitors, if derated and applied properly typically have a useful life of 10 to 20 years. This is because the electrolyte in electrolytic capacitors dissipates, drying up the capacitor, causing significant degradation in performance (capacitance, leakage current, or ESR) or outright open or short failure. This doesn’t mean that electrolytic capacitors are necessarily bad, just that they don’t live for 10,000+ years.
So, how should MTBF and MTTF be used? They should be used as indicators of failure rate during the useful life of the product. So, you take the MTBF or MTTF value and invert it, dividing 1 by it. This gives you the expected failure rate per operating hour for the product during its useful life. So, our electrolytic capacitors that have a MTBF of 108 (one hundred million) or 109 (one billion) hours actually have an expected failure rate of 1 to 10 x 10-9 failures per operating hour. It is possible that they will be very reliable during their 10 to 20 year useful life, but then they are dried out and done.
Using MTBF or MTTF values as projections of product useful life is extremely misleading and will probably get you laughed out of your job. Think about that before you improperly use MTBF or MTTF to claim that a product will last 10,000 years. Somebody may ask for a warranty that long. In writing.
Mistake #2: MTBF and MTTF assume a constant failure rate during the useful life of the item.
Many products do not exhibit a constant failure rate. Especially if the early failures were not mitigated and the product was not properly maintained. MTBF and MTTF only address the portion of the product’s failure population that arise out of random chance and apply a very simplistic “mean” by dividing the total operating time of the product population by the total number of failures. This is then made to look scientific by then stating that this is an exponential distribution whereby the failures that arose in the population were evenly distributed with no proof of even distribution. But the world is not random and failures do not arrive at a constant rate over the life of the product or product population. Most product failures happen in non-exponential distribution, non-random patterns for identifiable reasons.
Let’s say you have a product population of five products with the following failure times: 98, 99, 100, 101, 102. If you use the standard MTBF averaging, you have a MTBF of 100 hours. But these failures are not randomly distributed with a constant failure rate. They are clustered around 100 hours and there is probably an identifiable reason why.
Let’s say you have a product population of five products with the following failure times: 10, 10, 10, 235, 235. Again, if you use the standard MTBF averaging, you have a MTBF of 100 hours. It is obvious that there is something going on that caused three products to have a very short life and two products to have a much longer life. Either way, there is probably an identifiable reason why three products failed early and two lived much longer.
Assuming a constant failure rate and using simple averaging of failure times to come up with MTBF or MTTF values is lazy at best. Don’t be lazy, investigate failures to find root causes. These root causes will help you determine how to design products to eliminate the failure, mitigate against the failure, or perform proper preventive and predictive maintenance to avoid the failure.
Mistake #3: MTBF and MTTF are given an assumption of high likelihood that the product will make it to the value.
Even if we do mitigate early life failures and perform proper maintenance, most people assume that the MTBF or MTTF is a value with high statistical likelihood like a B10 life (the point at which 10% of products fail and 90% continue to survive) for bearings. Due to the constant failure rate assumption and underlying statistical distribution, MTBF and MTTF are actually the point at which 63% of products would have failed and only 37% survive. Some high likelihood, — recall that MTBF is the inverse of the failure rate, not a duration.
You can check the math yourself. The probability of survival of a product following the constant failure rate of the exponential distribution is e-(1/MTBF)(Operating Time). So, a product with a MTBF of 200,000 hours will have a probability of survival of e-(1/200,000)(200,000) or 37%.
Assuming MTBF and MTTF are high likelihood projections is actually almost the exact opposite of how the math really works out. Use MTBF and MTTF with high caution, not high trust.
Mistake #4: MTBF and MTTF data is assumed to be good and current
Even if you make it past the first three mistakes, this fourth mistake usually throws a wrench in MTBF and MTTF because many of the prediction models and prediction tools being sold are based on outdated information and outdated technologies. One example of this is using a MTBF prediction model for a flash memory device. Most of the data behind prediction tools stopped getting updated when the United States Defense Department transitioned to commercial off the shelf acquisition practices and stopped funding the collection of component operating and failure data. One example is many models for flash memory include devices that have 256K or 512K capacity while the world has moved way past this.
Assuming that the information in prediction models and tools is good and current may lead you to making extremely erroneous predictions of MTBF and MTTF. If you are going to predict MTBF or MTTF, you need to either have collected the operating and failure data yourself and analyzed it properly or make sure that component suppliers are providing good data.
Time to move on…
MTBF and MTTF may have had a brief time in the spotlight of reliability when items were screened for early defects and maintained properly, good data was kept, and people didn’t know how to or didn’t know better about uncovering root causes of failures and designing them out or mitigating them. But that past is past. It is time to move on from MTBF and MTTF to more effective methods to drive reliability.
Maybe you are one of the lucky ones who deal with large product populations, products are all properly maintained, and you keep good data so the MTBF and MTTF math still holds.
Good for you.
Most of us live in a demanding world with demanding customers and demanding bosses and tight schedules and limited resources. Customers don’t want to hear about averages that have low confidence levels, they expect the product they bought to live its expected usage life. Bosses don’t want to hear about the huge number of product samples needed to test and huge amount of field data needed to statistically derive the proper failure distribution analysis, they want to know why the product has not launched yet.
Reliability professionals in today’s world have to understand more and guide product teams to:
Design for Reliability for proper application, design margin, and derating.
Design for Maintainability to address issues that must be mitigated by maintenance when the needed product life reliability cannot be achieved without maintenance actions.
Failure Mode and Effects Analysis (FMEA) and Fault Tree Analysis (FTA) to determine the risks to the product based on severity, occurrence, and detection to drive actions to drive down risk before it becomes realized.
Reliability Testing to aggressively test and discover failures, at what point failures occur, and how much reliability margin the product will have to drive actions to correct the weak links in the design.
Design for Manufacturability to preserve the designed in reliability of the product during its manufacture.
Get Good Data from your own test and field history and supplier data you can trust instead of relying on generic and often outdated and obsolete prediction data. Data for your products in your customer’s hands tells you the real story of how your products are actually performing in their actual (and sometimes surprising) usage applications and operating environments.
When you say ‘… uses MTBF’? What is it you’re implying? Do they make important business decisions, or assess product designs, or order spares based on using MTBF?
Probably not.
When you use MTBF, what do you use it to accomplish?
Do you write a report and send it to the requesting team?
Do you run a calculation and provide the resulting MTBF to customers or vendors?
Do you or anyone in your organization use MTBF in a useful manner.
And, if so, does it work for you? Does MTBF actually provide a useful metric related to your product’s reliability performance?
In my experience, MTBF and related metrics are great for meeting requirements or fulfilling requests, not much else. They are not useful for decision making. MTBF is next to useless when ordering spares. And, it is so commonly misunderstood that the report values are often simply misleading.
Do you receive request for MTBF from customers or internal teams? What do they use MTBF to accomplish? Check of as done?
Some may claim they use MTBF as a comparison to previous products. Some claim it provides an insights to the expected reliability performance. Some really do not know what do with MTBF so just ignore the value.
When gathering data for a part count prediction (aka Mil Hdbk 217 or similar) do you request MTBF values? Is so, do you also ask about failure mechanisms, derating parameters, or how/what will most likely fail?
Simply taking the MTBF value provided reinforces that notion that ‘everybody uses MTBF’ and does not provide you or your team useful information.
Data sheets, vendor websites, reliability reports, etc. all contain MTBF (sometimes called life, or reliability, yet the most common reported metric is MTBF or something similar).
MTBF is around us, built into tools, and expected. My contention is that even though it is not useful, it is so common, that it is assumed everybody uses MTBF.
Don’t be Everybody.
You will do a better job reporting reliability as couplets of probability of success and duration, rather than MTBF.
Do something that is useful and easy to use. Do not use MTBF. Be better than everybody. Add value to your organization, to your team, to your customers. Help others by your example, to be like you and not like everybody else.
I’m on vacation and this is just a quick post for the week. The top five posts of NoMTBF.com by visits to date.
How to Calculate MTTF is probably popular as folks may be searching for a way to do this calculation. It’s actually very simple, yet this article asks why would you want to calculate MTBF?
Set a Reliability Goal without MTBF is another recent article and may have gather interest given it may seem impassable to set a goal without MTBF. It is possible and actually useful.
What is the purpose of Reliability Predictions is a guest post by Andrew Roland (3 of the top 5 are guest posts…) where he examines the useful use of predictions and where many have gone astray assuming a use.
Where does 0.7eV Come From – well, actually the activation energy that represents a doubling of rate in a chemical reaction with an increase in temperature of about 10°C is 0.7eV – beyond that Kirk explores the ramifications.
Back at my office next week, and home to find a few more record breaking articles to post. Plus, if you’re interesting in writing a post, either a problem with solution, a case study, or common issue with assumptions related to reliability – let’s see how it does with visits and views.
Sure, it would be easy to use MTBF for a system reliability goal. Your organization has regularly used MTBF. Your customers are asking for MTBF. The competition all use MTBF. Even your vendors supply only MTBF.
Yet, you know it’s not the best metric to use. It’s not accurate, it’s not useful, and you rather use something else.
How does your equipment fail? How do you plan for spares? Do you use your existing failure data to help refine your maintenance planning?
Given the title of the article, these questions are reasonable. As either a plant reliability or maintenance engineer do you also rely on gut feel to refine your estimates? If you rely on MTBF or similar metrics, you most likely do not trust the data to provide useful answers. Continue reading Maintenance and Statistics Without MTBF→
In the section on predictions you mention Dr. Box’s oft quoted
statement that “..all models are wrong, but some are useful.” In the
same book Dr. Box also wrote, “Remember that all models are wrong; the
practical question is how wrong do they have to be to not be useful.” [see these and other quote by Dr. George Box here]
Reliability predictions are intended to be used as risk and resource
management tools. For example, a prediction can be used to:
Compare alternative designs.
Used to guide improvement by showing the highest contributors to failure.
Evaluate the impact of proposed changes.
Evaluate the need for environmental controls.
Evaluate the significance of reported failures.
None of these require that the model provide an accurate prediction of
field reliability. The absolute values aren’t important for any of the
above tasks, the relative values are. This is true whether you express
the result as a hazard rate/MTBF or as a reliability. Handbook methods
provide a common basis for calculating these relative values; a
standard as it were. The model is wrong, but if used properly it can
be useful.
Think about the use of RPN’s in certain FMEA. The absolute value of
the RPN is meaningless, the relative value is what’s important. For
sure, an RPN of 600 is high, unless every other RPN is greater than
600. Similarly, an RPN of 100 isn’t very large, unless every other RPN
is less than 100. The RPN is wrong as a model of risk, but it can be
useful.
I once worked at an industrial facility where the engineers would dump
a load of process data into a spreadsheet. Then they would fit a
polynomial trend line to the raw data. They would increase the order
of the polynomial until R^2 = 1 or they reached the maximum order
supported by the spreadsheet software. The engineers and management
used these “models” to support all sorts of decision making. They were
often frustrated because they seemed to be dealing with the same
problems over and over. The problem wasn’t with the method, it was
with the organization’s misunderstanding, and subsequent misuse, of
regression and model building. In this case, the model was so wrong it
wasn’t just useless, it was often a detriment.
Reliability predictions often get press. In my experience, this is
mostly the result of misunderstanding of their purpose and misuse of
the results. I haven’t used every handbook method out there, but each
that I have used state somewhere that the prediction is not intended to
represent actual field reliability. For example, MIL-HDBK-217 states,
“…a reliability prediction should never be assumed to represent the expected field reliability.”
I think the term “prediction” misleads
the consumer into believing the end result is somehow an accurate
representation of fielded reliability. When this ends up not being the
case, rather than reflecting internally, we prefer to conclude the
model must be flawed.
All that said, I would be one of the first to admit the handbooks could
and should be updated and improved. We should strive to make the
models less wrong, but we should also strive to use them properly.
Using them as estimators of field reliability is wrong whether the
results are expressed as MTBF or reliability.
