Reaching your plant data without a rip-and-replace

In a lot of water and wastewater utilities, the same person is the operator, the maintenance department, and the IT person. There is no in-house architect and no dedicated OT team, and there is no appetite for a two-year integration project. What there is, usually, is a plant that has run well for thirty years on equipment that still does its job — and a growing list of people who want numbers out of it. The regulator. The board. The engineer doing a capacity study. The operator who would rather not drive out at two in the morning to read a level.

This is about getting at that data with what is already in the ground.

Why the question is being asked this year

One piece of dated context, and then we will leave it alone. Joint advisory AA26-097A, updated on 2026-07-22, names water systems among the sectors being actively targeted, and public reporting on it describes the access path as control equipment reachable from the internet rather than any novel exploit. Take that as the reason someone on your board has started asking about the boundary between the plant and everything else. The rest of this piece is about architecture.

Three problems that get talked about as one

Before choosing anything, it is worth being precise about where your data actually sits, because a small utility usually has three separate problems that get discussed as one.

In the control system, in a protocol from another era. Lift-station RTUs on DNP3. A pump drive or a chemical feed skid on Modbus. An OPC Classic server on a Windows machine nobody wants to touch, because the last time it was patched something downstream stopped working. The tags are there, measured every few seconds. They simply cannot be read by anything built this century.

In an instrument that only talks when someone is standing at it.A transmitter's configuration, its diagnostics, and its as-found and as-left values from the last calibration. That data lives inside the device and comes out through a handheld communicator on a loop cable, into a technician's notebook, and usually no further.

On a clipboard. Rounds are real data — a chlorine residual, a runtime hour, a pump that sounded different this week. Written on a form, filed in a binder, and effectively invisible from the moment it is filed.

These get bundled into one line item called “we need better data,” which is how they end up scoped as one project and then deferred as one project. They are three different problems with three different fixes, and none of them has to wait for the others.

Read what is already there

The first problem is a translation problem, not a hardware problem. The RTUs work. The register maps are correct. What is missing is something that speaks all of it at once.

RetroBridge is one runtime that connects OPC Classic, Modbus, DNP3, HART and ROC — roughly forty years of plant protocols — and serves the result as OPC UA. Any modern OPC UA client can point at it: a historian, a reporting package, a newer SCADA, an analytics tool. Nothing in the field is replaced, re-pointed, or restarted for that to happen. The bridge is one more client on gear that already serves several.

Two details matter more at a small utility than they do at a large refinery.

The first is that identifiers cross over intact. A DA item ID or a register-map tag path arrives as an OPC UA node carrying its real data type, access rights and browse structure — so you are not maintaining a translation spreadsheet for the rest of the plant's life, and the next person can find a tag by the name it has always had.

The second is timestamps. The time on a value is the device's own, not the moment the bridge happened to read it, and a source that supplies no timestamp is reported as having none rather than being stamped with the bridge's clock. If you are ever going to answer a regulator with this data, that is the difference between a record and a reconstruction.

The old Windows machine, meanwhile, stays where it is. The bridge talks to it the way it expects — COM on the same box, a poll on the same segment — and what crosses the plant network is a single OPC UA session on one TCP port.

Move it outward without an inbound door

Reading data locally is half the job. The other half is getting it to where the decision happens: the office, a hosted historian, an engineer's laptop, the phone of whoever is on call.

The common way to do that is a remote-access path into the plant. A VPN endpoint. A forwarded port on the utility's connection. A remote-support tool installed for a commissioning trip and never removed. Each of those is an inbound door, and each one has to be maintained, reviewed, and remembered by somebody. Where that somebody is one person who also runs the plant, the work competes directly with running the plant.

Flowgate runs the path the other way. A node inside the plant opens the connection outward to a node outside it, and data moves out over a session the plant itself initiated. There is no inbound port to forward and no inbound listener to configure, because that path does not have one. That is a statement about the shape of the data path, not a claim about what anyone can or cannot do to your network — every other control you have still matters.

Two limits worth stating plainly. It is one path, not all paths — a remote-support door that already exists does not close because a new path opened beside it. And the direction a session is initiated is not the direction data can move inside it; what leaves the plant, and what can reach back, is set by what that session is allowed to carry.

Around that path are the parts a one-person shop notices. Sign-in tied to the directory you already run, rather than another set of shared passwords. A timestamped, hash-chained record of what changed and who changed it. Store-and-forward buffering, so a cell modem at a remote lift station that drops for six hours backfills when it comes back instead of leaving a six-hour hole in the trend. And nodes chain, so a headworks, a treatment plant and a dozen outstations end up as one place to query rather than three logins and a spreadsheet that somebody stitches together on Friday.

The instruments, and the round

That leaves the data that never reaches a control system at all.

Zer0 is a battery-powered device that clips onto an instrument's terminals and translates its signal to an encrypted wireless link. RetroConnect is the application that meets it, so the phone or tablet already in a technician's pocket becomes the communicator. The instrument keeps speaking the protocol it has always spoken — HART first — and the cable between the technician and the device goes away. Leaving the device clipped on and working from a few feet away changes what a one-person round can cover.

The part that tends to matter a year later is the record. As-found and as-left values captured at the instrument, on the device, become data you can search — instead of a page in a notebook filled in by a technician who has since moved on.

Start with one thing you cannot see

None of this has to begin as a project.

Pick one thing you currently cannot see and put a path to it. The two lift stations that only tell you anything when they alarm. The chemical feed skid whose totals get transcribed by hand once a day. The calibration records you would have to reconstruct out of binders if somebody asked for them tomorrow. Read it where it is, carry it outward on a connection the plant opens, and leave the field equipment doing exactly what it does now.

Do that once and the second one is configuration rather than a decision. That is the point of not rebuilding: the work compounds instead of starting over. The plant you have is not the obstacle. It has been measuring what you need for decades. It has just never had anywhere to send it.