Nowoczesne systemy ISR (rozpoznanie, nadzór, zwiadu) generują wolumeny danych, które fundamentalnie przekraczają ludzką zdolność przetwarzania. Pojedynczy BSP średniej wysokości operujący ładunkiem pełnoruchowego wideo generuje około 2–4 TB surowego wideo dziennie przy standardowej rozdzielczości, plus powiązane dzienniki sensorów i metadane. Rozlokowany system zbierania SIGINT może produkować terabajty danych IQ dziennie w monitorowanym spektrum. Wąskim gardłem we współczesnym ISR nie jest zbieranie danych — lecz ich przetwarzanie i analiza.

Tradycyjna odpowiedź na to wąskie gardło to przepustowość: przesyłanie surowych danych do stacji naziemnej i stosowanie tam pracy analityków. To podejście napotyka trzy strukturalne ograniczenia we współczesnych środowiskach operacyjnych. Po pierwsze, budżet łącza — satelitarne i taktyczne łącza radiowe po prostu nie mogą ciągle przenosić pełnorozdzielcze wideo z dużej floty BSP. Po drugie, niedobór analityków — nie ma wystarczającej liczby wykwalifikowanych analityków obrazów do przeglądania wszystkich nagrań klatka po klatce. Po trzecie, wartość czasowa wywiadu — do czasu dotarcia surowego wideo do stacji naziemnej, ustawienia w kolejce i skupienia uwagi analityka, okno działania dla celów wrażliwych czasowo może się już zamknąć.

Triage AI na urządzeniu brzegowym rozwiązuje wszystkie trzy ograniczenia jednocześnie. Potok AI działa na platformie zbierającej — samym BSP lub węźle sensorowym — i automatycznie filtruje strumień danych, zatrzymując i przesyłając tylko te części zawierające obiekty zainteresowania, odrzucając lub silnie kompresując tło pustego terenu, nieba i wody, które stanowi większość surowego zbioru ISR.

Problem przeciążenia danych ISR

Skala problemu przeciążenia danych wymaga precyzyjnego sformułowania. Rozważmy rozlokowany rozpoznawczy BSP Wojska Polskiego operujący ładunkiem dwusensorowym EO/IR przy rozdzielczości 1080p, 30 kl./s, przez 16 godzin dziennie. Przy standardowej kompresji H.264 generuje to około 50 GB wideo na lot. Jeśli tylko 3% zebranego materiału zawiera obiekty zainteresowania (hojna ocena dla misji szerokiego obszaru), to 97% budżetu przepustowości i pamięci masowej jest zużywane na dane, które nigdy nie będą możliwe do działania. Triage AI na brzegu zmienia stosunek fundamentalnie: wykrywając i oznaczając tylko klatki zawierające wykrycia, wymaganie dotyczące przepustowości transmisji spada z 50 GB do około 1,5 GB na dzień lotu — w zasięgu satelitarnego łącza działającego przy umiarkowanych przepływnościach danych.

Zbieranie SIGINT stoi w obliczu analogicznego problemu. Szerokopasmowy system zbierania SDR monitorujący wycinek spektrum 200 MHz generuje kilkaset gigabajtów danych IQ na godzinę. Tylko mały ułamek monitorowanego spektrum jest aktywny w dowolnym momencie, a tylko ułamek aktywnych sygnałów ma znaczenie analityczne. Automatyczne skanowanie spektrum i klasyfikacja sygnałów na brzegu redukuje obciążenie przetwarzania końcowego z pełnej zebranej przepustowości do tylko klasyfikowanych sygnałów zainteresowania — redukcja o dwa do trzech rzędów wielkości.

Potok triażu na brzegu: od surowego wejścia sensorowego do oceny priorytetu

Potok triażu na brzegu dla przetwarzania wideo BSP przebiega przez cztery etapy:

1. Surowe wejście sensorowe. Klatki wideo z sensorów EO i/lub IR są odbierane przez sprzęt obliczeniowy urządzenia brzegowego. Dla wymagania przetwarzania w czasie rzeczywistym przy 30 kl./s, potok obliczeniowy musi zakończyć jeden pełny cykl inferencji — wstępne przetwarzanie, inferencja modelu detekcji, post-przetwarzanie i generowanie metadanych — w ciągu 33 ms.

