Potok wczytywania obrazów satelitarnych dla obronności: od surowej sceny do zleconej analizy

Scena satelitarna to nie wywiad. To surowe dane: skompresowany raster wartości pikseli zakodowany w zastrzeżonym formacie, oznaczony układem odniesienia współrzędnych, dołączony do pliku telemetrii sensora i opakowany w kontener klauzuli niejawności, który decyduje o tym, kto może go dotknąć. Pomiędzy tą surową dostawą a analitykiem celowania otrzymującym na swojej stacji roboczej użyteczny ortorektyfikowany obraz leży potok wczytywania: seria zautomatyzowanych etapów przetwarzania, które większość programów GEOINT niedocenia, dopóki nie zawiedzie o 02:00 przy pilnym wymaganiu zbiórki. Ten artykuł rozkłada na czynniki pierwsze każdy etap obronnego potoku wczytywania obrazów satelitarnych: jak zlecanie scen łączy się z API operatorów satelitarnych oraz systemami żądań krajowych środków technicznych (NTM), co stos wstępnego przetwarzania robi z surowymi obrazami, zanim trafią one do katalogu, dlaczego wybory formatów mają znaczenie operacyjne, jak katalogi przestrzenne umożliwiają szybkie pobieranie scen z milionów zarchiwizowanych scen oraz jak logika kierowania łączy nowo wczytane obrazy z narzędziami eksploatacji i kolejkami analityków, które ich potrzebują.

Potok obrazów satelitarnych: zakres i wymagania operacyjne

Obronny potok wczytywania obrazów obejmuje trzy domeny funkcjonalne: pozyskiwanie (sprowadzenie sceny z satelity lub od dostawcy do potoku), przetwarzanie (przekształcenie surowej sceny w skalibrowany, georeferencjowany, skatalogowany produkt) oraz kierowanie do eksploatacji (dostarczenie właściwej sceny do właściwego narzędzia lub analityka we właściwym czasie). Każda domena ma odrębne wymagania dotyczące opóźnienia, przepustowości i niezawodności, które kształtują wybory architektoniczne. Dla rutynowej zbiórki wspierającej długocyklową produkcję wywiadowczą akceptowalne jest opóźnienie typu „od końca do końca” od pozyskania sceny do dostępności w katalogu rzędu kilku godzin. Dla wymagań wywiadu wrażliwego na czas (TSI): oceny szkód bojowych, śledzenia sił czy dynamicznego celowania, ten sam potok musi skompresować to opóźnienie do poniżej 30 minut, a w niektórych architekturach do poniżej 10.

Wymagania operacyjne narzucają ograniczenia, z którymi komercyjne potoki obrazów się nie mierzą. Obsługa klauzul niejawności oznacza, że sceny o różnych poziomach bezpieczeństwa nie mogą współdzielić infrastruktury przetwarzania bez akredytacji albo muszą być przetwarzane w odizolowanych enklawach ze ścisłą kontrolą transferu danych między poziomami. Rejestrowanie łańcucha nadzoru, dokumentujące, kto zamówił zbiórkę, jakie algorytmy przetwarzania zastosowano, który analityk otrzymał produkt i jakie działania eksploatacyjne podjęto, jest obowiązkowe dla gotowego wywiadu o odpowiedzialności prawnej i operacyjnej. Wymagania dostępności dla potoków obrazów wspierających aktywne operacje są zazwyczaj wyższe niż dla systemów produkcyjnych czasu pokoju, co wymaga redundantnych węzłów przetwarzania, automatycznego przełączania awaryjnego oraz planów pracy w trybie zdegradowanym na wypadek niedostępności głównej komercyjnej ścieżki łącza zniżkowego lub chmurowego środowiska przetwarzania.

Potok musi być również z założenia wieloźródłowy. Teatr działań obronnych nie polega na jednej konstelacji satelitarnej. Dostawcy komercyjni (Maxar WorldView Legion, Planet SuperDoves, Airbus Pleiades Neo, Satellogic), dostawcy radaru z syntetyczną aperturą (SAR) (Capella Space, ICEYE, Umbra) oraz obrazy koalicyjne lub NTM docierają różnymi mechanizmami dostawy, z różnymi konwencjami formatów, schematami metadanych i ograniczeniami licencyjnymi. Potok wczytywania abstrahuje te różnice za wspólnym schematem wewnętrznym, tak aby narzędzia przetwarzania, katalogowania i eksploatacji poniżej operowały na znormalizowanej reprezentacji niezależnie od źródła.

