Automatyzacja bieżącej oceny sytuacji: utrzymanie świadomości sztabu w czasie rzeczywistym

Każda sekcja sztabu w kwaterze głównej prowadzi bieżącą ocenę sytuacji: stale aktualizowaną ocenę bieżącej sytuacji oraz stopnia realizacji zamiaru dowódcy. Oficer wywiadu ocenia siłę i intencje przeciwnika; oficer logistyki szacuje, na ile dni pozostało zaopatrzenie; oficer operacyjny ocenia siłę bojową całości ugrupowania. W doktrynie oceny te opisywane są jako „bieżące" — mają być aktualne przez cały czas. W praktyce zazwyczaj takie nie są, ponieważ prowadzone są ręcznie i aktualizowane tylko wtedy, gdy oficer sztabowy znajdzie czas na ich odświeżenie. Niniejszy artykuł dotyczy niwelowania tej luki za pomocą automatyzacji: pobierania danych na żywo do widoków siły bojowej, zabezpieczenia logistycznego i ryzyka, by dowódca widział rzeczywisty, bieżący obraz sytuacji, a nie migawkę sprzed kilku godzin.

Czym jest bieżąca ocena sytuacji i dlaczego traci aktualność

Bieżąca ocena sytuacji nie jest jednorazowym produktem, jak rozkaz operacyjny. Jest żywą oceną, którą każda funkcja walki utrzymuje w toku operacji. Jej struktura jest spójna między funkcjami: bieżąca sytuacja sił własnych, bieżąca sytuacja sił przeciwnika, uwarunkowania cywilne, wpływ wszystkich trzech czynników na planowane i potencjalne działania oraz wynikające z tego rekomendacje. Dowódca używa sumy tych ocen do utrzymania rozumienia sytuacji i podejmowania decyzji.

Ideał doktrynalny zakłada, że ocena odzwierciedla sytuację tu i teraz. Operacyjna rzeczywistość jest taka, że ręcznie prowadzona ocena odzwierciedla sytuację z momentu jej ostatniej aktualizacji. Wykres siły bojowej odświeżony podczas porannej odprawy synchronizacyjnej jest już nieaktualny, gdy dowódca przegląda go przed lunchem, ponieważ straty, zużycie amunicji, spalanie paliwa i awarie pojazdów zmieniają się w sposób ciągły i asynchroniczny. Ocena dezaktualizuje się w chwili publikacji, a tempo jej starzenia się jest najwyższe właśnie wtedy, gdy tempo działań jest najwyższe — czyli gdy dowódca potrzebuje jej najbardziej, by była aktualna.

Jest też drugi, mniej widoczny koszt. Ręczne agregowanie danych pochłania godziny pracy sztabu. Asystent oficera logistyki, który poświęca dwie godziny każdego cyklu na zbieranie raportów LOGSTAT, przepisywanie ich do głównego arkusza kalkulacyjnego i przeliczanie dni zaopatrzenia, ma o dwie godziny mniej na analizę, która rzeczywiście informuje decyzję. Automatyzacja nie zastępuje oceny oficera sztabowego; usuwa pracę biurową, która stoi między oficerem a oceną.

Od ręcznych wykresów do danych na żywo: architektura

Automatyzacja bieżącej oceny sytuacji oznacza budowę potoku, który pobiera wiarygodne raporty, normalizuje je do wspólnego modelu stanu, przelicza wskaźniki pochodne wraz ze zmianą danych wejściowych i prezentuje wynik wraz z zachowaną proweniencją. Architektura odzwierciedla warstwowy model stosowany przy wspólnym obrazie operacyjnym, lecz dane wyjściowe stanowią ocenę, a nie lokalizację.

Fundamentem jest model stanu zdefiniowany dla każdej funkcji walki. W ocenie operacyjnej model zawiera siłę bojową według pododdziałów — zazwyczaj wyrażoną jako procent stanu etatowego w osobach i kluczowym sprzęcie. W zabezpieczeniu logistycznym zawiera poziomy według klas zaopatrzenia, pozostałe dni zaopatrzenia i stan sprawności krytycznych systemów. W ochronie zawiera wskaźniki ryzyka i stan środków ochrony sił. Każde pole modelu wskazuje wiarygodne źródło, oczekiwany cykl aktualizacji oraz — dla wskaźników pochodnych — wzór obliczeniowy. Model ten jest umową, od której zależy każdy kolejny etap; błąd w modelu propaguje się na każdy pulpit nawigacyjny.

