15  Domain Selection

15.1 Why Different Domains Have Different Requirements

Estimated Time: 25 min | Complexity: Intermediate | Unit: P03.C02.U02

Key Concepts

• IoT Architecture: Layered model comprising perception, network, and application tiers defining how sensors, gateways, and cloud services interact.
• Edge Computing: Processing data close to the sensor source to reduce latency, bandwidth costs, and cloud dependency.
• Telemetry: Time-stamped sensor readings transmitted from a device to a cloud or edge platform for storage, analysis, and visualisation.
• Protocol Stack: Set of communication protocols layered from physical radio to application message format that devices must implement to interoperate.
• Device Lifecycle: Stages from manufacture through provisioning, operation, maintenance, and decommissioning that IoT management platforms must support.
• Security Hardening: Process of reducing attack surface by disabling unused services, applying least-privilege access, and enabling encrypted communications.
• Scalability: System property ensuring performance and cost remain acceptable as the number of connected devices grows from prototype to mass deployment.

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.

15.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

Minimum Viable Understanding

• Six Requirement Dimensions: Every IoT domain is defined by latency, reliability, scale, power, data volume, and regulation – no single technology satisfies all combinations, which is why domain analysis must precede technology selection.
• Requirements Before Technology: The leading cause of IoT project failure is choosing technology first; a hospital patient monitor needs 99.99% uptime, sub-second alerts, and FDA/HIPAA compliance ($500+ per sensor), while a vineyard frost sensor needs only 95% uptime and no regulation (<$50 per sensor).
• Constraint-Driven Elimination: The requirement with the tightest constraint (often power or regulation) typically eliminates 60-80% of technology options, narrowing viable choices to 3-5 candidates.
• Cost of Reliability: Each additional “nine” of uptime (e.g., 99% to 99.9% to 99.99%) roughly costs 10x more, meaning a healthcare system at 99.99% costs approximately 1,000x more infrastructure than an agriculture system at 95%.

Sensor Squad: The Requirements Challenge

Not all jobs are the same – and neither are sensors!

15.2.1 The Sensor Squad Adventure: The Requirements Challenge

The Sensor Squad just got THREE new missions – but each one needs completely different tools!

Mission 1: Hospital Helper Thermo the Temperature Sensor is assigned to monitor a sick child in the hospital. “This is serious!” says Thermo. “I need to check the temperature EVERY SECOND and tell the nurse INSTANTLY if there’s a fever. I can NEVER take a break – not even for one minute!” Thermo gets a special medical-grade badge and a strong Wi-Fi connection so messages arrive in less than a blink of an eye.

Mission 2: Farm Friend Hydro the Humidity Sensor is sent to a big vineyard to watch for frost. “I don’t need to be as fast,” Hydro says. “Frost happens slowly over 30 minutes, so checking every few minutes is fine.” Hydro gets a tiny battery that lasts 10 YEARS and uses LoRaWAN, which sends tiny messages over really long distances. “I cost only $50 – the farmer needs hundreds of me!”

Mission 3: Race Car Referee Motion Mo the Motion Detector gets the toughest job – a self-driving car! “I have to see EVERYTHING in less than 10 milliseconds – that’s faster than you can blink!” Mo needs the fastest computer right inside the car, because there’s no time to send data to the cloud and wait for an answer.

The big lesson? Same type of sensor, completely different requirements! Thermo needs to be super reliable. Hydro needs a super long battery. And Mo needs to be super FAST.

15.2.2 Key Words for Kids

Word	What It Means
Requirements	What a sensor MUST be able to do for its specific job
Latency	How quickly a sensor needs to send its message – like reaction time!
Reliability	How often the sensor works without breaking – hospitals need near-perfect!
Battery Life	How long the sensor can run before needing a new battery

15.2.3 Try This at Home!

Be a Requirements Detective!

1. Pick three “smart” devices in your house (thermostat, doorbell camera, smoke detector)
2. For each one, answer: How fast does it need to respond? What happens if it stops working?
3. Rank them: Which one is most important to NEVER break? Which can be slow?

What you’ll discover: Your smoke detector needs to be super reliable (life safety!), your doorbell can be a bit slow (a few seconds is OK), and your thermostat can even go offline for hours without a problem. Different jobs need different levels of speed and reliability!

For Beginners: Why “One Size Fits All” Fails in IoT

Understanding domain requirements is like understanding why you wouldn’t wear the same outfit to a beach and a job interview – context determines what’s appropriate.

Simple Analogy: Think of IoT technologies like vehicles:

• Ambulance (Healthcare IoT): Must be fast, reliable, expensive – lives depend on it
• Farm tractor (Agriculture IoT): Slow is fine, must be rugged and fuel-efficient over large areas
• Race car (Autonomous vehicles): Maximum speed, extreme precision, cost no object
• Bicycle (Smart home): Simple, affordable, good enough for short trips

You wouldn’t use a race car to plow a field, and you wouldn’t use a tractor in an emergency room!

The Six Key Questions before choosing any IoT technology:

1. How fast? (Milliseconds to hours – this is “latency”)
2. How reliable? (95% to 99.999% uptime)
3. How many devices? (10 in a house to 50,000 across a city)
4. What power source? (Wall outlet, battery, solar panel)
5. How much data? (A few bytes to gigabytes per day)
6. What rules apply? (Government regulations, safety standards)

Why This Matters for You: If you are building an IoT project, answering these six questions first will save you months of wasted work. The answers naturally narrow your technology options from hundreds to just 3-5 viable choices.

15.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.

The six dimensions of IoT domain requirements that drive technology selection

Figure 15.1: The six dimensions of IoT domain requirements that drive technology selection

15.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:

IoT latency spectrum showing response time requirements across application domains

Figure 15.2: IoT latency spectrum showing response time requirements across application domains

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.

15.5 Interactive: Latency-to-Distance Calculator

Explore how latency translates to physical distance traveled at different vehicle speeds:

viewof vehicleSpeed = Inputs.range(
  [10, 150],
  {
    label: "Vehicle Speed (mph)",
    value: 70,
    step: 5,
    format: x => `${x} mph (${(x * 1.60934).toFixed(0)} km/h)`
  }
)

viewof systemLatency = Inputs.range(
  [1, 500],
  {
    label: "System Latency (ms)",
    value: 100,
    step: 5,
    format: x => `${x} ms`
  }
)

