Integrated Systems Diagnostic Design (ISDD) Process
Tending To Basic Challenges of
Design For Testability
The term DFT has been around for several years now and has been focused on designing a component’s test capability for production. The DFT objectives have been driven by performance specifications at the component level. The primary goal of DFT has been to provide assurance that the component performance parameters are tested prior to production acceptance. The challenge facing DFT today is the need to look ahead to system level requirements and specifically the needs of the system / platform health management system, and the life cycle maintenance support. This challenge brings in the need for the Integrated Systems Diagnostics Design (ISDD) process.
The ISDD Process, which may be referred 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 the Integrated Systems Diagnostic Dsign process. The focus for DFT in today’s design environment must move to a full understanding of how the lower level component needs to perform at the system level. This performance goes beyond the typical functional parameters to the need for integrated systems diagnostics. The component failure modes must be observable at the system level and the effect of these failure modes must be understood at each level of the system hierachical relationships. Even though production level tests can be well designed through DFT, this provides no assurance that the component is diagnosable at a higher level of integration.
The ISDD 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 the design of Health Management and Logistics Support, but the actual requirements are either non-existent or confusing. Problems with requirements start with the end user/customer and the resulting confusion inevitably flows down through the contractor to lower-level subcontractors and suppliers. The other issue here is most component suppliers only understand the traditional DFT process and have no concern for the component’s diagnostics capability at higher levels of assembly.
To properly understand requirements and to flow down a balanced set of requirements, all parties in a product design must be involved in the decision process. Even if a prime contractor understands the systems diagnostics requirements, the subcontractors and suppliers must be involved in determining the optimum balance of diagnostics capabilities. In a truly integrated systems design, the component supplier must be involved with the diagnostics requirements derivation. 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 specification 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 System 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.
The four (4) principle goals of Designing for Testability for the Integrated System (end or fielded product) are to support Cost of Ownership, Availability, Mission Success and Safety. The implementation of an effective ISDD Process is the only viable means to qualitatively assess alternative diagnostic design capabilities to the integrated system requirements. Ultimately, the Integrated System’s Diagnostic capabilities shall be limited to the integrated diagnostic design constraints. This is a ubiquitous systems diagnostic design deficiency that results from diagnostic integration assumptions made by and between independent tools, processes and resources by and between each contributing supplier prior to systems integration.
Often various departments in organizations attempt to perform diagnostic engineering efforts with little or minimal consistency with the overall System Integrator and/or resort to home brewed methodologies (spreadsheets) that are not necessarily readily interpretable in the diagnostic design integration flow of information to be used by the end product system. The System Integrator is then left with the task of guessing how to make the diagnostic data be of value at the system level and to decide how to integrate the component level test with system level diagnostics. Figure 1 shows the complexity of integration between organizations and even within individual organizations with regards to diagnostics and DFT requirements.
Figure 1, Complexity of Integration between and within organizations
Today’s complex systems and dynamic operating environments demand a change from the “traditional” acquisition process. We must move away from the cookie cutter specifications and requirements flow down to a planned and well managed ISDD process. This process requires collaboration between the end user, system level designers, all of the sub-system designers, down to the component level designers. This drives interrelations amongst all of the contributing design team members coupled with the clarity and transfer of these principle goals of the system diagnostic requirements to these team members from the end product customer.
It is outside the scope of this chapter to discuss the details of mapping Design Requirements to any of these goals in particular, however, it is imperative to identify and realize the collaborative and ultimate system goals of designing for Testability and how this responsibility must be owned by all levels of design integration. The point that must be driven in with the new integration of DFT and ISDD is DFT is no longer a production only issue; DFT must include a full understanding of the product’s end use and all of the elements in between.
The traditional definition of DFT has been:
DFT - Design for testability, the process by which a system design takes into consideration the test coverage that can be achieved in production.
The new definition of DFT must be: