Pakiety danych i pakiety misji TAK: struktura i dystrybucja

Ekosystem TAK przenosi mnóstwo treści, które nie są śladem Cursor on Target: nakładki, obrazy, geofence, plany tras, aktualizacje wtyczek i pakiety certyfikatów. Mechanizmem, który to wszystko przenosi, jest pakiet danych — zwykły plik zip z manifestem. Zrozumienie formatu pakietu to różnica między flotą, która czysto współdzieli wspólny obraz operacyjny, a taką, która tonie w przestarzałych nakładkach i niedopasowanych warstwach mapy. To inżynierski przegląd tego, jak zbudowane są pakiety danych i pakiety misji, jak TAK Server je synchronizuje oraz jak generować je w potoku.

1. czym jest pakiet danych

Pakiet danych TAK to archiwum zip zawierające jeden wymagany plik — MANIFEST.xml — oraz dowolny zbiór plików ładunku, do których odwołuje się ten manifest. To cała definicja. Zip jest kontenerem transportowym; manifest to indeks, który informuje ATAK, WinTAK lub iTAK, co znajduje się w środku i jak obsłużyć każdy element po odbiorze. Ponieważ format to tylko zip plus deskryptor XML, pakiet danych jest uniwersalną jednostką wymiany treści w całej rodzinie TAK: cokolwiek klient potrafi wyświetlić lub zainstalować, można w niego opakować.

Gdy klient importuje pakiet, rozpakowuje go do katalogu roboczego aplikacji, parsuje manifest i kieruje każdy wpis treści do podsystemu, który nim zarządza. KML trafia do menedżera nakładek, CoT XML trafia na mapę jako elementy mapy, plik obrazu trafia do magazynu danych, APK trafia do instalatora wtyczek. Sam pakiet jest efemeryczny — po zaimportowaniu klient zachowuje wyodrębnione artefakty, a nie zip. Ta jedna decyzja projektowa (dyspozycja sterowana manifestem) sprawia, że jeden kontener może przenosić heterogeniczny zestaw, a każdy element trafia we właściwe miejsce.

2. plik MANIFEST.xml

Manifest to mały dokument XML z dwiema sekcjami najwyższego poziomu pod elementem głównym <MissionPackageManifest>. Pierwsza to <Configuration>, lista elementów <Parameter> opisujących pakiet jako całość. Dwa, które zawsze się pojawiają, to uid (unikalny identyfikator, zwyczajowo UUID, którego klient używa do deduplikacji i zastępowania wcześniejszych importów) oraz name (czytelna dla człowieka etykieta wyświetlana w importerze pakietów). Trzecim częstym parametrem jest onReceiveDelete — wartość logiczna, która, gdy jest true, nakazuje klientowi odbierającemu automatyczne usunięcie zawartości pakietu po jego usunięciu, zamiast pozostawiania jego artefaktów.

Druga sekcja to <Contents>, lista wpisów <Content>. Każdy wpis ma atrybut zipEntry podający ścieżkę pliku ładunku wewnątrz zipa oraz atrybut ignore, który kontroluje, czy klient traktuje plik jako zaimportowaną treść, czy jedynie jako zasób pomocniczy. Wpisy treści mogą również zawierać zagnieżdżone parametry — na przykład plik CoT może zadeklarować własny uid, aby klient zmapował go do konkretnego elementu mapy. Minimalny manifest wygląda tak:

<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>

Atrybut version="2" ma znaczenie: wybiera schemat manifestu, względem którego klient parsuje, a ustawienie go błędnie to najczęstsza przyczyna, dla której ręcznie zbudowany pakiet po cichu nie importuje się.

3. pakiety danych a pakiety misji

Terminy używane są swobodnie, ale rozróżnienie jest realne i architektoniczne. Pakiet danych to generyczny artefakt zip-plus-manifest — doraźny zestaw, który przekazujesz innemu operatorowi. Pakiet misji to ten sam artefakt, gdy jest powiązany z trwałą, wspieraną przez serwer misją na TAK Server. Format kontenera jest identyczny; różni się cykl życia i własność.

