Відстеження своїх військ на Android: ATAK, CoT та мережева архітектура

Автор: Інженерна команда Corvus Intelligence · Про команду →

25 червня 2026 11 хв читання

Відстеження своїх військ (BFT) — одна з найважливіших можливостей, яку може мати підрозділ у пішому порядку: бачити в майже реальному часі, де на карті перебуває кожен дружній елемент. Роками ця можливість була виключною сферою дорогих спеціалізованих терміналів. Платформи на базі Android з ATAK (Android Team Awareness Kit) змінили це рівняння — загартований смартфон або планшет із MANET-радіостанцією тепер забезпечує постійний BFT за частки вартості застарілого обладнання, з відкритою архітектурою плагінів, яка дозволяє співіснувати зі шаром відстеження спеціалізованим сенсорним потокам, нашаруванням ШІ та інструментам планування місій. Ця стаття охоплює весь стек BFT: схему подій позицій CoT, налаштування SA в ATAK, керування потоками на TAK Server, інтеграцію транспортного рівня MANET-радіо, профілювання частоти оновлень проти батареї та поведінку системи при втраті зв'язку.

Вимоги до BFT для тактичних підрозділів

Перед налаштуванням програмного забезпечення розгортання BFT потребує явної базової лінії вимог. Параметри, які визначають кожне наступне рішення, — це точність позицій, частота оновлень, затримка відображення та обмеження, які накладають пристрої й радіостанції в користуванні.

Точність позицій. Для BFT піхоти в пішому порядку ціль — ймовірне кругове відхилення (CEP) 10 метрів або краще — достатньо для деконфліктації в міській місцевості, де важлива роздільна здатність на рівні будівель. Для BFT на техніці зазвичай приймають CEP 50 м. Android-пристрої з багатоконстеляційним GNSS (GPS + GLONASS + Galileo) досягають CEP 3–5 м на відкритій місцевості; щільний полог або міські каньйони погіршують це до 15–30 м без підсилення. SBAS (WAAS/EGNOS) допомагає приймачам GNSS у сумісних з ATAK пристроях, подальше підвищуючи точність у підтримуваних географічних районах.

Частота оновлень. Частота оновлень позицій визначає, наскільки актуальними є треки на картах сусідніх підрозділів. Інтервали 5–10 секунд — стандарт для підрозділів безпосередньо в контакті або які виконують операції на близькій відстані. Інтервали 30–60 секунд достатні для підрозділів у підтримці або резерві. Частота оновлень безпосередньо множить навантаження на канал: кожне подвоєння кількості підрозділів або скорочення інтервалу оновлення вдвічі подвоює споживання смуги пропускання в спільній радіомережі.

Затримка відображення. Кінцева затримка відображення — від події позиції, згенерованої на вихідному пристрої, до появи трека на всіх підключених екранах — має залишатися менш як 3 секунди для операцій, де деконфліктація залежить від позицій у реальному часі. До затримки додаються час захоплення GPS, генерація події CoT, радіопередавання, обробка на сервері та рендеринг на клієнті. У добре налаштованій MANET з локальним TAK Server загальна затримка зазвичай становить 500 мс–1,5 с. Конфігурації із супутниковим бекголом додають 600 мс–1,2 с односторонньої затримки.

Обмеження пристроїв і радіостанцій. Загартовані Android-пристрої для BFT — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — мають батареї, розраховані на зміни 8–16 годин, але GPS і радіопередавання суттєво виснажують ємність. MANET-радіостанції зазвичай підключаються через USB OTG або точку доступу Wi-Fi; само підключення точки доступу додає антенне та РЧ-навантаження. Термічні обмеження в спекотних середовищах знижують стійку потужність передавання як Android-пристрою, так і радіостанції, потенційно зменшуючи ефективну дальність і тому вимагають коротших інтервалів оновлення для компенсації зростання втрат пакетів.

Події позицій Cursor on Target (CoT)

Стандарт CoT визначає схему XML-подій, якою говорить кожен елемент у мережі BFT. Розуміння цієї схеми необхідне для діагностики збоїв BFT і для написання власних плагінів, які вставляють або споживають дані про позиції.

