Geofencing w wojskowych aplikacjach polowych: alerty strefowe i kontrola dostępu

Przekroczona granica strefy bez alertu to błąd bezpieczeństwa. Niezależnie od tego, czy granica wyznacza linię kontaktu wojsk własnych, korytarz z ograniczonym dostępem, strefę wykluczenia wokół infrastruktury krytycznej, czy obwód miejsca zbiórki – operacyjna wartość tej granicy zależy całkowicie od zdolności systemu do wykrycia przekroczenia i powiadomienia właściwych osób w ciągu sekund. Wojskowe oprogramowanie geofencingu realizuje to wykrycie na dużą skalę: oceniając setki śledzonych obiektów względem dziesiątek lub setek definicji stref w sposób ciągły, na urządzeniach mogących mieć sporadyczną łączność sieciową, działając na sprzęcie żołnierskim z ograniczonymi zasobami procesora i pamięci. Artykuł omawia algorytmy geometryczne, architekturę oceny w trybie offline, zarządzanie cyklem życia stref, routing alertów, integrację z TAK oraz charakterystyki wydajnościowe, które czynią geofencing niezawodną zdolnością taktyczną, a nie funkcją działającą na zasadzie dołożenia starań.

Operacyjne przypadki użycia geofencingu wojskowego

Geofencing w wojskowych aplikacjach polowych odpowiada na szerszy zakres wymagań niż komercyjne usługi lokalizacyjne. Najczęstszym przypadkiem użycia jest monitorowanie granicy: wykrywanie, gdy zasób własny przekracza linię kontaktu (FLOT), wchodzi w obszar zagrożenia lub opuszcza wyznaczoną strefę działania. W każdym przypadku alert musi dotrzeć do właściwego odbiorcy -- urządzenia ATAK dowódcy plutonu, oficera dyżurnego C2 lub zautomatyzowanego systemu rejestrowania -- bez opóźnienia i bez konieczności podejmowania jakichkolwiek działań przez monitorowany obiekt. Monitorowany obiekt nadaje swoją pozycję przez standardowy kanał CoT; warstwa geofencingu ocenia tę pozycję w tle i wyzwala alerty wyłącznie przy zmianach stanu.

Kontrola dostępu to drugi główny przypadek użycia. Obszary ograniczone -- punkty składowania amunicji, stanowiska dowodzenia, urządzenia łączności -- mogą być otoczone strefami geofencingu skonfigurowanymi do alertowania o wejściu każdego nieautoryzowanego obiektu w obwód. Konfiguracja strefy określa, które kategorie obiektów są autoryzowane (przyjazne, określone znaki wywoławcze, określone UID jednostek) i które wyzwalają alerty (nieznane, wrogie lub dowolny obiekt nieznajdujący się na liście dozwolonych). Wymaga to od silnika geofencingu oceny nie tylko pozycji, ale także metadanych obiektu z kanału CoT: kodu typu CoT, znaku wywoławczego obiektu i pola przynależności, które ATAK wywodzi z prefiksów typów CoT.

Trzecim przypadkiem użycia jest alertowanie o zbliżeniu na potrzeby dekonfliktacji: ostrzeganie jednostki, gdy zbliża się do granicy aktywnej misji ogniowej artylerii, korytarza lotów UAS lub obszaru operacyjnego innej jednostki. Geometria strefy jest tu dynamiczna -- wielokąt misji ogniowej zmienia się wraz z postępem misji -- a silnik geofencingu musi obsługiwać aktualizacje stref przychodzące w trakcie misji bez zakłócania bieżącej oceny alertów. Połączenie dynamicznych stref, filtrów obiektów i wielu kanałów alertów sprawia, że wojskowy geofencing jest znacznie bardziej złożony niż prosta implementacja testu „czy ten punkt jest wewnątrz tego wielokąta".

Algorytmy geometryczne: punkt-w-wielokącie, zawieranie w okręgu i strefy kierunek-odległość

