KI-Inferenz an Bord von UAVs: Edge-Verarbeitung ohne Konnektivität

Ein UAV ohne Datenverbindung ist nicht blind, wenn seine Inferenzpipeline an Bord läuft. Die bodenseitige KI-Verarbeitung ist aus Kostengründen die verbreitete Architektur, erzeugt aber eine harte Abhängigkeit: Sobald die Verbindung abbricht, stoppt die Erkennung. In umkämpften Umgebungen, in denen Mittel der elektronischen Kriegsführung routinemäßig Datenverbindungen degradieren oder kappen, ist diese Abhängigkeit operativ inakzeptabel. Die bordseitige KI-Inferenz verlagert die Rechenleistung auf das Luftfahrzeug, verarbeitet Frames des EO- oder IR-Sensors direkt auf einem nutzlastmontierten Beschleuniger, speichert annotierte Erkennungen lokal und übermittelt dem C2-System unmittelbar nach Wiederherstellung der Konnektivität ein strukturiertes Erkennungsprotokoll. Dieser Artikel behandelt die Hardware-Plattformen, Modellkomprimierungstechniken, das Design der Erkennungspipeline, Energie- und Thermalbeschränkungen sowie C2-Integrationsmuster, die On-Device-Objekterkennung und -verfolgung auf kleinen taktischen UAVs realisierbar machen.

Warum die Inferenz an Bord des UAV ausgeführt werden muss

Das operative Argument für bordseitige Inferenz ist eindeutig: Jede Mission, die lückenlose Erkennung durch einen Verbindungsausfall erfordert, kann nicht auf bodenseitige Verarbeitung setzen. Ein UAV, das rohes Video an eine Bodenstation streamt, benötigt eine dauerhafte Breitbandverbindung – typischerweise 2–10 Mbps für komprimiertes HD-Video bei akzeptabler Latenz. Diese Bandbreite über eine taktische Reichweite von 10–30 km in einem Umfeld mit aktiver Störung zu erreichen, ist nicht garantiert. Wenn der Videostream abbricht, verliert der Bodenoperateur nicht nur das Lagebewusstsein über die Position des UAV, sondern auch jede Erkennung, die der Sensor während des Ausfalls erzeugt hätte. Bei einer Aufklärungs-, Überwachungs- und Zielerfassungsmission (ISR) über mehrere Stunden ist eine 20-minütige Verbindungslücke keine akzeptable Lücke im Erkennungsprotokoll.

Bordseitige Inferenz löst dieses Problem, indem sie den Datenfluss umkehrt. Anstatt rohe Sensordaten an einen Bodenverarbeitungsknoten zu streamen, überträgt das UAV nur Inferenzausgaben: Erkennungsdatensätze, die um Größenordnungen kleiner sind als rohe Videoframes. Ein Erkennungsdatensatz – Klassenbezeichnung, Konfidenzwert, Bounding-Box-Koordinaten, GPS-Position und Zeitstempel – belegt einige hundert Bytes. Ein Videoframe in voller Auflösung bei 10 Mbps belegt etwa 1,25 MB pro Sekunde. Wenn eine Backup-Verbindung mit geringer Bandbreite verfügbar ist (ein Kurzstreckenfunkgerät, ein MANET-Mesh mit reduzierter Bitrate), übertragen Erkennungsdatensätze, wo rohes Video es nicht kann. Und wenn überhaupt keine Verbindung besteht, sammeln sich Erkennungsdatensätze im lokalen Speicher an, bis die Verbindung wiederhergestellt ist.

Es gibt auch ein Latenzargument. Die Netzwerk-Roundtrip-Zeit von einem UAV in der Luft zu einer Bodenstation und zurück kann je nach Verbindungsqualität und Routing zwischen 50 ms und mehreren hundert Millisekunden betragen. Bei zeitkritischen Zielen – einem Fahrzeug, das Deckung verlässt, einer sich auflösenden Personengruppe – kann diese Latenz das Fenster für eine nützliche Zuweisung überschreiten. Bordseitige Inferenz liefert ein Erkennungsergebnis innerhalb der Frame-Verarbeitungszeit des lokalen Beschleunigers, typischerweise 30–100 ms von der Bildaufnahme bis zur annotierten Ausgabe, ohne Netzwerksprung im kritischen Pfad.

