1581 Edge Computing Platforms

1581.1 Learning Objectives

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

Deploy AWS IoT Greengrass for edge Lambda functions and ML inference
Configure Azure IoT Edge with containerized modules for edge processing
Implement vendor-neutral edge computing using EdgeX Foundry
Design hybrid architectures combining edge processing with cloud analytics
Choose appropriate edge platforms based on latency, connectivity, and processing requirements
Implement offline-capable IoT systems that sync when connectivity returns
Deploy machine learning models at the edge for real-time inference

1581.2 Prerequisites

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

Cloud IoT Platforms: Understanding cloud platform capabilities helps you design hybrid edge-cloud architectures
Edge Fog Computing: Architectural concepts of edge and fog computing tiers
Software Platforms Overview: The parent chapter provides context on the full IoT software stack

For Beginners: What is Edge Computing?

Edge computing moves processing closer to where data is created—like having a mini-computer at each sensor location.

Why not just send everything to the cloud?

Cloud-Only	Edge Computing
50-200ms latency (round trip)	<10ms latency (local)
Requires constant internet	Works offline
High bandwidth costs	Filters data locally
Privacy concerns (data leaves site)	Sensitive data stays local

Real-world example: A factory camera inspects products for defects: - Cloud approach: Send video (10 Mbps) to cloud, wait for response, reject defective product → Too slow, product already packaged - Edge approach: Run ML model on local edge device, detect defect in 5ms, reject immediately → Product rejected in real-time

Three popular edge platforms:

Platform	Best For	Runs On
AWS Greengrass	AWS users, Lambda functions	Industrial PCs, Raspberry Pi
Azure IoT Edge	Azure users, Docker containers	Any Linux device
EdgeX Foundry	Vendor-neutral, industrial	Any hardware

When to use edge computing: - Real-time decisions needed (<100ms) - Unreliable or expensive connectivity - Privacy requirements (data can’t leave premises) - High data volume (video, sensor streams)

1581.3 Introduction

Edge computing platforms extend cloud capabilities to devices at the network edge, enabling local processing, reduced latency, and offline operation. While cloud platforms excel at centralized analytics, storage, and global coordination, edge platforms handle time-sensitive decisions, bandwidth optimization, and privacy-sensitive processing. Modern IoT architectures typically combine both: edge for immediate actions, cloud for long-term analytics and coordination.

1581.4 AWS IoT Greengrass

Description: Edge runtime that extends AWS capabilities to edge devices.

1581.4.1 Key Features

Local Lambda functions
ML inference (SageMaker models)
Local messaging (MQTT)
Automatic sync with AWS IoT Core
Stream manager for data buffering

1581.4.2 Architecture Overview

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

flowchart TB
    subgraph Cloud["AWS Cloud"]
        IoTCore["AWS IoT Core"]
        Lambda["Lambda Functions"]
        S3["S3 Storage"]
        SageMaker["SageMaker Models"]
    end

    subgraph Edge["Edge Device (Greengrass)"]
        GGC["Greengrass Core"]
        LocalLambda["Local Lambda"]
        LocalMQTT["Local MQTT"]
        MLInference["ML Inference"]
        StreamMgr["Stream Manager"]
    end

    subgraph Devices["Local Devices"]
        Sensor1["Sensor 1"]
        Sensor2["Sensor 2"]
        Actuator["Actuator"]
    end

    Sensor1 --> LocalMQTT
    Sensor2 --> LocalMQTT
    LocalMQTT --> LocalLambda
    LocalLambda --> MLInference
    LocalLambda --> Actuator
    LocalLambda --> StreamMgr
    StreamMgr --> IoTCore
    GGC <--> IoTCore
    Lambda -.-> LocalLambda
    SageMaker -.-> MLInference

    style Cloud fill:#E67E22,stroke:#2C3E50
    style Edge fill:#16A085,stroke:#2C3E50
    style Devices fill:#7F8C8D,stroke:#2C3E50

1581.4.3 Example Greengrass Lambda

import greengrasssdk
import json

client = greengrasssdk.client('iot-data')

def lambda_handler(event, context):
    # Process locally on edge
    temperature = event['temperature']

    if temperature > 30:
        # Publish alert locally
        payload = json.dumps({'alert': 'High temperature', 'value': temperature})
        client.publish(topic='alerts/temperature', payload=payload)

    return {'statusCode': 200}

1581.4.4 Greengrass Components

Greengrass Core: - Manages local Lambda deployments - Handles device certificates and authentication - Coordinates cloud synchronization

Local Lambda Functions: - Run Python, Node.js, Java, or C/C++ - Execute on edge triggers (MQTT messages, timers) - Access local resources (GPIO, serial ports)

ML Inference: - Deploy SageMaker trained models - Run TensorFlow, MXNet, or custom models - Optimize for edge hardware (ARM, GPU)

Stream Manager: - Buffer data during connectivity loss - Automatic retry with exponential backoff - Prioritize critical vs. bulk data

1581.4.5 Strengths and Limitations

Strengths: - Seamless AWS integration - Offline operation - ML at edge - Device management