Algorytm rzutowania promieni jest standardową metodą testowania zawierania w dowolnym wielokącie. Dla punktu testowego P i wielokąta zdefiniowanego przez uporządkowaną listę wierzchołków algorytm rzutuje promień z P w ustalonym kierunku (zwykle na wschód wzdłuż linii stałej szerokości geograficznej) i liczy, ile razy promień przecina krawędzie wielokąta. Nieparzysta liczba przecięć oznacza, że P jest wewnątrz wielokąta; parzysta -- na zewnątrz. Dla współrzędnych geograficznych przecięcia krawędzi wymagają arytmetyki geodezyjnej zamiast płaskiej matematyki euklidesowej: krawędź na okręgu wielkim nie odpowiada linii prostej w płaskiej projekcji, a stosowanie współrzędnych rzutowanych wprowadza błędy rosnące wraz z rozmiarem wielokąta i odległością od środka projekcji. W skalach taktycznych -- wielokątach obejmujących dziesiątki do setek kilometrów -- użycie współrzędnych geodezyjnych WGS84 z formułami przecięcia krawędzi na sferycznej Ziemi utrzymuje błędy poniżej jednego metra bez narzutu pełnych obliczeń elipsoidalnych.

Algorytm liczby skrętów jest alternatywą poprawnie obsługującą wielokąty samoprzecinające się i unikającą numerycznego przypadku brzegowego, gdy promień przechodzi dokładnie przez wierzchołek. W teście liczby skrętów algorytm oblicza całkowity kąt owinięty w punkcie testowym przez obwód wielokąta podczas jego obchodzenia. Niezerowa liczba skrętów wskazuje, że punkt jest wewnątrz. Test liczby skrętów kosztuje około 30% więcej obliczeń na test niż rzutowanie promieni dla wielokątów wypukłych, ale jest numerycznie bardziej stabilny w pobliżu wierzchołków i obsługuje degeneracje wielokątów powstające, gdy autorzy stref tworzą granice ręcznie na urządzeniach dotykowych. Dla stref wypukłych -- obejmujących większość wojskowych przypadków użycia, takich jak okrągłe obszary patrolowania i prostokątne korytarze -- test półpłaszczyzny względem każdej krawędzi jest szybszy niż oba ogólne algorytmy i nadaje się do wektoryzacji SIMD na procesorach ARM.

Zawieranie w okręgu to zdegenerowany przypadek używany dla stref zbliżeniowych i okrągłych stref wykluczenia. Sprawdzenie, czy punkt leży wewnątrz okręgu, wymaga tylko jednego obliczenia odległości geodezyjnej: jeśli odległość Haversine między punktem testowym a środkiem okręgu jest mniejsza lub równa promieniowi, punkt jest wewnątrz. Obliczenie odległości Haversine na procesorze ARM Cortex-A zajmuje około 200 nanosekund, co czyni testy okrągłe około pięć razy szybszymi niż testy wielokątów dla wielokąta 12-wierzchołkowego. Strefy kierunek-odległość -- wachlarze lub sektory zdefiniowane przez punkt środkowy, zasięg i rozpiętość kątową -- są oceniane przez połączenie testu zawierania w okręgu z kontrolą kierunku: kierunek obiektu od środka strefy musi mieścić się w granicach kątowych strefy. Są one powszechne dla stref użycia środków ogniowych (WEZ) i obszarów pokrycia sensorów.

Ocena geofencingu w trybie offline-first na urządzeniach żołnierzy

Łączność w środowiskach taktycznych jest sporadyczna z założenia. Marginesami łącza radiowego się zarządza, częstotliwości się zmienia, a plany PACE zakładają okresy zdegradowanej lub odmówionej komunikacji. Implementacja geofencingu zależna od serwerowego silnika oceny nie zapewnia ochrony podczas takich przerw. Architektura offline-first wymaga, aby każda decyzja oceniająca, którą urządzenie żołnierza będzie musiało podjąć -- zawieranie w strefie, klasyfikacja obiektu, wyslanie alertu -- była wykonywalna przy użyciu danych już przechowywanych na urządzeniu.

