NASA NTRS2010
Automating prelaunch diagnostics for launch vehicles offers three potential benefits. First, it potentially improves safety by detecting faults that might otherwise have been missed so that they can be corrected before launch. Second, it potentially reduces launch delays by more quickly diagnosing the cause of anomalies that occur during prelaunch processing. Reducing launch delays will be critical to the success of NASA's planned future missions that require in-orbit rendezvous. Third, it potentially reduces costs by reducing both launch delays and the number of people needed to monitor the prelaunch process. NASA is currently developing the Ares I launch vehicle to bring the Orion capsule and its crew of four astronauts to low-earth orbit on their way to the moon. Ares I-X will be the first unmanned test flight of Ares I. It is scheduled to launch on October 27, 2009. The Ares I-X Ground Diagnostic Prototype is a prototype ground diagnostic system that will provide anomaly detection, fault detection, fault isolation, and diagnostics for the Ares I-X first-stage thrust vector control (TVC) and for the associated ground hydraulics while it is in the Vehicle Assembly Building (VAB) at John F. Kennedy Space Center (KSC) and on the launch pad. It will serve as a prototype for a future operational ground diagnostic system for Ares I. The prototype combines three existing diagnostic tools. The first tool, TEAMS (Testability Engineering and Maintenance System), is a model-based tool that is commercially produced by Qualtech Systems, Inc. It uses a qualitative model of failure propagation to perform fault isolation and diagnostics. We adapted an existing TEAMS model of the TVC to use for diagnostics and developed a TEAMS model of the ground hydraulics. The second tool, Spacecraft Health Inference Engine (SHINE), is a rule-based expert system developed at the NASA Jet Propulsion Laboratory. We developed SHINE rules for fault detection and mode identification. The prototype uses the outputs of SHINE as inputs to TEAMS. The third tool, the Inductive Monitoring System (IMS), is an anomaly detection tool developed at NASA Ames Research Center and is currently used to monitor the International Space Station Control Moment Gyroscopes. IMS automatically "learns" a model of historical nominal data in the form of a set of clusters and signals an alarm when new data fails to match this model. IMS offers the potential to detect faults that have not been modeled. The three tools have been integrated and deployed to Hangar AE at KSC where they interface with live data from the Ares I-X vehicle and from the ground hydraulics. The outputs of the tools are displayed on a console in Hangar AE, one of the locations from which the Ares I-X launch will be monitored. In a previous publication, we discussed how we selected the three tools based primarily on their ability to be certified for human spaceflight and described our plans for the prototype. This abstract is due October 23, 2009, and the Ares I-X launch is currently scheduled for October 27, 2009. If this abstract is accepted, then the full paper will describe how the prototype performed before the launch. It will include an analysis of the prototype's accuracy, including false-positive rates, false-negative rates, and receiver operating characteristics (ROC) curves. It will also include a description of the prototype's computational requirements, including CPU usage, main memory usage, and disk usage. If the prototype detects any faults during the prelaunch period then the paper will include a description of those faults. Similarly, if the prototype has any false alarms then the paper will describe them and will attempt to explain their causes. Also, the paper will describe the three tools and how they are used in the prototype. It will include a description of the TEAMS models of the Ares I-X first-stage TVC and associated ground hydraulics and how we adapted the TVC model for use in real-time diagnostics. It will describe the SHINE rules used for fault detection and mode identification and the software architecture that interfaces the various pieces of existing software that are part of the prototype to one another. It will describe how we selected the sensor values and commands that were used to train the IMS model and how we optimized the number of clusters in the IMS model. It will include screen shots of the graphical display that we developed in Java to display the outputs of the three tools. Because Ares I-X data was not yet available to us while we were developing the prototype, we used historical data from the Space Shuttle's Solid Rocket Booster (SRB) TVCs and the associated ground hydraulics to train IMS and to test the entire prototype. Because most of the failure modes that we modeled have never occurred in the Shuttle we inserted simulated failures into the Shuttle data. The Ares I-X first-stage TVC is very similar to the SRB TVC and we expect the data will be very similar. After the launch, we will determine how similar the data actually is and report how any differences in the data affected the diagnostic accuracy of the prototype. Finally, although we did not get the prototype certified, we designed it in a way that it could be certified and wrote a preliminary certification plan. The paper will include a brief summary of how we considered the need for certification in the design of the prototype, how we tested the prototype before deploying it to Hangar AE, and how we would propose to get it certified if it were deployed as an operational system. The paper will conclude with a description of some of the challenges we faced and some of the lessons learned in developing and deploying the prototype.
International Space Station↗