Fuziunea informațiilor din SIGINT, IMINT, HUMINT și OSINT într-o singură imagine coerentă pare simplă ca concept. În practică, este una dintre cele mai dificile probleme de inginerie din infrastructura de date din apărare. Fiecare disciplină produce date cu o viteză diferită, într-un format diferit, cu un model de încredere diferit — iar un sistem care doar agregă aceste fluxuri fără a le corela cu adevărat produce o imagine mai zgomotoasă decât un flux INT unic bine gestionat, nu una mai bună. O integrare serioasă a datelor pentru informațiile din apărare necesită o arhitectură proiectată de la principii fundamentale în jurul proprietăților fiecărui tip de sursă, nu un depozit de date generic cu adaptoare INT adăugate ulterior.

Acest articol parcurge întreaga arhitectură a unui sistem de fuziune multisursă în timp real — de la stratul de ingestie a fluxurilor care absoarbe fluxuri eterogene, prin rezoluția entităților și motorul de corelare, până la evaluarea încrederii și publicarea unei imagini informative îmbogățite către sistemele C2. Fiecare secțiune tratează deciziile specifice de proiectare care separă fuziunea de nivel producție de sistemele-prototip care arată corect într-o demonstrație, dar eșuează la scară operațională.

Problema fuziunii informațiilor multisursă — de ce fuziunea SIGINT/IMINT/HUMINT/OSINT este mai grea decât pare

Trei probleme structurale fac fuziunea multisursă calitativ mai grea decât procesarea oricărui INT individual la scară. Ignorarea lor — tratarea fuziunii ca pe o simplă problemă de conductă de date — este cea mai frecventă greșeală arhitecturală și produce un sistem care nu mai poate fi corectat odată ce datele curg la volum de producție.

Heterogenitatea formatelor este cea mai vizibilă problemă. O înregistrare de interceptare ELINT poartă frecvența emițătorului, intervalul de repetare a impulsului, tipul de scanare, azimutul și date de diferență de timp la sosire. O detecție IMINT poartă o casetă de delimitare, un scor de încredere în spațiul pixelilor, o distanță de eșantionare la sol și o coordonată UTM cu CEP asociat. Un extras narativ HUMINT poartă text liber, un grad al sursei atribuit de analist, o locație denumită și o fereastră temporală măsurată în ore sau zile. Aceste trei înregistrări pot să se refere toate la același obiect din lumea reală — un vehicul radar — dar nu împart niciun câmp comun, nicio convenție comună de sistem de coordonate și niciun identificator comun. Normalizarea lor într-o singură schemă canonică necesită adaptoare construite special pentru fiecare tip de sursă și un model canonic de entități care să le poată acomoda pe toate fără a le comprima semantica. Proiectarea modelului de date pentru fuziunea militară a senzorilor multi-INT acoperă acel strat canonic în detaliu.

Nepotrivirea încrederii este mai subtilă, dar provoacă mai multe erori analitice. Fiecare INT aplică propriul său model de încredere. Geolocalizarea SIGINT poartă un CEP (Circular Error Probable) în metri — o estimare a preciziei geometrice. Detecția IMINT poartă o probabilitate de clasificare — logit-ul de ieșire al rețelei neuronale pentru clasa obiectului. HUMINT poartă un grad de fiabilitate Admiralty — o scară de judecată umană cu șase niveluri. Aceste trei numere înseamnă lucruri fundamental diferite. Un sistem de fuziune naiv care le mediază produce un număr valid matematic, dar lipsit de sens analitic. Un model corect de încredere trebuie mai întâi să traducă fiecare încredere nativă a sursei într-un cadru probabilistic comun, apoi să agregheze între surse folosind un sistem bayesian sau de combinare a dovezilor (cum ar fi Dempster-Shafer) care tratează corect dovezile dependente și independente.