Implementacja geofencingu offline-first oznacza, że kompletny zestaw stref musi być przechowywany lokalnie, a nie pobierany na żądanie. Strefy są ładowane do lokalnej bazy danych urządzenia (SQLite jest standardowym magazynem w aplikacjach z rodziny ATAK) w momencie ich odebrania z TAK Server i trwają przez restarty aplikacji. Pętla oceny odczytuje strefy z lokalnego magazynu, nie z sieci, więc urządzenie, które było offline przez sześć godzin, nadal ocenia wszystkie strefy odebrane przed przerwą. Jedyną zdegradowaną zdolnością są aktualizacje stref: strefy zmienione lub stworzone na serwerze po przejściu urządzenia w tryb offline nie są oceniane do czasu ponownego połączenia urządzenia i odebrania zaktualizowanego zestawu stref.

Sama pętla oceny musi być wystarczająco wydajna, aby działać nieprzerwanie na zasilanym bateryjnie urządzeniu Android bez powodowania dławienia termicznego lub rozładowania baterii, które operator zauważy. Dobrze zaimplementowana pętla przetwarzająca 1000 pozycji obiektów względem 200 stref przy użyciu wstępnego filtrowania obwiednią i indeksu przestrzennego R-tree zużywa mniej niż 5% nowoczesnego procesora ARM Cortex-A przy częstotliwości aktualizacji 1 Hz. Indeks przestrzenny jest budowany jednorazowo podczas ładowania stref i aktualizowany przyrostowo przy dodawaniu, modyfikacji lub usuwaniu stref -- pełna przebudowa nie jest nigdy wymagana dla delta stref. Pozycje obiektów są przetwarzane w kolejności przybycia z kanału CoT bez blokowania wątku UI, przy użyciu wątku roboczego oceny w tle, który wysyła wyniki alertów do wątku głównego tylko wtedy, gdy wykryte zostanie przejście zawierania.

Zarządzanie cyklem życia stref: tworzenie, dystrybucja, wygaśnięcie i odwołanie

Strefa geofencingu, która przeżywa swój operacyjny cel, jest źródłem fałszywych alertów i dezorientacji operatorów. Zarządzanie cyklem życia stref obejmuje pełny łuk od tworzenia do usunięcia: każda strefa ma zdefiniowany czas wygaśnięcia, identyfikator wersji i rekord proweniencji pokazujący, który operator lub system ją stworzył. Atrybuty te są przenoszone w reprezentacji KML lub CoT XML strefy i przechowywane w lokalnej bazie danych stref urządzenia obok geometrii.

Dystrybucja stref w wdrożeniach ekosystemu TAK wykorzystuje pakiety danych -- archiwa ZIP zawierające pliki KML stref, powiązane obrazy i manifest -- przesyłane do podłączonych urządzeń przez API pakietów TAK Server. Manifest wymienia identyfikator, numer wersji i znacznik czasu wygaśnięcia każdej strefy. Gdy urządzenie odbiera pakiet danych, porównuje wersję każdej strefy z wersją w swoim lokalnym magazynie: strefy z wyższymi wersjami serwera zastępują lokalne kopie, nowe strefy są wstawiane, a strefy obecne lokalnie, ale nieobecne w manifeście serwera, są flagowane do przeglądu (nie usuwane automatycznie, aby uniknąć warunków wyścigu przy częściowych dostawach). Tworzenie wtyczek ATAK dla niestandardowych przepływów pracy geofencingu może podpiąć się pod zdarzenie odbioru pakietu, aby wyzwolić logikę konfiguracji stref specyficzną dla misji.

