Your Oldest Machine Is the Easy One: Connecting Legacy Equipment Without Replacing It

Every brownfield connectivity project starts with the same document: a list of machines sorted by age, with the old ones marked "dark" and a cost estimate next to each for making them speak.

That list is the reason the project will take eighteen months instead of six. Not because the estimate is wrong, but because the list is sorted by the wrong column.

1. Industrial Reality Check

A production manager walks a plant with an integrator. Twenty-two machines. The integrator's report comes back a fortnight later: eight machines "connectable", nine "requiring retrofit", five "not economically viable".

The five written off are the oldest on the floor. The verdict feels obvious enough that nobody audits it.

Here is what an audit would have found. Two of those five have a documented register map, a serial port, and a controls engineer three buildings away who still has the manuals in a cupboard. One publishes a standard information model that has been in the machine since it was commissioned, switched off, because nobody ever asked for it. The remaining two emit nothing beyond a set of dry contacts — which is still a signal, and enough to time a cycle and count a part.

Meanwhile, three machines in the "connectable" column did not get connected that year. Not one of them failed on technical grounds. One was under a support contract whose wording made the maintenance lead unwilling to authorise any additional network connection until legal had read it, and legal had a queue. One needed a data option the plant did not own, quoted at a price that needed a capital approval nobody wanted to raise for a pilot. The third was connected, briefly, until the works council asked a question about what was being recorded and the plant discovered it could not answer precisely enough, so the connection was switched off pending a conversation that never got scheduled.

Read that back. The machines that did not get connected were not the dark ones. They were the ones nobody was allowed to touch.

This is the pattern underneath most stalled brownfield programmes, and it is invisible on a spreadsheet sorted by year of manufacture.

2. Why the Problem Exists Structurally

The word "legacy" does a lot of quiet damage here, because it smuggles in a cause.

Call a machine legacy and you have implicitly explained why it is hard: it is old, and old things are limited. The remedy follows automatically — spend money to overcome the limitation, either by replacing the asset or by bolting new hardware onto it. The framing writes the purchase order before anyone has checked whether the limitation is real.

Legacy is not an age. It is a permission state.

A machine is legacy when nobody is willing to authorise reading from it. That is a governance property, not an engineering one, and it correlates with contract status far more strongly than with year of manufacture.

Follow that through and the counter-intuitive part falls out. A control from the mid-nineties frequently sits in the best possible position: its documentation is public or in a cupboard, its support contract expired two decades ago, nobody's warranty is at stake, and the plant's own controls engineer has full authority over it. It is old, unglamorous, and entirely yours.

A machine delivered in the last five years can sit in the worst position. Its data capability is real and often excellent, but it may be a licensed option rather than an included one. Its support agreement may contain language about unauthorised modification that no maintenance lead wants to test on a machine still inside its warranty period. Its integrator may need to be called, scheduled and paid before anything is touched. Every one of those is a permission cost, and permission costs do not appear on a connectivity quotation.

The plant experiences this as "the new machine was harder", finds that absurd, and does not write it down. So the lesson never propagates, and the next site sorts its list by age again.

There is a second structural force worth naming, because it explains why the retrofit answer is so persistently attractive. Bolting a sensor onto a machine requires permission from nobody. It is a purchase, not a negotiation. Faced with a liability conversation of unknown length and a sensor kit with a two-week lead time, a project manager under schedule pressure will choose the sensor kit, and will be able to defend that choice in every meeting except the one that matters eighteen months later.

3. Architecture Deep Dive

Set the age question aside and ask a different one: what does this control already emit, and what would it cost in permission — not in euros — to read it?

That question sorts a machine park into four bands, and the bands are what your architecture has to accommodate.

Band 1 — the control publishes a standard information model

The best case, and more common than most plants assume, because the capability often shipped with the machine and was never switched on. A modern companion specification does not just hand you values; it hands you values with agreed meaning. A spindle load is labelled as a spindle load, in a structure another machine of a different make also uses.

For metalworking machine tools, umati is the standard worth knowing by name. It is the interface built on OPC UA and driven by the VDW, and it exists precisely because the industry got tired of every builder inventing its own vocabulary. Where a machine speaks it, the semantic work is largely done for you.

