Dashboards are useful when people need to inspect a process. They are less effective when the required response is time-sensitive. If an alarm must be noticed, interpreted and then routed manually, the human review cycle becomes part of the system latency.

What is the role of an event-driven data layer?

An event-driven architecture allows systems to react to state changes rather than repeatedly asking whether something has changed. A temperature threshold, equipment state change, production event or quality condition can become an event consumed by the appropriate application or workflow.

How does the architecture support this?

• Use a shared information layer rather than a collection of isolated point-to-point links.

• Give events consistent asset and process context.

• Use publish-subscribe patterns so multiple consumers can act on the same event.

• Separate event transport from the applications that consume it.

What happens when the foundation is fixed first?

One documented engagement with a mid-sized discrete assembly manufacturer illustrates the gap. Before the architecture was restructured, more than 45% of machine-level data was collected but not used downstream, and average alert response exceeded 20 minutes. After the data architecture was unified, response time to production issues improved by 32% and unplanned downtime fell by 18%. These figures are presented as results from that engagement, not as a universal manufacturing benchmark.

Why is contextualisation essential?

An event saying 'temperature high' is incomplete. An event saying 'Line 2, Reactor 3, Temperature exceeded the configured threshold at 14:32 during Batch 184' is actionable. The more clearly the event is tied to the plant hierarchy and operating context, the less interpretation is required downstream.

What should be built first?

• Define the event types that have clear operational consequences.

• Define the minimum context each event needs.

• Publish a small set of trusted events.

• Connect them to alerts or workflows.

• Measure response latency and false or irrelevant events.

• Expand the event model after the first use case proves useful.

FAQ

Is event-driven architecture the same as automation?

No. Event-driven architecture provides the mechanism for detecting and distributing changes. Automation is what a downstream system does in response.

Can this work with existing plant systems?

Yes, provided the existing systems can expose or consume the required information through suitable interfaces.

Further reading: event-driven manufacturing data layer.

Written by Ketsol Marketing Team. Ketsol Pvt. Ltd.

Learn more on: https://ketsol.ai/

Connect on LinkedIn: https://www.linkedin.com/company/68765895

Overall Equipment Effectiveness (OEE) is the manufacturing industry's most widely used production KPI. The formula is simple: OEE = Availability × Performance × Quality. A score of 100% means perfect production every scheduled minute running, at full speed, producing only good output. In practice, global manufacturing plants average 65–70% OEE. The number itself is not the problem. The problem is that in most daily production reviews, the first 20 minutes are spent arguing about whether the number is right before anyone decides what to do about it. That is a data trust problem, not a formula problem.

Why do plant teams distrust OEE data?

Three structural failures drive OEE distrust across manufacturing plants, particularly in mid-sized operations where data systems have been added in layers over time.

1. Fragmented data sources with no single owner
   OEE draws from three separate inputs: machine runtime data (Availability), production count data (Performance), and quality rejection data (Quality). In most plants, these come from three different systems: a PLC or SCADA for availability, a MES or manual log for production, and a QMS or handwritten record for quality. Each source is locally accurate. The join between them is where trust breaks down. When timestamps don't align, when data types differ by system, and when no single team owns the combined output, the OEE number that emerges carries doubt from all three inputs.

2. Post-shift data editing
   Most plants allow downtime reasons and loss codes to be updated after the shift ends. This is an operationally necessary context that often arrives late. But it is architecturally damaging. When engineers know that last shift's data may have been edited, they discount this shift's data before it even appears. Mutable historical records are one of the top three drivers of KPI distrust in manufacturing analytics implementations.

3. Reporting latency kills context
   OEE calculated overnight or at the end of the shift is stale by the time the morning review starts. Context fades. Shift engineers who operated the machines are off-duty. Memory replaces evidence. And debate replaces decisions. Plants with sub-shift reporting OEE visible within 15–30 minutes of each production event consistently run shorter, more decisive reviews than plants relying on overnight batch calculations.

What does low OEE data trust actually cost?