Deviația temporală este problema care rupe cel mai vizibil arhitecturile de fuziune în timp real. Sursele diferite au latențe foarte diferite de la producerea evenimentului până la sosirea datelor în conductă. O interceptare SIGINT poate ajunge în conductă la secunde de la transmisiune. Un IMINT de la un satelit direcționat poate necesita 60–90 de minute de procesare a imaginilor înainte de producerea unei înregistrări de detecție. Un raport HUMINT care descrie evenimentele de ieri poate fi ingerat în ziua D+2. Un motor de fuziune care corelează înregistrările după marcajul de sosire în conductă va asocia greșit sistematic evenimentele — nu va reuși să lege interceptarea SIGINT de confirmarea IMINT pentru că au ajuns la 90 de minute distanță, deși descriu același eveniment. Arhitectura trebuie să separe timpul evenimentului (când s-a produs evenimentul în lume) de timpul de ingerare (când a ajuns mesajul în conductă) și să efectueze întreaga corelare temporală pe timpul evenimentului, folosind timpul de ingerare doar pentru monitorizarea performanței conductei.

Arhitectura de ingestie a fluxurilor — Kafka vs Pulsar pentru fluxurile de informații, registrul de scheme pentru tipurile de mesaje eterogene, gestionarea contrapresiunii

Stratul de ingestie a fluxurilor trebuie să gestioneze mesaje care sosesc cu rate de la câteva rapoarte HUMINT pe oră până la milioane de înregistrări SIGINT pe oră de la un singur sistem de culegere, toate curgând în aceeași conductă de fuziune. Proiectarea trebuie să absoarbă traficul exploziv de la sursele cu viteză ridicată fără a aplica acea contrapresiune surselor cu viteză redusă și prioritate ridicată — un raport HUMINT care sosește într-un val alături de un potop SIGINT nu trebuie întârziat pentru că conducta este saturată.

Alegerea arhitecturală principală la acest strat este între Apache Kafka și Apache Pulsar. Ambele sunt distribuite, tolerante la defecte și testate în luptă la scara sistemelor de nivel apărare. Kafka are un ecosistem mai mare și o integrare mai strânsă cu cadrele de procesare a fluxurilor — atât Kafka Streams, cât și Apache Flink au conectori de sursă Kafka de prim rang. Pulsar oferă multi-închiriere nativă, izolare a subiectelor per spațiu de nume și o arhitectură de calcul-stocare separată. Pentru o platformă de fuziune cu un singur chiriaș care operează într-un singur domeniu de clasificare, Kafka este alegerea pragmatică. Pentru o platformă care trebuie să izoleze fluxurile după nivelul de clasificare, să susțină noduri disconectate desfășurate în avans care se sincronizează asincron către un cluster din spate sau să deservească mai multe organizații chiriașe, arhitectura Pulsar oferă primitive de izolare mai curate, fără soluții ad-hoc.

Indiferent de alegerea brokerului, structura de subiecte trebuie să impună un subiect per tip de sursă, nu un subiect per disciplină INT:

# Convenție de denumire a subiectelor: {classification}.{int-type}.{source-id}.raw ts.sigint.comint-system-alpha.raw ts.sigint.elint-collection-bravo.raw ts.imint.uav-sensor-charlie.raw ts.imint.sat-proc-delta.raw ts.humint.field-reports.raw ts.osint.ais-feed.raw ts.osint.social-monitor.raw # Subiecte de ieșire normalizate (după adaptor) ts.fusion.observations.normalized ts.fusion.entities.enriched ts.fusion.correlations.output

Un registru de scheme este obligatoriu pentru subiectele de ieșire normalizate. Fără scheme impuse, un singur mesaj defect de la orice adaptor poate corupe contextul de deserializare al unui consumator din aval și poate bloca întreaga conductă de fuziune. Registrul impune scheme Avro sau Protobuf la fiecare scriere în subiectele de fuziune și respinge mesajele care eșuează la validare înainte de a ajunge la broker. Regulile de compatibilitate a schemelor — BACKWARD, FORWARD sau FULL — trebuie setate per subiect, în funcție de modul în care evoluează consumatorii. Pentru schema normalizată de observații, compatibilitatea BACKWARD este potrivită: versiunile noi de schemă pot adăuga câmpuri opționale, iar consumatorii vechi care nu înțeleg câmpurile noi vor continua să funcționeze corect.

