Why Do a Parts Count Prediction?

Why Would You Do a Parts Count Prediction?

Is there any useful result from a parts count prediction?

In most cases that I’ve seen parts count predictions used they are absolutely worthless. Worse, is the folks receiving the results believe they are accurate estimates of reliability performance (or at least use the results as such).

In my opinion, the range of parts count prediction methods and databases harm the field of reliability engineering.

We need to call out the poor results, promote better practices, and stop the vapid use of such a poorly understood tool.

Parts Count Prediction Concept

The concept of the parts count prediction method is rather simple.

Given the failure rates for the elements making up a system, add them up, and you have the expected failure rate of the system.

In part this hinges on the ability to add failure rates within the exponential distribution reliability function. The concept starts with the idea that the product of the reliability at some time, t, is the reliability of the system.

Of course there are a few assumptions that are in play when using a parts count approach.

  1. The failure rates of the components are in your design, environment and use profile
  2. The failure rates are constant over time (the exponential memoryless feature)
  3. Any part that fails causes the system to fail (series system reliability model)
  4. The information used to determine the component failure rate captures all the potential failure mechanisms

There may be more, yet those are the few that come to mind immediately.

How often do you see those using parts count predictions actually verifying any of these assumptions? Not often I suspect, as it is nearly impossible to create a system that would meet any of these assumptions.

The concept of adding failure rates is in part due the difficultly of the math involved with reliability functions from a range of time to failure distributions. Assuming the exponential permitted adding failure rates which is easy using a mechanical adder. In the 1960’s adding was simple, multiplication and exponents was tedious. The large projects at the time needed a way to create reliability estimates, thus the simplifications, as they had little choice for a better approach in a timely fashion.

Today, you are not limited to a mechanical adder. So don’t limit your analysis as if that was the only math tool available.

The Common and Mistaken Uses of Parts Count Predictions

Of course the first is the result of a prediction is stated in terms of MTBF. You know where I stand on that, which isn’t the fault of the prediction method, rather the need to use MTBF.

Don’t use MTBF.

Another is the idea the prediction result will estimate field performance. Mil Hdbk 217 says it is not useful to estimate field performance. Studies have shown any parts count prediction method is really bad to estimating actual performance.

Don’t use parts count predictions to estimate field reliability performance.

Another, the customer asked for a parts count prediction. Really? Or do they want some assurance that the product your are providing will meet their reliability performance requirements. A prediction is not able to provide an estimate of field performance. Instead ask your customer what they really want and provide that instead.

It’s in the contract is not an excuse to give your customer bogus information. Provide them with what they really need to know and mistakenly asked for a prediction study (or MTBF)

There are others – please add how you have seen parts count prediction used incorrectly in the comments section below.

The One Possible Way It’s Useful

My first thought is to say the only way a parts count prediction is useful is if it’s not done.

Then I though about the use to compare different design approaches. It’s rough, it’s just a comparison, yet may be useful.

Another consideration, if the prediction is used to provide feedback to the design team and they reduce the number of components (clean up the design) or run the system at cooler temperatures, then it has the purpose of reinforcing good design for reliability practices. The results are not all that important, it’s the behavior that results in an improved design that is good.

Years ago at some HP division, they did detailed failure analysis to the component level on every field failure. They had a database of component failure rates for their products, their designs, being used by their customers. The parts count predictions were actually rather close to what they experienced in the field. They limited the data and analysis to the warranty or service periods.

There were plenty of problems and issue with the parts count results, yet the results did provide a reasonable way to estimate field performance. For new products or components they had to wait till actual field failures built enough information to create a database entry, for example.

In contrast, using a 20 year old generic failure rate data base is just not going to work for your products and customers.

If you use (condone) parts count predictions? Why and under what conditions? Also, how are the results used and are they providing value? Share your experience, good or bad, in the comments section.

About Fred Schenkelberg

I am an experienced reliability engineering and management consultant with my firm FMS Reliability. My passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs.

6 thoughts on “Why Do a Parts Count Prediction?

  1. Hi Sir,
    part count is performed when the data available is less and if we have enough data of the component or system it’s always preferable to do part stress, as it considers various lambda factors which are more close to original operating environment condition in which component or system is going to perform

    1. Thanks for the comment Piyush,

      sure accounting for part stress is better, yet when built on the very faulty set of assumptions involved is still provide dismal results. Instead focus on the failure mechanisms and thier time to failure patterns.



  2. I was recently asked in an interview, what I thought about reliability prediction. My answer was that I didn’t!

    The interviewers, (all seasoned ‘reliability professionals’) seemed nonplussed. ‘At least it’s better than nothing’, one said.

    That’s the trouble though, it isn’t.

  3. Parts Count reliability prediction procedures purposely take a conservative approach by assuming part stress levels in their failure rate models that are significantly higher than most accepted derating policies/ practices. . Ideally, the Parts Count technique is applied early in the design phase to determine that the predicted reliability is in the “ball park” with reliability requirements. As more detailed design information becomes available, such as detailed part stress levels, circuit schematics, the predictions are refined to reflect actual applied component stress levels. Reliability models based on Physics of Failure is the best. CALCE is doing lot of work on this subject

    1. Hi Hilaire,

      thanks for the comment and yes, using physics of failure models is much better then using a parts count approach.

      I do not agree that the databases from parts count databases or from vendors are conservative with higher than actual failure rates. Nor will the parts count prediction be in the ball park or any where near the ball park. See http://nomtbf.com/wp-content/uploads/2011/12/Draft-Comparison-of-Electronic-Reliability-Prediction-Methodologies.pdf for the paper by Jones and Hayes that compared actual to predicted results.

      Thinking though your design including the components allows you and team to sort out the risks, design for reliability from the start, and address areas of uncertainty and risk. Parts count predictions are too often considered in the ball park or good enough and they really are random number generators, little more.



Leave a Reply

Your email address will not be published. Required fields are marked *