Hardware-Plattformen: NVIDIA Jetson Orin vs. Hailo-8 vs. Intel Movidius für UAV-Nutzlasten

Drei Siliziumfamilien dominieren Produktionseinsätze auf UAV-Nutzlasten. Jede steht für einen anderen Punkt auf der TOPS-pro-Watt-Kurve, und die richtige Wahl wird primär durch das Energiebudget der Plattform und die Komplexität der Inferenzaufgabe bestimmt. Ein detaillierter Vergleich dieser Optionen findet sich auch in unserem Artikel über Edge-AI-Hardware für die Verteidigung.

Der NVIDIA Jetson Orin Nano liefert 40 TOPS bei 7–15 W, abhängig vom konfigurierten Energiemodus im NV-Energieverwaltungs-Framework. Er läuft auf einem vollständigen Linux-Stack, unterstützt CUDA und TensorRT nativ und akzeptiert jedes über das ONNX-Austauschformat exportierte Modell – was ihn zur reibungsärmsten Option für Teams macht, deren Trainingspipeline bereits auf TensorRT ausgerichtet ist. Der Formfaktor des Orin Nano (69,6 mm x 45 mm) passt in Nutzlastschächte auf UAVs der 5–15 kg-Klasse, aber seine maximale Wärmeabgabe erfordert entweder aktive Kühlung oder sorgfältige Integration von Wärmespreizern gegen die Luftfahrzeughaut. Der Jetson Orin NX, die nächste Stufe mit bis zu 100 TOPS und 15–25 W, ist geeignet, wenn die Mission den gleichzeitigen Betrieb mehrerer Modelle erfordert (Erkennung plus Klassifizierung plus Wiedererkennung) auf demselben Inferenzknoten.

Das Hailo-8 M.2-Modul erreicht 26 TOPS bei unter 5 W, realisiert durch eine hocheffiziente Datenflusssarchitektur, die den Netzwerkgraphen auf einem Array von Prozessor-Clustern kachelt, anstatt ihn sequenziell auf einem GPU-Kern auszuführen. Der Kompromiss liegt in der Toolchain-Spezifität: Modelle müssen durch den Hailo Dataflow Compiler kompiliert werden, der ein Hailo Execution Format (HEF)-Binärdatei erzeugt. Der Compiler behandelt INT4- und INT8-Quantisierung intern und produziert hochoptimierte Binärdateien, erfordert jedoch, dass die Modellarchitektur im unterstützten Operatorensatz des Compilers darstellbar ist. Standard-YOLOv5-, YOLOv8- und RT-DETR-Architekturen befinden sich im Hailo Model Zoo und werden ohne Modifikation kompiliert. Die Leistungsaufnahme des Hailo-8 – 5 W Spitze aus einem M.2-Steckplatz – macht ihn zur natürlichen Wahl für Multi-Rotor-Plattformen unter 5 kg mit engen Nutzlast-Energiebudgets.

Der Intel Movidius Myriad X (OpenVINO-Ziel) liefert 4 TOPS bei etwa 1–2 W. Diese Zahl ist bescheiden im Vergleich zu Hailo und Jetson, aber die Integrationsdichte des Myriad X – er ist in USB-Stick- und M.2-Formfaktoren erhältlich, die sich über Standardschnittstellen an jeden Linux-Host anschließen lassen – macht ihn zur einfachsten Option für sehr kleine Starrflügler- oder rohrstartfähige UAVs, bei denen keine dedizierte Trägerplatine untergebracht werden kann. OpenVINOs Modelloptimierungs-Tool übernimmt den INT8-Quantisierungs- und Graphoptimierungspfad, und die Toolchain ist gut dokumentiert. Für Einsätze, bei denen ein YOLOv8n mit 5–10 fps ausreichend ist – langsame ISR über fester Infrastruktur beispielsweise – ist der Myriad X bei deutlich geringeren SWaP-C-Kosten als Hailo oder Jetson eine praktikable Option.

Modellkomprimierung: Quantisierung, Pruning und Knowledge Distillation für den Embedded-Einsatz

