SRU-IPAL

Problem

Sulfur recovery and wastewater treatment are continuous processes. They do not stop, and the people running them work in shifts — which means the operational picture has to survive a handover. In most plants it does not. Readings live in spreadsheets, logs live in binders, and the trend that would have told you something three days early is only visible to whoever happened to be looking.

The cost is not dramatic failure. It is the slow kind: a drift nobody catches, a report assembled by hand the week it is due, an answer that takes an afternoon to reconstruct.

What it does

SRU-IPAL puts both unit families on one panel. Operators record readings against the units they actually work on; the system holds the history, surfaces the trend, and produces the reporting that was previously manual.

• One surface for two unit families. Sulfur recovery and wastewater treatment share a layout, a vocabulary, and a single login instead of two disconnected systems.
• History that outlives the shift. Readings are timestamped and attributed, so the record answers when and who without anyone reconstructing it.
• Trends over snapshots. The value of a reading is its position in a series. The interface leads with the series.
• Reporting as output, not chore. What operators already log is what the reports draw from.

Approach

The design constraint that mattered most was that this is a working tool, not a showpiece. It is opened at the start of a shift and used, so it optimises for legibility over impression: dense readouts, unambiguous units, no decoration competing with data.

Access is restricted — operational data is not public — which is why the project sits behind authentication rather than offering a public demo.

Status

Live and in use. Ongoing work is focused on reporting depth and on widening the range of units the panel covers.