An IIoT edge-fog-cloud architecture uses three functional tiers: processing at the sensor or gateway, distributed processing across a local network, and centralized storage and analytics in the cloud [S1][S2].
The edge tier supports time-sensitive control, the fog tier aggregates and coordinates nearby devices, and the cloud tier handles fleet-wide data retention, analytics, and model development [S1][S4].
Define the three architectural layers
Edge processing occurs at or immediately beside the device that generates data, including a sensor, controller, or local gateway, while fog processing occurs at the local network or campus level [S2][S4]. This distinction matters because edge resources are limited, complex analytical tasks may exceed their capacity, and decisions must be allocated deliberately between the device, fog, and cloud [S2].
A fog node forms the intermediate layer between edge devices and the cloud. It can collect and filter data, normalize selected streams, make deterministic local decisions, and forward only necessary information for long-term storage, analytics, or model training [S1][S4].
The cloud serves as an upper-level data storage and analytics engine that can be accessed directly or indirectly by edge nodes [S4]. Cloud resources offer broad processing and storage capacity, but their remote location can introduce latency, confidentiality concerns, service-level constraints, and availability risks [S2].
Select workloads by latency and data value
Edge nodes are where sensors reside and where real-time processing and decisions occur, while fog nodes connect data from numerous edge devices and permit deterministic decisions for the overall system [S4]. Fog nodes are suited to aggregating several edge devices and applying decisions based on local information, such as pump control, payment acceptance, or tank-level monitoring [S4].
Cloud workloads suit historical retention, broad analytics, cross-site correlation, and model training [S1][S4]. Sending every sensor reading or video frame upstream is unnecessary when fog nodes can filter and reduce traffic before forwarding it [S1]. A useful division keeps operational data local while reserving cloud transfer for records that require wider context or longer retention.
The decision also depends on where supporting data resides. If a local decision requires data held in the cloud, the local system may still need a cloud round trip unless that context is synchronized to the fog layer [S4].
Compare edge, fog, and cloud designs
Edge computing minimizes distance between data generation and processing, reducing network traffic and response delay, but its compute and storage capacity is constrained by device and gateway hardware [S1][S2]. Fog computing expands local resources across a network, supports real-time processing, and reduces cloud dependence, but introduces a larger distributed infrastructure to operate and maintain [S1][S2]. Cloud computing offers the greatest centralization and scalability for storage and analytics, with the corresponding disadvantages of remote processing and greater network dependence [S1][S2].
This comparison explains why edge, fog, and cloud are complementary rather than interchangeable. A 2026 architectural taxonomy identifies cloud-centric, edge-enhanced, fog-layered, and hybrid IIoT models, with hybrid designs combining different tiers according to workload and deployment constraints [S3].
Identify users and unsuitable applications
This architecture fits plants that need deterministic local responses, large sensor populations, and enterprise-wide analytics without forcing every function through one centralized platform [S2][S3]. It also fits sites where edge filtering can reduce cellular traffic and where local processing must continue even if the upstream connection is impaired [S4].
It is less suitable for small installations whose data volume, latency requirements, and analytics complexity do not justify a separate fog layer. In that case, a device gateway plus cloud may be simpler. The three-tier design also becomes a poor choice where homogeneous hardware, centralized patching, and minimal operational overhead outweigh local response requirements [S1].
Cloud computing can suffer from higher latency, which directly affects application performance [S2]. Industrial control should not depend on remote cloud availability when the required decision can be made locally [S4].
Apply the model to operating use cases
In a fuel-station example, the edge handles the user's grade selection and payment type, the on-premise fog controls pumps, accepts payments, and monitors tank levels, and the cloud receives selected payment information [S4]. This illustrates the division of labor without suggesting that every data field must travel through all three tiers.
For vibration monitoring, edge processing can preserve rapid local detection, fog nodes can combine signals across nearby assets, and the cloud can retain histories for fleet-wide analysis. The related Edge vs Cloud Analytics for Vibration Data deployment matrix provides a narrower comparison for this analytics workload.
Fog deployments also fit production environments requiring predictive maintenance, production monitoring, and intelligent decisions [S3]. For batch or historian workloads, local systems can compress and contextualize events before transmission, while centralized storage preserves the broader historical record required for analysis.
Plan for scale, security, and interoperability
A fog layer becomes operationally complex when dozens or hundreds of locations use a mix of gateways, industrial PCs, routers, micro data centers, and vendor-specific platforms. Each platform can introduce a separate operating system, security posture, monitoring toolset, update process, and lifecycle [S1]. Standardization is therefore an architecture requirement, not an administrative afterthought.
Distributed fog designs can improve local storage, resource availability, security, and latency, but they also complicate scalability, consistency maintenance, and infrastructure cost [S2]. IIoT systems must also address interoperability, security, latency, scalability, and the volume of diverse, time-sensitive data generated by sensors and actuators [S3].
Keeping data local limits exposure, but edge, fog, and cloud must still be secured as one system. Wired and wireless interfaces are both valid depending on the use case, and the communication medium should be selected from the latency, bandwidth, availability, cost, and security requirements of the application [S4].
Track placement and performance criteria
A useful architecture review records the processing location for every critical decision, the upstream and downstream data flow, and the behavior during loss of connectivity. It should also identify which data remains local, which records are forwarded, and where historical storage is retained. These checks expose accidental cloud dependencies in control paths that were intended to remain deterministic [S1][S4].
Measure response time at the edge and fog, upstream traffic before and after filtering, and the number of platform types requiring maintenance. Track fog-node availability, cloud dependency for critical actions, patch consistency, and the share of traffic that leaves the site. These measures connect architecture decisions to engineering outcomes rather than treating edge, fog, and cloud as a deployment diagram alone [S1][S2].
The next architecture decision is not whether the cloud is more capable, but which workload must remain deterministic, which context belongs in the fog layer, and which data requires enterprise-wide retention and analytics.