13.8.1: Chapter 13

Overview

• Chapter: 13 — Managing Connected Devices and Edge Systems
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Flowchart, Conceptual Illustration, Comparison Table, Network Diagram, Infographic

Figure 13.1.1

Title: Cloud-Based IoT Device Management Lifecycle

Detailed Caption: Six numbered navy tiles orbit a central warm-gold cloud-and-chip emblem labeled "IoT Device Mgmt," connected clockwise by green arrows. The cycle begins at the top with 1. Device Onboarding & Provisioning (factory icon), continues right and down through 2. Authentication & Identity (key icon), 3. Monitoring & Telemetry (chart icon), 4. Remote Config & OTA Updates (gear-target icon), 5. Remote Control & Actuation (signal icon), and 6. Security & Access Control (shield icon), with the final arrow looping back to Onboarding to close the loop. Each tile carries a one-line subtitle clarifying its scope, and the consistent navy fill plus identical sizing visually emphasizes that no stage is privileged over the others. By drawing IoT device management as a closed cycle rather than a linear pipeline, the figure delivers the chapter's core argument that managing connected fleets is an ongoing operational practice — a device that's only onboarded once but never re-secured, monitored, or updated quickly becomes a liability rather than an asset.

Figure 13.2.1

Title: Four-Layer IoT-Cloud Architecture

Detailed Caption: Four wide horizontal bands stack vertically, color-graded from the bottom up: a gray "Device Layer" with Sensor, Thermostat, and Camera icons; a gray "Network Layer" carrying Wi-Fi, Cellular, and Gateway icons; a teal "Processing Layer" depicting an Edge Server tile on the left and a Cloud Data Center icon on the right linked by a dashed line; and a warm-gold "Application Layer" topping the stack with Dashboard, Analytics, and Mobile App icons. Two vertical arrows flank the stack — a teal "Telemetry / Data" arrow pointing up on the left and a gold "Commands / Configs" arrow pointing down on the right — and two right-edge brackets group the lower two bands as "Edge" and the upper two as "Cloud." The figure makes the dual-direction nature of IoT clear: data climbs up to be analyzed and visualized, while configuration and control commands flow back down — and the Edge/Cloud bracket reminds readers that the boundary between local and central processing is an architectural choice that shapes latency, bandwidth, and autonomy.

Figure 13.2.2

Title: MQTT Publish/Subscribe Messaging Model