Ein YOLOv8m-Modell in voller Präzision hat etwa 25 Millionen Parameter und belegt 50 MB im FP32-Speicher. Auf einem Hailo-8 mit 8 MB On-Chip-SRAM kann dieses Modell nicht direkt ausgeführt werden – es muss auf eine Größe komprimiert werden, die die Speicherhierarchie des Beschleunigers ohne übermäßigen DRAM-Bandbruckdruck aufnehmen kann. Drei Komprimierungstechniken werden in Kombination für Produktionseinsätze auf UAVs verwendet, und ihre Wechselwirkung wird ausführlich in unserem Artikel über ONNX und TensorRT-Modelloptimierung für den taktischen Edge-Einsatz behandelt.

Post-Training-Quantisierung (PTQ) konvertiert FP32-Gewichte und Aktivierungen in INT8, indem Skalierungsfaktoren anhand eines repräsentativen Datensatzes kalibriert werden. Auf Hardware mit INT8-Tensor-Ausführungseinheiten – Jetson Orin, Hailo-8, Myriad X – liefert INT8-Inferenz eine 2- bis 4-fache Durchsatzverbesserung gegenüber FP32 bei gleicher Modellkapazität. Der Genauigkeitsverlust beträgt typischerweise 0,5–2 mAP bei Luftbild-Objekterkennungs-Benchmarks, wenn der Kalibrierungsdatensatz dem Einsatzbereich entspricht. Der Kalibrierungsdatensatz sollte Proben vom tatsächlichen Sensor und der Höhe umfassen, auf der das Modell eingesetzt wird; eine Kalibrierung auf öffentlich verfügbaren Luftbild-Datensätzen und der Einsatz auf einem anderen Sensor erzeugt eine Domänenabweichung, die die quantisierte Genauigkeit stärker verschlechtern kann, als die reinen Zahlen vermuten lassen.

Strukturiertes Pruning entfernt ganze Faltungsfilter (Ausgabekanäle), deren L1-Norm unter einem Schwellenwert liegt, und erzeugt ein topologisch kleineres Modell, das sowohl von der reduzierten Parameteranzahl als auch von der reduzierten Speicherbandbreite profitiert. Ein 30-prozentiges strukturiertes Pruning von YOLOv8s entfernt etwa 30 % der Filter im gesamten Backbone, reduziert die Inferenzlatenz auf Jetson-Hardware um etwa 25 % und verbessert die INT8-Genauigkeitsuntergrenze nach der Requantisierung (da die verbleibenden Filter die am stärksten aktivierten sind). Der Pruning-Schwellenwert wird iterativ eingestellt: prunen, 10–20 Epochen auf dem Trainingsdatensatz feinabstimmen, Genauigkeit auf dem Validierungsdatensatz messen und wiederholen, bis die Ziellatenz oder der Speicherbedarf erreicht ist, ohne das akzeptable mAP-Budget zu überschreiten.

Knowledge Distillation adressiert den Fall, in dem das Pruning des vollständigen Modells das Ziel-Parameteranzahl nicht ohne inakzeptablen Genauigkeitsverlust erreichen kann. Ein kompaktes Schülermodell – beispielsweise YOLOv8n – wird trainiert, die Logit-Ausgaben eines größeren Lehrermodells (YOLOv8m oder YOLOv8l) auf den Trainingsdaten zu reproduzieren. Der Schüler lernt, die Konfidenzverteilung des Lehrers über Klassen nachzuahmen, nicht nur seine harten Labelzuweisungen, was Informationen über Klassenambiguität und Merkmalssimilarität vermittelt, die das Training mit harten Labels nicht bietet. Via Distillation trainierte Schülermodelle übertreffen konsistent gleich große, von Grund auf trainierte Modelle, typischerweise um 1–3 mAP bei Luftbild-Erkennungs-Benchmarks. Die Technik ist besonders effektiv, wenn der Trainingsdatensatz klein ist – eine häufige Situation bei Verteidigungseinsätzen, wo beschriftete Luftbildaufnahmen spezifischer Zielklassen rar sind.

Zielerfassungspipelines am Edge: YOLO-Varianten und Bildrate-vs.-Genauigkeits-Kompromisse

