IoT Lab (IT-705) - Unit 5 Short Notes

UNIT 5: ADVANCED IOT SYSTEMS, INTEGRATION & DEPLOYMENT

5.1 Review & Synthesis of Core IoT Stack

5.1.1 Perception Layer (Sensors/Actuators)

• Sensors: Convert physical phenomena to electrical signals. Common types: temperature (DHT22), humidity, motion (PIR), gas (MQ-series), proximity, GPS.

• Actuators: Convert electrical signals to physical action. Examples: relays (for high-power switching), servo motors, LEDs, buzzers.

• Interfacing: Microcontrollers (ESP32, Arduino) use GPIO pins. Analog sensors require ADC (Analog-to-Digital Converter). Digital sensors use communication protocols: I2C (multiple devices, moderate speed), SPI (high speed, single master), UART/Serial (simple, point-to-point).

• [!TIP] Exam Focus: Know when to use I2C vs. SPI. I2C uses 2 wires (SDA, SCL) and addressing; SPI uses 4+ wires (MOSI, MISO, SCK, CS) and is faster but more complex.

5.1.2 Network Layer (Communication Technologies)

5.1.3 Processing & Application Layers (Edge vs. Cloud)

• Edge Computing: Process data near the source (on gateway or device). Benefits: Reduced latency, bandwidth savings, offline operation, enhanced privacy.

• Cloud Computing: Centralized, scalable processing and storage. Benefits: Massive compute power, advanced analytics (AI/ML), global accessibility.

• Fog Computing: Intermediate layer between edge and cloud, providing distributed compute/storage closer to edge than core cloud.

5.1.4 Key Lab Integration Point: Stack Selection Trade-offs

Choosing a stack involves balancing:

• Power Consumption: Battery life vs. data rate.

• Range: Required coverage area.

• Bandwidth: Data payload size and frequency.

• Cost: Module cost, subscription fees (cellular), infrastructure.

• Scalability: Number of supported devices in a network.

[!TIP] Common Pitfall: Using high-bandwidth Wi-Fi for a battery-powered, infrequently transmitting sensor leads to rapid battery drain. LPWAN is often better for such cases.

5.2 Advanced Communication Protocols & Messaging

5.2.1 MQTT (Message Queuing Telemetry Transport) - In Depth

• Architecture: Publish/Subscribe model. Central Broker (e.g., Mosquitto, EMQX). Clients (devices/apps) publish to topics (e.g., home/livingroom/temp) and subscribe to topics.

• QoS (Quality of Service) Levels:

  • QoS 0 (At most once): Fire-and-forget. Fastest, no guarantee.

  • QoS 1 (At least once): Acknowledgment required. Guarantees delivery, possible duplicates.

  • QoS 2 (Exactly once): Four-step handshake. Guarantees delivery exactly once. Highest overhead.

  • \boxed{\text{QoS 0 < QoS 1 < QoS 2 in reliability and overhead}}

• Key Features:

  • Last Will & Testament (LWT): Pre-defined message sent by broker if a client disconnects unexpectedly (e.g., home/sensor/status = offline).

  • Retained Messages: Broker stores the last message on a topic for new subscribers to receive immediately.

• Security: Use TLS/SSL for encryption. Authentication via username/password or (preferably) X.509 certificates.

5.2.2 CoAP (Constrained Application Protocol)

• Model: RESTful (like HTTP) but designed for constrained devices. Uses UDP (not TCP) for low overhead.

• Key Features:

  • Observe Mode: Client can "observe" a resource on a server; server sends notifications when resource changes (like a lightweight MQTT).

  • Block-wise Transfer: Breaks large payloads into smaller blocks for transmission over networks with small MTU.

• Comparison:

  • vs. MQTT: MQTT is pub/sub (many-to-many). CoAP is request/response (one-to-one) but with observe for push. MQTT requires a broker; CoAP can be used peer-to-peer.

  • vs. HTTP: CoAP is binary (compact), uses UDP, has lower overhead. HTTP is text-based, uses TCP, heavier.

5.2.3 HTTP/REST APIs for IoT

• Used for device-to-cloud (sensor sending data) and cloud-to-device (commanding actuator) communication.

