Retrofitting legacy machines: making equipment you already own tell you what it is doing

Replacing working machines is rarely the answer

A great deal of productive equipment was installed before anyone expected it to report anything. It runs, it is paid for, the operators know its habits, and it will probably outlast several generations of the software being proposed to monitor it. Replacing it to gain visibility is an expensive answer to a question that can usually be answered another way.

Industry has a word for this: brownfield, meaning work on sites and equipment that already exist, as opposed to greenfield, where everything is specified new. Brownfield is the normal case. Most industrial IoT work is not building a smart factory from nothing; it is making an existing one legible.

The encouraging part is that machines leak information constantly. They vibrate, they draw current, they get warm, they make noise, and they take a measurable amount of time to do each thing they do. None of that requires the machine’s cooperation to observe.

What you can measure without opening anything

This is the heart of retrofit work. Before considering any connection to a control system, consider what can be sensed from outside it.

Current measurement deserves particular attention because it is unreasonably informative for how easy it is to obtain. A clamp around a supply conductor requires no electrical modification and no change to the machine, and the resulting trace contains the run state, the cycle boundaries, the load profile within each cycle, and a slow trend that reflects mechanical condition. For many machines it is the single most useful thing to measure first.

Reading from what is already there

Where a machine does have a controller, it may already hold data that nothing reads. A PLC, a variable-speed drive or an RTU often exposes an interface, commonly Modbus, sometimes OPC UA on newer equipment, and occasionally something proprietary and sparsely documented.

Using it is attractive because the values are already meaningful: a drive reporting motor load has done the interpretation work for you. Two cautions apply. First, serving data requests consumes controller resources, and on a controller close to its limits that is not free. Second, the register documentation is frequently wrong or missing, so what a register contains has to be established empirically rather than trusted. Our article on OPC UA, MQTT and Modbus covers that in detail, including the addressing conventions that cause most of the confusion.

In practice many retrofits do both: external sensing for mechanical condition, controller data for process values and state, combined at the gateway.

The architecture

The edge gateway does the work that makes the rest possible. It acquires from whatever is connected to it, buffers locally so that a network outage delays data rather than destroying it, translates between what the equipment speaks and what upstream expects, and publishes onward. Putting buffering at the edge rather than trusting the network is what separates a system that survives a plant’s real conditions from one that works during the demonstration.

Read-only, and why it matters more than it sounds

A monitoring system that only reads cannot disturb a control loop, cannot write a wrong setpoint, and cannot be the cause of a stoppage. That is worth a great deal when you are asking permission from people whose responsibility is uptime, and it removes an entire category of risk from the conversation.

Where writing back is genuinely required, it should be a separate decision with its own assessment rather than an extension of a monitoring scope that was approved on the basis of being harmless.

Practical installation questions

These determine whether an installation is straightforward or becomes a project of its own.

Mounting the sensor

For vibration in particular, how a sensor is attached materially affects what it can see. Mounting method determines the frequency range that survives the journey from the machine to the sensing element.

Location matters as much as method. A sensor on the bearing housing sees the bearing; the same sensor on a guard panel a few centimetres away may see mostly the panel. Consistency matters too: for trending to mean anything, the sensor must stay in the same place, which is an argument against magnetic mounting for anything permanent.

Power

Every retrofit device needs power, and this is a more frequent obstacle than the sensing itself. The options, roughly in order of preference where available: a local mains supply, which is simplest and most reliable; Power over Ethernet, where the network reaches the location anyway; a battery, which removes cabling entirely but introduces a maintenance obligation and constrains how often you can transmit; and energy harvesting, which is viable in specific circumstances but should be assessed against the worst case rather than the average. We cover the trade-offs in battery and power engineering.

Getting the data off the machine

Plant environments are not friendly to wireless. Steel structures, moving machinery, welding, drives and dense equipment all interfere. Where a cable can reasonably be run, it remains the most reliable choice. Where it cannot, the options need assessing at the actual installation point rather than from a coverage map; see wireless connectivity selection.

Environment

Retrofit hardware lives where the machines live: coolant, cutting fluid, dust, washdown, vibration, temperature swings and electrical noise. Ingress protection, cable gland selection, connector choice and strain relief are not details; they determine whether the installation is still working in two years or has quietly failed in ways nobody noticed.

What vibration actually tells you

Vibration is the most informative single measurement on rotating equipment, and also the easiest to collect badly. It is worth understanding roughly what practitioners look for, because it explains why sampling rate and mounting matter so much.

A rotating machine produces vibration at frequencies related to what is turning. The running speed itself, its harmonics, the rate at which gear teeth mesh, and a set of frequencies determined by bearing geometry all appear in the spectrum. Different faults emphasise different parts of it.

Two practical consequences follow from this. First, sampling rate must suit the highest frequency of interest. Early bearing degradation shows in high-frequency content long before it affects overall vibration level, so a system sampling slowly enough to capture only running speed and its low harmonics will miss the early warning it was installed to provide. Second, you need to know the running speed to interpret anything, which is one more reason current measurement pairs so well with vibration: it gives you speed and load context for the spectrum.

International standards such as the ISO 20816 series give general guidance on acceptable overall vibration levels by machine class, and they are useful for orientation. They are not a substitute for a per-machine baseline, because two nominally identical machines mounted differently on different foundations will sit at different levels while both being entirely healthy.

What the current trace tells you

Motor supply current is extraordinarily informative for something measurable with a clamp. At the simplest level, current magnitude indicates load, and the envelope of the trace marks cycle boundaries, which gives you run state, cycle duration and idle time without any cooperation from the machine.

Beyond that, the technique generally called motor current signature analysis looks at the frequency content of the current itself. Mechanical problems modulate the load on the motor, and that modulation appears as components in the current spectrum. Rotor bar damage and eccentricity produce characteristic patterns around the supply frequency, and a developing mechanical resistance shows as a slow upward trend in the current needed to do the same work.

The appeal for retrofit is that a clamp at the supply panel sees all of this for one sensor, installed in one place, without touching the machine. Where budget allows only one measurement per asset, current is frequently the one that answers the most questions.

The limitation is resolution. Current tells you that something is loading the motor differently; vibration tells you which bearing. For fault localisation you want both, which is why the common configuration is current on everything and vibration on the assets where a specific failure would hurt most. Choosing between them by machine type is covered in condition monitoring for rotating equipment.

What to measure first

The temptation is to instrument everything. It produces a large bill and a large volume of data nobody has time to interpret, and it delays the point at which anything useful happens. A better approach is to ask what decision you want to make differently, and measure what informs that.

What to measure on common asset types

The general principles narrow down usefully once you know what the machine is. The table below is a starting point rather than a specification, and the right answer always depends on how the asset is used and what failure would actually cost.

Two patterns are worth noticing in that table. Current appears almost everywhere, which reflects how much a motor’s supply reveals about what it is driving. And the second column is usually where the specificity lives: current tells you that something changed, while vibration and pressure tell you what.

Compressed air deserves a particular mention because it is so frequently the cheapest win available. Compressors often run loaded far more than anyone realises, and leaks in the distribution network are invisible, continuous and expensive. Measuring compressor load cycles alongside ultrasonic leak surveys on the distribution side frequently finds consumption that nobody had attributed to anything.

Running the programme

Survey

Establish what each machine is, what it already exposes, what is already instrumented, where power and network reach, and which losses actually hurt. A survey frequently changes what the project should be, which is a good reason to do it before specifying hardware rather than after.

Pilot

Instrument a small number of representative machines. Representative matters more than important: a pilot on your single most critical asset tends to attract caution and scrutiny that slows everything, while a pilot on three typical machines produces transferable evidence faster.

Baseline

Collect continuously and learn what normal looks like for each machine under its own conditions. This is not a formality. Two machines of the same model in the same building routinely have different vibration signatures because of mounting, foundation, load and age, which is exactly why shared thresholds from a datasheet produce either silence or noise.

Alerting

Alert on departures from each machine’s own baseline. Start conservative. A system that cries wolf in its first fortnight is ignored thereafter, and the investment is effectively dead regardless of how good the underlying analysis is.

Review, then scale

Look at what the data actually showed, including the inconvenient parts, and decide whether to extend on the basis of evidence from your own equipment. Scaling a design that has been proven on site is a different proposition from scaling one that was proven in a brochure.

