Architektura dashboardu Corvus.Head: fuzja danych ISR w czasie rzeczywistym

Dane z rozpoznania, obserwacji i wywiadu (ISR) docierają do posterunku dowodzenia jednocześnie z kilkunastu kierunków. Telemetria UAV napływa przez dedykowane łącze radiowe. Sensory walki elektronicznej przekazują zdarzenia przechwytywania przez zaszyfrowany kanał TCP. Obserwatorzy artylerii zgłaszają współrzędne siatki głosowo lub za pośrednictwem komunikacji cyfrowej. Platformy SIGINT produkują wzbogacone raporty o podmiotach w nieregularnych odstępach czasu. Każde z tych źródeł ma własny format, własną częstotliwość aktualizacji i własny profil niezawodności. Wyzwaniem nie jest pozyskiwanie danych — lecz ich interpretacja w czasie wystarczającym, by informacja mogła wpłynąć na podejmowane decyzje.

Corvus.Head to dashboard wywiadu operacyjnego firmy Corvus Intelligence, zaprojektowany w celu konsolidacji dokładnie tego rodzaju wieloźródłowych danych z pola walki w jeden, ustrukturyzowany interfejs dla dowódców wojskowych, zespołów wywiadowczych i planistów operacyjnych. Niniejszy artykuł stanowi techniczny opis architektury systemu: potoku pozyskiwania danych normalizującego heterogeniczne kanały, integracji PowerBI napędzającej wizualizacje analityczne, silnika geoprzestrzennego renderującego mapy ciepła i hotspoty, warstwy prognozowania trendów oraz topologii hostingu na Azure, która utrzymuje opóźnienia w granicach tolerancji operacyjnych.

Warstwa pozyskiwania danych: normalizacja heterogenicznych kanałów sensorycznych

Pierwsza decyzja architektoniczna w każdym wieloźródłowym systemie ISR dotyczy tego, jak pochłonąć różnorodność formatów danych nadrzędnych, nie pozwalając jednocześnie, by ta różnorodność propagowała się do warstw przetwarzania i wizualizacji. Corvus.Head stosuje wzorzec adaptera źródłowego: każdy typ sensora lub kanału danych otrzymuje dedykowaną usługę adapterową, której jedynym zadaniem jest połączenie ze źródłem, parsowanie jego natywnego formatu i emitowanie znormalizowanych zdarzeń kanonicznych na wewnętrzną magistralę komunikatów.

Kanoniczny schemat zdarzeń jest celowo minimalny. Każde zdarzenie zawiera: unikalny identyfikator podmiotu, znacznik typu źródła, szerokość i długość geograficzną w dziesiętnych stopniach WGS-84, wysokość w metrach nad średnim poziomem morza (null, jeśli źródło nie raportuje wysokości), kurs i prędkość, jeśli są dostępne, etykietę klasyfikacji (przyjazny, wrogi, nieznany, neutralny, oczekujący), znacznik czasu UTC w momencie powstania zdarzenia oraz swobodny obiekt metadanych dla pól specyficznych dla źródła, które nie mapują się na schemat podstawowy. Pola, których źródło nie może dostarczyć, są ustawiane na null, a nie szacowane — fabrykowanie danych na poziomie normalizacji jest bardziej niebezpieczne niż obsługiwanie wartości null w niższych warstwach.

Adaptery łączą się ze swoimi źródłami przez gniazda TCP, subskrypcje MQTT, pętle pollingu REST lub watchery plików, w zależności od tego, co każde źródło obsługuje. Awaria połączenia jest obsługiwana w adapterze z wykładniczym opóźnieniem; niedziałający adapter nigdy nie blokuje innych adapterów ani magistrali komunikatów. Każdy adapter publikuje na swój własny nazwany temat na magistrali, dzięki czemu konsumenci na niższych poziomach mogą subskrybować selektywnie według typu źródła. Technologią magistrali jest Apache Kafka na Azure Event Hubs: semantyka grup konsumentów Kafka pozwala silnikowi fuzji, potokowi analitycznemu i silnikowi geoprzestrzennemu na niezależne konsumowanie tego samego strumienia bez koordynacji.

Integracja PowerBI: dlaczego wybrano go do dashboardów obronnych

Warstwa wizualizacji analitycznej Corvus.Head — wykresy, linie trendów, porównania okresów i rozkłady domenowe — jest zbudowana na Microsoft PowerBI Embedded działającym na Azure. Decyzja o użyciu PowerBI zamiast własnego stosu wykresów jest celowa i warta wyjaśnienia, ponieważ jest nieoczekiwana dla inżynierów kojarzących PowerBI z business intelligence, a nie z aplikacjami obronnymi.

