inner banner

Design For Test-Design For Testability (DFT)

In the pioneering of “Testability” (in 1964), and before acronyms such as DFT, DfT or DDT were established to describe specific segmented activities within the fully intended scope of “Designing for Testability”, the objective was to “Influence the Design for Testing” – any and all testing – AND concurrently, to influence the design for effective sustainment – “Design for sustainment”.

Designing for Test, Testability, Sustainment, etc. must be a multiple disciplinary-inclusive process without design domain barriers. The activity must coexist as an efficient and exhaustive approach that always has an eye on the sustainment objectives and thereby contributes to the forming of a byproduct knowledgebase. But to gain any true knowledgebase, data artifacts retrieved from the integration of relevant, disciplinary-owed data would need to be formally “integrated”, which is beyond the simple “sharing” of data.

Since the objective of “Design For Testability” was intended to be to “Develop for the Sustainment lifecycle during Design Development”, any DFT activity would require the gathering, restructuring and organization of the DFT data for any and all of the designs comprising the “system” AND how each design is “interrelated” to any other design(s) within a fielded product (“Integrated System”).

DFT Must Be Considerate of Other Designs

When concerned about any independent design, DFT is important, but the awareness of the “integrated” designs, that may be developed by other design teams or organizations, is imperative to consider as design complexity increases. As independently developed designs are “integrated” into larger designs, assemblies, subsystems or the fielded product, the DFT performed for independent lower-level designs no longer retain its DFT value from the “fielded product” perspective – UNLESS the (functional and failure) interrelationships are established throughout the fielded product.

When the capturing of the functional and failure interdependencies between each design entity, regardless of design domain (electronic, hydraulic, mechanical, optical or software, etc.) is performed, the DFT is significantly more effective and is capable of determining “Fault Groups” for the fielded product! Now, the transitioning to Designing for Sustainment DFD may begin!

Test Coverage and Test Coverage Interference

”Test Coverage” is just one ingredient. We’ll need to introduce the design to “Test Coverage Interference” when “integrated” with other (sub)systems, etc. Here is where we soon discover the disparity in (BIT) Test Coverage acumen per operational state in a deployed environment – but that’s another discussion. Just know that this is where we ultimately need to be with “net” ‘Test Coverage’ beyond the lab or production environment. This unlocks more treasure from the performing of DFT, DfT and DTT that is necessary to generate DIAGNOSTIC CONCLUSIONS given “test results” when eventually deployed in the (myriad of evolving) sustainment paradigm(s).

Establishing of a Diagnostic Design “Knowledgebase”

Once the interrelationships between the designs are captured in eXpress, the overarching “Integrated System(s)” diagnostic design is ready to be established. By including the “Test Coverage” for each point of “test”, “observation” or “location of health status interrogation” (BIT sensors, ATE, etc.) the Diagnostic Design Knowledgebase comes to “life”!
Capturing and validating the Test Coverage for complex systems is an inherent advantage of using eXpress.

DFT for Semiconductor Industry

Design for Test as used by professionals in the semiconductor industry, have an acutely specialized understanding of “DFT”. As such, this activity concerns itself with digital designs using techniques as abist, ambist, atpg, boundaryscan, bsc, bsr, cbist, fastscan, ibist, jtag, logic test, logicbist, mbist, memory test, mixed-signal test, etc. While these are admirable techniques and have significant merit at that specific piece of DFT, the investment into this flavor of DFT is not generating enough attention as a valuable or reusable asset for the systems’ integrator for larger “integrated” products (trains, military vehicles, missile systems, airplanes, etc.). This will continue to be a challenge for the DFT community in this sector until it reaches out to integrate with methods or tools that can leverage this investment with, and across, other designs and design domains in a seamless transition, and become effective in any evolving sustainment paradigm(s).

DFT and its concept of “System”

The use of “system” is not universally understood to be narrowly specific, so it would be otherwise advantageous to embrace the broadest understanding of the term, “system”.

Whichever DFT, DfT or DDT activities that are able to be embraced, we need to be made fully aware that the investment into such an activity can be made to be fully extensible into other interdependent design domains, activities and throughout the sustainment lifecycle. The extending of such program value must show a benefit in servicing the balancing of the four (4) goals of Testability. These four goals effectively target the balancing of any sustainment paradigm(s) and those goals are:

  • (Equipment or System(s)) Availability
  • Operational or Mission Success (Reliability)
  • (Operational) Safety
  • Cost of Ownership

ALL of the “illities” are typically attempt to be “integrated” (not simply “incorporated”), but effectively result in being competing activities that “sharp-elbow” their interdependent disciplinary objective to be of greater priority (and thereby, greater influence on program budget).

DFT as a Design Influence Activity

The objective of “Designing for Sustainment” includes the interdependence on all of the design and support “ilities” and it MUST be a performed as “Design Influence” activity inclusive of all design disciplines and not restricted to any specific design domain (e.g. digital). The most optimal dividend of such a solution would be to establish a “Test Tool independent” capability, which coming from firsthand knowledge, was the originally intended scope of the full Systems Testability discipline. These are just some of the initial benefits of the embracing a much broader vision of DFT, DfT from today’s DFT community.

It is somewhat encouraging that the folks, some 50 years later than introduced to industry, are finally embracing early Design For Testability for “Design Influence”. This “early design influence” message has been repeated tens of thousands of times from our perspective alone.

Related Documents & Videos:

Boundary Scan modeling in eXpress

Standards-Powered, COTS-Based Solution for Through-Life Support

Subscribe To Our Newsletter