Gestionarea contrapresiunii necesită limite de rată pe tip de sursă, cu clasificare a priorității. Sursele cu prioritate ridicată — SIGINT și IMINT de la sisteme de culegere în timp real — nu trebuie niciodată limitate ca rată. Sursele cu prioritate redusă — ingestia în masă de OSINT, încărcarea istorică de HUMINT — trebuie să poarte ponderi explicite de prioritate care permit brokerului să le restricționeze consumatorii când debitul conductei este constrâns. În Kafka, acest lucru se implementează prin cote de grup de consumatori și strategii de alocare a partițiilor. În Pulsar, limitele de rată per spațiu de nume și cotele de expediere oferă un control echivalent. Modelele de arhitectură pentru conducta militară de date de informații acoperă în profunzime managementul cozilor și proiectarea grupurilor de consumatori.

Rezoluția entităților și deduplicarea — strategii de blocare pentru generarea candidaților de entități, evaluarea similarității bazată pe ML, îmbinarea entităților pe bază de graf

Rezoluția entităților este componenta care transformă un flux de observații independente — fiecare descriind un obiect detectat sau un eveniment raportat — într-un set de înregistrări de entități unificate, în care toate observațiile despre același obiect din lumea reală au fost îmbinate. Este cea mai greu de corectat componentă și cea mai predispusă la degradare silențioasă: un sistem cu o rezoluție proastă a entităților nu se prăbușește; produce o imagine cu prea multe entități (piste fragmentate) sau prea puține (îmbinări false), iar aceste erori se compun în timp, pe măsură ce fuziunea se construiește pe o stare de entități coruptă.

Abordarea naivă — compararea fiecărei observații sosite cu fiecare entitate existentă — este computațional infezabilă la orice scară realistă. Un sistem de culegere ELINT care produce 10.000 de înregistrări de interceptare pe minut împotriva unui corpus de 50.000 de piste de entități active ar necesita 500 de milioane de comparații pe minut înaintea oricărei evaluări a similarității. Strategiile de blocare reduc acest set la un set de candidați tratabil, exploatând structura datelor de informații:

  • Blocarea pe celule geografice — indexați fiecare entitate după locația sa estimată folosind o grilă hexagonală H3 la nivelul de rezoluție 9 (celule de aproximativ 0,1 km²). O observație sosită generează perechi de candidați numai împotriva entităților din aceeași celulă și a celor șase vecine imediate. Această singură cheie de blocare elimină peste 99,9% din perechile de candidați pentru date spațiale, realizând în același timp o rechemare ridicată pentru observațiile cu adevărat co-localizate.
  • Blocarea temporală — restricționați candidații la entitățile a căror interval de timp valid se suprapune pe o fereastră configurabilă în jurul timpului evenimentului observației. Pentru un vehicul în mișcare, fereastra trebuie să țină seama de viteza maximă plauzibilă între ultima observație și locația observației curente — un tanc nu poate parcurge 50 km în 5 minute. Blocarea temporală fără blocare pe celule geografice produce seturi de candidați uriașe pentru orice entitate activă global; cele două funcționează împreună ca o cheie compusă.
  • Blocarea pe identificatori duri — grupați toate înregistrările care împart un identificator determinist (IMSI, ieșire OCR a plăcuței de înmatriculare, hash biometric, cod de transponder Mode-S al aeronavei) într-un singur cluster de candidați, indiferent de locație sau de timp. Identificatorii duri ocolesc toate celelalte blocări și sunt tratați ca semnale definitive de îmbinare, sub rezerva unei verificări de deduplicare a identificatorului în sine.
  • Blocarea pe afinitate de tip INT — anumite perechi INT încrucișate sunt structural improbabil să se potrivească și nu trebuie evaluate. O observație de emisie SIGINT maritimă nu trebuie evaluată împotriva unei piste IMINT a unui vehicul terestru. Regulile de afinitate, definite pe tip de entitate, elimină perechile de candidați structural implauzibile înainte de evaluare.

