Construirea unui pipeline de fuziune pentru apărare, Partea 2: Corelarea urmelor și gestionarea ciclului de viață

Partea 1 a lăsat pipeline-ul cu un flux de observații canonice de urmărire care curgeau pe magistrala de mesaje. Fiecare observație este un atom izolat — "sursa X raportează obiectul la poziția Y cu viteza Z la momentul T". Sarcina motorului de fuziune este să decidă care observații se referă la același obiect fizic, să le acumuleze în urme stabile cu o încredere crescătoare a identității, să gestioneze ciclul de viață pe măsură ce observațiile se opresc sau altele noi sosesc și să expună o vizualizare interogabilă a lumii la COP și consumatorilor din aval. Partea 2 se referă la construirea acelui motor.

Referința conceptuală este Fuziunea datelor militare explicată pentru prezentarea generală a disciplinei, Modelul de fuziune a datelor JDL pentru maparea nivelurilor și pilonul Ghidul complet pentru fuziunea datelor de apărare pentru cadrul arhitectural mai larg.

Pasul 1: Filtrul de corelație în două etape

Decizia de bază a motorului de fuziune — dacă o observație care sosește este o actualizare a unei urme existente sau nașterea uneia noi — nu trebuie să folosească un singur algoritm. Modelul care scalează în producție folosește două etape: un filtru bazat pe reguli ieftin care gestionează cazurile ușoare și un motor de asociere probabilistă invocat numai când stratul de reguli este ambiguu.

Etapa bazată pe reguli gestionează 90% din observațiile care sunt neambigue. Pentru fiecare observație care sosește, calculează setul de urme existente candidate în raza cinematică — o poartă poziție-timp. Prioritățile de identitate filtrează în continuare: o observație etichetată "navă" nu poate corespunde unei urme "aeronavă". Regulile de compatibilitate a surselor filtrează și ele: o observație de la un radar terestru nu poate corespunde unei urme aeriene a unei platforme subacvatice. Acolo unde poarta produce exact un candidat care trece regulile de identitate și sursă, observația actualizează direct acel candidat. Acolo unde poarta nu produce candidați, observația inițiază o nouă urmă tentativă. Ieftin, rapid, explicabil.

Etapa probabilistă este invocată când stratul de reguli returnează mai mulți candidați sau când densitatea urmelor este suficient de mare încât filtrarea cu încredere este imposibilă. Asocierea probabilistă a datelor comune (JPDA) calculează probabilitatea că o observație aparține fiecărei urme candidate și actualizează fiecare ponderată după probabilitate. Urmărirea hipotezelor multiple (MHT) menține mai multe ipoteze de urmă pe parcursul observațiilor, amânând deciziile de asociere până când se acumulează suficiente dovezi. Ambele sunt mai grele computațional și mai greu de reglat; ambele sunt corecte numai pentru cazurile în care stratul de reguli a greșit să se angajeze.

Un capcană specifică care merită evidențiată: MHT generează un număr exponențial de ipoteze fără tăiere. Politica de tăiere — câte ipoteze să rețineți, când să fuzionați, când să ștergeți — este mai importantă decât algoritmul de bază. Implicit la tăiere agresivă; reglați în exterior numai când dovezile operaționale o cer.

Pasul 2: Reglarea stratului de reguli

Stratul de reguli este locul unde aterizează cea mai mare parte a efortului de inginerie de fuziune. Algoritmul este simplu; reglarea este o artă.

Parametrii porții care contează:

• Dimensiunea porții cinematice — cât de departe poate fi o observație de poziția prezisă a urmei pentru a corespunde în continuare. Prea mică ratează actualizări reale după zgomotul senzorului; prea mare produce corelații false în scene dense.
• Poarta de identitate — care atribute de identitate trebuie să corespundă (întotdeauna: taxonomia tipului; uneori: subtipul, numărul de borduri, indicativul).
• Regulile setului de surse — care surse pot actualiza ce tipuri de urme. Specifice domeniului (un radar maritim nu ar trebui să actualizeze o urmă subacvatică) și specifice platformei (un contact SIGINT cu rulment-only poate să nu se asocieze la o urmă cinematică fără potrivirea rulmentului).
• Toleranța timpului-de-la-ultima-actualizare — observațiile față de urmele care au fost tăcute prea mult timp produc o nouă urmă tentativă în loc să se re-asocieze cu cea veche.

Valorile implicite provin din profilurile de acuratețe și latență ale catalogului de surse. Reglarea operațională provine din reluarea față de datele capturate, cu metrici privind rata de corelație falsă și rata de asociere ratată. Motoarele de fuziune de calitate achizițională au aceste butoane de reglare expuse pentru echipa operațională pentru a le ajusta per implementare; programele bespoke adesea codifică valorile și le regretă când contextul de implementare se schimbă.

