Evaluation of reactive chemical hazards can range from simple paper-based calculations to highly complex testing and modeling. This post is aimed to help you formulate a systematic strategy for evaluating reactive chemical hazards in your facility. I will divide the various approaches in three tiers – simple to complex.[Read more…]
Give me a place to stand on, and I will move the Earth.Archimedes
Its known HALT is an effective way to find the weaknesses in your product during the reliability improvement program. In doing so, we view HALT as a qualitative test only. We cannot define the reliability and lifetime of the product from its results. So, unfortunately, we cannot use HALT for purposes of Type Certification, confirm the lifetime of Critical Parts, predict the warranty and maintenance costs, which are required, for example, for aviation.
If we could combine the effectiveness of HALT (high acceleration of testing) with the benefits of quantitative testing, we would get a very powerful tool for the Reliability Demonstration and the Reliability Development of the new products.
“What’s the MTBF of a Human?” That’s a bit of a strange question?
Guest post by Adam Bahret
I ask this question in my Reliability 101 course. Why ask such a weird question? I’ll tell you why. Because MTBF is the worst, most confusing, crappy metric used in the reliability discipline. Ok maybe that is a smidge harsh, it does have good intentions. But the amount of damage that has been done by the misunderstanding it has caused is horrendous.
MTBF stands for “Mean Time Between Failure.” It is the inverse of failure rate. An MTBF of 100,000 hrs/failure is a failure rate of 1/100,000 fails/hr = .00001 fails/hr. Those are numbers, what does that look like in operation? [Read more…]
A Novel Reason to Use MTBF
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…]
Reliability activities serve one purpose, to support better decision making.
That is all it does. Reliability work may reveal design weaknesses, which we can decide to address. Reliability work may estimate the longevity of a device, allowing decisions when compared to objectives for reliability.
Creating a report that no one reads is not the purpose of reliability. Running a test or analysis to simply ‘do reliability’ is not helpful to anyone. Anything with MTBF involved … well, you know how I feel about that. [Read more…]
Three prototypes survive the gauntlet of stresses and none fail. That is great news, or is it? No failure testing is what I call success testing.
We often want to create a design that is successful, therefore enjoying successful testing results, I.e. No failures means we are successful, right?
Another aspect of success testing is in pass/fail type testing we can minimize the sample size by planning for all prototypes passing the test. If we plan on running the test till we have a failure or two, we need more samples. While it improves the statistics of the results, we have to spend more to achieve the results. We nearly always have limited resources for testing.
Let’s take a closer look at success testing and some of the issues you should consider before planning your next success test. [Read more…]
Despite standing for the time between failures, MTBF does not represent a duration. Despite having units of hours (months, cycles, etc.) is it not a duration related metric.
This little misunderstanding seems to cause major problems. [Read more…]
The Fear of Reliability
MTBF is a symptom of a bigger problem. It is possibly a lack of interest in reliability. Which I doubt is the case. Or it is a bit of fear of reliability.
Many shy away from the statistics involved. Some simply do not want to know the currently unknown. It could be the fear of potential bad news that the design isn’t reliable enough. Some do not care to know about problems that will requiring solving.
What ever the source of the uneasiness, you may know one or more coworkers that would rather not deal with reliability in any direct manner. [Read more…]
To mean it means very little, as it rarely occurs. Products fail for a wide range of reasons and each failure follows it’s own path to failure.
As you may understand, some failures tend to occur early, some later. Some we call early life failures, out-of-box failures, etc. Some we deem end of life or wear out failures. There are a few that are truly random in nature, just as a drop or accident causing an overstress fracture, for example. [Read more…]
The calculation of MTBF results in a larger number if we make a series of MTBF assumptions. We just need more time in the operating hours and fewer failures in the count of failures.
While we really want to understand the reliability performance of field units, we often make a series of small assumptions that impact the accuracy of MTBF estimates.
Here are just a few of these MTBF assumptions that I’ve seen and in some cases nearly all of them with one team. Reliability data has useful information is we gather and treat it well. [Read more…]
We Need to Try Harder to Avoid MTBF
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…]
3 Ways to Expose MTBF Problems
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 there approaches that you can use to ferret out MTBF thinking and move your organization toward making informed decisions concerning reliability. [Read more…]
Why do we use ReliaSoft instead of JMP to Identify the Time to Failure?
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…]
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…]
Neither includes using MTBF, btw.
And, I’m not thinking about the common language definition either.
Plus, I may have this all wrong. Here is the way I think about the reliability of something. More than ‘it should just work’ and different than ‘one can count on it to start’. When I ask someone how reliable a product is, this is what I mean.
By explaining my basic understanding we can compare notes. It is possible, quite possible, that I will learn something. As you may as well. Let’s see. [Read more…]