Inspiration
A watched pot never boils. An unwatched oilfield water tank can shut down production. We called our project Watchpot because operators need a clear view of trouble before a tank reaches its automatic shut-in limit.
EOG Resources' Beat the Shutdown challenge made the problem concrete: oil production also produces salt water. When a pump fails, that water keeps entering the tank, and the operator has limited time to respond. We wanted to turn scattered readings into a clear answer: what is wrong, how long can we wait, and what should we do?
What it does
Watchpot is an operator-console prototype for the sponsor's supplied network, operating assumptions, and recorded telemetry. Our target workflow connects three tasks: identifying pipeline leaks and pump problems, estimating time until automatic shut-in after a pump failure, and presenting a practical response with its estimated implementation cost.
The interface is designed around a clickable network, system, and facility hierarchy. Operators can move from a broad overview to the affected pump, tank, pipeline, or well without losing the incident list. Planned controls include sorting by priority, recency, or response cost; filtering ongoing and resolved incidents; and exporting computed events.
For a pump failure, the response may involve trucks, selective well shut-in, a combination, or accepting automatic shutdown. Leaks and degrading pumps call for inspection. Recommendations are advisory: Watchpot does not control equipment or rewrite the recording. Implementation and integration are in progress; this description captures the scope we are building toward.
How we built it
We split the work between a Java backend and a plain HTML, CSS, and JavaScript frontend, served by the Java webserver. The backend owns the analysis and event recommendations; the frontend owns navigation, visualization, and readable action details.
Our integration design sends the selected dataset folder's GitHub URL to the backend and receives structured event objects. A separate network response supplies equipment relationships for the diagram. We keep API adaptation in one place so the interface can evolve alongside the backend.
The visual design uses a replaceable theme and an interactive equipment schematic. We prioritized useful information and direct navigation over decorative dashboard elements or an unnecessary chatbot.
Challenges we ran into
Our first challenge was narrowing an ambitious industrial-console concept to the sponsor's actual model. Discovering the supplied repository let us focus on interpreting data rather than inventing equipment and operating assumptions.
Another challenge is that a stopped pump can be normal: pumps cycle on and off with tank level. Slow degradation also needs to be distinguished from sensor noise. For response planning, several failing facilities can compete for the same trucks, so a locally attractive recommendation may not be feasible across the system.
On the frontend, we had to distinguish equipment specifications from live readings and avoid displaying costs or schedules that the API does not actually supply.
Accomplishments that we're proud of
We have defined a focused operator workflow, worked through the sponsor's data model, and designed a frontend/backend boundary that supports parallel development. Our interface concept connects incidents directly to equipment and puts the suggested action beside the evidence and shutdown deadline.
What we learned
The most useful screen is the one that helps someone make the next decision. A fault label alone is not enough: an operator also needs context, urgency, and a feasible response.
We also learned to treat recorded telemetry as information available up to a specific moment. Practice answer keys belong in offline validation, and replay must not use future readings.
What's next for Watchpot
Finish and test the backend/frontend integration, validate detection and recommendations against the practice datasets, and check behavior on an unfamiliar network. We also want to refine keyboard and touchpad navigation, responsive layouts, event export, and missing-data states. Once the core flow is reliable, sensor trends and comparisons between alternative plans are natural extensions.
