Urmărirea forțelor albastre pe Android militar: ATAK, CoT și rețeaua

De Echipa de inginerie Corvus Intelligence · Despre echipă →

25 iunie 2026 11 min de lectură

Urmărirea forțelor albastre (BFT) este una dintre cele mai importante capabilități pe care o unitate debarcată le poate purta: capacitatea de a vedea, în timp aproape real, unde se află fiecare element prieten pe hartă. Ani de zile, această capabilitate a fost domeniul exclusiv al terminalelor scumpe, dedicate. Platformele bazate Android care rulează ATAK (Android Team Awareness Kit) au schimbat această ecuație — un smartphone sau o tabletă ruggedizată cu radio MANET livrează acum BFT persistent la o fracțiune din costul hardware-ului moștenit, cu o arhitectură de plug-in deschisă care permite fluxurilor de senzori personalizați, straturilor AI și instrumentelor de planificare a misiunii să coexiste cu stratul de urmărire. Acest articol acoperă întreaga stivă BFT: schema evenimentelor de poziție CoT, configurarea SA ATAK, gestionarea fluxurilor pe TAK Server, integrarea transportului prin radio MANET, profilarea compromisului rată de actualizare vs. baterie și comportamentul sistemului când conectivitatea este pierdută.

Cerințe BFT pentru unitățile tactice

Înainte de a atinge configurarea software, o implementare BFT necesită o linie de bază explicită de cerințe. Parametrii care conduc fiecare decizie ulterioară sunt precizia poziției, frecvența de actualizare, latența afișajului și constrângerile impuse de dispozitivele și radiourile utilizate.

Precizia poziției. BFT-ul pentru infanteria debarcată țintește o eroare circulară probabilă (CEP) de 10 metri sau mai bună — suficientă pentru deconflictie în teren urban, unde contează rezoluția la nivel de clădire. BFT-ul montat pe vehicul acceptă de obicei CEP 50 m. Dispozitivele Android cu GNSS multi-constelație (GPS + GLONASS + Galileo) realizează CEP 3–5 m în teren deschis; baldachinul dens sau canioanele urbane degradează aceasta la 15–30 m fără augmentare. SBAS (WAAS/EGNOS) asistă receptoarele GNSS în dispozitivele compatibile ATAK, strângând și mai mult precizia în zonele geografice suportate.

Frecvența de actualizare. Rata de actualizare a poziției determină cât de curente sunt traseele de pe hărțile unităților învecinate. Intervalele de 5–10 secunde sunt standard pentru unitățile în contact direct sau care desfășoară operațiuni de proximitate. Intervalele de 30–60 de secunde sunt adecvate pentru unitățile în poziții de sprijin sau de rezervă. Rata de actualizare multiplică direct sarcina canalului: orice dublare a numărului de unități sau înjumătățire a intervalului de actualizare dublează consumul de lățime de bandă în rețeaua radio partajată.

Latența afișajului. Latența de afișare de la capăt la capăt — de la evenimentul de poziție generat pe dispozitivul sursă până la apariția traseului pe toate afișajele conectate — trebuie să rămână sub 3 secunde pentru operațiunile în care deconflictia depinde de poziția în timp real. Contribuțiile la latență includ timpul de fixare GPS, generarea evenimentului CoT, transmiterea radio, procesarea serverului și randarea clientului. Pe un MANET bine configurat cu TAK Server local, latența totală se încadrează de obicei în intervalul 500 ms–1,5 s. Configurațiile cu backhaul satelitar adaugă 600 ms–1,2 s de întârziere într-un sens.

Constrângerile de dispozitiv și radio. Dispozitivele Android ruggedizate folosite pentru BFT — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — poartă baterii dimensionate pentru ture de 8–16 ore, dar GPS-ul și transmisiile radio consumă masiv din acea capacitate. Radiourile MANET se conectează de obicei prin USB OTG sau hotspot Wi-Fi; conexiunea hotspot adaugă ea însăși sarcină de antenă și RF. Limitele termice în medii calde reduc puterea de transmisie sustenabilă atât pe dispozitivul Android, cât și pe radio, putând reduce raza efectivă și necesitând prin urmare intervale de actualizare mai scurte pentru a compensa pierderea crescută de pachete.

Evenimente de poziție Cursor on Target (CoT)

