← Outer RimMISSION 03 · PLANT ENERGY

Chemical engineering · Data modelling · Dashboard design

Plant Energy

A resin plant knows its energy bill but not why it moves. I modelled four months of meter data in SQL, taught it what "normal" looks like for every meter, and designed a dashboard that tells an engineer, in one sentence, where the money is going.

RoleSolo: data + design
StackSQLite, Python, JS
Data120 days · 2 shifts
StatusWorking prototype

All data is simulated. Nothing comes from a real plant. The findings below are what the dashboard detects in that simulation.

The problem

Energy is one of a chemical plant's biggest controllable costs, and most of it goes to a handful of utilities: boilers, air compressors, chillers and cooling towers. The usual dashboard shows total kWh and gas use against last month. That number moves for good reasons (more production, a hot week) and bad ones (a fouled boiler, a leak), and the chart can't tell them apart. So nobody acts on it.

The question I designed for: of the change this month, how much is real waste, where is it, and what is it worth?

A real data model, not a spreadsheet

The data lives in a SQLite star schema: dimensions for date, shift, equipment and energy type, and fact tables for energy, production and steam. Each boiler's "production" is the steam it makes, so its efficiency can be measured the same way as a production line's.

SQL views do the thinking:

  • Each meter's usual use, from a regression on production and weather fitted on a baseline period. "Usual" is the yardstick everything is compared to.
  • Daily energy per tonne (specific energy consumption), the number plant engineers actually track against target.

The build script uses only Python's standard library: it simulates the readings, loads the schema, fits the baselines and exports what the dashboard needs.

Findings written by the data, not by me

Every insight sentence on the dashboard is generated from the data. A change-point test looks for a lasting shift between actual and usual use, then the page says it in plain words, with a cost attached. In the simulated plant it finds:

  • Boiler 2 needed 18% more gas to make the same steam on night shifts since 5 October. That is worth about $4.8k a month, roughly 45% of the gap to target.
  • The air compressors keep running while the line is stopped, the classic signature of compressed-air leaks.
  • The packaging line has used 7–9% less since 19 September, a saving worth keeping.
  • A one-off dryer spike that went back to normal: no action, just a note for the shift log.
  • Use that the weather fully explains, flagged as reassurance so nobody wastes a day chasing it.

A good insight names the equipment, the shift, the date it started and what it costs.

A wording detail that matters

An early draft said a boiler "used 18% more steam". Boilers make steam; they use gas. An engineer reading that would stop trusting the page, so the sentence says "needed 18% more gas to make the same steam".

The dashboard

  • Four headline numbers against target.
  • Period and area filters, and a cost or energy toggle, because finance and engineering read the same chart differently.
  • Daily energy per tonne against target.
  • A drill-down from area to equipment to a single meter, showing actual against usual.
  • Day against night comparison, which is how the Boiler 2 problem becomes visible.
  • A split by energy type: electricity and natural gas.
Plant Energy · live demoOpen full screen ↗

What I'd do next

  • Connect to a plant historian and re-fit the baselines each quarter.
  • Let engineers confirm or dismiss a finding, and track the savings that follow.
  • Add steam-trap and condensate return data, a common hidden loss.