This is the band to check first, and the one most often skipped. Checking costs an afternoon.

Band 2 — the control exposes values without agreed meaning

Register-based access, typically over Modbus TCP, or a proprietary tag list. You can read a number reliably. What the number means is your problem: register 40012 is an integer, and whether it is a part count, a cycle counter that resets on shift change, or a running total since commissioning is a question for someone with the machine's documentation and a morning to spare.

This band is entirely workable. It relocates the effort from connection to interpretation, and every hour you skip here reappears later as a number nobody trusts.

MTConnect sits between the bands — a read-only-by-design standard with real semantics, common on machine tools, and worth checking for wherever the fleet includes machining centres.

Band 3 — the control emits only physical state

No data interface worth the name. What you have is a set of contacts: the machine is running, the machine is in alarm, the cycle-complete relay pulsed. Wire those into an input module and you can time cycles, count parts and classify machine state.

That sounds like defeat. It is not. Availability and a part count are most of an OEE calculation, and a plant that can compare Machine 4's availability against Machine 17's on the same definition has crossed the line that matters. Perfect fidelity on one machine is worth less than comparable fidelity across the fleet.

Band 4 — nothing at all

Rare, and usually smaller than the first survey claims. Here you are choosing between an added sensor and an honest manual entry. Both are legitimate. The design failure is pretending the manual entry is a measurement, rather than marking it as what it is. If an added sensor is the right answer, the choice of which one is its own discipline — we have set that out in Exploring IoT Sensor Types.

What sits above the bands

Four bands means four levels of fidelity feeding one system, and the architectural question is where the differences get reconciled.

The answer that does not scale is reconciling them in the application — which means every report, every calculation and every screen contains conditional logic about which machine it is reading, and adding machine twenty-three means editing all of them.

The answer that does scale is a canonical signal model: one internal representation of what a signal is, with every protocol adapter's job being to translate into it. A part count from a companion specification, a part count derived from a register, and a part count from a relay pulse all arrive in the same shape. They carry different metadata about their provenance and confidence — that difference is real and must not be flattened — but they are the same kind of object. Nothing downstream needs to know which band a machine came from unless it specifically asks.

This is the unified-namespace argument applied at the point of extraction, and we have written about the backbone it feeds in The Smart Factory Data Blueprint. The protocol trade-offs themselves — where MQTT belongs against OPC UA against Modbus — are set out in MQTT vs OPC UA vs Modbus, and this article deliberately does not re-argue them.

Where we are, stated exactly

Claim discipline matters more in this section than anywhere else, so here is our own position without rounding.

A read-only OT edge with roughly 72 hours of local buffer is what we deploy today. It is shipped, it is the piece we lead with, and the buffer exists because plant networks are interrupted for reasons that have nothing to do with you.

The layer that normalises those protocols into one canonical signal model is built and in testing, and the per-protocol proof differs in a way we would rather print than average out. OPC UA and umati are proven by live reads against a real sample server. Modbus TCP and MTConnect are proven against simulators — not against a real machine on a real floor. So the defensible sentence is that the layer speaks these protocols. The sentence we will not write is that it has been connected to four kinds of machine in production, because it has not.

A vendor-neutral OEE across a mixed fleet is shipped, and it is deliberately described by protocol rather than by machine brand throughout this article. That is not evasion. Naming builders would imply compatibility testing and commercial relationships we have not established, and the machine-tool audience is exactly the audience that would know.

4. Why Most IIoT Initiatives Fail to Scale

Three failure modes recur, and each has a name worth carrying into your next project meeting.

The retrofit reflex

Buying a sensor for a value the control already publishes.

A vibration sensor goes onto a spindle that has reported load since commissioning. A current clamp goes onto a machine whose control exposes power draw. An optical part counter goes onto a machine with a cycle-complete relay.

Every one is defensible in isolation and the cumulative effect is severe: the plant pays for hardware it did not need, installs it inside a machine's envelope where it needs maintenance and calibration, and creates a second version of a number that already existed.

