When tasked with selecting a Systems Diagnostic Engineering Tool, one important consideration is the reduction of the business risk associated with using that tool—something that can only be assessed if one understands not only the various calculations performed by the tool, but also the more basic question of how well the tool meets the overall needs of the systems engineering process. As alternative and/or complimentary tools are identified, the analyst must consider how the strengths of each tool might be leveraged without compromising the primary objectives of the systems diagnostic design.
Diagnostic Engineering Tools should be researched, evaluated, and selected early in the design process—before the Subsystems Design Requirements are derived and “flowed down” to developers (both internal and subcontracted). Furthermore, in order to reap the full benefits of the tool, the diagnostic engineering process should begin extremely early in the design process—well before the selection of specific parts or components (and therefore, well before the identification of specific failure modes). This concurrent, systems-oriented process should influence not only part selection, but also sensor placement, repair item partitioning, redundancy, access, safety, etc.
In order to provide effective feedback early in the design process, the Systems Diagnostic Engineering tool must be able to analyze the diagnostic capability of the functional design of the system. If the tool requires that failure modes be modeled before it can provide useful feedback, then that tool will be useless during the phase of development in which it would be cost-effective to implement the results of diagnostic analysis.
As parts are selected and specific modes of failure identified, the tool must be able to not only capture this knowledge, but also integrate it into the existing functional models. Of course, since it is not always possible to enter a program at the earliest design phase, the tool must be able to effectively support modeling and analysis at any stage of development, including work on legacy systems. Moreover, to address all business cases, the tool must support differing levels of effort. In some situations, such as when one needs a quick-and-dirty assessment of an existing design, it is desirable that modeling and analysis be performed with minimal effort, importing as much as possible from existing design databases. In other cases, it may be desirable to develop a more elaborate model in order to document details of the diagnostic design or establish a baseline that can be used for future analyses.
Since many complex systems require large, multi-layered breakdowns, a Systems Diagnostics Engineering Tool must be thoroughly scalable, allowing the analyst to efficiently model and analyze extremely large systems, as well as individual units (such as a circuit card or encapsulated device). It must also provide features to ensure consistency and facilitate the integration of models created by many different analysts—either within the same or in different companies or divisions.
Selecting a Systems Diagnostic Engineering tool is much more than comparing outputs. The tool must help you and your customers’ satisfy all technical and business case needs within the full Systems Engineering process.
The Systems Diagnostic Design Development Tool must: