Cursor on Target -skeema, kenttä kentältä

Cursor on Target on pienin skeema, joka tekee eniten työtä nykyaikaisessa taktisessa ohjelmistossa. Yksi XML-dokumentti — muutama sata tavua — kantaa sijainnin, identiteetin, luotettavuuden ja eliniän, ja tuo dokumentti riittää asettamaan merkin jokaiselle mesh-verkon kartalle. Se sai alkunsa MITRE-hankkeena, jonka tarkoituksena oli antaa operaattorin siirtää maali järjestelmästä toiseen kirjaimellisella kursorieleellä, ja siitä tuli TAK-ekosysteemin yhteinen kieli. Tämä on kenttä kentältä etenevä katsaus Cursor on Target -formaattiin: event-malli, tyyppitaksonomia, point-geometria, detail-säiliö sekä sen oikean generoinnin ja validoinnin realiteetit.

1. CoT-event-malli

Jokainen CoT-viesti on yksi <event>-elementti. Ei kuorta, ei otsaketta, ei erillistä viestityyppirekisteriä — juurielementti on viesti. Tämä on tarkoituksellinen suunnitteluvalinta, joka tekee CoT:stä halvan: yksi rekursiivinen skeema kantaa ystävällisen sotilaan, vihollisen ajoneuvon, geoaidan, chat-viestin, hätämajakan ja sensorijäljen ilman viestityyppikohtaista koodipolkua langalla.

Event sisältää tasan yhden <point>-lapsen (missä asia on) ja valinnaisen <detail>-lapsen (kaikki muu siitä). Eventin semantiikan määräävät täysin sen attribuutit sekä <detail>-elementin avoin sisältö. Jäsennin, joka ymmärtää neljä ydinattribuuttia ja pointin, pystyy piirtämään minkä tahansa CoT-viestin kartalle ymmärtämättä ainuttakaan detail-laajennusta — tuo armollisen rappeutumisen ominaisuus on syy siihen, miksi CoT skaalautuu eri toimittajien välillä, jotka eivät koskaan koordinoineet keskenään.

Kannattaa pysähtyä siihen, mitä mallissa ei ole. Ei ole skeematason eroa yksikön, merkin, chat-viestin ja sensorijäljen välillä — ne ovat kaikki eventejä, jotka erottuvat ainoastaan type-attribuuttinsa ja kantamiensa detail-lasten perusteella. Ei ole kuittausta, ei järjestysnumeroa eikä istuntoa. CoT on ammu ja unohda; luotettavuus, järjestys ja toimitus työnnetään alas siirtokerrokselle (TCP, TLS tai multicast-UDP) ja sen yläpuolella olevalle sovellukselle. Tuo minimalismi on skeeman määrittävä ominaisuus: se tekee yhden asian — kertoo missä jokin on ja mikä se on, rajatun ajan — ja kieltäytyy kasvattamasta omaa protokollapinoaan.

2. event-attribuutit

<event>-elementti kantaa kiinteän joukon attribuutteja. version on skeeman versio, lähes aina 2.0. uid on kuvattavan asian globaalisti yksilöivä tunniste — ei viestin, vaan asian. Saman entiteetin päivitetyn sijainnin uudelleenlähetys käyttää samaa uid-arvoa; juuri näin vastaanottaja tietää siirtää olemassa olevaa merkkiä uuden synnyttämisen sijaan. UID:t ovat vapaamuotoisia merkkijonoja, mutta TAK-asiakkaat käyttävät tavanomaisesti vakaata laitekohtaista tunnistetta (esim. ANDROID-serial) omille raporteilleen.

type on MITRE-tyyppimerkkijono (kohta 3). how kuvaa datan alkuperää — miten sijainti johdettiin. Yleisiä arvoja ovat h-g-i-g-o (ihminen, GPS-johdettu, manuaalisesti syötetty) ja m-g (kone, GPS). how-kenttä mahdollistaa sen, että fuusiomoottori painottaa käsin näpäteltyä spot-raporttia eri tavalla kuin live-GPS-syötettä.