Evaluarea similarității perechilor de candidați folosește un model de stimulare a gradientului (XGBoost sau LightGBM) antrenat pe perechi etichetate potrivire/nepotrivire din date istorice de informații. Vectorii de caracteristici includ: distanța spațială normalizată prin incertitudinea pozițională, distanța temporală normalizată prin plicul de viteze al tipului de entitate, scorul de suprapunere a atributelor pentru atribute tipizate (clasa entității, apartenența, tipul de echipament) și greutatea de compatibilitate a tipului INT. Modelul produce o probabilitate de potrivire în [0, 1]. Perechile deasupra unui prag ridicat (în mod tipic 0,85–0,92) sunt îmbinate automat; perechile dintr-o bandă intermediară sunt direcționate către analiză umană; perechile sub un prag scăzut sunt tratate ca entități separate.

Îmbinarea entităților pe bază de graf gestionează cazul multiplu — în care trei sau mai multe observații trebuie toate rezolvate la aceeași entitate. Se menține un graf în care nodurile sunt înregistrările de observații, iar muchiile sunt decizii de îmbinare cu scoruri de încredere asociate. Componentele conexe ale grafului reprezintă clusterii de candidați de entități. Înregistrarea aurie (golden record) pentru fiecare cluster este calculată aplicând politica de îmbinare definită asupra tuturor observațiilor contribuitoare. Când se adaugă o muchie nouă cu încredere ridicată care leagă două componente anterior disjuncte, componentele sunt îmbinate, iar înregistrările lor aurii sunt combinate. Reprezentarea pe graf permite și operații de divizare: eliminarea unei muchii cu încredere ridicată și recalcularea componentelor conexe este mecanismul de corectare a unei îmbinări false.

Referință de arhitectură
Conducta de rezoluție a entităților — fluxul etapelor
1
Blocare — generați perechi de candidați prin chei geocelulare, temporale și de identificator dur. Țintă de rechemare: >99,5% din potrivirile reale din setul de candidați.
2
Extragerea caracteristicilor — calculați distanța spațială, delta temporală, suprapunerea atributelor și compatibilitatea tipului INT pentru fiecare pereche de candidați.
3
Evaluare ML — modelul de stimulare a gradientului produce probabilitatea de potrivire pentru fiecare pereche. Perechile cu identificatori duri ocolesc evaluarea și merg direct la îmbinare.
4
Dirijare pe praguri — Scor ≥ 0,88: îmbinare automată. 0,55–0,87: coadă de analiză umană. < 0,55: respingere (entități separate).
5
Îmbinare pe graf — actualizați graful de entități cu muchii noi; recalculați înregistrările aurii ale componentelor conexe; emiteți entitățile actualizate în fluxul de entități îmbogățite.
Conductă de rezoluție a entităților cu cinci etape, de la generarea candidaților până la publicarea înregistrării aurii.

Proiectarea motorului de corelare — corelare pe bază de ferestre (proximitate temporală), corelare spațială (agrupare geocelulară), corelare semantică (potrivirea atributelor entității)

În timp ce rezoluția entităților întreabă „sunt aceste observații despre același obiect?”, motorul de corelare întreabă „formează aceste evenimente care implică obiecte diferite un model semnificativ?”. Un vehicul detectat lângă un depozit logistic, urmat 20 de minute mai târziu de același vehicul la un punct de alimentare cu combustibil, urmat de o interceptare SIGINT a unui apel radio consistent cu un raport de poziție de unitate de la punctul de alimentare — aceste trei evenimente implică același vehicul, dar descriu și un model situațional (activitate de reaprovizionare) care este analitic mai semnificativ decât orice observație singulară. Motorul de corelare produce acel obiect de informații de ordin superior.

Corelarea operează simultan pe trei planuri:

Corelarea temporală grupează evenimentele în ferestre după marcajul lor de timp și caută modele de co-apariție în interiorul fiecărei ferestre. Definiția ferestrei este configurabilă per regulă: o regulă care detectează declanșarea simultană a bruiajului și perturbarea comunicațiilor prietene poate folosi o fereastră de 30 de secunde; o regulă care detectează un vehicul la un punct de trecere, urmat de alt vehicul la același punct de trecere, poate folosi o fereastră de 2 ore. Ferestrele glisante (suprapuse cu jumătate din durata ferestrei) asigură că evenimentele de la granițele ferestrelor nu sunt ratate. Fereastrarea în timpul evenimentelor din Apache Flink, cu mărci de apă (watermarks), este alegerea standard de implementare, deoarece gestionează corect sosirea evenimentelor în afara ordinii — critic pentru o conductă în care IMINT și HUMINT au latențe de ingerare foarte diferite.