Standardul CoT definește o schemă de evenimente XML pe care o vorbesc toate elementele din rețeaua BFT. Înțelegerea schemei este esențială pentru diagnosticarea defecțiunilor BFT și pentru scrierea de plug-in-uri personalizate care injectează sau consumă date de poziție.

Schema XML CoT pentru evenimentele SA

Un eveniment minimal de poziție al unei unități terestre prietene arată astfel:

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="ANDROID-BFT-ALPHA-1"
  type="a-f-G-U-C"
  time="2026-06-25T08:30:00.000Z"
  start="2026-06-25T08:30:00.000Z"
  stale="2026-06-25T08:30:45.000Z"
  how="m-g">
  <point lat="49.8391" lon="24.0297"
         hae="320.0" ce="9.0" le="999999.0"/>
  <detail>
    <contact callsign="ALPHA-1"/>
    <uid Droid="ALPHA-1"/>
    <group name="Cyan" role="Team Member"/>
    <status battery="72"/>
    <track speed="1.4" course="045.0"/>
    <precisionlocation geopointsrc="GPS" altsrc="GPS"/>
  </detail>
</event>

Câmpurile cheie pentru BFT sunt:

uid — identificator unic pentru traseu. Trebuie să rămână stabil între actualizările de poziție; ATAK folosește IMEI-ul dispozitivului sau un UUID generat.
type — cod de tip CoT (a se vedea mai jos) care codează afilierea, dimensiunea și tipul platformei.
time / start — marcaj temporal de generare a evenimentului în ISO 8601 UTC. Precizia ceasului aici este critică: deviația ceasului cauzează respingerea ca expirat pe serverul receptor.
stale — marcaj temporal după care evenimentul este considerat expirat. ATAK setează stale la time + (interval de actualizare × 3) în mod implicit, oferind trei actualizări ratate înainte ca traseul să devină fantomă.
how — metoda de introducere a poziției: m-g (GPS de la mașină), h-g-i-g-o (GPS introdus de om), m-g-i (GPS inferat).
point — coordonate WGS84: lat/lon în grade zecimale, hae (înălțime deasupra elipsoidului WGS84) în metri, ce (eroare circulară) și le (eroare liniară) în metri.

Coduri de tip CoT pentru prieten, ostil și neutru

Codurile de tip CoT urmează o schemă ierarhică: a-[afiliere]-[dimensiune de luptă]-[funcție]. Pentru BFT, caracterul de afiliere este discriminatorul critic:

Prefix de tip	Afiliere	Culoarea pictogramei ATAK	Exemplu
`a-f-`	Prieten	Albastru	`a-f-G-U-C` — unitate terestră prietenă, luptă
`a-h-`	Ostil	Roșu	`a-h-G-U-C` — unitate terestră ostilă, luptă
`a-n-`	Neutru	Verde	`a-n-G-E-V-C` — vehicul terestru neutru, civil
`a-u-`	Necunoscut	Galben	`a-u-G-U` — unitate terestră necunoscută

Gestionarea timeout-ului de expirare

Marcajul temporal de expirare (stale) este mecanismul principal pentru curățarea traseelor de pe COP. Multiplicatorul de expirare implicit al ATAK este de 3× intervalul de actualizare SA configurat: la o rată de actualizare de 10 secunde, stale este setat 30 de secunde în viitor. Dacă trei evenimente consecutive de poziție sunt pierdute (pierdere de pachete, întrerupere radio, oprirea dispozitivului), traseul intră în stare de expirare, iar ATAK îl randează cu o pictogramă estompată. După o perioadă de grație configurabilă de operator (implicit 5 minute în majoritatea implementărilor), traseul expirat este eliminat complet de pe hartă.

Pentru BFT în medii cu pierdere mare de pachete (urban dens, baldachin de junglă, legături cu backhaul SATCOM), creșteți multiplicatorul de expirare la 6–10× pentru a evita ghosting-ul excesiv al traseelor. Aceasta se configurează per dispozitiv în ATAK la Settings → Network → SA Reporting → Stale Timer. Pe partea de TAK Server, pragul propriu de expirare al serverului (implicit 600 de secunde) controlează cât timp serverul reține un traseu în baza de date înainte de a-l expira — clienții nou conectați nu vor primi trasee care au depășit pragul de expirare al serverului.

ATAK ca client BFT

ATAK gestionează BFT în întregime prin subsistemul său SA (conștientizare situațională). Nu este necesar niciun plug-in suplimentar pentru BFT de bază — capabilitatea este încorporată în aplicația principală ATAK. Plug-in-urile extind BFT cu surse de date personalizate, straturi de afișare și căi de transmisie dincolo de opțiunile standard de server și multicast.

