| Scenario | Area (m²) | Devices | Concurrency | Rate (Mbps) | Compute (GFLOPS) | Radius (m) | Node caps (devices / Mbps / GFLOPS) | Recommended nodes |
|---|---|---|---|---|---|---|---|---|
| Highway corridor | 280,000 | 320 | 70% | 2.0 | 4.0 | 220 | 80 / 350 / 480 | 8–10 (with redundancy) |
| Bridge retrofit | 65,000 | 120 | 80% | 3.5 | 6.0 | 180 | 60 / 300 / 420 | 5–7 (with redundancy) |
| Urban streetscape | 140,000 | 260 | 60% | 1.5 | 3.0 | 200 | 90 / 400 / 500 | 6–8 (with redundancy) |
TotalCompute(GFLOPS) = ActiveDevices × ComputePerDevice
NodesByCoverage = ceil(WorksiteArea ÷ EffectiveCoveragePerNode)
NodesByBandwidth = ceil(TotalIngest ÷ NodeIngestCapacity)
NodesByCompute = ceil(TotalCompute ÷ NodeComputeCapacity)
TotalNodes = BaseNodes + SpareNodes (N+1 or percentage)
- Estimate the total footprint in square meters and define zones.
- Count devices, then set peak concurrency for the busiest shift.
- Enter typical ingest and compute per active device at peak.
- Enter realistic per-node limits from bench tests or vendor specs.
- Set coverage radius and efficiency based on site obstacles.
- Set latency target and baseline network latency for your backhaul.
- Choose redundancy, then press Calculate placement.
- Review dominant constraint and adjust inputs to reduce risk.
- Download CSV or PDF and attach them to your method statement.
Deployment context for construction edge nodes
Construction sites behave like moving networks: crews, plant, and temporary works shift daily. This calculator sizes edge nodes against four constraints—device sessions, ingest bandwidth, compute budget, and effective coverage area—then selects the highest node count as the base recommendation. Using peak shift inputs reduces rework, avoids uplink congestion, and keeps analytics close to operations. Supports safety, productivity, and audit readiness.
Device and workload profiling that improves accuracy
Start with a device inventory grouped by function: safety cameras, progress capture, telematics, access control, and environmental sensors. For each group, record typical sustained Mbps and average compute demand per active device. Peak concurrency is rarely 100%: many sensors burst, while video streams can be policy-limited. A realistic concurrency value yields node plans that meet performance targets without overspending.
Coverage geometry and efficiency losses on real sites
The radius input represents practical service reach, not a perfect circle. Earthworks, scaffolding, stockpiles, and steelwork create shadow zones, so the coverage efficiency factor reduces theoretical area to reflect overlap, obstacles, and non-uniform placement. If you expect frequent line-of-sight breaks, use 0.60–0.75 and plan for extra nodes near critical zones such as lifting areas and haul routes.
Latency target checks for time-critical workflows
Latency is estimated from baseline network delay, propagation from average device distance, processing time, and a queue penalty that rises after high utilization. When results exceed the target, reduce spacing, add nodes, or move high-demand devices into dedicated clusters. For alerting workflows, aim for headroom by keeping dominant utilization below about 75% during peak hours.
Example dataset and interpretation
Example inputs: area 280,000 m², 320 devices, 70% concurrency, 2.0 Mbps per active device, 4.0 GFLOPS per active device, node limits 80 devices, 350 Mbps, 480 GFLOPS, radius 220 m, efficiency 0.70, plus 10% redundancy. The calculator typically recommends 8–10 nodes, with dominant limits often driven by bandwidth or device sessions. Use the suggested spacing as a first pass, then adjust for power availability, safe access, and supervision points.
| Input field | Example value | Planning note |
|---|---|---|
| Peak concurrency | 70% | Use the busiest shift and strongest video policy. |
| Coverage efficiency | 0.70 | Accounts for overlap, obstacles, and relocation needs. |
| Redundancy | 10% | Supports maintenance and single-node failure scenarios. |
1) What does “dominant constraint” mean?
It is the limiting factor that requires the most nodes. The tool compares devices, bandwidth, compute, and coverage, then selects the maximum node count as the base requirement.
2) How should I choose peak concurrency?
Use the busiest operational period and estimate the share of devices active simultaneously. For video, apply streaming policies; for sensors, consider burst behavior and duty cycles.
3) What is a good coverage efficiency value?
Use 0.60–0.75 for cluttered sites with obstructions and frequent changes. Use 0.75–0.85 for open sites with stable mounting positions and clear line-of-sight.
4) Why does latency increase at high utilization?
As nodes approach capacity, buffering and scheduling delays grow. The calculator adds a queue penalty after higher utilization to reflect real-world congestion and processing contention.
5) When should I use N+1 redundancy?
Use N+1 when a single node failure must not interrupt critical workflows, or when maintenance windows are limited. It is also helpful for remote sites with slower replacement logistics.
6) How do I validate node bandwidth and compute inputs?
Prefer bench tests with representative streams and analytics settings. Use sustained values under thermal limits, storage load, and encryption overhead, not short peak benchmarks.
7) Can I plan separate node pools for different workloads?
Yes. Run the calculator for each workload cluster, such as safety video and telematics. Then allocate nodes per zone and keep headroom for temporary works, events, and change orders.