5 Edge-Fog Use Cases
Place Workloads by Constraint, Not by Hype
5.1 Start Simple
Take one ordinary IoT case, like cold-chain monitoring, traffic sensing, or predictive maintenance. The story starts with the local consequence: what must be noticed, decided, or preserved before a remote service can help. The core idea is to match each responsibility to the closest tier that has enough context and capacity. Start by writing the use case as a small operating promise, then add the evidence that would convince an operator it works during load, outage, and recovery.
5.2 Learning Objectives
By the end of this chapter, you will be able to:
- Identify the main constraint that makes an edge-fog design useful in a given IoT use case.
- Assign immediate actions, site coordination, and long-term analytics to edge, fog, and cloud tiers.
- Compare industrial, autonomous, privacy-sensitive, infrastructure, field, and energy use cases without relying on universal numeric claims.
- Write a placement record that captures data rate, latency budget, privacy boundary, failure mode, and verification evidence.
- Avoid common use-case mistakes such as cloud-only control loops, single-gateway bottlenecks, and privacy theater.
A use case does not “need edge” in general. A specific workload needs a specific placement because one constraint makes another placement fail. Name that constraint before choosing the architecture.
5.3 Use-Case Placement Map
The same domain can contain edge, fog, and cloud workloads at the same time. For example, a smart factory may stop a machine at the edge, correlate production-line anomalies at a fog server, and retrain models in the cloud. The useful question is not “which domain is this?” but “which workload has which constraint?”
5.3.1 Edge Role
Act on immediate sensor context, enforce local safety, filter high-rate data, and keep a defined behavior during upstream outages.
5.3.2 Fog Role
Coordinate devices in a site or region, buffer traffic, apply local policy, run shared inference, and summarize evidence before cloud upload.
5.3.3 Cloud Role
Maintain fleet history, train models, plan capacity, run cross-site analytics, and provide long-term reporting.
5.4 Pattern 1: Industrial Predictive Maintenance
Predictive maintenance is a useful edge-fog example because machines produce frequent signals, but maintenance decisions usually need both local context and long-term history.
5.4.1 Edge: Machine Controller
- Samples vibration, temperature, current, or acoustic signals.
- Applies basic filtering and threshold checks close to the equipment.
- Triggers immediate protective actions when a local safety rule is violated.
5.4.2 Fog: Production-Line Server
- Aggregates features across related machines.
- Runs anomaly detection or process-quality inference for the line.
- Buffers recent evidence and creates work-order events for local teams.
5.4.3 Cloud: Fleet Analytics
- Compares factories, lines, and equipment families.
- Trains or evaluates models using labelled maintenance history.
- Produces reliability reports, inventory planning, and long-term dashboards.
5.4.4 Review Risk
Do not claim a fixed data-reduction or payback value without the sampling rate, payload size, retention policy, and evidence requirement for the actual plant.
5.4.5 What to Validate
5.4.6 Data Rate
Calculate raw rate from sensor count, sample rate, sample size, and duty cycle. Then compare it with the selected local, site, and WAN links.
5.4.7 Reaction Time
Measure capture, preprocessing, inference, decision logic, and actuation together. Network round trip alone is not the full latency budget.
5.4.8 Evidence Retention
Decide which raw windows, features, alarms, and summaries must be retained for maintenance review or model improvement.
5.4.9 Outage Behavior
Specify what the machine, line server, and cloud queue do when the site uplink or fog node is unavailable.
5.5 Pattern 2: Autonomous and Mobile Systems
Vehicles, robots, drones, and mobile equipment are edge-heavy because movement converts latency into physical risk. That does not mean every workload runs on the vehicle. Immediate perception and control are local; cooperative awareness and route coordination can use nearby infrastructure; fleet learning and compliance reporting can happen later.
5.5.1 Immediate Control
Sensor fusion, obstacle avoidance, stabilization, braking, steering, and emergency fallback should not depend on a cloud response.
5.5.2 Nearby Coordination
Roadside units, base-station edge nodes, depot gateways, or field stations can coordinate multiple mobile assets and provide local updates.
5.5.3 Deferred Learning
Route optimization, model training, policy review, and fleet analytics can use batches, samples, and event evidence after the trip.
5.6 Pattern 3: Privacy-Sensitive Sensing
Cameras, microphones, location traces, health measurements, and building-occupancy streams can expose people. Edge and fog processing can reduce that exposure when the architecture collects only what is needed for the purpose.
5.6.1 Local Transformation
Detect, crop, blur, count, classify, or summarize near the sensor so raw sensitive content is not transmitted by default.
5.6.2 Site Policy Point
Apply retention rules, access control, audit logs, consent boundaries, and aggregation rules at the store, clinic, building, or campus.
5.6.4 Review Risk
Encryption in transit is necessary but not the same as data minimization. If the cloud still receives raw identifiable content, the privacy risk remains.
5.6.5 Example Privacy Record
Purpose
Optimize occupancy-based heating, cooling, and queue staffing.
Raw Input
Short-lived camera frames processed inside the building.
Local Output
Room count, coarse dwell-time bucket, confidence score, and timestamp.
Not Sent
Faces, full-resolution frames, individual tracks, and precise movement paths.
Evidence
Retention log, sample audit, false-positive review, and documented business purpose.
5.7 Pattern 4: Smart Infrastructure and Buildings
Smart city, campus, retail, and building systems often use fog because the interesting decision spans multiple edge devices. One traffic light can react locally; an intersection controller coordinates approaches; a city platform studies patterns over weeks. One room sensor can count occupancy; a building gateway can coordinate HVAC zones; a cloud service can compare energy performance across sites.
5.7.1 Traffic and Mobility
Edge sensors detect local state, fog controllers coordinate corridors or intersections, and cloud analytics plan long-term changes.
5.7.2 Buildings and Campuses
Room devices collect local readings, building gateways coordinate zones, and cloud systems compare comfort, energy, and maintenance trends.
5.7.3 Retail Operations
In-store processors turn video or shelf data into counts and exceptions, while regional systems compare store performance and inventory patterns.
5.7.4 Emergency and Public Safety
Local alarms and site gateways must keep operating when wide-area connectivity is degraded, with cloud reporting restored when links return.
5.8 Pattern 5: Field, Agriculture, and Remote Operations
Farms, mines, pipelines, offshore sites, and environmental monitoring deployments often have intermittent connectivity, limited power, and large sensing payloads. Their edge-fog pattern is less about polished dashboards and more about survivable local behavior.
5.8.1 Field Edge
Filter images, classify events, trigger local actuators, and preserve safety when the uplink is absent.
5.8.2 Site Fog
Collect batches from field devices, deduplicate readings, schedule uploads, and provide a local operator view.
5.8.3 Cloud Planning
Perform seasonal analysis, model training, asset planning, regulatory reporting, and cross-site comparison.
Use a simple first-pass calculation before discussing cloud processing:
data_rate = device_count * samples_per_second * bytes_per_sample
For image, audio, or radar workloads, also include frame rate, compression setting, duty cycle, and evidence-retention rules. If the raw stream is larger than the available link, the architecture needs local filtering, event extraction, batching, or store-and-forward behavior before the cloud path.
5.9 Quantify High-Rate Streams
For video analytics, the bandwidth argument should be calculated, not assumed. If one compressed camera stream is 4 Mbit/s, then one camera produces about 43 GB/day:
4 Mbit/s * 86,400 s/day = 345,600 Mbit/day
345,600 Mbit/day / 8 = 43,200 MB/dayA 50-camera site at that rate is roughly 2.1 TB/day of raw upload. If the operational need is occupancy counts, queue alerts, or shelf-gap events, the edge can send compact event metadata while fog coordinates the store and cloud receives the history. The exact numbers change by camera, codec, duty cycle, and retention policy, but the review method is stable: compare raw bytes, event bytes, retained samples, and missed-event risk before accepting the placement.
5.10 Pattern 6: Energy and Grid Systems
Energy systems combine local safety, site coordination, and fleet-level planning. A battery inverter, solar controller, or protection relay may need immediate local action. A microgrid controller coordinates local sources and loads. A utility analytics platform studies trends, forecasts demand, and plans maintenance.
5.10.1 Device-Level Control
Protect equipment, enforce local limits, and keep the site in a defined safe state when upstream communication is unavailable.
5.10.2 Site-Level Coordination
Balance local sources, loads, storage, alarms, and operator procedures across a facility, feeder, or microgrid.
5.10.3 System Planning
Use historical telemetry, weather, maintenance records, and fleet events for forecasts, planning, and reporting.
5.10.4 Review Risk
Do not put immediate protection or islanding logic behind a remote service call. Upstream analytics can advise, but local protection must be defined locally.
5.11 Placement Review Loop
Use the same loop for every use case. It prevents the design from becoming a list of impressive domains without architecture evidence.
1. Name the decision Write the exact decision or transformation: stop motor, classify frame, blur face, aggregate line status, upload batch, retrain model.
2. Quantify the constraint Estimate data rate, latency budget, privacy boundary, connectivity pattern, power budget, and coordination scope.
3. Assign tier responsibility Separate edge actions, fog coordination, cloud analytics, and management paths. Include who owns each path.
4. Define degraded behavior State what happens when cloud, fog, edge, identity, time sync, or network paths are slow, stale, or unavailable.
5. Test with evidence Collect traces, logs, screenshots, queue behavior, alert timing, data-volume samples, and recovery results.
6. Update the placement record Revise assumptions after lab, pilot, or field measurements. A stale record is a hidden architecture risk.
5.12 Worked Example: Site Video Analytics
Scenario: A retail chain wants occupancy counts, queue alerts, and shelf-gap events from in-store cameras. The business goal is operational analytics, not storing customer video.
5.12.1 Placement Record
5.12.2 Workload
Camera frames are analyzed for occupancy count, queue length, and shelf-gap exceptions. The system should avoid transmitting raw customer video except for explicitly approved evidence samples.
Edge
Run frame sampling, object detection, face/plate redaction if evidence clips are retained, and local event extraction.
Fog
Aggregate camera events per store, apply retention policy, deduplicate alerts, cache events during WAN outage, and expose a local operator view.
Cloud
Analyze store trends, compare regions, tune models, monitor fleet health, and distribute approved model updates.
Not Cloud
Immediate queue alerting and routine raw video processing.
5.12.3 Constraint Review
5.12.4 Latency
Queue alerts are operationally useful only while the queue still exists. The store can handle them locally rather than waiting for a distant analytics job.
5.12.5 Bandwidth
Continuous video is a high-volume stream. Counts, shelf-gap events, and short approved evidence clips are far smaller than raw footage.
5.12.6 Privacy
The architecture minimizes identifiable content by default. Raw frames are short-lived unless an approved policy explicitly retains evidence.
5.12.7 Outage
Store operations continue during WAN outage. The fog node queues summary events and uploads them when connectivity returns.
5.12.8 Resulting Architecture
5.12.9 Camera Edge
Sample frames, run detection, redact retained evidence, and emit event records.
5.12.10 Store Fog
Join events across cameras, enforce retention, store short local history, and manage WAN backpressure.
5.12.11 Retail Cloud
Compare stores, build dashboards, audit model behavior, and plan staffing or inventory adjustments.
5.13 Design Checklist
Use this checklist before declaring a use case ready for pilot.
5.13.1 Workload Split
- Which actions must run locally?
- Which tasks need multiple devices or site context?
- Which tasks can wait for cloud processing?
5.13.2 Data Discipline
- What raw data exists?
- What features, events, or summaries leave the site?
- What evidence must be retained for review?
5.13.3 Timing Evidence
- What is the full end-to-end latency budget?
- Which percentile matters, not just the average?
- What happens under burst load?
5.13.4 Failure Behavior
- What is safe degraded mode?
- How are buffers drained?
- How are conflicts resolved after reconnection?
5.13.5 Security and Privacy
- Where are identities and keys managed?
- Who can access local data?
- Which privacy or data-residency assumptions need legal or policy review?
5.13.6 Operations
- How are models, firmware, configs, and rollback handled?
- How is local health visible when the cloud path is down?
- Who owns site support?
5.14 Common Mistakes
5.14.1 Domain-Label Architecture
Saying “factory means edge” or “city means cloud” skips the actual placement work. Split the domain into workloads and constraints.
5.14.2 Cloud-Only Control Loop
Remote analytics can advise, but immediate safety, protection, and actuation need a local behavior that survives upstream delay or outage.
5.14.3 One Gateway for Everything
A single fog node can become a bottleneck or single point of failure. Capacity, zoning, redundancy, and failover must be explicit.
5.14.4 Privacy Theater
Encrypting raw sensitive data before cloud upload still leaves the cloud processing sensitive data. Minimize and transform data before transmission where the use case allows.
5.14.5 No Evidence Policy
Over-filtering can destroy the evidence needed for audits, incident review, or model improvement. Decide what raw windows or samples are retained.
5.14.6 Unmeasured Assumptions
Cost, data reduction, latency, and model accuracy claims should be treated as hypotheses until measured in the intended environment.
5.15 Summary
Edge and fog use cases are strongest when they are reviewed as constraint-driven placement decisions. Industrial maintenance, autonomous systems, privacy-sensitive sensing, smart infrastructure, field operations, and energy systems can all use the same architecture discipline: immediate local action at the edge, site or regional coordination at the fog tier, and long-term history in the cloud.
The best use-case record names the workload, quantifies constraints, assigns tier ownership, defines degraded behavior, and records evidence. Without that record, edge and fog become slogans. With it, they become testable architecture choices.
5.16 Concept Relationships
5.16.1 Use Case and Constraint
A domain example becomes useful only when it names the constraint that drives placement.
5.16.2 Edge and Immediate Action
Edge placement is strongest when local context, safety, outage behavior, or raw data rate makes remote processing unsuitable.
5.16.3 Fog and Coordination
Fog placement is strongest when several edge devices need shared policy, aggregation, buffering, or site-level context.
5.16.4 Cloud and Fleet History
Cloud placement is strongest when the work needs cross-site history, model training, governance, reporting, or slow analytics.
5.17 What’s Next
- Edge-Fog Pitfalls: Review failure modes that appear when edge and fog use cases move toward production.
- Edge-Fog Labs: Practice measuring latency, buffering, and placement behavior in small lab scenarios.
- Edge-Fog Simulator: Use simulation to compare placement assumptions before hardware decisions.
- Fog Applications: Continue into fog-specific application patterns and architecture choices.
5.18 Key Takeaway
Edge and fog are strongest in use cases with local control, privacy pressure, constrained links, intermittent connectivity, location-aware coordination, or expensive raw data movement.