Standards and Best Practices
Standards and best practices give reliability engineering a common vocabulary, repeatable methods, and expectations that survive changes of project and personnel. A standard tells an engineer which analysis to perform, how to perform it so that another laboratory reaches a comparable result, what evidence a customer or regulator will accept, and how much test time a claimed failure rate actually requires. Without that shared basis, reliability work becomes a matter of individual judgment and cannot be compared across projects, teams, or suppliers.
The body of reliability standards is large and uneven. International bodies such as ISO and IEC, industry associations such as JEDEC, SAE, and AIAG, and defense and space organizations have each built frameworks. Some establish general methods that any sector can use; others encode the specific expectations of automotive, aerospace, medical, telecommunications, or process industries. Layered over all of them is a long tail of cancelled military standards that survive as non-mandatory handbooks and as citations in legacy contracts. The practitioner's first task is therefore not to master every document but to know which documents apply, which are current, and which carry only historical authority.
Articles in This Category
How the Standards Landscape Is Organized
Reliability documents look interchangeable from a distance, but they answer different questions. Sorting them by purpose is the fastest way to decide which ones a program actually needs.
Program standards describe what a reliability effort must contain: which tasks are performed, at which milestones, and with what deliverables. MIL-STD-785B filled that role for defense programs for decades. Since its cancellation, the function has largely migrated into sector quality frameworks such as the ISO 9000 series and AS9100, into functional safety life-cycle requirements, and into program-specific statements of work.
Analysis-method standards define how an analysis is conducted and documented. IEC 60812 (edition 3.0, 2018) covers failure modes and effects analysis in both its FMEA and FMECA forms, IEC 61025 covers fault tree analysis, and IEC 61078 (2016) covers the reliability block diagram method. These documents standardize the method and its notation. They do not state what result is acceptable; that threshold comes from a customer requirement or a safety standard.
Test-method standards define how a stress is applied so that results from different laboratories mean the same thing. MIL-STD-810 covers environmental engineering considerations and laboratory tests, MIL-STD-883 covers microcircuit test methods, MIL-STD-750 covers test methods for semiconductor devices, and the JEDEC JESD22 series covers component-level reliability stresses. A test-method standard is a recipe, not a pass criterion; the acceptance limit belongs to the qualification specification that invokes it.
Prediction handbooks and data sources supply failure-rate models and base data. MIL-HDBK-217F, Telcordia SR-332, and FIDES all belong here, as does IEC 61709, which contributes stress models for converting failure rates between operating conditions rather than base failure rates of its own. These documents produce comparative numbers, and their outputs differ substantially for the same design because their underlying data sets and assumptions differ.
Data-collection standards make field experience poolable. ISO 14224 (2016) defines an equipment taxonomy and a failure-and-maintenance data format for the petroleum, petrochemical, and natural gas industries, which allows operators to combine records that would otherwise be incomparable. Any organization that intends to learn from its own field returns benefits from adopting a defined taxonomy, whether or not it uses that particular one.
Assurance and functional safety standards set the required rigor and the acceptable risk. IEC 61508 and its derivatives, DO-178C and DO-254 in civil aviation, and ISO 14971 in medical devices all belong to this group. They consume the products of the other four groups as evidence.
Reliability Standards Are Not Safety Standards
The most common category error in this field is treating a functional safety standard as a reliability standard. The two are complementary, not equivalent. A reliability standard supplies a method for estimating or demonstrating how often something fails. A functional safety standard states how often a dangerous failure may occur, demands architectural and process measures proportionate to that target, and requires documented evidence that the target has been met.
IEC 61508, published in its second edition in 2010, is the generic parent of that family. It expresses integrity targets as safety integrity levels, SIL 1 through SIL 4. For a safety function operating in low-demand mode, SIL 3 corresponds to an average probability of dangerous failure on demand between 10-4 and 10-3; for high-demand or continuous operation, the target is expressed instead as a probability of dangerous failure per hour. Sector derivatives adapt the same logic: IEC 61511 for process-industry instrumented systems, IEC 62061 for machinery control, and ISO 26262 for road vehicles, which substitutes automotive safety integrity levels, ASIL A through ASIL D, derived from severity, exposure, and controllability.
Two practical consequences follow. First, an integrity level is a property of a safety function in a defined context, not a badge attached to a part. A component may be assessed as suitable for use in a given safety function, but it is the function, with its architecture, diagnostics, and proof-test interval, that carries the SIL. Second, the reliability analysis is the evidence, not the conclusion. Failure rates, diagnostic coverage, common-cause factors, and proof-test intervals feed the safety calculation; the safety standard decides whether the resulting number is good enough and what process discipline must accompany it.
Aviation applies the same separation with different vocabulary. DO-178C (2011) governs airborne software and DO-254 governs airborne electronic hardware, both by assigning design assurance levels rather than numerical failure rates to development processes, while system-level safety assessment under ARP4761A and development assurance under ARP4754B, published in December 2023, allocate the quantitative budgets.
Active Requirements Versus Historical Guidance
A large share of the documents that reliability engineers cite daily are formally cancelled. MIL-STD-1629A, the FMECA procedure issued in 1980, was cancelled on 4 August 1998 without replacement, and its cancellation notice pointed users toward national and international alternatives. MIL-STD-785B, the reliability program standard, and MIL-STD-2074, the failure-classification standard for reliability testing, were likewise cancelled without superseding documents. All three continue to shape practice, appear in training material, and turn up in contract citations.
MIL-HDBK-217 illustrates the problem most sharply. Its last released revision, Revision F Notice 2, is dated 28 February 1995. A Revision G effort has been under way since 2008 under a Navy preparing activity without producing a published result. The handbook's component models therefore predate most of the packaging, process nodes, and part families now in production. A prediction generated from it remains useful for comparing two candidate designs under identical assumptions or for allocating a reliability budget among subsystems, but it should not be presented as a forecast of field failure rate, and stakeholders should be told which data vintage produced the number.
The distinction between a standard and a handbook matters for the same reason. A handbook is guidance by definition; a standard becomes a requirement only when a contract, regulation, or specification invokes it, and the invoking document may tailor it heavily. Before treating any clause as binding, read the document that invokes it and confirm both the revision and the tailoring. Citing "MIL-HDBK-217" without a revision, or "IEC 61508" without an edition, invites two parties to build evidence against different requirements.
Applying Standards in Practice
Adoption succeeds or fails on a handful of concrete habits.
Tailor deliberately. Standards are written to cover a wide range of programs, from a consumer accessory to a crewed spacecraft. Applying every clause to a modest product wastes effort and buries the clauses that matter. Tailoring should be a documented decision with a rationale, agreed with the customer or assessor, rather than a silent omission discovered during an audit.
Maintain a compliance matrix. Map each applicable clause to the specific artifact that satisfies it: a test report, an analysis, a procedure, a design review record. The matrix is what turns a shelf of documents into a defensible argument, and it exposes gaps months before a certification body does.
Plan for assessment. Functional safety certification, notified-body review for medical devices, and airworthiness approval all depend on evidence produced during development, not assembled afterward. Independence requirements, tool qualification, and configuration control are far cheaper to satisfy from the start than to reconstruct.
Flow requirements down. A system inherits the weaknesses of its supply chain. Qualification requirements, change-notification obligations, and data-reporting formats belong in purchase agreements, because a supplier that changes a die, a package, or a fabrication site without notice can invalidate a completed qualification.
Track revisions. Editions change what evidence is required. ISO 14971 reached its third edition in 2019, IEC 62061 was reissued in 2021, and a third edition of IEC 61508 is in development. Programs that span several years should schedule a periodic review of the standards they cite rather than discovering a revision at certification.
Common Pitfalls
Certification is sometimes mistaken for the objective. A certificate records that a process was followed and evidence was produced; it does not guarantee that a product is reliable in service, and organizations that optimize for the audit rather than the field failure rate eventually pay for the difference in warranty and recall costs.
Prediction results are frequently over-interpreted. Handbook methods carry wide uncertainty, they generally model only steady-state random failures, and they exclude the design errors, manufacturing defects, software faults, and misuse that dominate real field returns. Mixing methods within a single analysis compounds the problem, because a Telcordia figure and a MIL-HDBK-217 figure are not directly comparable.
Borrowing a framework wholesale from another sector rarely works. Automotive APQP assumes high volumes, long production runs, and a deep tier structure. Aerospace development assurance assumes small volumes, certification authorities, and service lives measured in decades. Each framework is well matched to its own economics and poorly matched to the other's.
Finally, standards compliance is often confused with usefulness of the resulting data. An FMEA performed to satisfy a checklist, filed, and never revisited when the design changes provides no protection at all. The discipline that makes a standard valuable is keeping its artifacts alive across the life cycle, feeding field failures back into the analyses that failed to anticipate them.
About This Category
Standards and best practices represent the collective experience of the reliability profession distilled into actionable frameworks. Organizations that adopt them draw on decades of accumulated practice and avoid reinventing approaches that have already been refined through wide application. Whether the goal is certification, benchmarking against industry norms, or simply internal consistency, these frameworks supply the structure that ad hoc effort cannot.
The landscape continues to evolve as technologies and reliability challenges change. Engineers must track revisions to existing documents and the emergence of new frameworks addressing software reliability, cybersecurity, and machine-learning systems, where established methods for quantifying failure remain immature. Used together, the subcategories above offer a practical foundation for applying reliability standards across the full life cycle of electronic systems, from early design through field sustainment.