flowchart TB Edge[Edge devices: sense, actuate, local safety] -->|Telemetry path: records, flags, replay| Fog[Fog gateway/site service: translate, buffer, coordinate] Fog -->|Summaries, evidence, fleet events| Cloud[Cloud: history, governance, analytics, rollout policy] Cloud -->|Management path: config, certificates, models, firmware| Fog Fog -->|Command path: authorized actions, acknowledgements, timeouts| Edge Edge -->|Failure path: fallback, buffered evidence, local alarms| Fog Fog -->|Recovery path: replay order, health, review trigger| Cloud
9 Edge, Fog, and Cloud: Architecture
edge-fog
cloud
9.1 Start Simple
Start with a single path: a device observes something, a nearby tier decides what to do, and a cloud service keeps the longer record. The core idea is ownership, not layer names. Everyday IoT architecture becomes reviewable when every telemetry, command, management, and fallback path has a named tier and a reason. Build one path record first, then add topology only when the responsibility or failure behavior requires it.
9.2 Architecture Is Owned Paths
The architecture is not complete when a diagram has three boxes. It is complete only when the important paths have owners: telemetry, commands, management actions, recovery behavior, retained evidence, and replay after outages.
For example, a packaging line may send sensor telemetry upward through a fog gateway, receive operator commands downward from a dashboard, accept model and certificate updates through a management path, and enter a local fallback path when the WAN is down. If those four paths are drawn as one arrow, the design hides the difference between observation, control, update authority, and recovery. A useful architecture record names the owner, evidence, timeout, and rollback rule for each path.
A quick review test is to follow one event in both directions. A vibration alarm might start at a motor edge device, be buffered and deduplicated by a gateway, appear in a cloud fleet dashboard, and then trigger a maintenance acknowledgement back to the site. Each hop should state whether it is a record, a command, a policy update, or a recovery action.
If you only need the big idea, use this rule: edge owns immediate physical behavior, fog owns local coordination, and cloud owns fleet-level memory and governance.
9.2.1 Interactive: Trace the Edge-Fog-Cloud Flow
Use the animation to follow telemetry upward through edge filtering, fog aggregation, and cloud insight, then follow commands and management updates back down before assigning architecture ownership.
9.2.2 Architecture Roles
9.2.3 Edge
Reads sensors, drives actuators, validates local signals, performs simple immediate decisions, and preserves minimum safe behavior when links are unavailable.
9.2.4 Fog
Aggregates local devices, translates protocols, buffers records, applies site policy, coordinates nearby workloads, and provides degraded-mode service during WAN outages.
9.2.5 Cloud
Stores long-term records, manages identity and rollout policy, trains or evaluates models, supports dashboards, and compares behavior across the fleet.
9.2.6 Beginner Examples
- An over-temperature cutoff belongs at the edge when waiting for a remote service would be unsafe.
- A site gateway that converts Zigbee readings into MQTT records and stores them during an outage is acting as fog.
- A cloud service that compares failure rates across many sites is doing fleet-scope work.
- A dashboard command path needs a separate review from telemetry upload because commands can affect physical equipment.
9.3 Knowledge Check: Architecture Ownership
9.4 Write the Architecture Record
A practical architecture record starts with workloads, not products. Telemetry upload, alarm decisions, actuator commands, local dashboards, protocol translation, identity checks, software updates, model inference, model training, and audit retention may belong at different tiers in the same system.
Keep the record short enough to maintain. It should name each workload, the tier that owns it, the evidence behind that placement, the normal path, the degraded path, the operations owner, and the trigger for re-review.
9.4.1 How It Works: Review the Paths
- Name the workload. Use behavior words: filter readings, raise alarms, translate records, aggregate a site summary, update firmware, serve a dashboard, or retain audit evidence.
- Assign the owner. Choose edge, fog, or cloud from timing, locality, privacy, bandwidth, reliability, compute, power, and support constraints.
- Draw the path. Separate telemetry, command, management, and failure paths so an upload route is not mistaken for an update or control route.
- Define the boundary. Record protocol translation, identity mapping, timestamp rules, quality flags, retained evidence, version visibility, and rollback behavior.
- Test the degraded case. Check stale policy, offline WAN, overloaded queues, delayed replay, adapter drift, and local failover before treating the architecture as production ready.
9.4.2 Architecture Flow Record
| Path | Primary Question | Evidence to Keep |
|---|---|---|
| Telemetry | How do observations move upward as raw frames, validated records, summaries, exceptions, or audit evidence? | Schema, timestamp rule, quality flag policy, retention choice, replay behavior, and loss handling. |
| Command | How do actions move downward with authorization, safety checks, acknowledgement, and timeout behavior? | Command owner, guard condition, acknowledgement rule, fallback state, and rollback test. |
| Management | How do certificates, configuration, firmware, models, policies, and health reports move through the system? | Version record, staged rollout plan, health signal, update evidence, rollback trigger, and decommission step. |
| Failure | What happens when a tier is unavailable, stale, overloaded, disconnected, or recovering? | Degraded-mode rule, queue depth, replay order, operator alert, field test, and review trigger. |
9.4.3 Interactive: Compare Placement Trade-offs
Use the comparison tool to assign one workload to edge, fog, or cloud, then compare the latency, bandwidth, cost, and energy evidence before recording why that tier owns the workload.
9.4.4 Interactive: Place a Fog Task
9.4.5 Intermediate Example
A cold-chain gateway receives readings from several rooms, checks local alarm thresholds, stores records while the WAN link is down, and sends cloud summaries when connectivity returns. The edge devices own sensing. The fog gateway owns local aggregation, alarm continuity, buffering, and replay. The cloud owns long-term trend review, fleet dashboards, and update policy. The record is weak if it only says “gateway to cloud”; it needs the outage path, replay order, and alarm owner.
9.5 Knowledge Check: Management Path
9.6 Boundaries, Topologies, and Drift
Most architecture failures are boundary failures. Device protocols, cloud records, command semantics, timestamps, identities, quality flags, update versions, and retained evidence can drift independently unless the architecture says where each boundary is owned.
The fog tier often carries the hardest boundary work. It may translate a fieldbus frame into a cloud-facing event, map device identity into fleet identity, buffer evidence during an outage, apply site policy, and expose local health. Those responsibilities should be reviewable, versioned, and testable.
9.6.1 Advanced Example
A regional water-monitoring system uses sensors at remote stations, rugged local gateways, and cloud analytics. A gateway normalizes units, stamps records with local time plus synchronization status, holds raw exceptions for investigation, and rejects commands when safety preconditions fail. The cloud keeps long-term history and rollout policy, but it does not need to approve each immediate pump-protection decision. The architecture succeeds only if translation, command authorization, local fallback, replay, and update rollback are all explicit.
Replay sizing makes those boundaries visible. If 50 stations send one normalized record every 5 seconds, a 20-minute WAN outage produces 50 x 12 x 20 = 12,000 records. At about 300 bytes per record after envelope metadata, the raw backlog is only 3.6 MB, but replaying it at 10 records per second takes another 20 minutes and may arrive out of order with live data unless the gateway marks event time, receive time, replay state, and quality. Commands and policy updates need different treatment: an old pump command should expire instead of replaying blindly, while a failed certificate or model update needs a rollback rule and a visible version boundary. That keeps recovery auditable.
9.6.2 Topology Patterns
9.6.3 Single Site Gateway
Simple to operate, but the decision record must state failure impact, replacement process, local minimum behavior, and replay rules.
9.6.4 Site Fog Cluster
Useful when a site needs redundancy, shared queues, local services, or high-volume processing across many devices.
9.6.5 Mobile Fog
Vehicles, robots, field kits, or ships can carry local coordination that moves with the devices and synchronizes opportunistically.
9.6.6 Cloud-Managed Edge
The cloud governs configuration and rollout while edge and fog continue the local workload if the management channel is unavailable.
9.6.7 Boundary Checklist
- Protocol boundary: source protocol, normalized record, unit conversion, timestamp rule, quality flag, and error behavior.
- Trust boundary: device identity, gateway identity, certificate lifecycle, command authorization, and physical access assumption.
- Data boundary: raw evidence, filtered records, summaries, privacy limits, retention period, replay order, and audit needs.
- Version boundary: firmware, adapter, schema, model, policy, cloud service, local override, and rollback trigger.
- Operations boundary: owner, health signal, alert threshold, update process, decommission step, and re-review condition.
9.7 Label the Diagram: Architecture Roles
9.8 Knowledge Check: Translation Boundary
9.9 Summary
Edge-fog-cloud architecture assigns IoT responsibilities across immediate physical behavior, local coordination, and fleet-level services. Edge owns sensing, actuation, validation, and minimum safe behavior. Fog owns local aggregation, protocol translation, buffering, site policy, and degraded-mode coordination. Cloud owns long-term history, governance, analytics, dashboards, and rollout policy.
A strong architecture record separates telemetry, command, management, and failure paths. It also states translation boundaries, trust boundaries, data-retention rules, version visibility, operations ownership, and the degraded cases that must be tested before rollout.
9.10 Key Takeaway
Do not treat edge, fog, and cloud as box labels. Treat them as ownership decisions for workloads, paths, boundaries, evidence, and recovery behavior.
9.11 See Also
Edge-Fog-Cloud Introduction
Use this when you want the placement motivation before reviewing the architecture record.
Devices and Integration
Connect tier responsibilities to device classes, gateways, adapters, and integration choices.
Edge Bandwidth Optimization
Refine telemetry, filtering, retention, and replay choices between tiers.
Edge/Fog Decision Framework
Turn latency, locality, privacy, bandwidth, reliability, and operations constraints into placement decisions.