Software UAV de recunoaștere: de la senzor la decizia operatorului

Un UAV transportă senzori. Un senzor produce date. Datele devin informații atunci când sunt fuzionate cu context și plasate în fața unui operator care poate acționa pe baza lor. Distanța dintre aceste două puncte finale — captarea senzorului și decizia operatorului — este bucla senzor-decizie, iar software-ul UAV de recunoaștere este cel care îi guvernează latența, fidelitatea și fiabilitatea. Acest articol examinează pipeline-ul complet: de la configurarea senzorului de bord prin downlink, în stația terestră, prin pipeline-ul de analitica video, și în imaginea operațională comună afișată ofițerilor S2 și S6 din teren.

Bucla senzor-decizie: prezentare generală a arhitecturii

Bucla are cinci etape discrete, fiecare introducând latență și fiecare reprezentând un potențial punct de eșec:

1. Senzorul de bord și codificarea. Sarcinile utile electro-optice (EO), infraroșu (IR), radar cu apertură sintetică (SAR) și SIGINT produc date brute care trebuie comprimate și multiplexate pentru transmitere. Pentru sarcinile utile video, codificarea H.264 sau H.265 are loc pe placa encoder video a UAV-ului. Metadatele MISB (Motion Imagery Standards Board) KLV — poziția platformei, atitudinea, câmpul de vedere al senzorului — sunt încorporate în fluxul de transport în această etapă. Latența de codificare pe hardware capabil este de obicei 30–80 ms.

2. Legătura de date. Fluxul de transport codat este transmis prin aer prin legătura C2 (uplink de comandă și control) și un downlink de informații separat, cu lățime de bandă mai mare. Tipurile comune de downlink includ Tactical Common Data Link (TCDL) la banda C sau Ku pentru platformele MALE și HALE, și legături punct-la-punct la 2,4 GHz sau 5,8 GHz pentru UAS tactice. Latența legăturii pentru un sistem linie-de-vedere bine proiectat este de 10–50 ms; releu prin satelit adaugă 500–600 ms unidirecțional (geostaționari) sau 20–80 ms (orbită joasă), ceea ce modifică semnificativ bugetul de latență pentru țintarea sensibilă la timp.

3. Recepția și decodarea stației terestre. Terminalul de date terestre (GDT) primește semnalul RF și emite un flux de transport MPEG-2 STANAG 4609 prin Ethernet sau serial. Software-ul stației terestre decodează fluxul, demultiplexează metadatele KLV din fluxul elementar video și le transmite consumatorilor din aval. Un stack de recepție bine implementat adaugă mai puțin de 100 ms de latență de procesare în această etapă.

4. Analitica și geolocalizarea. Cadrele decodate sunt transmise pipeline-ului de analitica video — detectare, clasificare și urmărire — în timp ce metadatele KLV extrase simultan alimentează motorul de geolocalizare. Ieșirea acestei etape este un set de detectii geolocalizate și clasificate publicate ca evenimente în rețeaua tactică. Latența analiticii depinde de complexitatea modelului și hardware; un model de dimensiunea YOLOv8 pe o stație de lucru echipată cu GPU procesează cadre 1080p mai rapid decât în timp real, sub 20 ms per cadru. Pe hardware de margine numai CPU, același model poate necesita 80–150 ms per cadru.

5. Afișajul operatorului și decizia. Operatorul vizualizează fluxul video, suprapunerea amprentei senzorului pe hartă și marcajele de detectare analitică în imaginea operațională comună. Latența deciziei — timpul de la afișare la o comandă sau raport — este un factor uman pe care niciun software nu îl poate controla complet, dar reducerea latenței de afișare și îmbunătățirea densității informaționale reduc direct sarcina cognitivă și scurtează ciclul decizional.

STANAG 4609 și MISB KLV: contractul de date

STANAG 4609 este contractul fundamental de date pentru imagistica în mișcare UAV în cadrul cadrelor de interoperabilitate ale alianței. Specifică faptul că videoul UAV trebuie transportat ca flux de transport MPEG-2 cu metadate MISB Local Set (LS) 0601 încorporate. LS 0601 definește aproximativ 140 de elemente de date etichetate care acoperă fiecare parametru de care un analist sau sistem automatizat are nevoie pentru a geolocali conținut în imagine: poziția senzorului, direcția platformei, înclinația, ruliul, unghiurile FOV ale senzorului, raza oblică, unghiul de oblicitate și altele.

Codificarea KLV (Key-Length-Value) utilizată de MISB este un format binar compact. Fiecare element de metadate este identificat printr-o cheie de 1 octet sau 2 octeți, urmată de un câmp de lungime, urmat de valoarea într-o codificare standardizată în virgulă mobilă sau întreg. Un pachet KLV minimal conform pentru un cadru video poate fi de 80–120 de octeți. La 30 de cadre pe secundă, aceasta adaugă aproximativ 3–4 kbps de overhead la fluxul de transport — neglijabil pe orice legătură de date tactică.

