Most industrial IoT projects aren't greenfield builds — they're adding sensing to equipment that's been running for years and was never designed to be instrumented. The first decision is whether to add sensors at all, or just read the data the equipment already has.
When people picture an industrial IoT project, the mental image is often a purpose-built machine with sensors designed in from the start. The more common reality is a motor, pump, or press that's been in service for a decade or more, with no spare I/O, no accessible wiring diagram, and a maintenance team that's understandably wary of anyone opening it up. Retrofitting sensing onto that kind of equipment is a different engineering problem than a greenfield design, and the biggest early decision isn't which sensor to use — it's whether you need to add a sensor at all. This is usually the first real constraint a predictive maintenance program for industrial equipment runs into, before any modeling question comes up.
A surprising amount of older industrial equipment already has usable telemetry, it's just never been extracted. Equipment with a PLC controller often exposes operational data over Modbus, and newer or upgraded installations may support OPC-UA, which is generally friendlier to work with and increasingly the preferred interface where it's available. Before specifying new sensors, it's worth establishing what signals are already available from the existing control system — run status, fault codes, cycle counts, sometimes even analog process values — because reading that data is almost always cheaper, less invasive, and lower-risk than adding new hardware to the equipment itself.
The tradeoff is that PLC/fieldbus data reflects whatever the equipment was originally instrumented to report, which may not include the specific failure modes a new monitoring program cares about. A PLC exposing run/stop status and fault codes doesn't tell you anything about bearing vibration trends if the original system was never wired to monitor that. In that case existing telemetry is a useful head start, not a complete answer.
When the failure mode of interest isn't visible in existing telemetry, non-invasive add-on sensors are usually preferable to modifying the equipment's internals. Current clamps read motor load without any electrical connection to the equipment's wiring, external vibration or acoustic sensors can be mounted to a housing without penetrating it, and surface-mount temperature sensors avoid drilling or tapping into the equipment. These approaches trade some signal fidelity for dramatically lower installation risk and no impact on the equipment's warranty or certification status — both of which matter a great deal to a plant operations team being asked to let someone modify equipment that's core to their production line. Whichever approach is used, the add-on hardware still has to survive the same plant-floor conditions as the equipment it's monitoring — see our note on designing ruggedized IoT hardware for harsh industrial environments.
Invasive retrofits — wiring into a motor's terminal box, adding an inline sensor to a process line — deliver better signal quality but come with real costs: equipment downtime for installation, potential warranty implications, and a much higher bar of trust with the equipment owner. They're usually only worth it when non-invasive options genuinely can't see the failure mode that matters.
Whatever the sensing approach, deployment on an active plant floor comes with constraints that are easy to underweight from an engineering desk. Continuous power isn't always available near the equipment being monitored, which pushes toward battery-powered or energy-harvesting sensor nodes with a real power budget. Wireless connectivity has to contend with a metal-heavy, RF-noisy environment that can behave very differently from an office wireless survey. And physical access for maintenance — battery swaps, sensor recalibration — needs to be planned around the plant's actual maintenance windows, not assumed to be freely available whenever an engineer wants it.
Retrofitting is fundamentally a triage exercise: read what's already there, add non-invasive sensing where existing telemetry falls short, and reserve invasive modifications for cases where nothing less will do. Getting this sequence right avoids both the cost of adding sensors the equipment didn't need and the friction of proposing changes a plant team will rightly resist — and it directly determines whether the resulting data is good enough to support the sensor coverage a predictive-maintenance model actually needs. This is where our embedded hardware and cloud & device platform work typically meet — sensing and connectivity on one side, getting that data somewhere useful on the other — and it's a common starting point for our broader industrial IoT and predictive maintenance engagements.
Our Occupancy & HVAC Optimization Platform case study covers a retrofit deployment onto existing building systems.
