IoT Fundamentals · Study deck

IoT Architecture Planner

Picture a farm owner who needs a dry-soil warning before a pump is damaged.

Physics Phoebe is your guide for this deck.

planner

Physics Phoebe, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Design a complete five-layer IoT architecture from sensing through application delivery
Evaluate edge-versus-cloud processing trade-offs for a given latency and bandwidth budget
Estimate hardware and recurring costs for different architectural approaches
Diagnose potential bottlenecks in data flow, gateway capacity, and processing pipelines

Major section

In 60 Seconds

A diagram with five boxes is not yet an architecture.

The owner needs to know where the reading begins, where a safe local action can happen, how the warning travels, and who notices a broken path.
Latency means the time a result takes to travel through the system.
A protocol means the agreed rules used to exchange messages.

Major section

Step 1: Define Your Application

where $D_{\text{month}}$ is monthly data volume in MB, $N_{\text{sensors}}$ is sensor count, $f_{\text{day}}$ is messages per sensor per day, and $B_{\text{msg}}$ is bytes per message.

If edge filtering removes 70% of non-actionable records, cloud ingest becomes about $13.2$ MB/month.
That reduction directly affects backhaul usage, storage cost, and query latency.
Problem: Assuming one gateway can cover an entire deployment area.

Major section

Deep Dive: Place Computation Where the Constraint Lives

An IoT architecture spans sensing, networking, processing, cloud, and application layers, but the decision that shapes cost and behavior most is where computation runs.

The same analytics can execute on the device, at the edge through a nearby gateway, or in the cloud.
The edge sits between those extremes.

Use the edge, fog, and cloud tiers as a placement record: immediate sensing and actuation stay low, local aggregation and offline decisions sit in the fog or gateway layer, and fleet analytics plus management live in the cloud.

Major section

Deep Dive: Place Computation Where the Constraint Lives (continued)

The cloud still aggregates events and retrains models, but it should not sit in the real-time inference path.

Below it, the fog layer handles local processing and caching, while the edge/device layer contains sensors and actuators.
A supermarket cold-room monitor shows the split.
The hidden mechanism is ownership of state.

Major section

Deep Dive: Place Computation Where the Constraint Lives (continued)

It may read DS18B20 or SHT31 probes every few seconds, trigger a local buzzer when temperature crosses a food-safety threshold, and publish summaries to a cloud dashboard.

The hourly trend, cross-site comparison, and maintenance report can live in the cloud because they need storage and fleet context more than millisecond timing.
Streaming raw 1080p video to the cloud for hazard detection costs large amounts of bandwidth, adds latency, and ships sensitive footage off-site.
The on-device tier is not one category of hardware, and treating it as one is a common planning mistake.

Major section

Deep Dive: Place Computation Where the Constraint Lives (continued)

Running the detection model on a gateway or camera means only a compact event travels upstream: timestamp, camera ID, confidence score, and a short retained clip when policy allows.

That purpose-built nature is also why application domain changes the architecture more than the five-layer diagram alone suggests.
Home and consumer IoT runs closer to hundreds of devices per person in uncontrolled environments over unlicensed spectrum (Zigbee, Z-Wave, Thread), optimized for convenience rather than guaranteed timing.
The device-vs-edge-vs-cloud choice is rarely all-or-nothing.

Major section

Deep Dive: Place Computation Where the Constraint Lives (continued)

The alarm decision belongs on the device or gateway because staff need it during an internet outage.

Each tier does the job it is suited for, and the architecture degrades gracefully instead of failing when the cloud link drops.
Each handoff should name message schema, retry behavior, timestamp source, and stale-data rules.
Without that ownership map, a hybrid design can become three partial systems that disagree during an outage.

Major section

Summary

Secure by design: Security is not an afterthought.

Optimize data flow: Process at the edge when possible to reduce costs.
Temperature Terry is excited! "I want to build the BIGGEST IoT system ever!" he shouts.
Building a great IoT system is like planning an awesome school project.

