15 IoT Evolution: Systems Foundations

15.1 Start With the Decision

Connected systems change when cost, reach, and compute cross a useful threshold. A timeline must link each shift to evidence and use.

15.2 Route Overview

This is part 1 of 2. Continue with IoT Evolution: Technology Cycles and Convergence.

15.3 Part Objectives

• Trace IoT system changes through enabling constraints.
• Separate adoption evidence from technology claims.

15.4 Overview

This first route follows connected systems through technology cycles and convergence, then separates transistor growth from the power limits that changed computing design.

This is part 1 of 2. Continue with IoT Systems Evolution: Computing and Placement for the second focused route.

15.5 Start With the Story

One more path makes the shift clear. Begin with a farm pump. A local switch once ran it. A timer came next. A moisture sensor added evidence. A small controller linked the two.

A local display then showed state. A nearby phone added easier control. A remote record added history. A shared service compared many pumps. Each step changed the system boundary.

The value also changed. The switch saved a walk. The timer saved routine work. The sensor reduced waste. The history helped find drift. The wider view helped plan care.

The risks changed as well. A bad switch affected one visit. A bad timer affected one schedule. A bad remote change could affect many sites. Wider reach raised the need for review.

The owners changed too. A farmer owned the switch. A maker owned some software. A network firm owned part of the path. A service team owned long-term support. Clear handoffs became essential.

Failure stayed physical. A dry field still harmed crops. A dead battery still stopped a reading. A broken valve still blocked water. Online success could not hide these facts.

Use this pattern with care. Add one capability. Name its value. Name its owner. Name its new failure. Keep a safe local state. Test the full path. Record the result.

Evolution is a set of choices. It is not a fixed ladder. Some jobs need one box. Some need a shared service. Some need both. Choose the smallest system that proves the outcome.

Follow one familiar product. Start with a room heater. Early control was local. A dial set the target. One box made the choice. The owner saw the result nearby.

Small chips changed that box. Sensors became cheaper. Memory became cheaper. Local control gained more detail. The heater could track time. It could keep simple history. It could show faults.

Wireless links changed the boundary. A phone could read state. A remote service could store history. Support staff could see some faults. A user could change a setting away from home. Each new link also added a new failure.

Online scale changed the service. One team could support many homes. Shared software could learn common faults. Updates could reach many products. A mistake could also reach many products. Scale raised both value and duty.

Placement became a design choice. Fast safety work stayed local. User control could cross the home. Long study could use remote records. A lost link needed a safe local response. Not every task belonged in one place.

Power remained a hard limit. Small devices still had finite batteries. Radios still used energy. Heat still constrained chips. A cheaper part still needed a working enclosure. Progress did not remove physics.

Cost also moved over time. Sale was only the start. Support continued. Storage continued. Updates continued. Field repair continued. End-of-life work arrived later. A low purchase price could hide a high service cost.

Trust became part of operation. More links created more entry points. More data created more duty. Remote action raised the cost of a mistake. Clear ownership mattered at every boundary.

Read the history as linked shifts. Do not treat it as a victory march. Old methods still fit some jobs. New methods create options. Evidence should choose among them. The Practitioner layer compares those choices. Under the Hood tests the power, scale, and cost claims that the short history simplifies.

Picture the computers used by one family. Years ago, one large machine did most tasks. Now a watch, phone, car, lamp, and heating control each do some work. They also share data with distant services. Computing has spread into everyday places.

Several changes made this possible. Chips became smaller and cheaper. They used less power for a given job. Storage grew. Wireless links became common. Online services could support many products at once. No single change created modern IoT.

The useful shift is about placement. Some work happens inside the device. Some happens nearby. Some happens in a large remote system. Put urgent work close to the event. Put long study where more history and power are available. Keep a safe local action when the distant path fails.

Economics changed too. A cheap device can create years of support cost. A connected product needs updates, care, and a clear end of life. More devices also create more points of failure. Scale is useful only when the service can operate it.

This first view tells a broad, steady story. Real progress came in uneven steps and did not make old limits vanish. The Practitioner layer compares placement and operating choices. Under the Hood examines power limits, cost curves, and the failure patterns that appear when many small computers act as one system.

Start with the path from one big computer serving many people to many small computers embedded in everyday places. The story is not just miniaturization; it is the shift from occasional data processing to continuous sensing, local decisions, distributed services, and connected feedback loops.

15.6 In 60 Seconds

An important mid-2000s pivot came as real technologies departed from ideal Dennard scaling and leakage, interconnect, power-density and thermal limits reduced reliance on frequency growth alone. Industry responses included multicore processors, specialised logic and greater emphasis on performance per watt. Together with continued integration, lower-cost microcontrollers and radios, networking and software-platform advances, this widened the cases in which distributed sensing and edge processing could outperform central-only designs.

Battery Bruno’s Math Bridge: Tiny Antenna, Ten-Year Current Budget

The mathematical gist. At 2.4 GHz, the 12.5 cm wavelength gives a 3.12 cm quarter-wave antenna that fits on a small board. A 220 mAh cell, after 1% annual self-discharge for ten years and 20% derating, leaves 159 mAh: only 1.82 microamps average. After a 1.0 microamp sleep floor, roughly 0.82 microamps remain for waking and radio work—about 70.6 short reports per day.

