52  Edge Computing: IoT Reference Model

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.

52.1 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

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.

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.

52.2 Prerequisites

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

52.3 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.

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 52.1: IoT Reference Model Seven Layers with Edge Computing Functions
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 52.2: Sequence timeline showing latency at each IoT Reference Model level

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.

Comparison diagram showing cloud-centric architecture where all IoT devices connect to centralized cloud versus edge-centric architecture with local processing nodes reducing cloud dependency and latency
Figure 52.3: Cloud-centric vs edge-centric IoT architecture
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 52.4: Data at the edge architecture overview

52.4 Level 1: Physical 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

52.5 Level 2: Connectivity (Communication and Processing Unit)

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).

Network topology diagram illustrating various IoT connectivity options including Wi-Fi, cellular, LoRaWAN, and wired connections linking devices through gateways to backend systems
Figure 52.5: Networking and connectivity in IoT systems

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

52.6 Level 3: Edge (Fog) Computing (Data Element Analysis and Transformation)

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

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{,}925\text{ GB}\] \[\text{Cloud ingestion cost} = 4{,}925\text{ GB} \times \text{\$0.15/GB} \approx \text{\$739/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 197\text{ GB}\] \[\text{Cloud ingestion cost} = 197\text{ GB} \times \text{\$0.15/GB} \approx \text{\$30/month}\]

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

52.6.1 Edge Bandwidth Savings Calculator

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

Detailed edge IoT system architecture showing data flow from sensors through edge gateways performing real-time processing, filtering, and aggregation before selective transmission to cloud
Figure 52.6: Edge IoT architecture and processing overview

52.6.2 Level 3 Processing Functions in Detail

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)

52.7 Worked Example: Edge Processing for a Cold Chain Monitoring System

Scenario: A pharmaceutical distributor monitors 50 refrigerated trucks, each carrying 20 temperature sensors that sample at 1 Hz (once per second). The system must detect temperature excursions above 8 degrees Celsius within 30 seconds for regulatory compliance.

Without Edge Processing (Cloud-Only Architecture):

Metric Calculation Value
Raw data rate per truck 20 sensors x 1 sample/sec x 16 bytes 320 bytes/sec
Fleet data rate 50 trucks x 320 bytes/sec 16,000 bytes/sec (16 KB/s)
Daily data volume 16 KB/s x 86,400 sec 1.38 GB/day
Monthly cellular data cost 1.38 GB/day x 30 days x $0.10/MB $4,140/month
Cloud ingestion cost 41.4 GB/month x $0.25/GB (AWS IoT Core) $10.35/month
Excursion detection latency Cellular RTT (200ms) + cloud processing (500ms) 700 ms

With Level 3 Edge Processing:

Each truck runs an edge gateway (Raspberry Pi or similar) that performs:

  • Evaluation: Discard readings within 2-8 degrees Celsius (normal range). Only escalate outliers.
  • Formatting: Convert raw ADC values to Celsius, attach truck ID and GPS coordinates.
  • Distillation: Compute 1-minute averages, min/max. Replace 1,200 raw readings with 4 summary values per sensor per minute.
  • Assessment: If any sensor exceeds 8 degrees Celsius for 3 consecutive readings (3 seconds), trigger immediate alert to dispatch.
Metric Calculation Value
Distilled data rate per truck 20 sensors x 4 values/min x 8 bytes / 60 sec 10.7 bytes/sec
Fleet data rate 50 trucks x 10.7 bytes/sec 535 bytes/sec
Daily data volume 535 bytes/sec x 86,400 sec 46.2 MB/day
Monthly cellular data cost 46.2 MB/day x 30 days x $0.10/MB $139/month
Excursion detection latency Local processing on gateway 3 seconds (3 readings)

Savings Summary:

