The Five Layers of an IoT System
Every IoT deployment, from a two-sensor pilot to a factory-wide rollout, is built from the same five layers:
- Sensing. The physical measurement — temperature, vibration, current, pressure, position, image.
- Edge processing. A microcontroller that reads the sensor, filters the signal and decides what is worth transmitting.
- Connectivity. The path from device to network: Wi-Fi, cellular, LoRaWAN, BLE, Ethernet.
- Ingestion and storage. The cloud endpoint that receives messages and the database that retains them.
- Application. The dashboards, alerts, reports and integrations that make the data useful.
Problems in any one layer surface as problems in the layer above, which is why diagnosing IoT systems requires visibility across all five.
Sensing: Getting a Trustworthy Measurement
The quality ceiling of the entire system is set here. No amount of cloud analytics recovers a measurement that was wrong at the point of capture.
What to specify
- Range and resolution. The sensor must cover the full operating range with enough resolution to detect the change you care about.
- Accuracy versus repeatability. For trend detection, repeatability often matters more than absolute accuracy.
- Environmental rating. Temperature, humidity, ingress protection, vibration and chemical exposure at the actual installation point.
- Calibration drift. How far the reading moves over a year, and whether field recalibration is practical.
Mounting is as important as the component. A correctly specified vibration sensor bolted to a flexible panel instead of the machine housing will produce confident, useless data.
Edge Processing: Deciding What to Send
The microcontroller does more than relay readings. Its job is to reduce a high-rate raw signal to the smallest set of messages that still answers the business question.
A vibration sensor might sample at 4 kHz. Transmitting that continuously is impossible on a battery and pointless on any connection. Instead the device computes RMS, peak and a few frequency bands locally, and sends a summary every minute — escalating to a full waveform capture only when a threshold is crossed.
Design rule: every byte transmitted costs power, bandwidth and storage. Decide at the edge what actually needs to leave the device.
Edge processing also determines behaviour when the network is down. A device that buffers to local flash and replays on reconnect turns a two-hour outage into a two-hour delay rather than a permanent gap in the record.
Connectivity: Choosing the Right Link
There is no default correct answer — the choice follows from power budget, data volume, range and who controls the site network.
| Technology | Best for | Trade-off |
|---|---|---|
| Wi-Fi | Mains-powered devices indoors | High power draw; depends on site IT |
| Ethernet | Fixed industrial installations | Cabling cost and routing |
| Cellular (LTE-M / NB-IoT) | Remote or mobile assets | Recurring data cost; coverage checks |
| LoRaWAN | Battery sensors over wide areas | Very low data rate |
| BLE | Short range, phone-adjacent devices | Needs a gateway to reach the cloud |
A frequent and expensive mistake is choosing Wi-Fi because it is convenient during prototyping, then discovering at deployment that the corporate network requires certificate-based authentication the firmware does not implement. Confirm the real network policy early.
Ingestion, Storage and the Application
On the cloud side, three concerns dominate.
Protocol and ingestion
MQTT is the common choice for constrained devices: it is lightweight, supports quality-of-service levels and handles intermittent connections well. HTTPS is simpler to debug and fine for devices reporting infrequently on mains power.
Storage shaped to the query
Sensor data is time-series data. A purpose-built time-series database handles retention policies, downsampling and range queries far better than a general relational schema. Decide retention up front — full-resolution data for 30 days and hourly aggregates for two years is a common and sensible default.
The application layer
This is where value is actually delivered: threshold alerts, trend dashboards, scheduled reports and integration into the systems your team already uses. A deployment that produces beautiful charts nobody opens has failed, regardless of how well the lower layers perform.
Common Pitfalls and Security
Power budget calculated too late
Battery life is determined by the sleep-current of the whole board and the duty cycle of the radio — not by the battery's rated capacity. Measure actual sleep current on real hardware before committing to an enclosure and a maintenance schedule.
No remote update path
Devices installed in the field will need firmware changes. Over-the-air update must be designed in from the first prototype, with a verified rollback path. Retrofitting it is painful and sometimes impossible.
Security treated as a later phase
At minimum: unique per-device credentials rather than a shared key, TLS for all transport, signed firmware images, and no debug interfaces left enabled in production. Device identity is the foundation — if every unit shares one key, compromising one compromises the fleet.
No plan for scale
A system that works with ten devices can fail at a thousand for reasons that never appear in the pilot: ingestion throughput, per-device provisioning, and the operational load of monitoring fleet health.
Conclusion
A working IoT system is a chain, and its usefulness is set by the weakest link. Most failures trace back to decisions made early — a sensor specified without checking the installation environment, a radio chosen before the power budget existed, or a device with no way to receive a firmware fix.
Design all five layers together, prototype with the connectivity you will actually deploy, and measure real power draw on real hardware. Getting those three right removes most of the risk from an IoT programme before a single unit ships.