Odwołanie strefy musi szybko rozpropagować się, gdy aktywna strefa staje się nieważna -- misja ogniowa, która się zakończyła, korytarz, który został skompromitowany, lub strefa stworzona z nieprawidłową geometrią. TAK Server obsługuje usuwanie stref przez zdarzenie CoT usunięcia: standardowy komunikat CoT stale lub delete odwołujący się do UID strefy powoduje, że wszystkie podłączone urządzenia natychmiast usuwają strefę. Urządzenia, które były offline w czasie odwołania, otrzymują usunięcie przy ponownym połączeniu, porównując swój lokalny zestaw stref z aktualnym manifestem serwera i usuwając strefy, których serwer nie posiada już jako aktywne. Znaczniki czasu wygaśnięcia stanowią mechanizm zapasowy: nawet jeśli komunikat odwołania zostanie utracony, wygasła strefa jest automatycznie dezaktywowana po upływie jej znacznika czasu, zapobiegając akumulacji bezterminowo przestarzałych stref na urządzeniach podczas długiej operacji.

Routing alertów: od wyzwolenia strefy do powiadomienia C2

Wykrycie przekroczenia granicy i powiadomienie właściwego odbiorcy to dwa odrębne problemy inżynierskie. Na urządzeniu wykrywającym naruszenie ścieżka powiadomień jest prosta: pętla oceny wysyła zdarzenie przejścia do dyspozytora alertów, który aktywuje skonfigurowany kanał powiadomień dla strefy. Kanały obejmują alerty nakładki ekranowej (baner lub zmiana znacznika mapy w ATAK), sygnały dźwiękowe (konfigurowalny ton lub wypowiadany znak wywoławczy) i ciche rejestrowanie w lokalnym rekordzie incydentów urządzenia. Dla stref ze skonfigurowanym przekierowaniem do C2 dyspozytor alertów konstruuje również zdarzenie CoT naruszenia i umieszcza je w kolejce do transmisji do TAK Server.

Zdarzenie CoT naruszenia zawiera dane strukturalne w swoim bloku szczegółowym: UID strefy, typ naruszenia (wejście lub wyjście), UID i znak wywoławczy naruszającego obiektu, znacznik czasu przejścia, pozycję obiektu w chwili przekroczenia oraz nazwę urządzenia raportującego. TAK Server odbiera zdarzenie naruszenia i przekazuje je do wszystkich subskrybentów, których filtr typów pasuje do typu CoT zdarzenia naruszenia. Stacje robocze C2 działające na oprogramowaniu mapowania lub wspólnego obrazu operacyjnego otrzymują zdarzenia naruszenia w czasie rzeczywistym i mogą kierować je do pulpitów nawigacyjnych oficerów dyżurnych, wyzwalać automatyczne odpowiedzi lub rejestrować je w rekordzie incydentów.

Integracja TAK i CoT dla zdarzeń naruszenia geofencingu

Schemat Cursor on Target (CoT) to format danych łączący decyzje geofencingu z każdym innym elementem ekosystemu TAK. Zdarzenie naruszenia geofencingu to komunikat CoT z kodem typu zaczerpniętym z taksonomii CoT, trójką time/start/stale definiującą okno ważności oraz blokiem szczegółowym zawierającym opisane wyżej strukturalne dane naruszenia. Dobrze sformowane zdarzenia naruszenia integrują się czysto z infrastrukturą subskrypcji CoT i routingu, którą strojenie wydajności TAK Server optymalizuje dla środowisk z dużą liczbą obiektów: te same mechanizmy fanout, które dystrybuują raporty pozycji, dystrybuują zdarzenia naruszenia do wszystkich subskrybujących konsumentów C2.

