2 Edge, Fog, and Cloud: Architecture

edge-fog

cloud

In 60 Seconds

Split Work by Time, Place, and Ownership

Picture a cold store with door sensors. A local alarm must sound at once. A site computer must join readings from many rooms. A central service must compare several sites across a year.

Edge means work on or close to the device. Fog means shared work in a nearby site or area. Cloud means centrally managed work that can span many sites. These are roles, not fixed product boxes.

Place each task from its needs. Keep urgent safe action where an outside outage cannot block it. Put site-wide rules and short shared history near the site. Put long records, fleet reports, and central learning under clear central ownership. State what moves between the roles and what happens when each link fails.

Keep enough evidence after each hand-off. A summary should retain source time, quality, rule version, and a path back to the decision. Test slow links, full local storage, repeated data, clock error, site loss, and return after an outage.

No layer is always best. Use Practitioner to design placement and recovery. Use Under the Hood to examine timing, state, trust, cost, and scale limits.

Edge, fog, and cloud architecture assigns IoT work to three scopes. The edge is closest to the physical event. The fog tier coordinates a local site, gateway, vehicle, cluster, or regional group. The cloud keeps fleet history, governance, analytics, dashboards, and rollout policy coherent across sites.

2.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.

2.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.

Inspect Figure 2.1 before continuing. The three tiers matter only when the system assigns each path and response to an owner. Figure 2.1 gives the physical context for tracing the vibration-alarm example in both directions.

Edge devices generate data, fog nodes perform local computation and cloud data centers provide heavy processing and storage. The three tiers form a connected architecture. — Figure 2.1: Fog, edge, and cloud architecture: edge IoT devices connect through fog nodes to the cloud layer, each tier owning distinct sensing, coordination, and fleet-service roles.

In the diagram Figure 2.1, the EDGE band groups IoT devices such as the car, phone, roadway equipment, and factory where data is generated. Nearby FOG Node elements provide distributed local computation before records reach the CLOUD layer for centralised processing and storage. A local alarm can therefore remain at the edge, site coordination can stop at fog, and fleet history can rise to cloud; any command returning through those same bands needs an equally explicit acknowledgement and fallback owner.

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.

2.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.

2.2.2 Architecture Roles

2.2.3 Edge

Reads sensors, drives actuators, validates local signals, performs simple immediate decisions, and preserves minimum safe behavior when links are unavailable.

2.2.4 Fog

Aggregates local devices, translates protocols, buffers records, applies site policy, coordinates nearby workloads, and provides degraded-mode service during WAN outages.

2.2.5 Cloud

Stores long-term records, manages identity and rollout policy, trains or evaluates models, supports dashboards, and compares behavior across the fleet.

2.2.6 Beginner Examples

First, An over-temperature cutoff belongs at the edge when waiting for a remote service would be unsafe. Next, A site gateway that converts Zigbee readings into MQTT records and stores them during an outage is acting as fog. Then, A cloud service that compares failure rates across many sites is doing fleet-scope work. After that, A dashboard command path needs a separate review from telemetry upload because commands can affect physical equipment.

2.3 Knowledge Check: Architecture Ownership

2.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.

2.4.1 How It Works: Review the Paths

First, 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. Next, Assign the owner. Choose edge, fog, or cloud from timing, locality, privacy, bandwidth, reliability, compute, power, and support constraints. Then, Draw the path. Separate telemetry, command, management, and failure paths so an upload route is not mistaken for an update or control route. After that, Define the boundary. Record protocol translation, identity mapping, timestamp rules, quality flags, retained evidence, version visibility, and rollback behavior. Finally, 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.

2.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.

2.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.

2.4.4 Interactive: Place a Fog Task

2.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.

2.4.6 Map the Runtime Path

Placement becomes concrete when one response is written as a timeline. For a cloud-controlled loop, separate the elapsed time into four measured intervals:

T_{\text{cloud loop}} = t_1 + t_2 + t_3 + t_4

Here $t_1$ is the device’s sensing, conversion, and local firmware time; $t_2$ is the outbound path from the device or gateway to the cloud service; $t_3$ is queueing, analysis, policy evaluation, and any durable write in the cloud; and $t_4$ is the return path that delivers the command and its local protocol translation. This is a decomposition, not a promise that the terms are constant. Radio access, retransmissions, gateway queues, WAN routing, service load, and storage can each give a term a long tail, so record percentiles as well as an average.

Interval	Start and stop markers	What changes it	Can a local decision remove it from the control loop?
$t_1$ device response	Physical event to validated local sample	Sensor dynamics, ADC schedule, firmware queue, debounce	No. The physical measurement still has to happen.
$t_2$ uplink	Validated sample to cloud ingress	Duty cycle, association, retries, backhaul, WAN latency	Yes, for the immediate decision; upload can occur later.
$t_3$ cloud work	Cloud ingress to command issuance	Broker queue, function start, rules, database commit	Yes, if the gateway holds the required rule and state.
$t_4$ return command	Command issuance to gateway or actuator receipt	WAN path, downlink paging, translation, local delivery	Yes, if the action is issued locally.

