Artillery fire control integration with C2 systems

Artillery fire missions have always depended on accurate data moving quickly between multiple actors: the observer who identifies the target, the fire direction center that computes firing data, and the gun line that executes. What has changed in modern artillery operations is the scope of the picture those actors need to share. Today a fire mission does not just involve the battery — it involves the brigade-level C2 platform that holds the common operational picture, the airspace management layer that must clear the trajectory, and a growing array of unmanned sensors that generate the target data in the first place. Connecting all of that in real time, without reversion to voice radio and manual coordinate re-entry, is the artillery fire control C2 integration problem.

This article examines the technical architecture of that integration. It covers how target data flows from sensor to FCS, the data standards that govern fires interoperability, how C2 software handles airspace deconfliction during a mission, and the latency and reliability requirements that separate a viable fires integration from one that operators will abandon under pressure. It is written for software engineers building or evaluating C2 platforms with fires capability, and for procurement teams assessing whether a candidate system meets the integration requirements of a combined arms force.

The fires integration challenge: three systems that must agree in real time

A modern indirect fires engagement involves at least three distinct software systems that each hold different, partially overlapping views of the battlefield. The sensor layer — whether a forward observer with a laser rangefinder and a tablet, a UAV with a gimbaled EO/IR camera, or a counter-battery radar — produces target data: coordinates, target type, time of detection, and confidence. The fire control system (FCS) — historically AFATDS on the US side, various national equivalents elsewhere — receives fire mission requests, computes firing data, manages the battery queue, and transmits fire commands to individual guns. The C2 platform holds the common operational picture: all friendly tracks, all known threat tracks, fire support coordination measures, active airspace reservations, and the operational timeline.

The integration challenge is that none of these systems was designed, originally, to talk to the others in real time over a shared data model. AFATDS was built as a self-contained fires system with defined message interfaces; the C2 platform was built around track management and display; the sensor layer evolved from standalone targeting tools. Connecting them without creating a single point of failure — and without introducing so much latency that operators revert to voice — requires careful attention to where the integration points are, what data formats those points use, and how the systems degrade gracefully when the network is intermittent.

AFATDS and the standard fire mission workflow

The Advanced Field Artillery Tactical Data System (AFATDS) is the US Army's primary FCS and the most widely integrated artillery software in NATO-partnered forces. Understanding its workflow is a prerequisite for designing any C2-to-fires integration, because most national FCS equivalents follow similar workflow patterns even when the specific message formats differ.

In the AFATDS model, a fire mission begins with a call for fire (CFF) submitted by a forward observer. The CFF contains the target location (MGRS or lat-lon), target description, method of engagement, and method of fire control. AFATDS receives the CFF, runs fire mission processing — computing firing data based on the weapon system, ammunition type, meteorological data, and terrain — and generates a fire mission order (FMO) transmitted to the designated battery. The battery section chief acknowledges the FMO, executes the mission, sends a shell-on-the-way (SOW) notification back to the FDC, and closes with an end-of-mission (EOM) report.

The C2 integration points in this workflow are: the CFF submission (the C2 platform should receive target data from the sensor layer and generate a CFF without requiring manual re-entry); the active fire mission display (the C2 COP should show each active fire mission as a spatial overlay so that all actors — not just the FDC — can see where rounds are going); and the EOM record (the mission outcome should update the C2 track database and feed the intelligence picture). Achieving all three without creating a brittle custom interface to a single FCS variant is the core engineering challenge.

Target data flow: from sensor to gun line

The data path from target detection to rounds on target crosses several format boundaries. At each boundary, a translation or adaptation occurs — and each translation is a potential source of error, latency, and information loss.

Sensor to C2 track. Target data from a UAV or a laser rangefinder arrives at the C2 platform as a Cursor-on-Target (CoT) event, a USMTF SPTREP (spot report), or a proprietary sensor feed. The C2 platform resolves this to a track: a point on the map with a UID, coordinates, target type, and timestamp. For artillery purposes, the coordinate accuracy of this track is critical — a 50-meter error in the target location translates directly to a 50-meter miss for an unguided round, and to a potential miss of the target entirely for precision munitions with CEP requirements.

C2 track to fire mission request. The fire mission request (call for fire) is generated by the C2 platform's fires workflow, using the target track as its source. The request must be formatted as a USMTF CFF message for transmission to AFATDS, or as the national-equivalent format for other FCS types. The C2 platform must translate the internal track representation to the required message format without losing the coordinate datum (WGS-84 vs. local datum differences have caused significant errors in legacy systems), without dropping required fields, and without introducing coordinate rounding that degrades accuracy below the FCS's computational precision.

