What an industrial IoT system is made of, from sensors to dashboard

Someone has asked you to “add IoT” to a plant, a packing line, a set of pumps or a cold store, and the proposals on your desk describe the same thing in different words. Underneath the vendor names, almost every industrial IoT system is built from the same handful of layers. Knowing what they are lets you read a proposal, spot the missing piece, and keep the project small enough to succeed.

The layers of an industrial IoT system

From the machine upwards, the layers are: sensors and actuators on the equipment; controllers and gateways that read them and produce messages; the plant network that carries those messages; a broker or a historian that receives and stores them; and the dashboards, reports and alerts that people actually look at. Each layer changes the shape of the data, and each boundary between layers is a place where a project can stall.

The rest of this article takes the layers one at a time. The sequence is also a reasonable order to design in, because a decision at a lower layer constrains everything above it.

Sensors and actuators on the machine

A sensor turns a physical quantity into a signal. In a plant the common ones are temperature (thermocouples, resistance thermometers, or integrated digital sensors), vibration (accelerometers mounted on bearings and motors), current (clamp transformers around a supply cable), pressure, flow, level and simple contacts that report whether something is open or closed.

The signal comes out in one of a few standard forms. Analog sensors give a voltage or a current in a defined range; the four to twenty milliamp current loop is the classic industrial one because a broken wire reads as zero and is easy to detect. Digital sensors talk over a wired bus, either a simple serial one on the sensor board or an industrial fieldbus, and hand over a number instead of a level to be interpreted. Wireless sensors package the same reading into a radio message and run on batteries, which makes retrofitting far easier and adds a power budget to think about.

An actuator is the reverse: a valve, a variable-speed drive, a relay, a damper. Most industrial IoT projects start with sensing only and leave actuation to the existing control system. That is the right instinct. Reading a machine changes nothing about how it runs; writing to it can, and that belongs with the control engineers.

The sensor layer is where “retrofit” is decided. A vibration sensor glued to a bearing housing, a current clamp on a cable and a temperature probe on a casing can all be fitted without opening the machine, which is why condition monitoring projects rarely need equipment replaced.

Controllers and gateways

Something has to read the sensor, attach a time, and turn the result into a message. In a modern plant that job may be done by the PLC that already controls the machine, by an edge gateway installed for the purpose, or by a small sensor node with its own microcontroller and radio.

A PLC is the controller that runs the machine’s logic. Many can publish their internal values directly, either through an OPC UA server built into the controller or by sending MQTT messages, and where that is available it is the cleanest source of machine data because the values are already scaled and named.

An edge gateway is a small industrial computer that sits next to the machines, speaks the protocols the equipment uses on one side (fieldbuses, serial links, older controller protocols), and speaks IP protocols on the other. It is the usual answer when the equipment predates any of this, or when a site has a mix of controllers from different decades. Gateways also do the first bit of processing: scaling raw values into engineering units, filtering noise, aggregating a fast signal into a summary, and buffering data when the network is down.

A sensor node is the wireless case: a battery-powered board with a sensor, a microcontroller and a radio such as LoRaWAN or a cellular module. It wakes, reads, sends and sleeps. Its messages go to a network server or a gateway that decodes them into something the higher layers understand.

The essential output of this layer is a message with three parts: which measurement (a tag name that means the same thing everywhere), the value, and when it was taken. Get the naming agreed early. A tag called “Temp1” on one line and “Temperature_Motor” on another creates work for every layer above.

The plant network and the broker

Messages need a path. On the plant floor that path is usually wired Ethernet, sometimes Wi-Fi, and for remote or mobile assets a cellular link or a low-power radio network. What matters is that the plant network is segmented from the office network and from the internet, with a firewall between, so that a sensor gateway cannot see the finance server and a compromised laptop cannot see a controller.

At the top of the network sits a broker. Most industrial IoT systems use MQTT for this: gateways and controllers publish messages to named topics, and anything that needs the data subscribes to the topics it cares about. The broker decouples producers from consumers. A new dashboard, a new analysis tool or a new alert engine subscribes without anyone reconfiguring the gateways, which is the main reason the pattern has become standard.

Where the plant already has an OPC UA infrastructure, the broker may sit alongside it: OPC UA for structured, on-demand access to controller data, MQTT for fan-out to everything else. The article on OPC UA and MQTT in factories covers how the two divide the job.

Storage, dashboards and alerts

A historian, or a time-series database, stores every value against its tag and timestamp. It is the memory of the system. A dashboard queries it to draw trends; an alert engine watches the live stream or the recent history and sends a message when a value crosses a threshold or behaves oddly; a report summarizes a shift or a week.

Dashboards are where projects are judged, and they are the easiest layer to get wrong by doing too much. A good first dashboard shows a handful of values that somebody has agreed to act on, with clear units, the time of the last reading, and an obvious way to see whether the data is stale. Colors and gauges come later.

Alerts need the same restraint. An alert that fires often is switched off within a month. Start with thresholds that catch only clear problems, review what fired and what was missed, and adjust. The predictive maintenance article goes into how thresholds are set for vibration and temperature in particular.

The cloud question lives at this layer. Storage and dashboards can run on a server in the plant, in a company data center or in a cloud service. Each is a legitimate choice, and the edge computing against cloud computing article gives a method for placing each job. The lower layers do not change, so the decision can be made on cost, skills and who needs to see the data, rather than on anything technical about the sensors.

Where systems usually go wrong

Projects rarely fail at a layer. They fail at the boundaries between them.

A sensor is bought before anyone has decided what will read it, and it turns out the nearest controller has no spare input and no communications port. A gateway is installed on a network segment the broker cannot reach, and the firewall request takes longer than the rest of the project. Two lines publish the same measurement under different tag names, and the dashboard shows one of them. A dashboard is built for a manager who never opens it, while the person who could act on the data has no login.

Three habits prevent most of this. Draw the five layers for your specific project before buying anything, and write in who owns each boundary. Start with one machine and one measurement, take it all the way to an alert that somebody acts on, and only then scale. And name things once: a tag naming convention agreed in the first week saves months.

An industrial IoT system is not a product you buy. It is these five layers, chosen and connected for your site. Once you can see them, every proposal becomes easier to read and every gap easier to spot.