Zarządzanie zbieraniem SIGINT: zlecanie zadań, dekonfliktowanie i priorytety

Każdy system SIGINT napotyka w końcu ten sam problem: wymagań zbierania jest więcej niż sensorów zdolnych je spełnić. Sensory mają ograniczony zasięg częstotliwości, ograniczoną pojemność jednoczesnego zlecania zadań i ograniczenia geograficzne, których żadna inżynieria w pełni nie eliminuje. Zarządzanie zbieraniem to dyscyplina, która wypełnia lukę między tym, czego dowódcy potrzebują wiedzieć, a tym, co flota sensorów jest w stanie fizycznie obserwować.

Artykuł omawia architekturę oprogramowania i algorytmy implementujące zarządzanie zbieraniem na poziomie systemu: jak wymagania przekształcają się w plany zadań, jak rozwiązywane są konflikty oraz jak system mierzy własną wydajność i adaptuje się w czasie rzeczywistym.

Czym jest zarządzanie zbieraniem

Zarządzanie zbieraniem sytuuje się między procesem wymagań wywiadowczych a poszczególnym sensorem. Z jednej strony analitycy i dowódcy generują strumień pytań: jakich częstotliwości używa sieć radarów obrony powietrznej przeciwnika? Czy podejrzany węzeł logistyczny nadaje? Które jednostki są aktywne w kwadracie siatki XY? Z drugiej strony dysponujemy skończonym zestawem sensorów o określonych oknach zasięgu, zakresach częstotliwości i limitach pojemności jednoczesnych zadań.

Funkcja zarządzania zbieraniem przekształca wymagania w wykonywalne rozkazy zadań dla sensorów, monitoruje wykonanie względem planu i przekazuje wyniki z powrotem do właścicieli wymagań. Bez tej funkcji wymaganie o wysokim priorytecie rywalizuje ślepo z rutynowymi zadaniami niskiego priorytetu. Sensory kierowane są na niewłaściwe cele. Krytyczne okna zbierania są pomijane, bo dwóch zbieraczy jest przydzielonych do tego samego celu, podczas gdy trzeci nie ma żadnej pracy.

Podstawowy problem programistyczny to planowanie zasobów z ograniczeniami w warunkach niepewności. Wymagania napływają ciągle. Dostępność sensorów zmienia się wraz z ruchem platform, statusem konserwacji i jakością łącza komunikacyjnego. Samo środowisko — zagłuszanie, maskowanie terenowe, efekty atmosferyczne — wpływa na to, co każdy zbieracz może obserwować. System zarządzania zbieraniem musi utrzymywać dokładny model wszystkich tych zmiennych i na bieżąco aktualizować plany zadań.

Zarządzanie wymaganiami zbierania

Wymagania trafiają do systemu zarządzania zbieraniem w ustrukturyzowanej hierarchii. Priorytetowe wymagania wywiadowcze (PIR) wyrażają najważniejsze potrzeby wywiadowcze dowódcy na poziomie strategicznym lub operacyjnym. PIR są rozkładane na wymagania wywiadowcze (IR) — bardziej szczegółowe pytania powiązane z konkretnymi celami, obszarami geograficznymi lub oknami czasowymi. IR są dalej rozkładane na szczegółowe wymagania zbierania (SIR) — atomowe, wykonywalne przez sensor zadania określające, jakiego sygnału szukać, w jakim paśmie częstotliwości, w jakiej lokalizacji i w jakim oknie czasowym.

Platforma COLISEUM (Collection Operations Intelligence Schedules and Execution Unified Management), stosowana w systemach wywiadowczych NATO, formalizuje tę hierarchię i dodaje pola dla wnioskodawcy, priorytetu, uzasadnienia i wymaganego harmonogramu zbierania. Rekordy wymagań w stylu COLISEUM mają unikalny identyfikator, który utrzymuje się przez cały łańcuch od zbierania do raportowania, umożliwiając śledzenie od początku do końca — od pytania dowódcy do wynikowego produktu wywiadowczego.

