The proposed SCADA bridge must cross less than a quarter mile of lake and carry a 10 Mbps traffic target; those two figures do not by themselves identify a suitable radio. Select a point-to-point link only after confirming the RF path, usable throughput, SCADA network behavior, and the supplier’s security evidence.
Is the path clear enough for a point-to-point bridge?
First record the endpoint locations, antenna mounting options, and the terrain or structures between them. A short distance is not proof of a reliable path: shoreline vegetation, buildings, terrain, and water-surface reflections can affect a link. Treat line of sight as a condition to verify, not a conclusion drawn from distance alone.
Inspect the path from both ends and assess clearance along the radio path, not just visibility between the proposed antenna locations. Ask the radio supplier to model the proposed frequency and antenna arrangement, then confirm the result with an on-site survey or commissioning measurements. A link that works at one water level or foliage condition may not maintain the same margin under other site conditions.
| Reading or observation | What it means | Next check |
|---|---|---|
| Clear path and adequate modeled clearance | A point-to-point bridge is a reasonable architecture to evaluate. | Confirm frequency availability and interference. |
| Obstructed path or marginal clearance | Distance alone cannot establish reliable operation. | Evaluate mounting changes or another engineered path before selecting hardware. |
| Path status changes with water, vegetation, or site activity | The propagation environment may vary over time. | Include those conditions in the link design and commissioning plan. |
Does the selected frequency work at both endpoints?
Identify the candidate radio band, antenna type, permitted operating conditions, and local spectrum requirements before comparing products. Some industrial links use licensed frequencies; others use unlicensed bands. A licensed option can provide a more controlled channel, but it also requires confirming that the required authorization and operating conditions are available. Do not select a band solely because another installation used it successfully.
Survey the proposed channel at both ends. Nearby wireless systems and other RF sources can raise the noise floor or cause intermittent packet loss. If the band is congested, compare available channels, antenna placement, and filtering options with the supplier. Filtering can reduce unwanted signals in some installations, but it does not correct an obstructed path or inadequate antenna placement.
| Design choice | Evaluate | Effect on the decision |
|---|---|---|
| Licensed radio band | Channel authorization, equipment availability, and link performance. | Proceed only when the site can operate under the applicable authorization. |
| Unlicensed radio band | Local channel occupancy, interference, and required antenna arrangement. | Proceed only if the surveyed channel can support the required link. |
| High-gain or elevated antenna | Path geometry, mounting constraints, and supplier design guidance. | Can change path performance; confirm with the complete link design. |
Is 10 Mbps the right capacity requirement?
Translate “10 Mbps needed” into a measured requirement before accepting a radio’s headline data rate. Establish whether 10 Mbps is peak or typical application traffic, whether it applies in one direction or both, and whether the figure includes only SCADA traffic or other devices sharing the link. Capture the busiest representative traffic period if the existing system can be measured.
Compare that load with the radio’s usable throughput for the proposed configuration, not just its advertised physical-layer rate. Wireless framing, acknowledgments, retransmissions, encryption, and shared airtime consume capacity. Confirm throughput in both directions and under conditions representative of the site. Ask the supplier to identify the test configuration and whether stated capacity is aggregate or per direction.
Also check whether SCADA performance depends on latency, jitter, or packet loss in addition to throughput. A radio can pass a bulk data test while cyclic polling or time-sensitive traffic still performs poorly. Use the controller and SCADA application’s actual communication requirements; do not invent a universal latency or capacity margin.
| Traffic reading | Interpretation | Decision |
|---|---|---|
| Measured peak reaches or exceeds the planned usable link capacity | There is no demonstrated capacity headroom. | Reassess the radio configuration, traffic mix, or link design. |
| Peak traffic is below tested usable capacity in each required direction | Capacity may be adequate for the measured load. | Test application response and packet behavior under operating conditions. |
| Only an aggregate or PHY rate is available | It does not prove SCADA payload capacity. | Request a configuration-specific throughput result or run a representative test. |
Does the radio preserve the SCADA network behavior?
Draw the path from the SCADA host through the local network equipment, radio, remote network equipment, and controller-side interface. Record which devices route and which bridge Ethernet frames. Confirm the intended IP addressing, VLAN handling, broadcast or multicast requirements, and any protocol ports or services before installation. A radio link can be healthy while an addressing, filtering, or network-design error prevents the controller from communicating.
Keep the network boundary explicit. If the radio transparently bridges the remote Ethernet segment, confirm that this is appropriate for the SCADA design and that the vendor supports the required frame behavior. If routing is used, document the routes and any access-control rules at each endpoint. Do not assume that every wireless product handles discovery, multicast, or VLAN traffic in the same way.
| Observed condition | Likely area to inspect | Next check |
|---|---|---|
| Radio link reports healthy; remote controller is unreachable | Addressing, routes, VLANs, filtering, or endpoint configuration. | Test network reachability hop by hop and inspect the radio’s frame or packet counters. |
| Basic reachability works; SCADA polling fails or times out | Protocol-specific traffic, multicast behavior, latency, loss, or application configuration. | Capture traffic at both sides and compare requests with responses. |
| Intermittent loss coincides with poor RF readings | Path, interference, antenna alignment, or radio configuration. | Correlate RF statistics with packet loss and application alarms. |
What security evidence should the supplier provide?
“Has not been hacked” is not a testable product-selection criterion. A disclosed incident does not alone establish current product risk, and the absence of a public disclosure does not establish security. Ask for evidence about the exact product and software lifecycle under consideration: supported versions, vulnerability handling, update delivery and integrity, account and access controls, and the vendor’s process for communicating security issues.
Use certification and organizational practices as evidence to evaluate, not as a guarantee that the installed system is secure. The evidence names product-oriented examples such as ISASecure and IEC 62443-4-2, development-process examples such as IEC 62443-4-1 and SDL, and organizational or service examples such as ISO 27001 and IEC 62443-2-4. Verify the scope, current status, and applicability of any claimed certification; a certificate for an organization or development process does not automatically certify the radio product.
Then evaluate the system around the bridge. Apply the site’s cybersecurity framework and risk process, control who can reach radio management interfaces, restrict traffic to what the SCADA design requires, and define how updates and credential changes will be managed. Product security and site controls address different layers; neither substitutes for the other.
Which radio architecture fits this lake crossing?
For two endpoints with a viable path, compare a dedicated point-to-point bridge against mesh only when a mesh route solves a real coverage or resilience requirement. Each additional wireless hop can consume shared airtime and reduce end-to-end capacity, so do not choose mesh by default for a single crossing. Ask suppliers to show the topology and usable end-to-end throughput under the proposed number of hops.
Shortlist equipment by verified capability rather than brand reputation or an anecdotal reliability claim. The relevant comparison is whether the specific radio supports the required band and authorization, delivers measured usable capacity, supports the required network behavior, and has security support appropriate to the site. Evaluate current datasheets and supplier test results for the proposed models; product names alone do not prove fit.
| Architecture | Use when | Tradeoff to verify |
|---|---|---|
| Point-to-point bridge | Two endpoints have a workable radio path and no intermediate coverage requirement. | Confirm path margin, throughput, and endpoint network compatibility. |
| Mesh or multi-hop path | An intermediate node is needed to reach the remote endpoint or provide a designed alternate route. | Confirm end-to-end capacity, latency, and route behavior with all hops active. |
| Licensed narrowband system | The application, data rate, and authorized spectrum fit the particular system. | Do not infer suitability for a 10 Mbps target from a long-range claim; verify usable data throughput. |
How should the chosen link be commissioned?
Once the supplier’s design meets the path, capacity, network, and security requirements, commission the installed link against a written baseline. Preserve the as-built antenna positions, radio configuration, network settings, and measured performance so later outages can be separated into RF, radio, network, or controller-side faults.
- Record the actual endpoint locations, antenna orientation and mounting, radio model and firmware, operating band, channel, and link configuration.
- Measure and save the radio’s signal, noise, link-quality, retry, and packet-error readings at each endpoint. Compare the readings with the supplier’s design criteria.
- Run a throughput test in each required direction using the configured radios and representative network path. Record usable payload rate, packet loss, and latency behavior.
- Verify IP reachability from the SCADA network to the remote endpoint, then confirm the controller’s actual SCADA exchanges complete without unexpected timeouts.
- Exercise the expected traffic mix and observe link statistics and application alarms. Confirm that performance remains acceptable when the link carries its representative peak load.
- Save the baseline and define which radio counters, network tests, and SCADA alarms operators will check first if communications degrade.
For troubleshooting, follow the same direction of travel as the data: compare radio link readings first, then test network reachability and packet behavior, then inspect controller and SCADA responses. A healthy RF indication with failed polling directs attention upstream to network or protocol configuration; deteriorating RF readings with correlated packet loss direct attention to the path or interference.
Frequently asked questions
Can a wireless bridge carry 10 Mbps across a lake?
Possibly, but distance and a radio’s advertised rate do not prove it. Verify usable throughput in each required direction using the proposed radio configuration, then test SCADA latency, packet loss, and application exchanges.
Why does a short wireless link still lose SCADA packets?
Short range does not rule out obstruction, water-path reflections, interference, poor antenna alignment, or network errors. Compare RF and retry counters with packet captures and controller communications to identify whether the fault is on the radio path or above it.
How do I verify the SCADA wireless bridge is ready?
Save the installed configuration, measure RF and packet statistics, test usable throughput in both required directions, and confirm controller polling succeeds under representative traffic. The final readiness check is a successful SCADA exchange while the installed link carries its expected peak load.