SCADA over Satellite

Remote industrial sites — mines, pipelines, water treatment plants, offshore platforms, power distribution substations — require continuous monitoring and control of physical processes. In most cases, these sites are located beyond the reach of terrestrial fiber, cellular, or microwave backhaul. Satellite connectivity provides the communication link that connects remote sensors, controllers, and actuators back to a centralized supervisory system. But connecting a SCADA system over satellite is not the same as providing general internet access. SCADA traffic has distinct characteristics — small packets, periodic polling, event-driven alarms, and strict reliability requirements — that demand specific network design considerations.

This article explains how SCADA systems operate over satellite links, what engineering challenges arise, how to design the network for industrial traffic, and what best practices apply to deploying and maintaining SCADA connectivity in remote environments. For background on satellite connectivity for industrial operations more broadly, see our guide on satellite internet for mining and remote industrial sites.

---

What Is SCADA?

SCADA — Supervisory Control and Data Acquisition — is a system architecture used to monitor and control industrial processes across distributed sites from a centralized location. A SCADA system consists of three core components: a master station (the central control center where operators view data and issue commands), remote terminal units (RTUs) or programmable logic controllers (PLCs) deployed at field sites that collect sensor data and execute control commands, and a communication network that links the field devices to the master station.

The master station continuously polls RTUs for current readings — pressure, temperature, flow rate, valve position, power output, tank level — and displays this data on operator dashboards. When an operator needs to change a setpoint, open a valve, or trip a breaker, the command travels from the master station through the communication network to the RTU, which executes it locally.

SCADA systems are the operational backbone of mining operations, oil and gas pipelines, water and wastewater utilities, electrical power distribution, and environmental monitoring networks. In all these applications, the reliability and timeliness of the communication link directly affects operational safety and efficiency. When the link fails, operators lose visibility into remote processes, alarms are delayed, and control commands cannot be executed.

---

Why Satellite Is Used for SCADA

The primary reason satellite is used for SCADA is geography. Many industrial sites that require supervisory control are located in areas where terrestrial communication infrastructure does not exist and cannot be economically deployed. A pipeline monitoring network spanning hundreds of kilometers through desert terrain, a mining operation in a remote region, a chain of water pumping stations across a rural area — these environments lack the fiber, cellular towers, or microwave paths that urban and suburban networks take for granted.

Satellite provides several advantages for these deployments:

• Coverage regardless of geography — a single geostationary satellite beam can cover an entire country or region, reaching any site with a clear view of the sky
• Rapid deployment — a VSAT terminal can be installed and operational in hours, without waiting for infrastructure construction
• Scalability — adding a new monitoring site requires installing a terminal, not extending a cable or building a tower
• Resilience — the satellite link is independent of terrestrial infrastructure that may be damaged by weather, construction, or conflict

The trade-offs — higher latency, shared bandwidth, weather sensitivity, and ongoing airtime costs — are well understood and manageable for most SCADA applications when the network is designed correctly. For a comprehensive overview of satellite connectivity in industrial environments, see satellite internet for mining and remote industrial sites.

---

How SCADA Traffic Behaves over Satellite

Understanding SCADA traffic behavior is essential for designing a satellite network that supports it effectively. SCADA traffic is fundamentally different from the web browsing, video streaming, and file transfer traffic that most satellite networks are optimized for.

Polling Traffic

The majority of SCADA traffic consists of small, periodic poll-response exchanges. The master station sends a request to an RTU ("report your current sensor readings"), and the RTU responds with a data packet containing the requested values. A typical poll request is 20–100 bytes; a typical response is 50–500 bytes. Polling intervals range from every few seconds (for critical process variables) to every few minutes (for environmental or status monitoring). The aggregate bandwidth requirement for a single RTU is typically 1–10 kbps — far less than a typical internet connection.

Event-Driven Alarms

When a sensor reading exceeds a configured threshold — high pressure, low flow, equipment fault, intrusion detection — the RTU generates an unsolicited alarm report and transmits it to the master station without waiting for the next poll cycle. Alarm traffic is sporadic and low-volume, but it is the highest-priority traffic on the network. A delayed alarm can mean the difference between a controlled shutdown and an equipment failure or safety incident.

Supervisory Control Commands

Operators at the master station issue control commands — open a valve, start a pump, change a setpoint — that travel to the RTU for execution. These are small packets (typically under 200 bytes), infrequent compared to polling traffic, but require reliable delivery. Most SCADA protocols implement a select-before-operate (SBO) sequence that requires a round-trip confirmation before the command is executed, making the total transaction latency two round trips through the satellite.

