Zielordner-Management: Aufbau und Pflege des Zielsystems

Ein Ziel ist keine Koordinate. Es ist ein strukturierter Wissensbestand — gesammelte Aufklärung, physische Beschreibung, funktionale Analyse, Bewertung des Kollateralrisikos und Befehlsbefugnis — organisiert in einem Zielordner, der vom Moment der Nominierung bis zur Gefechtsschadensbewertung nach dem Schlag fortbesteht. Zielordner-Management-Software ist das System, das dieses Wissen vorhält, die Abläufe zu seinem Aufbau und seiner Freigabe erzwingt und die gemeinsame Zielliste (JTL) mit dem Lagebild synchron hält. Dieser Artikel untersucht, wie diese Software architektonisch aufgebaut ist, welche Daten sie verwalten muss und wie sie sich mit dem umfassenderen gemeinsamen Lagebild und der C2-Umgebung integriert.

Der Zielordner: Datenmodell und Pflichtfelder

Der Zielordner ist der maßgebliche Datensatz für ein einzelnes Ziel über seinen gesamten Lebenszyklus im Zielbekämpfungssystem. Sein Datenmodell muss mehrere Informationskategorien aufnehmen, die unterschiedliche Einstufungsebenen, Quellentypen und Aktualisierungszyklen umspannen.

Standort und Geometrie. Der nominierte Zielstandort (NTL) ist eine bei der Nominierung vergebene WGS84-Koordinate. Im Verlauf der Entwicklung wird der NTL zu einem mittleren Treffpunkt (MPI) verfeinert — die Koordinate, auf die Waffen gerichtet werden. Der Zielordner speichert beide Werte mit zugehörigen Genauigkeitsangaben: einen Kreisfehlerwahrscheinlichkeitswert (CEP) oder die entsprechende Datengenauigkeitsangabe aus der Quellaufklärung. Belegt das Ziel eine Fläche (ein Depot, ein Flugplatz oder ein Führungsknoten mit mehreren funktional bedeutsamen Komponenten), speichert der Ordner zusätzlich zum MPI einen Polygon-Grundriss.

Zielidentifikation und -beschreibung. Jedes Ziel erhält bei der Nominierung eine von der Zielbekämpfungssoftware vergebene Zielseriennummer (TSN). Weitere Identifikationsfelder umfassen die Zielkategorie (aus einer standardisierten Zielkategorieliste, die mit doktrinären Rahmenwerken der Zielsystemanalyse abgestimmt ist), den Zielnamen sowie Querverweise auf vorhandene Einträge in der Aufklärungsdatenbank zum selben Objekt. Der Abschnitt zur physischen Beschreibung enthält strukturierte Felder zu Größe, Bauart, ober- und unterirdischer Ausdehnung sowie im Bildmaterial sichtbaren Unterscheidungsmerkmalen des Ziels.

Funktionale Analyse. Der Zielbekämpfungsoffizier dokumentiert, welche Komponenten des Ziels funktional kritisch sind — jene, deren Zerstörung oder Neutralisierung die gewünschte Wirkung erzielt — und welche redundant oder zweitrangig sind. Diese Analyse steuert den Wirkmittelschritt: Der Auswählende muss wissen, welcher Zielpunkt die gewünschte Wirkung erzielt, nicht bloß, welche Koordinate die Waffe innerhalb der Zielgrenze platziert.

Aufklärungsquellendatensätze. Jedes Datenelement im Ordner trägt eine Quellenreferenz: den Aufklärungsbericht, das Bildprodukt oder die menschliche Meldung, die es stützt. Quellenreferenzen umfassen Einstufungskennzeichnungen, Urheber und Datum. Die Software muss mehrere Einstufungsebenen innerhalb eines einzigen Ordners unterstützen, mit feldebenenbasierter Zugriffskontrolle, die Nutzer ohne erforderliche Freigabe daran hindert, eingestufte Quellendetails zu sehen, ihnen aber dennoch das Arbeiten mit dem bereinigten Zieldatensatz erlaubt.

