IoT Architecture

IoT Reference Architectures

Three-Tier Architecture

┌──────────────────────────────────────────────────────────┐
│  Cloud Tier                                              │
│  - Data storage, analytics, ML/AI                        │
│  - Device management, dashboards                         │
│  - API gateway, business logic                           │
└──────────────────────┬───────────────────────────────────┘
                       │  MQTT / HTTPS / WebSocket
┌──────────────────────┴───────────────────────────────────┐
│  Gateway / Edge Tier                                     │
│  - Protocol translation, data aggregation                │
│  - Local decision-making, buffering                      │
│  - Security boundary                                     │
└──────────────────────┬───────────────────────────────────┘
                       │  BLE / Zigbee / LoRa / Wired
┌──────────────────────┴───────────────────────────────────┐
│  Device Tier                                             │
│  - Sensors, actuators, MCUs                              │
│  - Constrained networks                                  │
│  - Battery-powered, low-cost                             │
└──────────────────────────────────────────────────────────┘

| Layer | Function | Technologies | |---|---|---| | Perception | Sensing, data acquisition | Sensors, RFID, cameras | | Network | Data transmission | BLE, LoRa, Wi-Fi, cellular | | Middleware | Service management, processing | MQTT broker, stream processing | | Application | Business logic, user interface | Dashboards, mobile apps, APIs | | Business | System management, analytics | BI tools, ML pipelines |

Edge Computing

Processing data near the source rather than sending everything to the cloud.

Why Edge Computing?

| Challenge | Cloud-Only | Edge + Cloud | |---|---|---| | Latency | 50-200 ms round trip | <10 ms local | | Bandwidth | All data uploaded | Only insights uploaded | | Reliability | Offline = dead | Functions offline | | Privacy | Raw data leaves premises | Data processed locally | | Cost | High bandwidth costs | Reduced cloud usage |

Edge Processing Patterns

Sensor --> MCU (filter, threshold) --> Gateway (aggregate, ML inference)
                                           |
                                      Cloud (storage, training, dashboards)

On-device edge: simple threshold checks, moving averages, anomaly flags on the MCU itself.

Gateway edge: runs ML inference models (TensorFlow Lite, ONNX), aggregates data from multiple sensors, makes local control decisions.

Fog Computing

An extension of edge computing that distributes processing across multiple layers between devices and cloud. Fog nodes are more capable than edge devices but closer to data sources than cloud.

Cloud        [ Heavy analytics, model training, long-term storage ]
  |
Fog nodes    [ Regional processing, caching, orchestration ]
  |
Edge         [ Local filtering, real-time response ]
  |
Devices      [ Sensing, actuation ]

Fog computing is particularly relevant for smart city, industrial, and transportation applications where hierarchical processing reduces latency and bandwidth.

IoT Platforms

AWS IoT

Device --> MQTT/HTTPS --> AWS IoT Core --> Rules Engine --> Lambda / S3 / DynamoDB
                             |
                        Device Shadow (digital twin)
                             |
                        Device Defender (security monitoring)

Key services:

IoT Core: managed MQTT broker with TLS mutual authentication
Device Shadow: JSON state document synced between device and cloud
IoT Greengrass: edge runtime for local compute, ML, and messaging
IoT SiteWise: industrial data collection and monitoring
FreeRTOS integration: official FreeRTOS support with connectivity libraries

Azure IoT

Device --> MQTT/AMQP/HTTPS --> IoT Hub --> Stream Analytics / Event Hubs
                                  |
                             Device Twins
                                  |
                             IoT Edge (containerized modules on gateways)

Key services:

IoT Hub: device management, message routing, file upload
IoT Central: low-code IoT application platform
IoT Edge: Docker containers on gateway devices
Digital Twins: spatial intelligence and graph-based modeling
Sphere: secure MCU platform (hardware + OS + cloud security)

Platform Comparison

| Feature | AWS IoT | Azure IoT | |---|---|---| | Protocol | MQTT, HTTPS, WebSocket | MQTT, AMQP, HTTPS | | Device twin | Device Shadow (JSON) | Device Twin (JSON) | | Edge runtime | Greengrass | IoT Edge (Docker) | | Max message | 128 KB | 256 KB | | Pricing model | Per million messages | Per edition + messages |

Device Provisioning

Securely onboarding devices at scale requires automated provisioning.

Provisioning Methods

| Method | Scale | Security | Complexity | |---|---|---|---| | Manual (per-device credentials) | Small | High | High labor | | Pre-shared key (fleet-wide) | Medium | Lower | Low | | X.509 certificates (per-device) | Large | Highest | Medium | | Token-based (just-in-time) | Large | High | Medium |

Zero-Touch Provisioning Flow

1. Device manufactured with unique identity (secure element, certificate)
2. Device powers on, connects to provisioning service
3. Service verifies device identity (certificate chain)
4. Service issues device-specific credentials and configuration
5. Device connects to production IoT endpoint
6. No human intervention required

OTA (Over-the-Air) Updates

Firmware updates in the field are critical for security patches and feature additions.

OTA Update Architecture

┌─────────┐     ┌──────────────┐     ┌──────────┐
│ Build    │────>│ Update Server│────>│ Device   │
│ Pipeline │     │ (firmware    │     │ (download,│
│          │     │  repository) │     │  verify,  │
│ CI/CD    │     │              │     │  install) │
└─────────┘     └──────────────┘     └──────────┘

Update Strategies

| Strategy | Downtime | Safety | Flash Required | |---|---|---|---| | A/B partitions | Near zero (reboot) | Rollback possible | 2x firmware size | | In-place update | During update | No rollback | 1x + staging area | | Delta/diff update | During apply | Size efficient | Patch + rollback slot |

