Next Generation Prognostics and Health Management for Unmanned Aircraft

8/4/2019 Next Generation Prognostics and Health Management for Unmanned Aircraft

1/14

1

Next Generation Prognostics and Health Management for

Unmanned AircraftM. G. Walker

General Atomics16969 Mesamint StreetSan Diego, CA 92127

[email protected]

AbstractThe importance of real-time prognostics andhealth monitoring (PHM) for mission critical systems hasincreased as the users of these systems demand improvedoperational availability, greater reliability, increased safety,and reduced cost12. Defining requirements for PHMsystems, however, has always been a challenge. Hugeimprovements in cost, schedule, and customer satisfactioncan be realized by applying the concepts of ReliabilityCentered Maintenance (RCM) to the specification of PHMsystem requirements. Meanwhile, model-based reasoning

methodologies have played an important role in theimplementation of PHM systems. The authors have beenapplying this two-tiered approach to specifying andimplementing next generation PHM systems for variousmission critical system users. In this paper, we discuss thespecific application of RCM focused PHM design andimplementation for use in unmanned, remotely pilotedaircraft (RPA).

TABLE OF CONTENTS

1.INTRODUCTION.................................................................12.PHMSYSTEM DESIGN METHODOLOGY .........................23.RPAPHMREASONING ENGINE......................................7

4.CONCLUSION ..................................................................12REFERENCES ......................................................................13BIOGRAPHY ........................................................................14

1.INTRODUCTION

Users of mission critical systems expect and require suchsystems to accomplish their operational objectives withminimal unscheduled interruption. Meanwhile, thedesigners, implementers, and integrators of such systemsstrive to maximize reliability by identifying and minimizingany likelihood of failure. In addition, they are also interestedin eliminating or minimizing potentially adverse (and costly)consequences of failure, such as loss of life, equipmentdamage, reduced efficiency, or harmful environmentalimpacts. These objectives are especially valid for unmannedvehicle systems, such as remotely piloted aircraft (RPA).

In support of these objectives, advanced monitoring systemshave evolved to better equip the users and maintainers withthe data and information necessary to help minimizedowntime. Such monitoring systems have increasingly

1978-1-4244-3888-4/10/$25.00 2010 IEEE.2 IEEEAC paper #1572, Version 2, Updated November 01, 2009

attempted to provide early warning of the onset of failure,with hopes of either minimizing the costs of failure orpossibly avoiding them all together. In many cases, theyalso strive to aid maintainers in optimizing theirmaintenance strategies according to the concepts ofCondition Based Maintenance (CBM) [14], while alsoproviding automated assistance in troubleshooting andisolation of root causes. These monitoring systems havetraditionally gone by various names, including FaultManagement (FM) systems, Integrated Systems Health

Management (ISHM) systems, Health and UsageMonitoring Systems (HUMS), Condition AssessmentSystems (CAS), Enterprise Health Management Systems(EHM), and Prognostic Health Management Systems(PHM). Regardless of the name, the importance of real-time health and prognostics management for unmannedvehicle systems has increased as the users of these systemsdemand improved operational availability, greaterreliability, increased safety, and reduced lifecycle costs. Forthe purposes of clarity, we will refer to such systems in thepaper as PHM systems.

While the utility of modern PHM systems seems clear, thedemonstrated benefits of such systems for use in RPA havebeen limited, if not disappointing. Developers of RPAPHM systems face many challenges, including difficultiesin accessing the data pertinent to defining the proper set ofPHM system requirements. In many cases, this data hasalready been generated through formal design analysis, butis not readily available to the PHM system designers. Inother cases, the data is incomplete or out of context from aPHM system perspective. In still other cases, the data hasnot been generated principally because RPA systemdesign processes do not properly consider the specificationof PHM system design requirements as being within theirscope. As a result, RPA PHM systems have either beenprohibitively expensive to specify, or they end up being ill-

specified, providing information that is of questionablevalue to operators and maintainers. Additional problemsarise from the fact that RPA PHM system design is oftenperformed late in the design cycle. In the worst cases, RPAPHM systems end up being reduced in scope or eliminatedaltogether.

The set of problems associated with specifying the rightPHM system for unmanned aircraft is just the tip of theiceberg for the RPA PHM system designer. Once a PHMsystem has been specified, good tools for delivering the


2/14

2

required functionality in a timely manner are seriouslylacking. Implementation cycles for traditional softwaredevelopment environments are costly and time-consuming,and provide limited tools for accelerating the time requiredto deliver tested and validated software that meets therequired PHM objectives. As a result, the development ofPHM systems has historically involved only limitedenhancements to legacy data acquisition and monitoring

systems. Usually, these enhancements involve adjustmentsto alarm thresholds and the inclusion of software built-in-test (BIT) level warnings - all of which intend to provideearlier warning, but result in a familiar flooding ofuncorrelated information from disparate sources to operatorsand maintainers.

