Machine Condition Data: What to Capture and How to Get It

What is machine condition data?

Machine condition data is the stream of signals a production machine emits about its own state — running, stopped, producing, idling, warming up, faulted — together with the physical parameters that describe how well it is doing those things. Synonyms in common use: machine state data, equipment status data, Maschinenzustandsdaten.

The distinction that matters: machine condition data is not the same as process data. Process data describes what the product is doing inside the machine — temperature, pressure, force, cycle count. Condition data describes what the machine itself is doing — is the drive running, is the safety door open, is the program active, is the reject chute full. In every MES project I've done since 1991, confusing the two has caused more pain than any protocol choice. You need both, they come from different places, and they answer different questions.

What signals actually count as machine condition data?

The first three rows are the ones every serial-production plant needs, without exception. The others are value-adds once the basics are solid. I've seen more plants fail by trying to collect everything at once than by collecting the basics cleanly. Start with run/stop, counts and fault codes. Everything else follows.

How do you actually get machine condition data out of a real production machine?

This is where thirty years of fieldwork pays off, and where most external advice falls apart. Machines in a real plant come in three categories, and the approach is different for each:

• Modern machines with OPC UA server. Anything built after roughly 2015 with a Siemens S7-1500, Beckhoff TwinCAT 3, Rockwell ControlLogix with the OPC UA add-on, or a native OPC UA interface on the HMI. Here the condition data is documented, structured and available over the network. Connection time per machine: 2–4 hours. This is the easy case, and it is still only maybe 20–30% of the installed base in most mid-sized plants.
• Older PLCs without OPC UA but with a network interface. S7-300/400, Rockwell SLC/ControlLogix pre-OPC-UA, Mitsubishi Q-series, Omron CJ. Condition data exists in the PLC but needs to be mapped through a gateway — Kepware, Matrikon, or a native IoT gateway like IXON or Weidmüller. Connection time: half a day to a day per machine, depending on how the PLC addresses are documented. The catch: you need the PLC program documentation, and in brownfield plants it is often missing.
• Old machines without usable network access. Pre-2000 equipment, Simatic S5, machines with proprietary controllers, fully mechanical presses, or anything where the PLC is effectively a black box. Here the answer is a digital-I/O gateway that taps physical signals — cycle lamp, counter pulses, machine-ready contact — without touching the PLC program. IXON IO boxes, Weidmüller u-remote, or custom boards. Connection time: 2–4 hours per machine, no PLC engineer required, no production interruption.

The third case is the one that surprises people. Most plants assume their old machines "can't deliver data." In thirty years of connecting equipment, I've seen that assumption proven wrong almost every time. If the machine has a cycle lamp, a start button and a fault light, it has enough signals to produce meaningful condition data. The wiring is physical; no firmware modification is needed. I've connected machines from 1985 this way, and they produced cleaner OEE data than some of the modern machines next to them.

What's the minimum viable data set?

1. A reliable run/stop signal. One binary signal that is true when the machine is producing and false otherwise. Everything else builds on this.
2. A good-count pulse. One pulse per good part produced, captured at the output of the process, not at the start. In-line rejects must not count.
3. At minimum a total-count pulse, or the ability to distinguish good from reject. The difference between good and total is the scrap rate — and without it, quality metrics are guesswork.
4. Reason codes for stops longer than a threshold. Ideally from the machine's own fault list, captured with timestamp. If the machine can't provide them, operator input via a shopfloor client is the fallback — slower, less reliable, but still better than nothing.
5. A time-stamp source you trust. If the gateway clock and the server clock drift, correlation dies. NTP sync is not optional.

Five signals. That's the whole starter kit. I've seen plants spend six months specifying a 40-signal capture list and never actually collect anything. The plants that succeed start with these five and grow from there once they see value.

What are the most common mistakes when capturing machine condition data?

• Capturing the wrong run signal. Taking "motor running" as "machine producing" is the classic error. A motor can run while the machine is empty, warming up, or cycling without parts. The correct signal is usually "program active AND part in process" — which often requires combining two PLC variables.
• Ignoring micro-stops. A stop under 2 minutes is often not captured at all, or lumped into "running". In most serial processes, micro-stops add up to more lost time than major breakdowns. The data-capture resolution has to be fast enough to catch them — ideally sub-second sampling on state changes.
• Logging only state changes, not durations. If a machine is running for 4 hours, you need one "start" event and one "stop" event, not a state read every 10 seconds. Event-based capture with timestamps is the correct pattern. Polling generates garbage at scale.
• No context data. A run/stop signal without the order, product and operator it belongs to is barely useful. The condition data must join to contextual data — typically from the MES or ERP — before it becomes meaningful.
• Reason-code fiction. A stop reason logged by the operator 40 minutes after the stop is usually wrong. Either capture the reason from the machine's fault list, or force the operator to classify it while the machine is still down. Retrospective classification at shift-end is a well-intentioned lie.
• Overcollection. Sampling every PLC variable at 100 ms because "storage is cheap" produces gigabytes of noise. Capture what you need for the questions you intend to ask. Add signals when new questions appear.

