Artillerie-Feuerleitung: Integration mit C2-Systemen

Artillerie-Feueraufträge waren schon immer darauf angewiesen, dass genaue Daten schnell zwischen mehreren Akteuren ausgetauscht werden: dem Beobachter, der das Ziel identifiziert, dem Feuerleitzentrum, das die Schussdaten berechnet, und der Geschützlinie, die die Mission ausführt. Was sich bei modernen Artillerieoperationen verändert hat, ist der Umfang des Lagebildes, das diese Akteure teilen müssen. Heute umfasst ein Feuerauftrag nicht nur die Batterie – er schließt die C2-Plattform auf Brigadeebene ein, die das gemeinsame Lagebild hält, die Luftraumverwaltungsschicht, die die Flugbahn freigeben muss, sowie eine wachsende Anzahl unbemannter Sensoren, die die Zieldaten überhaupt erst erzeugen. All das in Echtzeit zu verbinden, ohne auf Sprechfunk und manuelle Koordinateneingabe zurückzugreifen, ist das Problem der Artillerie-Feuerleitung-C2-Integration.

Dieser Artikel untersucht die technische Architektur dieser Integration. Er behandelt, wie Zieldaten vom Sensor zur FCS fließen, welche Datenstandards die Feuerinteroperabilität regeln, wie C2-Software die Luftraumdekonfliktion während einer Mission handhabt, sowie die Latenz- und Zuverlässigkeitsanforderungen, die eine tragfähige Feuerintegration von einer unterscheiden, die Bediener unter Druck aufgeben werden. Er richtet sich an Softwareingenieure, die C2-Plattformen mit Feuerfähigkeit entwickeln oder bewerten, sowie an Beschaffungsteams, die prüfen, ob ein Kandidatensystem die Integrationsanforderungen einer kombinierten Streitkraft erfüllt.

Die Feuerintegrations-Herausforderung: drei Systeme, die sich in Echtzeit einigen müssen

Ein modernes indirektes Feuerengagement umfasst mindestens drei unterschiedliche Softwaresysteme, die jeweils unterschiedliche, teilweise überlappende Sichten auf das Schlachtfeld haben. Die Sensorschicht – ob ein Vorwärtsbeobachter mit Laserentfernungsmesser und Tablet, eine UAV mit einer kardanisch aufgehängten EO/IR-Kamera oder ein Gegenartillerie-Radar – erzeugt Zieldaten: Koordinaten, Zieltyp, Erkennungszeitpunkt und Konfidenz. Die Feuerleitanlage (FCS) – historisch AFATDS auf US-amerikanischer Seite, verschiedene nationale Äquivalente andernorts – empfängt Feuerauftrag-Anfragen, berechnet Schussdaten, verwaltet die Batterie-Warteschlange und übermittelt Feuerbefehle an einzelne Geschütze. Die C2-Plattform hält das gemeinsame Lagebild: alle befreundeten Tracks, alle bekannten Bedrohungs-Tracks, Feuerunterstützungskoordinierungsmaßnahmen, aktive Luftraumreservierungen und den operativen Zeitplan.

Die Integrationsherausforderung besteht darin, dass keines dieser Systeme ursprünglich darauf ausgelegt war, in Echtzeit über ein gemeinsames Datenmodell mit den anderen zu kommunizieren. AFATDS wurde als eigenständiges Feuersystem mit definierten Nachrichtenschnittstellen entwickelt; die C2-Plattform wurde um Track-Verwaltung und -Anzeige herum gebaut; die Sensorschicht entwickelte sich aus eigenständigen Zielerfassungswerkzeugen. Sie zu verbinden, ohne einen Single Point of Failure zu schaffen – und ohne so viel Latenz einzuführen, dass Bediener auf Sprechfunk zurückgreifen –, erfordert sorgfältige Aufmerksamkeit dafür, wo die Integrationspunkte sind, welche Datenformate diese Punkte verwenden und wie die Systeme bei unterbrochenem Netz elegant degradieren.

