Event-Driven Manufacturing Systems

Most plant systems that describe themselves as “real-time” are actually running on polling — a dashboard or integration checking a data source every thirty seconds, every minute, every five minutes, and calling the result real-time because the delay is short enough that most people don’t notice it. Most of the time, that’s close enough. The times it isn’t — a quality hold that needs to stop a downstream process immediately, a critical machine fault that needs an instant alert — are exactly the moments a polling delay actually costs something.

Polling vs. Events, in Practice

A polling architecture asks a question on a schedule: “what’s the status of Machine 3?” every thirty seconds, whether or not anything changed since the last check. Most of those checks return “nothing new,” which is wasted overhead, and the one check that does catch a real change is delayed by up to the full polling interval — a fault that happened at second five of a thirty-second polling window isn’t seen until second thirty.

An event-driven architecture inverts this: Machine 3 (or the gateway representing it) publishes a message the instant its status actually changes, and every system subscribed to that event receives it immediately — no polling delay, no wasted checks on unchanged data. The dashboard, the ERP integration, and an alerting system all receive the same event at the same time, rather than each independently polling on their own schedule and drifting out of sync with each other.

Where the Latency Actually Matters

Not every piece of manufacturing data needs event-driven urgency. A daily production summary feeding a cost report is fine on a batch schedule. The events genuinely worth architecting for immediate propagation are the ones with real operational consequence if they’re delayed: a quality hold that should stop downstream processing, a critical machine fault that needs an immediate maintenance response, a safety interlock trip, a changeover completion that the next process step is waiting on. These are the events where a five-minute polling delay isn’t a minor inefficiency — it’s a window where bad product keeps getting made, or a downstream station sits idle waiting for a status update that already happened.

How This Actually Gets Built

The common pattern uses a message broker — MQTT is the standard choice in industrial environments — sitting between the machines (via the industrial gateway) and every system that needs to know when something happens: the dashboard, the ERP integration, an alerting system, the traceability record. Machines or the gateway publish events to specific topics; interested systems subscribe to the topics relevant to them. This decouples the systems from each other — the machine doesn’t need to know who’s listening, and a new system can subscribe to existing events without requiring any change to how the machine publishes them.

Reliability matters here more than in most architecture decisions: a message broker with persistence and delivery guarantees ensures an event published while a subscriber is offline still gets delivered once that subscriber reconnects, rather than being silently lost — which is the difference between “temporarily behind” and “missed a quality hold entirely.”

Not a Replacement for Everything

Event-driven architecture complements existing systems rather than replacing them wholesale. A legacy system that only knows how to poll can still be accommodated — an adapter layer can poll the message broker on the legacy system’s behalf, translating events into whatever format that system expects, so the rest of the architecture gets the latency benefit even where one older piece can’t fully participate in it yet.

Architecture That Matches the Urgency of the Data

The point of event-driven design isn’t architectural elegance for its own sake — it’s making sure the events that actually matter (a quality hold, a critical fault) propagate at the speed their consequences demand, while everything else runs on whatever schedule is genuinely sufficient. SG2’s Manufacturing & Industry 4.0 practice designs the event layer around which specific data actually needs that urgency, not by defaulting every data flow to real-time regardless of whether it needs to be.