Архітектура відстеження дружніх сил: передача позиційних звітів у масштабі

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

Що таке відстеження дружніх сил і чому масштаб — найскладніша частина

Відстеження дружніх сил — це безперервний збір, передача, деконфліктація та відображення позицій дружніх підрозділів на спільній карті. Його оперативна мета двояка: запобігання дружньому вогню — командир, який точно бачить, де перебувають дружні сили, не викличе вогонь на них — і скоординований маневр, коли підрозділи коригують рух на основі живого розміщення сусідніх елементів. BFT є шаром дружніх сил на COP, і це той шар, на який більшість користувачів дивиться найчастіше.

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

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

Приймання позиційних звітів і канонічна схема треку

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

Джерела різнорідні. Піші солдати, що використовують ATAK та кінцеві пристрої користувачів, випускають події Cursor on Target. Системи управління полем бою техніки випускають NFFI (NATO Friendly Force Information) або національні аналоги. Авіація може звітувати через Link 16 або платформно-специфічні канали передачі даних. Кожен із них має власний набір полів, конвенцію координат і частоту оновлення. Завдання адаптера прийому — перевірити вхідне повідомлення, конвертувати координати та одиниці виміру, призначити або зберегти стабільний UID та випустити канонічний запис треку на рівень злиття та зберігання.

Незмінне правило полягає в тому, що необроблені вихідні формати ніколи не повинні поширюватися за межі адаптера. Якщо подія CoT, повідомлення NFFI і кадр BMS власного формату потрапляють до сховища треків у нативному вигляді, кожен споживач нижчого рівня — злиття, фільтрація, відображення — мусить розуміти всі три, і система стає неможливою для розширення або налагодження. Одна канонічна схема на вході, багато відображувачів на виході.

Стабільна ідентичність і дедуплікація

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

Налаштування частоти оновлення: найефективніший важіль впливу на навантаження

Найефективніший спосіб контролювати мережеве навантаження BFT — контролювати, як часто кожен об'єкт звітує. Наївні системи використовують фіксований інтервал — кожен підрозділ передає кожні N секунд незалежно від того, що він робить. Це витрачає більшість передач на нерухомі підрозділи, чиє положення не змінилося, водночас будучи надто повільним для швидкісних об'єктів, чиє положення суттєво змінюється між звітами.

Адаптивне, подієво-орієнтоване звітування вирішує обидві проблеми. Кожен кінцевий пристрій вирішує, коли звітувати, на основі власного руху: передавати новий звіт, коли зміщення з моменту останнього звіту перевищує порогове значення відстані, коли курс змінюється за пороговим значенням кута, або коли максимальний тихий інтервал (серцебиття) минає без руху. Зупинений транспортний засіб тоді звітує раз на серцебиття — можливо, кожні 60–120 секунд — суто щоб підтвердити, що він ще активний, тоді як той самий транспортний засіб на ходу звітує кожні кілька секунд, оскільки постійно перетинає порогове значення зміщення.

Ефект на пропускну здатність великий. У змішаних силах, де більшість підрозділів у будь-який момент статичні або повільні, адаптивне звітування зазвичай скорочує обсяг переданих звітів на 60–80 відсотків порівняно зі звітуванням із фіксованою частотою без втрати тактичної точності — швидкі, важливі рухомі об'єкти все ще оновлюються часто, а нерухомі просто перестають витрачати канал. Типові базові інтервали до адаптації: 30–120 секунд для піших, 10–30 секунд для техніки та 1–5 секунд для авіації та швидкісних об'єктів.

Мережевий транспорт для позиційних звітів

На тактичному рівні домінуючим транспортом є Cursor on Target, що передається через UDP-мультикаст у mesh-радіомережі. Мультикаст є правильним примітивом, оскільки одна передача досягає кожного слухача в сегменті — коли транспортний засіб транслює свою позицію, кожен інший вузол у зоні досяжності отримує її без необхідності адресувати кожен вузол окремо. У тактичній мережі з обмеженою пропускною здатністю ця ефективність один-до-багатьох є вирішальною.

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

За наявності каналу зворотного зв'язку крайові вузли також пересилають звіти через TCP на TAK Server, який агрегує локальну картину та ретранслює її до вищих ешелонів і на інші сервери через федерацію. На рівні бригади та вище агрегація зазвичай переміщається до брокера публікації/підписки або шини повідомлень, яка розподіляє треки передплатникам за темою. Транспорт таким чином змінює характер у міру підйому за ешелонами: з втратами мультикаст на краю для ефективності, надійний точка-до-точки та брокерований pub/sub вище, де канали ширші та повнота важливіша.

Масштабування картини: фільтрація, дельти та відображення

Ефективна передача звітів — лише половина проблеми. Друга половина — представити оператору десятки тисяч треків без перевантаження ні мережевого каналу клієнта, ні його відображувача. Три методи, застосовані разом, роблять це можливим.

Серверна фільтрація за районом і ешелоном. Авторитетне сховище треків розміщується на сервері, і кожен клієнт отримує лише треки, що стосуються його — ті, що знаходяться в його географічній зоні інтересу та дозволені його допуском і ешелоном. Командний пункт роти не потребує і не повинен отримувати повну картину дивізії. Просторова індексація (дерево квадрантів або геохеш-сітка поверх сховища треків) робить запит «дай мені всі дружні треки в цьому обмежувальному прямокутнику» дешевим, а результуючий набір обмежується зоною огляду оператора, а не загальним розміром сил. Це механізм, що утримує пропускну здатність на клієнта приблизно рівною навіть при зростанні глобальної кількості треків.

Дельта-оновлення через публікацію/підписку. Клієнти повинні підписуватися на потік змін, а не опитувати повний стан. Після початкового знімка видимої зони сервер передає лише дельти — нові треки, оновлення позицій і видалення — через WebSocket або канал pub/sub. Опитування повного стану у масштабі — класична помилка: воно змушує сервер серіалізувати всю видиму картину на кожному інтервалі, множачи навантаження на кількість клієнтів. Дельти утримують трафік стаціонарного стану пропорційним до частоти реальних змін, а не до розміру картини.

Клієнтська кластеризація та GPU-відображення. На стороні відображення малювання кожного треку як DOM-елемента не витримує ще й тисячі маркерів. Виробничі клієнти COP відображають за допомогою апаратно-прискореного WebGL — Cesium, MapLibre або власного шару — який може малювати десятки тисяч символів на кадр з інтерактивною частотою. Щільні зони кластеризуються в агрегатні символи, що розкриваються при наближенні оператора, тому зона зосередження бригади показується як один кластер із лічильником на театральному рівні наближення і розкривається до окремих платформ на тактичному рівні. Кластеризація одночасно керує як вартістю відображення, так і зручністю для людини.

Застарілість, остання відома позиція та чесне відображення

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

Це важливо, тому що символ повної яскравості означає актуальний фікс. Система BFT, що зображає позицію годинної давнини як актуальну, не просто безкорисна — вона активно вводить командира в оману, змушуючи довіряти точці, що може бути за кілометри від реальності. Явна позначка «остання відома позиція 47 хвилин тому» набагато безпечніша за впевнену, але хибну. Чесне відображення застарілості — це вимога коректності, а не косметична перевага, і вона належить до відображувального шару кожної архітектури BFT.

Зведення конвеєра разом

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