Optimally, RPA PHM systems should not only beinstrumented for early warning of failures and predictions ofcomponent remaining useful life (RUL), but should alsoprovide a complete connection between this information andits impact on overall aircraft health as well as the usersbottom line. Recognizing the problems associated with

developing fully capable PHM software systems, PHMsystem practitioners have leveraged advanced softwaretechnologies (collectively referred to by practitioners asreasoners) such as signal processing based eventdetection; artificial intelligence based correlation; expertsystems based advisory systems; neural network andstatistics based classifiers; neural network and statisticsbased state estimators; and model-based reasoning (just toname a few) for the purposes of providing supervisorylevel intelligence and understanding of the state of thesystem. Though some progress has been made in theapplication of these technologies within PHM systems [9]-[11],[16],[19], the problems associated with a lack ofavailable toolsets and the high cost of implementation add totheir limited deployment and/or performance.

Additional complications arise for RPA PHM systemdevelopers when they attempt to test, validate, and deploytheir PHM systems in the real world. Validating systemperformance using only simulated data has obviousimplications, but even with the availability of historicaldata, many of the techniques being proposed tend to becomponent or sensor specific, overly sensitive to variancesin process, and unable to deal with variances in componentwear. These problems tend to result in a limitation of PHMsystem performance typically measured in terms ofundetected failures (false negatives) and failures which are

detected but untrue (false positives). Basically, this meansthat the PHM system is not only failing to deliver itspromised objectives, but is in fact adding to the confusionconcerning what is wrong as well as what should be doneabout it.

So with all of the obstacles imposed on the designers anddevelopers of RPA PHM systems, it is no wonder that theyhave had limited success in delivering fully functional PHMsystems.

Fortunately, both the benefits and the demand for advancedPrognostics Health Management capabilities for RPA aretoo well established to be ignored forever. This paperproposes several methodological improvements for RPAPHM system design along with examples of how powerfultools can help to employ them. The combination can aid inreducing the time and cost for specifying and implementingRPA PHM system requirements, help enhance the RPA

PHM system performance, and help guarantee the deliveryof functionality that maps well to what is important to RPApilots and maintainers. The next section introduces ourrecommended design methodology. Section 3 focuses onthe utility of employing model-based reasoning fordelivering RPA PHM system functionality, and introducesdetails of how such a PHM system has been architected bythe authors specifically for RPA.

2.PHMSYSTEM DESIGN METHODOLOGY

A generic methodology for capturing RPA PHM systemrequirements that is based on classic RCM [7],[12] ispresented in Figures 1, 4, 5 and 6. The major steps includeassessing the results from design analysis; defining thesystem and its components (assets); performing a functionalanalysis and associated functional FMEA; determining theconsequences of failure; identifying the associated eventpropagation and requirements for event detection;considering requirements for usage monitoring; gathering ofconditional probability distributions and statisticallikelihoods of failure; and specifying all appropriatecorrective actions. A brief summary of the major subtasksof this methodology are provided in the followingsubsections.

Integrating Design Analysis

RPA PHM design typically includes a costly requirementsphase that depends on data aggregated from variousreliability, failure mode, and criticality analyses oncomponents, subsystems, and systems tasks which haveusually already been performed by various stakeholders atdesign time, but whose results are spread out betweenmultiple organizations and often buried in formaldocumentation that fails to address the PHM systemobjectives directly. Such tasks are the realm of engineeringdisciplines associated with Reliability Analysis (RA),Failure Modes and Effects Analysis (FMEA), CriticalityAnalysis (CA), Fault Tree Analysis (FTA), Root CauseAnalysis (RCA), Probabilistic Risk Assessment (PRA), andReliability Centered Maintenance (RCM). These analysesstrive to provide the data necessary to reduce risk, guaranteesafety, and ensure system performance from both the userand suppliers perspective. Good references on each of theseanalyses are provided in [1][7]. An example of the typeand format of data that might be obtained from an existingRPA FMEA is shown in Figure 2.

In a typical RPA design activity, not all design analyses arebeing done in an integrated sense. As a result, many of thetasks are redundant or are providing only pieces of the


3/14

3

information needed for specifying PHM requirements.Meanwhile, the steps involved in PHM design require verysimilar analyses to be performed. If the data required byPHM designers is not available from the various reports anddocuments derived from system design, it is likely that thePHM designers will need to perform the analyses again usually a prohibitively expensive exercise. Even if the datais available, experience shows that the largest expense in

time and money associated with determining PHMrequirements is tied up in knowledge capture. Knowingwhat data is needed and where (or from whom) it can befound can be difficult and time consuming. This suggests aPHM system design methodology that aggregates the dataresulting from multiple design analyses and integrates itwith the specification of PHM system requirements. Sincethe data from these analyses is required for specifying PHMbehavior, integrating the design, safety, operationaldiagnosis, and maintainability analyses so that the activitiesonly have to occur once presents an opportunity forconsiderable cost savings.

