Smart Places and Infrastructure · Study deck
IoT Domain Requirements: Latency, Scale, and Power
This first route turns domain differences into latency, downtime, scale, availability, and battery calculations that can shape a system boundary.
Ada is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: 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.
- Explain: The envelope names the decision the IoT system supports, the constraints that are tight, the constraints that are flexible, and the trade-off that would make the application unsafe, unaffordable, or unmaintainable.
- Explain: Five percent of a 365-day year is 18.25 days, which matches the roughly 18 days shown for the first target; four nines permit only about 52 minutes.
Major section
Start With the Story
A hospital wants a warning before a patient is harmed.
- The same feature list cannot prove all three jobs.
- Latency means the time from an event to the result that needs it: The hospital may need a short limit for an alarm.
- The farm may accept a later soil report.
- If delay is hardest, load the shared path.
Major section
Start With the Story (continued)
Bandwidth means how much data a link can carry in a given time: Count message size, send rate, device count, bursts, updates, and retries.
- A calm average can hide the hour when every unit reports at once.
- A protocol is an agreed set of rules for an exchange.
- Practitioner builds the scorecard and cost tests.
Major section
Start With the Story (continued)
A familiar name is not evidence that the rules fit the site.
- For a control action, say what safe state remains when the result is unknown.
- A cheap part may create costly review or service work.
- It should list outcome, scale, place, power, time, data, loss, safety, privacy, support, cost, owner, and rejection test.
Major section
Start With the Story (continued)
The tightest limit will often rule out a tempting choice.
- If battery life is hardest, measure the worst radio day.
- If audit proof is hardest, trace one fact and one action from source to record.
- Reopen the envelope when the site, rule, device count, software, or service promise changes.
Major section
Start With the Story (continued)
A design that fits one domain today may not fit a wider job next year.
- If they choose a different limit, find the missing fact before buying parts.
- Both should see the same claim, limit, and next test.
- If their views differ, fix the promise before the plan grows.
Major section
Minimum Viable Understanding
Constraint-Driven Elimination: The requirement with the tightest constraint (often power or regulation) can eliminate technology options and narrow the viable choices.
- 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: Choosing technology before requirements can derail a project.
- Cost of Reliability: Higher availability can require redundancy, monitoring, tested recovery, and additional staffing.
Major section
The Requirements Challenge
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.
- Not all jobs are the same -- and neither are sensors!
- Thermo needs to be super reliable.
- Hydro needs a super long battery.
Major section
The Requirements Challenge (continued)
The Sensor Squad just got THREE new missions -- but each one needs completely different tools!
- And Mo needs to be super FAST.
- 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.
- Different jobs need different levels of speed and reliability!
Major section
Domains Turn Ideas Into Constraints
The practical tool in this chapter is a requirement envelope.
- A domain requirement is a boundary condition, not a preference.
- A few seconds of delay in a smart-home leak alert may be acceptable if the device has multi-year battery life.
- That discipline makes later technology choices defensible instead of accidental.
Major section
Domains Turn Ideas Into Constraints (continued)
The same delay in an industrial safety interlock or clinical alarm can be unacceptable because the user expects a local, auditable, fail-safe response.
- The envelope names the decision the IoT system supports, the constraints that are tight, the constraints that are flexible, and the trade-off that would make the application unsafe, unaffordable, or unmaintainable.
- If a requirement is tight, the design needs evidence: a latency budget, a battery calculation, a site survey, a retention rule, a failover test, or a maintenance plan.
- If a requirement is flexible, the design should say what flexibility is being used to reduce cost or complexity.
Major section
Tightest Constraint Wins
A hospital monitor may eliminate best-effort connectivity before cost optimization matters because missed identity, delayed escalation, or unclear alarm ownership can create clinical risk.
- Reliability should name what happens during packet loss, gateway outage, drained battery, sensor fault, or unavailable cloud service.
- Data should name sample rate, units, timestamp source, quality flags, retention, aggregation, and whether raw data or events must be preserved.
- End the practitioner pass with evidence tests.
Major section
Tightest Constraint Wins (continued)
Wi-Fi may suit mains-powered indoor devices with existing site networks, but provisioning and IT approval can dominate deployment.
- Regulation and governance should name consent, tenant boundaries, audit logs, export controls, privacy reviews, or safety evidence when those apply.
- LoRaWAN Class A can be attractive for low-rate, battery-powered field sensors, but it limits downlink behavior and payload size.
- If the technology survives the test tied to the domain decision, it is a candidate.
Major section
Tightest Constraint Wins (continued)
NB-IoT or LTE-M can remove gateway ownership for wide-area assets, but carrier coverage, SIM lifecycle, and recurring cost become requirements.
- BLE may fit phone-assisted setup or local wearables, while Ethernet may fit industrial panels where power and cabling are available.
- MQTT, CoAP, HTTPS, OPC UA, and MQTT Sparkplug are not interchangeable labels; each brings different assumptions about message delivery, semantics, tooling, and integration.
- A good envelope points to a site survey, link-budget check, battery calculation, protocol trace, environmental test, accessibility review, security review, pilot success metric, or support drill.
Major section
Requirement Envelopes as Contracts · Radio Remi's Math Bridge: Band Choice and Reporting Duty
The deeper reason domain requirements matter is that they assign responsibility across the system.
- A latency requirement decides what must run on the device, gateway, edge server, cloud service, and user interface.
- A reliability requirement decides redundancy, watchdogs, monitoring, queueing, retry limits, idempotency, and failover.
Major section
The Healthcare vs Agriculture Comparison
Criticality: Life-threatening if measurement is missed or inaccurate.
- Accuracy required: +/-1C (frost threshold is approximately 0C).
- Cost tolerance: <$50 per sensor (need hundreds, agriculture has tight margins).
- Latency spans a millisecond to an hour, so fast enough means nothing until the domain names its own limit.
Major section
Latency and Response Time
As the physical process changes more slowly, the response budget relaxes and cloud processing becomes more plausible.
- Tight safety loops stay local; tolerant monitoring can trade delay for wider aggregation and simpler operations.
- Industrial robotics: Under 50 ms because precise assembly operations require real-time coordination.
Major section
Latency and Response Time (continued)
Building automation: Under 1 second because HVAC response and lighting adjustments need to feel immediate to users.
- Smart agriculture: Under 1 minute because irrigation decisions are based on slowly changing soil conditions.
- Environmental monitoring: Under 1 hour because weather and air quality change gradually over time.
- Key Insight: A 100 ms delay is catastrophic for autonomous vehicles but completely acceptable for environmental monitoring.
Major section
Downtime Cost Spectrum · Reliability Cost Reasoning
Five percent of a 365-day year is 18.25 days, which matches the roughly 18 days shown for the first target; four nines permit only about 52 minutes.
- The consequences also change, from recoverable inconvenience to traffic disruption or patient harm.
- The lower downtime is not bought as a percentage.
Deck summary
Key takeaways
A hospital wants a warning before a patient is harmed.
- Bandwidth means how much data a link can carry in a given time: Count message size, send rate, device count, bursts, updates, and retries.
- A familiar name is not evidence that the rules fit the site.
- The tightest limit will often rule out a tempting choice.
- A design that fits one domain today may not fit a wider job next year.
Retrieval practice
Recall check
Ada says: answer from memory, then check your reasoning.
Q1A hospital monitoring service has a 99.99% availability target, while a farm irrigation service has a 95% target and a $50,000 baseline design. What can the team conclude about the hospital service's infrastructure cost from these facts alone?
Show answer
Answer: B Availability percentages do not determine cost.
Print reference
Answers
Answer key.
- B · Availability percentages do not determine cost.