Why This Matters for Satellite Design

The key insight is that SCADA traffic is characterized by many small transactions rather than large data transfers. Bandwidth requirements are low, but latency, reliability, and prioritization matter significantly. A satellite network designed for bulk throughput may not handle SCADA well if it introduces excessive queuing delay, drops small packets during congestion, or fails to prioritize alarm traffic over background data transfers.

---

Key Engineering Challenges

Operating SCADA over satellite introduces specific engineering challenges that do not exist — or are less significant — on terrestrial links.

Latency and Round-Trip Delay

A geostationary (GEO) satellite link introduces approximately 480–600 ms of round-trip delay due to the propagation distance (approximately 35,786 km altitude). For polling-based SCADA, this means each poll-response cycle takes at least 600 ms longer than it would on a terrestrial link. A select-before-operate control command, which requires two round trips, takes at least 1.2 seconds. For most industrial applications, this latency is tolerable — operators are accustomed to the delay, and process dynamics are typically slower than the satellite round-trip time. However, applications requiring sub-second control response may not be suitable for GEO satellite without architectural adaptation. For detailed analysis of satellite latency across orbit types, see satellite latency comparison.

Jitter and Packet Loss

Satellite links can introduce jitter (variation in packet arrival time) and packet loss due to rain fade, interference, and congestion on shared capacity. For SCADA, jitter affects the consistency of polling intervals, and packet loss can delay alarm delivery. Most SCADA protocols include retry mechanisms, but repeated retries on a high-latency link compound the delay. A single lost poll-response on a GEO link results in at least 1.2 seconds of additional delay (original round trip plus retry round trip).

Bandwidth Constraints

While SCADA itself requires minimal bandwidth, satellite links at remote sites often carry other traffic alongside SCADA — corporate data, VoIP, email, software updates, and sometimes video surveillance. On shared or contention-based satellite services, SCADA packets can be delayed behind bulk data transfers if proper traffic prioritization is not implemented.

Availability and Resilience

Industrial SCADA systems often require high availability — 99.5% or higher — because loss of monitoring and control capability can create safety risks and regulatory compliance issues. Satellite link availability is affected by weather (particularly rain fade on Ku-band and Ka-band), equipment faults, and satellite capacity constraints. Understanding the availability characteristics of the satellite service and matching them to SCADA requirements is critical. For detailed guidance, see satellite link availability explained and satellite SLA explained.

Challenge Summary

---

Network Design Considerations

Designing a satellite network for SCADA requires attention to topology, traffic management, redundancy, and security.

Topology

Most SCADA-over-satellite deployments use a star (hub-spoke) topology, which mirrors the centralized architecture of the SCADA system itself. The master station connects to a satellite hub (or is co-located with it), and each remote RTU site has a VSAT terminal. All traffic flows through the hub, which acts as the central switching point. This topology is natural for SCADA because the communication pattern is inherently centralized — the master station polls each RTU and receives responses from each RTU.

For networks that also require site-to-site communication (e.g., a regional control center that needs to communicate with both the master station and local RTUs), mesh or partial-mesh topologies may be considered, though these add complexity and cost.

QoS for Industrial Traffic

Quality of Service configuration is the single most important network design element for SCADA over satellite. Without proper QoS, SCADA traffic competes with other traffic on the same link, and small, time-sensitive SCADA packets can be delayed behind large data transfers.

Effective QoS for SCADA over satellite includes:

1. Traffic classification — identifying SCADA traffic by protocol (DNP3, Modbus/TCP), port number, source/destination IP, or VLAN tag
2. Priority queuing — placing SCADA traffic (especially alarms and control commands) in a high-priority queue that is serviced before bulk data
3. Bandwidth reservation — allocating a minimum guaranteed bandwidth (CIR) specifically for SCADA traffic, ensuring it is not affected by congestion from other traffic classes
4. Rate limiting for bulk traffic — preventing large file transfers, software updates, or video from consuming all available capacity and starving SCADA

For a detailed treatment of QoS mechanisms on satellite links, see QoS over satellite and traffic shaping.

Redundancy and Failover

For critical SCADA systems, single points of failure in the communication path are unacceptable. Common redundancy strategies include:

