167  Worked Example: Smart Building Architecture Mapping

167.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Map real-world systems to the 7-layer IoT reference model systematically
  • Calculate data volumes and storage requirements for IoT deployments
  • Design layer-appropriate APIs that abstract underlying complexity
  • Create complete architecture documentation ready for implementation

167.2 Introduction

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:

  1. The problem statement - What we’re trying to build
  2. The analysis process - How we break down requirements
  3. Design decisions - Why we choose specific technologies
  4. The complete solution - All layers documented

This is how real architects approach IoT system design.

167.3 Worked Example: Mapping a Smart Building System

NoteProblem Statement

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:

  • 750 total sensors/actuators across 15 floors
  • Requirement: <2 second response for HVAC adjustments based on occupancy
  • Data retention: 2 years of historical data for energy compliance reporting
  • Users: Building manager, maintenance team, energy consultants (external)

167.3.1 Step 1: Identify Layer 1 (Physical Devices)

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/second

Layer 1 Result: The perception layer generates approximately 570-751 readings/second at peak.

TipDesign Decision: Protocol Selection

Why different protocols for different devices?

  • Zigbee for occupancy: Battery-powered devices need low-power mesh networking
  • BACnet for HVAC: Industry standard, existing building infrastructure uses it
  • Modbus for meters: Simple, reliable, meters are wired anyway

167.3.2 Step 2: Design Layer 2 (Connectivity)

Layer 2 handles protocol translation and network topology.

Network Architecture:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph "Floor Level (x15)"
        ZC["Zigbee Coordinator"]
        BC["BACnet Controller"]
        MG["Modbus Gateway"]
        MQTT["MQTT Broker"]
    end

    subgraph "Building Level"
        CORE["Core Switch"]
        GW["Building Gateway"]
    end

    ZC --> MQTT
    BC --> MQTT
    MG --> MQTT
    MQTT --> CORE
    CORE --> GW

    style MQTT fill:#E67E22,stroke:#2C3E50,color:#fff
    style GW fill:#16A085,stroke:#2C3E50,color:#fff

Protocol Stack:

  • Zigbee mesh for 500 occupancy sensors (low power, self-healing)
  • BACnet/IP for HVAC (industry standard, existing infrastructure)
  • Modbus TCP for energy meters (reliable, simple)
  • MQTT broker at each floor aggregating all protocols

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.

167.3.3 Step 3: Design Layer 3 (Edge Computing)

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:

  • Node-RED: Local rule engine for real-time HVAC control
  • Mosquitto: MQTT broker for floor-level aggregation
  • InfluxDB (edge instance): 24-hour local buffer

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.

WarningCommon Mistake

A naive design might route all data through the cloud for simplicity. This would:

  1. Add 200-500ms latency (cloud round-trip)
  2. Fail the <2 second requirement during network congestion
  3. Stop working entirely during internet outages

Edge processing at Layer 3 solves all three issues.

167.3.4 Step 4: Design Layer 4 (Data Accumulation)

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 archive

Data Lifecycle:

  1. Hot (0-7 days): Full resolution in InfluxDB, SSD storage
  2. Warm (7-30 days): Full resolution, HDD storage
  3. Cold (30 days - 2 years): 5-minute aggregates in S3
  4. Archive (2+ years): Glacier for compliance

167.3.5 Step 5: Design Layer 5 (Data Abstraction)

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:

  • Current occupancy comes from InfluxDB
  • Historical reports come from S3 archives
  • Device metadata comes from PostgreSQL

Adding a new storage backend (e.g., moving to TimescaleDB) requires zero application changes.

167.3.6 Step 6: Design Layer 6 (Application)

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:

  • Dashboard: React + Grafana for real-time visualization
  • Mobile App: React Native for cross-platform
  • Energy Portal: Django with scheduled report generation

167.3.7 Step 7: Design Layer 7 (Collaboration)

Layer 7 defines business processes triggered by IoT data.

Automated Workflows:

  1. Energy Alert Workflow:
    • Trigger: Energy consumption > 120% of baseline
    • Action: Email to facilities manager
    • Escalation: Work order in CMMS if not acknowledged in 4 hours
  2. HVAC Failure Workflow:
    • Trigger: Temperature drift > 5F from setpoint for 30+ minutes
    • Action: Immediate page to on-call technician
    • Escalation: If unresolved in 30 min, escalate to HVAC contractor
  3. Monthly Review Process:
    • Trigger: First business day of month
    • Action: Energy consultant receives automated report
    • Outcome: Schedules optimization review with building manager

167.4 Complete Architecture Summary

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph L7["Layer 7: Collaboration"]
        WF["Workflows & Escalations"]
    end

    subgraph L6["Layer 6: Application"]
        DASH["Dashboard"]
        MOB["Mobile App"]
        PORT["Portal"]
    end

    subgraph L5["Layer 5: Abstraction"]
        API["REST API Gateway"]
    end

    subgraph L4["Layer 4: Accumulation"]
        TS["InfluxDB"]
        SQL["PostgreSQL"]
        S3["S3/Glacier"]
    end

    subgraph L3["Layer 3: Edge"]
        EDGE["Floor Gateways<br/>(Node-RED + MQTT)"]
    end

    subgraph L2["Layer 2: Connectivity"]
        NET["Zigbee + BACnet + Modbus"]
    end

    subgraph L1["Layer 1: Physical"]
        DEV["500 Sensors + 200 HVAC + 50 Meters"]
    end

    DEV --> NET --> EDGE --> TS & SQL
    TS & SQL & S3 --> API --> DASH & MOB & PORT --> WF

    style L1 fill:#16A085,stroke:#2C3E50,color:#fff
    style L3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L5 fill:#2C3E50,stroke:#16A085,color:#fff
    style L7 fill:#2C3E50,stroke:#16A085,color:#fff

Figure 167.1: Complete 7-layer architecture for the smart building system

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

167.5 Key Insights from This Exercise

ImportantCritical Finding

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:

  1. Data volume planning at Layer 1 informs storage decisions at Layer 4
  2. Latency requirements determine the edge/cloud processing split at Layer 3
  3. API abstraction at Layer 5 enables future storage technology changes
  4. Workflow automation at Layer 7 closes the loop from data to action

167.6 Practice Exercise

CautionYour Turn: Hospital Patient Monitoring

Apply the same 7-layer mapping process to this scenario:

Requirements:

  • 200 patient monitors (heart rate, SpO2, blood pressure)
  • 50 medication dispensers (automated dosing)
  • Real-time alerts to nursing stations (<1 second for critical vitals)
  • 7-year data retention (HIPAA compliance)
  • Integration with existing Electronic Health Record (EHR) system

Questions to Answer:

  1. What devices go in Layer 1? What protocols?
  2. Where does the <1 second alert requirement force processing?
  3. What storage strategy supports 7-year retention?
  4. How does Layer 5 integrate with the existing EHR?

167.7 Summary

This worked example demonstrated the systematic process for mapping an IoT system to the 7-layer reference model:

  1. Layer 1: Inventory devices and calculate data volumes
  2. Layer 2: Design protocol translation and network topology
  3. Layer 3: Determine edge vs cloud processing based on latency requirements
  4. Layer 4: Select storage systems matching data characteristics and retention needs
  5. Layer 5: Design abstraction APIs that hide storage complexity
  6. Layer 6: Build user-appropriate applications
  7. Layer 7: Define automated workflows for human collaboration

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.

167.8 What’s Next

Continue with practical application: