Mark A. Levin is the reliability manager at Teradyne, Inc. and is based in Agoura Hills, California. He received his bachelor of science degree in Electrical Engineering (1982) from the University of Arizona, a master of science degree in Technology Management (1999) from Pepperdine University, a master of science in Reliability Engineering (2009) from the University of Maryland, and all but dissertation for a PhD in Reliability Engineering from the University of Maryland. He has more than 36 years of electronics experience spanning the aerospace, defense, consumer, and medical electronics industries. He has held several management and research positions at Hughes Aircraft Missiles Systems Group, Hughes Aircraft Microwave Products Division, General Medical Company, and Medical Data Electronics. His experience is diverse, having worked in manufacturing, design, and research and development. He has developed manufacturing and reliability design guidelines, reliability training classes, workmanship standards, quality programs, JIT manufacturing, and ESD safe work environments, and has established a surface mount production facility.

(Mark.levin@Teradyne.com)

Ted T. Kalal is a reliability engineer (now retired) who has gained much of his understanding of reliability from hands‐on experience and from many great mentors. He is a graduate of the University of Wisconsin (1981) in Business Administration after completing much preliminary study in mathematics, physics, and electronics. He has held many positions as a contract engineer and as a consultant, where he was able to focus on design, quality, and reliability tasks. He has authored several papers on electronic circuitry and holds a patent in the field of power electronics. With two partners, he started a small manufacturing company that makes high‐tech power supplies and other scientific apparatus for the bioresearch community.

Jonathan Rodin is a software engineering manager at Teradyne, Inc. A graduate of Columbia University (1981), Jon has 39 years of experience developing software, both working as a programmer and managing software development projects. His experience spans companies of many sizes, ranging from early stage startups to companies of greater than 100 000 employees. Prior to joining Teradyne, Jon held executive engineering management positions at FTP Software, NaviSite, and Percussion Software. He has led software process reengineering projects numerous times, most recently driving the effort to bring Teradyne's Semiconductor Test Division to CMMI Level 3.

1. 1. Figure 1.1 Product cost is determined early in development.
   2. Figure 1.2 Cost to fix a design increases an order of magnitude with each subse...
   3. Figure 1.3 The reliability process reduces the number of ECOs required after pr...
   4. Figure 1.4 Including reliability in concurrent engineering reduces time to mark...
   5. Figure 1.5 Product introduction relative to competitors.
   6. Figure 1.6 The ICM process.
2. 1. Figure 2.1 Overcoming reliability hurdles bring significant rewards.
3. 1. Figure 5.1 The six phases of the product life cycle.
   2. Figure 5.2 The ICM process.
   3. Figure 5.3 A risk mitigation program (ICM) needs to address risk issues in all ...
4. 1. Figure 6.1 The bathtub curve (timescale is logarithmic).
   2. Figure 6.2 Cumulative failure curve.
   3. Figure 6.3 Light bulb theoretical example.
   4. Figure 6.4 Availability as a function of MTBF and MTTR. Note: The curve has a s...
   5. Figure 6.5 Design maturity testing – accept/reject criteria.
   6. Figure 6.6 Number of fan failures vs. run time.
   7. Figure 6.7 Mechanism that can cause degradation and failure.
   8. Figure 6.8 PHM data collection and processing to detect degradation..
5. 1. Figure 7.1 Functional block diagram.
   2. Figure 7.2 Filled‐out functional block diagram.
   3. Figure 7.3 Schematic diagram of a flashlight.
   4. Figure 7.4 Functional block diagram of a flashlight.
   5. Figure 7.5 Functional block diagram of a flashlight using Post‐its.
   6. Figure 7.6 Fault tree logic symbols.
   7. Figure 7.7 Fault tree diagram for flashlight using Post‐its.
   8. Figure 7.8 Logic flow diagram.
   9. Figure 7.9 Fault tree logic diagram.
   10. Figure 7.10 Flash light fault tree logic diagram.
   11. Figure 7.11 Functional block diagram for the flashlight process.
   12. Figure 7.12 Example of a SFTA for an execution flow failure.
