Getting from machine data to a live dashboard takes five stages: collect signals from the machines, add context (product, shift, standard), compute metrics, display them where decisions happen, and attach a response to every number. Dashboards fail when a stage is skipped, usually context or response, not because the charts were wrong.
Every plant has seen the failure case: a TV on the wall showing numbers nobody looks at, installed with enthusiasm, ignored within a month. The hardware was fine and the software was fine. What was missing was the pipeline behind the screen and the routine in front of it. This post walks the whole path, from PLC tag to a board a supervisor actually runs the shift from, and covers the specific ways the path breaks.
What Does It Take to Turn Machine Data Into a Dashboard?
Five stages, each with a distinct job. Collection gets raw signals out of PLCs and sensors through an edge layer, covered in edge connectivity in manufacturing. Context joins each signal to what the plant was doing: which product, which shift, which crew, what the standard rate is. Computation turns contextualized signals into metrics, counts against plan, availability, rate against standard, the OEE calculation. Display puts the metrics where the audience works, in the form the audience needs. Response attaches an expected action to each number: who does what when the number goes red.
The stages are not equally hard. Collection is mostly solved hardware. Display is mostly solved software. The middle, context, and the end, response, are where dashboards are won and lost, because both require decisions about how the plant runs rather than purchases.
Why Do Most Dashboards Fail?
Three ways, all preventable. No context, so numbers cannot be explained. A board that says "Line 3: 68%" invites an argument about the number instead of a decision about the line. The same board showing "68% on Product B, standard rate 120/min, two film jams totaling 41 minutes, reasons attached" ends the argument before it starts. Context is exactly what the operator-record join provides, which is why connecting machines and paperwork is upstream of trustworthy dashboards.
Stale or estimated data, so trust breaks once and never returns. The first time a supervisor catches the board showing a machine running that they can see is stopped, the board is dead. This is an argument for honest plumbing: machine-stamped timestamps, buffered delivery, and no manual re-typing anywhere in the path. It is also an argument against feeding boards from spreadsheets updated at shift end, which produces a report wearing a dashboard costume.
No response attached, so the board becomes wallpaper. A number with no owner and no expected action changes nothing, however accurate. The discipline is old: visual management has always meant displays that trigger behavior, and an andon system is precisely a display with a hard-wired response. The modern dashboard inherits the same rule or inherits the wallpaper fate.
What Belongs on a Floor Dashboard?
Less than fits. For a line-side or supervisor board, four families of information cover the shift, all derived from the short list in machine signals that matter:
Current state per machine: running, stopped, changeover, with the active reason for anything stopped. Output against plan: units made versus where the shift should be by now, not just a raw count. Rate against standard: the quiet loss detector, catching the line running at 85 percent of standard all day. Active exceptions: the stops, the slowdowns, the overdue checks, each with an owner. Everything else, trends, Paretos, comparisons across weeks, belongs one click deeper or on the analysis side of manufacturing analytics, where analysis happens, not on the glass the floor glances at fifty times a shift.
Different audiences need different slices of the same pipeline: the operator needs their machine now, the supervisor needs the shift across lines, the plant manager needs today across the plant. Build one pipeline and cut three views, never three pipelines.
Placement is part of the design, not an afterthought. A wall TV serves ambient awareness for a whole area; a line-side tablet serves the operator who needs to answer a prompt or drill into their machine; a phone view serves the supervisor mid-walk. Readability rules are unforgiving on a factory floor: numbers legible from ten meters, state communicated by more than color alone (a colorblind operator should still read the board), and nothing that requires a login to glance at. If the crew has to walk to an office to see the line's status, the pipeline ends in the wrong room.
How Is a Live Dashboard Different From a Report?
Tense. A report explains what happened; a dashboard shows what is happening, and everything about how each should be built follows from that difference. Reports reward completeness and reconciliation: every number final, every exception explained, formatted for people who were not there. Dashboards reward immediacy and selectivity: the few numbers that change behavior right now, current within seconds, shown to people standing next to the machines in question.
Plants get into trouble when they build one and expect the other's benefits. A dashboard assembled from shift-end spreadsheets is a report on a television. A report generated by screenshotting dashboards is a dashboard losing its context. The clean design uses one pipeline for both: live views read the stream as it flows, and reports are generated from the same records once the shift's events have closed, which is exactly how the reporting burden shrinks. When the record was born complete, the report is a query, not a project.
The same pipeline also feeds escalation. A stop that crosses ten minutes should not wait for someone to glance at the glass; it should page the responder the way an andon cord summons help. Boards are for ambient awareness; escalations are for exceptions that cannot wait. A pipeline that can drive both from one stream is doing its job.
How Do You Build the Pipeline, Step by Step?
- Connect the short-list signals on one line. Run state, counts, rate, fault codes, through an edge gateway with store-and-forward buffering so gaps cannot silently appear.
- Name and place every signal. Plant-hierarchy addresses and plain names, per the conventions in the PLC tag mapping guide, so the dashboard layer asks for Line2/Filler/RunState, not tag 47.
- Join the context at the event. Product from the schedule, shift from the calendar, standard rate from the product master, reasons from operator prompts. Context attached later is context argued about later.
- Compute a small set of metrics with agreed definitions. Write down what counts as downtime, what the standard rates are, and how OEE is calculated; sanity-check definitions against the OEE calculator. Disagreement about definitions is the root of most dashboard arguments.
- Cut views per audience and put them where the audience is. Line-side screen for operators, shift view for supervisors, plant view for managers, one pipeline, three windows.
- Attach a response to every number and review weekly. Who acts on a red, and what do they do? Then prune: any tile nobody acted on in a month comes off the glass.
What Changes When the Board Goes Live?
The shift conversation moves from reconstruction to response. Instead of the morning meeting arguing about what yesterday's numbers were, using yesterday's assembled report, the numbers are simply present, and the meeting spends its time on why and what next; the reporting ritual itself shrinks, as described in production reporting. That was the experience at CLS, a Chattanooga glass decorator: once paper logging became digital capture at the point of work, supervisors could see output, downtime, and disruptions as they happened instead of in the next morning's compilation, and daily reports generated themselves from shift data. The details are in the CLS case study.
Expect a settling-in period, and manage it deliberately. The first two weeks of a live board surface every disagreement the plant has been quietly carrying: whose count is right, what the real standard rate is, whether that recurring five-minute stop is downtime or "just how the machine runs." This is uncomfortable and enormously valuable; every argument the board triggers is a definition getting fixed. Plants that push through this phase end up with numbers nobody disputes. Plants that soften the numbers to avoid the arguments end up with wallpaper again, just more accurate wallpaper.
Getting there did not start with screens. It started with the pipeline, and that is the honest lesson of this whole topic: buy the screens last. Harmony AI builds this pipeline white-glove, engineers on-site connecting machines, mapping signals, and wiring context with your team, on top of the equipment you already run. No rip-and-replace.
Which Standards Keep the Pipeline Honest?
Three references are worth knowing. The ISA-95 standard defines the equipment hierarchy (enterprise, site, area, work center, work unit) that gives every signal and metric its address, and the boundary between control systems and the operations layer where dashboards live. OPC UA (IEC 62541) defines how machines expose data with units and metadata attached, which is what lets a dashboard trust that a rate is a rate. And MQTT (ISO/IEC 20922) is the lightweight publish/subscribe transport that moves changes to the display within seconds without polling everything constantly. None of them are required reading, but a pipeline built on them inherits their discipline, and a pipeline built against them fights it forever.