How do you do a rough MTBF analysis? - Page 1
Forum section: electronics / projects

author: Pack34
author_rank: Frequent Contributor
timestamp: June 23, 2016, 03:49:39 pm
content: I've been asked to get some rough and general MTBF numbers for a circuit board. How exactly would I go about doing this?I would assume I would take some reliability information from critical parts of the board, add in expected operating temperature, and some assembly information from the board house.Is there an off-the-cuff formula to do this? I haven't been able to find any reliability information on the datasheets for components. I would assume I would send some emails to vendors or manufacturers requesting the info. What exactly would I request?

author: TheAmmoniacal
author_rank: Unknown
timestamp: June 23, 2016, 03:51:19 pm
content: You make 1000 circuit boards, get them all up running and wait until they've all failed. Then do the statistics O0

author: MagicSmoker
author_rank: Super Contributor
timestamp: June 23, 2016, 05:35:18 pm
content: Quote from: Pack34 on June 23, 2016, 03:49:39 pmThere is no off-the-cuff formula, per se, and any MTBF more accurate than a WAG requires a huge effort and some environmental (specifically, accelerated life) testing.Sanjaya Maniktala does a decent job of covering MTBF estimation of power supplies in one of his books, Switching Power Supplies A to Z.

author: System Error Message
author_rank: Frequent Contributor
timestamp: June 23, 2016, 05:56:17 pm
content: take the lowest MTBF Rating of your components.

author: rfeecs
author_rank: Frequent Contributor
timestamp: June 23, 2016, 06:06:43 pm
content: Some light reading, MIL-HDBK-217F "Reliability Prediction of Electronic Equipment".Here's a summary of what people do from a software company:http://www.reliasoft.com/newsletter/v9i1/prediction_methods.htm

author: Pack34
author_rank: Frequent Contributor
timestamp: June 24, 2016, 02:30:13 pm
content: Thanks!The big question, is where can I get general MTBF numbers for the individual components? I've seen numbers in calculations such as: 2,290,000,000 hrs for an RS232 transceiver and 98,039,215 hrs for a diode. Is this information readily available somewhere? If so, where do I get it?

author: tszaboo
author_rank: Super Contributor
timestamp: June 24, 2016, 03:11:46 pm
content: You do high temperature accelerated aging testing. Calculate the MTBF from that test. When someone ask if this is really the correct method to do it, just nod. If they really question your method, then send links to articles. If, after that they dont leave you alone, go to a soundproof meeting room, tell them they are right, but please, leave you alone with your made up numbers, becuase there isnt a good method to make good numbers in short time.

author: Pack34
author_rank: Frequent Contributor
timestamp: June 24, 2016, 03:18:57 pm
content: I was afraid of that. I was asked to get some rough numbers for a circuit board with two days notice and no boards to test.

author: tszaboo
author_rank: Super Contributor
timestamp: June 24, 2016, 03:29:52 pm
content: Quote from: Pack34 on June 24, 2016, 03:18:57 pm

author: joeqsmith
author_rank: Super Contributor
timestamp: June 24, 2016, 04:52:02 pm
content: You bring up a nightmare topic. For military and automotive we would use 217. Ground mobile for automotive. When I started out, I wrote my own program using IBMs BASIC compiler that had the equations in it and would create a printout. Trivial compared to collecting the data. Later I used a commercial program form Powertronic Systems which was still based off 217. Automotive decided the numbers from 217 were not realistic for that application. A group was formed and they created PREL. That would have been late 90's early 2000. There should be some info on SAE about it.If you put a resistor in a desktop home radio, it may live longer than under the hood of your car. If you have a 0.5W resistor dissipating 0.01W it may live longer than the same part running at 0.48W. If you have a resistor rated for 50V and you run it at 1V, it may live longer than at 40V. Resistor package, type... all go into this.. There's your one resistor. A typical report would be several hundred pages. Some of the places would review line by line....I have no idea what best practices are today..Quote from: rfeecs on June 23, 2016, 06:06:43 pm

author: rfeecs
author_rank: Frequent Contributor
timestamp: June 24, 2016, 05:03:57 pm
content: You hire a consultant. Give him the BOM of your board and the stress levels of each component. He plugs that into his program and gives you a number.

author: saturation
author_rank: Super Contributor
timestamp: June 24, 2016, 07:57:59 pm
content: Using milspec parts you can estimate purely by math, a MTBF, since the parts are rigidly made to standards and have known predicted life spans:http://www.sohar.com/reliability-software/free_mtbf.htmlSimple version based on actual runtime data:http://www.rfwireless-world.com/calculators/MTBF-MTTF-Calculator.htmlQuote from: Pack34 on June 24, 2016, 02:30:13 pm

