4 Edge-Fog Use Cases: Placement Patterns
4.1 Start With the Decision
A safety alert may arrive too late when every sample travels to the cloud. Place each decision where latency, bandwidth, privacy, and recovery allow it to work.
4.2 Route Overview
This is part 1 of 3. Continue with Edge-Fog Use Cases: Bandwidth Optimization.
4.3 Part Objectives
- Compare edge, fog, and cloud placement for an IoT decision.
- Select a placement pattern from latency, bandwidth, and privacy limits.
4.4 Chapter Roadmap
- In 60 Seconds
- Start Simple
- Minimum Viable Understanding
- Most Valuable Understanding
- Use-Case Placement Map
- Knowledge Check: Constraint First
- Pattern 1: Industrial Predictive Maintenance
- Pattern 2: Autonomous and Mobile Systems
- Knowledge Check: Mobile Placement
- Pattern 3: Privacy-Sensitive Sensing
- Pattern 4: Smart Infrastructure and Buildings
- Pattern 5: Field, Agriculture, and Remote Operations
- Data-Rate Sanity Check
- Quantify High-Rate Streams
- Pattern 6: Energy and Grid Systems
- Placement Review Loop
- Worked Example: Site Video Analytics
- Design Checklist
4.5 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.
4.6 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.
4.7 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?”
Inspect Figure 4.1 before continuing. A domain name such as factory or healthcare does not determine placement. Figure 4.1 demonstrates how one workload’s response time, bandwidth, privacy, outage, and scale requirements lead to a tier choice.
In the diagram Figure 4.1, the tree asks Q1: Response time requirement?: under 10 ms leads to EDGE, while over 100 ms can reach CLOUD. The 10–100 ms branch tests Q2: Bandwidth constraint?, with constrained traffic pointing to FOG; later questions cover local privacy, operation during outage, and massive scale before choosing HYBRID. The examples below are illustrations of those branches, so the design decision should preserve the answers rather than copy a domain label.
4.7.1 Edge Role
Act on immediate sensor context, enforce local safety, filter high-rate data, and keep a defined behavior during upstream outages.
4.7.2 Fog Role
Coordinate devices in a site or region, buffer traffic, apply local policy, run shared inference, and summarize evidence before cloud upload.
4.7.3 Cloud Role
Maintain fleet history, train models, plan capacity, run cross-site analytics, and provide long-term reporting.
4.8 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.
4.8.1 Edge: Machine Controller
First, Samples vibration, temperature, current, or acoustic signals. Next, Applies basic filtering and threshold checks close to the equipment. Then, Triggers immediate protective actions when a local safety rule is violated.
4.8.2 Fog: Production-Line Server
First, Aggregates features across related machines. Next, Runs anomaly detection or process-quality inference for the line. Then, Buffers recent evidence and creates work-order events for local teams.
4.8.3 Cloud: Fleet Analytics
First, Compares factories, lines, and equipment families. Next, Trains or evaluates models using labelled maintenance history. Then, Produces reliability reports, inventory planning, and long-term dashboards.
4.8.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.
4.8.5 What to Validate
4.8.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.
4.8.7 Reaction Time
Measure capture, preprocessing, inference, decision logic, and actuation together. Network round trip alone is not the full latency budget.
4.8.8 Evidence Retention
Decide which raw windows, features, alarms, and summaries must be retained for maintenance review or model improvement.
4.8.9 Outage Behavior
Specify what the machine, line server, and cloud queue do when the site uplink or fog node is unavailable.
4.9 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.
4.9.1 Immediate Control
Sensor fusion, obstacle avoidance, stabilization, braking, steering, and emergency fallback should not depend on a cloud response.
4.9.2 Nearby Coordination
Roadside units, base-station edge nodes, depot gateways, or field stations can coordinate multiple mobile assets and provide local updates.
4.9.3 Deferred Learning
Route optimization, model training, policy review, and fleet analytics can use batches, samples, and event evidence after the trip.
4.10 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.
4.10.1 Local Transformation
Detect, crop, blur, count, classify, or summarize near the sensor so raw sensitive content is not transmitted by default.
4.10.2 Site Policy Point
Apply retention rules, access control, audit logs, consent boundaries, and aggregation rules at the store, clinic, building, or campus.
4.10.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.
4.10.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.
4.11 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.
4.11.1 Traffic and Mobility
Edge sensors detect local state, fog controllers coordinate corridors or intersections, and cloud analytics plan long-term changes.
4.11.2 Buildings and Campuses
Room devices collect local readings, building gateways coordinate zones, and cloud systems compare comfort, energy, and maintenance trends.
4.11.3 Retail Operations
In-store processors turn video or shelf data into counts and exceptions, while regional systems compare store performance and inventory patterns.
4.11.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.
4.12 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.
4.12.1 Field Edge
Filter images, classify events, trigger local actuators, and preserve safety when the uplink is absent.
4.12.2 Site Fog
Collect batches from field devices, deduplicate readings, schedule uploads, and provide a local operator view.
4.12.3 Cloud Planning
Perform seasonal analysis, model training, asset planning, regulatory reporting, and cross-site comparison.
4.12.4 Concrete Cases: Pipelines, Rail, and Wind
Farms and mines are one shape of field deployment. Pipelines, rail corridors, and wind farms are another: the asset is spread across many kilometers rather than concentrated on one site, so the fog tier’s job is covering distance, not just one building.
4.12.5 Pipeline Pressure and Flow
Continuous pressure, flow, and compressor monitoring on a gas or oil pipeline produces terabytes of data. Sending all of it to the cloud for analysis and storage is not efficient, and the network latency is not acceptable when a compressor fault needs a fast local response.
4.12.6 High-Speed Rail Track Conditions
Trackside fog nodes deployed along a rail corridor can analyze track-condition data fast enough to matter for a high-speed train. Sending that data to the cloud for analysis first is too slow to improve safety and reliability.
4.12.7 Wind Turbine Output
Real-time wind direction and speed analysis at the turbine can inform pitch and yaw adjustments that increase output. A decision that arrives after a cloud round trip has already missed the wind that prompted it.
4.12.8 Review Risk
A corridor or farm being “instrumented” does not guarantee reliable backhaul. Field and linear sites often have worse connectivity than a single building, so the fog tier needs its own outage behavior, not just the edge device’s.
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.
4.13 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.
4.14 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.
4.14.1 Device-Level Control
Protect equipment, enforce local limits, and keep the site in a defined safe state when upstream communication is unavailable.
4.14.2 Site-Level Coordination
Balance local sources, loads, storage, alarms, and operator procedures across a facility, feeder, or microgrid.
4.14.3 System Planning
Use historical telemetry, weather, maintenance records, and fleet events for forecasts, planning, and reporting.
4.14.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.
4.15 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.
Inspect Figure 4.2 before continuing. A use-case story becomes architectural evidence only after its assumptions are quantified and tested. Figure 4.2 provides the repeatable review record for doing that across domains.
In the diagram Figure 4.2, Name decision selects the actual verb—stop, classify, redact, aggregate, upload, or train—before Quantify limits records latency, data, privacy, power, outage, and scope. Assign tiers gives edge, fog, and cloud owners; Define degrade covers slow links, stale models, and fog failure. Collect evidence adds timing traces, queue load, data volume, and recovery, and Revise record replaces assumptions with pilot measurements. The loop keeps placement tied to observed constraints as the use case evolves.
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.
4.16 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.
4.16.1 Placement Record
4.16.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.
4.16.3 Constraint Review
4.16.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.
4.16.5 Bandwidth
Continuous video is a high-volume stream. Counts, shelf-gap events, and short approved evidence clips are far smaller than raw footage.
4.16.6 Privacy
The architecture minimizes identifiable content by default. Raw frames are short-lived unless an approved policy explicitly retains evidence.
4.16.7 Outage
Store operations continue during WAN outage. The fog node queues summary events and uploads them when connectivity returns.
4.16.8 Resulting Architecture
4.16.9 Camera Edge
Sample frames, run detection, redact retained evidence, and emit event records.
4.16.10 Store Fog
Join events across cameras, enforce retention, store short local history, and manage WAN backpressure.
4.16.11 Retail Cloud
Compare stores, build dashboards, audit model behavior, and plan staffing or inventory adjustments.
4.17 Design Checklist
Use this checklist before declaring a use case ready for pilot.
4.17.1 Workload Split
First, Which actions must run locally? Next, Which tasks need multiple devices or site context? Then, Which tasks can wait for cloud processing?
4.17.2 Data Discipline
- What raw data exists?
- What features, events, or summaries leave the site?
- What evidence must be retained for review?
4.17.3 Timing Evidence
- What is the full end-to-end latency budget?
- Which percentile matters, not just the average?
- What happens under burst load?
4.17.4 Failure Behavior
- What is safe degraded mode?
- How are buffers drained?
- How are conflicts resolved after reconnection?
4.17.5 Security and Privacy
First, Where are identities and keys managed? Next, Who can access local data? Then, Which privacy or data-residency assumptions need legal or policy review?
4.17.6 Operations
First, How are models, firmware, configs, and rollback handled? Next, How is local health visible when the cloud path is down? Then, Who owns site support?
4.18 Continue to the Next Part
Carry this evidence into Edge-Fog Use Cases: Bandwidth Optimization, which begins with Common Mistakes.