Limitations: - AWS lock-in - Complex deployment - Licensing costs

Typical Use Cases: - Industrial automation - Remote facilities - Predictive maintenance - Local decision-making

1581.5 Azure IoT Edge

Description: Container-based edge computing platform.

1581.5.1 Key Features

Docker containers as modules
Azure Functions at edge
Custom ML models
IoT Hub integration
Offline scenarios

1581.5.2 Architecture Overview

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

flowchart TB
    subgraph Cloud["Azure Cloud"]
        IoTHub["IoT Hub"]
        Functions["Azure Functions"]
        Storage["Blob Storage"]
        ML["Azure ML"]
    end

    subgraph Edge["Edge Device"]
        EdgeAgent["IoT Edge Agent"]
        EdgeHub["IoT Edge Hub"]
        Module1["Custom Module<br/>(Container)"]
        Module2["ML Module<br/>(Container)"]
        Module3["Azure Function<br/>(Container)"]
    end

    subgraph Devices["Downstream Devices"]
        Leaf1["Leaf Device 1"]
        Leaf2["Leaf Device 2"]
    end

    Leaf1 --> EdgeHub
    Leaf2 --> EdgeHub
    EdgeHub <--> Module1
    EdgeHub <--> Module2
    EdgeHub <--> Module3
    EdgeHub <--> IoTHub
    EdgeAgent <--> IoTHub
    ML -.-> Module2

    style Cloud fill:#E67E22,stroke:#2C3E50
    style Edge fill:#16A085,stroke:#2C3E50
    style Devices fill:#7F8C8D,stroke:#2C3E50

1581.5.3 Example Deployment Manifest

{
  "modulesContent": {
    "$edgeAgent": {
      "properties.desired": {
        "modules": {
          "tempSensor": {
            "version": "1.0",
            "type": "docker",
            "status": "running",
            "restartPolicy": "always",
            "settings": {
              "image": "mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0",
              "createOptions": "{}"
            }
          }
        }
      }
    }
  }
}

1581.5.4 Module Types