Praktyczne uzasadnienie sprowadza się do trzech możliwości. Po pierwsze, silnik DAX PowerBI zapewnia dojrzałą, dobrze przetestowaną warstwę obliczeniową dla wyliczanych metryk: wskaźniki zdarzeń na komórkę siatki na godzinę, wyniki niezawodności źródła, procentowe zmiany okres do okresu i średnie kroczące. Replikowanie semantyki obliczeń na poziomie DAX w niestandardowym stosie wykresów JavaScript to wieloletni wysiłek inżynieryjny, który odciąga zasoby od pracy integracji sensorów, która naprawdę różnicuje platformę.

Po drugie, PowerBI Embedded obsługuje tryb DirectQuery względem Azure Synapse Analytics, co oznacza, że dashboard może odpytywać wstępnie zagregowane tabele analityczne bez ładowania surowych danych zdarzeń do przeglądarki. Utrzymuje to czasy odpowiedzi zapytań poniżej 1,5 sekundy dla 90-dniowych okien analitycznych obejmujących miliony zdarzeń — wydajność, która wymagałaby znacznych inwestycji w infrastrukturę, gdyby zastosować podejście własne.

Po trzecie, wersjonowanie modelu danych i ścieżka aktualizacji raportów PowerBI są dobrze znane menedżerom programów obronnych, którzy muszą utrzymywać raporty analityczne przez wieloletnie kontrakty. Definicja raportu PowerBI (.pbix) staje się artefaktem kontrolowanym wersją, który można aktualizować, przeglądać i zatwierdzać bez ponownego wdrażania oprogramowania platformy.

Architektura integracji używa PowerBI Embedded JavaScript SDK do renderowania raportów wewnątrz iframes w powłoce Corvus.Head. Filtry zabezpieczeń na poziomie wiersza są stosowane w czasie osadzania przy użyciu atrybutów uprawnień użytkownika z tokenu sesji, zapewniając, że raporty PowerBI pokazują tylko dane, do których przeglądający użytkownik jest upoważniony — nawet jeśli sam zestaw danych PowerBI zawiera pełny korpus.

Silnik geoprzestrzenny: mapy ciepła, hotspoty i gęstość zdarzeń

Warstwa wyświetlania geoprzestrzennego służy innemu celowi niż wykresy analityczne. Podczas gdy PowerBI pokazuje zagregowane wzorce w czasie, warstwa mapy pokazuje, co dzieje się teraz i gdzie aktywność skoncentrowała się w ostatnim okresie obserwacji. Corvus.Head renderuje trzy typy nakładek geoprzestrzennych na warstwie mapy bazowej: ślady pozycji podmiotów (aktualizowane przez push WebSocket), mapy ciepła gęstości zdarzeń i dyskretne markery hotspotów.

Mapy ciepła gęstości zdarzeń są obliczane po stronie serwera przy użyciu siatki hasha przestrzennego z konfigurowalnym rozmiarem komórki (domyślnie 500 metrów). Każde zdarzenie napływające przez potok pozyskiwania zwiększa wynik gęstości komórki zawierającej jego lokalizację, ważone funkcją zaniku aktualności — zdarzenia starsze niż sześć godzin wnoszą wykładniczo mniej do wyniku komórki. Zanik zapobiega trwałemu wypaczaniu mapy ciepła przez historyczną aktywność i zapewnia, że wizualizacja odzwierciedla aktualny obraz operacyjny, a nie skumulowany historyczny.

Siatka mapy ciepła jest przeliczana zgodnie z konfigurowalnym harmonogramem (domyślnie co 60 sekund) i wypychana do klientów jako GeoJSON FeatureCollection wielokątów komórek z atrybutami gęstości. Przeglądarka renderuje to przy użyciu warstwy mapy WebGL z pięciopunktową rampą kolorów od ciemnoniebieskiego (niska gęstość) przez bursztynowy do czerwonego (wysoka gęstość). Operatorzy mogą stosować filtry domenowe — pokazując tylko zdarzenia EW lub tylko obserwacje UAV — co wyzwala przeliczenie siatki po stronie serwera z filtrowaniem do wybranych typów źródeł. Pozwala to uniknąć pełnego ponownego renderowania bazowej geometrii mapy po stronie przeglądarki.

Markery hotspotów to dyskretne punkty generowane automatycznie, gdy skupisko zdarzeń w jednej komórce siatki przekracza konfigurowalny próg w przesuwającym się oknie czasowym. Detektor hotspotów działa jako oddzielny mikroserwis subskrybujący kanoniczną magistralę zdarzeń i oceniający wariant algorytmu DBSCAN w kroczącym 30-minutowym oknie zdarzeń. Gdy skupisko przekroczy próg, rekord hotspotu jest zapisywany do bazy danych i rozgłaszany do podłączonych klientów dashboardu przez kanał push WebSocket. Hotspoty wygasają automatycznie, gdy aktywność skupiska spada poniżej progu przez trwały okres.