FCS to fire mission order. AFATDS or the national FCS equivalent processes the CFF and returns a fire mission order to the battery. This message travels over a tactical data network — typically a radio data link operating at low bandwidth. The FMO contains the weapon, propellant charge, fuze setting, deflection, quadrant elevation, and the number of rounds. The C2 platform may receive a copy of the FMO for display purposes, but it is not in the FMO's control path — that remains entirely within the FCS.

Shell-on-the-way to COP overlay. When rounds are in flight, the C2 platform should display a dynamic overlay on the COP showing the projected impact area based on the computed firing data. This overlay serves both the tactical picture — all actors can see where rounds are going — and the airspace deconfliction function — aircraft tracks can be checked against the active trajectory in near-real time rather than only at mission initiation.

NATO STANAG data standards for fires

Multinational fires integration requires shared data standards that allow a national C2 platform to receive and correctly interpret fire support data generated by an allied FCS. The relevant standards form a small but important body of agreements that any C2 platform operating in a combined arms environment must implement.

STANAG 4677 is the core fire support data standard. It defines the data structures for fire support coordination measures (FSCMs): fire support coordination lines (FSCL), coordinated fire lines (CFL), no-fire areas (NFAs), and restrictive fire areas (RFAs). Each FSCM has a geometric definition (polygon, line, or circle in a standard coordinate reference), an identifier, an effective time window, and a controlling authority. STANAG 4677 compliance means a C2 platform can import FSCM data from an allied fires network, display it correctly, and apply it in automated deconfliction checks — without any custom translation per allied nation.

STANAG 2181 addresses the procedural standards for fire support coordination, providing the doctrinal framework that the software must enforce. Where STANAG 4677 defines data structures, STANAG 2181 defines what those structures mean operationally and how coordinators are expected to use them. A C2 platform that correctly implements STANAG 4677 geometry but ignores STANAG 2181 coordination procedures will pass interoperability tests while failing operationally.

USMTF (United States Message Text Format) remains the dominant message format for fire mission exchange in US and US-partnered forces. The relevant messages — CALL FOR FIRE (FIREFAN), ADJUST FIRE, FIRE FOR EFFECT, SHELL REP, and END OF MISSION — carry the full fire mission workflow. USMTF messages are structured fixed-format text; they are verbose by modern standards but are well understood by FCS implementations and have the advantage of being human-readable in debug scenarios. Newer implementations wrap USMTF message semantics in XML or JSON schemas for easier integration with modern C2 APIs while maintaining payload compatibility.

Airspace deconfliction: clearing the trajectory, not just the target

Airspace deconfliction is one of the most technically demanding aspects of fires C2 integration, because it requires the C2 platform to reason about projectile trajectories — not just target points — in three dimensions and in near-real time.

A 155mm artillery round fired at a target 25 kilometers away follows a ballistic trajectory that may reach an apex of 6,000–8,000 meters altitude. Any rotary-wing or fixed-wing aircraft operating in the altitude band along that trajectory must be cleared before the fire mission proceeds. Checking only the target point — a common shortcut in immature implementations — misses the entire trajectory corridor and can clear a mission that would place a round through an aircraft's flight path at mid-trajectory.

A robust deconfliction implementation works as follows. When a fire mission request is processed, the FCS or the C2 integration layer generates a trajectory envelope: a corridor defined by the projectile's ballistic path from muzzle to target, expanded by a safety buffer that accounts for dispersion (CEP), meteorological uncertainty, and the minimum separation distance required for aircraft safety. This envelope is represented as a time-parameterized 3D volume — the projectile occupies different parts of the corridor at different times after firing, so the deconfliction check must account for when the aircraft will be at a given position, not just where it is at the moment the check runs.

The C2 platform queries its airspace management layer for all active flight plans, ATC holds, and minimum risk routes that intersect the trajectory envelope during the expected time window of the mission. Any intersection generates a conflict. The C2 interface presents the conflict to the fire mission coordinator: which aircraft (by track designation), at what altitude, at what time, and what the separation distance would be at closest approach. The coordinator can request the aircraft vacate the corridor, request a different flight route, or — in exceptional circumstances and with appropriate authority — accept the risk and override the conflict. All override decisions are logged with the acting operator's identity and timestamp.

