| the following is a discussion on the sister Linkedin NoMTBF Group recently. It was and may continue to be a great discussion. Please take a look and comment on where you stand? Do you some form of the Arrhenius reaction rate equation in your reliability engineering work?
Join the discussion here with a comment, or on the Linkedin group conversion. Fred |
An excellent short white paper by Craig Hillman that is worth reading. It underscores whey I claim HALT is the second worst 4 letter acronym in our profession. See the paper at http://www.dfrsolutions.com/uploads/white-papers/Why_HALT_Is_Not_HALT.pdf
Gear for anchor during rock climbing
Hello, can anyone advise me how to calculate temperature acceleration factor for a complex system including cards, RF elements, cables, motors and moving parts? Is the Arrhenius model valid for such systems, or there are more precise models? Thank you!
…and my response…
The acceleration factor equations are commonly tied very closely to a specific failure mechanism. For example, for SAC solder joint fatigue uses the modified Norris Landzberg model. And, for metal migration/corrosion within plastic encapsulated packages Peck’s equation is useful.
Each failure mechanism reacts to stresses differently, some more so than others. Making testing at a system level with accelerated stresses, … , more difficult.
So be careful, unless you know which failure mechanisms are most likely to occur during use and you accelerate appropriately.
If you know that temperature is the stress of interest related to the dominate failure mechanisms, again be careful, as you will quickly find, the activation energy is important and is generally associated with a specific failure mechanism.
And just temperature may not be sufficient – for moving parts, load and frequency of motion may be more useful for acceleration. For connectors and cables, maybe thermal cycling is more important.
If I don’t run a motor with a high temperature and humid environment it may fail due to corrosion. If I simply run it with an unbalanced load, it may wear out the bearing quickly – both lead to failure, yet have completely different acceleration factors (failure mechanisms) and one test or one AF is just not sufficient.
In short, there are more precise models – depending on the failure mechanisms involved.
hope that helps.
Fred
Fred i was asked this question and wanted to know what your thoughts were on this. R and D asked me what was the criteria to decide if to test at a component level or at a system level , my answer was that it should depend on what is the reliability and confidence level of the component
your thoughts?
thanks
sd
Hi SD,
Good question – and it’s not only a factor of reliability and confidence. While those are important to have in mind prior to designing a life test, it’s not the only consideration.
Often the decision to test at the component level is because it has a unique or new failure mechanism which is possible to evaluate and characterize with life testing directly on the component or test structure with the component. It’s often less expensive, easier to accelerate and to accomplish.
The testing at the system level is more expensive, more difficult to focus the testing on a specific component or component failure mechanism. Yet, is often the only way to evaluate interactions between elements of a product or while the product is operating.
In the rare case when a single component and it’s failure mechanism dominant the system’s failures, then testing the component at the system level makes sense.
Ok, backing up a little to your question.
Test at the component level when you want to learn about the life of the component and the components specific failure mechanisms.
Test at the system level when you are exploring system life during expected use conditions (possible to accelerate – like daily temperature changes affect on product life). Or, when the failure mechanisms are related to component interactions and operation.
If you do not have a clear failure mechanism as the target for the testing, then it may be difficult to design the appropriate test. Using FMEA, HALT or some other discovery method is useful to uncover the product’s failure mechanisms. Then move into life testing at the appropriate level with the test focused on specific failure mechanisms.
Hope that helps, please do let me know if you have any questions.
cheers,
Fred
Just a short post to point to a newly added paper to the reference section. A few years ago I recalled seeing a paper that studied the difference to expect between various parts count methods and actual results.
Jeff and colleagues did this work some time ago, and in most cases the underlying parts count methods haven’t changed too much, so I suspect the results are still very relevant.
The bottom line – expect as much as -100% to +500% different between the prediction and the actual result.
To see a draft of the paper, visit the References section of the site, click Draft Comparison of Electronic Reliability Prediction Methodologies, or via the slideshare window below.
Enjoy. And, if you know of other studies of this nature. Please let me know and we’ll at least post a link to the work.
Historically Reliability Engineering of Electronics has been dominated by the belief that 1) The life or percentage of complex hardware failures that occurs over time can be estimated, predicted, or modeled and 2) Reliability of electronic systems can be calculated or estimated through statistical and probabilistic methods to improve hardware reliability. The amazing thing about this is that during the many decades that reliability engineers have been taught this and believe that this is true, there is little if any empirical field data from the vast majority of verified failures that shows any correlation with calculated predictions of failure rates.
The probabilistic statistical predictions based on broad assumptions of the underlying physical causes begin with the first electronics reliability prediction guide begin November 1956, with the publication of the RCA release TR-1100, “Reliability Stress Analysis for Electronic Equipment”, which presented models for computing rates of component failures. This publication was followed by the “RADC Reliability Notebook” in October 1959, and the publication of a military reliability prediction handbook format known as MIL-HDBK-217.
It still continues today with various software applications which are progenies of the MIL-HDBK-217. Underlying these “reliability prediction assessment” methods and calculations is the assumption that the main driver of unreliability is due to components that have intrinsic failure rates moderated by the absolute temperature. It has been assumed that the component failure rates follow the Arrhenius equation and that component failure rates approximately doubles for every 10 °C.
MIL-HDBK-217 was removed from the military as reference document in 1996 and has not been updated since that time; it is still being reference unofficially by military contractors and still believed to have some validity even without any supporting evidence.
Much of the slow change in the industry is due to the fact that electronics reliability engineering has a fundamental “knowledge distribution” problem in that real field failure data, and the root causes of those failures can never be shared with the larger reliability engineering community. Reliability data is some of the most confidential sensitive data a manufacturer has, and short of a court order will never be published. Without this real data and information being disseminated and shared, one can expect little change in the beliefs of the vast majority of the electronics reliability engineering community.
Even though the probabilistic prediction approach to reliability has been practiced and applied for decades any engineer who has seen the root causes of verified field failures will observe that most all failures that occur before the electronic system is technologically obsolete, are caused by 1) errors in manufacturing 2) overlooked design margins 3) or accidental overstress or abuse by the customer. The timing of the root causes of these failures, which many times are driven by multiple events or stresses, are random and inconsistent. Therefore there is no basis for applying statistical or probabilistic predictive methods. Most users of predictions have observed the non-correlation between estimated and actual failure rates.
It is long past time that the electronics design and manufacturing organizations to abandon these invalid and misleading approaches, acknowledge that reliability cannot be estimated from assumptions and calculations, and start using “stress to limits” to find latent failure mechanisms before a product is released to market. It is true that you cannot derive a time to failure for most systems, but then no test can provide an actual field “life” estimate for a complex electronic system nor do we need to. There is more life than needed in most electronics for most applications.
Fortunately, there is an alternative. A much more pragmatic and effective approach is to find to put most engineering and testing resources to discovery of overlooked design margins or a weakest link early in the design process (HALT) and then use that strength and durability to quickly screen (HASS) for errors during manufacturing. HALT and HASS have little to do with a specific type of chamber or chamber capabilities. It is a fundamental change in the frame of reference for reliability development, moving instead from time metrics to stress/limit metrics. Many have already realized this new frame of reference. Since they have found these methods much more efficient and cost effective for developing robust electronics systems, it gives them a competitive advantage. They are not about to let the world or their competitors know of how successful these methods are.
With the kind permission of Wayne Nelson and Robert Abernathy we are posting an article on the analysis of repair data. As you may know, the assumptions made when using simple time to failure analysis of repairable systems may provide misleading results. Using the analysis method outlined by Wayne is one way to avoid those costly mistakes.
Here is the opening elements of the work by Wayne, followed by a link to the full paper.
Appendix M: Repair Data Analysis of Abernethy, R.B. (2006), The New Weibull Handbook, 5th ed., available from Dr. R.A. Abernethy, weibull@worldnet.att.net, 536 Oyster Road, North Palm Beach, FL 33408. May 5, 2006
AN APPLICATION OF GRAPHICAL ANALYSIS OF REPAIR DATA
Wayne Nelson, consultant
WNconsult@aol.com, 739 Huntingdon Drive, Schenectady, NY 12309, USA
SUMMARY. This expository article presents a simple and informative non-parametric plot of repair data on a sample of systems. The plot is illustrated with transmission repair data from cars on a preproduction road test.
KEY WORDS: repair data; reliability data; graphical analysis.
1. INTRODUCTION
Purpose. This article presents a simple and informative plot for analyzing data on numbers or costs of repeated repairs of a sample of systems. The plotting method provides a non-parametric graphical estimate of the population mean cu¬mulative number or cost of repairs per system versus age. This estimate can be used to:
1. Evaluate whether the population repair (or cost) rate increases or decreases with age (this is useful for sys¬tem retirement and burn-in decisions),
2. Compare two samples from different designs, production periods, maintenance policies, environ¬ments, operating conditions, etc.,
3. Predict future numbers and costs of repairs,
4. Reveal unexpected information and insight, an impor¬tant advantage of plots.
Overview. Section 2 describes typical repair data. Section 3 de¬fines the basic population model and its mean cumulative function (MCF) for the number or cost of repairs. Sec¬tion 4 shows how to calculate and plot a sample estimate of the MCF from data from systems with a mix of ages. Section 5 explains how to use and interpret such plots.
Dr. Wayne Nelson is a leading expert on analysis of reliability and accelerated test data. He consults and gives training courses for companies and professional societies. For 24 years he consulted across the General Electric Co. and received the Dushman Award of GE Corp. R&D for developments and applications of product reliability data analysis. He was elected a Fellow of the Amer. Statistical Assoc. (1973), the Amer. Soc. for Quality (1983), the Institute of Electrical and Electronics Engineers (1988) for his innovative developments. He was awarded the 2003 Shewhart Medal and the 2010 Shainin Medal of ASQ and the 2005 Lifetime Achievement Award of IEEE for outstanding developments of reliability methodology and contributions to reliability education. He authored three highly regarded books Applied Life Data Analysis (Wiley 1982, 2004), Accelerated Testing (Wiley 1990, 2004), Recurrent Events Data Analysis (SIAM 2003), two ASQ booklets, and 130 journal articles. He can be contacted via WNconsult@aol.com.
Dr. Robert B. Abernathy, www.bobabernethy.com
When conducting a Human Reliability Assessment (HRA) we use the terminology: errors of commission or errors of omission. It behoves every professional to question why we focus upon one metric in preference to all others, in an objective and constructive manner in order to discern whether we are exposing our organization to errors of professional omission or commission. Obviously the other conclusion is that we are doing the right thing and this is also an empowering piece of knowledge.
When an organization uses one reliability metric predominately, there is a propensity to subsequently force organizational behavior in a certain direction, which in turn becomes the social norm. If we fail to question the underlying rationale that motivates our organization to rely on certain metrics in favor of all others, then we also fail to fully comprehend our organization’s collective mindset. Such comprehension is crucial not only as the foundation to any potential change management initiative but also to break into management’s decision making cycle which drives every tier of an organization. Getting inside our executives decision making cycle is the first step in value adding at the core business level, rather than being relegated as a second tier employee that provides little more than a process compliance function. Reliability engineering is often viewed as an “add-on” mandated process by many middle to executive management staff and I proffer that it is not their shortcomings that lead to such a mindset….. it is ours. The reliability professional has the task of not only providing highly skilled analysis but also to educate our organization on how we can do business more efficiently, carry less risk forward and use existing resources more effectively by simply understanding how to integrate our skills into core business processes rather than as an “add-on”.
So, how is any of this related to something as seemingly innocuous as MTBF?
Well, if we have to ask ourselves that question then quite simply, we are not there yet. We are not at the level of professional and organizational understanding that allows us to instantly realize a potential disconnect between what we can truly offer and what we are currently doing. I concede, MTBF may be the right metric however, unless you “know” why it is the right metric then it should be questioned.
The real concern is not necessarily whether MTBF is being used but rather how its use is shaping organizational behavior that in turn potentially manifests into redundant activity, wasted resources, extended schedules, increased risk taking and more importantly…. our own inability to truly step into our management’s decision making cycle and ply our craft in a meaningful, effectual and professional manner.
So, are you exposing your organization to professional errors of commission or omission by not questioning the metrics being used? How is this then shaping your organizational behavior and more importantly…. what can “we” do to treat ill-informed behavior?
Giving a presentation last week and asked if anyone uses an 85/85 type test, and a couple indicated they did. I asked why?
The response was – just because. We have always done it, or it’s a standard, or customers expected it. The most honest response was ‘I don’t know’.
They why is the test being done? Who is using the information for a decision? What is the value of the test results? If ‘just because’ is the best you can say about a test, why do it? Continue reading