Budowa systemu C2 od zera, część 3: wspólny obraz operacyjny

Części 1 i 2 wytworzyły wiarygodne tory. Część 3 buduje powierzchnię, którą operator faktycznie widzi. Wspólny obraz operacyjny to warstwa, po której ocenia się platformę — zrób ją dobrze, a wyrozumiałość spłynie w dół przez resztę stosu; zrób ją źle, a technicznie poprawny potok fuzji zostanie wyłączony w drugim tygodniu operacji. Wzorce architektoniczne są ustalone (zob. Wspólny obraz operacyjny: jak buduje się go w nowoczesnym oprogramowaniu obronnym); część 3 przekuwa je w konkretne decyzje inżynierskie.

Krok 1: stos frontendowy

Dla przykładowej platformy COP to aplikacja działająca w przeglądarce. Wybór między natywnym a webowym został rozstrzygnięty na korzyść weba ponad dekadę temu; pozostały natywny ślad dotyczy wyspecjalizowanych platform ręcznych (ekosystem ATAK — zob. Rozwój wtyczek ATAK), a nie wyświetlaczy w stanowiskach dowodzenia.

Defensywny stos:

• React z TypeScript jako szkielet aplikacji. Dojrzałość ekosystemu, dostępność rekrutacyjna i przyjazne akredytacji oprzyrządowanie czynią go bezpiecznym wyborem dla platformy o horyzoncie 20 lat. Vue jest bronisty; Svelte nie jest jeszcze wyborem klasy zamówieniowej dla obronności.
• Cesium do widoku globu i 3D — teren, objętości przestrzeni powietrznej, tory satelitarne. Akcelerowane WebGL, dojrzałe, de facto standard dla geoprzestrzennego 3D w obronności.
• Mapbox GL lub MapLibre do widoku mapy 2D. Kafle wektorowe dla szybkości; fallback do kafli rastrowych w trybie offline. Kompromisy i sufit wydajności opisuje Renderowanie map w czasie rzeczywistym dla wojskowego C2.
• Zustand lub Redux Toolkit do stanu. Wolumen strumieniowych aktualizacji torów czyni naiwny stan React niewykonalnym; używaj store'a z selektorami stabilnymi referencyjnie i porównaniami shallow-equal.
• Ant Design lub Mantine dla otaczającego UI — panele, modale, formularze. Opieraj się budowaniu autorskiego design systemu w pierwszej iteracji; wybierz dojrzałą bibliotekę i sthemuj ją do konwencji obronnych.

Jedna nieoczywista decyzja: utrzymaj COP jako aplikację jednostronicową, nie witrynę wielostronicową. Operatorzy nie nawigują. Otwierają COP raz i używają go godzinami. Przeładowania strony to zła abstrakcja; widoki i panele w obrębie jednego szkieletu to właściwa.

Krok 2: symbolika wojskowa zrobiona dobrze

Tory renderują się jako symbole. Katalog symboli reguluje MIL-STD-2525D (lub równoważny wariant NATO APP-6). Ręcznie tworzona symbolika to czerwona flaga zamówieniowa i bloker interoperacyjności: w chwili gdy platforma integruje się z systemem sojuszniczym, niedopasowane symbole wywołują natychmiastową niezgodność.

Używaj utrzymywanej biblioteki. Open-source'owa implementacja milsymbol to de facto wybór dla webowych COP-ów; produkuje standardowy zestaw symboli jako rysowalne SVG lub canvas. Biblioteka obsługuje przynależność (przyjazny, wrogi, neutralny, nieznany), znaczniki szczebla, tekst identyfikujący oraz modyfikatory, które zamieniają ogólny symbol piechoty w „1. batalion, zmechanizowany, w postawie obronnej".

Wzorzec integracji: silnik fuzji emituje tory z atrybutami tożsamości; COP wyszukuje odpowiedni SIDC (Symbol Identification Code) MIL-STD-2525 dla tych atrybutów; biblioteka renderuje symbol. Buforuj renderowane symbole według SIDC; ten sam symbol jest używany tysiące razy w typowym obrazie operacyjnym.

Praktyczny szczegół wart odnotowania: MIL-STD-2525D ma tysiące odrębnych symboli. Niemal żaden operacyjnie istotny scenariusz nie używa więcej niż kilkuset. Buduj katalog od środka — zacznij od tego, co produkują sensory platformy, rozszerzaj wraz z pojawianiem się nowych klas sensorów.

