Părțile 1 și 2 au produs piste de încredere. Partea 3 construiește suprafața pe care operatorul o vede efectiv. Imaginea Operațională Comună este stratul pe care platforma este judecată — reușiți și iertarea se propagă în jos prin restul stivei; greșiți și un pipeline de fuziune corect din punct de vedere tehnic este dezactivat în a doua săptămână de operațiuni. Modelele arhitecturale sunt stabilite (consultați Imaginea Operațională Comună: Cum Este Construită în Software-ul Modern de Apărare); Partea 3 le transformă în decizii inginerești specifice.
Pasul 1: Stiva Frontend
Pentru platforma exemplu în derulare, imaginea operațională comună este o aplicație bazată pe browser. Alegerea între native și web a fost tranșată în favoarea web-ului de peste un deceniu; amprenta reziduală native se regăsește în platforme portabile specializate (ecosistemul ATAK — consultați Dezvoltarea Plugin-urilor ATAK) mai degrabă decât în afișajele postului de comandă.
Stiva justificabilă:
- React cu TypeScript pentru shell-ul aplicației. Maturitatea ecosistemului, disponibilitatea forței de muncă și instrumentele prietenoase acreditării fac din aceasta alegerea sigură pentru o platformă de 20 de ani. Vue este justificabil; Svelte nu este încă o alegere de nivel achiziții pentru apărare.
- Cesium pentru vizualizarea globului și 3D — teren, volume de spațiu aerian, piste de sateliți. Accelerat WebGL, matur, standardul de facto pentru 3D geospațial în apărare.
- Mapbox GL sau MapLibre pentru vizualizarea hărții 2D. Tile-uri vectoriale pentru viteză; fallback la tile-uri raster pentru offline. Compromisurile și plafonul de performanță sunt în Randarea Hărților în Timp Real pentru C2 Militar.
- Zustand sau Redux Toolkit pentru stare. Volumul de actualizări streaming ale pistelor face inutilizabilă starea React naivă; utilizați un store cu selectori stabili la referință și comparații shallow-equal.
- Ant Design sau Mantine pentru interfața utilizator înconjurătoare — panouri, modale, formulare. Rezistați tentației de a construi un sistem de design bespoke la prima construire; alegeți o bibliotecă matură și tematizați-o conform convențiilor de apărare.
O decizie non-evidentă: mențineți imaginea operațională comună ca aplicație cu o singură pagină, nu ca site multi-pagină. Operatorii nu navighează. Ei deschid imaginea operațională comună o dată și o utilizează ore în șir. Reîncărcările de pagini sunt abstractizarea greșită; vizualizările și panourile în cadrul unui singur shell sunt cea corectă.
Pasul 2: Simbologia Militară, Realizată Corect
Pistele se randează ca simboluri. Catalogul de simboluri este guvernat de MIL-STD-2525D (sau varianta echivalentă NATO APP-6). Simbologia realizată ad-hoc este un semnal de alarmă în achiziții și un blocant al interoperabilității: în momentul în care platforma se integrează cu un sistem aliat, simbolurile nepotrivite declanșează un eșec imediat de conformitate.
Utilizați o bibliotecă întreținută. Implementarea open-source milsymbol este alegerea de facto pentru imaginile operaționale comune bazate pe web; produce setul standard de simboluri ca SVG sau elemente de desen pe canvas. Biblioteca gestionează afilierea (prieten, ostil, neutru, necunoscut), marcatorii de eșalon, textul de identificare și modificatorii care transformă un simbol generic de infanterie în „Batalionul 1, mecanizat, în postură defensivă".
Modelul de integrare: motorul de fuziune emite piste cu atribute de identitate; imaginea operațională comună caută codul SIDC (Symbol Identification Code) MIL-STD-2525 corespunzător acelor atribute; biblioteca randează simbolul. Memorați în cache simbolurile randate după SIDC; același simbol este reutilizat de mii de ori într-o imagine operațională tipică.
Un detaliu practic care merită evidențiat: MIL-STD-2525D are mii de simboluri distincte. Aproape niciun scenariu operațional relevant nu utilizează mai mult de câteva sute. Construiți catalogul din interior spre exterior — începeți cu ceea ce produc senzorii platformei, extindeți pe măsură ce sosesc noi clase de senzori.
Pasul 3: Actualizări în Timp Real prin WebSocket
Sarcina imaginii operaționale comune este de a reflecta depozitul de piste în aproape timp real. Interogarea repetată nu este scalabilă; WebSocket este răspunsul structural. Modelul arhitectural:
Un serviciu gateway menține deschise conexiunile WebSocket la fiecare browser. Se abonează la topicurile tracks.updates și tracks.lifecycle ale motorului de fuziune. Când sosește o actualizare a pistei, gateway-ul evaluează filtrul per conexiune (ce zonă, ce roluri, ce clasificări) și transmite actualizarea browserului. Browserul aplică actualizarea în store-ul local de stare; React re-randează doar simbolurile afectate.
Detaliile inginerești non-evidente care determină dacă aceasta funcționează la scară:
Filtrarea are loc pe server. Transmiterea tuturor pistelor la fiecare browser nu funcționează — la 10.000 de piste actualizate de mai multe ori pe minut, atât rețeaua cât și browserul se blochează. Fiecare conexiune are un filtru de abonament (limitele viewport-ului, straturi bazate pe rol, filtru de clasificare) și doar actualizările corespunzătoare sunt transmise.
Actualizări delta, nu înlocuiri complete. O actualizare a pistei este parțială — poziția s-a schimbat, starea ciclului de viață s-a schimbat, identitatea a fost rafinată. Browserul aplică patch-ul la copia sa locală. Payload-urile complete ale pistelor sunt trimise doar la abonamentul inițial și la migrațiile de schemă.
Reconectare cu recuperarea stării. Conexiunile WebSocket se pierd, mai ales în rețelele tactice. La reconectare, browserul schimbă numărul de secvență văzut ultima dată cu gateway-ul, care redă actualizările ratate de pe magistrală. Fără pierdere de stare, fără refetch complet.
Gestionarea contrapresiunii. Un client lent nu trebuie să blocheze gateway-ul. Adâncimea cozii per client este limitată; când coada depășește limita, clientul este deconectat și forțat să se reconecteze cu un fetch complet al stării. Mai bine un operator care se reconectează decât toți operatorii înghețați.
Pasul 4: Filtrarea Bazată pe Rol și Clasificare
Nu fiecare operator vede fiecare pistă. Imaginea operațională comună a unui comandant de pluton de infanterie nu afișează zonele de angajare ale apărării antiaeriene. Un cont NATO-RESTRICTED nu vede pistele clasificate SECRET. Platforma aplică aceasta în două locuri: filtrul gateway (ce să trimită) și motorul de politici (dacă să trimită deloc).
Filtrul de rol este o configurație per-utilizator, per-sesiune: ce tipuri de piste, ce zone de operații, ce straturi de afișare. Utilizatorul poate ajusta în limitele autorizației sale; sistemul aplică limita superioară. Filtrul de clasificare este non-negociabil: clasificarea efectivă a unei piste (calculată în fuziune, propagată la gateway) trebuie să fie la sau sub autorizarea utilizatorului. Verificările încrucișate la nivelul API și al bazei de date — niciodată doar la nivel UI — sunt regula. Modelul detaliat se găsește în Controlul Accesului Bazat pe Rol în Sistemele C2 de Apărare.
O notă operațională: construiți interfața de configurare a rolului împreună cu comunitatea de operatori, nu în izolare. Valorile implicite contează. Un utilizator de infanterie nu dorește să înceapă fiecare sesiune dezactivând șase straturi de date de apărare antiaeriană irelevante. Un operator de aripă nu dorește să înceapă fiecare sesiune activând straturile de apărare antiaeriană pe care predecesorul său le-a dezactivat. Valorile implicite bazate pe rol care corespund activității efective a operatorului reduc la jumătate nivelul de bază al frustrării operatorilor.
Concluzie cheie: Imaginea operațională comună care câștigă o demonstrație este densă, animată și plină de suprapuneri. Imaginea operațională comună care câștigă operațiunile este reținută, rapidă și afișează doar ceea ce operatorul necesită. Implicit, optați pentru mai puține simboluri, mai mari și cu contrast mai ridicat. Permiteți operatorilor să adauge detalii; nu îi porniți la densitate maximă de informații.
Pasul 5: Ergonomia Operatorului
O imagine operațională comună care eșuează ergonomic eșuează operațional. Disciplina este construită dintr-un set de reguli non-negociabile.
Indicarea pistelor depășite. Când starea ciclului de viață al unei piste este în estompare sau pierdută, simbolul se schimbă — de obicei mai estompat, posibil cu contur, cu un indicator de vârstă. Operatorii trebuie să vadă dintr-o privire în care piste pot avea încredere.
Interfața de rezolvare a conflictelor. Când doi operatori editează simultan aceeași pistă sau sarcină, platforma trebuie să evidențieze conflictul, nu să suprascrie tăcut o parte. Ultimul scriitor câștigă pe bază de atribut individual este implicit; reconciliere explicită pentru atributele cu mize ridicate.
Design axat pe tastatură. Interfețele doar cu mouse eșuează în operațiuni stresante. Fiecare acțiune comună are o scurtătură de tastatură; scurtăturile sunt documentate în produs și ușor de descoperit.
Operare cu atingere și mănuși pentru ținte robuste. Aceeași imagine operațională comună rulează în posturile de comandă pe stații de lucru și pe tablete robuste în pozițiile de brigadă avansată. Țintele de atingere sunt dimensionate pentru mănuși; modurile de contrast ridicat sunt de primă clasă. Modelul mai amplu se găsește în Interfață Robustă pentru Operatorii Militari.
Operare offline. Implementările la marginea tactică pierd conectivitatea. Imaginea operațională comună trebuie să funcționeze pe cache-ul local, să redea acțiunile operatorilor puse în coadă la reconectare și să indice clar ce date sunt depășite. Modelul arhitectural se găsește în Aplicații Militare Offline-First; latura hărților offline în Hărți Offline cu MBTiles și PMTiles.
Pasul 6: Dincolo de Hartă — Tablouri de Bord și Panouri
Imaginea operațională comună este mai mult decât o hartă. Operatorii necesită interfețe de atribuire sarcini, compunere mesaje, instrumente de planificare, panouri de informații, vizualizări de jurnale. Regula UX la nivelul platformei: fiecare panou respectă aceleași convenții de interacțiune. Dacă selectarea unei piste pe hartă o evidențiază într-un panou lateral, atunci selectarea unei piste în orice panou o evidențiază pe hartă. Inconsistența pe acest strat este cel mai frecvent eșec UX în software-ul de apărare.
Separarea arhitecturală care merită menținută: vizualizarea hărții este un panou; tablourile de bord și panourile laterale sunt alte panouri; ele partajează aceeași stare de selecție prin store-ul central. Adăugarea unui nou instrument de analiză este un panou nou, nu o aplicație nouă. Modelele de arhitectură a tablourilor de bord se găsesc în Arhitectura Tablourilor de Bord C2.
Pasul 7: Obiective de Performanță
Obiectivele imaginii operaționale comune sunt mai stricte decât par:
- Încărcare inițială sub 3 secunde pe un laptop de margine tactică cu active statice în cache.
- Latența actualizării pistei sub 200 ms de la emiterea gateway-ului la simbolul vizibil deplasat în browser.
- Randare hartă susținută la 60 FPS cu până la 10.000 de piste vizibile.
- Responsiv la panoramare și zoom la scale tipice de hartă tactică (1:50.000 la 1:1.000.000).
- Memorie limitată — browserul trebuie să ruleze toată ziua fără scurgeri. Profilați fiecare lansare.
Obiectivele sunt realizabile cu stiva aleasă; neatingerea lor este de obicei rezultatul unui shortcut arhitectural mai devreme în pipeline (filtrarea server-side neimplementată, payload-uri complete în loc de delta, gestionarea naivă a stării).
Ce Urmează
Partea 3 a construit imaginea operațională comună. Pistele se randează cu simbologia corectă; actualizările sunt transmise prin WebSocket; operatorii văd doar ceea ce sunt autorizați să vadă; ergonomia susține operațiunile reale. Platforma este acum utilizabilă de un operator — dar nu este încă pregătită de livrare.
Partea 4 închide bucla: punți de interoperabilitate NATO (CoT, MIP4, STANAG 4559), etichetarea clasificărilor și aplicarea permisivității de distribuire, pipeline-ul DevSecOps care produce dovezi de acreditare și implementarea izolată fizic pentru utilizarea la marginea tactică. După Partea 4, platforma este implementabilă operațional.