Gateway-uri software pentru traducerea linkurilor de date tactice: Link 16, VMF, CoT și NFFI

Un grup de lucru comun al coaliției operează într-un peisaj de limbaje de date incompatibile. Componenta aeriană vorbește Link 16 — mesaje J-series în MIL-STD-6016 peste un waveform JTIDS/MIDS. Forțele terestre schimbă poziții și ordine în VMF (Variable Message Format) peste radiouri tactice sau în NFFI (NATO Friendly Force Information) prin IP între sistemele C2 la nivel de brigadă. Soldații pedestri și contralorii de atac terminal comun trimit evenimente CoT (Cursor-on-Target) prin IP de pe tablete ATAK. Sistemele de informații publică urme în XML proprietar sau în Standardul de Schimb de Informații al MIP. Niciun din aceste formate nu comunică în mod nativ cu celelalte. Gateway-ul software este cel care le face interoperabile — ingerând fiecare format, traducând conținutul semantic în alt format, gestionând identitățile urmelor rezultante, aplicând reguli de filtrare și livrând datele traduse în cadrul unui buget de latență care menține imaginea operațională comună utilă tactic. Acest articol examinează cum funcționează gateway-urile pentru linkul de date tactic (TDL) și unde eșuează în mod regulat.

Peisajul linkului de date

Înțelegerea problemei de traducere necesită înțelegerea pentru ce este proiectat fiecare format de link de date, deoarece fiecare a fost proiectat pentru un mediu diferit cu constrângeri diferite.

Link 16 — definit în MIL-STD-6016 — este un waveform cu acces multiplu cu divizare în timp proiectat pentru războiul aerian. Mesajele sale J-series transportă urme de supraveghere, date PPLI (Precise Participant Location and Identification), mesaje de gestionare a misiunilor și conținut de coordonare a armelor. Link 16 este compact, criptat, cu latență redusă și anti-bruiaj prin proiectare. Banda sa de frecvență este partajată între toți terminalii din rețea prin slot-uri de timp TDMA, ceea ce impune o limită maximă strictă privind câte urme pot fi partajate la ce rată de actualizare. O rețea Link 16 nu este o rețea IP de uz general; este un bus de mesaje construit cu scop cu capacitate fixă și o schemă rigidă de mesaje. Pentru mai multe detalii despre arhitectura Link 16, consultați analiza noastră a linkurilor de date tactice Link 16.

VMF (Variable Message Format, MIL-STD-2045-47001) este standardul Armatei americane și comun pentru mesajele digitale tactice. Mesajele VMF sunt codificate binar și optimizate pentru purtătoare radio cu bandă îngustă — o alegere de proiectare care le permite să fie transportate pe canale radio HF sau VHF cu debit de kilobiți pe secundă. VMF acoperă o gamă largă de tipuri de mesaje: rapoarte de conștientizare situațională, ordine digitale, cereri de sprijin de foc, mesaje logistice și altele. Codificarea binară face VMF compact dar inflexibil; adăugarea unui nou tip de mesaj necesită o modificare formală a specificației.

CoT (Cursor-on-Target) este o schemă de evenimente XML proiectată pentru ecosistemul TAK (Team Awareness Kit). Un eveniment CoT este o structură minimă, extensibilă: un identificator unic (UID), o poziție geografică, un tip de eveniment dintr-o taxonomie (inclusiv coduri de simbol militar MIL-STD-2525), un timp de viață și elemente de detaliu opționale. CoT a fost proiectat să fie simplu și nativ IP, lizibil atât de oameni cât și de mașini, extensibil fără a rupe analizatoarele și suficient de mic pentru a transita o legătură radio tactică. A devenit de facto limbajul comun al comunității soldaților pedeștri și al controlorilor de atac terminal comun și tot mai mult al operatorilor UAS și al forțelor de operații speciale.

NFFI (NATO Friendly Force Information, STANAG 5527) este standardul alianței pentru partajarea datelor de poziție și identitate ale forțelor prietenoase între sistemele C2 terestre prin IP. Definește un set de mesaje pentru raportarea urmelor, gestionarea urmelor și transferul de autoritate. NFFI este linkul de date preferat pentru sistemele C2 la nivel de brigadă și mai sus care trebuie să schimbe urme ale forțelor terestre cu sisteme aliate — oferă un limbaj comun pentru imaginea terestră la nivel operațional într-un mod în care Link 16 (proiectat pentru imaginea aeriană) nu o face.

Ce face de fapt un gateway TDL

Un gateway software TDL nu este un simplu convertor de protocoale. Dacă singura provocare ar fi reformatarea octeților de la o codificare la alta, ingineria ar fi banală. Problemele dificile sunt semantice: modelele de date care stau la baza acestor formate sunt diferite, schemele de identitate a urmelor sunt diferite, ratele de actualizare sunt diferite și atributele disponibile într-un format pot să nu aibă echivalent în altul. Un gateway trebuie să rezolve toate aceste probleme simultan și să o facă în timp real cu un buget de latență măsurat în sute de milisecunde.