Corelarea spațială grupează entitățile după locația lor estimată folosind agruparea geocelulară la o rezoluție calibrată pe scara spațială a regulii de corelare. Rezoluția H3 la nivelul 8 (aproximativ 0,7 km²) este potrivită pentru detectarea vehiculelor care operează în aceeași zonă; rezoluția H3 la nivelul 6 (aproximativ 36 km²) pentru detectarea modelelor de activitate pe o regiune. Spre deosebire de blocarea geocelulară din rezoluția entităților (care are nevoie de rechemare ridicată), agruparea spațială de corelare are nevoie de precizie definită de regulă: o regulă de corelare care detectează co-localizarea unui vehicul de comandă cu un vehicul logistic trebuie să folosească o celulă mai strânsă decât o regulă care detectează activitatea de aprovizionare la nivel de zonă. Regulile își codifică propriul parametru de rezoluție spațială, moștenind o setare globală.

Corelarea semantică potrivește entitățile pe baza valorilor atributelor, nu a proximității spațiale sau temporale. O entitate clasificată ca radar de apărare antiaeriană care începe să emită, corelată cu o entitate clasificată ca aeronavă de luptă care intră în zona de acoperire a radarului — corelarea este condusă de semantica atributelor (tipul radarului vs tipul aeronavei și traiectoria), nu de co-localizarea lor. Regulile semantice codifică predicate de atribute asupra tipurilor de entități: entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Aceste expresii de predicate sunt evaluate de procesorul de flux asupra fiecărui eveniment de actualizare a entității; când toate predicatele unei reguli se declanșează în fereastră, corelarea se declanșează.

Regulile de corelare sunt stocate ca definiții declarative într-un registru de reguli, nu ca logică încorporată în cod. Acest lucru permite analiștilor de informații să elaboreze reguli noi fără implicarea inginerilor și permite aplicarea schimbărilor de reguli fără redesfășurarea motorului de corelare:

# Exemplu de definiție a regulii de corelare (YAML) rule_id: RESUPPLY-PATTERN-001 name: "Detectarea secvenței de reaprovizionare a vehiculelor" description: "Detectează un vehicul care vizitează un nod logistic urmat de un punct de alimentare cu combustibil în fereastră" confidence_weight: 0.72 spatial_resolution: H3_LEVEL_8 temporal_window_minutes: 90 events: - alias: VEH entity_type: EQUIPMENT attribute_predicates: - "attributes.platform_class IN [APC, IFV, TRUCK, LOGISTICS_VEHICLE]" - alias: NODE_VISIT entity_type: EVENT attribute_predicates: - "attributes.event_class == LOCATION_VISIT" - "attributes.location_type IN [LOGISTICS_NODE, DEPOT, FUEL_POINT]" linked_entity: VEH temporal_order: AFTER VEH.last_seen output: entity_type: SITUATION situation_class: RESUPPLY_ACTIVITY contributing_entity_refs: [VEH.entity_id, NODE_VISIT.entity_id]

Fiecare corelare declanșată produce o entitate Situation — un nou obiect de informații la nivelul JDL 2 care face referire la UUID-urile entităților contribuitoare, poartă ID-ul regulii și greutatea de încredere a regulii și este publicată în fluxul de entități îmbogățite alături de actualizările standard de entități.

Evaluarea încrederii și proveniența — matricea fiabilității sursei × credibilitatea informației (sistemul Admiralty NATO), propagarea încrederii între entitățile fuzionate

Fiecare entitate din imaginea fuzionată poartă un scor de încredere, dar încrederea într-un sistem de fuziune multisursă nu este un singur număr — este un compus care trebuie descompus pe mai multe dimensiuni pentru a fi analitic util. Un scor de 0,73 produs de trei înregistrări SIGINT care se coroborează înseamnă cu totul altceva decât un scor de 0,73 provenit dintr-un singur raport HUMINT neverificat și din nimic altceva. Arhitectura trebuie să păstreze descompunerea, nu doar agregatul.