Math Bridge · guided foundationsWhat does a ten-year coin-cell claim leave for each report?Let Battery Bruno turn wavelength, retention, sleep current, and wake time into one budget. Learn the maths

15.7 Learning Objectives

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

• Trace technology cycles: Describe the 10x growth pattern from mainframes to IoT and explain why each era brought exponentially more devices at lower cost
• Distinguish Moore’s Law from Dennard Scaling: Explain how physics enabled and then constrained computing, and justify why the distinction matters for IoT device economics
• Analyze the mid-2000s power-efficiency pivot: Explain how slower frequency scaling increased emphasis on efficiency, multicore and specialised logic, and how that combined with lower-cost microcontrollers and radios to widen IoT compute-placement options.
• Apply economic analysis: Evaluate IoT solutions based on computing economics and cost-per-capability trends across technology generations
• Compare centralized vs distributed architectures: Assess the technical and economic trade-offs that favor edge computing in modern IoT deployments

15.8 Minimum Viable Understanding

If you only have 5 minutes, here is what matters most from this chapter:

• The cost/scale pattern is useful, not automatic: Major computing eras moved toward cheaper, smaller, more numerous devices — mainframes to PCs, phones, and embedded sensor fleets. Use this pattern to ask which device categories may become economically viable next, not as a guarantee that every projection will happen.
• The mid-2000s brought a power-efficiency pivot: Across multiple process generations, slower voltage scaling, leakage, interconnect and thermal constraints reduced reliance on frequency growth alone. Multicore and specialised designs gained importance alongside continued integration, lower-cost MCUs and radios, networking and software-platform advances.
• Distributed beats centralized only for the right workload: Edge processing is compelling when local latency, bandwidth, privacy, safety, or outage tolerance matter. Cloud or server-side processing still fits fleet analytics, model training, long-term storage, and cross-site coordination.

15.9 The 10x Technology Cycle

Computing era progression: The following numbers are classroom approximations for comparing orders of magnitude, not market forecasts.

• Mainframes in the 1960s cost about $1M and were deployed at roughly thousands of systems.
• PCs in the 1980s cost about $2K, roughly 500x cheaper than a mainframe, and reached millions of devices.
• Smartphones in the 2010s cost about $200, roughly 10x cheaper than a PC, and reached billions of devices.
• IoT sensors in the 2020s can cost a few dollars, roughly 100x cheaper than a phone-class device, and make massive sensor fleets economically plausible.

Economic crossover: A workload that can run across many low-cost edge nodes may beat a central-only architecture on latency, bandwidth, and resilience. The point is not that every sensor replaces a server; it is that cheap local compute gives architects another placement option.

15.10 Related Chapters and Resources

IoT Overview Series:

• IoT Introduction - Getting started with IoT and the Five Verbs
• Device Evolution - Embedded vs Connected vs IoT products
• IoT History and Paradigm Shifts - Lessons from technology evolution
• Industrial IoT Fundamentals - Industrial IoT and Industry 4.0 context

Architecture Deep Dives:

• Edge Computing - Edge computing patterns
• Fog Computing - Fog computing fundamentals
• Edge AI/ML - Machine learning at the edge

15.11 Tiny Chips Changed Economics

A useful way to picture this shift is to compare where computing could live in each era:

• Mainframe era: one expensive machine served an entire organization
• PC era: businesses and homes could afford multiple computers
• Mobile era: individuals carried powerful connected devices everywhere
• IoT era: low-cost chips can disappear into products, infrastructure, and physical spaces

The important change is not just that devices became smaller. Computing also became cheap enough, efficient enough, and connected enough that it started to make economic sense to distribute intelligence across thousands of endpoints instead of concentrating everything in one central server.

That is why IoT feels different from earlier waves of computing: once a capable wireless microcontroller costs only a few dollars, adding sensing, local logic, and connectivity to everyday objects becomes a deployment decision rather than a custom engineering exception.

15.12 IoT Is a Compute-Placement Shift

Systems evolution is about where useful computation can live. In the mainframe era, computation was scarce and centralized. In the PC and mobile eras, computation moved closer to individuals. In the IoT era, small processors, radios, sensors, batteries, and cloud services let computation move into rooms, vehicles, factories, farms, infrastructure, and products.

The design question is therefore not “edge or cloud?” It is “which part of the job belongs at the device, gateway, edge server, cloud service, or human workflow?” A vibration sensor may detect a threshold locally, a gateway may aggregate samples, a cloud service may train a model, and a maintenance planner may decide whether to stop a line.

The technology cycles in the linked figure in Part 2 make the placement economics visible: falling unit cost and rising device scale moved useful computation closer to physical processes, while cloud coordination and human workflow remained part of the architecture.

For IoT design, the historical pattern becomes a placement checklist. A 1960s business could afford only a shared central machine, so applications were organized around scheduled access. A 1980s office could justify PCs because the unit cost fell enough to put computation on a desk. A 2010s product could assume a phone, battery, camera, GPS, and network in a user’s pocket. A modern IoT product asks whether a low-cost MCU, radio, and sensor package can now sit directly beside the physical process and remove delay, manual inspection, or unnecessary network traffic.