• Dual-path connectivity — using satellite as the primary link with cellular (where available) as backup, or vice versa
• Automatic failover — configuring the network to switch to the backup path within seconds if the primary link fails
• Local autonomy — programming RTUs and PLCs to continue operating autonomously on pre-configured logic if the satellite link is lost, storing data locally for transmission when connectivity is restored

Security

SCADA systems are increasingly recognized as critical infrastructure requiring cybersecurity protection. When SCADA traffic traverses a satellite link, it crosses a shared medium that requires appropriate security measures:

• Encryption — using VPN tunnels (IPsec or SSL/TLS) to encrypt SCADA traffic end-to-end between the master station and each RTU site
• OT/IT segmentation — separating operational technology (SCADA) traffic from information technology (corporate internet, email) traffic using VLANs, separate satellite carriers, or distinct virtual networks
• Access control — restricting which devices and users can send control commands, with authentication at both the network and application layers

Security design should follow defense-in-depth principles without introducing excessive protocol overhead that would degrade SCADA performance on a bandwidth-constrained satellite link.

---

SCADA over GEO vs LEO

The choice between geostationary (GEO) and low earth orbit (LEO) satellite connectivity for SCADA involves trade-offs between latency, coverage, complexity, and maturity.

GEO for SCADA

GEO satellites have been the standard platform for SCADA-over-satellite deployments for decades. Their characteristics align well with most SCADA requirements:

• Predictable, constant latency — approximately 600 ms RTT, consistent and unchanging because the satellite is in a fixed orbital position
• Wide coverage from a single satellite — one GEO satellite covers roughly one-third of the earth's surface, simplifying network planning
• Proven technology — decades of operational experience with SCADA over GEO VSAT, well-understood performance characteristics
• No handover complexity — the satellite does not move relative to the ground, so there is no beam handover or tracking requirement for fixed terminals

For polling-based SCADA with intervals of 5 seconds or longer, GEO latency has minimal operational impact. Most industrial processes operate on timescales of minutes to hours, and the 600 ms round-trip delay is inconsequential compared to the process dynamics.

LEO for SCADA

LEO constellations (such as Starlink, OneWeb, or Telesat Lightspeed) offer significantly lower latency — typically 20–60 ms round-trip — which may benefit SCADA applications with tighter timing requirements:

• Lower latency — faster poll-response cycles and quicker control command execution
• Potentially higher availability — multiple satellites visible at any time, providing path diversity
• Better performance for closed-loop control — where sub-second response is required, LEO's lower latency is a meaningful advantage

However, LEO introduces complexities that GEO does not:

• Beam handover — as LEO satellites move across the sky, the terminal must switch between satellites, which can introduce brief interruptions
• Coverage variability — depending on the constellation's deployment phase, coverage at specific locations may not be continuous
• Less operational history for SCADA — LEO VSAT for industrial SCADA is newer, with less field-proven operational data

Comparison

For the majority of current SCADA deployments — periodic telemetry, alarm reporting, and supervisory control — GEO remains the proven and practical choice. LEO becomes compelling when the application requires lower latency than GEO can provide, or when the deployment is in high-latitude regions where GEO coverage is limited.

---

Real-World Use Cases

SCADA over satellite serves a wide range of industrial sectors where remote monitoring and control are operationally essential.

Mining and Resource Extraction

Mining operations in remote regions use SCADA over satellite to monitor equipment status, environmental conditions (dust, noise, water quality), power generation and distribution, and vehicle tracking. The satellite link provides both the SCADA communication path and general connectivity for the site. Large mining operations may deploy multiple RTUs across a single site — pit monitoring, processing plant, tailings dam, power station — all reporting to a centralized control room via satellite.

Pipelines and Utilities

Oil, gas, and water pipelines span hundreds or thousands of kilometers, with monitoring points (valve stations, pump stations, metering stations) distributed along the route. Many of these points are in locations with no terrestrial connectivity. SCADA over satellite enables centralized monitoring of flow, pressure, temperature, and leak detection across the entire pipeline from a single control center. Electrical utilities use similar architectures for distribution substations and renewable energy installations in remote areas.

Temporary and Exploration Operations

Construction sites, seismic survey operations, exploration drilling, and temporary field operations require SCADA monitoring but are too short-lived to justify permanent terrestrial infrastructure. Satellite VSAT terminals can be deployed for the duration of the operation and relocated when the project moves. This rapid deployment capability makes satellite the only practical option for temporary SCADA.

Disaster Recovery