Deck summary

Key takeaways

A diagram with five boxes is not yet an architecture.

where $D_{\text{month}}$ is monthly data volume in MB, $N_{\text{sensors}}$ is sensor count, $f_{\text{day}}$ is messages per sensor per day, and $B_{\text{msg}}$ is bytes per message.
An IoT architecture spans sensing, networking, processing, cloud, and application layers, but the decision that shapes cost and behavior most is where computation runs.
The cloud still aggregates events and retrains models, but it should not sit in the real-time inference path.
The alarm decision belongs on the device or gateway because staff need it during an internet outage.

Retrieval practice

Recall check 1 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q1Why should the planner estimate data volume before choosing cloud storage?

ABecause data volume affects gateway load, backhaul cost, storage cost, and processing placement

BBecause storage cost is the only important architecture constraint

CBecause frequent messages favor local storage, so the estimate should set the gateway's storage capacity

DBecause the data-volume estimate replaces field validation and gateway testing

Show answer

Answer: A Data volume affects gateway capacity, bandwidth cost, storage cost, and processing location.

Retrieval practice

Recall check 2 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q2When is an edge-heavy architecture pattern justified?

AWhen latency, resilience, privacy, or bandwidth requires edge processing

BWhenever a deployment has more than one sensor type

CWhen the cloud service has the lowest monthly subscription price

DWhenever the team wants to avoid designing a message schema

Show answer

Answer: A Edge-heavy designs are justified by local constraints, not by novelty or sensor count alone.

Retrieval practice

Recall check 3 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q3A vineyard deploys 500 battery-powered soil-moisture sensors spread across 50 hectares with no Wi-Fi infrastructure. Which connectivity approach is most appropriate?

AWi-Fi with range extenders every 100 m

BLoRaWAN with outdoor gateways every 2-5 km

CBluetooth LE mesh across all 500 sensors

DDirect cellular NB-IoT SIM in every sensor

Show answer

Answer: B Wide outdoor coverage with battery-powered, low-rate sensors is a classic LoRaWAN gateway fit.

Retrieval practice

Recall check 4 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q4A factory deploys 500 vibration sensors sampling at 1 kHz. Each sample is 4 bytes. The factory has unreliable cellular backhaul averaging 2 Mbps. What is the most critical architectural decision?

AUse Wi-Fi instead of cellular for higher bandwidth

BProcess data at the edge to reduce the volume sent over cellular

CReduce the number of sensors to 50 to lower bandwidth needs

DStore all data locally and upload once per day during off-peak hours

Show answer

Answer: B Correct!

Retrieval practice

Recall check 5 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q5Place each architecture responsibility where it lives so you can assign components, preserve evidence across hand-offs, and review the complete IoT design.

ACloud / Application Layer

BPerception Layer

CNetwork Layer

DPhysical Layer

Show answer

Answer: A The three regions separate physical evidence, network and edge control, and cloud application outcomes so you can assign each responsibility without confusing transport with sensing or decisions.

Q6Complete the IoT architecture configuration in JSON:

A'network_layer': 'MQTT',

B'network_layer': 42,

C'network_layer': True,

D'network_layer': ['MQTT',

Show answer

Answer: A IoT architectures are often configured as JSON objects with layers.

Print reference

Answers 1 of 2

Answer key.

A · Data volume affects gateway capacity, bandwidth cost, storage cost, and processing location.
A · Edge-heavy designs are justified by local constraints, not by novelty or sensor count alone.
B · Wide outdoor coverage with battery-powered, low-rate sensors is a classic LoRaWAN gateway fit.
B · Correct!
A · The three regions separate physical evidence, network and edge control, and cloud application outcomes so you can assign each responsibility without confusing transport with sensing or decisions.

Print reference

Answers 2 of 2

Answer key.

A · IoT architectures are often configured as JSON objects with layers.