The discussion about edge computing in corporate environments tends to revolve around cost — processing locally to reduce cloud bills, filtering data at the edge so as not to transmit what does not need to be transmitted. In the industrial context, this framing is wrong. Edge computing in a factory is not a cost-optimized decision with a viable alternative in the cloud. For a significant set of industrial applications, centralized cloud architecture simply does not meet operational requirements — too latency for process control, data volume too high for continuous transmission, unacceptable network dependency for critical operations. The question is not whether edge or cloud is cheaper. The question is which applications require local processing as a non-negotiable functional requirement, and how to scale the edge infrastructure to support them.
What does millisecond latency mean on the production line
Industrial process control systems — PLCs, DCS, vision systems — operate on time cycles that range from microseconds for motion control to tens of milliseconds for chemical process control. Round-trip latency to a data center in the same city, under favorable network conditions, is typically between 5 and 20 milliseconds. In network conditions with jitter, or with a geographically distant data center, it can easily exceed 50 milliseconds.
For an inspection line computer vision system that needs to reject defective parts before the part passes to the next station, the decision latency needs to be compatible with the line speed. A line cycle of 200 milliseconds per part gives a window of time for the camera to capture, the model to process, and the rejection signal to be sent to the actuator. Subtract the image capture time, actuator actuation time, and safety margin, and the window for processing can be less than 50 milliseconds. No public cloud architecture delivers this latency reliably and consistently.
The same reasoning applies to collaborative robot control systems, emergency stop systems based on sensor analysis, and any application where physical action depends on real-time algorithm decision. In these cases, edge computing is not preferable — it is mandatory. The cost of a decision with excessive latency is not an outdated dashboard. It is a defective part that passed inspection, equipment that did not stop at the right time, or an operation that the network interrupted.
The data volume problem that mathematics solves
A high-resolution industrial inspection camera at 30 frames per second generates approximately 1 to 3 gigabytes of data per hour per camera, depending on compression and resolution. A plant with fifty inspection cameras generates between 50 and 150 gigabytes per hour. In a month of two-shift operation, that's between 24 and 72 terabytes of video. Continuously transmitting this volume to the cloud is not a matter of bandwidth — there are operations that have the bandwidth available for this. It's a matter of cloud storage and processing costs that quickly become unjustifiable when the vast majority of images captured are of flawless parts and do not need analysis.
The model that works is inference at the edge: the computer vision model runs on local hardware, processes each frame and produces only the result — approved or rejected, with a degree of confidence — instead of transmitting the complete image. Images of rejected or low-confidence parts can be sent to the cloud for human review and retraining. The result is that transmission to the cloud goes from gigabytes per hour to megabytes per hour, and the data that reaches the cloud is the data that has value for analysis and model improvement.
High-frequency vibration sensors for equipment condition analysis have a similar profile. Sampling at 10kHz — necessary to detect some categories of mechanical defects — generates volumes of data that do not justify continuous transmission. What makes sense is to calculate the relevant metrics — frequency spectrum, amplitude in specific bands, condition indices — locally, and transmit only these calculated indicators, with the full time series available on local storage for deeper analysis when needed.
Industrial edge architecture: what makes up the stack
The industrial edge environment is not a Linux rack server. It is a hierarchy of computing capacity distributed between the equipment and the cloud, with different levels of processing happening at each layer.
At the closest equipment level are protocol gateways — devices that translate industrial protocols such as Modbus, Profibus, EtherNet/IP and OPC-UA into formats that the rest of the stack can consume. These gateways are often specialized hardware — Moxa, Advantech, Siemens SIMATIC — with firmware designed for the industrial environment: extended operating temperature, fanless, ten-year component life cycle. The cost per unit is higher than equivalent IT hardware in processing specification, but the requirement for reliability in an industrial environment justifies the difference.
One layer above are edge servers — hardware that can run everything from ruggedized industrial PCs to compact GPU racks for inferring computer vision models. Here the choice of hardware depends on the computational load. For processing time series and calculating maintenance indicators, a low-power processor is sufficient. For high-frequency computer vision model inference, industrial GPUs like the Nvidia Jetson AGX or Nvidia's own A2000 line appear in design specifications.
At the software level, the issue of orchestration — how to deploy, update, and monitor applications running on dozens or hundreds of edge nodes — is where most industrial edge architectures have the biggest gap. Kubernetes works, but its operational complexity in OT environments can be excessive for teams without deep experience in container orchestration. Platforms like Azure IoT Edge, AWS Greengrass, and Balena offer simpler abstractions and native integration with corresponding cloud services, but create vendor lock-in that needs to be evaluated in the context of the project.
Physical and logical security in a factory floor environment
Industrial edge computing adds an attack surface to environments that were designed to operate in isolation. An edge server on the factory floor is accessible physical hardware, connected to the OT network, and often managed by IT staff who do not have routine physical access to the space. This creates risks that the centralized data center security model does not address.
Physical security starts with the enclosure — industrial racks with locks and opening monitoring are not paranoia, they are standard practice for any computing equipment in an uncontrolled access area of a plant. Management of physical access to hardware includes control of who can connect USB, remove disk, or reset hardware.
Logical security in an edge environment requires that each edge node be authenticated for communication with the cloud — certificate-based authentication, not shared static credentials. Firmware and software updates need to be digitally signed to prevent installation of malicious software. The network segmentation model should limit what the edge server can access beyond the systems it needs to function — there is no reason for a computer vision inference server to have access to the company's HR system.
How to size and budget edge infrastructure
The most common mistake in industrial edge budgeting is calculating only the cost of the server hardware and ignoring everything around it: the OT network infrastructure that needs to be adapted to support the new traffic, the structured cabling that needs to be installed in environments that were not designed for it, the uninterruptible power system to ensure the edge node does not lose data in a power outage, and the engineering cost for commissioning and integration with existing systems.
A rule of thumb used in industrial edge projects is to budget the total cost of ownership of the edge hardware as two to three times the cost of the hardware itself in the first two years. The difference covers installation, integration, training of the operations team, and the initial adjustment cycle that any new implementation requires. From the third year onwards, the operating cost stabilizes at around 15 to 25% of the annual hardware cost, mainly in software maintenance and preventive replacement of components with a limited life cycle such as UPS batteries and disks.
Also read
- Edge computing: why computing is leaving the cloud and moving closer to the data
- Edge computing: why distributed processing will redefine your architecture
- Edge Computing Architecture: Strategies for Distributed Processing
- Inference at the edge: when running AI on the device makes more sense than in the cloud
- Cities as laboratory: when urban space becomes a testing platform
- Autonomous computing: when the system corrects itself before you notice the error