A/B Partition Layout

Flash Memory:
┌──────────────┬──────────────┬──────────┐
│ Bootloader   │ Slot A       │ Slot B   │
│ (always runs)│ (active FW)  │ (new FW) │
│              │              │          │
│ Decides which│ Currently    │ Downloaded│
│ slot to boot │ running      │ update   │
└──────────────┴──────────────┴──────────┘

Update flow:
1. Download new firmware to inactive slot (B)
2. Verify signature and integrity
3. Mark slot B as pending
4. Reboot into slot B
5. If boot succeeds, mark B as confirmed
6. If boot fails (watchdog timeout), revert to slot A

Firmware Signing

// Conceptual firmware verification (using ed25519)
PROCEDURE VERIFY_FIRMWARE(firmware, signature, public_key) → boolean
    key ← ED25519_KEY_FROM_BYTES(public_key)
    sig ← SIGNATURE_FROM_BYTES(signature)
    RETURN ED25519_VERIFY(key, firmware, sig) IS success

Digital Twins

A digital twin is a virtual representation of a physical device that stays synchronized with it.

Digital Twin Structure

{
  "deviceId": "pump-station-042",
  "reported": {
    "temperature": 72.5,
    "pressure": 14.7,
    "rpm": 1450,
    "status": "running",
    "firmware": "2.1.3",
    "lastSeen": "2026-03-24T10:30:00Z"
  },
  "desired": {
    "rpm": 1500,
    "firmware": "2.2.0"
  },
  "metadata": {
    "model": "XP-2000",
    "installDate": "2024-06-15",
    "location": { "lat": 37.7749, "lon": -122.4194 }
  }
}

Use cases:

Monitoring: dashboards showing fleet status without polling devices
Control: set desired state, device syncs when online
Simulation: test changes on the twin before deploying to hardware
Predictive maintenance: ML models on twin data predict failures

IoT Security

Threat Model

| Threat | Vector | Mitigation | |---|---|---| | Firmware extraction | Physical access, JTAG | Disable debug ports, encrypt flash | | Man-in-the-middle | Network interception | TLS/DTLS, certificate pinning | | Replay attacks | Captured valid messages | Nonces, timestamps, sequence numbers | | Firmware tampering | Malicious update | Signed firmware, secure boot chain | | Credential theft | Flash dump, side-channel | Secure element (ATECC608, STSAFE) | | Denial of service | Network flooding | Rate limiting, authentication |

Secure Boot Chain

ROM Bootloader (immutable, in silicon)
  |  verifies signature of -->
First-Stage Bootloader (U-Boot SPL)
  |  verifies signature of -->
Second-Stage Bootloader (U-Boot)
  |  verifies signature of -->
Kernel + Device Tree
  |  verifies -->
Root Filesystem (dm-verity)
  |  verifies -->
Application (signed binaries)

Each stage verifies the next before executing it. The root of trust is anchored in immutable ROM code and a hardware-stored public key.

Secure Elements

Hardware cryptographic modules that store keys and perform crypto operations in tamper-resistant silicon:

ATECC608B: ECC-P256 key storage, ECDH, ECDSA, AES-128, SHA-256
STSAFE-A110: certificate storage, TLS pre-master secret generation
TPM 2.0: platform integrity measurement, sealed storage

Keys never leave the secure element -- cryptographic operations happen inside the chip.

Power Management

Power Budget Calculation

Battery capacity: 2400 mAh (AA lithium)
Target lifetime: 5 years = 43,800 hours

Average current budget: 2400 / 43800 = 54.8 uA

Power budget breakdown:
  Sleep mode (99.9% of time):    3 uA
  Wake + sense (0.08%):        500 uA average during wake
  Transmit (0.02%):           20 mA average during TX

  Effective average = 0.999 * 3 + 0.0008 * 500 + 0.0002 * 20000
                    = 2.997 + 0.4 + 4.0
                    = 7.4 uA   (within budget)

Power Optimization Techniques

| Technique | Savings | |---|---| | Deep sleep between measurements | 100-1000x reduction | | Reduce sensor sampling rate | Linear reduction | | Batch transmissions | Amortize radio startup cost | | Lower TX power | Exponential range/power tradeoff | | Clock gating unused peripherals | Eliminate idle current | | Voltage scaling | Quadratic power reduction |

Energy Harvesting

Supplementing or replacing batteries with ambient energy:

| Source | Power Density | Technology | Application | |---|---|---|---| | Solar (indoor) | 10-100 uW/cm^2 | Photovoltaic cells | Sensors, displays | | Solar (outdoor) | 10-100 mW/cm^2 | Photovoltaic cells | Weather stations | | Vibration | 1-100 uW/cm^3 | Piezoelectric, electromagnetic | Industrial monitoring | | Thermal gradient | 20-60 uW/cm^2/K | Thermoelectric (Peltier) | Pipe monitoring, body heat | | RF (ambient) | 0.1-1 uW/cm^2 | Rectenna | RFID, near-field power |

Energy harvesting systems typically use a power management IC (PMIC) with maximum power point tracking (MPPT) to charge a supercapacitor or small LiPo battery.

Key Takeaways

IoT architectures span from simple three-tier (device-gateway-cloud) to complex fog computing hierarchies.
Edge computing reduces latency, bandwidth, and cloud dependency by processing data near the source.
OTA updates with A/B partitions and firmware signing are essential for field-deployed devices.
Security must be designed in from the start: secure boot, signed firmware, secure elements, TLS everywhere.
Power budgets determine battery life; deep sleep, batched transmissions, and energy harvesting extend it.
Digital twins bridge the physical-digital gap, enabling monitoring, control, and simulation at scale.