What Data to Collect from Machines (and What to Ignore)
DBR77 Team · Published
Start by collecting five things from every machine: its state (running, idle or stopped), part counts, cycle time, stop reasons and alarms. Add energy, vibration or process values only when you can name the decision they will change, the person who makes it and the threshold that triggers it.
Everything else can wait. Below you will find which signal supports which decision, and what to leave out at first.
Why "we already have IoT" often changes nothing
When a client tells Paweł Dera, CTO of DBR77, that they already have IoT, he asks one question: "What did you change in the process last month based on data from the system?" The answer is often silence.
Data flows, alerts arrive and the dashboard looks impressive, yet decisions are still made on operator experience and "how we always did it". In most of these plants the data itself is usable. What is missing is an answer to three questions that nobody asked at the start.
McKinsey noted back in 2015 that most IoT data are not used: on an oil rig with 30,000 sensors, only about 1% of the data were examined. Its later research describes "pilot purgatory", where projects stall before they scale.
Three questions to answer before you collect anything
Before choosing sensors or tags, answer three questions for the line in scope:
- Which five metrics actually matter here? Five that the line owner would change a plan for.
- Who is responsible for acting on each one? A named role on the current shift.
- What threshold triggers an action, not just a notification? For example, a stop longer than 5 minutes creates a task for maintenance.
We call the written answers the decision contract. Agreeing on it for one line is the first step in the first 30 days of IoT in a brownfield factory.
Not sure which five metrics fit your line?
In a 30-minute online demo we show the signals DBR77 IIoT starts with and help you sketch the decision contract for one line.
The five signals to start with
These five cover most availability and performance losses and can be read from almost any machine, including old ones without a PLC.
- Machine state. Running, idle or stopped, time-stamped. The backbone of availability and response time.
- Part counts. Total and, where possible, good and rejected parts.
- Cycle time. Actual cycle compared with the ideal cycle time. Vorne defines reduced speed as running slower than the theoretical fastest time to make one part.
- Stop reasons. Picked by the operator at the machine, from a short list, so each stop can be traced to a cause.
- Alarms. Fault codes from the PLC where they exist.
Collect a signal only when you can tie it to a decision and a person. On a typical line:
| Signal | Decision it supports | Who acts |
|---|---|---|
| Machine state (run, idle, stop) | Send someone now, or escalate an unanswered stop | Shift leader |
| Part counts | Adjust the shift plan or add overtime | Production planner |
| Cycle time vs ideal | Check tooling, settings or material on a slow machine | Process engineer |
| Stop reasons | Pick the top loss to fix this week | Line owner, CI team |
| Alarms and fault codes | Dispatch the right technician with the right part | Maintenance |
Reasons matter more than most plants expect. A study of raw OEE data from 884 machines in 23 companies found that nearly half of the recorded losses could not be classified, because loss categories were missing or poorly described. On one corrugated-packaging line, reason capture at the stop (about two seconds per stop) was part of what took OEE from 61% to 70%.
When energy, vibration and process data are worth adding
Energy, vibration, temperature and pressure are useful, but on most lines they belong in a second phase.
Add energy when someone will act on it. For example, a rule that idle machines are switched off after 20 minutes, or a tariff decision on when to run a furnace. ISO 50001 frames energy management the same way: use data to make decisions about energy use.
Add vibration on a few critical assets where failures are expensive and a technician will inspect when a limit is crossed. ISO 20816-1 describes how to measure and evaluate it.
Process values (temperatures, pressures, speeds) belong in scope when they explain scrap on a specific product.
What to ignore at the start
In the first phase, we recommend leaving out:
- Every PLC tag collected "just in case". Thousands of tags slow down setup and bury the five signals that matter.
- High-frequency raw data without a use case. Millisecond sampling on every axis costs storage and attention.
- Metrics nobody owns. If no role is named in the table above, the signal is not ready.
- Long reason lists copied from the ERP. Keep 10 to 15 reasons per machine type, in the operators' words.
- Predictive models before you have a clean event history. Prediction needs months of reliable state and reason data first.
Frameworks such as ISO 22400 define many manufacturing KPIs. You need few of them on day one.
From signals to decisions
A signal becomes useful when it carries context: which order, shift, product and reason. See why machine data is useless without context.
The other half is the response: each alert needs a named recipient and an escalation rule. The article on why IoT alerts fail on the shop floor covers routing and escalation rules that work. The DBR77 IIoT platform turns every alert into a task with an owner, so the third question from the decision contract is answered in the system itself.
FAQ
What is the minimum data to collect from a machine?
Machine state with time stamps, part counts, cycle time, stop reasons and alarms where available. Together they support OEE, response time and a downtime Pareto.
Can we collect this data from old machines without a PLC?
Yes. An edge device can read the stack light, motor current or a cycle sensor to get state and counts. The operator adds the stop reason on a tablet at the machine.
How many metrics should a line track at first?
Five is a good limit. Each one needs an owner and a threshold that triggers action. If you cannot name both, the metric is not ready.
When should we add vibration monitoring?
When a critical asset has expensive failures and a technician is ready to inspect when a limit is crossed. Start with a few such assets.
How do we know the data is being used?
Ask what you changed in the process last month based on the data. If the answer lists concrete actions, the system works as a decision tool.
Conclusion
If your plant already collects machine data, put Paweł Dera's question to your own team: what did you change in the process last month because of it? If nobody can answer, pick one line, write down the decision contract for the five starting signals, and keep energy, vibration and process values for later. The order of work for that line is laid out in the first 30 days of IoT in a brownfield factory.
What would better data be worth on your line?
Enter your shifts, output and current OEE in the ROI calculator to see the value of one OEE point. It takes about three minutes.
Sources
- McKinsey Global Institute, The Internet of Things: Mapping the value beyond the hype (summary), 2015
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- Hedman, Subramaniyan, Almström (Chalmers, Procedia CIRP), Analysis of Critical Factors for Automatic Measurement of OEE, 2016
- Vorne, The Six Big Losses
- ISO, ISO 50001 Energy management
- ISO, ISO 20816-1 Mechanical vibration: measurement and evaluation of machine vibration, 2016
- ISO, ISO 22400-1 Key performance indicators for manufacturing operations management, 2014
- DBR77 IIoT pilot data, corrugated-packaging line (client anonymous), 2026