It is at least 0.75 eons ago, so I only have "vague" memories and no specific details on the procedures any more.
I had to list all the quantities of each individual component type on a spreadsheet and out popped a calculated MTBF number. We also ran a number of instruments until failures occurred to determine a more "precise" number.
Sorry to be of so little help,
Ahne.
Interesting paragraph from http://en.wikipedia.org/wiki/Reliability_engineering
Some recognized reliability engineering specialists – e.g. Patrick O'Conner, R. Barnard – have argued that too much emphasis is often given to the prediction of reliability parameters and more effort should be devoted to the prevention of failure (reliability improvement).[3] Failures can and should be prevented in the first place for most cases. The emphasis on quantification and target setting in terms of (e.g.) MTBF might provide the idea that there is a limit to the amount of reliability that can be achieved. In theory there is no inherent limit and higher reliability does not need to be more costly in development. Another of their arguments is that prediction of reliability based on historic data can be very misleading, as a comparison is only valid for exactly the same designs, products, manufacturing processes and maintenance under exactly the same loads and environmental context. Even a minor change in detail in any of these could have major effects on reliability. Furthermore, normally the most unreliable and important items (most interesting candidates for a reliability investigation) are most often subjected to many modifications and changes. Engineering designs are in most industries updated frequently. This is the reason why the standard (re-active or pro-active) statistical methods and processes as used in the medical industry or insurance branch are not as effective for engineering. Another surprising but logical argument is that to be able to accurately predict reliability by testing, the exact mechanisms of failure most have been known in most cases and therefore - in most cases - can be prevented! Following the incorrect route by trying to quantify the complete Reliability Engineering problem in terms of MTBF or Probability and using the re-active approach is referred to by Barnard as "Playing the Numbers Game" and is regarded as bad practise.[2]
-----Original Message-----
From: Robert Kondner [mailto:[log in to unmask]]
Sent: 12 April, 2013 10:51
To: 'TechNet E-Mail Forum'; 'Ahne Oosterhof'
Subject: RE: [TN] Reliability Predictions
Ahne,
Can you give me a reference for the formulae? I am curious about this.
Here is a link: http://thequalityportal.com/glossary/rc.pdf of what I was thinking about. Sampling and errors rates required to establish levels of reliability.
Now remember, I am claiming total ignorance here. But if MTBF is the average time to failure for a device, and we require a 50% confidence in that MTBF number, then we would expect zero failures in a test of 1 devices for 1 hours for each declared MTBF hour.
So if we test 400 devices for 100 hours can we declare the MTBF at 40K Hours?
I probably screwed this up terribly, I should go back to the text books, but the idea here is having zero failures with a certain lot size for a certain time must, I think, tell us something about the MTBF. I just don't know exactly. I can see where getting failures helps to define a failure distribution.
Thanks,
Bob K.
-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Ahne Oosterhof
Sent: Friday, April 12, 2013 12:58 PM
To: [log in to unmask]
Subject: Re: [TN] Reliability Predictions
Without any failure a zero gets stuck in the formula, which upsets those who are stuck with formulae.
Ahne.
-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Robert Kondner
Sent: 12 April, 2013 08:43
To: [log in to unmask]
Subject: Re: [TN] Reliability Predictions
Ahne,
Very good answer.
But, If you do a test and have zero failures can't you still provide a MTBF based on a confidence level?
I am not experienced in this area but I would think getting 0 failures should always give you a better confidence level than having one.
Thanks,
Bob K.
-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Ahne Oosterhof
Sent: Thursday, April 11, 2013 11:26 PM
To: [log in to unmask]
Subject: Re: [TN] Reliability Predictions
Calculating a prediction of the MTBF by using failure predictions for each component is not a very precise method, or more accurately, a very imprecise method. The MTBF of any component is greatly affected by its power consumption and its resulting temperature rise and the temperature of the environment (and a few other things). But you get a number you can wow management (and customers) with.
We did an actual life test on a number of instruments to determine MTBF. But I was told if no failure occurred they could not calculate a number. So I introduced one failure after the test was almost finished to at least get them to give me a number.
Ahne.
-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Blair Hogg
Sent: 08 April, 2013 13:10
To: [log in to unmask]
Subject: [TN] Reliability Predictions
This might be a little off-topic but does anyone out there in TechNet Land know if there is an IPC standard for reliability predictions, similar to Mil 217 or Telcordia?
The process seems straightforward, grossly simplified you take a sum of the expected number of failures for all components on the BOM and take the inverse for MTBF. Haven't done enough research to determine the difference between the various standards used, it's a spare time project (whenever I get any).
Thanks,
Blair
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask] ______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask] ______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask] ______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask]
______________________________________________________________________
|
