Forum: Reliability & Maintainability Questions and Answers
Posted by: Bahman Kaboodrangi (Bahman.Kaboodrangi-Da@Boeing.com )
Date posted: Thu Jan 6 16:45:19 US/Eastern 2000
Subject: Base Failure Rate for Switches Notice1 vs Notice2
Why is the Base Failure Rate (Lambda B)for Switches in Notice 2 is worse than Notice 1. Please provide reason for the difference between the two versions.
Posted by: Floyd Kreuze (email@example.com )
Date posted: Thu Jan 6 10:10:11 US/Eastern 2000
Subject: Source of Latest PEM Field FR Estimates
Where can I find some information on the very latest estimates of field failure rates for plastic encapsulated microcircuit (PEM) devices? Any leads or suggestions would be appreciated. Thanks.
Posted by: Xiangping,Wu (firstname.lastname@example.org )
Date posted: Mon Jan 3 3:14:14 US/Eastern 2000
Subject: Reliability Prediction
I did a reliability prediction several days before.This system consists of about 10~15 PCBs,and there are average 500 components on each PCB.I used 217F and Bellcore respectively.MTBFs are 5800h and 40000h.Is that reasonable?
After that,I saw a reference about similar system of other company(a famous company).In that reference,they claim their system'MTBF is 1000 years(failure rate is 111 fits).Oh my god!Is that possible?Or am I wrong?
Posted by: Benny (email@example.com )
Date posted: Thu Dec 30 1:29:03 US/Eastern 1999
Subject: Derating guidelines for SMT
I am trying to find some derating guidelines with regards to Surface Mount Technology (SMT), especially in the area of microcircuits. Are such guidelines available? In general, are there any differences between the derating factors for SMTs compared to MIL-HDBK-338?
I understand that the latest derating study conducted by the former U.S Air Force Rome Lab in 1992 can be found in the technical report, RL-TR-92-11 (ADA253334). Does this study cover SMT? Please advise.Thanks.
Posted by: Mike D'Aquila (firstname.lastname@example.org )
Date posted: Mon Dec 20 10:23:09 US/Eastern 1999
Subject: The Applicabilility of Reliability Prediciton Techniques
I, first of all, extend an apology to all RAMP professionals who conclude from readnig this question that I am trivializing the scope and depth of the [correct]answer. I do not mean to, however: While spending many years in the COTS and defense contractor environments, on numerous occasions I personally participated ( or took notice of ) in debates about - for instance - using some interaiton of *217* as a prediction technique for, say, a next generation COTS processing architecture vs. a Bellcore-based algorithm or even, perhaps, one that considered Weibull or physics-of-failure, or whatever hybrid was in vogue at the time. I even recall the Redstone Arsenal organizational debate that was founded on a belief that the USA should move away from 217 totally, as the default technique.
Yes, there were many valid arguments against using 217 as a technique in the COTS development arena - one being that the appendices never were able to keep up with the lightship speed of the day's ic-development race to revenue fame and glory....i.e. always "..one step behind.."...or whatever. Generally, too, the knowledged concluded that 217's felxibility with setting Quality Factors allowed for too much subjectiveness so as to cloud viability and consistency. And, in the end, certain RAMP-guys said that actual measurement proved that 217 was a pessimist. So, with all that drivel comes my question: Are there any current "white paper" or "treatise" type discussions known to RAC where this the applicability of one technique vs another for COTS product development is at the focus ? Even though I have not looked into this for 18-24 months, I am confident that the synchronization between academia and commercial product development is again skewed......even more, perhaps. I read in one of the FAQs teh fact that some believe that 217 can be 2-3 times too pessimistic, or more, as compared to actual demonstration. PRISM, as I understand it, it to close this gap ?????? Thanks for your time........ Mike D'Aquila, 603.434.8231, "email@example.com"