A real-time manufacturing dashboard turns machine and production events into a current view of line status, output, downtime, quality, and constraints. “Real time” does not mean every screen needs millisecond updates. It means information arrives quickly and reliably enough for the operational decision being made.

An operator may need a stop reason within seconds. A supervisor may need output and scrap summarized each minute. An executive may only need daily trends. Defining those decisions prevents expensive data collection that no one uses.

From equipment to a browser

The data path usually starts with PLCs, sensors, robots, scales, vision systems, or existing machine controllers. An edge gateway reads approved tags or events through industrial protocols such as OPC UA, Modbus TCP, EtherNet/IP, or a vendor interface. It timestamps, normalizes, and forwards data through MQTT, HTTPS, or another controlled transport to a broker or application service.

A processing layer converts raw signals into business events. A rapidly toggling photoeye is not yet a production count. Logic may debounce the signal, associate it with a product, exclude test cycles, and record a completed unit. Current state may be held in a fast store, while a historian or time-series database preserves trends. The dashboard receives updates through polling, server-sent events, or WebSockets.

Useful metrics and their definitions

Common metrics include good count, total count, scrap, cycle time, changeover time, downtime, throughput, work in progress, and overall equipment effectiveness (OEE). Each requires an agreed definition. For OEE, availability, performance, and quality depend on scheduled time, ideal cycle time, and good units. If departments define planned downtime differently, dashboards will disagree even when the code is correct.

Create a metric dictionary listing formula, source tags, unit, time zone, product context, exclusions, owner, and update frequency. Display the definition near the chart or through a tooltip.

State, events, and context

Machine state is usually inferred from several signals: running, idle, starved, blocked, faulted, changeover, or offline. The system should store both state transitions and duration. Context—work order, SKU, shift, operator, tooling, and recipe—turns equipment data into production information.

Edge buffering matters. If connectivity drops for five minutes, a gateway should queue timestamped events and forward them after reconnection. The server must accept late events without double counting. The dashboard should show data freshness so users can distinguish “machine stopped” from “data connection lost.”

Practical example: packaging line

A packaging line has a filler, labeler, checkweigher, and case packer. The dashboard shows target versus good output, current speed, reject count by reason, and a state timeline for each machine. When the case packer is blocked, upstream equipment may idle. Simply reporting “filler downtime” would point maintenance at the wrong constraint.

The system correlates timestamps and shows that most lost minutes begin at the case packer. Supervisors review the top stop reason by shift, then examine sensor and operator notes. The dashboard supports investigation; it does not replace root-cause analysis.

Alarm design without alert fatigue

Not every abnormal value should page someone. Classify notifications by consequence, required response, owner, and time window. Use persistence or hysteresis so noisy signals do not repeatedly alarm. Group related events, suppress downstream symptoms when a known upstream fault exists, and require an acknowledgement or resolution note for critical alarms.

Measure alarm frequency and response. If an alert is routinely ignored, its threshold or workflow needs revision.

Security and network boundaries

Manufacturing networks should be segmented. Prefer read-only collection where control is not required, do not expose PLCs directly to the internet, and place gateways in an appropriate industrial zone. Use authenticated encrypted connections, device identities, least privilege, patch planning, and outbound-only patterns when possible. Any command path requires stricter risk analysis, interlocks, authorization, and safety review.

Designing screens people can use

  • Show current status, target, gap, and data freshness before decorative charts.
  • Use consistent units and colors; do not rely on color alone.
  • Let users move from plant to line to machine to event detail.
  • Keep wallboard text readable at distance and operator controls touch-friendly.
  • Preserve shift and product filters in shared links.
  • Make unknown and stale data explicit instead of displaying zero.

A staged rollout

Begin with one constrained line and three to five decisions. Validate signals against manual counts, document metric definitions, and run the dashboard beside the current process. Review discrepancies with operators. After data is trusted, add downtime reasons, alerts, and cross-line comparison. Scaling unvalidated tags only produces a larger unreliable system.

KarasTechs builds real-time manufacturing and operations dashboards that connect machine data with useful production context. Related inspection data can be incorporated using the approach described in computer vision for quality inspection.