30 IoT Domains: Shared Patterns

30.1 Start With the Decision

A farm, ward, factory, and city use different devices but repeat some service patterns. Start with the decision and harm in each domain.

30.2 Route Overview

This is part 1 of 2. Continue with IoT Domains: Constraints and Collection Paths.

30.3 Part Objectives

• Identify shared sensing, tracking, control, and alert patterns.
• Compare domain value without hiding operational owners.

30.4 Overview

This first route identifies recurring IoT patterns across domains, then follows sensors, telemetry meaning, and collection paths into a usable taxonomy.

This is part 1 of 2. Continue with IoT Application Domains: Requirements and Navigation for the second focused route.

30.5 Start With the Story

Picture a heart monitor and a city bin sensor. Both can send data, but a late heart warning and a late bin report do not cause the same harm. Their users, laws, power needs, and support paths are different too.

Start with the outcome in one domain. Name the person or service that acts, the time limit, the cost of a wrong result, and the data that must stay private. Then test a lost link, a bad reading, a failed update, and a change in scale.

Use those facts to shape sensing, communication, storage, and support. A domain label does not choose the architecture for you. Two health systems may need different designs, while a farm and a factory may share a useful pattern when their hard limits match.

Go deeper in two steps. The Practitioner sections compare domain constraints and design the collection path. Under the Hood explains how data meaning and response time change the architecture.

Use one outcome card per domain. Name the person, animal, place, asset, or service that should benefit. State the action that may change. Add the time in which that action still helps. If no action can be named, the data job is not yet clear.

Add the harm of a wrong result. A false heart alert may cause fear and care work. A missed heart alert may cause direct harm. A false bin alert may waste a trip. A late bin report may be fine until waste blocks a street. These gaps shape the design.

Name the place. A home has residents and a local network. A farm has land, weather, animals, and weak power. A plant has machines, shifts, safe states, and old gear. A road has motion, weather, and many owners. The place changes what can be sensed and fixed.

Write the measure claim. State the physical event, unit, range, rate, time, and known error. Add the point where the value is checked. Keep raw and changed forms linked. A shared sensor part does not give the same meaning in all domains.

Write the action path. Mark the device, local rule, gateway, network, store, service, human, and final act. Put an owner beside each step. Mark what must stay local. Mark what may wait. Mark what must never happen from old or doubtful data.

Test the normal path first. Then remove a sensor. Lose the link. Delay the data. Restart the device. Fill a queue. Change the user. Add ten times more units. Keep the safe result and repair owner for every case.

Review people and power. Ask who is watched, who is missing, who may say no, and who can fix a record. Ask who pays for the device, data, site visit, update, and final removal. A useful pilot may still fail as a fair or lasting service.

Keep domain needs in plain groups. Use time, harm, data, place, energy, scale, privacy, security, and support. Give each group a hard need or a measured range. This makes two domains easy to compare without forcing them into one design.

Choose the smallest first test that can break the claim. Use real people, places, and fault states where safe. Set the pass rule before the test. Keep misses and hard cases. Do not use a clean demo as proof for a full town, ward, plant, or fleet.

End with a narrow release statement. Name the domain, users, sites, devices, action, time, failure cases, and owners it covers. Add a date and the change that forces a new review. The domain name is the start of this record, not its conclusion.

For a first class task, compare just two cases. Use a home leak alarm and a park soil sensor. Both may sense water. The home alarm may wake a resident in one minute. The park sensor may guide work the next day. This one change in time can change power, link, and alert choices.

Add the wrong-action test. A false home alarm may wake a family and call a plumber. A false park alert may waste water and staff time. Write both costs. Set a rule that keeps weak data from making the costly action.

Add the lost-service test. Let the home unit sound a local alarm when the cloud is down. Let the park unit keep readings until the path returns. The same fault can need two safe results. Record each result beside its domain card.

Last, swap the sites. Ask whether the home design can run across a large park and whether the park design can guard a fast leak. The gaps show why a shared part does not erase domain needs. Keep that lesson when more cases are added.

Write the two results side by side. Use the same short fields for job, time, harm, place, power, data, owner, and safe fault. Circle the fields that differ. Those circles explain the design split in words that a new reader can test.

Keep one shared fact too. Both devices still need a sound measure and a support path. Shared facts can guide common parts, while the circled facts guide each setup. This is a safer use of a domain map than copying one full design into every case.

Picture walking through a city, clinic, farm, factory, store, and home with the same sensor kit in your bag. The lesson is that the domain changes the story: the same connected capability earns trust only when it matches the users, constraints, regulations, and failure consequences of that setting.

30.6 Learning Objectives

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

• Classify Major IoT Application Domains: Categorize the 14 key sectors where IoT creates value into the Five Pillars framework
• Explain Domain-Specific Challenges: Distinguish unique requirements for smart cities, agriculture, healthcare, and industry
• Compare IoT Solutions Across Sectors: Analyze how similar technologies apply differently across domains
• Evaluate Sensor and Communication Needs: Match appropriate technologies to application requirements
• Apply Cross-Domain Patterns: Demonstrate how common IoT patterns transfer across multiple industries

30.7 Application Domains

30.8 Minimum Viable Understanding

