Embed Size (px)
Citation preview
1
System Health Monitoringfor Space Mission Operations
David L. IversonNASA Ames Research Center
Mail Stop 269-4Moffett Field, CA 94035
Abstract— Many spacecraft provide an abundance of systemstatus telemetry that is monitored in real time by groundpersonnel and archived to allow for further analysis. In theflight control room, controllers typically monitor thesevalues using text or graphical displays that incorporateindividual parameter limit checking or simple trendanalysis. Recent developments in data mining techniquesfor anomaly detection make it possible to use the wealth ofarchived system data to produce more sophisticated systemhealth monitoring applications. These “data driven”applications are capable of characterizing and monitoringinteractions between multiple parameters and cancomplement existing practice to provide valuable decisionsupport for mission controllers.
Data driven software tools have been successfully applied tomission operations for both the Space Shuttle and theInternational Space Station. These tools have been appliedto engineering analysis of spacecraft data to detect unusualevents in the data, and to real time system healthmonitoring in the flight control room. Augmentingtraditional mission control software with advancedmonitoring tools can provide controllers with greater insightinto the health and performance of the space systems undertheir watch. Adding heuristic rule based methods thatencode system knowledge obtained from seasoned missioncontrollers can also be helpful to less experienced personnel.We will describe how such techniques have been applied toNASA mission control operations and discuss plans forfuture mission control system health monitoring softwaresystems. 1
TABLE OF CONTENTS
1. INTRODUCTION ............................................ 12. STANDARD MCC SOFTWARE TOOLS ............... 23. DATA MINING FOR MISSION CONTROL ............. 34. ORCA DISTANCE-BASED OUTLIER DETECTION. 35. IMS: INDUCTIVE MONITORING SYSTEM.......... 36. MISSION CONTROL APPLICATIONS................... 47. HEURISTIC FAULT IDENTIFICATION................. 68. SUMMARY AND FUTURE WORK...................... 7ACKNOWLEDGEMENTS ...................................... 7REFERENCES.................................................... 7BIOGRAPHY..................................................... 8
1 1 U.S. Government work not protected by U.S. copyright.
1. INTRODUCTION
Most NASA mission controllers are responsible not onlyfor operating their designated spacecraft subsystems to meetmission objectives, but also for monitoring thosesubsystems to ensure that they are operating properly. Insight into subsystem performance is provided by downlinked telemetry data produced by sensors on board thespacecraft. In the flight control room, controllers typicallymonitor these values in real time using text or graphicaldisplays that incorporate individual parameter limitchecking or simple trend analysis. Mission controlengineering support groups are available to perform more indepth analysis of collected telemetry to assess system healthor to explain unusual phenomena observed in systembehavior.
Recent developments in data mining techniques for anomalydetection make it possible to use the wealth of archivedspacecraft system data to produce advanced system healthmonitoring applications that can aid mission controllers andengineering analysts in their tasks. These “data driven”applications are capable of characterizing and monitoringinteractions between multiple parameters and can providevaluable decision support for mission controllers andengineers.
Several data driven software tools, including Orca and theInductive Monitoring System (IMS), have been successfullyapplied to mission operations for both the Space Shuttleand the International Space Station. Orca [1] is a datamining tool that searches for unusual data points, oroutliers, in multivariate data sets by calculating the distanceof each data point from neighboring points. The presence ofoutliers in spacecraft system data is of interest to missioncontrollers because they may indicate malfunctioningsystem components. The IMS tool [2] uses a data miningtechnique called clustering to analyze archived spacecraftdata and characterize nominal interactions between selectedparameters. This characterization, or model, of normaloperation is stored in a knowledge base that can be used forreal time system monitoring or analysis of archived events. Spacecraft data is compared with the nominal model builtby IMS to produce a measure of how well the data matchesthe normal behavior defined by the training data. Significant deviations from the nominal system model canalert the controller to a system malfunction or precursor to asignificant failure.
2
Supplementing current mission control software withadvanced monitoring tools, such as Orca and IMS, canprovide controllers and engineers with greater insight intothe health and performance of the space systems under theirwatch. The addition of heuristic rule based methods thatencode system knowledge obtained from seasoned missioncontrollers can also be helpful to less experienced personnel. We will discuss how these tools and techniques have beenused to complement existing NASA mission controlpractices and present plans for future mission control systemhealth monitoring software deployments using thesetechnologies.
2. STANDARD MCC SOFTWARE TOOLS
The NASA Mission Control Center (MCC) at the JohnsonSpace Center (JSC) employs a standard suite of certifiedsoftware tools in the flight control rooms. Individualcontroller disciplines may also introduce specializedsoftware tools suitable for their particular task. Coresoftware applications used for data monitoring in the MCCinclude the Information Sharing Protocol (ISP) datadistribution system, the MSK-View and RTPLOT datadisplay tools, the ELOG event logging utility, and theISPATOM computation tool.
Information Sharing Protocol (ISP)
The Information Sharing Protocol (ISP) software is adistributed system that supports real-time telemetrydistribution and messaging in the MCC. [3] It is theprimary spacecraft data feed for the mission controlconsoles. In addition to subscribing to telemetry data,console applications can publish values to ISP to allowother software applications to subscribe to and use locallycomputed results along with the real-time telemetry data.
MSK-View
MSK-View is a program used to display ISP data in atabular format defined in a screen configuration file. [4] Figure 1 shows an example of a display created with MSK-View. It allows the user to define screens withalphanumeric labels and parameter values along with simpleline drawings and screen navigation buttons. Each objecton the screen can be assigned a color as well. The MSK-View application can subscribe to an ISP data feed andprovide a text display of real-time data values as they arereceived. In addition, the display can show different userdefined text strings based on the value of a data parameter. For instance, a display element can be defined to display“HIGH” if a data value exceeds a high limit value, and“LOW” if it is less than a low limit value. This givescontrollers a way to detect off nominal parameters on theirMSK-View screens using predetermined limit values.
RTPLOT
The RTPLOT (Real Time Plot) program provides a meansof plotting real-time or played-backed data accessed via theISP data feed. [5] RTPLOT subscribes to the ISP data
Figure 1: Sample MSK-View Screen
stream and provides line plots of one or more parametervalues over time. (Figure 2). It allows the user to defineupper and lower limits for each plot, which appear as reddashed lines on the plot display. The plot can be iconifiedto a smaller size to conserve screen real estate. If aparameter on an iconified plot falls outside a limit, the plotname on the icon will be displayed in red to alert controllersof the out of limit condition. RTPLOT also includesroutines to estimate future data values by fitting lines orparabolic curves to previously plotted data.
Figure 2: Sample RTPLOT Display
ELOG
The ELOG event logger program provides a means toautomatically log telemetry change events in real time. [6] ELOG defines an event as a comparison (greater than, equalto, etc.) between an ISP parameter value and a constant. When the comparison is true for a specified amount of time,the event is logged to a file and displayed in a list on thecontroller’s screen. The display will show the time the
3
event occurred and a text message describing the event witha user selected background color. (Figure 3) The controllercan acknowledge that they have seen an event in the ELOGdisplay by clicking on that list item with the mouse. Anacknowledged event will be displayed in reverse video. Audible alarms can be associated with critical events toattract the controller’s attention. Like RTPLOT, the ELOGdisplay windows can be iconified to save screen space. AnELOG icon will show the name of the window, a count ofhow many events have been logged in that window, and acount of how many of those events have not beenacknowledged.
Figure 3: Sample ELOG Display
ATOM
The Advanced Tool of Math (ATOM) is a software tool thatallows controllers to define and execute real timecomputations on telemetry data by specifying equationsusing ISP parameter identifiers. [7] ATOM will parse theuser defined equation, subscribe to the required real-timetelemetry values, calculate results as new data arrives, andpublish the results back to ISP for use by otherapplications. ATOM provides common mathematical andcomparison functions, including square root, logarithmic,and trigonometric functions. It can also performcalculations on time series data, such as average, standarddeviation, and future value prediction using a least squaresline fit. Program flow control is provided by IF, WHILE,and CASE statements. Basic data structures like arrays andstacks can also be used in the calculations.
3. DATA MINING FOR MISSION CONTROL
NASA maintains years of archived Space Shuttle andInternational Space Station (ISS) telemetry data in theOperational Data Reduction Complex (ODRC) at theJohnson Space Center. This archive can provide a wealth ofinformation about the behavior of individual telemetryparameters and how those parameters correlate to each other. The standard suite of mission control software tools is ableto convey current data and system status to controllers, buttakes little advantage of information available on thehistoric behavior and interactions of the parameters.
Methods from the field of data mining are useful foranalyzing and characterizing the type of data found in theODRC archive. In particular, recent developments in datadriven anomaly detection techniques can process the data tofind unusual events, or outliers, in data for a given
subsystem. These anomaly detection techniques can alsoautomatically analyze archived nominal system data tocharacterize normal system performance. Comparingincoming real-time data to that nominal model can let theuser know if the current system behavior differs fromprevious system performance.
One powerful feature of these data mining techniques is theability to simultaneously analyze multiple parameters. Thisallows them to discover and model interactions betweenrelated parameters that might be difficult to notice whenmonitoring those parameters individually.
4. ORCA DISTANCE-BASED OUTLIER DETECTION
Orca is a data mining tool that analyzes multivariate datasets. [1] It uses a nearest neighbor approach to outlierdetection. Each group of parameter values is considered avector that defines a point in a multi-dimensional vectorspace. For each point in the data set, Orca locates otherpoints in the data set that are closest to that point, called thepoint’s nearest neighbors. Distance between points ismeasured with the Euclidean distance measure. Theprogram outputs a score for each point representing theaverage distance to the nearest k neighbors in the data set. The value of k is specified by the user. Points that have alarger average distance to their nearest neighbors than mostother points in the data set are considered outliers. TheOrca program is able to find outliers within a single dataset, or compare one data set with another to determinewhich points in the first data set are unusual in comparisonto the second set.
One approach to using Orca with spacecraft telemetry is toform data vectors by grouping a number of concurrentparameter values collected from sensors on a givenspacecraft subsystem and searching for outliers among thosevectors. For instance, vectors could be formed fromtemperature, pressure, and fuel flow rates in a rocket engine. Values collected simultaneously at regular time intervalsfrom each of the sensors would form the data set. An Orcaanalysis of this data set can locate data from time periodsduring the engine firing that display unusual characteristicscompared with the rest of the data. Those anomalous datapoints may be symptoms of engine malfunctions, such as afaulty pressure regulator or an incorrect fuel-oxidizer mixtureratio.
5. IMS: INDUCTIVE MONITORING SYSTEM
The Inductive Monitoring System (IMS) is a tool that usesa data mining technique called clustering to extract modelsof normal system operation from archived data. [2] LikeOrca, IMS works with vectors of data values. IMS analyzesdata collected during periods of normal system operation tobuild a system model. It characterizes how the parametersrelate to one another during normal operation by findingareas in the vector space where nominal data tends to fall.
4
These areas are called nominal operating regions andcorrespond to clusters of similar points found by the IMSclustering algorithm. These nominal operating regions arestored in a knowledge base that IMS uses for real-timetelemetry monitoring.
During system monitoring, IMS reads real-time or archiveddata values, formats them into the predefined vectorstructure, and searches the knowledge base of nominaloperating regions to see how well the new data fits thenominal system characterization. For each input vector,IMS returns the distance that vector falls from the nearestnominal operating region. Data that matches the normaltraining data well will have a deviation distance of zero. Ifone or more of the data parameters is slightly outside ofexpected values, a small non-zero result is returned. Asincoming data deviates further from the normal system data,indicating a possible malfunction, IMS will return a higherdeviation value to alert users of the anomaly. IMS alsocalculates the contribution of each individual parameter tothe overall deviation, which can help isolate the cause of theanomaly.
6. MISSION CONTROL APPLICATIONS
The Orca and IMS tools have both been applied in NASAmission control to support real-time telemetry monitoring
and engineering analysis of mission data. In support of theJSC Mission Evaluation Room (MER) engineering analysisactivity, the tools were applied to data from the SpaceShuttle Wing Leading Edge Impact Detection System(WLEIDS) to find potential impact signatures. In theInternational Space Station (ISS) flight control room theyhave been used to build real-time health monitoring applications for the ISS Control Moment Gyroscopes.
Space Shuttle Wing Leading Edge Impact Detection System
The Shuttle WLEID system was developed in response tothe loss of the Columbia orbiter on the STS-107 mission. During the launch of STS-107 a piece of foam shed fromthe Shuttle external fuel tank struck the leading edge of theorbiter’s left wing, compromising the thermal protectionsystem. This damage resulted in the tragic loss of vehicleand crew during reentry due to overheating and failure of theinternal wing structure. [8]
The WLEIDS consists of 132 single axis accelerometersmounted along the length the orbiter leading edge wingspars. (Figure 4) During launch, the accelerometers collectdata at a rate of 20 KHz and store that data onboard forsubsequent downlink to Mission Control. Within 6 to 8hours of launch, summary files containing periodic sub-samples of the data collected by each accelerometer are downlinked to the MER for analysis to find potential impactsignatures. This analysis must be performed within 24 to48 hours of the launch so the results can be used to schedule
5
detailed on-orbit wing leading edge inspections usingcameras mounted on the Shuttle robotic arm.
The basic WLEIDS analysis is performed by MERengineers by visually examining three dimensional graphsof the summary data that show accelerometer location andvibration magnitude along a time axis. (Figure 5). Theanalysts search the graphs for localized peaks among thenormal vibration signals caused by the Shuttle engines andaerodynamic forces. Unusual peaks in the data might havebeen caused by an impact on the wing leading edge. Whenpossible impact events are identified, a half second of rawdata collected by the affected accelerometer at that time isdownloaded for more thorough analysis.
Figure 5: Sample WLEIDS Summary File Graph
The Orca and IMS tools have been used to support theWLEIDS analysis on three Shuttle launches. The goal is toprovide a quick initial scan of the WLEIDS summary filesto locate unusual points and help focus the MER analysts’efforts. For each accelerometer sensor, vectors were formedfrom concurrent values collected from that sensor and sevennearby sensors. Orca is used to search for outliers withinthe data collected during the current launch. Prior to thelaunch, IMS was used to analyze normal data from previouslaunches to characterize typical vibration patterns for eachgroup of accelerometers. Data from the current launch iscompared to this characterization to identify unusualvibration patterns that might have been caused by impactevents.
To gauge the effectiveness of the data mining tools, wecompared Orca and IMS results to visual WLEIDSsummary file analysis performed by MER engineers on theSTS-115 launch of Space Shuttle Atlantis. The analystsclassify the events they identify as critical, probable, or
questionable based on the likelihood that the data signaturewas caused by an impact. Their analysis of the STS-115launch WLEIDS summary data produced 6 critical events,23 probable events, and 2 questionable events. The Orcaanalysis placed all critical events in the top 50 outliers. IMS identified 334 interesting events, divided nearly evenlybetween the two wings. Those events included all 6 criticalevents, 18 of 23 probable events, and all of the questionableevents found by the MER analysts. Most of the anomaliesidentified by Orca and IMS that were not noted by theanalysts could be eliminated as normal global vibrationsthat shook the entire vehicle. Additionally, during alllaunches where Orca and IMS have been used, the toolsidentified several lower energy vibration signatures that didnot stand out in the visual data inspection. These eventswere investigated with raw WLEIDS data downloads fromthe affected sensors. Fortunately all of the potential impactevents identified in the WLEIDS summary data were shownto be the result of non-damaging phenomena, such asaerodynamic events or sensor data spikes, and all missionsconcluded with safe and uneventful reentry and landing.
ISS Control Moment Gyroscopes
The International Space Station (ISS) Control MomentGyroscope (CMG) attitude control system consists of fourlarge gyroscopes, each mounted in a gimbal system that canrotate the CMG about the two axes perpendicular to thegyroscope spin axis. (Figure 6) The CMGs operate as non-propulsive attitude control devices that exchangemomentum with the ISS through induced gyroscopictorques.
Figure 6: ISS Control Moment Gyroscopes
As they have aged some of the CMGs have degradedenough to malfunction and require replacement. A failedCMG1 was replaced with a new unit in July 2005, and afaulty CMG3 was replaced in August 2007. Given theirhistory, the ISS Attitude Determination and Control Officer(ADCO) flight controllers are interested in detecting earlysymptoms of degradation in the CMGs. A deployment of
6
data driven system health monitoring applications in theISS flight control room is assisting with that task.
Working with the ADCO flight controllers, 13 CMGparameters were selected for real time monitoring. Theseparameters include CMG vibration, bearing temperatures,rotation speed, gimbal rates, electrical current, and ISSrotation rates, along with rates of change of the temperaturesand electrical current. Archived data collected over a periodof 10 months for CMG1, 2, and 4 was analyzed. Six weeksof available data for the recently installed CMG3 wasanalyzed for that unit. The data was sampled at a 1 Hz rateand formed into vectors of 13 values. Each CMG wasanalyzed individually to capture its unique characteristics.
The first operation with the CMG data was to remove anyanomalies from the archived data. This was accomplishedby searching for outliers within each data set using the Orcatool. Data records with significant deviations relative to theremainder of the data for that CMG were removed. Thesedeviations were typically caused by data corruption or minoranomalies in CMG operation. Once the archived CMG datahad gone through this cleaning process, the remainingnominal data was used by IMS to build a monitoringknowledge base for each CMG.
The IMS monitoring application was integrated with theISP data server software to access real-time telemetry in theISS flight control room. Four IMS processes, one perCMG, are run on the ADCO flight control console toprovide continuous monitoring. Once per second, whendata is available, each IMS process will query theappropriate CMG knowledge base and return the amount ofoverall deviation, if any, from the nominal training data. Itwill also return the contribution of each individualparameter to any deviation to aid in isolating the source ofthe deviation. These results are published back to the ISPdata stream for access by other software applications.
Figure 7: IMS Detection of a CMG Electronics Fault
The ADCO controllers have developed RTPLOT displays tograph the IMS CMG results in real-time on their controlconsole. These graphs read the IMS results from the ISPserver and show the amount of total IMS deviation overtime for each CMG (Figure 7), along with the individualparameter contributions. The controllers also use ELOGrules to notify them when IMS detects unusual CMGbehavior. The IMS output acts as a decision aid, alerting
the controllers to CMG anomalies and prompting them toinvestigate unusual occurrences. It also serves as a crosscheck for atypical events detected by other means. Forexample, when a controller sees a pattern on their telemetrydisplay that is different from what they expect, they cancheck the IMS output for that time period to see if this typeof behavior had occurred previously. If IMS showsminimal deviation during that time, then the current datamatches previous behavior seen in the nominal IMS trainingdata. If IMS shows a significant deviation during that time,further investigation may be warranted.
7. HEURISTIC FAULT IDENTIFICATION
The IMS processes monitoring the ISS Control MomentGyroscopes can alert the controllers when a CMG deviatesfrom typical behavior, but the basic IMS routines do notidentify the fault that caused the deviation. The ADCOcontrollers would like to receive explicit alerts in the eventof particular CMG faults when possible. Some of thesefault signatures are straightforward enough to encode asmonitoring rules and integrate with the IMS consolesoftware.
One relatively common, but recoverable, CMG fault is atransient condition in the CMG electronics assembly thatthe ADCO controllers call an “EA Fault”. This event ischaracterized by a brief electrical current spike beyond athreshold value accompanied by the setting of an error bit inthe electronics assembly. A routine was added to the IMSmonitoring software that watches for the occurrence of anappropriately sized current spike and the setting of theelectronics assembly fault bit within a short time window. If both of these events occur within that time span, IMSwill set an EA Fault bit on the ISP data stream to alert thecontrollers of the incident.
Another less frequent incident is a Loss of Comm fault thatoccurs when a CMG experiences problems with the networkconnection to the ISS computer responsible forcommanding the unit and gathering CMG sensor data. Thisevent is automatically recognized by ISS on board faultdetection logic, which initiates a recovery procedure toreestablish the connection. This recovery procedure resultsin transmission of several specific status messages to theground controllers. Watching for these status changesallows the IMS Loss of Comm detection routine to detectwhen the event has occurred and set the appropriate alert bitin the ISP data server. The routine also detects when asuccessful recovery has occurred and resets the alert bit.
Although these heuristic fault identification abilities do notcover all possible fault scenarios, they add value byenabling the controller to quickly determine the cause ofthese more common anomalies. This can be particularlyuseful for less experienced controllers that may not haveseen these particular fault signatures. Additional faultdetection routines may be incorporated in the future.
7
8. SUMMARY AND FUTURE WORK
Through practical application, it has been demonstrated thatdata driven system health monitoring applications can beuseful in a space mission operations setting. Manyspacecraft have extensive archives of telemetry data availablethat can be advantageously exploited by data miningmethods. Two data mining tools, Orca and the InductiveMonitoring System, have been used to analyze data fromthe Space Shuttle and International Space Station to searchfor anomalous data points that could be indications of afault or damage to the spacecraft. Providing information onpossible system anomalies in a timely manner providescontrollers and mission support engineers with helpfuldecision support and enables more efficient and effectiveexecution of their duties. The inclusion of faultidentification routines further simplifies their tasks.
These initial tool deployments in the NASA JSC missioncontrol center have demonstrated the utility andeffectiveness of data driven system health monitoringmethods in two disciplines, but the applications are notlimited to just these examples. There are many areas withrich archived data repositories where these and similartechniques can be applied. Mission controllers from severalISS disciplines, including power management, thermalcontrol, and life support, have expressed interest in similarsystem monitoring tools. Now that the software has beenintegrated with the mission control data systems, expansionof the capability is primarily a matter of identifying relevantparameters to monitor and performing the archived dataanalysis. Work is beginning now to develop monitoringcapability for ISS thermal control systems.
Eventually we plan to develop tools that allow missioncontrollers to build their own data driven monitoringapplications. They will specify which parameters tomonitor, what time periods to include in the nominaltraining data, and any computations that should beperformed on the raw telemetry data. The tool set willretrieve the desired archived training data, remove spuriousdata points using outlier detection, and build a newmonitoring knowledge base and an appropriate monitoringapplication configuration to run on their control console.
A useful enhancement to the current monitoring softwarewould be the ability to automatically detect operating modechanges in the monitored system and switch to a targetedmonitoring knowledge base developed specifically for thatmode. For instance, the ISS is flown in differentorientations and configurations during different missionphases. The behavior of the CMGs can differ in the variousconfigurations. Rather than building one large knowledgebase per CMG that covers all cases, as in the currentdeployment, a separate knowledge base could be built fromarchived data collected during each ISS configuration, thenconsulted for real-time monitoring when the ISS is in thatconfiguration. This would provide more accurate andefficient monitoring capability.
Another application of data driven monitoring to explore isthe use of supervised learning methods to help identify faultsignatures. If examples of fault behavior are available in thearchived data, supervised learning algorithms, such asdecision tree or support vector machine based techniques,may be able to analyze the data and distinguish betweendifferent types of fault behavior and normal operation. Ifthe monitored system exhibits unusual behavior, faultcharacterizations from the supervised learning algorithmcould help controllers identify the cause of the anomaly. These techniques could allow automated fault identificationin cases that are too complex to be encoded in heuristicrules.
ACKNOWLEDGEMENTS
The author would like to thank the following collaboratorswho directly supported and contributed to the developmentand deployment of the mission control software described inthis paper: From NASA Ames Research Center – RickAlena, Charles Lee (EASI), Dawn McIntosh, MarkSchwabacher, Lilly Spirkovska, and William Taylor. FromNASA Johnson Space Center – Tatiana Dobrinskaya (USA),Ann Esbeck (USA), Tammy Gafka, Joshua Johnson, KeithMartin (TSI), and Charles McCann.
REFERENCES
[1] Stephen D. Bay and Mark Schwabacher, “MiningDistance-Based Outliers in Near Linear Time withRandomization and a Simple Pruning Rule,” Proceedingsof The Ninth ACM SIGKDD International Conference onKnowledge Discovery and Data Mining, 2003.
[2] David L. Iverson, “Inductive System Health Monitoring,”Proceedings of The 2004 International Conference onArtificial Intelligence (IC-AI04), Las Vegas, Nevada, June2004. CSREA Press.
[3] Mission Control Center Platform Services SystemInformation Sharing Protocol User’s Guide, NASADocument CSOC-JSC-UG-002098, April, 2002.
[4] MSK-View Users Guide, Version 3.4, September 1997.
[5] RTPLOT Reference Guide, NASA Operations DocumentJSC-26101, August 1998.
[6] ELOG Reference Guide, NASA Operations DocumentJSC-26101, July 1998.
[7] Adam Dershowitz, Advanced Tool of Math (ATOM)Users Guide, Version 02.03.06, July 2006.
[8] Columbia Accident Investigation Board Report, Volume1, August 2003.
8
BIOGRAPHY
David Iverson has worked as acomputer engineer in the IntelligentSystems Division at the NASA AmesResearch Center for more than twodecades. During most of that time, hehas been involved in integrated systemhealth management (ISHM) for
spacecraft, aircraft, and scientific payload systems. He hasinvestigated several aspects of this field includingreasoning from system fault models, model basedmonitoring and diagnosis, and data driven techniques forsystem monitoring. Most recently, he has developed andapplied the Inductive Monitoring System data drivenanomaly detection software. He is the NASA Ames projectlead for deployment of data driven monitoring for JSCmission control applications. He received his B.S. from theUniversity of Puget Sound where he studied ComputerScience, Mathematics, and Physics. He also holds an M.S.in Computer Science from Stanford University.
