Fires-Deconfliction-Software: gemeinsame Feuer nahezu in Echtzeit freigeben

Ein modernes Gefechtsfeld ist voll von Dingen, die fliegen. Artilleriegranaten steigen bis zu einem Gipfelpunkt von mehreren Kilometern. Drehflügler durchqueren es im Tiefflug. Starrflügler fliegen Angriffsprofile. Loitering Munition und Aufklärungsdrohnen besetzen die mittleren Höhen. Schiffsartillerie reicht ins Landesinnere. Wenn mehrere davon gleichzeitig im selben Gebiet aktiv sind, ist das Risiko nicht abstrakt: Ein einziger unkoordinierter Feuerauftrag kann eine Granate durch dasselbe Luftraumvolumen schicken, das ein Luftfahrzeug gerade durchfliegt, oder sie auf einem Krankenhaus landen lassen, das die Rules of Engagement schützen. Fires-Deconfliction-Software existiert, um sicherzustellen, dass das nicht passiert – und das schnell genug, dass sie nie zum Grund wird, weshalb ein flüchtiges Ziel entkommt. Dieser Artikel untersucht, wie diese Software funktioniert: Luftraumkoordinierung, No-Strike- und Restricted-Target-Listen, den Clearance-of-Fires-Workflow und die Integration mit dem gemeinsamen Lagebild.

Was Fires-Deconfliction tatsächlich lösen muss

Deconfliction hat zwei eigenständige Dimensionen, die oft vermischt werden. Die erste ist die positionsbezogene Deconfliction: Feuer und Luftfahrzeuge in Raum und Zeit auseinanderhalten. Die zweite ist die zielbezogene Deconfliction: sicherstellen, dass das bekämpfte Objekt ein rechtmäßiges, autorisiertes Ziel ist und nicht bereits von jemand anderem bekämpft wird. Gute Software behandelt diese als getrennte Prüfungen mit getrennten Datenquellen, denn sie versagen auf unterschiedliche Weise und erfordern unterschiedliche Lösungen.

Positionsbezogene Deconfliction ist im Kern ein Geometrieproblem in vier Dimensionen – drei des Raums und eine der Zeit. Eine Artillerietrajektorie ist kein Punkt; sie ist ein gekrümmtes Volumen, das für ein begrenztes Fenster existiert. Auch ein Luftfahrzeug ist kein Punkt; es ist eine Spur mit einem Geschwindigkeitsvektor und einer Schutzblase um sich herum. Die Deconfliction-Engine muss bestimmen, ob sich diese beiden Volumina in den Momenten schneiden, in denen beide präsent sind. Zielbezogene Deconfliction ist dagegen ein Regel- und Nachschlageproblem: Fällt dieser Zielpunkt in ein geschütztes Gebiet, trägt er eine Feuerbeschränkung, und ist dasselbe Ziel bereits einem anderen Schützen zugewiesen?

Der schwierige Teil ist, all das in Sekunden zu erledigen. Eine Feueranforderung gegen ein bewegliches, zeitkritisches Ziel hat möglicherweise ein Fenster von einer Minute oder weniger, bevor das Ziel den Standort wechselt. Dauert der Deconfliction-Prozess länger als dieses Fenster, hat er den Auftrag faktisch verweigert. Jede Designentscheidung in Fires-Deconfliction-Software ist von dieser Latenzbeschränkung geprägt.

Es gibt zudem eine Koordinierungsdimension, die reine Geometrie übersieht. Mehrere Schützen – eine Geschützbatterie, ein Mörserzug, ein Element der Angriffsheeresflieger und ein Kampfflugzeug – können alle von verschiedenen Stäben, die einander nicht sehen, auf dasselbe Gebiet angesetzt werden. Ohne einen gemeinsamen Deconfliction-Dienst wird jede Feueranforderung isoliert gegen eine Teilsicht dessen freigegeben, was sonst noch geschieht – genau so kommt es zu einer Mehrfachbekämpfung oder einem Beinahe-Zusammenstoß zwischen einer Granate und einem Luftfahrzeug. Die Aufgabe der Software besteht daher nicht nur darin, einen Auftrag zu bewerten, sondern ihn gegen jedes andere Feuer und Luftfahrzeug zu bewerten, das im selben Gefechtsraum im selben Augenblick aktiv ist, gespeist aus einer gemeinsamen Datenquelle.

Luftraumkoordinierung: die Trajektorie modellieren

Der Kern der positionsbezogenen Deconfliction ist ein präzises Trajektorienmodell. Wenn ein Feuerunterstützungselement Waffe, Ladung und Ziel auswählt, berechnet die Software die ballistische Bahn: den Abschusspunkt, die Gun-Target-Line, den Gipfelpunkt, den Fallwinkel und die Flugzeit. Daraus entsteht ein überstrichenes Volumen – eine Luftraumröhre, die das Geschoss besetzen wird – gepaart mit einem Time-on-Target-Fenster, in dem dieses Volumen gefährlich ist.

