Model-based Diagnostics, Prognostics & Health Management

1. Model-based Diagnostics, Prognostics & Health Management

2. VSE: Who we are and what we do… • Legacy System Sustainment • Reset / Remanufacture / Modernization • Full Spectrum Integrated Logistics Support • Prepositioned Stock Management • Field Support • Integrated Logistics Support Services • Warehousing / Inventory Control • Configuration Data Management • Obsolescence Management • Supply Chain / Logistics Analysis • Sustainment Systems • Health Management Systems • System Diagnostics & Prognostics • Condition & Reliability Based Maintenance • Ship Transfer / Repair / Modernization • 67 Ships to-date, Navy and Coast Guard • From complexCombat Systems upgrades –to– basic hull repair • Foreign Military Sales (FMS) support • 13 years experience, 42 Countries • Full spectrum training • Modernization / Tech Insertion • Protection / Armor / Survivability • Alternative Energy Technologies • Public Engineering Services Company • Established in 1959 • Over $860M in annual revenue • America’s #1 Defense Contractor (small) • International Presence; HQ in Alexandria, Virginia • Unique Combination of Experience and Entrepreneurial Spirit • ~2,700 employees • 40% Veterans • A Culture of Creative, Cost Effective Problem Solving • A History of Exceptional Performance Big Business Capability…Small Business Agility

3. Core Technology • Expert System using Model-Based Reasoning • Uses design-based model for diagnostics/prognostics • Deterministic model using “first principles” of design • Reasons by dynamically interpreting the inference of data • Reads test data from variety of sources • Interprets test data to assess system health, predict, detect and isolate faults • Results in health monitoring and/or diagnostics fault isolation • Can be embedded (on-line, real-time) or off-line • Can be used on new or legacy systems • Run-time reasoning engine is structured as a library of functions that are called by a client program • Use functions to create unique solutions

4. Technology Applications Test Program Sets Health Monitoring Systems Prognostics Reasoner Diagnostic Reasoning Services Model Embedded Automated Maintenance & IETM

5. Architecture Client Applications Health Monitoring Debrief Tech Manuals Test Programs • GUI Client Programs • Existing client programs • New client programs written by customer • Client programs written by VSE Well-Documented API • Library of Functions Written in C • Can be re-compiled to any processor environment. Reasoner Diagnostic Reasoning Services Model • Binary File • Can be readily hosted on any processor

6. Applications • Navy Total Ship Monitoring (TSM) Program • SPY Radar Final Power Assembly • SPY-1 Electronic Cooling Water System • Lube Oil System & Pump • Navy Battle Group Automated Maintenance Environment Program (BG-AME) • Electronic Dry Air • Low Pressure Air Compressor • Fuel Service Pump • Firemain System • F/A-18 Operator Debrief and IETM • Adaptive Training and Skills Assessment for F/A-18 Automated Maintenance Environment • Universal Data Acquisition System (UDAS) – candidate replacement for F-16 Crash Survivable Flight Data Recorder • APG-63(V1) Radar (Raytheon) Flight Data Capture for Depot Use • Mikros Systems ADSSS monitoring LCS Combat Systems • HP Indigo Digital Press Monitoring & Diagnostics (Embedded) • Joint Land Attack Cruise Missile Defense Elevated Netted Sensor System (JLENS) • Navy SPS-48E (ITT Gilfillan) • US Army IBCS System (Northrop-Grumman/Boeing) • Kiowa Warrior Mast-Mounted Sight (TPS) • A-10/KC-135 Turbine Engine Monitoring System (TPS) • C-130 Gunship Ballistic Computer (TPS) • Joint Tactical Information Distribution System (JTIDS) (TPS) • Seawolf Submarine Ship Control System (Embedded) • Avitronics Radar Warning Receiver (IETM &ATE) • FAA Wide Area Augmentation System (Embedded and IETM) • Future Combat System Gun Mount Diagnostics and Prognostics (ADAPT) (Changes operating parameters to AVOID failure situations) • NASA Remote Power Controller (Diagnostician On A Chip) Dynamic Reconfiguration Manager

