Your Reliability Engineering Professional Development Site
All articles listed in reverse chronological order.
As stated before, variation happens.
The root cause of the variation for a stable process includes material, environmental, equipment, and so on, changes that occur during the process. No saw cuts the same length of material twice – look close enough there is some difference. [Read more…]
There are a lot of reliability tools.
From FMEA to FTA, from ALT to HALT, from derating to sneak circuit analysis. We also have a lot of acronyms. We cannot afford to do all the tasks, so which do we select and why?
Each activity has some reason for existing. Each has some question that it helps answer. HALT helps to find what will fail. ALT helps to determine when failures may occur.
Knowing what each tool is capable of doing is a start. Knowing what you need to know is essential.
It is the idea to eradicate MTBF from common use. The first question was
How do you explain what MTBF is and isn’t to someone that misunderstand MTBF?
An easy method to monitor and control a process average. It is an alternative to the Shewhart control chart.
Pre-control charts work well with stable and slow process drifts or changes. These charts provide a means to monitor a process and act as a guide for process centering.
They are easier to setup, implement, and interpret the Shewhart charts. [Read more…]
Every failure provides information. It provides time to failure, stress strength relationship, process stability and design margin types of information. In every case. Even failures directly related to human error.
A hardware intermittent failure observed by a firmware engineer should not be dismissed. Rather recorded, explored and examined.
A single intermittent failure, or glitch, may indicate nothing other than just a totally random glitch, or a design error that degrades over time causing 50% of units to fail in first three months.
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. [Read more…]
The connection between the specifications or drawings or design requirements and the manufacturing process is the capability of the process to consistently create items within spec.
A ratio of the specification over the spread of measured items provides a means to describe the process capability.
The ratios rely on the standard deviation or spread of the produced items. The index is meaningful only if the process is stable. Thus beyond making sure the measurements have minimal measurement error, check the stability using the appropriate control chart.
In this article we are assuming the measurements are normally distributed, yet knowing that is not always the case, you can calculate capability indices using the actual distribution.
The indices will have similar interpretations yet take care when applying these concepts using other than normal distribution data.
Some days are better than others. We sometimes run into failure when working to create a new product. With a little investigation we suspect the components are not working as expected.
We’ll call the vendor and ask for an explanation. If this is normal production and variability of performance, our product will suffer an higher than expected failure rate. The vendor will assure us with:
Not helpful. [Read more…]
Guest Post by Andrew Rowland, Executive Consultant, ReliaQual Associates, LLC, www.reliaqual.com in response to the ‘Reliability Predictions‘ article.
Hi Fred,
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:
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.
Best Regards,
Andrew
The basic idea of reliability growth is the information learned during testing allows the team to make improvements.
The improvements then reveal themselves in the next round of testing. There are improvements during each test phase as the immediate fixes occur.
Plus some improvements may have longer lead times and be implemented in time for the next round of testing. [Read more…]
As reliability professionals know, products fail. They fail for a wide range of reasons and over a broad span of time. We know it happens.
This doesn’t help when it impacts us directly though. When we purchase a product or service, it should just work. We know the odds, we know better, yet the sting of failure remains.
Customer Service provides a range of services, one of which is helping customers receive the benefit of their purchase. We call customer service to report a failure and expect their help making it right. [Read more…]
Let’s take a graphical view of reliability improvement that occurs during product development or improvement projects.
If we are making improvements the system reliability should increase. We can use the build, test, fix approach to measure improvements, find failures, design improvements, and repeat. [Read more…]
Really? Is MTBF the only way to work with reliability growth?
Received this question via LinkedIn (feel free to connect with me there) and hadn’t given it much thought before. I am familiar with a few growth models and regularly have seen MTBF in use. Thus discounted the modeling as an approach of little interest to me or my clients.
MTBF measures the inverse of the average failure rate, when in many cases we really want to know about the first or tenth percentile of time to failure. Measuring and tracking the average time to failure provides little information about the onset of the first few failures.
Did just a quick check of common reliability growth models and found a few in the NIST Engineering Statistics Handbook http://www.itl.nist.gov/div898/handbook/apr/section1/apr19.htm .
The Homogeneous Poisson Process (HPP) when the failure rate is constant over the time period of interest. This relies on the exponential distribution and the assumption of a stable and random arrival of failures, which is almost always not true (in my experience). It’s a convenient assumption as it makes the math a lot simpler, yet provides only a crude model and poor results.
The Non-Homogeneous Poisson process (NHPP) Power Law and Exponential Law models provide information based on the cumulative number of failures over time. These models rely on the notion that any system has a finite number of design errors that once resolved create a system that has a HPP behavior.
Duane Plot provides a graphical means to show cumulative failures over time. When the arrival of failures slows the curve decreases in slope effectively bending over. This provides a means to estimate the final failure rate (average unfortunately).
Given my dislike of all things MTBF, I’ve not used these model to estimate MTBF. Instead stay with the Duane plot and graphically track when the team is finding and fixing enough faults in the design.
I also tend to use reliability block diagrams (RBD) with each block modeled with the appropriate reliability distribution. For a series model then all we need to do is multiple the reliability value from each block for time t (say warranty period, or mission time, etc.) to estimate the system reliability at time t.
For complex systems with some amount of redundancy the RBD does get a bit more complicated. For very complex systems with degraded modes of operation or significant repair times then use Petri Nets or Markov Models to properly model.
In the vast majority of cases a simple RBD is sufficient to capture and understand the reliability of a system. This allows the team to focus on improving weak areas and reduce uncertainty though improving reliability estimates. An RBD does not require nor assume an exponential distribution and the math is easy enough to manage, often even in your favorite spreadsheet.
Reliability growth starts with model of the estimated number of failures over a time period. Testing then provides a value for that estimate. This does not require the use of MTBF, so instead of assuming a constant failure rate, focus on the failure mechanisms and use a simple RBD to build a system model. The reliability growth is the result of identifying areas for improvement and doing the improvement. RBD, in my experience, provides a great way to communicate with the team where to focus improvements.
The root sum squared (RSS) method is a statistical tolerance analysis method.
In many cases, the actual individual part dimensions occur near the center of the tolerance range with very few parts with actual dimensions near the tolerance limits. This, of course, assumes the parts are mostly centered and within the tolerance range.
RSS assumes the normal distribution describes the variation of dimensions. The bell-shaped curve is symmetrical and fully described with two parameters, the mean, μ, and the standard deviation, σ. [Read more…]
What happens when a product you produce fails? You customer may call and return the product. They may expect you to provide a replacement or refund.
Does it matter if the failure was due to a capacitor or motor that you didn’t design, just purchased?
No.
Does it matter if a supplier’s supplier made an error that directly lead to the failure?
No.
You customer experienced a failure and since the purchase was from you, you are expected to make it right.