2. Wykrywanie obiektów. Każda klatka jest przetwarzana przez lekki model detekcji obiektów (YOLOv8-nano lub YOLOv8-small, skwantowany do INT8), który identyfikuje obecność i lokalizację obiektów zainteresowania — pojazdy, osoby, budynki lub cele specyficzne dla sensorów. Wyjście detekcji to zestaw ramek ograniczających z etykietami klas i punktami pewności.

3. Klasyfikacja i wzbogacenie kontekstu. Klatki zawierające wykrycia powyżej progu pewności są przekazywane do wtórnego etapu klasyfikacji. Ten etap stosuje bardziej obliczeniowo intensywną analizę do wykrytych obiektów: klasyfikacja typu pojazdu (kołowy vs gąsienicowy, cywilny vs wojskowy profil), klasyfikacja aktywności (nieruchomy, poruszający się, zgrupowany) i adnotacja geoprzestrzenna (współrzędne GPS wykrytych obiektów przy użyciu geometrii gimbal i sensora). Dla detekcji wielu obiektów, etap klastrowania identyfikuje, czy wykryte obiekty tworzą grupy zgodne z konfiguracjami konwojów lub rozproszonych patroli.

4. Ocena priorytetu. Każde adnotowane zdarzenie wykrycia jest oceniane pod kątem priorytetu operacyjnego zgodnie z wymaganiami MON. Czynniki oceny obejmują: klasę i typ obiektu (pojazd wojskowy uzyskuje wyższy wynik niż cywilny); wynik pewności; bliskość do wcześniej zidentyfikowanych lokalizacji zainteresowania; wskaźniki aktywności (poruszające się cele zazwyczaj uzyskują wyższy wynik niż nieruchome); oraz gęstość czasową (wiele wykryć tego samego typu obiektu w oknie 10-minutowym zwiększa priorytet). Wynik priorytetu określa, czy zdarzenie jest przesyłane natychmiast, kolejkowane do transmisji wsadowej, czy archiwizowane bez transmisji.

Przetwarzanie wideo BSP: detekcja obiektów w czasie rzeczywistym przy 30 kl./s

Osiągnięcie stałej detekcji obiektów przy 30 kl./s na wbudowanym GPU wymaga starannej inżynierii potoku poza prostym wdrożeniem szybkiego modelu. Wejście wideo musi być wydajnie dekodowane i transferowane do pamięci GPU; dla zakodowanych strumieniowo wideo H.264/H.265 z kamer gimbal, sprzętowo przyspieszone dekodowanie (przy użyciu sprzętowego dekodera wideo NVDEC Jetson zamiast programowego dekodowania CPU) jest niezbędne, aby uniknąć zużycia budżetu CPU potrzebnego do sterowania i komunikacji.

DeepStream SDK NVIDIA zapewnia opartą na GStreamer strukturę potoku zoptymalizowaną dla Jetson, która obsługuje sprzętowo przyspieszone dekodowanie wideo, obsługę wielu strumieni i wydajne zarządzanie pamięcią GPU dla inferencji modelu detekcji. Potok DeepStream uruchamiający YOLOv8-small INT8 na Jetson Orin NX może przetwarzać cztery jednoczesne strumienie wideo 1080p przy 30 kl./s w budżecie mocy 15 W — umożliwiając konfiguracje ładunku czterosensorowego na BSP klasy średniej.

Wygładzanie temporalne jest krytycznym komponentem niezawodności. Model detekcji obiektów na jednej klatce produkuje wykrycia, które mogą migotać — obiekt wykryty w klatkach 1 i 3, ale nie w klatce 2 z powodu wariancji progu pewności. Warstwa agregacji oparta na śladach (przy użyciu ByteTrack lub podobnego) przypisuje trwałe identyfikatory śladów między klatkami i stosuje filtrowanie temporalne: tylko ślady, które utrzymują się przez minimalną liczbę klatek (zazwyczaj 3–5) i utrzymują minimalny średni wynik pewności, są podnoszone do zdarzeń triażu. To eliminuje jednoklatkowe fałszywe alarmy z wyjścia triażu bez wprowadzania znaczących opóźnień.