• Five Pillars Framework: IoT applications organize into 5 pillars — SUSTAIN (cities, 30% energy savings), MOVE (transport, sub-10 ms latency), HEAL (healthcare, 99.9% reliability), FEED (agriculture, 40% water savings), and MAKE (manufacturing, 25% less downtime) — each with fundamentally different technical requirements.
• Domain Requirements Vary by Orders of Magnitude: Latency spans from under 10 ms for autonomous vehicles to hours for agricultural sensors; battery life from unlimited (mains-powered industrial) to 10+ years (LoRaWAN parking sensors transmitting 10 bytes/hour).
• Cross-Pillar Innovation Transfers Proven Patterns: Predictive maintenance algorithms from manufacturing (MAKE) apply directly to medical equipment monitoring (HEAL), because the underlying pattern — sensor data to anomaly detection to preventive action — is domain-agnostic.
• Start with the Pain Point, Not the Platform: The #1 cause of IoT project failure is selecting technology before understanding domain-specific non-negotiable requirements (latency, reliability, power budget, data volume, regulatory compliance).

30.9 IoT Application Domains Basics

An IoT “application domain” is simply an industry or sector where connected sensors create value. Just like how smartphones have apps for different purposes (music, maps, health), IoT has different “domains” for different parts of life.

Simple Analogy: Think of IoT domains like departments in a hospital:

• The Emergency Room (Transportation) needs instant responses — milliseconds matter
• The General Ward (Smart Home) checks patients hourly — minutes are fine
• The Lab (Agriculture) runs tests daily — hours are acceptable

Each “department” uses similar tools (sensors, connectivity) but with very different requirements for speed, reliability, and precision.

Why This Matters for You:

• If you’re interested in building something: Understanding domains helps you pick the right project
• If you’re choosing a career: Each domain has different skill requirements
• If you’re evaluating a product: You’ll know what questions to ask

The Key Insight: IoT is not one-size-fits-all. The same sensor technology that works perfectly for a smart parking system would be completely wrong for a patient heart monitor. This chapter helps you understand why by mapping out the full landscape of IoT applications.

What You’ll Learn:

1. The five big categories (pillars) of IoT applications
2. The 14 specific domains within those pillars
3. How to navigate the detailed chapters that follow
4. What makes each domain unique in its requirements

30.10 IoT Domains for Business Leaders

Key Business Value: IoT creates measurable value across 14 major industry sectors — from 30% energy savings in smart buildings to 40% water reduction in precision agriculture. Early adopters gain competitive advantage through operational efficiency, new revenue streams from data-driven services, and enhanced customer experiences that differentiate their offerings in the market.

Decision Framework:

• Initial investment: Sensors, connectivity, platform, and integration typically range from $25,000 to more than $500,000.
• Operational cost: Platform fees, connectivity, and maintenance commonly range from $1,000 to $25,000 per month.
• ROI timeline: Payback depends on domain complexity and often falls between 6 and 36 months.
• Risk level: Consumer and facilities deployments are usually lower risk; industrial, healthcare, and transportation deployments carry higher safety, reliability, and compliance exposure.

When to Choose This Technology:

• Operations generate data that could drive better decisions (manufacturing, logistics, facilities)
• Manual monitoring or inspection processes are costly or error-prone
• Customer experience could be enhanced with connected products or services
• Regulatory compliance requires continuous monitoring and reporting

30.11 Domains Change the Design Question

An IoT domain is not just a market label. It changes the design question because each sector has different timing, safety, privacy, power, installation, and operating constraints. A smart-parking sensor, insulin refrigerator monitor, irrigation valve, and factory vibration sensor may all publish telemetry, but they are not interchangeable systems.

Use the Five Pillars as a first sorting tool, then test the fit against the concrete constraints in the linked figure in Part 2. SUSTAIN projects often optimize shared infrastructure. MOVE projects prioritize location, routing, and fast response. HEAL projects raise clinical workflow, safety, and privacy obligations. FEED projects must survive weather, distance, seasonality, and field maintenance. MAKE projects must fit production uptime, plant networks, and maintenance ownership.

The practical reason for the separation in the linked figure in Part 2 is that “good enough” changes. A building occupancy estimate can be probabilistic if it saves energy without making rooms unusable. A cold-chain vaccine monitor needs audit history, calibration evidence, and escalation before product quality is questioned. A factory vibration model can be useful when it predicts a maintenance window, but it can also damage trust if it creates alarms that stop production without root-cause evidence. The same sensor family can therefore require different sampling rates, data retention, user interface language, and support model.

Start each domain with the operating context rather than the product category. Ask what physical condition is being observed, who is accountable for the response, how quickly action must happen, what proof is needed after the event, and what happens when the device is missing, stale, wrong, or offline. That framing prevents a smart-city dashboard, a farm monitoring kit, a wearable health device, and an industrial asset monitor from being described as the same “sensor plus cloud” architecture.

• Outcome: Name the decision that changes because the device exists.
• Environment: Identify power, enclosure, radio path, installation access, and maintenance interval before selecting sensors.
• Operator: Identify who receives the alert, who can act, and what happens if the system is wrong.

The chapters that follow can be read as a catalogue, but they are more useful as comparison cases. Notice how each domain shifts the balance among power budget, connectivity, data quality, standards, human workflow, and liability. That comparison skill is what lets a team avoid copying an architecture from one domain into another where the assumptions no longer hold.

30.12 Continue to the Next Part

Carry this evidence into IoT Domains: Constraints and Collection Paths, which begins with Compare Domains by Constraints.