Pentru integratori, punctul critic de implementare este că metadatele KLV trebuie extrase în sincronizare cu cadrele video pe care le descriu. Pachetele KLV sunt încorporate în fluxul de transport ca PID-uri de date private alături de PID-ul video. Un parser care procesează cele două PID-uri asincron — sau care întârzie afișarea video fără a întârzia aplicarea metadatelor — va produce erori de geolocalizare care cresc cu viteza platformei și rata de deplasare a gimbalului. La o viteză de 60 noduri la sol și o latență a metadatelor de 1 secundă, eroarea de geolocalizare poate depăși 30 de metri.

Câmpurile obligatorii LS 0601 pentru geolocalizare

Nu toate câmpurile LS 0601 (140+) sunt necesare pentru geolocalizarea de bază. Setul minim necesar pentru a calcula unde cade un pixel din imagine pe sol include: latitudinea senzorului (tag 13), longitudinea senzorului (tag 14), altitudinea adevărată a senzorului (tag 15), unghiul de direcție al platformei (tag 5), unghiul de înclinație al platformei (tag 6), ruliul platformei (tag 7), FOV orizontal al senzorului (tag 16), FOV vertical al senzorului (tag 17), unghiul de azimut relativ al senzorului (tag 18), unghiul de elevație relativ al senzorului (tag 19), ruliul relativ al senzorului (tag 20) și raza oblică (tag 21). Toate celelalte câmpuri sunt suplimentare — utile pentru analiză, dar nu necesare pentru calculul de geolocalizare în timp real.

Pipeline-ul de analitica video: detectare și clasificare

Detectarea automată a obiectelor este etapa cel mai dependentă de ingineria specifică domeniului. Modelele de detectare de uz general antrenate pe imagini civile performează slab pe imagini militare din perspectivă UAV — unghiul de vizualizare, scara, camuflajul și diversitatea țintelor sunt toate diferite. Un model utilizat în producție ar trebui fin-acordat pe un set de date etichetat reprezentativ pentru mediul operațional: tipuri de ținte (vehicule, personal, instalații), intervalul de altitudine, tipul senzorului (EO vs. IR) și clasele de fundal (urban, rural, forestier, mixt).

Arhitectura standard pentru analitica video UAV în timp real utilizează un pipeline în două etape: un detector rapid cu o singură etapă (YOLOv8 sau echivalent) care rulează la rata completă de cadre pentru detectare și clasificare aproximativă, alimentând detecțiile unui model de clasificare mai lent, dar mai precis, care confirmă clasa și atribuie încrederea. Detectorul rapid prioritizează recuperarea — prinderea tuturor țintelor potențiale chiar cu prețul falselor pozitive. Clasificatorul filtrează lista de detectii și atribuie eticheta finală. Această separare permite sistemului să opereze la rata de cadre video aplicând în același timp mai multă putere de calcul detecțiilor confirmate.

Geolocalizarea detecțiilor

Fiecare casetă de delimitare a detectiei trebuie convertită într-o coordonată WGS84 pe planul terestru înainte de a putea fi publicată ca eveniment geospațial. Calculul utilizează coordonatele pixel ale centroidului detectiei, geometria senzorului din metadatele KLV și un model de elevație a terenului (DTED Nivelul 1 sau Nivelul 2). Abordarea standard este proiectarea unui fascicul de la senzor prin pixelul din planul imagine și intersecția cu suprafața terenului. Fără un DEM, o aproximare pâmânt-plat folosind raza oblică introduce erori dependente de elevație care devin semnificative pe teren deluros sau muntos.

Pentru urmărirea detecțiilor — legarea detecțiilor între cadre pentru a produce piste persistente — un filtru Kalman sau algoritmul SORT (Simple Online and Realtime Tracking) este standardul de producție. Pistele persistente reduc sarcina cognitivă a operatorului comparativ cu detecțiile per cadru: în loc de o hartă care pâlpâie cu marcaje noi în fiecare cadru, operatorul vede un număr mic de marcaje stabile, mobile, cu istoricul încrederii.

Integrarea stației terestre și arhitectura legăturii C2

Stația terestră este centrul buclei senzor-decizie. O stație terestră de producție pentru un program UAS tactic rulează de obicei mai multe componente software în paralel: receptorul și demultiplexorul fluxului de transport, aplicația de afișare video (cu înregistrarea misiunii), extractorul de metadate KLV, pipeline-ul de analitica și publisher-ul CoT/rețeaua tactică.

