Partea 1 a stabilit domeniul de aplicare, a fixat arhitectura pe patru niveluri și a proiectat schema canonică de piste. Partea 2 construiește motorul care transformă rapoartele senzorilor în piste de încredere: adaptoare care aduc sursele la bord, algoritmi de corelare care determină care rapoarte se referă la același obiect fizic, managementul ciclului de viață care informează imaginea operațională comună când o pistă a devenit depășită, și depozitul de piste care ancorezează totul. La finalul Părții 2, platforma produce piste utilizabile operațional; nu are doar unde să le afișeze.

Referința conceptuală pentru tot ce cuprinde Partea 2 este Ghidul Complet pentru Fuziunea Datelor de Apărare, care oferă o perspectivă de ansamblu asupra disciplinei. Aici luăm decizii specifice pentru platforma exemplu în derulare.

Pasul 1: Modelul Adaptor, Aplicat Riguros

Fiecare senzor produce date în propriul format. Radarele vorbesc ASTERIX; UAV-urile vorbesc STANAG 4586; receptoarele AIS emit NMEA 0183; clienții ATAK vorbesc CoT; fluxurile civile ADS-B emit un protocol binar diferit; observațiile raportate manual ajung printr-un formular web. Rolul stratului de adaptare este de a traduce toate acestea în schema canonică de piste definită în Partea 1.

Regula este strictă și merită memorată: niciun concept specific senzorului nu se scurge dincolo de adaptor. Dacă codul motorului dvs. de fuziune referențiază categorii ASTERIX, aveți o arhitectură cu scurgeri. Dacă depozitul dvs. de piste are o coloană pentru tipurile de mesaje AIS, aveți o arhitectură cu scurgeri. Adaptoarele sunt convertoare unidirecționale de date cu izolare strictă; ele expun doar piste canonice în amonte.

Structura pragmatică a adaptorului pentru fiecare sursă:

  • Transport — conectorul la sursă (socket UDP, abonament MQTT, webhook HTTP, monitor de fișiere). Rezistent la eșecul din partea sursei: reconectare, perioadă de așteptare, contabilizarea mesajelor pierdute.
  • Parser — traduce formatul de comunicare într-o structură puternic tipizată în proces. Validează conform specificației formatului. Respinge datele de intrare malformate explicit, nu în tăcere.
  • Normalizator — mapează câmpurile specifice sursei pe câmpurile canonice. Conversia sistemului de coordonate (de obicei la WGS84). Normalizarea marcajelor de timp (UTC, cu disciplina celor trei marcaje de timp din Partea 1).
  • Emițător — publică actualizarea canonică a pistei pe magistrala de mesaje. Etichetează cu identificatorul sursei, clasificarea sursei, permisivitatea de distribuire.

Fiecare adaptor este un serviciu sau proces separat. Ele partajează o bibliotecă client generată prin cod pentru schema canonică, dar nu și alte căi de cod. Adăugarea unui nou tip de senzor înseamnă scrierea unui nou adaptor, fără a atinge nicio altă componentă. Modelele detaliate de integrare pentru sursele comune se găsesc în Integrarea AIS și ADS-B în Imaginea Militară și partea CoT în Cursor on Target (CoT): Standardul XML din Spatele Aplicațiilor de Conștientizare Tactică.

Pasul 2: Conectarea Magistralei de Mesaje

Adaptoarele publică într-un jurnal durabil, ordonat, partiționat. Serviciile de fuziune consumă din acesta. La fel și serviciul de audit, serviciul de redare istorică și orice analize în aval. Magistrala de mesaje este coloana vertebrală a platformei.

Pentru exemplul în derulare utilizăm Kafka cu topicuri per tip de sursă și topicuri suplimentare pentru ieșirile fuziunii. Adaptoarele publică la raw.source-type; motorul de fuziune consumă acestea și publică la tracks.updates și tracks.lifecycle. Auditul se abonează la toate. Modelul de magistrală, inclusiv compromisurile privind debitul și durabilitatea, se găsesc în Cozi de Mesaje pentru Rețele de Date de Apărare.

Decizia arhitecturală care merită evidențiată: nu apelați HTTP între componentele de fuziune. Cuplarea sincronă cerere-răspuns fragilizează un pipeline de fuziune. O supraîncărcare a senzorilor care blochează un consumator nu trebuie să blocheze fiecare producător din amonte. Magistrala cu contrapresiune este soluția structurală; HTTP între componentele de fuziune este o sursă recurentă de întreruperi.

Pasul 3: Corelarea Pistă-la-Pistă

