7 Lab: Edge-Fog Computing
Measure Local Decisions, Site Coordination, and Cloud Review
7.1 Start Simple
Treat the lab like a small site rehearsal rather than a recipe to copy. One sensor reading becomes one local decision, then one site summary, then one outage drill, and finally one placement record. Everyday IoT teams use this pattern because measurements beat slogans about edge, fog, or cloud. Start by building the smallest repeatable run that produces a timestamped result, then compare it with the upstream path before adding more devices or scenarios.
7.2 Learning Objectives
By the end of these labs, you will be able to:
- Build a small edge/fog lab plan with measurable acceptance criteria.
- Implement a local guard that separates immediate action from upstream reporting.
- Design an aggregation record that preserves useful evidence without uploading every raw sample.
- Test fallback behavior when a gateway or cloud path is unavailable.
- Write a lab decision record that explains which tier owns each workload.
7.3 Lab Outcomes
7.3.1 Lab 1: Local Guard
You will define a sensor reading, a local threshold, a device action, and a log record. The device path handles immediate behavior; the upstream path receives evidence for later review.
7.3.2 Lab 2: Site Aggregation
You will combine readings from a small group of devices into a site summary. The gateway path applies site rules, buffers records, and sends summaries upstream when available.
7.3.3 Lab 3: Cloud Review
You will compare local and site records with cloud-facing reporting needs. The cloud path does not override local safety without a controlled management path.
7.3.4 Lab 4: Failure Drill
You will intentionally remove the upstream path and verify which behavior continues, which records are buffered, and what must be reconciled later.
7.4 Before You Build
Treat the simulator or hardware board as a measurement harness, not as proof by itself. A useful lab starts with a short plan.
7.4.1 Workload
Name the event or calculation. Example: “detect a temperature reading outside the allowed operating range” is better than “test edge computing.”
7.4.2 Budget
State the response, bandwidth, storage, and evidence requirements using values from your course setup or deployment scenario.
7.4.3 Ownership
Decide which tier owns immediate action, which tier owns site coordination, and which tier owns long-term review.
7.4.4 Failure Mode
Write what should happen when the upstream path, gateway, or dashboard is unavailable.
An edge/fog lab is complete only when the failure behavior is measured. A design that works while every network path is healthy has not yet proven local autonomy.
7.5 Simulator Setup
Use a browser-based ESP32 simulator or a physical ESP32-style development board. The exact tool matters less than repeatability.
7.5.1 Suggested Simulator Parts
- ESP32-compatible board
- One analog input, such as a potentiometer or temperature sensor
- Three LEDs or serial labels for edge, fog, and upstream states
- One button or serial command for network availability
7.5.2 Suggested Physical Parts
- ESP32-compatible board
- Breadboard and jumper wires
- Analog sensor or potentiometer
- LEDs with current-limiting resistors
- USB serial monitor
7.6 Scenario Cards and Calibration Plan
Use scenario cards to make the simulator produce decision evidence instead of a generic demo:
| Scenario | Edge behavior | Fog or upstream behavior | Evidence to capture |
|---|---|---|---|
| Safety interlock | Act locally when the threshold is crossed. | Receive a summary and reconcile the event later. | Local response time, outage behavior, and event log. |
| Site video filtering | Drop or redact unneeded frames near the source. | Store summaries, samples, or flagged clips. | Data reduction ratio and retained-evidence policy. |
| Multi-sensor diagnosis | Keep sensor fusion or local voting available during intermittent links. | Aggregate across a room, line, or site. | Correlation window, missing-sensor behavior, and false alarm notes. |
| Fleet trend review | Send compact features or rollups rather than every raw sample. | Compare sites and update thresholds. | Rollup definition, sample retention, and update rollback rule. |
Before treating simulator output as deployment evidence, replace defaults with measured or explicitly justified values: sensor sample rate, local processing time, gateway latency, upstream bandwidth, outage duration, retry policy, and failure probability. Keep those inputs with the lab decision record so another learner can rerun the same placement choice.
Open a new ESP32 project in your preferred simulator, such as Wokwi, then build the circuit described in this chapter. Keep a copy of the simulator URL, sketch version, and any diagram file you use so another learner can reproduce the run.
7.7 Lab 1: Local Guard
The local guard lab separates immediate device behavior from reporting. The edge path should be small enough to understand and test.
Run it: Prove why the guard belongs at the edge before you code it. In the latency comparison tool below, load a workload preset and watch one event travel through edge, fog, cloud, and hybrid paths against a response budget, then raise payload size or WAN distance until the cloud path misses the deadline while the edge path still fits. Read the P95 and P99 margin, not just the average, and use that evidence to justify which tier owns the immediate local action.
7.7.1 Edge Responsibility
Read the sensor, validate the reading, compare it with the local rule, and trigger the local indicator or actuator when needed.
7.7.2 Upstream Responsibility
Receive event records, retain history, and support later analysis. It should not be required for the immediate local action.
7.7.3 Local Guard Sketch Pattern
Use this pattern in your sketch. Replace pin numbers and thresholds with values from your lab setup.
struct Reading {
float value;
bool valid;
};
struct EventRecord {
float value;
bool localAction;
bool upstreamQueued;
};
Reading readSensor() {
int raw = analogRead(SENSOR_PIN);
bool valid = raw >= SENSOR_MIN && raw <= SENSOR_MAX;
return { convertToUnits(raw), valid };
}
EventRecord evaluateLocally(Reading reading) {
bool action = reading.valid && reading.value >= LOCAL_LIMIT;
digitalWrite(EDGE_LED_PIN, action ? HIGH : LOW);
return { reading.value, action, true };
}7.7.4 Lab 1 Procedure
1. Define the rule Choose a local limit and explain why that decision belongs near the device.
2. Run the local path Move the sensor value across the limit and confirm that local action does not require an upstream response.
3. Record evidence For each run, record the input condition, local result, upstream queue state, and any unexpected behavior.
4. Change the upstream path Disable the simulated network or gateway path and confirm that local behavior still follows the rule.
7.8 Lab 2: Site Aggregation
The site aggregation lab introduces the fog tier. The fog node does not have to be a special product; it is the local coordination role.
Run it: See the fog tier make its offload and escalation choices in the animation below before you write the aggregation code. Pick an offloading policy – Deadline first, Save device energy, or Reduce WAN traffic – and step through as the fog node decides which tasks it handles locally and which it sends upstream, watching how the Reduce WAN traffic policy holds ordinary summaries and forwards only unusual evidence. Let that shape your site summary and escalation rule.
7.8.1 Site Summary
Aggregate readings into a compact record that includes count, range, average, state changes, and retained evidence when needed.
7.8.2 Escalation Rule
Send ordinary summaries upstream on schedule. Retain or upload additional evidence only when the lab rule says the situation is unusual.
7.8.3 Aggregation Record Pattern
struct SiteSummary {
float minimum;
float maximum;
float total;
unsigned int count;
bool unusual;
};
void addReading(SiteSummary &summary, float value) {
summary.minimum = min(summary.minimum, value);
summary.maximum = max(summary.maximum, value);
summary.total += value;
summary.count += 1;
summary.unusual = summary.unusual || value >= LOCAL_LIMIT;
}
float averageOf(const SiteSummary &summary) {
return summary.count == 0 ? 0 : summary.total / summary.count;
}7.8.4 Lab 2 Procedure
1. Choose a window Define how many readings or how much time belongs in one site summary. Use the physical process as the reason, not a default copied from another lab.
2. Preserve extremes Keep minimum, maximum, count, and an unusual-state flag so the summary does not hide important behavior.
3. Compare records Compare one raw log and one summary record. Explain what the summary preserves and what it intentionally discards.
4. Test buffering Disable the upstream path and verify that summaries are buffered or marked for later reconciliation.
7.9 Lab 3: Cloud Review
Cloud review is not the opposite of edge computing. It is where longer-running comparison and governance belong.
7.9.1 History
Store accepted summaries and retained evidence so later analysis can explain what happened.
7.9.2 Fleet Comparison
Compare several sites, versions, or device groups to find patterns that one device cannot see.
7.9.3 Governed Updates
Plan configuration, model, or rule changes through a management path with rollback and audit records.
7.10 Lab 4: Failure Drill
Run the same input sequence in at least two states: upstream available and upstream unavailable. The expected behavior should be different only where the plan says it should be different.
7.10.1 Must Continue
Local guard evaluation, local indication, critical local actuation, and local event recording.
7.10.2 May Degrade
Dashboard freshness, cloud upload, cross-site reporting, and remote policy updates.
7.10.3 Must Be Reconciled
Buffered records, missed upload attempts, configuration versions, and any state changes made while disconnected.
7.10.4 Must Be Auditable
The final report should show what ran locally, what was buffered, what was uploaded later, and what still needs review.
Record the outage run in the lab notebook instead of relying on a hidden widget: outage length, queue size, records buffered, records dropped, local actions that continued, and the reconciliation result after the upstream path returns.
7.10.5 Interactive: Rehearse the Outage Run
7.11 Lab Decision Record
Fill this record after the lab, not before.
7.12 Practice Checks
7.13 Common Mistakes
7.13.1 Treating Delays as Universal
Simulator timings are teaching evidence for one setup. Production budgets must be measured on the actual network, firmware, gateway, and workload.
7.13.2 Hiding Extremes in Averages
Averages are useful, but they can hide short-lived states. Preserve ranges, counts, unusual flags, or retained samples when the decision depends on them.
7.13.3 Blocking Local Action on Cloud Review
Cloud review can improve the system later. It should not block the minimum safe local behavior during an outage.
7.13.4 Forgetting Reconciliation
Disconnected operation creates records that must be reconciled later. The lab should show how those records are identified and uploaded.
7.14 Make the Measurement Honest
A believable lab records more than a single average. Take a concrete workload:
100 sensors x 1 msg/s x 200 bytes = 20,000 B/s = 20 KB/s raw upstream
edge deadband suppresses about 90% of unchanged readings
-> about 2 KB/s upstream, a 10x reduction
while local threshold alerts still fire in less than 10 msThat 10x number is only trustworthy if it survives scrutiny. An honest lab reports the measurement method, the result under a stressed condition, the tail latency, and the failure behavior when a tier is unreachable. A 10x saving measured over one quiet minute is weak evidence; the same saving measured at peak, at the 95th percentile, and with the cloud link cut is much more useful.
If the average upstream reduction is 10x but the 95th-percentile local alert latency doubles during a burst, the placement may need a smaller aggregation window, a protected local queue, or a stricter rule for bypassing summaries. If the fog tier buffers records during an outage, mark replayed events with original event time so the cloud does not treat delayed records as fresh alarms.
Also record what the lab did not prove. A simulator run may prove the logic and measurement method, while production still needs the actual radio link, firmware, gateway storage, and cloud ingestion path tested before deployment.
7.15 Summary
Edge and fog labs should prove placement decisions with evidence. The edge path owns immediate local behavior, the fog path coordinates a site, and the cloud path supports review and governance. A lab is strong when it records the workload, measurement method, preserved evidence, failure behavior, and final placement decision.
7.16 What’s Next
Continue to Edge-Fog Latency to study how response budgets are analyzed, or use Edge-Fog Decision Framework to turn your lab evidence into a placement decision.
7.17 Key Takeaway
A useful lab measures more than whether the demo works. Capture latency, throughput, CPU, memory, power, queue behavior, update behavior, and failure recovery so the result can guide deployment decisions.