Integration with JTAC and CAS coordination workflows adds another dimension. When a close air support mission is active in an area adjacent to an artillery fire mission, the C2 platform must maintain awareness of both simultaneously and prevent their geometries from creating a mutual conflict — an artillery trajectory that crosses an active CAS ingress route, for instance. This level of fires-airspace integration requires a unified airspace management layer in the C2 platform, not separate silos for artillery and air coordination.

Latency and reliability requirements

Fires integration is one of the few domains in military C2 software where latency requirements are driven not by operational preference but by the physics of the engagement timeline.

The planning figure for acceptable fire mission data exchange latency — from observer target entry to FCS receipt of the fire mission request — is under 5 seconds at the 95th percentile. This figure follows from the time-on-target requirement for time-sensitive targets: in a mature fires workflow, the goal is to achieve first round on target within 60 seconds of observer report for immediate suppression, and within 3 minutes for deliberate engagement. A 5-second latency budget for the data exchange step consumes a manageable fraction of that timeline. A 30-second latency — which is common in systems that route fire mission requests through a cloud-hosted server without tactical edge caching — makes digital fires integration slower than voice procedure and guarantees that operators will revert to radio under pressure.

Reliability requirements are equally unforgiving. A fire mission request that is silently dropped — accepted by the C2 client with no error but never delivered to the FCS — is operationally equivalent to a total system failure for that mission. The fires integration must implement acknowledged delivery: the FCS must send an acknowledgment when it receives the CFF, and the C2 platform must alert the operator if no acknowledgment is received within a defined timeout. Silent drops are not acceptable.

High availability matters across the full battle rhythm, not just during individual missions. A battery that is engaged in ongoing fire support operations may be running 50–100 fire missions per hour across multiple observers. The C2-to-FCS integration must handle sustained throughput without degraded latency, and must fail gracefully when the network is intermittent — queuing messages locally, attempting retransmission on reconnect, and surfacing queue status to the operator so they know the system state at all times.

The combination of low latency, acknowledged delivery, and sustained throughput under intermittent connectivity is a demanding reliability profile. It is why fires integration is frequently cited as the most technically challenging of the C2-fires integration problems, and why immature implementations tend to fail in exactly the high-tempo scenarios where they matter most. For a broader view of how these requirements fit within a full C2 architecture, see the C2 dashboard architecture article, which covers the full-stack design considerations for mission-critical C2 display systems.

Implementation patterns: gateway, native integration, and API-first

In practice, C2-to-FCS integration is implemented through one of three architectural patterns, each with different trade-offs for latency, maintainability, and vendor dependency.

Gateway integration inserts a translation service between the C2 platform and the FCS. The gateway receives fire mission requests from the C2 platform in the C2's internal format, translates them to USMTF or the FCS-native format, and forwards them to the FCS. The gateway also receives FCS outputs and translates them back to the C2 format for display. Gateway integration is the fastest path to interoperability with an existing FCS but adds a component to the critical path and makes the integration dependent on the gateway's availability. Gateways also tend to accumulate feature debt as both the C2 platform and the FCS evolve — each version change requires gateway updates, and the gateway's field of view is limited to the message formats it was written to handle.

Native integration means the C2 platform implements the FCS's message interfaces directly, without an intermediate gateway. For AFATDS this means implementing the USMTF message set natively in the C2 platform's fires module. Native integration reduces the component count in the critical path and removes the gateway as a failure point, but it couples the C2 platform's development cycle to the FCS's interface specifications. When AFATDS updates its message formats — as it has done across major version releases — the C2 platform must update its native implementation in lockstep.

API-first integration is the emerging pattern for new FCS development and for C2 platforms targeting a multi-FCS environment. The FCS exposes a REST or gRPC API that abstracts its internal message format behind a standard data model aligned to STANAG 4677 and USMTF semantics. The C2 platform integrates against the API rather than the message format. This decouples the two systems from each other's internal implementation details and allows the FCS to evolve internally without breaking the C2 integration. The trade-off is that API-first requires the FCS vendor to invest in and maintain the API layer — a commitment that legacy FCS programs have been slow to make.

Corvus.Head: fires coordination in the C2 dashboard

Effective fires integration is not just a data exchange problem — it is a display and workflow problem. The C2 dashboard must present fire mission status, active FSCMs, airspace deconfliction results, and battery availability in a way that allows a fires coordinator to manage multiple concurrent missions without losing situational awareness of the broader operational picture. Corvus.Head is designed around exactly this requirement: a unified C2 dashboard that integrates the fires picture alongside ISR tracks, friendly force positions, and airspace management into a single coherent display, with fires workflow tools — mission request, deconfliction check, status tracking — built into the same interface rather than requiring operators to switch between separate applications.