Człowiek w pętli: progi eskalacji AI

Potok triażu AI nie jest zaprojektowany, aby zastąpić osąd analityka — jest zaprojektowany, aby skupić uwagę analityka. Architektura eskalacji ma trzy poziomy:

Automatyczna transmisja. Zdarzenia uzyskujące wyniki powyżej progu wysokiego priorytetu (zazwyczaj skorygowana pewnością kombinacja typu obiektu, aktywności i gęstości temporalnej) są przesyłane natychmiast przez dostępne łącze. Pakiet metadanych — współrzędne GPS, klasa obiektu, wynik pewności, znacznik czasu i reprezentatywna miniatura — ma około 50 KB na zdarzenie. System generujący 200 zdarzeń wysokiego priorytetu na dzień lotu wymaga około 10 MB przepustowości transmisji dla samych metadanych — dobrze poniżej typowej przepustowości łącza satelitarnego.

Kolejka przeglądu analityka. Zdarzenia średniego priorytetu są buforowane na pokładzie i przesyłane w następnym dostępnym oknie transmisji wysokiej przepustowości (kontakt satelitarny, powrót do bazy). Kolejka przeglądu analityka zawiera zarówno metadane, jak i klip wideo (zazwyczaj 10–30 sekund wokół zdarzenia wykrycia przy zmniejszonej rozdzielczości) do przeglądu kontekstowego.

Tylko archiwizacja. Zdarzenia o niskiej pewności i niskim priorytecie są archiwizowane na lokalnej pamięci masowej BSP. Jeśli późniejsze zdarzenie wysokiego priorytetu w tym samym obszarze wywołuje analizę retrospektywną, zarchiwizowane nagrania z okresu przed zdarzeniem wysokiego priorytetu mogą być przeglądane pod kątem poprzedzających wzorców aktywności.

Kluczowa obserwacja: Oszczędności przepustowości z triażu AI na brzegu to nie tylko logistyczne — są operacyjnie umożliwiające. BSP, który wcześniej wymagał łącza satelitarnego o wysokiej przepustowości do utrzymania ciągłego wyjścia wywiadowczego, może teraz działać efektywnie na znacznie węższym łączu, rozszerzając liczbę platform, które mogą być utrzymywane w ramach danej architektury komunikacyjnej, o rząd wielkości.

Oszczędności przepustowości: transmisja klipów vs pełnych strumieni wideo

Skwantyfikowana redukcja przepustowości z triażu na brzegu zależy od gęstości celów w obszarze operacyjnym i ustawień czułości modelu detekcji. W terenie o niskiej aktywności (otwarta pustynia, las, ocean), gdzie cele zainteresowania pojawiają się w mniej niż 1% klatek, triage na brzegu może osiągnąć redukcję 100:1 w przesyłanych danych. W wysoce aktywnych obszarach miejskich lub spornych, gdzie ruch pojazdu jest ciągły, redukcja jest mniejsza — może 10:1 — ale nadal znacząca dla zarządzania budżetem łącza zgodnie z wymaganiami MON.

Transmisja miniatury z metadanymi dla wykrytego zdarzenia wynosi średnio około 50–100 KB. 30-sekundowy klip wideo przy zmniejszonej rozdzielczości (480p, H.265) wynosi średnio około 5–10 MB. W porównaniu z transmisją pełnorozdzielczego wideo w pełnym ruchu przy około 2 Mbps (około 900 MB na godzinę), oszczędności przepustowości dla dnia lotu z 200 zdarzeniami triażu to: 200 pakietów metadanych (20 MB) plus 50 klipów średniego priorytetu (500 MB) wobec 14,4 GB pełnego wideo — redukcja 20:1 dla tego scenariusza, zmniejszając wymaganą przepustowość łącza satelitarnego z około 2 Mbps ciągłych do około 200 kbps średnich.