Analizarea mesajelor și normalizarea

Prima funcție a unui gateway este să analizeze fiecare format primit și să îl normalizeze la o reprezentare internă. Acea reprezentare internă trebuie să fie suficient de bogată pentru a captura toate atributele pe care orice format sursă le poate transporta, fără a pierde informații pe care un format țintă le poate exprima. O alegere comună este un obiect urmă canonic care deține atributele de identitate (indicativul de apel, numărul urmei, identitatea națională a urmei, codul transponderului ICAO), poziția și cinematica (poziție geodetică, altitudine, viteză, direcție), clasificarea (aer/suprafață/sub-suprafață/teren, prieten/neutru/necunoscut/ostil, tipul specific de platformă), indicatorii de calitate a datelor și metadatele de proveniență (care link de date a raportat asta, la ce oră, cu ce rată de actualizare).

Normalizarea este locul unde apar primele pierderi semantice. Mesajul de urmărire a supravegherii J3.0 al Link 16 transportă un număr de calitate a urmei pe o scară definită; CoT nu are un câmp echivalent. Secțiunea de detalii a unui eveniment CoT poate transporta coduri de simbol militar, dar aceeași platformă poate fi descrisă diferit într-o urmă Link 16. Gateway-ul trebuie să documenteze ce păstrează și ce pierde în fiecare direcție de traducere — și operatorii trebuie să fie informați despre acele limitări.

Gestionarea urmelor și corelarea mesajelor

Gestionarea urmelor este funcția care menține colecția de urme active — una per entitate din lumea reală — din toate sursele de date. Când sosește un raport nou, trackerul trebuie să decidă: este aceasta o entitate nouă sau este o actualizare a unei urme existente? Dacă este o actualizare, cărei urme existente îi aparține? Aceasta este problema corelării mesajelor.

Algoritmii de corelare funcționează de obicei în două etape. Prima etapă este filtrarea cinematică: dacă poziția și viteza raportate sunt geometric consistente cu o urmă existentă — noul raport se încadrează în elipsa de incertitudine a poziției prezise a urmei — raportul este un candidat pentru acea urmă. A doua etapă aplică atributele de identitate: dacă candidatul are un indicativ de apel, cod ICAO sau număr de urmă corespunzător, confidența corelării crește brusc. Când ambele etape sunt de acord, urma este actualizată. Când nu sunt de acord — poziție consistentă dar identitate nepotrivită, sau identitate potrivită dar poziție inconsistentă — algoritmul trebuie să aleagă între declararea unei noi urme și forțarea unei corelări potențial incorecte. Acest caz limită este originea rapoartelor operatorilor despre "urme fantomă" și "simboluri duplicate".

Corelarea devine deosebit de dificilă când urmele Link 16 — care se actualizează la fiecare două până la doisprezece secunde și transportă poziții geodetice de înaltă precizie — sunt corelate cu urmele CoT de pe dispozitivele TAK, care se pot actualiza mai rar și transportă poziții care reflectă precizia GPS mai degrabă decât precizia fuzionată de senzori a unei urme radar. Un senzor terestru care raportează un vehicul în mișcare în CoT și o urmă de supraveghere Link 16 pentru același vehicul pot fi separate de zeci de metri la momentul comparației, chiar dacă ambele rapoarte sunt exacte. Pragurile de corelare trebuie să fie setate suficient de largi pentru a prinde aceste cazuri fără a genera corelări false între entități distincte din apropiere.

Reguli de filtrare și posibilitate de eliberare

Un gateway TDL se află la o limită de date. Nu toate urmele dintr-un domeniu ar trebui să circule în altul: unele urme sunt clasificate la un nivel care nu poate fi eliberat la partea receptoare, unele sunt irelevante geografic pentru consumator, unele sunt sub un prag de calitate a datelor care ar produce afișaje înșelătoare și unele sunt duplicate ale urmelor deja prezente în rețeaua de destinație. Regulile de filtrare codifică aceste decizii.

Filtrarea posibilității de eliberare este cea mai sensibilă. Într-o coaliție de națiuni cu clasificări de securitate diferite și acorduri diferite de partajare a datelor, gateway-ul trebuie să aplice că urmele națiunii A sunt eliberabile la națiunea B înainte de a le transmite. Mecanismul de aplicare se bazează pe atributele din înregistrarea urmei — marcajul de clasificare, clauza de posibilitate de eliberare, națiunea de origine — care sunt transportate cu fidelitate prin etapa de normalizare. Un gateway care normalizează marcajele de posibilitate de eliberare este un risc de securitate, nu o caracteristică.