Category Cloud-Only Edge Processing Savings
Cellular data cost $4,140/month $139/month 97% reduction
Data volume 1.38 GB/day 46.2 MB/day 30x reduction
Detection latency 700 ms (but requires constant connectivity) 3 seconds (works offline) Operates during cellular dead zones
Gateway hardware cost $0 50 x $35 = $1,750 (one-time) Pays for itself in 13 days

The edge gateway investment of $1,750 saves $4,001 per month in cellular costs. More critically, the edge architecture detects temperature excursions even when trucks pass through tunnels or rural areas without cellular coverage – a compliance requirement that cloud-only architectures cannot guarantee.

52.7.1 Cold Chain Cost Calculator

Adjust the parameters below to explore how edge processing affects your cold chain monitoring costs.

52.7.2 Choosing the Right Processing Level: A Decision Framework

Not all data needs to travel to the cloud. The following decision table helps determine where to process each data stream:

Decision Factor Process at Level 3 (Edge) Process at Level 5-7 (Cloud)
Latency requirement Sub-second response needed (safety shutdowns, real-time control) Minutes to hours acceptable (trend analysis, reporting)
Data volume High-frequency raw data (>1 reading/sec per sensor) Pre-aggregated summaries (hourly/daily)
Connectivity Intermittent or expensive (cellular, satellite) Reliable broadband available
Privacy Sensitive data that should not leave premises (medical, industrial IP) Non-sensitive operational metrics
Compute complexity Simple rules, thresholds, averaging ML model training, cross-site correlation

Real-world example – vibration monitoring on rail networks: Deutsche Bahn deploys vibration sensors on approximately 5,400 ICE train wheelsets. Each sensor generates about 50 KB/second at 20 kHz sampling. Uploading everything would require approximately 23 TB/day in cellular bandwidth. Instead, edge gateways on each train run FFT (Fast Fourier Transform) locally, extract the dominant frequency peaks (~200 bytes), and upload only the spectral summary every 10 minutes. Cloud analytics then correlates these summaries across the fleet to predict bearing failures weeks before they occur. The edge processing reduces data volume by over 99.99% while preserving the diagnostic information needed for predictive maintenance.

52.8 Level 4: Data Accumulation (Storage)

Levels 1-3 have data in motion and are event-driven. At Level 4, the data in motion is converted to data at rest. Decisions at Level 4 include:

  • Is the data of interest to higher levels?
  • Does the data need to be saved or accumulated in memory for short-term use?
  • Does persistency require a file system, big data system, or relational database?
  • What data transformations are needed for the required storage system?
  • Does the data need to be recombined or recomputed?

Storage Decision Matrix:

Data Characteristic Storage Type Example
Short-term, high-frequency In-memory buffer Last 100 sensor readings
Time-series, queryable Time-series DB (InfluxDB, TimescaleDB) Historical sensor data
Relational, structured SQL database Device configuration, metadata
Unstructured, large Object storage (S3, blob) Images, video clips
Real-time streaming Message queue (Kafka, MQTT) Event streams for processing

52.9 Application Requirements Summary

Understanding the IoT Reference Model helps match application requirements to appropriate processing levels:

Comparison diagram showing Massive IoT applications prioritizing scale and cost with batch processing versus Critical IoT applications requiring ultra-low latency real-time edge processing for safety-critical systems
Figure 52.7: Massive IoT versus Critical IoT Processing Strategies

This view shows how edge processing decisions balance latency and bandwidth requirements:

Matrix diagram showing four quadrants of IoT processing: high-latency low-bandwidth handled by cloud batch, high-latency high-bandwidth requiring edge reduction, low-latency low-bandwidth suited for direct cloud streaming, and low-latency high-bandwidth demanding full edge processing

Latency vs bandwidth trade-off matrix for IoT processing decisions

The optimal processing location depends on both latency sensitivity and data volume. Edge processing is essential when either latency is critical or bandwidth is limited.