How does machine condition data become useful?

Raw condition data is not insight. The pipeline from signal to value has four stages, and each one is where most initiatives get stuck:

1. Capture — physical signals to digital events, timestamped at source. The gateway layer.
2. Context — joining events to orders, products, operators, shifts. Without this layer, every analysis is an aggregate.
3. Classification — turning raw stop events into reason-coded downtime, turning count pulses into good/scrap/rework. The MES layer.
4. Consumption — dashboards, OEE calculations, Pareto analyses, alerts. The visible output.

The part nobody talks about: stages 1–3 consume roughly 80% of the total effort in a condition-data project, and they are the stages that determine whether stage 4 produces truth or fiction. A beautiful dashboard on top of a dirty data layer is worse than no dashboard at all — it gives decisions a false confidence. I've been called in to plants where the problem wasn't the MES software, it was that the run signal was miswired and nobody had noticed for six months. Garbage at stage 1 becomes very expensive garbage at stage 4.

FAQ

What's the difference between machine condition data and process data?
Condition data describes what the machine is doing; process data describes what the part is experiencing inside the machine. A press has condition data (running, stopped, mode) and process data (ram force, cushion pressure, temperature). Both matter, but they serve different analyses — condition data drives availability and OEE, process data drives quality and capability.

Do I need a PLC program change to capture condition data?
Almost never. Modern PLCs expose data via OPC UA without changes. Older PLCs expose it via Ethernet address mapping without changes. Even machines with no digital interface can be tapped at physical signals — cycle lamp, fault light, counter pulse — via a digital-I/O gateway that never touches the PLC program. In 30 years of brownfield work, I have not had to modify a single customer PLC to capture condition data.

How fast does machine condition data need to be sampled?
State changes need to be captured within 100–500 ms of the event. Process parameters that drift slowly (temperature, pressure) can be sampled every 1–5 seconds. The principle is event-based capture where possible (capture on change), polling only where the signal doesn't support events. Continuous 100 ms polling of everything is overkill and clogs networks.

Can machine condition data be captured without a local server on the shopfloor?
Yes, and in 2026 it should be. A modern IoT gateway buffers locally for a few minutes against network outages and streams directly to the cloud via MQTT or OPC UA over TLS. No local server, no Windows machine in a cabinet, no IT asset on the shopfloor. That was the architectural decision behind SYMESTIC's cloud-native approach, and it's the reason our customers roll out in days rather than months.

How is machine condition data secured?
Three layers. First, the gateway authenticates to the cloud with per-device certificates. Second, traffic is encrypted in transit (TLS 1.3 minimum). Third, the OT network stays isolated — the gateway is the only device that bridges OT and IT, and it does so with outbound-only connections. No inbound port opening into the plant network. This is the architecture most corporate IT departments now require, and it is compatible with every serious cloud-MES offering.

Can old machines really produce OEE-quality data?
Yes. I have connected presses from 1985, CNC machines from 1992 and packaging lines from the late 1990s, all producing cleaner condition data than the modern machines next to them. The reason: older machines have fewer "smart" features to confuse the signal. A cycle lamp that turns on when the machine is running is an honest signal. What matters is the gateway and the signal-mapping discipline, not the age of the equipment.

How does SYMESTIC handle machine condition data capture?
Three paths, one platform. For modern machines, OPC UA cloud-connector pulls condition and process data directly into the SYMESTIC cloud. For older PLCs, MQTT and protocol-translating gateways bridge to the cloud without local servers. For machines without network interfaces, digital-I/O gateways tap physical signals — cycle lamp, counter, fault light — and stream them to the cloud the same way. The condition data flows into Production Metrics for availability and OEE, and into Process Data for parameter monitoring. No PLC intervention, no production interruption, no local server. Typical per-machine connection time: 2–4 hours, done while the machine is running.

Related: OEE · MES · Machine Data Collection · Operational Data Collection · OPC UA · Equipment Availability · Process Data · Predictive Maintenance · Production Metrics · Process Data.

About the author

Martin Brandel

MES Consultant at SYMESTIC. 30+ years in industrial automation — PLC engineering since 1991 (Simatic S5/S7/TIA), project lead for large-scale conveyor and process-engineering installations in Eastern Europe and China, head of automation engineering at SYMESTIC for 11 years. Since 2019 MES Consultant and project lead from first contact to go-live, specialising in brownfield machine connectivity without PLC intervention. Dipl.-Ing. Nachrichtentechnik. · LinkedIn