“How many wells?”
It is the first question on every SCADA integration call and it sets the estimate off in the wrong direction, because the well count and the work have less to do with each other than anyone expects.
We pulled a tag inventory off one SCADA platform in one operator’s estate, classified it, and tried to attribute every tag to a well. Roughly five thousand tags, around twenty facilities, and a well count in the mid thirties. About seven tags in ten could not be attributed to any named well at all.
They belonged to the facility.
That share is one platform in one estate, and it is a floor rather than a census, since it covers only the sites we actually opened. A gas-heavy estate with compression and processing will run higher. A simple rod-pump field will run lower. The proportion is not the point. The direction is: facility tags outnumber well tags, usually by a lot, and almost nobody scopes for them.
What the other two thirds actually are
Nothing about that share is exotic. It is the ordinary equipment that sits between the wellhead and the sales point, and it is instrumented because somebody needs to know what it is doing.
Tank batteries with level, temperature, and interface measurement on each tank. Treaters and separation. Saltwater disposal skids with injection pressure and rate. Vapor recovery units. Gas meters at the sales point and at each inlet. Site power and comms. Cameras. Flare monitoring, where the operator put it in. On a gas-heavier estate you would add compression to that list, with suction, discharge, runtime, and fault status per unit.
Some of that equipment serves one well. Most serves six, or twelve, or everything on the pad. A tank battery does not belong to a well. It belongs to a facility, and the wells route into it.
Which means that if your unit of work is the well, you have scoped about a third of the job. Every one of those facility tags still has to be ingested, normalized, quality-checked, mapped to something and kept working, and the effort involved is indifferent to whether a well is attached. It costs what it costs.
That usually surfaces as a schedule problem rather than a budget one. A team scopes against the well count, meets the facility tags once ingestion starts, and has to decide where they go with the plan already committed.
Why the data model breaks
The well-centric hierarchy is the default because it matches how the business talks. Basin, field, pad, well. Everyone in the office already thinks that way, and most master data is organized that way. We have written before about building a single master well table, and that work is still worth doing.
It just has nowhere to put a tank battery.
Watch someone force it. The tank battery serves six wells, so you duplicate its level readings across all six and corrupt every aggregate built on top, or you attach it to one arbitrary well and make five look uninstrumented. Or somebody invents PAD3-COMMON and hopes nobody asks. Expect the third. It is the one that lets the pipeline finish.
Each of those is a data-quality decision made under schedule pressure by whoever was on the ticket, documented nowhere, surfacing months later as a number nobody can reconcile.
The fix is dull: make the facility a first-class entity, with its own identity and its own tag attribution, at the same level of care as the well. Wells attach to facilities. Facility measurements stay on the facility.
graph TD
subgraph forced ["Well-centric: the tank battery has nowhere to go"]
P1[Pad] --> W1[Well 1]
P1 --> W2[Well 2]
P1 --> W3[Well 3]
W1 -.duplicated.-> TB1[Tank battery level]
W2 -.duplicated.-> TB1
W3 -.duplicated.-> TB1
end
subgraph fixed ["Facility as a first-class entity"]
P2[Pad] --> F[Tank battery]
P2 --> V1[Well 1]
P2 --> V2[Well 2]
P2 --> V3[Well 3]
F --> L[Level, temperature, interface]
V1 --> T1[Wellhead measurement]
V2 --> T2[Wellhead measurement]
V3 --> T3[Wellhead measurement]
end
The left shape is where the duplicated aggregates come from. The right shape is boring, and boring is the objective.
If you are already planning the abstraction layer above your SCADA vendors, put the facility entity in it now. Retrofitting one after the well hierarchy has gone load-bearing is a different and much worse project.
The measurement point nobody assigns
One case causes more argument than the rest of them combined.
The sales meter is a facility tag. It is also the number the business actually cares about, because it is the one the purchaser pays against. Wellhead measurement, where it exists, is upstream of allocation, and allocation is what turns the sales meter into per-well volumes.
So the tag that matters most to the money is the one your well-centric model has the least idea what to do with. When someone asks why the SCADA-derived volumes do not tie to the production system, this is frequently where it starts. Not because the meter is wrong, but because the model attributed it somewhere convenient and nobody wrote that down.
What to do with this before you scope
Count the tags before you quote against the wells.
Start with how many exist, not how many look interesting. That total is the denominator for every other number in the project, and getting it honestly is most of the exercise. Then attribute what you can to a named well, using whatever identifier genuinely ties the two together in that system. Where no such identifier exists, record the well as unidentified rather than inferring a match. That bucket will be larger than anyone expects, and it is better as a known gap than a quiet guess.
Whatever is left over is the interesting part. Group it by equipment class and you have the list of things your facility model has to support, which is a list nobody has written down before.
Count the facilities while you are in there. Operators are routinely surprised by that number, because facilities get built, renamed, consolidated and abandoned without anyone keeping a register. The register only ever existed as a screen hierarchy, maintained by whoever was configuring it that year.
None of this needs the pipeline built. It needs read access and patience. A tag inventory changes when somebody configures new equipment, not by the hour, so a manual pull holds up long enough to scope against. Automating the collection can wait for the phase that actually needs it.
Where the counting belongs
The crawl-walk-run sequencing we recommend has a first phase that proves the pattern on a single asset. Put the counting at the front of that phase, before the architecture conversation rather than after it.
The reason is not thoroughness. It is that an architecture conversation held without the count is six people defending estimates, and the same conversation held with it takes twenty minutes. The count does not make anyone smarter. It just removes the thing they were guessing about.
Your number will not be seven in ten. It will be some other number, and you can have it by Thursday.