Your flow computer already has the month.The truck is the only thing that moves it.

01 · The trip

The truck is your data path

A flow computer sits at the meter run. It reads differential pressure, static pressure and temperature, it runs the flow calculation continuously, and it builds its own records as it goes. By the time anybody in the office asks what that well did last month, the device at the pad has known the answer for weeks.

Some of it already moves. At a pad with a radio or a cellular modem back to SCADA, the supervisory system that polls your sites, a handful of live readings arrive without anybody driving anywhere, and they are the ones somebody configured years ago. The history is not in that poll, the event log is not in it either, and neither is the configuration. Nobody designed that. It accumulated one reasonable decision at a time into a data path that runs through a particular person, a particular laptop and a particular cable.

Suppose a meter run starts reading wrong early in the month and the route reaches that pad near the end of it. You have most of a month of production to re-state rather than a few days of it, and the device was not at fault, because it recorded exactly what it saw. Underneath that, a flow computer holds a bounded number of periodic and daily records and then begins overwriting the oldest ones, which is why the collection interval at most companies is set by the depth of the buffer rather than by anything anybody chose. Weather closes a lease road, a technician is off sick, and the records that rolled off the end are not late. When the truck is your data path, a missed trip does not make your records late, it makes them gone. The wellsite in this note is a composite of how these sites are generally arranged, not an account of any particular operator, site or incident.

02 · Four kinds of data

There are four kinds of data in that box

Before choosing anything, I would get precise about what “the data on the flow computer” actually means, because it is at least four different things and they are usually discussed as one.

Live readings are what the process is doing right now, and they are the part that already moves, because moving them is what SCADA was installed to do. History is what the device recorded for itself, hourly and daily records built from its own measurements on its own clock, and it is what a measurement review actually reads. Events and alarms are the explanation for that history, which is a setpoint written, a plate size changed, an alarm raised and cleared. Configuration is the definition of the measurement itself, the meter run setup, the plate dimensions, the calculation method and the input scaling, and the authoritative copy is whatever is in the box right now rather than whatever is in a folder on the shared drive.

Those four have four different destinations, which is also why your live and your historical data reach you by two different mechanisms, so when they disagree you are comparing a poll against a file rather than arguing about gas. In most budget conversations they get bundled into one line item about getting the data off the flow computers, so they get scoped as one project and deferred as one project, when they are four problems with four fixes and none of them has to wait for the other three. A fifth thing gets talked about as though it belonged in that list, and it is genuinely different, because the transmitters feeding the flow computer hold their own configuration, diagnostics and as-found and as-left readings, and none of that is in the flow computer at all.

So what makes the first four reachable and the fifth one not? A flow computer is a networked device that speaks a documented protocol, so it can be read from somewhere else, while a transmitter on a loop is not, which is why talking to one really does mean standing at it with something in your hand. At a gas wellsite that protocol is usually ROC Plus, and a FloBoss or a ROC800-series device answers it natively, the same way the vendor’s own software does, and it reaches the history, the events and the configuration rather than only the live readings. Modbus is almost always on the same pad, an older lease may have a DNP3 outstation as well, and each of those has been its own driver, manual and test rig, so the effort never compounds. That makes this a translation problem rather than a hardware problem. There are four kinds of data in that box, and the device already speaks a protocol that will hand over every one of them.

03 · What changes

You find out in days, not at month end

So what actually changes for you? The state of your data stops being a function of when the truck last arrived, so the same wrong meter run gets caught while it is still a few days of production rather than most of a month of it.

The other half of it is what that record looks like when you have to defend it. An hourly record that still carries the hour the flow computer assigned to it is a record, while the same number stamped with the time a collection process happened to run is a reconstruction, and the difference shows up the first time anybody has to account for a month. None of it changes what the device measures, though, because the plate, the transmitter, the calibration and the installation still decide whether the number is right, and moving a wrong number continuously gets you a wrong number sooner, which is useful and is not the same thing as a correct number.