Elinkaarikolmikko on time, start ja stale, kaikki ISO 8601 UTC -aikaleimoja. time on hetki, jolloin viesti tuotettiin. start on hetki, jolloin tieto tulee voimaan. stale on hetki, jolloin se vanhenee. Ikkuna start:in ja stale:n välillä on eventin voimassaoloaika: kun stale ohittuu, sääntöjenmukaisen vastaanottajan on kohdeltava eventiä vanhentuneena ja poistettava tai harmaannutettava merkki. Liikkuvan yksikön omasijaintiraportti saattaa asettaa stale:n arvoon time + 75 sekuntia; staattinen mittauspiste saattaa asettaa sen tunteja eteenpäin. Tämän kolmikon saaminen oikein on yleisin "haamumerkkien" lähde — aseta stale liian kauas tulevaisuuteen ja kuolleet jäljet viipyvät; aseta se liian lyhyeksi ja elävät jäljet vilkkuvat.

3. MITRE-tyyppihierarkia

type-attribuutti koodaa sen, mikä asia on käyttäen MITRE:n pisteellistä, väliviivallista taksonomiaa. Tärkein perhe on atom-tyyppi, etuliitteellä a-. Atom-tyyppi luetaan väliviivoin eroteltujen tokenien jonona: a-f-G-U-C.

Ensimmäinen token a:n jälkeen on liittouma: f ystävä, h vihollinen, n neutraali, u tuntematon, p odottava, sekä oletetut/epäillyt muunnelmat. Seuraava token on taisteludimensio: G maa, A ilma, S pinta (meri), U pinnanalainen, P avaruus, F erikoisjoukot. Loput tokenit poraavat MIL-STD-2525-symbolihierarkiaa alaspäin — a-f-G-U-C on ystävällinen maayksikkö, taistelu, ja niin edelleen. Jokerimerkki a-f-G-* tarkoittaa "ystävällinen maa-asia, sen yli määrittelemätön", ja renderöijät putoavat takaisin lähimpään määriteltyyn symboliin. Atomiin kuulumattomat perheet käyttävät eri etuliitteitä: b- biteille (sensori-/geometriadata, esim. b-m-p-s-p-i kiinnostavalle sensoripisteelle), t- tehtävänannolle ja y- vastauksille. Pisteellisen taksonomian nerokkuus on siinä, että se on etuliitteestä dekoodattavissa: asiakas, joka tuntee vain a-f-G:n, voi silti asettaa geneerisen ystävällisen maa-ikonin ja rappeutua armollisesti sen hännän kohdalla, jota se ei tunnista.

4. point-elementti

<point>-elementti on pakollinen ja kantaa viittä attribuuttia, kaikki vaadittuja. lat ja lon ovat WGS-84-desimaaliasteita. hae on korkeus ellipsoidin yläpuolella metreinä — huomaa "ellipsoidin yläpuolella", ei keskimääräisen merenpinnan yläpuolella; HAE:n ja ortometrisen korkeuden sekoittaminen (geoidipoikkeama voi ylittää 30 m) on klassinen pystysuuntaisen virheen bugi, kun CoT kohtaa järjestelmän, joka odottaa MSL:ää.

ce on ympyrävirhe — vaakasuuntainen 1-sigma-epävarmuussäde metreinä. le on lineaarivirhe — pystysuuntainen epävarmuus metreinä. Yhdessä ne antavat vastaanottajan piirtää tarkkuusrenkaan harhaanjohtavan tarkan pistenäpäytyksen sijaan. Vartija-arvo 9999999 (usein kirjoitettu 9999999.0) tarkoittaa "tuntematonta" — se ei ole oikea mittaus, se on skeeman null. Käsin pudotettu piste ilman mitattua tarkkuutta kantaa ce="9999999" le="9999999", ja fuusiologiikan on käsiteltävä tuo arvo erikoistapauksena sen sijaan, että se kohtelisi sitä 10 000 kilometrin virheenä.