Modelul de încredere suprapune trei intrări. Prima, greutatea fiabilității sursei, derivată din gradul de fiabilitate al sursei Admiralty NATO: A=1.0, B=0.8, C=0.6, D=0.4, E=0.2, F=0.1. Această greutate scalează contribuția fiecărei observații-sursă la calculul de fuziune. A doua, greutatea credibilității informației, derivată din gradul de credibilitate Admiralty: 1=1.0, 2=0.8, 3=0.6, 4=0.4, 5=0.2, 6=0.1. Această greutate se aplică per observație, independent de fiabilitatea sursei, pentru că o sursă fiabilă poate raporta informații incerte. A treia, scorul de acord între surse — fracția de surse care se coroborează independent și concordă asupra valorii atributului cheie, ponderată cu fiabilitatea sursei lor. O valoare de poziție coroborată de trei surse de grad A cu grade de informație B2 este evaluată foarte diferit față de una coroborată de două surse de grad E cu grade D4.

Încrederea compusă pentru un atribut este:

# Formula de încredere per atribut fuzionat # Pentru fiecare observație contribuitoare i: # w_i = source_reliability_weight(admiralty_grade_A_to_F) # × info_credibility_weight(admiralty_grade_1_to_6) # # Scor de acord ponderat: # agreement = sum(w_i for i in corroborating sources) # / sum(w_i for i in all contributing sources) # # Încredere de fuziune: # confidence = agreement × source_coverage_penalty # # unde source_coverage_penalty penalizează coroborarea pe un singur tip INT: # 1.0 dacă ≥ 2 tipuri INT distincte coroborează # 0.75 dacă exact 1 tip INT cu ≥ 2 surse # 0.5 dacă exact 1 sursă în total

Propagarea încrederii între entitățile derivate urmează o regulă de diluare: o entitate Situation derivată de motorul de corelare din două înregistrări aurii de entități contribuitoare nu poate avea o încredere mai mare decât entitatea contribuitoare cu încrederea cea mai mică. Încrederea poate crește doar când se adaugă observații independente suplimentare care se coroborează la entitățile contribuitoare. Aceasta împiedică motorul de corelare să umfle artificial încrederea prin legarea unor entități de slabă calitate.

Legăturile de proveniență sunt stocate ca un lanț: fiecare înregistrare aurie face referire la UUID-urile observațiilor care au contribuit la ea; fiecare observație face referire la ID-ul sursei, la sistemul de culegere și la gradele Admiralty. Lanțul este imuabil — nu este niciodată actualizat la loc. Când o sursă contribuitoare este evaluată ulterior ca fiind nesigură sau înșelătoare, lanțul oferă setul complet de entități care trebuie reevaluate cu contribuțiile acelei surse excluse. Retragerea sursei este o operație de prim rang, nu o procedură de urgență.

Publicarea imaginii informative — publicarea entităților îmbogățite către sistemele C2 prin CoT/NIEM, ținte de latență pentru informațiile sensibile la timp

Fluxul de entități îmbogățite este reprezentarea internă. Publicarea convertește acea reprezentare în formatele de fir pe care sistemele C2 și consumatorii din aval le înțeleg cu adevărat. Pentru majoritatea desfășurărilor din apărare, aceasta înseamnă Cursor on Target (CoT) pentru datele de pistă și formate de mesaje bazate pe NIEM pentru rapoartele de informații structurate.

Publicarea CoT mapifică fiecare actualizare a unei entități îmbogățite la un eveniment CoT. Maparea trebuie să gestioneze trei tipuri de actualizări: actualizări de poziție (coordonate noi cu incertitudine actualizată), actualizări de atribute (schimbare de încredere, schimbare de stare a activității, schimbare a evaluării de apartenență) și evenimente de ciclu de viață al entității (crearea entității, retragerea și evenimentele de divizare/îmbinare). Actualizările de poziție sunt directe — se traduc într-un eveniment de punct CoT cu poziția estimată a entității și încrederea poziției codificată în câmpul de eroare CoT. Actualizările de atribute se traduc în observații CoT sau actualizări ale elementului de detaliu pe entitatea existentă. Evenimentele de ciclu de viață — în special îmbinarea și divizarea — necesită o gestionare specială: un eveniment de îmbinare retrage pista CoT a entității cu încredere mai mică și actualizează detaliul CoT al entității supraviețuitoare cu informații de proveniență; un eveniment de divizare creează o pistă CoT nouă pentru entitatea recent separată.