AFATDS und der standardmäßige Feuerauftrag-Workflow

Das Advanced Field Artillery Tactical Data System (AFATDS) ist die primäre FCS der US Army und die am weitesten integrierte Artilleriesoftware in NATO-Partnerkräften. Das Verständnis seines Workflows ist eine Voraussetzung für die Entwicklung jeder C2-zu-Feuer-Integration, da die meisten nationalen FCS-Äquivalente ähnliche Workflow-Muster befolgen, auch wenn sich die spezifischen Nachrichtenformate unterscheiden.

Im AFATDS-Modell beginnt ein Feuerauftrag mit einem Call for Fire (CFF), der von einem Vorwärtsbeobachter eingereicht wird. Der CFF enthält den Zielort (MGRS oder Lat-Lon), die Zielbeschreibung, die Einsatzmethode und die Feuerleitkontrollmethode. AFATDS empfängt den CFF, führt die Feuerauftrag-Verarbeitung durch – berechnet Schussdaten basierend auf dem Waffensystem, dem Munitionstyp, den meteorologischen Daten und dem Gelände – und erzeugt einen Feuerbefehl (FMO), der an die bestimmte Batterie übermittelt wird. Der Batterie-Sektionschef bestätigt den FMO, führt die Mission aus, sendet eine Geschoss-unterwegs-Meldung (SOW) zurück an das Feuerleitzentrum und schließt mit einem Ende-der-Mission-Bericht (EOM) ab.

Die C2-Integrationspunkte in diesem Workflow sind: die CFF-Einreichung (die C2-Plattform sollte Zieldaten von der Sensorschicht empfangen und einen CFF generieren, ohne manuelle Neueingabe zu erfordern); die Anzeige aktiver Feueraufträge (das C2-COP sollte jeden aktiven Feuerauftrag als räumliches Overlay anzeigen, damit alle Akteure – nicht nur das Feuerleitzentrum – sehen können, wohin Geschosse gehen); und der EOM-Datensatz (das Missionsergebnis sollte die C2-Track-Datenbank aktualisieren und das Geheimdienstlagebild aktualisieren). All das zu erreichen, ohne eine fragile benutzerdefinierte Schnittstelle zu einer einzigen FCS-Variante zu schaffen, ist die zentrale ingenieurtechnische Herausforderung.

Zieldatenfluss: vom Sensor zur Geschützlinie

Der Datenpfad von der Zielerkennung bis zu Treffern am Ziel überquert mehrere Formatgrenzen. An jeder Grenze findet eine Übersetzung oder Anpassung statt – und jede Übersetzung ist eine potenzielle Fehler-, Latenz- und Informationsverlustquelle.

Sensor zu C2-Track. Zieldaten von einer UAV oder einem Laserentfernungsmesser kommen als Cursor-on-Target (CoT)-Ereignis, als USMTF SPTREP (Spotmeldung) oder als proprietärer Sensor-Feed bei der C2-Plattform an. Die C2-Plattform löst dies in einen Track auf: einen Punkt auf der Karte mit einer UID, Koordinaten, Zieltyp und Zeitstempel. Für Artilleriezwecke ist die Koordinatengenauigkeit dieses Tracks entscheidend – ein 50-Meter-Fehler im Zielort übersetzt sich direkt in einen 50-Meter-Fehlschlag bei einem ungelenkten Geschoss und potenziell in einen vollständigen Fehlschlag für Präzisionsmunition mit CEP-Anforderungen.

C2-Track zu Feuerauftrag-Anfrage. Die Feuerauftrag-Anfrage (Call for Fire) wird vom Feuerworkflow der C2-Plattform generiert, wobei der Ziel-Track als Quelle dient. Die Anfrage muss als USMTF-CFF-Nachricht für die Übertragung an AFATDS oder im nationalen Äquivalentformat für andere FCS-Typen formatiert sein. Die C2-Plattform muss die interne Track-Darstellung in das erforderliche Nachrichtenformat übersetzen, ohne das Koordinatendatum zu verlieren (WGS-84 vs. lokale Datum-Unterschiede haben in Altsystemen erhebliche Fehler verursacht), ohne erforderliche Felder zu verwerfen und ohne Koordinatenrundung einzuführen, die die Genauigkeit unter die rechnerische Präzision der FCS senkt.

