The Sensor Squad has been hired to design an IoT system for an office building. Let us see how they approach it!
Sammy the Sensor starts: “First, let me count all the devices: 500 occupancy sensors, 200 HVAC units, and 50 energy meters. That is 750 things on Floor 1!”
Max the Microcontroller does the math: “At peak, that is about 750 readings per second. If I process locally on each floor, I can reduce that to 75 summaries per second before sending to the cloud. That saves 90% of bandwidth!”
Lila the LED plans the dashboard: “The building manager wants to see real-time occupancy maps and energy charts. But I do not need to know whether a sensor is Zigbee or Modbus – the API (Layer 5) translates everything into the same format for me.”
Bella the Battery has a crucial question: “When someone walks into a room, how fast does the HVAC need to respond?” The answer is under 2 seconds. “Then that logic MUST run locally at the edge, not in the cloud. Cloud round-trips take too long!”
This is exactly how real architects design IoT systems: layer by layer, starting with devices and ending with people.
By the end of this chapter, you will be able to:
This worked example walks through the complete process of mapping a commercial building IoT system to the Cisco 7-layer reference model. Follow along step-by-step to understand how architectural decisions are made at each layer.
The scenario represents a common enterprise IoT deployment with multiple sensor types, real-time control requirements, and long-term data retention needs.
A worked example shows the complete solution process, not just the final answer. Like watching a chef prepare a dish step-by-step, you’ll see:
This is how real architects approach IoT system design.
Scenario: You are architecting an IoT system for a commercial office building with 500 occupancy sensors, 200 HVAC control units, and 50 energy meters. The building manager wants a dashboard showing real-time occupancy, automated climate control, and monthly energy reports. Map this system to the Cisco 7-layer reference model.
Given Requirements:
The first step is to inventory all physical devices and understand their data characteristics.
Device Inventory:
| Device Type | Count | Data Rate | Protocol | Output |
|---|---|---|---|---|
| Occupancy (PIR) | 500 | 1 Hz (motion events) | Zigbee | Boolean + timestamp |
| HVAC controllers | 200 | 0.1 Hz (setpoint changes) | BACnet | Temperature, fan speed |
| Energy meters | 50 | 1 Hz (power readings) | Modbus | kW, kWh, power factor |
Data Volume Calculation:
Peak readings = 500 + (200 x 0.1) + 50 = 570 readings/second average
Peak with simultaneous events = 751 readings/secondLayer 1 Result: The perception layer generates approximately 570-751 readings/second at peak.
Adjust the device counts below to see how data volume and storage requirements scale.
Why different protocols for different devices?
Layer 2 handles protocol translation and network topology.
Network Architecture:
Protocol Stack:
Key Design Decision: Protocol translation happens at the Layer 2/3 boundary via floor-level gateways. Each floor has its own MQTT broker, reducing inter-floor traffic and providing local redundancy.
Layer 3 determines what processing happens locally versus in the cloud.
Processing Location Analysis:
| Processing Task | Location | Latency Requirement | Rationale |
|---|---|---|---|
| Occupancy to HVAC trigger | Floor gateway | <2 sec | Real-time control loop |
| Energy spike detection | Floor gateway | <5 sec | Immediate alerts |
| Data aggregation (5-min rollups) | Floor gateway | N/A | Reduce cloud bandwidth |
| ML occupancy prediction | Cloud | Minutes | Requires historical data |
Edge Hardware Selection:
Each floor has a Raspberry Pi 4 gateway running:
Critical Insight: The <2 second HVAC response requirement forces occupancy-to-HVAC logic into Layer 3. If this went through the cloud, network latency alone (200-500ms round-trip) plus processing time would risk exceeding the 2-second SLA.
A naive design might route all data through the cloud for simplicity. This would:
Edge processing at Layer 3 solves all three issues.
Layer 4 selects storage systems for different data types.
Storage Architecture:
| Data Type | Storage System | Retention | Access Pattern |
|---|---|---|---|
| Sensor readings | InfluxDB (time-series) | 30 days raw, 2 years aggregated | Time-range queries |
| Device metadata | PostgreSQL (relational) | Permanent | Key-value lookups |
| Configuration | PostgreSQL | Permanent | Infrequent reads |
| Compliance archive | S3/Glacier | 2+ years | Rare access, regulatory |
Capacity Planning:
Daily data volume:
= 751 readings/sec x 86,400 sec x 100 bytes/reading
= 6.5 GB/day raw
Storage requirements:
- 30-day raw: 195 GB
- 2-year aggregated (1-min resolution): ~700 GB
- Total with overhead: ~1 TB active + 4.7 TB archiveData Lifecycle:
Let’s calculate the 3-year total storage cost with vs. without tiered data lifecycle management.
Without tiering (all raw data on SSD InfluxDB):
\[V_{\text{3-year}} = 6.5\text{ GB/day} \times 1,095\text{ days} = 7,118\text{ GB} \approx 7.1\text{ TB}\]
Cloud-managed InfluxDB (SSD storage): $0.25/GB/month
\[C_{\text{no-tiering}} = 7,118\text{ GB} \times \$0.25 \times 36\text{ months} = \$64,062\]
With 4-tier lifecycle:
\[C_{\text{monthly}} = \$11 + \$15 + \$22 + \$9.50 = \$57.50/\text{month}\]
\[C_{\text{3-year}} = \$57.50 \times 36 = \$2,070\]
Savings: $64,062 - $2,070 = $61,992 (97% cost reduction!)
Break-even for lifecycle automation: Building the data lifecycle pipeline costs ~$8,000 (2 weeks engineering). Pays for itself in 4.6 months. Without tiering, this smart building’s data storage alone would cost $1,780/month — more than most SMB IT budgets!
Layer 5 creates unified APIs that hide storage complexity from applications.
API Design:
# Current occupancy - queries InfluxDB
GET /api/v1/floors/{id}/occupancy/current
Response: { "floor": 5, "occupied_zones": 12, "total_zones": 20, "percentage": 60 }
# Historical energy - queries S3 archive
GET /api/v1/energy/report?start=2024-01&end=2024-12
Response: { "monthly_kwh": [...], "cost_breakdown": {...} }
# Device metadata - queries PostgreSQL
GET /api/v1/devices/{device_id}
Response: { "type": "occupancy", "floor": 5, "zone": "A", "last_seen": "..." }Key Abstraction Benefit: The API consumer doesn’t know that:
Adding a new storage backend (e.g., moving to TimescaleDB) requires zero application changes.
Layer 6 builds user-facing applications.
Application Portfolio:
| Application | Users | Key Features |
|---|---|---|
| Operations Dashboard | Building manager | Real-time floor maps, HVAC override controls |
| Mobile Alerts App | Maintenance team | Push notifications for equipment faults |
| Energy Portal | External consultants | Monthly reports, trend analysis, compliance docs |
Technology Stack:
Layer 7 defines business processes triggered by IoT data.
Automated Workflows:
Architecture Summary Table:
| Layer | Components | Key Technology |
|---|---|---|
| 7 - Collaboration | Workflows, escalations, reviews | Slack, ServiceNow, Email |
| 6 - Application | Dashboard, mobile app, portal | React, React Native, Grafana |
| 5 - Abstraction | REST APIs, data federation | Node.js API, GraphQL |
| 4 - Accumulation | Time-series, relational, archive | InfluxDB, PostgreSQL, S3 |
| 3 - Edge | Local rules, aggregation | Raspberry Pi, Node-RED |
| 2 - Connectivity | Protocol translation, routing | MQTT, Zigbee, BACnet gateway |
| 1 - Physical | Sensors, actuators | PIR, thermostats, meters |
The 7-layer analysis revealed that the <2 second HVAC response requirement forces occupancy-to-HVAC logic into Layer 3 (edge), not Layer 6 (cloud application).
Without this layered analysis, a naive design might route all data through the cloud, adding 200-500ms latency and failing the requirement.
Other Insights:
Apply the same 7-layer mapping process to this scenario:
Requirements:
Questions to Answer:
When designing Layer 4 (Data Accumulation) for large-scale IoT deployments, choose storage tiers based on access patterns and retention requirements:
Hot Tier (0-7 days, SSD-backed time-series DB like InfluxDB):
Warm Tier (7-30 days, HDD-backed or hybrid storage):
Cold Tier (30 days - 2 years, object storage like S3 with aggregation):
Archive Tier (2+ years, Glacier-class storage):
Real-world numbers (from smart building case study): - 751 readings/sec = 65M readings/day = 6.5 GB/day raw - Hot (7 days): 45 GB at $0.25/GB = $11.25/month - Warm (23 days): 150 GB at $0.08/GB = $12/month - Cold (23 months): 4,500 GB aggregated (90% reduction) at $0.03/GB = $135/month - Archive (5+ years): 9,000 GB at $0.005/GB = $45/month - Total storage cost: $203/month for 750 devices vs $4,875/month if everything in hot tier (96% savings)
Key decision point: Data volume at Layer 1 (751 readings/sec) directly determines Layer 4 architecture. Without tiered storage, cloud costs become prohibitive ($58K/year vs $2.4K/year).
Designing a system that “reads temperature and stores it in the cloud” without specifying latency budget, uptime, device count, and security. Non-functional requirements drive 80% of architectural decisions and cannot be deferred.
Using device-to-cloud direct connection for systems that require mesh networking, or pub/sub for systems needing acknowledged command delivery. Match the communication pattern to the interaction model, not to familiar technology.
Designing an architecture without checking each requirement is satisfied. Create a requirements traceability matrix mapping each requirement to the component satisfying it.
Designing data paths without addressing day-2 operations — firmware updates, certificate rotation, device replacement, log analysis, and capacity planning. Production architectures must include operational tooling.
This worked example demonstrated the systematic process for mapping an IoT system to the 7-layer reference model:
The key takeaway is that reference models are practical tools, not just theoretical frameworks. They reveal requirements (like edge processing needs) that might otherwise be missed.
| If you want to… | Read this |
|---|---|
| Test your architecture knowledge with a quiz | IoT Architecture Quiz |
| Practice with a hands-on lab | IoT Architecture Lab |
| Study common architectural mistakes | Common Pitfalls and Best Practices |
| Learn about production deployment | Production Architecture Management |
| Explore QoS and service management | QoS and Service Management |