8  IoT Requirements and Characteristics

8.1 Start With the Story

Begin with a device idea that sounds useful until someone asks how it will be powered, reached, secured, updated, and trusted. This chapter turns IoT enthusiasm into requirements evidence: the system must keep its promise across the physical environment, network path, data model, and operations workflow.

Chapter Roadmap

This chapter moves from a quick classification test into a design checklist:

1. First use the Three Ingredients Test to separate embedded, connected, and full IoT products.
2. Then translate useful-sounding qualities into measurable requirements across the five-layer architecture.
3. Next compare connectivity choices with the warehouse TCO example instead of choosing a radio by habit.
4. After that prioritize the eleven IoT characteristics by domain, because no system can excel at all of them.
5. Finally use the quizzes and scoring exercises to defend a product decision with evidence.

Checkpoints recap what you have covered, and “Deep dive” material is there when you want the supporting arithmetic or architecture detail.

8.2 Learning Objectives

By the end of this chapter, you will be able to:

• Explain IoT architecture: Describe the complete data flow through the five IoT system layers from sensor to application
• Apply minimum requirements: Identify and verify the three essential components every IoT device must have using the Three Ingredients Test
• Evaluate IoT characteristics: Assess IoT systems against eleven ideal characteristics and assign priority weights by domain
• Select appropriate technologies: Compare connectivity options (Wi-Fi, LoRaWAN, cellular) and justify choices based on application requirements

8.3 Related Chapters and Resources

IoT Overview Series:

• IoT Introduction - Getting started with IoT and the Five Verbs
• IoT Perspectives and Definitions - Different stakeholder views on IoT
• Device Evolution - Embedded vs Connected vs IoT products
• IoT History and Paradigm Shifts - Lessons from technology evolution

Deep Dive Chapters:

• Application Domains - Industry-specific IoT applications
• IoT Use Cases - Real-world implementation examples

Learning Hubs:

• Concept Navigator - Test your understanding
• Simulation Playground - Interactive tools
• Video Gallery - Visual learning resources

8.4 Prerequisites

This chapter assumes you have read IoT Introduction or have basic familiarity with what IoT means. No technical background is required.

8.5 Quick Mental Model

Use two passes whenever you evaluate a product:

1. Three Ingredients Test: Is there a physical thing, embedded computation, and internet reach, directly or through a gateway?
2. Characteristics Test: Once it qualifies as IoT, which 3-4 of the eleven qualities matter most for this domain?

• Qualification: Ask whether the product has a thing, computation, and internet reach. A timer microwave fails here because it is embedded; a Bluetooth-only lock is connected, but not full IoT.
• Quality: Ask which characteristics must be strongest for the use case. A farm sensor optimized for millisecond response while ignoring battery life is solving the wrong problem.
• Architecture: Ask where sensing, filtering, networking, and decisions should happen. Streaming everything raw to the cloud raises latency, cost, and fragility.

Fast classification examples:

• Timer microwave: Thing + computation, but no internet reach -> Embedded device
• Bluetooth lock: Thing + computation + local wireless, but no internet reach -> Connected product
• Soil sensor with LoRaWAN gateway: Thing + computation + gateway path to cloud -> IoT device

This framing keeps the chapter disciplined: first decide whether something qualifies as IoT, then decide whether it is good IoT for the job.

8.6 Minimum Viable Understanding

• Three ingredients define IoT: A physical thing, embedded computation, and internet connectivity. If any one is missing, the device is not IoT – it may be embedded (no connectivity) or connected (no internet reach), but not IoT.
• Eleven characteristics separate good from great: Ubiquitous, Smart, Agile, On Demand, Blend into Background, Secure, Low Maintenance, Fast, Upgradable, Growing, and Adaptable are quality benchmarks. No device excels at all eleven; prioritize 3-4 for your domain.
• Requirements drive technology, not the reverse: Start with application constraints (range, power budget, update frequency, environment) and select connectivity technology accordingly. Wi-Fi suits high-bandwidth local devices; LoRaWAN suits long-range battery-powered sensors; cellular suits mobile assets.

8.7 Make Classification Testable

The Three Ingredients Test is a requirement filter, not a vocabulary exercise. A product qualifies as IoT only when the physical thing, local computation, and internet reach work together to support a useful data or control loop. The test forces you to name the asset, the embedded logic, and the path that carries telemetry, commands, alerts, configuration, or updates beyond the local environment.

Figure 8.1: The minimum IoT requirement is the combined presence of a physical thing, local computation, and direct or gateway-mediated internet reach.

A Bluetooth-only lock may be connected, but it is not the same requirement set as a lock that reaches a cloud service through a Wi-Fi bridge or integrated Wi-Fi radio. A LoRaWAN soil sensor may qualify through a gateway even though the sensor itself never opens a TCP connection. A factory vibration sensor may reach a historian through an edge gateway and still count as IoT if the end-to-end path supports remote visibility or action. The requirement is the service path, not a specific radio.

Classification is only the first pass. The second pass asks whether the device is good IoT for its job. A smart thermostat, cold-chain tracker, irrigation valve, medication dispenser, and fleet sensor all satisfy the three ingredients, but their strongest characteristics differ. A cold-chain tracker may prioritize battery life, location coverage, tamper evidence, and data retention. A thermostat may prioritize local control, comfort, update safety, and household privacy. A fleet sensor may prioritize mobility, cellular roaming, ruggedness, and remote diagnostics.

• Thing: Name the physical asset, installation point, user, operating environment, enclosure limits, and expected lifetime.
• Computation: Name the local logic that samples, filters, stores, controls, protects, compresses, or signs device data.
• Internet reach: Name the direct or gateway-mediated path that carries data, commands, updates, or alerts beyond the local link.
• Usefulness: Name the action, decision, maintenance task, safety response, or service workflow that changes because the device is connected.

This framing prevents technology-first design. You do not choose Wi-Fi, LoRaWAN, cellular, MQTT, or a cloud platform because it sounds modern. You choose the weakest acceptable combination that still satisfies range, power, latency, security, maintenance, data-quality, and user-experience requirements.

8.8 Make Requirements Measurable

After classification, the practical work is to turn desirable qualities into measurable design constraints. “Low maintenance” becomes battery access, enclosure sealing, calibration interval, replacement process, spare-device handling, and OTA update policy. “Fast” becomes latency budget, sampling rate, queue behavior, command timeout, and local fallback. “Secure” becomes provisioning, credential storage, access control, audit logging, firmware signing, and revocation. The words are only useful when they become testable acceptance criteria.

Connectivity choices then become easier to defend. Wi-Fi fits mains-powered devices with local bandwidth and installation support. Thread or Zigbee may fit home and building meshes where a border router is acceptable. BLE can work for phone-assisted setup, short-range sensing, or local wearables. LoRaWAN fits small, infrequent telemetry over long range when downlink limits are acceptable. LTE-M or NB-IoT may fit wide-area assets when gateway ownership is impractical and the business model can carry subscription cost.

Write each requirement as a budget, threshold, or operational rule. A cold-chain sensor might require temperature samples every five minutes, upload within fifteen minutes when coverage exists, buffer seventy-two hours offline, survive washdown, rotate credentials on ownership transfer, and preserve audit records for a defined retention period. A smart-home lock might require local unlock when the cloud is down, revocation within minutes, low-battery warning before failure, and a clear household recovery path. These statements are design inputs, not after-the-fact documentation.

1. Prioritize characteristics. Pick the few qualities that matter most for the domain instead of claiming all eleven equally. Record the tradeoff you are accepting.
2. Translate each quality. Write a measurable requirement for power, latency, data freshness, update rate, range, identity, maintenance, recovery, privacy, and support.
3. Check the tradeoff. Confirm which requirement worsens when another improves, such as lower latency versus battery life, higher sample rate versus data cost, or stronger authentication versus setup friction.
4. Attach a verification method. Decide whether the evidence comes from a bench test, field trial, protocol trace, security review, battery calculation, accessibility check, or support drill.
5. Keep the requirement alive. Revisit assumptions when the deployment moves from prototype to pilot, from pilot to fleet, or from one domain to another.

8.9 Requirements Cross the Five Layers

A requirement usually touches more than one architecture layer. A freshness requirement may need a sensor timestamp, device clock behavior, gateway buffering rule, MQTT or HTTPS message policy, cloud ingestion timestamp, application stale-data label, and operator response rule. Treating freshness as a dashboard label alone leaves the system ambiguous. The physical layer, edge layer, connectivity layer, cloud layer, and application layer all need a share of the requirement.