7. Model-Based Diagnostic Technology Diagnostician Diagnostic Knowledge Base • Instead of depending on hard-coded troubleshooting logic trees, the Diagnostician uses a knowledge base that is derived from the design of the system! Diagnostician is a set of “reasoning” algorithms that correlate all possible faults to all possible symptoms, or test results to provide fast, effective fault isolation. • Dynamically bases its determinations based on a snapshot of current fault possibilities. • Diagnostic Profiler provides an automated development and maintenance process.

8. Fault/Symptom Matrix TESTS T1 T2 T3 T4 P1 P2 Design Import / Capture FAULTS Test Coverage X X Part 1 Output 1 P1 X Output 2 1 X X Part Part Part Part 2 Output 1 T1 1 2 3 2 X Part 3 Output 1 Part T2 X Part 4 Output 1 4 X Part 5 Output 1 Part T3 5 X X X X Part 6 Output 1 Part Part Part X X Part 7 Output 1 T4 6 7 8 X Part 8 Output 1 P2 Fault Propagation

9. Dynamic Reasoning Techniques Any data input: discrete, parametric, analysis, s/w or h/w, operational, observable conditions, etc. Uses all test data to collapse the field of possible faults Cones of Evidence Produced by Pass and Fail Data Minimum Set Covering Algorithms

10. Test Results Faults "Dynamic" Diagnostic Capability • Performance Monitor • System Sensors • Built-in Test • Start-up BIT • Periodic BIT • Operator Initiated • Test Results can be input • … in any order • no pre-set sequence • … from any source • operator observations, test instruments, data bus, data file, built-in test, automatic test equipment, system panels & displays, etc. • … as many as test source(s) can provide • not restricted to one-at-a-time to traverse fault tree • zeroes-in on cause of fault(s) • Can identify multiple faults • … Diagnostic trees follow single-fault assumption • Will always zero in on fault • … Never leaves the technician hanging • Only requests tests of diagnostic significance • … Based upon snapshot of current fault possibilities Test Data SNAPSHOTS System Status Test Request Fault Call-Out Repair Procedure Fault Recovery Data Log Inference Engine Embedded System Interrogation System Status Fault Description Fault Evidence Maintenance Procedures Troubleshooting Guidance Repair Options Data Log Parts Ordering

11. What is the Diagnostic Profiler? • A software tool for developing fault isolation diagnostics for test program sets (TPS) or interactive electronic technical manuals (IETM). • An engineer uses it to create a diagnostic database (dkb file), which communicates with the test program through a dynamic link library (dll file).

12. What is the Diagnostician? • The Inference Engine (Runtime tool) that uses the Diagnostic Knowledge Base (DKB) for diagnostic reasoning

13. How they work together • A developer uses the Diagnostic Profiler to develop and maintain a diagnostic knowledge base • The TPS/runtime environment uses the Diagnostician to access the Diagnostic Knowledge Base to: • Provide runtime information (Pass/Fail statuses) • Identify next best test, callout information, etc. (see Diagnostician Users Manual for complete list of queries).

14. UUT Testing • Test Engineering • Determining tests/measurements and requirements for pass/fail status • Diagnostic Engineering • Determining what fault isolation can be inferred from pass/fail data.

15. Traditional Diagnostic Method • Program a fixed logic tree for each test failure. • When a test fails, the program runs through the logic tree. • It measures one node signal after another, until it finds the one that is wrong. • It then calls out the components associated with that node. Repair/Replace: U2

16. Traditional Diagnostic Method • Issues • Engineer must code EVERY test path Code Tests Code Logic

17. Traditional Diagnostic Method • Issues • Each test path inherits fault coverage from the previous test. • Each test’s callouts are dependent on the previous tests that were run • A change at any point in the logic tree affects, possibly breaks tree • Updating Tree/Recoding = Rework Repair/Replace: ??

18. Traditional Diagnostic Method • Issues • Quality of logic tree is only as good as engineer that created it. • Developers have to manually track • Tree flow • Inherited coverage at each point • Manageable for smaller circuits, gets complicated for multi-page schematics

