Next Generation Prognostics and Health Management for Unmanned Aircraft

M. G. Walker General Atomics 16969 Mesamint Street San Diego, CA 92127 858-676-7177 [email protected] AbstractThe importance of real-time prognostics and health monitoring (PHM) for mission critical systems has increased as the users of these systems demand improved operational availability, greater reliability, increased safety, and reduced cost12. Defining requirements for PHM systems, however, has always been a challenge. Huge improvements in cost, schedule, and customer satisfaction can be realized by applying the concepts of Reliability Centered Maintenance (RCM) to the specification of PHM system requirements. Meanwhile, model-based reasoning methodologies have played an important role in the implementation of PHM systems. The authors have been applying this two-tiered approach to specifying and implementing next generation PHM systems for various mission critical system users. In this paper, we discuss the specific application of RCM focused PHM design and implementation for use in unmanned, remotely piloted aircraft (RPA). TABLE OF CONTENTS 1. INTRODUCTION .................................................................1 2. PHM SYSTEM DESIGN METHODOLOGY .........................2 3. RPA PHM REASONING ENGINE ......................................7 4. CONCLUSION ..................................................................12 REFERENCES ......................................................................13 BIOGRAPHY ........................................................................14 downtime. Such monitoring systems have increasingly attempted to provide early warning of the onset of failure, with hopes of either minimizing the costs of failure or possibly avoiding them all together. In many cases, they also strive to aid maintainers in optimizing their maintenance strategies according to the concepts of Condition Based Maintenance (CBM) [14], while also providing automated assistance in troubleshooting and isolation of root causes. These monitoring systems have traditionally gone by various names, including Fault Management (FM) systems, Integrated Systems Health Management (ISHM) systems, Health and Usage Monitoring Systems (HUMS), Condition Assessment Systems (CAS), Enterprise Health Management Systems (EHM), and Prognostic Health Management Systems (PHM). Regardless of the name, the importance of realtime health and prognostics management for unmanned vehicle systems has increased as the users of these systems demand improved operational availability, greater reliability, increased safety, and reduced lifecycle costs. For the purposes of clarity, we will refer to such systems in the paper as PHM systems. While the utility of modern PHM systems seems clear, the demonstrated benefits of such systems for use in RPA have been limited, if not disappointing. Developers of RPA PHM systems face many challenges, including difficulties in accessing the data pertinent to defining the proper set of PHM system requirements. In many cases, this data has already been generated through formal design analysis, but is not readily available to the PHM system designers. In other cases, the data is incomplete or out of context from a PHM system perspective. In still other cases, the data has not been generated principally because RPA system design processes do not properly consider the specification of PHM system design requirements as being within their scope. As a result, RPA PHM systems have either been prohibitively expensive to specify, or they end up being illspecified, providing information that is of questionable value to operators and maintainers. Additional problems arise from the fact that RPA PHM system design is often performed late in the design cycle. In the worst cases, RPA PHM systems end up being reduced in scope or eliminated altogether. The set of problems associated with specifying the right PHM system for unmanned aircraft is just the tip of the 1

1. INTRODUCTION
Users of mission critical systems expect and require such systems to accomplish their operational objectives with minimal unscheduled interruption. Meanwhile, the designers, implementers, and integrators of such systems strive to maximize reliability by identifying and minimizing any likelihood of failure. In addition, they are also interested in eliminating or minimizing potentially adverse (and costly) consequences of failure, such as loss of life, equipment damage, reduced efficiency, or harmful environmental impacts. These objectives are especially valid for unmanned vehicle systems, such as remotely piloted aircraft (RPA). In support of these objectives, advanced monitoring systems have evolved to better equip the users and maintainers with the data and information necessary to help minimize
1

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