Схема CoT XML для подій SA

Мінімальна подія позиції дружнього наземного підрозділу виглядає так:

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="ANDROID-BFT-ALPHA-1"
  type="a-f-G-U-C"
  time="2026-06-25T08:30:00.000Z"
  start="2026-06-25T08:30:00.000Z"
  stale="2026-06-25T08:30:45.000Z"
  how="m-g">
  <point lat="49.8391" lon="24.0297"
         hae="320.0" ce="9.0" le="999999.0"/>
  <detail>
    <contact callsign="ALPHA-1"/>
    <uid Droid="ALPHA-1"/>
    <group name="Cyan" role="Team Member"/>
    <status battery="72"/>
    <track speed="1.4" course="045.0"/>
    <precisionlocation geopointsrc="GPS" altsrc="GPS"/>
  </detail>
</event>

Ключові поля для BFT:

uid — унікальний ідентифікатор трека. Має залишатися стабільним між оновленнями позицій; ATAK використовує IMEI пристрою або згенерований UUID.
type — код типу CoT (див. нижче), що кодує належність, вимір і тип платформи.
time / start — мітка часу генерації події в ISO 8601 UTC. Точність годинника тут критична: розбіжність годинника спричиняє відкидання як застарілих на приймальному сервері.
stale — мітка часу, після якої подія вважається простроченою. ATAK за замовчуванням встановлює stale на time + (інтервал оновлення × 3), даючи три пропущені оновлення перед тим, як трек стане «привидом».
how — спосіб визначення позиції: m-g (GPS машини), h-g-i-g-o (GPS, введений людиною), m-g-i (виведений GPS).
point — координати WGS84: lat/lon у десяткових градусах, hae (висота над еліпсоїдом WGS84) у метрах, ce (кругова помилка) і le (лінійна помилка) у метрах.

Коди типів CoT для дружніх, ворожих і нейтральних

Коди типів CoT дотримуються ієрархічної схеми: a-[належність]-[бойовий вимір]-[функція]. Для BFT символ належності — критичний розрізнювач:

Префіс типу	Належність	Колір піктограми ATAK	Приклад
`a-f-`	Дружній	Синій	`a-f-G-U-C` — дружній наземний підрозділ, бойовий
`a-h-`	Ворожий	Червоний	`a-h-G-U-C` — ворожий наземний підрозділ, бойовий
`a-n-`	Нейтральний	Зелений	`a-n-G-E-V-C` — нейтральний наземний транспортний засіб, цивільний
`a-u-`	Невідомий	Жовтий	`a-u-G-U` — невідомий наземний підрозділ

Керування таймаутом застарілості

Мітка часу stale — основний механізм очищення треків із загальної картини обстановки. Типовий множник застарілості в ATAK — 3× від налаштованого інтервалу оновлення SA: за частоти оновлень 10 секунд stale встановлюється на 30 секунд у майбутнє. Якщо три послідовні події позицій втрачено (втрата пакетів, радіозатемнення, вимкнення пристрою), трек переходить у стан застарілості, і ATAK рендерить його з приглушеною піктограмою. Після налаштовуваного оператором пільгового періоду (за замовчуванням 5 хвилин у більшості розгортань) застарілий трек повністю видаляється з карти.

Для BFT у середовищах із високими втратами пакетів (щільна міська забудова, полог джунглів, канали через SATCOM) збільште множник застарілості до 6–10×, щоб уникнути надмірної появи «привидів» треків. Це налаштовується для кожного пристрою в ATAK: Параметри → Мережа → Звітування SA → Таймер застарілості. На боці TAK Server власний поріг застарілості сервера (за замовчуванням 600 секунд) контролює, як довго сервер зберігає трек у базі даних перед простроченням — клієнти, що щойно підключилися, не отримають треки, які перевищили поріг застарілості сервера.

ATAK як клієнт BFT