Nad modelem umieszczone są adaptery pobierania danych, po jednym na każde źródło. Strumień śledzenia sił własnych dostarcza pozycje i status pododdziałów, zazwyczaj jako komunikaty NFFI lub CoT. Logistyka napływa w postaci raportów LOGSTAT lub ich krajowych odpowiedników. Dane o usterkach i awariach, raporty o stratach osobowych oraz ocena wywiadowcza sił przeciwnika mają własne formaty i cykle aktualizacji. Zadanie każdego adaptera jest wąskie i rygorystyczne: przetłumacz format źródłowy na model stanu, zweryfikuj dane pod kątem zakresów wiarygodności i izoluj wszystko, co jest zniekształcone, zamiast pozwalać, by błędny raport zaburzał agregaty. Błędnie wpisana ilość amunicji, która w ciszy zmniejsza o połowę zgłaszany zapas podstawowy, jest gorsza niż brak raportu.

Ciągłe obliczanie siły bojowej i wskaźników logistycznych

Wskaźniki pochodne są sednem oceny. Procentowa siła bojowa, pozostałe dni zaopatrzenia i prognozowany zasięg operacyjny ugrupowania nie są raportowane bezpośrednio — są obliczane na podstawie danych z raportów cząstkowych. Najważniejszą decyzją projektową jest tutaj to, kiedy dokonywać ponownego obliczenia.

Prymitywna implementacja przelicza dane według stałego harmonogramu — powiedzmy co piętnaście minut. To gwarantuje, że ocena jest co najmniej piętnaście minut nieaktualna przez cały czas i marnuje zasoby obliczeniowe na przeliczanie wskaźników, które się nie zmieniły. Lepszym wzorcem jest przeliczanie zdarzeniowe: gdy raport LOGSTAT zmienia stan paliwa pododdziału, natychmiast przeliczaj dni zaopatrzenia tego pododdziału i wartość zbiorczą dla jego przełożonej formacji, pozostawiając wszystkie inne wskaźniki bez zmian. Przeliczanie zdarzeniowe utrzymuje opóźnienie bliskie zeru dla zmienionych wskaźników i unika zbędnej pracy przy tych, które się nie zmieniły.

Każdy wynik obliczeń musi zawierać swoją proweniencję. Wskaźnik siły bojowej wynoszący 78% jest bezwartościowy dla dowódcy bez odpowiedzi na dwa pytania: na kiedy i na podstawie czego. System powinien oznaczać każdy wskaźnik pochodny znacznikiem czasu i identyfikatorem źródła raportów, na podstawie których został obliczony, tak by proweniencja podążała za liczbą aż do ekranu. To jest różnica między oceną, którą dowódca może podważyć, a liczbą, której musi po prostu zaufać.

Agregacja i zwijanie danych

Wskaźniki siły bojowej i zabezpieczenia logistycznego agregują się w górę organizacji zadaniowej: drużyny w plutony, plutony w kompanie, kompanie w wynik batalionowy. Automatyzacja tego zwijania jest prosta w zasadzie i zdradliwa w szczegółach. Przydziały taktyczne i odłączenia zmieniają drzewo organizacyjne w toku operacji, a zwijanie wykorzystujące nieaktualną organizację zadaniową zsumuje nieprawidłowe pododdziały. Model stanu musi zatem traktować samą organizację zadaniową jako dane wejściowe na żywo, a nie statyczną konfigurację, by siła bojowa podążała za pododdziałami w miarę ich przegrupowywania. Gdy kompania zostaje przydzielona do innego batalionu, jej siła bojowa musi być ujęta pod nową jednostką od chwili, w której przydział staje się skuteczny.

Utrzymywanie wiarygodności oceny: przestarzałość, ufność i przesłonięcia

Najbardziej niebezpiecznym trybem awarii zautomatyzowanej oceny nie jest to, że jest błędna — lecz to, że wygląda pewnie, będąc błędną. Przejrzysty pulpit nawigacyjny z wyraźnym 78% budzi więcej zaufania niż ręcznie rysowany wykres z widocznymi poprawkami, nawet gdy ten ostatni jest bardziej aktualny. Inżynierowanie pod kątem zaufania oznacza inżynierowanie pod kątem rzetelnej niepewności.

Obsługa przestarzałości jest pierwszym wymogiem. Każde dane wejściowe mają oczekiwany cykl aktualizacji; każdy raport starszy niż konfigurowalna wielokrotność tego cyklu jest oznaczany jako przestarzały i prezentowany wizualnie — wyszarzony, oznaczony ikoną lub adnotacją — zamiast być używany bezgłośnie. Wskaźnik dni zaopatrzenia obliczony na podstawie raportu o paliwie sprzed osiemnastu godzin podczas intensywnych działań powinien wyraźnie sygnalizować swój wiek, a nie go ukrywać. Korollarz jest taki, że wskaźnik pochodny dziedziczy przestarzałość od swoich najstarszych danych wejściowych: wartość zbiorcza jest tylko tak świeża, jak jej najmniej świeży składnik.

