Unit 6: IoT Cloud & Edge Integration

I. Orientation

IoT cloud and edge integration is the coordinated use of connected devices, local computing resources, communication networks, and cloud services to collect data, make decisions, and control physical processes. Its governing principle is to place each function where it best satisfies latency, bandwidth, reliability, security, and scalability requirements.

• Things: Sensors measure physical quantities such as temperature in degrees Celsius, while actuators perform actions such as switching a relay.
• Connectivity: Devices exchange data through technologies such as Wi-Fi, Ethernet, Bluetooth Low Energy, Zigbee, LoRaWAN, or cellular networks.
• Messaging: Application protocols including MQTT, HTTP, and CoAP define how telemetry and commands are represented and transferred.
• Edge layer: Gateways and local processors filter data, run rules, translate protocols, and continue critical operations during cloud outages.
• Cloud layer: Remote platforms provide device registries, message ingestion, scalable storage, analytics, dashboards, and application integration.
• Data flow: Telemetry generally travels from device to cloud, while configurations and commands travel from cloud to device.
• Design assumptions:
  • Devices may have limited memory, processing power, energy, and network capacity.
  • Connections may be intermittent, delayed, or insecure unless protection is explicitly configured.
  • Device identity, authorization, encryption, monitoring, and update mechanisms must cover the complete lifecycle.

II. IoT System Design — Layers and Data Flow

A. IoT architecture

IoT architecture organizes devices, communication, processing, and applications into cooperating layers with clearly defined responsibilities.

• Perception layer: Sensors and actuators interact with the physical environment; for example, a DHT22 sensor can produce temperature and relative-humidity readings.
• Network layer: Gateways, routers, and communication links transport messages between devices, edge systems, and cloud endpoints.
• Processing layer: Edge or cloud services validate, filter, aggregate, store, and analyze incoming data.
• Application layer: Dashboards, alerts, mobile applications, and automation services turn processed data into user-facing functions.
• Management layer: Device provisioning, health monitoring, access control, logging, and firmware management support fleet operation.
• Typical telemetry path:
  1. A sensor samples temperature as 28.4 °C.
  2. A microcontroller encodes the value as JSON.
  3. MQTT or HTTP carries it through a gateway.
  4. A cloud rule stores it in a time-series database.
  5. A dashboard updates a chart or triggers an alert.
• Architectural models: A three-layer model uses perception, network, and application layers, while expanded models separate transport, processing, business, and security concerns.
• Design limitation: More layers improve separation and scalability but introduce additional configuration, latency, operational cost, and failure points.

III. Application-Layer Protocols — Device Communication Models

A. MQTT protocol

MQTT is a lightweight publish-subscribe messaging protocol designed for constrained devices and unreliable or low-bandwidth networks.

• Broker model: Publishers send messages to a broker, which forwards them to clients subscribed to matching topics.
• Topic structure: Hierarchical names such as factory/line1/motor3/temperature support organized routing and wildcard subscriptions.
• Quality of Service:
  • QoS 0: Delivers at most once, with no acknowledgment.
  • QoS 1: Delivers at least once, so duplicates are possible.
  • QoS 2: Delivers exactly once through additional handshaking.
• Session features: Retained messages provide the latest topic value to new subscribers, while a Last Will message reports an unexpected disconnection.
• Transport and security: MQTT commonly uses TCP port 1883; MQTT secured with TLS commonly uses port 8883. Authentication may use passwords, certificates, or tokens.
• Concrete message:

Topic: greenhouse/zone2/temperature
Payload: {"value": 31.2, "unit": "C"}
QoS: 1

• Limitation: MQTT depends on broker availability and requires topic permissions to prevent unauthorized publication or subscription.

B. HTTP protocol

HTTP is a request-response protocol widely used to connect IoT devices with web servers, cloud services, and REST APIs.

• Request structure: A client sends a method, URL, headers, and optionally a body; the server returns a status code, headers, and response body.
• Common methods: GET retrieves data, POST creates or submits data, PUT replaces a resource, PATCH modifies it, and DELETE removes it.
• Status codes: 200 means success, 201 means created, 400 indicates an invalid request, and 401 indicates missing or invalid authentication.
• Example request:

POST /api/readings HTTP/1.1
Host: example.net
Content-Type: application/json

{"deviceId":"sensor-7","temperature":26.8}

• Security: HTTPS protects traffic using TLS, normally over TCP port 443; API keys or bearer tokens identify and authorize clients.
• Limitation: Repeated headers and request-response exchanges consume more bandwidth and energy than compact protocols such as MQTT or CoAP.

C. CoAP protocol

CoAP is a compact REST-oriented protocol designed for constrained devices and low-power, lossy networks.

• Communication model: CoAP uses familiar methods such as GET, POST, PUT, and DELETE, but normally operates over UDP rather than TCP.
• Message types: Confirmable messages require acknowledgment, non-confirmable messages do not, and reset messages reject an unrecognized exchange.
• Resource addressing: A device may expose a resource such as coap://sensor.local/temperature.
• Observe extension: A client can observe a resource and receive later state changes without repeatedly polling it.
• Efficiency: A compact binary header reduces communication overhead for battery-powered nodes.
• Security: Deployment can use DTLS or OSCORE, with access restricted according to device identity and resource permissions.
• Limitation: UDP traversal, proxying, and enterprise integration can be harder than HTTP, although CoAP-to-HTTP gateways can bridge the protocols.

IV. IoT Cloud Platforms — Managed Device Services

A. ThingSpeak cloud platform

ThingSpeak is a cloud service for collecting, visualizing, and analyzing channel-based IoT data, with built-in MATLAB analytics support.