ATAK обробляє BFT повністю через свою підсистему SA (ситуаційна обізнаність). Додатковий плагін не потрібен для базового BFT — можливість вбудовано в основний застосунок ATAK. Плагіни розширюють BFT спеціалізованими джерелами даних, нашаруваннями відображення та шляхами передавання поза стандартними варіантами сервера і multicast.

Налаштування SA в ATAK

Основні елементи керування BFT розташовані в Параметри → Мережа → Параметри звітування:

Частота звітування (у русі) — інтервал передавання CoT, коли пристрій рухається. Встановіть 5–10 с для піхоти в пішому порядку, 3–5 с для підрозділів на техніці із зовнішнім живленням.
Частота звітування (нерухомий) — інтервал, коли пристрій не рухався за порогом руху. Встановіть 30–120 с для економії батареї під час статичних фаз.
Динамічне звітування SA — коли увімкнено, ATAK автоматично перемикається між частотами в русі й у спокої на основі акселерометра. Це рекомендований режим для всіх оперативних розгортань BFT.
Моя команда — призначає пристрій до групи (Cyan, Magenta, Yellow тощо), що визначає колір піктограми, який інші підрозділи бачать для цього трека, і контролює серверне групове фільтрування.
Моя роль — встановлює підтип функції в коді типу CoT (учасник команди, командир групи, штаб, медик, передовий спостерігач тощо).

Типи мережевих з'єднань

ATAK підтримує три типи мережевих з'єднань для доставки даних BFT:

TCP/TLS до TAK Server (порт 8089). Це стандартний оперативний режим. ATAK встановлює постійне TLS-з'єднання, автентифіковане клієнтським сертифікатом PKCS#12. Сервер доставляє всі підписані треки клієнту через це з'єднання та отримує події позицій клієнта для розповсюдження. TCP забезпечує надійну доставку і підтримує великі повідомлення (пакети місій, пакети даних) на додачу до подій CoT.

UDP multicast. ATAK може транслювати та приймати події CoT на multicast-адресі UDP (за замовчуванням 239.2.3.1:6969). Цей режим працює без будь-якої серверної інфраструктури — пристрої виявляють одне одного через спільну multicast-групу. Він придатний для однорангового BFT у локальних сегментах мережі (точка доступу Wi-Fi або локальний IP-простір MANET-радіо), але не підтримує федерацію, фільтрування чи постійну історію треків. Втрати пакетів у режимі multicast не відновлюються повторним передаванням: пропущена подія позиції просто не з'являється.

TCP-потік (застарілий). Старіший незашифрований режим потоків XML, який наразі відкинуто на користь TLS. Не використовуйте в жодному оперативному розгортанні.

Архітектура плагінів для спеціалізованих потоків BFT

API плагінів ATAK дозволяє стороннім застосункам вставляти події CoT у локальну карту ATAK без маршрутизації через сервер. Спеціалізований плагін BFT може отримувати дані про позиції з пропрієтарної форми хвилі радіомережі, апаратного трекера (через USB-послідовний порт) або оцінки позиції, виведеної ШІ, і вставляти їх як стандартну подію CoT, видиму на екрані ATAK. Плагін спілкується з ядром ATAK через інтерфейс intent CotMapComponent, публікуючи трансляційні intent com.atakmap.android.maps.COT_RECEIVER з корисним навантаженням CoT XML. Дивіться наш посібник із ATAK інтеграція в польових операціях для детального огляду розробки плагінів.

Керування потоками SA на TAK Server

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

Федерація серверів для SA між підрозділами

Коли BFT має охоплювати кілька незалежних інстанцій TAK Server — наприклад, сервер роти і батальйону, або передовий і тиловий ешелони — налаштування федерації TAK Server забезпечує взаємозв'язок. Федерація пересилає вибрані типи CoT через межу серверів у майже реальному часі. Для BFT налаштуйте фільтр федерації на двобічний пропуск подій a-f- (дружній atom). Не пропускайте a-h- (ворожі) через межі федерації, якщо обробку секретності на обох кінцях не перевірено — розвіддані про ворожі позиції часто чутливіші за дані про позиції своїх.