There is a constraint here I would rather state than let you discover. A wellsite is not a plant network, so if the pad is on a licensed radio or a metered cellular link then pulling history is a bulk transfer over a path sized for a handful of live readings. What works is to read the live readings at whatever rate the link genuinely supports and to pull history, events and configuration on a schedule you choose, with a transfer that resumes rather than restarts when the link drops. None of this eliminates the trip either, because calibration, inspection and plate changes still bring somebody out. What changes is the reason for the drive. Read the box where it sits and a meter run that starts reading wrong is a few days to re-state instead of most of a month.

04 · How we help

How can we help?

The move is smaller than a capital project. Read the device where it already sits, over the protocol it already speaks, and carry what you read out over a connection the site itself opens. The reason that has not already happened at a lot of companies has very little to do with software, because there is no test wellsite and no sensible person experiments on a revenue meter.

So we built somewhere else to do the experimenting. RetroSimulation is a digital twin of natural gas field equipment, and one live model of the process is served at the same time over native ROC Plus, Modbus TCP, MQTT and Sparkplug B, with real gas-flow and compressibility physics underneath it rather than a canned playback, verified by independent third-party protocol clients. You build the collection schedule and the report that comes out the far end there, before anything is pointed at a real meter run. It will not prove your radio path or your power budget in January, because those are found on the pad.

RetroBridge is the read. It is one runtime that connects OPC Classic, Modbus, DNP3, HART and ROC+, and it serves the result as OPC UA, which is the interface a historian, a measurement package or a reporting tool already knows how to consume. Your identifiers cross over intact, still carrying their data type, their access rights and their browse structure. The time on a reading is the device’s own rather than the moment the bridge read it, and a source that supplies no timestamp is reported as having none. Nothing in the field is replaced, re-pointed or restarted, because the bridge is one more client on gear that already serves several. The same argument written for a plant rather than a pad is in Water and Wastewater Data Without a Rip-and-Replace.

Flowgate is the path out, and it runs that path the other way around from the usual one. A node inside the site opens the connection outward to a node outside it, so your data moves over a session the site itself initiated, and there is no inbound port to forward and no inbound listener to configure. Readings are held at the sending end while a link is down, so a pad whose cellular signal disappears for six hours backfills when it comes back rather than leaving a six-hour hole in the record. 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. Where the destination is an analytics or AI layer, the node publishes over MQTT and Sparkplug B into whatever that layer already consumes, which makes it a feed into that layer rather than a query surface on top of it. And I want to be clear about what kind of claim that is. It describes the shape of a data path rather than what the path withstands, it does not detect an intrusion and it does not undo one, and every other control you have still matters as much as it did before. It is one path and not all paths, so a remote-support door that already exists does not close because a new one opened beside it, and enumerating the doors you have is still the hard part of the work. And the direction a session is initiated in is not the direction data can move inside it, so what can travel back toward the device is a separate decision, taken and recorded separately. The full argument for why that asymmetry is worth designing toward is in Outbound-Only: What Can Reach Your Control Layer, which is honest about what the arrangement does not buy you.

The fifth thing has its own answer. Zer0 clips onto an instrument’s terminals and translates its signal to an encrypted wireless link, RetroConnect meets it at the other end so the phone already in your technician’s pocket becomes the communicator, and the as-found and as-left readings captured there become data you can search rather than a page in a notebook. The instrument carries on speaking what it always spoke, which is HART first.

And here is the boundary, because I would rather set it out myself. None of this is a measurement audit and none of it is a compliance position, since what your measurement group, your partners and your auditor accept as a record is a determination they make about a whole system in its operating context, and no piece of software arrives carrying that determination. Nothing here has been measured, scored or assessed against a standard either. And one pad working is not the same as the estate working, because if a design only works when somebody configures it by hand once per site, what has been proven is that it can be done rather than that it can be run. So the question worth putting to any approach, ours included, is what the four hundredth site would cost compared to the first.