Nucleul motorului de fuziune este algoritmul care determină dacă un raport primit reprezintă o actualizare a unei piste existente sau nașterea uneia noi. Dacă greșiți, operatorul vede o suprapopulare de piste (o mie de simboluri acolo unde ar trebui să fie o sută) sau piste fantomă (duplicate care ar fi trebuit să se unească). Dacă reușiți, imaginea operațională comună devine de încredere.

Modelul pragmatic utilizează un filtru în două etape.

Etapa 1: filtrare bazată pe reguli. Pentru fiecare raport primit, calculați setul de piste candidate existente în raza cinematică — o poartă poziție-timp care afirmă că „o pistă deplasându-se cu cel mult V m/s ar fi putut călători de la ultima poziție cunoscută la poziția acestui raport în acest interval de timp". Prioritățile de identitate filtrează în continuare: un raport etichetat „navă" nu poate corespunde unei piste „aeronavă". Filtrele de compatibilitate ale sursei: un raport de la un radar terestru nu poate corespunde unui contact aerian al unei platforme subacvatice. Etapa bazată pe reguli gestionează 90% din intrări eficient și fără ambiguitate.

Etapa 2: asociere probabilistică. Pentru cazurile contestate — candidați multipli în interiorul porții, identitate ambiguă, scenarii dense cu traiectorii care se intersectează — invocați asocierea probabilistică a datelor. Asocierea Probabilistică Comună a Datelor (JPDA) pentru densitate moderată; Urmărirea cu Ipoteze Multiple (MHT) pentru cazurile cele mai dificile. Ambele calculează probabilitatea că un raport primit aparține fiecărei piste candidate și actualizează pistele ponderate cu această probabilitate.

Modelul teoretic complet cu implicațiile inginerești se găsește în Modelul JDL de Fuziune a Datelor: Referință Practică pentru Inginerie. Nuanțele inginerești privind momentul aplicării fiecărei tehnici și calibrarea necesară se găsesc în Fuziunea Datelor Militare Explicată.

Un risc 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ă se păstreze, când să se îmbine, când să se elimine — este mai importantă decât algoritmul de bază. Implicit, aplicați tăierea agresivă; extindeți doar când situația de amenințare o impune.

Pasul 4: Managementul Ciclului de Viață al Pistei

O pistă nu este un înregistrare statică. Se naște, este confirmată, îmbătrânește, se estompează și moare. Motorul de fuziune gestionează ciclul de viață în mod explicit; imaginea operațională comună afișează starea ciclului de viață, astfel încât operatorii să știe în care piste să aibă încredere.

Mașina de stare pentru exemplul în derulare:

  • Tentativă — prima observație; nu este afișată în imaginea operațională comună operațională dacă nu se solicită explicit. Trece la eliminată dacă nu există o urmărire în fereastra configurabilă.
  • Confirmată — două sau mai multe rapoarte corelate, consecvența cinematică se menține. Promovată din tentativă. Aceasta este starea implicită pentru pistele afișate.
  • Matură — confirmată și persistentă pentru cel puțin N minute cu actualizări consistente. Utilizată de analizele din aval care necesită identitate stabilă.
  • În estompare — nicio actualizare în intervalul de revizie așteptat. Afișarea marcată ca depășită. Configurabilă per clasă de sursă (o pistă maritimă cu 30 de secunde întârziere este acceptabilă; o pistă aeriană cu 30 de secunde întârziere este în estompare).
  • Pierdută — nicio actualizare pe o perioadă extinsă. Eliminată din afișarea activă, dar păstrată în depozitul de piste pentru audit și analiză istorică.

Fiecare tranziție de stare este înregistrată. Serviciul de audit consumă fluxul de tranziții și scrie înregistrări imuabile — subiectul Aprovizionarea prin Evenimente pentru Trasee de Audit de Apărare. Tranzițiile sunt expuse și pe magistrală, astfel încât imaginea operațională comună poate reda starea ciclului de viață fără interogare continuă.

Concluzie cheie: Operatorii tolerează o pistă lipsă. Nu tolerează o pistă depășită afișată cu încredere. Managementul ciclului de viață este stratul care face diferența. Construiți-l înainte ca algoritmul de fuziune să fie complet calibrat — este ieftin și se răsplătește de fiecare dată când un link de senzor se întrerupe.

Pasul 5: Depozitul Autorizat de Piste

