Współczesna przestrzeń walki jest zatłoczona obiektami, które latają. Pociski artyleryjskie wznoszą się do maksymalnej wysokości wierzchołka toru rzędu kilku kilometrów. Statki powietrzne ze skrzydłem wirnikowym przemieszczają się na małych wysokościach. Statki powietrzne ze skrzydłem stałym wykonują profile szturmowe. Amunicja krążąca i drony rozpoznawcze zajmują wysokości średnie. Ogień artylerii okrętowej sięga w głąb lądu. Gdy kilka z tych elementów jest aktywnych w tym samym rejonie i czasie, ryzyko nie jest abstrakcyjne: pojedyncze nieskoordynowane zadanie ogniowe może wysłać pocisk przez tę samą objętość przestrzeni powietrznej, przez którą leci statek powietrzny, albo posadzić go na szpitalu chronionym przez zasady użycia siły. Oprogramowanie do deconfliction ognia istnieje po to, by tego rodzaju sytuacjom zapobiegać – i robić to na tyle szybko, by nigdy nie stało się powodem, dla którego ulotny cel umyka. Niniejszy artykuł analizuje, jak działa to oprogramowanie: koordynacja przestrzeni powietrznej, listy celów zakazanych i ograniczonych, proces clearance-of-fires oraz integracja ze wspólnym obrazem operacyjnym.

Co tak naprawdę musi rozwiązać deconfliction ognia

Deconfliction ma dwa odrębne wymiary, które często są mylone. Pierwszy to deconfliction pozycyjny: utrzymywanie ognia i statków powietrznych w rozdzieleniu w przestrzeni i czasie. Drugi to deconfliction celów: upewnienie się, że rażony obiekt jest celem zgodnym z prawem i autoryzowanym oraz że nie jest już zwalczany przez kogoś innego. Dobre oprogramowanie traktuje je jako odrębne kontrole z odrębnymi źródłami danych, ponieważ zawodzą one w różny sposób i wymagają różnych rozwiązań.

Deconfliction pozycyjny jest w istocie problemem geometrycznym w czterech wymiarach – trzech przestrzennych i jednym czasowym. Trajektoria artyleryjska nie jest punktem; jest zakrzywioną objętością, która istnieje przez ograniczone okno. Statek powietrzny również nie jest punktem; jest śladem z wektorem prędkości i otaczającym go bąblem ochronnym. Silnik deconfliction musi ustalić, czy te dwie objętości przecinają się w chwilach, gdy obie są obecne. Deconfliction celów jest natomiast problemem regułowo-wyszukiwawczym: czy ten punkt celowania znajduje się w obszarze chronionym, czy niesie ze sobą ograniczenie ognia oraz czy ten sam cel jest już przydzielony innemu strzelającemu?

Trudność polega na tym, by zrobić to wszystko w ciągu sekund. Wezwanie ognia przeciwko ruchomemu, wrażliwemu na czas celowi może mieć okno minuty lub mniej, zanim cel zmieni położenie. Jeśli proces deconfliction trwa dłużej niż to okno, w praktyce odmówił on wykonania zadania. Każda decyzja projektowa w oprogramowaniu do deconfliction ognia jest kształtowana przez to ograniczenie opóźnienia.

Istnieje też wymiar koordynacji, który czysta geometria pomija. Wielu strzelających – bateria dział, sekcja moździerzy, element lotnictwa szturmowego oraz samolot szturmowy – może zostać naprowadzonych na ten sam rejon przez różne dowództwa, które nie widzą wzajemnie swoich zadań. Bez współdzielonej usługi deconfliction każde wezwanie ognia jest uzgadniane w izolacji względem częściowego obrazu tego, co jeszcze się dzieje, a to dokładnie tak dochodzi do dublowania zwalczania lub bliskiego minięcia pocisku i statku powietrznego. Zadaniem oprogramowania jest zatem nie tylko ocena jednego zadania, ale ocena go względem każdego innego ognia i statku powietrznego aktywnego w tej samej przestrzeni walki w tym samym momencie, czerpana z jednego współdzielonego źródła danych.

