A few years back, a facilities manager walked me past a row of rotary screw compressors and a chiller that had been running since before most of his technicians finished high school. Then he said, half joking, “Corporate wants an industrial IoT setup on these things by next quarter. Do I need to buy all new ones?” I told him what I tell almost everyone who asks that question. No. Instead, you need to learn how to listen to the machines you already have.
That is the real heart of industrial IoT. In other words, it is not about buying the shiniest equipment on the trade show floor. Rather, it is about getting useful information out of the motors, pumps, compressors, boilers, and production lines that are already paying your bills, and doing it without shutting the place down for six months.
I have spent most of my career as an IIoT engineer working in buildings and plants that were never designed with connectivity in mind. For example, I have worked in mechanical rooms with no network drops, control panels wired by someone who retired in 2009, and PLCs so old the programming software only runs on a laptop that lives in a drawer. If that sounds like your floor, then this article is for you.
What Industrial IoT Actually Means on a Working Floor
Once you strip away the marketing, industrial IoT is fairly simple. First, you attach or tap into something that measures what a machine is doing. Next, you move that measurement somewhere it can be stored and read. Finally, you use it to make a better decision than you would have made without it.
That is it. Temperature, vibration, current draw, pressure, run hours, cycle counts, and fault codes are the usual suspects. In fact, most of the value I have delivered in the field came from boring data like this, collected consistently and put in front of the right person at the right time.
How Vendors Define Industrial IoT
Similarly, the vendor definitions say much the same thing in more formal language. TeamViewer describes the industrial internet of things as connecting machines, devices, and systems in industrial environments to support real time data, automation, and better decisions. However, what separates it from the smart thermostat in your house is the stakes. Consumer IoT is built around convenience, whereas IIoT is designed for settings where reliability, uptime, and security matter most.
How I Explain Industrial IoT to Maintenance Crews
I like to explain it this way to technicians. Your best technician already does industrial IoT in his head. For instance, he walks past a pump, hears a bearing starting to growl, feels a motor running hotter than usual, and makes a note. Industrial IoT simply gives him those senses on every asset, all day and all night, including the ones tucked behind a wall where nobody walks.
Why Rip and Replace Is the Wrong Industrial IoT Starting Point
Generally, there are two ways people approach a connected facility. The industry calls them greenfield and brownfield. Greenfield means building something new with connectivity baked in from day one. Brownfield, on the other hand, means working with what is already installed.
Almost every client I have ever had is brownfield. As IIoT World points out, most legacy machines and facilities were never designed to connect beyond the plant network. As a result, companies end up choosing between building new plants with native IoT or updating the facilities they already run.
The Hidden Cost of New Equipment
Replacing equipment just to get data out of it rarely makes financial sense. After all, a well maintained compressor or air handler can run for decades. Swapping it for a connected model means capital spending, installation downtime, recommissioning, retraining, and a stack of new spare parts. More importantly, a new machine does not fix a bad data strategy. If you do not know what question you are trying to answer, a brand new connected chiller will simply generate data nobody reads.
Why Retrofitting Wins for Industrial IoT
Retrofitting, by contrast, flips the economics. You spend a fraction of the money, you keep the equipment your people already know how to fix, and you learn what data actually matters before you commit to anything larger. Then, when the day comes that a machine genuinely needs replacing, you will write a much smarter specification because you will know exactly what you want it to report.
The Four Layers of Any Industrial IoT Setup
Every industrial IoT system I have built, from a single pump house to a multi building campus, comes down to four layers. Understanding them, therefore, makes vendor conversations much less confusing.
Layer One: Sensing
This is where the physical world becomes numbers. Sometimes the sensor is already there, buried inside a PLC or a variable frequency drive. Other times you add it, such as a vibration sensor magnetically mounted on a motor housing, a current transformer clamped around a power lead, or a temperature probe on a discharge line.
Layer Two: The Edge
This is a small industrial computer or gateway that sits near the equipment. It collects readings, translates between protocols, filters out noise, and buffers data if the network drops. In my view, a good edge device is the unsung hero of a retrofit, because it lets old equipment speak a modern language without anyone touching the machine’s control logic.
Layer Three: Transport
This is how data travels from the edge to wherever it gets stored. Typically that means wired Ethernet when you can get it, cellular or private wireless when you cannot, and sometimes low power radio for sensors scattered across a large site.
Layer Four: Applications
Finally, there are dashboards, alarms, maintenance work orders, energy reports, and historian databases. This is where people actually see and use the information.
When a project fails, it is almost never because of layer one. After all, sensors are cheap and reliable now. Instead, projects fail at layer four, when the data lands somewhere and nobody’s daily routine changes because of it. So keep that in mind, because I will come back to it.
Industrial IoT Retrofits: Three Ways to Get Data Off Old Machines
This is where industrial IoT gets practical. Specifically, there are three main ways I connect equipment without overhauling the floor, and I usually use a mix of all three in a single facility.
Route One: Add External Sensors
For a standalone machine with no controller worth talking to, I just add sensors from the outside. For example, I might use a vibration and temperature sensor on a motor, a clamp on current transformer to see when a compressor loads and unloads, or a pressure transducer on a header. None of these touch the machine’s control wiring, which means there is no risk of changing how it runs.
As a result, this is the fastest and least risky route. In fact, I have instrumented an entire boiler room in an afternoon this way. Also, for sites where equipment is spread out, such as rooftop units across several buildings or pumps along a long run, low power wide area networks are worth a look because they can connect large numbers of sensors affordably over long distances and through difficult physical conditions.
Route Two: Read From the Controller That Is Already There
If a machine has a PLC or a smart drive, a lot of valuable data already exists inside it. For instance, you can often find run status, setpoints, alarm codes, motor speed, and sometimes even energy consumption. The trick, however, is reading it without disturbing what the controller is doing.
Because so much process information already lives in the PLC, getting those controllers connected is one of the biggest steps toward bringing existing operations into the industrial IoT. In practice, I put an edge gateway on the network, configure it to poll the PLC in a read only fashion, and keep the polling rate gentle. Fortunately, off the shelf gateways make this far easier than it used to be. Softing’s edgeGate, for example, supports controllers including Siemens Simatic, Siemens Sinumerik, Fanuc CNC, Modbus TCP, and Allen Bradley PLCs.
Still, there is one rule I never break: the gateway reads, it does not write. At least not at the start. The moment you let a new system send commands to an old controller, you have changed your risk profile entirely. Consequently, that conversation belongs to the controls engineer and the safety team, not the IoT project.
Route Three: Split the Signal at the I/O
Some older PLCs, however, are already running at their limit. Adding communication load to them is asking for trouble. In those cases, I tap the signals before they reach the controller.
A good example came out of the Industrial Internet Consortium. There, TE Connectivity’s Dr. Michael Hilgner explained that many brownfield PLCs are outdated and cannot handle extra work. Therefore, their approach replaces the existing I/O module with a retrofittable one that produces two independent data streams, one for the PLC’s original job and another for analytics. In addition, IO Link sensors feed a Y gateway that splits the traffic, sending one path to the PLC and the other to the cloud or an IoT platform.
I love this approach for critical equipment because the control path stays exactly as it was. In effect, the PLC never knows the analytics system exists.
Picking an Industrial IoT Protocol Without Getting Lost
Protocol arguments can eat an entire project meeting if you let them. So here is the short version from someone who has had to make all of them work together.
Modbus
Modbus is old, simple, and everywhere. For example, you will find it on drives, meters, boilers, and chillers. However, it is not secure by itself and it does not describe what its data means, so you need a register map and some patience. Even so, it works, and it will keep working.
OPC UA
OPC UA is the modern industrial standard for structured machine data. Unlike Modbus, it carries context with the values, so a temperature reading arrives knowing it is a temperature and what units it uses. It also has proper security built in. For these reasons, when I am bridging controllers into plant systems, OPC UA is my default.
MQTT
MQTT is a lightweight publish and subscribe messaging protocol. As such, it is fantastic for getting data from many edge devices up to a central broker or a cloud platform, especially over unreliable links. Like OPC UA, MQTT also supports encrypted connections, certificates, and user authentication.
How Industrial IoT Protocols Fit Together
In most of my builds, the pattern looks like this: Modbus or a native PLC protocol at the machine, OPC UA inside the facility, and MQTT for anything leaving the building. Meanwhile, the edge gateway acts as the translator in the middle. In short, you do not have to pick one winner. You just have to be deliberate about where each one lives.
Industrial IoT for Home Services and Facility Equipment
People hear “industrial IoT” and picture automotive assembly lines. Yet some of the best returns I have seen came from the equipment that keeps buildings running: HVAC systems, chillers, cooling towers, boilers, booster pumps, air compressors, and backup generators.
This matters a great deal to HVAC contractors, facility service companies, and mechanical maintenance firms. After all, their whole business is keeping someone else’s equipment alive, and they usually find out something is wrong when the customer calls angry. Industrial IoT, however, changes that relationship.
A Real Industrial IoT Example From the Field
Here is a pattern I have deployed more than once. A service company maintains rooftop units and chillers for a group of commercial buildings. First, we add current sensors to the compressors, temperature sensors on supply and return lines, and a small cellular gateway in each mechanical room. Then, within a few weeks, the data starts telling stories.
For instance, one compressor short cycles every afternoon. Meanwhile, a condenser fan draws more current than its twin, which turns out to be a failing motor. Likewise, a chiller runs overnight in an empty building because a schedule was overwritten during a power outage.
None of those findings required new equipment. Nevertheless, all of them saved money, either in energy or in emergency callouts. Moreover, for the service company, it turned a reactive contract into a monitored one, which is a far better business to be in.
The Maintenance Payoff
Maintenance is where the numbers get attention. EMQX, for example, cites a McKinsey study finding that IoT powered predictive maintenance can lower maintenance costs by as much as 30% and reduce downtime by 45%. Of course, I treat figures like that as a ceiling rather than a promise, because results depend heavily on how well your crew acts on the alerts. Even so, a fraction of that improvement pays for a modest sensor rollout quickly.
The Energy Payoff
Energy is the other big lever. In many buildings, mechanical equipment is the single largest electrical load. Consequently, simply seeing run hours and current draw by asset, broken out by time of day, tends to expose waste that nobody knew about. Honestly, I have yet to instrument a mechanical room and find nothing worth fixing.
Pick One Industrial IoT Problem First
The most important decision in any industrial IoT project is not the sensor brand or the cloud platform. Instead, it is choosing the first problem.
To get there, I ask clients three questions:
- Which piece of equipment, when it fails, causes you the most pain?
- What warning signs would a skilled technician look for before it fails?
- Who will receive an alert, and what will they do differently when they get it?
If you cannot answer the third question, then stop. Do not buy anything yet. After all, a dashboard without an owner is just expensive wallpaper.
Good first projects, in contrast, tend to share some traits. They involve a handful of machines rather than the whole site. Also, the failure mode is well understood, and the measurement is straightforward, like vibration on a motor or temperature on a bearing. Above all, there is a person with a name who has agreed to respond to the alerts.
Escaping Industrial IoT Pilot Purgatory
There is a well known trap in this field, and unfortunately I have watched good teams fall into it. The pilot works. Everyone nods at the demo. Then nothing happens for two years.
McKinsey named this problem years ago, and still it has not gone away. Their survey found that fewer than 30 percent of IoT pilots were starting to scale, while 84 percent of companies were stuck in pilot mode for over a year and 28 percent for over two.
Why Industrial IoT Pilots Stall
From what I have seen on the ground, pilots stall for a few predictable reasons. To begin with, the success criteria were never written down, so nobody can say whether it worked. In other cases, the pilot was built on a one off setup that cannot be copied to the next building. Alternatively, the data stayed trapped in a vendor’s dashboard and never connected to the systems people actually use. Alumio makes the same point, noting that many retrofit projects connect machines to a monitoring app and then stop, which simply adds a new data silo on top of the existing ones.
How to Get Unstuck
McKinsey’s advice lines up with my experience. Namely, they recommend starting simple and executing relentlessly, because sustaining momentum requires wins. In plain terms, pick a small problem, solve it visibly, document the result in money or hours saved, and then use that to fund the next step.
In addition, I insist on building the pilot the way I would build the full rollout. That means the same gateway model, the same naming conventions, the same network design, and the same security setup. Otherwise, if the pilot is a science fair project, it will stay a science fair project.
Industrial IoT Security: Do Not Bolt the Internet Onto Your Control Network
This is the section I wish more people read twice. Simply put, connecting operational equipment changes your exposure. For example, a chiller controller was never designed to face the internet, and many older devices have no authentication at all. That is why OT cybersecurity has to be part of the plan from the start.
Start With the NIST Guide
Fortunately, solid guidance exists. NIST’s Guide to Operational Technology Security, Special Publication 800 82 Revision 3, offers direction on securing OT systems while respecting their particular performance, reliability, and safety requirements. Furthermore, it covers typical OT topologies, common threats and vulnerabilities, and recommended safeguards. So if you only read one security document before a retrofit, make it that one.
My Field Rules
That said, my own field rules are simpler:
- Keep control networks and business networks separate, so the edge gateway sits between them rather than bridging them freely.
- Make data flow outward only wherever possible, because the cloud should receive data, not reach into your plant.
- Change every default password on every device, including the gateway itself.
- Use encrypted connections and certificates for anything leaving the site.
- Keep an inventory of every connected device, its firmware version, and who is responsible for it.
- Never let a vendor install a permanent remote access tool unless IT and operations both sign off.
Ultimately, security does not have to slow a project down if you design it in from the beginning. Rather, it becomes painful only when someone tries to retrofit it after the system is already live.
A Realistic First 90 Days of Industrial IoT
When clients ask what a sensible start looks like, I usually sketch out a plan along these lines.
Weeks One and Two: Scope
First, walk the floor. Then pick the first problem using the three questions above. After that, list the equipment involved, what controllers or meters already exist, and where network or cellular coverage is available. Most importantly, identify the person who will own the alerts.
Weeks Three and Four: Select Hardware
Next, choose sensors, one gateway model, and a place for the data to land. At the same time, agree on naming conventions now, before you have fifty tags called “Temp1.”
Weeks Five Through Eight: Install and Observe
Now install, and then let it run quietly. In particular, resist the urge to set alarms on day one. You need a few weeks of normal operating data to know what normal looks like for each machine, since every compressor has its own personality.
Weeks Nine Through Twelve: Act and Report
Afterward, set sensible alarm thresholds based on real baselines. Then route alerts into the tool your maintenance team already uses, whether that is a CMMS, email, or a text message. Also, track every alert and what happened next. Finally, at the end of the period, write a one page summary covering what you found, what it saved, and what you would change.
That summary, in the end, is your ticket to scaling. It turns an experiment into a business case.
Industrial IoT Mistakes I See Over and Over
After enough projects, the same errors show up again and again. Below are the ones that cost clients the most.
Collecting Everything
More data is not better data. For example, sampling vibration a thousand times per second on a fan that fails over months just fills a database. Instead, match the sampling rate to the failure you are trying to catch.
Ignoring the Technicians
The people who fix the equipment know which machines are trouble and why. So if they are not involved from the start, they will quietly ignore the alerts later, and frankly they will often be right to.
Choosing a Closed Platform
Some systems make it very easy to get data in but very hard to get it out. Therefore, ask any vendor how you export raw data and whether they support open protocols like OPC UA and MQTT. If the answer is vague, keep looking.
Forgetting Power and Mounting
I have seen projects delayed for weeks because nobody checked whether there was an outlet in the mechanical room, or because the sensor bracket did not fit the motor frame. To avoid this, walk the site with the installer before ordering.
Skipping the Baseline
Alarms set from a datasheet instead of real operating data produce floods of false alerts. As a result, within a month people mute them. Then the real failure arrives unnoticed.
Final Thoughts on Industrial IoT
Industrial IoT is not a single product you buy. Rather, it is a habit you build: measure what matters, put it in front of someone who can act, and keep improving. In reality, the machines on your floor today are far more capable of participating than most people assume. With a few sensors, a sensible gateway, and a clear first problem, that twenty year old compressor can become one of the best monitored assets in the building.
So start small. Read before you write. Separate your networks. Give every alert an owner. And when someone tells you the only path forward is replacing everything, ask them what question the new equipment will answer that the old equipment cannot. Most of the time, the honest answer is none.
Frequently Asked Questions About Industrial IoT
What is industrial IoT in simple terms?
Industrial IoT is the use of sensors, connected controllers, and software to collect data from machines in industrial and commercial settings. As a result, teams can monitor performance, catch problems early, and save energy. For a deeper primer, see EMQX’s IIoT explainer.
Can old machines really be connected without replacing them?
Yes. In fact, older equipment can be connected with external sensors, by reading data from an existing PLC through an edge gateway, or by splitting signals at the I/O level. For more detail, see IIoT World’s guide to brownfield plants.
What is the difference between IoT and industrial IoT?
Consumer IoT focuses on convenience in homes and personal devices. Industrial IoT, however, is built for environments where reliability, uptime, and safety are critical. TeamViewer’s IIoT overview breaks down the differences clearly.
Which protocol should I use for an industrial IoT project?
Most facilities use a mix: Modbus or native PLC protocols at the machine, OPC UA for structured data inside the plant, and MQTT for sending data to the cloud. For example, Softing’s edgeGate product page shows how a single gateway can bridge these.
How do I keep connected equipment secure?
First, separate control and business networks. In addition, use encrypted connections, change default passwords, and keep a device inventory. Overall, the NIST Guide to Operational Technology Security is the most thorough free reference available.
Why do so many industrial IoT pilots fail to scale?
Common causes include unclear success criteria, pilots built on one off setups, and data that never connects to daily workflows. Fortunately, McKinsey’s guide to avoiding pilot purgatory lays out the factors that separate pilots that scale from those that stall.
References
- McKinsey and Company. Avoid Pilot Purgatory in 7 Steps
- National Institute of Standards and Technology. Guide to Operational Technology (OT) Security, SP 800-82 Revision 3
- National Institute of Standards and Technology. NIST Publishes SP 800-82, Revision 3
- IIoT World. 3 Practical Ways to Transform Brownfield Plants into Digital Factories
- EMQX. IIoT Explained: Examples, Technologies, Benefits and Challenges
- TeamViewer. IIoT Explained: How the Industrial Internet of Things Is Transforming Modern Industry
- Softing Industrial. edgeGate: OPC UA Server and MQTT Publisher Gateway
- Alumio. How IIoT Retrofitting Gets Old Machines Talking to New Systems
- IndustryWeek. Five Steps to Get Out of Pilot Purgatory
- MFG Robots. IIC Testbed Demonstrates IoT Enabled Smart Manufacturing on Legacy PLC Equipment