Fuziunea produce un flux de actualizări ale pistelor și tranziții ale ciclului de viață. Depozitul de piste este vizualizarea materializată: starea curentă a fiecărei piste active, interogabilă de imaginea operațională comună și de analize. Decizia arhitecturală care merită luată devreme: depozitul de piste este un model de citire, nu o sursă autoritară. Sursa autoritară este jurnalul de evenimente pe magistrala de mesaje. Depozitul de piste este reconstruit din jurnal la cerere.

Acest model — stare cu aprovizionare prin evenimente cu proiecții de model de citire — are trei beneficii operaționale. Depozitul poate fi șters și reconstruit fără pierdere de date. Modele de citire multiple cu forme diferite pot coexista (unul pentru imaginea operațională comună, unul pentru analize, unul pentru un API extern). Interogările călătoriei în timp devin banale: redați jurnalul până la un moment ales pentru a reconstrui ce credea platforma atunci.

Depozitul în sine este PostgreSQL cu PostGIS pentru indexare geospațială. Pistele active trăiesc în memorie sau un strat Redis în fața PostgreSQL pentru lecturi sub-milisecundă; depozitul relațional gestionează interogările cu coadă mai lungă și garanțiile de persistență. Vizualizarea inginerească detaliată se găsește în PostGIS pentru Date Geospațiale de Apărare.

Rezistați impulsului de a adăuga o bază de date graf „pentru relații". Relațiile dintre piste — detectarea convoaielor, recunoașterea formațiilor, rețelele de contacte — sunt fuziunea de nivel 2 JDL, o preocupare separată de întreținerea pistelor de nivel 1. Construiți mai întâi Nivelul 1, rulați-l în operațiuni timp de un an, apoi reveniți la Nivelul 2 cu dovezile operaționale la îndemână.

Pasul 6: Testarea cu Date de Intrare Realiste

Un motor de fuziune testat doar cu sarcini reduse trece testele de integrare și eșuează în operațiuni. Disciplinele care identifică problemele înainte de implementare:

Platforme de test cu redare. Capturați urmele reale ale senzorilor în faza de dezvoltare și redați-le la viteză maximă față de motorul de fuziune. Urmele servesc drept suită de teste de regresie: un nou algoritm sau o modificare de schemă trebuie să producă rezultate echivalente sau mai bune pe urmele existente, nu doar pe sarcina sintetică.

Date de intrare adversariale. Mesaje AIS falsificate cu cinematică implausibilă. XML CoT malformat. Puncte radar care violează fizica (piste terestre la viteza Mach 5). Motorul de fuziune trebuie să le respingă sau să le semnaleze, să nu intre în panică, să nu se blocheze, să nu producă piste corecte-aparent-dar-greșite. Disciplina este aceeași cu cea mai amplă disciplină de testare din Testarea Sistemelor C2 de Misiune Critică.

Detecția tiparelor de comportament. Odată ce fuziunea de bază funcționează, adăugați analiza PoL — consultați Analiza Tiparelor de Comportament în Informații Militare. Serviciul PoL consumă aceleași topicuri de magistrală; produce adnotări de stare a pistelor îmbogățite, mai degrabă decât să concureze cu motorul de fuziune.

Pasul 7: Obiective de Performanță și Rezervă

Latența fuziunii este operațional semnificativă. Obiective pentru platforma exemplu în derulare: latența de fuziune end-to-end la percentila 95 sub 500 ms (ingestia rapoartelor senzorilor până la mesajul de actualizare a pistei pe magistrală); percentila 99 sub 1,5 s; debit susținut la 10.000 de rapoarte pe secundă cu o rezervă CPU de câteva procente unitare.

Acestea sunt obiective la nivel de brigadă tactică. Platformele strategice au toleranțe mai largi la latență și plafoane de debit mai ridicate. Obiectivele conduc deciziile arhitecturale: evitați apelurile sincrone inter-servicii pe calea activă; pre-alocați starea pistelor active; grupați doar acolo unde magistrala permite; instrumentați fiecare etapă a pipeline-ului astfel încât regresiile de latență să apară în CI mai degrabă decât în operațiuni.

Ce Urmează

Partea 2 a construit motorul. Adaptoarele senzorilor convertesc în piste canonice; magistrala de mesaje transportă evenimentele; motorul de fuziune corelează rapoartele în piste; managementul ciclului de viață menține operatorii informați cu privire la prospețimea datelor; depozitul de piste expune starea curentă. Platforma produce acum date de piste de încredere. Pur și simplu nu are suprafață orientată spre operator.

Partea 3 construiește Imaginea Operațională Comună — interfața care transformă pistele în harta pe care operatorul o folosește efectiv. Simbologia, actualizările în timp real, filtrarea bazată pe rol și deciziile inginerești care determină dacă platforma este adoptată pe teren.