TAK-ekosysteemi siirtää paljon sisältöä, joka ei ole Cursor on Target -seurantajälki: peittokuvia, kuvamateriaalia, geoaitoja, reittisuunnitelmia, liitännäispäivityksiä ja varmennenippuja. Mekanismi, joka kuljettaa kaiken tämän, on datapaketti — tavallinen zip-tiedosto ja manifesti. Pakettimuodon ymmärtäminen on ero kaluston välillä, joka jakaa yhteisen tilannekuvan siististi, ja sen välillä, joka hukkuu vanhentuneisiin peittokuviin ja yhteensopimattomiin karttatasoihin. Tämä on tekninen läpikäynti siitä, miten datapaketit ja tehtäväpaketit on rakennettu, miten TAK Server synkronoi ne ja miten ne luodaan putkessa.

1. mikä datapaketti on

TAK-datapaketti on zip-arkisto, joka sisältää yhden pakollisen tiedoston — MANIFEST.xml — ja mielivaltaisen joukon kyseisen manifestin viittaamia hyötykuormatiedostoja. Siinä on koko määritelmä. Zip on kuljetuskontti; manifesti on indeksi, joka kertoo ATAK:lle, WinTAK:lle tai iTAK:lle, mitä sisällä on ja miten kukin kohde käsitellään vastaanotettaessa. Koska muoto on vain zip plus XML-kuvaus, datapaketti on yleinen sisällönvaihdon yksikkö koko TAK-perheessä: kaikki, mitä asiakas voi piirtää tai asentaa, voidaan kääriä siihen.

Kun asiakas tuo paketin, se purkaa zipin sovelluksen työhakemistoon, jäsentää manifestin ja ohjaa kunkin sisältömerkinnän alijärjestelmälle, joka sen omistaa. KML menee peittokuvanhallintaan, CoT XML menee kartalle karttakohteina, kuvatiedosto menee datavarastoon, APK menee liitännäisasentajalle. Itse paketti on tilapäinen — kerran tuotuna asiakas säilyttää puretut artefaktit, ei zipiä. Tämä yksi suunnitteluratkaisu (manifestipohjainen ohjaus) on se, joka antaa yhden kontin kuljettaa heterogeenisen nipun ja saada jokainen osa päätymään oikeaan paikkaan.

2. MANIFEST.xml

Manifesti on pieni XML-dokumentti, jossa on kaksi ylimmän tason osiota juuri-<MissionPackageManifest>-elementin alla. Ensimmäinen on <Configuration>, lista <Parameter>-elementtejä, jotka kuvaavat pakettia kokonaisuutena. Kaksi aina esiintyvää ovat uid (yksilöivä tunniste, perinteisesti UUID, jota asiakas käyttää aiempien tuontien deduplikointiin ja korvaamiseen) ja name (paketin tuojassa näytettävä ihmisluettava nimike). Kolmas yleinen parametri on onReceiveDelete — totuusarvo, joka true-arvoisena kertoo vastaanottavalle asiakkaalle poistamaan paketin sisällön automaattisesti, kun paketti poistetaan, sen sijaan että sen artefaktit jätettäisiin jälkeen.

Toinen osio on <Contents>, lista <Content>-merkintöjä. Jokaisella merkinnällä on zipEntry-attribuutti, joka antaa hyötykuormatiedoston polun zipin sisällä, ja ignore-attribuutti, joka ohjaa, käsitteleekö asiakas tiedoston tuotuna sisältönä vai pelkkänä tukiresurssina. Sisältömerkinnöillä voi myös olla sisäkkäisiä parametreja — esimerkiksi CoT-tiedosto voi ilmoittaa oman uid:nsa, jolloin asiakas yhdistää sen tiettyyn karttakohteeseen. Minimaalinen manifesti näyttää tältä:

<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"-attribuutilla on merkitystä: se valitsee manifestin skeeman, jota vasten asiakas jäsentää, ja sen väärin saaminen on yleisin syy siihen, että käsin rakennettu paketti epäonnistuu tuonnissa hiljaisesti.

3. datapaketit vs. tehtäväpaketit

Termejä käytetään väljästi, mutta ero on todellinen ja arkkitehtoninen. Datapaketti on yleinen zip-plus-manifesti-artefakti — ad hoc -nippu, jonka annat toiselle operaattorille. Tehtäväpaketti on sama artefakti silloin, kun se on sidottu pysyvään, palvelinpohjaiseen tehtävään TAK Serverissä. Konttimuoto on identtinen; ero on elinkaaressa ja omistajuudessa.