Doraźny pakiet danych działa na zasadzie „wyślij i zapomnij”: budujesz go, wysyłasz, odbiorca importuje go i nie ma dalszej relacji między kopią nadawcy a kopią odbiorcy. Pakiet misji żyje wewnątrz misji — nazwanej, kontrolowanej dostępowo kolekcji na serwerze, którą klienci subskrybują. Gdy misja się zmienia, każdy subskrybent jest powiadamiany i pobiera deltę. Użyj doraźnego pakietu danych, gdy potrzebujesz jednorazowego transferu między dwoma lub trzema operatorami w terenie. Użyj misji, gdy potrzebujesz ogólnopododdziałowego, ciągle aktualizowanego wspólnego obrazu, który nowi uczestnicy mogą pobrać w całości i który przetrwa ponowną instalację klienta.

4. zawartość pakietu

Pakiet może przenosić w zasadzie dowolny artefakt, który rozumieją klienci TAK. Najczęstsze ładunki:

Zdarzenia CoT. Statyczny XML Cursor on Target — punkty, obszary, trasy — które materializują się jako elementy mapy po imporcie. Tak właśnie dostarczasz wstępnie zaplanowany zestaw środków kontroli lub stałe rozmieszczenie pozycji własnych.

Nakładki KML/KMZ. Nakładki wektorowe dla granic, linii faz, stref zakazu ognia i korytarzy. KMZ pakuje własne odwołane obrazy i style, więc dobrze podróżuje wewnątrz pakietu.

Obrazy i mapy bazowe. Zestawy kafelków GeoTIFF, MBTiles i GeoPackage do pokrycia mapowego offline obszaru operacji — często zdecydowanie największy element w pakiecie i powód, dla którego dyscyplina rozmiaru pakietu ma znaczenie.

Geofence. Zdarzenie CoT z atrybutami geofence, które klient uzbraja jako granicę alarmującą — powiadomienia o naruszeniu i wejściu uruchamiają się lokalnie na urządzeniu. Pakiet geofence to standardowy sposób przekazywania stałych stref alarmowych drużynie.

Certyfikaty. Pakiety rejestracji klienta i magazynu zaufania, używane do wprowadzenia urządzenia do TAK Server z właściwym łańcuchem CA i certyfikatem klienta w jednym imporcie.

Wtyczki APK. Binaria wtyczek ATAK, dostarczane tak, aby operator mógł zainstalować lub zaktualizować funkcję bez sklepu z aplikacjami. Budowanie tych wtyczek to osobna dyscyplina — zobacz naszą notatkę o inżynierii wtyczek ATAK/WinTAK — ale ich dystrybucja to po prostu kolejny wpis treści w manifeście.

5. synchronizacja danych TAK Server

Po stronie serwera mechanizmem stojącym za misjami jest magazyn Enterprise Sync — magazyn obiektów adresowany treścią, kluczowany hashem pliku. Każdy artefakt przesłany na serwer jest przechowywany raz pod swoim hashem; misje następnie odwołują się do tych hashów, zamiast przechowywać kopie. Misja to metadane plus lista odwołań do treści i strumień zmian.

Klienci współpracują poprzez niewielki zestaw API misji. Klient subskrybuje misję, a następnie odbiera zdarzenia strumienia zmian — dodano treść, usunięto treść, zaktualizowano szczegóły misji — jako wiadomości CoT przez istniejące połączenie z serwerem. Gdy nadejdzie istotna zmiana, klient pobiera nową treść z Enterprise Sync po hashu. Ponieważ magazyn jest adresowany treścią, plik już obecny na urządzeniu nigdy nie jest ponownie pobierany: dopasowanie hasha skraca transfer. To właśnie sprawia, że misja skaluje się do pełnego pododdziału — przenoszą się tylko delty, a identyczne artefakty są deduplikowane od końca do końca.

6. ścieżki dystrybucji

Istnieją trzy praktyczne sposoby, w jakie treść dociera do urządzenia. Pierwszy to transfer peer-to-peer — ścieżka QuickPic / „wyślij do kontaktu”, gdzie jeden klient pakuje pakiet i przesyła go bezpośrednio do innego klienta przez sieć kratową TAK lub przez serwer jako przekaźnik. To droga doraźna polowa: bez misji, bez subskrypcji, po prostu operator przekazuje zestaw operatorowi obok siebie.