Câmpul CoT stale_time este mecanismul natural pentru managementul TTL la receptorul C2. Fiecare eveniment CoT publicat setează stale_time la entity_publication_time + entity_TTL. Sistemul C2 receptor (ATAK, CURSOR sau similar) elimină entitatea din afișajul său când stale_time trece fără o reîmprospătare. Sistemul de fuziune trebuie să se asigure că entitățile cu observații active primesc evenimente de reîmprospătare CoT la un interval mai scurt decât TTL-ul lor — în mod tipic la 50% din TTL — pentru a împiedica dispariția entităților valide din imagine în timpul funcționării normale.

Țintele de latență determină modul în care trebuie implementat stratul de publicare. Pentru fluxurile de țintire sensibile la timp, latența de la capăt la capăt de la evenimentul senzorului la afișajul C2 trebuie să fie sub 30 de secunde. Realizarea acestui lucru necesită: lucrători de publicare asincroni, neblocați; serializare CoT paralelizată pe partiții de entități; cozi de ieșire prioritizate care dau întâietate pistelor mobile cu încredere ridicată față de actualizările de entități statice; și livrare directă TCP multicast către destinatarii C2, în loc de interogări REST API. Pentru conștientizarea situațională generală la nivel operațional, o latență de 60–120 de secunde este în mod tipic acceptabilă, permițând tipare de publicare sincronă în loturi, mai simple.

Publicarea NIEM deservește consumatorii de rapoarte de informații — sisteme care au nevoie de evaluări de informații structurate, lizibile de mașină, nu de date de pistă. O entitate Situation produsă de motorul de corelare este publicată ca mesaj de informații NIEM, cu UUID-urile entităților contribuitoare ca referințe, clasa situației ca subiect și datele de încredere și proveniență în blocul de metadate al mesajului NIEM. Consumatorii NIEM includ platforme de schimb de informații multi-domeniu, porți de interoperabilitate către sistemele națiunilor partenere și sisteme de arhivare care necesită proveniență structurată pentru conformitatea auditului.

Gestionarea incertitudinii temporale și a informațiilor învechite — managementul TTL pentru entitățile de informații, curbe de degradare pentru încrederea în poziție/activitate, declanșatoare de reevaluare

Informațiile sunt perisabile. Un raport de poziție pentru o pistă de vehicul care era corect acum 20 de minute este mai puțin corect acum — vehiculul s-ar fi putut mișca. O evaluare a activității bazată pe o singură interceptare SIGINT de acum 4 ore nu mai poate reflecta comportamentul curent. Un sistem de fuziune care nu modelează această degradare și nu o propagă către imaginea publicată îi va determina pe analiști să ia decizii pe baza unor informații învechite, cu scoruri de încredere ridicate câștigate de observații mai vechi.

Managementul TTL începe cu atribuirea TTL-ului la crearea entității. Valorile TTL sunt specifice tipului de entitate și nivelului de încredere:

  • Pistă de vehicul în mișcare cu încredere ridicată (confidence ≥ 0.80, mobility class = WHEELED/TRACKED): TTL 8–15 minute
  • Pistă în mișcare cu încredere medie (confidence 0.50–0.79): TTL 4–8 minute
  • Pistă tentativă cu încredere redusă (confidence < 0.50): TTL 2–4 minute
  • Facilitate fixă cu încredere ridicată (confidence ≥ 0.80, mobility class = STATIC): TTL 24–72 ore
  • Entitate de personal (bazată pe activitate, nu pe poziție): TTL 30–120 minute, în funcție de tipul ultimei activități
  • Entitate Situation (corelare derivată): TTL egal cu cel mai scurt TTL al oricărei entități contribuitoare, plafonat la 60 de minute