FCS zu Feuerbefehl. AFATDS oder das nationale FCS-Äquivalent verarbeitet den CFF und gibt einen Feuerbefehl an die Batterie zurück. Diese Nachricht reist über ein taktisches Datennetz – typischerweise eine Funk-Datenverbindung mit geringer Bandbreite. Der FMO enthält die Waffe, die Treibladung, die Zündereinstellung, die Richtungswinkelkorrektur, den Erhöhungswinkel und die Anzahl der Geschosse. Die C2-Plattform kann eine Kopie des FMO zu Anzeigezwecken empfangen, befindet sich aber nicht im Steuerpfad des FMO – dieser verbleibt vollständig innerhalb der FCS.

Geschoss-unterwegs zu COP-Overlay. Wenn Geschosse im Flug sind, sollte die C2-Plattform ein dynamisches Overlay auf dem COP anzeigen, das den vorhergesagten Einschlagsbereich basierend auf den berechneten Schussdaten zeigt. Dieses Overlay dient sowohl dem taktischen Lagebild – alle Akteure können sehen, wohin Geschosse gehen – als auch der Luftraumdekonfliktionsfunktion: Flugzeug-Tracks können nahezu in Echtzeit gegen die aktive Flugbahn geprüft werden, anstatt nur bei Missionsinitiierung.

NATO-STANAG-Datenstandards für die Feuerunterstützung

Multinationale Feuerintegration erfordert gemeinsame Datenstandards, die es einer nationalen C2-Plattform ermöglichen, von einer alliierten FCS generierte Feuerunterstützungsdaten zu empfangen und korrekt zu interpretieren. Die relevanten Standards bilden eine kleine, aber wichtige Sammlung von Vereinbarungen, die jede C2-Plattform, die in einem verbundenen Einsatzumfeld operiert, implementieren muss.

STANAG 4677 ist der zentrale Feuerunterstützungsdatenstandard. Er definiert die Datenstrukturen für Feuerunterstützungskoordinierungsmaßnahmen (FSCMs): Feuerunterstützungskoordinierungslinien (FSCL), koordinierte Feuerlinien (CFL), Feuersperrzonen (NFAs) und Feuerbeschränkungsgebiete (RFAs). Jede FSCM hat eine geometrische Definition (Polygon, Linie oder Kreis in einem Standard-Koordinatensystem), ein Kennzeichen, ein Gültigkeitszeitfenster und eine zuständige Behörde. STANAG-4677-Konformität bedeutet, dass eine C2-Plattform FSCM-Daten von einem alliierten Feuernetz importieren, korrekt anzeigen und in automatisierten Dekonfliktionsprüfungen anwenden kann – ohne benutzerdefinierte Übersetzung je alliierter Nation.

STANAG 2181 befasst sich mit den Verfahrensstandards für die Feuerunterstützungskoordinierung und liefert den doktrinären Rahmen, den die Software durchsetzen muss. Während STANAG 4677 Datenstrukturen definiert, legt STANAG 2181 fest, was diese Strukturen operativ bedeuten und wie Koordinatoren sie voraussichtlich nutzen werden. Eine C2-Plattform, die die STANAG-4677-Geometrie korrekt implementiert, aber die STANAG-2181-Koordinationsverfahren ignoriert, besteht Interoperabilitätstests, scheitert aber operativ.

