15 Edge, Fog, and Cloud: Architecture
15.1 Learning Objectives
By the end of this chapter, you will be able to:
- Distinguish Alternative Terminologies: Compare MGC (eMbedded-Gateway-Cloud) and Edge-Fog-Cloud architecture naming conventions
- Explain the Three-Layer Architecture: Describe Edge, Fog, and Cloud nodes in detail
- Compare Device Types: Differentiate between edge nodes, fog nodes, and cloud nodes based on latency, compute, and power constraints
- Design Protocol Translation: Plan data conversion across architecture layers
- Three-tier separation is driven by latency requirements: Edge nodes process safety-critical decisions in under 10ms (e.g., autonomous vehicle braking), fog nodes handle local optimization in seconds (e.g., factory floor anomaly detection), and cloud nodes perform global analytics over minutes to hours (e.g., fleet-wide predictive maintenance models). An autonomous vehicle cannot wait 200ms for a cloud round-trip to decide whether to brake.
- Fog nodes exist primarily to reduce bandwidth and add local intelligence: A factory generating 1 GB/second of vibration sensor data uses fog filtering to reduce that to 10 MB/second of meaningful events – a 99% reduction – before any data reaches the cloud. Without fog, cloud bandwidth costs alone would make most industrial IoT deployments economically unviable.
- Protocol translation at each tier boundary is non-optional: Edge devices speak constrained protocols (Zigbee, BLE, LoRa), fog gateways translate these to IP-based protocols (MQTT, HTTP), and cloud platforms consume standardized APIs. Designing without explicit protocol translation points leads to brittle, non-interoperable systems.
- Previous: Edge-Fog-Cloud Introduction - Prerequisites and overview
- Next: Edge-Fog-Cloud Devices and Integration - Device selection patterns
- Reference Models: IoT Reference Models - Foundational frameworks
15.2 Prerequisites
Before diving into this chapter, you should have completed:
- Edge-Fog-Cloud Introduction: Understanding of the three-tier concept
Hey there, future IoT architect! Let’s learn about the three-tier architecture with the Sensor Squad!
Sammy the Sensor has a question: “Where should we do our thinking - right here, at the clubhouse, or at headquarters?”
Think of it like a treehouse adventure:
Level 1 - The Treehouse (Edge)
- Sammy lives here with simple rules: “If I see danger, YELL immediately!”
- No time to ask anyone - just react!
- Like when you touch something hot - you pull your hand back INSTANTLY, no thinking needed!
Level 2 - The Clubhouse (Fog)
- Bella the Gateway collects reports from all the treehouse lookouts
- She’s smart enough to notice patterns: “Hmm, three sensors all reporting smoke… that’s a real fire, not just someone burning toast!”
- She can make decisions without calling headquarters
Level 3 - Headquarters (Cloud)
- The big computer brain that remembers EVERYTHING
- Plans for the future: “Based on 10 years of data, we should move sensors to better spots”
- Takes longer to respond, but makes the smartest long-term decisions
Real Example:
- Treehouse (Edge): Your smartwatch detects your heart beating too fast during exercise - it buzzes your wrist immediately
- Clubhouse (Fog): Your home hub notices multiple rooms are warm - it turns on the AC before you even feel hot
- Headquarters (Cloud): Google analyzes millions of smartwatches to discover a new health pattern that helps doctors
Fun Activity: Next time you play a game with friends, notice the three levels: 1. You (Edge) - React instantly to catch a ball 2. Team Captain (Fog) - Decides the next play based on what the whole team sees 3. Coach (Cloud) - Plans the overall strategy using experience from many games
15.3 For Beginners: Why Three Layers?
Analogy: Your Nervous System
Your body already uses a three-tier architecture:
- Reflexes (Edge) - Touch a hot stove, your hand pulls back in 50ms - no brain thinking required
- Spinal Cord (Fog) - Coordinates walking movements locally without conscious thought
- Brain (Cloud) - Plans complex actions like “I should make dinner” - takes longer but handles complexity
Why can’t everything go to the cloud?
| Scenario | Cloud-Only Problem | Three-Tier Solution |
|---|---|---|
| Self-driving car braking | 200ms delay = crash | Edge processes in 10ms |
| Factory sensor monitoring | $25/month bandwidth per machine | Fog filters 99%, costs $0.25/month |
| Security camera analysis | Internet outage = no security | Fog detects locally, syncs later |
Key Terms:
| Term | Simple Definition | Example |
|---|---|---|
| Edge | Devices that sense and act immediately | Temperature sensor, smart lock |
| Fog | Local smart hub that filters and decides | Raspberry Pi gateway, router |
| Cloud | Remote data center with massive power | AWS, Azure, Google Cloud |
| Latency | Time delay for data to travel | Edge: 1ms, Cloud: 200ms |
| Bandwidth | Amount of data that can flow | Edge saves by sending summaries |
15.4 Key Concepts
- Three-Layer Architecture: IoT systems are organized into Edge Nodes (sensors/devices), Fog Nodes (gateways/intermediate processing), and Cloud Nodes (data centers for large-scale analytics and storage)
- Seven-Level IoT Reference Model: Cisco’s structured framework defining layers from physical devices through connectivity, edge computing, storage, abstraction, applications, to collaboration and processes
- Edge Nodes: Physical devices and sensors that collect data from the environment, including microcontrollers, embedded devices, and smart appliances
- Fog Nodes: Intermediate processing layer using single-board computers and gateways to filter data and reduce cloud bandwidth requirements
- Cloud Nodes: Centralized data centers providing extensive computational resources for machine learning, analytics, and device management
- Protocol Translation: Converting data between different communication protocols (Bluetooth, Zigbee, MQTT, HTTP) as it flows through the architecture layers
You may encounter the three-tier architecture described as MGC (eMbedded–Gateway–Cloud). The following diagram from Stanford’s IoT course illustrates this hierarchical architecture:
Three-tier MGC architecture showing the hierarchical organization of IoT systems from embedded devices through gateways to cloud infrastructure, with clear delineation of processing responsibilities at each tier.
The diagram shows how embedded devices (sensors, wearables, appliances) connect to gateways (smartphones, vehicles, hubs) which bridge to cloud services (storage, analytics, ML/AI). Each tier has distinct characteristics:
| This Chapter | MGC Terminology | Description |
|---|---|---|
| Edge | eMbedded | Sensors, wearables, smart appliances with constrained resources |
| Fog | Gateway | Smartphones, vehicles, hubs that bridge protocols and aggregate data |
| Cloud | Cloud | Data centers for storage, analytics, and ML training |
The MGC terminology emphasizes the role of each tier rather than its location, making it useful when discussing protocol translation (embedded devices speak different languages than cloud services) and data aggregation patterns.
15.4.1 MGC Architecture with Protocol Details
The following figure from Stanford’s IoT course provides a detailed view of the MGC architecture showing specific devices and communication protocols at each tier:
MGC architecture with detailed device and protocol mapping across tiers: Embedded layer shows specific sensors (temperature, motion, GPS) and MCUs (Arduino, ESP32), Gateway layer illustrates protocol bridging (Zigbee→MQTT, BLE→HTTP), and Cloud layer displays platform services (AWS IoT Core, Azure IoT Hub, ThingSpeak) for storage and analytics.
This detailed architecture view illustrates how different IoT protocols and devices map to the three-tier MGC model. At the embedded tier, constrained devices use low-power protocols (Zigbee, BLE, LoRa) optimized for battery operation. The gateway tier performs critical protocol translation—converting Zigbee packets to MQTT messages, BLE advertisements to HTTP REST calls, and LoRaWAN frames to JSON payloads. Finally, the cloud tier receives standardized data formats (typically MQTT or HTTP) that platform services can process uniformly regardless of the original embedded protocol.
Key Protocol Translation Examples:
| Embedded Protocol | Gateway Translation | Cloud Protocol | Use Case |
|---|---|---|---|
| Zigbee (802.15.4) | Zigbee2MQTT gateway | MQTT over TCP | Smart home sensors (battery-powered, mesh network) |
| BLE Advertisements | BLE-HTTP bridge | HTTP REST API | Asset tracking beacons (periodic broadcasts) |
| LoRaWAN | Network server | JSON/HTTP webhook | Agricultural sensors (long-range, low data rate) |
| Modbus RTU | Modbus-TCP gateway | MQTT/OPC-UA | Industrial PLCs (wired serial to IP networks) |
This architecture enables heterogeneous device integration—your cloud application receives uniform MQTT messages regardless of whether data originated from Zigbee sensors, BLE beacons, or LoRaWAN nodes.
Fog nodes aggregate data from multiple edge devices to reduce bandwidth. Formula: For \(n\) edge devices generating \(D_i\) bytes/s each, fog input is \(D_{in} = \sum_{i=1}^{n} D_i\). With aggregation producing \(k\) statistics per time window \(T\), fog output is \(D_{out} = n \times k \times b_{stat}/T\). Reduction ratio \(r = 1 - D_{out}/D_{in}\).
Worked example: 50 temperature sensors at 1 reading/min (100 bytes) each. Input: \(D_{in} = 50 \times 100/60 = 83.3\) bytes/s. Fog sends 5-min summaries (4 stats × 8 bytes = 32 bytes per sensor every 300s). Output: \(D_{out} = 50 \times 32/300 = 5.33\) bytes/s. Reduction: \(r = 1 - 5.33/83.3 = 93.6\%\).
15.4.2 Three-Layer Data Flow
The following diagram illustrates how data flows upward through the three tiers while control commands flow downward, with each layer performing distinct processing responsibilities:
- Three-layer Edge-Fog-Cloud architecture showing bidirectional data flow. Raw sensor data flows upward from edge devices through fog gateways to cloud platforms, while control commands and ML model updates flow downward. Each layer reduces data volume and adds intelligence.
15.5 Edge, Fog, and Cloud
The architecture of IoT systems is typically organized into three main layers: Edge Nodes, Fog Nodes, and Cloud Nodes. Each layer plays a crucial role in the overall functionality and efficiency of the IoT system. Below, we discuss these components in detail, supported by visual representations from the slides.
Source: Princeton University, Coursera Fog Networks for IoT (Prof. Mung Chiang)
Core Concept: Device management encompasses the lifecycle operations of IoT devices - provisioning, configuration, monitoring, firmware updates, and decommissioning - across potentially thousands of geographically distributed endpoints.
Why It Matters: A factory with 500 sensors or a retail chain with 10,000 devices cannot manage each unit manually. Without automated device management, organizations face unpatched security vulnerabilities, inconsistent configurations, and operational blind spots. The fog layer typically hosts device management agents that aggregate status from edge devices and relay commands from cloud platforms, enabling centralized control with local execution.
Key Takeaway: Design for zero-touch provisioning from day one - devices should self-register with fog gateways using secure bootstrapping (certificates, TPM), receive their configuration automatically, and report health metrics without manual intervention.
15.5.1 Edge Nodes
Edge Nodes are the physical devices or sensors that collect data from the environment. They are the first point of interaction with the physical world and are responsible for data acquisition.
- Micro-Controller Based Edge Nodes: These include devices such as the Intel Edison, Arduino boards, and other microcontroller units (MCUs) that perform simple processing tasks at the edge.
- Embedded Devices: Common examples include smart appliances like refrigerators, smart locks, and wearable devices like smartwatches. These devices are embedded with sensors and connectivity modules to gather and transmit data.
Examples of Edge Nodes: - Intel Edison: A compact computing platform designed for building IoT projects. - Arduino: A popular open-source electronics platform based on easy-to-use hardware and software. - Smart Appliances: Refrigerators, smart locks, and smart lighting systems that collect and transmit data to other IoT components.
15.5.2 Fog Nodes
Fog Nodes act as intermediaries between edge devices and the cloud. They perform intermediate processing, data filtering, and storage to reduce the data volume sent to the cloud and to improve response times.
- Single Board Computers: These include devices like Raspberry Pi and BeagleBone that can handle more complex processing tasks compared to simple microcontrollers.
- Gateways: Devices that aggregate data from multiple edge nodes and provide a secure pathway to transmit data to the cloud. They often support various communication protocols such as 6LoWPAN, Zigbee, Z-Wave, Bluetooth, Wi-Fi, and WirelessHART.
Examples of Fog Nodes: - Raspberry Pi: A versatile single-board computer that can act as a fog node, performing local data processing and analytics. - BeagleBone: Another single-board computer used for IoT applications requiring more processing power. - Gateways: Devices that bridge communication between edge nodes and the cloud, ensuring efficient data transfer and processing.
15.5.3 Cloud Nodes
Cloud Nodes represent the data centers or cloud platforms that provide extensive computational resources for large-scale data processing, storage, and analytics. They form the backbone of IoT systems, offering services such as machine learning, data visualization, and device management.
- Cloud Data Centers: These include platforms like Amazon Web Services (AWS), Microsoft Azure IoT Suite, IBM Bluemix, and Kaa IoT Platform.
- Services: Cloud platforms offer various services including data analytics, storage, device management, and application hosting.
Examples of Cloud Nodes: - Amazon Web Services (AWS): Provides a comprehensive suite of IoT services for building scalable IoT applications. - Microsoft Azure IoT Suite: Offers tools and services for connecting, monitoring, and controlling IoT assets. - IBM Bluemix: A cloud platform that helps in developing, managing, and running IoT applications.
15.5.4 Integration of Architectural Components
The integration of edge, fog, and cloud nodes creates a seamless and efficient IoT architecture. Data collected from edge devices are pre-processed at fog nodes to reduce latency and bandwidth usage before being transmitted to cloud nodes for further analysis and storage. This layered architecture enhances the performance, scalability, and reliability of IoT systems.
Understanding the architectural components of IoT systems is essential for designing efficient and effective IoT solutions. By leveraging the strengths of edge, fog, and cloud nodes, IoT systems can achieve optimal performance and scalability, catering to a wide range of applications from smart homes to industrial IoT.
This section provides a detailed overview of the architectural components of IoT systems, supported by examples and visual aids from the provided slides, making it suitable for inclusion in a textbook or educational material on IoT.
The following diagram summarizes the key quantitative tradeoffs when deciding where to place processing logic across the three tiers:
- Processing placement decision matrix showing where different IoT workloads should execute based on compute requirements and latency sensitivity. Safety-critical tasks cluster at the edge (top-left), while compute-heavy analytics belong in the cloud (bottom-right).
Pitfall 1 – Treating Fog as Optional: Many first designs skip the fog layer entirely, sending all raw sensor data directly to the cloud. This works in prototypes with 5 devices, but fails at scale. A single industrial machine generating 1 GB/second of vibration data would cost over $2,500/month in cloud ingestion fees alone. Always design a fog filtering strategy, even if it starts as a simple threshold filter on a Raspberry Pi.
Pitfall 2 – Ignoring Offline Operation: Cloud connectivity is not guaranteed. Cellular networks drop, Wi-Fi routers reboot, and ISPs have outages. If your system cannot function at all without cloud connectivity, it is not a three-tier architecture – it is a cloud application with remote sensors. Design fog nodes to cache data and maintain local control loops during connectivity loss. A smart building that cannot control HVAC during an internet outage is a design failure.
Pitfall 3 – Hardcoding Protocol Assumptions: Assuming all edge devices will use the same protocol (e.g., “everything speaks MQTT”) prevents future device integration. A well-designed fog gateway should support pluggable protocol adapters. When a new Zigbee sensor needs to join a system designed only for BLE, a proper protocol translation layer avoids a costly redesign.
Pitfall 4 – Underestimating Edge Resource Constraints: Developers accustomed to cloud environments often write fog/edge software that assumes abundant RAM, storage, or CPU. An ESP32 has 520 KB of SRAM and no operating system process isolation. Running a full MQTT client library, TLS stack, and sensor fusion algorithm simultaneously may exceed available memory. Profile resource usage on target hardware early in development.
15.6 Code Example: Fog Data Filter Pipeline
This Python example demonstrates a fog node filtering pipeline that reduces raw sensor data volume before cloud transmission. It implements three reduction strategies – threshold filtering, temporal aggregation, and change-based deduplication:
class FogFilterPipeline:
"""Three-stage fog filter: threshold, aggregation, change detection."""
def __init__(self, sensor_id, window_sec=60):
self.sensor_id = sensor_id
self.raw_count = self.forwarded_count = 0
self.buffer, self.window_sec = [], window_sec
self.window_start = self.last_forwarded = None
self.thresholds = {}
def set_threshold(self, metric, low, high):
self.thresholds[metric] = (low, high)
def ingest(self, timestamp, metric, value):
self.raw_count += 1
# Stage 1: immediate alert for out-of-range
if metric in self.thresholds:
lo, hi = self.thresholds[metric]
if value < lo or value > hi:
self.forwarded_count += 1
return {"action": "ALERT", "value": value}
# Stage 2: buffer until window closes
if self.window_start is None:
self.window_start = timestamp
self.buffer.append(value)
if timestamp - self.window_start >= self.window_sec:
mean = sum(self.buffer) / len(self.buffer)
summary = {"mean": round(mean, 2), "samples": len(self.buffer)}
self.buffer, self.window_start = [], timestamp
# Stage 3: suppress if unchanged
if self.last_forwarded and abs(mean - self.last_forwarded) < 0.1:
return {"action": "SUPPRESSED"}
self.last_forwarded = mean
self.forwarded_count += 1
return {"action": "FORWARD", **summary}
return {"action": "BUFFERED"}
fog = FogFilterPipeline("vibration-motor-7", window_sec=10)
fog.set_threshold("accel_g", low=-2.0, high=2.0)Output -> Raw: 1000 | Forwarded: 2 | Reduction: 500x
FORWARD: mean=0.01, samples=1000
ALERT: value=3.5 (impact spike at sample 750)The fog node reduces 1,000 raw samples to just 2 cloud messages: one periodic summary and one threshold alert. At 100 Hz, this is 500x reduction – matching the factory scenario from the chapter introduction where fog filtering reduces 1 GB/s to 10 MB/s.
Scenario: A manufacturing plant generates 1 GB/s of vibration sensor data from 500 machines. The cloud ingestion cost is $0.09/GB, and safety shutdowns require <10ms response time.
Analysis:
- Raw data volume: 1 GB/s × 86,400 sec/day = 86.4 TB/day
- Cloud cost without filtering: 86.4 TB × $0.09/GB × 30 days = $233,280/month (economically unviable)
- Edge tier processing: Run FFT and threshold detection on ESP32 edge nodes. Filter 99.9% of data, sending only anomaly events (1,000 events/day × 1 KB = 1 MB/day)
- Fog tier aggregation: Gateway receives anomaly events from 500 machines, correlates across production line, applies local ML model to distinguish false positives (reduces by 50% → 500 events/day = 0.5 MB/day)
- Cloud tier final storage: 0.5 MB/day × $0.09/1024 = $0.000044/day = $1.32/month
- Safety shutdown: Edge ESP32 detects vibration >5g threshold in 3ms, triggers emergency stop via GPIO pin directly to motor controller. No network round-trip needed.
Result: 99.9999% data reduction (1 GB/s → 0.5 MB/day), $233K/month → $1.32/month bandwidth cost, <10ms safety-critical response at edge.
Use this table to determine the optimal processing tier for each workload in your IoT deployment:
| Decision Criteria | Edge (Device) | Fog (Gateway) | Cloud (Data Center) |
|---|---|---|---|
| Latency requirement | <10ms (safety-critical) | 10-100ms (operational) | >100ms (analytics) |
| Bandwidth cost | Raw data >10 Mbps | Aggregated 0.1-10 Mbps | Summary <0.1 Mbps |
| Offline operation | Must work offline | Tolerates WAN outages | Requires connectivity |
| Compute complexity | Simple threshold/filter | Aggregation/correlation | ML training/analytics |
| Data retention | Minutes/hours | Days/weeks | Months/years |
| Example workloads | Vibration threshold, collision avoidance | Multi-sensor fusion, protocol translation | Fleet analytics, model training |
Hybrid example: Autonomous vehicle uses edge (collision detection <5ms), fog at vehicle gateway (sensor fusion 20ms), cloud (fleet-wide route optimization, minutes).
The Mistake: Architects send all raw sensor data to the cloud assuming “storage is cheap” and “we might need it later,” without implementing fog-level filtering.
Real Numbers: A 1,000-sensor deployment generating 100 bytes/sec per sensor produces 8.64 GB/day of raw data. At $0.09/GB cloud ingestion + $0.023/GB storage: - Monthly ingestion: 259 GB × $0.09 = $23.31 - Monthly storage (cumulative): Month 1: $6, Month 12: $71, Year 5: $3,564
Total 5-year cost: $59,000 in cloud costs alone for data that is 99% noise.
Correct Approach: Implement 3-stage filtering: 1. Edge: Drop readings within ±2% of normal range (removes 95% of data) 2. Fog: Aggregate remaining 5% into 1-minute summaries (reduces by 60x) 3. Cloud: Receives 0.01% of original volume (7 MB/day instead of 8.64 GB/day)
5-year cost with filtering: $986 (savings of $58,014 = 98.3% reduction)
Hidden cost: Without filtering, cloud query latency grows as dataset scales. Querying 5 years × 8.64 GB/day = 15.7 TB takes minutes. Querying filtered 25.5 GB takes seconds.
15.7 Summary and Key Takeaways
This chapter established the three-tier Edge-Fog-Cloud architecture as the foundational organizational pattern for distributed IoT systems. The key takeaways are:
Three tiers serve three distinct purposes: Edge nodes provide sub-10ms reactions for safety-critical operations, fog nodes deliver local intelligence with second-range latency for data aggregation and protocol translation, and cloud nodes offer unlimited compute for historical analytics and ML model training. Each tier exists because the others cannot fulfill its role.
The MGC terminology (eMbedded-Gateway-Cloud) is interchangeable: Whether you call it Edge-Fog-Cloud or MGC depends on context. MGC emphasizes device roles (what each tier does), while Edge-Fog-Cloud emphasizes location (where processing happens). Both describe the same architectural pattern.
Protocol translation is an architectural requirement, not an afterthought: Edge devices communicate via constrained protocols (Zigbee, BLE, LoRa, Modbus) that are incompatible with cloud APIs. Fog gateways must explicitly translate between these protocol families. Designing without translation points leads to monolithic, non-extensible systems.
Data reduction at each tier is essential for economic viability: Without fog-layer filtering, cloud bandwidth and storage costs grow linearly with the number of edge devices. A 99% data reduction at the fog layer transforms an economically unviable deployment into a sustainable one.
Offline operation defines architectural robustness: A true three-tier architecture continues operating (with degraded capability) when any single tier loses connectivity. Edge nodes maintain safety reflexes, fog nodes maintain local control loops, and cloud nodes maintain historical records even during network partitions.
15.8 Knowledge Check
15.9 Concept Relationships
| Concept | Relates To | Relationship Type | Why It Matters |
|---|---|---|---|
| MGC Architecture | Edge-Fog-Cloud | Terminology equivalence | eMbedded-Gateway-Cloud emphasizes device roles while Edge-Fog-Cloud emphasizes location - both describe the same three-tier pattern |
| Protocol Translation | Gateway Integration | Required function | Edge devices use constrained protocols (Zigbee, BLE) incompatible with cloud APIs - fog gateways must translate |
| Fog Data Filtering | Bandwidth Economics | Cost driver | 99% data reduction at fog layer transforms $233K/month cloud-only costs into $1.32/month (factory vibration example) |
| Offline Operation | System Resilience | Design requirement | True three-tier architectures continue operating when any single tier loses connectivity - critical for industrial deployments |
| Edge Node Constraints | Resource Planning | Design limitation | ESP32 has 520 KB SRAM - edge software must be profiled on target hardware to avoid exceeding memory |
| Three-Tier Data Flow | Hierarchical Processing | Architectural pattern | Data flows upward with reduction, control flows downward with specificity across all three tiers |
15.10 See Also
Explore related chapters to understand how the three-tier architecture integrates with broader IoT concepts:
- Edge-Fog-Cloud Introduction - Foundational concepts and the 50-500-5000 latency rule
- IoT Reference Models - How three-tier architecture maps to standard IoT reference frameworks
- Gateway Integration Patterns - Protocol translation implementation at the fog layer
- Edge Compute Patterns - Data processing design patterns for edge and fog tiers
- Bandwidth Optimization Techniques - Quantified strategies for data reduction across tiers
15.11 How It Works: Protocol Translation at the Fog Layer
The Challenge: A smart factory has 200 legacy sensors using Modbus RTU (serial RS-485 protocol from 1979) and needs to integrate them with a modern cloud IoT platform expecting MQTT over TCP/IP. Edge devices speak one language, cloud speaks another - the fog gateway must translate.
Step 1: Edge Tier (Modbus RTU Device)
Legacy industrial sensor (temperature controller) speaks Modbus RTU:
# Modbus RTU frame (binary protocol over RS-485)
[Device Address] [Function Code] [Data Address] [Data] [CRC16]
0x01 0x03 0x0064 0x006B 0xE1C8
Translation:
- Device 0x01 (sensor #1)
- Function 0x03 (read holding registers)
- Address 0x0064 (register 100 = temperature)
- Value 0x006B (107 in decimal = 10.7°C when scaled by 0.1)
- CRC: 0xE1C8 (checksum for error detection)What the edge device does: Continuously measures temperature, stores in register 100, waits for Modbus master to poll. No IP stack, no cloud awareness.
Step 2: Fog Tier (Gateway with Dual Protocol Stack)
Gateway runs on Raspberry Pi with both RS-485 interface (for Modbus) and Ethernet (for MQTT/IP):
# Fog gateway: Protocol translation bridge
import minimalmodbus
import paho.mqtt.client as mqtt
# Initialize Modbus connection (RS-485)
modbus_sensor = minimalmodbus.Instrument('/dev/ttyUSB0', 1) # Device address 1
modbus_sensor.serial.baudrate = 9600
# Initialize MQTT connection (TCP/IP)
mqtt_client = mqtt.Client()
mqtt_client.connect("cloud-mqtt-broker.example.com", 1883)
while True:
try:
# Read from Modbus RTU device (edge)
raw_value = modbus_sensor.read_register(100) # Read register 100
temperature = raw_value * 0.1 # Scale to degrees Celsius
# Translate to MQTT message (cloud)
mqtt_payload = {
'device_id': 'factory_temp_001',
'timestamp': int(time.time()),
'temperature_celsius': temperature,
'protocol_source': 'modbus_rtu'
}
# Publish to cloud via MQTT
mqtt_client.publish(
topic='factory/floor2/temperature',
payload=json.dumps(mqtt_payload),
qos=1 # At-least-once delivery
)
print(f"Translated: Modbus 0x{raw_value:04X} → MQTT {temperature}°C")
except Exception as e:
print(f"Translation error: {e}")
time.sleep(10) # Poll Modbus every 10 secondsWhat happens: Fog gateway acts as Modbus master, polls sensor every 10 seconds (Modbus limitation - cannot push), extracts temperature from binary register, converts to human-readable JSON, and publishes via MQTT. The cloud receives standard MQTT messages with zero knowledge of underlying Modbus.
Step 3: Cloud Tier (AWS IoT Core - MQTT Broker)
Cloud platform receives standard MQTT messages:
# Cloud IoT platform receives this JSON over MQTT
{
'device_id': 'factory_temp_001',
'timestamp': 1707321600,
'temperature_celsius': 10.7,
'protocol_source': 'modbus_rtu'
}
# Cloud processing (IoT Core + Lambda)
def process_temperature_reading(mqtt_message):
temp = mqtt_message['temperature_celsius']
# Store in time-series database
write_to_timeseries_db(
device=mqtt_message['device_id'],
metric='temperature',
value=temp,
timestamp=mqtt_message['timestamp']
)
# Alert if out of range
if temp < 5.0 or temp > 40.0:
send_alert_to_operations(f"Temperature {temp}°C out of range!")
# Aggregate for dashboard
update_floor_average_temperature(temp)What happens: Cloud receives clean, standardized MQTT JSON. No Modbus complexity, no RS-485 serial interfaces, no binary parsing. The fog gateway absorbed all the legacy protocol complexity.
The Full Translation Path:
Edge (Modbus RTU): [0x01 0x03 0x0064 0x006B 0xE1C8]
↓
Fog (Translation): Binary → 107 → 10.7°C → JSON
↓
Fog (MQTT Publish): {"device_id":"factory_temp_001","temperature_celsius":10.7}
↓
Cloud (MQTT Receive): Standard JSON over MQTT/TCP/IPKey Benefits:
- Edge devices unchanged: 200 legacy Modbus sensors continue working with zero modifications
- Cloud platform standard: Cloud IoT platform uses standard MQTT - no Modbus driver needed
- Fog adds value: Beyond translation, fog can aggregate 200 sensors to reduce cloud traffic
Real-World Complexity: This example shows one Modbus device. A real fog gateway might handle: - 50 Modbus RTU sensors on one RS-485 bus - 30 Zigbee sensors via Zigbee2MQTT coordinator - 20 BLE beacons via Bluetooth adapter - 10 HTTP REST devices on Ethernet
All translated to unified MQTT stream to cloud.
15.12 What’s Next
Continue to:
| Topic | Chapter | Description |
|---|---|---|
| Device Selection | Edge-Fog-Cloud Devices and Integration | MCU vs SBC selection, integration patterns |
| Advanced Topics | Edge-Fog-Cloud Advanced Topics | Worked examples and misconceptions |