Command and control: what is the data challenge behind building unmanned systems at scale?
By David Greenberg, staff application engineer at RTI
The need to support Autonomous Collaborative Teaming (ACT) is putting increasing pressure on unmanned systems. In the past, the way these unmanned systems worked was pretty straightforward: one operator, controlling one machine, and one mission thread being carried out. A control station communicated with one platform via a known link, using recognised commands and status updates.
It’s true that managing command and control on an isolated, single-platform system requires only minimal operational complexity, which is a significant advantage in terms of ease of use. The communication loop is very predictable. Outbound control commands go directly to the platform, and inbound status updates come back 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. It could also cause them to run out of system capacity. In other words, the simpler model breaks down when we scale up beyond a single asset.
While these systems had previously proven their utility, it was clear that a new model was needed as the demand for more vehicles, sensors, payloads, and domains increased. Operators needed a cost-effective way to transition from controlling one machine to supervising multiple vehicles across land, sea, and air – the one-to-many (1:N) model.
The architecture must shift fundamentally 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. It is now about controlling the flow of mission-critical data across a distributed system without overwhelming the tactical links that enable command and control.
The data control challenge
External radio and satellite links connecting unmanned systems are fragile by nature. At the same time, internal sensors such as inertial measurement units, GPS, LiDAR and cameras are generating high-frequency data that was never intended to move freely across these links.
As unmanned systems become more widespread, the software architecture must enforce strict data boundaries to ensure that information remains local to the platform where appropriate and is shared across the mission network where necessary. Failing to maintain this localisation can result in internal data spilling into external links, causing network saturation and exhausting bandwidth. For defence operations, this outcome would be catastrophic. An overwhelmed tactical link can sever 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 directives such as paths, re-tasking commands or abort commands through the noise. At that point, the problem extends beyond data management. This renders the network completely unusable for the entire fleet.
Many unmanned systems programmes encounter a difficult architectural reality here: approaches that work for a single platform do not necessarily scale to coordinated, multi-asset operations.
If you have a pool of platforms that needs to be discovered on demand, how can you ensure that all the IP addresses are not hard coded to each platform? How can you ensure that the internal processes are not discoverable across the link and that only the bare minimum is exposed?
When a command is intended for a specific vehicle, how can you ensure that only that particular command is sent directly to the platform instead of being broadcast across the entire fleet? How do you ensure that only that specific message is resent if dropped, but not your other high-rate status messages?
These are thorny issues that go to the heart of efficient data control. When platforms, control stations and mission systems are all producing and consuming data, how does the architecture efficiently route information? More importantly, how will that architecture prevent redundant traffic from being re-ingested by the same systems that generated it?
We have been drilling down on these questions in our ACT reference architecture, which can provide teams with a highly useful starting point.
The need for message-level control
We already have the concept of a packet router at the network level, but it is time to take the next logical step and embrace message-level control. In a constrained, shared environment such as a mesh radio network, there needs to be a definitive arbiter of control over which data is allowed to leave the platform or control station. For instance, high-rate internal sensor data should not be permitted to automatically cross a constrained external link. In many cases, it should remain local. In other cases, it may need to be filtered or downsampled, or only routed under specific conditions.
The same principle applies to command and control traffic. Commands should not be broadcast broadly across necessary tactical links. They should only be routed to their intended destination with the correct delivery behaviour based on mission requirements.
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. This is the role of a message router. A message router can serve as the top-level endpoint acting as the entry point for the platform, control station, or mission system. It will handle discovery across a fleet and determine which messages are allowed to cross a constrained link while enforcing routing policies that preserve network performance. It also helps to ensure that command messages only reach their intended destination, enabling more precise data routing while conserving limited bandwidth.
Equally importantly, the message router can enforce unidirectional policies. For instance, platforms can receive targeted messages from controllers. Likewise, control stations can receive operational updates from specific platforms, preventing unnecessary peer-to-peer traffic from flooding 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 according to the mission state. This is the benefit of a data-centric approach: the ability to control data flow between systems by understanding its content, context, and intended use.
Accelerating the path to production
For unmanned systems programmes, the ability to scale is not just a future requirement. It is quickly becoming a production requirement. Programmes are moving beyond demonstrations of individual platforms towards coordinated fleets, collaborative autonomy, distributed sensing and multi-domain mission execution. In that environment, data movement becomes one of the most important architectural decisions.
The RTI ACT reference architecture was created to address this challenge. Built on the RTI Routing Service and Connext technologies, the ACT reference architecture provides a practical foundation for applying data-centric routing principles to unmanned systems. It provides development teams with a starting point for managing data flow, preserving constrained network resources and scaling command and control across distributed platforms. They can then customise the architecture to their own mission needs, reduce integration friction, and accelerate the path from prototype to deployment.
As unmanned systems continue to evolve from one-to-one control to many-to-many coordination, those that treat data control as a primary architectural requirement will be the ones that succeed.
For more news please visit: News – CIE
