7.1.1 Review of Chapter 6

Chapter 6 presented a design of an exemplary prototype of a PHM system that prognostic‐enabled multiple instantiations of systems and prognostic targets with excellent results (see Table 7.1).

The design supported multiple subsystems (two), each comprising prognostic targets: a power supply and two electro‐mechanical actuators (EMAs). The design included monitoring each of the two power supplies for a single mode of failure and monitoring each of the four EMAs for three failure modes. The monitoring, conditioning, and processing were all based on CBD signatures, and the prognostic approaches and methods provided excellent, if not superior, results:

• Degradation was detected at least 96% of the distance in time before functional failure occurred.
• Estimate accuracy was within 25% at least 93% of the distance in time before functional failure occurred.
• Estimate accuracy was within 10% at least 52% of the distance in time before functional failure occurred.
• A time to failure (TTF) value of 9600 hours was used to specify a prognostic TTF (using PITTFF0) value of 4800 hours:
  • All four of the prognostic targets that failed did so prior to that time: at estimated times of 2745 hours, 3164 hours, 4176 hours, and 4434 hours.
  • The actual TTF was 3630 hours.

7.1.2 Electronic Health Solutions

Electronic health solutions, such as those described in this book, become part of a PHM system. They are sometimes referred to as a prognostic ecosystem (see Figure 7.1), within which such solutions can be categorized at levels as shown in Figure 7.2: die, component, board, module, and system (Ridgetop Group 2018). Other levels could be added, such as an assembly of boards and a collection of modules into a replaceable unit.

7.1.3 Critical Systems and Advance Warning

Critical systems are considered vital to the ongoing operation of everyday life, and criticality is a key consideration when evaluating and selecting a node for prognostic enabling (a prognostic target). For example, a power system in an aircraft, or a gear box in a wind turbine, would be considered critical, since their operation is essential to meet design objectives of the overall system. Another example of criticality is the safety of life and health: prevention and avoidance of loss of life and injury is a primary objective of a system. Fault severity and fault propagation also play a role in the definition of systemwide criticality.

Advance warning, such as an alert, of any impending failure of a mission‐critical or safety‐critical prognostic target is vital: a properly designed PHM system will provide detection of anomalies that affect the ability of the system to operate within specifications and issue appropriate alerts. For example, Chapter 6 included examples of messages and alerts issued by an exemplary prototype PHM system. A PHM system will issue alerts (health monitoring) and/or initiate appropriate actions (health management) such as soft shutdowns, load shedding, and scheduling maintenance. There might also be various levels of alerting where threshold levels and fault models can be used to prioritize what information is available to an operator of an aircraft, or a seagoing ship, or a machine tool on the manufacturing floor. This brings in the notion of fault severity, access to the information, and what is done to mitigate an issue that results in an alert.

7.1.4 Reduction in Maintenance

To save money and resources, maintenance intervals can be optimized based on actual evidence of degradation. For example, a system might have components that fail after 250 hours of operation, some that fail after about 600 hours, and others that fail at about 500 hours. A usage‐based PHM system might be designed to do one of the following:

1. Schedule repair and/or replace maintenance for all units on or before 200 hours of operation – a 20% safety margin with respect to failure.
2. Schedule repair and/or replace maintenance for all units on or before 400 hours of operation.

In a first design of a PHM system, an objective might be to avoid all unexpected failures, but at increased maintenance costs: for example, an average 300 hours of lost usage for each instance of avoidance, and cost increases due to increased maintenance actions (more frequent replacement). A second design might focus on reducing sustainment costs by increasing the time between maintenance actions – but unexpected failures would increase. Typically, even disregarding mission and safety issues, the cost of an unexpected failure is higher than an early repair‐and‐replace action.

So, instead of a usage‐based PHM system, we advocate CBM using a PHM system that is CBD‐based; uses signature‐based detection and prognostic approaches and methods; and employs a fast, highly accurate set of data‐conditioning, prediction, and computational routines. The advocated approach of using CBD signatures is an effective method for handling variability introduced by the operational environment: operating in the desert of Arizona is very different than operating equipment in a rainy, cold environment such as that in Puget Sound, Washington.

