SCADA Using Satellite Communication: Design and Acceptance Testing

SCADA using satellite communication works when the complete control application is designed and tested for the actual path. The word “SCADA” does not define a protocol, transaction size, timeout, reporting method, security model, or safe outage response, while “satellite” does not define a service delay, capacity, availability, or address plan.

This guide provides a vendor-neutral method for remote telemetry and supervisory control over satellite. For portfolio planning across energy assets, use oil and gas satellite communications. For general link-delay boundaries, see the satellite latency comparison.

Quick Answer

A defensible SCADA-over-satellite design joins six evidence sets:

accepted SCADA path = exact application transactions
                    + safe local and disconnected behavior
                    + measured satellite service envelope
                    + deterministic QoS and security policy
                    + failure, buffering, and recovery design
                    + witnessed end-to-end application tests

Reject these shortcuts:

Keep Supervisory Communication Separate from Local Control

Start by documenting what the WAN is allowed to do.

The design should remain safe when the satellite path is unavailable. Define local autonomy, stale-data indication, command blocking or expiry, event buffering, operator procedures, and the point at which loss of communication requires an operational response.

NIST SP 800-82 Rev. 3 addresses OT systems with distinct performance, reliability, and safety requirements. Use it with the applicable functional-safety, process-safety, vendor, company, and national requirements rather than assuming that an IT availability target defines safe operation.

Inventory the Exact Transaction Path

Draw every component and trust boundary:

sensor / actuator
      |
PLC or RTU and local logic
      |
protocol gateway / site OT network
      |
industrial firewall / security gateway
      |
site router and satellite terminal
      |
satellite, gateway, and provider network
      |
enterprise security edge
      |
SCADA master / historian / operator

For each hop, record:

• equipment, software, firmware, protocol version, interface, address, route, and owner;
• client/master and server/outstation roles and which side initiates each session;
• connection, keepalive, idle, request, response, retry, duplicate, and reconnect behavior;
• message identifiers, sequence handling, acknowledgement, timestamp source, clock quality, and stale-data rules;
• security zone, permitted flow, authentication, encryption, certificate or key owner, role, and log source;
• monitoring point, support boundary, recovery method, configuration backup, and change authority.

Do not stop at “DNP3,” “Modbus,” or “OPC UA.” The Modbus Organization publishes distinct documents for its application protocol, TCP/IP implementation, serial line, and security. The DNP Users Group maintains protocol and secure-authentication resources. The OPC Foundation publishes multiple OPC UA parts for services, mappings, security, alarms, historical access, PubSub, and roles. Device support and configuration determine the observed behavior.

Measure the Traffic Instead of Guessing

Capture representative traffic at a safe test system or approved production observation point. Include normal, startup, reconnect, alarm burst, operator command, maintenance, history retrieval, certificate or key renewal, and recovery states.

Build a worksheet for every flow:

A transparent calculation for a periodic flow is:

mean bits/s = transactions per second
            × total on-wire bytes per transaction
            × 8

engineered rate = mean rate
                + simultaneous-event allowance
                + retransmission allowance
                + security and tunnel overhead
                + measurement uncertainty

Mean rate alone is insufficient. A small average can hide short alarm bursts, simultaneous reconnects, certificate exchanges, historian catch-up, or a software update that fills the queue. Verify peak queue delay and packet loss for the critical class while other site traffic is active.

Build a Transaction Timing Budget

Measure a transaction at named points rather than assigning all delay to the satellite:

T_transaction = T_master_processing
              + T_local_network_out
              + T_security_and_queue_out
              + T_provider_forward
              + T_remote_processing
              + T_provider_return
              + T_security_and_queue_return
              + T_master_completion

Repeat the measurement across representative load, route, weather, network-transition, and maintenance conditions. Record minimum, median, tail, timeout, retry, and failure behavior rather than one average.

Set application timers from the accepted distribution and the process requirement. A timer must leave room for the full transaction and controlled variation without masking a genuine failure for too long. Change one timer only after checking how it interacts with retries, duplicate suppression, connection liveness, alarms, operator feedback, and failover.

Use satellite latency comparison for propagation definitions and calculation boundaries. Orbit affects the space-path component, but the purchased service also includes terminal, gateway, network-core, terrestrial, security, and application processing.

Test Protocol Behavior Explicitly

Polling and Request/Response

Measure the number of outstanding requests supported by the master and outstation, serial-gateway behavior, response ordering, timeout, retry, and recovery after a delayed or lost response. Sequential polling can accumulate path delay differently from concurrent requests; prove the configured implementation rather than applying a generic rule.

