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.

SYSTEMS DIAGNOSTICS DESIGN DEVELOPMENT TOOL CHECKLIST

The Systems Diagnostic Design Development Tool must:

• Drive System Design Requirements.
• Fully support very early design influence decision making process based on functionality of the system.
• Provide a graphical means to efficiently communicate design functionality that describes diagnostic coverage.
• Provide effective design assessment and produce a requirements Gap Analysis at any phase in development or product use.
• Capture iterative and evolving data and design knowledge while effectively reporting system or subsystem diagnostic capabilities at any point during development.
• Integrate various program disciplines such as Reliability, Maintainability, Production, Logistics Support, Test Engineering, Cost Analysis, etc.
• Provide true hybrid integration of functional and failure mode analysis.
• Fully support both common cause (single fault) and Multiple Failure diagnostics.
• Provide a scalable and open architecture to allow the importing, exporting and exchange of data for rapid design and life cycle support of embedded Operational Health Management, and Logistics Support.
• Not be solely dependent on any single industry standard, but rather be easily adaptable to such standard(s).
• Be widely used within Industry and Government Agencies.
• Provide accurate and repeatable analysis results, with high confidence, from solid and proven algorithms backed by world wide industry experience.
• Be supported by a company with a long-standing reputation in industry.