6. 1. Figure 8.1 Pareto of failures.
   2. Figure 8.2 HALT failure percentage by stress type.
   3. Figure 8.3 Product design specification limits.
   4. Figure 8.4 Design margin.
   5. Figure 8.5 Some products fail product spec.
   6. Figure 8.6 HALT increases design margin.
   7. Figure 8.7 Soft and hard failures.
   8. Figure 8.8 Impact of HALT on design margins.
   9. Figure 8.9 Two heat exchangers placed in front of chamber forced air.
   10. Figure 8.10 Test setup profile to checkout connections and functionality.
   11. Figure 8.11 Temperature step stress with power cycle and end of each step.
   12. Figure 8.12 Vibration step stress.
   13. Figure 8.13 Temperature and vibration step stress.
   14. Figure 8.14 Rapid thermal cycling.
   15. Figure 8.15 Slow temperature ramp.
   16. Figure 8.16 Slow temperature ramp with constantly varying vibration level.
   17. Figure 8.17 HASS stress levels.
   18. Figure 8.18 The bathtub curve.
   19. Figure 8.19 HASA plan.
   20. Figure 8.20 A HALT chamber has six simultaneous degrees of freedom (movement).
   21. Figure 8.21 ARG process flow.
   22. Figure 8.22 Accelerated reliability growth.
   23. Figure 8.23 ARG and ELT acceleration test plans.
   24. Figure 8.24 Selective process control.
7. 1. Figure 9.1 Quality ROI chart (financial impact of escapes is low).
   2. Figure 9.2 Quality ROI chart (financial impact of escapes is high).
   3. Figure 9.3 Sample line counts.
   4. Figure 9.4 Defect run chart 1.
   5. Figure 9.5 Defect run chart 2.
   6. Figure 9.6 Comparative escape rates.
8. 1. Figure 10.1 Generic fishbone diagram.
   2. Figure 10.2 Sample fishbone diagram.
   3. Figure 10.3 Sample Pareto chart.
   4. Figure 10.4 Code review root cause Pareto.
   5. Figure 10.5 Try‐catch code example.
9. 1. Figure 11.1 Waterfall life cycle.
   2. Figure 11.2 Quality processes in a waterfall life cycle.
   3. Figure 11.3 Sprint activities.
   4. Figure 11.4 Sprint activities in an epic.
10. 1. Figure 12.1 Sample requirements.
    2. Figure 12.2 Sample user stories.
    3. Figure 12.3 Code comments example.
    4. Figure 12.4 Sample UART HAL code.
11. 1. Figure 15.1 ESPEC/Qualmark HALT chamber.
12. 1. Figure 17.1 The six phases of the product life cycle.
    2. Figure 17.2 The hardware reliability process.
    3. Figure 17.3 Proactive activities in the product life cycle.
13. 1. Figure 18.1 Product concept phase risk mitigation form.
    2. Figure 18.2 Risk severity scale.
    3. Figure 18.3 ICM sign‐off required before proceeding to design concept.
14. 1. Figure 19.1 Opportunity to affect product cost.
    2. Figure 19.2 The bathtub curve.
    3. Figure 19.3 System MTBF requirement.
    4. Figure 19.4 Subsystem MTBF requirement.
    5. Figure 19.5 180° of reliability risk mitigation.
    6. Figure 19.6 Where to look for new reliability risks.
    7. Figure 19.7 The reliability risk mitigation process.
    8. Figure 19.8 The ICM is an effective gate to determine if the project should pro...
15. 1. Figure 20.1 The first phase of the product life cycle.
    2. Figure 20.2 Looking forward to identify risk issues.
    3. Figure 20.3 Risk mitigation strategies for reliability and performance.
    4. Figure 20.4 Risk growth curve shows the rate at which risk issues are identifie...
    5. Figure 20.5 DFR guideline for electrolytic capacitor usage.
    6. Figure 20.6 HALT planning flow.
    7. Figure 20.7 HALT planning checklist.
    8. Figure 20.8 HALT development phase.