The same applies to recovery. A device may need local safe behavior when the radio is down, a gateway may need store-and-forward queues, the cloud may need idempotent command handling, and the app may need to show whether a command is pending, applied, rejected, expired, or unsafe to retry. Without those rules, a retry storm, duplicated command, stale reading, or silent offline device can look like normal operation until the user notices the failure.

Identity requirements also cross layers. Manufacturing may assign a device identifier and certificate. Provisioning may bind the device to an owner, site, room, vehicle, patient, or asset. The gateway may authorize which devices can join. The cloud may map device identity to tenant identity and permissions. The application may expose ownership transfer and decommissioning. If any step is vague, support teams cannot safely replace, resell, retire, or investigate the device.

Data semantics are the other hidden dependency. Units, timestamp source, calibration state, location precision, firmware version, quality flags, and command meaning must be defined before analytics or automation use the data. A temperature value in Celsius, sampled inside an enclosure, averaged over one minute, and marked stale has a different meaning from an instant probe reading in Fahrenheit. Requirements make those meanings explicit.

• Identity: Define provisioning, authentication, authorization, ownership transfer, credential rotation, and decommissioning before field rollout.
• Semantics: Define units, timestamps, quality flags, calibration state, device state, and command meaning before building analytics or automation.
• Reliability: Define offline behavior, buffering, retry limits, duplicate handling, command expiry, and safe local behavior for each failure mode.
• Observability: Define logs, counters, health checks, trace ids, fleet reports, and alert thresholds for each layer that can fail.

Checkpoint: Requirements as Evidence

You now know:

• The minimum IoT filter has three ingredients: a physical thing, embedded computation, and internet reach.
• After qualification, quality means choosing the right 3-4 characteristics for the domain, not claiming all eleven equally.
• Requirements must cross the physical, edge, connectivity, cloud, and application layers so identity, semantics, reliability, and observability stay testable.

The next section restates the formal IoT definition, then turns it into examples and checks. Keep the evidence habit from the checkpoint: name the thing, name the computation, and name the internet path.

8.10 What is Internet of Things (IoT)

Time: ~10 min | Level: Foundational | ID: P03.C01.U03

Key Concepts

• Three Ingredients Test: Simple filter for deciding whether a product qualifies as IoT: physical thing, embedded computation, and internet reach.
• Gateway Distinction: Local wireless is not the same as internet connectivity; many products remain merely connected unless a gateway gives them remote reach.
• Five-Layer Architecture: Teaching model that separates physical devices, edge logic, connectivity, cloud functions, and applications.
• Characteristic Prioritization: The eleven qualities of strong IoT systems are design goals that must be weighted differently by domain.
• Requirements-Driven Connectivity: Range, power budget, update rate, and environment should drive protocol choice rather than familiarity or hype.
• Trade-off Mapping: Strong IoT design means making the right compromises explicitly instead of optimizing every quality equally.

8.11 Definition

The Internet of Things (IoT) is the concept of connecting everyday physical objects to the internet. These objects can range from household appliances to industrial machinery, enabling them to collect, exchange, and act upon data. IoT bridges the physical and digital worlds, making our environments smarter and more responsive.

Simple Definition: At its core, the Internet of Things refers to the interconnection of physical devices with the internet. This connectivity allows these devices to communicate with each other and with users, often improving functionality and efficiency.

Diverse Interpretations: Various researchers and institutions define IoT in slightly different ways. While these definitions may vary, the central idea remains consistent - IoT is about connectivity and data sharing. Importantly, there is no universally “right” or “wrong” definition.

Figure 8.2: IoT ecosystem framework adapted from the Edinburgh Design Course.

8.12 How IoT Works: The Complete Flow

Beginner-Level View: Four Simple Steps

Figure 8.3: Four-step IoT value loop: sense, connect, process, and act.

Real Example - Smart Thermostat:

1. Sense: Temperature sensor reads 65F (you set target to 72F)
2. Connect: Thermostat sends data to cloud via Wi-Fi
3. Process: Cloud compares 65F vs 72F, decides “too cold”
4. Act: Cloud sends command to turn on heater + alerts your phone

This cycle repeats continuously, keeping your home comfortable automatically!

8.13 Examples of IoT Devices

Figure 8.4: Everyday objects that can become IoT devices.

Figure 8.5: Framework for redesigning everyday objects into connected IoT products.

Together, these examples show the same pattern repeating across domains: start with a physical object, add sensing and computation, then give it a reliable path into a larger digital workflow.

• Plug: A smart plug can be controlled remotely to turn devices on and off.
• Microwave: A connected microwave can be programmed via a smartphone.
• Washing machine: A smart washing machine monitors energy use and sends notifications when cycles are complete.
• Coffee machine: A coffee machine can be scheduled to brew automatically at specific times.
• Truck: A connected truck uses sensors to track location, fuel efficiency, and maintenance needs.
• Recycling bin: A smart bin monitors waste levels so collection routes can be optimized.

IoT has become a foundational technology in various fields, transforming how we live and work by making systems more intelligent and interconnected.

8.14 Knowledge Check: IoT Fundamentals

Question 1: A traditional coffee maker with a timer that you program by pressing buttons on the device itself is:

1. An IoT device because it has computation (timer chip)
2. A connected device because it can be scheduled
3. An embedded device because it lacks internet connectivity
4. A smart device because it makes coffee automatically

Reveal Answer Answer: c) An embedded device because it lacks internet connectivity

Explanation: The coffee maker has a physical thing (the machine) and computation (timer chip), but it lacks internet connectivity. Without all three ingredients, it cannot be classified as IoT. It’s an embedded device - a device with built-in computing that operates independently without network connection.

Key Distinction:

• Embedded: Physical thing with local computation, but no meaningful network path
• Connected: Physical thing with computation and local-only communication
• IoT: Physical thing with computation and internet reach, directly or through a gateway

Question 2: In the IoT data flow cycle (Sense -> Connect -> Process -> Act), which step is responsible for making intelligent decisions?

1. Sense - the sensors analyze the data
2. Connect - the network routes decisions
3. Process - the cloud/edge analyzes data and determines actions
4. Act - the actuators decide what to do

Reveal Answer Answer: c) Process - the cloud/edge analyzes data and determines actions

Explanation: In the four-step IoT cycle: - Sense: Collects raw data (no decision-making) - Connect: Transmits data (no decision-making) - Process: Analyzes data, applies business logic, makes decisions - Act: Executes the decisions made during processing

The intelligence lives in the Process layer, whether that’s in the cloud, at the edge, or a combination of both.

Question 3: A smart recycling bin with fill-level sensors that sends data to optimize collection routes is an example of IoT because:

1. It uses sensors
2. It has all three ingredients: thing, computation, and internet connectivity
3. It saves money on waste collection
4. It’s a physical object

Reveal Answer Answer: b) It has all three ingredients: thing, computation, and internet connectivity

Explanation: The smart recycling bin qualifies as IoT because: 1. Thing: The physical bin you can touch 2. Computation: Microcontroller processing sensor data 3. Internet: Connectivity to transmit fill levels to the cloud

While it does use sensors (a) and saves money (c), those alone don’t define IoT. Many non-IoT devices use sensors or provide benefits. The defining characteristic is having ALL THREE ingredients working together.

8.15 Complete IoT Architecture Layers

Figure 8.6: Five-layer IoT architecture stack from physical devices to user-facing applications.

Complete IoT Ecosystem - Data Flow:

• Physical layer: Sensors, actuators, and smart objects sense the environment and act on commands. Example: a thermostat sensor reads 65F.
• Edge layer: Gateways and local processors filter data or translate protocols. Example: a gateway converts Zigbee traffic to Wi-Fi.
• Connectivity layer: Wi-Fi, Ethernet, cellular, LPWAN, Bluetooth, and Zigbee move data between systems. Example: Wi-Fi sends a reading to the cloud.
• Cloud layer: Storage, analytics, ML, business logic, and APIs turn device data into decisions. Example: an ML model learns a heating schedule.
• Application layer: Mobile apps, dashboards, automation rules, alerts, and reports deliver user value. Example: an app shows energy savings.

Data Flow: Physical -> Edge -> Network -> Cloud -> Application Command Flow: Application -> Cloud -> Network -> Edge -> Physical (actuators respond)

