Your SCADA Knows Every Fifteen Minutes, Your Production System Knows Once a Day
The gap between sub-daily telemetry and the daily production number is where most unrealized operational value sits.
By John Wassilak
Two systems describe the same well. One of them sampled it ninety-six times yesterday. The other one recorded a single number.
Almost every unrealized operational insight at a mid-size operator lives in the space between those two figures. Not in a model, not in a new platform. In data you are already paying to collect and then throwing away by aggregation.
The daily number is not a mistake
Worth being fair to the production system before arguing with it.
Daily volumes exist because the business process needs a daily volume. Allocation runs daily. Royalty and joint-interest billing run monthly off daily. Regulatory reporting wants daily. Reserves work wants monthly. The entire commercial apparatus of an oil and gas company is built on a daily production number, and it has been for decades, correctly.
The production database is doing exactly what it was designed to do. The problem is that everyone then treats it as the record of what happened, when it is a summary of what happened, and summaries answer a narrow set of questions.
A day is a long time. A well that produced its normal volume yesterday might have run smoothly for twenty-four hours, or run at double rate for twelve and been down for twelve. Same daily number. Very different well.
What lives in the gap
Five recurring cases, all needing sub-daily resolution and none needing new instrumentation.
Contract compliance on delivery pressure. Gas contracts frequently specify a pressure at the delivery point, and gathering agreements sometimes carry fee adjustments or relief tied to whether the midstream party held their end. A daily average hides every excursion. Fifteen-minute data shows exactly how long line pressure sat above the contracted maximum and when. That is an auditable record for a commercial conversation, and it is sitting in SCADA already.
Compressor runtime against contracted availability. Compression is often contracted with an availability commitment. Verifying it requires knowing when the unit was actually running, which is a runtime tag sampled continuously, not a daily throughput number. The reconciliation is arithmetic once the data is in one place, and essentially impossible from summaries.
What the settings were during an event. After a workover, a failure, or an unexplained deferral, the engineer wants to know what the equipment was configured to do at the time. Setpoints, trip limits, control parameters. That history exists in SCADA and appears in no production report. This is why setpoint history belongs in a queryable form rather than being discarded as unchanging configuration.
Automated variance and a by-exception hit list. The daily routine at most operators is a person opening a report and looking for wells that moved. Sub-daily data plus a defined expectation turns that into a ranked list generated overnight, where the ranking accounts for how long a well was off rather than just how much it missed by. The difference between a well that produced 80 percent of expectation steadily and one that produced 100 percent for nineteen hours and nothing for five is invisible daily and obvious hourly.
Slow leaks and gradual losses. A tank that loses volume slowly, a line that develops a small leak, a meter that drifts. Each of these is undetectable in daily totals until it becomes large, and visible much earlier as a change in the shape of the sub-daily profile.
Why nobody is doing it
The reason is not that these ideas are novel. Ask any production engineer and they will tell you they would like all five.
The reason is that the two datasets live in systems that do not join, and making them join is the unglamorous work nobody funds.
SCADA identifies a well by whatever the automation contractor called it during commissioning. The production system identifies the same well by an API number, a lease name, or an internal key. Neither system holds the other’s identifier. Reconciling them is the master well table problem, and it is the actual prerequisite for everything in the previous section.
Then there is time. Sub-daily data has a timestamp, but which one: the instrument’s, the RTU’s, the gateway’s, or the historian’s? Production days start at a specific hour that may not be midnight and may not match what SCADA assumes. Getting a fifteen-minute series to line up correctly with a production day is a genuine piece of work, and getting it subtly wrong produces variance reports that are confidently off by one interval at the boundaries.
So the value sits there, visible to everyone, behind two pieces of infrastructure work that do not have an obvious owner.
Identity is the constraint, not resolution
The instinct when someone describes the gap is to reach for higher-frequency data. That is almost never the constraint.
Fifteen-minute data is plenty for every use case above. Some assets already produce one-minute or better. Nobody in that list needs a second-by-second stream, and the operators who chase higher resolution before solving identity end up with more data that still cannot be joined to anything commercial.
The work in order:
Resolve identity, so that a SCADA tag reliably maps to the same well the production system means. Then align time, deliberately and in one place, so a sub-daily series and a production day agree about what a day is. Then pick one use case from the list, build it end to end, and let it prove the pattern before anything else gets scoped.
Contract pressure compliance is often the right first one, because it has a dollar figure attached and a counterparty, which makes it easy to fund and easy to evaluate.
A worked example of the boundary problem
Time alignment sounds like a detail until you watch it produce a wrong answer, so here is the specific way it bites.
A production day at many operators starts at 7am, not midnight, because that is when the pumper’s day starts and when tanks get gauged. SCADA timestamps are in whatever the gateway is set to, which may be UTC, may be local, and may or may not observe daylight saving depending on how the box was configured years ago by someone who is no longer there.
Sum fifteen-minute volumes midnight to midnight and compare against a production day running 7am to 7am, and the daily discrepancy is not seven hours of production. It is the difference between the first seven hours of one day and the first seven hours of the next.
That is the trap. On a steady well those two nearly cancel and the error is small. It opens up only when the well’s rate changes across the boundary, which makes the discrepancy small, noisy, and rate-dependent rather than large and obvious. A seven-hour shortfall every day would be caught in an afternoon. An error that looks like scatter survives for months and gets blamed on meter performance.
It also moves twice a year. If the SCADA timestamp does not observe daylight saving and the production calendar does, the reconciliation shifts by an hour in March and back in November, which reads exactly like a seasonal effect.
The fix is unglamorous: convert everything to UTC at ingestion, store the production-day definition as data rather than as an assumption in a query, and test the boundary explicitly. Do it once, in the transformation layer, and every downstream consumer inherits it.
Where the gap should stay a gap
Not every question wants sub-daily data, and pretending otherwise is how these programs lose credibility.
Reserves, reporting, allocation, and anything that feeds a financial statement should keep running on the daily number. That number is governed, auditable, and reconciled, and replacing it with something derived from raw telemetry would be a downgrade in every respect that matters to those consumers. We have made the related point about measurement rigor: the value of a governed number is that everyone agrees on it.
Sub-daily data is for operational questions. What happened, when, for how long, and why. Keep the two lanes separate and both stay trustworthy. Blur them and you will spend the next year explaining why two systems disagree about production.
The daily number tells you the well made 84 barrels. The fifteen-minute data tells you it made them in nineteen hours and then stopped. Only one of those is a work order.