Koska jokainen attribuutti on vaadittu, ei ole olemassa pistettä ilman korkeutta tai ilman virhearviota — skeema pakottaa tuottajan tekemään väitteen, vaikka tuo väite olisi "tuntematon". Tämä on hiljaisesti hyvä suunnittelupäätös: vastaanottajan ei koskaan tarvitse arvailla, tarkoittaako puuttuva kenttä nollaa, tuntematonta vai oletusarvoa. Sillä on joko oikea luku tai vartija-arvo, ja nämä kaksi ovat yksiselitteisiä. Hinta on se, että laiskat enkooderit koodaavat kovakoodattuna hae="0.0":n kaikelle, mikä on pahempaa kuin vartija-arvo, koska se näyttää oikealta merenpinnan tasoiselta mittaukselta. Jos et tiedä korkeutta, sano se arvolla 9999999; älä väitä nollaa.

5. detail-elementti

<detail>-elementti on avoin laajennussäiliö, ja siinä CoT:n ekosysteemi todella elää. Skeema ei aseta sen lapsille mitään rajoitetta — mikä tahansa hyvin muodostettu XML on laillista — mikä mahdollisti sen, että TAK saattoi kerrostaa rikkaan sovellusprotokollan geneerisen tilannekuvaformaatin päälle haarauttamatta sitä.

Tavanomaisia alielementtejä noudatetaan laajasti. <contact> kantaa ihmisluettavan callsign:n ja TAK:n osalta päätepisteosoitteistuksen suoraviestintää varten. <track> kantaa course:n ja speed:n liikkuville entiteeteille, muuttaen staattisen pisteen vektoriksi. <remarks> on vapaata tekstiä. <status> raportoi asioita kuten akun varaustason. <__group> (kaksi alaviivaa) liittää yksikön TAK-tiimivärille ja -roolille — Cyan, Team Member — ohjaten ikonin väriä jokaisen joukkuetoverin näytöllä. <takv> raportoi TAK-asiakkaan version, laitteen ja alustan. Koska detail on avoin, vastaanottaja yksinkertaisesti ohittaa ne lapset, joita se ei tunnista, mikä on koko perusta CoT:n ja TAK:n yhteentoimivuudelle heterogeenisten asiakkaiden välillä.

6. CoT vs. Link 16 ja VMF

CoT vie saman käsitteellisen tilan kuin J-sarja ja VMF, mutta vastakkaisin suunnitteluprioriteetein. Link 16:n J-viestit ovat kiinteämuotoisia bittipakattuja sanoja, jotka on mitoitettu TDMA-aikaväliin; VMF (MIL-STD-6017) on muuttuva mutta tiukasti bittiorientoitunut formaatti vähäkaistaisille kantajille. CoT on monisanainen XML, joka on rakennettu IP-verkoille, joissa tavut ovat halpoja ja kehittäjäaika ei.

CoT:n kuvaaminen J-viestiksi on häviöllistä molempiin suuntiin. CoT:n liittouma ja taisteludimensio kuvautuvat siististi J3.x-jälkikenttiin ja VMF-identiteettikenttiin, ja lat/lon/hae kääntyvät suoraan. Impedanssiristiriita asuu tarkkuudessa ja semantiikassa: J-sarjan jälkilaatu on diskreetti luetteloitu arvo, kun taas CoT:n ce/le ovat jatkuvia metrejä; CoT:n avoimella <detail>:lla ei ole kiinteämuotoista vastinetta ja se putoaa kokonaan pois yhdyskäytävällä. Käänteisesti J-sarjan kentillä kuten tietyillä IFF-tiloilla tai PPLI-johdetulla verkko-osallistumisella ei ole natiivia CoT-paikkaa, ja ne on salakuljetettava mukautettuihin detail-laajennuksiin. Yhdyskäytävät, jotka siltaavat CoT:n ja taktiset datalinkit, kantavat siksi mielipiteellistä, käsin ylläpidettyä kenttäkartoitusta — sama mielipiteellinen kääntäjäongelma, joka ilmenee kaikkialla NATO C2:ssa.