Krok 3: aktualizacje w czasie rzeczywistym przez WebSocket

Zadaniem COP jest odzwierciedlanie magazynu torów w niemal czasie rzeczywistym. Polling się nie skaluje; WebSocket to odpowiedź strukturalna. Wzorzec architektoniczny:

Usługa bramowa utrzymuje otwarte połączenia WebSocket do każdej przeglądarki. Subskrybuje tematy tracks.updates i tracks.lifecycle silnika fuzji. Gdy nadchodzi aktualizacja toru, brama ewaluuje filtr per-połączenie (który obszar, które role, które klasyfikacje) i wysyła aktualizację do przeglądarki. Przeglądarka stosuje aktualizację do swojego lokalnego magazynu stanu; React ponownie renderuje tylko dotknięte symbole.

Nieoczywiste szczegóły inżynierskie, które przesądzają, czy to działa w skali:

Filtrowanie dzieje się po stronie serwera. Wysyłanie każdego toru do każdej przeglądarki nie działa — przy 10 000 torów aktualizowanych wielokrotnie na minutę zarówno łącze, jak i przeglądarka się duszą. Każde połączenie ma filtr subskrypcji (granice viewportu, warstwy oparte na rolach, filtr klasyfikacji) i tylko pasujące aktualizacje przepływają.

Aktualizacje przyrostowe (deltas), nie pełne zastąpienia. Aktualizacja toru to częściowa — zmieniła się pozycja, zmienił się stan cyklu życia, doprecyzowała tożsamość. Przeglądarka stosuje łatkę do swojej lokalnej kopii. Pełne ładunki toru są wysyłane wyłącznie przy pierwszej subskrypcji i przy migracjach schematu.

Rekonekcja z odzyskaniem stanu. Połączenia WebSocket zrywają się, zwłaszcza w sieciach taktycznych. Przy ponownym połączeniu przeglądarka wymienia z bramą ostatni widziany numer sekwencyjny, a brama odtwarza utracone aktualizacje z szyny. Bez utraty stanu, bez pełnego pobrania od nowa.

Obsługa przeciwciśnienia (backpressure). Powolny klient nie może zablokować bramy. Głębokość kolejki na klienta jest ograniczona; gdy kolejka się przepełnia, klient jest odrzucany i zmuszany do ponownego połączenia z pełnym pobraniem stanu. Lepiej jeden operator, który się ponownie łączy, niż wszyscy operatorzy zamrożeni.

Krok 4: filtrowanie oparte na rolach i klasyfikacja

Nie każdy operator widzi każdy tor. COP dowódcy plutonu piechoty nie pokazuje stref zaangażowania obrony przeciwlotniczej. Konto NATO-RESTRICTED nie widzi torów sklasyfikowanych jako SECRET. Platforma egzekwuje to w dwóch miejscach: filtr bramowy (co wysłać) i silnik polityki (czy w ogóle wysłać).

Filtr ról to konfiguracja per-użytkownik, per-sesja: które typy torów, które obszary operacji, które warstwy wyświetlania. Użytkownik może dostosować w ramach swoich uprawnień; system egzekwuje górną granicę. Filtr klasyfikacji jest nienegocjowalny: efektywna klasyfikacja toru (wyliczona w fuzji, propagowana do bramy) musi być na poziomie lub poniżej uprawnień użytkownika. Krzyżowe sprawdzenia na warstwie API i bazy danych — nigdy tylko w UI — to reguła. Szczegółowy wzorzec opisuje Kontrola dostępu oparta na rolach w obronnych systemach C2.

Uwaga operacyjna: buduj UI konfiguracji ról razem ze społecznością operatorów, nie w izolacji. Domyślne ustawienia mają znaczenie. Użytkownik piechoty nie chce zaczynać każdej sesji od wyłączania sześciu warstw nieistotnych danych obrony przeciwlotniczej. Operator skrzydła nie chce zaczynać każdej sesji od włączania warstw obrony przeciwlotniczej, które wyłączył jego poprzednik. Domyślne ustawienia oparte na rolach, które pasują do faktycznej pracy operatora, zmniejszają o połowę bazowy poziom frustracji operatora.

Krok 5: ergonomia operatora

COP, który zawodzi ergonomicznie, zawodzi operacyjnie. Dyscyplinę buduje się z kilku nienegocjowalnych reguł.

