IOT Lab (CE-705) - Unit 4 Short Notes

CE-705: IOT Lab - UNIT 4 SHORT NOTES

Theme: End-to-End IoT System Design, Cloud Integration & Deployment

4.0 Learning Objectives & Unit Overview

• Scope: Moves beyond single-device programming to designing, securing, deploying, and managing a complete, scalable IoT solution.

• Core Pipeline: Device(s) → Gateway (Optional) → Cloud Platform → Application Layer.

• Key Shift: Focus on system integration, cloud services, security at scale, and operational lifecycle management.

4.1 IoT Platform Architectures & Selection

Platform Selection Criteria:

1. Protocol Support: Native MQTT, CoAP, HTTP, LoRaWAN, etc.

2. Scalability & Cost: Pay-per-use model vs. fixed; message volume pricing.

3. Ecosystem & Tools: SDKs, management consoles, integration with other cloud services (DBs, analytics).

4. Vendor Lock-in: Proprietary services vs. open standards (e.g., LwM2M).

5. Security Model: Built-in certificate management, IAM integration.

[!TIP] Exam Focus: Be prepared to contrast AWS IoT Core (rules engine, device shadow), Azure IoT Hub (device twins, endpoints), and ThingsBoard (open-source, built-in dashboards).

4.2 Device Management & Provisioning at Scale

• Device Identity & Registry:

  • Thing/Device Shadow: A JSON document (virtual twin) that stores the desired and reported state of a device. Allows app to interact with device even if offline.

  • Digital Twin: More comprehensive virtual representation, including 3D models, relationships, and historical context.

• Secure Provisioning:

  • Just-in-Time Provisioning (JITP): Device connects with a certificate; IoT platform automatically registers it to a thing, based on certificate attributes. (AWS)

  • Just-in-Time Registration (JITR): Similar concept in Azure IoT Hub.

• Remote Management:

  • OTA Updates: Secure deployment of new firmware. Process: Upload binary → Create job → Target device group → Monitor deployment.

  • Jobs: Execute configuration changes or actions on a fleet (e.g., "set reporting interval to 5 min").

4.3 Data Ingestion, Processing & Storage

Data Pipeline Flow:

Device (MQTT/HTTP) → IoT Hub/Core → Rules Engine → (Stream Processor / Storage)

• Ingestion & Routing:

  • Rules Engine: SQL-like syntax to filter/transform incoming messages and route them to other services (e.g., Lambda, S3, DB).

  • Example Rule (AWS): SELECT * FROM 'sensors/temperature' WHERE temperature > 30

• Stream Processing:

  • Purpose: Real-time analytics on data streams (windowed aggregations, anomaly detection).

  • Services: AWS Kinesis Data Analytics, Azure Stream Analytics.

• Time-Series Storage (TSDB):

  • Why TSDB? Optimized for timestamped data (high write throughput, time-based queries, compression).

  • Examples: InfluxDB, AWS Timestream, Azure Time Series Insights.

  • vs. SQL/NoSQL: Poor performance for time-range queries on large datasets in traditional DBs.

[!TIP] Common Pitfall: Using a general-purpose database (like MySQL) for high-frequency IoT sensor data will lead to performance bottlenecks. Always justify TSDB choice.

4.4 IoT Application Development & Visualization

• Application Layer:

  • Serverless Functions (AWS Lambda/Azure Functions): Ideal for business logic triggered by IoT events (e.g., "if temp > threshold, send SMS").

  • Consuming Data: Use cloud SDKs, REST APIs (from storage), or WebSockets for real-time dashboards.

• Visualization Tools:

  | Tool | Type | Best For | | :--- | :--- | :--- | | Grafana | Third-party, open-source | Highly customizable, multi-source (TSDB, Prometheus) dashboards. | | Node-RED | Flow-based programming | Rapid prototyping of IoT logic & simple UIs. | | AWS IoT SiteWise | Platform-native | Industrial asset modeling & monitoring. | | Azure IoT Central | SaaS | Quick, no-code solution for specific verticals (e.g., fleet management). |