16. 1. Figure 21.1 Reliability activities in the validation phase.
    2. Figure 21.2 HALT process flow.
    3. Figure 21.3 HALT test setup verification test.
    4. Figure 21.4 Temperature step stress.
    5. Figure 21.5 Vibration step stress.
    6. Figure 21.6 Temperature and vibration step stress.
    7. Figure 21.7 Rapid thermal cycling (60 °C min⁻¹).
    8. Figure 21.8 Slow temperature ramp.
    9. Figure 21.9 Slow temperature ramp and sinusoidal amplitude vibration.
    10. Figure 21.10 HALT form to log failures.
    11. Figure 21.11 HALT graph paper for documenting test.
    12. Figure 21.12 HASS stress levels.
    13. Figure 21.13 HASS profile.
17. 1. Figure 22.1 Assert functions can be used with an appropriate header.
    2. Figure 22.2 Sample test plan.
    3. Figure 22.3 Sample log code.
    4. Figure 22.4 Example log file extract.
18. 1. Figure 24.1 Achieving quality in the production phase.
    2. Figure 24.2 Design issue tracking chart.
    3. Figure 24.3 Reliability growth chart.
    4. Figure 24.4 Reliability growth chart versus predicted.
    5. Figure 24.5 Duane curve.
    6. Figure 24.6 Phase 5 ARG process flow.
    7. Figure 24.7 Typical SPC chart.

1. Table 5.1 Functional activities for cross‐functional integration of reliability.
2. Table 6.1 Failures in the warranty period w/different MTBFs.
3. Table 6.2 Advantages of proactive reliability growth.
4. Table 6.3 RDT multiplier for failure‐free runtime.
5. Table 6.4 FMMEA for fan bearings (detection omitted).
6. Table 6.5 Sensors to monitor for overstress in wearout degradation.
7. Table 6.6 Sensors to monitor bearing degradation.
8. Table 6.7 Component grade temperature classifications.
9. Table 7.1 The FMEA spreadsheet.
10. Table 7.2 RPN ranking table.
11. Table 7.3 FMEA parking lot for important issue that are not part of the FMEA.
12. Table 7.4 Common software failure modes.
13. Table 7.5 Common causes for software failure.
14. Table 7.6 Failure modes and associated possible causes.
15. Table 8.1 Agreed upon HALT limits.
16. Table 8.2 HALT profile for test setup checkout.
17. Table 8.3 Temperature step stress with power cycle and end of each step.
18. Table 8.4 Vibration step stress.
19. Table 8.5 Temperature and vibration step stress.
20. Table 8.6 Rapid thermal cycling.
21. Table 8.7 Slow temperature ramp.
22. Table 8.8 Slow temperature ramp with constantly varying vibration level.
23. Table 11.1 CMMI process areas.
24. Table 11.2 CMMI maturity levels.
25. Table 11.3 Life cycle comparison.
26. Table 14.1 Industry standards for managing counterfeit material risk.
27. Table 15.1 Annual sales dollars relative to typical warranty costs.
28. Table 15.2 HALT facility decision guide.
29. Table 15.3 HALT machine decision matrix.
30. Table 16.1 Reliability skill set for various positions.
31. Table 17.1 Reliability activities for each phase of the product life cycle.
32. Table 17.2 Reliability activities – what's required, recommended, and nice to have.
33. Table 18.1 Product concept phase reliability activities.
34. Table 19.1 Design concept phase reliability activities.
35. Table 20.1 Reliability activities for the product design phase.
36. Table 20.2 Common accelerated life test stresses.
37. Table 20.3 Environmental stress tests.
38. Table 21.1 Reliability activities in the design validation phase.
39. Table 21.2 HALT Profile test limits and test times.
40. Table 24.1 Reliability activities in the production ramp Phase 5.
41. Table 24.2 Reliability activities in the production release Phase 6.
42. table B.1 Conversion tables for FIT to MTBF and PPM.
43. table B.2Factorials.
44. table B.3 Repairable versus nonrepairable systems still operating (in MTBF time units).

Engineering systems are becoming more and more complex, with added functions, capabilities and increasing complexity of the systems architecture. Systems modeling, performance assessment, risk analysis and reliability prediction present increasingly challenging tasks. Continuously growing computing power relegates more and more functions to the software, placing more pressure on delivering faultless hardware‐software interaction. Rapid development of autonomous vehicles and growing attention to functional safety brings quality and reliability to the forefront of the product development cycle.

