Fault Prognostication is a 3-year effort that started in 2017. The goal is to teach an underwater drone how to forecast failures before they happen. I like aggressive time-tables, so here it is:
- 2017: collect nominal and fault data
- 2018: develop fault prediction hardware for the drone
- 2019: test the system at sea.
Fault-detection is usually done by determining the range of normal operation and calling a fault when system variance exceeds a threshold. For example, impedance < max impedance is used for ground-fault detection, and altitude < min altitude to detect a minimum altitude fault. The value of the detection threshold is determined using either statistical criteria, for example signal – mean > 3 sigma, or heuristically.
Threshold-based fault-detection is effective in industrial applications where systems operate around a set point in a structured environment, but not in mobile robotics where the wider range of operation and lack of structure often leads to high rate of false alarms and missed detections.
The poor performance is tied to two related problems: lack of prediction (prognostication), and lack of ability to estimate impact (cost-estimation). The figure below illustrates this:
- The figure on the left shows a drone attempting a survey near the seabed. As it tries to level off into straight-and-level flight, the drone temporarily exceeds the minimum altitude threshold, and as a result calls a minimum altitude fault. Because it lacks the ability to predict (prognostication), the vehicle can’t tell that crossing the threshold is in fact safe (cost-estimation).
- The figure on the right shows the same drone, this time crossing the minimum altitude threshold at too steep an angle and crashing into the seabed at a result. Because it lacks the ability to predict and to estimate impact, the vehicle cannot respond in time to avoid the crash.
We observed a similar problem during mass-shifter startup: the mass-shifter wheels tend to flatten when idle, and as a result the velocity overshoots and causes false-alarms during startup. Because the algorithm lacks the ability to predict (prognostication), the mass-shifter can’t tell that crossing the threshold during startup is actually safe (cost-estimation).
Prognostication and cost-estimation are complementary: prognostication tells us that the temperature will be 20°F tomorrow, and cost-estimation tells us that this is normal in January in Boston or hazardous in July/Phoenix. Without prognostication, cost-estimation can only assess the immediate health of the system. Without cost-estimation, prognostication can only predict where the system will be.
The focus for 2018 will be prognostication. Cost-estimation will be addressed in 2019.
The prognostication approach we propose is to use algorithms developed for Time-Series (TS) forecasting. A number of TS forecasting techniques –Auto-Regressive Moving Average, Hidden Markov Models, State-Space Reconstruction by Time-Delay Embedding, Recursive Neural Networks, LSTM networks, etc. – have been successfully developed for weather forecasting, speech recognition, stock-market prediction, chaotic system prediction, etc. Our objective will be to find an algorithm that works on fault-detection. State of the art in PHM is a combination of UKF and Monte-Carlo.
The figure below illustrates the forecasting workflow, using the minimum altitude detection problem as an example. Similar to a weather forecast, the algorithm calculates the probability distribution function of altitude at different moments in the future. Cost estimation then uses this pdf to forecast the probability of collision Pcollision(t) = P(altitude <0; time t). As explained above, prognostication and cost-estimation are distinct but closely related: prognostication computes the probability distribution function versus time; cost estimation takes this as input and outputs a cost function (probability of collision). 0>