Drugi to przesłanie i pobranie z serwera. Operator lub system zewnętrzny przesyła pakiet na TAK Server; inni klienci pobierają go na żądanie z listy pakietów danych. To oddziela producenta od konsumenta w czasie — pakiet czeka na serwerze, aż ktoś go pobierze.

Trzeci to automatyczny import misji. Subskrybent misji otrzymuje nowe pakiety misji automatycznie: strumień zmian powiadamia klienta, klient pobiera treść i pojawia się ona na mapie bez działania operatora. Dla pododdziału prowadzącego wspólną misję to ścieżka, która utrzymuje wszystkich na bieżąco bez ręcznego wysyłania plików przez kogokolwiek. Serwery sfederowane rozszerzają to jeszcze bardziej — zobacz federację TAK Server, aby zobaczyć, jak misje i ich treść propagują się przez granicę federacji.

7. wersjonowanie i integralność

Hash stojący za Enterprise Sync jest również gwarancją integralności: treść pakietu jest identyfikowana przez jej hash, więc uszkodzony lub zmanipulowany plik po prostu nie będzie pasował do odwołania i nie zostanie zaakceptowany. Po stronie klienta uid pakietu jest uchwytem wersjonowania. Ponownie zaimportuj pakiet z tym samym uid, a klient zastąpi wcześniejszy import zamiast układać duplikat — w ten sposób przekazujesz zaktualizowaną nakładkę bez pozostawiania starej.

To zachowanie zastępowania jest niezawodne tylko wtedy, gdy używasz go celowo. Klasyczną porażką polową jest rozrost przestarzałych nakładek: każda rewizja planu wysłana jako świeży uid, więc urządzenie gromadzi dwanaście nieznacznie różniących się nakładek granic, a operator nie potrafi określić, która jest aktualna. Dyscypliny, które temu zapobiegają, są proste — utrzymuj stabilny uid na logiczny artefakt w kolejnych rewizjach, ustaw onReceiveDelete="true", aby usunięcie pakietu sprzątało jego treść, i traktuj przestrzeń nazw uid manifestu jako zarządzany zasób, a nie losowy UUID na eksport.

8. budowanie pakietów programowo

Generowanie pakietów ręcznie w kliencie jest w porządku dla jednego operatora; nie skaluje się do potoku, który musi przekazywać produkty planistyczne na sto urządzeń według harmonogramu. Dobra wiadomość jest taka, że format jest trywialnie automatyzowalny. Budowanie pakietu programowo to trzy kroki: zebranie plików ładunku, zapisanie MANIFEST.xml z poprawnym version, stabilnym uid i jednym wpisem <Content> na ładunek, a następnie spakowanie ich razem z manifestem w ścieżce, której oczekuje klient (zwyczajowo w katalogu MANIFEST/).

W przypadku automatyzacji po stronie serwera API misji i Enterprise Sync pozwalają potokowi przesyłać treść po hashu, tworzyć lub aktualizować misję i dołączać do niej treść — wszystko bez człowieka w pętli. System planistyczny może wygenerować nakładkę, spakować ją, przesłać do misji i sprawić, że każde subskrybowane urządzenie zaktualizuje się w ciągu sekund. Wzorzec, który działa, to traktowanie generowania pakietów jako kroku budowania: deterministyczne manifesty, stabilne UID kluczowane do logicznego produktu i przesyłanie adresowane treścią, tak aby ponowne uruchomienia generujące identyczne bajty były operacjami pustymi na łączu.

Lekcja architektoniczna odzwierciedla to, co mówimy o każdej integracji TAK: trzymaj generator pakietów poza swoim rdzeniem modelu domeny. Twój system planistyczny powinien posiadać plany; cienki adapter powinien tłumaczyć plan na manifest i zip. Gdy zmienia się rewizja schematu manifestu lub dodawany jest nowy typ treści, aktualizujesz adapter, a nie planer — a reszta łańcucha dystrybucji, od Enterprise Sync do urządzenia, nigdy nie musi o tym wiedzieć.