Events, Reports, and Subscriptions

Where the product supports event-driven, unsolicited, report-by-exception, or subscription behavior, test registration, acknowledgement, retry, duplicate delivery, sequence gaps, burst handling, and resynchronization. Event-driven behavior can reduce routine polling traffic, but it creates its own state and recovery requirements.

Commands and Writes

For every remote command, define:

• authenticated and authorized initiator;
• target, interlock, validation, and local permission;
• command age, expiry, duplicate handling, and replay protection;
• acknowledgement, execution confirmation, and operator display;
• behavior when the request or response is delayed, lost, or repeated;
• safe state when communication is ambiguous.

Do not infer command success from packet delivery alone. Verify the application and process indication required by the approved operating procedure.

History, Files, and Catch-Up

Specify how data is buffered locally, timestamped, prioritized, transmitted after restoration, deduplicated, and reconciled. Rate-limit catch-up so it does not delay current alarms and commands. Test storage exhaustion, clock error, extended outage, partial transfer, and repeated reconnection.

Design QoS Around the Degraded Link

Classify traffic by operational consequence and verified application identity. A practical policy often separates:

1. approved command and critical alarm transactions;
2. routine telemetry and state updates;
3. time synchronization and essential OT infrastructure;
4. controlled maintenance and remote support;
5. historian, files, and bulk operational data;
6. enterprise, video, guest, or welfare traffic.

Reserve or police capacity according to the purchased service and the measured bursts. Shape traffic before the bottleneck where possible, and define what is blocked or reduced when the backup path is smaller.

Port numbers alone can be weak classifiers when gateways, encryption, or shared infrastructure are involved. Use the approved combination of zones, endpoints, application identity, VLAN, DSCP handling, tunnels, and provider service classes, then verify that markings survive each boundary.

The QoS over satellite guide covers queue, shaping, and acceptance evidence in more detail.

Treat Addressing and Tunnels as Application Dependencies

Record whether the satellite handoff supplies public, private, or shared addressing; IPv4, IPv6, or both; static or changing routes; upstream translation; inbound filtering; and VPN compatibility.

A control-center-initiated poll may require a private routed WAN, stable public service, provider mapping, or overlay that creates the approved route. A site-initiated session can have different requirements. Do not assume that a public address is necessary or that a successful outbound web session proves SCADA reachability.

For each security overlay, test establishment, identity, key or certificate renewal, liveness, idle timeout, NAT traversal, MTU, fragmentation, reconnect, alternate endpoint, and failover behavior. The remote site must also have a secure recovery path when the overlay configuration or credentials fail.

Apply OT Segmentation and Controlled Remote Access

Treat the satellite path as untrusted transport. Separate process-control, safety-related, site operations, enterprise IT, guest or welfare, vendor access, and network management according to the approved OT architecture.

CISA's ICS recommended practices include defense-in-depth and remote-access guidance. For each remote-access workflow, define:

• accountable approver and named user or organization;
• managed source device and authenticated path;
• jump host or security boundary, destination asset, permitted actions, and time window;
• least privilege, credential lifecycle, session logging or recording, and monitoring;
• emergency revocation, vendor offboarding, incident isolation, and restoration.

Do not place an RTU, PLC, protocol gateway, engineering workstation, or management interface directly on a broadly reachable public service merely for convenience. A VPN is one control, not the whole OT security architecture.

Choose the Satellite Service from the Application Envelope

Compare exact services, not generic GEO-versus-LEO labels:

For a radio link, frequency, geometry, terminal performance, interference, and propagation determine the physical service envelope. ITU-R P.618-14 provides an in-force method for Earth-space propagation prediction; use it with the applicable companion recommendations and actual site inputs rather than a generic fade margin.

Design for Outage and Recovery

Write the disconnected-state behavior before adding a second WAN:

• local control and protection continue according to the approved design;
• the HMI clearly marks stale or unavailable remote data;
• remote commands are blocked, expired, queued, or reconciled according to a defined policy;
• alarms and events retain trustworthy timestamps and sequence information;
• local storage has a monitored capacity and an exhaustion response;
• current operational messages take priority over historical catch-up;
• the master and outstation recover without an uncontrolled command replay or alarm flood.

If a second path is required, draw shared power, routing, firewall, VPN, DNS, identity, gateway, application, and support dependencies. Measure carrier restoration and SCADA application recovery separately.

For offshore protection links, see satellite backup for offshore operations. For broader diversity logic, see satellite link availability.