W kategoriach programistycznych baza danych wymagań przechowuje każdy SIR jako rekord z następującymi kluczowymi polami: identyfikator celu, zakres częstotliwości lub klasa sygnału, geograficzny obszar zainteresowania (wielokąt lub punkt z promieniem), okno czasowe (znaczniki czasu nie-wcześniej-niż i nie-później-niż), tier priorytetu (zazwyczaj 1–5 lub P1–P5), jednostka wnioskodawcy oraz kryteria spełnienia — co stanowi sukces zbierania. Silnik planowania odczytuje tę bazę danych jako dane wejściowe i próbuje zbudować plan zadań sensorów spełniający jak najwięcej wymagań w ramach ograniczeń dostępnej floty sensorów.

Inwentaryzacja sensorów i modelowanie zdolności

Efektywne planowanie wymaga dokładnego modelu floty sensorów w czasie rzeczywistym. System zarządzania zbieraniem utrzymuje rejestr sensorów przechowujący następujące atrybuty każdego zbieracza:

Zasięg częstotliwości. Każdy sensor ma zakres strojenia (na przykład 20 MHz do 3 GHz) oraz jednoczesną przepustowość (na przykład 40 MHz pokrycia chwilowego). Sensor nie może jednocześnie pokrywać częstotliwości wykraczających poza jego przepustowość chwilową, więc wymagania szerokopasmowe mogą wymagać kilku sensorów lub kolejnych przejść strojenia.

Zasięg pokrycia. Dla systemów kierunkowych powietrznych lub naziemnych zasięg pokrycia jest funkcją pozycji platformy, orientacji anteny i zasięgu wykrywania. Model sensora oblicza zasięg jako wielokąt, aktualizowany na bieżąco wraz z ruchem platformy. Wymaganie może być spełnione przez dany sensor tylko wtedy, gdy cel mieści się w zasięgu sensora podczas okna czasowego wymagania.

Pojemność jednoczesnych zadań. Odbiornik wielokanałowy może obsługiwać N jednoczesnych zadań. Odbiornik jednokanałowy obsługuje jedno. Model sensora śledzi liczbę dostępnych miejsc na zadania w każdym kroku czasowym. Przydzielenie nowego zadania do nasyconego sensora tworzy stan przeciążenia, który system musi wykryć i oznaczyć.

Bieżący status i stan zdrowia. Sensory raportują status operacyjny przez komunikat heartbeat lub komunikat stanu zdrowia. Sensor, który przechodzi w tryb offline, wchodzi w tryb zdegradowany lub traci łącze komunikacyjne, musi być natychmiast oznaczony jako niedostępny. Oczekujące zadania dla tego sensora wymagają ponownego zaplanowania. System musi propagować tę zmianę stanu przez plan zadań w ciągu sekund, nie minut.

Dane o pozycji platformy bezpośrednio zasilają obliczenia zasięgu pokrycia. Dla sensorów naziemno-mobilnych ślady GPS integrują się z modelem sensora. Dla platform powietrznych system zarządzania lotem dostarcza pozycję, kurs i wysokość. Zasięgi pokrycia są przeliczane w każdym cyklu aktualizacji modelu — zazwyczaj co 5 do 30 sekund, zależnie od prędkości platformy.

Algorytmy zadań i planowania

Podstawowy problem planowania to wariant planowania przedziałowego z zasobami. Każde wymaganie ma okno czasowe, w którym musi być spełnione. Każdy sensor ma zestaw przedziałów czasowych, każdy z limitem pojemności. Ograniczenia częstotliwości sprzęgają wymagania z sensorami: wymaganie dotyczące sygnału VHF nie może być przydzielone do sensora z pokryciem wyłącznie HF. Ograniczenia geograficzne dalej ograniczają, które sensory mogą pokryć które cele. Celem jest maksymalizacja łącznego ważonego priorytetowo wskaźnika spełnienia wszystkich wymagań.