Die YOLO-Familie dominiert Edge-Erkennungseinsätze auf UAV-Nutzlasten in der Produktion aus zwei Gründen: Die Architektur ist einstufig (kein Regionsvorschlagsnetzwerk), was die Inferenzlatenz vorhersehbar und begrenzt hält, und der Modell-Zoo ist umfangreich – vortrainierte Gewichte in mehreren Skalierungen (n, s, m, l, x) ermöglichen Teams die Auswahl der Kapazitätsstufe, die in ihr Hardware-Budget passt. YOLOv8 ist die aktuelle Produktionsbasislinie für die meisten Verteidigungsintegratoren, obwohl RT-DETR (ein transformatorbasierter einstufiger Detektor) für Anwendungsfälle an Traktion gewinnt, bei denen die Erkennung kleiner Objekte – Personen auf 500 m Höhe beispielsweise – kritisch ist und die Inferenzhardware die höheren Rechenkosten verkraften kann.

Bildrate und Genauigkeit stehen durch drei Variablen in einem Kompromiss, die der Pipeline-Ingenieur kontrolliert: Modellskalierung, Eingangsauflösung und Konfidenzschwellenwert. Die Reduzierung der Eingangsauflösung von 640x640 auf 320x320 verringert den Inferenz-Rechenaufwand um etwa den Faktor 4 und verdoppelt die erreichbare Bildrate auf fester Hardware, reduziert aber proportional die effektive Erkennungsreichweite für kleine Ziele. Für die Fahrzeugerkennung auf 100–200 m Höhe ist 320x320 im Allgemeinen ausreichend. Für die Personenerkennung auf gleicher Höhe ist 640x640 das praktische Minimum. Die Reduzierung des Konfidenzschwellenwerts von 0,5 auf 0,35 erholt Erkennungen teilweise verdeckter oder entfernter Ziele, erhöht aber die Falsch-Positiv-Rate, was den Annotationsaufwand für das nachgelagerte Fusionssystem erhöht. Der korrekte Schwellenwert ist missionsabhängig und sollte anhand von Ground-Truth-Daten des Einsatzsensors und der Flughöhe abgestimmt werden.

Mehrstufige Pipelines – ein leichtgewichtiger Detektor zur Identifikation von Interessensbereichen, gefolgt von einem leistungsfähigeren Klassifikator zur Verfeinerung des Labels – können die Genauigkeit bei einem gegebenen Rechenbudget verbessern, indem Ressourcen auf Kandidatenregionen konzentriert werden. Ein YOLOv8n mit 30 fps identifiziert Bounding Boxes um fahrzeuggroße Objekte; ein MobileNetV3-Klassifikator mit 10 fps verarbeitet nur die zugeschnittenen Regionen, um Radfahrzeuge von Kettenfahrzeugen und leichte von schweren zu unterscheiden. Diese Kaskadenarchitektur eignet sich gut für das Datenflusssmodell des Hailo-8, bei dem zwei Netzwerke in eine einzige HEF kompiliert und als Pipeline-Graph ausgeführt werden können, anstatt sequenziell, wodurch die Latenz der zweiten Stufe hinter dem Frame-Intervall der ersten verborgen bleibt.

Energiebudget-Beschränkungen und Wärmemanagement auf kleinen UAVs

Das Energiebudget für eine UAV-Nutzlast ist nicht durch die Gesamtenergiekapazität des Luftfahrzeugs festgelegt, sondern durch die Stromzuteilung des Nutzlastschachts aus der Leistungsverteilungseinheit (PDU) und durch das Thermalmodell des Flugmanagementsystems für den Nutzlastschacht. Ein 5-kg-Multi-Rotor mit einem 100-Wh-Akku und 30 Minuten Flugzeit hat eine durchschnittliche Leistungsaufnahme von etwa 200 W aller Systeme kombiniert. Das Antriebssystem verbraucht 80–90 % dieses Budgets unter typischen Schwebeflugbedingungen, sodass 20–40 W für Avionik, Nutzlast und Sensoren verbleiben. Eine Nutzlast mit 15 W Stromaufnahme lässt nur 5–25 W für alles andere. In der Praxis sind Nutzlast-Energiezuteilungen auf Plattformen unter 5 kg vom Flugzeughersteller oft auf 5–8 W festgelegt, und deren Überschreitung verringert die Ausdauer messbar.

