A plant wants overall equipment effectiveness numbers and the data exists, in controllers installed before anyone considered that a factory might want an analytics platform. Some speak protocols with no modern library, some have no network port at all, and all of them are running production lines where an unplanned stop is measured in real money. The engineering constraint is not extracting the data, it is extracting it without ever becoming a risk to the process. This is typical manufacturing platform work.
01Never sit in the control path
The first architectural rule is that the data collection system must be incapable of affecting the process. Not unlikely to, incapable. A controller that stops a line because a monitoring system overwhelmed it or wrote to the wrong register produces a loss that dwarfs the entire value of the analytics project.
That means read-only access wherever the equipment supports it, physically separate networks where it does not, and a collection layer that fails silently rather than retrying aggressively against a controller under load. The plant team will ask this question first, and the answer determines whether the project is permitted to proceed at all.
02Survey the equipment before designing anything
Plants are heterogeneous in ways that are not documented centrally. The same nominal machine type across two lines may have different controller firmware, different tag naming and different data availability, because they were commissioned years apart by different integrators.
A physical survey, machine by machine, is unavoidable. It produces the list of what each asset can actually expose, which determines whether OEE can be calculated properly or only approximated, and that distinction needs settling before anyone promises a dashboard.
| Question | Why it changes the design |
|---|---|
| Controller make, model, firmware | Determines protocol and library options |
| Network reachable? | Decides gateway versus direct collection |
| Does it expose cycle counts? | Availability of real throughput data |
| Are stop reasons coded? | Determines if downtime can be classified |
| Who owns changes to it? | Integrator contracts often restrict access |
| Is there a maintenance window? | The only time anything can be installed |
03The three OEE factors have very different difficulty
OEE combines availability, performance and quality, and plants routinely assume all three are equally obtainable. They are not. Availability is usually derivable from machine state, performance needs cycle counts against a defined ideal rate, and quality needs reject data that frequently lives in a separate system or on paper.
Being explicit about which factors are measured and which are estimated keeps the resulting number honest. An OEE figure that silently assumes perfect quality because reject data was unavailable will be confidently wrong, and the operations team will eventually discover it and stop trusting the whole platform.
- Availability: usually available from machine state, the easiest factor.
- Performance: needs a cycle count and an agreed ideal rate, which is often disputed.
- Quality: frequently the hardest, because reject data lives outside the controller.
- Publish which factors are measured versus assumed, on the dashboard itself.
- Agree the ideal rate with production before building, not after the numbers look wrong.
04Downtime reasons need an operator, not an algorithm
A controller can tell you a machine stopped. It usually cannot tell you why, and the why is where the improvement value sits. Distinguishing a planned changeover from a material shortage from a mechanical fault requires either coded stop reasons the equipment supports or an operator entering them.
Where operator entry is needed, the interface design decides whether the data is any good. A terminal requiring several taps during a stoppage, when the operator is busy fixing the problem, produces a dataset dominated by whichever reason is first in the list. Few large buttons and a default of unclassified beats a comprehensive taxonomy nobody uses accurately.
05Buffer at the edge, because the network will drop
Plant networks are not data centre networks. Connectivity drops during shift changes, maintenance and for reasons nobody manages to reproduce. A collection architecture that streams directly to a central platform loses data every time.
Put a gateway at the line or cell that buffers locally and forwards when it can, with enough local storage to cover a realistic outage. This also isolates the equipment from the wider network, which is usually what makes the plant security team comfortable with the whole arrangement.
- Buffer locally for days, not minutes, and size it against observed outage length.
- Forward with idempotent identifiers so replayed data does not double-count.
- Timestamp at the edge, because central arrival time is not event time.
- Monitor the gateways themselves; a silent gateway looks identical to an idle machine.
- Keep gateway firmware updatable without a line stop.
06Deliver one line before the whole plant
Plant-wide rollouts fail slowly and expensively. One line, instrumented completely and producing numbers the production team agrees with, establishes both the technical pattern and the credibility needed for the rest.
It also surfaces the disagreements early. The first honest OEE number is frequently lower than the plant believed, and the resulting conversation about ideal rates and what counts as planned downtime is far better had over one line than across an entire site with the investment already committed.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.