Power Guard 360

AI predictive maintenance for a gas turbine plant: live Arduino sensors, Random Forest failure prediction with SHAP explanations, and one-tap engineer dispatch on a 3D plant map.

Comment

Inspiration: why we chose this problem

We built Power Guard 360 around one of the newest energy projects in the industry: Chevron's Project Kilby.

On 22 June 2026, Chevron's subsidiary Energy Forge One announced a 20-year agreement with Microsoft to supply about 2.67 gigawatts of power to Microsoft's AI data centers. The project is being developed with Engine No. 1 in West Texas and built in phases. It will run on natural gas from the Permian Basin, using GE Vernova and Solar Turbines (Caterpillar) gas turbines. A final investment decision is expected at the end of 2026, with first power expected in 2028.

What makes Kilby different is that the gas turbines are the main power source, not a backup. The AI data center runs directly on them. So if a turbine fails without warning, the data center loses power. AI workloads also swing quickly, which puts extra stress on the turbines.

That gave us our question: how do you keep those turbines healthy, and catch a failure before it happens? Most plants still fix machines on a schedule or after they break. We wanted a system that watches every turbine all the time, predicts failures, explains them in plain words, and gets the right engineer moving, while a human stays in charge of the decision. We chose this problem because it was the newest and most real challenge in Chevron's world, and exactly where machine learning can help.

Power Guard 360 is a student hackathon project inspired by Project Kilby. It is not affiliated with or endorsed by Chevron or Microsoft, and it was not built on their data.

What it does

Power Guard 360 is a predictive maintenance system for a gas turbine plant that powers an AI data center, shown as a live 3D digital twin.

  • You watch the plant run: 8 gas turbines with heat recovery boilers and stacks, a steam hall, an air-cooled condenser, a switchyard, a battery yard, the AI data center and the gas metering skid, with power flowing live between them.
  • A real sensor board drives one turbine. An Arduino measures a hand-spun motor, air temperature and air quality, and posts readings twice a second. GT-08 runs on those live readings; the other seven turbines replay real machine histories from the AI4I 2020 dataset.
  • A machine learning model scores every turbine every second. Model 1 gives the failure risk (0 to 1). Model 2 names the failure type: heat dissipation, power, overstrain or tool wear. SHAP gives the three readings that pushed the risk up or down the most.
  • The manager gets a recommendation, not an alarm storm. Each flagged turbine gets one recommendation with the reasons and a suggested check. Declining it silences that issue until the unit reads normal again.
  • Gas leak detection: if air quality at gas metering drops below 70% of clean air, a "possible gas leak" recommendation appears. In the demo, you breathe on the sensor and it shows up within seconds.
  • The human decides: the manager declines, or requests maintenance with their own notes and dispatches a chosen engineer. Nothing reaches an engineer before that.
  • The engineer's phone buzzes with the job. They accept, walk to the asset (shake the phone to walk), and the repair starts on arrival, all live on the 3D map.
  • Ask the plant: a Gemini copilot answers questions such as "Why is GT-08 flagged?" from the live plant data and the model's verdict.

How we built it

Machine learning (Python, scikit-learn, XGBoost, SHAP): trained on the AI4I 2020 Predictive Maintenance Dataset (UCI): 10,000 readings, only 339 failures (3.4%), with six inputs: machine type, air temperature, process temperature, rotational speed, torque and tool wear. We used an 80/20 stratified split with a fixed seed. The 2,000 test rows (68 failures) were touched once, at the end. We compared Logistic Regression (baseline), Random Forest and XGBoost, each with and without class weighting, using GridSearchCV with 5-fold stratified cross-validation, ranked by PR-AUC. The pipeline includes a custom cleaner for messy sensor values ("25 C", "1,551 rpm", "N/A", -999), Celsius to Kelvin conversion, range checks, and physics features (temperature gap, mechanical power, wear x torque). The winner, Random Forest, is wrapped in CalibratedClassifierCV (sigmoid, chosen by out-of-fold Brier score). Its alert threshold (0.614) was picked by F1 on out-of-fold training predictions only. Model 2 is a multilabel MultiOutputClassifier trained only on real failures, because one failure can have two causes. Explanations come from an exact SHAP explainer over the whole calibrated pipeline, so baseline + contributions = the risk shown. Everything is saved as one joblib bundle.

Results on the 2,000 held-out readings: precision 0.964, recall 0.779 (53 of 68 failures caught, 2 false alarms), F1 0.862, PR-AUC 0.899 (guessing scores 0.034), ROC-AUC 0.983, Brier score 0.0070. Model 2: macro-F1 0.93 on real failures (heat 1.00, power 1.00, overstrain 0.94, tool wear 0.78). Random Forest won because in cross-validation the Logistic Regression baseline reached only PR-AUC 0.50. Failures here come from combinations of conditions, such as high torque at low speed, that a straight line cannot capture. XGBoost came close (0.88 to 0.89), but Random Forest was highest and most stable across folds.