7.1.5 Health Management, Maintenance, and Logistics

This book is focused on prognostic enabling to monitor the health of a system of nodes: the prognostic targets chosen because those nodes have signals that change in response to degradation of devices, components, and so on that, when they fail, have a critical effect on the operation of the system. They may cause mission‐critical functions to cease or otherwise operate out of specifications, or they may create a hazardous threat to the safety of the system or life.

But monitoring, per se, does not avoid unexpected outages, does not repair anything, and does not prevent loss of life. Refer back to Figure 7.1 : a PHM system needs to provide services for health management, maintenance, and logistic support to schedule maintenance, locate and deliver parts and equipment, and dispatch a maintenance team.

Management

Given the accuracy of the prognostic information produced by the PHM system in Chapter 6, it would not be unreasonable to defer maintenance until a detected state of health (SoH) value at or below a specified level, such as 25%. PHM management support might be designed to act on alerts, such as those shown in Figure 7.3, which are excerpted from Chapter 6. In contrast, PHM management support might be designed to act on damage‐detected alerts, such as those shown in Figure 7.4.

7.1.6 Chapter Objectives

The previous chapters were focused on PHM aspects deemed critical to the design of a PHM system, including approaches and methods not suitable for CBD‐based prognostics. The overall objective of this book is to provide you with the knowledge to understand, evaluate, design (at least at a high level), and verify health monitoring. The introduction of this chapter has briefly introduced you to the concept of ecosystems, critical systems and warnings, reduction in maintenance, and health management. The remainder of this chapter is devoted to the evaluation, selection, and specifications of prognostic targets: nodes to be monitored to detect damage and provide prognostic information, to avoid unscheduled outages of critical functions and loss of safety in a system.

7.1.7 Chapter Organization

The remainder of this chapter is organized to present and discuss topics related to prognostic enabling:

• 7.2 Prognostic Targets: Evaluation, Selection, and Specifications

  This section includes descriptions of the meaning and relationship of TTF, time before/between failure (TBF), prognostic distance (PD), and prognostic horizon (PH); distributions of the onset of degradation and functional failure; mean time to failure (MTTF); and mean time before/between failure (MTBF).

• 7.3 Example: Cost‐Benefit of Prognostic Approaches

  This section is devoted to the cost‐benefit analysis of prognostic approaches and includes example comparisons of no PHM, two usage‐based approaches, CBD‐based detection, and CBD‐based prognostics.

• 7.4 Reliability: Bathtub Curve

  This section is devoted to the bathtub curve, prognostic triggers, and the relationship of the bathtub curve to failure rate and MTBF.

• 7.5 Chapter Summary and Book Conclusion

  This section summarizes and ends both the chapter and the book.

7.2.1 Criteria for Evaluation, Selection, and Winnowing

Because you are designing a PHM system to prognostic enable an operational system, your team will not perform any traditional failure mode and effect analysis (FMEA) or failure mode effect and criticality analysis (FMECA) (DAU 2018). Instead, your team will review the existing FMEA and FMECA data; the historical failure, service, and repair data; and any other data related to failure. The focus is on identifying, selecting, and winnowing prognostic targets. To select and winnow a list of prognostic candidates, including those identified as candidates by FMEA/FMECA, you need to know the following:

• TTF or TTFF. An estimate of the time to failure (alternatively, time to functional failure). This is a primary focus of this chapter.
• PD (estimated). An initial estimate of the distance in time between the onset of degradation and functional failure from which a prediction algorithm converges upward or downward to a true PH.
• Failure mode to be detected. The failure mechanism that causes the characteristic shape of the signature captured by one or more sensors.
• Severity classification. A qualitative assessment of the consequences of functional failure.
• Cost of failure. An estimate of the cost of an unplanned failure versus the cost of service and repair before failure.
• Cost of prognostic enabling. An estimate of, for example, the cost of the sensor, PHM support, design, development, testing, qualification, and fielding.
• Cost‐benefit analysis. An estimate of, for example, the change in sustainment cost plus time in use due to prognostic enabling, the effective savings achieved, and the change in service actions because of prognostic enabling.