Zamawianie i zlecanie scen: integracja z API operatorów satelitarnych i systemami żądań NTM

Zlecanie satelity zaczyna się od wymagania: geograficznego obszaru zainteresowania (AOI), okna zbiórki, wymagania rozdzielczości oraz priorytetu wywiadowczego. W organizacji obronnej wymagania są sformalizowane jako wymagania stałe (STANREQ) lub doraźne rozkazy zadań zarządzane w systemie śledzenia wymagań. Moduł zlecania potoku wczytywania odczytuje aktywne wymagania i tłumaczy je na zamówienia zbiórki przesyłane do każdego odpowiedniego operatora satelitarnego lub brokera NTM. Dla dostawców komercyjnych oznacza to wywołanie zlecającego REST API: przesłanie wielokąta AOI, okna zbiórki, specyfikacji poziomu produktu oraz poświadczeń uwierzytelniających. API Maxar SecureWatch, Planet Orders API oraz Airbus Intelligence Access API podążają za szeroko podobnymi wzorcami: POST zamówienia, odpytywanie o status oraz pobranie pakietu sceny z podpisanego URL, gdy zbiórka zostanie potwierdzona.

Integracja NTM podąża za odmiennym wzorcem rządzonym przez niejawne protokoły żądań. Zamiast komercyjnego REST API żądania NTM przepływają przez kontrolowane systemy dystrybucji, używając formatów komunikatów takich jak STANAG 4559 (standard NATO dla żądania i dostawy obrazów) lub protokołów specyficznych dla wspólnoty wywiadowczej USA. Moduł interfejsu NTM potoku wczytywania obsługuje uwierzytelnianie wobec odpowiedniego systemu brokerskiego, przesyła żądania w wymaganym schemacie, monitoruje powiadomienia o dostawie i pobiera pakiety scen przez autoryzowaną ścieżkę transferu. Kluczową zasadą architektoniczną jest to, że zlecanie NTM i komercyjne muszą być obsługiwane przez oddzielne moduły interfejsu z odizolowanymi magazynami poświadczeń, nawet jeśli zasilają tę samą kolejkę przetwarzania poniżej, ponieważ ich wymagania dotyczące klauzul niejawności, obsługi i audytu się różnią.

Zarządzanie zamówieniami wymaga lokalnej maszyny stanów do śledzenia cyklu życia każdego żądania zbiórki: przesłane, potwierdzone przez dostawcę, zebrane (przelot satelity nastąpił), przesłane łączem zniżkowym, przetworzone przez dostawcę oraz dostarczone do punktu końcowego wczytywania potoku. Awarie przetwarzania po stronie dostawcy, zachmurzenie w czasie zbiórki oraz konflikty zlecania satelity wymagają logiki obsługi: zmiany harmonogramu, eskalacji do alternatywnego dostawcy o wyższym priorytecie lub oznaczenia wymagania jako niezrealizowanego do ręcznego przeglądu. Moduł zlecania powinien utrzymywać historyczny rejestr wszystkich żądań i wyników, aby wspierać raportowanie skuteczności zbiórki oraz analizę wydajności dostawców.

Wstępne przetwarzanie surowych obrazów: ortorektyfikacja, korekcja atmosferyczna i maskowanie chmur

Scena dostarczona przez dostawcę komercyjnego na poziomie 1B (skorygowana radiometrycznie, geometria sensora) nie jest gotowa do eksploatacji ani katalogowania w obronnym systemie obrazów. Zanim trafi do katalogu przestrzennego, musi zostać poddana ortorektyfikacji: skorygowana geometrycznie w celu usunięcia błędów orientacji sensora i przemieszczeń terenowych, oraz znormalizowana radiometrycznie do spójnej skali współczynnika odbicia powierzchni. Te kroki nie są opcjonalnymi udoskonaleniami; są warunkami koniecznymi dla nakładania obrazów na mapy wektorowe, wykonywania wykrywania zmian względem wcześniejszych zbiórek oraz mierzenia obiektów z dokładnością wystarczającą do celów wywiadu wojskowego.

