Platforms and vendors
- Rockwell ControlLogix
- Siemens
- Ignition
- SQL databases
- OPC UA
- MQTT
- ISA-95
- ISA-88
Plant Intelligence · 02
Reliable Plant Data, Checked by the People Who Wrote the Code
Metromotion Controls turns PLC and SCADA signals into plant data people can trust: the right tag for each count, one meaning for each machine state, and every record placed in its context of site, line, machine, SKU, order and shift.
How we approach it
Engineered for your site and support model
Most plant reporting problems start before the report. A count is taken from the wrong tag, a state means one thing on the filler and another on the capper, a stop is booked to the machine that waited instead of the one that failed, or a shift boundary is set in the wrong time zone. The people best placed to get this right are the ones who wrote the PLC code. Metromotion Controls has built and programmed food and beverage lines since 2012, so we check signals against the logic that produces them and give every record the context it needs before anyone builds a dashboard on it.
01
Signal review against PLC logic before data is used
02
One stop model and state definition per machine type
03
ISA-95 line model for site, line, machine, SKU, order and shift
04
Data validation against independent counts during commissioning
05
Edge buffering, quality flags and a single time base
06
Historian and SQL data models the site owns
Delivery context
Relevant experience
- Chobani: supported the initial plant setup, added lines over the years, then built a data platform with contextualised production data from lab equipment and other external sources.
- Lactalis: programming and commissioning across six dairy sites, carrying SCADA work consistently across different installed bases.
- Bulla: SLC-500 control logic ported to CompactLogix, simplified and commented so each signal is easier to trace.
- Real Pet Food: ISA-88 batch control with recipe phases and route and ingredient validation at each step.
Section 01
Where plant data goes wrong
Plant data rarely fails because a database is missing. It fails because signals were collected without anyone checking what they mean. These are the faults we find most often when a site tells us its reports do not match the floor.
- Counts taken from the wrong tag: infeed instead of good output, or a counter that resets on a fault.
- States that mean different things on different machines, so one line looks worse only because its OEM labels stops differently.
- Stops booked to the machine that was starved or blocked rather than the one that caused the stop.
- Shift boundaries, daylight saving and server clocks that do not agree, so a stop lands in the wrong shift.
- Manual reasons typed after the event that override what the controller already knew.
- Rejects counted twice, once by the checkweigher and once by the line total.
Section 02
Why the integrator who wrote the code has an advantage
A consultant or a software vendor starts by learning what each tag means. When Metromotion Controls built the line, we already know: which counter is the real finished-goods count, which bit is the true fault and which is a warning, and why a stop is booked where it is. On lines we did not build, we read the PLC code first and trace each signal back to the logic that sets it before it is used for reporting. That removes the longest and least visible step in most data projects and stops a dashboard being built on a signal nobody checked.
Section 03
Validating data during commissioning
Data is validated the same way we validate control logic: against the real line, with the people who run it. During commissioning or the first weeks of a data project, we check each figure against an independent source before the report goes to management.
- Good-output counts checked against the filler, checkweigher and palletiser totals for the same run.
- Stop durations checked against what supervisors saw on the floor during a watched shift.
- Reject counts checked against the checkweigher and metal detector records.
- Shift and day boundaries checked against the roster and the site time base.
- A short list of known gaps, with owners, rather than a report that hides them.
Section 04
Context: the line model behind every record
A number without context cannot be acted on. We give each record its place in a line model based on ISA-95, so every count, stop and quality result is stored against the same structure and can be compared across lines and sites. The same model is what lets lab results, schedules and maintenance records join the production data without manual matching.
- Site, area, line and machine, following the ISA-95 equipment hierarchy.
- Product and SKU, with the ideal rate for each SKU on each line.
- Production order or batch, released from the schedule or ERP.
- Shift and crew, from one agreed time base.
- Stop reason and fault code, from the agreed reason tree.
- Quality and lab results, joined to the batch or time window they describe.
Section 05
Collection that does not lose data
Reliable data also means complete data. We collect from PLCs over native drivers, OPC UA or MQTT on a segmented OT network, buffer at the edge where the network is weak, and store events in an open SQL schema or historian the site owns. Each record carries a quality flag, so a value from a failed sensor or a communications drop is marked rather than silently averaged into a report.
- Store-and-forward buffering so a network drop delays data instead of losing it.
- Quality flags on every value, carried through to reports.
- One time base across PLCs, servers and reporting.
- Read-only collection from the control layer, under site change control.
Frequently Asked Questions
Common questions
Our reports do not match what supervisors see. Where do we start?
With the signals. We trace each figure in the report back to the PLC tag and logic that produces it, check it against an independent count on a watched shift, and fix the source before touching the report. Most mismatches come from a handful of tags.
Can you do this on lines you did not build?
Yes. We read the PLC code and trace each signal to the logic that sets it before it is used. Lines we built start with that knowledge already in hand, which is why the work is faster there.
What does contextualised data mean?
It means every value is stored with what it describes: the site, line, machine, product, order, shift and, for stops, the reason. Context is what lets a report answer why output was low, not just that it was.
Do we need a historian or a data lake?
Not to start. An open SQL schema holding events and counts with their context covers most production reporting. A historian is added where high-rate process trends are needed, and a larger data platform only once one site has data people trust.
Related Work
Connected services, industries and proof
Service
Plant Intelligence: factory data and OEE
OEE, reports, quality, CIP, maintenance and energy data from the team that builds and programs the lines.
Service
OEE and production monitoring
Live OEE, line status and stop reasons read directly from the PLCs on food and beverage lines.
Service
Production reports and dashboards
Shift, daily and weekly reports generated from line data and delivered to SCADA, Power BI or email.
Insight
ISA-95 and the Purdue model for food plants
The ISA-95 levels and the Purdue model explained on a food line, with where each piece of context lives.
Insight
Breaking down plant data silos
The unified namespace, MQTT and Sparkplug, OPC UA, historian contextualisation and ISA-95 alignment for a single source of plant truth.
Project
Chobani greenfield yoghurt plant
Large capital project delivery across process automation, electrical engineering and commissioning.
Project
Chobani OEE data platform
OEE and downtime reporting from PLC states, with shift and weekly management reports for an Australian yoghurt plant.
Project
Real Pet Food raw materials handling
Pet food raw materials automation covering batching, handling and production control requirements.
Project
Bulla SLC 500 to CompactLogix upgrade
SLC 500 end-of-life upgrade to CompactLogix PLCs, I/O and HMIs for two ice cream churns, completed in a one-week shutdown.
Project
Lactalis programming and commissioning support
Programming and commissioning support for dairy production controls and site delivery teams.
Service
Ignition SCADA integrator Melbourne
Ignition Gold Certified System Integrator for Ignition SCADA, historian, reporting and MES functions.
Service
Automation commissioning, FAT, SAT and audits
Commissioning engineers, acceptance testing, loop checks, startup support and control system readiness audits across Australia.
Industry
Food and beverage automation Australia
Automation, traceability, CIP, SCADA and production data for Australian food and beverage plants.
Related work
Related project proof
Project
Chobani
Chobani needed a controls partner to help establish its Australian manufacturing operation with new production lines and site infrastructure, and the relationship has had to keep adding and optimising lines without disturbing production already running on site. Metromotion Controls supported the initial setup and has continued to add, optimise and support production lines over the years, bringing process, packaging and site services onto common control and data interfaces so each addition extends one operating environment rather than a separate island. The scope spans plant services including boilers, refrigeration, trade waste, power monitoring and water usage monitoring, plus OEE, site data analytics and contextualised production data from lab equipment and other external sources.
Project
Chobani
Building on the greenfield automation delivered at Chobani's Australian facility, Metromotion Controls was engaged to develop an OEE data platform that gave the operations team structured visibility of line performance, availability losses, and production output. The project connected existing PLC infrastructure to a centralised reporting environment, establishing consistent downtime reason codes, shift-level OEE calculation, and management dashboards aligned to how the site teams already ran daily reviews.
Project
Real Pet Food Company
Real Pet Food Company needed automated raw materials handling with stronger batch traceability and scheduling, across a plant where mechanical, electrical and automation scope all had to be brought together by one team before startup. Metromotion Controls structured the batch control to ISA-88, breaking each product into recipe phases and validating the transfer route and ingredient at each step so material moved against a confirmed path rather than an assumed one. The team supplied, installed and commissioned the system, coordinating mechanical, electrical and automation scope through simulation, FAT and startup.
Related pages
Plant Intelligence
Plant Intelligence
Factory data, OEE, reports, quality, CIP, maintenance and energy from the team that builds and programs the lines.
Plant Intelligence
OEE & Production Monitoring
Live OEE, line status and stop reasons read directly from the PLCs, shown to operators, supervisors and managers when each of them needs it.
Plant Intelligence
Production Reports & Dashboards
Shift, daily and weekly production reports generated from line data and delivered to SCADA screens, Power BI or email, with no typed entries or spreadsheet collation.
Service
Ignition SCADA & MES Integrator
Ignition SCADA, historian, reporting and MES functions designed, built and supported by an Ignition Gold Certified System Integrator in Melbourne.
Not sure your plant data can be trusted?
Speak directly with an engineer about scope, timing and technical constraints.