Success-Plan Services
David Greenberg
The promise of maritime autonomy is often described in terms of reach, scale, and persistence. Autonomous surface and undersea systems can extend sensing, support distributed operations, reduce risk to personnel, and help cover large maritime areas that would be difficult to monitor with traditional platforms alone.
But there is a harder question every maritime autonomy stack eventually has to answer:
What happens when the environment stops cooperating?
At sea, autonomy does not operate in a clean, predictable network. It operates across long distances, unstable communications paths, limited bandwidth, harsh weather, electronic warfare threats, cyber risk, and mission conditions where GPS may be degraded or denied. A system that performs well in a controlled demonstration may behave very differently when communications are intermittent, latency is unpredictable, or the network is actively contested.
For maritime autonomy to move from promising demonstrations to operational fleets, resilience has to become a design requirement from the beginning.
This is not only about making the vehicle itself reliable. It is about making the entire mission system resilient: the autonomous platform, its sensors, onboard applications, command-and-control links, remote operators, and the data flows that connect them. Autonomous maritime systems must keep working when GPS is jammed, communications drop, or networks are attacked.
Autonomy Cannot Depend on Perfect Connectivity
Many early autonomy efforts are tested in conditions where connectivity is available, operators are nearby, and the environment is relatively controlled. That is an important step, but it does not represent the operational reality of contested maritime environments.
In real missions, an autonomous system may lose connection to a control station. A fleet of uncrewed vessels may need to coordinate while operating across different network conditions. A system may only be able to communicate at specific intervals. A surface vessel may need to continue collecting, processing, and prioritizing data even when it cannot immediately transmit everything back to command.
If the system depends on constant connectivity, then the mission becomes fragile.
Resilient autonomy starts with a different assumption: Communications will degrade, links will fail, bandwidth will be limited, and the system must still continue operating safely and effectively.
That changes how infrastructure architects think about software, data, and mission behavior.
The Mission Must Continue Through Disruption
In a contested environment, the goal is not simply to avoid failure. The goal is to preserve mission effectiveness despite disruption.
That might mean continuing a search pattern after losing contact with a remote operator. It might mean prioritizing the most important sensor data when bandwidth is constrained. It might mean storing information locally until a connection is restored. It might mean allowing a group of autonomous systems to adjust coordination based on who can still communicate.
This is where resilience becomes more than a networking issue. It becomes a mission design issue.
Architects need to define what the system should do when conditions degrade. Which data is mission-critical? Which messages require immediate delivery? Which updates can tolerate delay? What decisions can happen onboard? What must wait for command authority? How should the system recover when communications return?
These questions cannot be answered at the end of development. They need to be part of the architecture from the start.
Designing for Degraded Operations
A resilient maritime autonomy system needs to make intelligent use of the network it has, not the network it wishes it had.
That requires software infrastructure that can support different behaviors under different conditions. Some data may need low-latency delivery. Some data may need high reliability. Some data may need to be filtered, compressed, or prioritized. Some information may need to be stored and forwarded later when communications are restored.
In a top-level discussion, these terms can sound technical. But the mission impact is straightforward: the system needs to understand which information matters most and how that information should behave when the network changes.
Not all data is equal. Let’s break it down by Priority, Periodicity and Package size.
- Commands require ensured delivery – for example, they need to be re-sent if dropped, so that would be high-priority. They tend to be aperiodic and generally medium-size, although lists of waypoints can grow. This includes command acknowledgements from the platform back to control as well.
- Telemetry, such as positional/speed updates, etc., are sent periodically – so if you miss one there is another one coming up. They tend to be lower priority, as we would prefer that a command be ensured to make it through. Telemetry updates tend to feature smaller message sizes.
- Sensor imagery is the type of data that needs the most attention – because it has the highest impact on link health. It requires a single owner to arbitrate across all users of the link to allow imagery/video to flow as needed. Depending on the scenario, it could easily be high-priority. Sensor imagery tends to generate large message sizes and is also sent periodically.
Resilient systems are designed to handle those differences.
Security is Part of Resilience
Contested environments are not only degraded. They may also be adversarial.
That means resilience must include secure data distribution. Autonomous maritime systems need to protect mission data, authenticate communications, and reduce the risk that compromised or unauthorized information can affect operations.
Security cannot be bolted on after the fact. If autonomous systems are expected to operate as part of a distributed mission environment, then trust in the data becomes essential. Operators and other systems need confidence that the information being shared is accurate, authorized, and protected.
In this sense, resilience includes both availability and trust.
A system that keeps communicating but cannot protect the integrity of its data is not truly resilient. A system that protects data but cannot continue operating through disruption is also incomplete. Maritime autonomy requires both.
Building Trust in Autonomous Fleets
For decision makers, the real issue is confidence.
Can the fleet continue the mission if a link drops? Can it recover gracefully when communications return? Can it prioritize the right data under bandwidth constraints? Can it keep operating safely when GPS is degraded? Can operators trust the information they receive from distributed autonomous assets?
These are the questions that determine whether maritime autonomy can scale from individual systems to operational fleets.
Trust in autonomy is not created by a single successful demonstration. It is built through consistent behavior in difficult conditions. Engineers need to show that their autonomous systems can handle uncertainty, disruption, and degraded environments without becoming brittle.
That is especially important as maritime missions become more distributed. The more platforms, sensors, and autonomous assets are added to the mission, the more important it becomes to manage data intelligently across unreliable networks.
The Path Forward
The future of maritime autonomy will depend on resilience as much as autonomy.
A vehicle that can navigate, sense, and make decisions is valuable. But an autonomous fleet that can continue operating through communications loss, GPS disruption, cyber pressure, and degraded network conditions is far more operationally relevant.
That is why resilience should be treated as a design principle from the beginning, not as a late-stage requirement. The challenge is to define how systems behave when conditions degrade, how data is prioritized, how trust is maintained, and how the mission continues when connectivity is limited or unavailable.
At sea, perfect connectivity is the exception, not the rule. The autonomous systems that matter most will be the ones that keep working anyway.
This is where the underlying data architecture becomes critical. RTI Connext helps provide the real-time, secure, data-centric foundation needed for distributed systems to share information reliably across changing and contested conditions. For maritime autonomy programs moving from controlled demonstrations to operational fleets, that foundation can help make the difference between systems that only work when connected and systems designed to continue the mission.
Please visit our website for more information on RTI in Maritime. You can also meet with RTI at the Unmanned Maritime Systems Technology USA event in Arlington, Virginia from September 14-16, 2026.
Contact RTI today to find out how our experts can help you optimize maritime autonomy.
(Banner image source: DVIDS: CTF 66 Conducts Autonomous Systems Demonstration During Obangame Express 2026, by CPO Justin Stumberg)
About the Author
David Greenberg is a Staff Application Engineer at RTI with over 10 years experience in building and developing solutions in the maritime autonomy space.