Пакети даних і місійні пакети TAK: структура та розповсюдження

Екосистема TAK переміщує безліч вмісту, що не є треком Cursor on Target: оверлеї, зображення, геозони, плани маршрутів, оновлення плагінів і набори сертифікатів. Механізмом, що переносить усе це, є пакет даних — звичайний zip-файл із маніфестом. Розуміння формату пакета — це різниця між парком пристроїв, що чисто ділиться спільною оперативною картиною, і таким, що тоне у застарілих оверлеях і неузгоджених шарах карти. Це інженерний розбір того, як побудовані пакети даних і місійні пакети, як TAK Server їх синхронізує і як генерувати їх у конвеєрі.

1. що таке пакет даних

Пакет даних TAK — це zip-архів, що містить єдиний обов'язковий файл — MANIFEST.xml — і довільний набір файлів корисного навантаження, на які посилається цей маніфест. Це і є все визначення. Zip — це транспортний контейнер; маніфест — це індекс, який повідомляє ATAK, WinTAK або iTAK, що всередині та як обробляти кожен елемент після отримання. Оскільки формат — це просто zip плюс XML-дескриптор, пакет даних є універсальною одиницею обміну вмістом по всій родині TAK: усе, що клієнт може відрендерити чи встановити, можна загорнути в один такий пакет.

Коли клієнт імпортує пакет, він розпаковується у робочий каталог застосунку, парситься маніфест, і кожен запис вмісту передається підсистемі, якій він належить. KML іде до менеджера оверлеїв, CoT XML іде на карту як елементи карти, файл зображення іде до сховища даних, APK іде до інсталятора плагінів. Сам пакет ефемерний — після імпорту клієнт зберігає видобуті артефакти, а не zip. Саме це єдине проєктне рішення (диспетчеризація на основі маніфесту) дозволяє одному контейнеру переносити різнорідний набір і доставляти кожен елемент у правильне місце.

2. MANIFEST.xml

Маніфест — це невеликий XML-документ із двома секціями верхнього рівня під кореневим елементом <MissionPackageManifest>. Перша — <Configuration>, список елементів <Parameter>, що описують пакет як ціле. Два, які завжди присутні, — це uid (унікальний ідентифікатор, за угодою UUID, який клієнт використовує для дедуплікації та заміни попередніх імпортів) і name (зрозуміла людині мітка, що показується в імпортері пакетів). Третій поширений параметр — onReceiveDelete — булеве значення, яке, коли true, наказує клієнту-отримувачу автоматично видаляти вміст пакета при видаленні пакета, замість того щоб залишати його артефакти.

Друга секція — <Contents>, список записів <Content>. Кожен запис має атрибут zipEntry, що задає шлях файлу корисного навантаження всередині zip, і атрибут ignore, який керує тим, чи трактує клієнт файл як імпортований вміст, чи лише як допоміжний ресурс. Записи вмісту можуть також нести вкладені параметри — наприклад, файл CoT може оголосити власний uid, щоб клієнт зіставив його з конкретним елементом карти. Мінімальний маніфест має такий вигляд:

<MissionPackageManifest version="2"><Configuration><Parameter name="uid" value="b3f1…"/><Parameter name="name" value="OP GRANITE overlay"/><Parameter name="onReceiveDelete" value="true"/></Configuration><Contents><Content ignore="false" zipEntry="overlay.kml"/><Content ignore="false" zipEntry="aoi.cot"/></Contents></MissionPackageManifest>

Атрибут version="2" має значення: він обирає схему маніфесту, проти якої парситься клієнт, і неправильне його задання — найпоширеніша причина того, що зібраний вручну пакет тихо не імпортується.

3. пакети даних проти місійних пакетів

Терміни вживаються вільно, але відмінність реальна й архітектурна. Пакет даних — це загальний артефакт zip-плюс-маніфест — спонтанний набір, який ви передаєте іншому оператору. Місійний пакет — це той самий артефакт, коли він прив'язаний до постійної, серверної місії на TAK Server. Формат контейнера ідентичний; відрізняються життєвий цикл і власність.