Daten zur Kollateralschadensschätzung. Die Kollateralschadensschätzung (CDE) ist ein verpflichtender Schritt, bevor ein Ziel zur Bekämpfung freigegeben werden kann. Der Ordner speichert die CDE-Eingabedaten — Bildmaterial umliegender Strukturen, Entfernungsmessungen zu Schutzobjekten, Schätzungen der Bevölkerungsdichte — und die CDE-Ergebnisse für jede betrachtete Waffenoption. Da CDE-Ergebnisse durch Koordinatenänderungen oder Änderungen des Umfelds ungültig werden, muss die Software CDE-Datensätze versionieren und sie zur Neuberechnung kennzeichnen, wenn sich ihre Eingabedaten ändern.

Der gemeinsame Zielbekämpfungszyklus und der Software-Workflow

Der gemeinsame Zielbekämpfungszyklus bildet den prozeduralen Rahmen, innerhalb dessen Zielordner-Management-Software arbeitet. Der Zyklus hat sechs Phasen, und die Workflow-Engine der Software bildet jede Phase mit konfigurierbaren Statusübergängen und Routingregeln ab.

Phase 1: Vorgaben des Kommandeurs. Bevor die Zielbekämpfung beginnt, erteilt der Kommandeur Vorgaben, die das Zielsystem definieren (welche Zielkategorie die Operationsziele unterstützt), die gewünschten Wirkungen, Einschränkungen sowie alle Ziele, die aus operativen, rechtlichen oder politischen Erwägungen tabu sind. Diese Vorgaben werden in der Zielbekämpfungssoftware als Konfiguration auf Kampagnenebene kodiert: eine Liste freigegebener Zielkategorien, eine Liste eingeschränkter und No-Strike-Objekte (befüllt aus den Datenbanken der eingeschränkten Zielliste und der No-Strike-Liste) sowie Wirkungsschwellen, die die CDE-Methodik ohne erhöhte Befehlsfreigabe nicht überschreiten darf.

Phase 2: Zielentwicklung. Die Zielbekämpfungszelle nominiert Ziele und befüllt deren Ordner. Die Software erzwingt eine Mindestinhalts-Checkliste, bevor ein Ordner von „nominiert“ auf „Entwicklung abgeschlossen“ hochgestuft werden kann — alle erforderlichen Felder müssen befüllt und alle Quellenreferenzen angehängt sein. Unvollständige Felder werden in der Oberfläche markiert, und die Checkliste steuert den Arbeitsablauf des Zielbekämpfungsoffiziers, statt sich auf manuelle Nachverfolgung in Tabellen oder gemeinsam genutzten Dokumenten zu verlassen.

Phase 3: Wirkmittelplanung und Fähigkeitsanalyse. Der Wirkmitteloffizier wählt Waffen-Zielpunkt-Kombinationen, die die gewünschte Wirkung gegen die in der funktionalen Analyse identifizierten kritischen Komponenten erzielen. Die Zielbekämpfungssoftware speichert Wirkmittelergebnisse als strukturierte Datensätze, die mit bestimmten Zielpunkten in der Zielgeometrie verknüpft sind, mit Waffentyp, Zündereinstellung, Einsatzparametern und vorhergesagten Wirkungen. Für jede betrachtete Waffenoption wird die CDE durchgeführt, und die Ergebnisse bestimmen, welche Optionen auf der freigegebenen Befehlsbefugnisebene verfügbar sind.

Phase 4: Kräfteeinsatz. Freigegebene Ziele werden zur gemeinsamen Zielliste hinzugefügt und Angriffsplattformen — Luftfahrzeugen, Artillerie oder elektronischer Kampfführung — über den Luftauftragsbefehl (ATO) oder einen gleichwertigen Auftragsmechanismus zugewiesen. Die Zielbekämpfungssoftware erfasst die Zuweisung und aktualisiert den Zielstatus, um zu kennzeichnen, dass die Bekämpfung geplant ist. Die Integration mit der C2-Schicht der Artilleriefeuerleitung ist in dieser Phase eine zentrale Schnittstelle: Die Zielbekämpfungssoftware muss Zielpunktkoordinaten, Zünderdaten und Wirkungsanforderungen an das Feuerleitsystem übergeben und die Ausführungsbestätigung zurückerhalten.

Phase 5: Ausführungsplanung und Ausführung. Nach der Zuweisung überwachen Zielbekämpfungsoffiziere den Ausführungsstatus über die Integration der Zielbekämpfungssoftware mit dem operativen C2-Lagebild. Meldet eine Plattform die Ausführung — Waffenauslösung oder Feuerausführung — erfasst die Zielbekämpfungssoftware das Ausführungsereignis und löst den BDA-Workflow aus.

