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.1 details common quality and reliability challenges in electronics along with recommended test and inspection methods.
2.3.3 Software Reliability
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.
| Area of concern | Impacted item | Failure mechanism | Testing method | Inspection technique |
|---|---|---|---|---|
| Moisture sensitivity | Plastic IC packages, optocouplers, other polymer‐based components | Popcorn delamination at higher reflow temperatures. Heat damage of IC packages | Moisture sensitivity testing | Visual inspection |
| J‐STD‐020 | C‐SAM | |||
| Heat damage | All passive components, circuit boards, connectors | Cracking, dielectric breakdown (capacitors), PCB delamination, warping, or via cracking | Heat resistance, MIL‐STD 202G #210F, decomposition temp., time to delamination, package planarity, JESD22‐B108 | Visual inspection, functional verification |
| Poor wetting | All solder joints | Cold joints or weak joints fracture in the use environment | Solderability, J‐STD‐002, J‐STD‐003 | Wetting balance, visual inspection, x‐sectioning, lead pull |
| Solder fatigue | Solder joints, particularly on high‐CTE components | Cracked solder joints | Thermal cycling, JESD22‐A104, HALT, Vibration | Electrical continuity, visual inspection |
| Mechanical shock | Solder joints particularly on higher‐mass components | Solder joint failure during shipping or handling | Shock test | Electrical continuity, visual inspection |
| Sn whiskers | Sn and SnCu‐plated components | Shorting | iNEMI / JEITA procedures | SEM |
| Surface mount process control | Insufficient process window creates poor solder joints | Solder joint failures in the use environment | Precondition and assembly, JEDEC 22‐A113 | X‐ray, X‐section, visual inspection, reliability test |
| Rework process | Poor solder joints, damaged components | Joint failures or cracked vias in the use environment | Rework components followed by reliability testing | X‐ray, X‐section, visual inspection, reliability test |
| Wave solder process | Incomplete hole fill, fillet lifting, damage to the board | Failed through hole, cracked vias, weak joints | Thermal cycle, HALT Vibration | Electrical continuity, visual inspection |
| Electrochemical migration | Board surface with no‐clean paste residue | Shorting between biased traces in a moist environment | Bellcore GR‐78‐CORE, J‐STD‐004 SIR | Visual and resistance after 35 C/85%RH exposure at 50 V |
2.3.4 General Software Requirements
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.
The review results should be documented in an electronic format (spreadsheet or database) that allows it to be a living document for program tracking, management, and corrective action purposes. It should be organized