iceberg for the RPA PHM system designer. Once a PHM system has been specified, good tools for delivering the required functionality in a timely manner are seriously lacking. Implementation cycles for traditional software development environments are costly and time-consuming, and provide limited tools for accelerating the time required to deliver tested and validated software that meets the required PHM objectives. As a result, the development of PHM systems has historically involved only limited enhancements to legacy data acquisition and monitoring systems. Usually, these enhancements involve adjustments to alarm thresholds and the inclusion of software built-intest (BIT) level warnings - all of which intend to provide earlier warning, but result in a familiar flooding of uncorrelated information from disparate sources to operators and maintainers. Optimally, RPA PHM systems should not only be instrumented for early warning of failures and predictions of component remaining useful life (RUL), but should also provide a complete connection between this information and its impact on overall aircraft health as well as the users bottom line. Recognizing the problems associated with developing fully capable PHM software systems, PHM system practitioners have leveraged advanced software technologies (collectively referred to by practitioners as reasoners) such as signal processing based event detection; artificial intelligence based correlation; expert systems based advisory systems; neural network and statistics based classifiers; neural network and statistics based state estimators; and model-based reasoning (just to name a few) for the purposes of providing supervisory level intelligence and understanding of the state of the system. Though some progress has been made in the application of these technologies within PHM systems [9][11],[16],[19], the problems associated with a lack of available toolsets and the high cost of implementation add to their limited deployment and/or performance. Additional complications arise for RPA PHM system developers when they attempt to test, validate, and deploy their PHM systems in the real world. Validating system performance using only simulated data has obvious implications, but even with the availability of historical data, many of the techniques being proposed tend to be component or sensor specific, overly sensitive to variances in process, and unable to deal with variances in component wear. These problems tend to result in a limitation of PHM system performance typically measured in terms of undetected failures (false negatives) and failures which are detected but untrue (false positives). Basically, this means that the PHM system is not only failing to deliver its promised objectives, but is in fact adding to the confusion concerning what is wrong as well as what should be done about it. So with all of the obstacles imposed on the designers and developers of RPA PHM systems, it is no wonder that they 2

have had limited success in delivering fully functional PHM systems. Fortunately, both the benefits and the demand for advanced Prognostics Health Management capabilities for RPA are too well established to be ignored forever. This paper proposes several methodological improvements for RPA PHM system design along with examples of how powerful tools can help to employ them. The combination can aid in reducing the time and cost for specifying and implementing RPA PHM system requirements, help enhance the RPA PHM system performance, and help guarantee the delivery of functionality that maps well to what is important to RPA pilots and maintainers. The next section introduces our recommended design methodology. Section 3 focuses on the utility of employing model-based reasoning for delivering RPA PHM system functionality, and introduces details of how such a PHM system has been architected by the authors specifically for RPA.

2. PHM SYSTEM DESIGN METHODOLOGY

A generic methodology for capturing RPA PHM system requirements that is based on classic RCM [7],[12] is presented in Figures 1, 4, 5 and 6. The major steps include assessing the results from design analysis; defining the system and its components (assets); performing a functional analysis and associated functional FMEA; determining the consequences of failure; identifying the associated event propagation and requirements for event detection; considering requirements for usage monitoring; gathering of conditional probability distributions and statistical likelihoods of failure; and specifying all appropriate corrective actions. A brief summary of the major subtasks of this methodology are provided in the following subsections. Integrating Design Analysis RPA PHM design typically includes a costly requirements phase that depends on data aggregated from various reliability, failure mode, and criticality analyses on components, subsystems, and systems tasks which have usually already been performed by various stakeholders at design time, but whose results are spread out between multiple organizations and often buried in formal documentation that fails to address the PHM system objectives directly. Such tasks are the realm of engineering disciplines associated with Reliability Analysis (RA), Failure Modes and Effects Analysis (FMEA), Criticality Analysis (CA), Fault Tree Analysis (FTA), Root Cause Analysis (RCA), Probabilistic Risk Assessment (PRA), and Reliability Centered Maintenance (RCM). These analyses strive to provide the data necessary to reduce risk, guarantee safety, and ensure system performance from both the user and suppliers perspective. Good references on each of these analyses are provided in [1][7]. An example of the type and format of data that might be obtained from an