ML service (FastAPI, Uvicorn, pandas, NumPy): api.py loads the bundle and scores every running turbine each second. The JSON response keeps three parts separate: inputs (with their source: measured, simulated or dataset replay), model output (class, risk, threshold, failure types, top 3 SHAP reasons), and rule-based output (alert level, dispatch yes/no, suggested check).

Plant server (Node.js, TypeScript, ws, Zod): receives sensor posts with token authentication, validates every reading with Zod, runs the plant, calls the ML service, and pushes live state to every screen over WebSockets. If the ML service stops, a small decision tree trained on the same dataset takes over after 15 seconds.

Shared plant engine (TypeScript): one pure function runs on the server, the website and the phone, so every screen shows exactly the same plant.

3D twin and manager website (React 19, TypeScript, Vite, three.js, React Three Fiber, drei, postprocessing, Zustand): a procedural combined-cycle plant, clickable assets with live panels, a maintenance board and a copilot panel. Deployed on Vercel.

Engineer app (Expo, React Native, Expo Router): job alerts with expo-notifications and expo-haptics, shake to walk with expo-sensors, and a site map. It shares the website's plant engine and palette.

Hardware (Arduino UNO R4 WiFi, C++): Grove Base Shield, Grove Barometer (SPA06-003) for air temperature, an R280 motor spun by hand for rotational speed, and a Grove Air Quality Sensor v1.3 at the gas metering skid. Torque is derived from speed at constant power. Process temperature follows air temperature + 10 K with a lag, and tool wear counts up while the shaft turns. If a sensor fails, that reading replays from the dataset instead of sending a fake zero.

AI copilot (Google Gemini): answers from live plant data and the model's verdict. It switches to the next Gemini Flash model when one is slow or errors.

Tests and tooling: pytest (24 ML tests: cleaning, input validation, JSON output, SHAP additivity, API), Vitest (plant engine, server, copilot), TypeScript checks, oxlint, a board simulator that replays recorded failures, and a one-command deploy.sh that starts the whole demo on one laptop.

Challenges we ran into

  • Failures are rare. At 3.4%, a model that always says "fine" is 96.6% accurate and useless. We used class weighting, stratified splits and PR-AUC instead of accuracy.
  • Keeping the test honest: model, settings, calibration and threshold were all chosen on training data only, never on the test set.
  • An overconfident model: isotonic calibration made the model "100% sure" on 51 test readings. We added a rule that isotonic must beat sigmoid by at least 5%. Sigmoid won, and test PR-AUC rose from 0.861 to 0.899.
  • Tool wear failures are close to random. In this data a tool breaks somewhere between 200 and 240 minutes, so failing and healthy readings look alike. Lowering the threshold did not help, so we report it openly.
  • Venue Wi-Fi blocked the board. We moved everything onto a phone hotspot, switched from an ESP32 to the UNO R4 WiFi, reused one connection, and kept the board live through dropped posts and glitching sensors.
  • 3D performance: a texture leak and too many draw calls caused CPU and GPU spikes. Merging static parts cut draw calls from 594 to 122, and we capped the view at 30 fps.
  • False alarms from load swings: our first forecast alarmed on normal load changes. We replaced it with the trained model and a human approval step.
  • GPS doesn't work indoors at a demo, so engineers walk by shaking the phone.

Accomplishments that we're proud of

  • A working loop from a real sensor to prediction, explanation, recommendation, manager decision, engineer dispatch and repair.
  • A model that catches 78% of failures with only 2 false alarms in 2,000 readings, chosen and tested honestly.
  • Every prediction explains itself: the manager sees why, not just a red light.
  • A live gas leak demo you can trigger with your own breath.
  • Winner, Best Pitch/Demo at CodeRED: Orion.

What we learned

  • With rare events, accuracy lies. PR-AUC, precision and recall tell the real story.
  • A risk score is only useful if it is calibrated, and calibration can backfire if you don't check it.
  • Being clear about limits (tool wear, random failures, synthetic data) builds more trust than a perfect-looking number.
  • Most integration bugs between hardware, Python, Node.js, web and mobile come from one thing: agreeing on a single clear data format.

What's next for Power Guard 360

  • Retrain on real turbine data. AI4I 2020 is a simulated milling machine, not a turbine, and our miniature hardware doesn't represent industrial operating conditions.
  • Time-series features (how readings change over time) to catch tool wear failures.
  • A time-series database for history, plus model drift tracking.
  • Email, SMS and voice alerts, and connecting to real work-order systems.

Built With

Share this project:

Updates

Submission history