The proliferation of unmanned systems across all operational domains has outpaced the command and control infrastructure designed to manage them. A mechanised battalion that once tracked a handful of manned vehicle types now operates fixed-wing ISR UAS, rotary-wing multi-rotor platforms, loitering munitions, wheeled UGV scouts, and potentially USV assets in adjacent riverine or littoral areas — simultaneously, across the same battlespace, managed by operators who share a single common operating picture with the rest of the force. The result is a C2 integration challenge that is simultaneously a data engineering problem, a communications engineering problem, and a human-machine teaming design problem.
This article addresses each layer of that challenge: the taxonomy of unmanned systems and the protocol diversity it creates; the telemetry standards that bring vehicle data into the COP; the ground control station architecture that manages multi-vehicle operations; airspace deconfliction between UAS and manned aviation; swarm C2 for coordinated vehicle groups; and the legal and ROE constraints that govern unmanned engagement authority.
Unmanned system taxonomy: UAS, UGV, and USV
The term "unmanned systems" covers a wide range of vehicle types with fundamentally different C2 requirements. Understanding the taxonomy is the prerequisite for designing integration architecture that handles all of them.
Unmanned aerial systems (UAS) divide into three operationally significant categories. Fixed-wing UAS — ranging from hand-launched Group 1 platforms to medium-altitude long-endurance Group 4 systems — carry wide-area sensors and require runway or catapult launch and recovery infrastructure. Their C2 link requirements depend heavily on altitude and range: line-of-sight VHF/UHF for tactical platforms, SATCOM for MALE systems. Rotary-wing multirotor platforms dominate the small-UAS space, offer vertical takeoff and landing, and are the primary platform for urban reconnaissance and payload delivery at squad-to-company level. Loitering munitions — also called kamikaze drones or one-way attack UAS — are UAS that carry a warhead and are designed for terminal engagement against a target; their C2 integration requirements differ fundamentally from ISR UAS because every command sequence must comply with engagement authority rules.
Unmanned ground vehicles (UGV) are deployed in three primary roles. Reconnaissance UGV carry sensor payloads into areas too dangerous for dismounted scouts — building clearance, IED-suspected routes, forward observation positions — and return sensor data to the operator over short-range RF links. Logistics UGV carry resupply loads on preprogrammed or operator-guided routes, reducing the exposure of human drivers. Combat UGV — armed platforms with direct-fire weapons — are emerging but remain at low technology readiness levels in most programs, primarily because of the ROE compliance challenges associated with automating fire control.
Unmanned surface vessels (USV) operate in three primary roles: ISR — persistent surveillance of port approaches, rivers, and coastlines; mine countermeasures (MCM) — autonomous or semi-autonomous mine detection and neutralisation with the operator out of direct exposure; and surface strike — which carries the same engagement authority requirements as loitering munitions. USV C2 has the additional challenge of operating in environments where GPS may be unreliable near bridge infrastructure and where collision avoidance must comply with maritime COLREGs.
Telemetry standards: MAVLink 2, ROS 2, STANAG 4586, and CoT
Each vehicle category speaks a different native telemetry protocol. The C2 integration layer must either speak all of them natively or implement a gateway architecture that normalises them into a common internal representation.
MAVLink 2 is the dominant protocol for small and medium UAS, used by ArduPilot, PX4, and most commercial UAS platforms. It is a compact binary framing protocol designed for low-bandwidth radio links (as low as 1200 baud on early implementations). Version 2 added packet signing (HMAC-SHA256) for authentication and a 24-bit message ID space to support custom message extensions. A MAVLink telemetry stream carries vehicle position, attitude, airspeed, battery state, GPS fix quality, and payload status at configurable rates. The C2 integration gateway subscribes to the MAVLink stream, parses the relevant message types (GLOBAL_POSITION_INT, ATTITUDE, HEARTBEAT, COMMAND_ACK), and translates them into the COP's internal track format.
ROS 2 (Robot Operating System 2) with DDS (Data Distribution Service) transport is the preferred protocol for UGV platforms that carry significant onboard compute. Unlike MAVLink, which is a point-to-point protocol, ROS 2 uses a publish-subscribe architecture where the vehicle publishes to named topics (nav_msgs/Odometry, sensor_msgs/NavSatFix, geometry_msgs/Twist) and the C2 gateway subscribes. DDS provides quality-of-service policies for reliable and best-effort delivery, making it suitable for both high-rate sensor data and low-latency command delivery. ROS 2 interoperability between heterogeneous UGV platforms requires that topic names, message types, and QoS settings are standardised across platforms — a coordination task that is often neglected in multi-vendor UGV programs.
STANAG 4586 defines the NATO standard interface for UAV control systems, separating the operator-facing UCS (UAV Control System) from the vehicle-facing VSM (Vehicle-Specific Module) via a standardised interface data model. This separation allows a STANAG 4586-compliant GCS to control multiple UAS types by loading the appropriate VSM adapter without replacing the GCS software. STANAG 4586 is mandatory for NATO procurement programs and is the correct integration target for programs that require allied interoperability. The protocol covers mission planning, command delivery, telemetry return, and payload control within a single standardised message set.
Cursor-on-Target (CoT) XML is the lingua franca of TAK-ecosystem situational awareness platforms. While not a native vehicle control protocol, CoT is the standard format for injecting unmanned system tracks into ATAK, WinTAK, and iTAK displays used by ground operators. The telemetry gateway translates MAVLink or STANAG telemetry into CoT atom events that carry the vehicle's position, identity, and sensor footprint polygon, publishing them to the TAK server at a rate appropriate for the platform's speed (1 Hz for slow-moving UGV, 2–4 Hz for UAS). Operators see unmanned system tracks alongside manned force tracks in the same COP, with no protocol-specific knowledge required.
C2 architecture: GCS integration, relay nodes, handover, and bandwidth adaptation
The ground control station (GCS) is the operator interface through which unmanned system C2 is exercised. In a multi-domain operation, the GCS must integrate with the broader C2 stack rather than operating as a standalone application, while also managing the communications architecture that connects to the vehicles themselves.
Modern unmanned C2 architecture has three tiers. The vehicle tier encompasses the autopilot or onboard computer, the RF communications payload (typically a frequency-hopping spread-spectrum radio or SATCOM terminal), and the vehicle's native control interface. The GCS tier provides the operator with mission planning tools, real-time telemetry displays, payload control interfaces, and communications link management. The C2 integration tier provides the bridge between the GCS and the broader C2 system: it translates vehicle telemetry into COP track events, injects mission waypoints from the C2 planning layer into the GCS, and delivers sensor products (video, imagery, SIGINT) to the appropriate exploitation systems.
Relay and mesh relay nodes extend the UAS C2 link beyond line-of-sight distance. A relay UAS — typically a larger, longer-endurance platform — carries a radio relay payload that forwards GCS commands to forward-deployed UAS and returns their telemetry to the GCS. Mesh relay architectures distribute this relay function across multiple vehicles, providing redundant paths and the ability to continue operations if a single relay node is lost. The C2 system must track relay node status and alert operators when relay path degradation threatens link continuity to forward UAS.
GCS operator handover — transferring control of a vehicle from one operator to another, or from one GCS to another — is a safety-critical operation that the C2 system must support with an explicit, logged workflow. The handover sequence requires: the receiving operator to positively acknowledge the vehicle state and current mission; the releasing operator to confirm transfer; the vehicle to receive and confirm the handover command; and the C2 system to update the operator assignment record. An uncontrolled handover that leaves a vehicle in an uncommanded state is a safety hazard, particularly for UAS operating in shared airspace.
Bandwidth-adaptive telemetry is essential for operations where RF conditions vary, where multiple vehicles share a limited bandwidth allocation, or where EMCON constraints restrict transmission rates. The GCS should support configurable telemetry rates per vehicle and per message type, with automatic rate reduction when link quality degrades below threshold. Critical telemetry — position, link quality, battery state — should be prioritised over high-rate sensor telemetry when bandwidth is constrained. The C2 integration layer should track link quality per vehicle and surface degraded-link alerts to operators before loss-of-link contingency behaviours activate.
COP integration: track injection, sensor footprints, video association, and mission visualisation
The value of unmanned systems C2 integration is realised when ground commanders can see and task unmanned assets through the same COP interface they use for all other force elements — not through a separate GCS application that runs in parallel and requires context switching.
Track injection converts vehicle telemetry into COP track events. Each unmanned system track carries the standard track attributes — position, speed, heading, identity, affiliation — plus UAS-specific attributes: altitude (MSL and AGL), barometric pressure, GPS fix quality, and platform type. Track update rate is set by the C2 integration gateway, not the vehicle autopilot, allowing the COP display layer to receive consistent update rates regardless of the vehicle's native telemetry rate.
The sensor footprint polygon projects the current coverage area of the vehicle's EO/IR or SAR sensor onto the map. For an EO/IR gimbal, the footprint is computed from the gimbal azimuth and elevation angles, the sensor field of view, and the vehicle altitude above ground level (derived from terrain elevation data). The resulting ground polygon is included as a CoT detail element and rendered as a shaded overlay on the operator's map, allowing ground commanders to understand what the UAS sensor is currently covering without reviewing a separate video feed.
Video link association connects the UAS track in the COP to the live video stream from the platform's sensor payload. The track event carries the video feed URI — an RTSP stream address hosted by the GCS or a relay server — which the COP client uses to open the video feed when the operator clicks the track icon. This association must be maintained dynamically: as the video relay path changes (GCS-hosted vs relay-node-hosted), the URI in the track event must update to point to the currently active stream endpoint.
Mission waypoint visualisation renders the planned route of each UAS as a line overlay on the map, with waypoints shown as labelled points carrying altitude and action information (loiter, descend, payload trigger). As the vehicle executes the mission, the current target waypoint is highlighted, giving operators an immediate understanding of mission progress without requiring them to open the GCS mission planner interface.
Airspace deconfliction: conflict detection, dynamic geofencing, and UTM integration
Airspace deconfliction is the C2 function that prevents UAS operations from creating collision hazards with manned aviation and other UAS, and that ensures UAS operations remain within their authorised geographic and altitude bounds.
Automated conflict detection operates in two time horizons. Strategic conflict detection evaluates proposed UAS mission routes against the aviation coordination framework before mission authorisation: known air corridors, temporary restricted airspace (TRA), danger areas, and other planned UAS routes are checked against the proposed route, and conflicts are flagged for resolution before the mission is approved. Tactical conflict detection runs continuously during mission execution, monitoring all active UAS tracks against manned aviation transponder data and generating real-time separation alerts when predicted separation minima are going to be violated within a configurable time horizon (typically 2–5 minutes for medium UAS).
The primary input to tactical conflict detection is ADS-B Out data from manned aircraft, which broadcasts position, altitude, and velocity every second and is receivable with a low-cost SDR payload on the UAS itself or at the GCS. In environments where manned aircraft may not carry ADS-B (combat aircraft operating under EMCON, rotary-wing at low altitude), the deconfliction system must rely on pre-coordinated airspace reservations rather than real-time transponder data.
Dynamic geofencing enforces geographic and altitude bounds on UAS operations in real time. A geofence definition specifies a polygon or cylinder within which the UAS is authorised to operate. If the vehicle approaches the geofence boundary, the C2 system issues an alert; if it crosses the boundary, the system can be configured to issue an automatic return-to-home or orbit command depending on the operational context. Geofence definitions must be updatable in flight to support dynamic airspace management — for example, pushing a geofence update that permits entry into an area that has just been cleared of manned aviation.
UTM (Unmanned Traffic Management) integration provides a coordination interface with the national or theatre-level UAS traffic management service. UTM integration allows the C2 system to submit flight plans for approval, receive real-time updates on airspace restrictions, and coordinate with civil UAS operations in contested or shared airspace. In practice, military UTM integration is still maturing in most NATO nations, and current operational architectures rely primarily on human coordination through aviation coordination channels rather than automated UTM API calls.
Human-machine teaming: supervision ratios, autonomy levels, and override authority
The human-machine teaming design of unmanned systems C2 determines the number of vehicles one operator can manage effectively, the degree of autonomy granted to vehicles for different task categories, and the mechanisms by which human operators maintain meaningful control over vehicle behaviour.
Supervision ratio — the number of vehicles one operator can effectively manage — depends on mission complexity, vehicle autonomy level, communication reliability, and the cognitive load of the operator's other duties. For pre-programmed ISR missions with stable links, automated anomaly alerting, and minimal replanning requirements, a single UAS operator can supervise 4–8 platforms. For dynamic missions with active targeting, frequent waypoint modification, and coordination with ground elements, the practical ratio is 1:2 or 1:3. The C2 system design should target the operator's attention rather than optimising for the maximum theoretical ratio: an operator managing 8 platforms who misses a critical engagement window is less effective than an operator managing 3 platforms who responds to every significant event.
Autonomy level selection follows a structured taxonomy — analogous to the SAE levels for automotive automation — that specifies the degree to which the vehicle can initiate and execute actions without operator instruction. At lower autonomy levels, the vehicle executes operator commands but does not respond autonomously to environmental changes. At higher levels, the vehicle can re-route around obstacles, return to home on link loss, or execute pre-authorised actions within a defined envelope. The C2 system allows operators to set the autonomy level per vehicle and per mission phase, ensuring that higher autonomy is available for routine transit phases while reverting to lower autonomy for sensitive phases that require closer operator supervision.
Override authority is the guaranteed capability of the operator to take immediate manual control of any vehicle at any autonomy level. Architecturally, override commands must have higher priority than any autonomous behaviour and must be delivered to the vehicle on the most reliable available link. The override workflow should require a single unambiguous operator action — a dedicated button or command — and should not be buried behind confirmation dialogs that add latency to time-critical interventions.
Swarm C2: task allocation, formation control, communication topology, and graceful degradation
Swarm C2 extends the single-vehicle human-machine teaming model to groups of vehicles that coordinate their behaviour to achieve collective objectives. The fundamental challenge is to provide operators with meaningful supervisory control over the swarm's collective behaviour without requiring them to manage individual vehicle actions.
Task allocation in operational swarm C2 systems uses market-based or consensus-based algorithms to assign tasks from a task pool to individual vehicles based on capability, position, and endurance. The operator specifies the objective — cover this search area, establish a communications relay network between these two points — and the task allocator assigns individual vehicles to roles and routes. Operators can inspect assignments, override specific vehicle assignments, and modify the objective; the allocator then re-optimises remaining assignments to reflect the changes. This objective-specification model scales to large swarms without requiring per-vehicle operator attention.
Formation control maintains geometric relationships between vehicles during transit or area coverage, using onboard relative positioning (GPS differential or visual) and inter-vehicle communication to maintain formation without per-vehicle operator commands. The C2 system exposes formation type selection (line, echelon, wedge, area-coverage grid) and a formation spacing parameter; the vehicles maintain the specified geometry autonomously.
Communication topology in a swarm determines which vehicles communicate directly with the GCS and which communicate via inter-vehicle relay. The C2 system must visualise the current communication graph — showing which links are active, their quality, and which vehicles are reachable through which paths — and alert operators when topology changes (vehicle loss, link degradation) reduce swarm coherence.
Graceful degradation under jamming is the swarm's ability to continue executing its mission when communication with some or all vehicles is disrupted. Vehicles that lose link fall back to pre-programmed contingency behaviours — continue current task, return to home, orbit at current position — based on the mission phase and remaining endurance. The C2 system tracks which vehicles are in contingency mode and alerts operators, who can prioritise link restoration efforts. Task allocation algorithms should be designed to redistribute incomplete tasks to vehicles that remain reachable when some vehicles enter contingency mode.
Legal and ROE compliance: LAWS policy, human-in-the-loop, and audit trail
The legal and policy framework governing unmanned system engagement authority is the constraint that shapes the entire C2 architecture for lethal or potentially lethal unmanned systems. Understanding it is not optional for architects building systems that will be procured by or used alongside NATO forces.
Lethal autonomous weapons systems (LAWS) policy at NATO and among most member states prohibits fully autonomous lethal engagement — engagement where the system selects and attacks a target without per-engagement human authorisation. Current policy requires meaningful human control over each individual engagement decision for actions that constitute a use of force. This prohibition is not merely a doctrinal preference; it is implemented as a procurement requirement and an operational constraint. C2 systems that architecturally permit autonomous engagement — even if it is not operationally enabled by default — create legal liability and procurement risk for the customer.
Human-in-the-loop requirements for unmanned engagement authority are implemented in the C2 architecture as a mandatory authorisation step in the engagement command pathway. The authorisation step must: present the operator with sufficient target identification information to make an independent judgment; impose a time-bounded decision window (the authority expires if not acted upon); require a positive authenticated operator action to issue the engagement command; and log all information presented, the operator's identity, the decision, and the timestamp in an immutable record. The system must not allow autonomous progression from target nomination to terminal guidance without this authorisation step being completed.
Audit trail for engagement decisions must record: the target identification basis (what sensor data, reported by whom, assessed by what process); the COP state at the time of the engagement decision (what other information was available to the commander); the ROE authority under which the engagement was authorised; the operator who issued the engagement command and the command time; and the time-of-flight and terminal guidance events. This record must be stored in immutable form, attributable to individual operators, and retained according to mission records management requirements. The audit trail serves three functions: LOAC accountability, operational after-action review, and evidence in any post-engagement investigation.
ROE-defined no-strike areas must be implemented as hard geofence constraints in the C2 system — not as advisory warnings that operators can dismiss. An engagement command that would direct a loitering munition toward a target inside a no-strike area must be architecturally prevented, not merely flagged. The geofence database must be updateable through a secure, authenticated channel, and all updates must be logged with source authority and timestamp.