Industrial IoT

Industrial IoT architecture explained: sensor → gateway → MQTT → database → dashboard

By the Vera Automation engineering team · Updated

Short answer

A typical industrial IoT system has five layers: devices (sensors, meters, PLCs) produce data; an edge gateway reads them over protocols such as Modbus or OPC UA; a transport layer, usually MQTT over TLS, carries the data to a central platform; a time-series database stores it; and dashboards, alerts and integrations use it. Designing each layer for outages, security and multiple sites is what separates a reliable system from a demo.

The five layers

  1. Devices — sensors, meters, generators, PLCs, drives and building controllers that measure or control something physical.
  2. Edge gateway — reads each device over its native protocol, converts values to engineering units, timestamps them and buffers them locally.
  3. Transport — sends data from site to platform, most commonly with MQTT (a lightweight publish/subscribe protocol) over TLS, on fibre, LTE/GSM or LoRaWAN.
  4. Storage — a time-series database (for example TimescaleDB or InfluxDB) optimised for large volumes of timestamped readings.
  5. Applications — dashboards, reports, alerts, analytics, AI and integrations with ERP and business software.

Why MQTT?

MQTT was designed for unreliable, low-bandwidth links. Devices publish messages to named topics on a broker, and any number of applications subscribe to the topics they need. It supports quality-of-service levels for delivery guarantees, retained “last known value” messages and a “last will” message that signals when a device disconnects. The Sparkplug B specification adds a standard payload and state model for industrial use.

Designing for outages

  • Store-and-forward on the gateway so data is kept during link or power failures and uploaded later with the original timestamps.
  • Heartbeat monitoring so a silent gateway raises an alert rather than looking like a quiet site.
  • Local control stays local — PLCs keep running the process regardless of the cloud.

Designing for many sites

A consistent naming model is what makes a multi-site dashboard possible. Topics and tags follow a hierarchy such as company/site/area/device/measurement, so a new building or farm simply appears in the portfolio view with the same reports and alerts as the others. This idea — one structured namespace for all operational data — is often called a unified namespace.

Security by design

  • Outbound-only connections from site; no inbound ports.
  • TLS encryption and unique certificates or credentials per gateway.
  • Read-only access to control systems unless writing is explicitly designed and approved.
  • Separate OT and IT networks, with the gateway as the controlled bridge.
  • Role-based access to dashboards and audit logs of changes.

Cloud or on-premise?

Cloud platforms are quicker to deploy across many sites and easier to reach from anywhere. On-premise suits sites with strict data policies or poor connectivity. Hybrid designs — local storage and screens on site, summaries in the cloud — are common in manufacturing.

See how we apply this in industrial IoT integration and real-time dashboards.

FAQ

Frequently asked questions

How do I monitor multiple industrial sites from one dashboard?

Install a gateway at each site that publishes to the same central platform using a consistent naming structure. The dashboard then shows a portfolio view with drill-down per site, area and device.

Do I need a time-series database?

For more than a handful of devices, yes. Time-series databases store and query millions of timestamped readings far more efficiently than a general-purpose database table.

Is MQTT secure?

MQTT itself is only a messaging protocol. Used with TLS encryption, authenticated clients and topic-level permissions, it is suitable for industrial data.

Next step

Tell us what’s slowing you down.

Describe the process, the system or the site. We’ll come back with a clear, practical view of what can be automated — and what it would take.