20 Practical Edge Computing: Workload Placement
20.1 Start With the Decision
A vibration node cannot stream every raw sample forever. Place the FFT near the sensor when delay and bandwidth demand it.
20.2 Route Overview
This is part 1 of 2. Continue with Practical Edge Computing: Bandwidth and Inference Budgets.
20.3 Part Objectives
- Test practical edge computing check with a concrete scenario and pass criteria.
- Validate factory edge or cloud choice with a concrete scenario and pass criteria.
20.4 Start With the Story
Place the Job by Its Deadline and Evidence Need
Picture five hundred cold-store sensors sending readings every few seconds. A local computer must warn staff about a warming freezer, while a central service studies months of energy use. The system owner has to place each job without hiding its cost or its failure path.
Write the two decisions first. The warning needs a response time, a local safe action, and a maximum age for its input. The long study needs a saved period, enough detail, and a review trail. Do not give both jobs the same placement just because one computer can run them.
Measure the full trip for each job: capture, wait, work, send, store, and show. Then cut the outside link, fill the local store, restart the local computer, and send late or repeated readings. Record which decision still works and which evidence can be recovered.
Cost is more than the purchase price. Include field visits, power, link use, updates, support time, and the cost of a missed or late decision.
The simple split does not choose a final design. Practitioner builds the measured budget and comparison. Under the Hood covers queues, model size, hardware limits, and the standards or service terms that may change the result.
Use this placement check:
- Name the field decision first.
- Set its oldest useful input.
- Set its latest useful result.
- Keep urgent safe action local.
- Measure each step in the trip.
- Stop the outside link once.
- Fill the local store once.
- Restart the local computer once.
- Replay a known event twice.
- Count late and repeated results.
- Add field support to cost.
- Reopen when the job changes.
Picture an IoT team using the ideas in Edge Cost and Trade-offs during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.
Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.
The mathematical gist. The chapter’s 1,000 Hz, 16-bit stream is 16 kbps (2,000 B/s) per sensor and has a 98.1 dB ideal converter ceiling. At a stated 50 nJ/bit, raw transmission costs 0.800 mW per sensor. Dropping to 8 bits halves radio work but loses 48.2 dB; extracting the chapter’s FFT features removes 95% of the stream while retaining 16-bit input evidence.
- Start With the Story
- In 60 Seconds
- Phoebe’s Field Notes: Why Bit Depth Costs Watts, Not Just Storage
- Practical Edge Computing Check
- Key Concepts
- For Beginners: Practical Edge Patterns
- Prerequisites
- Edge vs Cloud Latency Explorer
- Latency Calculator
- How to Use This Explorer
- Checkpoint: Placement Constraints
- Visual Reference Gallery
- Edge IoT Architecture
- Data at the Edge Architecture
- IoT System Architecture
- Worked Examples
- Factory Edge or Cloud Choice
First, translate edge placement into latency and reliability questions. Then compare reference architectures and worked cost examples. Next, use the calculators to test your own assumptions. Finally, check deployment standards, pitfalls, quizzes, and ROI practice.
Checkpoint callouts pause the long worked sections so you can verify the decision logic before moving on; deep dives stay optional when they only extend the arithmetic.
20.5 Learning Objectives
By the end of this chapter, you will be able to:
- Use Interactive Latency Tools: Calculate end-to-end latency for different processing locations (device, edge, cloud)
- Apply Worked Examples: Follow step-by-step calculations for real-world edge vs cloud decisions
- Avoid Common Pitfalls: Recognize and prevent typical edge deployment mistakes
- Make Informed Architecture Decisions: Select appropriate processing locations based on latency, bandwidth, and cost requirements
Key Concepts
- Pattern instantiation: The process of taking an abstract edge pattern (e.g., aggregate-at-fog) and translating it into a concrete implementation with specific hardware, protocols, and code, appropriate for a given IoT use case.
- Resource-constrained optimisation: Adapting algorithms and data structures to operate within the tight memory, CPU, and energy budgets of edge hardware, often requiring significant trade-offs compared to cloud implementations.
- Incremental feature rollout: Deploying a simple edge pattern first (threshold detection), validating it in production, and then layering more sophisticated patterns (ML inference) on top once the simpler baseline is stable.
- Edge pattern composition: Combining multiple edge patterns in sequence (filter → aggregate → compress → transmit) to achieve the required data reduction while maintaining the information content needed for analytics.
- Real-world calibration offset: The gap between how an edge pattern performs on clean simulated data versus how it performs with real sensor noise, device-to-device variability, and environmental interference.
Practical edge processing patterns are proven recipes for handling IoT data at the source. Like cooking recipes, each solves a specific problem: one filters noisy readings, another aggregates data to reduce uploads, and a third makes quick local decisions. Learning these patterns saves you from reinventing solutions that experienced engineers have already refined.
20.6 Prerequisites
Before diving into this chapter, you should be familiar with:
- Edge Compute Patterns Overview: Introduction to edge computing concepts
- Edge Processing Patterns: Understanding the four primary edge processing patterns
20.7 Edge vs Cloud Latency Explorer
Use this explorer to compare end-to-end latency for different placement options (device-only, edge gateway, cloud) under configurable network conditions. This helps you make informed decisions about where to process data in your IoT architecture.
20.8 Latency Calculator
20.9 How to Use This Explorer
Network Condition Presets:
- LAN/Wi-Fi: Edge latency 1-5 ms, Cloud latency 10-30 ms
- Cellular (4G/5G): Edge latency 10-20 ms, Cloud latency 50-150 ms
- Satellite/Rural: Edge latency 20-50 ms, Cloud latency 200-600 ms
Real-World Scenarios:
| Use Case | Max Latency | Recommended Architecture |
|---|---|---|
| Factory emergency shutdown | 10-20 ms | Device-local processing |
| Smart home automation | 50-100 ms | Edge gateway |
| Environmental monitoring | 1000 ms+ | Cloud processing acceptable |
| Autonomous vehicle control | 1-5 ms | Device-local with edge backup |
| Smart building HVAC | 500-1000 ms | Edge or cloud (either works) |
Factory emergency shutdown
Recommended architecture: Device-local processing
Smart home automation
Recommended architecture: Edge gateway
Environmental monitoring
Recommended architecture: Cloud processing acceptable
Autonomous vehicle control
Recommended architecture: Device-local with edge backup
Smart building HVAC
Read the Smart building HVAC material as a decision path rather than as isolated entries. First identify the operating condition in each entry and keep its units, timing, source, and assumed system state attached to it. Next compare the entries at the point where responsibility changes between device, gateway, network, analytic service, and operator; that hand-off is where apparently similar choices often produce different outcomes. Then follow the failure case: ask what becomes stale, delayed, unavailable, or unsafe, who detects it, and what evidence permits recovery. Finally connect the result to the chapter's running design record by naming the selected behavior, the rejected alternative, the measurement that justifies the choice, and the condition that forces a recheck. That order turns the examples or comparison into an auditable engineering argument.
Recommended architecture: Edge or cloud (either works)
Key Insights:
- WAN latency dominates: The round-trip to cloud (2x uplink) often exceeds total edge processing time
- Safety-critical systems: Must process locally — network failures cannot prevent emergency responses
- Hybrid is best: Edge for time-critical decisions, cloud for analytics and ML training
- Cost vs. Latency trade-off: Cloud processing may be cheaper but slower; edge requires hardware investment
Try These Experiments:
- Set cloud latency to 200 ms (satellite link) — see how edge becomes essential
- Set latency requirement to 20 ms — observe that only local processing works
- Compare bandwidth costs: Edge reduces data transmission by 90% through local aggregation
Checkpoint: Placement Constraints
You now know:
- Edge placement starts with the strictest latency, bandwidth, reliability, or privacy constraint.
- Safety-critical control cannot depend on a cloud round trip.
- Hybrid designs keep fast decisions local while leaving heavy analytics to cloud services.
20.10 Visual Reference Gallery
Edge-to-cloud path
The gateway bridges cloud services with RF, wireless, and wired device families.
Edge computing architecture places processing close to IoT sensors, enabling real-time decisions, reducing bandwidth requirements, and providing resilience during network outages. Edge gateways filter, aggregate, and preprocess data before selectively forwarding to cloud services.
Four layers of data at the edge
Data starts on physical devices, gets analyzed locally, and accumulates upward into storage for later synchronization.
Edge data architectures implement local storage and processing capabilities, enabling autonomous operation even when disconnected. Time-sensitive decisions occur locally while historical data synchronizes to cloud during connectivity windows.
Three-tier IoT architecture
Data flows upward from things to fog to cloud, while analytics and control insight can flow back down.
Complete IoT architectures span from physical devices through edge processing to cloud analytics. Understanding how data flows through each layer and where processing occurs is essential for designing efficient, scalable systems.
These architecture views show where data can be filtered, stored, or acted on. The worked examples now turn those placements into measurable cost, latency, and memory decisions.
20.11 Worked Examples
Scenario: A manufacturing plant deploys 500 vibration sensors on critical machinery. Each sensor generates 1,000 samples/second at 16-bit resolution. Management needs to decide between edge processing (local analysis with alerts) versus cloud processing (centralized analysis). The plant has a 100 Mbps internet connection.
Given:
- 500 sensors, each producing 1,000 samples/second
- Sample size: 16 bits (2 bytes) per sample
- Internet bandwidth: 100 Mbps
- Cloud storage cost: $0.023/GB/month
- Cloud compute cost: $0.05/hour for ML inference
- Edge gateway cost: $500 per unit (supports 50 sensors each)
- Latency requirement for safety alerts: < 50 ms
- Cloud round-trip latency: ~150 ms
Solution:
Step 1: Calculate raw data bandwidth requirements
Per sensor: 1,000 samples/sec x 2 bytes = 2,000 bytes/sec = 16 kbps Total for 500 sensors: 500 x 16 kbps = 8,000 kbps = 8 Mbps
With protocol overhead (~20%): 8 x 1.2 = 9.6 Mbps (fits within 100 Mbps)
Step 2: Calculate monthly data volume and cloud storage cost
Daily data: 8 Mbps x 86,400 sec/day / 8 bits/byte = 86.4 GB/day Monthly data: 86.4 x 30 = 2,592 GB/month Cloud storage cost: 2,592 x $0.023 = $59.62/month
Step 3: Evaluate latency requirement
Cloud path: Sensor to Network to Cloud to Analysis to Response = 150 ms minimum Edge path: Sensor to Local Gateway to Analysis to Response = ~10-20 ms
Verdict: Cloud path fails the 50 ms safety requirement.
Step 4: Design hybrid architecture
Edge processing (10 gateways x $500 = $5,000 upfront):
- Real-time vibration analysis at edge
- Anomaly detection with immediate alerts (< 20 ms)
- 95% data reduction through FFT features (send frequency spectrum, not raw samples)
Reduced cloud data: 2,592 GB x 5% = 129.6 GB/month Reduced storage cost: 129.6 x $0.023 = $2.98/month
Step 5: Calculate total cost comparison over 3 years
Cloud-Only Approach:
- Storage: $59.62/month x 36 = $2,146
- Bandwidth: 2,592 GB x $0.09/GB x 36 = $8,398
- Compute (24/7 ML): $0.05/hour x 8,760 x 3 = $1,314
- Total: $11,858 (and fails latency requirement!)
Edge-Hybrid Approach:
- Edge hardware: $5,000 (one-time)
- Reduced storage: $2.98 x 36 = $107
- Reduced bandwidth: 129.6 GB x $0.09 x 36 = $420
- Cloud compute (periodic training only): $500/year x 3 = $1,500
- Total: $7,027 (and meets latency requirement!)
Result: Edge-hybrid architecture saves $4,831 (41%) over 3 years while meeting the critical 50 ms latency requirement that pure cloud cannot achieve.
20.12 Continue to the Next Part
Carry this evidence into Practical Edge Computing: Bandwidth and Inference Budgets, which begins with Putting Numbers to It.