Choosing a partner for sugar factory digitalisation means choosing who will help you maintain production when raw material quality changes, measurements drift and the campaign leaves little room for interruption. This framework tells you what to ask and what counts as a real answer.
The day you find out whether you chose the right automation vendor is rarely the day you sign. It is a night in week six of the campaign. A juice measurement drifts, the optimiser keeps moving setpoints on the strength of it, and the sensor maker, the software supplier and your own instrument team each assume one of the other two is looking at it. By then, nobody wants to start again.
Not every problem needs a new vendor. Better measurements and well-tuned conventional control solve a lot. Harder cases can justify advanced process control (APC) inside the existing distributed control system (DCS), or a specialist model predictive control (MPC) layer next to it.
Five questions for every bidder
- "Why do we need your control approach at all?" The gain against a well-tuned DCS baseline, and the sugar knowledge behind it.
- "Who is accountable from the measurement to the control action?" One named owner for sensors, calibration, models, integration and performance, or a documented split.
- "How does it connect to our DCS, and how does it evolve?" A working integration on your DCS version, a path to closed loop and controlled feature updates.
- "Who keeps the plant running when something fails?" Tested fallback, 24/7 escalation, remote support and recovery, in the contract.
- "How can we check your results?" Comparable reference plants, the method behind every number and a commissioning plan that fits the campaign.
Put the same five to every bidder, with the same evidence requirements.
Can a standard DCS achieve the same result?
Sometimes, yes, and more often than most vendors will tell you. If the problem is poor loop tuning, unreliable measurements, missing feedforward control or sequences that every shift runs a bit differently, the cheapest fix is in the DCS you already have. An optimiser on top will not repair a sticking valve, and it still needs good measurements.
"Standard DCS" also needs a definition. PID loops and sequences are one thing, a DCS with APC and MPC licensed is another (we compared PID and MPC in From Reactive to Predictive). DCS-native MPC is a real option: Emerson, for example, documents embedded multivariable control and optimisation in DeltaV Predict and PredictPro. Availability, execution location and licensing depend on the function and the installed version.
Take extraction: more draft gets more sugar out of the cossettes, and every extra cubic metre of water has to be evaporated again downstream, with steam you pay for. With long delays and variables pulling against each other, this is where a predictive model can earn its place. A good conventional strategy may get there too, and both claims need evidence from your application.
None of the three routes wins by default, and a separate platform has to pay for its extra interfaces and service with a gain you can measure.
| Route | Pros | Cons and conditions |
|---|---|---|
| Improve the existing DCS control | Same operator screens and engineering tools, little new infrastructure or licences, a strategy your team knows. | Only as good as the measurements and engineering hours available. Complex interactions can need a lot of custom logic. |
| Add DCS-native APC or MPC | Advanced control stays in the automation system you already run, and handles interacting variables and constraints. | Can need licences, controller capacity or a version upgrade. Sugar models and their upkeep still need expertise. Each DCS brand in your group is a separate project. |
| Add a specialist optimisation layer | Can bring sugar applications validated elsewhere, sensor support and functions reusable across DCS brands, where demonstrated. | More interfaces and software dependencies, possibly subscriptions and remote services. Needs a named owner for integration, fallback and model maintenance. |
Generic MPC and sugar-specific models
"We offer MPC" tells you about as much as "we offer software". What matters is how the supplier models your process and its trade-offs. For extraction, ask what the model assumes about the beet, and what it does in January with beet that looks nothing like the October beet it was tuned on. For crystallisation, ask how the controller knows the supersaturation in the pan, and what it does with the strike when that reading is wrong.
Every model has a range where it is valid: ask where the edges are and what the controller does outside them, before you find them yourself in week eight.
At the end, the question is how much sugar knowledge is already validated, and how much you will pay them to learn on your plant. Ask for the model description, validation results, known limitations and who retunes the model between campaigns, then put the cost of that retuning in the comparison.
Who owns the sensors, and who owns the measurement
Back to the drifting juice measurement: who investigates it, the instrument manufacturer, the calibration specialist, the software supplier or your own plant team? Who detects the drift, maintains the reference measurements and decides that a signal is no longer good enough to control on? If the contract does not name someone, the answer at 02:00 is nobody.
One supplier for sensors and control makes this simpler (Sucrosphere delivers both, so of course I would say that). Give credit for it only when the contract makes the responsibility explicit, maintenance and fault resolution included. A multi-vendor setup scores just as well if one named party owns the whole performance chain and the interfaces are documented.
With Device as a Service, check what the subscription covers: hardware, calibration, replacements, model maintenance, software updates and support. Ask what you can reuse for the next application or the next factory, and get the first installation and each extension priced separately.
From visibility to closed loop
Most projects climb the same ladder: visibility, recommendations, assisted optimisation, then closed-loop control. Check that each supplier can support all of it, and that what you pay for on the first step is still useful on the last. Ask which capabilities exist today, which need another licence and which are still on the roadmap, then ask to see customers running at the level you are being offered. Our checklist 10 Signs You Are Ready to Implement MPC covers pilot scope and how to start.
An OPC UA logo on a slide proves nothing about the integration with your DCS or programmable logic controllers (PLCs). Ask for the supported versions, the handling of bad-quality signals, the permitted writes, the operating limits and who holds control authority when.
What an upgrade or a new feature should include
Ask for a change description written for your plant. Depending on the route, it covers:
- DCS-only improvement: control logic, instrument changes, operator displays, testing and controller downloads.
- DCS-native MPC: the same, plus licences, controller or server capacity, model engineering and version dependencies.
- Specialist layer: local computing hardware, interfaces, network changes and the DCS modifications needed to accept or reject its commands.
For every control interface, agree units, timestamps, signal quality, update rates and permitted writes. The design also fixes the setpoint limits, how long an external command stays valid and when the DCS takes back control.
Then put the promise to a test. Say next year you want a new quality prediction, another sensor or optimisation on a second process stage. Does it run on what is installed, or does it need a site visit, a DCS change, a production stop or another licence? And when either side gets its next version, who makes sure the two still talk to each other?
Service-delivered software ships new functions more easily, but a control change still needs validation and an agreed release process. Compare offline testing, version documentation, plant approval, scheduling and how quickly the previous working configuration comes back. And ask what counts as maintenance and what is a chargeable extension, the answer tells you a lot about the next five years of invoices.
Cybersecurity in a connected factory
An isolated DCS has a real security advantage: fewer connections, fewer ways in. It is not immune, though: maintenance laptops, removable media, compromised updates and insiders bring threats in, isolated or not.
For a sugar producer, the strategic question is which connections create enough operational value to justify their risk and management effort. Remote expertise, new prediction models and software updates can support continuous improvement. A fully isolated system can still be the right choice for particular functions, but may require more on-site work and manual data transfer to obtain those benefits. Connectivity should serve a defined purpose, with critical control able to operate independently of external services.
Ask the supplier to show, on a network drawing, how the DCS is separated from the business network and from external platforms. Then ask which data leave the factory, and whether any remote service can write back to control. That last question is the one I would ask first, and if the answer takes more than one sentence, keep asking. Require protected gateways, tightly limited permissions, authenticated and logged remote access, and a way for the plant to switch that access off. These principles follow NIST's Guide to Operational Technology Security (SP 800-82).
Finally, ask who watches for vulnerabilities, who validates patches, how long each component stays supported and what happens if the supplier withdraws a service. If NIS2 applies to your company, supply chain security is part of your own obligations, so you will need these answers anyway.
When something fails during the campaign
Fallback has to be delivered and tested like any other function. Ask who engineers it, who validates it with the DCS supplier and whether it is in the offer. Redundant hardware does not help when the model is wrong or a measurement is lying.
Have the supplier demonstrate these scenarios in an agreed test environment before plant acceptance, with the responses validated by your plant team.
| Failure scenario | Supplier evidence to require |
|---|---|
| Sensor drift or stale data | Detection criteria; rejection or approved substitution of data; reduced-function operation or withdrawal from optimisation. |
| Optimiser or interface failure | Communication supervision; expiry of external commands; controlled transfer to an agreed local DCS strategy; operator indication. |
| Cloud or internet outage | An explicit list of the functions that continue locally, the functions lost and the conditions for reconnection. |
| Failed update or corrupted configuration | An accessible working version, a configuration backup and a demonstrated restoration procedure. |
Whatever the fallback, the protective functions in your DCS must stay effective. If the DCS itself fails, an external optimiser does not replace it.
Every stopped hour of the campaign is beet you do not get back, so give credit to suppliers who say before the order which changes can be made while the plant runs and which need a planned stop.
What 24/7 support must include
A phone number that answers around the clock is the easy part. Ask who answers at 02:00 during the campaign, and whether that person can diagnose the sugar application, get into the systems and pull in the DCS or sensor specialist. Compare coverage over weekends, holidays, languages and time zones, and ask what happens when three customers call on the same night.
The service agreement should separate acknowledgement, access to a qualified engineer, diagnosis or workaround, and restoration. Get numbers per incident severity, the escalation route and the update frequency. Write down when someone comes on site or brings spare hardware, and who provides it.
A server that is up and an optimisation that does its job are two different things. The server can run happily while the predictions drift or the optimiser gets switched off every night shift. Does the supplier monitor data quality, model performance and time in automatic operation, or wait for an operator to call?
Remote support and backup
Remote support covers diagnostics, log review, configuration checks and authorised software recovery, where your architecture and access policy allow it. It cannot replace an instrument or repair a network switch, so ask for a demonstrated remote diagnosis and the skills you still need on site. Require individual accounts, proper authentication, restricted permissions, logging and revocable access, with remote changes going through your normal change control. And ask how support works on the day the remote connection is down.
Three commitments get mixed up all the time:
- Fallback control keeps the process within the agreed operating strategy after a fault.
- Backup and restoration bring back the software, models and configuration.
- Redundancy or failover gives you a second component that is already running.
For the backup, ask for an inventory of everything needed to rebuild the solution: application versions, models, calibration settings and interface configuration. Confirm who owns it, where it is stored and protected, how long it is kept and whether you keep access if the contract ends. Agree the acceptable loss and restoration time, and require a restore test.
Reference plants
Ask to speak with the people who operate and maintain a comparable application. The shift supervisor will tell you more than the manager who signed the order. Match references on process stage, beet or cane, operating conditions and level of automation. For each claimed improvement, ask for the baseline, the measurement period, the production conditions and how other changes were accounted for.
Find out whether the benefit held, and how often the optimisation was actually switched on. Three good weeks in October are not a campaign. The reference customer can also tell you how much engineering the plant had to supply, what failed and how the vendor responded.
Logos, isolated screenshots and savings percentages without a method are a reason for more questions, nothing more. Where confidentiality limits disclosure, ask for an anonymised technical case or a reference call under an appropriate agreement.
The evaluation scorecard
Use this suggested weighting as a starting point. Agree any changes internally before reviewing bids, then apply the same weights to all suppliers. Score each row from 0 to 5 and record the evidence supporting it.
| Evaluation criterion | Weight | Evidence to request | A | B | C |
|---|---|---|---|---|---|
| Sugar expertise and value against the agreed baseline | 20% | Relevant engineering; fair baseline; sustained results | |||
| Sensor and control accountability | 10% | Named owner; calibration and fault-resolution scope | |||
| DCS integration and upgrade path | 15% | Version compatibility; interface design; change scope | |||
| Fallback, operator authority and updates | 15% | Tested failure responses, handover and restart | |||
| Campaign delivery and 24/7 support | 15% | Resourced plan; severity-based service commitments | |||
| Remote support and recovery | 10% | Access design; backup scope; tested restoration | |||
| Lifecycle cost, data terms and security | 10% | Release process; complete costs; access and exit terms | |||
| Comparable customer references | 5% | Operator feedback; actual workload and service record | |||
| Total | 100% | Weighted result out of 100 |
Label A, B and C with the suppliers or delivery routes being compared. Record the evidence reference and any unresolved contractual gap alongside each score in your working copy.
Scoring: 0 = absent or no evidence; 1 = claim only; 2 = partly documented with major gaps; 3 = meets the agreed requirement with credible evidence; 4 = demonstrated in comparable operation with clear responsibilities; 5 = sustained, reference-verified performance with the relevant commitments included in the offer.
Calculation: Total score = sum of each criterion's weight x its score divided by 5. Use weights as whole numbers: a score of 4 on the 20% criterion contributes 16 points.
Compare costs over the same period and scope, including infrastructure, commissioning, subscriptions, calibration, support, internal engineering and exit costs. Avoid counting the same benefit twice, for example both as additional output and as the margin earned on that output. The matrix should make the decision explainable to both operations and management.
Frequently asked questions
Is a sugar specialist always better than a general automation supplier?
No. A general platform with a strong sugar engineering team can qualify, and a specialist still has to prove its claims.
Should sensors and MPC come from the same supplier?
It can simplify fault resolution, as long as one party is clearly responsible, whether that is one company or a coordinated team.
Do we need to replace our existing DCS?
Usually not. Ask the bidder to show that its optimisation works with your installed system and to list every change it needs.
Can a standard DCS achieve the same result?
Yes, for some applications, especially where better measurements and conventional control address the main loss. Any claim of additional benefit needs the same operating constraints and a fair baseline.
Does a cloud backup guarantee uninterrupted operation?
No. Continued operation depends on local control and any redundancy engineered for it, a backup only helps you restore.
Does shared data automatically produce better models?
Not automatically. Ask for evidence that learning from other plants improves your application, and clarify permission, confidentiality and whether participation is optional.
What should decide between similarly scored suppliers?
The remaining delivery risks, the reference feedback and the contractual commitments. Prefer the proposal whose value, workload and responsibilities you can explain and verify.
Try it on us
Bring this scorecard to your next supplier discussion. If Sucrosphere is on your list, ask us to fill it in with the same evidence you ask of everyone else. The method and the results from our sensor and optimisation projects are in the Sucrosphere white papers.
This article is part of the Sucrosphere series on sugar factory digitalisation. Related reading: Sugar Factory Automation Checklist: 10 Signs You Are Ready to Implement MPC and Device as a Service: How Renting Sensors Changes the Business Case for Optimisation.
