UAV-Aufklärungssoftware: vom Sensor zur Operatorentscheidung

Ein UAV trägt Sensoren. Ein Sensor erzeugt Daten. Daten werden zur Information, wenn sie mit Kontext verknüpft und einem Operator präsentiert werden, der daraufhin handeln kann. Der Abstand zwischen diesen beiden Endpunkten — Sensorerfassung und Operatorentscheidung — ist die Sensor-Entscheidungs-Schleife, und UAV-Aufklärungssoftware bestimmt deren Latenz, Genauigkeit und Zuverlässigkeit. Dieser Artikel untersucht die vollständige Pipeline: von der bordeigenen Sensorkonfiguration über den Downlink, die Bodenstation, durch die Videoanalytik-Pipeline bis hin zum gemeinsamen Lagebild, das S2- und S6-Offizieren im Feld angezeigt wird.

Die Sensor-Entscheidungs-Schleife: Architekturübersicht

Die Schleife umfasst fünf diskrete Phasen, von denen jede Latenz einführt und einen potenziellen Ausfallpunkt darstellt:

1. Bordeigener Sensor und Kodierung. Elektro-optische (EO), Infrarot- (IR), Synthetic-Aperture-Radar- (SAR) und SIGINT-Nutzlasten erzeugen Rohdaten, die für die Übertragung komprimiert und gemultiplext werden müssen. Bei Video-Nutzlasten erfolgt die H.264- oder H.265-Kodierung auf der bordeigenen Videoencoderplatine des UAV. MISB-KLV-Metadaten (Motion Imagery Standards Board) — Plattformposition, Haltung, Sichtsfeld des Sensors — werden in dieser Phase in den Transportstrom eingebettet. Die Kodierungslatenz auf geeigneter Hardware beträgt typischerweise 30–80 ms.

2. Datenlink. Der kodierte Transportstrom wird über den C2-Link (Command-and-Control-Uplink) und einen separaten, breitbandigeren Intelligence-Downlink übertragen. Gängige Downlink-Typen sind Tactical Common Data Link (TCDL) im C-Band oder Ku-Band für MALE- und HALE-Plattformen sowie Punkt-zu-Punkt-2,4-GHz- oder 5,8-GHz-Links für taktische UAS. Die Link-Latenz eines gut ausgelegten Sichtverbindungssystems beträgt 10–50 ms; Satellitenrelais fügen 500–600 ms einfacher Laufzeit hinzu (geostationär) oder 20–80 ms (erdnahe Umlaufbahn), was das Latenzbudget für zeitkritische Zielerfassung erheblich verändert.

3. Empfang und Dekodierung an der Bodenstation. Das Ground Data Terminal (GDT) empfängt das HF-Signal und gibt einen STANAG-4609-MPEG-2-Transportstrom über Ethernet oder seriell aus. Die Bodenstationssoftware dekodiert den Strom, demultiplext die KLV-Metadaten aus dem Video-Elementarstrom und übergibt beides an nachgelagerte Verbraucher. Ein gut implementierter Empfangs-Stack fügt in dieser Phase weniger als 100 ms Verarbeitungslatenz hinzu.

4. Analytik und Geolokalisierung. Dekodierte Frames werden an die Videoanalytik-Pipeline übergeben — Erkennung, Klassifikation und Verfolgung — während die simultan extrahierten KLV-Metadaten die Geolokalisierungs-Engine speisen. Das Ergebnis dieser Phase ist eine Menge geolokalisierter, klassifizierter Erkennungen, die als Ereignisse im taktischen Netzwerk veröffentlicht werden. Die Analytiklatenz hängt von der Modellkomplexität und der Hardware ab; ein YOLOv8-großes Modell auf einer GPU-ausgestatteten Workstation verarbeitet 1080p-Frames schneller als Echtzeit in unter 20 ms pro Frame. Auf CPU-only-Edge-Hardware kann dasselbe Modell 80–150 ms pro Frame benötigen.

5. Operatoranzeige und Entscheidung. Der Operator betrachtet den Video-Feed, die Sensorfußabdruck-Überlagerung auf der Karte und die analytischen Erkennungsmarkierungen im gemeinsamen Lagebild. Entscheidungslatenz — die Zeit von der Anzeige bis zu einem Befehl oder Bericht — ist ein menschlicher Faktor, den keine Software vollständig kontrollieren kann. Die Reduzierung der Anzeigelatenz und die Verbesserung der Informationsdichte senken jedoch direkt die kognitive Belastung und verkürzen den Entscheidungszyklus.

STANAG 4609 und MISB KLV: der Datenvertrag

STANAG 4609 ist der grundlegende Datenvertrag für UAV-Bewegtbilder in Rahmenwerken zur Interoperabilität von Allianzen. Er legt fest, dass UAV-Video als MPEG-2-Transportstrom mit eingebetteten MISB-Local-Set-(LS-)0601-Metadaten übertragen werden muss. LS 0601 definiert rund 140 getaggte Datenelemente, die alle Parameter abdecken, die ein Analyst oder automatisiertes System benötigt, um Inhalte im Bild zu geolokalisieren: Sensorposition, Plattformkurs, Neigung, Rollen, FOV-Winkel des Sensors, Schrägentfernung, Schrägungswinkel und mehr.

Das von MISB verwendete KLV-Format (Key-Length-Value) ist ein kompaktes Binärformat. Jedes Metadatenelement wird durch einen 1-Byte- oder 2-Byte-Schlüssel identifiziert, gefolgt von einem Längenfeld und dem Wert in einer standardisierten Gleitkomma- oder Ganzzahlkodierung. Ein minimales konformes KLV-Paket für einen Video-Frame kann 80–120 Bytes umfassen. Bei 30 Frames pro Sekunde ergibt dies einen Overhead von etwa 3–4 kbps im Transportstrom — auf einem taktischen Datenlink vernachlässigbar.

Für Integratoren ist der kritische Implementierungspunkt, dass KLV-Metadaten synchron mit den Video-Frames extrahiert werden müssen, die sie beschreiben. KLV-Pakete sind im Transportstrom als private Daten-PIDs neben der Video-PID eingebettet. Ein Parser, der die zwei PIDs asynchron verarbeitet — oder der die Videoanzeige verzögert, ohne die Metadatenanwendung zu verzögern — erzeugt Geolokalisierungsfehler, die mit Plattformgeschwindigkeit und Gimbal-Schwenkrate zunehmen. Bei 60 Knoten Bodengeschwindigkeit und 1 Sekunde Metadatenverzögerung kann der Geolokalisierungsfehler 30 Meter überschreiten.

Pflichtfelder in LS 0601 für die Geolokalisierung

Nicht alle 140+ LS-0601-Felder sind für die grundlegende Geolokalisierung erforderlich. Der Mindestsatz, der benötigt wird, um zu berechnen, wo ein Pixel im Bild auf dem Boden liegt, umfasst: Sensor-Breitengrad (Tag 13), Sensor-Längengrad (Tag 14), wahre Sensorhöhe (Tag 15), Plattformkurswinkel (Tag 5), Plattformneigungswinkel (Tag 6), Plattformrollwinkel (Tag 7), horizontales Sichtfeld des Sensors (Tag 16), vertikales Sichtfeld des Sensors (Tag 17), relativer Azimutwinkel des Sensors (Tag 18), relativer Elevationswinkel des Sensors (Tag 19), relativer Rollwinkel des Sensors (Tag 20) und Schrägentfernung (Tag 21). Alle anderen Felder sind ergänzend — nützlich für die Analyse, aber nicht für die Echtzeit-Geolokalisierungsberechnung erforderlich.

Videoanalytik-Pipeline: Erkennung und Klassifikation

Die automatisierte Objekterkennung ist die Phase mit der stärksten Abhängigkeit von domänenspezifischem Engineering. Allgemeine Erkennungsmodelle, die auf zivilen Bildern trainiert wurden, erzielen schlechte Ergebnisse bei UAV-Perspektive-Militärbildern — Betrachtungswinkel, Maßstab, Tarnung und Zielvielfalt unterscheiden sich grundlegend. Ein in der Produktion eingesetztes Modell sollte auf einem beschrifteten Datensatz feinabgestimmt sein, der die Betriebsumgebung repräsentiert: Zieltypen (Fahrzeuge, Personal, Stellungen), Höhenbereich, Sensortyp (EO vs. IR) und Hintergrundklassen (urban, ländlich, bewaldet, gemischt).

