In a sugar factory, everything is connected. The extraction tower feeds the purification station, which feeds the evaporation, which feeds crystallisation. Change one thing upstream and you feel it downstream, sometimes hours later, sometimes in ways nobody expected.

Traditional control handles each piece in isolation. A PID loop keeps a temperature stable. Another one maintains a level. Each does its job well, but none of them knows what the others are doing. When the beet quality drops after a heavy rain, or when the factory needs to push throughput for a few hours, the operator is the one connecting the dots: adjusting setpoints, anticipating bottlenecks, making trade-offs based on experience.

Model Predictive Control does the same thing, but with a mathematical model instead of intuition. It looks at the current state of the process, predicts where things are heading, and calculates the best set of actions to take. Not just for the next minute, but for the next hour. And it does this continuously, updating its decisions as new measurements come in.

That is the core idea. The rest is engineering.

How Does MPC Differ From Traditional PID Control?

Most sugar factories run on PID controllers, one loop per variable,, each operating independently. MPC replaces that reactive, single-variable approach with a system that manages the entire process simultaneously and looks ahead.

How Does MPC Work, Concretely?

An MPC controller needs three things: a model of the process, a set of objectives, and constraints.

The model is a set of equations that describe how the process behaves: how temperature affects extraction rate, how lime addition changes pH, how supersaturation drives crystal growth. These are not black boxes. They are built from first principles and tuned with plant data. A typical extraction model has around 250 states; a full purification train model can reach 3,000, though the MPC controller itself works with a carefully simplified version.

The objectives tell the controller what matters. Maximise sugar recovery. Minimise steam consumption. Keep crystal size within spec. These can change depending on the situation. That is the point.. The same controller can switch from 'maximise throughput' to 'minimise energy' without any reconfiguration.

The constraints are the hard limits. Equipment capacities, safety thresholds, product specifications. The controller will never violate them, even when the process is under pressure and the trade-offs are hard to evaluate in real time.

Every few seconds to a minute, the controller solves an optimisation problem: given where we are now and where we are heading, what is the best sequence of moves? It applies the first move, waits for new measurements, and solves again. This is the 'receding horizon' , always looking ahead, always correcting.

Where Is MPC Applied in a Sugar Factory?

Extraction

This is where we started, and where the results are most tangible.

A beet extraction tower is a counter-current diffuser: beet cossettes go in one direction, water in the other. The goal is to extract as much sugar as possible while keeping water usage and energy consumption reasonable. The main levers are temperature profiles, water flow, and cossette feed rate. The main disturbance is the beet itself: its sugar content,, its texture, its moisture, all changing constantly.

We currently run MPC on six towers across four factories. The controller optimises in two modes. The first maximises sugar recovery: it pushes extraction efficiency while staying within equipment limits. The second minimises non-sugar extraction: it reduces the load on downstream purification. The factory can switch between them depending on what the day requires.

One concrete example: in a traditional setup, operators control the tower level and let the torque be a consequence. Our MPC can invert this and control the torque directly,, which gives smoother mechanical operation and extends equipment lifetime. A small conceptual shift, but it changes how the tower behaves day after day.

Purification

Juice purification (the sequence from raw juice through liming and carbonation) is a different kind of challenge. The chemistry is nonlinear, the interactions between milk of lime addition, pH, temperature, and CO2 flow are complex, and the measurements are often sparse.

Our purification MPC handles ten manipulated variables simultaneously: five milk of lime streams, two recycle flows, and three temperature setpoints. The model solves in about 20 seconds. The goal is to reduce lime consumption (which is expensive and energy-intensive) while maintaining the juice quality that downstream evaporation and crystallisation need.

This is still in active development. The measurement infrastructure in purification is less mature than in extraction, and some key variables, like CO2 volume flow, in carbonation , are not always available. We are working through these gaps one by one. Purification MPC is scheduled for full release in 2026.

Crystallisation

Crystallisation is the most operator-dependent step in the factory. The decisions about when to seed, how fast to feed, when to cut: these are made based on experience, visual inspection, and a handful of measurements. Two operators running the same equipment will produce different crystal size distributions.

MPC in crystallisation integrates process models with real-time sensor data, including vision systems that measure crystal size distribution and near-infrared sensors that track composition. The controller stabilises supersaturation, optimises crystal growth, and reduces the risk of off-spec batches. The goal is consistency: encode the best operating practice into a system that runs it the same way every batch, every shift.

Factory-Level Coordination

Each of these controllers optimises its own section. But the real opportunity is in connecting them. What if the extraction MPC could tell the purification MPC that a batch of low-quality beet is coming? What if the crystallisation schedule could feed back to extraction to adjust throughput? This is a factory-level coordination layer that receives production targets from management and distributes them across the process MPCs. We already have first integration tests running, and the real validation will come at the end of our current juice campaign and into the next beet campaign.

What Results Can MPC Deliver?

There is a temptation to quote impressive numbers here, and the literature is full of them. I prefer to be honest about what we observe.

The most visible improvement is consistency. MPC does not have bad days. It does not get distracted. It applies the best decision it can compute, every cycle, around the clock. Over a campaign of 100 to 150 days, that compounds into measurable gains in recovery, energy, and product quality.

It also changes what operators spend their time on. When the routine adjustments are handled automatically, they can focus on supervision, planning, and the situations that actually require human judgment.

Something that is often underestimated: knowledge preservation. When an experienced operator retires, their intuition leaves with them. An MPC model, once tuned and validated, captures the process relationships in a form that can be maintained, improved, and transferred to other factories.

From our deployments, results vary depending on the level of automation each factory had before MPC was introduced:

I would rather you see it running in a factory than take my word for specific percentages. The white papers linked below contain the full deployment methodology and data.

Is MPC Right for Your Factory?

That depends less on your equipment and more on your situation.

MPC delivers the most value when processes are tightly interconnected, when raw material variability is high, when energy costs matter, and when operators are stretched thin managing complex trade-offs. If your factory runs a single product with stable inputs and plenty of operator capacity, the business case is harder to make.

It is not a plug-and-play solution. It requires reliable process data: if your measurements are wrong, the model predictions will be wrong. It requires clear objectives: if nobody can agree on whether the priority is throughput or quality, the controller cannot decide for you. And it requires integration with your existing automation. MPC sits on top of your DCS and PLC infrastructure, it does not replace it.

The biggest risk in MPC projects is not technical. It is organisational.

Without alignment between operations, process engineering, and management on what the controller should optimise, the project will stall, not because the technology does not work, but because nobody agreed on what 'better' means. We have seen this more than once.

Frequently Asked Questions

Does MPC replace operators?

No , and the operators who have worked with it do not want to go back. It handles the continuous multi-variable adjustments that are exhausting to do manually. The operator stays in charge of supervision, exception handling, and the decisions that require context the model does not have.

Can MPC work with our existing DCS and PLC systems?

Yes. MPC sits on top as a software layer: it reads measurements and writes setpoints through OPC-UA or MQTT. Your existing control loops stay in place. We do not touch the core DCS logic, we integrate with it.

How long does MPC implementation take?

For extraction, we have brought deployment down to 8-10 weeks per tower, including model fitting and commissioning. Purification and crystallisation take longer: the models are bigger and the measurement infrastructure is often less mature.

Do we need new sensors to deploy MPC?

Not to start. MPC works with whatever instrumentation is already there. But additional sensors (near-infrared analysers, vision systems) , open up capabilities otherwise out of reach. Our approach: deploy first with existing sensors, then add instrumentation where the model shows the biggest gaps.

What is the biggest risk in an MPC project?

Not the technology. It is organisational alignment. If the production team, the process engineers, and management cannot agree on what the controller should optimise, the project stalls. We have seen this more than once: the MPC works, but nobody defined what 'better' means.

Want to See the Data?

The deployment methodology and verified results from our extraction and crystallisation projects are in the white papers, including the full economic analysis behind the numbers above.

White Papers

Or get in touch directly to talk through what MPC could look like at your factory.