latencyCalculation = {
  const speedMps = vehicleSpeed * 0.44704;  // mph to m/s
  const latencySec = systemLatency / 1000;  // ms to seconds
  const distanceMeters = speedMps * latencySec;
  const distanceFeet = distanceMeters * 3.28084;
  
  // Safety assessment
  let safetyLevel, safetyColor, safetyText;
  if (systemLatency <= 10) {
    safetyLevel = "Autonomous Vehicles";
    safetyColor = "#16A085";
    safetyText = "Suitable for collision avoidance";
  } else if (systemLatency <= 50) {
    safetyLevel = "Industrial Robotics";
    safetyColor = "#3498DB";
    safetyText = "Good for coordinated operations";
  } else if (systemLatency <= 200) {
    safetyLevel = "Driver Assistance";
    safetyColor = "#E67E22";
    safetyText = "Human reaction time needed";
  } else {
    safetyLevel = "Not Safe";
    safetyColor = "#E74C3C";
    safetyText = "Too slow for vehicle safety systems";
  }
  
  return {
    distanceMeters: distanceMeters,
    distanceFeet: distanceFeet,
    speedMps: speedMps,
    safetyLevel: safetyLevel,
    safetyColor: safetyColor,
    safetyText: safetyText
  };
}

html`
<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); padding: 24px; border-radius: 8px; color: white; margin: 20px 0;">
  <h3 style="margin-top: 0; color: #16A085; font-size: 1.3em;">Latency Distance Analysis</h3>
  
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 16px; margin-top: 16px;">
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #16A085;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Vehicle Speed</div>
      <div style="font-size: 1.8em; font-weight: bold;">${vehicleSpeed} mph</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">${latencyCalculation.speedMps.toFixed(1)} m/s</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #E67E22;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">System Latency</div>
      <div style="font-size: 1.8em; font-weight: bold;">${systemLatency} ms</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #3498DB;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Distance Traveled</div>
      <div style="font-size: 1.8em; font-weight: bold;">${latencyCalculation.distanceMeters.toFixed(2)} m</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">${latencyCalculation.distanceFeet.toFixed(1)} feet</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid ${latencyCalculation.safetyColor};">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Safety Assessment</div>
      <div style="font-size: 1.4em; font-weight: bold; color: ${latencyCalculation.safetyColor};">${latencyCalculation.safetyLevel}</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">${latencyCalculation.safetyText}</div>
    </div>
  </div>
  
  <div style="margin-top: 20px; padding: 16px; background: rgba(22, 160, 133, 0.2); border-radius: 6px; border-left: 4px solid #16A085;">
    <strong style="color: #16A085;">💡 Why This Matters:</strong> 
    ${systemLatency <= 10 ? `At ${systemLatency}ms latency, the vehicle travels only ${latencyCalculation.distanceMeters.toFixed(2)} meters before reacting - essential for autonomous obstacle avoidance.` : systemLatency <= 50 ? `With ${systemLatency}ms latency, the vehicle moves ${latencyCalculation.distanceMeters.toFixed(1)} meters during processing - acceptable for driver assistance but requires edge computing for safety-critical decisions.` : `At ${systemLatency}ms, the vehicle travels ${latencyCalculation.distanceMeters.toFixed(1)} meters (${latencyCalculation.distanceFeet.toFixed(0)} feet) before reacting. This latency is too high for autonomous safety systems - cloud processing delays would be catastrophic at highway speeds.`}
  </div>
</div>
`

15.6 The Reliability Spectrum: Cost of Downtime

System reliability requirements directly correlate with the human and economic cost of failure:

Reliability requirements and associated costs across IoT domains – each additional nine of uptime roughly costs 10x more

Figure 15.3: Reliability requirements and associated costs across IoT domains – each additional nine of uptime roughly costs 10x more

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%)

Putting Numbers to It

Consider building an IoT infrastructure for 10,000 sensors. The base infrastructure cost at 95% uptime (agriculture-grade) is $50,000. Each additional “nine” of reliability approximately costs 10× more:

\[\text{Cost}_{95\%} = \$50,000\] \[\text{Cost}_{99\%} = \$50,000 \times 10 = \$500,000\] \[\text{Cost}_{99.9\%} = \$500,000 \times 10 = \$5,000,000\] \[\text{Cost}_{99.99\%} = \$5,000,000 \times 10 = \$50,000,000\]

This 1,000× cost difference ($50K to $50M) explains why agriculture systems tolerate 18 days/year of downtime while healthcare systems allow only 52 minutes/year. The reliability requirement alone determines whether your project costs $5 per sensor or $5,000 per sensor for infrastructure.

15.7 Interactive: Reliability Cost Calculator

Use this calculator to explore how reliability requirements impact infrastructure costs:

viewof reliabilityUptime = Inputs.select(
  [95, 99, 99.9, 99.99, 99.999],
  {
    label: "Target Uptime (%)",
    value: 99,
    format: x => x === 99.999 ? "99.999% (Five Nines)" : x === 99.99 ? "99.99% (Four Nines)" : x === 99.9 ? "99.9% (Three Nines)" : x === 99 ? "99% (Two Nines)" : "95%"
  }
)

viewof baseInfrastructureCost = Inputs.range(
  [10000, 500000],
  {
    label: "Base Infrastructure Cost (95% uptime) ($)",
    value: 50000,
    step: 5000,
    format: x => `$${(x/1000).toFixed(0)}K`
  }
)

viewof sensorCount = Inputs.range(
  [100, 50000],
  {
    label: "Number of Sensors",
    value: 10000,
    step: 100,
    format: x => x.toLocaleString()
  }
)

reliabilityCalculation = {
  const uptimeMap = {
    95: { multiplier: 1, downtime: 18.25, label: "95%" },
    99: { multiplier: 10, downtime: 3.65, label: "99% (Two Nines)" },
    99.9: { multiplier: 100, downtime: 0.73, label: "99.9% (Three Nines)" },
    99.99: { multiplier: 1000, downtime: 0.0876, label: "99.99% (Four Nines)" },
    99.999: { multiplier: 10000, downtime: 0.00876, label: "99.999% (Five Nines)" }
  };
  
  const data = uptimeMap[reliabilityUptime];
  const totalCost = baseInfrastructureCost * data.multiplier;
  const costPerSensor = totalCost / sensorCount;
  
  // Convert downtime to appropriate units
  let downtimeDisplay;
  if (data.downtime >= 1) {
    downtimeDisplay = `${data.downtime.toFixed(2)} days/year`;
  } else if (data.downtime >= 0.04) {  // More than 1 hour
    const hours = (data.downtime * 24).toFixed(1);
    downtimeDisplay = `${hours} hours/year`;
  } else {
    const minutes = (data.downtime * 24 * 60).toFixed(0);
    downtimeDisplay = `${minutes} minutes/year`;
  }
  
  return {
    uptime: data.label,
    multiplier: data.multiplier,
    totalCost: totalCost,
    costPerSensor: costPerSensor,
    downtimeDisplay: downtimeDisplay,
    downtimeDays: data.downtime
  };
}