Suppose a pump-protection path measures $t_1=18\ \text{ms}$ , $t_2=85\ \text{ms}$ , $t_3=42\ \text{ms}$ , and $t_4=90\ \text{ms}$ . The nominal cloud round trip is

T_{\text{cloud loop}} = 18+85+42+90 = 235\ \text{ms}.

If the gateway has the authenticated cutoff rule, current limit, and actuator interlock, the time-critical loop becomes

T_{\text{local loop}} = t_1+t_{\text{gateway decision}}+t_{\text{local command}}.

With a 4 ms rule evaluation and a 7 ms fieldbus command, that is $18+4+7=29\ \text{ms}$ . The architecture did not make sensing faster; it removed the WAN, remote queue, and return-WAN terms from the safety deadline. The gateway can still upload the event, raw window, decision version, and acknowledgement asynchronously so the cloud retains fleet evidence without sitting inside the protection loop.

Walk the path in that order during review. First timestamp the physical event and validated sample. Next timestamp cloud ingress and decision completion. Then timestamp command receipt and physical acknowledgement. Finally repeat under weak radio, WAN loss, and cloud overload. A local path is justified only if it also has policy-version custody, fail-safe behavior, bounded local queues, and evidence reconciliation after connectivity returns.

2.5 Knowledge Check: Management Path

2.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.

2.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.

2.6.2 Topology Patterns

2.6.3 Single Site Gateway

Simple to operate, but the decision record must state failure impact, replacement process, local minimum behavior, and replay rules.

2.6.4 Site Fog Cluster

Useful when a site needs redundancy, shared queues, local services, or high-volume processing across many devices.

2.6.5 Mobile Fog

Vehicles, robots, field kits, or ships can carry local coordination that moves with the devices and synchronizes opportunistically.

2.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.

2.6.7 Boundary Checklist

First, Protocol boundary: source protocol, normalized record, unit conversion, timestamp rule, quality flag, and error behavior. Next, Trust boundary: device identity, gateway identity, certificate lifecycle, command authorization, and physical access assumption. Then, Data boundary: raw evidence, filtered records, summaries, privacy limits, retention period, replay order, and audit needs. After that, Version boundary: firmware, adapter, schema, model, policy, cloud service, local override, and rollback trigger. Finally, Operations boundary: owner, health signal, alert threshold, update process, decommission step, and re-review condition.

2.7 Label the Diagram: Architecture Roles

2.8 Knowledge Check: Translation Boundary

The matched timelines in Figure 2.2 expose which terms disappear when a safety decision stays near the device.

Matched response timelines total 235 ms for a cloud loop and 29 ms for a local gateway. Local decisions remove internet transit and cloud queue/storage from the control path. — Figure 2.2: Cloud and local-gateway response loops sum device, link, processing, and return-command latency terms.

Read Figure 2.2 across CLOUD LOOP to its 235 ms total, then compare LOCAL GATEWAY LOOP at 29 ms. Keeping DEVICE acquisition still costs 5 ms, but Internet transit + cloud queue/storage leaves the control path; asynchronous cloud evidence can continue without holding the local command hostage.

Now walk the same event through the interactive budget in formula order. Step along the gateway path first and observe the greyed-out WAN legs, then inspect the cloud path and use the dominant-term and budget-margin readouts to explain the difference. Finally choose Flip misconception: the single action changes only gateway queue and gateway inference, making local congestion reverse the winner while every cloud term stays fixed.

2.9 Edge, Fog, and Cloud: The Three Tiers

In 60 Seconds

Prove One Workload Has a Safe Home

Picture a greenhouse that loses its upstream link while a fan still needs control. A placement label is useful only when the local action and later record both survive that break.

A gateway means the boundary system that joins local devices to another network or service. Name what it senses, decides, sends, stores, and does when the next tier is absent.

Run the workload with the link healthy, slow, and absent. Keep the tier, input, decision time, action, queued record, recovery result, and owner so another person can repeat the trial.

This test covers one workload and outage window, not every site failure. The deeper sections compare placement, coordination, scale, security, cost, and support.

Edge, fog, and cloud are placement choices for specific IoT workloads. Edge runs close to the physical process. Fog runs nearby in a gateway, site server, or regional tier that coordinates more than one edge device. Cloud runs centralized services that need fleet history, dashboards, governance, analytics, and long-term records. A good design does not say “use edge” or “use cloud” as a slogan. It names the workload, the tier, the evidence, the fallback behavior, and the owner.

