Oprogramowanie do namierzania celów czasowo krytycznych: architektura dla skompresowanych pętli decyzyjnych łańcucha rażenia

Szybkość jest podstawowym wymaganiem projektowym dla oprogramowania do namierzania celów czasowo krytycznych. Cel mobilny, ulotny lub czasowo wrażliwy zniknie zanim łańcuch rażenia dobiegnie końca, jeśli oprogramowanie nie kompresuje aktywnie każdego przekazania. Wyzwanie polega na tym, że szybkość nie może odbywać się kosztem rozliczalności: każde zaangażowanie musi być powiązane z konkretnym organem, sprawdzone pod kątem zasad użycia sił i zdekonfliktowane z siłami własnymi oraz chronionymi obiektami. Te dwa wymagania -- szybkie wykonanie i weryfikowalna autoryzacja -- pozostają ze sobą w architektonicznej sprzeczności, a sposób, w jaki system ją rozwiązuje, decyduje o tym, czy jest operacyjnie realny czy jedynie teoretycznie poprawny. Artykuł omawia wzorce architektoniczne umożliwiające osiągnięcie obu celów: projekt automatu stanowego do śledzenia łańcucha rażenia, budżety latencji w osi czasu sensor-do-strzelca, przepływy pracy dekonfliktacji ognia, delegowanie uprawnień do zaangażowania, rozmieszczenie bramek z udziałem człowieka oraz integrację z interfejsami API JTAC i warstwy zarządzania walką.

Czego architektura oprogramowania wymaga od namierzania celów czasowo krytycznych

Operacje namierzania celów czasowo krytycznych (TCT) kompresują pełny łańcuch rażenia -- od początkowego wykrycia celu przez zatwierdzenie uprawnień do zaangażowania aż po użycie broni -- do osi czasu mierzonych w minutach lub sekundach, a nie godzinach. Oprogramowanie musi wspierać tę kompresję bez poświęcania dokumentacji, która sprawia, że przegląd po zaangażowaniu jest spójny prawnie i operacyjnie. Oznacza to, że architektura nie może opierać się na doraźnych przepływach pracy, gdzie operatorzy ręcznie kopiują współrzędne między systemami lub ustnie przekazują zatwierdzenia: każdy krok musi być ustrukturyzowaną, zalogowaną, niskooporową transakcją.

Pierwszym architektonicznym wymaganiem jest dostępność danych z niską latencją. Oficer namierzania nie może rozpocząć etapu szacowania szkód ubocznych, dopóki nie potwierdzi współrzędnych celu, wskaźnika pewności klasyfikacji i zaktualizowanego obrazu sił własnych -- wszystkich trzech elementów danych napływających z oddzielnych systemów. Jeśli którekolwiek z tych strumieni ma wielosekundowe opóźnienie odpytywania, staje się wąskim gardłem niezależnie od tego, jak szybki jest etap decyzji ludzkiej. Oprogramowanie TCT musi utrzymywać stale odświeżaną warstwę danych operacyjnych, a nie model zapytania na żądanie, tak aby każdy ekran i krok przepływu pracy prezentował aktualne dane bez oczekiwania na pobranie.

Drugim wymaganiem jest automatyzacja przepływu pracy na granicach przekazania. Przejścia między krokami łańcucha rażenia -- od śladu sensora do zgłoszenia celu, od zgłoszenia do wniosku o uprawnienia, od zatwierdzenia do misji ogniowej -- są miejscami, gdzie czas narastał w systemach ręcznych. Automatyzacja na tych granicach oznacza wstępne wypełnianie formularzy z istniejących danych śladu, kierowanie wniosków o zatwierdzenie do właściwego organu bez potrzeby identyfikowania go przez operatora zgłaszającego oraz przekazywanie danych ogniowych do systemów strzelców w momencie udzielenia zatwierdzenia. Kroki ludzkie są zachowane tam, gdzie są wymagane; oprogramowanie eliminuje każdy mechaniczny krok wokół nich.

Oś czasu sensor-do-strzelca: budżety latencji w każdym ogniwie łańcucha