Massive IoT vs Critical IoT Requirements: Two distinct IoT application categories – Massive IoT prioritizes scale and cost efficiency with delay tolerance (smart metering, agriculture), while Critical IoT demands ultra-low latency and high reliability for safety-critical applications (autonomous vehicles, industrial control). Edge processing strategies differ accordingly.

Common Pitfalls

Edge patterns like ‘filter-at-source’ and ‘aggregate-at-fog’ must be mapped to specific reference model tiers (device tier vs connectivity tier) before implementation decisions about hardware, protocol, and power can be made.

Optimising the device tier for low power and the cloud tier for analytical throughput without considering the connectivity tier in between often produces an architecture where the network is the bottleneck. Design all tiers together.

The data flow (sensor → cloud) is visible and well-designed in most architectures, but the control flow (cloud → device configuration, firmware updates) is often an afterthought. Both flows must be explicit in the reference model mapping.

The reference model for a smart building differs from one for industrial automation or connected health. Apply the reference model as a starting template and adapt tier responsibilities and protocols to the specific domain requirements.

52.10 Summary

  • The seven-level IoT Reference Model separates operational technology (Levels 1-3, data in motion) from information technology (Levels 5-7, data at rest), with Level 4 as the transition from streaming to stored data
  • Level 1 (Physical Devices) includes all sensors, actuators, and controllers that generate or receive data
  • Level 2 (Connectivity) provides reliable, timely transmission through appropriate protocols and network topologies
  • Level 3 (Edge Computing) transforms raw data through evaluation, formatting, distillation, and assessment before storage
  • Level 4 (Data Accumulation) converts data in motion to data at rest, selecting appropriate storage types based on data characteristics
  • Massive IoT applications prioritize scale and cost at Levels 1-4 with batch processing
  • Critical IoT applications demand real-time processing at Level 3 with cloud for monitoring only
Key Takeaway

The IoT Reference Model separates edge processing (Levels 1-3, data in motion) from cloud analytics (Levels 5-7, data at rest), with Level 4 as the critical transition point. Level 3 is the edge computing layer that filters, formats, and reduces data before storage. Massive IoT applications prioritize scale and cost efficiency with batch processing, while Critical IoT demands real-time edge processing for safety and reliability.

The Sensor Squad builds a seven-story tower!

The Sensor Squad imagined their IoT system as a seven-story building, where each floor does something different:

Floor 1 (The Ground Floor): “This is where I live!” said Sammy the Sensor. “All the physical devices – sensors, cameras, switches – are on the ground floor, collecting information from the real world.”

Floor 2 (The Mail Room): “I handle the mail!” said Lila the LED, who was in charge of connectivity. “I make sure all the messages from Floor 1 get delivered reliably – using Wi-Fi, Bluetooth, or even wires!”

Floor 3 (The Smart Office): Max the Microcontroller was here, doing edge computing. “I am the smartest middle floor! I look at all the data coming in and decide what is important. If the temperature is normal, I just write down a summary. But if something is WRONG – like a fire alarm – I take action RIGHT AWAY without waiting for the top floors!”

Floor 4 (The Filing Cabinet): “I save everything important,” said a big hard drive. “Data stops moving here and gets stored safely.”

Floors 5-7 (The Penthouse): “We are the cloud!” called voices from the top. “We do the really big thinking – predicting the weather next week, training smart computer models, and sharing reports with everyone around the world!”

Bella the Battery smiled: “See? Each floor has its own job. The bottom floors are fast but simple. The top floors are powerful but slow. That is why we need ALL of them working together!”

52.11 Concept Check

Quick Knowledge Check

Q: What is the key difference between data in motion (Levels 1-3) and data at rest (Level 4+)?

Data in motion is event-driven, streaming data that flows from sensors through edge processing. Data at rest is stored in databases for batch analytics and historical queries. Level 4 is the critical transition point where real-time streams become persistent storage.

Q: Why is Level 3 edge computing called the “transformation layer”?