The answer is rarely “put everything at the edge.” A soil sensor may sample and sleep locally, a LoRaWAN gateway may buffer readings, a cloud service may compare fields over a season, and an agronomist may approve irrigation changes. The systems-evolution lesson is that cheap endpoint compute creates more placement choices, not fewer architecture layers.

• Device layer: Sensing, actuation, sampling, filtering, low-power sleep, and immediate safety behavior.
• Gateway or edge layer: Protocol translation, buffering, local rules, site-level dashboards, and operation during WAN outages.
• Cloud and fleet layer: Long-term storage, model training, device registry, OTA rollout, alert routing, and cross-site analytics.

15.13 Choose Placement by Constraint

A practical IoT architecture starts by naming the constraint that decides placement. Put computation near the device when response time, privacy, safety, radio airtime, or offline operation dominates. Put computation in the cloud when the task needs fleet history, large model training, cross-site comparison, heavy storage, or integration with enterprise systems.

The bill of materials also matters. A low-cost MCU is not a finished node. The design still needs the sensor, radio, antenna, power regulation, enclosure, mounting, certification, provisioning, and device-management cost. ESP32, nRF52, STM32, RP2040, and ARM Cortex-M devices make many edge patterns affordable, but the system cost depends on battery life, installation labor, support, and replacement cycles.

Start with a concrete workload budget. If a leak detector only needs to wake every few minutes, check a threshold, and publish a small MQTT or CoAP message, a low-power MCU plus a simple radio may be enough. If a camera must classify frames locally, the design may need an edge-AI module, a better power supply, heat management, and model-update storage. If a factory gateway aggregates 200 Modbus or OPC UA devices, it may need Linux, container isolation, local buffering, and a clear failover path to avoid losing events during a WAN outage.

Then price the whole lifecycle, not just the chip. A cheaper endpoint can become expensive if it shortens battery life, requires truck rolls, cannot accept OTA updates, or needs manual certificate replacement. A slightly more expensive gateway may be cheaper over five years if it reduces cellular backhaul, keeps a line running during cloud outages, and gives operators useful diagnostics. The right compute placement is the one that meets the physical constraint with the lowest credible lifecycle risk.

1. List the physical constraint. Identify latency, energy, bandwidth, privacy, safety, or environmental limits.
2. Assign the compute location. Decide what runs on firmware, gateway, edge server, cloud service, or operator tool.
3. Check the lifecycle cost. Include provisioning, certificates, OTA updates, diagnostics, field replacement, and decommissioning.

15.14 Distributed Systems Failure Modes

Moving computation outward creates resilience, but it also creates more state. A device can have a local reading, a gateway cache, an MQTT retained message, a cloud device twin, a time-series row, and a dashboard state that do not all update at the same moment. The architecture must define which layer is authoritative for commands, telemetry, alarms, and configuration.

That is why modern IoT systems pair cheap compute with protocol and operations discipline. BLE, Wi-Fi, Thread, LoRaWAN, LTE-M, MQTT, CoAP, OPC UA, and HTTP each carry different assumptions about latency, power, addressing, reliability, and security. A sound design includes backpressure, buffering, idempotent commands, timestamp discipline, quality flags, least-privilege credentials, and rollback-capable firmware updates.

The growing emphasis on performance per watt is visible in the failure model. Firmware now spends most of its life sleeping, then wakes for interrupts, ADC reads, radio joins, watchdog checks, and short publish windows. Gateways often translate between constrained field networks and IP services, so they must preserve timestamps, units, quality codes, sequence numbers, and source identity. Cloud services receive derived state rather than perfect truth, which means they need late-arrival handling, duplicate suppression, clock-skew tolerance, and explicit command expiry.

Security state also becomes distributed. A device may hold a hardware identity, a gateway may enforce topic or route policy, a cloud registry may own the device twin, and an operator console may issue commands. Certificate rotation, revoked devices, OTA rollback, and factory resets all cross these layers. Treating IoT as many small computers rather than one small sensor helps teams design the boring-but-critical paths: reconnect behavior, failed update recovery, queue backpressure, audit logs, and safe defaults when layers disagree.

• Command path: Separate requested, queued, delivered, applied, rejected, overridden, and expired states.
• Telemetry path: Preserve timestamp, unit, calibration, and quality metadata before aggregation changes meaning.
• Operations path: Monitor battery, signal strength, firmware version, queue depth, gateway health, and update status as first-class data.

15.15 Evolution of Internet of Things Systems

The Internet of Things (IoT) has evolved through several distinct phases, reflecting the increasing interconnectedness of devices, people, and systems. Each phase represents a significant technological milestone in the journey from simple networks to fully integrated IoT ecosystems.

15.16 Video: IoT World Forum Barcelona

15.17 Continue to the Next Part

Carry this evidence into IoT Evolution: Technology Cycles and Convergence, which begins with The 10x Technology Cycle Pattern.