Pulpit dowodzenia i kontroli (C2) to nie narzędzie Business Intelligence z militarnym wyglądem. Decyzje architektoniczne, które decydują o odpowiedniej wydajności pulpitu BI — interwały odpytywania, cykle odświeżania strony, synchroniczne wywołania API — są dokładnie tymi decyzjami, które spowodują awarię obronnego pulpitu C2 w warunkach polowych. Model zagrożeń, środowisko sieciowe i stawki operacyjne są fundamentalnie inne.

Artykuł obejmuje główne decyzje architektoniczne, z jakimi styka się zespół deweloperski przy budowie pulpitu C2 do zastosowań obronnych: jak podzielić frontend od backendu, jak pozyskiwać dane w czasie rzeczywistym bez przeciążania interfejsu, jaką technologię renderowania map wybrać, jak strukturyzować kontrolę dostępu opartą na rolach dla różnych szczebli dowodzenia oraz jak utrzymać wydajność przy tysiącach śladów.

Podział frontend / backend w pulpitach obronnych

Dominującym wzorcem w nowoczesnym tworzeniu pulpitów C2 jest jednostronicowa aplikacja (SPA) React lub Vue, konsumująca dane z zestawu mikrousług backendowych przez połączenia WebSocket dla danych na żywo i REST dla konfiguracji i zapytań historycznych. Ten podział zapewnia jasne rozdzielenie obowiązków: frontend odpowiada za renderowanie stanu, backend — za utrzymanie autorytarnego stanu i rozgłaszanie delt.

Backend mikrousług zazwyczaj składa się z co najmniej czterech usług w minimalnym wdrożeniu: usługa śladów (utrzymuje żywą bazę danych obiektów), usługa wiadomości (obsługuje przychodzące CoT i NFFI), usługa alertów (ocenia reguły i publikuje powiadomienia) oraz usługa uwierzytelniania (weryfikuje tokeny JWT i egzekwuje polityki RBAC). Każda usługa jest skonteneryzowana — zazwyczaj Docker na Kubernetes dla wdrożeń sztabowych lub Docker Compose na utwardzonym serwerze dla konfiguracji przednich pozycji.

Krytycznym ograniczeniem architektonicznym, które odróżnia obronne pulpity od komercyjnego SaaS, jest wymóg działania w środowiskach air-gapped lub poważnie ograniczonych przepustowościowo. Oznacza to, że cały pakiet frontendu, wszystkie kafle map i wszystkie biblioteki geoprzestrzenne muszą być dostępne lokalnie.

Pozyskiwanie danych w czasie rzeczywistym: WebSocket a odpytywanie

Dla aktualizacji śladów WebSocket jest jedynym realnym wyborem przy taktycznych wymaganiach opóźnień. Podejście HTTP polling z 5-sekundowym interwałem wprowadza średnie opóźnienie 2,5 sekundy plus czas przetwarzania serwera, co jest niedopuszczalne dla śladów powietrznych, gdzie obowiązuje próg nieaktualności 10 sekund. Połączenia WebSocket, prawidłowo zarządzane, zapewniają opóźnienie poniżej 200 ms w sieci lokalnej i poniżej 500 ms przez taktyczne łącze radiowe.

Standardowym wzorcem implementacji jest brama WebSocket z rozgałęzieniem (fan-out). Usługa śladów backendu publikuje delty śladów (nie pełny stan) do wewnętrznej magistrali komunikatów — Redis Pub/Sub lub NATS JetStream są powszechnymi wyborami. Brama WebSocket subskrybuje magistralę, utrzymuje pulę połączeń uwierzytelnionych sesji przeglądarkowych i rozgałęzia odpowiednie zdarzenia do każdej sesji na podstawie roli sesji i filtru obszaru zainteresowania.

Backpressure jest krytycznym problemem, który wiele wczesnych implementacji C2 pomija. Gdy frontend nie może przetwarzać zdarzeń tak szybko, jak nadchodzą — np. podczas intensywnego starcia, gdy setki śladów aktualizują się jednocześnie — bufor WebSocket może się zapełnić i połączenie może zostać przerwane. Rozwiązaniem jest kolejka zdarzeń po stronie klienta z konfigurowalną głębokością i polityką odrzucania.

Technologie warstwy map

Warstwa map jest najbardziej krytycznym wizualnie komponentem pulpitu C2 i tym o najbardziej znaczących implikacjach wyboru technologii. Trzy opcje dominują w obronnym tworzeniu C2: Mapbox GL JS, Cesium.js i niestandardowe renderowanie WebGL na bazie OpenLayers lub Leaflet.