Koordynacja przestrzeni powietrznej: modelowanie trajektorii

Rdzeniem deconfliction pozycyjnego jest dokładny model trajektorii. Gdy element wsparcia ogniowego wybiera uzbrojenie, ładunek i cel, oprogramowanie oblicza tor balistyczny: punkt wystrzelenia, linię działo-cel, maksymalną wysokość wierzchołka toru, kąt opadania oraz czas lotu. Daje to zamiataną objętość – tubę przestrzeni powietrznej, którą zajmie pocisk – sparowaną z oknem time-on-target, podczas którego ta objętość jest niebezpieczna.

Ta objętość jest następnie sprawdzana względem przestrzeni powietrznej w jej aktualnej strukturze. Środki koordynacji przestrzeni powietrznej (ACM) dzielą przestrzeń powietrzną na zarządzane regiony: strefy operacji ograniczonych, wysokości koordynacyjne, niskopoziomowe trasy przelotu oraz standardowe trasy przelotu lotnictwa wojsk lądowych. Statki powietrzne pojawiają się również jako ślady na żywo pobierane z obrazu C2, każdy z pozycją, kursem, prędkością i objętością niepewności, która rośnie wraz z wiekiem śladu. Silnik przecina tubę pocisku zarówno ze statycznymi ACM, jak i z dynamicznymi śladami.

Gdy trajektoria przebija zajętą lub ograniczoną objętość w oknie strzelania, system zgłasza konflikt. Co istotne, nie mówi po prostu „nie”. Proponuje rozwiązania uszeregowane według wpływu operacyjnego: rozdzielenie czasowe (ogień po opuszczeniu rejonu przez statek powietrzny), boczne ograniczenie przestrzeni powietrznej, blok wysokościowy (ograniczenie maksymalnej wysokości wierzchołka toru, które może wymusić inny ładunek lub trajektorię), zmianę pozycji strzeleckiej albo – w ostateczności – wstrzymanie. Koordynator wsparcia ogniowego dokonuje wyboru, a wybrana trajektoria staje się tą, która zostaje uzgodniona i odstrzelana.

Dlaczego maksymalna wysokość wierzchołka toru ma znaczenie

Częstą wadą naiwnych narzędzi deconfliction jest traktowanie trajektorii jako prostej linii działo-cel. Ogień pośredni nie porusza się po linii prostej; zadanie moździerzowe pod dużym kątem może osiągnąć wierzchołek znacznie powyżej wysokości przelotowej przemieszczającego się śmigłowca, który nie znajduje się ani w pobliżu działa, ani celu. Deconfliction, który ignoruje maksymalną wysokość wierzchołka toru, uzgodni zadanie, które w rzeczywistości jest niebezpieczne. Model trajektorii musi nieść cały łuk, łącznie z wysokością wierzchołka, a kontrola przestrzeni powietrznej musi być wykonywana względem tego łuku, a nie uproszczonej linii. Jest to pojedyncza, najważniejsza właściwość poprawnościowa silnika deconfliction przestrzeni powietrznej.

Listy celów zakazanych i ograniczonych

Deconfliction celów zaczyna się od dwóch referencyjnych zbiorów danych. Lista celów zakazanych (NSL) wylicza obiekty chronione przed celowym zwalczaniem na podstawie prawa konfliktów zbrojnych oraz zasad użycia siły: placówki medyczne, miejsca kultu, dobra kultury, szkoły, zapory i inne chronione struktury. Lista celów ograniczonych (RTL) zawiera cele, które mogą być zwalczane wyłącznie pod określonymi ograniczeniami – konkretny organ zatwierdzający, określone uzbrojenie, próg strat ubocznych lub limit czasowy (na przykład most, którego nie wolno razić przed wyznaczoną godziną).

