An Optimiser Needs Somewhere Safe to Fail

Most people never meet an optimiser directly. An optimiser is just an algorithm that searches for the settings and parameters that make an outcome as good as it can be. I first met them tuning a neural network. What I have realised since is that industry is full of systems that are governed by parameters, setpoints and operator knowledge. The difficulty is that an optimiser needs to try combinations to assess the outcome. Something which is just not possible on a real plant.

The first time I used an optimiser, I was not thinking about plants at all.

I was training a convolutional neural network to read date codes on packaging, and the network had a set of dials I had to get right. Learning rate, batch size, how deep to make it. Set them badly and the model never learns properly. So I reached for an optimiser to search those settings for me, instead of guessing by hand.

That is really all an optimiser does. It has an outcome you care about, some knobs it is allowed to turn, and a way to measure how good the result is. It tries a set of parameters, checks the score, and works towards the ones that give the best score. Different optimisers reach the same outcome in a different way, however some optimise better!

An industrial plant is a system with knobs and an outcome, same as a neural network. Setpoints, flow rates, pump schedules, temperatures. And an outcome you want more of, or less of. Energy used. Throughput. Product quality. Most plants are running on settings that were set up to get the plant running. Maybe they were optimal, maybe some combinations were tried. With some systems there are thousands of relative combinations. It is just not possible to try them all and assess them even if you had the plant eternally.

The question is how you search.

The blunt approach is grid search. Pick a set of values for each knob, then try every combination. It is simple, and it will find the best point on the grid. But it does not scale. Add a few more knobs, or a finer grid, and the number of combinations explodes past anything you can afford to run. It is known as a brute-force approach.

Smarter optimisers do not try everything. They use the results so far to decide where to look next. Particle swarm optimisation sends a swarm of candidate solutions across the search space, each one pulled towards the best result found so far. Genetic algorithms breed good solutions together and let the poor ones die off. Grey wolf optimisation borrows the same idea from the way a wolf pack closes in on prey. And when each trial is expensive, a Bayesian optimiser builds a running model of the whole space and spends its limited attempts where they are most likely to pay off.

Different machinery, same job. Find the best settings without checking every one.

However, one hurdle still exists.

Every one of these methods works by running a trial combination, and a lot of these combinations are poor performers. That is not a flaw. Exploring poor combinations of parameters is how the algorithm finds the good ones. A bad setting is fine on paper but is expensive or even unsafe on a real plant. It can mean lost product, a tripped process, stressed equipment, or a safety limit crossed. You cannot hand an optimiser the controls of a live plant and let it fail its way to a good answer. The plant is making product, and it is not allowed to break.

So the optimiser needs somewhere else to fail. Thousands of times, freely, at no cost.

That is what the digital twin is for.

It is a model that behaves like the plant, sitting to one side of it. The optimiser runs against the model instead of the real site. It tries its thousands of scenarios there, fails as often as it needs to, and converges on settings that work. Only then do those settings get validated and taken to the plant. The exploration happens where failure is free. The plant only ever sees the answer.

The most important factor is the fidelity of the twin. And optimisers can help there too.