html`
<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); padding: 24px; border-radius: 8px; color: white; margin: 20px 0;">
  <h3 style="margin-top: 0; color: #16A085; font-size: 1.3em;">Reliability Cost Analysis</h3>
  
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 16px; margin-top: 16px;">
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #16A085;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Target Uptime</div>
      <div style="font-size: 1.8em; font-weight: bold;">${reliabilityCalculation.uptime}</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #E67E22;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Cost Multiplier</div>
      <div style="font-size: 1.8em; font-weight: bold;">${reliabilityCalculation.multiplier}x</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #3498DB;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Total Infrastructure Cost</div>
      <div style="font-size: 1.8em; font-weight: bold;">$${(reliabilityCalculation.totalCost / 1000000).toFixed(2)}M</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">$${reliabilityCalculation.costPerSensor.toFixed(2)} per sensor</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #E74C3C;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Allowed Downtime</div>
      <div style="font-size: 1.8em; font-weight: bold;">${reliabilityCalculation.downtimeDisplay}</div>
    </div>
  </div>
  
  <div style="margin-top: 20px; padding: 16px; background: rgba(22, 160, 133, 0.2); border-radius: 6px; border-left: 4px solid #16A085;">
    <strong style="color: #16A085;">💡 Key Insight:</strong> Each additional "nine" of uptime costs approximately 10x more. 
    ${reliabilityUptime === 99.99 ? `Healthcare systems at ${reliabilityCalculation.uptime} cost approximately ${(reliabilityCalculation.multiplier/10).toFixed(0)}x more than agriculture systems at 95% uptime.` : reliabilityUptime === 95 ? `Agriculture systems can tolerate ${reliabilityCalculation.downtimeDisplay}, keeping costs low.` : `At ${reliabilityCalculation.uptime}, you're spending $${(reliabilityCalculation.totalCost / 1000000).toFixed(1)}M for infrastructure that delivers ${reliabilityCalculation.downtimeDisplay} of allowed downtime.`}
  </div>
</div>
`

15.8 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)

15.9 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

15.10 Interactive: Battery Life Estimator

Calculate expected battery life based on power consumption and duty cycle:

viewof transmitPowerMw = Inputs.range(
  [10, 250],
  {
    label: "Transmit Power (mW)",
    value: 50,
    step: 10,
    format: x => `${x} mW`
  }
)

viewof dutyCycle = Inputs.range(
  [0.01, 10],
  {
    label: "Duty Cycle (%)",
    value: 1,
    step: 0.1,
    format: x => `${x.toFixed(1)}%`
  }
)

viewof batteryCapacityMah = Inputs.select(
  [1000, 2000, 3000, 5000, 10000],
  {
    label: "Battery Capacity (mAh)",
    value: 3000,
    format: x => `${(x/1000).toFixed(0)}Ah (${x}mAh)`
  }
)

viewof sleepPowerMw = Inputs.range(
  [0.001, 5],
  {
    label: "Sleep Power (mW)",
    value: 0.05,
    step: 0.01,
    format: x => x < 0.1 ? `${(x*1000).toFixed(0)} µW` : `${x.toFixed(2)} mW`
  }
)

batteryCalculation = {
  const voltage = 3.7;  // Standard Li-ion voltage
  const batteryCapacityMwh = batteryCapacityMah * voltage;  // Convert to mWh
  
  // Calculate average power consumption
  const dutyCycleFraction = dutyCycle / 100;
  const avgPowerMw = (transmitPowerMw * dutyCycleFraction) + (sleepPowerMw * (1 - dutyCycleFraction));
  
  // Battery life in hours
  const batteryLifeHours = batteryCapacityMwh / avgPowerMw;
  const batteryLifeDays = batteryLifeHours / 24;
  const batteryLifeYears = batteryLifeDays / 365;
  
  // Determine technology suitability
  let techRecommendation, techColor;
  if (batteryLifeYears >= 10) {
    techRecommendation = "LoRaWAN / Sigfox";
    techColor = "#16A085";
  } else if (batteryLifeYears >= 5) {
    techRecommendation = "NB-IoT";
    techColor = "#3498DB";
  } else if (batteryLifeYears >= 1) {
    techRecommendation = "Bluetooth LE";
    techColor = "#E67E22";
  } else if (batteryLifeDays >= 7) {
    techRecommendation = "Wi-Fi (rechargeable)";
    techColor = "#9B59B6";
  } else {
    techRecommendation = "Requires Mains Power";
    techColor = "#E74C3C";
  }
  
  // Format display
  let lifetimeDisplay;
  if (batteryLifeYears >= 1) {
    lifetimeDisplay = `${batteryLifeYears.toFixed(1)} years`;
  } else if (batteryLifeDays >= 1) {
    lifetimeDisplay = `${batteryLifeDays.toFixed(0)} days`;
  } else {
    lifetimeDisplay = `${batteryLifeHours.toFixed(0)} hours`;
  }
  
  return {
    avgPowerMw: avgPowerMw,
    batteryLifeHours: batteryLifeHours,
    batteryLifeDays: batteryLifeDays,
    batteryLifeYears: batteryLifeYears,
    lifetimeDisplay: lifetimeDisplay,
    techRecommendation: techRecommendation,
    techColor: techColor
  };
}

html`
<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); padding: 24px; border-radius: 8px; color: white; margin: 20px 0;">
  <h3 style="margin-top: 0; color: #16A085; font-size: 1.3em;">Battery Life Analysis</h3>
  
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 16px; margin-top: 16px;">
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #16A085;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Average Power</div>
      <div style="font-size: 1.8em; font-weight: bold;">${batteryCalculation.avgPowerMw.toFixed(2)} mW</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #E67E22;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Expected Battery Life</div>
      <div style="font-size: 1.8em; font-weight: bold;">${batteryCalculation.lifetimeDisplay}</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">${batteryCalculation.batteryLifeHours.toFixed(0)} hours total</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid ${batteryCalculation.techColor};">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Recommended Technology</div>
      <div style="font-size: 1.4em; font-weight: bold; color: ${batteryCalculation.techColor};">${batteryCalculation.techRecommendation}</div>
    </div>
  </div>
  
  <div style="margin-top: 20px; padding: 16px; background: rgba(22, 160, 133, 0.2); border-radius: 6px; border-left: 4px solid #16A085;">
    <strong style="color: #16A085;">💡 Key Insight:</strong> 
    ${batteryCalculation.batteryLifeYears >= 10 ? `With ${dutyCycle.toFixed(1)}% duty cycle and ${transmitPowerMw}mW transmit power, you achieve ${batteryCalculation.batteryLifeYears.toFixed(1)} years - ideal for remote agricultural or environmental monitoring using LoRaWAN.` : batteryCalculation.batteryLifeYears >= 1 ? `Battery life of ${batteryCalculation.lifetimeDisplay} is suitable for ${batteryCalculation.techRecommendation}. Consider reducing duty cycle or transmit power to extend lifetime.` : `Short battery life (${batteryCalculation.lifetimeDisplay}) requires frequent recharging or mains power. Wi-Fi consumes ${transmitPowerMw}mW at ${dutyCycle.toFixed(1)}% duty cycle - this is why agriculture uses LoRaWAN instead.`}
  </div>
