Fog Computing vs Edge Computing: Architecture Layers Explained

TL;DR:

• Edge computing processes data at or near the source (device, sensor, gateway); fog computing is the intermediate layer between edge and cloud
• Fog nodes aggregate, filter, and pre-process data from multiple edge nodes before forwarding to the cloud
• In practice, many teams use “edge” to mean both — the architectural distinction matters most when you’re designing multi-tier systems at scale

Fog computing vs edge computing is one of those distinctions that practitioners argue about and vendors ignore. Marketing materials use the terms interchangeably, which obscures a genuinely useful architectural framework. The fog/edge distinction describes where processing happens in a distributed hierarchy, and getting that hierarchy right determines latency characteristics, bandwidth costs, and operational complexity for your entire system.

The Three-Tier Hierarchy

The clearest way to understand the difference is to place both in a three-tier model:

Edge computing happens at or immediately adjacent to the data source. A smart camera that runs object detection inference locally, a PLC executing control logic on the factory floor, or an industrial gateway aggregating Modbus sensor readings from 20 devices — these are edge nodes. The defining characteristic is proximity to the physical process.

Fog computing occupies the intermediate tier — an aggregation point between distributed edge nodes and the central cloud. A fog node might receive temperature readings from 500 edge sensors across a building, discard redundant readings, compute 5-minute averages, detect threshold violations, and forward anomalies and summaries to the cloud. The fog layer makes selective decisions about what deserves cloud attention.

Where Fog and Edge Differ in Practice

The confusion arises because a device can be both. An industrial gateway that processes data locally (edge behaviour) and also aggregates data from downstream sensors before sending to the cloud (fog behaviour) is playing both roles. The architecture question isn’t about devices — it’s about which processing happens at which latency tier.

Sub-millisecond requirements (motor control, safety systems) must run on the edge device itself, with no network hop. 1–50ms requirements (anomaly detection, local dashboards, coordinated multi-device control) sit at the fog layer, typically LAN-connected. Anything where 50ms+ is acceptable (historical analytics, model retraining, fleet management) goes to the cloud.

The bandwidth argument drives the fog value proposition. A factory with 1,000 sensors reporting at 10Hz generates 10,000 readings per second. Forwarding all of them to the cloud costs money and saturates uplinks. A fog layer that aggregates, filters to anomalies, and forwards 100 events per second instead of 10,000 has a measurable ROI in reduced bandwidth bills alone — which matters a lot for UK sites on expensive WAN connections.

OpenFog Consortium and Standards

The OpenFog Consortium (now merged into the Industrial Internet Consortium) formalised fog computing as a concept in 2015 and published the OpenFog Reference Architecture in 2017. The reference architecture defines eight pillars for fog nodes: security, scalability, openness, autonomy, RAS (reliability/availability/serviceability), agility, hierarchy, and programmability.

The hierarchy pillar is the most important: OpenFog explicitly supports multi-tier fog hierarchies, where a city-level fog node aggregates from neighbourhood fog nodes, which aggregate from building-level fog nodes, which aggregate from floor-level edge gateways. This cascading aggregation model is how large-scale smart city and utility deployments are actually structured — including smart city projects in Manchester, Bristol, and Milton Keynes.

OpenFog’s work influenced IEEE 1934 (the formal fog computing standard) and fed into the Industrial Internet Consortium’s Architecture Framework. For enterprise deployments, these standards provide reference architectures that vendors and integrators share vocabulary around.

Use Cases by Layer

Typical edge layer use cases include motor protection and shutdown (sub-millisecond, on-device), local control loop execution (PLC, DCS), computer vision inference on a camera (needs local GPU/TPU), and protocol translation (Modbus to OPC-UA).

Typical fog layer use cases include cross-device anomaly detection (correlating events from multiple sensors), local historian (24-hour rolling buffer before cloud sync), edge analytics dashboards for plant operators that don’t depend on cloud connectivity, selective data forwarding based on significance thresholds, and local ML model serving for multiple edge nodes.

When to skip the fog layer entirely: if you have few devices (under 50), adequate cloud connectivity, and latency requirements above 50ms, a two-tier architecture (edge → cloud) is simpler and sufficient. The fog layer adds operational complexity — another tier to monitor, update, and secure — and it’s not worth it if you don’t need it.

Deployment Technology

Edge nodes are typically single-board computers, PLCs, or industrial PCs running lean Linux distributions or RTOS. K3s or bare Docker for containerised workloads; systemd for single-application nodes.

Fog nodes are typically rack-mounted edge servers (Dell PowerEdge, HPE ProLiant EL300) or ruggedised industrial PCs. They’re powerful enough to run Kubernetes (often K3s or MicroK8s) and support multiple container workloads. MEC (Multi-access Edge Computing) platforms from UK telcos essentially standardise the fog node concept for cellular networks — compute infrastructure at cell towers performs the fog aggregation role for connected devices.

The Bottom Line

The fog/edge distinction is architectural, not marketing. Edge is about minimum-latency processing at the data source; fog is about intelligent aggregation before cloud upload. Design your system by working backwards from latency requirements: anything below 10ms must stay on edge hardware, anything that benefits from cross-device context belongs at the fog tier, and everything else can go to the cloud. The distinction matters most when you’re designing for hundreds of edge nodes and need a principled way to decide what gets processed where.