Oprogramowanie do rozpoznania UAV: od sensora do decyzji operatora

UAV przenosi sensory. Sensor produkuje dane. Dane stają się informacją, gdy zostaną połączone z kontekstem i dostarczone operatorowi, który może na nich działać. Odległość między tymi dwoma punktami końcowymi — uchwytem sensora a decyzją operatora — to pętla sensor–decyzja, a oprogramowanie do rozpoznania UAV zarządza jej opóźnieniem, wiernością i niezawodnością. Ten artykuł analizuje pełny potok: od konfiguracji pokładowego sensora przez łącze transmisji danych, do stacji naziemnej, przez potok analizy wideo, aż do wspólnego obrazu sytuacyjnego wyświetlanego oficerom S2 i S6 w terenie.

Pętla sensor–decyzja: przegląd architektury

Pętla ma pięć odrębnych etapów, z których każdy wprowadza opóźnienie i każdy stanowi potencjalny punkt awarii:

1. Pokładowy sensor i kodowanie. Ładunki elektrooptyczne (EO), podczerwieni (IR), syntetycznej apertury radarowej (SAR) i SIGINT produkują surowe dane, które muszą być skompresowane i multipleksowane do transmisji. W przypadku ładunków wideo kodowanie H.264 lub H.265 odbywa się na pokładowej płycie kodera wideo UAV. Metadane KLV MISB (Motion Imagery Standards Board) — pozycja platformy, postawa, pole widzenia sensora — są osadzane w strumieniu transportowym na tym etapie. Opóźnienie kodowania na wydajnym sprzęcie wynosi typowo 30–80 ms.

2. Łącze transmisji danych. Zakodowany strumień transportowy jest transmitowany drogą radiową przez łącze C2 (sterowanie i kontrola — uplink) i osobny szerokopasmowy downlink wywiadowczy. Popularne typy downlinku obejmują Tactical Common Data Link (TCDL) w paśmie C lub Ku dla platform MALE i HALE, oraz łącza punkt-punkt 2,4 GHz lub 5,8 GHz dla taktycznych UAS. Opóźnienie łącza dla dobrze zaprojektowanego systemu w linii wzroku wynosi 10–50 ms; przekaźnik satelitarny dodaje 500–600 ms w jedną stronę (geostacjonarny) lub 20–80 ms (niska orbita ziemska), co znacząco zmienia budżet opóźnień dla wrażliwego czasowo namierzania.

3. Odbiór i dekodowanie w stacji naziemnej. Naziemny terminal danych (GDT) odbiera sygnał RF i wyprowadza strumień transportowy MPEG-2 STANAG 4609 przez Ethernet lub szeregowo. Oprogramowanie stacji naziemnej dekoduje strumień, demultipleksuje metadane KLV z elementarnego strumienia wideo i przekazuje oba do konsumentów downstream. Dobrze zaimplementowany stos odbiorczy dodaje mniej niż 100 ms opóźnienia przetwarzania na tym etapie.

4. Analiza i geolokalizacja. Zdekodowane klatki są przekazywane do potoku analizy wideo — wykrywanie, klasyfikacja i śledzenie — podczas gdy jednocześnie wyodrębnione metadane KLV zasilają silnik geolokalizacji. Wynikiem tego etapu jest zestaw geolokalizowanych, sklasyfikowanych detekcji publikowanych jako zdarzenia do sieci taktycznej. Opóźnienie analityczne zależy od złożoności modelu i sprzętu; model o rozmiarze YOLOv8 na stacji roboczej z GPU przetwarza klatki 1080p szybciej niż w czasie rzeczywistym, poniżej 20 ms na klatkę. Na sprzęcie edge wyłącznie z CPU ten sam model może wymagać 80–150 ms na klatkę.

