Геофенсинг для військових польових застосунків: зонові сповіщення та контроль доступу

Перетинання межі зони без сповіщення — це збій безпеки. Незалежно від того, позначає ця межа передній рубіж військ, коридор з обмеженим доступом, зону виключення навколо критичної інфраструктури чи периметр пункту збору, оперативна цінність цієї межі повністю залежить від системи, що виявляє перетин і сповіщає потрібних людей протягом секунд. Військове програмне забезпечення геофенсингу реалізує це виявлення у масштабі: оцінює сотні відстежуваних об'єктів відносно десятків або сотень визначень зон безперервно, на пристроях з нестабільним мережевим підключенням, що працюють на солдатському обладнанні з обмеженими ресурсами процесора та пам'яті. У цій статті розглядаються алгоритми геометрії, архітектура офлайн-оцінки, управління життєвим циклом зон, маршрутизація сповіщень, інтеграція з TAK та характеристики продуктивності, що роблять геофенсинг надійною тактичною можливістю, а не фоновою функцією з кращим зусиллям.

Оперативні сценарії використання військового геофенсингу

Геофенсинг у військових польових застосунках охоплює ширший набір вимог, ніж комерційні служби визначення місцезнаходження. Найпоширеніший сценарій — моніторинг кордону: виявлення, коли дружній актив перетинає передній рубіж своїх військ (FLOT), входить у відому зону загрози або залишає призначену зону операцій. У кожному випадку сповіщення повинно дійти до потрібного отримувача — пристрою ATAK командира взводу, чергового C2 або автоматизованої системи реєстрації — без затримки та без необхідності будь-яких дій з боку відстежуваного активу. Відстежуваний об'єкт транслює свою позицію через стандартний фід CoT; шар геофенсингу оцінює цю позицію непомітно та запускає сповіщення лише при зміні стану.

Контроль доступу — другий основний сценарій використання. Обмежені зони — склади боєприпасів, командні пункти, засоби зв'язку — можуть бути оточені геофенсними зонами, налаштованими на сповіщення про будь-який несанкціонований об'єкт, що входить у периметр. Конфігурація зони визначає, які категорії об'єктів авторизовані (дружні, конкретні позивні, конкретні UID підрозділів) та які запускають сповіщення (невідомі, ворожі або будь-який об'єкт, якого немає у списку дозволених). Це вимагає від рушія геофенсингу оцінки не лише позиції, а й метаданих об'єкта з фіду CoT: коду типу CoT, позивного об'єкта та поля приналежності, яке ATAK виводить із префіксів типу CoT.

Третій сценарій — сповіщення про наближення для деконфліктації: попередження підрозділу, коли він наближається до межі активного вогневого завдання артилерії, коридору польоту UAV або призначеного району операцій іншого підрозділу. Тут геометрія зони динамічна — полігон вогневого завдання змінюється в міру виконання завдання — і рушій геофенсингу повинен обробляти оновлення зон, що надходять під час місії, не порушуючи поточну оцінку сповіщень. Поєднання динамічних зон, фільтрів об'єктів і множинних каналів сповіщення робить військовий геофенсинг суттєво складнішим, ніж проста реалізація «чи знаходиться ця точка всередині цього полігону».

Алгоритми геометрії: точка в полігоні, приналежність до кола та зони пеленга-дальності

Алгоритм трасування променів є стандартним методом тестування приналежності для довільних полігонів. Для тестової точки P та полігону, визначеного впорядкованим списком вершин, алгоритм кидає промінь від P у фіксованому напрямку (як правило, на схід вздовж лінії постійної широти) та підраховує кількість перетинів променя з ребрами полігону. Непарна кількість перетинів означає, що P знаходиться всередині полігону; парна — поза ним. Для географічних координат перетини ребер вимагають геодезичної арифметики, а не плоскої евклідової математики: ребро на великому колі не відповідає прямій лінії у плоскій проєкції, і використання проєктованих координат вносить помилки, що зростають із розміром полігону та відстанню від центру проєкції. При тактичних масштабах — полігони, що охоплюють десятки та сотні кілометрів — використання геодезичних координат WGS84 з формулами перетину ребер на сферичній Землі утримує помилки нижче одного метра без накладних витрат повних еліпсоїдальних обчислень.