• Methods: GET (read state), POST/PUT (send data/update), DELETE.

• Payloads: Typically JSON (lightweight, readable) or XML.

• Authentication: API Keys (simple, static), OAuth 2.0 (token-based, more secure, revocable).

5.2.4 Protocol Selection & Interoperability

• Gateway Role: Acts as a protocol translator. Example: A Zigbee sensor network connects to a gateway, which translates Zigbee messages to MQTT for the cloud.

• Challenge: Heterogeneous environments with multiple protocols (BLE, Zigbee, MQTT, HTTP) require robust gateway software (e.g., using Node-RED, EdgeX Foundry) to unify data flow.

5.3 Edge Computing & Fog Architecture

5.3.1 Concepts: Edge vs. Cloud vs. Fog

• Edge: Compute/storage on the device or immediate gateway (e.g., Raspberry Pi processing camera feed).

• Fog: Distributed layer of nodes between edge and cloud (e.g., multiple gateway nodes in a factory building).

• Rationale for Edge: Latency (real-time control), Bandwidth (filter/aggregate before sending), Privacy (process sensitive data locally), Reliability (operate during cloud outage).

5.3.2 Edge Frameworks & Tools

• AWS IoT Greengrass: Deploy and run AWS Lambda functions, containers, and pre-built components on edge devices.

• Microsoft Azure IoT Edge: Run containerized workloads (modules) on edge devices, managed from Azure IoT Hub.

• EdgeX Foundry: Vendor-neutral, hardware-agnostic edge computing platform. Provides microservices for device connectivity, data processing.

• Containerization: Docker containers package edge applications with dependencies, ensuring consistency across devices.

5.3.3 Edge Analytics

• Perform lightweight processing at the edge:

  • Filtering: Remove noise or outlier sensor readings.

  • Aggregation: Compute averages, sums over time windows.

  • Rule-Based Actions: Trigger local actuator if temperature > threshold (using Node-RED or simple scripts). Reduces need for cloud round-trip.

5.3.4 Lab Exercise: Edge Node with Raspberry Pi

• Goal: Deploy a local anomaly detection function.

• Steps:

  1. Set up Raspberry Pi as an edge gateway.

  2. Install Node-RED or a Python script.

  3. Subscribe to MQTT topic from a sensor.

  4. Implement logic: if temperature > 50°C, publish a local MQTT command to a buzzer and forward a summary to cloud.

  5. Demonstrate local action works even if cloud connection is severed.

5.4 Cloud IoT Platforms & Integration

5.4.1 Platform Comparison (Architectural Overview)

5.4.2 Core Platform Services

• Device Registry/Management: Secure database of all connected devices, their credentials, and metadata.

• Ingestion Pipelines: High-throughput endpoints (e.g., AWS IoT Core MQTT broker) to receive device data.

• Rule Engines: (e.g., AWS IoT Rules) Trigger actions based on incoming data. Can route to Lambda, Kinesis, S3, etc.

• Serverless Functions: AWS Lambda, Azure Functions execute code in response to events (e.g., process incoming MQTT message) without managing servers.

5.4.3 Data Storage & Visualization

• Time-Series Databases (TSDB): Optimized for timestamped data.

  • InfluxDB: Open-source, high-performance TSDB.

  • AWS Timestream: Managed TSDB.

  • Azure Time Series Insights: PaaS for IoT analytics.

• Dashboarding Tools:

  • Grafana: Open-source, connects to many data sources (InfluxDB, Prometheus).

  • AWS IoT SiteWise: Managed service for industrial equipment data.

  • Microsoft Power BI: Business analytics, can connect to IoT data.

5.4.4 Lab Exercise: End-to-End Data Flow

1. Sensor (e.g., DHT22 on ESP32) reads data.

2. ESP32 publishes JSON payload to MQTT topic (e.g., sensors/temp) using TLS.

3. Cloud Platform (AWS IoT Core) receives message, authenticates device via certificate.

4. IoT Rule triggers on topic sensors/temp, sends payload to AWS Lambda.

5. Lambda function parses JSON, writes to InfluxDB.

6. Grafana dashboard connected to InfluxDB displays real-time temperature graph.