Configurarea SA în ATAK

Controalele principale de configurare BFT se află la Settings → Network → Reporting Preferences:

Reporting Rate (Moving) — intervalul de transmitere CoT când dispozitivul este în mișcare. Setați la 5–10 s pentru infanteria debarcată, 3–5 s pentru vehicule cu alimentare externă.
Reporting Rate (Stationary) — intervalul când dispozitivul nu s-a mișcat dincolo de pragul de mișcare. Setați la 30–120 s pentru a economisi bateria în fazele statice.
Dynamic SA Reporting — când este activat, ATAK comută automat între ratele de mișcare și staționare pe baza accelerometrului. Acesta este modul recomandat pentru toate implementările operaționale BFT.
My Team — atribuie dispozitivul unui grup (Cyan, Magenta, Yellow etc.), care determină culoarea pictogramei pe care celelalte unități o văd pentru acest traseu și controlează filtrarea de grup pe partea de server.
My Role — setează subtipul de funcție din codul de tip CoT (Team Member, Team Leader, HQ, Medic, Forward Observer etc.).

Tipuri de conexiune de rețea

ATAK acceptă trei tipuri de conexiune de rețea pentru livrarea datelor BFT:

TCP/TLS către TAK Server (port 8089). Acesta este modul operațional standard. ATAK stabilește o conexiune TLS persistentă, autentificată cu un certificat de client PKCS#12. Serverul livrează toate traseele abonate către client pe această conexiune și primește evenimentele de poziție ale clientului pentru distribuție. TCP oferă livrare fiabilă și acceptă sarcini utile mari de mesaje (pachete de misiune, pachete de date) pe lângă evenimentele CoT.

Multicast UDP. ATAK poate difuza și primi evenimente CoT pe o adresă de multicast UDP (implicit 239.2.3.1:6969). Acest mod operează fără nicio infrastructură de server — dispozitivele se descoperă reciproc prin grupul de multicast partajat. Este potrivit pentru BFT peer-to-peer pe segmente de rețea locale (spațiu IP local hotspot Wi-Fi sau radio MANET), dar nu acceptă federare, filtrare sau istoric persistent al traseelor. Pierderea de pachete în modul multicast nu este retransmisă: un eveniment de poziție ratat pur și simplu nu apare.

Streaming TCP (moștenit). Un mod de flux XML necriptat mai vechi, acum depreciat în favoarea TLS. Nu îl utilizați în nicio implementare operațională.

Arhitectura de plug-in pentru fluxuri BFT personalizate

API-ul de plug-in al ATAK permite aplicațiilor terțe să injecteze evenimente CoT în harta ATAK locală fără a trece prin server. Un plug-in BFT personalizat poate primi date de poziție de la o formă de undă radio proprietară, un dispozitiv de urmărire hardware (prin serial USB) sau o estimare de poziție derivată din AI și o poate injecta ca eveniment CoT standard, vizibil pe afișajul ATAK. Plug-in-ul comunică cu nucleul ATAK prin interfața de intent CotMapComponent, postând intent-uri de difuzare com.atakmap.android.maps.COT_RECEIVER cu sarcina utilă XML CoT. Consultați ghidul nostru despre operațiuni de teren de integrare ATAK pentru un parcurgere detaliată a dezvoltării de plug-in-uri.

Gestionarea fluxurilor SA pe TAK Server

TAK Server este hub-ul care agregă evenimentele de poziție BFT de la toți clienții ATAK conectați și le distribuie abonaților. Configurarea corectă a serverului este la fel de importantă ca setările clientului pentru un BFT fiabil.

Federarea serverului pentru SA între unități

Când BFT trebuie să se întindă peste mai multe instanțe TAK Server independente — de exemplu, un server de companie și un server de batalion, sau un eșalon înainte și unul în spate — configurarea federării TAK server oferă interconectarea. Federarea redirecționează tipurile CoT selectate peste granița serverului în timp aproape real. Pentru BFT, configurați filtrul de federare pentru a trece evenimentele a-f- (atom prieten) bidirecțional. Nu treceți a-h- (ostil) peste granițele de federare decât dacă gestionarea clasificării la ambele capete este verificată — informațiile despre pozițiile ostile sunt frecvent mai sensibile decât datele despre pozițiile prietene.