W oprogramowaniu obie listy są przechowywane jako rekordy geoogrodzone: każdy wpis ma swój obrys, typ ochrony lub ograniczenia oraz obowiązujące okno czasowe. Gdy cel zostaje ustalony, oprogramowanie buforuje punkt celowania o spodziewany promień rażenia uzbrojenia – jego strefę śmiertelną i strefę strat ubocznych – i testuje ten buforowany obrys względem NSL i RTL. Przecięcie z listą celów zakazanych blokuje zadanie i ujawnia operatorowi chroniony obiekt. Przecięcie z listą celów ograniczonych nie blokuje; eskaluje, dołączając obowiązujące ograniczenie i kierując zadanie do wymaganego organu zatwierdzającego.

Dyscyplina polega tu na tym, że listy muszą być autorytatywne i aktualne. Nieaktualna NSL jest gorsza niż brak NSL, ponieważ tworzy fałszywe poczucie pewności. Oprogramowanie do deconfliction ognia wersjonuje zatem te listy, oznacza znacznikiem czasu każdą aktualizację i odmawia uzgadniania ognia względem listy starszej niż konfigurowalny próg dezaktualizacji – wymuszając świadome potwierdzenie przez człowieka zamiast cichego działania na przestarzałych danych.

Proces clearance-of-fires

Clearance of fires to autorytatywne stwierdzenie, że zadanie jest uzgodnione, zgodne z prawem i zatwierdzone do otwarcia ognia. Jest to moment odpowiedzialności i w oprogramowaniu musi być modelowany jako wyraźny, audytowalny proces, a nie jako niejawny efekt uboczny naciśnięcia przycisku.

Proces łączy poszczególne elementy w łańcuch. Cyfrowe wezwanie ognia wchodzi do systemu. Silnik uruchamia kontrole celów (NSL/RTL, dublowanie zwalczania) oraz kontrole przestrzeni powietrznej (trajektoria względem ACM i śladów), dołączając swoje ustalenia do zadania. Zadanie wraz z ustaleniami jest kierowane do wymaganych organów – koordynatora wsparcia ogniowego oraz każdego dowódcy manewru, którego siły lub rejon działania są dotknięte. Każdy organ widzi te same ustalenia dotyczące konfliktów i rejestruje wyraźną decyzję o zgodzie lub odmowie. Dopiero gdy wszystkie wymagane zgody zostaną zarejestrowane, system zwalnia zadanie do pododdziału strzelającego.

Dwie właściwości czynią ten proces godnym zaufania. Po pierwsze, każdy wynik automatycznej kontroli i każda decyzja człowieka są oznaczane znacznikiem czasu i zapisywane w niezmienialnym dzienniku, dzięki czemu zgodę można odtworzyć i przeanalizować po fakcie – co jest niezbędne zarówno dla szkolenia, jak i odpowiedzialności. Po drugie, proces ma wyraźne role i organy; oprogramowanie egzekwuje, kto ma prawo udzielić zgody na co, tak samo jak COP egzekwuje dostęp do danych oparty na rolach. Oficer wsparcia ogniowego może udzielać zgody w ramach delegowanych uprawnień; zadanie dotykające listy celów ograniczonych jest eskalowane do wskazanego organu zatwierdzającego i nie może uzyskać zgody poniżej tego poziomu.

Integracja z obrazem C2

Deconfliction ognia nie może działać na prywatnej wyspie danych. Kontrola przestrzeni powietrznej jest tylko tak dobra, jak dane o śladach i przestrzeni powietrznej, które ją zasilają, a jedynym autorytatywnym źródłem tych danych jest obraz C2. Silnik deconfliction subskrybuje zatem wspólny obraz operacyjny dla śladów aktywnych statków powietrznych i sił własnych oraz pobiera środki koordynacji przestrzeni powietrznej i środki koordynacji wsparcia ogniowego (FSCM) jako nakładki mapowe utrzymywane przez komórki przestrzeni powietrznej i ognia.