Najprostsze praktyczne podejście wykorzystuje zachłanny harmonogramista oparty na priorytetach. Wymagania są sortowane według tieru priorytetu, następnie według pilności okna czasowego (wymagania z najbliższym terminem pierwsze w każdym tierze). Harmonogramista iteruje przez posortowaną listę i przydziela każde wymaganie do najlepszego dostępnego sensora — tego z najwyższym marginesem stosunku sygnału do szumu dla danego celu lub tego z największą pozostałą pojemnością jednoczesną. Działa w czasie O(R log R + R·S), gdzie R to liczba wymagań, a S to liczba sensorów, i produkuje dobre rozwiązania wystarczająco szybko dla aktualizacji w czasie rzeczywistym.

Dla dłuższych horyzontów planowania programowanie z ograniczeniami (CSP) lub mieszane całkowitoliczbowe programowanie liniowe (MILP) produkują globalnie lepsze plany. Harmonogramista MILP minimalizuje łączne niespełnione wymagania ważone priorytetem z zachowaniem: ograniczeń pojemności per sensor, ograniczeń wykonalności częstotliwości, ograniczeń pokrycia geograficznego i ograniczeń wykonalności okna czasowego. Komercyjne solvery (GLPK, HiGHS, CBC) rozwiązują instancje praktycznych rozmiarów — setki wymagań, dziesiątki sensorów — w mniej niż minutę. Zachłanny harmonogramista obsługuje aktualizacje w czasie rzeczywistym; MILP działa jako okresowa porcja wsadowa optymalizująca horyzont planowania z wyprzedzeniem.

Wykrywanie przeciążenia to wymagany podsystem. Gdy liczba przydzielonych zadań sensora przekracza jego pojemność jednoczesną lub gdy łączne obciążenie zadaniami w całej flocie pozostawia wymaganie bez możliwego przydzielenia sensor-czas, system generuje alert przeciążenia. Alert zawiera identyfikator wymagania, tier priorytetu i najwcześniejsze okno czasowe, w którym pojemność się zwolni. Menedżerowie ISR wykorzystują te informacje, aby zaakceptować lukę lub eskalować wymaganie w celu dodatkowej alokacji sensorów.

Dekonfliktowanie

Dekonfliktowanie to proces zapobiegania sytuacji, w której dwa rozkazy zadań generują sprzeczne lub redundantne zbieranie. W zarządzaniu zbieraniem SIGINT występują dwa typy konfliktów.

Dekonfliktowanie częstotliwości. Dwóch zbieraczy dostrojonych do nakładających się pasm częstotliwości w tym samym obszarze geograficznym może sobie wzajemnie przeszkadzać, szczególnie jeśli jeden jest nadajnikiem o dużej mocy lub jeśli obaj używają aktywnych technik DF w tym samym widmie. System sprawdza każdy nowy rozkaz zadania względem wszystkich aktywnych zadań pod kątem nakładania się częstotliwości w połączeniu z bliskością geograficzną. Jeśli dwa zadania mieszczą się w promieniu interferencji — będącym funkcją mocy nadawczej i wzmocnienia anteny — system oznacza konflikt i proponuje alternatywny segment częstotliwości lub przesunięcie czasowe.

Dekonfliktowanie geograficzne i celów. Dwóch zbieraczy przydzielonych do tego samego celu w tym samym oknie czasowym produkuje zbędne zbieranie. Jest to marnotrawstwo, gdy pojemność sensorów jest ograniczona. Silnik dekonfliktowania utrzymuje bazę danych zadań indeksowaną według identyfikatora celu i okna czasowego. Przed przydzieleniem drugiego sensora do celu sprawdza, czy istniejące pokrycie jest już wystarczające. Jeśli istniejące pokrycie zapewnia wystarczającą jakość sygnału i geometrię geolokalizacji, drugie przydzielenie jest blokowane, a sensor jest zwalniany dla niespełnionych wymagań.

