An IoT/SCADA platform for a small plant: what you need

Seven layers: from a controller register to a phone

The first layer is the equipment and its interface. Controllers, drives, meters and sensors mostly expose data over Modbus: RTU on a two-wire RS-485 bus or TCP on an ordinary network. With a documented register map, the rest is a matter of time. Without one, this is the most expensive part of the project — worth finding out before the equipment is bought.

The second is the gateway on site: the device that polls the bus and turns registers into events — an industrial Modbus RTU/TCP gateway, a Linux controller or a small computer in the cabinet. The third is telemetry transport: how data reaches the server and what happens without a link. The fourth is history: a database that can answer “what happened in March”.

The fifth is visualisation: site status and charts. The sixth is alarms: a rule such as “bay not responding for twenty minutes” that becomes a message to a person. The seventh is phone access: the same site state, opened from the road. On a small plant it is alarms and the phone that deliver most of the value; the mimic diagrams get opened once a month.

Offline operation and buffering: the site must not depend on the server

Platforms are designed in an office where the internet is always on, then installed where the mobile link drops every week. So the first decision: the site runs on its own. The line does not stop because the server is unreachable; a cycle starts, the event is written locally. The server is where data arrives, not where it is born.

The second decision is a buffer on the gateway’s disk rather than in memory: power on site fails more often than the link. Events are numbered on site and the server ignores repeats — otherwise every outage leaves duplicates in the history. Readings that refresh every minute can be lost; events involving money and stoppages cannot.

In the SamWash self-service car wash network we maintain, the terminals work exactly this way: they take payment without a link and resend transactions when the channel returns; fourteen million payment transactions have passed through that system. For a production line the principle is the same: a dropped link is a routine event, not an emergency. Buffer sizing, clock drift and deduplication are in the answer on telemetry where the link drops.

Off-the-shelf SCADA or your own platform

Boxed industrial SCADA is good where an operator sits in front of a screen and reacts in seconds: mimic diagrams, emergency sequences, certification. It costs as much as the equipment, is licensed per tag, and brings a Windows server, an integrator and an annual contract. In a workshop where data is looked at in the morning and when an alarm fires, most of that goes unused.

A custom platform is a Modbus poller, a time-series database, a handful of alarm rules and a web page. Its strength is that it speaks the language of your business: not “register 40012” but “line 2 was down for 47 minutes”, tied to units produced or material consumed. Its weakness is that it needs a person who understands how the system stops and how it comes back.

The third option, in practice the most common: open components assembled for the task — a ready-made collector and time-series database, your own rules and screens. No per-tag licence, and no illusion that “the box will do everything”. An honest comparison of custom versus boxed is in a separate answer.

When a Raspberry Pi is enough, and when it is not

A Raspberry Pi in the cabinet makes sense when the job is to poll the bus, accumulate and forward. It runs ordinary Linux with ordinary Modbus libraries, and ownership is cheaper because of the people who can work with it, not the board. The conditions under which it lives for years: a read-only system card, data in separate storage or straight to the server, automatic restart, and the Pi never being the only place the data exists.

It is the wrong choice where safety or equipment integrity depends on it: if a failure means “the pump ran dry” rather than “we did not count”, a certified industrial controller is needed. It is wrong where reaction must be in milliseconds, which general-purpose Linux does not guarantee. And it becomes a burden at dozens of sites: a fleet of Pis has to be updated and monitored, and at some point it is cheaper to move the logic to the server and leave a simpler gateway on site.

One warning about RS-485 on a computer: a USB converter adds latency and some Modbus RTU frames break apart — it looks like random timeouts. The cure is a converter with hardware direction control. What else breaks on the bus is in the answer on RS-485 on site.

Security: Modbus never faces the internet

Modbus has no encryption and no passwords: anyone who reaches the bus or the TCP port can read and write registers. So devices are never exposed to the internet directly. The gateway initiates the connection to the server itself over a VPN, and there are no inbound ports on site at all. This is the most important rule, and the one most often broken because “it is easier to set up that way”.

Second, roles: an operator acknowledges alarms, a technician sees diagnostics, the owner sees a summary across sites, and nobody writes to control registers from a phone without a separate confirmation. Third, an action log: who changed a threshold or paused a line, and when. Fourth, gateway updates with rollback, designed in from the start — otherwise every update is a site visit.

How to estimate the cost

The cost has three parts, and hardware is the smallest. The first is the equipment interface: documented Modbus connects quickly; a closed device means replacing the controller, adding external sensors or giving up on that section. That one fact moves the estimate more than anything else in the specification.

The second is the number of sites and people: ten sites bring roles, comparison between sites, consolidated reporting and a gateway fleet. The third, most often underestimated, is upkeep: thresholds change, alarms need tuning, devices get added. A system with nobody looking after it shows, a year later, a state nobody trusts.

The order that avoids overpaying: first collect data — data never collected cannot be recovered later. Then alarms: they pay back faster than any analytics. Only then screens with charts. Nobody honest will name a figure without a site survey: it depends on what is in the cabinet.

Common mistakes

Starting with the dashboard: a handsome screen on top of unreliable collection shows things that are not there. Buying equipment without a register map. Exposing Modbus TCP to the internet “temporarily”. Making the server the only place data exists. Alarms without hysteresis and delays: a hundred messages overnight, then everyone switches them off. RS-485 wired as a star instead of a line.

And the most expensive one: treating the platform as a project with an end date. Equipment changes, thresholds drift, people ask new questions. A platform with an owner lives for years; a platform that was “delivered” becomes, within a year, a screen nobody looks at.

Frequently asked