Łączność radiowa stanowi podstawę koordynacji bliskiego wsparcia lotniczego (CAS) od czasów II wojny światowej. Kontroler naziemny (JTAC) odczytuje dziewięcioliniowy briefing przez radio do pilota, pilot go powtarza, a jeśli wszystkie dziewięć pól przetrwają zakłócenia i alfabet fonetyczny bez błędu transkrypcji — atak jest przeprowadzany. Proceduralna prostota jest myląca: wskaźnik błędów podczas rzeczywistych operacji jest znacznie wyższy niż podczas szkoleń, powtórne odczytanie zajmuje minuty, a wizualnego potwierdzenia, że pilot i JTAC widzą ten sam punkt na ziemi, nie ma.

Cyfrowe oprogramowanie do koordynacji CAS rozwiązuje jednocześnie wszystkie trzy problemy. Ustrukturyzowany formularz zastępuje swobodny tekst transmisji radiowej, lokalizacja celu jest powiązana z markerem na żywej mapie sytuacji operacyjnej (COP), a łańcuch zatwierdzania — od JTAC do AFAC do organu autoryzującego — pozostawia niezmienialny ślad audytowy od początkowego wniosku do oceny zniszczeń po uderzeniu.

Tam, gdzie jest to istotne, artykuł odwołuje się do tego, jak TAKpilot rozwiązuje te problemy w przepływie pracy CAS opartym na TAK.

Problem przepływu pracy JTAC: dlaczego głosowa transmisja 9-linii zawodzi pod presją

Standardowy format dziewięcioliniowego wniosku CAS przekazuje dokładnie te informacje, których potrzebuje pilot do znalezienia, identyfikacji i zaatakowania celu. W kontrolowanych warunkach format działa dobrze. W warunkach operacyjnych błędy narastają na każdym etapie łańcucha transmisji.

Pole lokalizacji celu — najważniejsze pole briefingu — jest łańcuchem współrzędnych, zwykle w formacie MGRS. Wypowiedziane przez zdegradowany kanał radiowy przy wysokim tempie operacji, sześciocyfrowe współrzędne mogą być błędnie odebrane. Cyfrowe oprogramowanie CAS eliminuje fonetyczne odczytywanie współrzędnych, automatycznie wypełnia lokalizację celu z markera COP i wyświetla strefę rażenia na wspólnej mapie, którą jednocześnie widzą JTAC i organ autoryzujący.

Cyfrowa struktura wiadomości 9-liniowej: od wolnego tekstu do typowanego schematu

Każde z dziewięciu pól odpowiada ustrukturyzowanemu typowi z regułami walidacji egzekwowanymi podczas wprowadzania danych.

Linia 1 — IP/Przesunięcie. Punkt wyjściowy przechowywany jako UID obiektu COP lub współrzędna z etykietą. Przesunięcie to namiar w stopniach azymutu magnetycznego i odległość w metrach.

Linia 2 — Kurs. Całkowity namiar w stopniach azymutu magnetycznego. System renderuje oś ataku jako strzałkę na nakładce strefy rażenia.

Linia 3 — Odległość. Odległość całkowita w metrach od IP do celu. Automatycznie obliczana, gdy oba pola są wypełnione z COP.

Linia 4 — Wysokość celu. Całkowita wysokość w stopach npm. Automatycznie wypełniana z bazy danych terenu dla współrzędnych celu.

Linia 5 — Opis celu. Ustrukturyzowany typ: kategoria główna z klasyfikacją drugorzędną i polem uwag w wolnym tekście.

Linia 6 — Lokalizacja celu. Najważniejsze pole. Przechowywana w formatach MGRS i dziesiętnych stopniach. Przy wprowadzaniu współrzędnych system wyświetla punkt na mapie i prosi JTAC o wizualne potwierdzenie.

Linia 7 — Typ oznaczenia. Wyliczenie: laser (z kodem), wskaźnik podczerwieni, dym (z kolorem), GPS, siatka, brak.

Linia 8 — Siły przyjazne. Zgłoszona pozycja najbliższych sił przyjaznych względem celu. Walidowana krzyżowo z rzeczywistymi pozycjami śladów w COP.

Linia 9 — Wyjście. Zaplanowany kierunek wyjścia samolotu po ataku. Przechowywany jako kierunek kardynalny lub UID zaplanowanej trasy.

Integracja z COP: powiązanie 9-linii z żywą mapą

Gdy JTAC składa wniosek, oprogramowanie do koordynacji tworzy zestaw obiektów COP: marker lokalizacji celu, nakładkę strefy rażenia, strzałkę kursu ataku i odcinek linii IP-cel. Wszystkie nakładki są przesyłane na serwer TAK i pojawiają się na wszystkich podłączonych klientach ATAK lub WinTAK. AFAC i organ autoryzujący widzą tę samą geometrię co JTAC, bez żadnego kroku interpretacji współrzędnych.

Przepływ pracy zatwierdzania: od wniosku JTAC do przeglądu AFAC i zezwolenia SMEAC

Planowany CAS przechodzi przez pełny łańcuch SMEAC. Awaryjny CAS skraca ten łańcuch do jednej autoryzacji AFAC. Cyfrowe oprogramowanie musi implementować oba przepływy pracy z różnymi układami formularzy, różnym routingiem zatwierdzeń i różnymi zachowaniami timeoutów.

Dekonfliktacja: przestrzeń powietrzna, zapobieganie bratobójstwu i zgodność z ROE

Dekonfliktacja w cyfrowym oprogramowaniu CAS działa na trzech poziomach: przestrzeń powietrzna, zapobieganie bratobójstwu i zasady użycia siły (ROE). Przed zatwierdzeniem blok wysokości strefy rażenia jest sprawdzany pod kątem aktywnych rezerwacji przestrzeni powietrznej. Automatyczna kontrola wszystkich przyjaznych śladów w COP względem geometrii strefy rażenia jest wykonywana w momencie zatwierdzenia.

Integracja TAKpilot: od wniosku w języku naturalnym do ustrukturyzowanej 9-linii

TAKpilot akceptuje wniosek CAS w języku naturalnym — "zaatakować pojazd w siatce 37T EL 441528, laser 1688, siły przyjazne 300 m na południe" — i automatycznie generuje wstępnie wypełniony projekt 9-linii. Po potwierdzeniu TAKpilot składa 9-linię do przepływu pracy zatwierdzania i jednocześnie przesyła marker lokalizacji celu oraz nakładkę strefy rażenia do CloudTAK przez REST API serwera TAK.

Ocena skutków bombardowania: rejestrowanie obrazu po uderzeniu

Formularz wprowadzania oceny szkód bojowych (BDA) aktywuje się automatycznie, gdy status lotu przechodzi w stan "atak zakończony". JTAC wprowadza: czas uderzenia (UTC), typ i ilość uzbrojenia, zaobserwowany efekt, lokalizację krateru w MGRS, ocenę PT/PT oraz wstępną ocenę strat ubocznych.

Po operacji: dziennik lotów, archiwum 9-linii i rekonstrukcja osi czasu

Dziennik lotów zapewnia chronologiczny przegląd całej aktywności CAS. Rekonstrukcja osi czasu na potrzeby odprawy używa oznaczonych czasowo przejść stanów do generowania osi czasu zdarzeń, którą można nałożyć na archiwum śladów COP. Publiczność odprawy może przeglądać lot sekundy po sekundzie.