The world has changed, your equipment has not.Everyone now wants data the equipment was never designed to give.

01 · Three destinations

The data has three places to be

Start with who is asking, because the same readings now have three separate places they need to go. The regulator wants them in a compliance report, on a schedule. The board wants them rolled up into the systems the rest of the business runs on. And your own people want them as history, for the capacity study and the pump that sounded different last month.

Today, every one of those deliveries is a person. Somebody reads a panel and fills in a form, somebody retypes the form into a report, somebody drives out to collect what a lift station already knows. The asks keep growing because everything above the plant now runs on data, and the plant itself was built decades before that was true. The asks are not going away, and every one of them lands on a person until the data can travel on its own.

02 · Read and reach

Read what is already there, and let the plant do the reaching

Here is the good news inside that: the world changed, and nothing in your plant has to, because nearly everything on the list is already being measured. Some readings sit in control equipment speaking protocols from another era, DNP3 in the remote terminal units at your lift stations, Modbus on a pump drive or a chemical feed skid, an OPC Classic server on a Windows machine nobody wants to touch. Some sit inside an instrument that only talks when a technician is standing at it with a communicator, which is where your calibration records live. And some never get past the clipboard on a round. The measurements exist. They were just never given anywhere to go.

So this is a translation problem rather than a hardware problem. Your equipment works and your register maps are correct, and what is missing is something that speaks all of it at once and somewhere for the result to go. Speaking all of it at once is ordinary software work, because those old protocols are documented and one piece of software can hold several of them and hand the result on in a modern one. Two details decide whether it is still worth having a year later. Your identifiers have to cross over intact, so nobody maintains a translation spreadsheet for the rest of the plant’s life. And the time on a reading has to be the device’s own rather than the moment something happened to poll it, because if you are ever going to answer a regulator with this data, that is the difference between holding a record and putting together a reconstruction.

Then there is getting it out of the plant. One piece of dated context, and then I will leave it alone. Joint advisory AA26-097A, updated on 2026-07-22, names water systems among the sectors being actively targeted, and the reporting on it points at control equipment reachable from the internet rather than any clever new exploit. That is usually why somebody on your board has started asking about the boundary between the plant and everything else. I wrote about that week from the inside in After the disconnect, and the money now proposed to pay for the fix is in Water cybersecurity funding.

The habit is to get data out by opening a path in, whether that is a VPN endpoint, a forwarded port on the utility’s connection, or a remote-support tool installed for a commissioning trip and never removed. Every one of those is an inbound door that somebody has to maintain, review and remember, and when that somebody also runs the plant, the work competes with running the plant. Run the path the other way around instead: a node inside the plant opens the connection outward, and your data leaves on an encrypted session the plant itself started, so there is no inbound port to forward, no inbound listener to configure, and nothing standing open for a stranger to find. That is a statement about the shape of the path and not about what anyone can or cannot do to your network, so every other control you have still matters exactly as much as it did before. This is a translation problem rather than a hardware problem, so the equipment stays where it is and the readings leave on a connection your plant opens itself.

03 · One system

Solve it for all of them, not one at a time

So how do you implement a system that solves this for every type of equipment you own, instead of one type at a time? The trap on this road is the pile of point fixes: a vendor tool that reads one protocol, an app that talks to one brand of instrument, a spreadsheet that holds one round. Each solves the thing in front of it and adds one more system somebody has to run.

What you want is one system that reads every kind of source you have, the control equipment, the instruments and the rounds, and delivers the readings everywhere they need to go on one path out. And you do not have to build it all at once. Pick one thing you currently cannot see and put a path to it, whether that is the lift stations that only speak when they alarm or the calibration records you would be reconstructing out of binders. Read it where it already is, leave the equipment doing exactly what it does now, and the first path buys back a drive and buys you the argument for the second. Put a path to one thing you cannot see, and the second one is configuration rather than a decision.

04 · How we help

How can we help?

Everything above holds for whoever you buy from. Here is the part we build: one system in three pieces, one for each kind of source your plant has.

RetroBridge is the answer to the protocol problem. It is one runtime that connects OPC Classic, Modbus, DNP3, HART and ROC+, which is roughly forty years of plant protocols, and serves the result as OPC UA, so a historian, a reporting package or an analytics tool can read a thirty-year-old lift station. It meets both of the tests above, on your identifiers and on the time a reading carries. Nothing in the field is replaced, re-pointed or restarted for that to happen. The old Windows machine stays exactly where it is, and the only thing that crosses your plant network is a single OPC UA session on one TCP port.

Flowgate is the way out. A node inside the plant opens the connection outward to a node outside it, over a connection that is encrypted and secure, so there is no inbound port to forward and no inbound listener to configure. As above, that describes the shape of the path rather than what anyone can do to your network, and there are two limits I would rather state plainly than leave you to discover. This is one path and not all paths, so a remote-support door that already exists does not close because a new path has opened beside it. And the direction a session is initiated in is not the direction data can move inside it, so what leaves the plant, along with what can reach back, is set by what that session is allowed to carry.

The parts built around that path are the ones a one-person shop tends to notice. Sign-in binds to the directory you already run rather than to another set of shared passwords, and changes land in a timestamped, hash-chained record of what changed and who changed it. Store-and-forward buffering means 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 your trend.

Zer0 and RetroConnect meet the instrument at the ground. Zer0 is a battery-powered device that clips onto an instrument’s terminals and translates its signal to an encrypted wireless link, and RetroConnect is the application that meets it at the other end, so the phone already in your technician’s pocket becomes the communicator, with the instrument still speaking the protocol it has always spoken, which is HART first. What matters a year later is the record, because as-found and as-left readings are captured at the instrument and become data you can search instead of a page in a notebook.

05 · Sources

Sources

• CISA, joint cybersecurity advisory AA26-097A (updated 2026-07-22)