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                             │
└──────────────────────────────────────────────────────────┘

Five-Layer IoT Model

Edge Computing

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

Why Edge Computing?

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

Device Provisioning

Securely onboarding devices at scale requires automated provisioning.

Provisioning Methods

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

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

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

Energy Harvesting

Supplementing or replacing batteries with ambient energy:

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.