Алгоритм числа намотування є альтернативою, яка правильно обробляє самоперетинні полігони та уникає числового граничного випадку, коли промінь проходить точно через вершину. При тесті числа намотування алгоритм обчислює повний кут, що охоплюється в тестовій точці межею полігону при обході межі. Ненульове число намотування вказує, що точка знаходиться всередині. Тест числа намотування коштує приблизно на 30% більше обчислень на тест, ніж трасування променів для опуклих полігонів, але є чисельно більш стабільним поблизу вершин та обробляє виродження полігонів, що виникають, коли автори зон створюють межі вручну на сенсорних пристроях. Для опуклих зон — які охоплюють більшість військових сценаріїв, таких як кругові патрульні зони та прямокутні коридори — тест на напів-площину відносно кожного ребра є швидшим за обидва загальні алгоритми та піддається SIMD-векторизації на процесорах ARM.

Приналежність до кола — вироджений випадок для зон наближення та кругових зон виключення. Перевірка того, чи знаходиться точка в колі, вимагає лише одного обчислення геодезичної відстані: якщо відстань Гавресина між тестовою точкою та центром кола менша або рівна радіусу, точка знаходиться всередині. Обчислення відстані Гавресина на процесорі ARM Cortex-A займає приблизно 200 наносекунд, що робить тести на коло приблизно вп'ятеро швидшими за тести на полігон для 12-вершинного полігону. Зони пеленга-дальності — фани або сектори, визначені центральною точкою, дальністю та кутовим діапазоном — оцінюються шляхом поєднання тесту приналежності до кола з перевіркою пеленга: пеленг об'єкта від центру зони повинен потрапляти в кутові межі зони. Вони поширені для зон застосування зброї та зон покриття сенсорів.

Офлайн-оцінка геофенсу на пристроях солдатів

Підключення у тактичних середовищах є переривчастим за задумом. Запасами радіоканалу управляють, частоти змінюються, а плани PACE передбачають періоди деградованого або відмовленого зв'язку. Реалізація геофенсингу, що залежить від рушія оцінки на стороні сервера, не забезпечує захисту під час таких відключень. Офлайн-архітектура вимагає, щоб кожне рішення про оцінку, яке пристрою солдата може знадобитися прийняти, — приналежність до зони, класифікація об'єкта, відправка сповіщення — було виконуваним з використанням даних, що вже зберігаються на пристрої.

Реалізація офлайн-геофенсингу означає, що повний набір зон повинен зберігатися локально, а не завантажуватися на вимогу. Зони завантажуються до локальної бази даних пристрою (SQLite є стандартним сховищем у застосунках сімейства ATAK), коли пристрій отримує їх від TAK Server, і зберігаються між перезапусками застосунку. Цикл оцінки зчитує зони з локального сховища, а не з мережі, тому пристрій, що перебував офлайн шість годин, продовжує оцінювати всі зони, отримані до відключення. Єдина деградована можливість — оновлення зон: зони, переглянуті або створені на сервері після того, як пристрій пішов офлайн, не оцінюються, поки пристрій не підключиться і не отримає оновлений набір зон.

Сам цикл оцінки повинен бути достатньо ефективним для безперервної роботи на пристрої Android з акумуляторним живленням без теплового дроселювання або розряджання акумулятора, що помітить оператор. Добре реалізований цикл, що обробляє 1000 позицій об'єктів відносно 200 зон із попередньою фільтрацією за обмежувальними рамками та R-деревом просторового індексу, споживає менше 5% часу сучасного ARM Cortex-A при частоті оновлень 1 Гц. Просторовий індекс будується один раз при завантаженні зон та оновлюється інкрементно при додаванні, зміні або видаленні зон — повне перебудування ніколи не потрібне для дельти зон. Позиції об'єктів обробляються в порядку надходження з фіду CoT без блокування потоку UI, з використанням фонового обробника оцінки, що публікує результати сповіщень до головного потоку лише при виявленні переходу приналежності.

