Machine monitoring: the metrics, the capture methods, and how to design a system that the floor trusts

What machine monitoring measures

Machine monitoring is the automatic capture of equipment state and output — running, stopped, idle, cycle counts, speed, and increasingly health signals — to compute utilisation, OEE and reliability metrics without manual logging. Everything downstream (Paretos, alerts, maintenance triggers, ERP confirmations) depends on the quality of that raw stream. The metrics it should produce, with their standard definitions (ISO 22400 for most):

Metric	Definition	Raw signal needed	What it exposes
Utilisation	Run time ÷ scheduled (or calendar) time	Run/stop state	Capacity actually used
Availability (A)	Run time ÷ planned production time	Run/stop + planned-stop classification	Breakdowns, changeovers, waiting
Performance (P)	(Ideal cycle time × count) ÷ run time	Counts + ideal cycle time	Slow cycles, micro-stops
Quality (Q)	Good count ÷ total count	Good/reject counts	Scrap, rework, startup losses
OEE	A × P × Q (world-class benchmark 85%)	All of the above	Overall effectiveness
Cycle time (actual vs ideal)	Time between consecutive parts	Part signal timestamps	Speed loss, drift, tool wear
MTBF / MTTR	Mean time between failures / to repair	Stop events classified as failures, with durations	Reliability and maintenance responsiveness
Changeover time	Last good part (A) → first good part (B)	Stop events + product change	SMED opportunity
Energy per part	kWh ÷ good count	Power metering + counts	Idle consumption, inefficient settings

Note the dependency: Performance and OEE are only as good as the ideal cycle time you enter. A generous ideal hides speed loss; a theoretical one nobody achieves makes the metric ignorable. Use the best demonstrated sustained rate, and document it.

Capture methods: how the signal gets out of the machine

Method	How it works	Data you get	Best for	Watch out for
PLC tags via OPC UA / Modbus / vendor drivers	Read state, counters and alarms directly from the controller	Rich: states, counts, alarm codes, parameters	Modern lines with accessible PLCs	Needs controls-engineer time; tag mapping per machine; older PLCs may lack the protocol
MTConnect / FOCAS / vendor CNC APIs	Standardised streams from CNC controllers	Execution state, program, spindle load, overrides, alarms	Machining fleets	Controller generation matters; licences on some vendors
Digital I/O taps	Wire a running signal / part-counter output to an I/O module	Run/stop, counts	Any machine with an accessible signal	Electrical work per machine; no reason codes
Current / power clamps	Infer state and cycles from motor current signature	Run/idle/stop, often cycle detection	Old or closed machines, fast rollout	Counting accuracy depends on signature clarity
Vibration / acoustic sensors	Infer state and health from vibration	Run/stop, cycles, condition indicators	Presses, machining, rotating assets	Mounting location matters; calibration per machine
Optical / proximity counters	Detect parts passing a point	Counts, cycle time	Conveyors, packaging, simple parts flow	Dirt, ambient light, double counts
Operator terminal	Operators confirm reasons, quality, changeovers	Context: why, which product, which reject type	Every deployment — as a complement	Must be under 5 seconds per entry or it will be skipped

Most real plants are mixed: a 2023 machining centre next to a 1998 press next to a packaging line with a closed OEM controller. A monitoring system for a mixed-age fleet has to be sensor-agnostic — able to take PLC tags where available and retrofit clamps or vibration sensors where not — and treat all of them as the same event stream.

Designing the system: decisions that determine whether it works

• Event model. Define states (running, planned stop, unplanned stop, idle/no demand, changeover) and the rule that decides a state from raw signals — including the micro-stop threshold (how many seconds without a cycle counts as a stop). Write it down; it is the plant's OEE constitution.
• Reason-code taxonomy. Two levels, 10–20 codes at the top level, mapped to the Six Big Losses so Paretos aggregate cleanly across lines.
• Edge buffering. When the network drops, the gateway must keep timestamping events and back-fill later. Otherwise every Wi-Fi hiccup becomes a phantom stop.
• Time source. One clock (NTP) for gateways, terminals and servers; a two-minute drift between a PLC and a terminal makes reasons land on the wrong stop.
• Shift and planned-time calendar. Availability is meaningless without an accurate planned production time per line per day, including breaks and planned maintenance.
• Integration outputs. Confirmations to ERP, work orders to CMMS, events to a data platform. Decide who owns each interface before selecting a vendor.
• Automatic loss classification. Modern platforms use machine learning on the signal patterns to propose reasons for stops, which lifts the share of classified stops without adding operator burden — the difference between a Pareto people argue with and one they act on.

Validating the numbers before anyone sees them

Run a two-week validation on the pilot line before publishing dashboards: (1) compare automatic counts with physical counts per shift (target under 1% deviation); (2) compare detected stops with an observer's stopwatch log for a few hours, especially for micro-stops around the threshold; (3) recompute OEE by hand for one shift from the raw events and match the system to the decimal; (4) check the share of stops with a reason — under about 80%, the Pareto is not yet trustworthy; (5) review the "unknown" bucket weekly and split it. Plants that skip this step spend the next year defending the dashboard instead of using it.

What good looks like

A working machine-monitoring system produces, every shift, a Pareto of losses that the team leader recognises as true, and a trend of OEE components that moves when countermeasures are applied. The magnitude available is illustrated by Hutchinson, where a TeepTrak deployment built on exactly this loss-first approach took OEE from 47% to 72%. For sector context, see our OEE benchmarks by industry, and for the software side, the 2026 platform ranking.

Frequently asked questions

What is machine monitoring?

The automatic capture of equipment state and output — running, stopped, cycle counts, speed and health signals — from sensors or controllers, to compute utilisation, OEE, cycle time and reliability metrics without manual logging.

What is the difference between machine monitoring and condition monitoring?

Production-focused machine monitoring measures output and losses (run/stop, counts, speed) for OEE and utilisation. Condition monitoring measures equipment health (vibration, temperature, current signature) for maintenance. Modern systems increasingly derive both from the same sensors.

How do you monitor old machines without a PLC connection?

With retrofit sensors: current or power clamps on the motor supply, vibration sensors on the frame, optical or proximity counters on the parts flow, or a digital tap on an existing running signal. These capture run/stop, cycles and counts without touching the controller.

Which metrics should a machine monitoring system produce?

Utilisation, Availability, Performance, Quality and OEE, actual vs ideal cycle time, MTBF and MTTR, changeover time, and energy per part — with standard definitions (ISO 22400) so lines and sites can be compared.

How do you validate machine monitoring data?

Compare automatic counts with physical counts per shift, compare detected stops with a manual stopwatch log for a few hours, recompute OEE by hand for one shift from raw events, and track the share of stops with a classified reason (aim above 80%).