</div>
`

15.11 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

Worked Example: Manufacturing Predictive Maintenance Data Volume

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 (raw): 17 GB/day x $0.10/GB = $1.70/day
• Cloud cost (edge-processed): 170 MB/day x $0.10/GB = $0.017/day
• Annual savings: $620/year vs. $6/year – a 100x cost reduction through edge processing!

Key Insight: High data volumes make edge computing economically necessary, not just technically optimal.

15.12 Interactive: Data Volume & Edge Processing Calculator

Calculate daily data volume and edge processing savings:

viewof samplingRateHz = Inputs.range(
  [1, 1000],
  {
    label: "Sampling Rate (Hz)",
    value: 100,
    step: 10,
    format: x => x < 10 ? `${x} Hz` : `${x} Hz (${x} samples/sec)`
  }
)

viewof numberOfSensors = Inputs.range(
  [1, 1000],
  {
    label: "Number of Sensors",
    value: 500,
    step: 10,
    format: x => x.toLocaleString()
  }
)

viewof bytesPerSample = Inputs.select(
  [1, 2, 4, 8, 16],
  {
    label: "Bytes per Sample",
    value: 4,
    format: x => `${x} bytes ${x === 4 ? '(float32)' : x === 2 ? '(int16)' : x === 8 ? '(float64)' : ''}`
  }
)

viewof edgeCompressionRatio = Inputs.range(
  [1, 200],
  {
    label: "Edge Processing Compression Ratio",
    value: 100,
    step: 10,
    format: x => `${x}:1 (${(100/x).toFixed(1)}% sent)`
  }
)

dataVolumeCalculation = {
  // Raw data calculation
  const bytesPerSecond = samplingRateHz * numberOfSensors * bytesPerSample;
  const bytesPerDay = bytesPerSecond * 86400;  // 86400 seconds per day
  
  // Convert to appropriate units
  const gbPerDay = bytesPerDay / (1024 * 1024 * 1024);
  const mbPerDay = bytesPerDay / (1024 * 1024);
  
  // Edge processed data
  const edgeProcessedBytesPerDay = bytesPerDay / edgeCompressionRatio;
  const edgeProcessedMbPerDay = edgeProcessedBytesPerDay / (1024 * 1024);
  
  // Cost calculation ($0.10 per GB standard cloud ingestion)
  const cloudCostPerGB = 0.10;
  const rawCloudCostPerDay = gbPerDay * cloudCostPerGB;
  const edgeCloudCostPerDay = (edgeProcessedBytesPerDay / (1024 * 1024 * 1024)) * cloudCostPerGB;
  const annualSavings = (rawCloudCostPerDay - edgeCloudCostPerDay) * 365;
  
  // Architecture recommendation
  let archRecommendation, archColor;
  if (gbPerDay > 10) {
    archRecommendation = "Edge Essential";
    archColor = "#E74C3C";
  } else if (gbPerDay > 1) {
    archRecommendation = "Edge Recommended";
    archColor = "#E67E22";
  } else if (mbPerDay > 100) {
    archRecommendation = "Edge or Cloud";
    archColor = "#3498DB";
  } else {
    archRecommendation = "Cloud Acceptable";
    archColor = "#16A085";
  }
  
  return {
    bytesPerSecond: bytesPerSecond,
    mbPerDay: mbPerDay,
    gbPerDay: gbPerDay,
    edgeProcessedMbPerDay: edgeProcessedMbPerDay,
    rawCloudCostPerDay: rawCloudCostPerDay,
    edgeCloudCostPerDay: edgeCloudCostPerDay,
    annualSavings: annualSavings,
    savingsMultiplier: edgeCompressionRatio,
    archRecommendation: archRecommendation,
    archColor: archColor
  };
}

html`
<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); padding: 24px; border-radius: 8px; color: white; margin: 20px 0;">
  <h3 style="margin-top: 0; color: #16A085; font-size: 1.3em;">Data Volume Analysis</h3>
  
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 16px; margin-top: 16px;">
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #16A085;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Raw Data Volume</div>
      <div style="font-size: 1.8em; font-weight: bold;">${dataVolumeCalculation.gbPerDay >= 1 ? `${dataVolumeCalculation.gbPerDay.toFixed(1)} GB/day` : `${dataVolumeCalculation.mbPerDay.toFixed(0)} MB/day`}</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">${(dataVolumeCalculation.bytesPerSecond/1024).toFixed(1)} KB/sec</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #E67E22;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">After Edge Processing</div>
      <div style="font-size: 1.8em; font-weight: bold;">${dataVolumeCalculation.edgeProcessedMbPerDay.toFixed(0)} MB/day</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">${edgeCompressionRatio}:1 compression</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #3498DB;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Annual Cloud Cost Savings</div>
      <div style="font-size: 1.8em; font-weight: bold;">$${dataVolumeCalculation.annualSavings >= 1000 ? (dataVolumeCalculation.annualSavings/1000).toFixed(1) + 'K' : dataVolumeCalculation.annualSavings.toFixed(0)}</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">$${dataVolumeCalculation.rawCloudCostPerDay.toFixed(2)}/day → $${dataVolumeCalculation.edgeCloudCostPerDay.toFixed(2)}/day</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid ${dataVolumeCalculation.archColor};">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Architecture</div>
      <div style="font-size: 1.4em; font-weight: bold; color: ${dataVolumeCalculation.archColor};">${dataVolumeCalculation.archRecommendation}</div>
    </div>
  </div>
  
  <div style="margin-top: 20px; padding: 16px; background: rgba(22, 160, 133, 0.2); border-radius: 6px; border-left: 4px solid #16A085;">
    <strong style="color: #16A085;">💡 Economic Impact:</strong> 
    ${dataVolumeCalculation.gbPerDay > 10 ? `At ${dataVolumeCalculation.gbPerDay.toFixed(1)} GB/day, edge processing saves $${(dataVolumeCalculation.annualSavings/1000).toFixed(1)}K annually by reducing cloud data transfer ${edgeCompressionRatio}x. This makes edge computing economically essential, not just technically optimal.` : dataVolumeCalculation.annualSavings > 100 ? `Edge processing reduces annual cloud costs by $${dataVolumeCalculation.annualSavings.toFixed(0)}, making the business case for edge infrastructure clear.` : `With only ${dataVolumeCalculation.mbPerDay.toFixed(0)} MB/day, cloud processing is economically viable. Edge computing would be for latency, not cost reasons.`}
  </div>