existing RPA FMEA is shown in Figure 2. In a typical RPA design activity, not all design analyses are being done in an integrated sense. As a result, many of the tasks are redundant or are providing only pieces of the information needed for specifying PHM requirements. Meanwhile, the steps involved in PHM design require very similar analyses to be performed. If the data required by PHM designers is not available from the various reports and documents derived from system design, it is likely that the PHM designers will need to perform the analyses again usually a prohibitively expensive exercise. Even if the data is available, experience shows that the largest expense in time and money associated with determining PHM requirements is tied up in knowledge capture. Knowing what data is needed and where (or from whom) it can be found can be difficult and time consuming. This suggests a PHM system design methodology that aggregates the data resulting from multiple design analyses and integrates it with the specification of PHM system requirements. Since the data from these analyses is required for specifying PHM behavior, integrating the design, safety, operational diagnosis, and maintainability analyses so that the activities only have to occur once presents an opportunity for considerable cost savings. Defining the Assets The second subtask in our RPA PHM design methodology is to properly define the system assets (components) being monitored (refer to Figure 1). This task involves the review of all available and appropriate system documentation. This includes architecture diagrams, functional block diagrams, schematics, interface descriptions, system specifications, and other related design documents. It is imperative that a consistent representation of the system and its architecture is formulated. This representation serves multiple purposes, as it will: define the assets covered by the PHM system (which are 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 for communicating what is being modeled back to the designers; provide a means of determining to what detail the system should be modeled; and provide a means by which the subsystem interactions will be defined and understood. In our model-based reasoning environment, this translates to a detailed software object model over which the PHM system can reason. This is discussed in more detail in Section 3, while an example hierarchical PHM domain representation for RPA is depicted in Figure 3. Defining Functions The third step in the proposed RPA PHM design methodology involves defining the various functions of each 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 3

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 that detected failures and propagated effects of the PHM system will be specified according to what the user cares most about. This is the essence of the RCM based methodology for specifying PHM requirements: to deliver what is required, and avoid superfluous fault modeling and event detection.

Figure 2 Typical RPA FMEA Example

Figure 3 Internal aircraft object model for RPA PHM System As a result, it is increasingly important for PHM systems dedicated to monitoring how well a system is performing (as well as predicting how it is expected to perform) to take all appropriate performance metrics into account. 4 Requirements for PHM systems should therefore be based on the reliable and early detection of any failure mode that is expected to interfere with the specified functions of the monitored system(s).

Defining Functional Failures The fourth step in the RPA PHM design methodology involves the specification of each functional failure or ways the described assets functions might fail (refer to Figure 4). Like the functions, the functional failures should be written within the operational context. These include specifications for performance, quality, safety, and environmental impacts. Again, one of the benefits of defining failures according to function is that all stakeholders can share and agree on what constitutes a functional failure as well as its criticality. It will then be the list of functional failures that defines what will be (or should have been) analyzed during the Failure Modes and Effects Analysis. One of the interesting aspects of focusing on functional failures is that sometimes there are more functional failures than discrete failure modes of components. This highlights the need for consideration for separate ways that the system and its components may fail to perform their desired objectives as well as considering each individual consequence. Sometimes, component failures result in no failures of function. An RCM focused methodology helps to identify such cases where consequences are minimal, and where minimal monitoring may be acceptable. Performing FMEA The fifth step in the PHM design methodology involves the very important task of performing an FMEA. Since reliability analysis and FMEAs are likely to be required as part of system design, it is critical to try and coordinate with those responsible in order to avoid redundant effort. The specific steps for performing an FMEA are provided by many sources, including [2] and [3], and are not reproduced here. In any case, it is imperative that the FMEA be performed very early in the design cycle. If already performed, it will be important for the PHM system designers to carefully review the results. In many cases, the FMEA data will be incomplete, from a PHM design perspective, and additional analysis will be required. Among other things, FMEAs help to identify failure symptoms (effects) potentially measureable evidence that a failure is either occurring or is on its way to occurring. Resulting detection algorithms are responsible for generating failure events asynchronous conclusions drawn by the PHM system that will invoke additional PHM behavior. These events include those events typically detected by thresholds placed on measurement parameters, but also include more complicated methods of measurement and detection for falling capability (caused by deterioration, disassembly, foreign materials, or even human error), increased expectation (cases where the required or expected performance levels might change), and applied stress (cases where the asset is being subjected to stresses outside of expected or sustainable values). Identifying potentially measurable evidence also helps to specify the required 5

instrumentation as well as mechanisms for detecting failure effects. Meanwhile, advanced PHM systems require advanced tools to assist in health monitoring and event detection. As will be discussed in Section 3, model-based reasoners have demonstrated some key advanced PHM capabilities relative to monitoring usage, detecting events, propagating events, correlating events, and isolating root causes.

Figure 4 PHM Design Methodology, Part 2 Consider Consequences The next step in the RPA PHM design methodology is identifying the consequences of system and component failure (Figure 5). Consequences go beyond the measurable evidence of failure, and consider in what ways the effects will matter to the users. The consequences of system and component failures are often completely overlooked by traditional FMEA and Reliability Analysis, even though these consequences are directly related to the users bottom line. Specific consequences within the operational context such as failing to deliver to customer expectations, lost

productivity, permanent equipment damage, safety hazards, and environmental hazards are ultimately the things that the users care most about. Criticality Analysis and Probabilistic Risk Assessment both attempt to address these concerns by focusing on potential consequences and their likelihood of happening. Critical failures are those failures deemed to have dire consequences mainly from operational, safety, and environmental perspectives. Meanwhile, PRA attempts to identify likely risks and mitigate them through various means.

design cycle, thereby allowing the PHM system to incorporate appropriate correlation logic. Through the use of model-based reasoners, the authors have demonstrated the utility of employing software modeling tools that can capture fault tree logic graphically; providing for powerful propagation and graph traversal capability at run time that supports root cause fault isolation and downstream impact analysis [17]-[22]. The same tools can assist in propagating predictions of falling capability, when sufficient evidence exists. In any case, the ability to graphically model the failure modes, effects, and consequences at design time has proven to be very useful. Stakeholders can examine and validate the underlying fault models early and with ease. Any necessary changes can be made very quickly by editing the fault model graphically, and the propagation behavior can be tested quickly and validated using the same approach. Fault model-based reasoning 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 often the successful prediction of health problems requires the identification and understanding of the statistical likelihoods of failure for each of the assets being considered (see Figure 6). These likelihoods are typically specified by conditional probability distributions, and predictions involving the onset of failure require manipulations and calculations involving these probability distributions. It is important to identify tools which support this type of reasoning. The first step in managing this aspect of PHM is to identify and gather all of the necessary statistical information. This can be time consuming and costly, depending on where the information is located. In many cases, good information about the likelihood of failure for various failure modes is not available at all. It is imperative to know which of these pieces of information is actually required, based on the steps outlined above (e.g. which failures are critical, and what are the potential consequences?), so that time is spent only gathering the data that is pertinent to the users. Monitoring Age and Usage

Figure 5 PHM Design Methodology, Part 3 Defining Event Propagation There are a number of other tools that have been used to assist in the generation and understanding of FMEA data. These include Fault Tree Analysis, which organizes the data in terms of a branched tree, and provides more information on the cause and effect relationships between various failure mechanisms and symptoms. Analyses like FTA provide the RPA PHM system designer with an improved understanding of how failure events propagate through the system. It is important to obtain this knowledge early in the 6

Clearly, time varying processes are an important aspect of PHM, but they are often ignored by the design analyses used to derive specific health monitoring requirements. Typically, failure modes and estimations of component reliability are calculated as static values or distributions. In fact, the reliability of most systems and equipment are a function of age, usage, and operating mode - and therefore time. For example, the statistical distributions associated with time to failure, time to detect, time to abort, and time to repair, are constantly changing. Not only are they a function of the equipment life cycle, but they are also impacted by the stresses applied by external processes and by subsystems which share common interfaces.

likelihoods of failure be updated at run time? These questions need to be asked early in the design cycle, so that sufficient time is secured for obtaining the necessary information. Identify Proactive Tasks In the spirit of RCM, the final step in the RPA PHM design methodology calls for identifying any proactive task that can help in mitigating risk or increasing overall system reliability. The principal reason for this step is to provide a better understanding of what can be done to help mitigate failures and increase overall reliability. It is also designed to help identify the maintenance actions that are possible, necessary, or desirable. In response, the PHM system will need to be instrumented to identify at run time the need for such proactive maintenance tasks. Before proactive tasks are identified, all mechanisms for deterioration are considered and the means for performing age detection on the various assets is identified. Required instrumentation and algorithm performance is also noted. The conditional probabilities of failure that were collected in the previous steps are taken into consideration particularly with respect to measuring the remaining life of components. Figure 6 PHM Design Methodology, Part 4 Since PHM is responsible for monitoring expected equipment life, it is important that the dynamic behavior and utilization of the components and systems are also managed and monitored. As a result, it is imperative that the dynamic nature of the data be taken into account at the time the design analyses are being performed. Furthermore, the PHM software platform (particularly any reasoners) should be able to account for and reason over the dynamic nature of the state of the system. An example of how age and usage monitoring is modeled and leveraged within an RPA PHM systems is provided in Section 3. Gather Other Design Criteria In addition to the probability distributions for the various functional failures, the RPA PHM designer will need to identify other pertinent design criteria for the various assets being considered. In order to monitor usage and perform stress detection, the PHM system will probably need to know what the operational criteria for a particular asset might be. For example, the performance specifications for a vehicle engine might only make reference to sustained vehicle speeds, and not specify the preferred operating regime in terms of engine rotations per minute (rpm) or loading. What if the engine is operated at high RPM briefly, but repetitively? What is worse - long periods of stop and go, or continuous operation at high RPM? Basically, the PHM designer should be asking questions like: Under what conditions should the estimated 7 This step is also where stress detection is formulated and proposed. After stress has been assessed (which is usually a cumulative effect), the likelihoods of failure can be modified accordingly, and predictions presented with respect to functional failures and their consequences. The PHM designer then asks the question: What maintenance activities might be scheduled (and when) that might restore the 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 on the physics of failure and considers any possible algorithms that can be employed to detect the onset of failure. In the absence of physical model descriptions, empirical models and classifiers can be considered typically trained over historical data, if available. Cost analysis for the detection means is performed at this step, and the utility of oncondition monitoring is considered. If none of these techniques are possible (in other words, predicting failures is mostly impossible and/or failure rates are mostly random), then the PHM designer must consider appropriate inspection tasks that might be performed in order to help mitigate any consequences of failure. These types of maintenance tasks are usually expensive, but if the cost of failure is unacceptably high, then such tasks are appropriate.

3. RPA PHM REASONING ENGINE

Concern about mission critical system availability,

reliability, and performance has spawned the development of powerful reasoning systems that attempt to assess overall system health, detect events that suggest degradations in health, make predictions about the expected availability and RUL of the system and its functions, and provide advisement regarding the steps that can be taken to avoid any negative consequences of failure. As mentioned earlier, these systems have evolved from basic diagnostic systems to advanced Prognostics and Health Management systems. HealthMAP Based on several years of work implementing PHM systems for mission critical applications [17]-[22], the authors have implemented a framework of software components that are designed to facilitate the development of RPA PHM systems according to the methodology presented above. This framework is collectively referred to as the Health Monitoring, Assessment, and Prognostics engine (HealthMAP). Some of the key enabling technologies employed by PHM reasoners such as HealthMAP (HM) include expert system based decision support, high performance digital signal processing, Bayesian Belief Network based data fusion, neural network based function approximation, Kalman Filtering and state estimation, clustering and statistical based pattern recognition, rule-based inferencing, and model-based reasoning. A typical HealthMAP system architecture is provided in Figure 7. At the core of the architecture is a reasoning execution engine, which is itself a real-time virtual machine capable of scheduling, simulating, inferencing, trending, and multi-threaded processing. HM applications support standards-based interfacing, allowing them to communicate directly to various applications and real-time data sources. These might include sensors, transducers, programmable logic controllers (PLCs), distributed control systems (DCS), supervisory control and data acquisition systems (SCADA), data aggregation platforms, and even third-party management applications. The engine also supports interfacing to advanced dynamic modeling software executables. This is especially useful when the application requires state prediction that involves higher order mathematics. Additionally, the engine typically interfaces to any number of database systems, such as personnel, configuration, maintenance, and inventory databases, as well as historical data. An Open DataBase Connectivity (ODBC) compliant database is also typically incorporated for the archiving of the events, maintaining persistence, and managing diagnostic conclusions.

Figure 7 Typical HM System Architecture Model-based Reasoning The significance of model-based reasoning for RPA PHM is the ability to provide a supervisory understanding of vehicle state and to aid in employing policies based on mission objectives and operational context. The ability to model across the processes of an entire aircraft provides higherlevel reasoning mechanisms that take advantage of reasoning over operational context and aid in improving operational efficiency; providing situational awareness; enforcing policy and procedure; and delivering the lifecycle objectives of CBM and RCM. There are also several key benefits to applying model-based reasoning within RPA PHM system architectures relative to lowering the total cost of implementation. For more information on these benefits, please refer to [19]-[22], [24]. Domain Modeling In order to deliver effective PHM solutions, we have found it essential to create a system level object model in software over which the PHM application will reason. This model is built directly from information extracted from the PHM design process. Special care must be taken to ensure that the underlying object model is consistent with all other system specifications. Typically, a hierarchical domain model is produced that will consist of higher level system and subsystem objects, along with the specific instances of equipment that are contained in those systems. All of the domain model objects are defined according to a reusable generic class hierarchy. An example of hierarchichal domain modeling for RPA was provided in Figure 3. Examples of the reusable RPA class libraries developed for this purpose are provided in Figure 8 and Figure 9.

Systems Architecture for Condition Based Maintenance (OSA-CBM) [23], providing for Application Programming Interfaces (APIs) within each layer.

Figure 8 Generic Sensor Class Libraries for RPA PHM The object model is further enriched through the specification and population of object attributes, many of whose values will be linked to incoming real-time sensor information and configuration data. Other attributes include operating parameters such as run-time, cycle time, operating mode, etc. Also included in this model are the definitions of relationships that might exist between objects, as well as the specific (and often dynamic) instantiation of these relationships. PHM Layered Architecture In order for HealthMAP applications to deliver the full functionality specified by the PHM methodology, HM applications are organized into layers that map closely to the methodology (refer to Figure 10). Included in this architecture are five layers, including the input layer, the configuration data layer, the event detection layer, the fault management layer, the health management layer, and the prognostics layer. The layering also conforms to Open 9

Figure 9 Valve Class Libraries for RPA PHM The Input Layer includes the measurement and state information required to properly assess system health. This layer includes all validated sensor measurements, along with state information pertaining to operating modes and commands. This would include valve and switch state changes that prompt an update to the underlying domain model within the model-based reasoner. The Configuration Data Layer provides both a placeholder for, and the ability to make use of the system specific configuration data necessary for providing operational context. In addition to detailed component specifications (weight, size, volumes, temperature specifications, etc.), configuration data might also include models of expected system behavior, a priori fault likelihoods, designed-to stresses, maintenance requirements, and anticipated usage.

Figure 10 - PHM Reasoner Layered Architecture The Event Detection Layer is responsible for making comparisons between measured and expected process behavior. It is also responsible for monitoring state information and transitioning the object model according to state commands and operational modes. Similar comparisons are performed by the event detection layer relative to stress detection and maintenance monitoring. For stress detection, it is necessary for the system to perform usage monitoring, and make comparisons between detected stresses and the designed-to stresses. For maintenance monitoring, comparisons are made between monitored maintenance activity and maintenance requirements. The Event Detection layer is also the place where data driven health assessment is performed as with neural network or clustering based anomaly detection. The Fault Management Layer focuses on isolating faults and making root cause determinations, while the Health Management Layer makes a determination of health based on all available information. The Prognostics Layer takes the estimates of health and makes predictions and recommendations accordingly based on anticipated usage and criticality of consequences. FMEA and Fault Models According to any FMEA performed, the discrete number of generic 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 generic operational fault model a directed graph which depicts the cause-and-effect relationships between the components failure modes, the upstream root causes, and any of the observable (or measurable) downstream effects. For this, we use a graphical programming language that can both represent the information provided by FMEAs; as well as provide context for the software to perform propagations at run-time. Since the propagation of fault events and predictions at run-time are operational in context, some care must be taken to ensure that the FMEAs are defined with PHM objectives in mind. We have found FMEAs that are focused only on verifying reliability of design to be flat and lacking the detail necessary to capture the event propagation that occurs during operation. In the worst cases, the failure modes and the effects are identical (failure mode: function A fails; effects: function A fails). In these cases, some modification is required for translating design FMEAs and FTAs into operational fault models. An example of such 10

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

determined from modeling and simulation), or trend towards some a priori classified failure signature.