2.9.1 Start Simple

Picture a greenhouse fan, a site gateway, and a cloud dashboard looking at the same temperature event. The edge can react quickly, the fog tier can coordinate the site, and the cloud can compare patterns across many sites. Everyday IoT architecture starts by asking which part of that work must be local, which part benefits from nearby coordination, and which part needs fleet history. Start with one workload and write where the sensing, decision, command, record, and fallback live.

Edge Eddie

“Send the decision, not the raw feed — the edge earns its keep in milliseconds and megabytes saved.”

Through this chapter, Eddie shadows each placement call: what runs beside the process, what still travels upstream, and the evidence that proves the split.

2.9.2 Learning Objectives

By the end of this chapter, you will be able to:

Define edge, fog, and cloud as workload placement options, not as competing product labels.
Explain when latency, bandwidth, privacy, reliability, operations, and evidence boundaries push work toward each tier.
Write a placement decision record that separates telemetry, command, management, and health paths.
Review an IoT placement claim for degraded-mode behavior, ownership, and retest triggers.

Most Valuable Understanding

A tier label is not proof. Placement is reviewable only when each workload has a named requirement, measured or testable evidence, a normal path, a degraded path, and an owner.

2.9.3 The Three-Tier Model

Start by naming the work. A warehouse dock sensor can filter noisy events at the edge, let a fog gateway coordinate local alerts and screens, and send curated history to the cloud for fleet analysis. The tiers are not a ranking. They divide work by timing, scope, evidence, and who can recover the path when a link or service fails.

Eddie’s Edge Ledger

Decide here: the dock sensor filters its own noisy events — first response stays local.
Send up: curated history for fleet analysis; the fog gateway coordinates local alerts en route.
Clock it: no number yet — timing and scope divide the work; the drivers table sets the measured bar.

2.9.3.1 Edge

Handles work that must stay near the device: immediate sensing, local filtering, simple inference, safety interlocks, offline behavior, and first response.

2.9.3.2 Fog

Handles nearby coordination: gateway decisions, site dashboards, protocol bridging, aggregation, buffering, local policy, and degraded-mode service.

2.9.3.3 Cloud

Handles broad services: long-term storage, fleet analytics, model training, cross-site reporting, identity governance, update orchestration, and audit records.

Cloud capability makes sense only in relation to the work retained nearer the devices. Figure 2.3 provides that comparison, so inspect the three tiers before assigning storage, analytics, or control to the top layer.

A detailed three-tier IoT architecture map showing edge devices and actuators, gateway and fog services, and cloud platform services connected by local and wide-area links — Figure 2.3: Three-tier IoT architecture roles

In the diagram Figure 2.3, the Device Tier contains sensors and actuators connected over LAN and PAN links. Above it, the Platform Tier -- Gateway / Fog Computing performs protocol translation, pre-filtering, local inference, caching, and OTA coordination. The Enterprise Tier -- Cloud / Data Center adds scalable compute, ML model training, time-series or lake storage, dashboards, IAM, and compliance. Those boundaries show why cloud is the natural home for fleet history and heavy analysis but not proof of a dependable local response.

Knowledge Check: Placement Claim

2.9.4 Placement Drivers

Review placement by evidence, not by preference. Write the same workload three ways before choosing a tier: at the edge, what must keep working if the network disappears; at the fog tier, what a site or gateway can coordinate better than a single device; in the cloud, what needs fleet history, model training, governance, or cross-site comparison.

Driver	Often pushes toward	Evidence to collect	Common mistake
Response time	Edge for immediate control; fog for site response; cloud when delayed response is acceptable.	Measured path latency, jitter, local queueing, actuation time, and degraded-mode behavior.	Using average latency when the decision depends on worst-case or tail behavior.
Data volume	Edge or fog when raw streams are too large; cloud when curated history is needed.	Raw rate, filtered rate, retention need, compression rule, link capacity, and exception handling.	Sending every raw sample upstream without proving the cost or value of that transfer.
Privacy and control	Edge or fog when sensitive data or physical authority should remain local; cloud for governed fleet services.	Data classification, authorization boundary, audit path, command approval, and local fallback rule.	Mixing telemetry and commands so a dashboard path becomes an uncontrolled control path.
Operations	The tier with clear owners, monitoring, update path, rollback, and support access.	Runbooks, health checks, version records, alert ownership, backup, and retest cadence.	Choosing a tier that works in a demo but cannot be patched, observed, or recovered safely.

Eddie’s Edge Ledger

Decide here: immediate control at the edge when response time drives it.
Send up: the filtered rate, not every raw sample — unproven raw upload is the table’s named mistake.
Clock it: measured path latency, jitter, worst-case tail — averages are the wrong evidence.