Level 3 performs five critical functions: evaluation (check data quality), formatting (standardize schemas), expanding (decode proprietary protocols), distillation (reduce data volume through aggregation), and assessment (trigger local responses). It transforms raw device data into cloud-ready information.

52.12 Concept Relationships

Builds on:

Enables:

Related Concepts:

  • Massive IoT vs Critical IoT - Different processing requirements at each level
  • Gateway Architecture - Level 3 gateways handle protocol translation for non-IP devices
  • Tiered Storage - Level 4 retention policies (hot/warm/cold tiers)

52.13 See Also

Core Edge Computing:

Architecture Context:

Real-World Applications:

52.14 Try It Yourself

Scenario: A pharmaceutical cold chain monitoring system tracks 50 refrigerated trucks, each with 20 temperature sensors sampling at 1 Hz.

Your Task: Design the architecture for Levels 1-4:

  1. Level 1 (Devices): What sensors are needed? What’s the data format?
  2. Level 2 (Connectivity): Which protocol (Bluetooth, LoRaWAN, cellular)? Why?
  3. Level 3 (Edge Gateway): Apply the five functions:
    • Evaluation: What threshold values trigger alerts?
    • Formatting: Design the standardized data schema
    • Distillation: Calculate data reduction ratio (1 Hz raw to what summary?)
    • Assessment: What local actions (alarms, door locks)?
  4. Level 4 (Storage): What retention policy (hot/warm/cold tiers)?

What to Observe:

  • Compare bandwidth costs: raw 1 Hz data vs edge-processed summaries
  • Calculate alert latency: edge detection vs cloud detection
  • Consider offline operation: what happens during cellular dead zones?

Starter Code (Python simulation):

import time
import statistics

class ColdChainEdgeGateway:
    def __init__(self, truck_id, num_sensors=20):
        self.truck_id = truck_id
        self.buffer = []
        self.alert_threshold_max = 8.0  # degrees C

    def evaluate(self, reading):
        """Level 3: Evaluation - check data quality"""
        return 2.0 <= reading <= 10.0  # Valid range

    def format(self, sensor_id, temp_c):
        """Level 3: Formatting - standardize schema"""
        return {
            "truck_id": self.truck_id,
            "sensor_id": sensor_id,
            "temp_celsius": round(temp_c, 1),
            "timestamp_utc": time.time()
        }

    def distill(self, readings_1min):
        """Level 3: Distillation - 60 readings to 4 summary values"""
        return {
            "min": min(readings_1min),
            "max": max(readings_1min),
            "avg": statistics.mean(readings_1min),
            "stddev": statistics.stdev(readings_1min)
        }

    def assess(self, temp_c):
        """Level 3: Assessment - trigger local alarm"""
        if temp_c > self.alert_threshold_max:
            print(f"ALERT: Truck {self.truck_id} temp {temp_c} C exceeds 8 C")
            return True
        return False

# Test the gateway
gateway = ColdChainEdgeGateway("TRUCK-042")
readings = [5.2, 5.3, 5.1, 8.5, 8.9, 9.2]  # Temperature excursion!

for i, temp in enumerate(readings):
    if gateway.evaluate(temp):
        formatted = gateway.format(sensor_id=1, temp_c=temp)
        gateway.assess(temp)
        gateway.buffer.append(temp)

summary = gateway.distill(gateway.buffer)
print(f"1-minute summary: {summary}")
print(f"Data reduction: {len(gateway.buffer)} readings to 4 values")

Extension Challenge: Add Level 4 storage with tiered retention (last hour = raw data, last week = hourly summaries, beyond = daily aggregates).

52.15 Knowledge Check

52.16 What’s Next

Next Topic Description
Edge Processing Patterns Four primary patterns: Filter, Aggregate, Infer, Store-Forward
Cyber-Foraging and Caching Opportunistic compute offloading and caching strategies
Edge Patterns Practical Guide Interactive tools and worked examples for architecture decisions