19. Diagnostic Profiler • Diagnostic Model is created for each test Profiler determines functional circuitry by using a net list. The Diagnostician clears circuits when a test passes, and suspects them when it fails. • When a test fails, the Diagnostician takes over the test sequence. • It runs tests until it cannot clear any more circuits. • It then calls out the suspected circuits (the components in them) that have not been cleared. Probe 1 Ckt Ckt Ckt Test1 1 2 3 Ckt Test 2 4 Ckt Test 3 5 Ckt Ckt Ckt Test 4 6 7 8 Probe 2

20. Diagnostic Profiler • Advantages • Engineer codes ONLY the Test Modules Probe 1 Ckt Ckt Ckt Test1 1 2 3 Ckt Test 2 4 Ckt Test 3 Code Tests 5 Ckt Ckt Ckt Test 4 6 7 8 Probe 2

21. Diagnostic Profiler • Advantages • Diagnostic Reasoning: Diagnostician always finds the best diagnostic path to take • Logic Tree is dynamic-Diagnostician finds Available/Useful tests based on test failure • Example: • Test 1 Fails • Test 2/Probe 1 are now Available/Useful Tests • Probe 1 runs, and Passes Probe 1 Ckt Ckt Ckt Test1 1 2 3 Ckt Test 2 4 Ckt Test 3 5 Ckt Ckt Ckt Test 4 6 7 8 Repair/Replace: Circuit 3 Probe 2

22. Diagnostic Profiler • Advantages • Each test has its own diagnostic model in the database • Removing/Changing/Adding a test does NOT break logic tree. • Model is re-compiled; Profiler finds best diagnostic path with new list of Available/Useful tests. • Example: • Test 1 Fails • Test 2 is now the only Available/Useful Test • Test 2 runs, and Passes Probe 1 Ckt Ckt Ckt Test1 1 2 3 Ckt Test 2 4 Ckt Test 3 5 Ckt Ckt Ckt Test 4 6 7 8 Repair/Replace: Circuit 2, 3 Probe 2

23. Diagnostic Profiler • Advantages • Test Engineering/Diagnostic Engineering are 2 separate, concurrently running processes • TPS Quality is maximized • Test Engineer focuses on Test Requirements/quality of test • Diagnostic Engineer focuses on diagnostic significance of tests

24. Benefits • Advantages • Enhanced Diagnostic Capability • Reduced Runtimes • Go-Chain runs only tests that are truly required • Many Legacy TPS have diagnostics embedded in Go-Chain • Diagnostic Database always finds best diagnostic path

25. Dynamic Reasoning Capability • Will be better than traditional diagnostics • Algorithms use pass & fail data, minimum set covering, etc., which gives better diagnostic resolution for test data • Will cost less to implement • No Hard-Coded Diagnostic Logic • Will be easier to Update & Maintain • Design Changes / Test Changes easily introduced to Knowledge Base

26. Prognostics Framework

27. Prognostic Framework Developer • Prognostics Framework is a development system for developing models for use with the PF reasoner • PF Run-time: • Condition Monitoring and Prognostic Reasoning • Reads streams of parametric data values • Correlates current values to determine system statuses • Computes prognostics algorithms based on calculation specification in model

28. Prognostics Framework Real-time Continuous Monitoring Input Data Operations Impact Operations Support Diagnostics & Prognostics Reasoning Health Assessment Maintenance Support Maintenance Tasks Alerts / Notifications

29. Prognostics Framework Reasoning • Analyze operational data, sensor, BIT and parametric data as symptoms – • Diagnostics • Apply algorithms to predict & diagnose the implication of out of tolerance symptoms on each future time point defined in the model - • Prognostics • Identify the components and sub-systems affected by failures and predicted failures – • Health Assessment • Identify the functions and missions affected by failures - Mission Readiness • Identify the repair actions needed - Anticipatory Maintenance Symptom Data (1) Symptoms T=0 Prediction Time Horizon T=1 (2) X Faults T=2 X T=N (3) Sub-systems Parts Faults (4) (5) • Maintenance Needs • Spare Parts • Repair Actions

30. Prognostics Framework • Uses design-based engineering model coupled with Inference Engine to provide a deterministic method of real-time condition assessment (“first principles of design”) • Condition Monitoring (Condition-Based Prognostics) • Condition Based prognostics monitors outliers to failure onset • Includes a variety of algorithms to identify the onset of failure conditions or anomalous operations • Life Usage Monitoring (Reliability-Based Prognostics) • Reliability Based Prognostics uses de-rated failure rates and accumulates operating time against the units. Contextual stress factors are used as a multiplier of operating time accumulated against the unit • Maturation process used to verify and adjust de-rated failure rates and stress factor weighting • Can also be applied to track preventive maintenance intervals based on operating hours, stress factors, elapsed time intervals or calendar intervals