Defining the AssetsThe second subtask in our RPA PHM design methodologyis to properly define the system assets (components) beingmonitored (refer to Figure 1). This task involves the reviewof all available and appropriate system documentation. Thisincludes architecture diagrams, functional block diagrams,schematics, interface descriptions, system specifications,and other related design documents. It is imperative that aconsistent representation of the system and its architecture isformulated. This representation serves multiple purposes, asit will: define the assets covered by the PHM system (whichare also the assets for which FMEA should be performed);define the underlying software object model over which the

PHM system will reason; provide a means forcommunicating what is being modeled back to thedesigners; provide a means of determining to what detail thesystem should be modeled; and provide a means by whichthe subsystem interactions will be defined and understood.In our model-based reasoning environment, this translates toa detailed software object model over which the PHMsystem can reason. This is discussed in more detail inSection 3, while an example hierarchical PHM domainrepresentation for RPA is depicted in Figure 3.

Defining Functions

The third step in the proposed RPA PHM design

methodology involves defining the various functions ofeach of the assets defined in step 1. According to RCM [7],

[22], it is important to specify asset functions according to

their operating context that is, according to their detailed

performance specifications. This may seem obvious, but

most FMEA exercises involve the analysis of equipment

failure modes that are independent of how the asset is

expected to be used. From a design perspective, basing

functional descriptions on operating context should help

alert the designer whenever desired performance exceeds or

is marginally close to the initial capability of the asset. It

also helps to ensure that all stakeholders in the design

process share a common understanding of what the asset

functions are.

Figure 1 PHM Design Methodology, Part 1

As will be seen in the following section, basing functional

descriptions on operating context also guarantees thatdetected failures and propagated effects of the PHM systemwill be specified according to what the user cares mostabout. This is the essence of the RCM based methodologyfor specifying PHM requirements: to deliver what isrequired, and avoid superfluous fault modeling and eventdetection.


4/14

4

As a result, it is increasingly important for PHM systemsdedicated to monitoring how well a system is performing(as well as predicting how it is expected to perform) to takeall appropriate performance metrics into account.

Requirements for PHM systems should therefore be basedon the reliable and early detection of any failure mode thatis expected to interfere with the specified functions of themonitored system(s).

Figure 2 Typical RPA FMEA Example

Figure 3 Internal aircraft object model for RPA PHM System


5/14

5

Defining Functional Failures

The fourth step in the RPA PHM design methodologyinvolves the specification of each functional failure orways the described assets functions might fail (refer toFigure 4). Like the functions, the functional failures shouldbe written within the operational context. These includespecifications for performance, quality, safety, andenvironmental impacts. Again, one of the benefits ofdefining failures according to function is that allstakeholders can share and agree on what constitutes afunctional failure as well as its criticality. It will then bethe list of functional failures that defines what will be (orshould have been) analyzed during the Failure Modes andEffects Analysis.

One of the interesting aspects of focusing on functionalfailures is that sometimes there are more functional failuresthan discrete failure modes of components. This highlightsthe need for consideration for separate ways that the systemand its components may fail to perform their desiredobjectives as well as considering each individual

consequence. Sometimes, component failures result in nofailures of function. An RCM focused methodology helpsto identify such cases where consequences are minimal, andwhere minimal monitoring may be acceptable.

Performing FMEA

The fifth step in the PHM design methodology involves thevery important task of performing an FMEA. Sincereliability analysis and FMEAs are likely to be required aspart of system design, it is critical to try and coordinate withthose responsible in order to avoid redundant effort. Thespecific steps for performing an FMEA are provided bymany sources, including [2] and [3], and are not reproducedhere. In any case, it is imperative that the FMEA beperformed very early in the design cycle. If alreadyperformed, it will be important for the PHM systemdesigners to carefully review the results. In many cases, theFMEA data will be incomplete, from a PHM designperspective, and additional analysis will be required.

Among other things, FMEAs help to identify failuresymptoms (effects) potentially measureable evidence thata failure is either occurring or is on its way to occurring.Resulting detection algorithms are responsible forgenerating failure events asynchronous conclusions drawnby the PHM system that will invoke additional PHM

behavior. These events include those events typicallydetected by thresholds placed on measurement parameters,but also include more complicated methods of measurementand detection for falling capability (caused by deterioration,disassembly, foreign materials, or even human error),increased expectation (cases where the required or expectedperformance levels might change), and applied stress (caseswhere the asset is being subjected to stresses outside ofexpected or sustainable values). Identifying potentiallymeasurable evidence also helps to specify the requiredinstrumentation as well as mechanisms for detecting

failure effects. Meanwhile, advanced PHM systems requireadvanced tools to assist in health monitoring and eventdetection. As will be discussed in Section 3, model-basedreasoners have demonstrated some key advanced PHMcapabilities relative to monitoring usage, detecting events,propagating events, correlating events, and isolating rootcauses.


Consider Consequences

