Solutions · Water and wastewater
Water SCADA that does not lose data when the link drops
Pump stations, wells and reservoirs are not in the same building, and often not even in the same district. In Bella SCADA the polling loop is a separate process, and readings are buffered when the centre is unreachable; they are queued back once the link returns.
In a water utility, distance is what breaks the system
Water and wastewater sites are spread out: the pump station is at one edge of town, the wells are down a country road, the treatment plant is on a different plot. What ties them to the control room is usually GSM or a VPN — and that link drops.
Two things happen when it does. First, the reading for that site is never written to history; the next morning there is a hole in the trend chart and that hole has to be explained in an audit. Second, the alarm reaches nobody — the pump stops at night and it is noticed in the morning.
In Bella SCADA the polling loop runs in a process (ScadaRuntime) separate from the web application. When the centre or Redis is unreachable, readings are held in a store-and-forward queue (10,000 records by default) and replayed once the link returns. The same split maps onto the IEC 62443 zone-and-conduit model: the field side and the web surface are separate processes.
To be straight about it: there is no panel screen showing queue depth yet. The counter is produced but nothing in the interface reads it; a runtime health screen is on the roadmap. Today queue state is read from the logs.
Typical architecture
Remote sites connect back to a centre. A dropped link is treated as normal, not as an exception.
1 · Remote site
The RTU or PLC at the pump station or wellhead: level, flow, pressure, pump run status, energy. Read over Modbus RTU-over-TCP, IEC 60870-5-104 or DNP3.
2 · Transport
A GSM router or a corporate VPN. Dropping is expected: the polling loop increments an error counter, writes to the queue and retries the connection; the process does not die.
3 · The centre
ScadaRuntime, a PostgreSQL historian and Redis live distribution on a single server. TimescaleDB compression and retention policies are implemented for long-term storage — but they ship disabled and are enabled at commissioning.
4 · Output
An operator screen per site, alarm history, flow and pump run-hour trends, scheduled daily or weekly report e-mails. Alarms are pushed to e-mail, a webhook, Telegram and an HTTP-based SMS provider.
Protocols used in this vertical
These are the three protocols we meet in water utilities. The direction column shows what the driver can do today; the validation column shows whether it has been tested against real hardware.
| Protocol | Typical device | Direction | Field validation |
|---|---|---|---|
| Modbus RTU-over-TCP | Serial RTUs behind a GSM router, level and flow meters | Read + write | Not done |
| IEC 60870-5-104 | Telecontrol RTUs, common across utility networks | Read + write (single/double command, set-point) | Not done |
| DNP3 | Outstations used across water and power infrastructure | Read + write (CROB / analog output) | Not done — needs a real outstation |
| Modbus TCP | PLCs and power meters at the treatment plant | Read + write | Not done |
The drivers are verified by build and simulation tests; none has yet been tested against real field hardware. We say this at quotation stage: the first task in a pilot is a connection test against your own device. The current matrix lives on the protocols page.
What ships in the box
Screens that do not change as site count grows; each pump station gets its own screen.
Site screen
One HMI screen per pump station or well: level indicator, pump status, flow, hand/auto position. Control rights can be limited per screen.
Alarms and call-out
Active alarms, acknowledge and shelve, alarm history. Notification channels are e-mail, webhook, Telegram and SMS. ISA-18.2 flood suppression is active: past 10 alarms in 10 minutes individual notifications stop and a single summary is sent when the flood ends.
Trends
Historical charts for level, flow, pressure and pump run hours. Logging interval is set per tag, so rarely changing signals do not fill the disk.
Reports
Alarm history and trend reports as Excel or PDF on a schedule. There is no free-form report designer for a utility's own template — that is a project line item.
Public tenders and domestic software
Most water and wastewater work is tendered by municipalities and utilities. The software is developed in Türkiye; the domestic-product certificate application is in progress and the certificate has not been granted yet. Once granted, it triggers the mandatory 15% price advantage in Turkish public procurement — something foreign competitors structurally cannot reach.
For the security clauses that recur in tender specifications we have a hash-chained audit log, a permission catalogue, 2FA and an IEC 62443-4-2 mapping; the detail and the honest list of open gaps are on the security and compliance page.
If the specification says "minimum X tags", read this carefully: the scale test has not been published. Tag and concurrent-client capacity are unmeasured; the load-test tooling exists but there is no results document. If a specification needs a number from us, we run the test first — we do not write an estimate.
Recommended package
Plant — unlimited tags, clients and screens; 11 field protocols; historian; ISA-18.2 alarm management; reporting and scheduled e-mail; REST API key. The licence bill does not grow as sites are added. The price band is on the pricing page.
If uninterrupted operation of the central server is contractual, the Critical Plant package adds hot-standby redundancy. The redundancy code exists and ships disabled; a real failover needs a second physical node, and the two-node scenario has not been run in the field to date.
Frequently asked
The GSM link was down for half an hour. What happened to that data?
If the break is between the centre and the site, readings are held in the store-and-forward queue and replayed when the link returns, so no hole appears in the historian. The queue holds 10,000 records by default and the oldest are dropped once it fills. If outage duration times polling rate exceeds that capacity, the polling period is lengthened.
How many sites can you monitor?
There is no licence limit — tags, connections and clients are unlimited in the Plant package. On performance we have measured and published: at 20,000 tags there was no queue overflow and no data loss. The limit is not the point count but the refresh rate — 1,000 tags refresh once per second, 20,000 roughly once every 26 seconds. Tell us how many points you need at what rate; we will run a further test on that scenario if required.
Can we send commands to the field?
Write is implemented in the Modbus, IEC 60870-5-104 and DNP3 drivers (single/double command, set-point, CROB). None of them has been validated against a real RTU, so commands are tested against your device during commissioning. Writes can be made to require an electronic signature — with a policy in place, an unsigned write is rejected.
Can we prove who changed a value?
The audit log is hash-chained, so altering an entry after the fact breaks the chain. User, timestamp and action are recorded. Exporting the audit log to a central WORM store is not implemented yet — it is one of the open items for IEC 62443 SL-3.
Should the SCADA server sit in the cloud or at the utility?
Either works. Where field commands are involved we recommend the server on the utility's own network; cloud deployments are usually chosen for monitoring-only scenarios. Monthly cloud hosting packages are on the pricing page.
Try it against your own pump station
Tell us the RTU brand and protocol on your site and we will build a sample pump-station screen that speaks it. We will run the link-drop scenario together.