The check is an afternoon of reading a manual before any sensor is specified. It is skipped because reading a manual is not a deliverable and a purchase order is.

The parallel plant

The failure the retrofit reflex leads to.

Your added sensor says the machine made 1,140 parts. The machine's own counter says 1,152. Both are working correctly and measuring subtly different events — one counts optical interruptions and misses two double-feeds, the other counts cycle completions including two scrapped at inspection.

The plant now has two truths and no tie-breaker. Worse, it has two truths that are close enough that nobody notices for months and far enough apart to matter at the end of a quarter. Data that disagrees with itself is more corrosive than data that is absent, because absence is honest.

The design rule: for every value, one authoritative source, declared in advance. A second measurement of the same value is a validation input, explicitly subordinate, or it does not get collected.

The snowflake fleet

Each machine connected as its own project, by whoever was available, with its own conventions.

Machine 4's part count is a running total; Machine 9's resets nightly; Machine 12's counts operations rather than parts because that is what the register offered and the contractor did not ask. Each was locally sensible. Collectively they are not comparable, and comparison was the entire objective.

This is why the canonical model has to be decided before the second machine is connected, not after the twentieth. Retrofitting consistency onto a connected fleet is a data-archaeology project, and the plant that needs one usually discovers it during an audit.

Underneath all three sits the same error, which we have written about at length in The Lie of Plug-and-Play IIoT: treating connection as the objective. Connection is the cheap half. Agreement about meaning is the half that determines whether any of it survives contact with a second machine.

5. Governance, Security and EU Compliance Considerations

This is the section that decides whether a brownfield project happens, and it is routinely the shortest slide in an integrator's deck.

The warranty question is an engineering objection

When a maintenance lead refuses to authorise a connection to a machine under support, they are usually right, and treating that refusal as an obstacle to route around is how projects acquire an internal opponent.

The productive move is to make the refusal unnecessary rather than to argue with it. A connection that is read-only by construction — not by configuration, not by policy, but by what the edge component is physically capable of doing — changes the conversation from a liability negotiation into a technical review. "It cannot write" is a claim you should be prepared to demonstrate rather than assert, and a maintenance lead who has watched an integrator's laptop write to a control will want the demonstration.

Get the contract read early, before the survey, not after the pilot. The five machines your integrator marked "not economically viable" cost nothing to leave until phase two. The three you cannot get permission for will hold up phase one.

NIS2 and segmentation

The relevant question under NIS2 is not which protocol you chose. It is who owns the segment, who signs off on the connection, and who answers at three in the morning when it drops.

A read-only edge with local buffering has a specific advantage in that conversation: the data path is one-directional and interruption-tolerant, so the failure mode of a network incident is delayed data rather than an unavailable machine. We have set out the segmentation argument in full in Cybersecurity in the Age of Industry 4.0, and this section is deliberately a pointer rather than a repetition.

The works council conversation

In a German plant this is not a formality, and it belongs before the first cable, not after the first report.

Machine data becomes a workforce question the moment it can be resolved to a person — which, on a single-operator machine on a known shift, is a shorter step than most project plans assume. The design decisions that shorten this conversation are concrete: access scoped to site and role by default; audit reads that fail closed, so a request without a verifiable identity is refused rather than served with a default; and named performance ranking removed outright, with role-level counts subject to a small-count floor.

On machine approval, the honest description matters. Our activation gate governs and records which machines are admitted and by whom. It is a governance and audit control, and it should not be described as a network block — the accurate and stronger statement is that no auto-approve path exists anywhere: no field, no timeout, no code path admits a machine without a person doing it.

State that precisely to a works council and you get a conversation. Overstate it once and you get a policy.

6. Decision Framework for Platform Evaluation

Five questions to put to any vendor, including us. They are ordered by how much they discriminate.

1. Show me the read-only guarantee.
Not the setting — the mechanism. What in the architecture makes a write impossible rather than disabled? If the answer is a configuration flag, ask what happens when someone changes it, and whether that change is visible.

2. What happens to my data during a four-hour network outage?
Buffer duration, buffer location, and behaviour on reconnection. Does it backfill in order, and what happens to timestamps? A platform that silently drops a shift is a platform you will not trust after the first outage.