Ortorektyfikacja wykorzystuje wymierne współczynniki wielomianowe (RPC) dołączone do sceny oraz numeryczny model wysokościowy (DEM) do rzutowania każdego piksela z geometrii sensora na odwzorowanie mapowe. SRTM 1-arc-second (około 30 m rozdzielczości poziomej) jest bazowym DEM dla większości potoków na poziomie teatru; dla zbiórek o wysokiej rozdzielczości (0,3–0,5 m odległości próbkowania na gruncie), gdzie liczy się submetrowa dokładność geolokalizacji, wymagany jest wysokorozdzielczy DEM specyficzny dla teatru, wyprowadzony ze stereoskopowych zbiórek satelitarnych lub lotniczego lidaru. Model oparty na RPC osiąga 3–8 m błędu kołowego prawdopodobnego (CEP) bez kontroli naziemnej; dodanie rzadkiego zestawu naziemnych punktów kontrolnych (GCP) zmierzonych GPS w celu udoskonalenia rozwiązania RPC poprawia dokładność do 1–2 m CEP dla produktów przetworzonych. Dla misji, w których absolutna dokładność geolokalizacji jest krytyczna, na przykład pomiarów współrzędnych celu, potok musi integrować bazę GCP i automatycznie stosować krok udoskonalenia RPC.

Korekcja atmosferyczna konwertuje radiancję na szczycie atmosfery (TOA) na współczynnik odbicia powierzchni, usuwając efekty rozpraszania molekularnego, absorpcji aerozoli oraz geometrii oświetlenia słonecznego. Ten krok jest niezbędny dla multispektralnego wykrywania zmian: dwie sceny zebrane w różnych warunkach atmosferycznych wykażą pozorne różnice radiometryczne w każdym paśmie, nawet jeśli powierzchnia gruntu się nie zmieniła, generując fałszywe alarmy. Modele transferu radiacyjnego, takie jak MODTRAN lub 6S, obliczają współczynniki korekcji na podstawie parametrów atmosferycznych (grubość optyczna aerozoli, para wodna, kolumna ozonu) uzyskanych z koincydentnych odczytów MODIS lub pól analizy modelu. Maskowanie chmur i cieni chmur wykorzystuje algorytm oceny jakości (FMask, S2cloudless lub wytrenowaną CNN) do oznaczenia każdego piksela jako czysty, chmura, cień lub śnieg/lód. Maska chmur jest przechowywana jako pasmo towarzyszące obok przetworzonej sceny i propaguje się przez całe przetwarzanie poniżej: na przykład algorytmy wykrywania zmian muszą wykluczać piksele zamaskowane jako chmury ze swoich statystyk.

Krajobraz formatów: NITF, GeoTIFF, JPEG 2000 i ich obronne przypadki użycia

Obronne potoki obrazów muszą zarządzać wieloma współistniejącymi formatami, ponieważ żaden pojedynczy format nie zaspokaja wszystkich przypadków użycia w organizacji obronnej. NITF 2.1 (National Imagery Transmission Format) jest autorytatywnym kontenerem dla obrazów wywiadowczych w systemach USA i sojuszniczych. Niesie dane obrazu obok strukturalnych pól metadanych, których żaden inny format nie wspiera natywnie: oznaczenia klauzul niejawności i obsługi bezpieczeństwa w nagłówku pliku, techniczne rekordy rozszerzeń PIAIMC (Profile for Imagery Access) opisujące parametry sensora i geometrię zbiórki, SENSRB (Sensor Data Records) dla precyzyjnej telemetrii sensora oraz współrzędne narożników IGEOLO i informacje o odwzorowaniu mapowym. Struktura NITF pozwala również na wiele segmentów obrazu w jednym pliku, umożliwiając współistnienie pasma panchromatycznego, stosu multispektralnego oraz produktu pan-sharpening w jednym kontenerze ze wspólnym nagłówkiem metadanych.