Dieses Volumen wird dann gegen den Luftraum geprüft, wie er aktuell strukturiert ist. Luftraumkoordinierungsmaßnahmen (ACMs) gliedern den Luftraum in verwaltete Regionen: Restricted Operations Zones, Coordinating Altitudes, Tiefflugtransitrouten und Standard-Use Army Aircraft Flight Routes. Luftfahrzeuge erscheinen außerdem als Live-Spuren aus dem C2-Lagebild, jede mit Position, Kurs, Geschwindigkeit und einem Unsicherheitsvolumen, das mit dem Alter der Spur wächst. Die Engine schneidet die Geschossröhre sowohl gegen die statischen ACMs als auch gegen die dynamischen Spuren.

Wenn die Trajektorie während des Feuerfensters ein belegtes oder eingeschränktes Volumen durchstößt, löst das System einen Konflikt aus. Entscheidend ist: Es sagt nicht einfach „nein". Es schlägt Lösungen vor, gerankt nach operativer Auswirkung: eine zeitliche Trennung (feuern, nachdem das Luftfahrzeug frei ist), eine seitliche Luftraumbeschränkung, eine Höhensperre (eine Beschränkung des Gipfelpunkts, die eine andere Ladung oder Trajektorie erzwingen kann), ein Wechsel der Feuerstellung oder – als letztes Mittel – ein Hold. Der Fire Support Coordinator wählt, und die gewählte Trajektorie wird diejenige, die freigegeben und gefeuert wird.

Warum der Gipfelpunkt zählt

Ein häufiger Fehler in naiven Deconfliction-Werkzeugen besteht darin, die Trajektorie als gerade Gun-Target-Line zu behandeln. Indirektes Feuer bewegt sich nicht auf einer geraden Linie; ein Mörserauftrag mit hohem Winkel kann einen Scheitelpunkt weit über der Reiseflughöhe eines durchquerenden Hubschraubers erreichen, der weder in der Nähe des Geschützes noch des Ziels ist. Eine Deconfliction, die den Gipfelpunkt ignoriert, gibt einen Auftrag frei, der tatsächlich gefährlich ist. Das Trajektorienmodell muss den vollständigen Bogen tragen, einschließlich der Scheitelhöhe, und die Luftraumprüfung muss gegen diesen Bogen erfolgen, nicht gegen eine vereinfachte Linie. Dies ist die mit Abstand wichtigste Korrektheitseigenschaft einer Luftraum-Deconfliction-Engine.

No-Strike- und Restricted-Target-Listen

Zielbezogene Deconfliction beginnt mit zwei Referenzdatensätzen. Die No-Strike-Liste (NSL) zählt Einheiten auf, die nach dem humanitären Völkerrecht und den Rules of Engagement vor absichtlicher Bekämpfung geschützt sind: medizinische Einrichtungen, Gotteshäuser, Kulturgüter, Schulen, Talsperren und andere geschützte Strukturen. Die Restricted-Target-Liste (RTL) enthält Ziele, die nur unter Auflagen bekämpft werden dürfen – einer bestimmten Freigabeinstanz, einer bestimmten Waffe, einem Kollateralschadensschwellenwert oder einer zeitlichen Begrenzung (zum Beispiel eine Brücke, die nicht vor einer benannten Stunde getroffen werden darf).

In Software werden beide Listen als geofenced Datensätze gespeichert: Jeder Eintrag hat eine Grundfläche, einen Schutz- oder Beschränkungstyp und ein Gültigkeitszeitfenster. Wenn ein Ziel aufgelöst wird, puffert die Software den Zielpunkt um den erwarteten Wirkungsradius der Waffe – ihren tödlichen und Kollateralschadensbereich – und testet diese gepufferte Grundfläche gegen die NSL und RTL. Eine Schnittmenge mit der No-Strike-Liste blockiert den Auftrag und macht die geschützte Einheit für den Operateur sichtbar. Eine Schnittmenge mit der Restricted-Target-Liste blockiert nicht; sie eskaliert, hängt die geltende Auflage an und leitet den Auftrag an die erforderliche Freigabeinstanz weiter.

Die Disziplin hier besteht darin, dass die Listen maßgeblich und aktuell sein müssen. Eine veraltete NSL ist schlimmer als keine NSL, denn sie erzeugt falsches Vertrauen. Fires-Deconfliction-Software versioniert diese Listen daher, versieht jede Aktualisierung mit einem Zeitstempel und verweigert die Freigabe von Feuer gegen eine Liste, die älter als ein konfigurierbarer Veralterungsschwellenwert ist – was eine bewusste menschliche Bestätigung erzwingt, statt stillschweigend auf veralteten Daten fortzufahren.

Der Clearance-of-Fires-Workflow

Clearance of Fires ist die maßgebliche Aussage, dass ein Auftrag deconflictet, rechtmäßig und zum Feuern freigegeben ist. Es ist der Moment der Verantwortlichkeit, und in Software muss er als ausdrücklicher, prüfbarer Workflow modelliert werden statt als impliziter Nebeneffekt eines Knopfdrucks.