Filtrarea geografică reduce aglomerarea și consumul de bandă de frecvență. Un consumator interesat de imaginea aeriană peste o zonă specifică de operațiuni nu are nevoie de urme de pe jumătate de continent. Gateway-ul poate aplica un filtru de limită geografică — un poligon de delimitare sau o limită de distanță față de un punct — și poate suprima urmele care cad în afara sa. Acest lucru este deosebit de important pe linkurile cu bandă de frecvență limitată unde fiecare actualizare de urmă consumă capacitate care ar putea transporta trafic cu prioritate mai mare.

Bugetul de latență

Bugetul de latență pentru un gateway TDL este întârzierea suplimentară maximă pe care gateway-ul poate introduce pe lângă latența nativă de raportare a fiecărui link de date. Pentru urmele aeriene Link 16 utilizate în interceptare sau control al focului sensibil la timp, ciclul nativ de raportare este deja de două până la doisprezece secunde; adăugarea câtorva secunde de latență gateway deasupra produce o urmă care este operațional inutilă pentru decizii sensibile la timp. Pentru afișajele de conștientizare situațională la nivel de brigadă și mai sus, câteva secunde de latență suplimentară este de obicei acceptabilă.

Latența într-un gateway se acumulează din mai multe surse: adâncimea cozii de intrare când rata de sosire a mesajelor depășește rata de procesare, timpul de procesare a corelării pentru scenarii complexe de corelare multi-la-multi, timpul de serializare a ieșirii pentru loturi mari și timpul de tranzit prin rețea la consumator. Cel mai rău caz — o explozie de actualizări Link 16 în timpul unui angajament aerian de mare intensitate, toate necesitând corelarea față de o bază de date mare de urme existente — este exact când latența contează cel mai mult. Proiectanții de gateway trebuie să testeze de stres sub scenarii realiste de sarcină de vârf, nu numai benchmark-uri de sarcină medie, și să specifice latența de percentilă 99 mai degrabă decât media.

Standarde deschise și ecosistemul gateway

Piața gateway TDL include atât sisteme militare proprietare cât și implementări construite pe specificații deschise sau publicate. Pe partea deschisă, schema CoT este publicată și implementată pe scară largă; ecosistemul TAK a produs implementări de referință care formează baza multor gateway-uri dezvoltate de guvern. NFFI (STANAG 5527) este un standard NATO disponibil pentru națiunile membre. MIL-STD-6016 și MIL-STD-2045-47001 sunt standarde americane cu distribuție controlată, dar formatele lor de mesaje sunt suficient de documentate pentru ca implementări independente să existe în baza industrială a apărării.

XMPP (Extensible Messaging and Presence Protocol) a apărut ca strat de transport preferat pentru distribuirea CoT în ecosistemul TAK și în FMN, atât deoarece oferă semantică de mesagerie fiabilă peste IP cât și deoarece arhitectura sa federată se scalează la utilizarea coaliției fără un singur broker central. Mai multe implementări naționale ale serviciilor de mesagerie FMN sunt construite pe XMPP cu CoT ca sarcină utilă, creând un strat de facto de distribuție a urmelor coaliției sub arhitectura NFFI mai formală. Gateway-urile care suportă XMPP atât ca intrare cât și ca ieșire pot servi atât comunitatea forțelor terestre centrată pe TAK cât și comunitatea C2 a coaliției orientată spre FMN dintr-un singur punct de integrare. Rolul mai larg al CoT în interoperabilitatea NATO este acoperit în articolul nostru despre CoT și TAK în interoperabilitatea NATO.

Modelul gateway API — expunerea traducerii TDL ca serviciu printr-un API REST sau gRPC mai degrabă decât ca interfață binară proprietară — câștigă teren pe măsură ce arhitecturile coaliției se îndreaptă spre proiecte orientate pe servicii. Un gateway TDL bazat pe API poate fi integrat cu platformele de partajare a datelor ale coaliției, inclusiv modelele gateway API pentru partajarea datelor coaliției descrise în analiza noastră conexă, fără a necesita integrare la nivel scăzut personalizată pentru fiecare sistem consumator. Compromisul este că HTTP/REST adaugă latență față de o conexiune binară directă — care poate sau nu poate fi în cadrul bugetului de latență în funcție de cazul de utilizare.

Standardul MIP4 și IES — modelul de date al forțelor terestre NATO — definește stratul semantic pe care sistemele C2 terestre trebuie să îl utilizeze atunci când schimbă informații despre forțe. Un gateway complet al coaliției trebuie să poată mapa la și de la entitățile și relațiile canonice ale MIP, nu doar la formatul de mesaj al NFFI. Pentru detalii despre MIP4 și IES, consultați analiza noastră a MIP4 și IES: standardul de date al forțelor terestre NATO.