A food and beverage SCADA is one layer in a defined hierarchy that runs from field devices and PLCs up through supervision, site operations and the business systems. Designing to the ISA-95 levels keeps responsibilities, data flows and security boundaries clear.
An alarm system rationalised to ISA-18.2 and EEMUA 191, presented on screens built to ISA-101, gives operators a short list of valid, prioritised alarms during an upset. A poor alarm model carried onto a new platform stays poor.
Recall-grade records, CIP evidence, batch genealogy and trend data are far cheaper to capture when the historian and record retention are designed up front rather than retrofitted onto a live plant.
SCADA for a food and beverage plant is the layer that lets a shift team see and supervise the process, manage alarms during an upset, and keep the records the site relies on for traceability and reporting. Done well it is the operator's window onto the plant and the plant's memory of what happened. Done poorly it becomes a screen people learn to ignore, with alarms nobody trusts and records nobody can find when a recall investigation needs them.
Metromotion Controls delivers SCADA and HMI projects for food and beverage manufacturers across Melbourne, Victoria and Australia. The design choices below are the ones that decide whether a SCADA earns its place on a plant. This post supports our SCADA programming Melbourne, HMI programming Melbourne and food and beverage automation Australia pages.
The SCADA sits above the PLCs and below the business systems. The PLCs execute the real-time control logic and interlocks; the SCADA acquires data from them, presents the process state to operators, manages alarms, and historises trend and event data. That separation matters, because control and safety stay valid in the PLC even when the SCADA is offline, so it is a supervision and record layer rather than the thing that keeps the process safe. The work it carries is specific: it shows the state of tanks, valves, pumps, heat exchangers, CIP circuits and packaging lines; gives operators the controls they are allowed to use and withholds the rest; records the evidence of a clean-in-place cycle, a pasteurisation run or a batch against its recipe; and connects to the historian that holds the data a quality team needs months later. Each is a design decision, and the platform is only the container they sit in.
A food and beverage SCADA is one layer in a defined hierarchy, and the clearest way to reason about it is the ISA-95 functional model, the same level structure that underpins the Purdue reference model for control networks. Placing each function at the right level keeps responsibilities, data flows and security boundaries clear.
Designing to these levels clarifies where each function belongs, so the historian, the reporting path and the MES integration each have a defined home, and it gives the OT network and security design a structure to work to. The boundary between Level 3 and Level 3.5 is exactly where the control network is protected from the business network, the foundation our OT network and systems integration work builds on.
A SCADA is only as useful as the screens an operator reads under pressure. ISA-101, Human Machine Interfaces for Process Automation Systems, sets out how to design, build and maintain HMIs so operators can see plant state quickly and respond correctly. The principles that matter most on a food and beverage plant: use a calm, low-contrast background with muted colours for normal operation, so colour is reserved for abnormal conditions rather than spent decorating a busy mimic; reserve red for alarms and for nothing else, because an operator who sees red everywhere stops reading it as a warning; build a clear hierarchy from a plant overview down through area and unit screens to detail and faceplate views; show process values with context, such as a trend sparkline or a normal operating range, rather than a bare number that says nothing about whether it is drifting; and design for the task the operator performs at that screen. The common failure is a high-contrast, colour-saturated mimic that looks impressive in a demonstration and overwhelms an operator during an upset. A screen built to ISA-101 looks quieter and works harder.
The single biggest determinant of whether operators trust a SCADA is its alarm system, and a poor alarm model carried onto a new platform stays poor. The goal is a short list of valid, prioritised alarms that each require a response. ISA-18.2, Management of Alarm Systems for the Process Industries, developed by the ISA18 committee and adopted internationally as IEC 62682, defines an alarm-management lifecycle from an alarm philosophy through identification, rationalisation, detailed design, implementation, operation, maintenance, monitoring and management of change. EEMUA 191, the engineering guideline that predates the standard, supplies the widely used performance targets, including the benchmark of around one alarm every ten minutes per operator in steady state and firm limits on the alarm rate during an upset. A project typically uses ISA-18.2 as the lifecycle framework and the EEMUA 191 metrics to judge whether the rationalised system performs.
Rationalisation does the real work. Each candidate alarm is tested: is it valid, does it require a unique operator response, and is there enough time to act before the consequence occurs. Alarms that fail are removed, turned into status indications, or merged. Those that pass are assigned a priority that reflects the consequence and the time to respond, not the convenience of whoever configured them. This work is done with the process and operations team, not left as a default the platform arrives configured with.
The following figures are illustrative engineering examples, not a measured Metromotion Controls result. Consider a dairy process area with three balance tanks, a plate heat exchanger, a CIP set and the associated pumps and valves, configured by carrying every PLC fault bit and analogue deviation straight to the SCADA as an alarm. A typical outcome is an alarm database of around 1,400 configured alarms, with an upset on the heat exchanger producing a burst of 60 to 80 alarms in the first two minutes as cascading interlocks trip. An operator cannot read that, so the alarms that matter are buried.
A rationalisation pass against ISA-18.2 works through the database, asking the validity and response question of each alarm. Many turn out to be duplicates of a single root cause, status changes that need no operator response, or deviations set so tight they alarm during normal operation. It would not be unusual to retire or reclassify well over half of them, and to redesign the heat exchanger trip so the operator sees the originating cause as a single high-priority alarm rather than the downstream cascade. The target is to bring the peak alarm rate during that upset toward the EEMUA 191 guidance and give the operator a clear first action. The platform did not change. The alarm design did. A capable platform such as Ignition supplies the technical pieces, prioritisation, shelving, notification pipelines and an alarm journal, but the rationalisation and priority assignment are design work, and that is where the value is.
The historian is the plant's memory, and on a food and beverage site it does double duty: it serves the trend data engineers and operators use day to day, and it holds the records a quality team and a recall investigation depend on. A process historian records tag values over time, usually with a compression scheme so years of data stay manageable, alongside an event and alarm journal that records what happened and when. The scope to define up front includes CIP cycle evidence such as conductivity, temperature and flow against the cleaning specification; pasteurisation and thermal process records; batch records tied to recipe and lot; and the production states that feed a defensible OEE programme rather than operator-entered figures.
Two design points carry most of the risk. Retention and sizing: tag history and alarm journals grow continuously, so the database needs to be sized for the tag count and logging rates at design time, with a retention and maintenance plan, rather than patched once the disk fills. Record integrity: the records that support a recall or a quality release need controlled access, time synchronisation across the plant so timestamps line up, and a clear understanding of what is the system of record. This is part of our industrial data and IIoT work.
Whether a SCADA needs redundancy is an availability question, answered by what an outage costs the process. If loss of supervision stops production, risks product, or removes the operator's ability to see a CIP or pasteurisation cycle in progress, a redundant server pair is usually justified. If the SCADA is reporting-focused and the plant can run on local HMIs through a short outage, it may not be warranted. Most platforms run redundancy as a master and backup pair sharing one configuration, with a choice between a warm standby that takes over fast at the cost of extra device and network load, and a cold standby that loads less but fails over more slowly because tags must be subscribed and initialised on switchover. That choice belongs in the architecture phase. The point that gets missed is that redundancy has to extend past the server: a redundant gateway pair behind a single network switch, or fed from a single power supply, has moved the single point of failure rather than removed it. A genuine availability design considers the network path, the historian database, the supervisory power feed and the connection down to the PLCs.
OPC UA is the vendor-independent, secure machine-to-machine protocol that lets a SCADA connect to PLCs and devices from different vendors through a common interface, and lets plant data flow up to MES, historians and analytics. On a mixed-vendor site, for example Allen-Bradley on packaging and Siemens on process, it gives one consistent connectivity model instead of a bespoke driver for every link, and it carries authentication and encryption at the protocol level. For sites pursuing IIoT, edge gateways at the line or area publish data over MQTT and the Sparkplug specification to a central system, decoupling field devices from the central SCADA and forming the basis of a Unified Namespace where every system reads one consistent picture of plant state. The discipline that keeps it sound is the same as everywhere else: define the data model, the polling and publish rates, and the security of each path at design time. The protocols support strong security, but it has to be configured rather than assumed, so confirm the OPC UA security profile, certificate handling and MQTT broker placement during design.
The platform is a smaller decision than the design work around it. A useful order of operations on a food and beverage SCADA project looks like this.
| Decision | What drives it |
|---|---|
| Platform | Existing PLC estate, IT constraints, in-house support skills, reporting and IIoT needs |
| Architecture | ISA-95 level placement, standalone gateway versus edge and MQTT, OT/IT boundary |
| Redundancy | Cost of a SCADA outage to the process, extended to network, database and power |
| HMI design | ISA-101 hierarchy and presentation, designed around operator tasks |
| Alarm system | ISA-18.2 lifecycle and rationalisation, judged against EEMUA 191 metrics |
| Historian and records | Retention and sizing, CIP and batch evidence, recall-grade traceability scope |
Work top to bottom, but recognise that the lower rows decide whether the SCADA is actually useful. A capable platform with an un-rationalised alarm system and a cluttered HMI is a worse outcome than a modest platform designed well.
For an Australian food and beverage manufacturer, the SCADA's record-keeping connects directly to recall obligations. Food Standards Australia New Zealand sets the requirements for food recalls, and effective recall depends on traceability one step back to suppliers and one step forward to customers, supported by accurate batch and lot records. A historian supports this by recording which batch ran when, which raw material lots and recipe were used, the CIP and process evidence for that run, and the genealogy that links finished product lots back to their inputs. The practical aim is fast, defensible isolation of affected product so a recall can be narrow and quick rather than broad and slow. The current FSANZ recall guidance and the Australia New Zealand Food Standards Code should be checked for the specific record content and timing expectations, because they are the authoritative source and are updated periodically. The engineering practice is to design the historian and batch records so the traceability question can be answered in minutes from retained data, which is far cheaper built in than retrofitted onto a live plant.
If you are planning a SCADA upgrade or a new build for a food or beverage plant, the most useful starting point is operator tasks, alarm quality and record-keeping scope, with the platform decision following from those. If you can share your existing platform, PLC mix and the sites in scope, Metromotion Controls can work through the right architecture for your plant as part of our systems integration and automation upgrades services.
The standards, regulatory and platform sources below are general industry references, cited so the technical claims above can be checked against the originals. They are not Metromotion Controls measurements.
Tommy Kim writes for Metromotion Controls, a Melbourne control systems integrator delivering PLC, SCADA, controls integration and commissioning for food, beverage, dairy and FMCG manufacturers across Australia.
PLC logic, SCADA architecture, HMI standards, alarming and historian integration for manufacturing sites.
OEE, downtime, historian and production reporting systems built from reliable plant signals.
Automation, traceability, CIP, SCADA and production data for Australian food and beverage plants.
A practical view of where Ignition is the right SCADA platform for Australian manufacturers and where it is not.
When Ignition fits an Australian food and beverage site: Perspective vs Vision, architecture and redundancy, OT security, and buying Ignition locally.
Key point
Platform fit comes before platform capability
Published 9 May 2026
Practitioner guide to scoping industrial automation for Melbourne manufacturers: control stack scope, greenfield versus brownfield, and choosing an integrator.
Key point
Scope from the operating constraint
Published 8 Apr 2026
How beverage automation reduces variability: recipe and batch control, versioned recipes you can trace back in time, work orders as a single live source of truth, and a historian that records exactly how every batch was made.
Key point
A single live source of truth
Published 3 June 2026
Map out scope, delivery approach and what to have ready before the first conversation. Answer a few questions and Metromotion Controls returns a tailored scoping brief on screen.