author: CatalinaWOW
author_rank: Super Contributor
timestamp: June 24, 2016, 11:45:18 pm
content: For quick and dirty analysis the MIL 217 approach is in my opinion the best game in town. And may be slightly better than throwing darts at a board. It has the benefit that it is a known and fairly widely accepted methodology. And has the drawback that it's tables of data have little bearing on modern electronics. You can sometimes patch the holes with manufacturers data, but more often you are just hiding your guesses behind layers of analysis. Hiring an expert may give you an answer that is slightly more likely to reflect reality, but the real value of hiring the expert is the artificial credibility that it gives the answer. The expert will also have a much larger library of existing data/guesses already at hand.You won't know the real MTBF of your board until it has been in the field long enough to start seeing failures. Then the differences between your model and the real environment (which includes the actual components used, the assembler used, the real environment and use pattern they are exposed to and the ability and interest of the user in detecting and reporting failure.) will show up. It is not unusual to find discrepancies of several orders of magnitude.The most famous example of these discrepancies is the US Space Shuttle. Many, many thousands of hours of analysis and component level testing were used to calculate a system failure rate causing death to astronauts was less than one in 100,000 while the actual number was closer to one in 50. The analysis was actually done twice, once during program development, and again after the first shuttle failure.

author: sarepairman2
author_rank: Frequent Contributor
timestamp: June 26, 2016, 12:11:52 am
content: its all nearly useless because of electrical overstress caused by ESD, EMI, etc. How on earth can you calculate a MTBF if some some subsystem or w/e starts spewing damaging transients, slowly errording transistors?the best way is to make something, and document repairs (and your documentation will suck balls unless you police it heavily).you might get some general data like "communications failure". is it because your protection system is inadequate and not clamping enough? thermal aging? Your repair people will find a comm chip that went bad and write down comm fail. Then you will be scratching your head as to why it happened. Or you can heavily scrutinize each return and have managers yelling about backlogs (because who wants to hire a big repair department? it looks bad to visitors). The electronics layman will say something like "oh it was not designed right your product sucks" and not realize that things relating to electrical protection etc require individual attention and FEEDBACK to implement correctly*. You bascially need an entire department dedicated to the job cooperating with the design engineers. The amount of data you get might also be so small that things like employee laziness might totally skew your data. Not to mention that useful data takes years to collect and that NO ONE will want to do anything about it anywayThere is no cost effective one size fits all solution for electrical protection and you will always have people that find problems due to weird electrical things that happen in their facility (take the case of the mini fridge that turned into a 6GHz radio jammer!!!!!!!!!!!! (google it). Imagine the PCB you made started taking a hammering from 6GHz HV! )Every "non robust" solution in your PCB is there only because of cheap design and lack of engineering time/skill.