Mapbox GL JS jest najszerzej stosowaną opcją dla 2D pulpitów obrazu operacyjnego. Renderuje kafle wektorowe przy użyciu WebGL, obsługuje niestandardowe porządkowanie warstw i wydajnie zarządza dynamicznym stylizowaniem. Krytycznie dla wdrożeń w sieciach zamkniętych, Mapbox GL JS może być w pełni hostowany lokalnie bez zewnętrznych zależności sieciowych. Głównym ograniczeniem jest renderowanie wyłącznie 2D.

Cesium.js jest standardem dla renderowania 3D powierzchni Ziemi. Obsługuje globowy tryb elipsoidalny, dokładny teren 3D i wizualizację dynamiczną w czasie — historię śladów można renderować jako ślady na globie z dokładnym postępem czasowym. Koszt wydajności jest realny: Cesium wymaga dyskretnego GPU i nowoczesnego CPU.

Niestandardowe serwery kafli dla sieci zamkniętych są wymagane w większości krajowych programów obronnych. MON i Wojsko Polskie wymagają, aby wszystkie dane georeferencyjne były przechowywane i obsługiwane z zatwierdzonych lokalnych serwerów. MapTiler Server Enterprise i TileServer-GL obsługują MBTiles i mogą obsługiwać zarówno kafle rastrowe, jak i wektorowe.

Kontrola dostępu oparta na rolach dla szczebli dowodzenia

Pulpit C2 obsługuje personel z fundamentalnie różnymi potrzebami informacyjnymi i poziomami autoryzacji. Dowódca na szczeblu brygady potrzebuje pełnego obrazu operacyjnego z uprawnieniami do kontroli ognia. Operator potrzebuje zarządzania śladami i możliwości raportowania, ale nie inicjowania misji ogniowych. Analityk potrzebuje dostępu tylko do odczytu do wszystkich danych śladów plus nakładek wywiadowczych, bez dostępu do zapisu. Oficer logistyki potrzebuje nakładek tras i statusu węzłów logistycznych, bez dostępu do przedziałów wywiadowczych.

Standardowa implementacja używa tokenów JWT z wbudowanymi claimami kodującymi zarówno rolę użytkownika, jak i jego poziom klasyfikacji. API backendu egzekwuje dostęp na poziomie zasobu. Frontend używa tych samych claimów do warunkowego renderowania elementów UI — przycisk „Misja ogniowa" nie jest renderowany dla użytkowników bez roli FIRE_CONTROL, nie jest tylko wyłączony.

Wydajność w skali: 10 000+ jednoczesnych śladów

Skalowalność liczby śladów jest najczęściej niedocenianym wyzwaniem w tworzeniu pulpitów C2. System na szczeblu brygady w środowisku wysokiej intensywności może mieć 500–2000 jednoczesnych śladów. System na szczeblu teatru działań może przekroczyć 50 000.

Kluczową decyzją architektoniczną jest to, czy renderować ślady jako elementy DOM, SVG, Canvas 2D lub WebGL. DOM i SVG zawodzą powyżej około 1000 elementów. WebGL jest jedyną opcją, która skaluje się do 10 000+ śladów przy 60 FPS, używając instancjonowanego renderowania do rysowania tysięcy identycznych geometrii symboli jednym wywołaniem rysowania.

Przy 10 000+ śladach wąskim gardłem staje się przetwarzanie JavaScript przychodzących zdarzeń WebSocket. Rozwiązaniem jest przeniesienie zarządzania stanem śladów do Web Workera, aby główny wątek był wolny dla interakcji użytkownika.

Zasada architektoniczna: Oddziel ścieżki odczytu od ścieżek zapisu na poziomie API. Odczyty śladów są częste i wrażliwe na opóźnienia; zapisy śladów są rzadkie i wrażliwe na poprawność. Mają różne wymagania infrastrukturalne i nie powinny dzielić tej samej warstwy usług.

Architektura logiki alertów

Logika alertów w pulpicie C2 musi być deterministyczna, audytowalna i szybka. Alert uruchamiający się 30 sekund po warunku wyzwalającym jest operacyjnie bezużyteczny. Usługa alertów ocenia reguły względem żywego stanu śladów przy każdym zdarzeniu aktualizacji z magistrali komunikatów.

Reguły są przechowywane jako ustrukturyzowane dokumenty JSON polityk: warunek (przestrzenny — ślad wchodzi do zdefiniowanego wielokąta; atrybutowy — prędkość śladu przekracza próg; czasowy — ślad nie był aktualizowany przez N sekund) i działanie (push powiadomienia WebSocket, tworzenie rekordu alertu, wyzwalanie integracji zewnętrznej). Silnik reguł ocenia warunki przestrzenne używając indeksu przestrzennego (R-drzewo) dla sprawdzeń przecięcia wielokąta O(log n).