Geometria geolokalizacji jest kluczowym czynnikiem w dekonfliktowaniu celów. Pojedynczy sensor zapewnia linię namiaru, a nie pozycję. Dwa sensory zapewniają pozycję tylko wtedy, gdy ich geometryczna baza względem celu produkuje dopuszczalne rozmycie precyzji (DOP). Silnik dekonfliktowania zatem dopuszcza — i aktywnie zaleca — przydzielenie wielu sensorów do tego samego celu, gdy dokładność geolokalizacji jest celem zbierania, o ile dwa sensory są umieszczone tak, by zapewniać odpowiednie rozdzielenie kątowe. Jest to pokrycie skoordynowane, a nie redundantne, i oba przypadki wymagają różnej obsługi w logice dekonfliktowania.

Wyniki dekonfliktowania są przechowywane jako rekord dekonfliktowania łączący identyfikatory zadań, typ konfliktu i podjęte działanie rozwiązujące. Ten dziennik zasila ścieżkę audytu architektury platformy i jest dostępny do analizy po misji.

Ponowne zlecanie zadań w czasie rzeczywistym

Plan zbierania, który nie może adaptować się w trakcie misji, jest operacyjnie bezużyteczny. Dynamiczne zdarzenia nieustannie unieważniają założenia planu: platforma docelowa zmienia pozycję, nowy emiter pojawia się w wcześniej spokojnym paśmie, sensor traci łącze komunikacyjne lub dowódca wydaje wymaganie o priorytecie błyskawicznym, które zastępuje aktualny plan.

Ponowne zlecanie zadań w czasie rzeczywistym wymaga architektury sterowanej zdarzeniami. System zarządzania zbieraniem subskrybuje strumień zdarzeń zmiany stanu z sensorów, systemów wywiadowczych i warstwy dowodzenia. Każde zdarzenie wywołuje ukierunkowaną aktualizację planu zamiast pełnego przeplanowania. Procedura aktualizacji jest następująca:

Najpierw identyfikuje się bieżące zadania, na które zdarzenie ma wpływ — zadania, których sensor jest teraz niedostępny, lub zadania, których cel przesunął się poza zasięg bieżącego sensora. Zadania te oznacza się jako oczekujące na ponowne zaplanowanie. Następnie ponownie ocenia się wymagania, których to dotyczy, względem bieżącego stanu sensora i przelicza się przydzielenia za pomocą zachłannego harmonogramisty. Na koniec generuje się rozkazy ponownego zadania dla sensorów, których to dotyczy, i przesyła je przez łącze dowodzenia. Cały cykl powinien zakończyć się w czasie poniżej dwóch sekund dla typowych rozmiarów zdarzenia.

Wymagania o priorytecie błyskawicznym — zadania P1 wydawane w odpowiedzi na zdarzenie krytyczne czasowo — wymagają wywłaszczenia. Harmonogramista porównuje wymaganie błyskawiczne z aktualnie najniższym priorytetowym aktywnym zadaniem na najlepszym kandydującym sensorze. Jeśli priorytet wymagania błyskawicznego przewyższa priorytet aktywnego zadania, aktywne zadanie jest wywłaszczane: sensor otrzymuje rozkaz zatrzymania zadania dla zadania o niższym priorytecie, zadanie wraca do kolejki niezaplanowanych, a wymaganie błyskawiczne jest natychmiast przydzielane. Właściciel wywłaszczonego zadania otrzymuje powiadomienie z powodem wywłaszczenia i najwcześniejszym oknem wznowienia.

Interfejs dowodzenia i sterowania sensorami musi obsługiwać dostarczanie zadań z małymi opóźnieniami. Rozkazy ponownego zadania wysyłane przez łącza o dużych opóźnieniach — satelitarny SATCOM z czasem podróży w obie strony 600 ms — wymagają, by harmonogramista uwzględniał opóźnienie propagacji poleceń przy obliczaniu najwcześniejszego możliwego czasu ponownego zadania sensora. Zadanie zlecone w chwili T nie może być zaplanowane do rozpoczęcia przed T plus opóźnienie propagacji plus czas przetwarzania po stronie sensora.