7.2.2 Meaning of MTBF and MTTF

PHM systems are typically referenced to either MTBF or MTTF, and therefore you should know and understand the difference between them (Speaks 2005):

• MTBF. Calculated mean time between (or before – context dependent) failures of a repairable system.
• MTTF. Expected TTF of a nonrepairable system.

As you can see, the meaning of (and therefore the use of) these terms is dependent upon the definition of failure and the definition of repairable. To achieve an understanding of those terms, recollect that Chapter 2 introduced failure in time (FIT) in Eq. (2.15):

where AF is the value of an acceleration factor for a specified test. Refer to Tables 2.3 and 2.4 for examples.

But you are not given a failure rate: instead, you are told that the FIT number is 50. Now you need to know the following to relate that FIT number to a failure rate (Ellerman 2012; NIST 2018 ):

7.1

where 1 FIT = 1/10⁹ hours.

Even though your research confirms that your calculation is correct, because the calculated rate of failure is so large, you decide to calculate an MTBF (mean time before failure) value using Eq. (7.1) (Abernethy 2006; RAC 2005; Speaks 2005 ; Weibull 2008):

7.2

But this does not help, because you do not know the total time, which you know is calculated using Eq. (7.3):

7.3

You also don't know the number of tested units or the test time. So, you find another expression for MTBF

7.4

which, for FIT = 50, is equal to the Example 7.4 calculated value for λ: 20 000 000 hours.

Literature research reveals the following:

• In 1993, MTTF was defined as “mean time to first” failure (Seymour 1993), and the expression to calculate that value is given as
  
• So, MTTF (circa 1993) is calculated the same way as MTBF in 2018, when B means before.
• You discover that MTBF is also defined as “mean time between failures” for a repairable product.
• MTTF is defined as “mean time to failure” (no reference to first) for a nonrepairable product.
• A relationship of MTBF to MTTF is defined as follows (Ellerman 2012 ):
  7.5

  where MTTR is defined as “mean time to repair.”

• Ergo, you have a multiplicity of definitions and acronyms that are ambiguous and cause uncertainty regarding use and meaning.

Regardless of meaning and/or definition, neither MTTF nor either of the two definitions of MTBF is useful for prognostic enabling. MTTF and MTBF should be limited to a classical definition of reliability (Section 1.6): without intervention, there is a 63% probability the system will fail prior in time to the value of MTTF or MTBF.

7.2.3 MTTF and MTBF Uncertainty

