Edge vs Fog Computing
Choose between a direct local architecture and an intermediate distributed layer for physical-system workloads.
Edge and fog computing are related placement patterns, not rival product categories. Edge places execution at or near the data source. Fog introduces one or more intermediate nodes that aggregate, coordinate, or serve several edge systems before information reaches a central service. The correct choice depends on topology, autonomy, and the data contract between sites.
Use the terms to describe placement, not branding
Edge computing places acquisition, processing, storage, and local response close to the device or physical process. A single edge node may serve one machine, a cell, a building zone, a camera group, or an entire small site. Its primary responsibility is to keep the local workload useful when upstream services are slow or unavailable.
Fog computing adds an intermediate, distributed layer between field edge nodes and central services. A fog node may be a local site server, a gateway cluster, or a regional hub. It can aggregate selected data from multiple edge nodes, provide site-wide coordination, retain a shared local history, or host services that should remain within the facility or region but do not need to run beside each device.
The terminology is not used consistently across the industry. Some teams use fog for any distributed edge architecture; others reserve it for a multi-tier hierarchy. The architecture is more important than the label: name the local critical path, the intermediate responsibilities, and the central consumers of each flow.
The difference is an intermediate operating layer
| Layer | Typical scope | Primary responsibility |
|---|---|---|
| Device and field network | Sensor, camera, PLC, meter, actuator, machine, or local gateway. | Produce measurements, states, media, or control signals. |
| Edge node | One asset, cell, line, zone, or small site. | Connect locally, execute time-sensitive work, retain local evidence, and apply rules that must survive isolation. |
| Fog node or site hub | Several edge nodes within a facility, campus, vehicle fleet, or local region. | Aggregate selected outcomes, coordinate local services, provide a shared site view, and relay approved information upstream. |
| Central services | Organisation-wide or externally hosted systems. | Support reporting, cross-site analytics, enterprise workflows, long-term aggregation, and collaboration. |
In a pure edge-to-central design, the intermediate row does not exist: each edge node sends its selected outputs directly to the systems that consume them. In a fog design, the intermediate layer has a real operating purpose. Adding it simply because it is available creates another node to secure, monitor, update, and recover.
What changes when a fog layer is introduced
| Decision factor | Direct edge architecture | Edge plus fog architecture |
|---|---|---|
| Data path | Each edge node publishes selected information directly to its consumers. | Edge nodes publish selected information to a local or regional hub, which aggregates, enriches, or relays it. |
| Site-wide coordination | Implemented independently at each node or in a central service. | Can be handled close to the site across several nodes, without placing every decision in the cloud. |
| Local autonomy | Strong per-node autonomy; nodes need no hub for their critical local path. | Edge nodes should remain locally autonomous; fog adds shared services, not a hidden dependency for device-level work. |
| Operational complexity | Fewer layers and simpler routing, but more direct integrations to manage. | Fewer upstream paths from field nodes, but the hub becomes an additional service with capacity and recovery requirements. |
| Data aggregation | Occurs centrally or is limited to each individual edge node. | Can occur within the facility or region, reducing WAN traffic and preserving local context. |
| Failure boundary | A problem at one edge node affects that local workload. | A fog failure can affect shared aggregation or coordination; it must not halt independently designed local edge workloads. |
Introduce a fog layer only when it owns a clear local responsibility
- Several edge nodes need a shared site view. A facility has many cameras, machines, or gateways and operators need an aggregated local picture without waiting for a central system.
- Cross-node correlation matters locally. Events from several nodes must be combined to understand a process, coordinate a response, or eliminate duplicate alarms.
- WAN bandwidth is constrained. The site needs to filter, summarise, or consolidate selected outputs before sending them upstream.
- Local governance requires an intermediate boundary. Data may be shared inside a plant, building, or region while only approved subsets leave that boundary.
- Shared local services are justified. A site needs a broker, historian, notification path, or specialist processing service that several edge nodes can use without placing it in a remote data centre.
A fog node is not automatically the best place for device control or raw high-rate acquisition. The closer a workload is to a device’s timing and failure behaviour, the stronger the argument for keeping it at the edge node that owns the device connection.
Keep the architecture flat when node autonomy is enough
- The site has only one or a few nodes. A hub adds more operational cost than value.
- Nodes do not need to coordinate locally. Each location can publish its selected results directly to the intended consumer.
- Central services already meet the shared need. There is no requirement for facility-local aggregation, and the upstream connection is suitable for the non-critical workload.
- The edge node can host the necessary local service. A device gateway, local storage, rule engine, or broker does not need to be shared across machines.
- Recovery must remain easy for site staff. Fewer layers make ownership, troubleshooting, and change control clearer.
Many successful edge deployments are deliberately flat. They use a repeatable node pattern, publish structured outcomes to the appropriate consumer, and avoid building an intermediate tier until a concrete site-wide requirement appears.
Banalytics is the local edge operating layer first, and an optional fog participant second
In an edge-computing architecture, a Banalytics Agent belongs beside the physical workload. It connects to equipment, runs components and tasks, processes events, retains local data, and exposes a browser-operable system at the site. It can communicate with local services through mechanisms appropriate to the workload, including in-process exchange, shared memory, ZeroMQ, MQTT, and protocol-specific device connections. The transport tiers are described in How Banalytics Works for Industrial Sensing.
| Architecture tier | Banalytics role | Boundary to preserve |
|---|---|---|
| Field edge node | The normal role: connect to local devices, execute tasks, store site data, evaluate events, and apply authorised local actions. | Acquisition and time-sensitive local response must remain independent of a hub or upstream service. |
| Fog or site hub | An optional Banalytics Agent can receive filtered events from several field Agents, apply shared rules, maintain a local event view, or host a site-level integration. | Use it for selected outcomes and shared coordination, not as a compulsory receiver of every raw stream or device poll. |
| Central systems | Banalytics publishes the defined events, measurements, files, or integration messages that external consumers require. | Do not make a remote consumer the source of truth for an edge node's local operating state. |
When several Agents need to share selected events, a Banalytics Agent can also act as a hub for an event flow. The Agent Connector establishes a WebRTC connection to another Agent and becomes an event consumer. Field Agents can forward filtered events to a hub Agent, where further rules, notifications, or a local event history can be applied. This is a practical fog-like pattern for selected events; it should not be interpreted as an instruction to mirror every raw stream to a central node.
A local MQTT broker can serve a similar site-wide message role for clients that use MQTT. The MQTT Server runs inside an Agent and supports a local publish/subscribe path. Define topic ownership, authentication, persistence, and capacity before treating it as shared plant infrastructure. Banalytics is not a replacement for a PLC or dedicated safety system, and it should not be positioned as a general-purpose regional cloud platform; its value is the local operational boundary and the explicit integrations around it.
Keep the critical path below the aggregation layer
- Define the local critical path first. Identify the device interactions, storage, processing, and actions that must remain available even if the hub or upstream service fails.
- Assign the fog node one explicit job. Examples include local event aggregation, a shared broker, site reporting, or cross-node correlation. Avoid a vague “central edge server” role.
- Publish selected outcomes, not every input. Send events, measurements, summaries, and approved evidence according to a documented contract.
- Plan fog failure deliberately. Decide which shared functions can pause and prove that edge nodes continue their own required work.
- Keep ownership visible. Document who owns field nodes, the site hub, integrations, credentials, monitoring, updates, and recovery.
- Measure before centralising. Validate event rate, bandwidth, retention, CPU, memory, and operator workflows with a representative pilot.
Edge and fog work well together when the hierarchy reflects the physical and organisational boundaries of the system. The aim is not to create more tiers; it is to place each responsibility at the narrowest layer that can operate it reliably.