Published March 28, 2026 · 9 min read
Walk into most small and mid-size manufacturing plants and you will find production status tracked on a whiteboard near the supervisor's desk. Shift leads update it every hour or two. By the time the numbers are written down, they are already stale. At the end of the shift, someone transcribes the whiteboard into an Excel spreadsheet. By the time management reviews the spreadsheet the next morning, the data is 12 to 18 hours old.
This lag makes it impossible to react to problems in real time. A machine that went down at 10:15 AM does not show up in the data until the next day. By then, the root cause details are fuzzy, the operator who saw the failure has gone home, and the urgency to fix the underlying issue has faded. Problems that could have been addressed in minutes become recurring losses that persist for weeks.
A real-time production dashboard eliminates this delay entirely. Machine status, OEE, job progress, and downtime events are visible to everyone, everywhere, as they happen. The behavioral change this creates on the shop floor is immediate and measurable: operators respond faster to problems, supervisors make better decisions, and management has the data they need without waiting for end-of-shift reports.
A dashboard that tries to show everything shows nothing useful. The best production dashboards are designed with specific audiences and use cases in mind. Here are the essential elements:
At a glance, you need to see which machines are running, idle, in changeover, or faulted. Color coding is the standard approach: green for running, yellow for idle or changeover, red for faulted or down. This is the manufacturing equivalent of an andon board — the visual management system Toyota pioneered in the 1950s that remains one of the most effective tools for shop floor visibility.
Each machine tile should show the current state, how long it has been in that state, and the active job (if any). A machine that has been idle for 3 minutes is unremarkable. A machine that has been idle for 45 minutes demands investigation.
Each machine (or production line) should display its current shift OEE broken down into Availability, Performance, and Quality. Showing only the combined OEE number is not enough — knowing that OEE is 62% does not tell you what to fix. Seeing that Availability is 71%, Performance is 94%, and Quality is 93% immediately points you toward the downtime problem dragging the number down.
For each machine, show the current work order, the target quantity, the current count (good parts and rejects), and the estimated completion time. Progress bars give operators and supervisors a visual sense of whether a job is ahead, on track, or behind schedule. This information is essential for planning changeovers and coordinating downstream operations.
A scrolling list or timeline of recent downtime events, including duration, reason code (if assigned), and whether the event is still active. This serves two purposes: it creates urgency around active downtime events, and it provides a running log that supervisors can review during shift handovers.
Critical alarms should be prominently displayed — equipment faults, out-of-spec environmental conditions, material shortages, and quality holds. These should be visually distinct from status information so they are impossible to miss.
Running totals for the current shift: total parts produced, total good parts, total scrap, total downtime minutes, and overall OEE. These give context to individual machine metrics and help supervisors assess whether the plant as a whole is meeting daily targets.
A large TV (55" to 75") mounted on the shop floor wall is the most effective way to create shared visibility. Everyone — operators, material handlers, maintenance technicians, supervisors — can see the current state of production without opening an application or walking to a computer. The psychological effect is significant: visible data creates accountability and urgency in a way that data locked in a computer screen does not.
For wall displays, use a small form-factor PC (Intel NUC, Raspberry Pi, or a mini PC) running a browser in kiosk mode. The browser opens the dashboard URL at boot and runs full-screen with no address bar, no taskbar, and no ability for someone to accidentally close it. The display should auto-refresh and recover from network interruptions without manual intervention.
Supervisors, planners, and managers typically access the dashboard from their desk. The same dashboard should work in a standard browser window with the ability to drill down into individual machines, view historical data, and access configuration settings that are not appropriate for the shop floor display.
Plant managers and maintenance staff are rarely at their desks. A responsive dashboard that works on phones and tablets means they can check production status from anywhere — the shop floor, the break room, or their car. Push notifications for critical alarms (machine faults, prolonged downtime, quality holds) ensure that the right people know about problems even when they are not looking at a screen.
The data pipeline from a PLC to a dashboard involves several layers. Understanding each one helps you choose the right architecture and avoid common pitfalls.
You need a defined set of signals from each machine's PLC: machine state (running/idle/faulted), part count, cycle time, reject count, and any additional signals relevant to your process (spindle speed, temperature, pressure, etc.). These signals must be defined in the PLC program and exposed via the PLC's communication protocol.
The two dominant protocols for getting data out of PLCs are OPC-UA and MQTT. OPC-UA is the traditional industrial approach: a server on the plant network collects data from PLCs and makes it available to client applications. MQTT is the newer, lighter-weight approach: an edge gateway on the plant network publishes PLC data to a message broker, which distributes it to any number of subscribers.
For real-time dashboards, MQTT has significant advantages. It is event-driven (data is published when it changes, not polled on a schedule), it is lightweight (minimal bandwidth and processing overhead), and it naturally supports the publish/subscribe pattern that dashboards need. Sparkplug B adds structure and semantics on top of MQTT, providing standardized birth/death certificates, metric definitions, and state management that make it practical for production environments.
Raw PLC signals need to be processed into meaningful metrics. A part count signal incrementing from 147 to 148 needs to be translated into "one good part produced on Machine 3 for Work Order WO-2024-0847." OEE needs to be calculated from the combination of state signals, count signals, and time. This processing layer sits between the raw MQTT data and the dashboard.
The final mile is getting processed data to the browser with minimal latency. WebSocket connections or GraphQL subscriptions allow the server to push updates to the browser as soon as they are available, without the browser polling for changes. This is what enables sub-second update latency — the dashboard reflects machine state changes within 500 milliseconds of the PLC signal change.
Common mistakes that reduce dashboard effectiveness:
The return on investment from a production dashboard comes from three sources:
Faster response to downtime. When everyone can see that Machine 5 has been down for 12 minutes, the response time drops dramatically. Maintenance gets notified immediately instead of when someone walks over and tells them. Studies from the manufacturing consulting industry consistently show that average response time to unplanned stops drops by 30-50% after implementing real-time visibility.
Reduced data collection labor. Supervisors and operators spend significant time manually recording production counts, downtime events, and quality data. Automated dashboards eliminate this manual data entry, freeing up 30 to 60 minutes per shift per supervisor for actual supervisory work.
Better decision-making. When management can see production performance in real time, decisions about overtime, job scheduling, maintenance priorities, and capital investment are based on data rather than gut feel. This is the hardest ROI to quantify but often the most impactful.
PulseMQ is a browser-based production monitoring platform that connects to PLCs via MQTT and Sparkplug B. Data flows from the PLC through an edge gateway to the cloud, where it is processed and pushed to connected browsers via GraphQL subscriptions. The result is a live dashboard with sub-500ms update latency that works on wall-mounted TVs, desktop browsers, and mobile devices.
The platform includes a kiosk mode designed specifically for shop floor displays: full-screen, auto-refreshing, auto-recovering from network interruptions, and configurable to show the machines and metrics relevant to each area of the plant. No login required on display screens. Supervisors can configure what each display shows from their own browser without touching the TV.
Because PulseMQ is cloud-based, there is no on-premises server to install or maintain. The edge gateway (a small industrial PC or Raspberry Pi running the MQTT bridge) is the only hardware on your network. Everything else — data processing, OEE calculation, dashboards, historical storage, and alerting — runs in AWS. See how cloud MES changes the cost equation for small manufacturers.
Live OEE, machine status, job progress, and downtime — on the wall, on your desk, and on your phone. Sub-500ms updates from PLC to browser.
Schedule a Demo