3. Which protocol claims are proven against real equipment, and which against simulators?
Ask for the distinction explicitly, because most vendors do not volunteer it. The answer tells you less about capability than about honesty, which is the more useful signal at evaluation stage. Ours is stated in the architecture section above.

4. What is the cost of machine twenty-three?
If connecting the twenty-third machine costs roughly what the third did, the vendor has a canonical model. If it is quoted as a fresh integration each time, you are buying a consultancy engagement with a licence attached.

5. Can I export my normalised data and take it elsewhere?
The point of a canonical model is a structure you own. If the normalised form is proprietary and unexportable, you have exchanged vendor lock-in at the machine layer for vendor lock-in at the data layer, which is a worse trade because it now covers your whole fleet.

7. Executive Summary — Board-Level Interpretation

For a board, this reduces to four points.

The connectivity estimate on your desk is probably mis-sorted. It is ranked by machine age; the constraint is contractual and organisational permission. Expect the sequence to change materially after a permission audit, and expect some written-off machines to be cheap.

The first spend should be an audit, not hardware. Establishing what each control already emits, and what governs reading from it, is inexpensive and routinely eliminates a meaningful share of proposed retrofit cost. Hardware bought before that audit is the most common avoidable expense in these programmes.

Comparable data across the fleet beats perfect data on one machine. The commercial value is in comparison — which line, which shift, which machine. A programme that achieves high fidelity on three machines and nothing on the other nineteen has not produced a decision-grade view.

The governance conversations are on the critical path. Warranty language, network segment ownership and the works-council discussion determine schedule more reliably than any technical factor. Started early they are unremarkable. Started after the pilot they stop it.

On our own position, so the board can weigh it: the read-only edge with roughly 72-hour buffering and vendor-neutral OEE across a mixed fleet are what we deploy today. The protocol normalisation layer is built and in testing, proven by live reads for OPC UA and umati and against simulators for Modbus TCP and MTConnect. We would rather you hold us to that sentence than to a rounder one.

8. Practical Implementation Checklist

Before anything is bought

1. List every machine with three columns: what the control emits, what governs reading from it, and who can authorise it. Not year of manufacture.
2. For each machine, check the control's own documentation for an information model before specifying any sensor. An afternoon here removes purchases.
3. Identify which machines are under active support or warranty and get that contract language read. This is the longest-lead item and it is not technical.
4. Pick one value — part count is the usual choice — and define it precisely for the whole fleet. Counted at which event, reset when, including or excluding scrap.

First connection

5. Start with a Band 1 machine if you have one. A standard information model gives you a working reference before you meet the hard interpretation problems.
6. Prove the read-only path in front of the maintenance lead. Demonstrate it; do not assert it.
7. Establish the canonical signal model now, with one machine connected. Retrofitting it at machine twenty is a data-archaeology project.

Scaling out

8. Connect a Band 3 machine early — the relay-and-contacts one. It forces the fidelity-metadata question while the design is still cheap to change, rather than at machine fifteen.
9. For every value, declare one authoritative source. Any second measurement is explicitly a validation input.
10. Track cost per machine connected. A flat or falling curve means the model is working; a rising one means you are building snowflakes.

Governance, in parallel throughout

11. Take the works-council conversation before the first report exists, with the scoping and audit behaviour written down.
12. Document segment ownership and the escalation path per connection, while the connection is being made.

Diagnostic Closing Questions

1. For each machine we call dark — is it actually silent, or is it unauthorised?
2. What does each control already publish, and who has checked rather than assumed?
3. Which contract, warranty or support clause actually governs reading from this asset?
4. If a bolted-on sensor disagrees with the machine's own counter, which one wins, and who decided that in advance?
5. Can we demonstrate — not assert — that our connection cannot write to the control?
6. Who owns the network segment, and who answers the page at three in the morning?
7. What is the first number we would trust enough to put in front of the plant manager?

The machines on your floor have been running for decades and will run for decades more. Most of them have been trying to tell you something the entire time.

The question was never whether they can speak. It is whether anyone in your organisation is allowed to listen.