Підписка на потоки SA та ізоляція груп

TAK Server керує тим, які клієнти отримують які треки, через свою систему груп. Коли клієнт ATAK підключається з сертифікатом, призначеним до групи «PLATOON-1», він автоматично отримує всі події CoT від інших клієнтів у тій самій групі плюс будь-які групи, які PLATOON-1 налаштовано бачити (наприклад, «COMPANY-HQ»). Ця модель підписки на основі груп усуває потребу в будь-якому налаштуванні підписок на треки для кожного клієнта — належність до групи визначає всю картину SA.

Ізоляція груп користувачів — також механізм розмежування за секретністю. Призначте клієнтів ATAK секретної мережі до групи без перетину видимості з несекретними групами. Сервер ніколи не маршрутизує секретні треки несекретним клієнтам незалежно від типу чи вмісту CoT. Для жорстких меж секретності запускайте цілком окремі інстанції TAK Server на фізично окремих сегментах мережі без федераційного зв'язку між ними.

Налаштування потоків SA у CloudTAK

# Create a user group for BFT population
curl -s -X POST https://tak.yourdomain.com:8443/api/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PLATOON-1",
    "direction": "BOTH",
    "description": "1st Platoon BFT group",
    "bitpos": 0
  }'

# Assign a user certificate to the group
curl -s -X PUT https://tak.yourdomain.com:8443/api/users/alpha-1/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '["PLATOON-1", "COMPANY-HQ"]'

Поле direction контролює, чи є група вхідною (події надходять IN від цього клієнта), вихідною (події йдуть OUT до цього клієнта) чи BOTH. Встановлення BOTH — стандарт для BFT: кожен пристрій і надає, і отримує треки в межах призначених груп.

Транспорт mesh-радіо для BFT

Радіоканал — найбільш операційно обмежений елемент у стеку Android BFT. MANET-радіостанції забезпечують однорангову IP-мережу, яка з'єднує пристрої ATAK, коли інфраструктура Wi-Fi і стільниковий покриття недоступні. Розуміння того, як ATAK інтегрується з апаратурою MANET, критичне для передбачуваної продуктивності BFT у піших операціях. Наша стаття про військову mesh-мережу MANET детально охоплює мережевий рівень; цей розділ зосереджений саме на інтеграції з ATAK.

Інтеграція MANET-радіостанцій з ATAK

Harris RF-7800W (Falcon III). RF-7800W підключається до Android-пристрою через USB OTG, надаючи мережевий інтерфейс RNDIS (USB Ethernet). IP-адреса радіостанції на цьому інтерфейсі зазвичай 192.168.100.1. ATAK розглядає інтерфейс RNDIS як стандартний мережевий інтерфейс — спеціальний драйвер чи супутній застосунок не потрібні. Налаштуйте з'єднання з сервером ATAK на IP-адресу TAK Server, доступну через mesh-мережу радіостанції. Для локального однорангового BFT без сервера налаштуйте UDP multicast-вихід ATAK на адресу інтерфейсу RNDIS.

Persistent Systems MPU5. MPU5 працює як точка доступу Wi-Fi або як USB-пристрій RNDIS. У режимі точки доступу Android-пристрій підключається до SSID Wi-Fi MPU5; керувальна IP-адреса радіостанції доступна на 10.168.1.1 за замовчуванням. Persistent Systems надає супутній застосунок Android (Wave Relay Mobile), який інтегрується з ATAK, щоб показувати стан форми хвилі, карту вузлів і метрики якості каналу як рідне нашарування ATAK. Події CoT в ATAK проходять стандартним TCP- або UDP-шляхом через IP-mesh MPU5.

Розподіл смуги пропускання для трафіку SA

Кількісна оцінка бюджету смуги пропускання BFT до розгортання запобігає перевантаженню mesh-мережі в найгірший можливий момент. Одна подія позиції CoT з повним блоком detail займає 800–1200 байт. За інтервалу оновлення 10 секунд для відділення з 12 осіб:

Units:          12
Event size:     1000 bytes
Update rate:    10 seconds
Raw BFT load:   12 × 1000B / 10s = 1200 B/s ≈ 9.6 kbps