Prognozowanie trendów: okresy dzienne, tygodniowe i miesięczne

Prognozowanie trendów daje dowódcom ilościową podstawę do przewidywania tempa operacyjnego, zamiast reagowania na nie. Corvus.Head udostępnia prognozy aktywności zdarzeń dla trzech okresów — dziennego, tygodniowego i miesięcznego — obliczane przy użyciu modelu dekompozycji sezonowej stosowanego do danych szeregów czasowych per komórka.

Potok prognozowania działa na Azure Databricks zgodnie z harmonogramem (co godzinę dla prognoz dziennych, nocnie dla tygodniowych i miesięcznych). Pobiera ostatnie 90 dni liczby zdarzeń zagregowanych per komórka siatki per kosz czasowy z Azure Synapse, stosuje dekompozycję STL (Seasonal-Trend decomposition using LOESS) w celu wyodrębnienia komponentów sezonowych i trendowych oraz generuje prognozy z przedziałami ufności obliczonymi z wariancji residualnej. Wyniki są zapisywane z powrotem do Synapse jako wstępnie obliczone kolumny prognoz, które PowerBI może odpytywać przez DirectQuery bez uruchamiania dekompozycji na żywo.

Decyzja o wstępnym obliczaniu zamiast obliczania na żądanie jest celowa. Dekompozycja STL dla 90 dni danych w tysiącach komórek siatki jest kosztowna obliczeniowo — uruchamianie jej na żądanie w odpowiedzi na zapytanie dashboardu powodowałoby niedopuszczalne opóźnienia. Wstępne obliczenie przenosi koszt na zaplanowane zadanie wsadowe i utrzymuje czasy odpowiedzi dashboardu poniżej 1,5 sekundy dla każdego zapytania prognostycznego, które użytkownik może wydać.

Architektura filtrowania: analiza domenowa i czasowa

Dashboard pokazujący wszystko jest tak samo bezużyteczny operacyjnie jak dashboard niepokazujący nic. Architektura filtrowania decyduje o tym, czy dowódcy mogą szybko wyizolować sygnał istotny dla bieżącej decyzji z otaczającego szumu pełnego obrazu wieloźródłowego.

Corvus.Head implementuje filtrowanie wzdłuż dwóch osi: domeny (typ źródła lub klasyfikacja podmiotu) i przedziału czasowego (ostatnia godzina, ostatnie 6 godzin, ostatnie 24 godziny, ostatnie 7 dni lub zakres niestandardowy). Filtry są stosowane na trzech warstwach: warstwie zapytań API (która pobiera z Synapse tylko pasujące zdarzenia), warstwie subskrypcji magistrali komunikatów (która subskrybuje tylko tematy typów źródeł istotnych dla transmisji na żywo WebSocket) oraz warstwie raportu PowerBI (która stosuje kontekst filtrowania DAX do wszystkich miar). To trójwarstwowe podejście zapewnia, że zmiany filtrów są spójnie odzwierciedlane we wszystkich komponentach wizualnych bez konieczności przetwarzania pełnego zestawu danych po stronie przeglądarki.

Stan filtra jest utrzymywany w powłoce dashboardu jako obiekt stanu serializowalny do URL, pozwalający dowódcom na dodanie do zakładek i udostępnienie określonych przefiltrowanych widoków swojemu sztabowi. Oficer wywiadu brygady może wysłać podwładnym określony przefiltrowany widok — zdarzenia EW, ostatnie 6 godzin, sektor północny — jako URL, a odbiorcy widzą identyczny przefiltrowany widok po otwarciu łącza.

Topologia hostingu na Azure i kwestie opóźnień

Corvus.Head jest hostowany na Azure Government Cloud (Azure for Government w USA, równoważne regiony sovereign cloud dla krajów partnerskich). Topologia hostingu jest zaprojektowana wokół trzech budżetów opóźnień: quasi-rzeczywistego dla aktualizacji pozycji podmiotów (cel: poniżej 3 sekund end-to-end), czasu odpowiedzi na zapytania analityczne (cel: poniżej 1,5 sekundy dla wstępnie zagregowanych zapytań) i dostarczania kafelków mapy (cel: poniżej 500ms dla kafelków buforowanych).

Adaptery pozyskiwania i magistrala komunikatów (Azure Event Hubs w trybie kompatybilnym z Kafka) działają w tym samym regionie Azure co sklasyfikowane źródła danych, minimalizując skok sieciowy między systemami sensorów a warstwą normalizacji. Silnik fuzji i brama WebSocket są wdrożone jako obciążenia Azure Kubernetes Service w tym samym regionie. Pojemność PowerBI Embedded i obszar roboczy Azure Synapse Analytics są aprowizowane w tym samym regionie, aby uniknąć opóźnień transferu danych między regionami przy wywołaniach DirectQuery.