Figure 12 Example RPA PHM specific event propagation Both FMECA and RCM analysis provide a lot of the information needed for PHM event prediction and detection. According to MIL-STD-1629A, failure predictability (which is annotated as part of the FMECA-maintainability charts) should include information on known incipient failure indicators (e.g., operational performance variations) which are peculiar to the item failure trends [3]. This information, which specifies the necessary data and how it should be processed to predict the failure, aids in implementing PHM system failure prediction algorithms. Another category of information provided by FMECA and RCM is the failure detection means. This information explains how each failure mode can be detected, provides methods for resolving ambiguities (cases where more than one root cause exists per failure mode), and provides detailed information on appropriate monitoring or warning devices. Obviously, this information is directly applicable to the specification of PHM system requirements. Health and Prognostics The assessment of health and making of predictions regarding RUL are inextricably linked to system specifications and dependant on the outputs of the PHM design methodology. As a result, the health management and prognostics layers need to be exceedingly flexible. For health management, it is important that any PHM system have the ability to make use of all information relative to the state of the system. Such information includes the probability distributions for each failure mode, along with knowledge regarding how those probabilities might change dynamically when presented with excessive stresses. Stress detection implies that appropriate instrumentation is in place a requirement that should be supported by consequence and criticality analysis. HealthMAP configuration dialogs that enable reasoning about design specifications, usage monitoring, failure modes, failure rates, stress detection, and maintenance monitoring are provided in Figure 13. Health assessment and prediction may also be a function of monitored maintenance activity (or lack thereof). In one case, the likelihood of failure may increase immediately following maintenance activities, while in another case, delinquent maintenance activity might suggest a higher 11

