Success-Plan Services
David Greenberg
The need to support Autonomous Collaborative Teaming (ACT) puts increasing pressure on unmanned systems. Historically, these unmanned systems followed a simple model: one operator, controlling one machine, executing one mission thread. A control station talks to one platform over a known link, using known commands and status updates.
It’s true that managing command and control on an isolated, single-platform system requires only minimal operational complexity. The communication loop is highly predictable, outbound control commands move directly to the platform, and inbound status updates return along the same exclusive pipeline.
However, attempting to scale these systems for swarming and teaming meant that the traditional 1:1 model could quickly cause teams to run out of bandwidth and system capacity. In other words, the simpler model collapses when we scale beyond a single asset.
Even though these systems had proven their utility in the past, clearly a new model was needed as the push for more vehicles, sensors, payloads, and domains began. Operators required a cost-effective way to shift from controlling one machine to a supervisory role over multiple vehicles across land, sea and air, which is the one-to many (1:N) model.
The architecture must fundamentally shift when transitioning from 1:1 to 1:N fleet operations, and ultimately, to complex many-to-many (N:N) environments where multiple operators, platforms, and domains must collaborate simultaneously. This scalability challenge is further intensified when these operations must execute over unpredictable, resource-constrained networks.
The issue is no longer simply how to control an unmanned platform. The issue is how to control the flow of mission-critical data across a distributed system without overwhelming the tactical links that make command and control possible.
The Data Control Challenge
External mesh radio and satellite links connecting unmanned systems are inherently fragile. At the same time, internal sensors like Inertial Measurement Units, GPS, LiDAR, cameras, and other payloads are generating high-frequency data that was never intended to move freely across constrained external links.
As unmanned systems scale, the software architecture must enforce a strict data boundary between what should remain local to the platform and what must be shared across the mission network.
Failing to maintain this localization risks internal data spilling into external links, causing network saturation and bandwidth exhaustion. For defense operations, this outcome is catastrophic.
An overwhelmed tactical link severs the critical command and control (C2) loop. Operators may lose the ability to receive execution confirmations or critical system alerts. They may also lose the ability to transmit outbound directives like paths, re-tasking commands, or abort commands through the noise.
At that point, the problem is no longer just data management. This renders the network completely unusable for the entire fleet.
This is where many unmanned systems programs encounter a difficult architectural reality: approaches that work for a single platform do not necessarily scale to coordinated, multi-asset operations.
If you have a pool of platforms now that needs to be discovered on demand, do you hard code all the IP addresses to each platform? How do you ensure the internal processes are not all discoverable across the link and only expose the bare minimum?
When a command is intended for a specific vehicle, how do you ensure only that particular command message gets sent directly to the platform, instead of being broadcasted across the entire fleet? And how do you make sure only that specific message gets re-sent if dropped, but not your other high-rate status messages?
It’s a thorny issue that goes to the heart of efficient data control: When platforms, control stations, and mission systems alike are all producing and consuming data, how does the architecture route information efficiently? Even more to the point, how will that architecture simultaneously prevent redundant traffic from being re-ingested by the same systems that generated it?
These are the questions we have been drilling down on in our ACT reference architecture, which can provide teams with a highly useful starting point.
The Need for Message-Level Control
At the network level we already have the concept of a packet router, but it is time to introduce the next logical step and move boldly into message-level control. Because in a constrained, shared environment such as a mesh radio network, there needs to be a definitive arbiter of control over what data gets to leave the platform or control station.
For example, high-rate internal sensor data should not automatically be allowed across a constrained external link. In many cases, it should remain local. In other cases, it may need to be filtered, downsampled, or routed only under specific conditions.
The same principle applies to the command and control traffic side of the equation. Commands should not be broadcast broadly across necessary tactical links. They should be routed only to their intended destination, with the right delivery behavior based on mission need.
This requires more than basic connectivity. It requires an architecture that can understand, route, and govern data based on the content and purpose of the message itself.
That is the role of a message router. A message router can serve as the top level endpoint that acts as the entry point for the platform, control station or mission system. This will be the mechanism that handles discovery across a fleet and determines which messages are allowed to cross a constrained link, while enforcing routing policies that preserve network performance at every turn.
It also helps ensure that command messages reach only the intended destination, enabling more precise data routing while conserving limited bandwidth.
Just as importantly, the message router can enforce unidirectional policies. For example, platforms may receive specific target messages from controllers. Likewise, control stations may receive operational updates from specific platforms without allowing unnecessary peer-to-peer traffic to flood the network.
These rules would not be applied by coupling any specific platform to any other controller. Instead, they should be applied based on the data itself and per the mission state.
That is the value of a data-centric approach: the ability to control the data flow between systems by understanding the content, context and intended use of the data itself.
Accelerating the Path to Production
For unmanned systems programs, the ability to scale is not just a future requirement. It is quickly becoming a production requirement.
Programs are moving beyond demonstrations of individual platforms and toward coordinated fleets, collaborative autonomy, distributed sensing, and multi-domain mission execution. In that environment, data movement becomes one of the defining architectural decisions.
The RTI ACT reference architecture was created to help address this challenge.
Built on RTI Routing Service and Connext, our ACT reference architecture provides a practical foundation for applying data-centric routing principles to unmanned systems. It gives development teams a starting point for managing data flow, preserving constrained network resources, and scaling command and control across distributed platforms. Teams can then customize the architecture to their own mission needs, reduce integration friction, and accelerate the path from prototype to deployment
As unmanned systems continue to scale from one-to-one control to many-to-many coordination, the programs that succeed will be the ones that treat data control as a first-order architecture requirement.
Contact RTI today to learn more and try a demo of our ACT reference architecture.
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.