Publikuje też z powrotem. Gdy zadanie zostaje uzgodnione, aktywny środek koordynacji – objętość i okno przestrzeni powietrznej, które zajmuje ogień – jest publikowany do COP przy użyciu formatów komunikatów Cursor on Target i sojuszniczych komunikatów ogniowych, aby sąsiednie pododdziały i statki powietrzne widziały przestrzeń powietrzną jako gorącą na okno strzelania. To zamyka pętlę: system, który decyduje, czy ogień jest bezpieczny, działa na – i przyczynia się do – tego samego autorytatywnego obrazu, który widzą komórka artyleryjska, komórka przestrzeni powietrznej i dowódca manewru. Jest to ta sama dyscyplina integracji, która szerzej łączy systemy kierowania ogniem z obrazem C2.

Formaty komunikatów mają znaczenie dla interoperacyjności. W koalicji dane o ogniu i przestrzeni powietrznej muszą przepływać między systemami narodowymi. Oparcie się na zdefiniowanych w STANAG zestawach komunikatów ogniowych i powietrznych oraz na Cursor on Target dla raportowania pozycji pozwala silnikowi deconfliction konsumować trasy przelotu pododdziału sojuszniczego i publikować własne środki koordynacji bez dedykowanych adapterów dla poszczególnych partnerów.

Pogorszona łączność zmienia obraz integracji, ale nie zawiesza wymogu deconfliction. Wysunięte komórki ogniowe często działają na łączach o niskiej przepustowości i przerywanych, gdzie pełny COP nie może być strumieniowany w czasie rzeczywistym. Odporny silnik deconfliction utrzymuje lokalnie buforowaną kopię środków przestrzeni powietrznej, list celów zakazanych i ograniczonych oraz ostatnich śladów, a każdy buforowany element oznacza wiekiem. Gdy łączność spada, silnik nadal uzgadnia ogień względem buforowanych danych – ale podnosi widoczność progu dezaktualizacji, oznaczając ślady i listy, które postarzały się poza swoje okno zaufania, tak aby koordynator wsparcia ogniowego udzielał zgody z otwartymi oczami co do tego, co system aktualnie może i czego nie może widzieć. Zasada projektowa jest taka, że utrata sieci musi pogarszać pewność operatora w sposób widoczny, a nie po cichu pogarszać bezpieczeństwo zgody.

Kluczowy wniosek: Najbardziej niebezpiecznym błędem w oprogramowaniu do deconfliction ognia jest konflikt, którego nie wykryje – fałszywa zgoda – a nie fałszywy alarm, który podniesie. Zaprojektuj model trajektorii i kontrole celów zakazanych tak, by zawodziły bezpiecznie: gdy dane o śladzie są nieaktualne, gdy model wysokości jest niepewny lub gdy lista jest przestarzała, silnik musi ujawnić wątpliwość i wymusić decyzję człowieka, a nie po cichu uzgodnić ogień. Narzędzie deconfliction, które optymalizuje pod kątem mniejszej liczby alertów kosztem przeoczonego konfliktu, jest gorsze niż brak narzędzia w ogóle.

Deconfliction ognia jest jednym elementem szerszego obrazu ognia połączonego, który obejmuje artylerię, bezpośrednie wsparcie lotnicze oraz efekty międzydomenowe – zobacz, jak to samo wyzwanie koordynacji pojawia się w cyfrowej koordynacji CAS oraz w pulpicie operacji wielodomenowych.

Uzgadniaj ogień połączony z jednego autorytatywnego obrazu

Corvus HEAD scala ślady na żywo, środki koordynacji przestrzeni powietrznej oraz dane ogniowe w jeden obraz operacyjny – jedyną bezpieczną podstawę do deconfliction i uzgadniania ognia połączonego w czasie zbliżonym do rzeczywistego, z każdą kontrolą i zgodą rejestrowaną dla potrzeb odpowiedzialności.

Poznaj Corvus HEAD → Umów odprawę

Niniejszą analizę przygotowali inżynierowie Corvus Intelligence, którzy budują krytyczne dla misji oprogramowanie C2 i ogniowe dla organizacji obronnych i rządowych. Poznaj nasz zespół →