Der Workflow verkettet die Einzelteile. Eine digitale Feueranforderung tritt in das System ein. Die Engine führt die Zielprüfungen (NSL/RTL, Mehrfachbekämpfung) und die Luftraumprüfungen (Trajektorie gegen ACMs und Spuren) durch und hängt ihre Befunde an den Auftrag an. Der Auftrag mit seinen Befunden wird an die erforderlichen Instanzen weitergeleitet – den Fire Support Coordinator und jeden Manöverkommandeur, dessen Kräfte oder Einsatzraum betroffen sind. Jede Instanz sieht dieselben Konfliktbefunde und erfasst eine ausdrückliche Clear- oder Deny-Entscheidung. Erst wenn alle erforderlichen Freigaben erfasst sind, gibt das System den Auftrag an die Feuereinheit frei.

Zwei Eigenschaften machen diesen Workflow vertrauenswürdig. Erstens wird jedes automatisierte Prüfergebnis und jede menschliche Entscheidung mit Zeitstempel versehen und in ein unveränderliches Protokoll geschrieben, sodass die Freigabe im Nachhinein rekonstruiert und überprüft werden kann – wesentlich sowohl für Ausbildung als auch für Verantwortlichkeit. Zweitens hat der Workflow ausdrückliche Rollen und Befugnisse; die Software setzt durch, wer was freigeben darf, genauso wie ein COP rollenbasierten Zugriff auf Daten durchsetzt. Ein Feuerunterstützungsoffizier kann innerhalb der delegierten Befugnis freigeben; ein Auftrag, der die Restricted-Target-Liste berührt, wird an die benannte Freigabeinstanz eskaliert und kann unterhalb dieser Ebene nicht freigegeben werden.

Integration mit dem C2-Lagebild

Fires-Deconfliction kann nicht auf einer Dateninsel laufen. Die Luftraumprüfung ist nur so gut wie die Spur- und Luftraumdaten, die sie speisen, und die einzige maßgebliche Quelle dieser Daten ist das C2-Lagebild. Die Deconfliction-Engine abonniert daher das gemeinsame Lagebild für Live-Luftfahrzeug- und Eigenkräftespuren und übernimmt Luftraumkoordinierungsmaßnahmen und Fire Support Coordination Measures (FSCMs) als Kartenüberlagerungen, die von den Luftraum- und Feuerzellen gepflegt werden.

Sie veröffentlicht auch zurück. Wenn ein Auftrag freigegeben ist, wird die aktive Koordinierungsmaßnahme – das Volumen und das Zeitfenster des Luftraums, das das Feuer besetzt – über Cursor on Target und alliierte Fires-Nachrichtenformate ins COP veröffentlicht, sodass benachbarte Einheiten und Luftfahrzeuge den Luftraum für das Feuerfenster als heiß sehen. Das schließt den Kreis: Das System, das entscheidet, ob ein Feuer sicher ist, arbeitet aus demselben maßgeblichen Lagebild und trägt zu ihm bei, das die Artilleriezelle, die Luftraumzelle und der Manöverkommandeur alle sehen. Es ist dieselbe Integrationsdisziplin, die Feuerleitsysteme breiter mit dem C2-Lagebild verbindet.

Die Nachrichtenformate sind für die Interoperabilität entscheidend. In einer Koalition müssen Fires- und Luftraumdaten zwischen nationalen Systemen fließen. Auf STANAG-definierten Fires- und Luftraum-Nachrichtensätzen aufzubauen sowie auf Cursor on Target für die Positionsmeldung lässt eine Deconfliction-Engine die Flugrouten einer alliierten Einheit konsumieren und ihre eigenen Koordinierungsmaßnahmen veröffentlichen, ohne maßgeschneiderte Adapter je Partner.

Beeinträchtigte Kommunikation verändert das Integrationsbild, hebt aber die Pflicht zur Deconfliction nicht auf. Vorgeschobene Feuerzellen arbeiten häufig auf bandbreitenarmen, unterbrochenen Verbindungen, über die das vollständige COP nicht in Echtzeit gestreamt werden kann. Eine robuste Deconfliction-Engine hält eine lokal zwischengespeicherte Kopie der Luftraummaßnahmen, der No-Strike- und Restricted-Listen sowie der jüngsten Spuren vor und versieht jedes zwischengespeicherte Element mit einem Alter. Wenn die Konnektivität abbricht, gibt die Engine weiterhin Feuer gegen die zwischengespeicherten Daten frei – sie erhöht jedoch die Prominenz des Veralterungsschwellenwerts und markiert Spuren und Listen, die über ihr Vertrauensfenster hinaus gealtert sind, sodass der Fire Support Coordinator mit offenen Augen freigibt, was das System derzeit sehen kann und was nicht. Das Designprinzip lautet: Der Verlust des Netzwerks muss das Vertrauen des Operateurs sichtbar mindern, statt die Sicherheit der Freigabe stillschweigend zu mindern.

Fires-Deconfliction ist ein Teil eines größeren Bildes gemeinsamer Feuer, das Artillerie, Close Air Support und domänenübergreifende Wirkungen umfasst – sehen Sie, wie dieselbe Koordinierungsherausforderung bei der digitalen CAS-Koordinierung und in einem Multi-Domain-Operations-Dashboard auftaucht.