Schema Cursor on Target, câmp cu câmp

Cursor on Target este cea mai mică schemă care face cea mai multă muncă în software-ul tactic modern. Un singur document XML — câteva sute de octeți — transportă o poziție, o identitate, un nivel de încredere și o durată de viață, iar acel document este suficient pentru a plasa un marcaj pe fiecare hartă dintr-o rețea mesh. A apărut ca un efort MITRE pentru a permite unui operator să transmită o țintă de la un sistem la altul printr-un gest literal de cursor și a devenit lingua franca a ecosistemului TAK. Aceasta este o parcurgere câmp cu câmp a formatului Cursor on Target: modelul event, taxonomia de tipuri, geometria point, containerul detail și realitățile generării și validării sale corecte.

1. modelul de event CoT

Fiecare mesaj CoT este un singur element <event>. Nu există anvelopă, nu există antet, nu există un registru separat de tipuri de mesaje — elementul rădăcină este mesajul. Aceasta este alegerea de proiectare deliberată care face CoT ieftin: o singură schemă recursivă transportă un soldat prieten, un vehicul ostil, un geofence, un mesaj de chat, o baliză de urgență și o pistă de senzor, fără o cale de cod per-tip-de-mesaj pe fir.

Event-ul conține exact un copil <point> (unde se află obiectul) și un copil opțional <detail> (tot ce ține de el). Semantica unui event este complet determinată de atributele sale plus conținutul deschis al <detail>. Un parser care înțelege cele patru atribute de bază și point-ul poate reda orice mesaj CoT pe o hartă fără a înțelege nicio extensie detail — acea proprietate de degradare grațioasă este motivul pentru care CoT scalează între furnizori care nu s-au coordonat niciodată.

Merită să zăbovim asupra a ceea ce nu se află în model. Nu există o distincție la nivel de schemă între o unitate, un marcaj, un mesaj de chat și o pistă de senzor — toate acestea sunt event-uri, diferențiate doar prin type-ul lor și prin copiii detail pe care îi transportă. Nu există confirmare, nu există număr de secvență și nu există sesiune. CoT este fire-and-forget; fiabilitatea, ordonarea și livrarea sunt împinse în jos către transport (TCP, TLS sau UDP multicast) și către aplicația de deasupra. Acest minimalism este proprietatea definitorie a schemei: face un singur lucru — spune unde se află ceva și ce este, pentru un timp delimitat — și refuză să-și dezvolte o stivă de protocoale proprie.

2. atributele event

Elementul <event> poartă un set fix de atribute. version este versiunea schemei, aproape întotdeauna 2.0. uid este identificatorul unic global pentru obiectul descris — nu mesajul, ci obiectul. Retrimiterea unei poziții actualizate pentru aceeași entitate reutilizează același uid; astfel un receptor știe să mute un marcaj existent în loc să creeze unul nou. UID-urile sunt șiruri în formă liberă, dar clienții TAK folosesc în mod convențional un identificator stabil per-dispozitiv (de ex. ANDROID-serial) pentru auto-raportări.

type este șirul de tip MITRE (Secțiunea 3). how descrie proveniența datelor — cum a fost derivată poziția. Valori comune sunt h-g-i-g-o (uman, derivat din GPS, introdus manual) și m-g (mașină, GPS). Câmpul how este ceea ce permite unui motor de fuziune să pondereze un raport de poziție introdus manual diferit față de un flux GPS live.

Triada de ciclu de viață este time, start și stale, toate marcaje temporale ISO 8601 UTC. time este momentul în care a fost produs mesajul. start este momentul în care informația devine validă. stale este momentul în care expiră. Fereastra dintre start și stale este durata de validitate a event-ului: după ce trece stale, un receptor conform trebuie să trateze event-ul ca expirat și să elimine sau să atenueze marcajul. Un raport de auto-poziție de la o unitate în mișcare ar putea seta stale la time + 75 de secunde; un punct de relevare static l-ar putea seta la ore distanță. Stabilirea corectă a acestei triade este cea mai frecventă sursă de „marcaje fantomă" — setați stale prea departe în viitor și pistele moarte persistă; setați-l prea scurt și pistele live pâlpâie.

3. ierarhia de tipuri MITRE