Figure 7.5 illustrates the relationship of a failure distribution (density of failures/time), the MTBF (failure rate between failures), the MTBF (mean time before a first failure), and MTTF: MTTF and MTBF were originally defined for an exponential distribution having a constant, low failure rate: for example, solid‐state (integrated circuit) devices. Those devices are subjected to one or more accelerated tests, such as a HALT, with test results extrapolated to normal life using an AF (Ellerman 2012 ; O'Connor and Kleyner 2012; NIST 2018 ; RAC 2005 ; Speaks 2005 ; Wilkins 2002).

Typical commercial FIT values for solid‐state devices are in the 50–1000 range, with FIT values in the range of 1–10 for space applications (Johnston 2010). There are simulators that calculate values called MTTF and MTBF using simulated failure times (Weibull 2008 ), which adds even more uncertainty as to the meaning of and/or calculation of a particular MTTF and/or MTBF value.

Even worse, different failure distributions, different CBD signatures, and so on, can result in identical (or nearly identical) reliability metrics such as MTTF: compare Figures 7.5 and 7.6. Finally, this book asserts that attempts to use a TTF value of hundreds of thousands (or larger) of hours for CBD‐based prognostics is nonsensical: an MTTF value of 100 000 hours is equivalent to more than 11 years.

7.2.4 TTF and PITTFF

We need to know how to determine, calculate, and/or estimate a TTF value that begins when degradation begins and ends when functional failure occurs (see TTF 1 and TTF 2 in Figure 7.5 ). But at the time when degradation is first detected, there is no a priori knowledge of that future time of failure; yet our prediction program needs to converge from an initial estimate of that time to a very accurate estimate of the time of failure. Research into reliability metrics such as MTTF, MTBF, and FIT indicates that they are not really close in value to what we need for TTF.

The prediction program we are using, ARULEAV, provides a parameter called PITTFF0 (introduced in Chapter 6) as a means to specify an initial value for TTF. TFF is not a value that is looked at or specified by manufacturers and/or vendors of products; failures in the field are usually due to either an anomalous event such as a lightning strike or degradation. Degradation typically is not caused by a part entering what is referred to as the wear‐out region of a bathtub curve; rather, degradation is typically due to an accumulation of fatigue damage caused by cyclic stresses and strains (such as thermal and mechanical) during operation (Hofmeister et al. 2006).

We can estimate an initial value for TTF using a number of methods: a service‐life determination, an end‐use test method, or an MTTF‐based method. But be aware that the supplier of the prediction program advises that, in general, that program converges to within 25% accuracy in less time when the initial estimate is higher, rather than lower, in comparison to the true time of functional failure.

TTF: End‐Use Test Method

You can calculate TBF and TTF values in the same way as MTBF and MTTF values, respectively, using the following (Weibull 2008 ):

7.6

7.7

7.3.1 Cost‐Benefit Situations

The situations are the following: (i) none; (ii) usage‐based, MTTF; (iii) usage‐based, 2/3 MTTF; (iv) CBD‐based, replace when damage is detected; and (v) CBD‐based, replace within 720 hours after estimated SoH becomes 75% or less. Although the first situation fails to meet the requirement that unexpected failures will be less than 5%, it establishes a baseline estimate of cost.

Your customer arranged for special delivery of 6 power supplies and 12 EMAs. Those 18 units were subjected to end‐use tests similar to HALTs (refer back to Section 2.2). Your team assisted in the design of the experiment and building of the test beds; the tested units (power supplies and EMAs) needed to be prognostic enabled, as described in Chapter 6. For analysis purposes, test failures are to be evaluated as though all of the tested units were installed at the same time and failed in the sequences and times indicated by the test.

The numbers to be used in a cost‐benefit analysis are provided by the customer and listed in Tables 7.1 and 7.5. After examining the rest results (see Figure 7.15 and Table 7.6), your customer concludes the cost‐benefit analysis for the power supply scenario is sufficient for evaluation of the five approaches.

7.3.2 Cost Analyses

7.4.1 Bathtub Curve: MTBF and MTTF

As you can see in Figure 7.16 , MTBF (between failures) is not a time‐axis value: it is a failure‐rate value. Neither MTTF nor MTBF is seen in a typical view of a bathtub curve, perhaps because of the relationship suggested in Figure 7.17 (Seastrunk 2016).

7.4.2 Trigger Point and Prognostic Distance

Also shown in Figure 7.16 is a conceptual diagram intended to convey the notion that it is possible to employ a prognostic trigger to provide advance warning of a probable failure within time PD while, at the same time, conveying a notion that useful life does not extend into the wear‐out region. Figure 7.18 conveys a more practical view of prognostic trigger points:

• Envision multiple sensors attached to a complicated product such as an EMA with a built‐in power supply, as already described in this book.
• When a population of those EMAs are deployed and put into use, they become damaged due to cyclic stress, weak/defective components, and random events.
• Continued use increases the level of damage to the point that the attached sensors detect the damage, trigger alerts, then trigger maintenance activity, and then trigger alerts that failure is imminent or has occurred.

References

1. Abernethy, R.B. (2006). The New Weibull Handbook, 5e, 2006. Berringer and Associates.
2. Astfalck, L., Hodkiewicz, M., Medjaher et al. (2016). A modelling ecosystem for prognostics. Annual Conference of the Prognostics and Health Management Society.
3. DAU (2018). Failure modes & effects analysis (FMEA) and failure modes, effects & criticality analysis (FMECA). Acquipedia, Defense Acquisition University, 9820 Belvoir Road, Fort Belvoir, VA 22060. https://www.dau.mil/acquipedia.
4. Ellerman, P. (2012). Calculating Reliability Using FIT & MTTF: Arrhenius HTOL Model, MicroNote™ 1002, Rev 0. MicroSemi Corp. https://www.microsemi.com/document‐portal/doc_view/124041‐calculating‐reliability‐using‐fit‐mttf‐arrhenius‐htol‐model (accessed 2018).
5. Hofmeister, J.P., Lall, P., and Graves, R. (2006). In‐situ, real‐time detector for faults in solder joint networks belonging to operational, fully programmed field programmable gate arrays (FPGAs). In: Proceedings of the IEEE AUTOTESTCON, Anaheim, CA, 18–21 Sept. 2006, 237–243. IEEE.
6. Johnston, A. (2010). Reliability and Radiation Effects in Compound Semiconductors, 117–132. Singapore: World Scientific Publishing Co. Pte. Ltd.
7. O'Connor, P. and Kleyner, A. (2012). Practical Reliability Engineering. Chichester, UK: Wiley.
8. RAC (2005). Reliability Toolkit: Commercial Practices Editions. Reliability Analysis Center, Rome Laboratory. https://www.dsiac.org/sites/default/files/journals/2Q2005.pdf (accessed 2018).
9. Ridgetop Group. (2018). Sentinel Network, view of the graphical user interface (GUI) for an electronic power supply (EPS). Courtesy and permission of Ridgetop Group, Inc., 3580 West Ina Road, Tucson, AZ, 85741.
10. Seastrunk, B. (2016). Reliability, warranty, and why nothing lasts as long as it used to. http://opinionbypen.com/reliability‐warranty‐and‐why‐nothing‐lasts‐as‐long‐as‐it‐used‐to (accessed 2018).
11. Seymour, B. (1993). MTTF, failrate, reliability and life testing. Application Bulletin, AB‐059, Burr‐Brown Corporation. Tucson, AZ.
12. Speaks, S. (2005). Reliability and MTBF overview. Vicor Reliability Engineering. http://www.vicorpower.com/documents/quality/Rel_MTBF.pdf (accessed August 2015).
13. Tobias, P. (2003). Assessing product relability. In: Engineering Statistics Handbook. National Institute of Standards and Technology. https://www.itl.nist.gov/div898/handbook/apr/apr.htm.
14. Weibull. (2008). MTTF, MTBF, mean time between replacements and MTBF with scheduled replacements. HotWire 94. https://www.weibull.com/hotwire/issue94.
15. Wilkins, D.J. (2002). The bathtub curve and product failure behavior, part two – normal life and wear‐out. HotWire 22. https://www.weibull.com/hotwire/issue22/hottopics22.htm (accessed 2018).

Further Reading

1. Filliben, J. and Heckert, A. (2003). Probability distributions. In: Engineering Statistics Handbook. National Institute of Standards and Technology. http://www.itl.nist.gov/div898/handbook/eda/section3/eda36.htm.
2. Tobias, P. (2003a). Extreme value distributions. In: Engineering Statistics Handbook. National Institute of Standards and Technology. https://www.itl.nist.gov/div898/handbook/apr/section1/apr163.htm.
3. Tobias, P. (2003b). How do you project reliability at use conditions? In: Engineering Statistics Handbook. National Institute of Standards and Technology. https://www.itl.nist.gov/div898/handbook/apr/section4/apr43.htm.