Pattern from the field · Process Manufacturing

The Control Room We Never Touched

A continuous-process plant needed its production reporting modernised. The control layer was the one thing nobody was allowed near, and that turned out to be the constraint that made the project work.

Process Manufacturing · Anonymised client pattern

The situation

A continuous-process plant, running around the clock, with a planned shutdown once a year. Everything above the control layer had aged badly: production reporting ran off a 15-year-old application, batch records were assembled by hand, and the quality team exported to spreadsheets because the reports had never quite answered their question.

The ask was to modernise all of it. The constraint arrived in the same sentence: the control layer was not to be touched. Not the PLCs, not the safety-instrumented systems, not the historian’s collection configuration. Those systems were validated, their behaviour was understood, and the plant’s licence to operate rested on them continuing to behave exactly as documented.

Some teams treat a boundary like that as an obstacle to negotiate. On this engagement it was the single most useful thing anyone said, because it settled the architecture before the first workshop.

What was really going on

The interesting discovery was that almost nothing people complained about was actually a control-layer problem.

The reports were slow because the reporting application queried the historian directly, on demand, once per user per screen. The batch records were manual because two systems disagreed about when a batch started, and a person had been quietly reconciling that difference for years. The spreadsheets existed because the reports aggregated to shift boundaries and the quality team needed them aggregated to batch boundaries, which nobody had ever changed because changing the report meant touching the application nobody wanted to touch.

Three separate complaints, none of them requiring a single change below the line. The control layer was doing its job. Everything built on top of it had been designed around the fear of going near it, and that fear had shaped fifteen years of workarounds.

What we did

We drew the boundary explicitly and then designed to it, rather than treating it as a caveat in a document nobody reads.

The historian stayed exactly as it was, collecting what it always collected. We added a read-only extraction path alongside it, pulling into a separate store on a schedule, so the reporting estate stopped querying the live historian on demand. That one change removed most of the performance complaints without altering a single tag or collection setting.

The batch-boundary disagreement we treated as a modelling problem, not an integration one. We wrote down what a batch actually meant to each system, found the two definitions genuinely differed for a real operational reason, and made the difference explicit in the new model instead of averaging it away. The person who had been reconciling it by hand became the person who reviewed the rule, which is the outcome you want.

Then we replaced the reporting application incrementally, running old and new side by side against the same extracted data until the numbers matched for a full quarter, including a month-end and a planned changeover. No production downtime was required, because nothing we built sat in the production path. The plant did not need our software to keep running, and at no point did it depend on us being finished.

This is what legacy and platform modernisation looks like when the riskiest part of the estate is off limits: you find the seam above it, and you do the work there.

What changed

The reporting estate was replaced, the manual batch-record assembly went away, and the quality team stopped exporting to spreadsheets because the reports finally aggregated the way they needed. The control layer ended the project in exactly the state it started, which was the point.

The wider lesson is about where the boundary belongs. A hard “do not touch” line around a validated control layer does not block modernisation. It clarifies it, because it forces you to be honest about which problems actually live below the line and which have simply been attributed there because nobody wanted to look. In our experience most of them are above it.

There is a caveat worth stating. This works when the control layer genuinely is doing its job. If the process control itself is the problem, this is the wrong pattern and you need specialists in that layer, which we are not. We work above the line, on the systems that surround it. Being clear about that boundary is why plants let us in at all.

If you are being told a modernisation cannot happen because the plant cannot stop, it is worth checking how much of the work actually needs it to. Talk to us and we will help you find the seam.

Anonymised, composite pattern drawn from real engagements. Figures are openly estimated, not audit-grade.

Recognise this in a system you own? We can talk it through.

The rewrite is the easy part. The diagnosis isn't.