Die Standardarchitektur für die Echtzeit-UAV-Videoanalytik verwendet eine zweistufige Pipeline: einen schnellen Einstufendetektor (YOLOv8 oder gleichwertig), der mit voller Framerate für Erkennung und grobe Klassifikation läuft, und Erkennungen an ein langsameres, aber genaueres Klassifikationsmodell weitergibt, das die Klasse bestätigt und Konfidenz zuweist. Der schnelle Detektor priorisiert Trefferquote (Recall) — alle potenziellen Ziele zu erfassen, auch auf Kosten von Falschpositiven. Der Klassifikator filtert die Erkennungsliste und weist das endgültige Label zu. Diese Trennung ermöglicht dem System, mit Video-Framerate zu arbeiten, während mehr Rechenleistung für bestätigte Erkennungen aufgewendet wird.

Geolokalisierung von Erkennungen

Jeder Erkennungs-Bounding-Box muss eine WGS84-Bodenebenenkoordinate zugewiesen werden, bevor sie als georäumliches Ereignis veröffentlicht werden kann. Die Berechnung verwendet die Pixelkoordinaten des Erkennungszentroids, die Sensorgeometrie aus den KLV-Metadaten und ein Geländehöhenmodell (DTED Level 1 oder Level 2). Der Standardansatz besteht darin, einen Strahl vom Sensor durch das Bildebenen-Pixel zu projizieren und ihn mit der Geländeoberfläche zu schneiden. Ohne ein DEM führt eine Flache-Erde-Näherung mit Schrägentfernung zu höhenabhängigen Fehlern, die über hügligem oder gebirgigem Gelände bedeutend werden.

Für die Erkennungsverfolgung — das Verknüpfen von Erkennungen über Frames hinweg zur Erzeugung persistenter Spuren — ist ein Kalman-Filter oder der SORT-Algorithmus (Simple Online and Realtime Tracking) der Produktionsstandard. Persistente Spuren reduzieren die kognitive Belastung des Operators im Vergleich zu Frame-für-Frame-Erkennungen: Statt einer Karte, die mit jedem Frame mit neuen Markierungen flackert, sieht der Operator eine kleine Anzahl stabiler, sich bewegender Markierungen mit Konfidenzhistorie.

Bodenstationsintegration und C2-Link-Architektur

Die Bodenstation ist der Knotenpunkt der Sensor-Entscheidungs-Schleife. Eine Produktionsbodenstation für ein taktisches UAS-Programm betreibt typischerweise mehrere Softwarekomponenten parallel: den Transportstrom-Empfänger und -Demultiplexer, die Videoanzeigeanwendung (mit Missionsaufzeichnung), den KLV-Metadaten-Extraktor, die Analytik-Pipeline und den CoT-/Taktiknetzwerk-Publisher.

Der C2-Uplink — Befehle vom Operator zum UAV — und der Intelligence-Downlink sind logisch getrennt, teilen jedoch häufig dasselbe HF-System. Die Integrität des C2-Links ist schwieriger zu schützen als der Downlink: Befehlsnachrichten sind klein, müssen aber mit sehr geringer Latenz und hoher Zuverlässigkeit ankommen. Die Standardarchitektur für die C2-Link-Integrität verwendet einen dedizierten Schmalband-Uplink auf einer separaten Frequenz vom Breitband-Intelligence-Downlink mit AES-256-Verschlüsselung und FHSS (Frequency Hopping Spread Spectrum) zur Störungsresistenz. Die Software auf der Bodenstation muss C2-Link-Qualitätsmetriken überwachen — Bitfehlerrate, Round-Trip-Befehlsbestätigungslatenz — und den Operator warnen, bevor eine Linkdegradierung zum Verlust der Flugzeugkontrolle führt.

ATAK-Plugin-Muster für UAV-Feeds

Die Integration eines UAV-Feeds in ATAK — die Standard-Taktische-Situationsbewusstsein-Anwendung — folgt einer bewährten Plugin-Architektur. Ein UAV-Integrations-Plugin hat drei funktionale Komponenten, die gleichzeitig arbeiten.

