sustainment systems division model-based diagnostics, prognostics & health management

Sustainment Systems Division

Model-based Diagnostics, Prognostics & Health Management

Use or disclosure of the data contained on this slide is subject to the restrictions in accordance with FAR 15.209 (a) and FAR 52.215-1, restriction on disclosure of use and data

VSE: Who we are and what we do…• 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

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 complex Combat 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

Big Business Capability…Small Business Agility


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


Technology Applications

Test Program Sets Health Monitoring Systems

Automated Maintenance & IETMEmbedded

Prognostics

Model

ReasonerDiagnostic Reasoning Services


5Binary File

• Can be readily hosted on any processor

Library of Functions Written in C

• Can be re-compiled to any processor environment.

GUI Client Programs• Existing client programs• New client programs

written by customer• Client programs written by

VSE

Well-Documented API

Model

ReasonerDiagnostic Reasoning Services

ArchitectureClient Applications

Health Monitoring Debrief Tech Manuals Test Programs


Applications• 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

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


Model-Based Diagnostic Technology

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.

Diagnostician

Diagnostic Knowledge Base


Fault/Symptom Matrix

Design Import / Capture

Part 1 Output 1

Output 2

Part 2 Output 1

Part 3 Output 1

Part 4 Output 1

Part 5 Output 1

Part 6 Output 1

Part 7 Output 1

Part 8 Output 1

FAULTS TESTS T1 T2 T3 T4 P1 P2

X X

X

X X

X

X

X

X X XX

XX

X

T1

T2

T3

T4

P2

Part1

Part2

Part3

Part4

Part6

Part7

Part5

Part8

1

2

P1

Test Coverage

Fault Propagation


Dynamic Reasoning Techniques

Uses all test data to collapse the field of possible faults

Cones of Evidence Produced by Pass and Fail Data

Minimum Set Covering Algorithms

Any data input: discrete, parametric, analysis, s/w or h/w, operational, observable conditions, etc.


"Dynamic" Diagnostic CapabilityTest Results can be input

… in any orderno pre-set sequence

… from any sourceoperator 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 treezeroes-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

Performance Monitor

System Sensors

Built-in TestStart-up BITPeriodic BITOperator Initiated

Test DataSNAPSHOTSSystem StatusTest RequestFault Call-OutRepair ProcedureFault RecoveryData Log

InferenceEngine

Faul ts

Test Results

Embedded System InterrogationSystem StatusFault DescriptionFault EvidenceMaintenance ProceduresTroubleshooting GuidanceRepair OptionsData LogParts Ordering


A software tool for developing fault isolation diagnostics for test program sets (TPS) or interactive electronic technical manuals (IETM).

What is the Diagnostic Profiler?

An engineer uses it to create a diagnostic database (dkb file), which communicates with the test program through a dynamic link library (dll file).

11


The Inference Engine (Runtime tool) that uses the Diagnostic Knowledge Base (DKB) for diagnostic reasoning

What is the Diagnostician?

12


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).

How they work together

13


Test Engineering Determining tests/measurements and requirements for

pass/fail status Diagnostic Engineering

Determining what fault isolation can be inferred from pass/fail data.

UUT Testing

14


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.

Traditional Diagnostic Method

Repair/Replace:U2

15


Issues Engineer must code EVERY test

path


Code Tests

Code Logic

16


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:??

17


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


18


Diagnostic Model is created for each testProfiler 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.

Diagnostic Profiler

Test1

Test 2

Test 3

Test 4

Probe 2

Ckt 1

Ckt2

Ckt3

Ckt4

Ckt6

Ckt7

Ckt5

Ckt8

Probe 1

19


Advantages Engineer codes ONLY the Test

Modules

Diagnostic Profiler

Test1

Test 2

Test 3

Test 4

Probe 2

Ckt 1

Ckt2

Ckt3

Ckt4

Ckt6

Ckt7

Ckt5

Ckt8

Probe 1

Code Tests

20


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

Diagnostic Profiler

Test1

Test 2

Test 3

Test 4

Probe 2

Ckt 1

Ckt2

Ckt3

Ckt4

Ckt6

Ckt7

Ckt5

Ckt8

Probe 1

Repair/Replace:Circuit 3

21


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

Diagnostic Profiler

Test1

Test 2

Test 3

Test 4

Probe 2

Ckt 1

Ckt2

Ckt3

Ckt4

Ckt6

Ckt7

Ckt5

Ckt8

Probe 1

Repair/Replace:Circuit 2, 3