Phase 6: Bewertung. Gefechtsschadensbewertungsdaten — Bildmaterial, Signale oder Bodenmeldungen — werden als strukturierter Bewertungsdatensatz in den Zielordner eingegeben. Der Bewertungsablauf vergleicht die beobachteten Wirkungen mit den gewünschten Wirkungen aus Phase 1, klassifiziert das Ergebnis (Ziel zerstört, Ziel beschädigt und erneute Bekämpfung erforderlich, Ziel unbeschädigt) und erzeugt eine Empfehlung zur erneuten Bekämpfung, wenn die gewünschte Wirkung nicht erzielt wurde. Der abgeschlossene BDA-Datensatz schließt den Zielbekämpfungszyklus für dieses Ziel; Ziele, die eine erneute Bekämpfung erfordern, werden mit aktualisierten Ordnern an die JTL zurückgegeben.

Ziellistenverwaltung: die JTL als lebende Datenbank

Die gemeinsame Zielliste ist kein statisches Dokument — sie ist eine lebende Datenbankansicht, die sich fortlaufend ändert, während Ziele nominiert, entwickelt, freigegeben, bekämpft und bewertet werden. Zielordner-Management-Software pflegt die JTL als gefilterte, sortierte Abfrage über die zugrunde liegende Zieldatenbank, mit konfigurierbaren Ansichten für verschiedene Nutzer und Befehlsebenen.

Die JTL-Ansicht zeigt Ziele gruppiert nach Kategorie, Wirkung oder geografischem Einsatzgebiet. Zielbekämpfungsoffiziere können nach Zielstatus, Priorität, zugewiesener Plattform oder Zeitfenster filtern. Kommandeure sehen eine Übersicht mit Zielpriorität, JTL-Position und Ausführungsstatus. Rechtsberater sehen die CDE- und Verhältnismäßigkeits-Prüfwarteschlange. Jede Rolle sieht dieselben maßgeblichen Daten aus derselben Datenbank, unterschieden nur durch Zugriffskontrolle und Anzeigekonfiguration.

Die Zielpriorisierung auf der JTL wird von einem Bewertungsmodell gesteuert, das den Beitrag des Ziels zu den Zielen des Kommandeurs, die Zeitkritikalität (hat das Ziel ein begrenztes Fenster, in dem es verfügbar oder verwundbar ist?) und die Bekämpfungskosten hinsichtlich Plattformverfügbarkeit und Risiko einbezieht. Die Software erfasst die Begründung der Priorisierung, was für die Nachbereitung der Operation und den Nachweis wichtig ist, dass Zielbekämpfungsentscheidungen im Einklang mit den Vorgaben des Kommandos und dem geltenden Recht getroffen wurden.

Integration der No-Strike-Liste und der eingeschränkten Zielliste

Die No-Strike-Liste (NSL) und die eingeschränkte Zielliste (RTL) müssen auf Datenebene in die Zielbekämpfungssoftware integriert werden, nicht als Prüfung auf Oberflächenebene. Jeder Zielordner wird beim Eingeben oder Aktualisieren von Koordinaten automatisch mit der NSL und der RTL abgeglichen. Fällt der MPI eines Ziels in die Nähe-Schwelle eines Schutzobjekts — eines Krankenhauses, einer Schule, eines Kulturguts oder einer religiösen Stätte — markiert die Software den möglichen Konflikt und verlangt eine ausdrückliche Bestätigung des freigebenden Offiziers, bevor das Ziel weitergeführt werden kann. Die Nähe-Schwelle ist je Kategorie von Schutzobjekt und gemäß den geltenden Einsatzregeln konfigurierbar.

NSL- und RTL-Daten werden als separate, kontrollierte Datenbank geführt, die vom höheren Kommando in die Zielbekämpfungssoftware synchronisiert wird. Der Aktualisierungsmechanismus muss zuverlässig und prüfbar sein: Jede Änderung der NSL oder RTL wird mit Zeitstempel, Quellbehörde und den konkret hinzugefügten oder entfernten Objekten festgehalten. Ziele, deren NSL/RTL-Nähestatus sich durch eine NSL-Aktualisierung — nicht durch eine Zielbewegung — ändert, müssen erneut zur Prüfung markiert werden, selbst wenn sich ihre eigenen Daten nicht geändert haben.

