The quote that starts with “first we replace the controls”
A plant manager asks a simple question — how many hours did that press actually run last month, and why was it down — and gets back a proposal for a controls retrofit, a new network, a platform subscription and eighteen months. The question was worth answering. The proposal answers a different question, which is how to sell a platform. Meanwhile the press has been telling anyone who asks what it is doing, for years, over a port nobody plugged into.
Machine data is not one problem. It is a small stack of separate problems — access, transport, time, naming, storage — and each has a cheap answer and an expensive one. The expensive answers get quoted because they sell as a bundle. What follows assumes the normal floor: some equipment from the last five years, some from the nineties, two or three controls vendors, an ERP that knows what was ordered but not what happened, and a controls engineer who has been burned before.
You are probably here because
- You want downtime and cycle counts and were quoted a controls project
- Someone told you the older machines “cannot be connected”
- You already bought a historian or SCADA package and nobody queries it
- Corporate wants a dashboard and you want the number under it to be right
The five-paths section tells you what is reachable. The clocks section decides whether any of it is usable afterwards.
Five ways to read a machine, cheapest first
Every piece of equipment on your floor sits in one of five tiers. Work down the list in order and stop at the first one that answers the question you actually have.
One: the machine already publishes. A great deal of equipment built in the last decade ships with an open data interface that is switched off or simply unused. Many CNC machine tools support MTConnect, an open, royalty-free standard that presents machine state as XML over plain HTTP — you can read it in a browser. Newer controls of all kinds ship an OPC UA server, standardized as IEC 62541, which is the closest thing this world has to a universal read interface. The first call is not to a systems integrator. It is to the machine builder, asking what this serial number supports and what it costs to turn on. Sometimes the answer is a license key. Sometimes it is already on.
Two: the control system talks, but not in a standard. An Allen-Bradley controller exposes tags over EtherNet/IP. A Siemens S7 answers on its own protocol and, on newer firmware, on OPC UA. Older equipment of every brand very often speaks Modbus TCP, which is simple, unauthenticated and completely readable. Here you put a gateway in the middle: software that speaks the native protocol on one side and publishes something standard on the other. Commercial connectivity servers do this and so do open tools. The work is not the software. The work is finding out which tag holds the thing you want.
Three: you already have a historian or SCADA system. The most overlooked case in the building. A plant buys a SCADA package for alarms and screens, and it has been quietly recording tag history for years into a database nobody has ever run a query against. If this is you, the first project is not a data project at all. It is two days of someone writing SQL against a system you already own and pay maintenance on, and we would tell you that rather than quote you for it.
Four: no network, but there are signals. A 1994 machine with a relay panel will never be connected to anything. It is still observable. A clamp-style current transformer around the main drive feed gives you a load trace, and a load trace separates running from idle from stopped with no wiring into the control at all. A tap on the stack light — through an isolated input, never a splice into a control circuit — gives you the machine's own opinion of its state. A proximity sensor on a cycling member gives you a part counter. None of this says anything about quality or setpoints. All of it gives you availability, which is usually the number the plant manager wanted.
Five: the operator. A tablet or a wired button box at the machine, with four buttons and no keyboard. This gets a bad reputation it does not entirely deserve. Reason codes for downtime have to come from a person no matter how good your instrumentation is, because no sensor knows that the truck was late. The right design uses machine signals for the duration and a human for the cause, and asks the human for as little as possible.
How complete a picture each path gives you — our judgment
Our judgment of how much of a typical downtime-and-throughput question each path can answer on its own. Not a survey. A plant with one instrumented cell and good operator entry beats a plant with full telemetry and no reason codes.
Read-only, and why the controls engineer is right
Every analytics project on a plant floor should be read-only. Not mostly read-only. Read-only, enforced by architecture, stated in writing, and demonstrable to the person who owns the machine.
The reason is not squeamishness. A control system is a safety and liability boundary. If a dashboard project holds write access to a controller and equipment injures somebody or scraps a shift, the investigation now includes your code. The controls engineer who says no to writes is doing exactly their job, and the fastest way to get cooperation is to agree before they have to argue for it.
The same logic runs through the network design. The reference model everybody here uses stacks a plant into levels — sensors and actuators at the bottom, control above them, plant operations above that, enterprise at the top — with a demilitarized zone between operations and enterprise. Data moves up through that boundary; control traffic does not move down through it. The IEC 62443 series formalizes this into zones and conduits, and it is the vocabulary to use when asking a plant network owner for something, because they already have it.
In practice the pattern that gets approved looks like this. A collector sits on the plant side and does all the protocol work. It pushes outbound only, through the DMZ, over a single well-understood channel, and nothing on the IT side ever initiates a connection into the plant network. In high-consequence environments this becomes a hardware unidirectional gateway, so reverse traffic is physically impossible rather than merely disallowed. For most manufacturers, outbound-only publish with no inbound rule is enough — and it is a far easier conversation than asking for a hole in the other direction.
The transport that has already won
For moving the data itself, the pattern that has quietly consolidated is a lightweight publish-and-subscribe broker with an industrial convention on top. MQTT is the transport — small, tolerant of bad networks, built for constrained devices. Sparkplug is the convention that makes it usable for industrial data: how topics are named, how payloads are structured, and how devices announce themselves on connect and are marked dead when they drop. Without something like it, every integrator invents a topic scheme and you get a broker full of strings one person understands.
Two properties matter more than the protocol choice. Store and forward: your plant WAN link will fail, and when it does the collector must buffer locally and backfill on reconnect, or the downtime report will show the machine as perfect during the exact hour everything went wrong. Ask any vendor this directly, including what happens when the buffer fills. Report by exception: publish on change with a deadband plus a periodic heartbeat, so a silent tag is distinguishable from a dead collector. That is the difference between a data volume you can afford and one you cannot, and it costs nothing but configuration.
The clocks are what actually ruins the project
Here is the failure we see most often, and it is almost never discovered until months of data have been collected.
A controller's clock has drifted ninety seconds. Another machine on the same line is off by four minutes the other way. A gateway applies its own timestamp when it reads a tag rather than when the event happened, adding a variable delay. The historian stamps a third time on ingest. Nobody set up a time source on the plant network because nothing on it needed one. Every one of these is individually minor and completely invisible in a dashboard.
Then somebody asks the first genuinely useful question — what was the upstream machine doing in the two minutes before this scrap event — and the answer is noise. Correlation across machines is the whole point of collecting machine data, and correlation is exactly what clock error destroys. You do not find this by looking at the data. You find it by trying to use the data.
The fix is unglamorous and cheap. Put a time source on the plant network and point every device that has a clock at it — controllers, gateways, SCADA server, vision systems. Timestamp events at the source and carry that timestamp through, keeping ingest time as a separate field you can compare against. Ordinary network time synchronization is enough for anything measured in seconds; the high-precision alternative used for motion control is not needed here. Then verify: trigger something observable on two machines and check the records line up. Do this on day one, because doing it in month six makes the first five months decoration.
| Defect | What it looks like | What it costs you later |
|---|---|---|
| Unsynchronized clocks | Nothing. Every dashboard renders fine | Cross-machine correlation is impossible; root-cause work returns noise |
| Timestamp applied at ingest | Slight lag, varying with load | Event ordering inverts under load, exactly when you care most |
| No store and forward | Clean charts with quiet gaps | The worst hours are silently missing from every report |
| Tags named DB12.DBW44 | A working system one person understands | That person leaves and the system becomes unmaintainable |
| Polling everything at high rate | Impressive volume, rising bill | Storage cost grows faster than the value of the answers |
| No machine state model | Raw tags with no meaning attached | Every report re-derives “running” differently and they disagree |
Naming, and the map you build once
A mid-size plant will produce tens of thousands of addressable tags, many of them named things like DB12.DBW44 or N7:21. That is not carelessness — it is what the control platform generates, and for control purposes it is fine, because the person who wrote the logic knows what it means.
For analytics it is fatal, and the failure is delayed. The project works, because the integrator holds the mapping in their head or in an unsaved spreadsheet. Two years later somebody asks why the availability number changed and there is no way to answer, because the meaning of the underlying tags was never written down anywhere durable.
So build a tag map as a file, in version control, from the first week: physical asset, tag address, human name, unit, expected range, sample strategy, and one sentence of what it means. Give assets stable identifiers that survive being moved, and never encode the line into the asset ID. This costs a few hours and it is the difference between a system that lasts and one that has to be rebuilt when a person leaves.
Layer a small state model on top of the raw tags: a short agreed list of machine states — running, idle, setup, blocked, starved, down, off — defined once and computed in one place. Everything downstream reads the state, not the tags. Otherwise every report re-derives “running” from first principles, they disagree by a few percent, and people stop trusting all of them.
What this costs, in shapes rather than numbers
We will not quote you someone else's prices; they vary by region, by machine count and by how your reseller feels about you. The shape of the cost is stable, though, and worth knowing before you take a quote.
Hardware is the small number — an industrial PC, a managed switch, a power supply, some sensors and a panel. It is a real purchase and it is not where the surprise lives.
Software licensing is, and what matters is the shape of the license rather than today's price. Some products charge per server with unlimited tags. Some charge per driver family. Some charge per connection or per tag, in tiers. A per-connection model that looks cheap for a three-machine pilot can become the largest line in the project at machine forty. Get quoted at the machine count you expect in two years, and ask what happens at the next tier boundary.
Integration labor is the largest and least predictable item, and it is dominated by discovery — finding out which tag means what on equipment whose documentation is a binder in a drawer. Budget it per machine family, not per machine: the second identical machine is cheap, the first from a new vendor is not. And there is one item that never appears in the quote and always appears in the invoice, which is who keeps it running. A collector on the plant floor is a production system. Decide who patches and monitors it before you build it, or you will end up with a gateway under a desk that everyone has forgotten about until the day it fails.
What we would not do
- Replace working controls to get data — the retrofit is a controls project with a controls risk profile, and it is rarely what the question needed
- Buy the platform first — the platform decision is much easier after you know which three questions matter and how much data they need
- Connect every machine at once — do the constraint and one comparison machine, prove the number, then scale by family
- Stream high-rate waveform data to the cloud — process spectra at the edge and ship features, not samples
- Ask for write access in an analytics scope — separate project, separate conversation, separate sign-off
- Let the pilot live on a laptop — pilots that succeed become production whether or not anyone decided that
A two-week proof that settles the argument
Before committing to anything plant-wide, run something small enough that failure is cheap and success is undeniable.
Pick one cell, ideally the constraint, because that is where any improvement actually shows up in output. Write down three questions in advance in the plant manager's words: how many hours did it run last week; what were the five longest stops and why; how many parts per running hour against what we think it can do. Instrument only what those three questions require.
Synchronize time before collecting anything. Stand the collector up where production will live. Collect for ten working days across every shift, including a weekend if the plant runs one, because weekend data is where the assumptions break. Then sit with the supervisor and reconcile the machine's version of the week against the paper log. They will not match, and the gap between them is the real deliverable, because it tells you which of your two records is wrong and why.
Bottom line
Most plants can get real machine data without touching a control program, replacing a network or buying a platform first. Call the machine builder before the integrator. Check whether the historian you already own has been recording all along. Keep everything read-only and push outbound only. Fix the clocks on day one. Write the tag map into a file rather than somebody's head. Then prove it on one cell with three questions before spending anything at scale. The plants that get this right are not the ones with the biggest budget; they are the ones that answered a narrow question correctly and then widened it.
Frequently asked questions
For availability and cycle counting, almost always — not through the control system but around it. A current transformer on the main drive feed distinguishes running from idle from stopped, an isolated stack-light tap gives you the machine's own state, and a proximity sensor counts parts. What you cannot get this way is anything internal: setpoints, part programs, measurements, alarm text. If the question is how much it ran and when it stopped, age is not the obstacle people assume.
No, and buying one first is a common and expensive detour. An MES is a good answer to a work-order execution problem — routing, dispatch, genealogy, work instructions. It is an oversized answer to “why is the press down.” Collect the machine data first, and if an MES is still the right shape after a couple of quarters, you will buy a far better-specified one.
Both, split by function. The collector belongs on the plant floor regardless, because it has to keep working when the WAN does not. Where the history and analysis live is a separate decision driven by data volume, by your contractual obligations about where information may be stored, and by whether you have anyone to run a server. If the work involves controlled technical information under a government contract, storage location is a compliance question before it is an engineering one.
Slower than you think. Downtime attribution and throughput need state transitions and counters, which are events rather than a sample rate. Process work needs whatever resolution the process actually varies at, usually seconds. Only vibration and electrical signature analysis need high rates, and those belong at the edge as features rather than streamed raw. Decide the question first; the rate falls out of it.
Often yes. Ask them three things first: can we export our own history in bulk in an open format without their tooling; what happens to our data if we stop paying; what does the license cost at three times our current machine count. If those answers are good, using the system you already own and already train people on is the right call, and we would tell you so.