Aerospace, Military & Defence Focus
Command and control: the data challenge behind building unmanned systems at scale
By David Greenberg, staff application engineer at RTI T
he 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
22 September 2026
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
Components in Electronics
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
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