USMTF (United States Message Text Format) bleibt das dominante Nachrichtenformat für den Feuerauftrag-Austausch in US-amerikanischen und US-partnerischen Streitkräften. Die relevanten Nachrichten – CALL FOR FIRE (FIREFAN), ADJUST FIRE, FIRE FOR EFFECT, SHELL REP und END OF MISSION – tragen den vollständigen Feuerauftrag-Workflow. USMTF-Nachrichten sind strukturierte Festformat-Texte; sie sind nach modernen Standards ausführlich, aber von FCS-Implementierungen gut verstanden und haben den Vorteil, in Debug-Szenarien lesbar zu sein. Neuere Implementierungen verpacken die USMTF-Nachrichtensemantik in XML- oder JSON-Schemata für eine einfachere Integration mit modernen C2-APIs, während die Nutzlastkompatibilität erhalten bleibt.

Luftraumdekonfliktion: Freigabe der Flugbahn, nicht nur des Ziels

Die Luftraumdekonfliktion ist einer der technisch anspruchsvollsten Aspekte der Feuer-C2-Integration, da sie von der C2-Plattform verlangt, über Projektilflugbahnen – nicht nur über Zielpunkte – in drei Dimensionen und nahezu in Echtzeit nachzudenken.

Ein 155-mm-Artilleriegeschoss, das auf ein Ziel in 25 Kilometer Entfernung abgefeuert wird, folgt einer ballistischen Flugbahn, die an ihrem Scheitelpunkt möglicherweise eine Höhe von 6.000–8.000 Metern erreicht. Jedes Rotor- oder Starrflügelflugzeug, das im Höhenband entlang dieser Flugbahn operiert, muss freigegeben werden, bevor der Feuerauftrag fortgesetzt werden kann. Nur den Zielpunkt zu prüfen – eine häufige Abkürzung in unreifen Implementierungen – übersieht den gesamten Flugbahnkorridor und kann eine Mission freigeben, die ein Geschoss auf halbem Weg durch den Flugweg eines Flugzeugs führen würde.

Eine robuste Dekonfliktionsimplementierung funktioniert wie folgt. Wenn eine Feuerauftrag-Anfrage verarbeitet wird, generiert die FCS oder die C2-Integrationsschicht eine Flugbahnhülle: einen Korridor, der durch die ballistische Flugbahn des Projektils vom Lauf zum Ziel definiert wird, erweitert um einen Sicherheitspuffer, der die Streuung (CEP), meteorologische Unsicherheit und den für die Flugsicherheit erforderlichen Mindestabstand berücksichtigt. Diese Hülle wird als zeitparametrisiertes 3D-Volumen dargestellt – das Projektil befindet sich zu verschiedenen Zeitpunkten nach dem Abfeuern in verschiedenen Teilen des Korridors, daher muss die Dekonfliktionsprüfung berücksichtigen, wann sich das Flugzeug an einer bestimmten Position befinden wird, nicht nur wo es sich zum Zeitpunkt der Prüfung befindet.

Die C2-Plattform fragt ihre Luftraumverwaltungsschicht nach allen aktiven Flugplänen, ATC-Haltemanövern und Mindestrisikorouten ab, die die Flugbahnhülle während des erwarteten Zeitfensters der Mission schneiden. Jede Schnittmenge erzeugt einen Konflikt. Die C2-Schnittstelle stellt dem Feuerauftrag-Koordinator den Konflikt dar: welches Flugzeug (nach Track-Bezeichnung), in welcher Höhe, zu welchem Zeitpunkt und welcher Abstand beim nächsten Annäherungspunkt wäre. Der Koordinator kann das Flugzeug auffordern, den Korridor zu verlassen, eine andere Flugroute anzufordern oder – in Ausnahmefällen und mit entsprechender Befugnis – das Risiko zu akzeptieren und den Konflikt zu übergehen. Alle Override-Entscheidungen werden mit der Identität des handelnden Bedieners und dem Zeitstempel protokolliert.

Die Integration mit JTAC- und CAS-Koordinations-Workflows fügt eine weitere Dimension hinzu. Wenn eine Close Air Support-Mission in einem Bereich neben einem Artillerie-Feuerauftrag aktiv ist, muss die C2-Plattform beide gleichzeitig im Blick behalten und verhindern, dass ihre Geometrien einen gegenseitigen Konflikt erzeugen – etwa eine Artillerieflugbahn, die eine aktive CAS-Anflugstrecke kreuzt. Dieses Maß an Feuer-Luftraum-Integration erfordert eine einheitliche Luftraumverwaltungsschicht in der C2-Plattform, keine getrennten Silos für Artillerie- und Luftkoordinierung.