The next step in the RPA PHM design methodology isidentifying the consequences of system and componentfailure (Figure 5). Consequences go beyond the measurableevidence of failure, and consider in what ways the effectswill matter to the users. The consequences of system andcomponent failures are often completely overlooked bytraditional FMEA and Reliability Analysis, even thoughthese consequences are directly related to the users bottomline. Specific consequences within the operational contextsuch as failing to deliver to customer expectations, lostproductivity, permanent equipment damage, safety hazards,


6/14

6

and environmental hazards are ultimately the things that theusers care most about. Criticality Analysis and ProbabilisticRisk Assessment both attempt to address these concerns byfocusing on potential consequences and their likelihood ofhappening. Critical failures are those failures deemed tohave dire consequences mainly from operational, safety,and environmental perspectives. Meanwhile, PRA attemptsto identify likely risks and mitigate them through various

means.


Defining Event PropagationThere are a number of other tools that have been used toassist in the generation and understanding of FMEA data.These include Fault Tree Analysis, which organizes the datain terms of a branched tree, and provides more informationon the cause and effect relationships between various failuremechanisms and symptoms. Analyses like FTA provide theRPA PHM system designer with an improved understandingof how failure events propagate through the system. It isimportant to obtain this knowledge early in the design cycle,thereby allowing the PHM system to incorporate appropriate

correlation logic.

Through the use of model-based reasoners, the authors havedemonstrated the utility of employing software modelingtools that can capture fault tree logic graphically; providingfor powerful propagation and graph traversal capability atrun time that supports root cause fault isolation anddownstream impact analysis [17]-[22]. The same tools can

assist in propagating predictions of falling capability, whensufficient evidence exists. In any case, the ability tographically model the failure modes, effects, andconsequences at design time has proven to be very useful.Stakeholders can examine and validate the underlying faultmodels early and with ease. Any necessary changes can bemade very quickly by editing the fault model graphically,and the propagation behavior can be tested quickly andvalidated using the same approach. Fault model-basedreasoning is described in more detail in Section 3.

Gather All Distributions

While many of the failure events defined for a system

involve simple, threshold-based detection means, very oftenthe successful prediction of health problems requires theidentification and understanding of the statistical likelihoodsof failure for each of the assets being considered (see Figure6). These likelihoods are typically specified by conditionalprobability distributions, and predictions involving the onsetof failure require manipulations and calculations involvingthese probability distributions. It is important to identifytools which support this type of reasoning.

The first step in managing this aspect of PHM is to identifyand gather all of the necessary statistical information. Thiscan be time consuming and costly, depending on where the

information is located. In many cases, good informationabout the likelihood of failure for various failure modes isnot available at all. It is imperative to know which of thesepieces of information is actually required, based on the stepsoutlined above (e.g. which failures are critical, and what arethe potential consequences?), so that time is spent onlygathering the data that is pertinent to the users.

Monitoring Age and Usage

Clearly, time varying processes are an important aspect ofPHM, but they are often ignored by the design analysesused to derive specific health monitoring requirements.Typically, failure modes and estimations of component

reliability are calculated as static values or distributions. Infact, the reliability of most systems and equipment are afunction of age, usage, and operating mode - and thereforetime. For example, the statistical distributions associatedwith time to failure, time to detect, time to abort, and time torepair, are constantly changing. Not only are they a functionof the equipment life cycle, but they are also impacted bythe stresses applied by external processes and by subsystemswhich share common interfaces.


7/14

7


Since PHM is responsible for monitoring expectedequipment life, it is important that the dynamic behavior andutilization of the components and systems are also managedand monitored. As a result, it is imperative that the dynamicnature of the data be taken into account at the time the

design analyses are being performed. Furthermore, thePHM software platform (particularly any reasoners) shouldbe able to account for and reason over the dynamic nature ofthe state of the system. An example of how age and usagemonitoring is modeled and leveraged within an RPA PHMsystems is provided in Section 3.

Gather Other Design Criteria

In addition to the probability distributions for the variousfunctional failures, the RPA PHM designer will need toidentify other pertinent design criteria for the various assetsbeing considered. In order to monitor usage and performstress detection, the PHM system will probably need to

know what the operational criteria for a particular assetmight be. For example, the performance specifications for avehicle engine might only make reference to sustainedvehicle speeds, and not specify the preferred operatingregime in terms of engine rotations per minute (rpm) orloading. What if the engine is operated at high RPM briefly,but repetitively? What is worse - long periods of stop andgo, or continuous operation at high RPM? Basically, thePHM designer should be asking questions like: Under whatconditions should the estimated likelihoods of failure beupdated at run time? These questions need to be asked

early in the design cycle, so that sufficient time is securedfor obtaining the necessary information.

Identify Proactive Tasks