Figure 11 RPA Fuel Subsystem Fault Model Within a PHM system, such generic fault models can be traversed by software to aid in determining the causes of abnormal system behavior. The models can also be traversed for predicting the downstream impacts. By traversing all applicable fault models upon receipt of detected events, PHM software can identify the necessary tests to diagnose and isolate the root causes of problems, ruling out other possible explanations that are not substantiated by event data. This is known in industry as Root 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, these analyses provide a powerful diagnosis and prediction capability that fully leverages the generic nature of the object and relation definitions within a model-based PHM application [17]-[22]. An example specific event propagation associated with an RPA subsystem fault is depicted in Figure 12. System-Wide Event Detection It is important to ensure that each observable event is detectable and distinguishable through a properly specified method of event detection. These events typically represent early warning of deterioration or falling capability [7]. Historically, PHM systems have focused primarily on single component health monitoring based on sensor measurement thresholding for detecting specific equipment failure modes. These techniques are expected to generate alerts and alarm notifications whenever system parameters begin to deviate from normal (as determined from statistical analysis of historical data), deviate from expected values (as

Figure 13 Configuration of PHM Model Objects for Health and Prognostics likelihood of failure. In any case, health assessment is usually accompanied by confidence indices. The degree of confidence in health assessment can be modified by additional evidence a fusion task well suited for Bayesian Belief Networks. When PHM reasoners are equipped with empirical health assessment algorithms, such as neural networks, these estimates can be used by the health and prognostics management layers to increase their confidence in 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-torepair. 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 12 other forms of electronic media useful to the maintainers.

4. CONCLUSION
The importance of real-time system health monitoring for mission critical systems like unmanned, remotely piloted aircraft has increased as the users of these systems demand improved operational availability, greater reliability, increased safety, and reduced cost. The general goal of such PHM applications is to aid in the timely detection and/or prediction of failures that might result in increased safety hazards, unscheduled shutdowns, equipment and personnel casualties, mission interruption, negative environmental impacts, loss in production, or loss of revenue. Defining requirements for PHM systems, however, has always been a challenge. Huge improvements in cost, schedule, and customer satisfaction can be realized by applying the concepts of RCM to the specification of PHM system requirements. In particular, with the application of the right set of tools and technologies, significant savings can be achieved for RPA PHM development by reusing the domain knowledge developed during design analysis at the earliest stages of system conceptual design. The implementation of integrated RPA PHM systems is greatly facilitated by advanced reasoning systems that

incorporate various advanced technologies. Tools that readily incorporate these technologies and provide access to high level reasoning capability are essential to delivering powerful PHM systems. While there are many effective tools and technologies developed by academia and industry for developing PHM systems or performing system design analysis, tools that support integrated system design and analysis and the development of run-time PHM are limited and constitute significant opportunities for PHM system designers and researchers. When coupled with model-based reasoning capability that incorporates the various required PHM system layers, we believe that full featured unmanned aircraft Prognostics and Health Management systems can be implemented faster and more efficiently.

[11] A. Patterson-Hine, G. Aaseng, G. Biswas, S. Narashimhan, K. Pattipati. A Review of Diagnostic Techniques for ISHM Applications. ISHM Forum 2005, Napa, CA [12] Reliability-Centered Maintenance Handbook, Washington D.C.: Naval Sea Systems Command, 2007. [13] J. Levitt, Preventive and Predictive Maintenance. New York, NY: Industrial Press, 2003, pp. 123135. [14] S.W. Butcher, Assessment of Condition-Based Maintenance 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, 2006 IEEE Sensors Applications Symposium, Houston, TX, April 2006 [16] M. Schoeller, M. Roemer, M. Derriso. Embedded PHM and Reasoning Integration Across Key Aerospace Vehicle Systems. Integrated Systems Health Management Conference, Cincinnati, OH, Aug. 2007. [17] Kapadia, R. SymCure: A model-based approach for fault management with causal directed graphs, Proc. Of the 16th Intl. Conf. IEA/AIE-03, pp. 582-591, Loughborough, UK [18] R. Kapadia, G. Stanley, and M. Walker, Real World Model-based Fault Management. Proc. Of the 18th Intl. Workshop on Principles of Diagnosis, Nashville, TN May 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, October 2009. [20] M. Walker, Model-based Reasoning Applications for Remote Intelligent Systems Health Management, ASNE Intelligent Ships Symposium, May 2007 [21] M. Walker, R. Kapadia, B. Sammuli, and M. Venkatesh A Model-based Reasoning Framework for Conditionbased Maintenance and Distance Support, ASNE Automation and Controls Symposium, December 2007 [22] M. Walker, R. Kapadia Integrated Design of Online Health and Prognostics Management, PHM Society Conference 2009, San Diego, CA, October 2009 [23] G. Puri, D. Boylan, R. Walter, M. Lebold. Building an OSA-CBM (Open Systems Architecture for Condition13

REFERENCES
[1] E. Elsayed, Reliability Engineering. Reading, PA: Addison Wesley, 1996. [2] D.H.Stamatis, Failure Mode and Effect Analysis: FMEA from theory to execution. Milwaukee, WI: American Society for Quality, 2003. [3] Procedures for Performing a Failure Mode, Effects, and Criticality Analysis (Military Standard), MIL-STD1629A, Washington D.C.: Department of Defense,1980. [4] D. Okes, Root Cause Analysis, Milwaukee, WS.: ASQ Quality Press, 2009. [5] NUREG-0492 Fault Tree Handbook, Washington D.C.: U.S. Nuclear Regulatory Commission, Office of Nuclear Regulatory Research,1981. [6] M. Stamatelatos, Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners, Washington D.C.: NASA, 2002. [7] J. Moubray, Reliability Centered Maintenance, Second Edition. 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 Diagnosis into a Common Process, Electronic Systems for Vehicles,Duesseldorf: VDI Verlag, 2001, pp. 53-73. [9] M. Schwabacher, K. Goebel. A Survey of Artificial Intelligence for Prognostics. AI for Prognostics Symposium, Arlington VA, 2007 [10] T. Kurtoglu, S. Johnson, E. Barszcz, J. Johnson, P. Robinson. Integrating System Health Management into the Early Design of Aerospace Systems Using Functional Fault Analysis. PHM08, Denver, CO, 2008.

based Maintenance) System. Penn State Air Force Research Labs, Nov 2006. [24] Y. Papadopoulos, Model-based system monitoring and diagnosis of failures using state charts and fault trees. Amsterdam: Elsevier Science; 2003

BIOGRAPHY
Mark G. Walker received his BSEE from Cal Poly University, Pomona (1990), and his MSCompEng from the University of Southern California, Los Angeles, CA (1994), where he specialized in machine intelligence. He has been working in applied artificial intelligence since 1989, and has coauthored three patents in the field. His work with HUMS and PHM began with BFGoodrich Aerospace, Vergennes, VT in 1996. He also spent 6 years as Senior Consulting Engineer for expert system manufacturer Gensym Corporation. He has been with General Atomics since 2004, where he is employed as Lead Engineer, Intelligent Systems. He resides with his family in Oceanside, California.

14