Użyteczna architektura TCT zaczyna się od konkretnego modelu osi czasu. Dla mobilnego celu naziemnego, wobec którego wymagane jest skompresowane zaangażowanie, realistyczny budżet dzieli łańcuch na fazy: wykrycie sensora i potwierdzenie śladu (cel pojawia się w strumieniu ISR, wiek śladu przekracza minimalny próg jakości) może obejmować 20-30 sekund; identyfikacja celu i szacowanie szkód ubocznych kolejne 15-25 sekund; zatwierdzenie uprawnień do zaangażowania 10-20 sekund; przydzielenie broni, obliczenie danych ogniowych i transmisja do strzelca ostatnie 5-15 sekund. Łączny czas od potwierdzenia śladu do gotowości ogniowej może być krótszy niż 90 sekund dla wcześniej zaplanowanych kategorii celów z odpowiednim wstępnym delegowaniem -- znacznie dłuższy dla dynamicznych celów w złożonych środowiskach, ale model budżetowy przynajmniej ujawnia wąskie gardła.

Każdy przydział budżetu przekłada się na konkretne wymaganie oprogramowania. 20-30-sekundowe okno potwierdzenia śladu wymaga, aby warstwa fuzji sensorów de-duplikowała i oceniała jakość przychodzących śladów w czasie zbliżonym do rzeczywistego, a nie w 30-sekundowym cyklu odpytywania. 10-20-sekundowe okno zatwierdzenia uprawnień wymaga, aby wniosek o zatwierdzenie dotarł na ekran zatwierdzającego dowódcy z już zgromadzonymi wszystkimi danymi pomocniczymi -- zobrazowaniem celu, historią śladu, oceną szkód ubocznych, statusem dekonfliktacji -- tak aby krok decyzji nie był poprzedzony krokiem gromadzenia danych. Oprogramowanie nie może kontrolować szybkości podejmowania decyzji przez dowódców, ale może zapewnić, że każda sekunda okna uprawnień jest czasem decyzji, a nie czasem nawigacji po ekranie.

Monitorowanie osi czasu jest samo w sobie funkcją oprogramowania. Automat stanowy łańcucha rażenia powinien wyświetlać czas, jaki upłynął w każdym stanie w stosunku do wyznaczonego limitu, alertując odpowiedzialny podmiot gdy przejście zbliża się do limitu czasowego i eskalując automatycznie po przekroczeniu limitu. Zapobiega to cichemu zatrzymaniu zaangażowań w stanie, gdy nikt nie zdaje sobie sprawy, że oś czasu już przekroczyła okno operacyjne. Wspomaganie alertowania przez sztuczną inteligencję w systemach C2 może dalej priorytetyzować, które zatrzymane zaangażowania wymagają natychmiastowej uwagi człowieka, na podstawie zmienności celu i szacunków pozostałego okna zaangażowania.

Śledzenie łańcucha rażenia: projekt automatu stanowego dla zaangażowań wielopodmiotowych

Łańcuch rażenia jest zasadniczo przepływem pracy z wieloma równoległymi podmiotami, uporządkowanymi zależnościami i obowiązkowymi bramkami autoryzacji. Automat stanowy jest naturalnym modelem. Każde zaangażowanie istnieje jako obiekt w jednym ze zdefiniowanych stanów -- Wykryty, Zidentyfikowany, Zgłoszony, Zatwierdzony, Przydzielony, Zaangażowany, Ocena-Szkód-Bojowych -- a przejścia między stanami są wyzwalane przez konkretne działania podmiotów dostarczające wymagane dane i niosące uwierzytelnioną tożsamość podmiotu jako rekord autoryzacji. Automat stanowy egzekwuje, że żaden krok nie jest pomijany: zaangażowanie nie może osiągnąć stanu Przydzielony bez przejścia przez Zatwierdzony, a przejście Zatwierdzony wymaga podpisu autoryzacyjnego od roli z ważnymi uprawnieniami do zaangażowania dla tej kategorii celu i lokalizacji.