Custom Modules: - Any Docker container (Python, Node.js, C#, Go) - Full flexibility for custom logic - Access to host resources

Azure Functions: - Serverless functions at edge - Event-driven processing - Easy deployment from Azure portal

Azure Stream Analytics: - Real-time data processing - SQL-like query language - Windowing and aggregation

Machine Learning: - ONNX model deployment - Azure Custom Vision models - Real-time inference

1581.5.5 Strengths and Limitations

Strengths: - Container-based (flexible) - Any language support - Strong offline capabilities - Azure ecosystem

Limitations: - Requires understanding of containers - Azure dependency - Resource requirements

Typical Use Cases: - Retail edge analytics - Manufacturing quality control - Video analytics - Hybrid cloud scenarios

1581.6 EdgeX Foundry

Description: Open-source, vendor-neutral edge framework (Linux Foundation).

1581.6.1 Key Features

Microservices architecture
Protocol abstraction
North/south bound connectors
Rule engine
Container deployment (Docker/Kubernetes)

1581.6.2 Architecture Layers

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

flowchart TB
    subgraph North["Application Services (North)"]
        Export["Export Services"]
        Rules["Rules Engine"]
        Analytics["Analytics"]
    end

    subgraph Core["Core Services"]
        Data["Core Data"]
        Metadata["Core Metadata"]
        Command["Core Command"]
        Registry["Registry"]
    end

    subgraph South["Device Services (South)"]
        Modbus["Modbus DS"]
        MQTT["MQTT DS"]
        BLE["BLE DS"]
        REST["REST DS"]
    end

    subgraph Devices["Physical Devices"]
        PLC["Industrial PLC"]
        Sensor["IoT Sensor"]
        Gateway["BLE Gateway"]
    end

    PLC --> Modbus
    Sensor --> MQTT
    Gateway --> BLE

    Modbus --> Data
    MQTT --> Data
    BLE --> Data
    REST --> Data

    Data --> Core
    Metadata --> Core
    Command --> Core

    Core --> Export
    Core --> Rules
    Core --> Analytics

    style North fill:#E67E22,stroke:#2C3E50
    style Core fill:#16A085,stroke:#2C3E50
    style South fill:#7F8C8D,stroke:#2C3E50

1581.6.3 Service Components

Device Services (South Bound): - Protocol-specific connectors - Modbus, BLE, MQTT, OPC UA, GPIO - Abstract device communication

Core Services: - Core Data: Event/reading storage - Core Metadata: Device registry - Core Command: Device control - Registry: Service discovery

Application Services (North Bound): - Export to cloud platforms - Rules engine processing - Data transformation

1581.6.4 Deployment Example

# Deploy EdgeX with Docker Compose
git clone https://github.com/edgexfoundry/edgex-compose.git
cd edgex-compose

# Start core services
docker-compose -f docker-compose-no-secty.yml up -d

# Add Modbus device service
docker-compose -f docker-compose-no-secty.yml \
  -f docker-compose-device-modbus.yml up -d

1581.6.5 Strengths and Limitations

Strengths: - Vendor-neutral - Extensive protocol support - Microservices flexibility - Commercial support available

Limitations: - Complex architecture - Steep learning curve - Resource intensive

Typical Use Cases: - Industrial edge computing - Building automation - Protocol aggregation - Multi-vendor environments

1581.7 Edge Platform Comparison

Feature	AWS Greengrass	Azure IoT Edge	EdgeX Foundry
Vendor	Amazon	Microsoft	Linux Foundation
Architecture	Lambda functions	Docker containers	Microservices
Cloud Integration	AWS only	Azure only	Any (agnostic)
ML Support	SageMaker models	ONNX, Custom Vision	External
Protocol Support	Limited	Moderate	Extensive
Offline Mode	Yes	Yes	Yes
License	Commercial	Commercial	Apache 2.0
Best For	AWS shops	Azure shops	Multi-vendor

1581.8 Knowledge Check

Quiz: Edge Computing Platform Selection

Question 1: An industrial facility has 200 sensors on a local network without internet connectivity. They need real-time data processing and local dashboards. Which architecture is MOST appropriate?

Edge computing platforms enable local processing, storage, and decision-making without cloud connectivity. AWS Greengrass runs Lambda functions locally, Azure IoT Edge runs containers, EdgeX Foundry provides vendor-neutral edge framework. Benefits: sub-100ms latency (critical for industrial control), operation during internet outages, reduced bandwidth costs, data privacy (sensitive data stays on-premises), real-time analytics. Cloud platforms require internet—introducing latency (50-200ms minimum) and single point of failure. VPN adds complexity and latency. Hybrid approach: edge for real-time control + periodic cloud sync for long-term analytics and remote monitoring. Industrial IoT increasingly adopts edge-first architectures.

Question 2: An agricultural IoT system monitors soil moisture across 500-acre farm with LoRaWAN sensors sending data every 15 minutes. Data must trigger irrigation systems within 30 seconds. Which architecture ensures reliability?

Agricultural IoT requires local autonomy for reliability. Edge computing architecture: LoRaWAN gateway receives sensor data, edge platform (Raspberry Pi running edge software) processes locally, triggers irrigation immediately, syncs data to cloud for analytics/monitoring. Benefits: 30-second response time guaranteed (cloud latency 1-5 seconds plus internet variability), works during internet outages (critical for rural areas), reduced cellular data costs, real-time decision-making. Cloud-only fails if internet drops. Mobile app isn’t automated and requires farmer presence. Peer-to-peer lacks central coordination and logging. Modern IoT systems use hybrid: edge for control + cloud for intelligence. This pattern applies broadly: industrial automation, building management, vehicle fleets.

Question 3: Your IoT fleet management system requires deploying machine learning models to 5,000 vehicles for real-time driver behavior analysis. Which platform feature is MOST important?

Edge ML inference is critical for: Real-time analysis (sub-100ms latency for driver alerts), Privacy (video stays on-device), Bandwidth efficiency (5000 vehicles uploading video = TB/day cellular costs), Offline operation (works without connectivity). AWS Greengrass integrates SageMaker models, Azure IoT Edge runs ONNX models in containers, NVIDIA Jetson provides GPU acceleration. Workflow: train models in cloud, deploy via OTA to edge devices, inference runs locally, aggregate results synced to cloud. Cloud-only inference isn’t viable for real-time vehicle applications (latency + bandwidth). Manual updates don’t scale to 5K vehicles. Edge ML is transforming IoT: real-time video analytics, predictive maintenance, quality inspection, voice processing.

1581.9 Summary

AWS IoT Greengrass extends AWS Lambda to edge devices with local MQTT messaging, ML inference using SageMaker models, and automatic synchronization with AWS IoT Core when connectivity returns
Azure IoT Edge uses Docker containers as modules, enabling any language or framework at the edge with strong integration into Azure Functions, Stream Analytics, and machine learning services
EdgeX Foundry provides vendor-neutral edge computing with extensive protocol support (Modbus, BLE, OPC UA) and microservices architecture under Apache 2.0 license
Edge computing benefits include sub-100ms latency for real-time control, operation during connectivity loss, bandwidth optimization by processing locally, and privacy protection by keeping sensitive data on-premises
Hybrid architectures combine edge platforms for immediate actions with cloud platforms for long-term analytics, coordination, and model training
Platform selection depends on existing cloud investments (AWS vs. Azure), vendor neutrality requirements, protocol needs, and available technical expertise

Related Chapters & Resources

Platform Deep Dives: - Cloud IoT Platforms - AWS, Azure, Google Cloud - Application Frameworks - Node-RED, Home Assistant - Device Management and Selection - Balena, Mender, platform selection

Architecture: - Edge Fog Computing - Architectural concepts - IoT Reference Models - Software layers

Machine Learning: - Edge AI and TinyML - ML inference at edge

1581.10 What’s Next

The next section covers Device Management Platforms and Selection Criteria, which addresses fleet management, OTA updates, open-source alternatives, and how to select the right platform for your specific requirements.