The Design Environment

Legacy strategies are often updated as a result of technology improvements (including Design changes, ATE changes, new BIT capabilities, etc). They are also sometimes updated as a result of their failure to meet expectations or handle conditions that might have only become known once fielded. In such cases, one quickly discovers how effectively the original design environment captured information, and whether the potential for re-using the original data still exists.

The most common discovery, unfortunately, is that the engineering data is not as useful as it once was, and that a fair amount of re-engineering is necessary. Significant contributors to this problem include:

• Too little information was represented
• Data representation is too abstract for analysis
• Information or assumptions were poorly documented
• Data is no longer accessible to current tools (data obsolesence)

When the captured information reduces large amounts of knowledge to a few key conclusions, documentation becomes essential for any future attempt to understand the logic behind the conclusion. Often, this reduction is not only poorly documented, but represents such a reduction in knowledge as to obscure how the knowledge was derived. This is also commonly known as “brain-drain,” where the knowledge that wasn’t documented is lost along with the engineers who originally developed it.

The other problem that can be difficult to avoid, and is why new standards like XML were developed, is that of poor interoperability. Often, the tools that continue to hold the information do not support the import / export capabilities useful to other tools currently being used. While XML promises to solve much of this problem, most users have a hard time identifying to what extent the XML representation is available or suitable.

Overcoming these problems requires emphasizing several aspects of the problem. First, fully assessing each tool’s interoperability, in the context of the problem at hand, helps avoid data obsolescence. Second, ensuring good documentation practices helps avoid the “brain-drain” loss of knowledge. Lastly, creating multiple representations of data helps overcome the limitations of any particular representation. For example, supplementing a diagnostic strategy with a FMECA report helps provide another view of how tests detect certain failures. Of course, a FMECA alone is not useful as a complete definition of testing capability.