Zaangażowania wielopodmiotowe -- gdzie wiele jednostek ogniowych jest jednocześnie rozważanych lub przydzielanych do tego samego celu -- wymagają, aby automat stanowy utrzymywał relacje nadrzędny-podrzędny między rekordami zaangażowania. Rekord nadrzędny śledzi ogólny cel i jego stan w łańcuchu rażenia. Każdy rekord podrzędny śledzi przydzielenie, złożenie i ocenę szkód bojowych przez indywidualnego strzelca. Ta struktura umożliwia systemowi obsługę częściowego użycia (jeden strzelec przerywa, podczas gdy inny kontynuuje), akumulację ocen szkód bojowych z wielu źródeł przed zamknięciem zaangażowania oraz utrzymanie kompletnego śladu kontrolnego każdego podmiotu, który zetknął się z zaangażowaniem na każdym etapie.

Trwałość stanu i odtwarzanie są krytyczne dla odporności. W środowisku zdegradowanej łączności rekord zaangażowania musi przetrwać partycję sieciową i poprawnie zsynchronizować się po przywróceniu łączności. Automat stanowy powinien być zaimplementowany z architekturą opartą na zdarzeniach: wiążącym rekordem jest uporządkowany dziennik zdarzeń przejść stanu, a nie mutowalny dokument bieżącego stanu. Każdy węzeł może zrekonstruować bieżący stan przez odtworzenie dziennika zdarzeń od początku. Konflikty wynikające z równoczesnych przejść stanu podczas partycji sieciowej są rozwiązywane przez deterministyczną regułę scalania -- zazwyczaj ostatni-zapis-wygrywa w obrębie tego samego stanu, z flagą przeglądu przez człowieka dla konfliktujących przejść na etapach autoryzacji.

Delegowanie uprawnień do zaangażowania i egzekwowanie zasad użycia sił w oprogramowaniu

Uprawnienia do zaangażowania w operacjach połączonych nie są płaskim zezwoleniem -- są hierarchicznym drzewem delegowania, gdzie każdy szczebel może przyznać podrzędnym ograniczony podzbiór własnych uprawnień. Wymiary zakresu obejmują kategorię celu (pojazdy opancerzone, systemy obrony przeciwlotniczej, personel), obszar geograficzny (wyrażony jako granica środka koordynacji wsparcia ognia lub odniesienie do siatki), typ broni, okno czasowe i często minimalny próg pewności klasyfikacji celu. Oprogramowanie musi dokładnie modelować to drzewo i rozstrzygać dla każdego zgłoszenia zaangażowania, który dokładnie szczebel uprawnień musi je zatwierdzić na podstawie przecięcia wszystkich wymiarów zakresu.

Egzekwowanie zasad użycia sił (ROE) w oprogramowaniu działa równolegle z warstwą delegowania uprawnień, ale dotyczy innego pytania. Delegowanie uprawnień odpowiada na pytanie "kto może zatwierdzić to zaangażowanie?" Egzekwowanie ROE odpowiada na pytanie "czy to zaangażowanie jest w ogóle dozwolone na mocy obowiązujących rozkazów?" Reguły ROE są zakodowane jako warunki wstępne przejść stanu: zaangażowanie, które uderzyłoby w zdefiniowanej odległości od chronionego obiektu, nie może przejść do stanu Zatwierdzony niezależnie od tego, czy zatwierdzający dowódca ma uprawnienia do delegowania. Kontrole ROE uruchamiają się automatycznie, gdy zaangażowanie wchodzi w stan Zgłoszony i ponownie na etapie Zatwierdzenia, prezentując wyniki zatwierdzającemu dowódcy jako ustrukturyzowane podsumowanie zgodności, a nie binarny wynik pozytywny lub negatywny.

Rekordy delegowania i zestawy reguł ROE muszą być aktualizowalne w terenie wraz ze zmianą warunków operacyjnych. Architektura oprogramowania powinna traktować oba jako wersjonowane obiekty konfiguracyjne dystrybuowane przez ten sam kanał synchronizacji danych, co obraz operacyjny, tak aby dowódca modyfikujący swoje delegowania podczas operacji dynamicznej widział propagację tych zmian do wszystkich podrzędnych węzłów w oknie synchronizacji sieci taktycznej -- zazwyczaj sekundy do kilkudziesięciu sekund w działającej siatce. Przestarzałe dane delegowania stanowią zagrożenie bezpieczeństwa: podrzędny działający na podstawie nieaktualnego uprawnienia, które zostało odwołane, może złożyć zaangażowanie, które powinno zostać eskalowane.