Acceptance Test Plan

Agree safe test conditions, named endpoints, tools, pass/fail thresholds, witnesses, data ownership, and remediation before deployment. Do not issue live process commands or disrupt protection functions merely to prove a network.

1. Baseline Configuration

• record device, firmware, protocol and security versions, routes, firewall rules, QoS, addressing, time, certificates or keys, and application timers;
• verify network zones, permitted flows, user roles, remote access, monitoring, logging, backup, and recovery documentation;
• synchronize test timestamps across terminal, router, firewall, VPN, master, outstation, and application logs.

2. Normal and Peak Transactions

• run routine polling or subscriptions, alarms, approved commands, history, files, and maintenance workflows;
• reproduce busy-period competing traffic and simultaneous events;
• measure on-wire volume, queue delay, loss, retry, transaction completion, data freshness, and operator indication.

3. Impairment and Brownout

• apply only approved laboratory or controlled-path delay, variation, loss, reordering, duplication, constrained capacity, and session interruption;
• verify timer, retry, duplicate, stale-data, command-age, buffer, QoS, and alarm behavior;
• distinguish terminal or RF degradation from provider, IP, tunnel, and application faults.

4. Outage and Recovery

• remove the approved WAN dependency and confirm local autonomy, stale indication, buffering, alarm, and escalation;
• restore or switch paths and measure packet, session, and application recovery separately;
• confirm ordered catch-up, current-data priority, duplicate handling, timestamp integrity, and failback behavior.

5. Evidence Record

Retain packet captures where approved, configurations, logs, RF and IP metrics, test scripts, timestamps, traffic conditions, application results, exceptions, corrective actions, retests, and witness sign-off.

Troubleshooting Sequence

When SCADA fails over satellite, isolate the boundary in order:

1. confirm local PLC or RTU operation and safe state;
2. check terminal power, alarms, receive/transmit state, and provider registration;
3. verify local interfaces, address, route, MTU, errors, and queues;
4. test the controlled provider and enterprise path;
5. inspect VPN, firewall, identity, DNS, time, and certificate or key state;
6. verify protocol session, transaction identifiers, timeout, retry, duplicate, and stale-data behavior;
7. compare master, outstation, security, and network logs on one timeline;
8. preserve evidence before changing timers or opening security rules.

Use remote site network monitoring over satellite to build the RF-to-application telemetry chain.

FAQ

Can SCADA use satellite communication?

Yes, when the application timing, capacity, addressing, security, availability, disconnected behavior, and support boundaries fit the purchased service. Prove the exact master, outstation, gateway, security, and network configuration end to end.

How much bandwidth does satellite SCADA need?

There is no universal value per RTU. Measure on-wire request, response, acknowledgement, retry, security overhead, reporting interval, simultaneous events, history catch-up, and competing traffic. Engineer peak queue behavior as well as the mean rate.

Is GEO latency too high for SCADA?

The answer depends on the transaction and process requirement. Some supervisory functions tolerate the measured path; others do not. Keep fast or safety-related control local unless approved otherwise, and test transaction distributions instead of relying on an orbit label.

Is LEO better for industrial control?

Lower space-path propagation can help a latency-sensitive transaction, but service routing, congestion, transitions, gateway paths, terminal behavior, support, and contract still matter. Test the exact plan and application.

Which SCADA protocols work over satellite?

Many IP or gateway-based implementations can operate over satellite, but the protocol name is not enough. Verify version, transport mapping, session model, security, timeout, retry, event, command, buffering, and recovery behavior for the actual devices.

Should SCADA use a static public IP?

Not necessarily. A managed private route or site-initiated secure overlay may satisfy the requirement without direct public exposure. Define initiation direction, routing, translation, inbound policy, identity, segmentation, and failover first.

What happens to data during an outage?

The approved design should define local control, stale indication, event buffering, timestamping, storage limits, command policy, catch-up priority, duplicate handling, and operator response. Test those behaviors rather than assuming the RTU buffers correctly.

Related Guides

• Oil and Gas Satellite Communications — portfolio requirements, hazardous areas, procurement, and lifecycle evidence
• Oil Rig Satellite Internet — one-platform site, terminal, power, network, and acceptance design
• Satellite Backup for Offshore Operations — independent protection path, health checks, degraded traffic, and recovery
• QoS over Satellite — queueing, shaping, and traffic-class evidence
• Satellite Latency Comparison — propagation and end-to-end measurement boundaries
• Satellite Provider Evaluation — SLA, support, service, and contract comparison