Geometria strefy sama w sobie jest reprezentowana w CoT jako element shape w bloku szczegółowym, przy użyciu listy punktów wielokąta lub pary środek/promień okręgu. Pozwala to na tworzenie stref w ATAK, publikowanie ich do TAK Server jako komunikatów CoT i subskrybowanie przez inne urządzenia -- czyniąc dystrybucję stref częścią standardowego przepływu danych CoT zamiast osobnym mechanizmem. Urządzenia, które otrzymują komunikaty CoT stref, przechowują je w lokalnej bazie danych stref i zaczynają je oceniać natychmiast, bez wymaganego restartu aplikacji. Komunikaty CoT stref zawierają czas stale pasujący do znacznika czasu wygaśnięcia strefy, więc standardowe zbieranie śmieci zdarzeń stale w TAK Server automatycznie usuwa wygasłe strefy z aktywnego zestawu serwera.

Dla wtyczek ATAK implementujących niestandardową logikę geofencingu, API wtyczek bezpośrednio udostępnia model danych CoT: wtyczki mogą rejestrować listenery dla zdarzeń CoT pasujących do określonych kodów typów lub UID, zapisywać zdarzenia CoT do lokalnego magazynu i subskrybować system warstw mapy, aby renderować niestandardowe nakładki stref. Wtyczka geofencingu, która musi oceniać niestandardowe typy stref -- wachlarz kierunek-odległość, ograniczona czasowo strefa wykluczenia lub strefa z regułami autoryzacji specyficznymi dla obiektu -- implementuje własną pętlę oceny obok wbudowanego geofencingu platformy, używając tego samego strumienia pozycji CoT jako wejścia.

Wydajność pod obciążeniem: ocena tysięcy śladów względem setek stref

Środowiska operacyjne z wieloma obiektami i wieloma strefami wprowadzają pętlę oceny w obszar, gdzie wybory algorytmiczne mają znaczenie. Naiwna ocena O(N x M) dla N stref względem M śladów skaluje się słabo: przy 800 strefach i 2000 śladach aktualizowanych z częstotliwością 2 Hz naiwne podejście wymaga 3,2 miliona testów zawierania na sekundę. Na urządzeniu Android ze średniej klasy procesorem ARM Cortex-A75 każdy test zawierania wielokąta zajmuje 0,5-2,0 mikrosekundy w zależności od liczby wierzchołków, co umieszcza naiwny najgorszy przypadek na poziomie 6,4 sekundy na cykl aktualizacji -- wyraźnie niewykonalne.

Indeks przestrzenny R-tree nad obwiednią stref redukuje zbiór kandydatów dla każdego śladu z O(N) do O(log N + k), gdzie k to liczba stref z nakładającymi się obwiednią -- typowo 1-5 w dobrze zaprojektowanym zestawie stref, gdzie strefy nie nakładają się na siebie znacząco. Z R-tree scenariusz 800 stref i 2000 śladów redukuje się do około 2000 przeszukań indeksu plus małej liczby dokładnych testów zawierania na cykl, kończąc się w znacznie poniżej 100 milisekund na tym samym sprzęcie. R-tree jest utrzymywany przyrostowo: wstawianie i usuwanie stref aktualizuje indeks w czasie O(log N) bez wymaganej przebudowy.

Dalszą optymalizacją jest oddzielenie częstotliwości oceny od częstotliwości alertów. Nie każdy obiekt musi być oceniany przy każdym ticku TAK Server. Obiekty, które były nieruchome przez dłużej niż konfigurowalny próg (typowo 30 sekund), są depriorytetyzowane: ich stan zawierania w strefie jest sprawdzany z niższą częstotliwością (raz na 10 sekund zamiast raz na sekundę) do czasu, gdy aktualizacja pozycji wskazuje ruch. Obiekty dynamiczne -- te z niedawnymi, znaczącymi zmianami pozycji -- są zawsze oceniane z pełną częstotliwością aktualizacji. To adaptacyjne harmonogramowanie redukuje obciążenie procesora o 40-60% w typowych scenariuszach operacyjnych, gdzie znaczna część śledzonych obiektów jest w danym momencie nieruchoma. Te same zasady zarządzania obciążeniem, które rządzą subskrypcją obiektów TAK Server, mają bezpośrednie zastosowanie do pętli oceny geofencingu po stronie klienta.