Atributul type codifică ce este obiectul folosind taxonomia MITRE, cu puncte și cratime. Cea mai importantă familie este tipul atom, prefixat cu a-. Un tip atom se citește ca o secvență de tokeni separați prin cratimă: a-f-G-U-C.

Primul token după a este afilierea: f prieten, h ostil, n neutru, u necunoscut, p în așteptare, plus variante presupus/suspect. Următorul token este dimensiunea de luptă: G sol, A aer, S suprafață (mare), U subacvatic, P spațiu, F SOF. Tokenii rămași coboară în ierarhia de simboluri MIL-STD-2525 — a-f-G-U-C este o unitate terestră prietenă, de luptă, și așa mai departe. Un wildcard a-f-G-* înseamnă „un obiect terestru prieten, nespecificat dincolo de atât", iar renderele revin la cel mai apropiat simbol definit. Familiile non-atom folosesc prefixe diferite: b- pentru biți (date de senzor/geometrie, de ex. b-m-p-s-p-i pentru un punct de interes de senzor), t- pentru tasking și y- pentru răspunsuri. Geniul taxonomiei cu puncte este că este decodabilă prin prefix: un client care cunoaște doar a-f-G poate plasa în continuare o pictogramă generică de prieten-sol și se degradează grațios pe coada pe care nu o recunoaște.

4. elementul point

Elementul <point> este obligatoriu și poartă cinci atribute, toate necesare. lat și lon sunt grade zecimale WGS-84. hae este înălțimea deasupra elipsoidului în metri — observați „deasupra elipsoidului", nu deasupra nivelului mediu al mării; amestecarea HAE și a înălțimii ortometrice (decalajul geoidului poate depăși 30 m) este un bug clasic de eroare verticală atunci când CoT întâlnește un sistem care așteaptă MSL.

ce este eroarea circulară — raza orizontală de incertitudine de 1-sigma în metri. le este eroarea liniară — incertitudinea verticală în metri. Împreună permit unui receptor să deseneze un inel de precizie în loc de un punct fix înșelător de precis. Valoarea santinelă 9999999 (adesea scrisă 9999999.0) înseamnă „necunoscut" — nu este o măsurătoare reală, este valoarea nulă a schemei. Un punct plasat manual fără precizie relevată poartă ce="9999999" le="9999999", iar logica de fuziune trebuie să trateze acea valoare ca un caz special în loc să o trateze ca o eroare de zece mii de kilometri.

Deoarece fiecare atribut este obligatoriu, nu există un point fără înălțime sau fără o estimare de eroare — schema obligă producătorul să facă o afirmație, chiar dacă acea afirmație este „necunoscut". Aceasta este o decizie de proiectare discret de bună: un receptor nu trebuie niciodată să ghicească dacă un câmp lipsă înseamnă zero, necunoscut sau implicit. Are fie un număr real, fie are santinela, iar cele două sunt neambigue. Costul este că codificatoarele leneșe codifică rigid hae="0.0" pentru tot, ceea ce este mai rău decât santinela pentru că arată ca o măsurătoare reală la nivelul mării. Dacă nu cunoașteți înălțimea, spuneți-o cu 9999999; nu afirmați zero.

5. elementul detail

Elementul <detail> este containerul deschis de extensie și este locul în care trăiește de fapt ecosistemul CoT. Schema nu impune nicio constrângere asupra copiilor săi — orice XML bine format este legal — ceea ce a permis TAK să stratifice un protocol de aplicație bogat deasupra unui format SA generic fără a-l furca.

Sub-elementele convenționale sunt larg respectate. <contact> poartă un callsign lizibil de om și, pentru TAK, adresarea endpoint pentru mesagerie directă. <track> poartă course și speed pentru entitățile în mișcare, transformând un point static într-un vector. <remarks> este text liber. <status> raportează lucruri precum nivelul bateriei. <__group> (subliniere dublă) atribuie unității o culoare și un rol de echipă TAK — Cyan, Team Member — determinând culoarea pictogramei pe ecranul fiecărui coechipier. <takv> raportează versiunea clientului TAK, dispozitivul și platforma. Deoarece detail este deschis, un receptor pur și simplu omite copiii pe care nu îi recunoaște, ceea ce reprezintă întreaga bază a interoperabilității CoT și TAK între clienți eterogeni.

6. CoT vs Link 16 și VMF

