Default eXpress64
What Exactly is a Diagnostic Analysis Tool?
The terms diagnostics and analysis are thrown around in many contexts. The following text describes how DSI defines this term.

Unfortunately, the use of the term “analysis” with “diagnostics” enforces the notion that a “diagnostic analysis tool” may be an aid to examining existing design data or information. We’ll use the term “Diagnostic Analysis” to initially establish a general common ground for discussing diagnostics. However, when we employ the most deterministic and efficient diagnostic methodologies, we soon encounter a conflict with the thought of scoping the discipline to solely being a design reactive process.

For most of us, Diagnostic Analysis may be a familiar process, and certainly there is merit to the incorporation of a “look back” or reactive approach, but it’s lack of adaptability poses certain diagnostic risks encumbered by inherent design limitations. Such design limitations are, in essence, diagnostic limitations. In this vein, after the design is frozen, we have compromised our diagnostic influence and effectiveness in areas such as system reliability, maintainability, availability, accessibility, hardware partitioning, sensor placement, safety, etc.

A “Diagnostic Development” tool is probably a more accurate representation of the diagnostic process implemented by the ISDD tool suite. The intent of the tool suite is to synthesize the diagnostics with the design. For any tool to achieve this objective, it must be capable of looking back (reactive) and looking ahead (proactive) at any phase of equipment’s design. Starting in the design’s concept phase, you should have the ability to continuously assess the design’s current diagnostic capability, while still being in the position to make changes appropriate to satisfying design requirements. Without having a tool in this position, future decisions about various implementation or technology tradeoffs must be made haphazardly, thus opening the door to drastic increases in cost of ownership due to poor diagnosability, reliability and availability. For example, the X-33 diagnostic analysis revealed that redundancies in the propulsion systems decreased the overall system reliability and increased maintenance costs. Having found this during the design development cycle allowed the appropriate changes to be made to the design to achieve a less costly and more reliable course of action.

The eXpress Software is an interactive, graphical, model-based engineering tool for the development, assessment and governing of System and Unit level diagnostics. The full hierarchical nature of eXpress allows for both top-down and bottom-up editing of models. It features a self-contained symbol and parts library and it is primarily being used in the integrated design and diagnostic development environment.

While the benefits of its use are greatest when used early in the design process, it can be implemented at any point in order to impact remaining diagnostic decisions. With shuttle upgrades planned and/or still unplanned, the use of this approach to compliment your existing design process, should vastly decrease future cost of ownership. Employing this type of co-development approach greatly enhances the diagnostic utility of Vehicle Health Monitoring (VHM) for any number of systems, including the avionics, communications, payload, or propulsion systems, for example, on-board the Obiter or any other like Space Transportation System. Having in-depth diagnostic insight, gives the owner or system’s integrator the power to be able to simulate, measure, forecast, and most importantly, modify the system’s design before manufacturing begins.

Prime objectives are to be able to identify, evaluate and prioritize design and diagnostic elements that make a system more reliable by decreasing complexities though reductions in design redundancy, strategic sensor placement and/or diagnostic implementation. Further benefits can then be realized from the many aspects associated with minimizing manufacturing and operational costs. Less manufacturing and complexity may produce a need for fewer parts, lower fuel requirements, reduction in Fault Detection, Fault Isolation and Recovery times, reduce turn around time and any related risks or costs, while increasing overall system supportability, reliability and safety.