In the spirit of RCM, the final step in the RPA PHM designmethodology calls for identifying any proactive task thatcan help in mitigating risk or increasing overall systemreliability. The principal reason for this step is to provide abetter understanding of what can be done to help mitigatefailures and increase overall reliability. It is also designedto help identify the maintenance actions that are possible,necessary, or desirable. In response, the PHM system willneed to be instrumented to identify at run time the need forsuch proactive maintenance tasks.

Before proactive tasks are identified, all mechanisms fordeterioration are considered and the means for performingage detection on the various assets is identified. Requiredinstrumentation and algorithm performance is also noted.The conditional probabilities of failure that were collectedin the previous steps are taken into consideration

particularly with respect to measuring the remaining life ofcomponents.

This step is also where stress detection is formulated andproposed. After stress has been assessed (which is usually acumulative effect), the likelihoods of failure can bemodified accordingly, and predictions presented withrespect to functional failures and their consequences. ThePHM designer then asks the question: What maintenanceactivities might be scheduled (and when) that might restorethe asset to its original resistance to failure?

In addition to making predictions based on changes to an

assets expected failure, the PHM designer then focuses onthe physics of failure and considers any possible algorithmsthat can be employed to detect the onset of failure. In theabsence of physical model descriptions, empirical modelsand classifiers can be considered typically trained overhistorical data, if available. Cost analysis for the detectionmeans is performed at this step, and the utility of on-condition monitoring is considered.

If none of these techniques are possible (in other words,predicting failures is mostly impossible and/or failure ratesare mostly random), then the PHM designer must considerappropriate inspection tasks that might be performed in

order to help mitigate any consequences of failure. Thesetypes of maintenance tasks are usually expensive, but if thecost of failure is unacceptably high, then such tasks areappropriate.

3.RPAPHMREASONING ENGINE

Concern about mission critical system availability,reliability, and performance has spawned the developmentof powerful reasoning systems that attempt to assess overallsystem health, detect events that suggest degradations inhealth, make predictions about the expected availability and


8/14

8

RUL of the system and its functions, and provideadvisement regarding the steps that can be taken to avoidany negative consequences of failure. As mentioned earlier,these systems have evolved from basic diagnostic systemsto advanced Prognostics and Health Management systems.

HealthMAP

Based on several years of work implementing PHM systemsfor mission critical applications [17]-[22], the authors haveimplemented a framework of software components that aredesigned to facilitate the development of RPA PHMsystems according to the methodology presented above.This framework is collectively referred to as the HealthMonitoring, Assessment, and Prognostics engine(HealthMAP).

Some of the key enabling technologies employed by PHMreasoners such as HealthMAP (HM) include expertsystem based decision support, high performance digitalsignal processing, Bayesian Belief Network based datafusion, neural network based function approximation,

Kalman Filtering and state estimation, clustering andstatistical based pattern recognition, rule-based inferencing,and model-based reasoning.

A typical HealthMAP system architecture is provided inFigure 7. At the core of the architecture is a reasoningexecution engine, which is itself a real-time virtual machinecapable of scheduling, simulating, inferencing, trending, andmulti-threaded processing. HM applications supportstandards-based interfacing, allowing them to communicatedirectly to various applications and real-time data sources.These might include sensors, transducers, programmablelogic controllers (PLCs), distributed control systems (DCS),

supervisory control and data acquisition systems (SCADA),data aggregation platforms, and even third-partymanagement applications. The engine also supportsinterfacing to advanced dynamic modeling softwareexecutables. This is especially useful when the applicationrequires state prediction that involves higher ordermathematics. Additionally, the engine typically interfaces toany number of database systems, such as personnel,configuration, maintenance, and inventory databases, aswell as historical data. An Open DataBase Connectivity(ODBC) compliant database is also typically incorporatedfor the archiving of the events, maintaining persistence, andmanaging diagnostic conclusions.

Figure 7 Typical HM System Architecture

Model-based Reasoning

The significance of model-based reasoning for RPA PHM isthe ability to provide a supervisory understanding of vehiclestate and to aid in employing policies based on missionobjectives and operational context. The ability to modelacross the processes of an entire aircraft provides higher-level reasoning mechanisms that take advantage ofreasoning over operational context and aid in improvingoperational efficiency; providing situational awareness;enforcing policy and procedure; and delivering the life-cycleobjectives of CBM and RCM. There are also several keybenefits to applying model-based reasoning within RPAPHM system architectures relative to lowering the total costof implementation. For more information on these benefits,please refer to [19]-[22], [24].

Domain Modeling

In order to deliver effective PHM solutions, we have foundit essential to create a system level object model in softwareover which the PHM application will reason. This model isbuilt directly from information extracted from the PHMdesign process. Special care must be taken to ensure thatthe underlying object model is consistent with all othersystem specifications.

Typically, a hierarchical domain model is produced that will

consist of higher level system and subsystem objects, alongwith the specific instances of equipment that are containedin those systems. All of the domain model objects aredefined according to a reusable generic class hierarchy. Anexample of hierarchichal domain modeling for RPA wasprovided in Figure 3. Examples of the reusable RPA classlibraries developed for this purpose are provided in Figure 8and Figure 9.


