Fires deconfliction software: clearing joint fires in near real time

A modern battlespace is crowded with things that fly. Artillery shells arc to a maximum ordinate of several kilometers. Rotary-wing aircraft transit at low level. Fixed-wing aircraft run attack profiles. Loitering munitions and reconnaissance drones occupy the medium altitudes. Naval gunfire reaches inland. When several of these are active in the same area at the same time, the risk is not abstract: a single uncoordinated fire mission can put a shell through the same volume of airspace an aircraft is flying through, or land it on a hospital that the rules of engagement protect. Fires deconfliction software exists to make sure that does not happen – and to do it fast enough that it never becomes the reason a fleeting target escapes. This article examines how that software works: airspace coordination, no-strike and restricted target lists, the clearance-of-fires workflow, and integration with the common operational picture.

What fires deconfliction actually has to solve

Deconfliction has two distinct dimensions that are often conflated. The first is positional deconfliction: keeping fires and aircraft apart in space and time. The second is target deconfliction: making sure the thing being struck is a lawful, authorized target and that it is not already being engaged by someone else. Good software treats these as separate checks with separate data sources, because they fail in different ways and require different resolutions.

Positional deconfliction is fundamentally a geometry problem in four dimensions – three of space and one of time. An artillery trajectory is not a point; it is a curved volume that exists for a bounded window. An aircraft is not a point either; it is a track with a velocity vector and a protective bubble around it. The deconfliction engine must determine whether those two volumes intersect during the moments both are present. Target deconfliction, by contrast, is a rule-and-lookup problem: does this aimpoint fall inside a protected area, does it carry a firing constraint, and is the same target already assigned to another shooter?

The hard part is doing all of this in seconds. A call for fire against a moving, time-sensitive target may have a window of a minute or less before the target relocates. If the deconfliction process takes longer than that window, it has functionally denied the mission. Every design decision in fires deconfliction software is shaped by this latency constraint.

There is also a coordination dimension that pure geometry misses. Multiple shooters – a gun battery, a mortar section, an attack aviation element, and a strike aircraft – may all be cued onto the same area by different headquarters that do not see each other's missions. Without a shared deconfliction service, each call for fire is cleared in isolation against a partial view of what else is happening, which is exactly how a duplicate engagement or a near-miss between a shell and an aircraft occurs. The software's job is therefore not only to evaluate one mission, but to evaluate it against every other fire and aircraft active in the same battlespace at the same instant, drawn from one shared data source.

Airspace coordination: modelling the trajectory

The core of positional deconfliction is an accurate trajectory model. When a fire support element selects a weapon, charge, and target, the software computes the ballistic path: the launch point, the gun-target line, the maximum ordinate, the descent angle, and the time of flight. This produces a swept volume – a tube of airspace the projectile will occupy – paired with a time-on-target window during which that volume is dangerous.

That volume is then checked against the airspace as it is currently structured. Airspace coordination measures (ACMs) divide the airspace into managed regions: restricted operations zones, coordinating altitudes, low-level transit routes, and standard-use army aircraft flight routes. Aircraft also appear as live tracks pulled from the C2 picture, each with a position, heading, speed, and an uncertainty volume that grows with track age. The engine intersects the projectile tube against both the static ACMs and the dynamic tracks.

When the trajectory pierces an occupied or restricted volume during the firing window, the system raises a conflict. Crucially, it does not simply say "no." It proposes resolutions ranked by operational impact: a time separation (fire after the aircraft clears), a lateral airspace restriction, an altitude block (a maximum ordinate restriction that may force a different charge or trajectory), a change of firing position, or – as a last resort – a hold. The fire support coordinator chooses, and the chosen trajectory becomes the one that is cleared and fired.

Why the maximum ordinate matters

A common failure in naive deconfliction tools is treating the trajectory as a straight gun-target line. Indirect fire does not travel in a straight line; a high-angle mortar mission may reach an apex far above the cruising altitude of a transiting helicopter that is nowhere near the gun or the target. Deconfliction that ignores the maximum ordinate will clear a mission that is in fact dangerous. The trajectory model must carry the full arc, including apex altitude, and the airspace check must be performed against that arc, not a simplified line. This is the single most important correctness property of an airspace deconfliction engine.

No-strike and restricted target lists

