Planner inputs
Example data
| Scenario | Sensors | Updates/sec | Payload (bytes) | Overhead % | Redundancy × | Compression × | Edge % | Peak × | Retention (days) |
|---|---|---|---|---|---|---|---|---|---|
| Example Tower Retrofit | 450 | 0.2 | 320 | 18 | 1.25 | 1.5 | 20 | 1.8 | 30 |
| Dense tunnel build | 1200 | 1.0 | 420 | 22 | 1.50 | 1.80 | 25 | 2.20 | 14 |
| Crane monitoring program | 90 | 0.5 | 260 | 15 | 1.20 | 2.00 | 30 | 1.40 | 90 |
Formula used
The planner converts telemetry into a peak backhaul requirement, then sizes gateways by both throughput and device limits.
| Raw_bps | = Sensors × UpdatesPerSec × PayloadBytes × 8 |
| Avg_bps | = Raw_bps × Active% × (1+Overhead%) × Redundancy ÷ Compression × (1-Edge%) × (1+Growth%) |
| Peak_Mbps | = (Avg_bps ÷ 1,000,000) × PeakFactor |
| ReqBackhaul_Mbps | = Peak_Mbps ÷ Efficiency% |
| Gateways | = max(ceil(ReqBackhaul_Mbps ÷ GatewayCapacity), ceil(Sensors ÷ GatewaySensorLimit)) |
| Storage_GB | = (Avg_bps ÷ 8) × 86400 × RetentionDays ÷ 1e9 |
| Downtime_min/year | = (1 - Availability%) × 525600 |
How to use this calculator
- Enter your sensor count, update rate, and typical payload size.
- Set active percentage if devices report intermittently.
- Add protocol overhead and redundancy for your reliability plan.
- Apply compression and edge reduction if you aggregate on-site.
- Choose peak factor for bursty operations and synchronized reporting.
- Provide gateway limits and backhaul efficiency to size capacity.
- Set retention days and optional costs for budget estimates.
- Press Calculate, then export results as CSV or PDF.
Professional guidance: planning a digital twin network
Digital twin programs succeed when the physical jobsite and its data pipeline are planned together. A network plan should start with the operational questions: What must be detected, how fast must it be detected, and who consumes the insight. Those answers translate into sensor counts, reporting cadence, payload size, and acceptable latency. When these inputs are clear, connectivity becomes an engineering problem rather than guesswork.
In the calculator, begin with the device population and update rate. For example, the “Example Tower Retrofit” scenario uses 450 sensors sending 0.2 updates per second with a 320‑byte payload. Before overhead, that is 450 × 0.2 × 320 × 8 = 230,400 bps, or about 0.23 Mbps. Real deployments include encryption, acknowledgements, and metadata, so the overhead factor inflates the stream. Redundancy then protects continuity by duplicating paths or mirroring critical feeds.
Optimization levers matter because construction sites are bursty. Compression reduces repetitive telemetry, while edge reduction filters noise and converts high‑rate raw signals into events. A peak factor captures synchronized bursts such as shift starts, equipment checks, or safety drills. For link sizing, the calculator applies backhaul efficiency to account for usable throughput after quality controls and shaping.
Gateway sizing should balance bandwidth and device limits. If each gateway can reliably forward 50 Mbps and associate with 250 sensors, the calculator selects the higher of the throughput‑based and sensor‑based counts. This avoids designs that pass bandwidth checks but overload radio scheduling, association tables, or power budgets.
Retention planning is equally important. Storing thirty days of averaged telemetry supports trending, claims analysis, and predictive maintenance. The tool estimates storage from average throughput, converting bits to bytes and scaling by days. Use the GB and GiB results to align commercial pricing and technical allocation.
Finally, treat costs as planning ranges. CAPEX scales with gateway counts, while OPEX is dominated by backhaul, storage, and edge management. Run a baseline, then test a “dense tunnel build” or “crane monitoring program” variant to see how change in payloads and peak factors reshapes capacity. Document assumptions, validate with pilots, and update parameters as the site evolves.
For reliability, pair the target availability with operational response. Higher availability often implies diverse backhaul, spare gateways, and monitored power. Define alert thresholds for packet loss, jitter, and queue depth, then verify in commissioning. When commissioning adds new trades and temporary assets, use the growth allowance to keep headroom without constant redesign prematurely.
FAQs
1. What does protocol overhead include?
Overhead represents headers, acknowledgements, security wrapping, and control traffic around each payload. If you are unsure, start with 15–25% and validate using packet captures during a pilot deployment.
2. How should I choose the peak factor?
Use 1.2–1.6 for steady monitoring, 1.8–2.5 for bursty operations, and higher when many devices report simultaneously. Review shift-change events, scheduled scans, and alarm storms to set it.
3. What compression ratio is realistic?
Telemetry with repeated fields compresses well, while already‑encoded binary may not. Start with 1.2–2.0×, then confirm using your actual message format and sample logs from the field.
4. What is edge reduction, and when is it safe?
Edge reduction models filtering and aggregation done on-site. It is safe when raw data is not required centrally and events or summaries meet reporting needs. Keep raw locally if investigations may require it.
5. Why does the calculator size gateways two ways?
A gateway can hit bandwidth limits before device limits, or vice versa. The tool recommends the larger requirement so you avoid radio congestion, association failures, and throughput saturation under peaks.
6. How do I set the retention period?
Pick retention based on analytics goals and contract needs. Short windows suit live dashboards, while longer windows support trending, claims, and maintenance history. Use tiered storage if costs rise quickly.
7. What does backhaul efficiency mean?
Efficiency is the usable portion of the link after shaping, QoS, and unavoidable framing overhead. If you need guaranteed performance, use a conservative value like 80–90% and measure throughput end-to-end.