Управління життєвим циклом зон: створення, розподіл, закінчення терміну та відкликання

Геофенсна зона, що переживає свою оперативну мету, є джерелом хибних сповіщень та плутанини операторів. Управління життєвим циклом зон охоплює повну дугу від створення до видалення: кожна зона має визначений час закінчення терміну, ідентифікатор версії та запис про походження, що показує, який оператор або система її створила. Ці атрибути зберігаються у представленні зони у KML або CoT XML та в локальній базі даних зон пристрою разом із геометрією.

Розподіл зон у розгортаннях екосистеми TAK використовує пакети даних — ZIP-архіви з файлами KML зон, пов'язаними зображеннями та маніфестом, — що надсилаються на підключені пристрої через API пакетів TAK Server. Маніфест містить ідентифікатор, номер версії та часову мітку закінчення терміну кожної зони. Коли пристрій отримує пакет даних, він порівнює версію кожної зони з версією у локальному сховищі: зони з вищими версіями сервера замінюють локальні копії, нові зони вставляються, а зони, наявні локально, але відсутні в маніфесті сервера, позначаються для перевірки (не видаляються автоматично, щоб уникнути перегонових умов при частковій доставці). Розробка плагінів ATAK для нестандартних робочих процесів геофенсингу може підключитися до цієї події отримання пакету для запуску логіки налаштування зон, специфічної для місії.

Відкликання зони повинне швидко поширюватися, коли активна зона стає недійсною — завдання, що завершилося, коридор, що був скомпрометований, або зона, створена з неправильною геометрією. TAK Server підтримує видалення зон через подію видалення CoT: стандартне повідомлення CoT про застарілість або видалення, що посилається на UID зони, змушує всі підключені пристрої негайно видалити зону. Пристрої, що були офлайн під час відкликання, отримують видалення при повторному підключенні, порівнюючи локальний набір зон із поточним маніфестом сервера та видаляючи зони, що сервер більше не утримує як активні. Часові мітки закінчення терміну забезпечують резервний варіант: навіть якщо повідомлення про відкликання втрачено, зона з вичерпаним терміном автоматично деактивується, коли її часова мітка минає, запобігаючи накопиченню безстроково застарілих зон на пристроях протягом тривалої операції.

Маршрутизація сповіщень: від спрацювання зони до сповіщення C2

Виявлення перетину кордону та сповіщення потрібного отримувача — це два окремі інженерні завдання. На пристрої, що виявляє порушення, шлях сповіщення є прямолінійним: цикл оцінки публікує подію переходу до диспетчера сповіщень, який активує налаштований канал сповіщення для зони. Канали включають екранні накладені сповіщення (банер або зміну маркера на карті в ATAK), звукові сигнали (налаштований тон або проголошений позивний) та тихе журналювання до локального запису інцидентів пристрою. Для зон із налаштованою передачею до C2 диспетчер сповіщень також формує подію CoT про порушення та ставить її в чергу для передачі на TAK Server.

Подія CoT про порушення несе структуровані дані у своєму блоці деталей: UID зони, тип порушення (входження або виходження), UID та позивний об'єкта-порушника, часову мітку переходу, позицію об'єкта на момент перетину та ім'я пристрою, що повідомляє. TAK Server отримує подію порушення та пересилає її всім підписникам, чий фільтр типу збігається з типом CoT події порушення. Робочі станції C2 із програмним забезпеченням картографування або загальної оперативної картини отримують події порушення в реальному часі та можуть маршрутизувати їх до панелей чергових офіцерів, запускати автоматизовані реакції або реєструвати їх у записі інцидентів.

Інтеграція TAK та CoT для подій порушення геофенсу

Схема Cursor on Target (CoT) — це формат даних, що пов'язує рішення геофенсингу з кожним іншим елементом екосистеми TAK. Подія порушення геофенсу — це повідомлення CoT з кодом типу, взятим із таксономії CoT, трійкою час/початок/застарілість, що визначає вікно дійсності, та блоком деталей із описаними вище структурованими даними про порушення. Добре сформовані події порушення чисто інтегруються з інфраструктурою підписки та маршрутизації CoT, яку налаштування продуктивності TAK Server оптимізує для середовищ з великою кількістю об'єктів: ті самі механізми розгалуження, що розподіляють звіти про позиції, розподіляють події порушення всім підписаним споживачам C2.

