-
-
DewaterIQ dashboard showing synthetic centrifuge telemetry, operating indicators, equipment trends, and fault-scenario flags.
-
Simulated dewatering workflow covering feed pumping, polymer conditioning, centrifuge separation, and source/destination pit levels.
-
Live NVIDIA Nemotron inference through Nebius Token Factory, delivering advisories alongside an offline rule-based baseline for comparison.
Inspiration
DewaterIQ was inspired by conversations with an experienced U.S. drilling-rig solids-control operator who explained how centrifuge and dewatering performance still depends heavily on operator experience.
Operators continuously interpret centrifuge RPM, motor current, torque, feed rate, pit levels, mud properties, pH, polymer dosage, and wet/dry cut quality. Much of this information is viewed live and is not preserved in a structured historian, making it difficult to reproduce good operating conditions, investigate abnormal events, or support less-experienced operators.
The goal became clear: create a read-only intelligence layer that can capture process behavior first, learn from historical patterns, and assist operators without modifying proprietary or rented centrifuge controls.
What it does
DewaterIQ is an AI-assisted monitoring and decision-support platform for oilfield solids-control and dewatering operations.
The MVP:
- simulates centrifuge and process telemetry in Embedded C99,
- tracks variables such as RPM, flow, current, torque, pit level, pH, mud weight, vibration, and bearing temperature,
- detects deterministic process and equipment anomalies,
- stores historical operating data,
- visualizes current and historical behavior in a Streamlit dashboard,
- and uses an NVIDIA open-source AI model through Nebius Token Factory to provide contextual diagnostics and operator recommendations.
DewaterIQ is intentionally advisory-only. It does not send commands to centrifuges, VFDs, pumps, valves, or chemical-dosing systems.
How we built it
The system is divided into several layers:
- Embedded C99 for equipment/process simulation, telemetry generation, and basic deterministic anomaly detection.
- GCC for compiling the embedded-style C implementation.
- MQTT-style telemetry architecture for industrial data transport.
- Python for backend integration, historian logic, analytics, and AI orchestration.
- SQLite for the hackathon historian.
- Streamlit for the monitoring dashboard.
- NVIDIA open-source AI models through Nebius Token Factory for diagnostics and explainable operator recommendations.
The simulator includes multiple scenarios such as stable operation, increasing centrifuge load, pump-flow degradation, wet-cut/chemistry issues, intentional volume loss, pit imbalance, bearing problems, VFD degradation, and power-fault events. A key architectural decision was to keep machine-specific observations separate from universal control logic. Field observations such as specific current ranges, RPM values, or pH ranges are treated as configurable, site-specific evidence rather than hard-coded industrial limits.
Challenges we ran into
The biggest challenge was defining the system without inventing access to real industrial signals. The field equipment is proprietary, expensive, and often rented, so direct controller integration cannot be assumed. Communication protocols, VFD interfaces, and external signal access still require field validation. Another challenge was distinguishing actual process intent from apparent anomalies. For example, a rig may deliberately operate in a mode that loses fluid volume in order to make room for base oil or chemical treatment. A naïve model could incorrectly classify that as poor recovery.
The solution was to explicitly model operating modes and keep the MVP read-only.
Accomplishments that we're proud of
- Built a complete Embedded C99 centrifuge/process simulator.
- Successfully compiled the simulator using GCC.
- Created multiple realistic oilfield operating scenarios.
- Implemented process and equipment anomaly detection.
- Integrated the simulator with a Python backend and historian.
- Built a Streamlit monitoring dashboard.
- Preserved strict read-only safety boundaries.
- Designed the architecture so field telemetry can later replace synthetic telemetry without rewriting the entire application.
- Structured the project around real field interviews rather than a purely hypothetical use case.
What we learned
- The biggest lesson was that oilfield dewatering is not a single-variable control problem.
- Machine behavior depends on the interaction of:
- centrifuge RPM,
- feed flow,
- mud weight,
- chemistry,
- pH,
- solids content,
- pit levels,
- operating mode,
- current,
- torque,
- and output quality.
We also learned that operator intent is critical. The same sensor values can mean different things depending on whether the objective is barite recovery, polishing, dewatering, normal fluid recovery, or intentional volume reduction.
This reinforced the need for a historian-first, machine-specific approach before attempting autonomous control.
What's next for DewaterIQ
The next step is to replace synthetic telemetry with authorized, read-only field data. Future development includes:
- integrating real centrifuge, flow, level, and chemistry signals,
- validating machine-specific operating envelopes,
- adding similar-run retrieval,
- correlating torque/current with cut quality,
- improving output-quality labels using laboratory measurements,
- optimizing chemical consumption,
- adding condition-monitoring and predictive-maintenance analytics,
- and eventually evaluating supervised PLC-based automation after safety and process validation.
The long-term vision is a vendor-neutral retrofit intelligence platform that can sit above existing solids-control equipment without replacing OEM safety or control systems.
Log in or sign up for Devpost to join the conversation.