• Channels: A channel stores time-stamped data in up to eight fields, such as temperature in field1 and humidity in field2.
• Data upload: Devices can write data using HTTP requests or MQTT messages and a channel Write API key.
• Concrete request:

https://api.thingspeak.com/update?api_key=WRITE_KEY&field1=27.5

• Visualization: Channel views provide line charts, gauges, and status displays derived from stored field values.
• Analytics: MATLAB code can calculate averages, detect thresholds, or transform sensor readings.
• Use and limitation: ThingSpeak suits prototypes, education, and small monitoring systems, but update limits and simpler fleet-management features constrain large deployments.

B. AWS IoT cloud platform

AWS IoT provides managed services for securely connecting device fleets to cloud applications and other AWS resources.

• AWS IoT Core: The service includes an MQTT broker, device gateway, registry, authentication, and rules engine.
• Device identity: X.509 certificates and IoT policies control which MQTT topics a device may publish or subscribe to.
• Rules engine: SQL-like rules route telemetry to services such as Lambda, Amazon S3, DynamoDB, or CloudWatch.
• Device Shadow: A JSON document stores desired and reported device states, allowing applications to request changes while a device is offline.
• Example state:

{"state":{"desired":{"fan":true},"reported":{"fan":false}}}

• Operational concern: Fine-grained policies improve security, but service permissions, message volume, storage, and cross-region design require careful cost and governance controls.

C. Azure IoT Hub cloud platform

Azure IoT Hub is a managed communication service that supports secure, bidirectional messaging between device fleets and cloud applications.

• Device-to-cloud path: Devices send telemetry that can be routed to Azure Functions, Event Hubs, Blob Storage, or Stream Analytics.
• Cloud-to-device path: Applications send commands, properties, or messages to individual registered devices.
• Device twins: JSON documents hold desired properties, reported properties, and metadata for configuration synchronization.
• Direct methods: A cloud application invokes an immediate operation on an online device and receives a result.
• Security: Per-device credentials may use symmetric keys, SAS tokens, or X.509 certificates; the Device Provisioning Service supports enrollment at scale.
• Operational concern: Message quotas, routing endpoints, retry behavior, and service tiers must match the expected fleet size and telemetry rate.

V. Application Integration — APIs and Presentation

A. REST API integration

REST API integration exposes IoT resources through stateless HTTP operations using predictable URLs and representations.

• Resource model: URLs identify nouns such as /devices/42/readings; HTTP methods express operations on those resources.
• Representation: JSON commonly carries values, timestamps, units, and identifiers between services.
• Authentication: API keys are simple but difficult to scope, while OAuth 2.0 bearer tokens can provide limited permissions and expiration.
• Reliability: Clients should use timeouts, exponential backoff, and idempotency where retries could repeat an operation.
• Integration flow: A gateway can POST aggregated readings to a cloud API, receive 201 Created, and retain unsent data locally after failures.
• Limitation: REST polling creates delay and unnecessary requests; MQTT subscriptions or webhooks are preferable for frequent event delivery.

B. Real-time dashboards and visualization

Real-time dashboards convert live and historical IoT data into displays that support monitoring and operational decisions.

• Visual forms: Line charts show change over time, gauges show current values, maps show location, and tables expose device-level details.
• Pipeline: Broker messages pass through stream processing and time-series storage before reaching a dashboard through WebSockets, subscriptions, or periodic queries.
• Context: A value such as 80 is ambiguous unless the dashboard includes the metric, unit, timestamp, and device identity.
• Alerts: Threshold rules can flag temperature above 40 °C, while hysteresis prevents repeated alerts near the boundary.
• Performance: Downsampling one-second readings into one-minute averages reduces rendering and query load without discarding long-term trends.
• Limitation: A visually current dashboard is not necessarily instantaneous; ingestion, processing, network, and refresh delays determine end-to-end latency.

VI. Computing Placement — Distributed Processing Choices

A. Edge computing versus cloud computing

Edge computing processes data near its source, whereas cloud computing uses centralized, elastic infrastructure in remote data centers.

1. Edge computing:
   • Strengths: Millisecond-scale local response, reduced bandwidth use, offline operation, and stronger control over sensitive raw data.
   • Example: A machine gateway stops a motor immediately when vibration exceeds a safety threshold.
   • Constraints: Limited CPU, memory, storage, and physical maintenance complicate advanced analytics and fleet consistency.
2. Cloud computing:
   • Strengths: Elastic storage, large-scale analytics, centralized administration, and access to managed AI and database services.
   • Example: Months of vibration records from 10,000 motors are compared to predict bearing failures.
   • Constraints: Internet dependence, network latency, transfer cost, and data-sovereignty requirements can restrict use.
   • Hybrid model: The edge performs filtering and urgent control, while the cloud handles long-term storage, model training, fleet analysis, and global coordination.

VII. Device Lifecycle Management — Remote Software Maintenance

A. OTA firmware updates

Over-the-air firmware updates remotely deliver new device software without physical access, enabling security patches, defect fixes, and feature deployment.

• Update workflow: A device checks a signed manifest, downloads an image, verifies its hash and signature, installs it, reboots, and reports the result.
• Integrity: A cryptographic hash such as SHA-256 detects corruption, while a digital signature proves that an authorized publisher created the image.
• Resilience: A/B partitions keep the current firmware in one slot and install the candidate version in another, allowing rollback after boot failure.
• Efficiency: Delta updates transmit only changed blocks, reducing bandwidth and energy consumption compared with a complete firmware image.
• Rollout control: Canary deployment updates a small device group first; staged percentages limit the impact of defective releases.
• Security controls: TLS protects transfer, secure boot verifies executable code, version checks prevent downgrade attacks, and update keys require protected storage.
• Operational limitation: Interrupted power, insufficient flash memory, unstable connectivity, and incompatible hardware revisions must be handled before deployment.