113 IoT Domain Requirements and Selection
113.1 Why Different Domains Have Different Requirements
Before diving into each domain, it’s crucial to understand why we can’t use the same IoT solution everywhere. The answer lies in understanding what each domain actually needs–and why those needs differ so dramatically.
113.2 Learning Objectives
By the end of this chapter, you will be able to:
- Compare domain requirements across latency, reliability, scale, power, and data volume dimensions
- Explain regulatory impacts on IoT project cost and timeline
- Match technology choices to domain-specific constraints
- Evaluate trade-offs when selecting IoT solutions for different applications
113.3 The Healthcare vs Agriculture Comparison
Consider two temperature monitoring scenarios that illustrate how the same measurement can have completely different requirements:
Hospital Patient Monitoring
- What’s measured: Patient body temperature
- Criticality: Life-threatening if measurement is missed or inaccurate
- Response needed: Immediate (seconds) for fever alerts
- Accuracy required: +/-0.1C (medical-grade precision)
- Reliability: 99.99% uptime (lives at stake–52 minutes downtime per year maximum)
- Compliance: HIPAA (patient data privacy), FDA (medical device approval)
- Cost tolerance: $500+ per sensor acceptable (patient safety justifies expense)
Vineyard Frost Monitoring
- What’s measured: Air temperature in agricultural fields
- Criticality: Crop damage if frost missed, but not life-threatening
- Response needed: Minutes (frost builds slowly over 30-60 minutes)
- Accuracy required: +/-1C (frost threshold is approximately 0C)
- Reliability: 95% uptime acceptable (redundant sensors compensate for failures)
- Compliance: None required (no regulations for agricultural sensing)
- Cost tolerance: <$50 per sensor (need hundreds, agriculture has tight margins)
Same measurement (temperature), completely different requirements!
This comparison reveals why domain requirements matter: the consequences of failure, the speed of decision-making, regulatory oversight, and economic constraints all vary dramatically based on context.
113.4 The Latency Spectrum: Why Response Time Matters
Different applications have fundamentally different time constraints based on what they’re controlling and the consequences of delays:
| Domain | Typical Latency Requirement | Why This Matters |
|---|---|---|
| Autonomous vehicles | <10 ms | Avoiding collisions at highway speeds (70 mph = 30 meters per second) |
| Industrial robotics | <50 ms | Precise assembly operations require real-time coordination |
| Building automation | <1 second | HVAC response and lighting adjustments feel instantaneous to users |
| Smart agriculture | <1 minute | Irrigation decisions based on slowly-changing soil conditions |
| Environmental monitoring | <1 hour | Weather and air quality change gradually over time |
Key Insight: A 100ms delay is catastrophic for autonomous vehicles but completely acceptable for environmental monitoring. Understanding these latency requirements drives architecture decisions–autonomous vehicles need edge computing (local processing), while environmental monitoring can use cloud platforms.
113.5 The Reliability Spectrum: Cost of Downtime
System reliability requirements directly correlate with the human and economic cost of failure:
| Domain | Uptime Requirement | Annual Downtime Allowed | Consequence of Failure |
|---|---|---|---|
| Healthcare | 99.99% (four nines) | 52 minutes/year max | Patient harm or death |
| Traffic control | 99.9% (three nines) | 8.7 hours/year max | Accidents, traffic chaos, economic loss |
| Smart home | 99% (two nines) | 3.6 days/year max | Inconvenience, user frustration |
| Agriculture | 95% | 18 days/year max | Partial crop loss (often recoverable) |
Real-World Implications:
- Achieving 99.99% uptime requires redundant systems, failover mechanisms, and 24/7 monitoring–expensive infrastructure that healthcare justifies but agriculture cannot afford
- Smart home users tolerate occasional failures (thermostat offline for a day), but traffic control systems require enterprise-grade reliability
- The cost to deliver each additional “nine” of uptime roughly increases by 10x (99% to 99.9% to 99.99%)
113.6 The Scale Spectrum: From Wearables to Cities
Deployment scale fundamentally changes system architecture, cost structure, and technology choices:
| Scale | Device Count | Example Application | Infrastructure Implications |
|---|---|---|---|
| Personal | 1-10 devices | Fitness tracker, smartwatch | Bluetooth to smartphone, no infrastructure needed |
| Home | 10-50 devices | Smart home automation | Wi-Fi or Zigbee mesh, single gateway, consumer budget |
| Building | 50-500 devices | Office HVAC, security | Building-wide network, IT staff, professional installation |
| Campus | 500-5,000 devices | University, hospital, vineyard | Dedicated network infrastructure, gateway management |
| City | 5,000+ devices | Municipal parking, streetlights | Requires LoRaWAN/NB-IoT, city-scale backbone, operations center |
Technology Selection by Scale:
- Personal/Home (1-50 devices): Bluetooth, Wi-Fi, Zigbee (existing consumer infrastructure)
- Building/Campus (50-5,000 devices): Wi-Fi, LoRaWAN gateways, wired Ethernet (dedicated infrastructure)
- City (5,000+ devices): LoRaWAN, NB-IoT, Sigfox (carrier-grade networks, no per-site infrastructure)
113.7 Power Source Drives Everything
The availability of power fundamentally constrains connectivity and sensor choices:
| Power Source | Typical Lifetime | Enables Technologies | Typical Domains |
|---|---|---|---|
| Mains (wall power) | Unlimited | Wi-Fi, Ethernet, Video, High-power sensors | Buildings, traffic cameras, industrial |
| PoE (Power over Ethernet) | Unlimited | IP cameras, VoIP, Wi-Fi APs | Office buildings, warehouses |
| Rechargeable battery | 1-7 days between charges | Bluetooth, moderate sensors | Wearables, smartphones, patient monitors |
| Long-life battery | 1-10 years | LoRaWAN, NB-IoT, ultra-low-power sensors | Parking sensors, environmental monitoring |
| Solar + battery | 10+ years | LoRaWAN, Sigfox, periodic sampling | Agriculture, remote environmental |
| Energy harvesting | Unlimited (if sufficient) | BLE beacons, low-power sensors | Indoor tracking, maintenance-free sensors |
Example: Why agriculture uses LoRaWAN instead of Wi-Fi:
- Wi-Fi: 100-200 mW transmit power means battery drains in weeks
- LoRaWAN: 20-50 mW transmit power, only active 1% of time means battery lasts 5-10 years
- Result: $50 sensor with 10-year battery vs. $200 sensor + solar panel or frequent battery replacement
113.8 Data Volume Shapes Architecture
How much data you generate determines where you can process it and how much it costs:
| Data Volume | Bytes per Device per Day | Example Applications | Architecture Impact |
|---|---|---|---|
| Very Low | <1 KB | Environmental sensors (temperature, soil moisture) | LoRaWAN/Sigfox acceptable, edge processing unnecessary |
| Low | 1-100 KB | Smart parking, occupancy sensors | NB-IoT or Wi-Fi, cloud processing fine |
| Medium | 100 KB - 10 MB | Wearable biometrics, building automation | Wi-Fi or cellular, cloud or edge processing |
| High | 10-100 MB | Industrial vibration analysis, traffic monitoring | Wired Ethernet or 4G/5G, edge processing preferred |
| Very High | >100 MB | Video surveillance, high-frequency sensors | Wired Ethernet required, edge processing essential |
Real-World Example: Manufacturing predictive maintenance
Vibration sensor sampling at 100 Hz:
- Per sensor: 100 samples/sec x 4 bytes = 400 bytes/sec
- 500 sensors: 200 KB/sec = 17 GB/day raw data
- Edge processing: Compress to 1% (only anomalies sent to cloud) = 170 MB/day
- Cloud cost: 17 GB/day x $0.10/GB = $1.70/day vs. 170 MB/day x $0.10/GB = $0.017/day
- Annual savings: $1.70/day x 365 = $620/year per day of data vs. $6/year (100x reduction!)Key Insight: High data volumes make edge computing economically necessary, not just technically optimal.
113.9 Regulatory Complexity Adds Cost and Time
Some domains face stringent regulations that dramatically increase project complexity:
| Domain | Key Regulations | Approval Timeline | Cost Impact |
|---|---|---|---|
| Healthcare | FDA Class II medical device, HIPAA privacy | 12-24 months | +200-500% development cost |
| Automotive | ISO 26262 functional safety, NHTSA | 18-36 months | +300-800% testing and validation |
| Utilities (Smart Grid) | NERC CIP cybersecurity, utility commission approval | 6-18 months | +100-200% compliance overhead |
| Industrial | OSHA safety, OT security standards | 3-12 months | +50-150% implementation cost |
| Agriculture | Minimal (mostly voluntary) | 0-3 months | +0-25% (mostly environmental certifications) |
| Consumer | FCC (radio), UL (electrical), voluntary privacy | 3-6 months | +20-50% (primarily testing costs) |
Example: Why healthcare wearables cost more than fitness trackers:
| Aspect | Fitness Tracker (Consumer) | Medical Wearable (Healthcare) |
|---|---|---|
| Regulatory approval | FCC radio certification | FDA Class II medical device + FCC |
| Development timeline | 6-12 months | 18-36 months |
| Clinical validation | None required | Required (IRB studies, clinical trials) |
| Data accuracy requirements | “Best effort” acceptable | +/-0.1C temperature, +/-2 bpm heart rate |
| Privacy compliance | Voluntary (company policy) | HIPAA mandatory (fines up to $1.5M per violation) |
| Product liability | Limited consumer liability | Medical malpractice exposure |
| Typical retail price | $50-200 | $500-2,000 |
Key Insight: Regulatory compliance isn’t just bureaucracy–it ensures safety and privacy, but adds 50-500% to project cost and timeline.
113.10 Domain Requirements Comparison Matrix
| Domain | Latency | Reliability | Scale | Power | Data Volume | Regulations |
|---|---|---|---|---|---|---|
| Autonomous Vehicles | <10 ms | 99.999% | Personal | Mains | Very High | Very High |
| Healthcare Monitoring | <1 s | 99.99% | Personal-Building | Battery/Mains | Medium | Very High |
| Industrial M2M | <50 ms | 99.9% | Building-Campus | Mains | High | High |
| Smart Cities | <1 min | 99% | City | Battery/Solar | Low-Medium | Medium |
| Smart Agriculture | <1 hour | 95% | Campus | Solar/Battery | Very Low | Low |
| Smart Home | <1 s | 99% | Home | Mains/Battery | Low | Low |
| Environmental Monitoring | <1 hour | 95% | City | Solar | Very Low | Low |
113.11 Technology Selection Decision Tree
When selecting IoT technologies for a domain, follow this decision process:
- What’s the latency requirement?
- <50 ms: Edge computing required, wired connectivity preferred
- <1 s: Edge or cloud, Wi-Fi/cellular acceptable
- <1 min+: Cloud processing fine, LPWAN acceptable
- What’s the power source?
- Mains power: Wi-Fi, Ethernet, cellular–no constraints
- Long-life battery: LoRaWAN, NB-IoT, Sigfox only
- Solar: LoRaWAN or Sigfox with careful power budget
- What’s the deployment scale?
- <50 devices: Consumer protocols (Wi-Fi, Bluetooth, Zigbee)
- 50-5,000 devices: LoRaWAN gateways or Wi-Fi infrastructure
- 5,000+ devices: Carrier networks (NB-IoT) or city-scale LoRaWAN
- What data volume per device?
- <1 KB/day: Any LPWAN works
- 1-100 KB/day: NB-IoT or Wi-Fi preferred
100 KB/day: Wi-Fi, cellular, or wired required
- What’s the regulatory environment?
- Healthcare/Automotive: Budget 2-3x timeline and cost
- Industrial: Plan for OT security integration
- Consumer: Standard compliance sufficient
The Myth: “I can use Wi-Fi for everything” or “LoRaWAN solves all IoT problems”
Why It’s Wrong: No single technology works across all domains because requirements are fundamentally incompatible:
Wi-Fi Works Great For:
- Smart homes (existing infrastructure, mains power)
- Healthcare (hospital Wi-Fi already deployed)
- Industrial (high data volume, wired power available)
Wi-Fi Fails For:
- Agriculture (50-100m range means 100+ APs for 50 hectares, power consumption drains batteries in weeks)
- Environmental monitoring (remote areas lack infrastructure, power constraints)
- Smart cities (deployment cost prohibitive: 50,000 streetlights x 1 AP per 100m = 500+ APs)
Similarly, LoRaWAN Fails Where Wi-Fi Excels:
- Healthcare patient monitors (0.3-50 kbps insufficient for continuous ECG/video)
- Industrial video analytics (need Mbps, not Kbps)
- Smart home real-time control (1-2 second latency too slow for voice control)
The Truth: Every domain has 3-5 viable technology options based on specific constraints.
113.12 Domain Selection Framework
Use this scoring system to evaluate IoT domains for a project:
Weighted Scoring (100 points total):
- Requirements Fit (50%): How well does the technology match domain needs?
- Cost Alignment (30%): Is the solution within budget constraints?
- Complexity Match (20%): Can your team implement this complexity level?
Example Calculation for Smart Agriculture Project:
| Factor | Weight | Score | Weighted |
|---|---|---|---|
| Requirements Fit | 50% | 85/100 | 42.5 |
| Cost Alignment | 30% | 90/100 | 27.0 |
| Complexity Match | 20% | 80/100 | 16.0 |
| Total | 100% | 85.5 |
Projects scoring above 75 are strong candidates; 60-75 require careful evaluation; below 60 should be reconsidered.
113.13 Summary
Understanding domain requirements is essential for IoT project success:
- Latency ranges from <10 ms (autonomous vehicles) to hours (environmental monitoring)
- Reliability costs increase 10x per additional “nine” of uptime
- Scale determines infrastructure investment and technology choices
- Power constraints often eliminate entire technology categories
- Data volume drives edge vs. cloud processing decisions
- Regulations can add 50-500% to project cost and timeline
The key insight: Start with requirements, not technology. Understanding what each domain actually needs prevents the common mistake of force-fitting a favorite technology into an incompatible use case.
113.14 What’s Next
Now that you understand why domains have different requirements, explore specific application areas:
- Smart Cities - Urban infrastructure at scale
- Smart Agriculture - Remote, battery-powered deployments
- Healthcare IoT - High-reliability, regulated environments
- Industrial Manufacturing - Real-time, high-data-volume systems