%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'12px'}}}%%
mindmap
root((IoT Sensor<br/>Applications))
Smart Cities
Parking systems
Traffic monitoring
Street lighting
Waste management
Air quality
Healthcare
Patient monitoring
Wearable devices
Medication tracking
Emergency response
Agriculture
Soil moisture
Weather stations
Livestock tracking
Irrigation control
Crop monitoring
Industrial
Asset tracking
Predictive maintenance
Quality control
Energy monitoring
Safety systems
Home Automation
HVAC control
Security systems
Energy management
Lighting control
Appliances
Environmental
Weather monitoring
Pollution tracking
Water quality
Wildlife monitoring
Disaster prediction
521 Sensor Application Architecture
System Design Patterns and Data Flow
521.1 Learning Objectives
By the end of this chapter, you will be able to:
- Visualize System Architecture: Understand sensor network topology and data flow patterns
- Apply Design Patterns: Use proven architectural patterns for different deployment scenarios
- Plan Deployment Lifecycle: Follow systematic processes from requirements to operations
- Analyze Sensor Coverage: Determine optimal sensor placement and network design
- Select Appropriate Connectivity: Match network protocols to application requirements
Core concept: Sensor applications follow a layered architecture pattern: sensors collect data, gateways aggregate and filter, networks transport, clouds store and analyze, applications present insights. Why it matters: Understanding this architecture helps you identify bottlenecks, plan for scale, and make informed decisions about where to process data (edge vs. cloud). Key takeaway: Design your architecture based on latency requirements, data volume, and connectivity constraints - not all data needs to reach the cloud.
In This Series: - Sensor Applications Overview - Domain introduction - Sensor Selection Wizard - Hardware selection - Sensor Application Labs - Hands-on exercises
Architecture Topics: - IoT Reference Models - Standardized architectures - Edge Computing - Local processing - Wireless Sensor Networks - WSN design
521.2 Sensor Application Domain Hierarchy
This layered view categorizes sensors by criticality level - from safety-critical to convenience - helping you understand different reliability and accuracy requirements.
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ECF0F1', 'fontSize': '11px'}}}%%
flowchart TB
subgraph L1["SAFETY-CRITICAL (Failure = Harm)"]
S1["Medical: SpO2, ECG, Blood Glucose"]
S2["Industrial: Gas leak, Radiation"]
S3["Automotive: Collision, Tire pressure"]
REQ1["Requirements: Redundancy, Certification, Real-time"]
end
subgraph L2["OPERATIONAL (Failure = Downtime)"]
O1["Industrial: Vibration, Temperature"]
O2["Agriculture: Soil moisture, pH"]
O3["Building: HVAC, Occupancy"]
REQ2["Requirements: Accuracy, Reliability, 99%+ uptime"]
end
subgraph L3["INFORMATIONAL (Failure = Inconvenience)"]
I1["Smart Home: Motion, Light levels"]
I2["Wearables: Step count, Sleep"]
I3["Environment: Weather, Air quality"]
REQ3["Requirements: Cost-effective, Good-enough accuracy"]
end
L1 --> L2
L2 --> L3
style L1 fill:#E67E22,stroke:#2C3E50
style L2 fill:#16A085,stroke:#2C3E50
style L3 fill:#7F8C8D,stroke:#2C3E50
521.3 Sensors Per Domain
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'10px'}}}%%
flowchart TB
subgraph smartcity["SMART CITY"]
SC1["Ultrasonic -> Parking spots"]
SC2["Camera -> Traffic counting"]
SC3["PM2.5 -> Air quality"]
SC4["LDR -> Street light control"]
end
subgraph health["HEALTHCARE"]
H1["PPG -> Heart rate"]
H2["Accelerometer -> Fall detection"]
H3["Temperature -> Fever monitoring"]
H4["SpO2 -> Oxygen saturation"]
end
subgraph agri["AGRICULTURE"]
A1["Soil moisture -> Irrigation"]
A2["DHT22 -> Greenhouse climate"]
A3["pH sensor -> Soil health"]
A4["GPS -> Livestock tracking"]
end
subgraph industry["INDUSTRIAL"]
I1["Vibration -> Predictive maintenance"]
I2["Current clamp -> Energy monitoring"]
I3["Thermocouple -> High-temp process"]
I4["Flow meter -> Production rate"]
end
style smartcity fill:#E3F2FD,stroke:#2C3E50
style health fill:#FCE4EC,stroke:#E91E63
style agri fill:#E8F5E9,stroke:#16A085
style industry fill:#FFF3E0,stroke:#E67E22
521.4 Sensor Selection Decision Tree
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'13px'}}}%%
flowchart TD
Start[Sensor Selection<br/>for Application]
Q1{Indoor or<br/>Outdoor?}
Q2{Battery<br/>powered?}
Q3{Real-time<br/>data needed?}
Q4{Budget per<br/>sensor?}
Indoor[Indoor Deployment]
Outdoor[Outdoor Deployment]
Wi-Fi[Wi-Fi Sensors<br/>ESP32-based]
BLE[BLE Beacons<br/>Ultra low power]
LoRa[LoRaWAN Sensors<br/>Long range]
Cellular[Cellular IoT<br/>NB-IoT/LTE-M]
Wired[Wired Sensors<br/>Modbus/RS485]
Start --> Q1
Q1 -->|Indoor| Q2
Q1 -->|Outdoor| Q3
Q2 -->|Yes| BLE
Q2 -->|No| Wi-Fi
Q3 -->|Yes| Cellular
Q3 -->|No| Q4
Q4 -->|Low <$50| LoRa
Q4 -->|High >$50| Wired
style Start fill:#2C3E50,stroke:#16A085,color:#fff
style Q1 fill:#E67E22,stroke:#2C3E50,color:#fff
style Q2 fill:#E67E22,stroke:#2C3E50,color:#fff
style Q3 fill:#E67E22,stroke:#2C3E50,color:#fff
style Q4 fill:#E67E22,stroke:#2C3E50,color:#fff
style Wi-Fi fill:#16A085,stroke:#2C3E50,color:#fff
style BLE fill:#16A085,stroke:#2C3E50,color:#fff
style LoRa fill:#16A085,stroke:#2C3E50,color:#fff
style Cellular fill:#16A085,stroke:#2C3E50,color:#fff
style Wired fill:#16A085,stroke:#2C3E50,color:#fff
This decision tree helps you quickly narrow down connectivity options based on key deployment criteria. The path from indoor battery-powered leads to BLE for ultra-low power, while outdoor real-time applications typically require cellular connectivity.
521.5 Data Flow Architecture
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'13px'}}}%%
flowchart LR
Sensors[Sensor Layer<br/>DHT22, BMP280<br/>PIR, LDR, etc.]
Gateway[Gateway/Edge<br/>ESP32/Raspberry Pi<br/>Data aggregation]
Network[Network Layer<br/>Wi-Fi/LoRaWAN<br/>Cellular/Ethernet]
Cloud[Cloud Platform<br/>AWS IoT/Azure IoT<br/>ThingSpeak/Blynk]
Analytics[Analytics Layer<br/>Data processing<br/>ML/AI inference]
App[Application Layer<br/>Web dashboard<br/>Mobile app<br/>Alerts]
Sensors -->|Raw data| Gateway
Gateway -->|Filtered data| Network
Network -->|MQTT/HTTP| Cloud
Cloud -->|Batch/Stream| Analytics
Analytics -->|Insights| App
App -.->|Control commands| Gateway
style Sensors fill:#2C3E50,stroke:#16A085,color:#fff
style Gateway fill:#E67E22,stroke:#2C3E50,color:#fff
style Network fill:#E67E22,stroke:#2C3E50,color:#fff
style Cloud fill:#16A085,stroke:#2C3E50,color:#fff
style Analytics fill:#16A085,stroke:#2C3E50,color:#fff
style App fill:#27ae60,stroke:#2C3E50,color:#fff
Key Architecture Decisions:
- Edge Processing: Filter and aggregate data at the gateway to reduce network traffic and cloud costs
- Protocol Selection: MQTT for low-bandwidth, HTTP for compatibility, WebSocket for real-time
- Bidirectional Communication: Enable control commands from application back to sensors
- Analytics Placement: Real-time alerts at edge, batch analytics in cloud
521.6 Sensor Usage Statistics
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'14px'}}}%%
pie title Most Common IoT Sensors by Application Volume
"Temperature" : 28
"Motion/Proximity" : 22
"Light/Color" : 15
"Humidity" : 12
"Pressure/Altitude" : 10
"Acceleration/Gyro" : 8
"Gas/Air Quality" : 5
Temperature sensors dominate IoT deployments because they are: - Universal: Needed across all domains (cities, homes, industry, agriculture, health) - Low-cost: Starting at $1-2 for basic sensors - Easy to integrate: Simple analog or digital interfaces - Well-understood: Mature technology with predictable behavior
521.7 Sensor Type Comparison by Application
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'12px'}}}%%
graph LR
subgraph Smart_Cities["Smart Cities"]
SC1[Smart Parking<br/>Magnetic Field]
SC2[Traffic<br/>Magnetic + Camera]
SC3[Air Quality<br/>Gas Sensors]
SC4[Lighting<br/>LDR + PIR]
end
subgraph Agriculture["Agriculture"]
AG1[Soil Moisture<br/>Capacitive]
AG2[Weather<br/>Temp/Humid/Press]
AG3[Livestock<br/>GPS + RFID]
AG4[Irrigation<br/>Flow + Soil]
end
subgraph Healthcare["Healthcare"]
HC1[Heart Rate<br/>Optical PPG]
HC2[Fall Detection<br/>Accelerometer]
HC3[Temperature<br/>IR Thermometer]
HC4[Activity<br/>IMU Fusion]
end
subgraph Industrial["Industrial"]
IN1[Vibration<br/>Accelerometer]
IN2[Temperature<br/>Thermocouple]
IN3[Current<br/>CT Clamps]
IN4[Position<br/>Encoder/Hall]
end
subgraph Environment["Environment"]
EN1[Air Quality<br/>PM2.5/CO2/VOC]
EN2[Water Quality<br/>pH/DO/Turbidity]
EN3[Noise<br/>MEMS Microphone]
EN4[Seismic<br/>High-g Accel]
end
style Smart_Cities fill:#2C3E50,stroke:#16A085,color:#fff
style Agriculture fill:#E67E22,stroke:#2C3E50,color:#fff
style Healthcare fill:#e74c3c,stroke:#2C3E50,color:#fff
style Industrial fill:#7F8C8D,stroke:#2C3E50,color:#fff
style Environment fill:#16A085,stroke:#2C3E50,color:#fff
style SC1 fill:#ECF0F1,stroke:#2C3E50,color:#000
style SC2 fill:#ECF0F1,stroke:#2C3E50,color:#000
style SC3 fill:#ECF0F1,stroke:#2C3E50,color:#000
style SC4 fill:#ECF0F1,stroke:#2C3E50,color:#000
style AG1 fill:#ECF0F1,stroke:#E67E22,color:#000
style AG2 fill:#ECF0F1,stroke:#E67E22,color:#000
style AG3 fill:#ECF0F1,stroke:#E67E22,color:#000
style AG4 fill:#ECF0F1,stroke:#E67E22,color:#000
style HC1 fill:#ECF0F1,stroke:#e74c3c,color:#000
style HC2 fill:#ECF0F1,stroke:#e74c3c,color:#000
style HC3 fill:#ECF0F1,stroke:#e74c3c,color:#000
style HC4 fill:#ECF0F1,stroke:#e74c3c,color:#000
style IN1 fill:#ECF0F1,stroke:#7F8C8D,color:#000
style IN2 fill:#ECF0F1,stroke:#7F8C8D,color:#000
style IN3 fill:#ECF0F1,stroke:#7F8C8D,color:#000
style IN4 fill:#ECF0F1,stroke:#7F8C8D,color:#000
style EN1 fill:#ECF0F1,stroke:#16A085,color:#000
style EN2 fill:#ECF0F1,stroke:#16A085,color:#000
style EN3 fill:#ECF0F1,stroke:#16A085,color:#000
style EN4 fill:#ECF0F1,stroke:#16A085,color:#000
521.8 Sensor Deployment Lifecycle
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ECF0F1','fontSize':'13px'}}}%%
flowchart TD
Start([Sensor Application<br/>Project Start])
Requirements[Requirements Analysis<br/>- Application domain<br/>- Coverage area<br/>- Accuracy needs<br/>- Budget constraints]
Selection[Sensor Selection<br/>- Type matching<br/>- Power budget<br/>- Cost analysis<br/>- Protocol choice]
Design[System Design<br/>- Network topology<br/>- Gateway placement<br/>- Data flow<br/>- Edge processing]
Prototype[Prototype & Test<br/>- Small deployment<br/>- Validate coverage<br/>- Test connectivity<br/>- Measure performance]
Optimize{Performance<br/>Acceptable?}
Deploy[Full Deployment<br/>- Install sensors<br/>- Configure network<br/>- Calibrate sensors<br/>- Test end-to-end]
Monitor[Operations & Monitor<br/>- Data collection<br/>- Alert management<br/>- Performance tracking<br/>- Battery monitoring]
Maintain[Maintenance<br/>- Calibration<br/>- Battery replacement<br/>- Firmware updates<br/>- Issue resolution]
Evaluate{System<br/>Health OK?}
Scale[Scale & Expand<br/>- Add sensors<br/>- New locations<br/>- Additional types]
End([Continuous<br/>Operation])
Start --> Requirements
Requirements --> Selection
Selection --> Design
Design --> Prototype
Prototype --> Optimize
Optimize -->|No| Selection
Optimize -->|Yes| Deploy
Deploy --> Monitor
Monitor --> Maintain
Maintain --> Evaluate
Evaluate -->|Issues| Maintain
Evaluate -->|Good| Monitor
Monitor -.->|Expansion needed| Scale
Scale --> Deploy
Monitor --> End
style Start fill:#2C3E50,stroke:#16A085,color:#fff
style End fill:#27ae60,stroke:#16A085,color:#fff
style Requirements fill:#E67E22,stroke:#2C3E50,color:#fff
style Selection fill:#E67E22,stroke:#2C3E50,color:#fff
style Design fill:#E67E22,stroke:#2C3E50,color:#fff
style Prototype fill:#16A085,stroke:#2C3E50,color:#fff
style Deploy fill:#16A085,stroke:#2C3E50,color:#fff
style Monitor fill:#3498db,stroke:#2C3E50,color:#fff
style Maintain fill:#3498db,stroke:#2C3E50,color:#fff
style Optimize fill:#f39c12,stroke:#2C3E50,color:#000
style Evaluate fill:#f39c12,stroke:#2C3E50,color:#000
style Scale fill:#9b59b6,stroke:#2C3E50,color:#fff
Lifecycle Phases Explained:
- Requirements Analysis (Week 1-2): Define what you need to measure, where, how accurately, and within what budget
- Sensor Selection (Week 2-3): Match sensor specifications to requirements using the Selection Wizard
- System Design (Week 3-4): Plan network topology, gateway placement, and data flow architecture
- Prototype & Test (Week 4-8): Deploy 5-10% of planned sensors to validate assumptions
- Optimization (Week 8-10): Adjust sensor placement, sampling rates, and connectivity based on prototype results
- Full Deployment (Week 10-16): Install all sensors, configure network, calibrate, and test end-to-end
- Operations & Monitor (Ongoing): Collect data, manage alerts, track performance metrics
- Maintenance (Quarterly): Calibrate sensors, replace batteries, update firmware
- Scale & Expand (As needed): Add sensors, new locations, or additional sensor types based on operational insights
521.9 Architecture Design Patterns
521.9.1 Pattern 1: Star Topology (Simple)
Sensor1 ---+
|
Sensor2 ---+--- Gateway --- Cloud
|
Sensor3 ---+
Use when: Small deployments (<20 sensors), all sensors within gateway range, Wi-Fi/BLE connectivity Example: Smart home, single office floor, small greenhouse
521.9.2 Pattern 2: Mesh Topology (Resilient)
Sensor1 --- Sensor2
| X |
Sensor3 --- Sensor4 --- Gateway --- Cloud
Use when: Large area coverage, redundancy required, Zigbee/Thread connectivity Example: Industrial floor, smart city block, large farm
521.9.3 Pattern 3: Hierarchical (Scalable)
Sensors --- Edge1 ---+
|
Sensors --- Edge2 ---+--- Cloud
|
Sensors --- Edge3 ---+
Use when: Large-scale deployments (100+ sensors), edge processing needed, LoRaWAN/cellular Example: City-wide deployment, multi-site enterprise, large agricultural operation
521.9.4 Pattern 4: Hybrid (Complex Requirements)
Critical Sensors --- Direct Cloud (Cellular)
|
Bulk Sensors --- Edge ---+ (LoRaWAN)
|
Local Sensors --- Hub ---+ (Wi-Fi)
Use when: Mixed requirements (real-time + batch), different criticality levels, cost optimization Example: Hospital (critical patient monitors + environmental sensors), factory (safety + monitoring)
521.10 Coverage Planning
521.10.1 Sensor Coverage Radius Guidelines
| Sensor Type | Indoor Coverage | Outdoor Coverage | Notes |
|---|---|---|---|
| Temperature | 50-100 m2 | 500-1000 m2 | Depends on HVAC zones |
| Motion (PIR) | 5-12 m cone | Not recommended | Line of sight required |
| Gas (CO2, VOC) | 50 m2 | 100-500 m2 | Diffusion-limited |
| Particulate (PM2.5) | 100 m2 | 1-2 km2 | Wind disperses particles |
| Noise | 20-50 m radius | 100-200 m radius | Inverse square law |
| Ultrasonic | 2-4 m direct | 4-8 m direct | Point measurement |
521.10.2 Coverage Calculation Example
Scenario: Monitor air quality in 10,000 m2 office building
- CO2 sensors: 10,000 m2 / 50 m2 per sensor = 200 sensors (too many!)
- Optimization: Place sensors near HVAC returns (8 zones) + high-occupancy areas (10 conference rooms) + open office (5 clusters) = 23 sensors
- Validation: Pilot with 5 sensors, interpolate missing areas, adjust as needed
- Result: 80% coverage with 90% fewer sensors
521.11 Network Bandwidth Planning
521.11.1 Data Rate Calculation
Data Rate = Sensors x Sample Rate x Bytes per Sample x Overhead
Example: 100 temperature sensors, 1 sample/minute, 4 bytes/sample, 2x overhead
= 100 x (1/60) x 4 x 2 = 13.3 bytes/second = 0.1 kbps
521.11.2 Bandwidth Requirements by Application
| Application | Sensors | Sample Rate | Data per Sensor | Total Bandwidth |
|---|---|---|---|---|
| Smart Parking | 1000 | 0.01 Hz | 10 bytes | 0.1 kbps |
| Air Quality | 100 | 0.1 Hz | 50 bytes | 0.5 kbps |
| Industrial Vibration | 20 | 1000 Hz | 4 bytes | 640 kbps |
| Video Surveillance | 10 | 30 fps | 100 KB/frame | 240 Mbps |
Key Insight: Video dominates bandwidth. For sensor-only deployments, bandwidth is rarely the bottleneck; power and cost are.
521.12 Summary
This chapter covered sensor application architecture patterns:
- Domain Hierarchy: Understanding how 61+ applications map across 12 IoT domains
- Criticality Levels: Safety-critical vs. operational vs. informational sensor requirements
- Data Flow Architecture: Six-layer model from sensors to applications
- Decision Trees: Systematic approaches to sensor and connectivity selection
- Deployment Lifecycle: Nine-phase process from requirements to continuous operation
- Design Patterns: Star, mesh, hierarchical, and hybrid topologies for different scales
- Coverage Planning: Guidelines for sensor placement and density optimization
- Bandwidth Planning: Calculating network requirements for different application types
521.13 Whatβs Next
Now that you understand sensor application architecture, put your knowledge into practice with hands-on exercises:
Continue to Sensor Application Labs -> - Practical exercises for designing and planning sensor deployments, including cost analysis, coverage optimization, and multi-sensor integration.