Insights / IoT / Connected Products
IoT Solution Anatomy: The Layers of a Remote IoT System
The three tiers of a remote IoT system, what lives in each layer, and the decisions about edge processing, device management and security that shape the build.
The short answer
A remote IoT system has three tiers. The device tier holds the sensors and actuators, the low-power agents that collect their data, any local edge server, and the gateway that moves data off site. The platform tier connects and manages devices, processes and analyses data, and secures the whole system. The application tier is what people use: apps and dashboards, integrations with other systems, and the services that deploy and manage everything. Most of the system is invisible to the user, and most project cost and risk sits there.
Key takeaways
- Users see devices and an app; most of the engineering sits in the layers between them.
- Decide early which data is processed locally and which goes straight to the cloud. It changes hardware, connectivity and cost.
- Device management decides whether a fleet can be updated and diagnosed without site visits.
- Treat every agent, actuator and edge computer as a potential entry point, and secure each one.
Why the anatomy matters before you estimate anything
A user sees a set of devices that measure or do something, and an application to control them and read their history. That is the tip of the system. Behind it sit data collection, local processing, communication links, device management, analytics, security and the services that keep it running.
Teams that scope only the visible parts usually underestimate the work. Knowing every layer, and what each must do for your product, is what makes a realistic estimate of time and resources possible. No single design fits every problem, so each layer has to be tailored to the product's requirements and constraints.
The three tiers of an IoT solution
IoT architecture is usually divided into three tiers by level of abstraction and closeness to the user. Each tier contains several layers or groups of services.
| Tier | Layers and services | What it does | The question it answers |
|---|---|---|---|
| Device tier (perception) | Things, sensors and actuators; data collection and edge computing; communication gateway | Measures and changes the physical world, collects readings, processes some locally and sends them on | What do we sense, what do we control, and where is data processed first? |
| Platform tier (network or intermediate) | Device management; data processing and analytics; security management | Connects and operates devices remotely, turns data into information and protects the system | How do we run, update and trust a fleet we cannot touch? |
| Application tier | Cross-platform user applications; integration; deployment; management | Presents the system to users and operators, connects it to other systems and allocates resources | Who uses the system, through which interfaces, and with which rights? |
- Agent
- A low-power component at the device tier that collects data from one or more sensors and sends it on at set intervals, either straight to the cloud or to a local server for processing.
The device tier: things, edge and gateway
Things, sensors and actuators
This layer holds everything that touches the physical world. Sensors turn a physical quantity into an electrical signal that is digitised and sent as data. That sounds simple, but sensors vary widely in complexity and cost, and the developer needs to understand how each one behaves. Actuators change the environment on command: water shut-off valves, controlled lighting, motors, cameras that move, robotic arms. Because they act directly on the world, they must be safe and precisely controlled, which makes them harder to design.
A thing can be much larger than a single sensor: a wearable, a vehicle, a plant, livestock, or a whole agricultural field. See sensors and actuators in IoT for how the sense and act loop is designed.
Data collection and edge computing
Agents collect sensor data and send it on once per time window. There are two common patterns, and choosing between them is one of the first architecture decisions.
| Pattern | How data flows | Suits | Example |
|---|---|---|---|
| Direct to cloud | Each agent sends readings to the cloud with no intermediate processing | Agents that are far apart, report infrequently and do not justify local infrastructure | Meter reading spread evenly across a network |
| Through a local edge server | Agents send data to a local server that accumulates, pre-processes and compresses it before forwarding | Agents close together that produce a lot of data or need a fast local response | Video surveillance; vehicles where all basic calculations run on board |
- CaptureCameras produce a continuous high-volume stream.
- Collect locallyA local server receives the streams instead of sending them all to the cloud.
- DetectThe server processes the video and detects changes in the scene.
- AlertIf needed, the server raises an alarm straight away, without waiting for the cloud.
- Compress and forwardCompressed video is sent to the cloud for storage and remote viewing.
The time-critical decision stays local; the cloud receives less data, later, for storage and viewing.
Communication: the IoT gateway
The gateway moves collected and organised data to a central server or cloud. It relies on physical channels and data protocols such as MQTT, CoAP, HTTP(S), AMQP, Zigbee and Z-Wave. The right channel depends on the solution, topology and location: Wi-Fi in a home, cellular networks across a city, satellite links in remote regions. Low-power cellular standards such as NB-IoT suit battery devices that report small amounts of data; see NB-IoT explained.
The platform tier: device management, data and security
Between the physical devices and what the user sees sits a set of services for controlling devices, processing data and keeping the system running and protected. These are usually provided by an IoT platform; how to choose an IoT platform covers that decision.
Device management
Device management makes it possible to connect, configure and operate devices, and to monitor, test, update and troubleshoot them without physical access. A common technique is the digital twin: a virtual model of each device in the cloud that keeps its own state and synchronises with the real device from time to time. Applications read the twin rather than the device, so the system stays current while devices send less data.
- ConnectThe device joins the platform with its own identity.
- ConfigureSettings are applied remotely and recorded against the device.
- Monitor and testHealth, connectivity and behaviour are observed from the platform.
- UpdateSoftware is updated over the air, without a technician on site.
- TroubleshootFaults are diagnosed remotely from logs and reported state.
Throughout the cycle, the digital twin holds the device's last known and desired state and syncs when the device reports.
Data processing and analytics
Turning raw readings into business information depends on the data and the goal. Machine learning, including deep neural networks, is often used for analysis, but choosing the right models and parameters takes experienced people.
Security management
Any device, whether an agent with a sensor, an actuator or an edge computer, can endanger the whole system. Security services should cover device identity based on certificates or similar mechanisms, secure network connectivity, secure software updates, authentication, access control and protection against data loss.
The application tier: apps, integration, deployment and management
The application tier is what end users and operators work with. It mediates information flows and controls changes in the system. This is where the solution takes its final form.
- Cross-platform user applications: web and mobile interfaces where people receive notifications, operate actuators and see the state of the system.
- Integration: services that connect parts of the system to each other and to external services, giving continuous access to the things.
- Deployment: services that allocate enough resources, for example in the cloud, to do the job. System efficiency and response time in a critical situation depend on getting this right.
- Management: tools for users and their rights, device monitoring and configuration, applications and databases, and the access rights of users and devices to the rest of the system.
Engineering trade-offs
Agents direct to cloud vs a local edge server
- You gain
- Direct-to-cloud agents need no local infrastructure; an edge server responds faster and sends far less data.
- You pay
- Direct agents push every reading over the network; an edge server is another device to install, power and maintain.
- Choose it when
- Direct to cloud for sparse, infrequent readings; an edge server for dense, high-volume or time-critical data.
Digital twin vs querying devices directly
- You gain
- A twin keeps state available when devices sleep or drop off, and reduces traffic from the field.
- You pay
- The twin can be stale, and the system must handle conflicts between desired and reported state.
- Choose it when
- Use a twin for fleets of battery or intermittently connected devices; query directly only for always-on devices with a few consumers.
Platform services vs building the platform tier
- You gain
- Platform services provide device management, data and security building blocks from day one.
- You pay
- They bring the vendor's data model, pricing and limits into your architecture.
- Choose it when
- Use platform services unless device behaviour, data ownership or cost at scale requires your own implementation.
Where processing runs, by system type
The examples in this article map to three placements of the first processing step:
| Device | Data volume | Response needed | First processing step | What the cloud receives |
|---|---|---|---|---|
| Distributed metering | Low, infrequent | Not time-critical | In the cloud | Raw readings from each agent |
| Video surveillance | High, continuous | Fast local alarm | Local edge server | Alarms and compressed video |
| Vehicle on-board systems | High | Immediate | On-board computer | Selected data, if any |
Decision rule: Start from data volume and the response time the physical process needs; place the first processing step as close to the source as those two require, and send the cloud only what it needs.
Questions to answer before you design
- List every sensor and actuator, what it measures or changes, and what must happen if it fails.
- For each data stream, record volume, frequency and the response time the process needs.
- Decide per stream whether it goes direct to the cloud or through a local edge server.
- Choose connectivity per site: Wi-Fi, cellular, low-power cellular or satellite.
- Define how devices are identified, configured, updated and diagnosed remotely.
- Name the users and operators, the interfaces each needs and the rights each has.
- List the external systems the solution must exchange data with.
Common mistakes
Scoping only the devices and the app
Device management, security and integration appear late and break the estimate.
Instead: Walk through all three tiers before estimating.
Sending every reading to the cloud
High-volume sources overload links and storage, and local alarms wait on the network.
Instead: Process dense or time-critical data at the edge and forward results.
No remote update path
Every fix needs a site visit, and known vulnerabilities stay open.
Instead: Design secure over-the-air updates into device management from the start.
Trusting devices by default
One compromised agent or edge computer becomes a way into the whole system.
Instead: Give every device its own identity and only the access it needs.
Where we've built this
We have described the build of an IoT system for managing solar energy usage. It is a practical illustration of the tiers in this article: equipment data at the device tier, a cloud platform in the middle and a dashboard for the people who use it.
Case studyA web service for monitoring and configuring residential solar systemsA connected solar energy management system whose monitoring app and cloud dashboard sit on top of data from field equipment, so all three tiers had to be designed together.Questions engineers ask
What are the main components of an IoT system?
Sensors and actuators that interact with the physical world, agents and edge servers that collect and pre-process data, a gateway that moves data off site, a platform for device management, analytics and security, and applications and integrations that people and other systems use.
How is IoT architecture structured?
Usually in three tiers: a device tier close to the physical world, a platform tier that manages devices and data, and an application tier where users, operators and other systems interact with the solution.
Was this useful?
Where this shows up in our work
ExpertiseIoT Product Engineering & Development ServicesDesigning all three tiers together, from sensors and gateways to the platform and the apps on top, is the end-to-end IoT product engineering our teams do.Where the devices are machines that have to keep running, the edge and device management decisions above carry more weight. See Engineering connected products for machines that keep running.
Apply this to your product