Latenz- und Zuverlässigkeitsanforderungen

Die Feuerintegration ist eine der wenigen Domänen in militärischer C2-Software, in der Latenzanforderungen nicht durch operative Präferenz, sondern durch die Physik des Engagementzeitplans bestimmt werden.

Der Planungswert für eine akzeptable Latenz beim Feuerauftrag-Datenaustausch – von der Zieleingabe des Beobachters bis zum Eingang der Feuerauftrag-Anfrage bei der FCS – liegt beim 95. Perzentil unter 5 Sekunden. Dieser Wert ergibt sich aus der Zeitanforderung für zeitkritische Ziele: In einem ausgereiften Feuerworkflow besteht das Ziel darin, das erste Geschoss für sofortige Unterdrückung innerhalb von 60 Sekunden nach dem Beobachterbericht am Ziel zu haben, und innerhalb von 3 Minuten für geplante Engagements. Ein 5-Sekunden-Latenzbudget für den Datenaustausch beansprucht einen handhabbaren Teil dieses Zeitplans. Eine Latenz von 30 Sekunden – die in Systemen üblich ist, die Feuerauftrag-Anfragen über einen cloud-gehosteten Server ohne taktisches Edge-Caching routen – macht die digitale Feuerintegration langsamer als Sprachverfahren und garantiert, dass Bediener unter Druck auf Funk zurückgreifen werden.

Zuverlässigkeitsanforderungen sind ebenso unerbittlich. Eine Feuerauftrag-Anfrage, die lautlos verworfen wird – vom C2-Client akzeptiert, ohne Fehler, aber nie an die FCS zugestellt –, ist operativ gleichbedeutend mit einem vollständigen Systemausfall für diese Mission. Die Feuerintegration muss eine bestätigte Zustellung implementieren: Die FCS muss eine Bestätigung senden, wenn sie den CFF erhält, und die C2-Plattform muss den Bediener warnen, wenn keine Bestätigung innerhalb eines definierten Timeouts eingeht. Lautlose Verwürfe sind nicht akzeptabel.

Hochverfügbarkeit ist über den gesamten Gefechtsrhythmus hinweg wichtig, nicht nur während einzelner Missionen. Eine Batterie, die laufende Feuerunterstützungsoperationen durchführt, kann pro Stunde 50–100 Feueraufträge von mehreren Beobachtern abarbeiten. Die C2-zu-FCS-Integration muss anhaltenden Durchsatz ohne verschlechterte Latenz bewältigen und muss bei unterbrochenem Netz elegant degradieren – Nachrichten lokal in die Warteschlange stellen, bei Wiedererstellung der Verbindung erneut senden und den Warteschlangenstatus dem Bediener anzeigen, damit dieser den Systemzustand jederzeit kennt.

Die Kombination aus niedriger Latenz, bestätigter Zustellung und anhaltendem Durchsatz bei intermittierender Konnektivität ist ein anspruchsvolles Zuverlässigkeitsprofil. Deshalb wird die Feuerintegration häufig als die technisch anspruchsvollste der C2-Feuer-Integrationsprobleme genannt, und weshalb unreife Implementierungen genau in den Hochtemposszenarien versagen, in denen sie am wichtigsten sind. Für einen umfassenderen Überblick darüber, wie diese Anforderungen in eine vollständige C2-Architektur passen, lesen Sie den Artikel zur C2-Dashboard-Architektur, der die Full-Stack-Designüberlegungen für missionskritische C2-Anzeigesysteme behandelt.

Implementierungsmuster: Gateway, native Integration und API-First