Metryki i sprzężenie zwrotne

System zarządzania zbieraniem, który nie mierzy własnej wydajności, nie może się poprawiać. Warstwa metryk zamyka pętlę między planowanym a wykonanym zbieraniem.

Podstawową metryką jest wskaźnik trafień zbierania: frakcja zaplanowanych zadań, które zostały wykonane i wyprodukowały użyteczny produkt wywiadowczy w oknie czasowym wymagania. Wskaźnik trafień oblicza się per tier priorytetu, per sensor, per typ celu i per okres czasu. Wskaźnik trafień P1 poniżej 90% to problem na poziomie systemu wymagający natychmiastowego zbadania. Wskaźnik trafień P4 wynoszący 60% może być akceptowalny biorąc pod uwagę ograniczoną flotę sensorów.

Analiza braków kategoryzuje każde niepowodzenie zbierania według przyczyny źródłowej. System rozróżnia między: brakami po stronie sensora (niedostępność platformy, awaria łącza, usterka mechaniczna), brakami pokrycia (cel przesunął się poza zasięg przed rozpoczęciem zbierania), brakami częstotliwości (cel nie nadawał w wymaganym paśmie podczas okna zbierania), brakami planu (wymaganie nie zostało zaplanowane z powodu ograniczeń pojemności) i brakami jakości (zbieranie miało miejsce, ale wynikowy produkt nie spełnił kryteriów satysfakcji, na przykład niewystarczająca dokładność geolokalizacji). Każda kategoria braków wymaga innego działania naprawczego.

Pętla sprzężenia zwrotnego plan-versus-wykonanie porównuje plan zadań na początku każdego okresu planowania z zapisem wykonania na końcu. Trwałe luki — wymagania, które są wielokrotnie niespełnione przez wiele cykli planowania — są oznaczane jako chroniczne niedobory i eskalowane w celu rozbudowy floty sensorów lub ponownego ustalania priorytetów wymagań. To sprzężenie zwrotne zasila również model zdolności sensora: sensor, który konsekwentnie nie trafia w cele na skraju swojego nominalnego zasięgu, ma zbyt optymistyczny model pokrycia wymagający korekty.

Efektywność zbierania — stosunek czasu, jaki sensory spędzają w aktywnym zbieraniu, do czasu bezczynności lub repozycjonowania — to drugorzędna metryka ujawniająca marnotrawstwo planowania. Sensor pozostający bezczynny, gdy wymagania są niespełnione, wskazuje na błąd planowania — albo w modelowaniu zasięgu, albo w logice dopasowywania wymagań do sensorów. Śledzenie efektywności per typ sensora ujawnia, które typy zbieraczy są przeciążone, a które mają rezerwy, informując przyszłe decyzje dotyczące struktury sił.

Metryki są najbardziej użyteczne, gdy są prezentowane jako pulpit nawigacyjny na żywo widoczny dla menedżera ISR i aktualizowany w tym samym rytmie co cykl planowania. Pulpit pokazujący wskaźnik trafień per tier priorytetu, bieżące alerty przeciążenia i procent zgodności planu daje menedżerowi ISR informacje potrzebne do podejmowania decyzji o alokacji zasobów podczas misji, a nie do odkrywania luk w przeglądzie po misji.

Jeśli budujesz lub oceniasz oprogramowanie do zarządzania zbieraniem SIGINT, najważniejsze decyzje inżynieryjne to wierność modelu sensora, opóźnienie algorytmu planowania przy dynamicznym obciążeniu oraz potok ponownego zlecania zadań sterowany zdarzeniami. Poprawne wykonanie tych trzech elementów decyduje o tym, czy system pomaga menedżerom ISR zamykać luki zbierania, czy jedynie je dokumentuje po fakcie.

Więcej o szerszej platformie, z którą integruje się zarządzanie zbieraniem, znajdziesz w naszych artykułach o komponentach platformy SIGINT i projektowaniu architektury platformy SIGINT.