Abonarea la fluxuri SA și izolarea grupurilor

TAK Server gestionează ce clienți primesc ce trasee prin sistemul său de grupuri. Când un client ATAK se conectează cu un certificat atribuit grupului „PLATOON-1”, primește automat toate evenimentele CoT de la ceilalți clienți din același grup, plus orice grupuri pe care PLATOON-1 este configurat să le vadă (de exemplu „COMPANY-HQ”). Acest model de abonare bazat pe grup elimină nevoia oricărei configurări de abonare la trasee per client — apartenența la grup determină întreaga imagine SA.

Izolarea grupurilor de utilizatori este și mecanismul de separare a clasificării. Atribuiți clienților ATAK din rețeaua SECRET un grup fără suprapunere de vizibilitate cu grupurile UNCLASSIFIED. Serverul nu va redirecționa niciodată trasee SECRET către clienți UNCLASSIFIED, indiferent de tipul sau conținutul CoT. Pentru granițe dure de clasificare, rulați instanțe TAK Server complet separate pe segmente de rețea fizic separate, fără nicio legătură de federare între ele.

Configurarea fluxului SA CloudTAK

# Create a user group for BFT population
curl -s -X POST https://tak.yourdomain.com:8443/api/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PLATOON-1",
    "direction": "BOTH",
    "description": "1st Platoon BFT group",
    "bitpos": 0
  }'

# Assign a user certificate to the group
curl -s -X PUT https://tak.yourdomain.com:8443/api/users/alpha-1/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '["PLATOON-1", "COMPANY-HQ"]'

Câmpul direction controlează dacă grupul este un grup de intrare (evenimentele curg ÎN de la acest client), un grup de ieșire (evenimentele curg SPRE acest client) sau BOTH. Setarea BOTH este standard pentru BFT — fiecare dispozitiv atât contribuie, cât și primește trasee în cadrul grupurilor sale atribuite.

Transportul prin radio mesh pentru BFT

Legătura radio este cel mai constrâns din punct de vedere operațional element din stiva BFT Android. Radiourile MANET oferă rețeaua IP peer-to-peer care conectează dispozitivele ATAK când infrastructura Wi-Fi și acoperirea celulară nu sunt disponibile. Înțelegerea modului în care ATAK se integrează cu hardware-ul MANET este critică pentru performanța BFT predictibilă în operațiunile debarcate. Articolul nostru despre rețeaua mesh militară MANET acoperă stratul de rețea subiacent în detaliu; această secțiune se concentrează pe integrarea ATAK în mod specific.

Integrarea radioului MANET cu ATAK

Harris RF-7800W (Falcon III). RF-7800W se conectează la dispozitivul Android prin USB OTG, expunând o interfață de rețea RNDIS (USB Ethernet). Adresa IP a radioului pe această interfață este de obicei 192.168.100.1. ATAK tratează interfața RNDIS ca pe o interfață de rețea standard — nu este necesar niciun driver special sau aplicație companion. Configurați conexiunea server ATAK pentru a indica adresa IP a TAK Server așa cum este accesibilă prin rețeaua mesh a radioului. Pentru BFT local peer-to-peer fără server, configurați ieșirea multicast UDP a ATAK pe adresa interfeței RNDIS.

Persistent Systems MPU5. MPU5 operează ca punct de acces Wi-Fi sau ca dispozitiv USB RNDIS. În modul punct de acces, dispozitivul Android se conectează la SSID-ul Wi-Fi al MPU5; IP-ul de management al radioului este accesibil la 10.168.1.1 în mod implicit. Persistent Systems oferă o aplicație Android companion (Wave Relay Mobile) care se integrează cu ATAK pentru a expune starea formei de undă, harta nodurilor și metricile de calitate a legăturii ca strat nativ ATAK. Evenimentele CoT ATAK curg pe calea standard TCP sau UDP prin mesh-ul IP al MPU5.

Alocarea lățimii de bandă pentru traficul SA

Cuantificarea bugetului de lățime de bandă BFT înainte de implementare previne supraîncărcarea mesh-ului în cel mai prost moment posibil. Un singur eveniment de poziție CoT cu bloc complet de detalii are 800–1200 de octeți. La un interval de actualizare de 10 secunde pentru un escadron de 12 persoane:

Units:          12
Event size:     1000 bytes
Update rate:    10 seconds
Raw BFT load:   12 × 1000B / 10s = 1200 B/s ≈ 9.6 kbps