In der Praxis wird die C2-zu-FCS-Integration über eines von drei Architekturmustern implementiert, von denen jedes unterschiedliche Kompromisse hinsichtlich Latenz, Wartbarkeit und Anbieterabhängigkeit aufweist.

Gateway-Integration fügt einen Übersetzungsdienst zwischen der C2-Plattform und der FCS ein. Das Gateway empfängt Feuerauftrag-Anfragen von der C2-Plattform im internen Format der C2, übersetzt sie in USMTF oder das FCS-native Format und leitet sie an die FCS weiter. Das Gateway empfängt auch FCS-Ausgaben und übersetzt sie zurück in das C2-Format zur Anzeige. Gateway-Integration ist der schnellste Weg zur Interoperabilität mit einer bestehenden FCS, fügt aber eine Komponente zum kritischen Pfad hinzu und macht die Integration von der Verfügbarkeit des Gateways abhängig. Gateways neigen auch dazu, Feature-Schulden anzuhäufen, da sich sowohl die C2-Plattform als auch die FCS weiterentwickeln – jede Versionsänderung erfordert Gateway-Aktualisierungen, und das Sichtfeld des Gateways ist auf die Nachrichtenformate beschränkt, für die es geschrieben wurde.

Native Integration bedeutet, dass die C2-Plattform die Nachrichtenschnittstellen der FCS direkt implementiert, ohne ein zwischengeschaltetes Gateway. Für AFATDS bedeutet dies, den USMTF-Nachrichtensatz nativ im Feuermodul der C2-Plattform zu implementieren. Native Integration reduziert die Komponentenanzahl im kritischen Pfad und beseitigt das Gateway als Fehlerpunkt, koppelt aber den Entwicklungszyklus der C2-Plattform an die Schnittstellenspezifikationen der FCS. Wenn AFATDS seine Nachrichtenformate aktualisiert – wie es über wichtige Versionsveröffentlichungen hinweg geschehen ist –, muss die C2-Plattform ihre native Implementierung im Gleichschritt aktualisieren.

API-First-Integration ist das aufkommende Muster für neue FCS-Entwicklungen und für C2-Plattformen, die auf eine Multi-FCS-Umgebung abzielen. Die FCS stellt eine REST- oder gRPC-API bereit, die ihr internes Nachrichtenformat hinter einem Standarddatenmodell abstrahiert, das an STANAG-4677- und USMTF-Semantik ausgerichtet ist. Die C2-Plattform integriert sich gegen die API und nicht gegen das Nachrichtenformat. Dies entkoppelt die beiden Systeme voneinander in Bezug auf interne Implementierungsdetails und ermöglicht es der FCS, sich intern weiterzuentwickeln, ohne die C2-Integration zu unterbrechen. Der Kompromiss ist, dass API-First erfordert, dass der FCS-Anbieter in die API-Schicht investiert und sie pflegt – eine Verpflichtung, die Legacy-FCS-Programme nur langsam eingegangen sind.

Corvus.Head: Feuerkoordinierung im C2-Dashboard

Effektive Feuerintegration ist nicht nur ein Datenaustauschproblem – es ist ein Anzeige- und Workflowproblem. Das C2-Dashboard muss den Feuerauftragsstatus, aktive FSCMs, Ergebnisse der Luftraumdekonfliktion und Batterieverfügbarkeit so darstellen, dass ein Feuerkoordinator mehrere gleichzeitige Missionen verwalten kann, ohne das Situationsbewusstsein über das umfassendere operative Lagebild zu verlieren. Corvus.Head ist genau auf diese Anforderung ausgelegt: ein einheitliches C2-Dashboard, das das Feuerlagebild zusammen mit ISR-Tracks, Freundkräftepositionen und Luftraumverwaltung in einer einzigen kohärenten Anzeige integriert, mit Feuerworkflow-Werkzeugen – Missionsanfrage, Dekonfliktionsprüfung, Statusverfolgung –, die in dieselbe Schnittstelle integriert sind, anstatt Bediener zu zwingen, zwischen separaten Anwendungen zu wechseln.