Uplink-ul C2 — comenzi de la operator la UAV — și downlink-ul de informații sunt logic separate, dar partajează adesea același sistem RF. Integritatea legăturii C2 este mai greu de protejat decât downlink-ul: mesajele de comandă sunt mici, dar trebuie să sosească cu latență foarte mică și fiabilitate ridicată. Arhitectura standard pentru integritatea legăturii C2 utilizează un uplink dedicat cu bandă îngustă la o frecvență separată de downlink-ul de informații cu bandă largă, cu criptare AES-256 și FHSS (frequency-hopping spread spectrum) pentru rezistență la bruiaj. Software-ul de pe stația terestră trebuie să monitorizeze valorile de calitate ale legăturii C2 — rata de erori de biți, latența de confirmare a comenzilor dus-întors — și să alerteze operatorul înainte ca degradarea legăturii să cauzeze pierderea controlului aeronavei.

Pattern-ul de plugin ATAK pentru fluxurile UAV

Integrarea unui flux UAV în ATAK — aplicația standard de conștientizare situațională tactică — urmează o arhitectură de plugin bine stabilită. Un plugin de integrare UAV are trei componente funcționale care operează concurent.

Componenta panoului video. Un panou susținut de SurfaceView în interiorul ferestrei plugin-ului ATAK redă fluxul video decodat. Decodorul video rulează într-un fir de fundal, împingând cadre pe suprafață la rata de cadre nativă a fluxului. Panoul ar trebui să includă adnotări suprapuse (casete de țintă din pipeline-ul de analitica) redate prin Canvas pe un strat transparent deasupra suprafeței video, sincronizate cu cadrul afișat.

Componenta suprapunerii amprentei. Cele patru coordonate de colț ale amprentei senzorului — calculate din câmpurile de geometrie MISB și modelul de teren — sunt publicate ca un eveniment poligon CoT și redate pe harta ATAK ca un trapez semitransparent. Poligonul amprentei se actualizează la rata metadatelor KLV (de obicei 1–10 Hz pentru majoritatea sistemelor). La rate de actualizare mai lente, amprenta poate părea că întârzie afișajul video în timpul deplasărilor rapide ale gimbalului; soluția este extrapolarea poziției amprentei folosind rata de schimbare a atitudinii platformei între actualizările de metadate.

Componenta publisher-ului de detectii. Detecțiile geolocalizate din pipeline-ul de analitica sunt publicate ca evenimente punct CoT pe TAK Server cu coduri de tip CoT corespunzătoare. Pistele de detectie cu identitate persistentă sunt publicate cu un UID consistent între actualizări, astfel încât clienții ATAK le afișează ca marcaje mobile, mai degrabă decât o secvență de evenimente independente. Plugin-ul ar trebui să permită operatorului să confirme sau să respingă o detectie — detecțiile confirmate sunt promovate la un tip CoT cu încredere mai mare; detecțiile respinse sunt eliminate din imagine.

Bugete de latență pentru ținte sensibile la timp

Țintarea sensibilă la timp — procesul de detectare, identificare și angajare a unei ținte care se prezintă pentru o fereastră scurtă — impune cele mai stricte cerințe de latență asupra stack-ului de software UAV de recunoaștere. Doctrina militară relevantă specifică un ciclu de țintire sub 30 de minute pentru țintarea deliberată; țintarea sensibilă la timp comprimă aceasta la minute sau secunde în funcție de tipul amenințării.

În cadrul pipeline-ului software, alocările bugetului de latență cele mai importante sunt:

Latența afișajului video: sub 500 ms total de la captarea senzorului la afișajul operatorului. Aceasta înseamnă codificare (80 ms) + legătură (50 ms, linie-de-vedere) + decodare (30 ms) + pipeline de afișare (20 ms) = aproximativ 180 ms pentru un sistem bine optimizat. Bufferizarea pentru streaming cu rată de biți adaptivă sau compensarea jitter-ului adaugă adesea 200–500 ms în plus față de aceasta — setările agresive ale bufferului sunt cea mai frecventă sursă de latență de afișare inacceptabilă.

Latența detectie-CoT: sub 3 secunde de la detectie în pipeline-ul de analitica până la evenimentul CoT vizibil pe clienții ATAK conectați. Acest buget acoperă inferența de detectie (20–150 ms), calculul de geolocalizare (10 ms), construcția și publicarea evenimentului CoT (5 ms), releu TAK Server (50–200 ms în funcție de hopurile de federație) și actualizarea clientului ATAK (100–500 ms în funcție de intervalul de sondaj pentru actualizare).

Latența operator-C2: sub 2 secunde de la desemnarea unei ținte de către operator în plugin-ul ATAK până la o comandă care ajunge la operatorul UAV sau elementul de control al focului. Aceasta este în principal o latență de rețea și sistem C2 — contribuția plugin-ului de integrare UAV este neglijabilă dacă publică CoT imediat la acțiunea operatorului.

Pentru o tratare mai aprofundată a arhitecturii de viziune computerizată utilizate în pipeline-ul de analitica, consultați articolul despre viziunea computerizată pentru drone ISR.