GeoTIFF, a konkretnie Cloud-Optimized GeoTIFF (COG), jest formatem roboczym dla wizualizacji webowej, warstw wizualizacji platformy GEOINT oraz przepływów pracy przetwarzania AI/ML. Pliki COG organizują wewnętrzną strukturę kafelków i przeglądów, tak aby żądania zakresu HTTP mogły pobrać tylko fragment obrazu widoczny przy bieżącym poziomie powiększenia mapy, umożliwiając usłudze map webowych strumieniowanie obrazów z pamięci obiektowej bez wstępnego generowania piramid kafelków. Dla wnioskowania modeli AI: wykrywania zmian, wykrywania obiektów, ekstrakcji cech, GeoTIFF z metadanymi czytelnymi dla GDAL jest standardowym formatem wejściowym dla geoprzestrzennych frameworków ML opartych na Pythonie. Potok generuje pochodne COG z wzorca NITF jako równoległy krok wyjściowy, zapisując je do warstwy pamięci obiektowej dostępnej dla usług webowych i węzłów wnioskowania ML.

JPEG 2000 zajmuje specyficzną niszę w obrazach obronnych: jest formatem kompresji osadzonym wewnątrz plików NITF dla produktów o wysokiej rozdzielczości, gdzie wymagana jest kompresja bezstratna lub wizualnie bezstratna w stosunkach od 4:1 do 8:1, i jest formatem używanym w wielu starszych sojuszniczych standardach wymiany obrazów. Kompresja JPEG 2000 oparta na falkach przewyższa JPEG przy wysokich stosunkach kompresji, zachowując jednocześnie drobnoszczegółowe cechy krytyczne dla eksploatacji (identyfikacja pojazdów, analiza obiektów, rozpoznawanie wzorców aktywności). Potok powinien być w stanie odczytywać i zapisywać strumienie JPEG 2000 zarówno jako pliki samodzielne, jak i jako dane segmentu obrazu wewnątrz kontenerów NITF, używając zgodnej biblioteki takiej jak OpenJPEG lub Kakadu. Dla obronnych potoków fuzji danych obsługujących wieloźródłowe obrazy normalizacja wszystkich źródeł do spójnego formatu wewnętrznego przed indeksowaniem katalogu eliminuje obsługę specyficzną dla formatu w narzędziach poniżej.

Indeksowanie katalogu: indeksowanie przestrzenne i czasowe dla szybkiego pobierania scen

Katalog przestrzenny jest pamięcią operacyjną potoku obrazów. Każda przetworzona scena musi być zaindeksowana, zanim stanie się użyteczna: ortorektyfikowany NITF leżący w pamięci obiektowej, o którym żaden katalog nie wie, jest faktycznie niewidoczny dla analityków i narzędzi eksploatacji. Specyfikacja SpatioTemporal Asset Catalog (STAC) stała się standardowym schematem dla obronnych i komercyjnych katalogów obrazów, ponieważ definiuje wspólną strukturę JSON dla metadanych sceny: geometrię zasięgu, datę i czas pozyskania, identyfikatory sensora i platformy, opisy pasm, odnośniki do zasobów, czytelną dla rosnącego ekosystemu klientów katalogu, API wyszukiwania i narzędzi wizualizacji bez prac integracyjnych na zamówienie.

W ramach STAC API baza danych PostgreSQL oparta na PostGIS przechowuje rekordy Item i ich geometrie zasięgu GeoJSON. Zapytania przestrzenne: „wszystkie sceny przecinające ten wielokąt, zebrane w ostatnich 14 dniach, z zachmurzeniem poniżej 15%, o rozdzielczości 0,5 m lub lepszej”, wykonują się jako zapytania o przecięcie przestrzenne PostGIS z indeksami złożonymi na kolumnie geometrii zasięgu, kolumnie daty i czasu pozyskania oraz numerycznych polach zachmurzenia i rozdzielczości. Dla katalogu zawierającego 10 milionów rekordów scen ta struktura zapytania zwraca wyniki w poniżej 500 ms, jeśli indeksy są utrzymywane, a plany zapytań zoptymalizowane. Krok indeksowania potoku wstawia każdy nowy rekord STAC Item natychmiast po zapisaniu NITF i zwalidowaniu jego metadanych, tak aby scena była przeszukiwalna w ciągu sekund od zakończenia przetwarzania.

