![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
OK, so here's a question.
When you look at product datasheets, sometimes they quote an "MTBF"
figure. (As in, Mean Time Between Failures.) The question is... do these
numbers mean anything? Are they a product measurement, or a design goal?
(I.e., do you *design* a product to have an MTBF of over 100,000 hours?
Or do you design a product and then *measure* what it's MTBF actually
is?) What exactly is the mean taken over?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 30 Jan 2009 13:42:23 +0000, Invisible <voi### [at] dev null> wrote:
>Or do you design a product and then *measure* what it's MTBF actually
>is?) What exactly is the mean taken over?
Yes, the mean is generally taken from installation to the present or the last
reporting period.
And there is also mean time to repair (MTTR)
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Or do you design a product and then *measure* what it's MTBF actually
>> is?) What exactly is the mean taken over?
>
> Yes, the mean is generally taken from installation to the present or the last
> reporting period.
>
> And there is also mean time to repair (MTTR)
So... you design your product, set up a million of them, measure how
long it takes each one to fail, and take the arithmetic mean of that?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> So... you design your product, set up a million of them, measure how long
> it takes each one to fail, and take the arithmetic mean of that?
For our products at least, we usually set up 5-50 of them depending on what
the final volumes will be. Before mass production has started it is very
expensive to make products, so you try to keep the numbers down as much as
possible.
Usually we have a target from our customer, like 10000 hours, so we design
with that in mind. The testing usually confirms that everything will last
ok for 10000 hours, but sometimes we need to go back to the customer and
negotiate a change in spec if the results aren't so good. Either they then
tell us to fix it and we go through another 10000 hour test, or they agree
with the spec change (usually accompanied with a price reduction!).
One cool thing (literally) is that before an entire car goes on sale it must
go through similar tests, they essentially stick it in a freezer for 6
months at -40 degrees and then check that everything works afterwards. This
is part of the reason why cars take several years to design and test before
they are sold.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> One cool thing (literally) is that before an entire car goes on sale it
> must go through similar tests, they essentially stick it in a freezer
> for 6 months at -40 degrees and then check that everything works
> afterwards. This is part of the reason why cars take several years to
> design and test before they are sold.
LOL! Cool. ;-)
Reminds me of the experiment I saw where they were testing a cow worming
device. Basically it's a lump of special metal, you use a gun to shoot
it down the cow's throat (??!?!!), and it sits inside the cow's stomach,
slowly releasing chemicals which kill digestive parasites. Anyway, to
test it, they basically took a dozen of these things and put them inside
an artificial stomach. That is, a tray full of acid inside an oven at
Let me tell you: it was smelly. :-S
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> afterwards. This is part of the reason why cars take several years to
> design and test before they are sold.
Bellcore has the phone pole farm. Hundreds of 4-foot-high telephone poles in
a field, some with showerheads sprinkling them, some with mirrors around
them shining extra sun on them, etc etc etc, to see how long the various
treatments would make phone poles last.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> When you look at product datasheets, sometimes they quote an "MTBF"
> figure. (As in, Mean Time Between Failures.) The question is... do these
> numbers mean anything? Are they a product measurement, or a design goal?
> (I.e., do you *design* a product to have an MTBF of over 100,000 hours?
> Or do you design a product and then *measure* what it's MTBF actually
> is?) What exactly is the mean taken over?
I guess this depends on how good it is done.
Small companies that can't afford a dedicated quality department may just pick a
bunch of samples fresh from production, run them for some time, count the number
of failures, and give the MTBF as <test duration> * <number of samples> /
<number of failures>.
The proper process, however, should start with experience from previous products
and the design changes implemented in the current one, to specify failure modes
(in what ways can it fail?), guesstimate failure mode probailities (how likely
is it to fail this way?), guesstimate probability distributions (how long will
it take to fail this way? e.g. failure modes due to production problems are
often most likely to show up during the first hours of use, while failure modes
due to wear are often increase in likelyhood over time), and other such details.
Also, the risk of specifying a wrong MTBF in the datasheet is an issue (how sure
do we want to be about the MTBF?)
From all this information, a test plan is devised (using accepted best pracice
and certain statistical formulae) specifying things like:
- How do we test?
- How do we detect the individual failure modes?
- How long do we test each sample?
- How do we pick samples to test?
- What MTBF do we hope to see confirmed?
- How many samples do we have to test for confirmation?
- How many failures do we accept *at most*, (a) in total, and (b) per failure
mode, to consider the expected MTBF confirmed?
In theory, such a test plan is (typically) only suitable to confirm (or, more
precisely, give a certain confidence in) a certain lower limit of the MTBF; If
the results fail to give the desired confidence in the expected MTBF, a new
MTBF guesstimate must be made, and the tests re-run (unless the test results
can be mapped to the new test plan in a mathematically "clean" way); on the
other hand, if the results indicate that the true MTBF is probably
significantly higher, it may still be decided to go with the more conservative
original guesstimate, because gaining enough confidence in the indicated MTBF
may require much more exhaustive (and therefore more expensive) tests. Both
cases should also give rise to the question what actually went wrong - whether
the error is actually in the MBTF guesstimate or in the tests - and why.
All in all, quality control is a science by itself...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
...but don't ask *this* engineer:
http://uk.youtube.com/watch?v=SNgNBsCI4EA
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Bellcore has the phone pole farm. Hundreds of 4-foot-high telephone poles
> in a field, some with showerheads sprinkling them, some with mirrors
> around them shining extra sun on them, etc etc etc, to see how long the
> various treatments would make phone poles last.
That's cool :-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
>> Bellcore has the phone pole farm. Hundreds of 4-foot-high telephone
>> poles in a field, some with showerheads sprinkling them, some with
>> mirrors around them shining extra sun on them, etc etc etc, to see how
>> long the various treatments would make phone poles last.
>
> That's cool :-)
It was especially funny when they split into AT&T Long Distance and the
local telcos. They had to cut a new door in each side of the building
there, brick up the front door, and build a wall down the middle of the
building on the inside, so they could comply with the law not to share
assets. Some other parts of the facility were dedicated to long-term testing
of the long-distance stuff, see.
There was even a foot-high brick wall down the middle of the parking lot,
and now two entrances to the parking lot. Weird.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |