MES and SCADA in Food Plants: How They Work Together and Where the Lines Are

MES and SCADA are the two systems most often confused in food manufacturing conversations, because both deal with production data and modern platforms have blurred the boundary between them. Before deciding what you need, it is worth being clear about what each system actually does and which published standards govern the integration. This article sets out the ISA-95 functional levels, the MESA functional model, the B2MML data exchange, the SCADA-to-MES boundary, and a worked Level 2 to Level 3 data mapping that shows how plant data becomes a contextualised production record.

This post supports our systems integration work, where the connection between control systems, MES and ERP is designed and delivered.

What SCADA does

SCADA is a control and monitoring system. It runs in real time, communicating with PLCs to read process values, display plant state, manage alarms, and in many cases execute control actions directly. It is the system the control room operator uses to see what the plant is doing and to intervene, the layer covered by our PLC, SCADA and HMI work.

A SCADA historian records time-series data: temperatures, pressures, flows, line speeds and equipment states. That data is accurate and granular, but it captures what happened at the process level, not what was being produced or why. A historian tag will tell you that a filler ran at 480 units per minute between 14:02 and 14:37; it does not, on its own, tell you that the run was work order 10455 producing a 600 mL SKU against recipe version 3.

What MES does

MES sits above the control system and manages the relationship between production orders, from ERP or planning, and what the plant floor actually does. The Manufacturing Enterprise Solutions Association (MESA) describes the function set an MES typically covers; the core functions in a food plant are these.

• Production tracking and dispatch. Releases work orders to lines, records start and end, tracks work-in-progress, and reconciles produced quantities back to the order.
• Scheduling. Allocates orders to lines and shifts, sequences jobs to minimise changeover and allergen sequence risk, and tracks the schedule against actual progress.
• Genealogy and traceability. Links raw material lots to the production batch and finished-goods lot. This is the backbone of recall readiness.
• Recipe and specification management. Stores the master recipe, manages versions, and provides the correct parameters to the control system when production starts.
• Performance and OEE. Consolidates downtime, production counts and quality rejects into OEE calculated at the production order level, not just the time period.
• Quality management. Captures in-process checks, links results to the batch record, and can trigger holds or release decisions when results fall outside specification.

These functions turn raw process data into a production record that operations, quality and the business can act on.

The ISA-95 functional levels

ISA-95, published jointly as ANSI/ISA-95 and IEC 62264 and maintained through the ISA95 committee, is the international standard for integrating enterprise and control systems. It defines a functional hierarchy.

Between Level 3 and Level 4, production orders flow down from ERP and actual results flow back up. Between Level 2 and Level 3, SCADA provides process data to MES, and MES sends recipe parameters and order context down to the control system. ISA-95 also defines the object models that cross these boundaries, including the production schedule, the production performance record, the material definition and the material lot. Specifying an integration against these named objects is more durable than describing it informally.

The SCADA-to-MES boundary

The boundary is functional, not always architectural, and the clearest way to define it is by what each layer owns. SCADA owns the real-time picture: live values, alarms, operator actions and the high-resolution historian. Its job is correctness and responsiveness now. MES owns the production context: the work order, the recipe version, the material lots, the people, and the assembled batch record. Its job is to make the process evidence meaningful and auditable after the fact.

The boundary has blurred because platforms now span it. Modern SCADA products carry MES-grade modules, for example an ISA-88 batch engine, OEE and recipe management on the same database and tag model as the supervisory layer, while a dedicated MES can acquire plant data directly. The boundary still matters as a design concept, because Level 2 questions, is the process correct right now, and Level 3 questions, what did we make, from what, against which order, are answered differently and serve different users.

The MESA model and B2MML

Two industry references make the Level 3 layer concrete.

The MESA model describes the functional scope of MES: resource allocation and status, operations and detailed scheduling, dispatching production units, document control, data collection and acquisition, labour management, quality management, process management, maintenance management, product tracking and genealogy, and performance analysis. Where ISA-95 tells you where MES sits, the MESA model tells you what it does inside that boundary. Reading a tender or vendor proposal against the MESA function list is a quick way to see which functions are genuinely included and which are stubs.

B2MML, Business to Manufacturing Markup Language, is a set of XML schemas published by MESA that implement the ISA-95 object models, giving MES and ERP a common format for exchanging production schedules, performance records, material definitions and personnel data. Compared with a hand-coded flat-file or database interface, a B2MML interface is documented against a published standard, easier to extend, and less fragile when one system is upgraded. Even where B2MML itself is not warranted, the ISA-95 object definitions can still discipline a simpler interface so both ends agree on what a production performance message contains.

Data contextualisation: from a tag to a record

Contextualisation is the step that turns SCADA data into an MES record. A historian tag is a value with a timestamp; an MES record is that value bound to an order, a product, a recipe version, a material lot and a person. The binding work is where most of the integration effort lives.

The mechanics are a stable tag model in SCADA, so the same physical measurement always maps to the same address; a time base shared between SCADA and MES, so events align; and a contextualisation rule that says, in effect, while work order X is active on line Y, attribute these tags to this order. Get the tag model or the time base wrong and the contextualisation produces records that look complete but attribute data to the wrong order. This is one reason a disciplined tag and User Defined Type model in SCADA pays back directly at the MES layer.

Worked example: an illustrative Level 2 to Level 3 data mapping

The tag names and numbers below are illustrative, used only to show the shape of the mapping; they are not a Metromotion Controls measurement or a client result.

Suppose the SCADA layer (Level 2) exposes these historian tags for a dairy filling line:

Line3/Filler/Count_Total      integer, units produced (cumulative)
Line3/Filler/Speed_Actual     real, units per minute
Line3/Filler/State            enum: Running / Idle / Faulted / Changeover
Line3/Filler/Reject_Count     integer, units rejected at checkweigher
Line3/CIP/Temp_Return         real, degrees C
Line3/CIP/Conductivity        real, mS/cm

The MES layer (Level 3) holds the order context for the run:

WorkOrder       10455
Product         600 mL whole milk, SKU 6012
RecipeVersion   3
Line            Line 3
PlannedQty      24000 units
MaterialLots    [milk silo 2 lot M-2207, caps lot C-1144]
Operators       [shift B]

The Level 2 to Level 3 mapping binds them. While work order 10455 is active on Line 3, MES attributes the filler tags to that order and derives the production record.

If the line runs 50 minutes against a 60 minute planned window, fills 22,800 good units and rejects 360 at a rated speed of 500 units per minute, then availability is roughly 83 percent and quality about 98.4 percent. MES multiplies the factors into an OEE figure attributed to work order 10455 rather than to an anonymous time block, and the genealogy record ties the finished lot to milk lot M-2207 and cap lot C-1144. That attribution is the point of the Level 2 to Level 3 integration: the same raw counts become a defensible, order-level production and traceability record.

Deciding whether you need a dedicated MES

For many Australian food sites, particularly single-product or limited-SKU operations, a well-structured SCADA historian with order-level data from ERP covers the practical need. A dedicated MES earns its cost when these signals appear.

• Multiple products share equipment and recipe and version management is too complex for ERP to handle cleanly.
• Regulatory or customer requirements demand electronic batch records with lot-level genealogy that ERP does not support.
• Scheduling complexity, whether multi-line, multi-site or campaign-based, exceeds what ERP planning tools manage well.
• Quality management requires in-process hold and release decisions linked to production records, not just post-production inspection.
• Performance reporting needs OEE and downtime attributed to specific orders and root causes, not a periodic time-window figure.

A practical sequence is to map the required Level 3 functions against the MESA model, check which the existing SCADA and ERP already cover, and scope MES only for the genuine gap. Buying a full MES to obtain one or two functions SCADA could carry is a common over-spend; forcing complex genealogy and scheduling into a historian and a spreadsheet is just as costly in audit and recall exposure.

Common mistakes

• Treating MES and SCADA as competing products. They occupy different ISA-95 levels and answer different questions. The decision is which functions live where, not which product wins.
• Skipping the tag model. Contextualisation depends on a stable tag and UDT model in SCADA. Retrofitting it corrupts the data lineage the MES record depends on.
• Operator-entered states feeding OEE. OEE and downtime are only defensible when machine states are read directly from the control layer.
• Point-to-point ERP interfaces. Bespoke flat-file or database links are fragile under upgrades. B2MML, or at least the ISA-95 object definitions, make the interface durable.
• No shared time base. If SCADA and MES disagree on time, contextualisation attributes data to the wrong order. Time synchronisation across the OT estate is a prerequisite.
• Confusing a SCADA batch record with an audit-grade MES record. The process evidence is necessary but not sufficient; recalls and audits rely on the contextualised MES record.

The Australian context

Australian food and beverage manufacturers operate under the FSANZ Food Standards Code and customer and retailer traceability expectations that, in practice, require lot-level genealogy and defensible batch records. The genealogy and quality functions in the MESA model map directly onto those obligations, which is often what tips a multi-SKU site towards a dedicated MES.

Many Australian sites also run mixed PLC estates and a mix of legacy and modern SCADA, so the Level 2 to Level 3 integration has to bridge more than one control platform, which makes a consistent tag model and a standards-based ERP interface matter more. Sites in the food and beverage, dairy and FMCG sectors typically have the SKU range, allergen sequencing and recall exposure that make the Level 3 functions worth formalising. A recurring blocker is fragmented plant data spread across disconnected systems, which we cover in breaking down plant data silos; the MES contextualisation layer is one of the main tools for resolving it.

What this means

SCADA manages the real-time control environment at Levels 1 and 2; MES manages production at Level 3; ERP plans the business at Level 4. The integration between them, especially the Level 2 to Level 3 contextualisation shown above, is where food manufacturers create the batch records, genealogy linkages and order-level performance reporting that auditors, customers and operations rely on. The right starting point is to map the functions you actually need against the standard, confirm what your existing SCADA and ERP already cover, and scope only the genuine gap.

References

The standards and model references above are general industry sources, cited so the technical claims can be checked against the originals. They are not Metromotion Controls measurements.

• ISA, ISA95 committee maintaining the enterprise-control integration standard: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95
• Food Standards Australia New Zealand, the FSANZ Food Standards Code and traceability requirements: https://www.foodstandards.gov.au/