With TCP/TLS overhead (≈15%): ~11 kbps
With zlib CoT compression (≈50% reduction): ~5.5 kbps

MPU5 capacity (typical multi-hop mesh):  500 kbps–5 Mbps
RF-7800W capacity (typical):             200–500 kbps

BFT as % of RF-7800W at 200 kbps:        ~5.5% — acceptable
BFT as % of HF/SATCOM backhaul (32 kbps): ~17% — significant

У масштабі роти (100+ одиниць з інтервалом 10 секунд) необроблене навантаження BFT перевищує 80 кбіт/с до накладних витрат — суттєва частка будь-якого HF- або SATCOM-бекголу. У таких середовищах збільште інтервали оновлення в спокої до 120+ секунд і покладайтеся на пакетні оновлення від руху, щоб утримати сукупне навантаження на каналі бекголу нижче 20 кбіт/с.

Частота оновлень позицій проти часу роботи батареї

Частота оновлень позицій — найвпливовіший параметр налаштування BFT для часу роботи батареї. Захоплення GPS і радіопередавання — дві найбільші статті споживання енергії пристроєм ATAK BFT; обидві масштабуються прямо пропорційно частоті оновлень.

Профілювання батареї в операційних умовах

На Samsung Galaxy XCover Pro (батарея 4050 мА·год) з ATAK і безперервним захопленням GPS:

Частота оновлень	Споживання GPS	Споживання радіо (точка доступу MPU5)	Оцінка часу роботи BFT
5 с (агресивна)	~120 мА	~180 мА	~8–9 год
10 с (стандартна)	~120 мА	~120 мА	~10–12 год
30 с (патрулювання)	~90 мА	~60 мА	~15–18 год
120 с (статична)	~60 мА	~20 мА	~22–26 год

Споживання GPS відносно стабільне незалежно від частоти оновлень, оскільки ATAK тримає приймач GPS у режимі безперервного відстеження, щоб позиція завжди була актуальною, коли спрацьовує оновлення. Змінна — це робочий цикл радіопередавання: за інтервалів 5 секунд радіо активне майже безперервно; за інтервалів 120 секунд пакети передавання займають лише 1–2% робочого циклу.

Стратегії адаптивної частоти оновлень

Режим динамічного звітування SA в ATAK реалізує двошвидкісну адаптивну стратегію. Складніший підхід використовує плагіни ATAK або серверні команди push для коригування частоти оновлень залежно від оперативного контексту:

Перемикання частоти від руху — спрацьовування від акселерометра: якщо пристрій змістився більш як на 10 м від останнього передавання, передати негайно незалежно від запланованого інтервалу. ATAK реалізує це рідно в режимі Dynamic SA.
Пакетні оновлення від спрацьовування геозони — коли підрозділ перетинає визначену межу геозони (вхід у район цілі, перетин фазової лінії), увімкнути пакетну частоту оновлень 5 секунд на 60 секунд, потім повернутися до фонової частоти. Налаштуйте спрацьовування геозон через плагіни геозон ATAK або API геозон TAK Server.
Підвищення частоти від контакту — коли TAK Server виявляє ворожий трек у визначеному радіусі від дружнього підрозділу, він надсилає push-сповіщення клієнту ATAK дружнього підрозділу через сервер-клієнтський канал CoT, спонукаючи клієнт перейти на швидку частоту оновлень. Це потребує спеціалізованого серверного плагіна або шару інтеграції ШІ.
Зниження частоти за порогом батареї — агент керування пристроями (профіль MDM або плагін ATAK) моніторить батарею пристрою і автоматично піднімає інтервал SA, коли заряд падає нижче 30%, обмінюючи актуальність позицій на продовження роботи крізь критичну фазу.

Ситуаційна обізнаність в автономному режимі

Жодна MANET-радіомережа не працює бездоганно на всьому оперативному районі. Екранування місцевістю, радіоелектронна боротьба, відмова радіостанції та навмисний emcon (керування випромінюванням) — усе це створює періоди роботи без зв'язку. Надійний дизайн BFT має точно визначати, що робить система за відсутності радіоканалу.