With TCP/TLS overhead (≈15%): ~11 kbps
With zlib CoT compression (≈50% reduction): ~5.5 kbps

MPU5 capacity (typical multi-hop mesh):  500 kbps–5 Mbps
RF-7800W capacity (typical):             200–500 kbps

BFT as % of RF-7800W at 200 kbps:        ~5.5% — acceptable
BFT as % of HF/SATCOM backhaul (32 kbps): ~17% — significant

La scară de companie (100+ unități la intervale de 10 secunde), sarcina BFT brută depășește 80 kbps înainte de overhead — o fracțiune semnificativă din orice backhaul HF sau SATCOM. În aceste medii, crește intervalele de actualizare staționară la 120+ secunde și bazează-te pe izbucnirile declanșate de mișcare pentru a menține sarcina agregată sub 20 kbps pe legătura de backhaul.

Rata de actualizare a poziției vs. durata de viață a bateriei

Rata de actualizare a poziției este cel mai impactant parametru de configurare BFT pentru durata de viață a bateriei. Achiziția GPS și transmisia radio sunt cele mai mari două consumuri de energie pe un dispozitiv ATAK BFT; ambele se scalează direct cu frecvența de actualizare.

Profilarea bateriei în condiții operaționale

Pe un Samsung Galaxy XCover Pro (baterie de 4050 mAh) care rulează ATAK cu GPS în fixare continuă:

Rata de actualizare	Consum GPS	Consum radio (hotspot MPU5)	Durata de viață BFT estimată
5 s (agresiv)	~120 mA	~180 mA	~8–9 h
10 s (standard)	~120 mA	~120 mA	~10–12 h
30 s (patrulă)	~90 mA	~60 mA	~15–18 h
120 s (static)	~60 mA	~20 mA	~22–26 h

Consumul GPS este relativ stabil indiferent de rata de actualizare, deoarece ATAK menține receptorul GPS în modul de urmărire continuă pentru a se asigura că poziția este mereu curentă când pornește o actualizare. Variabila este ciclul de funcționare al transmisiei radio: la intervale de 5 secunde, radio-ul este activ aproape continuu; la intervale de 120 de secunde, izbucnirile de transmisie ocupă doar 1–2% din ciclul de funcționare.

Strategii de rată de actualizare adaptivă

Modul Dynamic SA Reporting al ATAK implementează o strategie adaptivă cu două rate. O abordare mai sofisticată folosește plug-in-uri ATAK sau comenzi de push pe partea de server pentru a ajusta ratele de actualizare pe baza contextului operațional:

Comutare de rată bazată pe mișcare — declanșată de accelerometru: dacă dispozitivul s-a mișcat mai mult de 10 m de la ultima transmisie, transmiteți imediat, indiferent de intervalul programat. ATAK implementează aceasta nativ în modul Dynamic SA.
Izbucniri de actualizare declanșate de geofence — când o unitate traversează o graniță de geofence definită (intrarea în zona obiectivului, traversarea liniei de fază), declanșați o rată de actualizare în izbucnire de 5 secunde pentru 60 de secunde, apoi reveniți la rata de fundal. Configurați declanșatoarele de geofence prin plug-in-urile de geofencing ATAK sau API-ul de geofence al TAK Server.
Escaladarea ratei declanșată de contact — când TAK Server detectează un traseu ostil în raza definită a unei unități prietene, trimite o notificare push către clientul ATAK al unității prietene prin canalul CoT server-către-client, declanșând comutarea clientului la rata sa rapidă de actualizare. Aceasta necesită un plug-in personalizat pe partea de server sau un strat de integrare AI.
Reducerea ratei la prag de baterie — un agent de gestionare a dispozitivului (profil MDM sau plug-in ATAK) monitorizează bateria dispozitivului și crește automat intervalul SA când bateria scade sub 30%, tranzacționând actualitatea poziției pentru funcționarea continuă printr-o fază critică.

Conștientizarea situațională în modul deconectat

Nicio rețea de radio MANET nu operează perfect pe toată zona operațională. Mascarea terenului, războiul electronic, defecțiunile radio și emcon-ul deliberat (controlul emisiilor) produc toate perioade de operare deconectată. Un design BFT robust trebuie să definească exact ce face sistemul când legătura radio este absentă.

Afișarea poziției cunoscute ultima dată