Figure 8.7: IoT connectivity technologies organized by network range.

8.16 Minimum Requirements of IoT

Time: ~7 min | Level: Foundational | ID: P03.C01.U04

To qualify as part of the Internet of Things (IoT), a physical object must meet three minimum requirements: it should start as an everyday object, be enhanced with computational intelligence, and be equipped with internet communication capability. These components ensure the object can perform smart functions and communicate effectively within an IoT ecosystem.

Everyday Thing: The starting point for any IoT device is a physical object commonly found in daily life, such as furniture, appliances, or vehicles. These objects are made “smart” by adding computational and connectivity features.

Computation: Objects must be enhanced with computational capabilities to process data, execute tasks, and enable intelligent behavior. This often involves embedding microprocessors, sensors, and actuators into the object.

Internet Connectivity: Connectivity is the defining feature of IoT devices. It enables them to communicate with other devices, users, or cloud systems via direct or indirect internet communication channels.

8.17 Device Classification Decision Tree

Use this decision tree to classify any device you encounter:

Figure 8.8: Decision tree for classifying software, embedded, connected, and IoT products.

Figure 8.9: The three minimum ingredients for an IoT device: thing, computation, and internet reach.

IoT devices transform the ordinary into extraordinary by leveraging computational intelligence and connectivity, enabling seamless integration into smart environments.

8.18 IoT Classification Check

Scenario: Your company is launching a smart lock product with annual revenue projections of $50M. The engineering team proposes a design with a physical deadbolt mechanism, a microcontroller for keypad control and motor operation, and Bluetooth connectivity to communicate with smartphones within 30 feet. Marketing wants to call it an “IoT smart lock” and price it at $299 (premium over $150 traditional locks).

Think about:

1. Does Bluetooth-only connectivity truly enable “control from anywhere” marketing promises?
2. What would competitors with Wi-Fi-enabled locks offer that this version cannot?

Key Insight: Understanding the difference between “connected” and “IoT” is critical for product positioning and customer expectations.

Current Design Status:

• Thing: Physical deadbolt mechanism
• Computation: Microcontroller for control logic
• Internet: Only Bluetooth (local wireless, NOT internet)

Classification: This is a Connected Product, not a full IoT device. Bluetooth provides 10-100 feet range (requires proximity), while Internet enables global access.

Real Example - August Smart Lock Evolution:

• Version 1.0: Bluetooth only -> Connected Product (30-foot range, $249)
• Version 2.0: Bluetooth + Wi-Fi bridge -> IoT Device (remote access, $279)
• Version 3.0: Integrated Wi-Fi -> Full IoT (cloud intelligence, remote unlock, $299)

Business Impact:

• Connected: Unlock when standing at door, limited value proposition
• IoT: Unlock remotely for delivery ($2B package delivery market), monitor access logs, receive cloud alerts, 3x higher customer lifetime value

8.19 Warehouse Tech Selection Check

Scenario: Your logistics company wants to monitor temperature and humidity in 50 warehouses (200,000+ sq ft each) across the country to protect sensitive pharmaceutical inventory worth $2.5B annually. FDA compliance requires documented temperature control. The IT team presents two competing approaches:

Approach A (Wi-Fi): $50 sensors, $10/month/warehouse, 30-second updates, requires Wi-Fi infrastructure Approach B (LoRaWAN): $80 sensors + $200 gateway, $5/month/warehouse, 10-minute updates, 10-year battery

Think about:

1. What happens when temperature drifts out of range in a 200,000 sq ft warehouse with metal racking blocking signals?
2. Is the $30 sensor price difference more important than 5-year operational costs and reliability?

Key Insight: IoT technology selection depends on application requirements, not “newest” or “fastest” technology.

8.20 IoT Connectivity TCO

Compare total cost of ownership for different IoT connectivity technologies:

colors = ({
  navy: "#2C3E50",
  teal: "#16A085",
  orange: "#E67E22",
  blue: "#3498DB",
  gray: "#7F8C8D",
  purple: "#9B59B6",
  red: "#E74C3C"
})

viewof numSensors = Inputs.range([10, 2000], {
  label: "Number of Sensors",
  step: 10,
  value: 50
})

viewof years = Inputs.range([1, 10], {
  label: "Deployment Years",
  step: 1,
  value: 5
})

viewof sensorCostWiFi = Inputs.range([30, 100], {
  label: "Wi-Fi Sensor Cost ($)",
  step: 5,
  value: 50
})

viewof sensorCostLoRa = Inputs.range([50, 150], {
  label: "LoRaWAN Sensor Cost ($)",
  step: 5,
  value: 80
})

viewof monthlyOpsCostWiFi = Inputs.range([1, 30], {
  label: "Wi-Fi Monthly Ops Cost ($/warehouse)",
  step: 1,
  value: 10
})

viewof monthlyOpsCostLoRa = Inputs.range([1, 30], {
  label: "LoRaWAN Monthly Ops Cost ($/warehouse)",
  step: 1,
  value: 5
})

// Calculations
wifiHardware = numSensors * sensorCostWiFi
loraHardware = numSensors * sensorCostLoRa

wifiInstall = numSensors * 30 // Assuming $30/sensor for Wi-Fi infrastructure
loraInstall = Math.ceil(numSensors / 100) * 200 // Gateway cost, 100 sensors per gateway

wifiOps = monthlyOpsCostWiFi * 12 * years
loraOps = monthlyOpsCostLoRa * 12 * years

wifiTCO = wifiHardware + wifiInstall + wifiOps
loraTCO = loraHardware + loraInstall + loraOps

savings = wifiTCO - loraTCO
savingsPct = (savings / wifiTCO * 100).toFixed(1)
formatUSD = value => "$" + value.toLocaleString()

// Results Display
html`
<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 20px; margin-top: 20px;">
  <div style="border: 2px solid ${colors.navy}; border-radius: 8px; padding: 20px; background: #f8f9fa;">
    <h4 style="color: ${colors.navy}; margin-top: 0;">Wi-Fi / Cellular</h4>
    <div style="display: grid; gap: 8px;">
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap;"><strong>Hardware:</strong><span>${formatUSD(wifiHardware)}</span></div>
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap;"><strong>Installation:</strong><span>${formatUSD(wifiInstall)}</span></div>
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap;"><strong>Operations (${years}yr):</strong><span>${formatUSD(wifiOps)}</span></div>
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap; border-top: 2px solid ${colors.navy}; padding-top: 8px; font-weight: bold;">
        <strong>Total TCO:</strong>
        <span style="color: ${colors.navy};">${formatUSD(wifiTCO)}</span>
      </div>
    </div>
  </div>
  
  <div style="border: 2px solid ${colors.teal}; border-radius: 8px; padding: 20px; background: #f8f9fa;">
    <h4 style="color: ${colors.teal}; margin-top: 0;">LoRaWAN</h4>
    <div style="display: grid; gap: 8px;">
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap;"><strong>Hardware:</strong><span>${formatUSD(loraHardware)}</span></div>
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap;"><strong>Installation:</strong><span>${formatUSD(loraInstall)}</span></div>
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap;"><strong>Operations (${years}yr):</strong><span>${formatUSD(loraOps)}</span></div>
      <div style="display: flex; justify-content: space-between; gap: 12px; flex-wrap: wrap; border-top: 2px solid ${colors.teal}; padding-top: 8px; font-weight: bold;">
        <strong>Total TCO:</strong>
        <span style="color: ${colors.teal};">${formatUSD(loraTCO)}</span>
      </div>
    </div>
  </div>
</div>

<div style="margin-top: 20px; padding: 15px; background: ${savings > 0 ? colors.teal : colors.orange}; color: white; border-radius: 8px; text-align: center; font-size: 1.1em;">
  ${savings > 0 
    ? `<strong>LoRaWAN saves ${formatUSD(savings)} (${savingsPct}%) over ${years} years</strong>`
    : `<strong>Wi-Fi saves ${formatUSD(Math.abs(savings))} (${Math.abs(savingsPct)}%) over ${years} years</strong>`
  }
</div>

<div style="margin-top: 15px; padding: 12px; background: #f8f9fa; border-left: 4px solid ${colors.blue}; border-radius: 4px;">
  <p style="margin: 0; color: ${colors.navy};"><strong>Key Insight:</strong> ${savings > 0 
    ? `Lower operational costs (${monthlyOpsCostLoRa} vs ${monthlyOpsCostWiFi} monthly) drive LoRaWAN ROI despite higher sensor prices.` 
    : `Wi-Fi's lower sensor cost (${formatUSD(sensorCostWiFi)} vs ${formatUSD(sensorCostLoRa)}) outweighs higher operational expenses for this configuration.`
  }</p>
