Industrial IoT in practice: what separates pilot projects from full-scale

There is a repeated pattern in industrial IoT projects that any automation engineer a few years into their career recognizes: the pilot works. The ten sensors transmit, the dashboard shows the data in real time, the plant manager gets excited and authorizes the expansion. Six months later, with two hundred sensors installed, the system starts losing data, latency increases, alerts stop arriving at the correct time, and the IT team is fighting with the automation team over who is responsible for which part of the infrastructure. Expansion stalls. The project remains in limbo. The investment does not deliver the projected return. What differentiates companies that can scale industrial IoT from those stuck in pilots isn't technology — it's an architectural decision made before installing the first sensor.

The network problem that the pilot does not reveal

Industrial environments were designed to work with OT — Operational Technology — networks that are physically and logically separated from corporate IT networks. This separation has historical justification: SCADA systems, PLCs and field networks such as Profibus and Modbus were designed for deterministic reliability in environments with electromagnetic interference, not for IP connectivity with the outside world. The result is that most industrial plants have an OT network that has been running for years without problems, and a corporate IT network that connects computers, printers and management systems. Industrial IoT requires the two to talk, and this process is where most projects start to run into problems.

OT/IT convergence is not a cable and a switch. It is a security, governance and architectural project that involves decisions about which data can cross the perimeter between the two environments, with what frequency, with which translation protocol, and with which authentication system. In a pilot with ten sensors, it is possible to create a workaround — a gateway that takes sensor data and publishes it to the IT network without touching the OT network. At scale, this workaround creates single points of failure, latency issues, and attack surfaces that neither OT nor IT teams want to manage.

The right decision happens before the pilot: defining the complete network architecture for the target scale, including the segmentation model, interlayer communication protocols, and the governance model of who operates what. Most companies make this decision after the pilot, when there is already deadline pressure and internal resistance on both sides of the OT/IT divide.

Data volume: what to process where and when

A high-frequency bearing vibration sensor can generate between 5 and 50 megabytes of data per hour. A computer vision camera for quality inspection can generate gigabytes per hour. In a project with hundreds of monitoring points, the mathematics of transmitting data to the central cloud quickly becomes unfeasible — both in terms of bandwidth cost and in terms of latency for applications that require real-time response.

The decision of where to process what needs to be made before scaling the infrastructure. The general model that works at scale distributes processing across three layers: on the device itself or on a local gateway, filtering and pre-processing takes place that eliminates redundant data and detects events that require immediate action. At an edge layer — servers on the factory floor or in a technical warehouse — the most complex analysis processing takes place that does not require sending to the cloud, including anomaly detection models that require low latency. The central cloud houses the history, model training, correlation between multiple plants and executive dashboards.

This division seems obvious when described like this, but most pilots are designed to send everything to the cloud because it's the simplest way to demonstrate the concept. When the project scales and the cost of data transmission appears on the cloud invoice, or when the response latency does not meet the operational requirement, the architectural redesign would cost twice as much as it would have if done from the beginning.

Device management: the problem that grows with the square

Installing a hundred sensors is an engineering project. Managing a hundred sensors over three years is one operation. The difference between the two lies in a set of challenges that do not appear in the demo: updating firmware on devices in the field without interrupting operation, replacing defective devices without losing configuration context, provisioning new devices in an acceptable time, and monitoring the health of the device fleet to detect failure before data is lost.

Projects that reach thousands of devices without an adequate management platform find that the operational cost of maintaining the fleet outweighs the benefit of the analyzes that the project was supposed to deliver. In a plant with a thousand sensors, a defect rate of 5% per year — conservative for hardware in an industrial environment — means fifty replacements per year. If the replacement process involves manually configuring each device, that's engineer time that wasn't in the budget.

IoT device management platforms — AWS IoT Device Management, Azure IoT Hub, or solutions like Balena for embedded Linux environments — exist exactly to solve this problem. But the decision to adopt them from the pilot stage has an implementation cost that is rarely included in the proof-of-concept budget. The result is that the pilot uses manual configuration and homemade scripts, and when the project scales, migration to a suitable platform has to happen with devices already in the field, which is substantially more complex than implementing the platform from scratch.

Security in OT environments: a different problem than corporate IT

Security of OT networks has historically been solved by physical isolation — what cannot be accessed from the outside cannot be attacked from the outside. Industrial IoT connects this environment to the outside world, and devices added to the OT environment have rarely been designed with the same security rigor as industrial equipment that already exists. A temperature sensor with outdated firmware, accessible via IP, is an attack vector that did not exist ten years ago.

The implications are concrete. The attack on Colonial Pipeline in 2021 did not directly compromise OT systems, but the company preemptively shut down systems due to a lack of visibility and confidence in the integrity of the network. In Brazil, power plants, water systems and energy distribution have increasing exposure as they connect more devices to the industrial environment. The cost of an OT security incident is not just production downtime — it is the loss of confidence in the integrity of historical data, which invalidates all the analysis that the IIoT project was producing.

The security model for industrial IoT needs to include network segmentation that limits the impact radius of a compromised device, device authentication by certificate or token that prevents an unauthorized device from entering the network, and anomalous traffic monitoring that detects nonstandard device behavior. This is no different from the enterprise IT security model in principle — it is different in execution, because the OT protocols, acceptable latency for security scanning, and available tools are specific to the industrial environment.

The architectural pattern that scales: What successful companies do differently

Companies that successfully scale industrial IoT share one characteristic: they make the complete architectural decision before installing the first sensor, and they treat the pilot as validation of the architecture, not as a demonstration of technological capability. The pilot is not to prove that sensors work — that is already known. The pilot is to validate that the chosen network architecture, processing, device management and security will handle the target scale.

The other common element is the explicit decision of who operates each layer of the system. In industrial environments, the line between IT and OT is a cultural boundary as much as a technical one. Projects that don't explicitly define which team operates what — and that don't create an escalation model for conflicts between the two teams — discover at scale that the problem isn't technology, it's governance. Who is responsible for the vibration sensor? Who is the edge gateway managed by? When the data does not reach the dashboard, what is the diagnosis process and at what point does the ticket pass from one team to the other?