Відображення останньої відомої позиції

Коли ATAK втрачає зв'язок із TAK Server (або втрачає прийом multicast у одноранговому режимі), він продовжує відображати всі треки за їхніми останніми отриманими позиціями. Візуальне розрізнення між актуальними та застарілими треками контролює мітка часу stale у CoT: щойно час stale трека минає, ATAK рендерить його з прозорим нашаруванням і міткою часу, що показує, як давно востаннє отримано позицію. Треки зберігаються в цьому застарілому стані, доки не досягнуть порога видалення застарілих на карті ATAK (налаштовується для кожного розгортання; за замовчуванням 5 хвилин).

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

Інтеграція відображення екстраполяції траєкторії

ATAK підтримує екстраполяцію трека за курсовим прокладанням через елемент detail track у подіях CoT, який містить швидкість і курс. Коли трек застаріває, плагін курсового прокладання може спроєктувати оцінену поточну позицію трека вперед від останнього відомого визначення з використанням заявлених векторів швидкості та курсу. Спроєктована позиція відображається з відмінною піктограмою (зазвичай відкритий/пунктирний символ), щоб відрізнити її від позиції, підтвердженої GPS.

Точність курсового прокладання швидко погіршується для піхоти в пішому порядку (швидкість і курс постійно змінюються) і надійніша для техніки на відомих дорожніх мережах. Реалізовуйте відображення курсового прокладання лише тоді, коли оператори розуміють його обмеження, а стандартна операційна процедура чітко розрізняє спроєктовані та підтверджені позиції.

Повторне підключення та узгодження SA

Коли ATAK повторно підключається до TAK Server після періоду без зв'язку, сервер виконує повний push стану SA: він доставляє поточну (або найновішу) подію CoT для кожного трека в підписаних групах клієнта. Це пакетне оновлення перезаписує застарілі останні відомі позиції на карті клієнта поточними даними сервера. Процес узгодження завершується за 1–3 секунди для типових розмірів підрозділів (менш як 200 треків).

# Verify reconnection burst via CloudTAK events WebSocket
# (Use wscat or a browser WebSocket client for testing)
# wss://tak.yourdomain.com:8443/api/events?groups=PLATOON-1
#
# On reconnect, expect a rapid burst of CoT events — one per known
# track — within the first 2–3 seconds of the WebSocket session.
# Monitor the event count to confirm all expected tracks are delivered.
#
# If the burst is partial, check server-side stale threshold:
# GET /api/config/cot-stale-seconds
# Default: 600s — tracks older than 10 min are not pushed to reconnecting clients

Один крайній випадок, до якого варто готуватися: якщо період без зв'язку перевищує поріг застарілості сервера (за замовчуванням 600 секунд для CloudTAK), сервер уже прострочив застарілі треки з активного сховища. Під час повторного підключення ці треки не з'являться в пакетному оновленні й повернуться лише тоді, коли вихідні пристрої передадуть нові події позицій. Для операцій, де повторні підключення можуть наставати після багатогодинних перебоїв зв'язку, підніміть поріг застарілості сервера до очікуваної максимальної тривалості перебою.

Впровадьте BFT для свого підрозділу чи організації

Ми проєктуємо та розгортаємо системи відстеження своїх військ на основі ATAK для оборонних і державних організацій — зокрема налаштування TAK Server, інтеграцію MANET-радіостанцій, AI-копілота TAKpilot і розробку плагінів під конкретні місії.

AI-копілот TAKpilot → Замовити брифінг

Цей аналіз підготували інженери Corvus Intelligence, які створюють програмне забезпечення критичного призначення для оборонних і державних організацій. Дізнайтеся про нашу команду →

Часті запитання

Що таке відстеження своїх військ на військових Android-пристроях?

