How to Estimate Monthly Cellular Data for a SCADA Site
Choosing a data plan without estimating the site's real appetite is how fleets end up either paying overage every month or buying oversized plans across hundreds of sites. A defensible estimate works up from the poll cycle to a monthly figure, adds the overhead and the non-poll traffic that always sneak in, and leaves margin for the messy real world. This procedure is for whoever sizes plans before deployment and wants a number that survives contact with the carrier bill.
Estimate monthly cellular data for a SCADA site in one line: To estimate monthly cellular data for a SCADA site, compute bytes per poll, multiply by polls per day and by days per month, apply an overhead factor for protocol and IP headers, then add non-poll traffic such as keepalives, reconnects, and firmware. Add a margin for real-world messiness and size the plan to the total rather than to the bare payload.
Work Up From Bytes Per Poll to a Month
Start with the smallest unit and scale it. Estimate the bytes moved in one poll, which is the request plus the response for the registers you read, then multiply by the number of polls per day and by the days in the month to get the routine monthly payload. Written symbolically, monthly payload equals bytes-per-poll times polls-per-day times days-per-month, so each of those three levers scales the total directly and you can see immediately how a faster poll or a bigger register block moves the bill. This is the same poll arithmetic used when checking a live site, described in the procedure to verify data usage against polling math.
Be honest about the poll rate you will actually run, not the one you hope to run, because a site that polls every few seconds moves an order of magnitude more than one that polls every few minutes. If different points are polled at different rates, sum each group separately. The routine payload from this step is the floor of the estimate; everything else is added on top.
Add Overhead and the Traffic That Always Appears
Multiply the routine payload by an overhead factor, because every packet carries protocol and IP headers on top of the useful bytes, and on frequent small polls that overhead is a large fraction of the total rather than a rounding error. The overview of a cellular telemetry data plan covers why the billed figure always exceeds the raw payload. Then add the non-poll traffic: keepalives and heartbeats that hold the link open, reconnect handshakes on a link that drops, periodic firmware or configuration pushes, and any alarm or event reporting that fires outside the routine loop.
The non-poll traffic is where estimates go wrong, because it is invisible in a payload-only calculation and can be substantial on a marginal site that reconnects often. A site with weak signal and an eager reconnect policy can spend as much on handshakes as on data, so if the survey showed marginal signal, budget generously for reconnects. If the design uses report-by-exception or batching to cut routine traffic, credit that in the payload step but keep the overhead and non-poll additions, which do not go away.
Add Margin and Size the Plan
Add a margin on top of the summed estimate for the things you did not model: an operator pulling extra data, a temporary faster poll during a troubleshooting session, a month with more outages and more reconnects than usual. A plan sized exactly to a clean-month estimate will overage the first messy month, and overage charges usually cost more per byte than the headroom would have. Size the plan to the estimate plus margin, and for a fleet, size to the estimate of the busiest representative site rather than the average, or pool the data across the fleet if the carrier allows it.
Feed the sized plan back into provisioning, because the plan you choose here is the plan the SIM gets assigned when you provision and activate the SCADA SIM. An estimate that never reaches the provisioning step is just arithmetic.
Record the estimate and its assumptions so the number can be revisited when the site changes. When a platform such as Merobix trends the site's actual data against this estimate, a site that runs consistently above or below its sizing tells you the assumptions were off and the plan should be resized, which is far cheaper to catch in the trend than in a year of overage bills. The estimate sizes the plan; the trend proves the estimate.
Frequently Asked Questions
How much cellular data does a SCADA site use per month?
It depends entirely on the poll rate, the payload size, and the overhead, so there is no single figure. Work it up: bytes per poll times polls per day times days per month, multiplied by an overhead factor and added to non-poll traffic like reconnects and firmware. A slow-polling site with a lean payload can use very little, while a fast-polling site with a big register block uses far more.
Should I size the plan to my estimate exactly?
No, add margin. A plan sized to a clean-month estimate will overage on the first month with extra outages, reconnects, or a troubleshooting session that raises the poll rate, and overage typically costs more per byte than headroom. Size to the estimate plus a margin, and for a fleet, size to the busiest representative site or pool the data if the carrier permits.
Why does the carrier bill exceed my payload calculation?
Because payload is only part of the traffic. Protocol and IP overhead ride on every packet and can dwarf the payload on frequent small polls, and non-poll traffic like keepalives, reconnect handshakes, and firmware pushes adds more. An estimate that includes overhead and non-poll traffic matches the bill far better than one built on payload alone.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.