7. striimaus ja TAK

Tuotannossa CoT on virta, ei dokumentti. TAK Server multipleksoi CoT-eventit asiakkaiden välillä: yksikön omasijaintiraportti virtaa ylös pysyvän TCP-yhteyden (usein TLS) yli konfiguroitavalla nopeudella — yleisesti joka 1–10 sekunti riippuen liikkeestä ja "dynaamisen raportoinnin" asetuksesta — ja palvelin levittää sen tilaajille, valinnaisesti suodatettuna tehtävän, ryhmän tai geoaidan mukaan. Mesh SA, palvelimeton tila, multicast-lähettää samat eventit UDP:llä paikallisverkossa, joten ryhmä toimii ilman infrastruktuuria.

Viestinopeudet ohjaavat suunnittelua. 200 solmun harjoitus, jossa kaikki raportoivat joka 2. sekunti, on 100 eventiä/sekunti pelkkää omasijaintia, ennen sensorijälkiä. Palvelin ei ylläpidä poistoprotokollaa millekään tästä; sen sijaan jokainen asiakas kerää roskaa itsenäisesti näkemiensä stale-aikaleimojen perusteella. Stale-ohjattu roskankeruu on elegantti — ei johtajaa, ei konsensusta — mutta se tarkoittaa, että yhteyden menettävä asiakas katselee koko kuvansa vanhenevan ja katoavan aikataulun mukaan, mikä on yleensä oikea käyttäytyminen ja toisinaan ikävä yllätys yhteyskatkon aikana.

8. CoT:n validointi ja generointi

Lankaformaatti on anteeksiantava, mikä tekee hienovaraisesti rikkinäisen CoT:n tuottamisesta helppoa. Validoi julkaistua Event.xsd-skeemaa vastaan kehityksen aikana, mutta tunne sen rajat: XSD tarkistaa, että point on olemassa ja että elinkaariattribuutit ovat läsnä ja hyvin tyypitetyt, mutta se ei voi kertoa, että stale on ennen start:ia, että type-tokenisi on merkityksetön, tai että hae:si on geoidikorkeus ellipsoidikorkeudeksi naamioituneena.

Toistuvat väärinmuodostetun viestin bugit ovat ennustettavissa. Aikaleimat ilman perässä olevaa Z:aa tai paikallisvyöhykkeen poikkeamilla — CoT-aika on UTC, piste, ja puuttuva Z lähettää merkit menneisyyteen tai tulevaisuuteen. Käänteiset elinkaaret, joissa stale edeltää start:ia, tuottaen eventejä, jotka ovat kuolleita saapuessaan. Yhden uid:n uudelleenkäyttö erillisille entiteeteille, mikä saa kaksi oikeaa jälkeä romahtamaan yhdeksi vilkkuvaksi merkiksi. Oikealta näyttävän ce:n lähettäminen 9999999-vartija-arvon sijaan mittaamattomalle pisteelle, mikä huijaa fuusiota luottamaan roskaan. Kun rakennat CoT-enkooderin, tee elinkaarikolmikosta ensiluokkainen tyyppi, joka pakottaa start ≤ stale ja renderöi UTC:n Z:lla, generoi UID:t vakaasta entiteettiavaimesta viestikohtaisen laskurin sijaan, ja lähetä tuntemattoman vartija-arvo eksplisiittisesti. Saa nämä neljä invarianttia oikein, niin CoT:si toimii yhteen asiakkaiden kanssa, joita et ole koskaan nähnyt — mikä on formaatin koko tarkoitus.