CoT ocupă același spațiu conceptual ca seria J și VMF, dar cu priorități de proiectare opuse. Mesajele J Link 16 sunt cuvinte cu format fix, împachetate pe biți, dimensionate pentru un slot TDMA; VMF (MIL-STD-6017) este un format variabil, dar strict orientat pe biți, pentru purtători de bandă joasă. CoT este XML verbos construit pentru rețele IP unde octeții sunt ieftini, iar timpul dezvoltatorului nu este.

Maparea CoT la un mesaj J este cu pierderi în ambele direcții. Afilierea și dimensiunea de luptă a CoT se mapează curat pe câmpurile de pistă J3.x și pe câmpurile de identitate VMF, iar lat/lon/hae se traduc direct. Nepotrivirea de impedanță se află în precizie și semantică: o calitate de pistă din seria J este o valoare enumerată discretă, în timp ce ce/le ale CoT sunt metri continui; <detail> deschis al CoT nu are niciun corespondent cu format fix și este eliminat în întregime la un gateway. Invers, câmpurile din seria J precum moduri IFF specifice sau participarea la rețea derivată din PPLI nu au niciun slot CoT nativ și trebuie strecurate în extensii detail personalizate. Gateway-urile care fac punte între CoT și legăturile de date tactice poartă, prin urmare, o hartă de câmpuri opinionată, întreținută manual — aceeași problemă a traducătorului-cu-opinii care apare peste tot în C2 NATO.

7. streaming și TAK

În producție, CoT este un flux, nu un document. TAK Server multiplexează event-urile CoT între clienți: raportul de auto-poziție al unei unități curge în sus printr-o conexiune TCP persistentă (adesea TLS) la o rată configurabilă — frecvent la fiecare 1 până la 10 secunde în funcție de mișcare și de setarea „raportare dinamică" — iar serverul îl distribuie către abonați, opțional filtrat după misiune, grup sau geofence. Mesh SA, modul fără server, multicastează aceleași event-uri prin UDP în rețeaua locală, astfel încât o grupă operează fără infrastructură.

Ratele de mesaje conduc ingineria. Un exercițiu cu 200 de noduri în care toată lumea raportează la fiecare 2 secunde înseamnă 100 de event-uri/secundă doar de auto-poziție, înainte de pistele de senzor. Serverul nu menține un protocol de ștergere pentru niciuna dintre acestea; în schimb, fiecare client face colectare de gunoi în mod independent pe baza marcajelor stale pe care le-a văzut. Colectarea de gunoi condusă de stale este elegantă — fără lider, fără consens — dar înseamnă că un client care își pierde conectivitatea va privi cum întreaga sa imagine îmbătrânește și dispare conform programului, ceea ce de obicei este comportamentul corect și ocazional o surpriză neplăcută în timpul unui blackout de comunicații.

8. validarea și generarea CoT

Formatul de fir este iertător, ceea ce face ușor să emiți CoT subtil defect. Validați față de schema publicată Event.xsd în timpul dezvoltării, dar cunoașteți-i limitele: XSD verifică că point există și că atributele de ciclu de viață sunt prezente și bine tipizate, dar nu vă poate spune că stale al vostru este înainte de start, că tokenul vostru type este lipsit de sens sau că hae al vostru este înălțime de geoid deghizată în înălțime de elipsoid.

Bug-urile recurente de mesaje malformate sunt previzibile. Marcaje temporale fără Z-ul final sau cu decalaje de zonă locală — timpul CoT este UTC, punct, iar un Z lipsă trimite marcaje în trecut sau viitor. Durate de viață inversate în care stale precede start, producând event-uri care sunt moarte la sosire. Reutilizarea unui singur uid pentru entități distincte, ceea ce face ca două piste reale să colapseze într-un singur marcaj care pâlpâie. Emiterea unui ce cu aspect real în loc de santinela 9999999 pentru un punct nerelevat, ceea ce păcălește fuziunea să aibă încredere în gunoi. Când construiți un codificator CoT, faceți din triada de ciclu de viață un tip de primă clasă care impune start ≤ stale și redă UTC cu Z, generați UID-uri dintr-o cheie de entitate stabilă în loc de un contor per-mesaj și emiteți explicit santinela de necunoscut. Faceți corect aceste patru invariante, iar CoT-ul vostru va interopera cu clienți pe care nu i-ați văzut niciodată — ceea ce este întregul rost al formatului.