Real-Time Data and Measurement Data Aren't the Same Problem

Written by By AUTOSOL | Jul 21, 2026 5:58:52 PM

"Getting data out of the field" sounds like one problem. In practice, most oil and gas operators are solving two different ones at the same time, and they don't behave the same way.

The first is real-time data: the live status of a valve, pressure reading, a command to open or close something. The second is measurement data: the record used to determine how much gas or liquid actually moved, and who owes whom for it. Both come off similar-looking field equipment. The requirements underneath them are not similar at all.

What real-time data optimizes for

Real-time SCADA data exists to give an operator current visibility and control. A master station polls a device, or the device reports on an exception, and the value on the screen reflects what's happening right now. If a poll gets missed, the fix is simple: the next one is seconds away. Freshness matters more than any individual data point. This is the model most SCADA protocols, DNP3, Modbus, and OPC UA, were originally built around, and it's the right model for the job it's doing.

What measurement data optimizes for

Electronic Flow Measurement (EFM) data is a different problem entirely. It's the record used for custody transfer, the point where gas or liquid changes ownership between two parties, and both sides need to agree the number is right. That changes what the data actually has to do. It's not enough for it to be current. It has to be complete, and it has to hold up after the fact: what was measured, when, under what configuration, with what adjustments, if any.

That completeness requirement is the key difference from real-time data. In an EFM context, a missing interval isn't something the next poll quietly fixes. It's a gap that has to be identified and accounted for, because both parties to the transaction are relying on it. This work typically happens at or near the meter, on a flow computer calculating volumes from differential pressure, temperature, and other measured inputs, whether the commodity is gas or liquid.

Why the distinction matters for your architecture

A system tuned purely for real-time responsiveness, one that assumes any gap self-heals on the next poll, is not automatically going to give you the complete, defensible record that measurement accounting requires. And a system built entirely around measurement rigor is often more than an operator needs for straightforward monitoring and control. Treating these as the same problem, and picking one architecture to serve both, is usually where gaps show up.

It's bigger than SCADA or measurement

Getting this distinction right isn't just about serving today's control room or today's measurement audit. It's about what you can do with the data afterward. Analytics, enterprise reporting, and increasingly AI and machine learning applications are only as good as the data underneath them, and that data has to be collected correctly at the source, respecting what each type of data actually requires, before any of that downstream work is possible. A live value collected with the wrong assumptions, or a measurement record with silent gaps, doesn't get more useful the further downstream it travels. Whatever you want to do with your OT data next, the foundation gets laid at the point of collection.

Where ACM and eACM fit in

AUTOSOL Communication Manager (ACM) is built to handle both without forcing a choice: real-time polling and control alongside EFM data collection from flow computers, across both gas and liquid measurement systems. Operators running both real-time monitoring and custody transfer measurement off the same equipment don't need two separate systems to collect it. eACM, AUTOSOL's edge platform, extends that same dual capability closer to the field, so the distinction between real-time and measurement data doesn't have to disappear just because processing has moved to the edge.

Where to start

If you're not sure whether your current data layer is actually built for both jobs, or just happens to be doing both because that's how it's always worked, that's worth a closer look, especially if you're thinking about what comes next for that data. Reach out to AUTOSOL, your trusted communication advisors, to talk through how your architecture handles real-time and measurement data today, and where ACM and eACM might fit into that picture.