</div>
`

Try adjusting:

• Number of sensors to see scaling effects
• Deployment duration to see how operational costs accumulate
• Sensor costs to reflect your vendor quotes

Critical Requirements Analysis:

Warehouse Environment Challenges:

• Large buildings (200,000+ sq ft) - Wi-Fi coverage gaps common
• Metal racking - blocks Wi-Fi signals, creates dead zones
• Power outlets scarce - sensors need battery-powered
• Temperature changes slowly - no need for 30-second updates

5-Year Total Cost of Ownership:

• Wi-Fi: $10K sensors, $15K installation for Wi-Fi and power, $500/month operations ($30K over five years), for a five-year total of $55,000.
• LoRaWAN: $16K sensors, $3K simple gateway placement, $250/month operations ($15K over five years), for a five-year total of $34,000 and roughly 38% savings.

8.21 Connectivity Technology TCO

Given: 50-sensor deployment, 5-year horizon

• Cellular TCO: $18K hardware + $12K installation + $25K operations = $55K
• LoRaWAN TCO: $16K hardware + $3K installation + $15K operations = $34K
• Cost savings: ($55K - $34K) / $55K = 38%

Scaling impact: At 1,000 sensors, the gap widens:

• Cellular: $360K + $240K + $500K = $1.1M
• LoRaWAN: $320K + $20K + $300K = $640K, about 42% savings

Lower operational costs (10-year batteries, no SIM management) drive LoRaWAN ROI despite higher initial gateway investment.

Why 10-Minute Intervals Suffice:

• Pharmaceutical storage temperature changes gradually (hours, not seconds)
• Refrigeration systems have thermal mass - temperature drifts slowly
• 10-minute intervals provide ample warning (regulations require hourly checks)
• Real-time creates data overload: 1,051,200 readings/year vs 52,560

LoRaWAN Advantages:

• Single gateway covers entire warehouse (vs dense Wi-Fi AP deployment)
• 10-year battery eliminates power infrastructure ($15K savings)
• Excellent signal penetration through metal racking
• Dedicated IoT network isolated from business Wi-Fi

Phoebe’s Field Notes: What “10-Year Battery” Actually Budgets

Phoebe’s Why

“10-year battery” is a charge-versus-time claim, and the TCO table above spends it like cash without showing the receipt. A cell’s mAh rating is charge, not energy, and it is not all usable: internal resistance sags the terminal voltage under every transmit pulse, a slow self-discharge drains capacity even while the sensor sleeps for nine and a half of every ten minutes, and a design margin has to be reserved so the sensor shuts down cleanly instead of browning out mid-uplink. A ten-year claim is really a statement about the average current the whole device – sleep, wake, sense, transmit – is allowed to draw, and that average has almost no slack once self-discharge and derating take their share.

The Derivation

Usable charge after self-discharge over service life \(t\) and a design derating margin \(\delta\):

\[C_{usable} = C_0\,(1-k)^{t}\,(1-\delta)\]

A target service life \(T_{life}\) sets the maximum average current the whole device may draw:

\[I_{budget} = \frac{C_{usable}}{T_{life}}\]

For a duty cycle of active current \(I_{active}\) over duration \(t_{active}\) inside a reporting period \(T\), with sleep current \(I_{sleep}\) the rest of the time:

\[I_{avg} = \frac{t_{active}}{T}I_{active} + \left(1-\frac{t_{active}}{T}\right)I_{sleep}\]

and under load the terminal voltage sags by the cell’s internal resistance:

\[V_{load} = V_{oc} - I\,R_{int}\]

Worked Numbers: The Warehouse Sensor’s Budget

This section names the interval (10 minutes) and the claim (10-year battery) but not the cell, so take a catalog-typical AA-size lithium thionyl-chloride cell used in real LoRaWAN sensors (\(V_{oc} = 3.6\) V, \(C_0 = 2400\) mAh, \(R_{int} \approx 15\ \Omega\) typical for this bobbin-type chemistry):

• Usable capacity after 1%/year self-discharge over 10 years and a 15% design derate: \(C_{usable} = 2400\times(0.99)^{10}\times0.85 = 1850\) mAh
• Budget implied by the claim: \(I_{budget} = 1850\ \mathrm{mAh}/87{,}600\ \mathrm{h} = 0.0211\) mA \(= 21.1\ \mu\)A average, for the entire device, every second of every day
• At a \(300\) ms active window per 10-minute uplink (wake, sample, and a single unconfirmed transmission) and a \(1.5\ \mu\)A sleep current: \(I_{avg} = \frac{0.3}{600}(45) + \frac{599.7}{600}(0.0015) = 0.0240\) mA \(= 24.0\ \mu\)A – already over budget by 14%
• If the far corner of a 200,000 sq ft warehouse needs a higher spreading factor for margin and the active window doubles to 600 ms: \(I_{avg} = 0.0450\) mA \(= 45.0\ \mu\)A, and the achievable life becomes \(1850/0.0450\ \mathrm{mA} \div 8760 = 5.17\) years – half the claim
• Voltage sag during the 45 mA transmit pulse: \(\Delta V = 0.045\times15 = 0.675\) V, terminal voltage drops to \(3.6-0.675=2.93\) V during transmit – exactly the moment a brownout would cost the whole uplink, not just a few microamps

The “10-year battery” line in the TCO table is not automatically wrong, but it is a tight budget with almost no declared margin. It survives only if the active window, sleep current, and self-discharge all land close to catalog-best, which is precisely the evidence a requirements record – not a vendor slide – should demand before the five-year TCO comparison is trusted at scale.

Checkpoint: Classification and Connectivity

You now know:

• Bluetooth-only products can be connected without being full IoT; internet reach is the deciding requirement.
• In the 50-warehouse example, LoRaWAN’s $34,000 five-year TCO beats the $55,000 Wi-Fi total by roughly 38%.
• A 10-minute interval can be enough for pharmaceutical storage because temperature drift happens over hours, while 10-year batteries reduce field maintenance.

Once a product qualifies as IoT and the connectivity tradeoff is defensible, the next question is whether the design is good enough for its domain.

8.22 Knowledge Check: Minimum Requirements

Question 1: A fitness tracker that records steps locally and only syncs to your phone via Bluetooth (no cloud connection) is:

1. A full IoT device because it has sensors and connectivity
2. A connected device because Bluetooth enables device-to-device communication but not internet
3. An embedded device because it has no connectivity at all
4. An IoT device because it can track health metrics

Reveal Answer Answer: b) A connected device because Bluetooth enables device-to-device communication but not internet

Explanation: The tracker has: - Thing: The physical wristband - Computation: Processor counting steps - Connectivity: Bluetooth only (not internet)

Bluetooth alone provides local wireless communication but not internet connectivity. The device becomes IoT only when the phone acts as a gateway to upload data to the cloud. Without that cloud connection, it’s “connected” but not truly “IoT.”

The Gateway Distinction: Many devices achieve IoT status indirectly through a smartphone gateway. If this tracker’s companion app uploads to the cloud, the SYSTEM is IoT, but the tracker alone is just connected.

Question 2: Which of the following is the MOST accurate way to describe the “Internet” requirement in IoT?

1. The device must use Wi-Fi
2. The device must connect to the World Wide Web
3. The device must be able to communicate with remote systems via IP-based networks
4. The device must have a mobile app

Reveal Answer Answer: c) The device must be able to communicate with remote systems via IP-based networks

Explanation:

• (a) Wrong: Wi-Fi is just one connectivity option. Cellular, Ethernet, LoRaWAN are equally valid.
• (b) Partially wrong: IoT uses internet protocols (TCP/IP) but doesn’t necessarily access “web pages.”
• (c) Correct: The core requirement is IP-based communication enabling remote access, whether direct or through a gateway.
• (d) Wrong: Mobile apps are a user interface choice, not a connectivity requirement. Many IoT devices use web dashboards or machine-to-machine communication.

Key Insight: “Internet” in IoT means protocol-based network communication (typically IP), not specifically “browsing the web.”

Question 3: A smart door lock with Wi-Fi that allows remote unlocking from anywhere in the world demonstrates which IoT advantage over a Bluetooth-only lock?

1. Better security
2. Lower power consumption
3. Global accessibility instead of proximity-only control
4. Faster response time

Reveal Answer Answer: c) Global accessibility instead of proximity-only control

Explanation: The fundamental difference between “connected” (Bluetooth) and “IoT” (Wi-Fi/Internet) is reach:

• Bluetooth: 10-100 feet range, requires physical proximity
• Wi-Fi/Internet: Global range, control from anywhere with internet access

Business Impact Example:

• Bluetooth lock: Can only unlock when standing at the door
• IoT lock: Can unlock remotely for delivery drivers (Amazon Key), grant temporary access to guests, or monitor who enters while you’re traveling

This global accessibility unlocks new use cases worth billions (package delivery, Airbnb key management, enterprise access control).

8.23 Characteristics of Ideal IoT Systems

Time: ~8 min | Level: Intermediate | ID: P03.C01.U05

What distinguishes a well-designed IoT system from a mediocre one? Understanding the characteristics of ideal IoT implementations helps engineers, designers, and product managers create systems that deliver real value. These eleven characteristics represent design goals that the best IoT solutions strive to achieve.

8.24 The Eleven Characteristics of Ideal IoT

Figure 8.10: Eleven characteristics of strong IoT systems grouped by design goal.

8.25 Characteristics as Tradeoffs

This variant shows the 11 characteristics as a priority matrix - different IoT domains prioritize different characteristics:

Figure 8.11: How different IoT domains prioritize the eleven IoT characteristics.

Why this variant helps: The original mindmap lists all 11 characteristics as equally important. This variant shows the design reality: different applications prioritize different characteristics. A factory needs millisecond response times (Fast), while a farm sensor can wait hours (Growing is more important). Understanding these trade-offs is essential for IoT product design.

• Ubiquitous: Available everywhere and integrated across environments, like smart lighting that works consistently at home, office, and hotel.
• Smart: Makes decisions from data and context, like a thermostat that learns a schedule and pre-heats before arrival.
• Agile: Adapts quickly to changing conditions, like factory sensors that detect anomalies and adjust process parameters.
• On Demand: Responds when requested, like a voice assistant that reacts within milliseconds.
• Blend into Background: Operates unobtrusively, like environmental sensors that work silently.
• Secure: Resists cyber threats through encryption, secure boot, and regular updates.
• Low Maintenance: Self-monitors and reduces human intervention through health reports and automatic updates.
• Fast: Delivers low-latency response, like industrial control loops responding in less than 10 ms.
• Upgradable: Evolves through OTA updates without hardware replacement, like vehicles gaining new software features.
• Growing: Scales from pilot to production fleet without redesign.
• Adaptable: Supports new use cases, protocols, and integrations as requirements change.

8.26 IoT Priority Scoring

Score your IoT project requirements against the eleven ideal characteristics:

colorsChar = ({
  navy: "#2C3E50",
  teal: "#16A085",
  orange: "#E67E22",
  blue: "#3498DB",
  gray: "#7F8C8D",
  purple: "#9B59B6",
  red: "#E74C3C"
})

// Project type selector
viewof projectType = Inputs.select(
  ["Custom", "Smart Home", "Industrial IoT", "Medical Wearable", "Smart Agriculture", "Commercial Building"],
  {label: "Project Type (presets available)", value: "Custom"}
)

// Importance sliders for each characteristic
viewof ubiquitousImportance = Inputs.range([1, 10], {
  label: "Ubiquitous (works everywhere)",
  step: 1,
  value: projectType === "Smart Home" ? 7 : projectType === "Industrial IoT" ? 5 : projectType === "Medical Wearable" ? 6 : projectType === "Smart Agriculture" ? 4 : projectType === "Commercial Building" ? 6 : 5
})

viewof smartImportance = Inputs.range([1, 10], {
  label: "Smart (intelligent decisions)",
  step: 1,
  value: projectType === "Smart Home" ? 8 : projectType === "Industrial IoT" ? 9 : projectType === "Medical Wearable" ? 7 : projectType === "Smart Agriculture" ? 6 : projectType === "Commercial Building" ? 7 : 5
})

viewof agileImportance = Inputs.range([1, 10], {
  label: "Agile (adapts quickly)",
  step: 1,
  value: projectType === "Smart Home" ? 6 : projectType === "Industrial IoT" ? 9 : projectType === "Medical Wearable" ? 5 : projectType === "Smart Agriculture" ? 5 : projectType === "Commercial Building" ? 6 : 5
})

viewof onDemandImportance = Inputs.range([1, 10], {
  label: "On Demand (instant response)",
  step: 1,
  value: projectType === "Smart Home" ? 9 : projectType === "Industrial IoT" ? 7 : projectType === "Medical Wearable" ? 6 : projectType === "Smart Agriculture" ? 3 : projectType === "Commercial Building" ? 7 : 5
})

viewof blendImportance = Inputs.range([1, 10], {
  label: "Blend into Background (unobtrusive)",
  step: 1,
  value: projectType === "Smart Home" ? 8 : projectType === "Industrial IoT" ? 5 : projectType === "Medical Wearable" ? 7 : projectType === "Smart Agriculture" ? 8 : projectType === "Commercial Building" ? 6 : 5
})

viewof secureImportance = Inputs.range([1, 10], {
  label: "Secure (protected)",
  step: 1,
  value: projectType === "Smart Home" ? 8 : projectType === "Industrial IoT" ? 10 : projectType === "Medical Wearable" ? 10 : projectType === "Smart Agriculture" ? 6 : projectType === "Commercial Building" ? 9 : 5
})

viewof lowMaintenanceImportance = Inputs.range([1, 10], {
  label: "Low Maintenance (self-sufficient)",
  step: 1,
  value: projectType === "Smart Home" ? 7 : projectType === "Industrial IoT" ? 8 : projectType === "Medical Wearable" ? 9 : projectType === "Smart Agriculture" ? 10 : projectType === "Commercial Building" ? 8 : 5
})

viewof fastImportance = Inputs.range([1, 10], {
  label: "Fast (low latency)",
  step: 1,
  value: projectType === "Smart Home" ? 7 : projectType === "Industrial IoT" ? 10 : projectType === "Medical Wearable" ? 9 : projectType === "Smart Agriculture" ? 3 : projectType === "Commercial Building" ? 6 : 5
})

viewof upgradableImportance = Inputs.range([1, 10], {
  label: "Upgradable (OTA updates)",
  step: 1,
  value: projectType === "Smart Home" ? 9 : projectType === "Industrial IoT" ? 8 : projectType === "Medical Wearable" ? 8 : projectType === "Smart Agriculture" ? 7 : projectType === "Commercial Building" ? 9 : 5
})

viewof growingImportance = Inputs.range([1, 10], {
  label: "Growing (scalable)",
  step: 1,
  value: projectType === "Smart Home" ? 4 : projectType === "Industrial IoT" ? 9 : projectType === "Medical Wearable" ? 5 : projectType === "Smart Agriculture" ? 10 : projectType === "Commercial Building" ? 9 : 5
})

viewof adaptableImportance = Inputs.range([1, 10], {
  label: "Adaptable (flexible integrations)",
  step: 1,
  value: projectType === "Smart Home" ? 9 : projectType === "Industrial IoT" ? 7 : projectType === "Medical Wearable" ? 5 : projectType === "Smart Agriculture" ? 8 : projectType === "Commercial Building" ? 8 : 5
})

// Calculate scores
characteristics = [
  {name: "Ubiquitous", score: ubiquitousImportance},
  {name: "Smart", score: smartImportance},
  {name: "Agile", score: agileImportance},
  {name: "On Demand", score: onDemandImportance},
  {name: "Blend into Background", score: blendImportance},
  {name: "Secure", score: secureImportance},
  {name: "Low Maintenance", score: lowMaintenanceImportance},
  {name: "Fast", score: fastImportance},
  {name: "Upgradable", score: upgradableImportance},
  {name: "Growing", score: growingImportance},
  {name: "Adaptable", score: adaptableImportance}
]

sortedChars = characteristics.sort((a, b) => b.score - a.score)

topThree = sortedChars.slice(0, 3)
bottomThree = sortedChars.slice(-3).reverse()

// Visualization
html`
<div style="margin-top: 20px;">
  <h4 style="color: ${colorsChar.navy};">Your Priority Ranking</h4>
  <div style="display: grid; gap: 8px;">
    ${sortedChars.map((char, idx) => {
      const isTop = idx < 3
      const isBottom = idx >= 8
      const barColor = isTop ? colorsChar.teal : isBottom ? colorsChar.gray : colorsChar.blue
      const width = (char.score / 10) * 100
      
      return `
        <div style="display: flex; align-items: center; gap: 10px; flex-wrap: wrap;">
          <div style="width: 30px; text-align: right; font-weight: bold; color: ${colorsChar.navy}; flex: 0 0 30px;">${idx + 1}.</div>
          <div style="flex: 1 1 220px; min-width: 0;">
            <div style="display: flex; align-items: center; gap: 10px; flex-wrap: wrap;">
              <div style="flex: 1 1 9rem; min-width: min(9rem, 100%); font-weight: ${isTop ? 'bold' : 'normal'};">${char.name}</div>
              <div style="flex: 2 1 11rem; min-width: min(11rem, 100%); background: #e0e0e0; border-radius: 4px; height: 24px; position: relative;">
                <div style="background: ${barColor}; width: ${width}%; height: 100%; border-radius: 4px; transition: width 0.3s;"></div>
                <div style="position: absolute; right: 8px; top: 50%; transform: translateY(-50%); color: ${width > 50 ? 'white' : colorsChar.navy}; font-weight: bold;">${char.score}/10</div>
              </div>
            </div>
          </div>
        </div>
      `
    }).join('')}
  </div>