author: sarepairman2
author_rank: Frequent Contributor
timestamp: June 26, 2016, 12:21:21 am
content: Quote from: rfeecs on June 24, 2016, 05:03:57 pmand have a report thats 90% useless bullshit and 10% weird situational things he saw once in his life that costed you 250$ an hour to generate. This is literally like hiring a advisor to help you bet on horses (this being someone on your design team wanting someone to reassure them that the DCDC converter running with no filter through a 1 amp linear regulator won't fail at 850mA (ignoring inrush currents) because they are too cheap to add $1.50 to the BOM to get a 2 amp linear regulator LOLNow, if you are doing something that is near theoretical limits (deep horizons probe, super sonic low altitude missile (SLAM, google it) ) then sure, it makes sense to hire some expensive advisors to think of stuff. Otherwise you are just looking for someone to reassure your cheapness.What is a consultant gonna tell you about stress levels in some weird semiconductor part you choose because it was cheap that has a 2 page datasheet (where linear technologies would have 20, including test methodologies), with stuff going on unique to that manufacturing process (lets say, depending on how the bond wire was attached to the die)? Not to mention to do their job they will need advanced knowledge of your system behavior (i.e. code behavior, so they understand power cycling over time (that you might not want competitors to know about).I have seen consultants/tradespeople in my job that come in and bullshit with employees for two hours lol!they act like they get a salary (while they rob the company by the hour) (and this is not guys that you want to have a strong professional relationship with, like customers or vendors). It's good that this interaction occurs to a degree for company culture, but often excessive.another problem is that the jobs they perform take wayyyyyyy longer then estimated, so you get management freaking out about how long they will be present for due to cost. why not have your employees learn something and add value to the comapny?

author: Mario Blunk
author_rank: Newbie
timestamp: August 06, 2025, 02:33:30 pm
content: The most important lesson you draw from MIL-HDBK-217 is: You get a sense of why and how frequent electronic assemblies fail under stress. With this knowledge you start designing with another approach, with more care on things you have not seen before.As far as I know, 217 is the mother of all other reliability prediction standards which work similar but with different focus (telecommunication, automotive, medical, ...)ANSI VITA 51.1 provides methods to adjust the prediction models of 217.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 07, 2025, 10:58:00 am
content: Sorry to necropost again, but I just wanted to explain what to do with the MTBF/MTTF figures.When you've got the MTTF number for every component in the system, you invert them all and scale them to failures-per-billion-hours. Then you add together all the failure rates. Finally you invert the result to convert it back into the MTBF for the whole system.

author: coromonadalix
author_rank: Super Contributor
timestamp: August 07, 2025, 02:47:52 pm
content: @steeve ? not conclusive at allat my jobwe oven the assembled machines at least 2 months, we try statistics with clients RMA (causes like HW failures, human errors etcc)and Mil 217 ...We try to get some figures to work with ... we are under 1% for hardware, 2-4 % for SW bugsand sadly higher because of the human factor : abuses, wrong connections / usages / manipulations / abuses that are higher than the specified specs, and this human factor is very hard to calculate outside official RMA's or comissioning reports ...in the end human factor is maybe 10 times more than hardware ...

author: SteveThackery
author_rank: Super Contributor
timestamp: August 07, 2025, 03:27:55 pm
content: Quote from: coromonadalix on August 07, 2025, 02:47:52 pmLet me be clear: i don't disagree with any of the above. 😁👍I wanted to explain the basics of Reliability Engineering when the component MTBF is known. Also the concepts of failure rate, MTBF, MTTF, resilience, redundancy, diversity, and software reliability.I deliberately did not talk about themassivearea ofmeasuringthe reliability of components and systems. This is a whole other area, and a big one at that. Plus it has controversies.There's a whole argument about accelerated ageing, for example. Firstly, its critics say that it exposes components to conditions they will never see in actual service and reveals failure modes that would never happen in service. Secondly, critics point out that MTBF and MTTF numbers have nothing to do with ageing mechanisms - rather they are random in-life failures.I'm not going to take sides in this thread. My position is that there's very little chance the OP has the facilities to perform what you are describing. Rather, they just need a reasonable overview of the most important concepts in the whole area of reliability.One last point: I agree 100% that human factors can often swamp other factors when it comes to the real-world reliability of a system or service. However, the effects of intervention faultscanbe modelled when performing FMEA and other related techniques.

author: Stray Electron
author_rank: Super Contributor
timestamp: August 07, 2025, 09:28:18 pm
content: Quote from: rfeecs on June 23, 2016, 06:06:43 pmI don't know if it's still available but one of the engineers, Anthony "Tony" Flowers, at what was then Martin Marietta Electronic and Missiles Systems in Orlando (now Martin Lockheed) wrote a program to do this and he released it to the public domain in the late 1980s. IIRC it was written in Turbo Pascal but I don't know if he released the source code or not.Part of the problem with calculating MTBFs is that the Mil-Spec failure rate is different for operating time vs non-operating time so you have to know the system's operating requirements and the proportion of the time that each part of the system is powered on. Also the failure rate varies for aircraft, wheeled ground vehicles, tracked vehicles, stationary equipment, etc. The operating failure rate is much higher in tracked vehicles due to the vibrations and higher in wheeled vehicles than stationary equipment, etc etc.OK so you break every end item down into sub-assemblies and then each sub-assembly down into lower level assemblies, etc etc until you get down to the component level. You then make a list of all of the component parts for each next higher level assembly and add up their failure rates to calculate the predicted failure rates (both operating and non-operating) of that assembly. Then repeat for all of the lower level assemblies in the next higher assembly and then calculate the failure rate for the 2nd level assemblies. Then keep repeating until you get to what is called the End Item. That just gives you the operating and non-operating failure rate (usually defined per million hours). Then you have to analyze how the system is operated and make an estimate of how much of the time that each assembly is used as a percentage of the higher that it's next higher assembly is used. That will then basically tell you how much time each assembly is used on (usually) an annual basis. You multiply the annual operating hours for each assembly times it's operating failure rate and that gives you the predicted number of annual failures while operating. The multiply the annual non-operating hours times the non-operating failure rate and that will give you the predicted number of non-operating failures per year. Add the two numbers together to get a total number of predicted failures per year for each and every component and assembly in the EI.Yeah, expect to spent a couple of YEARS inputting all of the numbers and specs for every component and every assembly and linking each component and each assembly to it's Next Higher Assembly in order to get the answers that you seek. And by contract, those are defined as ROM (Rough Order of Magnitude) Estimates.Don't ask me how I know! :-/

author: bson
author_rank: Unknown
timestamp: August 07, 2025, 09:34:11 pm
content: Quote from: SteveThackery on August 07, 2025, 03:27:55 pmIn fact the reason for canonical bathtub shape is that early failures are generally caused by manufacturing defects... And to calculate the mean between early and late failures gives an MTBF/MTTF where in reality few units fail. It's a bit like California winters: they tend to be either wet or dry, with an average or normal that's far less common. For distributions like this it makes a lot more sense to consider two normals, or two distributions: one for manufacturing defects that made it out the door (which may be a term a manufacturer would prefer not to use), and one for age-induced failures. There are organizations for example which replace hard drives at some fraction of the MTTF, but doing so they really only expose themselves to early failures without taking advantage of the full, mostly fault-free, service life. Of course, good product testing, shakedowns, and "burn in" periods will greatly reduce early failures and hence increase reliability metrics. To actually reliably determine the tub shape is really not realistic for small organizations or projects, that's more something you expect from Google or AWS.

author: Stray Electron
author_rank: Super Contributor
timestamp: August 07, 2025, 09:45:46 pm
content: Those early failures are called "infant mortality" in the aerospace and defense industry and they are the reason all incoming parts are tested and burned in and then retested. Also each assembly is tested, even the very low level ones, before they are added to the Next Higher Level assembly.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 07, 2025, 10:06:38 pm
content: Correct. The early part of the bathtub curve is due to manufacturing defects, and the later part is due to ageing effects. But the lengthy middle part of the curve forms a pretty constant failure rate, and it is generally accepted that these, too, are largely due to random defects in the materials, or "noise" in the manufacturing process.The system designer has to work with those failures and mitigate appropriately for the desired system or service MTBF. As @Stray Electron says, you can use "burn in" to get you past the infant mortality stage of the bathtub curve.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: August 07, 2025, 10:19:03 pm
content: There are many reasons that reliability predictions are unreliable. But in general a better prediction means that the reliability will be better than the product or configuration having a lower prediction.But always the predictions and how they are used depend on understanding what you are doing. In all the cases where I was involved in this sort of thing MTBF/MFR and similar metrics were understood to only be meaningful after infant mortality failures had reduced to levels below the steady state failure rate. Whether the infant failures were lumped in with the other data depending on the goals of the analyst. If you want confidence that your warranty costs are covered by the financial plan leaving them in under-represents field performance and gives "margin". Someone trying to set an interval for a costly replacement or renovation will probably use a "more accurate" reflection of the data.Another place where caution is required is depending on the Arrhenius relation between a stressor and failure rate. In my experience I have found that there are many examples where the relation holds, even though there is no fundamental understanding of the physics. This is why it is so widely used. But the Murphy principal says that you will uncover one of the many exceptions when it hurts the most. Use it even without a real physics connection, but understand the risk you are taking.Warranties based on predictions can be very costly. Providing a warranty is only safe for products that have been in the field long enough to start showing the right side of the bathtub. It is still likely to not kill the company providing the warranty if products that haven't been there that long have only what are believed to be minor variations from a product that is in the field. These conditions are generally true for mature products like automobiles, radios and refrigerators. And totally false for many other products.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 08, 2025, 09:52:09 am
content: Quote from: CatalinaWOW on August 07, 2025, 10:19:03 pmOh, yes! For example, a lot of the data on MTBFs and MTTFs is unreliable (I can explore why later). Also the implementation of many functions in software makes modelling failures much harder. The human factor is also important - so-called intervention faults account for alotof failures.

author: calzap
author_rank: Frequent Contributor
timestamp: August 09, 2025, 03:23:30 pm
content: This thread reminds me of Richard Feynman’s part in the investigation of the Challenger shuttle disaster. Prior to the disaster, the higher-ups at NASA determined that the chance of a failure was 1 in 100,000 for each launch. This was jaw-dropping to Feynman. This meant that on average, a shuttle could be launched every day with a launch failure occurring about once every 300 years!Feynman began questioning hands-on engineers at NASA. They estimated that a failure would occur once every 100-300 launches. One had studied the overall launch failure rate of over 100 unmanned launches of various rockets and found the failure rate to be 4%. Because tolerances and safety measures were more rigorous for manned flights, he reduced the level to 1% for those flights. This turned out to be correct, out of 135 shuttle launches there was one launch failure … Challenger, the 25th launch. However, he was pressured to drop the estimate to 0.1%, and his report was buried until after the Challenger disaster.When an administrator was pressured by Feynman to state the origin of the 1:100,000 failure rate estimate, he produced a report. The report listed the presumed failure rate of the numerous individual parts of the engines. Some were ridiculously low, like 1:10,000,000 per launch. They were obvious, unrealistic WAGs or more likely adjusted to make the failure rate of all the parts sum to 1:100,000.Because there were two lethal failures in the shuttle program (one launch, one re-entry) the chances of dying when flying it were about 2%. Made skydiving look perfectly safe.Mike