5.5 IoT Security & Privacy (Critical Focus Area)

5.5.1 Security Challenges

• Physical Access: Devices often in public/unsecured locations.

• Resource Constraints: Limited CPU/memory for strong crypto.

• Large Attack Surface: Millions of devices, diverse software/firmware.

• Heterogeneity: Many vendors, protocols, making uniform security hard.

5.5.2 Device Security

• Secure Boot: Cryptographically verifies firmware signature on startup, prevents unauthorized code.

• Hardware Security: HSM (Hardware Security Module) or TEE (Trusted Execution Environment) for secure key storage and crypto operations.

• Firmware Signing: Updates must be signed by manufacturer; device verifies signature before applying.

• Secure Key Storage: Never hardcode keys in firmware. Use secure elements or TEE.

5.5.3 Communication Security

• TLS/DTLS: Transport Layer Security (for TCP) / Datagram TLS (for UDP). Provides encryption, integrity, authentication.

• Certificate-Based Auth: X.509 certificates are standard for device authentication in MQTT/HTTPS. Each device has a unique cert.

• Pre-Shared Keys (PSK): Symmetric key shared beforehand. Lighter than certificates but less scalable/secure for large fleets.

5.5.4 Cloud/Application Security

• IAM (Identity and Access Management): Principle of Least Privilege. Cloud resources (Lambda, DB) should have minimal permissions.

• Secure APIs: Use API keys, OAuth tokens. Rate limiting to prevent abuse.

• Data Encryption: At Rest (e.g., AES-256 in database), In Transit (TLS).

5.5.5 Privacy by Design

• Data Minimization: Collect only data absolutely necessary for the function.

• Anonymization/Pseudonymization: Remove or hash personally identifiable information (PII) before storage/analysis.

• User Consent: Explicit opt-in for data collection, especially in consumer IoT. Provide clear data usage policies.

5.5.6 Common Attacks & Mitigations

[!TIP] Exam Focus: Be prepared to describe the Mirai botnet attack vector (default telnet passwords) and its mitigation (unique credentials, firmware updates).

5.6 Data Management, Analytics & AI at IoT Scale

5.6.1 IoT Data Characteristics

• Volume: High from millions of devices.

• Velocity: Often real-time or near-real-time streams.

• Variety: Time-series telemetry, events, images, audio.

• Challenges: Storage cost, processing latency, schema evolution.

5.6.2 Stream Processing

• Apache Kafka: Distributed event streaming platform. Acts as a durable commit log for real-time data pipelines.

• AWS Kinesis: Fully managed service for real-time data streaming (Kinesis Data Streams, Firehose).

• Azure Stream Analytics: Serverless, query-based real-time analytics on streams (SQL-like syntax).

5.6.3 Predictive Maintenance & Anomaly Detection

• Basic Methods: Statistical Process Control (SPC), moving averages, threshold-based alerts.

• Machine Learning:

  • Time-Series Forecasting: ARIMA, Prophet for predicting sensor values.

  • Anomaly Detection: Unsupervised learning (Isolation Forest, Autoencoders) to find unusual patterns.

  • Platforms: AWS SageMaker, Azure Machine Learning for building, training, deploying models on IoT data.

5.6.4 Digital Twins

• Concept: Virtual, dynamic replica of a physical asset, system, or process.

• Architecture: Physical asset <-> IoT data (sensors) <-> Digital Twin model (physics-based, ML) <-> Applications (monitoring, simulation, prediction).

• Use Cases: Simulate changes before implementation, predict failures, optimize performance (e.g., digital twin of a wind turbine).

5.7 IoT Application Domains & System Design

5.7.1 Smart Cities

• Applications: Smart traffic (adaptive signals), waste management (fill-level sensors), environmental (air/water quality), smart lighting.

• Key Considerations: Scalability (city-wide deployment), public infrastructure integration, data privacy for citizens, long-term maintenance.

5.7.2 Industrial IoT (IIoT) / Industry 4.0

• Applications: Predictive maintenance (vibration analysis), asset tracking, process automation, safety systems.