The book you are about to read presents a comprehensive and practical approach to reliability engineering as an integral part of the product design process. Various pieces of the puzzle, such as hardware reliability, physics of failure, FMEA, product validation and test planning, reliability growth, software quality, lifecycle engineering approach, supplier management and others fit nicely into a comprehensive picture of a successful reliability program.

Despite its obvious importance, quality and reliability education is paradoxically lacking in today's engineering curriculum. Few engineering schools offer degree programs or even a sufficient variety of courses in quality or reliability methods. Therefore, a majority of the quality and reliability practitioners receive their professional training from colleagues, engineering seminars, publications and technical books. The lack of formal education opportunities in this field greatly emphasizes the importance of technical publications, such as this one, for professional development.

We are confident that this book, as well as the whole series, will continue Wiley's tradition of excellence in technical publishing and provide a lasting and positive contribution to the teaching and practice of engineering.

There is a popular saying, “If you fail to plan, you are planning to fail.” I don't know if there is another discipline in complex product development where this is more true than designing for product reliability. When products are simple, it is possible to achieve high reliability by observing good design practices, but as products become more complex, and include thousands of components and hundreds of thousands of lines of software, a systematic approach is required.

This has played itself out inside of Teradyne over the last decade through two product lines in our Semiconductor Test Division. One product line, the UltraFLEX Test System, was designed internally. Another, the ETS‐800 Test System, was designed in a company that Teradyne acquired in 2008.

The UltraFLEX platform was designed using Teradyne's internal Design for Reliability standards. The principles embodied in those standards are described by the authors. We religiously used an approved parts list of qualified components and suppliers, we analyzed the electrical stress on every circuit, and we calculated predicted reliability for every instrument and the whole system. Once the system was fielded, we tracked MTBF and executed our failure response, analysis, and corrective action system (FRACAS) on repeat failure modes. The result is that the UltraFLEX platform, our most complex product, has a field reliability about three times higher than prior‐generation products. What makes this more remarkable is that the UltraFLEX has the capability to test two or even four more semiconductor devices in parallel compared to prior testers.

During the development of the UltraFLEX and over the past decade, we also began to deploy and came to rely upon more formal methods to improve software reliability. To be frank, our organizational maturity in software reliability lagged behind our hardware best practices. But through the application of tools like defect models, and especially tracking the reliability of deployed software through automated quality monitors, we were able to both improve the quality of the deployed product and also improve our development methods. A key tool we use to evaluate software reliability is a metric we call clean sessions. A clean session is a session where an operator starts up the tester, loads a program, executes a task like developing tests, debugging, or just testing devices, finishes the task, and then unloads the program, without encountering any anomalous behavior. When we started tracking this metric at the launch of the UltraFLEX, only about half of the sessions were clean. It took us nearly five years to get to 95% clean sessions, and this has set a benchmark that our competitors struggle to reach. Through the learning achieved in this long struggle, we have been able to achieve 95% clean sessions within three months of the release of our next‐generation product.

The ETS‐800 is the next generation version of the successful tester for mixed signal and power devices. When Teradyne acquired the business in 2008, there was no formal reliability program in place, but their products were well regarded in the marketplace and reasonably reliable. The ETS‐800 was a big step up in terms of capability from the prior generation. The instruments were two to four times as dense, and the system could support almost twice as many instruments. Further, the tester included a promising new feature that would greatly simplify customer test programs by providing the switching needed to share tester resources between different device pins.

From a functional and performance perspective, the ETS‐800 was a fantastic success. A single ETS‐800 could replace up to eight prior generation testers. But we found out the hard way that the informal approach to reliability that worked for simple products did not work for more complex ones. When we initially fielded the ETS‐800, it was not a reliable tester. The weak link in the design was the inclusion of thousands of mechanical relays. These relays provided superior electrical performance, but are challenging to use from a reliability perspective. Mechanical relays are highly reliable if they are not hot switched, or switched while a current is flowing through the contacts. A hot‐switching event causes an arc across the contacts surface that causes a rapid degradation to the contact surface and the life of the relay. If the relays were designed for reliability, the hot‐switching event could have been avoided. The ETS 800 reliability was an order of magnitude below the much more complex UltraFLEX platform, and this put a blemish on the reputation we worked hard to develop for delivering highly reliable products.