Ufność jest drugim wymogiem. Gdy raporty bazowe są niekompletne — na przykład gdy tylko dwa z trzech podległych pododdziałów złożyły raporty — agregat powinien zawierać wyraźny wskaźnik ufności lub pokrycia, zamiast prezentować sumę cząstkową jak gdyby była kompletna. Łączy to bieżącą ocenę sytuacji z szerszą dziedziną wsparcia decyzji opartego na AI, gdzie ujawnianie podstawy i niepewności rekomendacji jest tym, co czyni ją użyteczną, a nie tylko imponującą.

Obsługa przesłonięć jest trzecim wymogiem. Oficer sztabowy czasem wie coś, czego źródła danych nie odzwierciedlają — pododdział zameldował się przez radio, lecz jeszcze nie złożył ustrukturyzowanego raportu, lub znany wadliwy czujnik powinien być pomijany. System musi pozwolić oficerowi przesłonić wartość automatyczną, musi rejestrować kto dokonał zmiany i dlaczego, i nigdy nie pozwolić, by późniejsza aktualizacja automatyczna po cichu usuwała to przesłonięcie. Przesłonięcia powinny wygasać lub wymagać ponownego potwierdzenia, zamiast utrzymywać się niewidocznie w nieskończoność, by ręczna korekta z wczoraj nie zniekształcała po cichu dzisiejszego obrazu.

Prezentowanie oceny: widoki na żywo dla dowódcy i sztabu

Ostatni etap przekształca obliczony stan w widoki, z których ludzie faktycznie korzystają. Bieżąca ocena sytuacji to nie jeden ekran, lecz kilka widoków filtrowanych według roli: widok siły bojowej dla oficera operacyjnego i dowódcy, widok logistyczny dla służb zabezpieczenia, widok ryzyka i ochrony oraz zbiorcze podsumowanie dla dowódcy. Każdy jest projekcją wyłącznie do odczytu tego samego wiarygodnego zasobu stanu, co gwarantuje, że widok logistyczny i podsumowanie dowódcy nigdy nie mogą być sprzeczne co do stanu paliwa tego samego pododdziału. Ta dyscyplina jednego źródła prawdy jest tą samą zasadą, która rządzi solidną architekturą pulpitu nawigacyjnego C2: wyświetlacze są konsumentami, a nie edytorami zasobu stanu.

Widoki na żywo powinny przesyłać zmiany w momencie ich wystąpienia, a nie czekać na odświeżenie, i powinny kierować wzrok na to, co się zmieniło. Pulpit nawigacyjny, który przerysowuje każdy wskaźnik przy każdej aktualizacji, uczy dowódcę, by go ignorował; ten, który wyróżnia delty — kompanię, której siła bojowa właśnie spadła poniżej 70%, klasę zaopatrzenia, która właśnie przekroczyła próg decyzyjny — kieruje uwagę na nieliczne fakty, które tego wymagają. Celem nie jest pokazanie wszystkiego, co jest aktualne, lecz pokazanie tego, co właśnie stało się prawdą i co to oznacza dla planu.

Progi decyzyjne zasługują na szczególne traktowanie. Dowódcy ustalają kryteria — siła bojowa poniżej określonego procentu, dni zaopatrzenia poniżej określonej liczby — które wyzwalają decyzję. Zautomatyzowana ocena może monitorować te progi w sposób ciągły i alarmować po ich przekroczeniu, zamieniając ocenę z czegoś, co sztab czyta, w coś, co mówi sztabowi, kiedy działać. Wymagana jest ostrożność: alerty progowe uruchamiające się na podstawie pojedynczego przestarzałego lub izolowanego raportu szybko podważają zaufanie, więc alert powinien uruchamiać się na tych samych wskaźnikach uwzględniających proweniencję i przestarzałość, które pokazują pulpity nawigacyjne, a nie na surowych danych wejściowych.

Jak automatyzacja wpisuje się w szerszy obraz C2

Bieżąca ocena sytuacji nie funkcjonuje w izolacji. Korzysta z tych samych źródeł co wspólny obraz operacyjny i szerszy pulpit nawigacyjny operacji wielodomenowych, i zasila rekomendacje generowane przez narzędzia wsparcia decyzji. Mapa odpowiada na pytanie, gdzie są siły i zagrożenia; ocena odpowiada na pytanie, jakie są możliwości tych sił i co to oznacza dla misji. Gdy obie są zbudowane jako widoki nad jednym wiarygodnym zasobem stanu, dowódca nigdy nie musi godzić mapy pokazującej pododdział z przodu z oceną pokazującą go jako niezdolny do walki — oba są obliczane na podstawie tych samych raportów i są spójne z zasady.

Ta spójność jest prawdziwą nagrodą automatyzacji. Utrzymywanie bieżącej oceny sytuacji w aktualności nie polega przede wszystkim na oszczędzaniu godzin pracy sztabu, choć i to osiąga. Chodzi o to, by gdy dowódca odwraca wzrok od mapy ku ocenie, obie mówiły tę samą, aktualną prawdę — by decyzja opierała się na sytuacji taką, jaka jest teraz, a nie taką, jaka była podczas ostatniej odprawy.