Ad hoc -datapaketti on aseta-ja-unohda: rakennat sen, lähetät sen, vastaanottaja tuo sen, eikä lähettäjän kopion ja vastaanottajan kopion välillä ole enää mitään suhdetta. Tehtäväpaketti elää tehtävän sisällä — nimetty, käyttöoikeuksin hallittu kokoelma palvelimella, johon asiakkaat tilaavat. Kun tehtävä muuttuu, jokaiselle tilaajalle ilmoitetaan ja se hakee deltan. Käytä ad hoc -datapakettia, kun tarvitset kertaluonteisen siirron kahden tai kolmen operaattorin välillä kentällä. Käytä tehtävää, kun tarvitset yksikön laajuisen, jatkuvasti päivitettävän jaetun kuvan, jonka uudet liittyjät voivat hakea kokonaan ja joka selviää asiakkaan uudelleenasennuksesta.

4. paketin sisältö

Paketti voi kuljettaa käytännössä mitä tahansa artefaktia, jonka TAK-asiakkaat ymmärtävät. Yleiset hyötykuormat:

CoT-tapahtumat. Staattinen Cursor on Target -XML — pisteet, alueet, reitit — joka materialisoituu karttakohteiksi tuonnissa. Näin toimitat ennalta suunnitellun joukon hallintatoimenpiteitä tai kiinteän ryhmityksen omista positioista.

KML/KMZ-peittokuvat. Vektoripeittokuvat rajoille, vaihelinjoille, tulenkieltoalueille ja käytäville. KMZ niputtaa oman viitatun kuvamateriaalinsa ja tyylittelynsä, joten se matkustaa hyvin paketin sisällä.

Kuvamateriaali ja taustakartat. GeoTIFF-, MBTiles- ja GeoPackage-laattajoukot toiminta-alueen offline-karttapeittoa varten — usein ylivoimaisesti suurin kohde paketissa ja syy siihen, miksi paketin koon kuri on tärkeää.

Geoaidat. CoT-tapahtuma geoaita-attribuuteilla, jotka asiakas aktivoi hälyttävänä rajana — läpäisy- ja saapumisilmoitukset laukeavat paikallisesti laitteella. Geoaitapaketti on vakiotapa työntää pysyviä hälytysvyöhykkeitä ryhmälle.

Varmenteet. Asiakkaan ilmoittautumis- ja luottamusvarastonipput, joita käytetään laitteen liittämiseen TAK Serveriin oikean CA-ketjun ja asiakasvarmenteen kanssa yhdellä tuonnilla.

Liitännäis-APK:t. ATAK-liitännäisten binäärit, jotka toimitetaan niin, että operaattori voi asentaa tai päivittää kyvykkyyden ilman sovelluskauppaa. Näiden liitännäisten rakentaminen on oma erikoisalansa — katso muistiomme ATAK/WinTAK-liitännäisten kehityksestä — mutta niiden jakelu on vain yksi sisältömerkintä manifestissa.

Keskeinen oivallus: Datapaketti ei ole semantiikkaa sisältävä tiedostomuoto — se on kirjekuori. Älykkyys elää kokonaan manifestissa. Kaksi pakettia, joissa on tavuidenttiset hyötykuormat mutta erilaiset uid-, onReceiveDelete- ja ignore-arvot, käyttäytyvät täysin eri tavoin vastaanottavalla laitteella. Kun paketit toimivat huonosti kentällä, vianhae manifesti ensin, ei koskaan hyötykuormaa.

5. TAK Serverin datasynkronointi

Palvelinpuolella tehtävien takana oleva koneisto on Enterprise Sync -varasto — sisältöosoitteinen objektivarasto, joka avaimitetaan tiedoston tiivisteellä. Jokainen palvelimelle ladattu artefakti tallennetaan kerran tiivisteensä alle; tehtävät viittaavat sitten näihin tiivisteisiin sen sijaan, että ne pitäisivät kopioita. Tehtävä on metadataa plus lista sisältöviittauksia ja muutosvirta.

Asiakkaat ovat vuorovaikutuksessa pienen tehtävä-API-joukon kautta. Asiakas tilaa tehtävän ja vastaanottaa sitten muutosvirtatapahtumia — sisältöä lisätty, sisältöä poistettu, tehtävän tiedot päivitetty — CoT-viesteinä olemassa olevan palvelinyhteytensä kautta. Kun olennainen muutos saapuu, asiakas hakee uuden sisällön Enterprise Syncistä tiivisteellä. Koska varasto on sisältöosoitteinen, laitteella jo olevaa tiedostoa ei koskaan ladata uudelleen: tiivisteen täsmäys oikosulkee siirron. Tämä on se, mikä saa tehtävän skaalautumaan kokonaiseen yksikköön — vain deltat liikkuvat, ja identtiset artefaktit deduplikoidaan päästä päähän.

6. jakelupolut

