17 IoT Edge Models: Processing Levels

analytics-ml

edge

patterns

iot

17.1 Start With the Decision

Keep the first design small. Use one sensor, one local check, and one outside service.

17.2 Route Overview

This is part 1 of 2. Continue with IoT Edge Models: Cold-Chain Processing.

17.3 Part Objectives

Test iot edge reference check with a concrete scenario and pass criteria.
Validate level 3 processing functions in detail with a concrete scenario and pass criteria.

17.4 Start With the Story

Imagine a factory camera that notices a blocked walkway. Sending every frame away would be slow and costly. An edge system does some work near the camera before it sends a result. Bandwidth means how much data a link can carry in a given time.

Start with the decision the system must support. Keep the first useful check close to the sensor when delay, privacy, or link cost matters. Send the evidence that another person needs to review the result. Then test a lost connection, a stale model, and a wrong alert. The design should say what continues locally and when a person must step in.

Keep the first design small. Use one sensor, one local check, and one outside service. Write the input and output in plain words. Time the local result. Time the sent result. Turn off the link. Show what the operator sees. Restore the link. Mark any old result. This short trial often reveals where the first useful decision should live.

Use a short placement review. Name the raw input. Name the first useful result. Set the latest safe response time. Mark any private data. Measure the link on a bad day. Decide what the device can do alone. Decide what the site can do offline. Send only what the next step needs. Keep enough detail to explain an alert. Record the model and rule in use. Mark old results as old. Give a person a clear way to pause a wrong action.

The best location is not always the nearest one. It is the place that meets the need and leaves honest evidence. Recheck that choice when data, links, models, or risks change.

This simple path does not decide every placement question. Some work belongs on the device, some at a site, and some in a central service. The Practitioner section maps those jobs to the IoT reference levels. Under the Hood examines timing, trust, and data-flow trade-offs.

Picture an IoT team using the ideas in Edge in the IoT Reference Model 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.

In 60 Seconds

The seven-level IoT Reference Model defines where data processing occurs in IoT systems. Levels 1-3 handle operational technology (data in motion): physical devices, connectivity, and edge computing. Level 4 converts data in motion to data at rest. Levels 5-7 handle information technology: data abstraction, applications, and business collaboration. Level 3 (edge computing) is the critical transformation layer where raw data is evaluated, formatted, distilled, and assessed before storage.

Chapter Roadmap

Start With the Story
In 60 Seconds
IoT Edge Reference Check
Key Concepts
Edge in the IoT Model Basics
Prerequisites
IoT Reference Model Overview
Level 1 Devices and Controllers
Level 2 Connectivity
Level 3 Edge Computing
Putting Numbers to It
Edge Bandwidth Savings Calculator
Level 3 Processing Functions in Detail
Checkpoint: Level 3 Transformation

This chapter follows data as it climbs the reference model:

First separate the device, connectivity, edge-computing, and storage responsibilities.
Then recompute the Level 3 bandwidth bill for vibration data.
Next test the same functions against cold-chain monitoring and processing-location choices.
Finally connect the model to application requirements, quizzes, and the placement-contract chapter.

Checkpoints recap the placement decisions. Calculation panels and practice exercises can be collapsed on a first read.

17.5 Learning Objectives

By the end of this chapter, you will be able to:

Explain the Seven-Level IoT Reference Model: Describe how data flows from physical devices through edge processing to cloud analytics
Distinguish OT vs IT Layers: Classify which levels handle operational technology (data in motion) versus information technology (data at rest)
Apply Level 3 Processing Functions: Implement evaluation, formatting, decoding, distillation, and assessment at the edge
Design for Data Accumulation: Determine appropriate storage strategies at Level 4 based on data characteristics

IoT Edge Reference Check

Key Concepts

IoT reference model: A standardised multi-tier architecture model (physical → network → middleware → application → business) that provides a common vocabulary and design framework for IoT system architects.
Device tier: The lowest layer of the IoT reference model containing physical sensors, actuators, and embedded processing — the tier where edge patterns are most directly applied.
Connectivity tier: The network layer responsible for transporting sensor data from devices to higher processing tiers, using protocols suited to the device’s power, range, and bandwidth constraints.
Edge analytics tier: An intermediate processing layer (typically gateways or fog nodes) that applies data reduction, event detection, and protocol translation before forwarding to cloud.
Cross-tier optimisation: Designing computation placement, data formats, and communication frequencies across multiple tiers simultaneously rather than optimising each tier in isolation.

Edge in the IoT Model Basics

This chapter shows where edge data processing fits in the larger IoT architecture. Think of understanding where the kitchen sits in a restaurant floor plan — knowing the overall layout helps you design each part to work well with the others. The IoT reference model maps out how data flows from sensors through edge devices to the cloud.

17.6 Prerequisites

Before diving into this chapter, you should be familiar with:

