Workshop data collection: what to collect, how, and what to do with it

The common mistake in workshop data collection is to start with devices, protocols and tag lists. The order should be reversed: decide what to collect, then how, then where the data goes. Skip a step and the usual outcome is money spent and a set of curves nobody reads.

Step one: what to collect

Equipment status. Running, stopped, idle. This is the foundation for everything else; if status is wrong, capacity and utilisation are meaningless.

Counts. Output and cycle time. Output says how much was made, cycle time says how much more could be — together they locate a capacity bottleneck.

Process parameters. Temperature, pressure, speed, torque and other key values. Their value is traceability: when a defect appears you can look back at whether parameters drifted.

Reasons. Downtime causes and defect causes. The cheapest and most valuable class, and the most often skipped. Without reasons, a dashboard says how long a line stopped but never why.

Step two: three routes

Direct connection. The machine has a communication port and is read through a PLC or collection terminal. Most accurate and most real-time, provided the equipment supports it.

Sensors plus a gateway. For older machines, current transformers, photoelectric switches and limit switches infer running state and counts, aggregated by a gateway. Moderate cost; installation method determines accuracy.

Manual reporting. Scanning or entering on a tablet, suited to small batches, high variety and complex operations. Lowest cost; quality depends on discipline.

Comparing the routes

Real projects mix all three: direct connection on critical machines, sensors on the rest, manual reporting at assembly and inspection. The condition is that all three reconcile on the same order and operation numbers, otherwise aggregation needs manual matching again.

Choosing a protocol: OPC UA and Modbus

Modbus is simple and ubiquitous, supported by almost every PLC and instrument, suited to few tags and moderate real-time needs. The drawback is hand-maintained tag lists and little semantics — the protocol does not know whether a register is output or temperature.

OPC UA, standardised as IEC 62541, carries a semantic model: what a value is, its unit, which machine it belongs to. It suits mixed-vendor environments with many tags. The price is greater implementation complexity, and older machines often need a gateway.

The practical rule: few device types and few tags, Modbus is enough; many vendors and long-term expansion, the semantic model saves maintenance effort later, though not wiring time now.

Step three: four links from data to action

1. Collect status, counts, parameters and reasons on one time base.
2. Dashboard with only what the shift must see: plan completion, downtime minutes, the exception list. Beyond ten metrics, nobody looks.
3. Alert on thresholds — one machine stopped over fifteen minutes, an operation below eighty percent of standard cycle time. Few and accurate; alerts that cry wolf are ignored.
4. Work order turning the alert into a task with an owner and a deadline, with the outcome written back.

The fourth is the one most often cut. Many projects stop at the dashboard and end up visible but unmanaged. Whether collection actually runs shows in one number: how long from a stoppage to someone responding.

Five pitfalls

1. Status without reasons. Downtime minutes look good and every monthly review concludes that the cause is under investigation.
2. Clocks out of sync. Machines, gateways and servers on different times make later matching against work orders impossible.
3. Data lost on disconnection. Without local buffering on the gateway, hours of output vanish with the network.
4. Inconsistent tag names. One signal under two names across two tables means manual mapping for every report.
5. No maintenance. Machines change, processes change, tag lists do not, and the system is eventually bypassed.

Three questions before starting

What problem comes first — inaccurate output, too much downtime, or quality traceability? Which three machines or two operations matter most? Who maintains the tag list and the data quality? Answer those and the discussion of devices and budget lands in the right order.

The national standard GB/T 39116-2020 puts gap identification before solution planning, and collection systems fit that logic particularly well: seeing which layer is weak before deciding what to collect costs far less than buying a system and looking for a use. iResearch's 2024 white paper on enterprise data governance also notes silos and inconsistent standards across manufacturing systems; standardising names and a single time base at the collection layer lowers integration cost later.

If your workshop is choosing a collection design, send us the equipment list and the three signals you most want (contact) and we will say which route fits. To see collected data land on one operating screen, look at the T001 manufacturing AI service centre.

In one line: decide what the data is for, then what to collect, then which devices and protocols.