Cheryl Tulkoff - Design for Excellence in Electronics Manufacturing

Reliability goals and requirements address the product or system itself and include test and assessment requirements and associated tasks and documentation. These are included in appropriate system/subsystem requirements and specifications, test plans, and contract statements.

Examples of reliability goals and metrics:

Minimum required field service life under defined conditions: 10 years of environmental exposure and 150,000 miles (or 1 million operating hours)

Maximum allowable quality defect rates– Field infant mortality quality defect rates at 3‐6‐9‐12 months– Dead on arrival (DOA) defect rate– Required minimum field reliability at one year or the end of the warranty period– Six Sigma first‐pass quality yield– Non‐repairable or failure to replicate (no trouble found, NTF) rates

Meaningful reliability prediction must consider the environment in which the product is used. There are several commonly used approaches to identifying the environment. One approach involves the use of industry/military specifications such as MIL‐STD‐810, MIL‐HDBK‐310, SAE J1211, IPC‐SM‐785, Telcordia GR3108, and IEC 60721‐3. The advantages of this approach include the low/no cost of the standards, their comprehensive nature, and acceptance throughout the industry. If key information is missing from a given industry standard, simply consider standards from other industries. Disadvantages include the advanced age of the standards (some are more than 20 years old) and the lack of validation against current design usage. Depending upon the product and environment, the standards both overestimate and underestimate reliability by an unknown margin.

A second approach to identifying the field environment uses actual measurements of similar products in similar environments. This provides the ability to determine both average and realistic worst‐case scenarios. All failure‐inducing loads can be identified; and all environments, including manufacturing, transportation, storage, and field, can be included.

An example of where to implement key reliability tools and tests across the product design and development phases is shown in Figure 2.1.

Figure 2.1 Reliability tools across the design and development process.

Table 2.1details common quality and reliability challenges in electronics along with recommended test and inspection methods.

The major difference between software and other engineering endeavors is that software is purely design. Hardware unreliability issues are typically related to physical failures of components, which can be traced back to a variety of root causes, such as material, fabrication, or assembly defects; environment or usage overstress; or wearout and design errors. In contrast, when software problems arise, they are traced back to design faults, which come from human errors such as inadequate or incomplete requirements, coding errors, logic errors, improper resource allocation, or the inability of the software to deal with system faults, noise and exception faults.

Therefore, software integrity and dependability are fully dependent on properly implementing quality procedures throughout the specification, design, and coding of the software. This activity should be coupled with meticulous testing and validation activities that can find and correct inadequate requirements, bugs, and discrepancies as early as possible in the design, development, and validation process.

In addition to verifying basic functional operation per the requirements covered in the various industry standards on software development, procedures that also evaluate functional robustness, fault tolerances, and – for devices with operator interfaces – user‐friendliness should also be considered. The following procedures are recommended for use in the specification, creation, development, and validation processes of functional safety of critical software.

Table 2.1 Common quality and reliability issues.

Requirements Verification Assessment for Accuracy and Completeness

Historically, many software discrepancies can be traced back to specification inadequacies, such as inconsistent, incomplete, imprecise, or vague requirements. Therefore, the first step in any functionality/software validation effort is for the responsible software design organization to perform an analytical review with the specifying organization. The review facilitates an understanding of the requirements, ensures accurate requirements communication, weeds out obvious discrepancies before they are incorporated into the code design, and determines and documents the readiness of the specification for starting the design effort. With this knowledge, corrections can be rapidly implemented.