IoT System Architecture: Layers, Requirements and Common Mistakes

Why architecture matters more than sensor choice

Many IoT projects start with a simple question: which sensor should we buy? What decides whether a system is still useful several years later, however, is its architecture: how data travels from equipment to the platform, where it is stored, who can access it and how it connects to real business processes such as maintenance or production planning.

A sound architecture allows sensors or connectivity to be replaced later without rebuilding the entire system. A weak one typically ends in a collection of isolated solutions, each with its own dashboard, database and logic, that nobody can maintain as a whole.

A layered reference model

Splitting the system into independent layers gives operations, IT and management a shared vocabulary. The following model is a common framework for industrial IoT:

1. Devices and sensors

Temperature, vibration, current, pressure and level sensors, meters, and PLCs or machines that already produce data. Key questions at this layer are accuracy and sampling rate, power supply and battery life, IP rating and mounting conditions. In legacy equipment retrofit, much of the work happens here, with add-on sensors that do not interfere with the machine control.

2. Connectivity

The choice depends on range, data volume, energy budget and existing infrastructure: LoRaWAN for battery-powered sensors with small payloads, NB-IoT or LTE-M for wide coverage, Wi-Fi and industrial Ethernet for high data rates, and Modbus or OPC UA at machine level. The architecture should stay network-neutral so that no single operator becomes a hard dependency.

3. Edge and gateway

Gateways translate field protocols into IP-based protocols. An edge layer can filter and aggregate data, buffer it during network outages and run simple logic such as local alarms without depending on the central server.

4. Ingestion and messaging

Publish/subscribe protocols such as MQTT decouple data producers from consumers. Topic structure, QoS levels, device authentication and behavior on reconnect need careful design here, because they are hard to change once hundreds of devices are deployed.

5. Platform and storage

Telemetry is time-series data, and time-series databases handle range queries and aggregation far better than general-purpose relational schemas. Platforms such as ThingsBoard combine device management, an asset model, a rule engine and dashboards in one package. A data retention policy should be defined from the start rather than after the disk fills up.

6. Analytics

This ranges from simple threshold rules through trend and anomaly detection to predictive maintenance models. It is sensible to begin with transparent, explainable rules and add more complex methods once enough clean, labeled data exists.

7. Applications and integration

Value appears when data leads to decisions and actions: automatically creating work orders in the maintenance management system, feeding energy consumption into the ERP, or showing line status to the shift supervisor. These integrations use REST APIs, webhooks or workflow automation tools.

Data model, naming and interfaces

The layers only work together if they share a consistent data model. In practice this means agreeing early on a few conventions that every device, gateway and integration follows:

• Asset hierarchy: for example site, area, line, machine and measuring point. Telemetry is attached to a position in this hierarchy, not only to a device serial number, so that a replaced sensor continues the same history.
• Naming and units: one scheme for telemetry keys (for example motor_temp_c instead of a mix of vendor names), with units and scaling documented and applied at the edge or in the decoder, not in each dashboard.
• Timestamps: device or gateway time in UTC, with a clear rule for what happens when buffered data arrives late.
• Metadata: installation date, calibration status, firmware version and responsible person stored as attributes, so that the system can answer questions about itself.

Interfaces between layers should rely on open, documented formats such as JSON over MQTT or HTTP, and OPC UA where machines already provide it. A thin decoding step that converts vendor-specific payloads into the common model keeps device diversity from leaking into the platform and applications. When a sensor model changes, only the decoder needs to change.

Non-functional requirements

Most serious problems in operation come not from missing features but from neglected non-functional requirements:

• Security: a unique identity per device, encryption in transit, segmentation between OT and IT networks, and least-privilege access for users and integrations.
• Scalability: a system designed for ten devices should grow to hundreds and to several sites without redesign.
• Battery life: reporting interval, radio technology and coverage quality directly drive the cost of field maintenance.
• Maintainability: documentation, consistent naming, monitoring of the system itself (for example devices that have stopped reporting) and a tested backup routine.
• OTA updates: secure firmware updates without site visits, which matters especially for remote sites and mines.
• Data ownership: who owns the data, where it is stored and whether it can be exported in an open format if the platform changes.

Cloud, on-premises or hybrid

Where the platform runs is one of the fundamental architecture decisions. The table below gives a qualitative comparison:

Criterion	Cloud	On-premises	Hybrid
Speed of setup	High	Medium, needs hardware and configuration	Medium
Control over data	Depends on provider and contract	Fully with the organization	Sensitive data local, the rest in the cloud
Dependency on internet	High	Low	Local operation continues during outages
Maintenance effort for internal team	Low	High	Medium
Typical fit	Pilots and distributed small sites	Strict security or regulatory environments	Many multi-site industrial organizations

Whichever model is chosen, the interfaces between layers should be the same, so that a later move from cloud to on-premises, or the reverse, does not require changes at device level.

Common architecture mistakes

1. Starting with the dashboard: designing visualizations before the data model and naming conventions leads to repeated rework.
2. Vendor lock-in: proprietary formats and missing open APIs make it hard to change sensors or platforms later.
3. Ignoring network outages: without buffering at the edge, data from outage periods is simply lost.
4. Security as the last step: retrofitting security into a running system is much harder than designing it in.
5. No operational owner: if nobody is responsible for responding to alarms, even a well-built system goes unused.
6. Collecting everything without a purpose: data without a clear question only adds storage cost and complexity.

Conclusion

An industrial IoT architecture should start from the business goal and the operational process, then define layers with clear, standards-based interfaces. Non-functional requirements, particularly security, data ownership and maintainability, belong in the design from day one. For more on the implementation approach, see industrial IoT and IIoT consulting, or use the contact page to discuss the conditions of your own project.