Dostarczanie kafelków mapy używa Azure Blob Storage z akceleracją Azure CDN dla nieklasyfikowanych kafelków warstwy bazowej. Sklasyfikowane kafelki nakładek — warstwy adnotacji wywiadowczych, nakładki rozmieszczenia sił własnych — są serwowane z dedykowanego serwera kafelków wewnątrz bezpiecznego perimetru, który nie korzysta z CDN. Cele czasu odpowiedzi serwera kafelków są egzekwowane przez monitor kondycji, który alarmuje zespół operacyjny, jeśli dostawa kafelków p95 przekroczy 800ms.

W konfiguracjach wdrożenia polowego, gdzie łączność z Azure jest niedostępna lub zawodna, Corvus.Head obsługuje konteneryzowany tryb wdrożenia na jednym serwerze przy użyciu Docker Compose. W tym trybie pełny stos — adaptery pozyskiwania, silnik fuzji, serwer kafelków, lokalny broker Kafka i baza danych PostgreSQL zastępująca Synapse — działa na utwardzonym serwerze w sieci taktycznej. PowerBI jest zastąpiony lekkim silnikiem analitycznym korzystającym z gotowych specyfikacji wykresów Vega-Lite opartych na lokalnym REST API. Profil opóźnień znacząco się zmienia w tym trybie: bez zarządzanych usług Azure zespół operacyjny jest odpowiedzialny za monitorowanie i skalowanie lokalnej infrastruktury, a niektóre funkcje analityczne z 90-dniową głębokością historyczną są ograniczone do 30-dniowej lokalnej pamięci podręcznej.

Krok po kroku: integracja nowego źródła danych z Corvus.Head

Architektura adapterowa sprawia, że wdrożenie nowych typów sensorów staje się powtarzalnym procesem inżynieryjnym, a nie każdorazowo odrębnym projektem integracyjnym. Poniższe kroki opisują standardową ścieżkę integracji.

Krok 1 — Zdefiniuj schemat źródła i częstotliwość aktualizacji. Udokumentuj format danych (CoT XML, JSON, protokół binarny), oczekiwany wskaźnik aktualizacji w komunikatach na sekundę oraz autorytatywne nazwy pól dla pozycji, czasu, typu podmiotu i klasyfikacji. Ta definicja schematu staje się kontraktem dla adaptera.

Krok 2 — Zaimplementuj adapter pozyskiwania danych. Napisz specyficzny dla źródła adapter, który łączy się z kanałem i emituje znormalizowane zdarzenia kanoniczne na magistralę komunikatów. Adapter obsługuje ponowne próby połączenia, ponowne składanie częściowych komunikatów i uwierzytelnianie specyficzne dla źródła. Nie może nigdy blokować magistrali w przypadku awarii połączenia.

Krok 3 — Mapuj pola na kanoniczny schemat zdarzeń. Przekształć każdy przychodzący komunikat do kanonicznego formatu zdarzeń Corvus.Head. Pola, które nie mapują się, są odrzucane na poziomie adaptera. Pola, których źródło nie może dostarczyć, są ustawiane na null, a nie wymyślane.

Krok 4 — Skonfiguruj reguły asocjacji silnika fuzji. Dodaj nowy typ źródła do tabeli reguł asocjacji silnika fuzji. Określ próg zbliżenia przestrzennego i okno czasowe używane do kojarzenia raportów z tego źródła z istniejącymi śladami oraz ustaw wagę dokładności źródła dla estymatora pozycji.

Krok 5 — Zarejestruj źródło w modelu danych PowerBI. Dodaj nowy typ źródła jako wartość wymiaru w tabeli SourceType. Sprawdź, czy istniejące filtry i miary DAX obsługują nową wartość bez psucia istniejących raportów.

Krok 6 — Waliduj opóźnienia i przepustowość w środowisku testowym. Uruchom adapter na powtórce historycznych danych źródłowych z prędkością 2x czasu rzeczywistego. Zmierz opóźnienie end-to-end od odbioru komunikatu do wyświetlenia na dashboardzie. Potwierdź, że opóźnienie p99 pozostaje poniżej 3 sekund i że głębokość kolejki magistrali komunikatów nie rośnie nieograniczenie pod stałym obciążeniem.

Krok 7 — Włącz i monitoruj na produkcji. Wdróż adapter z kontrolą feature-flag, aby można go było wyłączyć bez cofania wdrożenia w razie problemów. Monitoruj kolejkę dead-letter, wskaźnik zdarzeń na źródło oraz wskaźnik asocjacji śladów do raportów silnika fuzji. Spadek wskaźnika asocjacji poniżej 80% zwykle wskazuje na niezgodność schematu wprowadzoną przez aktualizację firmware'u źródła.

Najczęściej zadawane pytania