How much data, and what to keep

Retrofit projects generate more data than expected, and storage decisions made casually become expensive at scale.

Raw vibration waveform is the main offender. Capturing a continuous high-rate waveform from many machines produces volumes that are impractical to transmit and costly to retain. The usual approach is to process at the edge, extracting the features that matter, such as overall levels and specific frequency-band energies, transmitting those continuously, and retaining full waveform only around events of interest or on a sampled schedule.

For slower signals, publishing on change with a periodic heartbeat routinely reduces volume by an order of magnitude compared with fixed-interval reporting, without losing anything anyone was going to look at. The heartbeat matters: without it, a value that has not changed and a device that has died look identical.

What drives the cost

We will not quote figures without seeing an installation, but it is worth knowing where cost concentrates, because it is usually not where people expect.

• Integration with existing systems. Commonly the largest and least predictable element, because it depends on what your systems permit and how well documented they are.
• Installation labour and access. Including qualified panel work, cable routing and any production windows required.
• Survey and commissioning. Establishing what registers mean and verifying that readings are correct, which is real engineering time.
• Sensors and gateways. Genuinely a smaller share than most expect.
• Ongoing costs. Connectivity per device, cloud storage and ingestion, which scale with the estate and with reporting rate.

Networking inside a plant

Getting data from the gateway to wherever it is going is frequently more troublesome than the sensing. Industrial environments are actively hostile to radio, and plant networks are often not designed for additional traffic from unfamiliar devices.

A pattern that works well in practice is to aggregate locally and transmit once: sensors connect to a nearby gateway over a short, robust link, and a single wired or cellular connection carries the aggregated data onward. This reduces the number of radio paths that have to work, concentrates the reliability problem in one place where it can be addressed properly, and makes buffering effective because there is a single point at which to buffer.

The organisational question is often harder than the technical one. Adding devices to a plant network means involving whoever owns that network, and the conversation goes better when you arrive with a clear statement of what the devices do, what they connect to, what direction traffic flows, and what happens if they are switched off.

Security when connecting equipment that has none

Older industrial equipment was designed on the assumption that physical access was the security boundary. Connecting it to anything invalidates that assumption, and the equipment itself cannot help you: a controller from the 1990s has no authentication to enable, no encryption to configure, and no patches to apply.

The protection therefore has to come from the architecture around it.

• Segmentation. Operational technology and IT networks separated, with a controlled point between them rather than a flat network where everything can reach everything.
• Direction of flow. Data leaves the control network; nothing initiates a connection into it. An outbound-only pattern removes an entire class of exposure, which is one reason MQTT suits this role.
• Read-only collection. A gateway that cannot write cannot be used to write, regardless of what reaches it.
• Least privilege. Collection accounts with access to exactly the data they need, and nothing else.
• Compensating controls. Where equipment cannot be secured, the surrounding network and access controls carry the load. This is a normal and accepted approach, but it must be deliberate.
• Credential and certificate handling. Including expiry dates recorded somewhere that survives staff turnover.

Formal frameworks exist for this, IEC 62443 being the most cited in industrial contexts, and larger organisations will often have their own standards that constrain the design. Raise them at scoping, because they shape the architecture rather than decorate it. We are engineers rather than a certification body, and where formal assessment is required that is separate accredited work.

Making alerts that get acted on

The technical part of a retrofit is usually the easier half. The part that determines whether the investment produces anything is whether alerts reach a person who can act, in a form they can act on, at a time when acting is still useful.

Several things reliably undermine that.

Alert fatigue. A system that produces false alarms in its first weeks is disregarded thereafter, and regaining that trust is much harder than earning it. Start conservative, tune with real collected data, and accept missing some early events in exchange for the system still being believed in month six.

Delivery to nowhere. An email address nobody monitors, or a dashboard in an office when the person who can act is on the floor. Alerts should arrive in whatever tool the responding team already uses, which usually means integrating with the maintenance system rather than building a new inbox.

Alerts without context. “Vibration high on Press 2” invites a shrug. The same alert with the current value, the baseline, the trend over recent weeks and when it started invites an investigation.

No feedback route. If an engineer investigates and finds nothing, or finds something, that outcome needs to return to the system. Without it the thresholds never improve and the failure history that enables later prediction never accumulates.