Indeksowanie czasowe ma takie samo znaczenie jak indeksowanie przestrzenne dla przepływów pracy wykrywania zmian. Analitycy i usługi zautomatyzowane często odpytują o „wszystkie wcześniejsze zbiórki tego AOI”, aby ustanowić bazowy obraz dla wykrywania zmian lub analizy wzorców aktywności. Indeks na kolumnie daty i czasu pozyskania ze strukturą B-drzewa wspiera zapytania zakresowe (wszystkie zbiórki między datą A a datą B) wydajnie, lecz najużyteczniejszy wzorzec dostępu czasowego: „wszystkie sceny przecinające zasięg X, uporządkowane według daty pozyskania”, wymaga łącznego zapytania przestrzenno-czasowego, które korzysta z indeksu pokrywającego łączącego kolumny geometrii i daty/czasu. Te same zasady indeksowania przestrzennego stosowane w potokach normalizacji danych sensorów mają zastosowanie tutaj: schemat musi być zaprojektowany pod wzorce zapytań, które narzędzia eksploatacji faktycznie wydają, a nie wyłącznie pod normalizację schematu.

Kierowanie do eksploatacji: kolejkowanie obrazów do odpowiednich narzędzi analitycznych i stacji roboczych analityków

Nowo skatalogowana scena jest kandydatem do dostarczenia do wielu odbiorców poniżej jednocześnie: zautomatyzowanej usługi wykrywania zmian, modelu wykrywania obiektów opartego na AI, ludzkiego analityka obrazów oraz systemu generowania raportów. Silnik kierowania jest komponentem, który dopasowuje każdą nową scenę do zarejestrowanych wymagań i ustala, którzy odbiorcy ją otrzymują, w jakiej kolejności priorytetowej i jakim mechanizmem dostawy. Model kierowania używany w większości obronnych systemów obrazów opiera się na subskrypcjach nazwanego obszaru zainteresowania (NAI) połączonych z wymaganiami stałymi (STANREQ), które określają kryteria filtrowania: minimalną rozdzielczość, maksymalne zachmurzenie, okno daty zbiórki, typ sensora, oraz system docelowy lub kolejkę analityka.

Gdy krok indeksowania zapisuje nowy STAC Item, silnik kierowania ocenia go względem wszystkich aktywnych subskrypcji. Subskrypcje są implementowane jako zapytania przestrzenne względem biblioteki wielokątów NAI: jeśli zasięg sceny przecina zarejestrowane NAI, silnik stosuje kryteria filtrowania subskrypcji. Scena, która przechodzi wszystkie kryteria, generuje powiadomienie o dostawie do wskazanego celu. Dla usług eksploatacji AI powiadomienie niesie URI pamięci masowej NITF sceny i jest publikowane do kolejki roboczej (RabbitMQ, AWS SQS lub równoważnego brokera komunikatów) konsumowanej przez procesy robocze usługi. Dla stacji roboczych analityków powiadomienie aktualizuje kolejkę zadań analityka w systemie eksploatacji obrazów (SOCET GXP, RemoteView lub FADE/MIST) nowym rekordem zadania wskazującym na scenę. Dla wymagań wywiadu krytycznego czasowo silnik kierowania stosuje wzmocnienie priorytetu, które wyprzedza elementy o niższym priorytecie już znajdujące się w kolejce eksploatacji.

Kierowanie międzyklauzulowe wymaga szczególnej staranności. Scena zebrana na wyższym poziomie klauzuli niejawności niż bazowa akredytacja analityka nie może być kierowana do jego standardowej kolejki stacji roboczej; musi być kierowana do stacji roboczej w odpowiednio akredytowanej enklawie. Silnik kierowania musi odpytać rekord poświadczenia bezpieczeństwa i akredytacji analityka w systemie zarządzania tożsamością przed wysłaniem jakiegokolwiek powiadomienia o dostawie. Zautomatyzowane usługi AI, które przetwarzają obrazy na wielu poziomach klauzul niejawności, muszą być akredytowane na najwyższym poziomie danych, które przetwarzają, a ich produkty wyjściowe muszą nosić oznaczenia klauzul niejawności źródłowych obrazów, które skonsumowały. Projektanci potoków, którzy odkładają te kontrole na „dodanie później”, niezmiennie odkrywają, że dopasowanie kierowania świadomego klauzul niejawności do istniejącej architektury przekazywania komunikatów jest droższe i bardziej uciążliwe niż wbudowanie go od samego początku.