Wskazanie nieaktualności toru. Gdy stan cyklu życia toru to wygasanie lub utracony, symbol zmienia się — zwykle przyciemniony, możliwie obrysowany, ze wskaźnikiem wieku. Operatorzy muszą widzieć na pierwszy rzut oka, którym torom mogą zaufać.

UI rozwiązywania konfliktów. Gdy dwóch operatorów edytuje ten sam tor lub zadanie równocześnie, platforma musi ujawnić konflikt, a nie po cichu nadpisać jedną stronę. Last-writer-wins na bazie per-atrybut jest domyślą; jawne uzgadnianie dla atrybutów o wysokiej stawce.

Projekt klawiaturowy w pierwszej kolejności. UI wyłącznie myszowe zawodzą w operacjach pod presją. Każda częsta akcja ma skrót klawiaturowy; skróty są udokumentowane w produkcie i odkrywalne.

Obsługa dotykowa i w rękawicach dla celów ruggedized. Ten sam COP działa w stanowiskach dowodzenia na stacjach roboczych oraz na ruggedized tabletach na pozycjach wysuniętych brygady. Cele dotykowe są wymiarowane pod rękawice; tryby wysokokontrastowe są pierwszej klasy. Szerszy wzorzec opisuje UX ruggedized dla operatorów wojskowych.

Działanie offline. Wdrożenia na taktycznej krawędzi tracą łączność. COP musi działać na lokalnym cache'u, odtwarzać zakolejkowane akcje operatora po ponownym połączeniu i jasno wskazywać, które dane są nieaktualne. Wzorzec architektoniczny opisuje Aplikacje wojskowe offline-first; stronę map offline — Mapy offline z MBTiles i PMTiles.

Krok 6: poza mapą — dashboardy i panele

COP to coś więcej niż mapa. Operatorzy potrzebują interfejsów zadaniowania, kompozycji wiadomości, narzędzi planowania, paneli wywiadu, widoków logów. Ogólnoplatformowa zasada UX: każdy panel przestrzega tych samych konwencji interakcji. Jeśli wybranie toru na mapie podświetla go w panelu bocznym, to wybranie toru w dowolnym panelu podświetla go na mapie. Niespójność w tej warstwie to najczęstszy błąd UX w oprogramowaniu obronnym.

Warta utrzymania separacja architektoniczna: widok mapy to jeden panel; dashboardy i panele boczne to inne panele; dzielą ten sam stan selekcji przez centralny store. Dodanie nowego narzędzia analityka to nowy panel, a nie nowa aplikacja. Wzorce architektury dashboardów opisuje Architektura dashboardów C2.

Krok 7: cele wydajnościowe

Cele COP-a są ostrzejsze, niż brzmią:

• Wczytanie początkowe poniżej 3 sekund na laptopie taktycznej krawędzi z zacache'owanymi zasobami statycznymi.
• Opóźnienie aktualizacji toru poniżej 200 ms od emisji z bramy do widocznego ruchu symbolu w przeglądarce.
• Stabilne 60 FPS renderowania mapy przy maks. 10 000 widocznych torów.
• Responsywne panoramowanie i zoom przy typowych skalach map taktycznych (1:50 000 do 1:1 000 000).
• Ograniczona pamięć — przeglądarka musi działać cały dzień bez wycieków. Profiluj każde wydanie.

Cele są osiągalne z wybranym stosem; chybianie ich jest zwykle wynikiem skrótu architektonicznego wcześniej w potoku (niezaimplementowane filtrowanie po stronie serwera, pełne ładunki zamiast deltas, naiwne zarządzanie stanem).

Co dalej

Część 3 zbudowała COP. Tory renderują się z poprawną symboliką; aktualizacje płyną strumieniem przez WebSocket; operatorzy widzą tylko to, do czego są upoważnieni; ergonomia wspiera realne operacje. Platforma jest teraz używalna przez operatora — ale jeszcze nie gotowa do dostarczenia.

Część 4 zamyka pętlę: mosty interoperacyjności NATO (CoT, MIP4, STANAG 4559), etykietowanie klasyfikacji i egzekwowanie releasability, potok DevSecOps wytwarzający dowody akredytacyjne oraz wdrożenie air-gapped do użycia na taktycznej krawędzi. Po części 4 platforma jest operacyjnie wdrażalna.