SCADA on a budget: when a Raspberry Pi is enough

Decide what you will look at every morning

Before choosing a system, answer a plain question: which three numbers will you check each morning. Usually it is revenue per site for the day, equipment downtime, and the list of errors overnight. Everything else is a pleasant extra that rarely gets opened.

That answer sizes the system more than the number of sites does. Three numbers a day can be delivered by a message and a single page. Full dispatching with mimic diagrams belongs where an operator reacts in real time — and at a car wash or a vending route nobody reacts in real time, they react in the morning.

Where a Raspberry Pi genuinely fits

The scenario where it runs for years: the equipment already has an interface — Modbus RTU over RS-485, or Modbus TCP — and something has to poll it regularly, assemble the data and pass it on. The Pi sits in the cabinet, powered from the same line, polls the controllers and writes to a database.

Why it rather than an industrial controller: hardware cost is not the main saving. The main saving is that it runs ordinary Linux, and therefore ordinary development, ordinary libraries, ordinary updates. Total cost of ownership drops because of the people who can work with it, not because of the board.

On reliability. A Pi does fail more often than an industrial controller, and usually it is the memory card. The cure is design, not faith: the system partition read-only, data written elsewhere or straight to the server, automatic restart — and above all, the Pi must never be the only place the data exists.

Where it stops being the right answer

When human safety or equipment integrity depends on it. If a control failure means not “we did not count the revenue” but “the pump ran dry”, you need an industrial controller with the matching certification, and that is not a place to economise.

When the response has to be real-time, that is, within milliseconds. General-purpose Linux gives no such guarantee in principle.

When the number of sites grows. Ten Pis in ten cabinets is a fleet: it needs updating, monitoring and somebody to look after it. At some point it becomes cheaper to move the logic to a server and leave something simpler and more robust on site.

What to do when the equipment exposes nothing

The most expensive case is a closed device with no documented interface. There are usually three options. Replace the controller with one that speaks Modbus — cleanest and dearest. Take the signals physically: a pulse counter, a current sensor on the pump line, a dry contact. That yields less data, but often enough: whether it ran, and for how long.

The third option is to ask the equipment supplier. Sometimes the interface exists and simply is not in the datasheet. That question costs one email and saves weeks.

A practical note for next time: ask “does this device expose data, and over which protocol” BEFORE buying equipment. That single answer moves the cost of automation more than anything else in the specification.

Where to start without overpaying

The cheapest useful first step is to collect data, even with nobody to show it to yet. Polling, a database, storage. A dashboard can be drawn later; data nobody collected will not appear retroactively.

Second step: alerts about what broke. Not a report — a message: “bay 3 has not answered for twenty minutes.” It pays for itself faster than any analytics, because it shortens downtime.

Third — and only third — a screen with charts. Not everyone gets there, and that is fine: if the first two steps are done, the business already has what matters.

Frequently asked