50 Applied: Edge Workload Placement
50.1 Start With the Story
Picture an IoT team using the ideas in Applied: Edge Workload Placement 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.
50.2 Learning Objectives
After this page, you should be able to:
- Place processing stages on device, edge, fog, storage, cloud, or application tiers based on latency, bandwidth, privacy, and compute constraints.
- Distinguish connectivity movement from Level 3 semantic transformation in the IoT reference model.
- Specify evidence records for local alarms, cloud model updates, and tier-crossing data reductions.
- Review what information is lost when raw data becomes features, summaries, events, or work orders.
50.3 Why Placement Follows IoT Tiers
Edge in the IoT Reference Model maps edge computing onto the seven-layer reference model. This page turns that map into an implementation contract: what runs at each tier, which tier owns the consequence, and what evidence must cross boundaries so a later operator can explain the decision.
Use it when a system mixes local gateway decisions, fog aggregation, cloud analytics, model rollout, and application workflows.
50.4 Choose the Right Tier
The IoT reference model spreads computation across a continuum: the device itself, the edge/fog (a gateway or local server near the data), and the cloud (elastic but distant). The design skill is not choosing device or cloud, but deciding which tier each piece of processing belongs on.
Four forces drive that placement: latency (how fast must it respond?), bandwidth (how much data would travel?), privacy (must the raw data stay local?), and compute/energy (how heavy is the work?). Read those four for each stage of a pipeline and the right tier usually names itself.
A useful way to apply the model is to follow one measurement upward. Level 1 creates the observation, such as a vibration sample or a temperature reading. Level 2 carries it across a local link. Level 3 decides whether the stream needs immediate action, format repair, feature extraction, or aggregation before it becomes a stored record at Level 4. Levels 5 to 7 then use the accumulated data for analytics, applications, and business coordination. That ordering prevents a common design error: calling every gateway task “connectivity” just because it sits near the network. If the gateway interprets payloads, removes noise, computes a feature, or triggers a local response, it is doing Level 3 edge work.
Intuition: keep the fast, private, bandwidth-heavy work close to the sensor, and send only the distilled, heavy-lifting, big-picture work to the cloud. The edge decides; the cloud learns.
For example, a cold-chain truck may sample temperature at Level 1 and forward readings over BLE or a vehicle bus at Level 2. The gateway at Level 3 rejects impossible values, converts units, checks the 8 C compliance threshold, and sends one-minute summaries unless an excursion occurs. Level 4 stores the summaries and alert events. Fleet dashboards and route-planning applications use those records later, but the compliance-critical decision already happened at the edge.
50.4.1 Overview Knowledge Check
50.5 Practitioner: Placing Each Stage
In practice, tier placement starts as a row-by-row review of the data path. Write down each operation, then mark the deadline, raw input size, privacy boundary, failure mode, and update cadence. Operations with hard deadlines or raw high-rate signals stay close to the gateway. Operations that compare many sites, train models, or join historical records move upward. The reference model is useful because it makes those decisions explicit: “filter vibration peaks at L3, store events at L4, retrain bearings model at L5, show maintenance work order at L6.”
Latency-critical (a safety cutoff) -> edge (no cloud round trip)
High-volume raw data (kHz sampling) -> edge reduces it to summaries
Privacy-sensitive (voice, video, health)-> keep raw at the edge
Heavy training / fleet-wide analytics -> cloud (elastic compute)Worked example: a vibration monitor for a machine
Raw signal: accelerometer at 10 kHz -> ~10,000 values/sec.
Stream all raw to cloud? No -- bandwidth is huge and a
fault alarm cannot wait for a cloud round trip.
Placement:
EDGE: compute features + anomaly score locally; raise the
alarm in milliseconds; transmit only summaries + events
CLOUD: collect summaries from the whole fleet; retrain the
model; push the updated model back down to the edge
Result: fast local decisions, small uplink, global learning.This split – inference at the edge, training in the cloud, models pushed back down – is the backbone pattern of production IoT analytics.
A design review should also record the evidence contract for each tier. The edge alarm should include the sensor ID, feature window, threshold version, local clock, and gateway software version so the cloud can audit why a shutdown happened. The cloud model update should include the training data period, model hash, rollout target, and rollback condition before it is pushed back to gateways. Without those contracts, the architecture may look layered on a diagram but fail in operations because teams cannot explain which tier made a decision or reproduce it later.
Use a simple rule of thumb: the tier that owns the consequence should hold enough evidence to defend that consequence. A gateway that stops a motor must retain the local readings and threshold that justified the stop. A cloud service that changes a maintenance interval must retain the fleet-level trend and model version that justified the change.
50.5.1 Practitioner Knowledge Check
50.6 Edge Continuum, Not Switch
Under the hood, the placement decision is about what state changes at each boundary. Level 2 moves packets and frames, so its evidence is delivery status, link quality, retries, and addresses. Level 3 changes the meaning of the payload: raw waveforms become features, device-specific payloads become a common schema, and readings become alerts, summaries, or local control actions. Level 4 changes persistence state by assigning retention, indexes, lineage, and replay rules. Levels 5 to 7 change organizational state by turning stored records into trends, dashboards, maintenance tickets, automation rules, or business decisions.
That separation is useful during outages. If the cloud is unavailable, a well-designed Level 3 gateway can keep applying local safety rules, buffer evidence, and forward a compressed backlog when connectivity returns. If the gateway is unavailable, Level 4 may show stale records but should not pretend that fresh local assessment occurred. If a model changes in the cloud, gateways need a versioned rollout so every local decision can be traced to the model actually running at the time. The reference model is therefore both an architecture diagram and an accountability map.
The other hidden issue is information loss. Edge reduction is valuable only when the discarded data is not needed for the decision being defended. Sending one-minute averages may be correct for billing or environmental trends, but wrong for diagnostics that need spikes, spectra, or phase relationships. Keeping only event clips may protect privacy, but incident review still needs timing, thresholds, confidence, and local clock evidence. Good edge designs document these losses deliberately, with a rule for when the gateway keeps richer evidence temporarily.
Latency by tier
A cloud round trip is typically tens to hundreds of milliseconds; local edge processing is sub-millisecond to a few milliseconds. That gap alone forces real-time control to the edge.
Bandwidth is a cost, not just a limit
Streaming raw high-rate data is often infeasible and always expensive. The edge’s core job is data reduction – filter, aggregate, featurize – so only valuable, compact data travels.
Fog fills the middle
Between device and cloud sits fog computing on gateways and local servers: more power than a sensor, lower latency than the cloud. Many pipelines place different stages on different tiers.
Privacy is a placement force
Keeping raw voice, video, or health data on the device and sending only derived results is often the simplest privacy control: the data that never leaves cannot leak.
So the reference model is a spectrum of placement choices, not an on/off switch. The same application routinely runs sensing and real-time inference at the edge, aggregation on a fog gateway, and training plus fleet analytics in the cloud – each stage placed where its latency, bandwidth, privacy, and compute needs are best served.
A strong placement contract names the state mutation at each crossing. For a Level 3 edge crossing, write the raw input, the transformation, the output summary, the local rule or model version, and the retained replay evidence. For a Level 4 storage crossing, write the schema, retention class, lineage key, and replay or deletion rule. For a Level 5 to 7 crossing, write the analytics result, application action, owner, and business consequence.
This separation matters for failure handling. Cloud dashboards should label stale records when the gateway is offline; gateways should continue local safety rules when the cloud is offline; and model rollout should leave enough version evidence to explain a local action weeks later. The reference model is therefore both an architecture diagram and an accountability map.
A useful sanity check is to ask whether a tier crossing loses information needed for a later defense. Sending only averages upstream may be correct for billing or environmental trends, but wrong for diagnostics that need spikes or spectra. Keeping only event clips may protect privacy, but it must still preserve enough timing and threshold evidence for incident review. Good edge designs document those losses deliberately instead of discovering them after the raw data is gone.
50.6.1 Under-the-Hood Knowledge Check
50.7 Release Checklist
Before shipping a reference-model placement contract, verify these records:
- Each pipeline operation names its owning tier: device, connectivity, edge/fog, storage, analytics, application, or business process.
- Local actions include the source data window, rule or model version, timestamp, gateway software version, and rollback or manual-review path.
- Cloud model updates include training period, model hash, target fleet, rollout gate, fallback version, and gateway acknowledgement record.
- Data-reduction boundaries say what was discarded, what summary evidence remains, and when richer raw evidence is retained temporarily.
- Outage behavior is explicit for each tier, including local operation, buffered replay, stale-data labels, and post-reconnect reconciliation.
50.8 See Also
- Edge in the IoT Reference Model for the seven-layer placement map.
- Edge Processing Patterns for filter, aggregate, infer, and store-forward implementation choices.
- Edge Stream Window Contracts for window semantics and bounded state behind edge summaries.
- Edge Patterns Placement and Cost Contracts for cost, latency, privacy, and lifecycle review.
50.9 Next
Return to Edge in the IoT Reference Model, then continue to Edge Patterns Practical Guide for worked placement decisions.