Detailed Caption: A large navy "MQTT Broker" tile labeled "Message Routing · Topic Management" sits at the center, fed from the left by three publisher devices — a Temp Sensor (sensors/temp), a Smart Meter (sensors/meter), and a Camera (sensors/camera) — each emitting a teal "PUBLISH" arrow into the broker. On the right, two subscribers — Cloud Analytics (sensors/#) and Mobile Dashboard (sensors/temp) — receive gold "SUBSCRIBE" arrows from the broker. A floating dashed-bordered teal pill above reads "Topic: sensors/temp · matched & routed to subscribers," and a bottom-right legend defines the QoS levels (QoS 0 At most once, QoS 1 At least once, QoS 2 Exactly once). By rendering the publisher-broker-subscriber decoupling visually, the figure makes the MQTT architectural lesson concrete: senders and receivers don't know about each other; the broker's topic taxonomy is the contract — and that decoupling is what lets a single sensor stream feed analytics, dashboards, and rules engines simultaneously without rewiring devices.

Figure 13.3.1

Title: Cloud-to-Edge Computing Continuum

Detailed Caption: A horizontal axis runs left to right with four labeled tiles aligned to dot markers — Device Edge (sensor icon, < 1 ms), Near Edge / Gateway (server-rack icon, 1–10 ms), Regional Edge / Cloud Zone (small data-center icon, 10–50 ms), and Central Cloud (large cloud icon, 50–200+ ms). Above the row, a gray "Increasing Latency →" arrow points right; below it, a gray "← Increasing Compute Power & Storage" arrow points left, and the dot color fades from teal on the left to navy on the right to reinforce the gradient. Latency badges in warm gold sit beneath each tile with their numeric ranges. By placing latency and compute as opposing arrows along a single continuum, the figure communicates the chapter's central design pressure: every workload has a sweet spot somewhere along this axis, and choosing where to run it is a trade between responsiveness and computational scale rather than a binary edge-vs-cloud decision.

Figure 13.3.2

Title: Benefits and Challenges of Edge Computing

Detailed Caption: Two side-by-side columns sit beneath color-coded headers — a teal "Benefits" header with a checkmark icon on the left and a navy "Challenges" header with a caution-triangle icon on the right. Each column lists five rows in matching format with a bolded headline phrase and a one-line gloss: Benefits — Reduced Latency (real-time local processing), Bandwidth Optimization (filter data at source), Offline Autonomy (operate without cloud connectivity), Data Privacy (sensitive data stays local), and Real-Time Control (immediate actuation loops); Challenges — Management Complexity (many distributed nodes to maintain), Heterogeneity (diverse hardware/software), Data Consistency (synchronization across edge and cloud), Security Surface (more attack vectors at edge locations), and Resource Constraints (limited compute, memory, and storage). A thin warm-gold divider runs vertically between the two columns. By placing the wins and the costs at equal visual weight, the figure resists the marketing gloss that often surrounds edge computing — students see the trade-offs in a balanced ledger and can reason about whether a workload's requirements actually justify the operational burden.

Figure 13.4.1

Title: Workload Distribution Decision Framework — Edge vs. Cloud

Detailed Caption: A navy "Workload to Place" tile at the top opens into a chain of light-gray decision diamonds. The first diamond, "Latency requirement < 50 ms?", branches Yes (left) and No (right). The Yes path drops into "Requires offline operation?" — Yes routes left to a teal "EDGE" terminal, No falls into "High data volume needing local filtering?" with Yes also routing to EDGE and No connecting to a warm-gold "HYBRID (Edge + Cloud)" terminal in the bottom center. The No path on the right enters "Needs large-scale analytics or ML training?" — Yes routes to a navy "CLOUD" terminal, No falls into "Data privacy requires local processing?" with Yes routing to EDGE and No to CLOUD. Color-coded outcomes (teal Edge, gold Hybrid, navy Cloud) sit at the bottom as the flow's three terminals. The figure converts the chapter's prose decision criteria into an actionable tree practitioners can apply directly — and the deliberate routing of multiple paths into a single Hybrid terminal makes plain that for many real workloads, neither pure cloud nor pure edge is the right answer.

Figure 13.6.1

Title: IoT Security and Governance Framework

Detailed Caption: Five horizontal bands stack vertically, color-graded from gray-blue at the bottom to warm gold at the top. The base, "Device Identity & Authentication" (X.509 Certificates, PKI, Secure Elements), and the next band, "Access Control & Policy Enforcement" (Least Privilege, MQTT Topic Policies, IAM), are bracketed on the left as "Device Side." Above them, a teal "Secure Communications & OTA Updates" band (TLS/DTLS Encryption, Signed Firmware, Audit Trails), a lighter teal "Data Privacy & Compliance" band (GDPR, HIPAA, Data Minimization, Anonymization), and a warm-gold "Governance Monitoring & Auditing" band (Continuous Audit, Anomaly Detection, Incident Response) sit at the top, bracketed on the right as "Cloud Side." Small icons (key, shield, lock, document, magnifier) anchor each band, and downward arrows between bands signal that each layer depends on the integrity of the layers below. The figure makes the chapter's central argument visible: IoT security isn't a single control but a five-layer stack that bridges device and cloud — break any layer and the layers above it provide false confidence rather than real protection.

Figure 13.7.1

Title: Cloud Provider IoT Service Comparison — AWS, Azure, and Google Cloud

Detailed Caption: A four-column table sits beneath teal provider headers — AWS, Azure, Google Cloud — with each header decorated by its brand-color underline (orange, blue, multi-color), and a navy "Category" column running down the left margin. Four rows trace IoT capabilities: Device Connectivity pairs IoT Core (MQTT, HTTPS, WebSockets) on AWS with IoT Hub (MQTT, AMQP, HTTPS) on Azure and Pub/Sub + Partners (post-IoT Core deprecation) on Google; Device Management contrasts IoT Device Management / Device Shadow / Fleet Indexing on AWS with Device Twins / DPS / Automatic Provisioning / Module Twins on Azure and Firebase / Cloud Functions / Custom Device Mgmt / Partner Integrations on Google; Edge Computing maps IoT Greengrass (Local Lambda, ML Inference) to IoT Edge (Edge Modules, Container-based Runtime) to Anthos / Distributed Cloud (Kubernetes at Edge, GKE Enterprise); and Analytics & ML lists IoT Analytics + SageMaker against Stream Analytics + Power BI against Dataflow + BigQuery + Vertex AI. A horizontal warm-gold accent line at the bottom unifies the table. By aligning the same four capabilities across providers, the figure replaces vendor marketing with a flat comparison: AWS, Azure, and Google have substantially equivalent IoT stacks but pivot on different specialties, so the choice is rarely about features and usually about ecosystem fit.