2.9.5 Write a Placement Decision Record

A practical edge-fog-cloud review starts by listing workloads, not technologies. Telemetry upload, alarm decision, actuator command, local dashboard, identity check, update delivery, model inference, model training, and audit retention can each have different placement needs. Treat them as separate decisions until the evidence says they can be combined.

For each workload, record:

First, Workload: The exact behavior, such as filter readings, raise an alarm, aggregate a site summary, run inference, train a model, store history, or update devices. Next, Requirement: Response time, data volume, privacy, safety, reliability, compute, power, connectivity, and support constraints in plain language. Then, Chosen tier: The simplest placement that can meet the requirement and can still be operated, monitored, updated, and recovered. After that, Paths: Separate telemetry, command, management, identity, update, audit, and health paths instead of drawing one generic arrow. Finally, Proof: The test, measurement, pilot, operator runbook, and retest trigger that keep the claim bounded.

Knowledge Check: Placement Record

2.9.6 Paths and Boundaries

An edge-fog-cloud system is a set of paths that cross trust, timing, and ownership boundaries. A telemetry path may move sensor facts upward. A command path may move decisions downward. A management path may deliver policies, credentials, updates, and rollback controls. A health path may report stale data, missing data, and degraded operation. Each path has a different failure mode.

A tier diagram becomes useful when it reveals both the processing roles and the links between them. Figure 2.4 is the chapter’s route map for deciding what crosses a local boundary and what must traverse the WAN.

Edge-fog-cloud overview with an embedded device tier for low-latency sensing, a fog and gateway tier of smartphones, vehicles, and hubs for local processing, and a cloud tier for storage, analytics, and ML. — Figure 2.4: Edge-fog-cloud overview: an embedded device tier for low-latency sensing, a fog and gateway tier for local processing, and a cloud tier for storage, analytics, and machine learning.

In the diagram Figure 2.4, at the bottom, the Embedded Device Tier names sensors, wearables, and appliances under a low-latency role. LAN / PAN Protocols such as 6LoWPAN, ZigBee, and Bluetooth connect them to the Fog / Gateway Tier, where smartphones, vehicles, and hubs relay or process locally. WAN Protocols then lead to the Cloud Tier for data lakes, batch analytics, and model training. Reading those two protocol bands separately exposes the latency and outage boundaries that each workload must tolerate.

Path	What it proves	What it does not prove	Retest trigger
Telemetry upward	Readings, events, summaries, or features can move from device or fog tier toward storage and analytics.	Command safety, local autonomy, dashboard freshness, or field usefulness of every retained value.	Sensor, sampling, filter, aggregation, schema, link, retention, or dashboard change.
Command downward	Approved decisions can reach a device or site controller through the reviewed authorization and audit path.	That commands are always safe, timely, reversible, or allowed under degraded connectivity.	Actuator, policy, role, dashboard, authorization, audit, timeout, or fallback change.
Management downward	Credentials, configuration, firmware, model artifacts, and policy updates can be delivered and rolled back.	Telemetry quality, business value, or correctness of the workload placement decision.	Certificate, key, update, model, policy, rollback, owner, or support tool change.
Health and recovery upward	The system can report offline devices, stale data, buffer state, degraded mode, and recovery status.	That every local decision remained correct during the outage or that no data was lost.	Outage scenario, queue rule, clock behavior, stale-data display, reconciliation, or incident process change.

Knowledge Check: Path Boundaries

2.9.7 Summary

First, Edge, fog, and cloud are placement options for specific workloads, not proof by themselves. Next, A reviewable placement claim names the workload, tier, requirement, normal path, degraded path, owner, evidence, and retest trigger. Then, Edge often fits immediate local work; fog often fits nearby coordination; cloud often fits fleet services, history, governance, and broad analytics. After that, Telemetry, command, management, and health paths need separate evidence because they fail in different ways. Finally, Strong placement records keep physical authority, privacy, latency, bandwidth, recovery, updates, and monitoring visible before rollout.

Key Takeaway

Approve edge, fog, and cloud placement only when each workload is tied to its required behavior, evidence boundary, operating owner, degraded-mode rule, and retest trigger.

2.9.8 See Also

2.9.8.1 Edge, Fog, and Cloud: Architecture

Map device, gateway, site, regional, and cloud layers with placement evidence and failure boundaries.

2.9.8.2 Edge-Fog Decision Framework

Use response, data, trust, connectivity, and operations constraints to decide where workloads belong.

2.9.8.3 Edge-Fog Latency

Build measured response budgets before choosing where control, inference, and dashboards should run.

2.9.8.4 Edge Bandwidth Optimization

Review filtering, aggregation, compression, batching, and local inference as bandwidth-placement tools.

2.10 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.

2.11 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.