Edge Compute Patterns Overview: Introduction to edge computing concepts and application types
Edge, Fog, and Cloud Overview: Understanding the three-tier architecture

Use those prerequisites as orientation: this chapter names the reference-model levels first, then asks which evidence each layer should produce.

17.7 IoT Reference Model Overview

The IoT Reference Model provides a structured framework for understanding where data processing occurs in IoT systems. It spans seven levels, from physical devices at the bottom to business collaboration at the top. Start with Figure 17.1 because placement only becomes meaningful once the whole path and the Level 3 transformation boundary are visible.

Seven-layer IoT Reference Model diagram showing Level 1 Physical Devices at bottom through Level 7 Business Collaboration at top, with Level 3 Edge Computing highlighted as the transformation layer performing evaluation, formatting, distillation, and assessment — Figure 17.1: IoT Reference Model Seven Layers with Edge Computing Functions

Read Figure 17.1 from Level 1 upward. Devices create observations, connectivity moves them, and Level 3 evaluates, formats, distils, or assesses them before Level 4 makes data durable. Higher levels then analyse, present, and turn accumulated evidence into organisational action. With that path established, the timeline in Figure 17.2 shows what changes when a response stops locally or continues upward.

Latency timeline comparing edge processing path at Level 3 adding 10ms for 20-60ms total local response versus cloud path through Levels 5-7 taking seconds to minutes for deep analytics — Figure 17.2: Sequence timeline showing latency at each IoT Reference Model level

Read Figure 17.2 from the local branch to the cloud branch. The local route stops at Level 3 for a response measured in tens of milliseconds, whereas the cloud route crosses accumulation and higher-level processing and can take seconds or longer. The comparison connects level placement to the chapter’s running constraints—latency, bandwidth, and the amount of context required by the decision. The architecture comparison in Figure 17.3 applies that timing distinction to complete system shapes.

IoT Reference Model Levels 1-7: Seven-layer architecture showing transition from Operational Technology (data in motion, Levels 1-3) to Information Technology (data at rest, Levels 5-7). Level 3 edge computing performs critical functions: evaluation, formatting, reduction, and assessment before data accumulation at Level 4.

The paired architecture diagram in Figure 17.3 asks whether immediate device traffic must reach the central service or can terminate at a governed local node.

Figure 17.3: Cloud-centric vs edge-centric IoT architecture

Use Figure 17.3 to compare the two routing shapes. On the cloud-centric side, device traffic and immediate decisions depend on the central service; on the edge-centric side, a local node can absorb processing and continue selected decisions near the source. The layered diagram in Figure 17.4 then shows how that local node participates in a larger data path.

Layered architecture diagram showing IoT devices at bottom, edge processing layer in middle performing filtering and aggregation, and cloud services at top for analytics and storage — Figure 17.4: Data at the edge architecture overview

Trace Figure 17.4 from devices through filtering and aggregation at the edge to cloud analytics and storage. That order shows that edge and cloud are complementary tiers, not competing labels: the edge handles bounded, time-sensitive reduction, and the cloud retains the broader history and compute needed for fleet analysis and business collaboration. This completes the running route from reference-model level to latency consequence and then to an implementable tier boundary.

17.8 Level 1 Devices and Controllers

The IoT Reference Model starts with Level 1: Physical devices and controllers that might control multiple devices. These are the ‘Things’ in the IoT, and they include a wide range of endpoint devices that send and receive information. Today, the list of devices is already extensive and it will become almost unlimited as more equipment is added to the IoT over time.

Device Categories at Level 1:

Category	Examples	Data Generated
Sensors	Temperature, humidity, pressure, motion	Continuous measurements
Actuators	Motors, valves, switches, displays	State changes, commands
Controllers	PLCs, MCUs, embedded systems	Processed signals, control loops
Gateways	Protocol converters, edge boxes	Aggregated device data

17.9 Level 2 Connectivity

Level 2 contains communications and connectivity — providing reliable, timely information transmission. This includes transmissions from devices (Level 1) to the network, across the network, and into the edge computing layer (Level 3).

Before treating Level 2 as a reliable transport layer, inspect Figure 17.5 to see where its promises must be tested. The numbered topology makes the route concrete: devices may use different access links, may hand traffic to a gateway, and may reach the backend through different failure and trust boundaries. That is why connectivity must be reviewed as a set of constrained paths rather than as one abstract link.

IoT network regions span PAN at 10–100 m, LAN at 100–1000 m and WAN up to 100 km, with Bluetooth, WiFi and cellular labels. — Figure 17.5: Networking and connectivity in IoT systems

Trace Figure 17.5 from devices through their Wi-Fi, cellular, LoRaWAN, or wired links and any gateway toward the backend. Compare range, power, bandwidth, and failure boundaries before treating the paths as equivalent connectivity. A gateway changes protocol and trust responsibilities, while a direct IP path moves more of those responsibilities onto the device. This advances the reference-model narrative: Level 2 must deliver the identity, time, and payload evidence that Level 3 is expected to evaluate and transform.