5. Wyświetlenie operatorowi i decyzja. Operator ogląda kanał wideo, nakładkę śladu sensora na mapie i znaczniki wykrytych detekcji we wspólnym obrazie sytuacyjnym. Opóźnienie decyzji — czas od wyświetlenia do wydania komendy lub raportu — jest czynnikiem ludzkim, którego żadne oprogramowanie nie może w pełni kontrolować, ale redukcja opóźnienia wyświetlania i poprawa gęstości informacji bezpośrednio zmniejsza obciążenie poznawcze i skraca cykl decyzyjny.

STANAG 4609 i KLV MISB: kontrakt danych

STANAG 4609 jest podstawowym kontraktem danych dla obrazów ruchomych UAV w ramach sojuszniczych struktur interoperacyjności. Określa, że wideo UAV ma być przesyłane jako strumień transportowy MPEG-2 z osadzonymi metadanymi MISB Local Set (LS) 0601. LS 0601 definiuje około 140 otagowanych elementów danych obejmujących każdy parametr potrzebny analitykowi lub systemowi automatycznemu do geolokalizacji zawartości obrazu: pozycja sensora, kurs platformy, pochylenie, przechylenie, kąty FOV sensora, zasięg skośny, kąt obliquity i inne.

Kodowanie KLV (Key-Length-Value) używane przez MISB to kompaktowy format binarny. Każdy element metadanych jest identyfikowany przez 1-bajtowy lub 2-bajtowy klucz, po którym następuje pole długości i wartość w standardowym kodowaniu zmiennoprzecinkowym lub całkowitoliczbowym. Minimalny zgodny pakiet KLV dla klatki wideo może mieć 80–120 bajtów. Przy 30 klatkach na sekundę dodaje to około 3–4 kbps narzutu do strumienia transportowego — zaniedbywalnego dla każdego taktycznego łącza danych.

Dla integratorów kluczowym punktem implementacyjnym jest to, że metadane KLV muszą być wyodrębniane w synchronizacji z klatkami wideo, które opisują. Pakiety KLV są osadzone w strumieniu transportowym jako prywatne PID danych obok PID wideo. Parser, który przetwarza dwa PID asynchronicznie — lub który opóźnia wyświetlanie wideo bez opóźniania aplikacji metadanych — będzie produkował błędy geolokalizacji rosnące wraz z prędkością platformy i szybkością obrotu gimbala. Przy prędkości naziemnej 60 węzłów i 1-sekundowym opóźnieniu metadanych, błąd geolokalizacji może przekroczyć 30 metrów.

Obowiązkowe pola LS 0601 do geolokalizacji

Nie wszystkie 140+ pól LS 0601 jest wymaganych do podstawowej geolokalizacji. Minimalny zestaw potrzebny do obliczenia, gdzie piksel na obrazie pada na grunt, obejmuje: szerokość geograficzna sensora (tag 13), długość geograficzna sensora (tag 14), prawdziwa wysokość sensora (tag 15), kąt kursu platformy (tag 5), kąt pochylenia platformy (tag 6), kąt przechylenia platformy (tag 7), poziome FOV sensora (tag 16), pionowe FOV sensora (tag 17), względny kąt azymutu sensora (tag 18), względny kąt elewacji sensora (tag 19), względny kąt przechylenia sensora (tag 20) i zasięg skośny (tag 21). Wszystkie pozostałe pola są uzupełniające — przydatne do analizy, ale niewymagane do obliczania geolokalizacji w czasie rzeczywistym.

Potok analizy wideo: wykrywanie i klasyfikacja

Automatyczne wykrywanie obiektów jest etapem najbardziej zależnym od inżynierii domenowej. Modele wykrywania ogólnego przeznaczenia wytrenowane na obrazach cywilnych słabo radzą sobie z militarnymi obrazami z perspektywy UAV — kąt widzenia, skala, kamuflaż i różnorodność celów są zupełnie inne. Model używany w produkcji powinien być dostrojony na oznakowanym zbiorze danych reprezentatywnym dla środowiska operacyjnego: typy celów (pojazdy, personel, stanowiska), zakres wysokości, typ sensora (EO vs. IR) i klasy tła (miejski, wiejski, zalesiony, mieszany).

