IIoT Calculations

How to Calculate IIoT, SCADA and Edge Connectivity Metrics Step by Step

The five formulas every OT engineer needs to size an IIoT rollout: coverage, connectivity rate, tag coverage, MQTT data volume, and historian storage, each with worked numbers and where the inputs come from.

Five formulas carry most of an IIoT and SCADA rollout. Edge gateway coverage and machine connectivity rate size how much of the plant is online, OPC UA tag coverage measures data depth per asset, MQTT data volume drives your telemetry pipeline sizing, and data historian storage sets your disk budget. Each pulls inputs from a specific system: the gateway console, the polling engine, the tag database, the broker config, and the historian retention plan. Get the inputs from the right source and the arithmetic is straightforward. Below, each formula is worked with real units and numbers you can reproduce with the Edge Gateway Coverage and Machine Connectivity Rate calculators.

Edge gateway coverage answers what fraction of scoped assets stream through a gateway. The formula is connected assets divided by total in-scope assets, times 100. With 42 assets connected out of 60 in scope, coverage is 42 / 60 x 100 = 70 percent. The connected count comes from your gateway management console; the denominator comes from the asset register, and you must strip out retired or manual equipment that was never in scope. The gap to a 90 percent target is 90 minus 70, which is 20 points, or 18 more assets. Do not count a gateway that is provisioned but not yet streaming.

Machine connectivity rate looks different because it measures live reporting, not deployment. Divide machines publishing data in the current polling window by total connectable machines, times 100. If 138 of 150 machines reported in the last 60-second poll, the rate is 138 / 150 x 100 = 92 percent. The numerator comes from the polling engine or PLC data availability log for the latest window, not a cumulative count. Because a machine can be deployed but silent, this number often sits 3 to 8 points below edge coverage. The PLC Data Availability calculator uses the same window logic against successful reads.

OPC UA tag coverage measures depth: how many of the tags you intended to expose are actually mapped and publishing. Divide mapped, active tags by target tags per asset, times 100. If an asset should expose 45 tags and 38 are live, coverage is 38 / 45 x 100 = 84 percent. Pull the mapped count from the OPC UA server address space and the target from the tag specification for that equipment class. This is the metric that catches a machine counted as connected under edge coverage while still missing temperature, vibration, or state tags that a predictive model needs. Run it per asset class, not plant-wide averaged.

MQTT data volume sizes your broker and cellular or cloud egress. Bytes per day equals number of tags times messages per tag per second times average payload bytes times 86,400 seconds. Take 500 tags, 1 message per second each, and a 120-byte payload: 500 x 1 x 120 x 86,400 = 5.18 billion bytes, about 5.18 GB per day per gateway before overhead. Add 20 to 40 percent for MQTT and TLS framing. The MQTT Data Cost calculator uses this to convert volume into a monthly bill; the input that swings it most is publish frequency, so confirm whether tags publish on interval or on change.

Data historian storage follows from tag count and sample rate. Bytes per day equals tags times samples per second times bytes per sample times 86,400. For 5,000 tags at 1 sample per second and 8 bytes per raw value, that is 5,000 x 1 x 8 x 86,400 = 3.46 billion bytes, roughly 3.46 GB per day, or about 1.26 TB per year uncompressed. Historians like PI or Ignition apply swinging-door compression that typically cuts this 5 to 20 times, so plan 60 to 250 GB per year for that tag set. The Data Historian Storage Cost calculator lets you sweep the compression ratio to bracket the disk budget.

Sequence these calculations so outputs feed the next input. Start with edge coverage and connectivity rate to fix how many assets and machines are truly online. Feed the live machine count into tag coverage to find total active tags across the plant. That active tag total, multiplied by your publish rate, feeds both the MQTT volume and historian storage formulas. A common check: if tag coverage says 84 percent but your MQTT volume was sized on 100 percent of target tags, you overbuilt egress by roughly 16 percent. Aligning the tag count across all four formulas keeps sizing consistent.

Watch units and windows, because that is where results drift. Coverage and rate are dimensionless percentages, but they use different denominators, in-scope assets versus connectable machines, so never compare them directly. MQTT and historian formulas both hinge on the per-second message or sample rate, and mixing per-minute with per-second inflates or deflates volume by 60 times. Payload bytes should be the on-wire size including topic and headers, not just the value. When you carry these numbers into the Tag Mapping Workload calculator, keep tags-per-asset consistent so the labor estimate matches the tag count your storage and bandwidth math assumed.

Published 2026-07-01.