9/14

9

Figure 8 Generic Sensor Class Libraries for RPA

PHM

The object model is further enriched through thespecification and population of object attributes, many ofwhose values will be linked to incoming real-time sensorinformation and configuration data. Other attributes includeoperating parameters such as run-time, cycle time, operatingmode, etc. Also included in this model are the definitions ofrelationships that might exist between objects, as well as thespecific (and often dynamic) instantiation of theserelationships.

PHM Layered Architecture

In order for HealthMAP applications to deliver the fullfunctionality specified by the PHM methodology, HMapplications are organized into layers that map closely to themethodology (refer to Figure 10). Included in thisarchitecture are five layers, including the input layer, theconfiguration data layer, the event detection layer, the fault

management layer, the health management layer, and theprognostics layer. The layering also conforms to OpenSystems Architecture for Condition Based Maintenance(OSA-CBM) [23], providing for Application ProgrammingInterfaces (APIs) within each layer.

Figure 9 Valve Class Libraries for RPA PHM

The Input Layer includes the measurement and stateinformation required to properly assess system health. Thislayer includes all validated sensor measurements, along withstate information pertaining to operating modes andcommands. This would include valve and switch statechanges that prompt an update to the underlying domainmodel within the model-based reasoner. The Configuration

Data Layer provides both a placeholder for, and the abilityto make use of the system specific configuration datanecessary for providing operational context. In addition todetailed component specifications (weight, size, volumes,temperature specifications, etc.), configuration data mightalso include models of expected system behavior, a priorifault likelihoods, designed-to stresses, maintenancerequirements, and anticipated usage.


10/14

10

The Event Detection Layer is responsible for makingcomparisons between measured and expected processbehavior. It is also responsible for monitoring stateinformation and transitioning the object model according tostate commands and operational modes. Similarcomparisons are performed by the event detection layerrelative to stress detection and maintenance monitoring. Forstress detection, it is necessary for the system to performusage monitoring, and make comparisons between detectedstresses and the designed-to stresses. For maintenancemonitoring, comparisons are made between monitoredmaintenance activity and maintenance requirements. TheEvent Detection layer is also the place where data drivenhealth assessment is performed as with neural network orclustering based anomaly detection.

The Fault Management Layer focuses on isolating faults andmaking root cause determinations, while the HealthManagement Layer makes a determination of health basedon all available information. The Prognostics Layer takesthe estimates of health and makes predictions andrecommendations accordingly based on anticipated usageand criticality of consequences.

FMEA and Fault ModelsAccording to any FMEA performed, the discrete number ofgeneric failure modes can be identified for the system,subsystems, and components within a PHM domain model.From these failure modes it is possible to construct a genericoperational fault model a directed graph which depicts thecause-and-effect relationships between the componentsfailure modes, the upstream root causes, and any of theobservable (or measurable) downstream effects. For this,we use a graphical programming language that can bothrepresent the information provided by FMEAs; as well asprovide context for the software to perform propagations atrun-time. Since the propagation of fault events and

predictions at run-time are operational in context, some caremust be taken to ensure that the FMEAs are defined withPHM objectives in mind. We have found FMEAs that arefocused only on verifying reliability of design to be flat andlacking the detail necessary to capture the event propagationthat occurs during operation. In the worst cases, the failuremodes and the effects are identical (failure mode: functionA fails; effects: function A fails). In these cases, somemodification is required for translating design FMEAs andFTAs into operational fault models. An example of such

Figure 10 - PHM Reasoner Layered Architecture


11/14

11

fault models applied to RPA fuel subsystem components isshown in Figure 11.

Figure 11 RPA Fuel Subsystem Fault Model

Within a PHM system, such generic fault models can betraversed by software to aid in determining the causes ofabnormal system behavior. The models can also betraversed for predicting the downstream impacts. Bytraversing all applicable fault models upon receipt ofdetected events, PHM software can identify the necessarytests to diagnose and isolate the root causes of problems,ruling out other possible explanations that are notsubstantiated by event data. This is known in industry asRoot Cause Analysis (RCA).

Similarly, by traversing downstream in a fault model, PHM

systems can predict degradations and the onset of failure commonly referred to as Impact Analysis. Together, theseanalyses provide a powerful diagnosis and predictioncapability that fully leverages the generic nature of theobject and relation definitions within a model-based PHMapplication [17]-[22]. An example specific eventpropagation associated with an RPA subsystem fault isdepicted in Figure 12.

System-Wide Event Detection

It is important to ensure that each observable event isdetectable and distinguishable through a properly specifiedmethod of event detection. These events typically representearly warning of deterioration or falling capability [7].