Wydajność potoku: przepustowość, opóźnienie i wymagania pamięci masowej w skali operacyjnej

Średniej skali obronny potok obrazów wspierający jeden teatr działań przetwarza zazwyczaj 50–150 scen satelitarnych dziennie z wielu źródeł komercyjnych i rządowych. Przy rozdzielczości 0,5 m standardowy komercyjny pas zbiórki obejmuje 15–30 km szerokości i 100–200 km długości, produkując ortorektyfikowane sceny po 1–4 GB każda jako GeoTIFF i 2–8 GB jako nieskompresowany NITF. Dzienny wolumen wczytywania w tej skali wynosi 150–600 GB nowych danych scen, plus półprodukty wstępnego przetwarzania, które mogą podwoić lub potroić wymaganą pamięć roboczą podczas aktywnego przetwarzania. Wysokorozdzielcza fala dla całego teatru: kompleksowe pokrycie dużego spornego obszaru, może podnieść dzienne wolumeny wczytywania do kilku terabajtów, wymagając klastrów wstępnego przetwarzania skalujących się horyzontalnie, aby spełnić SLA opóźnienia.

Opóźnienie przetwarzania jest ograniczeniem wydajności, które najbardziej bezpośrednio wpływa na użyteczność operacyjną. Dla przepływów pracy TSI celem jest poniżej 30 minut od dostawy sceny do dostępności w katalogu; dla rutynowej produkcji akceptowalne jest poniżej 4 godzin. Krok ortorektyfikacji jest najbardziej intensywnym obliczeniowo etapem: scena panchromatyczna o pełnej rozdzielczości 0,3 m z udoskonaleniem RPC i rzutowaniem DEM zajmuje 5–20 minut na pojedynczym nowoczesnym węźle obliczeniowym. Zrównoleglenie po kafelkach sceny oraz równoczesne uruchamianie wielu scen na klastrze 8–16 węzłów osiąga cele opóźnienia TSI dla typowych wolumenów scen. Korekcja atmosferyczna jest obliczeniowo lżejsza (1–3 minuty na scenę), ale wymaga dostępu do koincydentnych danych parametrów atmosferycznych z analizy modelu NWP lub satelitarnych produktów aerozolowych, co wprowadza zależność danych, która może opóźnić przetwarzanie, jeśli pomocniczy potok danych nie jest wstępnie wypełniony.

Architektura pamięci masowej podąża za wielowarstwowym modelem dostępu dopasowanym do wzorców eksploatacji. Aktywna pamięć robocza (blokowa oparta na NVMe lub wysokowydajna pamięć obiektowa) przechowuje najnowsze 30–60 dni ortorektyfikowanych scen w pełnej rozdzielczości, wspierając zapytania katalogu poniżej sekundy i szybkie pobieranie scen do aktywnej eksploatacji. Warstwa aktywnego archiwum 6–18 miesięcy używa pamięci obiektowej (zgodnej z S3) z opóźnieniem pobierania od sekund do minut, adekwatnym dla analizy historycznej i baz wykrywania zmian. Długoterminowe przechowywanie powyżej 18 miesięcy przenosi się do zimnej pamięci obiektowej lub taśmy, z opóźnieniem pobierania rzędu godzin: akceptowalnym dla obowiązków rejestru historycznego, ale nie dla aktywnej eksploatacji. Baza katalogu STAC zawsze przechowuje kompletne metadane dla wszystkich warstw; URI pamięci masowej w każdym rekordzie katalogu wskazuje na odpowiednią warstwę, a warstwa pobierania obsługuje dostęp niewidoczny dla warstw, tak aby narzędzia eksploatacji nie musiały wiedzieć, w której warstwie pamięci masowej znajduje się żądana scena.