Wärmemanagement auf kleinen UAVs ist schwieriger als auf Bodenfahrzeugen oder fester Infrastruktur, weil der Nutzlastschacht versiegelt, klein und möglicherweise aus thermisch isolierenden Verbundmaterialien gefertigt ist. Das UAV-Luftfahrzeug bietet durch Hautleitung und Luftstrom über die Außenfläche etwas Kühlung, aber dieser Vorteil variiert mit Fluggeschwindigkeit und Nutzlastschacht-Geometrie. Das Standardverfahren besteht darin, die Inferenz-Rechenplatine auf einem thermischen Schnittstellenpad am dicksten Aluminium-Strukturelement des Nutzlastchassis zu montieren, das als Wärmespreizer zur Luftfahrzeughaut dient. Für den Jetson Orin Nano bei 10 W Dauerbetrieb kann eine 2 mm dicke Aluminiumplatte, die mit Wärmeleitpaste an die Unterseite des Rumpfes geklebt ist, die Chip-Temperatur bei 40 °C Umgebungstemperatur während des Horizontalflugs unter 75 °C halten. Für den Hailo-8 bei 5 W reicht typischerweise ein einfacher Kühlkörper am M.2-Anschluss des Moduls aus.

Der Stromverbrauch reagiert auch auf die Softwarekonfiguration. Das nvpmodel-Dienstprogramm der Jetson-Plattform bietet Energiemodus-Voreinstellungen, die CPU-Takt, GPU-Takt und Speicherbandbreite begrenzen. Die Einstellung des Orin Nano auf einen 7-W-Energiemodus reduziert den Inferenzdurchsatz um etwa 35 % im Vergleich zum maximalen 15-W-Modus, halbiert aber nahezu die Wärmeabgabe – was der richtige Kompromiss sein kann, wenn die thermische Einhüllende des Nutzlastschachts die bindende Beschränkung ist, nicht die Inferenzlatenz. Eine Konfiguration, die das gesamte Missionsprofil des Luftfahrzeugs ohne thermische Drosselung ausführt, ist zuverlässiger als eine, die 15 Minuten lang maximale Inferenzleistung erzielt, bevor der automatische Thermoschutz des Chips auslöst und die Bildrate unvorhersehbar reduziert.

C2-Integration über MANET bei Wiederverbindung

Das während eines Verbindungsausfalls angesammelte Erkennungsprotokoll hat begrenzten Wert, wenn es nicht schnell und vollständig an das Führungs- und Kontrollsystem übermittelt werden kann, sobald die Konnektivität wiederhergestellt ist. MANET-Funkgeräte (Mobile Ad-hoc Network) – eingesetzt in taktischen UAV-Operationen zur Bereitstellung von Mesh-Konnektivität zwischen Luftfahrzeug, Bodenfahrzeugen und abgesessenen Kräften – sind der primäre Transport sowohl für Echtzeit-Erkennungsstreaming als auch für die Nachausfall-Synchronisierung. Wenn das UAV wieder in die Mesh-Abdeckung eintritt, stellt der MANET-Knoten an Bord innerhalb von Sekunden das Routing wieder her, und der Synchronisierungsagent beginnt mit der Übertragung gepufferter Erkennungsdatensätze.

Die Synchronisierungsagenten-Architektur sollte um zwei Betriebsmodi herum gestaltet werden. Im verbundenen Modus werden Erkennungsdatensätze in nahezu Echtzeit übertragen, sobald sie von der Inferenzpipeline erzeugt werden, als CoT-Ereignisse serialisiert und über das MANET-Mesh an TAK Server veröffentlicht. Im getrennten Modus sammeln sich Datensätze in einer lokalen SQLite-Datenbank mit einem "synchronisiert"-Flag an. Bei Wiederverbindung fragt der Agent nach nicht synchronisierten Datensätzen, geordnet nach Zeitstempel, und überträgt sie in chronologischer Reihenfolge, ratenbegrenzt, um das Funknetz des MANET-Geräts nicht mit Burst-Traffic auf Kosten anderer Netzwerkteilnehmer zu sättigen. Nach der Bestätigung jedes Datensatzes durch den Server wird er als synchronisiert markiert. Die Datenbank sorgt für Absturzwiederherstellung: Wenn das UAV landet oder der Inferenzdienst mitten in der Synchronisierung neu startet, setzt der nächste Synchronisierungszyklus vom letzten nicht synchronisierten Datensatz fort, anstatt das gesamte Protokoll erneut zu übertragen.