</div>
`

15.13 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.

15.14 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

15.15 Technology Selection Decision Tree

When selecting IoT technologies for a domain, follow this decision process:

IoT technology selection decision tree guiding choices based on latency, power, scale, and data volume requirements

Figure 15.4: IoT technology selection decision tree guiding choices based on latency, power, scale, and data volume requirements

The decision tree follows five key questions in sequence:

1. 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
2. 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
3. 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
4. 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

5. What’s the regulatory environment?
   • Healthcare/Automotive: Budget 2-3x timeline and cost
   • Industrial: Plan for OT security integration
   • Consumer: Standard compliance sufficient

Common Misconception: “One Size Fits All” IoT Solutions

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.

15.16 Requirements Trade-Off Map

Real-world IoT projects rarely satisfy all six dimensions optimally. Understanding common trade-off patterns helps engineers make informed compromises:

Common trade-off patterns in IoT domain requirements – optimizing one dimension often constrains another

Figure 15.5: Common trade-off patterns in IoT domain requirements – optimizing one dimension often constrains another

Understanding these trade-offs explains why no single IoT platform dominates every domain. Each application must decide which dimensions to prioritize and which to compromise on.

Common Pitfalls in Domain Requirements Analysis

Pitfall 1: Ignoring Worst-Case Latency Designers often specify average latency (e.g., “200ms average cloud round-trip”) but forget tail latency. A system averaging 200ms may spike to 2-5 seconds under load – catastrophic for industrial safety. Always specify P99 (99th percentile) latency, not just average.

Pitfall 2: Confusing Sensor Accuracy with System Accuracy A medical-grade temperature sensor rated at +/-0.1C still produces inaccurate readings if the signal conditioning, ADC resolution, or firmware rounding introduces errors. System-level accuracy must account for the entire measurement chain, not just the sensor datasheet.

Pitfall 3: Underestimating Battery Replacement Cost at Scale A 2-year battery life sounds acceptable until you deploy 10,000 sensors across a city. Replacing 5,000 batteries per year at $15 each (battery + labor) costs $75,000 annually. A 10-year battery at $5 more per sensor saves $350,000 over the deployment lifetime.

Putting Numbers to It

Compare two parking sensor options for a 10,000-sensor smart city deployment:

Option A: Wi-Fi-based sensor with 2-year battery

• Initial cost: $40/sensor = $400,000
• Battery replacement: $15/sensor × 5,000 sensors/year × 10 years = $750,000
• Total 10-year cost: $1,150,000

Option B: LoRaWAN sensor with 10-year battery

• Initial cost: $60/sensor = $600,000
• Battery replacement over 10 years: $0
• Total 10-year cost: $600,000

\[\text{Total Savings} = \$1,150,000 - \$600,000 = \$550,000\]

The lifetime savings from choosing the right power architecture: \(\$550,000 / 10,000 = \$55\) per sensor. This 48% cost reduction demonstrates why power source and battery life dominate TCO analysis for large-scale deployments.

Pitfall 4: Assuming Regulations Won’t Change IoT privacy regulations are evolving rapidly. The EU AI Act (2024), updated GDPR enforcement, and new US state privacy laws mean a consumer product launched today may face medical-device-level compliance requirements within 3-5 years. Build compliance hooks into your architecture from day one.

15.17 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.

15.18 Interactive: Domain Selection Scoring Calculator

Evaluate IoT projects using the weighted scoring framework:

viewof requirementsFit = Inputs.range(
  [0, 100],
  {
    label: "Requirements Fit (0-100)",
    value: 85,
    step: 5,
    format: x => `${x}/100`
  }
)

viewof costAlignment = Inputs.range(
  [0, 100],
  {
    label: "Cost Alignment (0-100)",
    value: 90,
    step: 5,
    format: x => `${x}/100`
  }
)

viewof complexityMatch = Inputs.range(
  [0, 100],
  {
    label: "Complexity Match (0-100)",
    value: 80,
    step: 5,
    format: x => `${x}/100`
  }
)

domainScoringCalculation = {
  const weights = {
    requirements: 0.50,  // 50%
    cost: 0.30,          // 30%
    complexity: 0.20     // 20%
  };
  
  const weightedRequirements = requirementsFit * weights.requirements;
  const weightedCost = costAlignment * weights.cost;
  const weightedComplexity = complexityMatch * weights.complexity;
  
  const totalScore = weightedRequirements + weightedCost + weightedComplexity;
  
  // Determine recommendation
  let recommendation, recommendationColor, recommendationDetail;
  if (totalScore >= 75) {
    recommendation = "Strong Candidate";
    recommendationColor = "#16A085";
    recommendationDetail = "Project aligns well across all dimensions. Proceed with detailed planning.";
  } else if (totalScore >= 60) {
    recommendation = "Proceed with Caution";
    recommendationColor = "#E67E22";
    recommendationDetail = "Some concerns exist. Conduct risk analysis before committing resources.";
  } else {
    recommendation = "Reconsider Approach";
    recommendationColor = "#E74C3C";
    recommendationDetail = "Significant misalignment. Consider alternative technologies or domain focus.";
  }
  
  // Identify weakest dimension
  const scores = [
    { name: "Requirements Fit", score: requirementsFit, weight: weights.requirements },
    { name: "Cost Alignment", score: costAlignment, weight: weights.cost },
    { name: "Complexity Match", score: complexityMatch, weight: weights.complexity }
  ];
  const weakest = scores.reduce((min, curr) => curr.score < min.score ? curr : min);
  
  return {
    weightedRequirements: weightedRequirements,
    weightedCost: weightedCost,
    weightedComplexity: weightedComplexity,
    totalScore: totalScore,
    recommendation: recommendation,
    recommendationColor: recommendationColor,
    recommendationDetail: recommendationDetail,
    weakestDimension: weakest.name,
    weakestScore: weakest.score
  };
}

html`
<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); padding: 24px; border-radius: 8px; color: white; margin: 20px 0;">
  <h3 style="margin-top: 0; color: #16A085; font-size: 1.3em;">Domain Selection Score</h3>
  
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 16px; margin-top: 16px;">
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #16A085;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Requirements Fit (50%)</div>
      <div style="font-size: 1.8em; font-weight: bold;">${requirementsFit}/100</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">Weighted: ${domainScoringCalculation.weightedRequirements.toFixed(1)} pts</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #E67E22;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Cost Alignment (30%)</div>
      <div style="font-size: 1.8em; font-weight: bold;">${costAlignment}/100</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">Weighted: ${domainScoringCalculation.weightedCost.toFixed(1)} pts</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid #3498DB;">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Complexity Match (20%)</div>
      <div style="font-size: 1.8em; font-weight: bold;">${complexityMatch}/100</div>
      <div style="font-size: 0.75em; opacity: 0.8; margin-top: 4px;">Weighted: ${domainScoringCalculation.weightedComplexity.toFixed(1)} pts</div>
    </div>
    
    <div style="background: rgba(255,255,255,0.1); padding: 16px; border-radius: 6px; border-left: 4px solid ${domainScoringCalculation.recommendationColor};">
      <div style="font-size: 0.85em; opacity: 0.9; margin-bottom: 4px;">Total Score</div>
      <div style="font-size: 2.2em; font-weight: bold; color: ${domainScoringCalculation.recommendationColor};">${domainScoringCalculation.totalScore.toFixed(1)}/100</div>
    </div>
  </div>
  
  <div style="margin-top: 20px; padding: 16px; background: rgba(${domainScoringCalculation.recommendationColor === '#16A085' ? '22, 160, 133' : domainScoringCalculation.recommendationColor === '#E67E22' ? '230, 126, 34' : '231, 76, 60'}, 0.2); border-radius: 6px; border-left: 4px solid ${domainScoringCalculation.recommendationColor};">
    <strong style="color: ${domainScoringCalculation.recommendationColor}; font-size: 1.2em;">${domainScoringCalculation.recommendation}</strong>
    <div style="margin-top: 8px; opacity: 0.95;">${domainScoringCalculation.recommendationDetail}</div>
    ${domainScoringCalculation.weakestScore < 70 ? `<div style="margin-top: 12px; padding-top: 12px; border-top: 1px solid rgba(255,255,255,0.2);"><strong>⚠️ Attention Needed:</strong> ${domainScoringCalculation.weakestDimension} scores only ${domainScoringCalculation.weakestScore}/100. Focus improvement efforts here.</div>` : ''}
  </div>
  
  <div style="margin-top: 16px; font-size: 0.85em; opacity: 0.8; padding: 12px; background: rgba(255,255,255,0.05); border-radius: 4px;">
    <strong>Scoring Guide:</strong> 75+ = Strong Candidate (proceed) | 60-75 = Proceed with Caution (risk analysis) | <60 = Reconsider (significant issues)
  </div>
