Diagnostic Validation for Complex Designs
Diagnostic Validation for Complex Designs
Traditionally, designs have been developed with little attention to discovering the design's diagnostic integrity. Engineers are overwhelmed with many tasks while Program Management hasn't really understood the widespread value of diagnostic engineering.
It hasn't been too long ago when the embracing of DFT within the design discipline has been able to demonstrate an improvement in the quality of the (digital) design(s) and the design practices. Functional "Test Coverage" could be ascertained and design processes could be enhanced as an initial benefit.
Designing for Health Management (PHM, ISHM, etc.) or multiple sustainment levels, is a more complex task today. It embodies a different level of "Test Coverage" sophistication when considering the incorporation of many designs across a complex hierarchical design architecture. Vehicle or Equipment BIT Test Coverage and sensor placement becomes a much more challenging endeavor when required to consider a wide variety of designs supplied by many contributing design activities from within or from outside the Systems Integrating Organization.
What traditional design Test Coverage analyses fails to provide is Diagnostic Clarity. We can all be pleased with our Test Coverage, but are we able to truly rely on it in an evolving operational environment?
This is where we embark on the purpose of understanding the “Diagnostic Integrity” of our design(s) – no matter what design domain mix is involved, nor how large or how complex these designs may be or may become in a world of change.
If any complex or critical design is to be maintained and supported, we need to consider how our current methods can be greatly enriched to support any type of diagnostic paradigm and multitude of sustainment paradigms, including, but not limited to: Production Laboratory, ATE, Health Management and any extensible Guided Troubleshooting environment (IETM, PMA, or JPA).
Therefore, what we really want to discuss is the ability to validate our diagnostic integrity. By using the term, “validation” there are several different meanings or uses that one may be referring.
One meaning might be to assess if the diagnostic integrity of our design is sensible. In other words, did we capture or “model” the BIT (or any diagnostic interrogation/observation point) correctly and does the diagnostics we developed make sense from an operational standpoint?
Another type of diagnostic validation may be simply by our being able to insert several faults into the system and to discover and prove that we’re able to isolate those inserted faults correctly. Still other uses may target:
Diagnostic Sanity Checks ? Customer or Maintenance Demos
Diagnostic Sequencing Deliverables ? BIT or Fault Code Validation
In-House Design Reviews ? Validation of Diagnostic Procedures
Guided Troubleshooting Integrity ? Multiple Design Domain Applicable
However, before we do that using an actual fielded system, we can immediately learn all of this right NOW – during Design Development!
The video link in the image will guide you through an introduction how this is performed at any time during the Design Development or evolving Sustainment lifecycle(s).
In the video, we will insert faults and see what the diagnostics are supposed to isolate to, based on the development we did and which tests were used.
Some of you can imagine how you would be able to IMPRESS your customer by performing a preliminary maintenance demo by inserting faults – their predetermined faults – any random faults – any combination of whatever faults!
In this manner, if we aren’t generating the same results as expected, we can actually step through our diagnostics in our model, see what was happening and figure out if there was a problem in the implemented diagnostics in the field, whether there was a problem in assumptions made by the diagnostics as contained in the model that aren’t being completely transferred into the field, or whether we actually have any errors in the model. So this comprehensive diagnostic validation capability was designed to target any single or multiple diagnostic scenarios.
You will be able to observe how any design’s test and diagnostic coverage can be fully and comprehensively validated – early or iterative for design influence, during design development or later for evolving life-cycle sustainment purposes!
Other Related videos:
ATML-Based Integration of Diagnostics and Test
BIT to Guided Troubleshooting
Diagnostically-informed FMECA & FTA
Realizing Interdisciplinary Design Value
DSI International, Inc. is a leading provider
of
World Class diagnostic engineering tools and services.
Topic Notes
Craig DePaul
Maintenance philosophies for fielded "systems" typically require analyses to specific Levels of Repair. Often the "bridging" between "diagnostic levels" (e.g. on-board BIT to (sub)system fault isolation to replaceable components at lower enclosure levels) map to required sustainment paradigms. On-board BIT or Health Management capabilities do not isolate failures, or impending failures (in PHM implementations). Ultimately, the "BIT-indicted" components (in accordance with the maintenance philosophy) are at "lower levels" (replaceable) of the design but still require extended failure diagnosis. Typically, this entails another or "second" level of diagnostic activity - usually "Guided Troubleshooting" beginning with second level diagnostic entry points (Using the on-board failure effects as Fault Codes). So the sustainment paradigm will influence or determine any effective diagnostic design hierarchies for the specific program. If one prefers to "expand" or "flatten" their models within the diagnostic representation(s) of their "system(s)", then this can be performed at any time during design development or during design sustainment to accommodate specific assessment criteria or technological diagnostic implementation. Software is typically treated as "inputs" within the design. Specific eXpress model "diagnostic tests" are usually included in the diagnostic model(s). Jack, you may benefit by attending the eXpress Users Group September 16th in Anaheim, CA. You can directly ask Raytheon, BAE Systems, NAVAIR, General AtomIcs, Northrop Grumman or any of the other participants how they prefer to use the model to represent their diagnostic objectives.
Indir, Thank you for your comment. The eXpress tool is not similar to any other tool, but likely other tools may appear similar to specific eXpress characteristics or any of the interrelated DSI "ISDD" tools. When eXpress was first released, beginning in 1988, it was criticized for its introduction of a graphical method to represent "information flow" by similar tool manufacturers that ultimately resorted to pursuing government set-aside SBIR or academia-based business opportunities. Because of its acceptance and reliance in industry, DSI's eXpress, contrarily, is a more comprehensive "diagnostic engineering process" tool. It's use has target many "LARGE" and complex, "BIG BOY" real world applications. The model can be used long before parts are selected (prior to FMECA, etc.) to influence the design and assess Test Coverage constraints, overlap or corroboration early in design development - a benefit when concerned about cost avoidance in design development without waiting for all parts to be formally selected or sensor placement/effectiveness to be fixed. Since the model is a "hybrid" that represents both functional and failure interrelationships, integrated assessment products (FD/FI, FMECA, FTA, etc.) are auto-generated at any point - enabling auto-Fault Code generation, assignment and management as the system is placed in the design or sustainment implementation paradigm. The small piece that is shown in this video demonstration is merely the use of an eXpress feature (DFI) that enables a "UNIQUE" capability to emulate any desired desktop interactive fault insertion interrogation. Where eXpress is a design engineering tool, the other DSI tools (shown in other videos: ie. BIT to Guided Troubleshooting: https://www.youtube.com/watch?v=23tMvFSp3Z4) are currently being used in a wide variety of environments/implementations (ATE, Production Test, on-board Reasoners, TRD, TPS, IETM, Guided Troubleshooting, etc.). The objective is to create an "agile" diagnostic design "IP" (or "twin diagnostic design DNA") that can be used to produce the traditional (and/or unprecedented new) assessment products and elegantly move to the run-time implementation or operational environment. This transition can be used with the DSI tools or most any popular/advanced diagnostic implementation tools and is a broader capability of DSI's ISDD tool suite (read each: https://www.dhirubhai.net/today/author/0_0A5LW3KlM9PhwF3tTEP_xU?trk=prof-sm). Since eXpress has a diagnostic data XML (DiagML) export capability, it has produced diagnostic data for use in the TEAMS paradigm years ago, as well. Other tool manufacturers, such as Reliasoft, Itemsoft, RLD, etc., and any/or Failure data generation tool or home-grown spreadsheet produces data that's immediately importable into eXpress. This data is cross-validated across all designs allowing for a mixed used of preferred or "independent" tools. Once the design and any other available failure or any other attribute data (including maintenance LORA, LCN, Part #, FR, Test/Repair Documentation/videos, etc.) is captured in eXpress/"RTAT", it can be reused in the current maintenance paradigms or with popular Test tools produced by many manufacturers (i.e. Marvin Test Systems, Teradyne, National Instruments, Mentor, Cadence, etc.). DSI's eXpress is often criticized for being so comprehensive, but its broad use on some of the largest and most complex systems in all branches of the US military as well as overseas, ensures the user that eXpress will be the most robust and capable diagnostic engineering tool that they've ever discovered. It will also foster many valuable design development benefits and massive sustainment cost reductions.
Senior Member at AMAC-Alumni FER
8 年Craig, this is similar to Qualtech Systems's TEAMS diagnostics models, i.e. multilevel models describing the structure, behavior, interconnections, and failure modes of the system under test (SUT). Qualtech Systems has TEAMS-Designer, an graphical tool that has ability to diagram all inputs, outputs, fault conditions, events, dependencies, and tests.