A 2025 Dun & Bradstreet Manufacturing Pulse Survey found that only 36% of manufacturers feel confident making business decisions with their existing data. The operational cost shows up in specific, measurable ways:

• Review meetings run 20–40% longer as teams reconcile conflicting data before deciding actions

• Issues that should be resolved within a shift take 24–48 hours to close

• More than 50% of operations managers maintain personal Excel backup files even where dashboards are deployed

• Production targets soften because teams won't commit to numbers they can't fully trust.

How does a reliable OEE data pipeline fix this?

The fix is not a better dashboard. It is a better data infrastructure beneath the dashboard. Three changes make the most consistent difference:

1. Automated data capture at the machine level. Eliminate manual entry at the source. Data collected via OPC UA, Modbus, or MQTT directly from PLCs removes the most common point of human-introduced error.

2. Immutable event logging. Raw downtime events are recorded and protected. Corrections are appended as separate records; the original entry is never overwritten. Engineers trust data they know hasn't been changed.

3. Sub-shift calculation and reporting. OEE available within 15–30 minutes of each shift event means context is present when decisions are needed — not hours after context has faded. Plants that implement these three changes report review meetings running 30–40% shorter. Production issues close 20–25% faster. Decisions move forward instead of circling back.

What should engineers look for in an OEE monitoring system?

• Protocol-native data collection: native support for OPC UA, Modbus TCP, MQTT, and EtherNet/IP avoids custom middleware and timestamp drift.

• Edge-level normalisation: data normalised before it reaches the analytics layer, preventing calculation inconsistencies from device-level variation.

• Immutable audit logs: event logs that append corrections rather than overwriting source data.

• Configurable latency: OEE visible at 15-minute, 30-minute, or per-shift intervals depending on plant requirements

The engineering effort to reach this state is real. The return, measured in shorter reviews, faster issue closure, and decisions made in the meeting rather than after it, is consistent.

Conclusion

OEE is a sound metric. The 85% world-class benchmark, first established by Seiichi Nakajima in the 1980s through TPM frameworks, remains a relevant directional target. What has changed is the complexity of the data pipelines that feed it. When those pipelines are clean, automated, and low-latency, OEE earns trust. When trust is fragmented, mutable, and delayed, it erodes regardless of how good the dashboard looks. Fix the pipeline. The dashboard will follow.

For a detailed breakdown of how OEE trust failures trace back to data architecture in Indian manufacturing plants, read the full analysis here: ketsol.ai/blog/oee-trust-problem-manufacturing-daily-review-data-quality.

FAQ

1. What is a good OEE score in manufacturing?

A score of 85% is considered world-class for discrete manufacturing. The global average across industries is 65–70%. In Indian manufacturing, mid-sized plants typically operate between 55–72% OEE depending on sector and digitisation maturity.

2. Why do manufacturers distrust their OEE data?

OEE distrust most commonly traces to three causes: data collected from multiple disconnected systems, downtime records that can be edited after the shift ends, and OEE calculated hours after production so context has already faded by review time.

3. How does IIoT improve OEE accuracy?

IIoT-based OEE monitoring collects machine data automatically via protocols like OPC UA or MQTT, eliminating manual entry errors. Real-time calculation means OEE is visible within minutes of each production event, not hours later. This removes the two biggest sources of inaccuracy: human data entry and reporting latency.

4. What causes OEE to be inaccurate?

Common causes include incomplete downtime capture, manually entered production counts that round up or miss small stops, unrealistic ideal cycle times, and quality records that exclude rework. Each distortion is small individually, multiplied across shifts, the gap between reported OEE and actual performance becomes significant.

5. Can small manufacturers in India benefit from OEE monitoring?

Yes. OEE monitoring can start with a few critical machines and scale gradually. Modern IIoT gateways support legacy PLCs without requiring full automation upgrades. The most important first step is automated data capture, even on one line, to establish a trusted baseline.

Author: The Ketsol team, Ketsol builds industrial IoT gateways and manufacturing intelligence platforms for plants across India. ketsol.ai