Your Reliability Engineering Professional Development Site
Now for something completely different. Roaming the net looking for an interesting advertisement or data sheet with a ‘great’ (i.e. bad) example of the mis use of MTBF, ran across that MTBF is actually being used by at least one government for department budgeting.
[Read more…]
Most of us have seen reliability specified using a requirement like the following:
The Zeus 5000 SUV shall have an MTBF of 144,269.5 miles with a 90% confidence.
Some readers may not have seen reliability requirements specified in any other way. What they have always seen has read something like: The widget shall have an MTBF of X with a Y% confidence. This reliability requirement structure is rather ubiquitous
in military and aerospace specifications, which along with Mil-HDBK-217, have been major influences in reliability specification practices for decades in many industries.
After a discussion with a client this morning, and their motor vendor’s reliability engineer asked for a reference for a sample size calculation formula I recommended, I had a short email exchange with said reliability engineer. In my note with the references, I included an aside with a link to this site. He liked the site and agreed that MTBF was often misunderstood and not useful. He asked if the store sold much in the way of NoMTBF logo’ed merchandise – it doesn’t btw. I thought about how and why this site and the store exist and that invited my passion on this topic once again.
We need to do something to further the eradication of MTBF.
[Read more…]
The dividing up of a reliability goal is one way to specify reliability goals for specific key elements of your product. Yet, that is not the only purpose of allocation. It can and should be a key practice to get your team working toward a common goal in a unified and collaborative manner.
Let’s discuss a couple of easy ways to accomplish reliability allocation or apportionment, then examine a valuable way to use this tool to improve the chances of achieving your overall reliability goal.
[updated January 2025]
Just answered a question on where to find reliability engineering training on basics and statistics. There are plenty of options and below I’m listing just where to find the many, many options available to you.
[Read more…]
Life testing a product or component, at times, involves months and months of testing. Even accelerated life testing can take a long time, given the limitation on our ability to cause the proper acceleration for meaningful results. So, what is one to do if waiting 3 months for test results is unacceptable?
Let’s explore a few alternatives along with the pros and cons. We examine using our knowledge and the knowledge of others to streamline the testing or avoid it altogether. We also need to consider why we need to estimate life in the first place. Sometimes, estimating the life of something is not all that useful or valuable. [Read more…]
Just back from the Reliability and Maintainability Symposium and not happy. While there are signs, a proudly worn button, regular mentions of progress and support, we still talk about reliability using MTBF too often. We need to avoid MTBF actively, no, I mean aggressively.
Let’s get the message out there concerning the folly of using MTBF as a surrogate to discuss reliability. We need to work relentlessly to avoid MTBF in all occasions.
Teaching reliability statistics does not require the teaching of MTBF.
Describing product reliability performance does not benefit by using MTBF.
Creating reliability predictions that create MTBF values doesn’t make sense in most if not all cases. [Read more…]
MTBF use and thinking is still rampant. It affects how our peers and colleagues approach solving problems.
There is a full range of problems that come from using MTBF, yet how do you spot the signs of MTBF thinking even when MTBF is not mentioned? Let’s explore the approaches that you can use to ferret out MTBF thinking and move your organization toward making informed decisions concerning reliability. [Read more…]
Over 20 years ago the Assistant Secretary of the Army directed the Army to not use MIL HBK 217 in a request for proposals, even for guidance. Exceptions, by waiver only.
217 is still around and routinely called out. That is a lot of waivers.
Why is 217 and other parts count database prediction packages still in use? Let’s explore the memo a bit more, plus ponder what is maintaining the popularity of 217 and ilk.
[Read more…]
Ongoing Reliability Testing (ORT) is a class of product testing that aims to identify potential field reliability issues after product launch and before customers experience failures. Typically, done using a rotation of samples directly from production and using expected use conditions/stresses, the testing balances many factors to be of value.
ORT works well to monitor an ongoing production process subject to variation. If that variation impacts reliable performance, then a well-designed and implemented ORT should identify the issue.
Let’s explore the range of considerations when designing an ORT to optimize the ORT’s ability to identify field problems efficiently. We will also discuss the various tradeoffs that impact sample size, the use of accelerating stresses, and more.
At least one group called this the ‘Delta Phase.’ It is the period shortly after launching a product and provides a unique opportunity to reduce future field failures and improve customer satisfaction dramatically. The idea is to aggressively identify and resolve any field issues identified by your customers.
There are a couple of ways to implement the Delta Phase with your product launch. Yet, it requires creating a team from the design/development team that has the authority and capability to implement design changes quickly.
Let’s explore the concept of a delta phase and how to implement it in your organization. Plus, let’s examine a few situations that make significant short and long-term reductions in the field failure rate.
This is a question someone posted to Quora and the system prompted me to answer it, which I did.
This question is part of the general question around which software tools do you use for specific situations. First, my response to the question. [Read more…]
System or Operational Effectiveness is comprised of three elements. An early definition included capability, reliability, and availability. Another early definition included availability, dependability, and capability. In essence, can the system do what it’s supposed to do? Is it ready when needed? And is it able to work without failure long enough?
Let’s examine system effectiveness and its factors or elements in more detail. Then, examine an example or two so you can apply this concept to your situation.
Let’s say we want to characterize the reliability performance of a vendor’s device. We’re considering including the device within our system, if and only if, it will survive 5 years reasonably well.
The vendor’s data sheet lists an MTBF value of 200,000 hours. A call to the vendor and search of their site doesn’t reveal any additional reliability information. MTBF is all we have.
We don’t trust it. Which is wise.
Now we want to run an ALT to estimate a time to failure distribution for the device. The intent is to use an acceleration model to accelerate the testing and a time to failure model to adjust to our various expected use conditions.
Given the device, a small interface module with a few buttons, electronics, a display and enclosure, and the data sheet with MTBF, how can we design a meaningful ALT? [Read more…]
Thanks to a reader that noticed my question on why MTBF came into existence, we have a new (new to me at least) rationale for using MTBF. Basically, MTBF provides clarity on the magnitude of a number, because a number in scientific notation is potentially confusing.
What is doubly concerning is the use of MTTF failure rate values in ISO standards dealing with system safety.
Let’s explore the brief email exchange and my thoughts. [Read more…]