Спонтанний пакет даних — це «надіслав і забув»: ви його збираєте, надсилаєте, отримувач його імпортує, і далі немає жодного зв'язку між копією відправника та копією отримувача. Місійний пакет живе всередині місії — іменованої колекції з контролем доступу на сервері, на яку підписуються клієнти. Коли місія змінюється, кожен підписник повідомляється і підтягує дельту. Використовуйте спонтанний пакет даних, коли потрібна одноразова передача між двома-трьома операторами в полі. Використовуйте місію, коли потрібна спільна картина в межах підрозділу, що безперервно оновлюється, яку нові учасники можуть підтягнути повністю і яка переживає перевстановлення клієнта.

4. вміст пакета

Пакет може нести фактично будь-який артефакт, який розуміють клієнти TAK. Поширені види корисного навантаження:

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

Оверлеї KML/KMZ. Векторні оверлеї для меж, фазових ліній, зон заборони вогню і коридорів. KMZ містить власні зображення та стилізацію, на які посилається, тож добре подорожує всередині пакета.

Зображення та базові карти. Набори тайлів GeoTIFF, MBTiles та GeoPackage для офлайн-покриття карти району операцій — часто найбільший елемент у пакеті, і саме тому важлива дисципліна щодо розміру пакета.

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

Сертифікати. Набори реєстрації клієнта та довіреного сховища, що використовуються для підключення пристрою до TAK Server з правильним ланцюжком CA та клієнтським сертифікатом за один імпорт.

APK плагінів. Бінарники плагінів ATAK, що постачаються, аби оператор міг встановити чи оновити можливість без магазину застосунків. Створення цих плагінів — це окрема дисципліна — див. нашу замітку про інженерію плагінів ATAK/WinTAK — але їх розповсюдження — це просто ще один запис вмісту в маніфесті.

5. синхронізація даних TAK Server

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

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

6. шляхи розповсюдження

Існує три практичні способи, якими вміст досягає пристрою. Перший — це передача між однорангами — шлях QuickPic / «надіслати контакту», де один клієнт пакує пакет у zip і відправляє його напряму іншому клієнту через мережу TAK mesh або через сервер як реле. Це польово-оперативний маршрут: без місії, без підписки, просто оператор передає набір оператору поруч.

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

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

7. версіонування та цілісність

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

Така поведінка заміни надійна лише тоді, коли ви використовуєте її свідомо. Класична польова невдача — це розростання застарілих оверлеїв: кожна ревізія плану відправлена з новим uid, тож пристрій накопичує дванадцять трохи різних оверлеїв меж, і оператор не може зрозуміти, який актуальний. Дисципліни, що запобігають цьому, прості — тримайте стабільний uid на логічний артефакт через усі ревізії, встановлюйте onReceiveDelete="true", щоб видалення пакета прибирало його вміст, і трактуйте простір імен uid маніфесту як керований актив, а не випадковий UUID на кожен експорт.

8. програмна побудова пакетів

Генерувати пакети вручну в клієнті прийнятно для одного оператора; це не масштабується до конвеєра, який має надсилати продукти планування на сотню пристроїв за розкладом. Хороша новина в тому, що формат тривіально автоматизується. Програмна побудова пакета — це три кроки: зібрати файли корисного навантаження, записати MANIFEST.xml з правильним version, стабільним uid і одним записом <Content> на кожне корисне навантаження, потім запакувати їх у zip разом із маніфестом за шляхом, який очікує клієнт (за угодою під каталогом MANIFEST/).

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

Архітектурний урок віддзеркалює те, що ми кажемо про кожну інтеграцію TAK: тримайте генератор пакетів поза вашою основною доменною моделлю. Ваша система планування має володіти планами; тонкий адаптер має транслювати план у маніфест і zip. Коли ревізія схеми маніфесту змінюється чи додається новий тип вмісту, ви оновлюєте адаптер, а не планувальник — і решта ланцюжка розповсюдження, від Enterprise Sync до пристрою, ніколи не потребує про це знати.