Historically, PHM systems have focused primarily on singlecomponent health monitoring based on sensor measurementthresholding for detecting specific equipment failure modes.These techniques are expected to generate alerts and alarmnotifications whenever system parameters begin to deviatefrom normal (as determined from statistical analysis ofhistorical data), deviate from expected values (asdetermined from modeling and simulation), or trend towardssome a priori classified failure signature.

Figure 12 Example RPA PHM specific event

propagation

Both FMECA and RCM analysis provide a lot of theinformation needed for PHM event prediction and detection.According to MIL-STD-1629A, failure predictability(which is annotated as part of the FMECA-maintainabilitycharts) should include information on known incipientfailure indicators (e.g., operational performance variations)which are peculiar to the item failure trends [3]. Thisinformation, which specifies the necessary data and how itshould be processed to predict the failure, aids inimplementing PHM system failure prediction algorithms.

Another category of information provided by FMECA and

RCM is the failure detection means. This informationexplains how each failure mode can be detected, providesmethods for resolving ambiguities (cases where more thanone root cause exists per failure mode), and providesdetailed information on appropriate monitoring or warningdevices. Obviously, this information is directly applicableto the specification of PHM system requirements.

Health and Prognostics

The assessment of health and making of predictionsregarding RUL are inextricably linked to systemspecifications and dependant on the outputs of the PHMdesign methodology. As a result, the health management

and prognostics layers need to be exceedingly flexible. Forhealth management, it is important that any PHM systemhave the ability to make use of all information relative to thestate of the system. Such information includes theprobability distributions for each failure mode, along withknowledge regarding how those probabilities might changedynamically when presented with excessive stresses. Stressdetection implies that appropriate instrumentation is in place a requirement that should be supported by consequenceand criticality analysis. HealthMAP configurationdialogs that enable reasoning about design specifications,usage monitoring, failure modes, failure rates, stressdetection, and maintenance monitoring are provided in

Figure 13.

Health assessment and prediction may also be a function ofmonitored maintenance activity (or lack thereof). In onecase, the likelihood of failure may increase immediatelyfollowing maintenance activities, while in another case,delinquent maintenance activity might suggest a higherlikelihood of failure. In any case, health assessment isusually accompanied by confidence indices. The degree ofconfidence in health assessment can be modified byadditional evidence a fusion task well suited for Bayesian


12/14

12

Belief Networks. When PHM reasoners are equipped withempirical health assessment algorithms, such as neuralnetworks, these estimates can be used by the health and

prognostics management layers to increase their confidencein their assessments.

Maintenance Actions

One of the purposes of both the FMECA and RCM is to

identify any appropriate maintenance actions that should be

taken in the event of a predicted or detected failure.

Maintenance actions include those that are preventative,

those that are corrective, and those that involve some form

of inspection. Though maintenance actions are typically

manual operations, there are many instances where these

actions can be automated. Our PHM methodology provides

insight regarding automated maintenance actions, as well as

details about procedures, costs, and distributions of time-to-

repair. A model-based reasoning platform coupled with a

supervisory system that automates decision support can

assist in making these maintenance decisions. Such a

software platform can also be used to integrate with

Interactive Electronic Technical Manuals (IETMs) and other

forms of electronic media useful to the maintainers.

4.CONCLUSION

The importance of real-time system health monitoring formission critical systems like unmanned, remotely pilotedaircraft has increased as the users of these systems demandimproved operational availability, greater reliability,increased safety, and reduced cost. The general goal of suchPHM applications is to aid in the timely detection and/orprediction of failures that might result in increased safetyhazards, unscheduled shutdowns, equipment and personnelcasualties, mission interruption, negative environmentalimpacts, loss in production, or loss of revenue.

Defining requirements for PHM systems, however, hasalways been a challenge. Huge improvements in cost,schedule, and customer satisfaction can be realized byapplying the concepts of RCM to the specification of PHMsystem requirements. In particular, with the application ofthe right set of tools and technologies, significant savingscan be achieved for RPA PHM development by reusing thedomain knowledge developed during design analysis at theearliest stages of system conceptual design.

The implementation of integrated RPA PHM systems isgreatly facilitated by advanced reasoning systems thatincorporate various advanced technologies. Tools thatreadily incorporate these technologies and provide access to

Figure 13 Configuration of PHM Model Objects for Health and Prognostics


13/14

13

high level reasoning capability are essential to deliveringpowerful PHM systems. While there are many effectivetools and technologies developed by academia and industryfor developing PHM systems or performing system designanalysis, tools that support integrated system design andanalysis and the development of run-time PHM are limitedand constitute significant opportunities for PHM systemdesigners and researchers. When coupled with model-based

reasoning capability that incorporates the various requiredPHM system layers, we believe that full featured unmannedaircraft Prognostics and Health Management systems can beimplemented faster and more efficiently.

REFERENCES

[1]E. Elsayed, Reliability Engineering. Reading, PA:Addison Wesley, 1996.

[2]D.H.Stamatis, Failure Mode and Effect Analysis: FMEAfrom theory to execution. Milwaukee, WI: AmericanSociety for Quality, 2003.