4.5 Security in Integrated IoT Systems

Defense-in-Depth Model:

graph TD

    A[Device Layer] --> B[Communication Layer] --> C[Cloud/App Layer]

    A --> A1[Secure Boot/TPM];

    A --> A2[Unique Device Identity<br/>(X.509 Cert)];

    B --> B1[TLS/DTLS Encryption];

    B --> B2[Certificate Pinning];

    C --> C1[IAM & Least Privilege];

    C --> C2[VPC/Network Segmentation];

    C --> C3[Audit Logging];

• Critical Practices:

  1. Device: Use hardware-based keys (TPM/HSM) for certificate storage. Never hardcode credentials.

  2. Communication: Enforce TLS 1.2+ for all MQTT/HTTP. Rotate certificates regularly.

  3. Cloud: Apply least privilege IAM policies to devices, functions, and users. Use VPC endpoints to keep traffic within cloud network.

[!TIP] Exam Question: "Explain how a compromised device certificate should be handled?" → Revoke it in the platform's certificate registry, and ensure the device cannot re-enroll.

4.6 System Integration & Testing

• Gateway Role: Protocol translation (e.g., Zigbee/Z-Wave → MQTT), local buffering, edge compute.

• Testing Pyramid:

  1. Unit: Test individual device functions (sensor read) and cloud functions (logic).

  2. Integration: Simulate device traffic (using tools like mqtt-benchmark or custom scripts) to validate:

     • Message flow to cloud topic.

     • Rules engine triggering.

     • Data landing correctly in storage.

  3. Load/Stress: Test platform limits (message throughput, concurrent connections).

  4. Monitoring: Use built-in tools (CloudWatch, Azure Monitor) to track $aws/events/presence/connected/disconnected topics and service health.

4.7 Deployment, Monitoring & Maintenance

• Deployment Strategies:

  • Phased Rollout: Deploy firmware to 5% → 25% → 100% of devices, monitoring for errors.

  • Blue-Green: Maintain two device fleets; switch traffic after validation.

• Key Monitoring KPIs:

  • Connectivity: Connected vs. Disconnected devices.

  • Throughput: Messages/sec, bytes/sec.

  • Latency: Time from publish to cloud processing.

  • Error Rates: Auth errors, Throttling errors.

• Lifecycle:

  • Decommissioning: Revoke device certificate/keys, remove from registry, delete data (as per policy).

  • Cost Optimization: Use cloud cost explorer; analyze per-message and storage costs. Set billing alerts.

4.8 Mini-Project / Capstone Lab Synthesis

Standard Implementation Phases:

1. Define Use Case: e.g., "Smart Agriculture: Monitor soil moisture & automate irrigation."

2. Architecture Diagram: Sketch all components (ESP32 sensor node → MQTT → AWS IoT Core → Lambda → DynamoDB → Grafana).

3. Device Sim/Code: Program device to read sensor (simulated or real), connect using X.509 cert, publish JSON to MQTT topic.

4. Cloud Setup:

   • Create IoT Thing, attach certificate.

   • Configure IoT Rule to route data to Lambda/DB.

   • Set up TSDB (e.g., Timestream) or DynamoDB table.

5. Application Layer: Build Lambda function for logic (e.g., "if moisture < 40%, publish 'ON' to irrigation topic"). Deploy Grafana dashboard connected to TSDB.

6. Security Hardening: Apply IAM policies, enable VPC logging, set up certificate rotation.

7. Test & Validate: End-to-end test: sensor change → dashboard update. Simulate device disconnect.

8. Document: System design, deployment steps, troubleshooting log (e.g., "certificate not trusted error → check policy").

[!TIP] Viva Prep: Be ready to explain why you chose your platform (AWS/Azure/Other), your security model, and how you would scale the solution to 10,000 devices.