</div>
`

15.19 Knowledge Check: IoT Domain Requirements

ikcModule = await import("https://iotclass.org/assets/js/inline-knowledge-checks.js")

KC_DomReq1 = {
  const question = {
    id: "domreq_latency_selection",
    question: "A startup is building an IoT system for autonomous drone delivery in urban areas. The drones must detect and avoid obstacles in real-time while navigating at 40 km/h. Which latency requirement and processing architecture is MOST appropriate?",
    options: [
      "Less than 1 second latency with cloud-based processing -- urban areas have good cellular coverage for fast cloud round-trips",
      "Less than 10 milliseconds latency with on-device edge computing -- obstacle avoidance at speed requires immediate local processing",
      "Less than 1 minute latency with LPWAN connectivity -- drones move slowly enough that delayed responses are acceptable",
      "Less than 50 milliseconds latency with a nearby fog computing node -- the drone can relay processing to ground stations"
    ],
    correctIndex: 1,
    difficulty: "intermediate",
    feedback: {
      correct: "Correct! At 40 km/h, the drone travels about 11 meters per second. A 10ms response time means the drone moves only 11 cm before reacting -- essential for obstacle avoidance. Cloud processing adds 50-200ms of network latency (0.5-2.2 meters of travel), which is too slow for collision avoidance. Edge computing on the drone itself is the only viable approach for safety-critical real-time decisions.",
      incorrect: "Not quite. At 40 km/h (11 m/s), the drone travels 11 cm in 10ms but over 1 meter in 100ms. Obstacle avoidance requires sub-10ms response, which only on-device edge computing can guarantee. Cloud processing adds 50-200ms network latency. Fog nodes add variable latency depending on distance. LPWAN latency (seconds) would be catastrophic. Safety-critical, real-time applications always require local edge processing."
    }
  };
  return ikcModule.createMultipleChoiceWidget(question);
}

KC_DomReq2 = {
  const question = {
    id: "domreq_power_technology",
    question: "A vineyard needs to deploy 500 soil moisture sensors across 200 hectares of remote farmland with no electrical infrastructure. Sensors report every 15 minutes. Which technology and power combination will achieve the LOWEST total cost of ownership over 5 years?",
    options: [
      "Wi-Fi sensors with solar panels -- Wi-Fi provides reliable data delivery and solar ensures unlimited power",
      "NB-IoT sensors with rechargeable batteries -- cellular coverage reaches rural areas and batteries can be swapped annually",
      "LoRaWAN sensors with long-life batteries (10-year) and 3-5 LoRaWAN gateways with solar power",
      "Zigbee mesh sensors with mains power run via buried cables -- mesh networking provides excellent coverage"
    ],
    correctIndex: 2,
    difficulty: "intermediate",
    feedback: {
      correct: "Correct! LoRaWAN is ideal for this scenario: (1) Long range (2-15 km) means 3-5 gateways cover 200 hectares, (2) ultra-low power consumption with 15-minute reporting enables 10-year battery life, (3) sensor cost is $30-50 each, (4) no per-device connectivity fees. Total 5-year cost: ~$25K sensors + $5K gateways + $0 connectivity = ~$30K. Wi-Fi would need 200+ access points ($100K+). NB-IoT adds $2-5/month per device ($60K-150K in connectivity alone). Buried cables for 200 hectares would cost $500K+.",
      incorrect: "Consider the full cost picture across 5 years for 500 sensors over 200 hectares. Wi-Fi range (50-100m) would need 200+ APs plus power infrastructure. NB-IoT cellular fees add $2-5/month per device ($60K-150K over 5 years). Zigbee mesh range (10-100m) would need thousands of relay nodes. LoRaWAN's combination of 2-15 km range (needing only 3-5 gateways), 10-year battery life, and zero per-device connectivity fees makes it the clear winner for large-scale agricultural deployments."
    }
  };
  return ikcModule.createMultipleChoiceWidget(question);
}

KC_DomReq3 = {
  const question = {
    id: "domreq_regulation_impact",
    question: "A company that makes consumer fitness trackers ($150 retail, 12-month development cycle) wants to pivot to medical-grade patient monitoring wearables. Which statement BEST describes the impact on their business model?",
    options: [
      "Minimal impact -- the same hardware can be repackaged with a medical label and sold at a higher price point",
      "Development timeline extends to 18-36 months, costs increase 200-500%, retail price rises to $500-2,000, but the addressable market and margins are significantly higher",
      "The only difference is adding HIPAA compliance to data handling -- the device hardware and software remain essentially the same",
      "The regulatory burden makes this pivot economically unviable for any company that is not already in the medical device industry"
    ],
    correctIndex: 1,
    difficulty: "advanced",
    feedback: {
      correct: "Correct! The pivot from consumer to medical-grade requires: FDA Class II device approval (12-24 months), clinical validation with IRB studies, HIPAA-compliant data handling, medical-grade accuracy (+/-0.1C vs 'best effort'), and product liability insurance. This increases development cost by 200-500% and timeline to 18-36 months. However, the medical device market commands $500-2,000 retail prices with higher margins, insurance reimbursement, and stronger customer retention. Many successful companies (like Apple with ECG features) have made this transition.",
      incorrect: "The transition from consumer wearable to medical device involves far more than just data compliance. FDA Class II approval alone requires 12-24 months and clinical trials. Hardware must meet medical-grade accuracy standards (+/-0.1C temperature, +/-2 bpm heart rate). HIPAA compliance requires end-to-end encryption and audit trails. Product liability exposure changes dramatically. However, this pivot IS economically viable -- medical devices command 3-10x higher prices, and many companies successfully transition. The key is budgeting 2-3x the timeline and cost."
    }
  };
  return ikcModule.createMultipleChoiceWidget(question);
}

KC_DomReq4 = {
  const question = {
    id: "domreq_data_volume_architecture",
    question: "A manufacturing plant has 500 vibration sensors sampling at 100 Hz (400 bytes/sec per sensor). Raw data totals 17 GB/day. Edge processing can reduce this to 170 MB/day by sending only anomalies. What is the PRIMARY reason to implement edge processing in this scenario?",
    options: [
      "Edge processing improves sensor accuracy by filtering noise before data reaches the cloud",
      "Edge processing reduces cloud storage and bandwidth costs by approximately 100x ($620/year vs $6/year), making the system economically viable at scale",
      "Edge processing is required because cloud platforms cannot handle 17 GB/day of data",
      "Edge processing eliminates the need for cloud infrastructure entirely, reducing architectural complexity"
    ],
    correctIndex: 1,
    difficulty: "intermediate",
    feedback: {
      correct: "Correct! The primary driver is economics. Cloud platforms can technically handle 17 GB/day, but the costs are prohibitive at scale: $620/year in cloud costs vs $6/year with edge processing -- a 100x reduction. For a plant with multiple production lines, this difference scales to tens of thousands of dollars annually. Edge processing also reduces bandwidth requirements (from 200 KB/sec to 2 KB/sec), enabling less expensive network infrastructure. While edge processing can also improve latency for real-time alerts, the economic argument is what makes the business case.",
      incorrect: "Think about this from a business perspective. Cloud platforms absolutely can handle 17 GB/day -- major cloud providers handle petabytes daily. Edge processing doesn't eliminate cloud needs; you still need cloud for historical analysis, dashboards, and cross-plant comparisons. The primary driver is economics: sending 17 GB/day to the cloud costs ~$620/year per production line, while edge-processed 170 MB/day costs only ~$6/year -- a 100x reduction that makes predictive maintenance economically viable across hundreds of sensors."
    }
  };
  return ikcModule.createMultipleChoiceWidget(question);
}

KC_DomReq5 = {
  const question = {
    id: "domreq_scale_architecture",
    question: "A university campus is deploying IoT sensors for energy management across 30 buildings with approximately 2,000 total sensor points (temperature, occupancy, lighting, HVAC). Which deployment scale category does this fall into, and what is the MOST appropriate network architecture?",
    options: [
      "Home scale -- use consumer Wi-Fi routers in each building with a cloud dashboard",
      "Building scale -- deploy a single building management system with wired sensors in the main building only",
      "Campus scale -- dedicated network infrastructure with LoRaWAN gateways or enterprise Wi-Fi, centralized gateway management, and a building management platform",
      "City scale -- deploy NB-IoT cellular sensors to avoid campus network infrastructure costs"
    ],
    correctIndex: 2,
    difficulty: "intermediate",
    feedback: {
      correct: "Correct! With 2,000 sensors across 30 buildings, this is firmly in the campus scale (500-5,000 devices). Campus deployments need: dedicated network infrastructure (enterprise Wi-Fi or LoRaWAN gateways covering all buildings), centralized management for gateway/sensor fleet, professional installation, and a building management platform for cross-building analytics. Consumer Wi-Fi would lack the management capabilities. A single building system wouldn't cover 30 buildings. NB-IoT would add unnecessary per-device cellular costs when campus infrastructure can be deployed once.",
      incorrect: "Consider the scale: 2,000 sensors across 30 buildings. This maps to the campus tier (500-5,000 devices). Home-scale solutions (consumer Wi-Fi) lack fleet management for 2,000 devices across 30 locations. Building-scale approaches only cover one building. City-scale NB-IoT adds per-device cellular fees ($2-5/month x 2,000 = $4K-10K/month) when the university can deploy its own LoRaWAN gateways or use existing enterprise Wi-Fi infrastructure for a one-time cost. Campus scale requires dedicated but self-managed network infrastructure."
    }
  };
  return ikcModule.createMultipleChoiceWidget(question);
}

Worked Example: Calculating True 5-Year Total Cost of Ownership for LoRaWAN vs. NB-IoT

Scenario: A city plans to deploy 10,000 smart parking sensors across downtown. They must choose between LoRaWAN (private network) and NB-IoT (carrier network).

Given:

LoRaWAN Option:

• Sensor hardware: $185/unit (includes LoRa radio, magnetic sensor, 10-year battery)
• Gateways needed: 25 gateways at $2,400 each (covers 5 km² city center)
• Gateway installation: $800 per gateway (mounting, power, networking)
• Network server license: $12,000/year (self-hosted)
• No per-device connectivity fees (unlicensed spectrum)
• Maintenance: 2% sensor replacement annually, 5% gateway failures

NB-IoT Option:

• Sensor hardware: $165/unit (includes NB-IoT modem, magnetic sensor, 10-year battery)
• Connectivity: $3/device/month (carrier subscription, includes data allowance)
• No gateway infrastructure needed (uses existing cellular towers)
• Cloud platform: $8,000/year (carrier-provided management)
• SIM management fees: $0.50/device/year
• Maintenance: 2% sensor replacement annually

Step 1: Initial Capital Expenditure (Year 0)

LoRaWAN:

• Sensors: 10,000 × $185 = $1,850,000
• Gateways: 25 × $2,400 = $60,000
• Gateway installation: 25 × $800 = $20,000
• Network server setup: $15,000 (one-time)
• Total CapEx: $1,945,000

NB-IoT:

• Sensors: 10,000 × $165 = $1,650,000
• No infrastructure needed
• Total CapEx: $1,650,000

Initial advantage: NB-IoT saves $295K upfront

Step 2: Annual Operating Costs (Years 1-5)

LoRaWAN (per year): - Network server license: $12,000 - Sensor replacements (2%): 200 × $185 = $37,000 - Gateway replacements (5%): 1.25 × $2,400 = $3,000 - Network maintenance: $8,000 (monitoring, updates) - Power/connectivity for gateways: 25 × $300/year = $7,500 - Annual OpEx: $67,500

NB-IoT (per year): - Connectivity: 10,000 × $3/month × 12 = $360,000 - SIM management: 10,000 × $0.50 = $5,000 - Cloud platform: $8,000 - Sensor replacements (2%): 200 × $165 = $33,000 - Annual OpEx: $406,000

Step 3: 5-Year Total Cost of Ownership

LoRaWAN:

• Initial: $1,945,000
• 5 years operations: $67,500 × 5 = $337,500
• 5-Year TCO: $2,282,500

NB-IoT:

• Initial: $1,650,000
• 5 years operations: $406,000 × 5 = $2,030,000
• 5-Year TCO: $3,680,000

Result: LoRaWAN saves $1,397,500 over 5 years (38% lower TCO)

Step 4: Breakeven Analysis

When does LoRaWAN’s higher upfront cost pay off?

Annual savings: $406,000 (NB-IoT OpEx) - $67,500 (LoRaWAN OpEx) = $338,500/year

Payback period: $295,000 (upfront difference) / $338,500 (annual savings) = 0.87 years (10.4 months)

LoRaWAN breaks even in under 11 months, then saves $338K annually thereafter.

Step 5: Sensitivity Analysis

What if NB-IoT carrier fees drop to $1.50/device/month?

New NB-IoT annual OpEx: - Connectivity: 10,000 × $1.50 × 12 = $180,000 - Other costs: $46,000 - New annual: $226,000

5-year NB-IoT TCO: $1,650K + ($226K × 5) = $2,780,000

LoRaWAN still wins, saving $497,500 (18% lower)

What if deployment scales to 50,000 sensors?

LoRaWAN (50K sensors, 100 gateways): - Initial: 50K × $185 + 100 × $2,400 + 100 × $800 = $9,570,000 - 5-year ops: ($12K + 185K + 12K + 8K + 30K) × 5 = $1,235,000 - 5-year TCO: $10,805,000

NB-IoT (50K sensors): - Initial: 50K × $165 = $8,250,000 - 5-year ops: ($1.8M + 25K + 8K + 165K) × 5 = $9,990,000 - 5-year TCO: $18,240,000

At scale, LoRaWAN advantage increases to $7.4M (41% lower TCO)

Step 6: Additional Considerations

LoRaWAN Benefits:

• Data sovereignty: City owns all data, no carrier access
• No ongoing fees: Budget predictability, immune to carrier price increases
• Customization: Can modify network parameters, add features
• Resilience: Works during cellular outages
• Expansion: Can add more sensor types (air quality, waste, etc.) using same gateways

LoRaWAN Risks:

• Requires in-house RF expertise for troubleshooting
• City responsible for network uptime (no carrier SLA)
• Gateway hardware lifecycle (replace every 7-10 years)

NB-IoT Benefits:

• Zero infrastructure deployment: Faster time to value
• Carrier SLA: Guaranteed uptime, professional support
• Better building penetration: Works in underground parking
• Easier procurement: No RF expertise required

NB-IoT Risks:

• Carrier lock-in: Switching carriers requires replacing all SIMs
• Recurring fees subject to price increases (3-5% annually typical)
• Sunset risk: If carrier ends NB-IoT service, must replace all sensors
• Data flows through carrier infrastructure

Decision Recommendation:

Choose LoRaWAN when:

• Deployment >5,000 devices (economies of scale)
• Long-term project (5+ years)
• City has IT team capable of managing infrastructure
• Data sovereignty is important
• Want to expand to multiple sensor types using same infrastructure

Choose NB-IoT when:

• Deployment <2,000 devices (LoRaWAN infrastructure cost not justified)
• Short-term pilot (1-3 years)
• No in-house RF expertise
• Need fast deployment (no infrastructure setup time)
• Coverage includes underground/indoor areas where LoRa struggles

For this 10,000-sensor parking deployment: LoRaWAN is the clear winner, breaking even in 11 months and saving $1.4M over 5 years, with additional benefits of data sovereignty and multi-use infrastructure.

Key Takeaway: Per-device costs look attractive (NB-IoT $3/month seems cheap), but multiply by device count and time period to reveal true TCO. At city scale (5K+ devices, 5+ years), private LPWAN networks like LoRaWAN deliver 30-40% TCO savings despite higher upfront investment.

15.20 Concept Check: IoT Domain Requirements

Concept Check: Requirement Trade-Offs

15.21 See Also

Explore how different domains apply these requirement principles:

• Smart Cities - 80% sensor coverage threshold and LoRaWAN vs NB-IoT trade-offs for city-scale deployments
• Smart Agriculture - 10-year battery life requirements drive LoRaWAN adoption over cellular
• Healthcare IoT - 99.99% reliability and FDA compliance add 200-500% to development costs
• Transportation & V2X - <10ms latency requirement for vehicle collision avoidance

Interactive Quiz: Match Requirement Dimensions

Interactive Quiz: Sequence Domain Requirement Analysis

Label the Diagram

💻 Code Challenge

15.22 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

In 60 Seconds

This chapter covers domain selection, explaining the core concepts, practical design decisions, and common pitfalls that IoT practitioners need to build effective, reliable connected systems.

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.

15.23 What’s Next

Chapter	Description
Smart Cities	Urban infrastructure at scale with 80% coverage thresholds
Smart Agriculture	Remote, battery-powered deployments with LoRaWAN
Healthcare IoT	High-reliability, FDA-regulated environments
Smart Manufacturing	Real-time, high-data-volume industrial systems