Die CoT-Ereigniskonstruktion für UAV-KI-Erkennungen folgt dem Standard-CoT-Schema, trägt aber nutzlastspezifische Erweiterungen im Detail-Block. Die Erkennungsklasse und der Konfidenzwert füllen benutzerdefinierte CoT-Detail-Unterelemente. Die GPS-Position des UAV zum Zeitpunkt der Bildaufnahme wird als CoT-Punkt verwendet, und wenn die Inferenzpipeline eine bodenprojizierte Erkennungsposition aus dem Sichtfeld des Sensors, der Höhe über Grund und dem Gimbal-Winkel berechnen kann, wird diese projizierte Koordinate stattdessen verwendet – der Erkennungsmarker wird auf der Karte an der tatsächlichen Bodenposition des Ziels platziert, nicht an der Position des Luftfahrzeugs. TAK Server liefert diese CoT-Ereignisse an alle verbundenen ATAK-Clients, wo sie als klassifizierte Marker mit Erkennungsherkunft und Konfidenz-Metadaten im Ereignisdetailbereich erscheinen.

Beschaffung: SWaP-C und MIL-STD-Umweltbewertungen

Die Beschaffung einer bordseitigen KI-Inferenz-Nutzlast für ein taktisches UAV-Programm erfordert die Bewertung von Hardware anhand von drei nicht verhandelbaren Achsen: SWaP-C (Größe, Gewicht, Leistung und Kosten), Umweltbewertungen und Lieferketten-Reife. SWaP-C treibt den oben beschriebenen Plattformkompromiss an – TOPS pro Watt, physische Abmessungen und Stückkosten schränken allesamt ein, welches Silizium praktikabel ist. Umweltbewertungen bestimmen, ob die Hardware die Einsatzbedingungen übersteht, denen sie begegnen wird. Die Kosten bestimmen die Expendabilitätsdoktrin der Plattform: Eine Nutzlast für ein wiedergewinnbares ISR-UAV hat eine andere Kostentoleranz als eine, die in ein Einweg-Loitering-System eingebaut ist.

MIL-STD-810 definiert die für UAV-Nutzlasten relevanten Umweltbelastungstests: Temperaturwechsel (Methode 501/502), Vibration (Methode 514), Feuchtigkeit (Methode 507), Höhe (Methode 500) und Schock (Methode 516). Handelsübliche (COTS) Inferenzmodule wie der Jetson Orin Nano sind für 0–80 °C Betriebstemperatur in der kommerziellen Variante und -25 bis 80 °C in der industriellen Variante ausgelegt. UAV-Nutzlastschächte in kalten Klimazonen oder Hochgebirgseinsätzen können die Rechenplatine beim Start Temperaturen unter -25 °C aussetzen. Wo dies ein Problem darstellt, ist eine thermische Vorkonditionierungsschaltung – ein Widerstandsheizgerät, das von einem Thermostaten gesteuert wird und den Schacht erwärmt, bevor die Hauptnutzlastversorgung eingeschaltet wird – eine einfachere und zuverlässigere Lösung als die Auswahl eines Prozessors mit breiterem Temperaturbereich, der möglicherweise nicht in der erforderlichen Leistungsklasse existiert.

Die Lieferketten-Reife ist in Verteidigungsprogrammen überproportional wichtig, weil lange Produktionsläufe eine konsistente Komponentenverfügbarkeit über mehrjährige Zeiträume erfordern. Der Lebenszyklus des Jetson Orin-Moduls ist von NVIDIA mit einem 10-jährigen Produktionsbekenntnis für industrietaugliche Varianten veröffentlicht, was die meisten Verteidigungsprogramm-Lebenszyklusanforderungen erfüllt. Der Hailo-8 ist ein neuerer Marktteilnehmer mit kürzerer Produktionshistorie, und Beschaffungsbehörden, die ihn für Hochvolumenprogramme evaluieren, sollten vertragliche Lieferkontinuitätsverpflichtungen fordern. Für Plattformen, bei denen der Inferenz-Chip in eine nach Programmspezifikationen gestaltete kundenspezifische Trägerplatine eingebettet wird, sollte das Trägerplatinen-Design Footprint-Bestimmungen für mindestens ein alternatives Beschleunigermodul enthalten, damit eine programmbegleitende Chip-Lebenszyklus-Änderung keinen Trägerplatinen-Neuentwurf erfordert.