Curbele de degradare a încrederii modelează modul în care încrederea în poziție și în activitate se degradează între observațiile de confirmare. În locul unei stări binare activ/învechit, curba de degradare oferă o funcție continuă de încredere în timp de la ultima observație:

# Degradarea încrederii în poziție — model exponențial # c(t) = c_0 × exp(-λ × t) # unde: # c_0 = încrederea la momentul ultimei observații de confirmare # t = timpul scurs de la ultima observație (secunde) # λ = constanta de degradare, specifică tipului de entitate # # Constante de degradare (ilustrative): # TRACKED_VEHICLE: λ = 0.003 (perioadă de înjumătățire ≈ 3.8 min) # WHEELED_VEHICLE: λ = 0.004 (perioadă de înjumătățire ≈ 2.9 min) # SLOW_MOVER: λ = 0.001 (perioadă de înjumătățire ≈ 11.5 min) # STATIC_SITE: λ = 0.00001 (perioadă de înjumătățire ≈ 19 ore) # MARITIME_SURFACE: λ = 0.002 (perioadă de înjumătățire ≈ 5.8 min) # # Entitatea trece în STALE când c(t) < staleness_threshold # (în mod tipic 0.15 pentru piste mobile, 0.05 pentru situri statice)

Declanșatoarele de reevaluare se activează când sosește o observație nouă care este consecventă spațial și temporal cu o entitate învechită. În loc să creeze o entitate nouă pentru observația nouă, declanșatorul o direcționează prin conducta de rezoluție a entităților, având entitatea învechită drept candidat. Dacă încrederea de potrivire depășește pragul de îmbinare, observația nouă reîmprospătează entitatea învechită: ceasul TTL se resetează, încrederea este recalculată din observația nouă (posibil în sus față de valoarea degradată, dacă observația nouă are o încredere puternică), iar entitatea trece înapoi din starea STALE în starea ACTIVE. Reîmprospătarea este înregistrată ca eveniment de actualizare în istoricul de audit al entității.

Modelul de degradare trebuie comunicat și consumatorilor C2, nu doar aplicat intern. Publicarea unei poziții cu încredere ridicată în CoT fără a semnala că poziția are 18 minute vechime determină afișajul C2 să arate o pictogramă de pistă ascuțită, încrezătoare, pe care analistul o poate interpreta ca pe o observație în timp real. Două mecanisme abordează acest lucru: câmpul CoT stale_time (discutat deja) asigură că entitatea dispare din afișaj când este definitiv învechită; iar un câmp de vechime de la ultima observație, publicat în elementul de detaliu CoT, îi dă analistului vizibilitate în timp real asupra vechimii observației subiacente, chiar și pentru entitățile care nu și-au atins încă timpul de învechire. Unele sisteme C2 folosesc acest câmp pentru a modula reprezentarea vizuală a încrederii — schimbând opacitatea sau dimensiunea pictogramei de pistă ca funcție de vechimea observației.

Împreună, cele șapte componente arhitecturale descrise în acest articol — ingestia eterogenă a fluxurilor, normalizarea cu scheme impuse, rezoluția entităților prin blocare plus ML, motorul de corelare multi-plan, evaluarea încrederii pe straturi, publicarea CoT/NIEM și managementul degradării TTL — constituie o platformă completă de fuziune de informații multisursă în timp real. Niciuna dintre aceste componente nu este independentă inovatoare. Ceea ce face arhitectura de nivel producție este proiectarea explicită a interfețelor dintre ele: schema canonică de observații pe care normalizarea o produce și rezoluția entităților o consumă; formatul grafului de entități pe care rezoluția entităților îl produce și motorul de corelare îl consumă; fluxul de entități îmbogățite pe care atât rezoluția entităților, cât și motorul de corelare îl scriu și stratul de publicare îl citește. Un sistem în care aceste interfețe sunt implicite sau nedocumentate — în care fiecare componentă presupune un anumit comportament de la cea din amonte — este fragil exact în punctele în care datele de informații sunt cele mai variabile ca caracter.