22


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

Diagnostic Profiler

23


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

Benefits

24


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

25


Prognostics Framework


Prognostic Framework Developer

28

• 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


Diagnostics & Prognostics

Reasoning

Input DataReal-time Continuous

Monitoring

Operations Support

Maintenance Support

Alerts / Notifications

Health Assessment

Maintenance Tasks

Operations Impact

Prognostics Framework

29


Prognostics Framework Reasoning

30

Symptom Data

Symptoms

Faul

ts

X

T=0T=1

T=N

XT=2

FaultsParts

Sub-systems

1. Analyze operational data, sensor, BIT and parametric data as symptoms –

Diagnostics

2. Apply algorithms to predict & diagnose the implication of out of tolerance symptoms on each future time point defined in the model -

Prognostics

3. Identify the components and sub-systems affected by failures and predicted failures –

Health Assessment

4. Identify the functions and missions affected by failures - Mission Readiness

5. Identify the repair actions needed - Anticipatory Maintenance

Prediction Time Horizon

(4)

(5)

(1)

(2)

(3)

Maintenance Needs•Spare Parts•Repair Actions


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


Prognostics Capabilities

Symptom Data

Fau

lts

Raw Data Inputs

Perform Mathematical Calculations (Algorithms)

getTrend()

applyLeastSquaresBestFit()

verifySensorData()

Least Squares Best Fit (LSBF) Trend Extrapolation

Detect out of limit valuesOut of Range function/Percent

Out of RangeCounts per IntervalDetect sensor failureReduce sensor noiseAnalyze false alarmsApply filters (e.g., M of N)Auto-BaselineCross-correlate values to make

inferences on symptom Accumulate operating time and

stresses

Standard Functions


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

Prognostic Reasoner

GenericAPI

Health Management SystemUser Interface

Model


Input Data

Sample Prognostics Analysis Diagram

ComputeLife UsageIncrement

(LUI)

Trend and Extrapolate

LUI

Trend and Extrapolate

Margin

Compare Signals Vs Limits

Prognostic Alerts

Prognostic ReportsLife Usage Limit (End of Useful Life – 20 Hours)

OR

State & Context(Stressor)

Life UsageData

+ -+

Prior Life Usage

Updated Life Usage

Life Usage > Limit

Margin < Limit

Margin Limits-

+Margin

ConditionBased

PrognosticData

Predicted Exceedance

Prognostic Alert

Predicted RUL

Computed RUL

+

Reliability Based Prognostics Condition Based PrognosticsPrognostic Alerts

PrognosticsFrameworkReasoner

Models

and

UsageDatabase

Usage Report

Centralized Usage

Database

Health Management

System


Symptom Data

Fau

lts

Liquid/air heat exchanger

Symptom Data

Fau

lts

Glycol heater

Symptom Data

Fau

lts

Controller Assy

Symptom Data

Fau

lts

Flow Switches

Symptom Data

Fau

lts

Pump

Symptom Data

Fau

lts

Control Valve

Symptom Data

Fau

lts

Fan/Motor Assy

Symptom Data

Fau

lts

Symptom Data

Fau

lts

Power GPSSymptom Data

Fau

lts

AntennaSymptom Data

Fau

lts

TransmitterSymptom Data

Fau

lts

Data DistributionSymptom Data

Fau

lts

ReceiverSymptom Data

Fau

lts

Heat Exchange Unit

Symptom Data

Fau

lts

Symptom Data

Fau

lts

Symptom Data

Fau

lts

Radar Comms PowerSymptom Data

Fau

lts

Processors

Model Based Reasoning

“Reasoner” is software that correlates BIT data to system hierarchy to determine status

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 InputsF

aults

Symptom Data

System


36

Scope of Prognostics Model

PrognosticsFramework

Model

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

DESIGN DATA• Definition of Parts, Faults, Failure Modes, Failure

Rates, Tests, Interconnectivity and Test Coverage

MAINTENANCE SUPPORT• Repair Item Definition• Combinations of Repair Items• Repair Actions (IETM Interface)• Parts Ordering Data• PMCS Triggering and Tracking


For More Information

• Questions?• Contact us:

Mary Nolan Rebecca [email protected] [email protected](706) 569-6546 (973) 670-3754

mailto:[email protected]

mailto:[email protected]

sustainment systems division model-based diagnostics, prognostics & health management

Documents

data model

disclosure of use

test data

system health

data vse

inference of data reads

client program use functions

modelbased reasoning