Standardowa architektura dla analizy wideo UAV w czasie rzeczywistym używa dwuetapowego potoku: szybki jednoetapowy detektor (YOLOv8 lub odpowiednik) działający z pełną szybkością klatek dla wykrywania i zgrubnej klasyfikacji, zasilający detekcje do wolniejszego, lecz dokładniejszego modelu klasyfikacji potwierdzającego klasę i przypisującego pewność. Szybki detektor priorytetyzuje czułość — wychwytywanie wszystkich potencjalnych celów nawet kosztem fałszywych alarmów. Klasyfikator filtruje listę detekcji i przypisuje ostateczną etykietę. Ta separacja umożliwia systemowi działanie z szybkością klatek wideo przy jednoczesnym stosowaniu większej mocy obliczeniowej do potwierdzonych detekcji.

Geolokalizacja detekcji

Każda obwiednia detekcji musi być przekonwertowana na współrzędną WGS84 na płaszczyźnie gruntu, zanim będzie mogła być opublikowana jako zdarzenie geoprzestrzenne. Obliczenie używa współrzędnych pikselowych centroidu detekcji, geometrii sensora z metadanych KLV i modelu rzeźby terenu (DTED Level 1 lub Level 2). Standardowym podejściem jest rzutowanie promienia od sensora przez piksel płaszczyzny obrazu i przecięcie go z powierzchnią terenu. Bez DEM przybliżenie płaskiej ziemi z wykorzystaniem zasięgu skośnego wprowadza błędy zależne od wysokości, które stają się istotne na pagórkowatym lub górzystym terenie.

Do śledzenia detekcji — łączenia detekcji między klatkami w celu tworzenia trwałych śladów — filtr Kalmana lub algorytm SORT (Simple Online and Realtime Tracking) jest standardem produkcyjnym. Trwałe ślady zmniejszają obciążenie poznawcze operatora w porównaniu z detekcjami klatka po klatce: zamiast mapy migającej nowymi znacznikami przy każdej klatce, operator widzi niewielką liczbę stabilnych, poruszających się znaczników z historią pewności.

Integracja stacji naziemnej i architektura łącza C2

Stacja naziemna jest centrum pętli sensor–decyzja. Produkcyjna stacja naziemna dla taktycznego programu UAS typowo uruchamia kilka komponentów oprogramowania równolegle: odbiornik i demultiplekser strumienia transportowego, aplikację wyświetlania wideo (z nagrywaniem misji), ekstraktor metadanych KLV, potok analityczny oraz wydawcę CoT/sieci taktycznej.

Uplink C2 — komendy od operatora do UAV — i downlink wywiadowczy są logicznie oddzielone, ale często współdzielą ten sam system RF. Integralność łącza C2 jest trudniejsza do utrzymania niż downlinku: wiadomości komend są małe, ale muszą docierać z bardzo małym opóźnieniem i wysoką niezawodnością. Standardowa architektura dla integralności łącza C2 używa dedykowanego wąskopasmowego uplinku na oddzielnej częstotliwości od szerokopasmowego downlinku wywiadowczego, z szyfrowaniem AES-256 i FHSS (frequency-hopping spread spectrum) dla odporności na zagłuszanie. Oprogramowanie stacji naziemnej musi monitorować metryki jakości łącza C2 — bitową stopę błędów, opóźnienie potwierdzenia komendy w obie strony — i alarmować operatora przed degradacją łącza powodującą utratę kontroli nad statkiem powietrznym.

Wzorzec pluginu ATAK dla zasobów UAV

Integracja zasobu UAV z ATAK — standardową taktyczną aplikacją świadomości sytuacyjnej — podąża za ugruntowaną architekturą pluginów. Plugin integracji UAV ma trzy komponenty funkcjonalne działające równocześnie.