Connectivity Considerations:

Protocol selection: Match protocol to bandwidth, range, and power requirements
Network topology: Star, mesh, or hybrid depending on reliability needs
Reliability mechanisms: Acknowledgments, retransmission, error correction
Security: Encryption, authentication at the transport layer

17.10 Level 3 Edge Computing

Level 3 focuses on high-volume data analysis and transformation. It converts network data flows from Level 2 into information suitable for storage and higher-level processing at Level 4 (data accumulation). Level 3 processing can include:

Evaluation: Applying criteria to determine if data should be processed at a higher level
Formatting: Reformatting data to improve consistency
Expanding/decoding: Decrypting data and translating device-specific code
Distillation/reduction: Distilling data to reduce the amount of network traffic
Assessment: Determining whether data should trigger a response

17.11 Putting Numbers to It

Consider a fleet of 100 vibration sensors sampling at 10 kHz (10,000 samples/sec):

Without Level 3 processing (raw transmission to cloud): $\text{Per sensor} = 10{,}000\text{ samples/s} \times 2\text{ bytes} = 20{,}000\text{ bytes/s} = 19.5\text{ KB/s}$ $\text{Fleet total} = 19.5\text{ KB/s} \times 100 = 1{,}950\text{ KB/s} \approx 1.9\text{ MB/s}$ $\text{Monthly bandwidth} = 1.9\text{ MB/s} \times 2{,}592{,}000\text{ s} \approx 4{,}809\text{ GB}$ $\text{Cloud ingestion cost} = 4{,}809\text{ GB} \times \text{\$0.15/GB} \approx \text{\$721/month}$

With Level 3 edge processing (512-point FFT every 51.2 ms):

Transmit only top 20 frequency components (40 bytes) at ~19.5 Hz $\text{Per sensor} = 40\text{ bytes} \times 19.5\text{ Hz} = 780\text{ bytes/s}$ $\text{Fleet total} = 780\text{ bytes/s} \times 100 = 78{,}000\text{ bytes/s} \approx 76\text{ KB/s}$ $\text{Monthly bandwidth} = 76\text{ KB/s} \times 2{,}592{,}000\text{ s} \approx 188\text{ GB}$ $\text{Cloud ingestion cost} = 188\text{ GB} \times \text{\$0.15/GB} \approx \text{\$28/month}$

Result: Level 3 achieves 96% cost reduction ($721 to $28/month) while preserving spectral anomaly detection. This is the power of distillation at the edge.

17.12 Edge Bandwidth Savings Calculator

Use this interactive calculator to explore how edge processing reduces bandwidth and cost for vibration monitoring fleets.

The architecture diagram in Figure 17.6 connects the calculator’s bandwidth result to the physical processing path that produces it.

An edge IoT gateway bridges internet servers and devices over RF and wire. Big things use complex data models; small and non-IP things have constrained, simple models. — Figure 17.6: Edge IoT architecture and processing overview

Read Figure 17.6 from sensors into the edge gateway, then follow evaluation, filtering, and aggregation before the selective cloud transmission. The calculator quantifies the difference between the raw and reduced branches; the diagram shows where that difference is created and which boundary must preserve event meaning. This connects the arithmetic to the running model: bandwidth savings are defensible only when the retained stream still supports the cloud decision and the gateway records what it discarded or summarised.

17.13 Level 3 Processing Functions in Detail

Read the Level 3 Processing Functions in Detail 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.

Evaluation determines whether data warrants further processing:

Raw reading: temperature = 23.4 C
Evaluation criteria: Alert if > 30 C or < 10 C
Result: Within normal range -> do not escalate

Formatting standardizes data from heterogeneous sources:

Device A reports: {"temp": 23.4, "unit": "C"}
Device B reports: {"temperature_f": 74.12}
Formatted output: {"temperature_celsius": 23.4, "timestamp": "2026-01-19T10:30:00Z"}

Distillation reduces data volume while preserving key information:

Input: 1000 temperature readings over 1 minute
Distillation: min=22.1, max=24.8, avg=23.4, stddev=0.5
Output: 4 values instead of 1000 (99.6% reduction)

Assessment triggers immediate local responses:

Vibration reading: 8.5 g-force (threshold: 5.0)
Assessment: CRITICAL - exceeds safe operating limit
Action: Trigger immediate machine shutdown (local actuator)

Checkpoint: Level 3 Transformation

You now know:

Levels 1-2 collect and move operational data before edge processing changes it.
Level 3 evaluates, formats, decodes, distills, and assesses data before storage.
The vibration example drops monthly transfer from about 4,809 GB and $721 to about 188 GB and $28.

17.14 Continue to the Next Part

Carry this evidence into IoT Edge Models: Cold-Chain Processing, which begins with Cold Chain Edge Processing.