Target deconfliction begins with two reference datasets. The no-strike list (NSL) enumerates entities protected from deliberate engagement under the law of armed conflict and the rules of engagement: medical facilities, places of worship, cultural property, schools, dams, and other protected structures. The restricted target list (RTL) holds targets that may be engaged only under constraints – a specific approval authority, a particular weapon, a collateral-damage threshold, or a timing limit (for example, a bridge that may not be struck before a named hour).

In software, both lists are stored as geofenced records: each entry has a footprint, a protection or restriction type, and an effective time window. When a target is resolved, the software buffers the aimpoint by the weapon's expected effects radius – its lethal and collateral-damage area – and tests that buffered footprint against the NSL and RTL. An intersection with the no-strike list blocks the mission and surfaces the protected entity to the operator. An intersection with the restricted target list does not block; it escalates, attaching the applicable constraint and routing the mission to the required approval authority.

The discipline here is that the lists must be authoritative and current. A stale NSL is worse than no NSL, because it creates false confidence. Fires deconfliction software therefore versions these lists, timestamps every update, and refuses to clear fires against a list older than a configurable staleness threshold – forcing a deliberate human acknowledgement rather than silently proceeding on outdated data.

The clearance-of-fires workflow

Clearance of fires is the authoritative statement that a mission is deconflicted, lawful, and approved to fire. It is the moment of accountability, and in software it must be modelled as an explicit, auditable workflow rather than an implicit side effect of pressing a button.

The workflow chains the pieces together. A digital call for fire enters the system. The engine runs the target checks (NSL/RTL, duplicate engagement) and the airspace checks (trajectory versus ACMs and tracks), attaching its findings to the mission. The mission, with its findings, is routed to the required authorities – the fire support coordinator, and any maneuver commander whose forces or area of operations are affected. Each authority sees the same conflict findings and records an explicit clear or deny decision. Only when all required clearances are recorded does the system release the mission to the firing unit.

Two properties make this workflow trustworthy. First, every automated check result and every human decision is timestamped and written to an immutable log, so the clearance can be reconstructed and reviewed after the fact – essential for both training and accountability. Second, the workflow has explicit roles and authorities; the software enforces who is permitted to clear what, the same way a COP enforces role-based access to data. A fire support officer can clear within delegated authority; a mission touching the restricted target list is escalated to the named approval authority and cannot be cleared below that level.

Integration with the C2 picture

Fires deconfliction cannot run on a private island of data. The airspace check is only as good as the track and airspace data feeding it, and the only authoritative source of that data is the C2 picture. The deconfliction engine therefore subscribes to the common operational picture for live aircraft and friendly-force tracks, and ingests airspace coordination measures and fire support coordination measures (FSCMs) as map overlays maintained by the airspace and fires cells.

It also publishes back. When a mission is cleared, the active coordination measure – the volume and window of airspace the fire occupies – is published to the COP using Cursor on Target and allied fires message formats, so adjacent units and aircraft see the airspace as hot for the firing window. This closes the loop: the system that decides whether a fire is safe is working from, and contributing to, the same authoritative picture that the artillery cell, the airspace cell, and the maneuver commander all see. This is the same integration discipline that connects fire control systems to the C2 picture more broadly.

The message formats matter for interoperability. In a coalition, fires and airspace data must move between national systems. Building on STANAG-defined fires and airspace message sets, and on Cursor on Target for position reporting, lets a deconfliction engine consume an allied unit's flight routes and publish its own coordination measures without bespoke per-partner adapters.

Degraded communications change the integration picture but do not suspend the requirement to deconflict. Forward fires cells frequently operate on low-bandwidth, intermittent links where the full COP cannot be streamed in real time. A robust deconfliction engine maintains a locally cached copy of the airspace measures, the no-strike and restricted lists, and recent tracks, and it stamps every cached element with an age. When connectivity drops, the engine keeps clearing fires against the cached data – but it raises the staleness threshold's prominence, marking tracks and lists that have aged beyond their confidence window so the fire support coordinator clears with eyes open about what the system can and cannot currently see. The design principle is that loss of the network must degrade the operator's confidence, visibly, rather than silently degrading the safety of the clearance.

Fires deconfliction is one piece of a larger joint-fires picture that spans artillery, close air support, and cross-domain effects – see how the same coordination challenge appears in digital CAS coordination and in a multi-domain operations dashboard.