When terrestrial communication infrastructure is damaged by natural disasters, satellite provides an alternative SCADA communication path for critical utility systems — water treatment, power distribution, flood monitoring — that must continue operating during and after the event. Pre-positioned satellite terminals in disaster kits enable rapid restoration of SCADA connectivity. For more on satellite in emergency scenarios, see enterprise satellite internet guide.

---

Best Practices

Deploying SCADA over satellite successfully requires attention to the specific characteristics of industrial traffic and remote site operations. The following checklist covers the essential design and operational considerations:

1. Plan capacity for critical traffic first — calculate the bandwidth requirement for SCADA polling, alarms, and control commands at the expected polling interval and number of RTUs. This is your non-negotiable baseline. All other traffic (corporate data, updates, video) is allocated from remaining capacity.

2. Prioritize alarms and control traffic via QoS — configure the satellite network to classify SCADA alarm and control packets as highest priority. These packets must not be delayed behind file transfers, software updates, or web browsing traffic, regardless of congestion level.

3. Test application behavior before deployment — verify that the SCADA application, protocols, and RTU firmware operate correctly over the expected satellite latency. Run end-to-end tests with simulated satellite delay to identify timeout issues, protocol incompatibilities, or performance degradation before deploying to remote sites.

4. Use store-and-forward for non-critical data — historical data logs, trend data, and periodic reports can be batched and transmitted during off-peak hours rather than competing with real-time telemetry for bandwidth during operational periods.

5. Plan for link outages with local buffering — configure RTUs to buffer telemetry data and alarm logs locally when the satellite link is unavailable. When connectivity is restored, the buffered data is transmitted to the master station, providing a complete record with no gaps.

6. Separate OT and IT traffic — use VLANs, dedicated satellite carriers, or virtual network segmentation to isolate SCADA traffic from corporate IT traffic. This improves both security and performance predictability for industrial systems.

7. Monitor link quality metrics relevant to SCADA — track latency, jitter, packet loss, and availability specifically for the SCADA traffic class, not just aggregate link statistics. Set up alerts when these metrics approach thresholds that would affect SCADA operation.

---

Common Misunderstandings

"SCADA needs high bandwidth." Typical SCADA polling generates less than 10 kbps per RTU. Even a network with 50 RTUs may require less than 500 kbps of aggregate bandwidth for telemetry and control. The bandwidth challenge comes from other traffic sharing the same satellite link, not from SCADA itself.

"All industrial traffic is the same." Telemetry polling, alarm reports, control commands, video surveillance, and bulk data transfers have vastly different profiles in terms of packet size, frequency, latency sensitivity, and priority. Treating them identically on a bandwidth-constrained satellite link leads to poor performance for the traffic that matters most.

"Satellite latency makes SCADA impossible." Most polling-based SCADA systems tolerate 600 ms round-trip delay without operational impact. Industrial processes typically operate on timescales of seconds to minutes. The 600 ms GEO latency adds delay to individual poll-response cycles but does not prevent effective monitoring and control for the vast majority of applications.

"Any satellite plan will work for SCADA." A shared best-effort satellite service without QoS, without guaranteed bandwidth (CIR), and without availability commitments is insufficient for critical industrial control. SCADA requires a service tier that provides priority, predictability, and reliability — not just connectivity.

---

FAQ

Can SCADA run over satellite?

Yes. SCADA has operated over satellite links for decades, particularly using geostationary (GEO) VSAT networks. The small packet sizes and low bandwidth requirements of SCADA traffic are well-suited to satellite connectivity. The key requirements are proper QoS configuration, adequate link availability, and network design that accounts for satellite latency.

Is satellite latency a problem for SCADA?

For most SCADA applications, no. GEO satellite introduces approximately 600 ms of round-trip delay, which adds time to each poll-response cycle but does not prevent effective operation. Most industrial processes operate on timescales much longer than 600 ms. Applications requiring sub-second closed-loop control may need LEO satellite or a hybrid approach with local autonomy at the RTU. For most polling-based telemetry and supervisory control, GEO latency is operationally acceptable.

What is the bandwidth requirement for SCADA over satellite?

Individual RTUs typically require 1–10 kbps for standard polling cycles. A network of 20 RTUs with 10-second polling intervals might require 40–200 kbps of aggregate bandwidth for SCADA traffic alone. The actual satellite bandwidth needed is usually higher because the link also carries other traffic (corporate data, email, occasional video). Capacity planning should allocate guaranteed bandwidth (CIR) for SCADA and allow other traffic to use remaining capacity.