• Key Considerations: High reliability & availability (downtime costly), deterministic latency (OPC-UA over TS), stringent security (air-gapped networks, zero trust), safety certifications.

5.7.3 Smart Agriculture & Environment

• Applications: Precision farming (soil moisture, crop health), livestock monitoring, weather stations, water management.

• Key Considerations: LPWAN focus (LoRaWAN) for wide, low-power coverage. Remote locations with poor connectivity. Low-cost sensors.

5.7.4 Smart Homes & Consumer IoT

• Applications: Lighting, HVAC, security cameras, appliances.

• Key Considerations: Interoperability – the Matter protocol (built on IP) aims to unify ecosystems (Apple Home, Google Home, Alexa). Privacy concerns with always-on devices (microphones, cameras). Voice assistant integration.

5.7.5 System Design Methodology

1. Define Requirements: Functional (what system does), non-functional (latency, security, scalability).

2. Select Components: Hardware (sensor, MCU), Network (BLE, LoRaWAN), Cloud Platform.

3. Create Architecture Diagram: Show data flow from device -> gateway -> cloud -> application. Include protocols at each link.

4. Proof-of-Concept (PoC): Build minimal viable prototype to validate core functionality and technology choices.

5.8 Deployment, Management & Lifecycle

5.8.1 Device Provisioning

• Just-in-Time (JIT): Device connects to cloud for first time, cloud dynamically creates identity and attaches policies.

• Just-in-Time Registration (JITR): Similar, but device first registers with a provisioning service (like AWS IoT Core's Fleet Provisioning) to get credentials.

• Fleet Provisioning: Bulk onboarding of devices using templates and unique identifiers.

5.8.2 Device Management Operations

• Monitoring: Collect metrics (battery, signal strength) and logs from devices via cloud platform (e.g., AWS IoT Device Management).

• Configuration Updates (OTA - Over-The-Air): Securely push new firmware or configuration to devices. Must be signed to prevent malicious updates.

• Shadow Devices (Device Shadows): JSON document (in cloud) that stores desired state (what you want the device to do) and reported state (what the device actually is). Syncs between cloud and device. Enables offline command queuing.

5.8.3 Lifecycle Management

• Onboarding: Secure provisioning, initial configuration.

• Operation: Monitoring, maintenance, updates.

• Decommissioning: Secure disposal – wipe all credentials and sensitive data from device. Revoke certificates in cloud registry.

5.8.4 Scalability & Reliability

• Design for Millions: Use cloud-native, serverless, and microservices architectures. Avoid monolithic apps.

• Load Balancing: Distribute incoming device connections across multiple broker/ingestion nodes.

• High Availability (HA): Multi-AZ (Availability Zone) deployments, redundant brokers, failover mechanisms.

5.9 Lab Project Synthesis & Best Practices

5.9.1 Designing a Complete IoT Solution

• Start with a clear problem statement.

• Write a requirements specification (functional, non-functional).

• Create system architecture diagram (device, network, gateway, cloud, application layers).

• Build a Proof-of-Concept focusing on the riskiest/most novel part first.

5.9.2 Testing & Validation

• Unit Testing: Test individual device code functions (e.g., sensor read, MQTT publish).

• Integration Testing: Test end-to-end flow: sensor -> cloud -> dashboard.

• Load Testing: Simulate many devices connecting/publishing to test cloud/backend scalability.

• Security Testing: Penetration testing, firmware analysis, checking for hardcoded secrets.

5.9.3 Documentation

• System Architecture Document: High-level design, component choices, data flow.

• API Documentation: For any cloud APIs or device-to-cloud interfaces (use OpenAPI/Swagger).

• Deployment Guide: Step-by-step for setting up cloud resources, provisioning devices.

• Maintenance Manual: Troubleshooting steps, update procedures, monitoring checklists.

5.9.4 Ethical & Societal Considerations

• Sustainability (E-Waste): Plan for device longevity, repairability, and responsible recycling.

• Digital Divide: Ensure solutions don't exclude populations without internet/tech access.

• Algorithmic Bias: In AI-driven IoT (e.g., smart policing, hiring), audit models for bias that could disadvantage groups.

• Surveillance & Privacy: Be transparent about data collection, especially in public spaces or homes.