Dekonfliktacja ognia: zapobieganie bratobójstwu w zautomatyzowanych przepływach pracy namierzania

Dekonfliktacja ognia jest obliczeniowo prosta, ale organizacyjnie złożona: dane potrzebne do sprawdzania konfliktów -- pozycje sił własnych, aktywne rezerwacje przestrzeni powietrznej, wpisy na liście zakazów uderzeń, inne aktywne zaangażowania, granice FSCM -- pochodzą z wielu oddzielnych systemów obsługiwanych przez różne szczeble, i każde źródło ma własną latencję aktualizacji. Silnik dekonfliktacji sprawdzający na podstawie przestarzałych danych jest równie niebezpieczny jak brak dekonfliktacji. Architektura musi traktować aktualność danych jako zagadnienie pierwszorzędne, wyświetlając znacznik czasu każdego źródła danych obok wyników dekonfliktacji, aby operator mógł ocenić, czy wynik "bez konfliktu" opiera się na bieżących informacjach czy danych sprzed kilku minut.

Typy konfliktów mają różne poziomy ważności wymagające różnych odpowiedzi. Nakładanie strefy użycia broni z inną aktywną misją to twardy konflikt, który powinien blokować zaangażowanie przed postępem do czasu rozwiązania lub zastąpienia z dokumentacją. Ostrzeżenie o bliskości -- siły własne w promieniu skutków broni, ale poza strefą śmiertelną -- to miękki konflikt informujący zatwierdzającego dowódcę bez blokowania przejścia. Kontrola bliskości listy zakazów uderzeń w konfigurowalnej odległości bezpiecznej generuje ostrzeżenie doradcze wymagające potwierdzenia przez dowódcę przed kontynuowaniem. Kodowanie tej taksonomii ważności w silniku dekonfliktacji pozwala oprogramowaniu utrzymać tempo operacyjne dla zaangażowań niskiego ryzyka, jednocześnie egzekwując twarde zatrzymania tam, gdzie ryzyko bratobójstwa jest realne. Szczegółowe omówienie techniczne algorytmów dekonfliktacji i wzorców wymiany danych zawarto w architekturze oprogramowania do dekonfliktacji ognia dla operacji połączonych.

Bramki z udziałem człowieka: gdzie oprogramowanie zatrzymuje się dla autoryzacji

Bramki z udziałem człowieka (HITL) to punkty w automacie stanowym łańcucha rażenia, gdzie automatyczne przejście jest wyraźnie zabronione -- gdzie człowiek z odpowiednimi uprawnieniami musi przejrzeć, zdecydować i dostarczyć uwierzytelnioną autoryzację przed postępem zaangażowania. Rozmieszczenie tych bramek jest decyzją polityczną, a nie decyzją oprogramowania, ale oprogramowanie musi je implementować z wystarczającą dokładnością, aby ich ominięcie nie było kwestią kliknięcia przez okno ostrzeżenia. Właściwie zaimplementowana bramka HITL wymaga pozytywnego działania autoryzacyjnego -- nie braku weta -- od roli z aktualnie ważnymi uprawnieniami, zalogowanego z tożsamością podmiotu, znacznikiem czasu i stanem danych, który był przedstawiony w momencie decyzji.

Rekord autoryzacji generowany w bramce HITL jest częścią trwałego śladu kontrolnego zaangażowania i musi być zachowany nawet jeśli zaangażowanie zostanie następnie anulowane, zastąpione lub skutkuje bratobójstwem. Przegląd po incydencie zależy od możliwości rekonstrukcji dokładnie, jakie informacje były widoczne dla każdego zatwierdzającego dowódcy, jakie kontrole ROE zostały przeprowadzone i co zwróciły oraz ile czasu upłynęło między zgłoszeniem a autoryzacją. Ten wymóg wiernego zachowania dziennika kontrolnego musi być odzwierciedlony w architekturze przechowywania: zdarzenia autoryzacji powinny być zapisywane do dziennika tylko-dołączaj, który jest replikowany poza serwerem zarządzania zaangażowaniem do oddzielnego magazynu audytowego, tak aby awaria systemu na węźle operacyjnym nie niszczyła rekordu autoryzacji.