Când ATAK pierde conectivitatea la TAK Server (sau pierde recepția multicast în modul peer-to-peer), continuă să afișeze toate traseele la ultimele poziții primite. Diferențierea vizuală între traseele curente și cele expirate este controlată de marcajul temporal de expirare CoT: după ce trece timpul de expirare al unui traseu, ATAK îl randează cu un strat de transparență și o adnotare de marcaj temporal care arată de cât timp poziția a fost primită ultima dată. Traseele persistă în această stare de expirare până când ating pragul de eliminare prin expirare al hărții ATAK (configurabil per implementare; implicit 5 minute.

Operatorii trebuie să fie instruiți să recunoască și să acționeze pe baza indicatorilor de traseu expirat. O poziție de traseu veche de 3 minute pentru o unitate debarcată care se mișcă cu ritmul infanteriei ar putea reprezenta 180–360 de metri de deplasare reală — suficient pentru a cauza risc de fraticid dacă este tratată ca fiind curentă. SOP-ul ar trebui să specifice că traseele expirate sunt folosite doar pentru conștientizarea generală a zonei, nu pentru deconflictia sprijinului de foc.

Integrarea afișajului de dead reckoning

ATAK acceptă extrapolarea traseului prin dead reckoning prin elementul de detalii track din evenimentele CoT, care poartă viteza și cursul. Când un traseu devine expirat, un plug-in de dead reckoning poate proiecta poziția curentă estimată a traseului înainte de la ultima fixare cunoscută, folosind vectorii raportați de viteză și curs. Poziția proiectată este afișată cu o pictogramă distinctă (de obicei un simbol deschis/punctat) pentru a o distinge de o poziție confirmată prin GPS.

Precizia dead reckoning se degradează rapid pentru infanteria debarcată (viteza și cursul se schimbă constant) și este mai fiabilă pentru vehicule pe rețele de drumuri cunoscute. Implementați afișarea prin dead reckoning numai când operatorii înțeleg limitările sale și SOP-ul distinge clar pozițiile proiectate de cele confirmate.

Reconectarea și reconcilierea SA

Când ATAK se reconectează la TAK Server după o perioadă deconectată, serverul efectuează o împingere completă a stării SA: livrează evenimentul CoT curent (sau cel mai recent) pentru fiecare traseu din grupurile abonate ale clientului. Această actualizare în cascadă suprascrie pozițiile expirate cunoscute ultima dată de pe harta clientului cu datele curente deținute de server. Procesul de reconciliere se finalizează în 1–3 secunde pentru dimensiuni tipice de unitate (sub 200 de trasee.

# Verify reconnection burst via CloudTAK events WebSocket
# (Use wscat or a browser WebSocket client for testing)
# wss://tak.yourdomain.com:8443/api/events?groups=PLATOON-1
#
# On reconnect, expect a rapid burst of CoT events — one per known
# track — within the first 2–3 seconds of the WebSocket session.
# Monitor the event count to confirm all expected tracks are delivered.
#
# If the burst is partial, check server-side stale threshold:
# GET /api/config/cot-stale-seconds
# Default: 600s — tracks older than 10 min are not pushed to reconnecting clients

Un caz de excepție de planificat: dacă perioada deconectată depășește pragul de expirare al serverului (implicit 600 de secunde pentru CloudTAK), serverul a expirat deja traseele expirate din depozitul său activ. La reconectare, acele trasee nu vor apărea în actualizarea în cascadă și vor reapărea numai când dispozitivele sursă transmit evenimente noi de poziție. Pentru operațiuni în care reconectările pot urma unor întreruperi de comunicații de mai multe ore, creșteți pragul de expirare al serverului pentru a se potrivi cu durata maximă așteptată a întreruperii.

Implementați BFT pentru unitatea sau organizația dumneavoastră

Proiectăm și implementăm sisteme de urmărire a forțelor albastre bazate pe ATAK pentru organizații de apărare și guvernamentale — inclusiv configurarea TAK Server, integrarea radiourilor MANET, copilotul AI TAKpilot și dezvoltarea de plug-in-uri specifice misiunii.

Copilot AI TAKpilot → Programați un briefing

Această analiză a fost elaborată de inginerii Corvus Intelligence, care construiesc software critic pentru misiune destinat organizațiilor din domeniul apărării și instituțiilor guvernamentale. Aflați mai multe despre echipa noastră →

Întrebări frecvente

Ce este urmărirea forțelor albastre pe dispozitive militare Android?

Urmărirea forțelor albastre (BFT) pe dispozitive militare Android se referă la afișarea și transmiterea în timp real a pozițiilor unităților prietene pe o hartă digitală partajată. ATAK (Android Team Awareness Kit) este clientul BFT principal: citește poziția GPS de pe dispozitiv, o împachetează ca eveniment XML Cursor on Target (CoT) și transmite acel eveniment către un TAK Server sau direct către dispozitive peer, prin multicast sau radio MANET. Serverul agregă evenimentele de poziție de la toate unitățile conectate și le difuzează către fiecare client ATAK, astfel încât fiecare soldat vede simultan toate traseele prietene. Ratele de actualizare, simbolistica hărții și căile de conectivitate sunt toate configurabile în setările SA ale ATAK.

Ce este Cursor on Target și cum este folosit pentru BFT?

Cursor on Target (CoT) este un format de mesaj bazat pe XML, dezvoltat inițial de Forțele Aeriene SUA pentru partajarea datelor tactice de poziție și stare între sisteme disparate. Pentru BFT, tipul de eveniment CoT cheie este evenimentul „atom” (prefix de tip „a-”), care poartă un element punct cu coordonate lat/lon/hae, un marcaj temporal de expirare (stale) care indică când poziția expiră și un bloc de detalii care conține indicativul, culoarea echipei și rolul. ATAK generează automat aceste evenimente din GPS-ul dispozitivului, la un interval configurabil (de obicei la fiecare 5–30 de secunde) și le transmite către TAK Server, care le redifuzează către toți clienții abonați. Marcajul temporal de expirare asigură că, dacă o unitate încetează să mai transmită, traseul său dispare automat de pe afișajele celorlalte unități după fereastra de expirare definită.

Ce rată de actualizare să configurez pentru ATAK BFT în operațiuni tactice?

Rata optimă de actualizare BFT depinde de tipul misiunii, lățimea de bandă a radioului și constrângerile de baterie. Pentru infanteria debarcată în contact, o rată de actualizare de 5–10 secunde oferă actualitate adecvată a poziției; pentru unitățile montate pe vehicul cu alimentare externă, 3–5 secunde este practic. Pe legăturile MANET cu lățime de bandă limitată, creșteți intervalul la 30–60 de secunde pentru unitățile care nu manevrează și bazați-vă pe izbucnirile declanșate de mișcare (evenimente de ieșire din geo-fence) pentru actualizări imediate când o unitate se deplasează. Funcția de raportare SA adaptivă din ATAK poate comuta automat între o rată lentă de fundal și o rată rapidă de contact, pe baza vitezei de mișcare detectate de accelerometrul dispozitivului.

Cum se conectează ATAK la un TAK Server pentru BFT?

ATAK acceptă trei tipuri principale de conexiune pentru BFT: (1) streaming TCP — o conexiune TCP/TLS persistentă la portul 8089 al TAK Server, folosită pentru livrare unicast fiabilă cu autentificare pe bază de certificate; (2) multicast UDP — evenimente CoT difuzate pe o adresă de multicast într-un segment de rețea local, potrivit pentru medii LAN sau MANET fără infrastructură de server; și (3) Streaming XML — un mod TCP moștenit care folosește fluxuri XML necriptate, acum depreciat. Pentru implementările operaționale, TCP/TLS către un TAK Server este standardul. Setările de rețea ale ATAK acceptă un nume de gazdă al serverului, un port și un pachet de certificate PKCS#12 pentru autentificare TLS mutuală.

Ce radiouri MANET se integrează cu ATAK pentru BFT?

ATAK se integrează cu radiourile MANET prin USB OTG Android sau prin aplicația Android companion a radioului. Radiourile frecvent integrate includ Harris RF-7800W (seria Falcon III), Persistent Systems MPU5, Domo Tactical PRC-ACM și Silvus StreamCaster. Fiecare radio expune o interfață de rețea virtuală sau un serviciu de releu CoT pe care ATAK îl recunoaște ca legătură de date TAK. Radio-ul gestionează rutarea IP pe mesh, iar ATAK trimite pachete UDP multicast CoT standard sau TCP către adresa IP locală a radioului. Unele radiouri expun și un API de gestionare a formei de undă (waveform) pe care plug-in-urile ATAK îl pot interoga pentru a monitoriza calitatea legăturii și a adapta parametrii de transmitere SA în consecință.

Cum gestionează TAK Server fluxurile SA pentru BFT?

TAK Server menține un depozit de evenimente CoT în memorie pentru toți clienții conectați. Când sosește un eveniment nou de poziție CoT, serverul: (1) scrie evenimentul în baza de date persistentă; (2) evaluează regulile de grup și filtrare pentru a determina ce clienți ar trebui să îl primească; (3) împinge evenimentul către toate conexiunile de clienți abonați. Pentru BFT în mod specific, serverul urmărește cel mai recent eveniment de poziție per UID și îl servește clienților nou conectați, astfel încât aceștia să primească imediat la conectare o imagine comună de operare curentă. Abonările la fluxuri SA sunt gestionate prin sistemul de grupuri al serverului — clienții atribuți aceluiași grup partajează automat traseele BFT, fără configurare manuală de abonare.

Cum împiedic apariția traseelor BFT simultan pe instanțele ATAK clasificate și necalificate?

Separarea clasificării într-un mediu TAK BFT se realizează printr-o combinație de izolare de grup pe partea de server și separare fizică a rețelei. Pe TAK Server, atribuiți unitățile clasificate unui grup care nu este vizibil clienților necalificați (de exemplu, un grup „SECRET” fără federare sau abonare la grupul „UNCLASSIFIED”). Pentru separare strictă, rulați două instanțe TAK Server complet separate — una pe un segment de rețea clasificat și una pe un segment neclasificat — fără nicio legătură de federare între ele. Nu vă bazați niciodată exclusiv pe filtrele de grup software pentru separarea clasificării; separarea fizică sau criptografică a rețelei este necesară pentru a respecta standardele de asigurare a informațiilor.

Ce se întâmplă cu traseele BFT când ATAK pierde conectivitatea la TAK Server?

Când ATAK pierde conectivitatea la server, intră în modul deconectat. Harta continuă să afișeze ultimele poziții primite pentru toate traseele, diferențiate vizual printr-un indicator de expirare (de obicei o pictogramă estompată sau o adnotare de marcaj temporal) după ce trece timpul de expirare CoT al traseului. ATAK continuă de asemenea să își transmită propria poziție pe orice cale locală de difuzare disponibilă (multicast UDP, radio MANET). Când conectivitatea este restabilită, ATAK se reconectează automat, iar serverul împinge starea curentă a tuturor traseelor ca actualizare în cascadă, suprascriind pozițiile expirate cunoscute ultima dată. Administratorii trebuie să stabilească timeout-uri de expirare potrivite tempo-ului tactic — o fereastră de expirare de 10 minute previne apariția fantomelor de trasee (ghosting) în medii cu conectivitate precară.

Câtă lățime de bandă consumă BFT peste ATAK pe o legătură MANET?

Un singur eveniment de poziție CoT ATAK (XML CoT cu bloc de detalii) are aproximativ 800–1200 de octeți. La un interval de actualizare de 10 secunde pentru un pluton de 20 de unități, traficul total BFT este de aproximativ 20 × 1000 octeți / 10 s = 2 kB/s, adică circa 16 kbps. Aceasta este cu mult sub capacitatea radiourilor MANET moderne (MPU5 oferă 1–10 Mbps per nod), dar se acumulează rapid în formațiuni mari. Pentru o companie de 100 de unități la intervale de 10 secunde, traficul BFT brut se apropie de 80 kbps — gestionabil, dar semnificativ pe legăturile HF sau satelitare de backhaul. Compresia CoT (zlib peste fluxul TCP) reduce de obicei dimensiunea sarcinii utile cu 40–60%, iar ratele de actualizare adaptivă pot reduce sarcina cu un ordin de mărime în fazele statice.

Ce dispozitive Android sunt certificate pentru BFT militar cu ATAK?

ATAK MIL (varianta militară distribuită prin TAK.gov) rulează pe o gamă de dispozitive Android ruggedizate. Platformele frecvent utilizate includ Samsung Galaxy XCover Pro, Getac PS336, Kyocera DuraForce Pro 2 și tabletele Dell Latitude Rugged. Pentru BFT în mod specific, criteriile de selectare a dispozitivului includ sensibilitatea cipului GPS (pentru canioane urbane și penetrarea vegetației), capacitatea bateriei (sau capacitatea de schimbare la cald), intervalul de temperatură de operare și rezistența la șocuri și apă MIL-STD-810. Dispozitivele cu GNSS multi-constelație (GPS + GLONASS + Galileo) oferă fixări de poziție mai fiabile în medii degradate comparativ cu cipuri numai GPS.