Retrofit, replace, or do nothing

It is worth being explicit that retrofit is not always the right answer, and a supplier who never says so should be treated carefully.

A useful test: if a machine failed unexpectedly tomorrow, what would it actually cost, counting lost output, expedited parts, labour and any knock-on effects downstream? Where that number is small, instrumentation is hard to justify. Where it is large and the failure would have shown warning signs, retrofit is usually the cheapest form of insurance available.

What to keep, and for how long

Retention decisions made casually become expensive at scale, and also become difficult to reverse, because you cannot retroactively keep data you discarded.

The last row is the one worth protecting. Sensor data without recorded outcomes is a large collection of numbers about which nothing can be concluded. Sensor data with a history of what was found and when is the foundation of everything a programme might eventually want to do.

Mistakes we see

• Instrumenting everything at once. Large bill, large data volume, no interpretation capacity, slow first result.
• Sampling too slowly to see the phenomenon. The information is simply not in the data afterwards, and no processing recovers it.
• Using shared thresholds across machines. Per-machine baselines exist because machines differ.
• Building an island. A system that measures well and integrates with nothing changes no decision.
• Magnetic mounting left in place permanently. Fine for a survey, unreliable for trending.
• Promising prediction in month one. It sets an expectation that the data cannot meet and damages the programme’s credibility.
• Ignoring who receives alerts. An alert that arrives somewhere nobody looks is not an alert.

Getting it approved inside your own organisation

A surprising share of retrofit projects fail before any hardware is ordered, for reasons that have nothing to do with engineering. The proposal arrives without a named problem, or without the people whose cooperation it needs, or with a business case built on someone else’s numbers.

The approach that tends to work is narrow and concrete. Name one problem that costs money now. Propose measuring a small number of machines for a defined period. Agree in advance what result would justify extending and what result would mean stopping. That last commitment is what distinguishes a proposal from a pitch, and it makes approval considerably easier because the downside is bounded.

Avoid building the case on published figures about typical savings. They were measured in someone else’s plant, on different equipment, with different maintenance practices. Anyone reviewing the proposal knows this, and leaning on those numbers weakens the argument rather than strengthening it. The stronger case is: here is what one unplanned stoppage on this asset cost us last quarter, here is what we propose to spend finding out whether it was foreseeable, and here is when we will decide.

Who needs to be in the room

• Maintenance. They will receive the alerts and they know which machines misbehave and how. Their scepticism is informed and worth hearing early.
• Operations. Any installation touches their schedule, and any floor interface competes with their actual job.
• Whoever owns the network. New devices on a plant network is their decision, and discovering their requirements after ordering hardware is expensive.
• Electrical and safety. Panel access, isolation and permit requirements are not negotiable and are better planned than accommodated.
• Whoever pays. Preferably having agreed beforehand what evidence would justify the next phase.

Choosing a pilot that proves something

The instinct is to pilot on the most important machine. It is usually the wrong choice: the most critical asset attracts the most caution, the most stakeholders and the slowest approvals, and a result there may not transfer to anything else.

A pilot proves more when it covers machines that are typical of the estate, includes at least one machine with a known recurring problem so there is something to detect, and runs long enough to see normal operating variation including different products, shifts and seasons. Two weeks of data in one season tells you less than you think.

Questions worth asking any retrofit supplier

Including us. These separate suppliers who have done this from those who have read about it.

• What will you measure, and why that rather than something else? A specific answer tied to the failures you care about is a good sign. A standard package applied uniformly is not.
• What sampling rate, and what does that let you see? If the answer is vague, the system may be incapable of detecting what it is being sold to detect.
• Does anything write to our equipment? The answer should be no, or a clear explanation of exactly what writes, when and why.
• What happens when the network drops? Buffering depth and behaviour when the buffer fills should be specified, not improvised.
• Who owns the data, and can we export it? Establish this before deployment, not when you want to change supplier.
• What happens if we stop paying? Whether the hardware keeps working locally, and whether historical data remains accessible.
• Can it integrate with the systems we already run? A closed platform creates another island.
• What are you not promising? A supplier willing to state limits is usually more reliable about the things they do promise.

A worked example