Pasul 3: Când și cum să invocați asocierea probabilistă

Asocierea probabilistă este instrumentul potrivit când filtrarea bazată pe reguli nu poate produce o singură potrivire confidențiată. Semnalul că probabilistă este necesară: poarta returnează mai mult de un candidat la o rată de peste (să zicem) 5% în scena operațională.

Modelul de invocare pragmatic:

JPDA pentru densitate moderată. Când poarta returnează 2-4 candidați per observație ambiguă, JPDA calculează probabilitățile de asociere folosind priorități cinematice (distanța Mahalanobis față de poziția prezisă) și priorități de identitate. Actualizările urmelor sunt ponderate de probabilitate; nicio urmă nu primește o actualizare „definitivă", dar candidații cei mai probabili acumulează dovezile mai repede.

MHT pentru cazurile cele mai dificile. Când poarta returnează mulți candidați și ambiguitatea de asociere persistă pe parcursul observațiilor, MHT amână decizia. Menține ipoteze (interpretări alternative ale cărei observații aparțin cărei urme) și taie după probabilitate. După mai multe observații, ipoteza dominantă apare și celelalte sunt șterse.

Ieșire combinată. Ambii algoritmi produc actualizări care curg înapoi în același stoc de urme ca actualizările bazate pe reguli. Din perspectiva consumatorilor din aval, toate actualizările arată identic; diferența este în metadatele de încredere și proveniență atașate.

Realitatea implementării: biblioteci open-source bine testate există pentru ambele JPDA și MHT (Stone Soup, FilterPy și instrumente adiacente). Majoritatea motoarelor de fuziune operaționale înfășoară o bibliotecă testată în loc să implementeze de la zero. Efortul de inginerie este în integrare, reglare și întărire operațională — nu în algoritm.

Pasul 4: Mașina de stare a ciclului de viață al urmei

Urmele au cicluri de viață. Mașina de stare care le guvernează este una dintre deciziile cel mai important operațional ale platformei: operatorii tolerează urmele lipsă dar nu tolerează urmele vechi afișate cu încredere. Ciclul de viață este granița dintre afișarea de încredere și cea nedemă de încredere.

Mașina de stare pentru exemplul curent:

• Tentativă. Prima observație; în așteptarea confirmării. Nu este afișată în COP-ul operațional dacă un operator nu solicită explicit vizibilitate la încredere scăzută. Se degradează la șterse dacă nu urmează nicio observație în cadrul unei ferestre configurabile.
• Confirmată. Două sau mai multe observații corelate în fereastra de consistență cinematică. Promovată din tentativă. Starea implicită pentru urmele afișate.
• Matură. Confirmată și persistentă pentru cel puțin N minute cu actualizări consistente. Folosită de analiticele din aval care au nevoie de identitate stabilă pentru analiza tiparelor de viață sau comportamentale.
• În scădere. Nicio actualizare în intervalul de revizitare așteptat pentru această clasă de sursă. Afișajul marcat ca vechi (simbol mai slab, indicator de vârstă). Configurabil per clasă de sursă — o urmă maritimă de 30 de secunde este în regulă; o urmă aeriană de 30 de secunde este în scădere.
• Pierdută. Nicio actualizare pentru o perioadă extinsă. Eliminată din afișajul activ dar reținută în stocul de urme pentru audit și analiză istorică.

Tranzițiile sunt bazate pe timp și pe actualizări, ambele alimentând un singur arbore de decizie. Fiecare tranziție este înregistrată cu evenimentul declanșator (actualizare prin observație, expirarea timeout-ului, suprascriere de operator). Jurnalul tranzițiilor alimentează traseul de audit bazat pe event sourcing acoperit în Event Sourcing pentru trasee de audit de apărare.

Un detaliu practic: serviciul de ciclu de viață este un proces separat față de motorul de corelație. Se abonează la evenimentele de actualizare a urmelor din corelație, calculează tranzițiile de ciclu de viață și le publică ca un flux separat pe magistrală. Decuplarea permite politicii de ciclu de viață să evolueze fără a atinge motorul de corelație.

Pasul 5: Stocul de urme ca model de citire bazat pe event sourcing

Fuziunea produce un flux de actualizări ale urmelor și tranziții ale ciclului de viață. Stocul de urme este vizualizarea materializată: starea curentă a fiecărei urme active, interogabilă de COP, de analiticele și de API-urile externe. Decizia arhitecturală care merită luată devreme este că stocul de urme este un model de citire, nu o sursă autoritară. Sursa autoritară este jurnalul de evenimente de pe magistrala de mesaje. Stocul de urme este reconstruit din jurnal la cerere.

Beneficiile acestui model:

Ștergere și reconstruire. Stocul poate fi curățat și reconstruit din jurnal fără pierdere de date. Migrările de schemă, optimizarea performanței și recuperarea datelor corupte devin de rutină în loc să fie riscante.

