Applications & Use Cases · 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.
Blueprint Bina is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: 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.
- 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: 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
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
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
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.
- The test is not whether the page still draws a chart.
Major section
Requirement Envelopes as Contracts (continued)
If a factory interlock must act locally, the cloud may only record evidence after the fact.
- A regulation requirement decides identity, logging, retention, consent, deletion, audit boundaries, and who can view or export data.
- Without that allocation, the architecture may look complete while nobody owns the requirement when the deployment fails.
- If a parking sensor can tolerate minutes, the design may batch messages to save power.
Major section
Requirement Envelopes as Contracts (continued)
Healthcare or regulated deployments may need patient or device identity matching, audit logs, and retention rules before data can enter clinical or compliance workflows.
- The user-facing number is not a single network measurement; it is the sum of sensor sampling, firmware filtering, radio wake time, gateway processing, broker delivery, stream processing, notification, and human response.
- MQTT QoS can reduce message-loss risk, but it does not prove that the sensor was calibrated, the unit is correct, the timestamp is trustworthy, or the command is safe to retry.
- If the design still holds under those conditions, the technology choice is defensible.
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).
- That labelled limit reconnects the visual to the healthcare vs agriculture comparison.
Major section
Latency and Response Time
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.
Major section
Downtime Cost Spectrum · Reliability Cost Reasoning
That sequence keeps downtime cost spectrum tied to what is visibly labelled.
- The cost multipliers shown are also assumptions for a hypothetical design exercise.
- Real targets and costs come from the service's harm model, operating window, failure dependencies, recovery time, staffing, and supplier commitments.
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
Blueprint Bina 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: C Availability percentages do not determine cost.
Print reference
Answers
Answer key.
- C · Availability percentages do not determine cost.