Two dashboards can look identical and rest on very different records.
Resolution, fidelity, continuity and attribution — the four properties that decide whether a monitoring record is worth relying on when a number is disputed.
Data acquisition is the engineering discipline underneath machine monitoring: sampling, timing, buffering and integrity. It is separate from what the data is used for, and it is where monitoring systems are actually differentiated — two platforms showing the same dashboard can be built on records of very different quality.
This article is about that record. It is deliberately vendor-neutral and does not describe any specific control's interface.
Resolution
How finely time is divided. A record at shift granularity has already discarded micro-stops; a record at second granularity has not.
Fidelity
Whether the record reflects what happened. Interpolated or inferred values are useful, but must be distinguishable from measured ones.
Continuity
Whether gaps exist, and whether they are visible. An invisible gap is far more dangerous than a marked one.
Attribution
Whether an event can be tied to a machine, time, job and operator. Without attribution, analysis is limited to totals.
Sampling interval is a trade between resolution and load. Too coarse and short events vanish; too fine and you generate volume with no analytical value. The right answer differs by machine and by what you are trying to see.
A useful rule is to sample at least twice as often as the shortest event you need to detect. If six-minute micro-stops matter, a one-minute interval is comfortable and a ten-minute interval is useless. If you are watching a furnace hold temperature over an eight-hour soak, a one-minute interval is wasteful.
This is why a fixed platform-wide interval is a red flag. A monitoring system should let the interval be set per machine, because a machining centre and a heat-treatment furnace have nothing in common in this respect.
The property most often got wrong.
The alternative — stamping on arrival — produces a record where a two-hour network outage compresses into a single instant, and where nothing looks obviously wrong. This is why an edge device needs its own real-time clock: a device that loses time during a power cut cannot produce a defensible record afterwards.
A monitoring system on an Indian shop floor should assume the network will fail, the power will dip, and a switch will reboot mid-shift. Reliability is not the absence of those events; it is what the system does when they happen.
Buffering at the edge with acknowledged delivery means an interruption produces a delay rather than a hole. The practical test to demand during a pilot is simple and rarely offered: unplug the network cable for ten minutes during a running shift, plug it back in, and check whether the resulting timeline is complete and correctly ordered.
Three kinds of value, and why labelling them matters.
| Kind | Example | How much to trust it | How it should be shown |
|---|---|---|---|
| Measured | A part counter incrementing | High — it came from the machine | Presented plainly |
| Derived | Availability computed from state durations | High, if the inputs are measured | Presented plainly, with the formula available |
| Inferred | Part count estimated from cycle time or current | Moderate — it is a model, not an observation | Labelled as an estimate wherever it appears |
Most monitoring demonstrations show the presentation layer, because that is what looks impressive. The questions that actually distinguish systems are about the record: what interval, set where, stamped when, buffered how, and which values on this screen are measured rather than inferred.
A vendor who answers those four precisely is describing an engineered system. A vendor who redirects to dashboard features may still have one, but you have not yet seen evidence of it.