Відстеження своїх військ (BFT) на військових Android-пристроях — це відображення та передавання позицій дружніх підрозділів у реальному часі на спільній цифровій карті. ATAK (Android Team Awareness Kit) — основний клієнт BFT: він зчитує позицію GPS із пристрою, пакує її в XML-подію Cursor on Target (CoT) і передає цю подію на TAK Server або безпосередньо на суміжні пристрої через multicast або MANET-радіо. Сервер агрегує події позицій від усіх підключених підрозділів і розсилає їх кожному клієнту ATAK, тож кожен боєць бачить усі дружні треки одночасно. Частоту оновлень, умовні позначення на карті та шляхи зв'язності можна налаштовувати в параметрах SA в ATAK.

Що таке Cursor on Target і як його використовують для BFT?

Cursor on Target (CoT) — це формат повідомлень на основі XML, який спочатку розробили у ВПС США для обміну тактичними даними про позиції та стан між різнорідними системами. Для BFT ключовим типом події CoT є подія «atom» (префіс типу 'a-'), яка містить елемент point із координатами lat/lon/hae, мітку часу stale, що вказує, коли позиція застаріває, і блок detail із позивним, кольором команди та роллю. ATAK автоматично генерує ці події з GPS пристрою з налаштовуваним інтервалом (зазвичай кожні 5–30 секунд) і передає їх на TAK Server, який повторно розсилає їх усім підписаним клієнтам. Мітка часу stale гарантує, що якщо підрозділ припиняє передавати, його трек автоматично зникає з екранів інших підрозділів після визначеного вікна прострочення.

Яку частоту оновлень налаштувати для ATAK BFT у тактичних операціях?

Оптимальна частота оновлень BFT залежить від типу місії, смуги пропускання радіомережі та обмежень батареї. Для піхоти в пішому порядку в бою частота оновлень 5–10 секунд забезпечує достатню актуальність позицій; для підрозділів на техніці із зовнішнім живленням прийнятні 3–5 секунд. На MANET-каналах з обмеженою смугою пропускання збільште інтервал до 30–60 секунд для підрозділів, що не маневрують, і покладайтеся на спрацьовування від руху (події залишення геозони) для негайних оновлень, коли підрозділ рухається. Функція адаптивного звітування SA в ATAK може автоматично перемикатися між повільною фоновою швидкістю та швидкою швидкістю в бою залежно від швидкості руху, яку визначає акселерометр пристрою.

Як ATAK підключається до TAK Server для BFT?

ATAK підтримує три основні типи підключення для BFT: (1) TCP-потоки — постійне TCP/TLS-з'єднання з TAK Server на порту 8089, яке використовують для надійної доставки в unicast із автентифікацією на основі сертифікатів; (2) UDP multicast — події CoT, що транслюються на multicast-адресу в межах локального сегмента мережі, придатне для середовищ LAN або MANET без серверної інфраструктури; і (3) Streaming XML — застарілий режим TCP із незашифрованими потоками XML, який наразі відкинуто. Для оперативного розгортання стандартом є TCP/TLS до TAK Server. Мережеві налаштування ATAK приймають ім'я хоста сервера, порт і сертифікатний набір PKCS#12 для взаємної автентифікації TLS.

Які MANET-радіостанції інтегруються з ATAK для BFT?

ATAK інтегрується з MANET-радіостанціями через USB OTG Android або через супутній застосунок Android для радіостанції. Поширені радіостанції для інтеграції: Harris RF-7800W (серія Falcon III), Persistent Systems MPU5, Domo Tactical PRC-ACM і Silvus StreamCaster. Кожна радіостанція надає віртуальний мережевий інтерфейс або службу ретрансляції CoT, яку ATAK розпізнає як канал даних TAK. Радіостанція виконує IP-маршрутизацію поверх mesh-мережі, а ATAK надсилає стандартні UDP multicast або TCP-пакети CoT на локальну IP-адресу радіостанції. Деякі радіостанції також надають API керування формою хвилі, який плагіни ATAK можуть опитувати для моніторингу якості каналу та відповідного налаштування параметрів передавання SA.

Як TAK Server керує потоками SA для BFT?