Napięcie projektowe w bramkach HITL leży między wiernością autoryzacji a tempem operacyjnym. Bramka prezentująca dowódcy gęsty, nieskonfigurowany zrzut danych nie wspiera znacząco świadomego podejmowania decyzji pod presją czasu -- popycha dowódcę ku mechanicznemu zatwierdzaniu w celu utrzymania tempa. Dobrze zaprojektowany ekran autoryzacji prezentuje minimalne dane niezbędne do podjęcia konkretnej decyzji wymaganej na tej bramce: tożsamość celu i pewność, ocenę szkód ubocznych, podsumowanie statusu dekonfliktacji i konkretne wymagane działanie autoryzacyjne. Wszystkie szczegóły pomocnicze są dostępne, ale nie wymuszone do widoku głównego. Celem jest uczynienie właściwej decyzji szybką decyzją, a nie przyspieszenie decyzji przez minimalizowanie jej treści kognitywnej.

Integracja z JTAC, koordynacją CAS i interfejsami API warstwy zarządzania walką

Wsparcie lotnicze z bliska (CAS) i zaangażowania wspierane przez JTAC dodają wymiar integracji, którego czysta koordynacja ognia nie wymaga: system namierzania musi wymieniać dane z platformami powietrznymi i terminalami JTAC, które działają na różnych standardach łącza danych. Interfejs API warstwy zarządzania walką (BML) łączący te systemy -- niezależnie od tego, czy jest zaimplementowany jako komunikaty Link 16 serii J, JREAP-C, koalicyjna usługa sieciowa BML czy strumień danych oparty na TAK -- determinuje zarówno latencję, jak i wierność cyfrowej wymiany danych odprawy 9-liniowej. System namierzania wymagający od JTAC ponownego wprowadzania współrzędnych celu, które już znajdują się w rekordzie łańcucha rażenia, dodaje krok ręczny, ryzyko błędu przepisania i czas, który powinien być wyeliminowany przez bezpośrednie mapowanie danych. Architektura integracji dla tego przepływu pracy jest opisana technicznie w architekturze oprogramowania do koordynacji JTAC i CAS.

Na poziomie modelu danych cyfrowa odprawa 9-liniowa mapuje się bezpośrednio do pól, które system TCT już utrzymuje: lokalizacja celu (Linia 1), typ oznaczenia (Linia 2), pozycja sił własnych (Linia 3), wysokość celu (Linia 4), opis celu (Linia 5), oznaczenie celu (Linia 6), lokalizacja sił przyjaznych (Linia 7), kierunek odejścia (Linia 8) i uwagi (Linia 9). Adapter integracji automatycznie przekłada rekord zaangażowania łańcucha rażenia na te pola, pozostawiając JTAC potwierdzenie dokładności i dodanie geometrii talk-on zamiast komponowania odprawy od podstaw. Przychodzące potwierdzenie od JTAC -- potwierdzenie zameldowania statku powietrznego, ukończenia talk-on i zezwolenia na atak -- jest parsowane z powrotem do rekordu łańcucha rażenia, przesuwając automat stanowy i znacznikując każdy krok dla śladu kontrolnego.

Poza wymianą 9-liniową integracja CAS wymaga, aby system namierzania był świadomy pozycji samolotu CAS, dostępności amunicji i profilu lotu w celu przeprowadzenia znaczącej dekonfliktacji przestrzeni powietrznej. Integracja CAS znająca tylko ostatnio zgłoszoną pozycję statku powietrznego nie może sprawdzić, czy planowany przebieg ataku będzie kolidował z aktywną misją ogniową powierzchnia-powierzchnia w tym samym obszarze. Architektura integracji powinna pobierać aktualizacje stanu statku powietrznego z najwyższą dostępną częstotliwością -- zazwyczaj co 2-12 sekund na Link 16 lub poniżej sekundy na bezpośrednim strumieniu TAK -- i udostępniać je silnikowi dekonfliktacji jako stale odświeżaną warstwę własnych śladów powietrznych. Integracja tego rozwiązania z wspomaganiem decyzji przez sztuczną inteligencję w systemach C2 może dalej zautomatyzować krok wykrywania konfliktów, wyświetlając konflikty przestrzeni powietrznej koordynatorowi ognia zanim JTAC zwróci się o zezwolenie na atak, a nie po.