Scaling industrial Internet of Things (IIoT) networks makes an "all-to-cloud" strategy technically and economically unfeasible for large infrastructure projects. Attempting to transmit massive volumes of raw sensor data directly to centralized cloud platforms leads to increased traffic costs and critical dependency on the stability of external network channels.
Modern effective IoT architecture does not attempt to fully replace the cloud with edge computing. It is built on a pragmatic distribution of workloads. For IoT architects, CTOs, and OT managers of industrial enterprises, the choice between Edge and Cloud is based on evaluating latency, data transmission costs, and strict requirements for the autonomy of the technological segment.
Why the "all-to-cloud" concept no longer works for industrial IoT
At the beginning of IoT development, an approach often dominated where data was collected via simple sensors and then sent to a centralized cloud repository for analysis. In practice, however, this approach faces physical limitations in communication channel bandwidth. According to AWS Well-Architected IoT Lens recommendations, proper architecture design at the "device-edge-cloud" level is crucial for long-term system reliability. Errors at this stage lead to difficulties in scaling the infrastructure.
Centralized architecture also creates a single point of failure for local processes. If an industrial control system depends on a cloud service for real-time decision-making, any WAN network failure can lead to equipment downtime or a breach of technological process safety.
Distribution criteria: when processing should remain at the edge level
To determine the optimal level of data processing, an architect must evaluate the system based on several critical parameters. The first is latency. If the response time to an event is critical for local safety loops, calculations must occur exclusively at the Edge level.
The second factor is operational autonomy. The NIST SP 800-82 guide states that in operational technology (OT), system availability is prioritized over data confidentiality. If the connection to the cloud is interrupted, local control loops must continue to function. To achieve this, Edge devices must independently make decisions based on pre-defined rules.
Typical examples of local processing include:
- High-frequency telemetry filtering: local analysis of sensor data at the Edge level allows for anomaly detection and reduces traffic costs before sending aggregated reports to the cloud.
- Local safety loops: implementing control loops critical for safety that must function even in the event of a total loss of connection to cloud platforms.
- Data normalization: using the OPC UA standard to normalize legacy industrial equipment data before performing analytics on edge devices.
The role of the cloud in hybrid architecture: aggregation and model training
Local processing at the Edge does not mean abandoning cloud platforms. The cloud remains necessary for tasks requiring long-term data storage, global coordination, and advanced analytics that exceed the resources of an edge device.
In a hybrid architecture, the cloud receives filtered and aggregated data from many Edge nodes. Predictive maintenance models can be trained on these historical datasets. Subsequently, optimized versions of these models are deployed to Edge devices to perform fast local analysis.
Security and compatibility: IT/OT integration according to ISA/IEC 62443 and OPC UA standards
Combining industrial networks with cloud analytical systems requires robust protection. The ISA/IEC 62443 series of standards covers cybersecurity for industrial automation across more than 20 industries, requiring clear segmentation of IT/OT networks. This is a fundamental requirement to prevent direct unauthorized access to technological equipment.
OPC UA plays an important role in integration. As noted by the OPC Foundation, it acts as a platform-independent architecture for normalizing machine data before its transmission to edge analytical systems or the cloud. This ensures the interoperability of different types of equipment within a secure circuit.
| Analysis criterion | Edge level (Periphery) | Cloud level (Cloud) |
|---|---|---|
| Latency | < 10 ms (critical for local safety loops) | > 100 ms (acceptable for trend monitoring) |
| Data volume and traffic | Filtering and compression of raw high-frequency data | Storage of aggregated historical data and metadata |
| Autonomy (Offline) | Full functionality of local scenarios during connection loss | Dependency on WAN channel stability |
| Computational complexity | Simple rules, anomaly detection, basic cleaning | Heavy analytical models, wear prediction |
| Security (IT/OT) | Processing within a secure OT perimeter (ISA/IEC 62443) | Transmission via encrypted gateways without reverse access |
Architectural balance: designing a reliable IoT circuit
Designing a hybrid infrastructure is a custom engineering task. Each enterprise has unique requirements for system availability, a set of legacy interfaces, and security policies.
Expertise in custom IoT/embedded system development and hybrid architecture design is provided by Softengi, a member of the Intecracy Group, an alliance of independent companies linked by partner agreements and share exchanges. Certified under the international artificial intelligence management standard ISO/IEC 42001:2023, Softengi creates systems capable of performing complex analytics (including Computer Vision algorithms) directly on Edge devices without violating the OT network security perimeter.
To build the upper level of such ecosystems—corporate monitoring portals and registries—the technological foundation of the UnityBase platform can be used. This full-stack JavaScript low-code platform is a joint development of Intecracy Group companies (where InBase acts as a key, but not sole, developer). Thanks to Domain metadata mechanisms, automatically generated REST API, and built-in access control tools (RBAC, RLS, audit trail), solutions based on UnityBase allow for the reliable aggregation and visualization of data from thousands of Edge nodes in a secure corporate environment.
FAQ
How to determine which IoT data needs to be filtered at the Edge and which to send to the cloud?
The choice depends on the data's impact on real-time processes and transmission costs. High-frequency telemetry (e.g., vibration) is more efficiently processed at the Edge for immediate anomaly detection, while it is advisable to send aggregated metadata and reports to the cloud for long-term storage and model training.
How does the ISA/IEC 62443 standard regulate data transmission from local Edge devices to cloud platforms?
The standard requires clear segmentation of IT and OT networks to protect industrial systems. Data transmission must be performed securely, without direct access from the corporate or global network to the equipment control loop.
What are the hardware requirements for Edge gateways for data normalization via OPC UA?
The Edge gateway hardware must support the platform-independent OPC UA architecture, possess sufficient resources for local machine data transformation, support interoperability, and ensure the transmission of already normalized data to cloud systems.