Should SCADA traffic use dedicated capacity?

For critical SCADA systems, dedicated bandwidth (CIR) allocated specifically for SCADA traffic is strongly recommended. This ensures that SCADA packets are transmitted without delay regardless of what other traffic is on the link. On shared satellite services, this is achieved through QoS bandwidth reservation. For the most critical applications, a physically separate satellite carrier (SCPC) dedicated to SCADA may be justified.

What SCADA protocols work over satellite?

DNP3, Modbus/TCP, IEC 60870-5-104, and OPC UA all operate over satellite links. These protocols use TCP/IP as the transport layer, which handles the satellite latency through standard TCP mechanisms. DNP3 and IEC 60870-5-104 are designed for wide-area networks and tolerate higher latency well. Older serial protocols (Modbus RTU, Modbus ASCII) may require serial-to-IP converters at each site. Protocol performance over satellite should be tested during the design phase to verify timeout settings and retry behavior.

Can satellite support closed-loop control for industrial systems?

GEO satellite is generally not suitable for closed-loop control that requires sub-second response times, because the minimum round-trip delay of approximately 600 ms exceeds the control loop timing requirement. LEO satellite, with round-trip delays of 20–60 ms, can support faster control loops. However, most industrial closed-loop control is performed locally by the PLC or RTU, with only supervisory commands and setpoint changes sent over the satellite link. This local-autonomy architecture works well over GEO satellite.

How do you prioritize SCADA traffic on a shared satellite link?

SCADA traffic is prioritized through QoS (Quality of Service) configuration at both the satellite hub and the remote VSAT terminal. Traffic is classified by protocol, port number, IP address, or VLAN tag, and placed into priority queues. SCADA alarm and control packets are assigned the highest priority, polling traffic receives high priority, and all other traffic (email, web, file transfer) is placed in lower-priority queues. Bandwidth reservation (CIR) ensures SCADA traffic always has capacity available. See QoS over satellite and traffic shaping for details.

What happens to SCADA data during a satellite link outage?

During a satellite link outage, RTUs continue operating based on their local programming (PLC logic continues executing locally). Sensor data and alarm events are buffered in the RTU's local memory. When the satellite link is restored, the buffered data is transmitted to the master station, typically with timestamps so operators can reconstruct the complete event history. The master station should be configured to accept and process this delayed data correctly. For critical sites, dual-path redundancy (satellite plus cellular backup) minimizes the duration of communication loss.

---

Key Takeaways

• SCADA over satellite is proven technology — decades of operational deployments in mining, pipelines, utilities, and remote infrastructure demonstrate that satellite provides a reliable communication path for industrial monitoring and control.

• SCADA traffic is small and periodic — typical polling generates less than 10 kbps per RTU, making bandwidth requirements minimal compared to other satellite applications.

• GEO latency is tolerable for most SCADA — the ~600 ms round-trip delay affects individual transaction speed but does not prevent effective monitoring and supervisory control for the vast majority of industrial processes.

• QoS is non-negotiable — without proper traffic classification and prioritization, SCADA packets are delayed behind bulk data traffic, degrading monitoring and alarm performance.

• Design for outages — local buffering at RTUs, automatic failover to backup paths, and autonomous PLC operation ensure continuity when the satellite link is temporarily unavailable.

• Separate OT from IT — keeping SCADA traffic isolated from corporate internet traffic improves both performance predictability and cybersecurity posture.

• Test before deploying — validate SCADA application behavior, protocol timeouts, and RTU firmware over simulated satellite delay before committing to a remote site deployment.

---

Related Articles

• Satellite Internet for Mining and Remote Industrial Sites — Comprehensive guide to deploying satellite connectivity for mining operations, covering bandwidth planning, site design, and operational considerations.
• QoS over Satellite and Traffic Shaping — How Quality of Service mechanisms prioritize traffic on satellite links, including classification, queuing, and bandwidth management.
• Satellite Latency Comparison — Detailed comparison of latency across GEO, MEO, and LEO satellite orbits and their impact on different applications.
• Enterprise Satellite Internet Guide — End-to-end planning guide for enterprise satellite deployments covering architecture, provider evaluation, and operational management.
• Satellite Link Availability Explained — How satellite link availability is calculated, the role of rain fade margins, and what availability figures mean in practice.
• Satellite SLA Explained — Engineering guide to satellite service level agreements covering availability commitments, performance metrics, and evaluation methodology.