Softwarearchitektur: die Zielbekämpfungsdatenbank und ihre Schnittstellen

Der Kern der Zielordner-Management-Software ist eine strukturierte relationale Datenbank mit einem Dokumentenspeicher für Anhänge — Bild-Miniaturansichten, Bildprodukte in voller Auflösung, CDE-Arbeitsblätter und Bewertungsberichte. Die relationale Schicht hält den Zieldatensatz mit allen strukturierten Feldern; der Dokumentenspeicher hält binäre und große Textanhänge, verknüpft mit der Zielseriennummer.

Die Zielbekämpfungsdatenbank muss die gleichzeitige Bearbeitung durch mehrere Zielbekämpfungsoffiziere unterstützen, mit Konflikterkennung und -auflösung für die gemeinsam genutzten Felder (JTL-Priorität, Zielstatus, Zielpunktkoordinaten). Eine Versionshistorie für alle strukturierten Felder ist eine Grundanforderung: Zielbekämpfungsbehörden müssen den Zustand jedes Zielordners zum Zeitpunkt jedes Freigabe- oder Ausführungsereignisses für die rechtliche Nachbereitung der Operation rekonstruieren können.

Integrationsschnittstellen verbinden die Zielbekämpfungssoftware mit dem Rest der C2-Umgebung. Die primäre Schnittstelle ist die COP-Schicht, die freigegebene Zieldatensätze aus der JTL als georäumliche Overlays übernimmt — Zielreferenzpunkte, benannte Interessengebiete oder Bekämpfungszonen, veröffentlicht als Kartenobjekte. Diese Schnittstelle ist bidirektional: Ausführungsereignisse und BDA-Eingaben fließen aus den COP- und ISR-Schichten in die Zielbekämpfungsdatenbank zurück. Eine sekundäre Schnittstelle verbindet die Zielbekämpfungssoftware mit dem Feuerkoordinationssystem zur direkten Übertragung von Zielpunktdaten, Waffenparametern und Ausführungsbestätigung. Siehe die verwandte Betrachtung der JTAC- und CAS-Koordinationssoftware für den Koordinationsablauf der Luftnahunterstützung, der parallel zum geplanten Zielbekämpfungszyklus läuft.

Einstufungshandhabung und multidomänenfähige Zugriffskontrolle

Zielordner aggregieren Daten aus mehreren Aufklärungsquellen, die auf unterschiedlichen Einstufungsebenen arbeiten. Ein einzelner Ordner kann nicht eingestuftes Bildmaterial von kommerziellen Satelliten, signalerfassende Aufklärung der Stufe Geheim und menschliche Meldungen der Stufe Streng Geheim enthalten — alle beschreiben dasselbe Ziel. Die Software muss feldebenenbasierte Einstufungskennzeichnungen umsetzen und sie auf API-Ebene erzwingen, nicht nur auf der Darstellungsebene.

Die praktische Folge ist, dass ein Zielbekämpfungsoffizier mit einer Geheim-Freigabe und ein Zielbekämpfungsoffizier mit einer Streng-Geheim-Freigabe unterschiedliche Versionen desselben Zielordners sehen können. Beide sehen die Koordinaten, die Kategorie und den JTL-Status des Ziels. Nur der höher freigegebene Offizier sieht die aus HUMINT abgeleitete funktionale Analyse. Die Software muss jedem Nutzer eine kohärente, konsistente Ansicht auf Basis seiner Zugriffsebene darstellen — nicht einfach Felder leeren, was Verwirrung darüber stiftet, ob Daten existieren.

Koalitionsoperationen fügen eine weitere Dimension hinzu: Personal von Partnernationen kann gleichwertige Freigabeebenen, aber unterschiedliche nationale Vorbehalte haben, die den Zugriff auf Aufklärung aus bestimmten Quellen einschränken. Das Zugriffskontrollmodell muss zusätzlich zur Filterung nach Einstufungsebene eine vorbehaltsbasierte Filterung unterstützen und für die Austauschregeln jeder Koalition konfigurierbar sein, ohne Softwareanpassung zu erfordern.