Modele multiple de citire. Un model de citire optimizat pentru COP (indexat geospațial, cache urmă-fierbinte, citiri cu latență scăzută) coexistă cu un model optimizat pentru analiticele (denormalizat, prietenos pentru batch) și un model pentru API extern (filtrat, clasificat per consumator). Toate sunt proiecții ale aceluiași flux de evenimente de bază.

Interogări în timp. "Ce credea platforma la 14:32?" devine trivial: redați jurnalul până la 14:32 față de o proiecție proaspătă. Revizuirea post-acțiune, instruirea și auditurile de acreditare beneficiază toate.

Implementarea: PostgreSQL cu extensia PostGIS pentru interogări geospațiale (implicit pentru exemplul curent). Un strat Redis în față pentru citiri urmă-fierbinte sub-milisecunde pe calea critică COP. Stocul relațional gestionează interogările cu coadă mai lungă și garanțiile de persistență. Vizualizarea de inginerie detaliată, inclusiv strategiile de indexare care scalează la miliarde de puncte, se află în PostGIS pentru date geospațiale de apărare.

Pasul 6: Rezistați baza de date graf (deocamdată)

O tentație previzibilă în proiectarea fuziunii este adăugarea unei baze de date graf "pentru relații". Detectarea convoaielor, recunoașterea formațiunilor, rețelele de contact — toate acestea sună ca formă de graf. Tentația este să le modelați în Neo4j sau echivalent și să obțineți interogări de relații "naturale".

Contra-argumentul pragmatic: relațiile dintre urme sunt fuziunea JDL Nivelul 2, o preocupare separată față de menținerea urmelor Nivelul 1. Construiți mai întâi Nivelul 1, rulați-l în operațiuni timp de un an și abia atunci revizitați Nivelul 2 cu dovezile operaționale la îndemână. Relațiile de Nivel 2 deseori se dovedesc că au nevoie de o formă diferită de cea intuiției bazei de date graf — temporal-relaționale mai degrabă decât pur topologice, conștiente de clasificare mai degrabă decât deschise, exprimate la abstractizare mai înaltă decât muchii per urmă.

Platformele care reușesc încep cu PostGIS + Redis pentru modelul de citire, dovedesc fuziunea la Nivelul 1 și adaugă capabilități de Nivel 2 ca servicii separate care consumă același flux de evenimente. Platformele care eșuează adaugă baza de date graf în prima săptămână și petrec doi ani depanând abstracția nepotrivită.

Pasul 7: Testarea motorului de fuziune față de realitate

Un motor de fuziune testat numai cu sarcină de jucărie trece testele de integrare și eșuează în operațiuni. Disciplinele care prind problemele înainte de implementare:

Harnamente de test cu reluare. Urme de senzori capturate din operațiuni reale, redate la rata completă și la rata accelerată față de motorul de fuziune. Urmele sunt suita de teste de regresie: orice schimbare de algoritm sau schemă trebuie să producă rezultate echivalente sau mai bune, nu numai pe sarcina sintetică.

Metrici de calitate a urmei în CI. Rata de corelație falsă, rata de asociere ratată, rata de fragmentare a urmelor, temporizarea tranzițiilor ciclului de viață. Fiecare metrică urmărită în timp; regresiile blochează lansarea. Metricile sunt evaluate față de urmele de reluare, nu față de sarcina sintetică.

Testarea scenariilor adversariale. Mesaje AIS falsificate cu cinematică implausibilă. Ploturi radar care violează fizica. Căderi ale surselor în momente critice. Motorul de fuziune trebuie să se degradeze grațios sub intrare defectă — să nu se prăbușească, să nu producă urme cu încredere dar greșite. Modelul de inginerie mai larg pentru robustețea adversarială în apărare se află în Testarea sistemelor C2 de misiune critică.

Testarea sarcinii și vârfurilor. Latența de fuziune la percentila 95 sub 500 ms la 10.000 observații/secundă; la percentila 99 sub 1,5 s. Susținut pe durata unei rotații operaționale, nu numai pentru benchmark-ul de marketing. Platforma trebuie să aibă marjă CPU cu cifre unice pentru gestionarea vârfurilor.

Ce urmează

Partea 2 a construit motorul. Corelația în două etape gestionează cazurile ușoare și dificile. Mașina de stare a ciclului de viață evidențiază prospețimea pentru operatori. Stocul de urme ca model de citire bazat pe event sourcing suportă interogările fără a deveni o sursă autoritară. Disciplinele de testare validează stratul față de realitate.

Partea 3 aprofundează cazul multi-INT — combinarea SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT în același flux de fuziune păstrând diferențele lor semantice — și abordează propagarea clasificării și a difuzabilității pe care fuziunea de apărare o necesită în mod unic.