Komponent panelu wideo. Panel wspierany przez SurfaceView wewnątrz okna pluginu ATAK renderuje zdekodowany strumień wideo. Dekoder wideo działa w wątku w tle, przesyłając klatki do powierzchni z natywną szybkością klatek strumienia. Panel powinien zawierać adnotacje nakładkowe (okna celów z potoku analitycznego) renderowane przez Canvas na przezroczystej warstwie nad powierzchnią wideo, zsynchronizowanej z wyświetlaną klatką.

Komponent nakładki śladu. Cztery współrzędne narożnikowe śladu sensora — obliczone z pól geometrii MISB i modelu terenu — są publikowane jako zdarzenie wielokąta CoT i renderowane na mapie ATAK jako półprzezroczyste trapezoidalne nałożenie. Wielokąt śladu aktualizuje się z szybkością metadanych KLV (typowo 1–10 Hz dla większości systemów). Przy wolniejszych szybkościach aktualizacji ślad może wydawać się opóźniony względem wyświetlania wideo podczas szybkich obrotów gimbala; naprawą jest ekstrapolacja pozycji śladu z wykorzystaniem szybkości zmiany postawy platformy między aktualizacjami metadanych.

Komponent wydawcy detekcji. Geolokalizowane detekcje z potoku analitycznego są publikowane jako zdarzenia punktu CoT na TAK Server z odpowiednimi kodami typów CoT. Ślady detekcji z trwałą tożsamością są publikowane ze spójnym UID w aktualizacjach, aby klienci ATAK wyświetlali je jako ruchome znaczniki, a nie sekwencję niezależnych zdarzeń. Plugin powinien umożliwiać operatorowi potwierdzenie lub odrzucenie detekcji — potwierdzone detekcje są awansowane do typu CoT o wyższej pewności; odrzucone detekcje są usuwane z obrazu.

Budżety opóźnień dla wrażliwych czasowo celów

Wrażliwe czasowo namierzanie celów — proces wykrywania, identyfikacji i zaangażowania celu, który pojawia się w krótkim oknie czasowym — nakłada najsurowsze wymagania dotyczące opóźnień na stos oprogramowania do rozpoznania UAV. Odpowiednia doktryna wojskowa określa cykl namierzania poniżej 30 minut dla namierzania deliberatywnego; wrażliwe czasowo namierzanie kompresuje to do minut lub sekund w zależności od typu zagrożenia.

W potoku oprogramowania alokacje budżetu opóźnień, które mają największe znaczenie, to:

Opóźnienie wyświetlania wideo: poniżej 500 ms całkowitych od uchwycenia przez sensor do wyświetlenia operatorowi. Oznacza to: kodowanie (80 ms) + łącze (50 ms, linia wzroku) + dekodowanie (30 ms) + potok wyświetlania (20 ms) = około 180 ms dla dobrze zoptymalizowanego systemu. Buforowanie dla adaptacyjnego strumieniowania bitrate lub kompensacji jittera często dodaje 200–500 ms na to — agresywne ustawienia bufora są najczęstszym źródłem niedopuszczalnego opóźnienia wyświetlania.

Opóźnienie wykrycie–CoT: poniżej 3 sekund od detekcji w potoku analitycznym do zdarzenia CoT widocznego na połączonych klientach ATAK. Ten budżet obejmuje wnioskowanie detekcji (20–150 ms), obliczanie geolokalizacji (10 ms), budowanie i publikowanie zdarzenia CoT (5 ms), przekaźnik TAK Server (50–200 ms zależnie od liczby skoków federacyjnych) i aktualizację klienta ATAK (100–500 ms zależnie od interwału odpytywania aktualizacji).

Opóźnienie operator–C2: poniżej 2 sekund od wyznaczenia celu przez operatora w pluginie ATAK do dotarcia komendy do operatora UAV lub elementu kontroli ognia. Jest to przede wszystkim opóźnienie sieciowe i systemów C2 — udział pluginu integracji UAV jest zanieczyszczalny, jeśli natychmiast publikuje CoT po działaniu operatora.

Głębsze omówienie architektury widzenia komputerowego używanej w potoku analitycznym znajdziesz w artykule o widzeniu komputerowym dla dronów ISR.