We worked for a long time to try to improve the robustness of the relays, and reduce the occurrence of hot switching without making much progress. Ultimately we decided to redesign all of the instrumentation using guidelines from the Teradyne reliability system. We are just beginning the deployment of the redesigned instruments, but in side‐by‐side testing, they are demonstrating about 100 times higher reliability than the ones that they replace. It was a hard but effective lesson that a systematic approach to hardware reliability and software quality as the authors have described is the best way to achieve both high customer satisfaction and good profits.

Modern engineering products, from individual components to large systems, must be designed and manufactured to be reliable. The manufacturing processes must be performed correctly and with the minimum of variation. All of these aspects impact upon the costs of design, development, manufacture, and use, or, as they are often called, the product's life cycle costs. The challenge of modern competitive engineering is to ensure that life cycle costs are minimized whilst achieving requirements for performance and time to market. If the market for the product is competitive, improved quality and reliability can generate very strong competitive advantages. We have seen the results of this in the way that many products, particularly Japanese cars, machine tools, earthmoving equipment, electronic components, and consumer electronic products have won dominant positions in world markets in the last 30–40 years. Their success has been largely the result of the teaching of the late W. E. Deming, who taught the fundamental connections between quality, productivity, and competitiveness. Today this message is well understood by nearly all the engineering companies that face the new competition, and those that do not understand lose position or fail.

The customers for major systems, particularly the US military, drove the quality and reliability methods that were developed in the West. They reacted to a perceived low achievement by imposing standards and procedures, whilst their suppliers saw little motivation to improve, since they were paid for spares and repairs. The methods included formal systems for quality and reliability management (MIL‐Q‐9858 and MIL‐STD‐758) and methods for predicting and measuring reliability (MIL‐STD‐721, MIL‐HDBK‐217, MILSTD781). MIL‐Q‐9858 was the model for the international standard on quality systems (ISO9000); the methods for quantifying reliability have been similarly developed and applied to other types of products and have been incorporated into other standards such as ISO60300. These approaches have not proved to be effective and their application has been controversial.

By contrast, the Japanese quality movement was led by an industry that learned how quality provided the key to greatly increased productivity and competitiveness, principally in commercial and consumer markets. The methods that they applied were based on an understanding of the causes of variation and failures, and continuous improvements through the application of process controls and the motivation and management of people at work. It is one of history's ironies that the foremost teachers of these ideas were Americans, notably P. Drucker, W.A. Shewhart, W.E. Deming, and J.R Juran.

These two streams of development epitomize the difference between the deductive mentality applied by the Japanese to industry in general, and to engineering in particular, in contrast to the more inductive approach that is typically applied in the West. The deductive approach seeks to generate continuous improvements across a broad front and new ideas are subjected to careful evaluation. The inductive approach leads to inventions and “break‐throughs,” and to greater reliance on “systems” for control of people and processes. The deductive approach allows a clearer view, particularly in discriminating between sense and nonsense. However, it is not as conducive to the development of radical new ideas. Obviously these traits are not exclusive, and most engineering work involves elements of both. However, the overall tendency of Japanese thinking shows in their enthusiasm and success in industrial teamwork and in the way that they have adopted the philosophies of western teachers such as Drucker and Deming, whilst their western competitors have found it more difficult to break away from the mold of “scientific” management, with its reliance on systems and more rigid organizations and procedures.

Unfortunately, the development of quality and reliability engineering has been afflicted with more nonsense than any other branch of engineering. This has been the result of the development of methods and systems for analysis and control that contravene the deductive logic that quality and reliability are achieved by knowledge, attention to detail, and continuous improvement on the part of the people involved. Therefore, it can be difficult for students, teachers, engineers, and managers to discriminate effectively, and many have been led down wrong paths.

In this series we will attempt to provide a balanced and practical source covering all aspects of quality and reliability engineering and management, related to present and future conditions, and to the range of new scientific and engineering developments that will shape future products. The goal of this series is to present practical, cost‐efficient and effective quality and reliability engineering methods and systems.

I hope that the series will make a positive contribution to the teaching and the practice of engineering.