Video-Panel-Komponente. Ein SurfaceView-basiertes Panel im ATAK-Plugin-Fenster rendert den dekodierten Videostrom. Der Videodekoder läuft in einem Hintergrund-Thread und schiebt Frames mit der nativen Framerate des Streams auf die Oberfläche. Das Panel sollte Überlagerungsanmerkungen (Zielrahmen aus der Analytik-Pipeline) enthalten, die über Canvas auf einer transparenten Ebene über der Videooberfläche gerendert werden — synchronisiert mit dem angezeigten Frame.

Fußabdruck-Überlagerungs-Komponente. Die vier Eckkoordinaten des Sensorfußabdrucks — berechnet aus MISB-Geometriefeldern und dem Geländemodell — werden als CoT-Polygon-Ereignis veröffentlicht und auf der ATAK-Karte als halbtransparentes Trapez dargestellt. Das Fußabdruck-Polygon wird mit der KLV-Metadaten-Rate aktualisiert (typischerweise 1–10 Hz für die meisten Systeme). Bei langsameren Aktualisierungsraten kann der Fußabdruck während schneller Gimbal-Schwenks gegenüber der Videoanzeige verzögert erscheinen; die Lösung besteht darin, die Fußabdruckposition zwischen Metadaten-Updates mithilfe der Änderungsrate der Plattformhaltung zu extrapolieren.

Erkennungs-Publisher-Komponente. Geolokalisierte Erkennungen aus der Analytik-Pipeline werden als CoT-Punktereignisse mit entsprechenden CoT-Typencodes an den TAK-Server veröffentlicht. Erkennungsspuren mit persistenter Identität werden mit einer konsistenten UID über alle Updates hinweg veröffentlicht, sodass ATAK-Clients sie als bewegliche Markierungen und nicht als Folge unabhängiger Ereignisse anzeigen. Das Plugin sollte dem Operator erlauben, eine Erkennung zu bestätigen oder abzulehnen — bestätigte Erkennungen werden in einen CoT-Typ mit höherer Konfidenz befördert; abgelehnte Erkennungen werden aus dem Lagebild entfernt.

Latenzbudgets für zeitkritische Ziele

Zeitkritische Zielerfassung — der Prozess der Erkennung, Identifikation und Bekämpfung eines Ziels, das sich nur für ein kurzes Zeitfenster präsentiert — stellt die strengsten Latenzanforderungen an den UAV-Aufklärungssoftware-Stack. Die relevante Militärdoktrin gibt einen Zielerfassungszyklus von unter 30 Minuten für planmäßige Zielerfassung vor; zeitkritische Zielerfassung komprimiert dies auf Minuten oder Sekunden, je nach Bedrohungstyp.

Innerhalb der Software-Pipeline sind die wichtigsten Latenzbudget-Zuteilungen:

Video-Anzeigelatenz: unter 500 ms gesamt vom Sensorerfassen bis zur Operatoranzeige. Das bedeutet Kodierung (80 ms) + Link (50 ms, Sichtverbindung) + Dekodierung (30 ms) + Anzeigepipeline (20 ms) = ca. 180 ms für ein gut optimiertes System. Buffering für adaptives Bitraten-Streaming oder Jitter-Kompensation fügt häufig 200–500 ms obendrauf hinzu — aggressive Buffer-Einstellungen sind die häufigste Ursache für inakzeptable Anzeigelatenz.

Erkennungs-zu-CoT-Latenz: unter 3 Sekunden von der Erkennung in der Analytik-Pipeline bis zum CoT-Ereignis, das auf verbundenen ATAK-Clients sichtbar ist. Dieses Budget umfasst Erkennungsinferenz (20–150 ms), Geolokalisierungsberechnung (10 ms), CoT-Ereigniskonstruktion und -Veröffentlichung (5 ms), TAK-Server-Relay (50–200 ms je nach Föderationshops) und ATAK-Client-Update (100–500 ms je nach Update-Polling-Intervall).

Operator-zu-C2-Latenz: unter 2 Sekunden von der Zielbezeichnung durch den Operator im ATAK-Plugin bis zum Erreichen eines Befehls beim UAV-Operator oder Feuerleit-Element. Dies ist hauptsächlich eine Netzwerk- und C2-Systemlatenz — der Beitrag des UAV-Integrations-Plugins ist vernachlässigbar, wenn es CoT sofort bei Operatoraktion veröffentlicht.

Für eine ausführlichere Behandlung der Computer-Vision-Architektur in der Analytik-Pipeline siehe den Artikel über Computer Vision für ISR-Drohnen.