Design for Testability (DFT)
And
Design for Diagnosability (DFD)
Design for Testability – The aspects of the product design process whose goal is to ensure that the testability of the end product is
competently and sufficiently developed.
Design for Diagnosability – the aspects of the Diagnostic Engineering process that focus on improving the product design, with the intent of optimizing the extent to which faults within the end product can be confidently, unambiguously and efficiently identified.
Design for Testability is one of two independent, yet related disciplines—both falling under the “testability” rubric—that emerged from the realization that good system diagnostics are the result not only of well-developed test and diagnostic procedures, but also of decisions made during the product design process. Today, Design for Testability most frequently refers to a set of practices that provide a means of ensuring fit or function of low-level circuits within electronic circuit boards or chips (including fitness for software test). In practice, Design for Testability is closely related to Design for Test (both even sharing the acronym DFT).
Considerable confusion arises from the fact that the various parties who are designing for testability are not necessarily doing Design for Testability—they may be doing what we might call Design for Diagnosability.
The other discipline that falls under the “testability” rubric—a discipline whose domain has been variously referred to as system testability, quantitative testability (FD/FI) and, more recently, Diagnosability—concerns itself with optimizing a system or device’s ability to support good diagnostics. This discipline, which we will refer to as Design for Diagnosability, encompasses all levels of the design hierarchy (from lowest-level components to top-level system) and is therefore applied during all phases of an Integrated Systems Development process.
This process begins early in the design phase when the system is being conceptualized and when the performance requirements of the system or end product are being determined. In time, system requirements are formed and flowed down to contractors and suppliers in the form of functional specifications. Unfortunately, a dichotomy of Diagnostics Requirements flow-down exists in many of today’s programs where much is expected (and needed) for design of Health Management and Logistics Support, but the actual requirements are either non-existent or confusing. Problems in requirements start with the end user/customer and the resulting confusion inevitably flows down through the contractor to lower-level subcontractors and suppliers.
Basic testability measures such as the probability of fault detection and isolation to a specified fault group are not sufficient to meet today’s operational and support needs. Furthermore, requirements such as “no support equipment shall be required” or “100% isolation to a single unit” sound good in a proposal but are usually neither financially nor technically feasible. To meet the needs of modern Health Management and Logistics Support, a balance of capabilities must be determined through qualified diagnostic analyses and trade studies to determine the optimum design solution. Embedded Diagnostics should be the goal, but the optimal solution may require some form of external test. Small fault groups are, in general, desirable, but what level of isolation is actually required by the maintenance concept? What is the optimal Level of Repair? These values cannot be effectively specified at the beginning of a design project; they must be determined through iterative Diagnostics Analyses and trade studies that interact with the Logistics Support Analysis.
Other requirements are also derived from the Systems Diagnostics Analysis such as candidates for limited prognostics (based on physics of failure) vs. planned or scheduled maintenance, and System Reliability based on redundancy or degraded modes of operation.
