Understanding how to systematically select an IoT architecture prevents costly mistakes. Here’s the step-by-step decision process:
Step 1: Quantify Your Requirements
Start by measuring concrete values, not assumptions: - Device Scale: Count actual sensors/actuators (e.g., “500 temperature sensors, 200 HVAC controllers”) - Latency Requirement: Define max acceptable delay (e.g., “HVAC must respond within 2 seconds of occupancy change”) - Data Volume: Calculate daily data generation (e.g., “500 sensors × 10 bytes × 86,400 samples/day = 432 MB/day”) - Connectivity Pattern: Measure actual uptime (e.g., “99.9% uptime in building, 80% uptime in remote sites”)
Step 2: Map to Decision Matrix
Use the three-factor decision matrix:
IF device_scale < 100 AND latency_acceptable > 1s AND data < 1GB/day:
→ Cloud-Centric Architecture
ELSE IF device_scale < 10,000 AND latency 100ms-1s AND data 1-100GB/day:
→ Fog/Hybrid Architecture (edge + cloud tiers)
ELSE IF device_scale > 10,000 OR latency < 100ms OR data > 100GB/day:
→ Edge-Centric Architecture (distributed processing)
Step 3: Validate Edge Necessity
Edge processing adds deployment complexity - only use when required: - Latency: Can cloud round-trip (200-500ms) meet your SLA? If no → edge mandatory - Bandwidth: Does edge aggregation save >50% of cloud traffic? If yes → edge justified - Offline: Must system work during internet outages? If yes → edge mandatory - Privacy: Must sensitive data stay local? If yes → edge mandatory
Step 4: Select Reference Model
Choose based on domain requirements: - ITU-T Y.2060: Telecom integration (5G, NB-IoT, carrier partnerships) - IoT-A: Multi-stakeholder systems (smart cities, hospitals with multiple departments) - ISA-95/RAMI 4.0: Industrial automation (factories with PLCs, SCADA integration)
Example Walkthrough: Smart Building Selection
Requirements: - Scale: 750 devices (500 occupancy, 200 HVAC, 50 meters) - Latency: <2s for HVAC response to occupancy - Data: 751 readings/sec × 100 bytes × 86,400 = 6.5 GB/day - Connectivity: Reliable building Wi-Fi/Ethernet
Decision Matrix Application: - Device scale: 750 → Medium (100-10K range) - Latency: <2s → Low latency category (requires local processing) - Data: 6.5 GB/day → Medium (1-100 GB/day) - Connectivity: Reliable → BUT latency requirement overrides
Architecture Selected: Fog/Hybrid with floor-level edge gateways
Why: - <2s latency requirement forces HVAC control logic to edge (cloud round-trip would risk exceeding SLA) - Edge aggregation reduces 6.5 GB/day to ~650 MB/day (90% reduction by sending summaries, not raw data) - Cloud handles historical analytics, long-term storage, and user dashboards - Floor-level gateways provide zone isolation (one floor failure doesn’t affect others)
Reference Model: IoT-A (multi-stakeholder: building management, tenants, energy consultants)
The 90% data reduction at the edge isn’t arbitrary – it’s mathematically driven by aggregation ratios. Let’s quantify the bandwidth savings:
Raw data at Layer 1: \[
\text{Daily Volume} = 751 \text{ readings/sec} \times 100 \text{ bytes} \times 86{,}400 \text{ sec/day} = 6.5 \text{ GB/day}
\]
Edge aggregation at Layer 3 (5-minute summaries): \[
\text{Aggregation Factor} = \frac{300 \text{ sec}}{1 \text{ sec}} = 300:1
\]
Reduced cloud traffic: \[
\text{Cloud Volume} = \frac{6.5 \text{ GB}}{10} = 650 \text{ MB/day}
\]
Over cellular at $10/GB, this saves \((6.5 - 0.65) \times 10 = \$58.50\) per day, or $21,352 annually in bandwidth costs alone.
What to Remember: The decision process is systematic - requirements drive architecture, not vice versa. Start with measurements (Step 1), use the matrix (Step 2), validate edge necessity (Step 3), then select reference model (Step 4). Never skip requirements quantification.