31. Prognostics Capabilities Raw Data Inputs Standard Functions • Least Squares Best Fit (LSBF) Trend Extrapolation • Detect out of limit values • Out of Range function/Percent Out of Range • Counts per Interval • Detect sensor failure • Reduce sensor noise • Analyze false alarms • Apply filters (e.g., M of N) • Auto-Baseline • Cross-correlate values to make inferences on symptom • Accumulate operating time and stresses Perform Mathematical Calculations (Algorithms) verifySensorData() Symptom Data applyLeastSquaresBestFit() getTrend() Faults

32. Client-Server Software Architecture • Client Program (Graphical User Interface) • Design user interface as desired or use existing • Existing client programs • New client programs written by customer • Client programs written by VSE • Server (Prognostic Reasoner) • Library of functions written in C that can be re-compiled to any processor environment • Software functions serve as building blocks • Integrate building blocks to build desired functionality • Integrate building blocks to build desired functionality • Well-documented API • Prognostic Model • Binary file • Can be readily hosted on any processor Health Management System User Interface Generic API Prognostic Reasoner Model

33. OR Sample Prognostics Analysis Diagram Health Management System Prognostics Framework Reasoner Models and Usage Database Life Usage Limit (End of Useful Life – 20 Hours) Prognostic Reports Updated Life Usage Prior Life Usage + + State & Context (Stressor) Life Usage Data Compute Life Usage Increment (LUI) - + Life Usage > Limit Trend and Extrapolate LUI Predicted RUL Input Data Computed RUL Prognostic Alert Trend and Extrapolate Margin Predicted Exceedance Condition Based Prognostic Data Compare Signals Vs Limits Prognostic Alerts + Margin < Limit Margin Centralized Usage Database - Margin Limits Usage Report Prognostic Alerts Condition Based Prognostics Reliability Based Prognostics

34. System Symptom Data Faults Symptom Data Symptom Data Symptom Data Symptom Data Faults Faults Faults Faults Receiver Power Heat Exchange Unit GPS Antenna Transmitter Data Distribution Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Symptom Data Faults Faults Faults Faults Faults Faults Faults Faults Faults Faults Faults Faults Faults Faults Liquid/air heat exchanger Glycol heater Controller Assy Flow Switches Pump Control Valve Fan/Motor Assy Model Based Reasoning • System model constructed as hierarchical family of fault/symptom matrices • Fault/symptom matrix contains mapping of fault propagation andtest coverage • Reasoner correlates actual test data with faults – across hierarchy of fault/symptom matrices • Operational Data/State Data • Status Monitoring • BIT/BITE Results • Prognostic Indications • Operator/Maintainer Inputs Processors Radar Comms Power “Reasoner” is software that correlates BIT data to system hierarchy to determine status

35. Scope of Prognostics Model • DESIGN DATA • Definition of Parts, Faults, Failure Modes, Failure Rates, Tests, Interconnectivity and Test Coverage • SYSTEM DATA MANAGEMENT • Input Data Definition & Characterization • Prediction Horizons • TEST/SENSOR DATA • BIT Inputs & Mapping • Sensor Data & Mapping • Additional Data Inputs & Mapping • HEALTH MANAGEMENT • Detection Algorithms • Diagnostic Coverage • Prediction Algorithms • Fault Criticality • Input Data Processing & Filtering • Confidence Factors • MISSION SUPPORT • Mission Profile • Function Correlation to Mission Phases • Function Criticality to Mission • Immediate Operator Actions Prognostics Framework Model • MAINTENANCE SUPPORT • Repair Item Definition • Combinations of Repair Items • Repair Actions (IETM Interface) • Parts Ordering Data • PMCS Triggering and Tracking

36. For More Information • Questions? • Contact us: Mary Nolan Rebecca Norman MENolan@VSECorp.comRRNorman@VSECorp.com (706) 569-6546 (973) 670-3754