TAK Server веде сховище подій CoT у пам'яті для всіх підключених клієнтів. Коли надходить нова подія позиції CoT, сервер: (1) записує подію в постійну базу даних; (2) оцінює правила груп і фільтрів, щоб визначити, які клієнти мають її отримати; (3) надсилає подію всім підписаним клієнтським з'єднанням. Зокрема для BFT сервер відстежує останню подію позиції для кожного UID і надає її клієнтам, що щойно підключилися, тож вони одразу отримують актуальну загальну картину обстановки. Підписки на потоки SA керуються через систему груп сервера — клієнти, призначені до однієї групи, автоматично діляться треками BFT без ручного налаштування підписок.

Як запобігти появі треків BFT одночасно на секретних і несекретних інстанціях ATAK?

Розмежування за рівнями секретності в середовищі TAK BFT досягають поєднанням серверної ізоляції груп і фізичного розмежування мережі. На TAK Server призначте секретні підрозділи до групи, яка не видима несекретним клієнтам (наприклад, група 'SECRET' без федерації чи підписки на групу 'UNCLASSIFIED'). Для жорсткого розмежування запустіть дві цілком окремі інстанції TAK Server — одну в секретному сегменті мережі, іншу в несекретному — без федераційного зв'язку між ними. Ніколи не покладайтеся лише на програмні групові фільтри для розмежування за секретністю; для відповідності стандартам забезпечення інформаційної безпеки потрібне фізичне або криптографічне розмежування мережі.

Що відбувається з треками BFT, коли ATAK втрачає зв'язок із TAK Server?

Коли ATAK втрачає зв'язок із сервером, він переходить в автономний режим. Карта продовжує відображати останні отримані позиції всіх треків, візуально відокремлені індикатором застарілості (зазвичай приглушена піктограма або мітка часу), щойно мине час stale трека. ATAK також продовжує передавати власну позицію будь-яким доступним локальним шляхом трансляції (UDP multicast, MANET-радіо). Коли зв'язок відновлюється, ATAK автоматично підключається знову, а сервер надсилає поточний стан усіх треків пакетним оновленням, перезаписуючи застарілі останні відомі позиції. Адміністратори мають встановлювати таймаути застарілості відповідно до свого тактичного темпу — 10-хвилинне вікно застарілості запобігає появі «привидів» треків у середовищах зі слабким зв'язком.

Скільки смуги пропускання споживає BFT через ATAK на MANET-каналі?

Одна подія позиції CoT в ATAK (CoT XML із блоком detail) займає приблизно 800–1200 байт. За інтервалу оновлення 10 секунд для взводу з 20 одиниць загальний трафік BFT становить приблизно 20 × 1000 байт / 10 с = 2 кБ/с, або близько 16 кбіт/с. Це значно нижче за можливості сучасних MANET-радіостанцій (MPU5 забезпечує 1–10 Мбіт/с на вузол), але швидко накопичується у великих з'єднаннях. Для роти зі 100 одиниць з інтервалом 10 секунд необроблений трафік BFT наближається до 80 кбіт/с — це керовано, але суттєво для каналів HF або супутникового бекголу. Стиснення CoT (zlib поверх TCP-потоку) зазвичай зменшує розмір корисного навантаження на 40–60%, а адаптивні частоти оновлень можуть знизити навантаження на порядок під час статичних фаз.

Які Android-пристрої сертифіковані для військового BFT з ATAK?

ATAK MIL (військова версія, яку розповсюджують через TAK.gov) працює на низці загартованих Android-пристроїв. Поширені платформи: Samsung Galaxy XCover Pro, Getac PS336, Kyocera DuraForce Pro 2 і планшети Dell Latitude Rugged. Зокрема для BFT критерії вибору пристрою включають чутливість чипа GPS (для міських каньйонів і просочування крізь рослинність), ємність батареї (або можливість гарячої заміни), робочий діапазон температур і стійкість до ударів та води за MIL-STD-810. Пристрої з багатоконстеляційним GNSS (GPS + GLONASS + Galileo) забезпечують надійніше визначення позицій у деградованих середовищах порівняно з чипами лише GPS.