[3]Procedures for Performing a Failure Mode, Effects, andCriticality Analysis (Military Standard), MIL-STD-1629A, Washington D.C.: Department of Defense,1980.

[4]D. Okes, Root Cause Analysis, Milwaukee, WS.: ASQQuality Press, 2009.

[5]NUREG-0492 Fault Tree Handbook, Washington D.C.:U.S. Nuclear Regulatory Commission, Office of NuclearRegulatory Research,1981.

[6]M. Stamatelatos, Probabilistic Risk AssessmentProcedures Guide for NASA Managers and

Practitioners, Washington D.C.: NASA, 2002.

[7]J. Moubray, Reliability Centered Maintenance, SecondEdition. New York, NY: Industrial Press, 1997, pp.123135.

[8]R. Brignolo, F. Cascio, L. Console, P. Dague, P. Dubois,O. Dressler, et al., Integration of Design and Diagnosisinto a Common Process, Electronic Systems forVehicles,Duesseldorf: VDI Verlag, 2001, pp. 53-73.

[9]M. Schwabacher, K. Goebel. A Survey of ArtificialIntelligence for Prognostics. AI for Prognostics

Symposium, Arlington VA, 2007

[10]T. Kurtoglu, S. Johnson, E. Barszcz, J. Johnson, P.Robinson. Integrating System Health Management intothe Early Design of Aerospace Systems UsingFunctional Fault Analysis. PHM08, Denver, CO, 2008.

[11]A. Patterson-Hine, G. Aaseng, G. Biswas, S.Narashimhan, K. Pattipati. A Review of DiagnosticTechniques for ISHM Applications. ISHM Forum2005, Napa, CA

[12]Reliability-Centered Maintenance Handbook,Washington D.C.: Naval Sea Systems Command, 2007.

[13]J. Levitt, Preventive and Predictive Maintenance.NewYork, NY: Industrial Press, 2003, pp. 123135.

[14]S.W. Butcher, Assessment of Condition-BasedMaintenance in the Department of Defense, Logistics

Managemenet Institute, McLean, VA 2000.

[15]F. Figueroa, R. Holland, J. Schmalzel, and D.Duncabage, Integrated System Health Management(ISHM): Systematic Capability Implementation, 2006IEEESensors Applications Symposium, Houston, TX,April 2006

[16]M. Schoeller, M. Roemer, M. Derriso. EmbeddedPHM and Reasoning Integration Across Key AerospaceVehicle Systems. Integrated Systems HealthManagement Conference, Cincinnati, OH, Aug. 2007.

[17]Kapadia, R. SymCure: A model-based approach forfault management with causal directed graphs, Proc. Ofthe 16th Intl. Conf. IEA/AIE-03, pp. 582-591,Loughborough, UK

[18]R. Kapadia, G. Stanley, and M. Walker, Real WorldModel-based Fault Management. Proc. Of the 18th Intl.Workshop on Principles of Diagnosis, Nashville, TNMay 2007

[19]R. Kapadia, R. Gross, M. Walker, M. Venkatesh.Health Monitoring Assessment and Prognostics(HealthMAP) for Advanced Arresting Gear System.

PHM Society Conference 2009, San Diego, CA, October2009.

[20]M. Walker, Model-based Reasoning Applications forRemote Intelligent Systems Health Management,ASNE Intelligent Ships Symposium, May 2007

[21]M. Walker, R. Kapadia, B. Sammuli, and M. VenkateshA Model-based Reasoning Framework for Condition-based Maintenance and Distance Support, ASNEAutomation and Controls Symposium, December 2007

[22]M. Walker, R. Kapadia Integrated Design of OnlineHealth and Prognostics Management, PHM SocietyConference 2009, San Diego, CA, October 2009

[23]G. Puri, D. Boylan, R. Walter, M. Lebold. Building anOSA-CBM (Open Systems Architecture for Condition-based Maintenance) System. Penn State Air ForceResearch Labs, Nov 2006.

[24]Y. Papadopoulos, Model-based system monitoring anddiagnosis of failures using state charts and fault trees.Amsterdam: Elsevier Science; 2003


14/14

14

BIOGRAPHY

Mark G. Walker received his BSEE fromCal Poly University, Pomona (1990), andhis MSCompEng from the University ofSouthern California, Los Angeles, CA(1994), where he specialized in machineintelligence. He has been working in

applied artificial intelligence since 1989, and has co-authored four patents in the field. His work with HUMSand PHM began with BFGoodrich Aerospace, Vergennes,VT in 1996. He also spent 6 years as Senior ConsultingEngineer for expert system manufacturer GensymCorporation. He has been with General Atomics since2004, where he is employed as Lead Engineer, IntelligentSystems. He resides with his family in Oceanside,California.

Next Generation Prognostics and Health Management for Unmanned Aircraft

Documents

Transcript of Next Generation Prognostics and Health Management for Unmanned Aircraft