A plant with roughly forty machines of mixed age. Eight have modern controllers exposing Modbus TCP. The rest expose nothing usable, and three are old enough that no documentation survives.

A sensible shape: begin with six representative machines, chosen across the age range rather than by importance. Current clamps on all six for run state, cycle timing and load. Vibration on the four with significant rotating elements, adhesive mounted on bearing housings. One gateway per area, buffering locally and publishing over MQTT to a broker on site. Read-only Modbus polling from the eight modern controllers where useful process values exist.

Collect for a defined period to establish baselines. Add conservative alerting. Route alerts into the existing maintenance system so they become work orders rather than emails. Record findings when anything is investigated. Review after an agreed interval with the question: what did this show that we did not previously know, and what is that worth. Then decide about the remaining thirty-four.

How we help

• Survey and assessment. What each machine exposes, what can be sensed externally, and which losses justify instrumentation.
• Sensing design. What to measure, where to mount it and how to condition the signal. See sensor selection and signal conditioning.
• Gateway hardware and firmware. Where the environment or the interface rules out off-the-shelf equipment. See embedded firmware development.
• Protocol work. Including recovering undocumented register maps. See industrial protocol integration.
• Backend and dashboards. Storage, processing and views people will actually open. See cloud and dashboards.
• Integration. Into SCADA, historians and maintenance systems. See SCADA and PLC integration.
• Analysis as history accumulates. See AI for industrial machinery.

Where this usually leads

A retrofit that works rarely stays a retrofit for long. Once a plant can see what its equipment is doing, the questions change. Teams that began by asking whether a bearing was about to fail start asking why one shift produces more stoppages than another, why the same product takes longer on one line, and what the compressors are doing at three in the morning when nothing is running.

That progression is the real return, and it is worth anticipating in the architecture. A system built narrowly around one alert type can be difficult to extend; one built around collecting good data and making it available tends to absorb new questions without redesign. That is the argument for spending time on the data model and the integration rather than only on the sensors, even when the first application is simple.

It is also why the recording habit matters so much. The plant that writes down what it found, every time it investigated something, is the one that can answer the harder questions two years later. The one that only kept sensor readings has a great deal of data and very little history. The hardware that collects it on site is covered in industrial edge gateways. Retrofitting is one layer of a larger structure, described in what industrial IoT actually is.

Questions we are asked about this

Common questions

What clients ask before starting

Do we have to modify the machine?

Usually not. Vibration, supply current, temperature, acoustic signature and cycle timing can all be measured externally, without opening the machine or altering its control system. External sensing is the normal starting point precisely because it avoids disturbing equipment that is working.

Will this void a warranty or a service agreement?

External sensing that does not interfere with the machine generally does not, but it depends on your agreement. Anything involving connection inside the control panel should be checked with the supplier first, and we would raise it rather than assume.

Do we have to stop production to install it?

External sensors usually go on during normal running or a routine break. Work inside a panel needs the supply isolated, so that requires a planned window. Panel work must be done by someone qualified for it under your site rules.

Our machines are from different decades and different makers. Does that matter?

That is the normal situation and it is what gateways exist for. Collection and protocol translation happen at the gateway, so a mixed estate reaches one consistent system regardless of what each machine speaks.

How many machines should we start with?

A small number of representative ones, instrumented properly and collected over a defined period. That produces evidence from your own equipment on which to base the decision about extending, which is far more persuasive internally than a vendor case study.

How long before it is useful?

Alerting on departures from normal typically becomes useful within months, because it needs a baseline rather than a failure history. Predicting specific failures takes longer, because it depends on recording what was found when equipment was investigated.

Can it connect to our existing SCADA or maintenance system?

That is the intention. A retrofit that cannot pass data to anything becomes another island. Interfaces and access levels are agreed at design time; see SCADA and PLC integration.

Is it secure to connect old machines to a network?

The machines themselves usually have no security worth the name, which is why the architecture carries it: read-only collection, segmentation between operational and IT networks, and no inbound path to the control layer. The protection is in the design, not in the equipment.

Start a conversation

Tell us what is on your floor

Describe the machines, their rough age, what you already measure, and which failures or losses cost you most. A short survey usually sharpens the question before any hardware is specified.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in