On kolme käytännöllistä tapaa, joilla sisältö saavuttaa laitteen. Ensimmäinen on vertaissiirto — QuickPic / "lähetä kontaktille" -polku, jossa yksi asiakas zippaa paketin ja työntää sen suoraan toiselle asiakkaalle TAK-mesh-verkon yli tai palvelimen kautta välityksenä. Tämä on kenttäkelpoinen reitti: ei tehtävää, ei tilausta, vain operaattori, joka ojentaa nipun vieressä olevalle operaattorille.

Toinen on palvelimelle lataus ja sieltä lataus. Operaattori tai ulkoinen järjestelmä lataa paketin TAK Serveriin; muut asiakkaat lataavat sen tarpeen mukaan datapakettilistasta. Tämä erottaa tuottajan kuluttajasta ajassa — paketti odottaa palvelimella, kunnes joku hakee sen.

Kolmas on tehtävän automaattinen tuonti. Tehtävän tilaaja vastaanottaa uudet tehtäväpaketit automaattisesti: muutosvirta ilmoittaa asiakkaalle, asiakas hakee sisällön, ja se ilmestyy kartalle ilman operaattorin toimia. Yksikölle, joka ajaa jaettua tehtävää, tämä on polku, joka pitää kaikki ajan tasalla ilman, että kukaan lähettää tiedostoja manuaalisesti. Liittovaltaistetut palvelimet laajentavat tätä edelleen — katso TAK Server -liittovaltaistus siitä, miten tehtävät ja niiden sisältö leviävät liittovaltaisuusrajan yli.

7. versiointi ja eheys

Tiiviste, joka tukee Enterprise Synciä, on myös eheystakuu: paketin sisältö tunnistetaan sen tiivisteellä, joten vioittunut tai peukaloitu tiedosto ei yksinkertaisesti täsmää viittaukseen eikä sitä hyväksytä. Asiakkaalla paketin uid on versiointikahva. Tuo paketti uudelleen samalla uid:lla ja asiakas korvaa aiemman tuonnin sen sijaan, että pinoaisi kaksoiskappaleen — näin työnnät päivitetyn peittokuvan jättämättä vanhaa jälkeen.

Tuo korvauskäyttäytyminen on luotettavaa vain, jos käytät sitä tarkoituksella. Klassinen kenttävika on vanhentuneiden peittokuvien rönsyäminen: jokainen suunnitelman versio toimitetaan tuoreena uid:na, jolloin laitteelle kertyy kaksitoista hieman erilaista rajapeittokuvaa eikä operaattori voi sanoa, mikä on ajankohtainen. Sitä estävät kurinalaisuudet ovat yksinkertaisia — pidä vakaa uid loogista artefaktia kohden versioiden välillä, aseta onReceiveDelete="true", jotta paketin poistaminen siivoaa sen sisällön, ja kohtele manifestin uid-nimiavaruutta hallittuna omaisuutena, ei satunnaisena UUID:na per vienti.

8. pakettien rakentaminen ohjelmallisesti

Pakettien luominen käsin asiakkaassa on hyvä yhdelle operaattorille; se ei skaalaudu putkeen, jonka on työnnettävä suunnittelutuotteita sadalle laitteelle aikataulun mukaan. Hyvä uutinen on, että muoto on triviaalisti automatisoitavissa. Paketin rakentaminen ohjelmallisesti on kolme vaihetta: kokoa hyötykuormatiedostot, kirjoita MANIFEST.xml oikealla versionilla, vakaalla uid:lla ja yhdellä <Content>-merkinnällä per hyötykuorma, ja zippaa ne sitten yhteen manifestin kanssa polkuun, jota asiakas odottaa (perinteisesti MANIFEST/-hakemiston alle).

Palvelinpuolen automaatiota varten tehtävä- ja Enterprise Sync -API:t antavat putken ladata sisältöä tiivisteellä, luoda tai päivittää tehtävän ja liittää siihen sisältöä — kaikki ilman ihmistä silmukassa. Suunnittelujärjestelmä voi luoda peittokuvan, pakata sen, ladata sen tehtävään ja saada jokaisen tilatun laitteen päivittymään sekunneissa. Toimiva malli on kohdella paketin luontia rakennusvaiheena: deterministiset manifestit, vakaat UID:t loogiseen tuotteeseen avaimitettuna ja sisältöosoitteinen lataus, jolloin uudelleenajot, jotka tuottavat identtiset tavut, ovat tyhjäkäyntejä linjalla.

Arkkitehtoninen oppitunti heijastaa sitä, mitä sanomme jokaisesta TAK-integraatiosta: pidä paketin luoja erossa ydindomain-mallistasi. Suunnittelujärjestelmäsi tulisi omistaa suunnitelmat; ohuen sovittimen tulisi kääntää suunnitelma manifestiksi ja zipiksi. Kun manifestin skeeman revisio muuttuu tai uusi sisältötyyppi lisätään, päivität sovittimen, et suunnittelijaa — ja loppuosa jakeluketjusta, Enterprise Syncistä laitteeseen, ei koskaan tarvitse tietää.