</div>

<div style="margin-top: 25px; padding: 20px; background: linear-gradient(135deg, ${colorsChar.teal} 0%, ${colorsChar.blue} 100%); color: white; border-radius: 8px;">
  <h4 style="margin-top: 0; color: white;">Top 3 Priorities for Your Project</h4>
  <ol style="margin: 10px 0; padding-left: 20px; font-size: 1.1em;">
    ${topThree.map(char => `<li><strong>${char.name}</strong> (${char.score}/10)</li>`).join('')}
  </ol>
  <p style="margin-bottom: 0; font-size: 0.95em; opacity: 0.9;">
    <strong>Design Principle:</strong> Focus your engineering effort on excelling at these top 3 characteristics rather than achieving mediocrity across all eleven.
  </p>
</div>

<div style="margin-top: 15px; padding: 15px; background: #fff3cd; border-left: 4px solid ${colorsChar.orange}; border-radius: 4px;">
  <p style="margin: 0; color: ${colorsChar.navy};"><strong>Acceptable Trade-offs:</strong> Lower-priority characteristics (${bottomThree.map(c => c.name).join(', ')}) can be de-prioritized to achieve excellence in your top 3.</p>
</div>
`

How to use:

1. Select your project type for preset values, or choose “Custom”
2. Adjust sliders to reflect your specific requirements
3. Review your top 3 priorities - these should drive your design decisions
4. Accept trade-offs on bottom-ranked characteristics

8.27 Characteristic Dependencies

The eleven characteristics do not exist in isolation – several depend on or enable each other. Understanding these relationships helps you identify which foundational characteristics to invest in first.

Figure 8.12: Characteristic dependencies among foundation, enablement, and experience qualities.

Reading the diagram: Arrows show dependency direction. “Secure” enables “Upgradable” because OTA updates require authenticated, encrypted channels. “Fast” enables “On Demand” because instant user response requires low-latency infrastructure. Investing in foundation-layer characteristics unlocks the enabler and experience layers.

8.28 Why These Characteristics Matter

Trade-off Reality: No single IoT system perfectly achieves all eleven characteristics. Designers must prioritize based on use case:

• Medical wearable: Prioritize Secure, Fast, and Low Maintenance; it may be acceptable to sacrifice Ubiquitous if the device works only in supported regions.
• Smart agriculture: Prioritize Low Maintenance, Growing, and Adaptable; it may be acceptable to sacrifice Fast because hourly updates are often sufficient.
• Industrial control: Prioritize Fast, Secure, and Agile; it may be acceptable to sacrifice Blend into Background because operators need visibility.
• Consumer smart home: Prioritize On Demand, Upgradable, and Blend into Background; it may be acceptable to sacrifice Growing because a home has a fixed practical size.

Design Principle: Identify your 3-4 must-have characteristics and ensure they’re exceptional, rather than achieving mediocrity across all eleven.

8.29 Evaluate IoT Products

Scenario: You’re evaluating two smart thermostat products for a commercial building deployment (500 units across 50 floors):

Product A: Fast response (2-second latency), excellent mobile app, requires manual firmware updates via USB, single-building deployment limit, proprietary protocol.

Product B: Slower response (8-second latency), basic web interface, automatic OTA updates, unlimited scalability, supports multiple protocols (Wi-Fi, Zigbee, BACnet).

Question: Which product better meets ideal IoT characteristics for this commercial deployment?

Answer: Product B wins because: - Growing: Unlimited scalability handles future expansion (Product A’s single-building limit is disqualifying) - Low Maintenance: OTA updates across 500 devices vs. USB updates (500 x manual visits = untenable) - Upgradable: Automatic firmware ensures security patches reach all devices - Adaptable: Multi-protocol support integrates with existing BACnet building management systems

Speed Trade-off is Acceptable: HVAC systems have thermal mass - 8-second response is adequate for temperature control (rooms don’t heat/cool in seconds). 2-second advantage provides no practical benefit.

Product A’s mobile app is irrelevant for commercial building operators who use centralized building management dashboards, not individual phone apps.

This illustrates why prioritizing the right characteristics for your use case matters more than raw feature comparison.

Checkpoint: Characteristic Priorities

You now know:

• The eleven characteristics are tradeoff categories, not a checklist where every item receives equal weight.
• Commercial thermostat selection across 500 units and 50 floors values Growing, Low Maintenance, Upgradable, and Adaptable more than a 2-second response.
• Product B’s 8-second latency is acceptable because HVAC thermal mass makes the speed gain less valuable than OTA updates and multi-protocol integration.

The knowledge checks below test whether you can carry that priority logic into agriculture, medical, automotive, and smart-home examples.

8.30 Knowledge Check: Eleven Characteristics

Question 1: A smart irrigation system for a large farm needs to scale from a 10-sensor pilot to 10,000 sensors across multiple fields. Which characteristic is MOST critical?

1. Fast (low latency)
2. Growing (scalability)
3. On Demand (instant response)
4. Blend into Background (invisible operation)

Reveal Answer Answer: b) Growing (scalability)

Explanation: For agricultural IoT deployments that start small and expand:

• Growing (b) is critical because the platform must handle 1000x growth without architectural changes
• Fast (a) is not critical because soil moisture changes over hours, not milliseconds
• On Demand (c) is nice-to-have but farmers don’t need instant response for irrigation decisions
• Blend into Background (d) is expected but not the primary concern

Design Implication: Choose a platform architecture (cloud, protocols, data storage) that scales horizontally from day one, even if the pilot is small.

Question 2: An IoT pacemaker must prioritize which characteristics above all others?

1. Growing and Adaptable
2. Secure and Fast
3. Ubiquitous and On Demand
4. Low Maintenance and Blend into Background

Reveal Answer Answer: b) Secure and Fast

Explanation: For life-critical medical devices:

• Secure: A hacked pacemaker could kill the patient. Security is non-negotiable.
• Fast: Cardiac events happen in milliseconds. The device must respond instantly.

Why others are lower priority:

• Growing: One pacemaker per patient, no scaling needed
• Adaptable: Regulatory approval limits changes; stability > flexibility
• Ubiquitous: Works in one patient’s body, not everywhere
• Blend into Background: Yes, but security and speed come first

Key Insight: Medical IoT has different priorities than consumer or industrial IoT. Always map characteristics to the specific domain’s requirements.

Question 3: Which IoT characteristic does Tesla’s over-the-air (OTA) software updates best demonstrate?

1. Smart
2. Upgradable
3. Growing
4. Agile

Reveal Answer Answer: b) Upgradable

Explanation: Tesla’s OTA updates exemplify Upgradable because:

• Cars receive new features years after purchase (Autopilot improvements, new games, performance boosts)
• No dealership visit required
• Hardware stays the same; software evolves

Why not the others:

• Smart (a): The car being intelligent is separate from its ability to receive updates
• Growing (c): Tesla’s fleet scaling is a company achievement, not an individual car characteristic
• Agile (d): Agile means quick adaptation to real-time conditions; OTA updates are periodic improvements

Industry Impact: Tesla’s OTA capability forced traditional automakers to add similar features. It’s now a competitive requirement in the automotive IoT market.

Question 4: A startup is designing a smart home hub. They can only excel at 3 characteristics. Which combination makes the most business sense?

1. Fast, Growing, Secure
2. On Demand, Upgradable, Adaptable
3. Ubiquitous, Smart, Blend into Background
4. Low Maintenance, Fast, Growing

Reveal Answer Answer: b) On Demand, Upgradable, Adaptable

Explanation: For consumer smart home hubs:

• On Demand: Users expect instant response (“Alexa, turn on lights”)
• Upgradable: Smart home ecosystem evolves rapidly; hub must receive new features
• Adaptable: New device protocols emerge constantly (Thread, Matter); hub must integrate them

Why others are less critical:

• Fast (a, d): Home automation doesn’t need industrial-grade millisecond response
• Growing (a, d): Homes have finite size; scaling to millions isn’t the hub’s job
• Secure (a): Important but not a top-3 differentiator for consumers (sadly)
• Ubiquitous (c): Hub stays in one home; works in all rooms but not multiple locations
• Blend into Background (c): Nice aesthetically but not a purchase decision driver

Design Principle: Match your top 3 characteristics to what customers actually value and pay for.

8.31 Common Pitfalls

1. Confusing “Connected” with “IoT” A device with Bluetooth-only connectivity is a connected device, not an IoT device. True IoT requires internet reachability – either directly (Wi-Fi, cellular) or indirectly through a gateway. Marketing teams frequently label Bluetooth-only products as “IoT” or “smart,” misleading buyers who expect remote access and cloud intelligence.

2. Treating All Eleven Characteristics as Equally Important No single IoT system can excel at all eleven characteristics simultaneously. Attempting to optimize for everything leads to a mediocre product that excels at nothing. Successful teams identify 3-4 characteristics critical to their domain and design around those. A farm sensor optimized for “Fast” (millisecond response) wastes engineering effort – soil moisture changes over hours.

3. Choosing Technology Before Understanding Requirements Teams often select Wi-Fi because it is familiar, then discover it drains batteries in days, requires power infrastructure at every sensor node, and struggles with signal penetration in industrial environments. Always start with the application’s constraints (range, power, data rate, environment) and let requirements drive technology selection.

4. Ignoring the Gateway Distinction A fitness tracker that syncs only to a phone via Bluetooth is not IoT on its own. The system becomes IoT when the phone uploads data to the cloud. This distinction matters for reliability: if the phone is absent, the cloud connection breaks. Design decisions should account for whether a device depends on a gateway and what happens when that gateway is unavailable.

5. Overlooking Scalability Until It Is Too Late A prototype that works with 10 sensors often fails catastrophically at 10,000. Architecture choices made during prototyping (polling frequency, database schema, message broker capacity) become constraints at scale. Evaluate the “Growing” characteristic early, even if the pilot is small.

Checkpoint: Avoiding Requirements Traps

You now know:

• The five common pitfalls mostly come from treating labels, features, or prototypes as requirements evidence.
• The five-layer teaching model is useful first; the seven-layer reference view becomes useful when storage, abstraction, applications, and business processes need sharper boundaries.
• The practice section checks matching, ordering, labeling, and code so you can test concept meaning from more than one angle.

The visual bridge and interactive quizzes are a review lane: first map the architecture layers, then prove you can classify and sequence them.

8.32 Visual Bridge: From 5 Layers to 7

The five-layer model used earlier in the chapter is a teaching shortcut. Detailed reference architectures split the backend into more specific data and business layers when you need sharper design boundaries.

Figure 8.13: Bridge from the five-layer teaching model to a seven-layer reference architecture.

Use the five-layer version when you are learning the flow. Switch to the seven-layer reference view when you need to separate storage, abstraction, applications, and business processes explicitly.

8.33 Interactive Quiz: Match Concepts

8.34 Interactive Quiz: Sequence the Steps

8.35 Label the Diagram

8.36 Code Challenge

8.37 Summary

In this chapter, you learned:

• IoT works in four steps: Sense -> Connect -> Process -> Act, repeating continuously
• Three minimum requirements define IoT: Thing + Computation + Internet connectivity
• Eleven characteristics distinguish ideal IoT systems: Ubiquitous, Smart, Agile, On Demand, Blend into Background, Secure, Low Maintenance, Fast, Upgradable, Growing, Adaptable
• Trade-offs are necessary: Different applications prioritize different characteristics
• Technology selection should be driven by requirements, not by “newest” or “fastest”

8.38 Key Takeaways

1. The Three Ingredients Test is your filter: If a device lacks Thing, Computation, OR Internet connectivity, it’s not IoT regardless of marketing claims
2. Connected vs IoT distinction matters for product positioning: Bluetooth-only = connected (proximity); Internet = IoT (global reach)
3. The Eleven Characteristics are quality benchmarks, not checkboxes: No device excels at all eleven; prioritize 3-4 based on your use case
4. Trade-offs define design decisions: Medical IoT prioritizes Secure+Fast; Agriculture prioritizes Growing+Low Maintenance; Consumer prioritizes On Demand+Upgradable
5. Technology selection follows requirements: Choose LoRaWAN for long-range battery-powered sensors, Wi-Fi for high-bandwidth local devices, cellular for mobile assets

• Three Ingredients: Thing plus computation plus internet reach is the minimum IoT filter for any device.
• Connected vs. IoT: Local wireless such as Bluetooth is not the same as global internet reach, which affects classification and positioning.
• Eleven Characteristics: Quality goals are not equal requirements; prioritize the few that fit the domain.
• Trade-offs: No perfect IoT device exists, so match priorities to the use case.
• Technology selection: Requirements should drive connectivity choices, not trends.

8.39 Knowledge Check

8.40 IoT Requirements Quiz

8.41 Eleven Characteristics Selection

Scenario: A hospital system must choose between three remote patient monitoring (RPM) wearable devices for 5,000 chronic heart failure patients. All three meet minimum IoT requirements (Thing + Computation + Internet). Which characteristics matter most, and how do you score them?

The Three Devices:

• Device A: $89, 48-hour battery, 15-minute data interval, FDA cleared, proprietary protocol, and no OTA updates because devices must be returned.
• Device B: $199, 7-day battery, 5-minute data interval, FDA cleared, standard BLE plus FHIR, and automatic OTA updates.
• Device C: $145, 72-hour battery, 1-minute data interval, FDA cleared, standard protocols, and OTA updates with manual approval.

Step 1: Prioritize Characteristics for Healthcare RPM

For a medical wearable with 5,000 deployed devices, which of the 11 characteristics are non-negotiable vs. nice-to-have?

• Secure, critical 9/10: HIPAA compliance and patient health data protection are mandatory.
• Fast, high 7/10: Heart failure alerts need less than five-minute latency.
• Low Maintenance, high 8/10: 5,000 devices with frequent battery visits would be unsustainable.
• Upgradable, high 8/10: FDA-required firmware patches and clinical protocol changes must reach the fleet.
• Growing, medium 6/10: The system may expand to 10,000 patients, but not 100,000.
• Adaptable, medium 5/10: Epic EHR integration matters, but the scope is defined.
• Smart, medium 6/10: Local anomaly detection helps, but is not the primary decision driver.
• On Demand, low 4/10: Medical monitoring is periodic, not an instant-response consumer interaction.
• Ubiquitous, low 3/10: The device works at home and clinic, not everywhere.
• Agile, low 4/10: Clinical protocols change slowly.
• Blend into Background, low 3/10: Patients expect visible medical devices.

Step 2: Score Each Device

• Secure, 20%: Device A scores 7/10 because the proprietary design is hard to audit; Devices B and C score 9/10 with standard protocols.
• Fast, 15%: Device A scores 5/10 because 15-minute intervals are too slow; Device B scores 9/10 at five minutes; Device C scores 10/10 at one minute.
• Low Maintenance, 20%: Device A scores 4/10 with a two-day battery; Device B scores 10/10 with a seven-day battery; Device C scores 6/10 with a three-day battery.
• Upgradable, 20%: Device A scores 2/10 because updates require return; Device B scores 10/10 with automatic OTA; Device C scores 7/10 with manual OTA.
• Growing, 10%: Device A scores 4/10 due to vendor lock-in; Devices B and C score 9/10 with open standards.
• Adaptable, 10%: Device A scores 3/10 with proprietary integration; Device B scores 10/10 with FHIR; Device C scores 9/10 with standards but a narrower integration set.
• Smart, 5%: Device A scores 6/10 with basic alerts; Device B scores 8/10 with edge anomaly detection; Device C scores 7/10 with cloud-only processing.

Weighted Scores:

• Device A: (7×0.20) + (5×0.15) + (4×0.20) + (2×0.20) + (4×0.10) + (3×0.10) + (6×0.05) = 4.5/10
• Device B: (9×0.20) + (9×0.15) + (10×0.20) + (10×0.20) + (9×0.10) + (10×0.10) + (8×0.05) = 9.5/10
• Device C: (9×0.20) + (10×0.15) + (6×0.20) + (7×0.20) + (9×0.10) + (9×0.10) + (7×0.05) = 7.8/10

In 60 Seconds: This chapter covers IoT requirements and characteristics, explaining the core concepts, practical design decisions, and common pitfalls that IoT practitioners need to build effective, reliable connected systems.

Step 3: Calculate Total Cost of Ownership (5-Year)

• Hardware for 5,000 devices: Device A costs $445,000; Device B costs $995,000; Device C costs $725,000.
• Battery replacements at $25 per visit: Device A costs $112,500 per year, or $562,500 over five years; Device B costs $6,250 per year, or $31,250; Device C costs $87,500 per year, or $437,500.
• Firmware updates: Device A costs $225,000 for return shipping across three updates; Device B costs $0 with OTA; Device C costs $75,000 for two manual updates.
• Integration: Device A costs $150,000 because of proprietary integration; Device B costs $25,000; Device C costs $40,000.
• Five-year TCO: Device A totals $1,382,500; Device B totals $1,051,250; Device C totals $1,277,500.

Step 4: Calculate Clinical Value

• Early alert detection: Device A catches 72% of events in time, Device B catches 94%, and Device C catches 96%.
• Prevented hospitalizations per 5,000 patients per year: Device A prevents 360, Device B prevents 470, and Device C prevents 480.
• Cost per hospitalization: All three use the same $12,500 avoided-cost assumption.
• Annual savings: Device A saves $4.5M, Device B saves $5.875M, and Device C saves $6.0M.
• Five-year clinical value: Device A produces $22.5M, Device B produces $29.375M, and Device C produces $30.0M.

Decision:

Device B wins on all three dimensions:

1. Highest quality score: 9.5/10 vs. 7.8 (Device C) vs. 4.5 (Device A)
2. Lowest TCO: $1.05M vs. $1.28M (Device C) vs. $1.38M (Device A)
3. Highest clinical value: $29.4M vs. $30M (Device C, marginal) vs. $22.5M (Device A)

Device B costs $110 more per unit than Device A, but saves $331K in 5-year TCO and delivers $6.9M more in clinical value.

Device C has slightly better clinical outcomes ($600K over 5 years) but costs $226K more than Device B and scores lower on critical characteristics (Low Maintenance, Upgradable).

Key Lessons:

1. Not all 11 characteristics matter equally: For medical RPM, 75% of the decision weight comes from just 4 characteristics (Secure, Fast, Low Maintenance, Upgradable). Domain determines priorities.

2. TCO ≠ purchase price: Device A’s $89 price looks attractive, but 5-year TCO is 31% higher than Device B due to battery replacement visits and firmware update logistics.

3. Characteristics predict TCO: Low Maintenance and Upgradable directly correlate with operational costs. Devices scoring poorly on these characteristics always cost more long-term.

4. Weighted scoring prevents bias: Without structured scoring, humans gravitate toward “favorite features.” Device C’s 1-minute data frequency is impressive but matters far less than Device B’s 7-day battery and auto-OTA for a 5,000-device deployment.

Application to Your Projects:

1. List the 11 characteristics
2. Prioritize 3-4 as non-negotiable for your domain
3. Assign weights summing to 100%
4. Score each option on the prioritized characteristics
5. Calculate weighted total + TCO + domain-specific value
6. Document the rationale for the decision

This framework prevents “gut feel” decisions and ensures the right trade-offs for your use case.

Checkpoint: Weighted Decisions

You now know:

• In medical RPM, 75% of the decision weight comes from four characteristics: Secure, Fast, Low Maintenance, and Upgradable.
• Device B wins with a 9.5/10 quality score, the lowest five-year TCO at $1.05M, and $29.4M in five-year clinical value.
• A structured score, TCO, and value calculation can overturn the tempting $89 purchase price of Device A.

The final data-flow section ties the chapter back to architecture: every requirement has to land somewhere in the physical, edge, connectivity, cloud, or application layer.

8.42 IoT Data Flow Layers

The big picture: IoT systems move data through five architectural layers – Physical, Edge, Connectivity, Cloud, and Application – with each layer transforming raw sensor readings into actionable user value.

Step-by-step breakdown:

1. Physical Layer (Data Capture): A smart thermostat’s temperature sensor (DHT22) measures 18.3°C every 30 seconds – Real example: generates 2,880 readings per day, each 2 bytes = 5.76 KB/day raw data
2. Edge Layer (Local Processing): The thermostat’s microcontroller (ESP32) averages the last 10 readings, detects “temperature dropping 0.3°C/hour” trend, and flags “heat needed soon” – Real example: reduces data from 2,880 points to 288 aggregated readings (10x compression) before transmission
3. Connectivity Layer (Data Transmission): Wi-Fi sends the aggregated reading + trend flag to AWS IoT Core via MQTT protocol – Real example: 50-byte payload transmitted every 5 minutes = 14,400 bytes/day (2.5x further reduction vs. raw streaming)
4. Cloud Layer (Intelligence and Storage): AWS Lambda function compares current pattern against 6 months of historical data (52 million readings), ML model predicts “optimal heating start time is 6:15 PM for 7:00 PM comfort” – Real example: processes data from 1 million+ thermostats simultaneously, generating personalized schedules
5. Application Layer (User Value): Mobile app displays “Heating starts in 15 min” notification and shows “You’ll save $12 this month vs. always-on heating” – Real example: 30% energy savings ($180/year) delivered through optimized scheduling based on learned patterns

Why this matters: Understanding this data flow reveals where processing should happen. Streaming 5.76 KB/day raw sensor data to the cloud costs $2/month in cellular data (IoT project killer), while edge processing reduces it to 14.4 KB/day for $0.20/month. The 10x cost difference between “sense and stream” vs. “sense, process, then stream” is why edge computing is fundamental to viable IoT economics, not just a performance optimization.

8.43 Concept Relationships

• Three Ingredients Test -> IoT Introduction: Thing, computation, and internet reach expand into minimum requirements.
• Eleven Characteristics -> IoT Perspectives: Different stakeholders prioritize different characteristics.
• Architecture Layers -> Reference Architectures: The five-layer model expands into complete system design patterns.
• LoRaWAN for Agriculture -> LoRa and LoRaWAN: LPWAN technology selection explains the warehouse and field-monitoring examples.
• Connectivity Selection -> Protocol Comparison: The same framework helps choose Wi-Fi, LoRaWAN, cellular, or a gateway pattern.

8.44 See Also

Continue the IoT Overview Series:

• IoT Introduction - The Three Ingredients Test that defines minimum requirements
• IoT Perspectives - How stakeholders prioritize different characteristics
• Device Evolution - How Embedded → Connected → IoT progression builds capability

Architecture Deep Dives:

• Reference Architectures - Complete system design patterns for all five layers
• Edge Computing - Local processing to meet Fast and Low Maintenance characteristics

Connectivity Selection:

• Wi-Fi for IoT - When to use Wi-Fi (local high-bandwidth)
• LoRa and LoRaWAN - When to use LPWAN (long-range, battery-powered)
• Cellular IoT - When to use NB-IoT/LTE-M (mobile assets)

8.45 What’s Next

• Next: Common Pitfalls explains mistakes to avoid when choosing vendors, architectures, and deployment assumptions.
• Previous: IoT Perspectives compares how different stakeholders weight these same characteristics.
• Related: IoT Perspectives reinforces stakeholder trade-off analysis.
• Advanced: Device Evolution revisits the embedded -> connected -> IoT progression through a capability lens.
• Hub: Simulation Playground collects interactive IoT protocol experiments.