Геометрія зони сама по собі представлена в CoT як елемент shape у блоці деталей, використовуючи або список точок полігону, або пару центр/радіус кола. Це дозволяє авторизувати зони в ATAK, публікувати їх на TAK Server як повідомлення CoT та підписуватися на них іншими пристроями — роблячи розподіл зон частиною стандартного потоку даних CoT, а не окремим механізмом. Пристрої, що отримують повідомлення CoT про зони, зберігають їх у локальній базі даних зон та починають їх оцінювати негайно, без необхідності перезапуску застосунку. Повідомлення CoT про зони включають час застарілості, що збігається з часовою міткою закінчення терміну зони, тому стандартне збирання сміття застарілих подій TAK Server автоматично видаляє зони з вичерпаним терміном з активного набору сервера.

Для плагінів ATAK, що реалізують нестандартну логіку геофенсингу, API плагінів безпосередньо надає доступ до моделі даних CoT: плагіни можуть реєструвати слухачів для подій CoT, що відповідають конкретним кодам типів або UID, записувати події CoT до локального сховища та підписуватися на систему шарів карти для відображення нестандартних накладок зон. Плагін геофенсингу, якому потрібно оцінювати нестандартні типи зон — фан пеленга-дальності, тимчасова зона виключення або зона з правилами авторизації для конкретних об'єктів — реалізує власний цикл оцінки поряд із вбудованим геофенсингом платформи, використовуючи той самий потік позицій CoT як вхідні дані.

Продуктивність під навантаженням: оцінка тисяч треків відносно сотень зон

Оперативні середовища з багатьма об'єктами та багатьма зонами переводять цикл оцінки в область, де алгоритмічний вибір має значення. Наївна оцінка O(N x M) для N зон відносно M треків погано масштабується: при 800 зонах та 2000 треках, що оновлюються з частотою 2 Гц, наївний підхід вимагає 3,2 мільйона тестів на приналежність за секунду. На пристрої Android середнього класу з процесором ARM Cortex-A75 кожен тест приналежності для полігону займає 0,5–2,0 мікросекунди залежно від кількості вершин, розміщуючи наївний найгірший випадок на рівні 6,4 секунди на цикл оновлення — явно нездійсненний результат.

R-дерево просторового індексу по обмежувальних рамках зон зменшує набір кандидатів для кожного треку з O(N) до O(log N + k), де k — кількість зон із перекриваючимися обмежувальними рамками — як правило, 1–5 у добре спроєктованому наборі зон, де зони суттєво не перекриваються. З R-деревом сценарій з 800 зонами та 2000 треками зводиться до приблизно 2000 пошуків у індексі плюс невелика кількість точних тестів на приналежність за цикл, завершуючись менш ніж за 100 мілісекунд на тому самому обладнанні. R-дерево підтримується інкрементно: вставки та видалення зон оновлюють індекс за час O(log N) без необхідності перебудови.

Подальша оптимізація відокремлює частоту оцінки від частоти сповіщень. Не кожен об'єкт потрібно оцінювати при кожному тіку TAK Server. Об'єкти, що були нерухомими більше налаштованого порогу (як правило, 30 секунд), депріоритизуються: їх стан приналежності до зони перевіряється з нижчою частотою (раз на 10 секунд, а не раз на секунду) до надходження оновлення позиції, що вказує на рух. Динамічні об'єкти — ті, що мають нещодавні, суттєві зміни позиції — завжди оцінюються з повною частотою оновлення. Це адаптивне планування зменшує навантаження на процесор на 40–60% у типових оперативних сценаріях, де значна частка відстежуваних об'єктів є нерухомою в даний момент. Ті самі принципи управління навантаженням, що регулюють підписку на об'єкти TAK Server, безпосередньо застосовуються до клієнтського циклу оцінки геофенсингу.