Construirea unui pipeline de fuziune pentru apărare, Partea 1: Surse, scheme și stratul de adaptoare

Un pipeline de fuziune care funcționează fiabil sub sarcină nu este proiectat; el este iterat. Prima iterație eșuează aproape întotdeauna din același motiv: disciplină insuficientă la nivelul sursei și al schemei. Adaptoarele scurg concepte specifice sursei în amonte, schema de urmărire nu este suficient de stabilă pentru a suporta evoluția, modelul canonic amestecă concepte care ar trebui să rămână separate, iar șase luni mai târziu echipa rescrie motorul de fuziune în timp ce operatorii folosesc în continuare cel defect. Această serie în patru părți prezintă cum să evitați acest rezultat. Partea 1 acoperă fundația: catalogarea surselor, proiectarea schemei canonice de urmărire și stratul de adaptoare care menține totul curat.

Cadrul arhitectural pentru această serie se află în Ghidul complet pentru fuziunea datelor de apărare. Echivalentul din perspectiva C2 — construirea întregului stack C2 cu fuziunea ca o componentă — este seria paralelă care începe cu Construirea unui sistem C2 de la zero, Partea 1. Această serie se concentrează strict pe subsistemul motor de fuziune plus stratul de date.

Pasul 1: Catalogarea surselor înainte de a scrie cod

Cea mai valoroasă activitate la începutul unui program de fuziune este catalogul surselor — un document care descrie fiecare senzor, feed de informații și intrare externă pe care platforma le va ingera. Catalogul este plictisitor de construit, plictisitor de citit și esențial de realizat corect. Devine contractul de care depinde fiecare componentă din aval.

Catalogul captează, pentru fiecare sursă:

• Identitatea sursei — identificator stabil, nume prietenos, organizație proprietară.
• Formatul de wire — categoria și versiunea ASTERIX, versiunea STANAG 4586, AIS NMEA 0183, versiunea schemei CoT XML, versiunea NITF etc.
• Transportul — multicast UDP, unicast TCP, subiect MQTT, webhook HTTP, drop de fișiere. Include adresare, autentificare, postură de criptare.
• Cadența — rata mesajelor la sarcină nominală, rata de vârf, intervale de tăcere așteptate.
• Profilul de latență — timpul de observare față de timpul de raportare față de timpul de ingerare. Unele surse sunt în timp real; altele au întârzieri batch măsurate în ore.
• Acuratețe și incertitudine — ce pretinde specificația, ce arată datele operaționale, cum arată modurile de eșec.
• Postura de clasificare — nivelul de clasificare la care operează sursa, compartimentele aplicabile, regulile de difuzare care guvernează datele.
• Moduri de eșec cunoscute — căderi de legătură, întreruperi pe partea sursei, degradare graduală, posibilități de manipulare deliberată.
• Mapările schemei — cum se mapează fiecare câmp al sursei la schema canonică de urmărire (completat odată ce schema există).

Catalogul este un artefact versionat, stocat în depozit alături de codul sursă, revizuit de echipa de inginerie și (unde este cazul) de comunitatea operațională ale cărei senzori alimentează platforma. O nouă sursă nu este „integrată" până când nu are o intrare în catalog; această disciplină singură previne cel mai frecvent refactor multianual în proiectele de fuziune.

Tratamentul detaliat al provocărilor de integrare a surselor, în special semantica multi-INT care apare în apărare, se află în Provocările integrării datelor de apărare.

Pasul 2: Proiectarea schemei canonice de urmărire

Urma este structura de date centrală a oricărei platforme de fuziune. Fiecare adaptor produce urme; fiecare decizie de fuziune actualizează urme; fiecare consumator citește urme. Schema este contractul cu care platforma trăiește pe toată durata sa operațională, tipic 15-20 de ani. Investiți un sprint pentru a o face corect; investiți o săptămână pentru a o documenta.

Schema minimă viabilă include:

ID-ul urmei. Unic global, stabil pe toată durata de viață a urmei, niciodată reutilizat. UUIDv7 sau un prefix tipizat plus UUID este implicit sigur. ID-ul este opac — nu codifică sursa, identitatea sau orice alt atribut care s-ar putea schimba.

Identitate. Un tip structurat cu trei subcâmpuri: taxonomia tipului (navă, aeronavă, vehicul, persoană, unitate, semnal, altele-neclasificate), subtip (clasificare mai granulară per domeniu) și atribute de identificare (număr de borduri, număr de coadă, indicativ, MMSI, ID transponder). Identitatea este actualizată prin fuziune pe măsură ce dovezile se acumulează; ID-ul nu este.

Poziție și incertitudine. Latitudine, longitudine, altitudine în WGS84 în mod implicit. Incertitudinea reprezentată fie ca matrice de covarianță (preferată pentru fuziunea cinematică), fie ca axa majoră/minoră cu rulment (acceptabilă pentru cazuri de utilizare mai simple). Niciodată un singur număr de incertitudine — pierde informațiile geometrice de care are nevoie fuziunea.

Starea cinematică. Vectorul vitezei, rata de viraj, cursul/viteza derivate pentru afișare. Marcate temporal cu momentul estimării.

Setul de surse. Care adaptoare au contribuit cu observații la această urmă, cu clasificarea per sursă, difuzabilitatea și încrederea. Setul de surse este fundația pentru propagarea clasificării și auditului. Tratamentul detaliat se află în Fuziunea datelor militare explicată.

Trei marcaje temporale. Timpul de observare (când senzorul a văzut obiectul), timpul de raportare (când mesajul a părăsit senzorul), timpul de ingerare (când platforma l-a primit). Confundarea acestora este cea mai frecventă sursă de erori în ingineria fuziunii. Operatorii au nevoie de timpul de observare; analiticile de reluare au nevoie de timpul de ingerare; diferența dintre ele evidențiază latența senzorului pentru monitorizare.

Starea ciclului de viață. Tentativă, confirmată, matură, în scădere, pierdută. Detaliile mașinii de stare vin în Partea 2.

Învelișul de clasificare. Clasificarea efectivă calculată din setul de surse. Etichetele de difuzare calculate din intersecția difuzabilităților surselor. Marcajele compartimentelor unde este cazul.

Încredere și certitudine. Încrederea la nivel de urmă ca un scor calibrat unic. Certitudinea per atribut acolo unde diferă semnificativ — de exemplu, o urmă poate avea certitudine ridicată a poziției, dar identitate tentativă.

Pasul 3: Angajamentul față de evoluția aditivă a schemei

Schema va evolua. Vor fi necesare atribute noi; vor apărea cazuri rare pe care proiectul original nu le-a anticipat. Disciplina care menține platforma operațională prin această evoluție este versionarea exclusiv aditivă.

Regulile:

• Câmpurile noi sunt opționale. Consumatorii existenți le ignoră până când sunt actualizați. Producătorii le completează când sunt disponibile date relevante.
• Câmpurile existente nu își schimbă niciodată semantica. Un câmp care înseamnă „viteză în m/s" astăzi trebuie să însemne „viteză în m/s" pentru totdeauna. O schimbare de sens necesită un câmp nou, nu o modificare în loc.
• Eliminările sunt deprecieri. Un câmp marcat ca depreciat rămâne în schemă; noii producători încetează să-l scrie; noii consumatori încetează să-l citească; datele vechi continuă să funcționeze pe termen nelimitat.
• Modificările de rupere sunt creșteri de versiune majoră. Se întâmplă — rar. Când se întâmplă, migrarea este documentată, testată și coordonată între toți consumatorii. O schimbare de rupere ar trebui să apară cel mult o dată pe durata de viață a platformei, nu o dată per lansare.

Înfășurați schema într-o bibliotecă client generată de cod, partajată de fiecare limbaj consumator. Schema-ca-cod previne divergența lentă care altfel produce „platforma de fuziune v3.4 în serviciul A, v3.6 în serviciul B, v4.0 în serviciul C" — coșmarul operațional pe care orice program de fuziune îl va întâlni fără această disciplină.

Pasul 4: Construirea stratului de adaptoare cu izolare strictă

Stratul de adaptoare traduce formatul nativ al fiecărei surse în schema canonică de urmărire. Regula arhitecturală este brutală și merită memorată: niciun concept specific senzorului nu scapă dincolo de adaptor. Dacă codul motorului de fuziune referențiază categorii ASTERIX, aveți o arhitectură cu scurgeri. Dacă stocul de urme are o coloană pentru tipurile de mesaje AIS, aveți o arhitectură cu scurgeri. Regula este structurală — o încălcați o dată, iar costul se acumulează de-a lungul anilor.

Structura unui adaptor bine proiectat, în patru straturi:

Transport. Conectorul la sursă. Socket UDP, ascultător TCP, abonament MQTT, webhook HTTP, monitor de fișiere. Rezistent la eșecul pe partea sursei: reconectare automată cu backoff, contabilizarea mesajelor pierdute, telemetrie exportată în stiva de monitorizare a platformei.

Parser. Traduce formatul wire într-o structură în proces puternic tipizată. Validează față de specificația formatului. Respinge intrările malformate zgomotos, cu jurnalizare structurată care evidențiază malformarea, identificatorul sursei și marcajul temporal. Eliminarea tăcută a intrărilor defecte este implicit greșită — ascunde problemele operaționale care ar trebui evidențiate.

Normalizator. Mapează câmpurile specifice sursei la câmpurile schemei canonice. Conversia sistemului de coordonate (de obicei la WGS84). Normalizarea marcajelor temporale la UTC cu disciplina celor trei marcaje temporale. Normalizarea câmpurilor de identitate între diferitele moduri în care același număr de borduri sau indicativ ar putea fi formatat în surse diferite.

Emițător. Publică actualizarea canonică a urmei pe magistrala de mesaje a platformei, etichetată cu identificatorul sursei, clasificarea sursei, difuzabilitatea și un marcaj temporal proaspăt de ingerare. Emițătorul este singura componentă din adaptor care cunoaște platforma; tot ce se află deasupra sa este cod izolat specific sursei.

Fiecare adaptor rulează ca un serviciu sau proces separat. Partajează o bibliotecă client generată de cod pentru schema canonică, dar nicio altă cale de cod. Adăugarea unei surse noi înseamnă scrierea unui nou adaptor; nu atinge nicio altă componentă. Modelele detaliate de integrare pentru cele mai frecvente surse de apărare se află în Integrarea AIS și ADS-B în imaginea militară și partea CoT în Cursor on Target (CoT).

Pasul 5: Conectarea adaptorilor la o magistrală de mesaje durabilă

Adaptoarele publică pe un jurnal durabil, ordonat, partiționat. Serviciile de fuziune consumă din el. La fel fac auditul, reluarea istorică și analiticele din aval. Magistrala este măduva spinării a platformei de fuziune.

Modelul care scalează: Kafka sau NATS JetStream ca jurnal de evenimente durabil; subiect-per-tip-sursă pe partea de intrare; subiect-per-tip-ieșire pe partea de fuziune. Adaptoarele publică pe raw.<source-type>; motorul de fuziune consumă din acestea și publică pe tracks.updates, tracks.lifecycle, tracks.classification. Consumatorii se abonează la subiectele de care au nevoie.

Compromisurile detaliate între Kafka și NATS, disciplina modelării subiectelor și considerațiile operaționale se află în Cozi de mesaje pentru pipeline-urile de date de apărare.

Regula arhitecturală care merită evidențiată: nu apelați HTTP între componentele de fuziune. Cuplarea sincronă cerere-răspuns între adaptoare, servicii de fuziune și consumatori fragilizează pipeline-ul. Un vârf de senzori care blochează un consumator nu trebuie să blocheze și partea producătorului. Magistrala cu tratarea contrapresiunii este soluția structurală; HTTP între componentele de fuziune este o sursă recurentă de întreruperi.

Pasul 6: Testarea catalogului surselor față de realitate

Catalogul surselor este o ipoteză până când este testat. Disciplinele care îl validează înainte ca pipeline-ul să devină operațional:

Reluarea datelor capturate. Pentru fiecare sursă, capturați zile sau săptămâni de trafic real în format wire într-un fișier. Redați fișierul față de adaptor la rata originală și la rata accelerată. Adaptorul care gestionează date reale la viteza 10× este adaptorul care gestionează vârfurile operaționale ale senzorilor; adaptorul care gestionează doar date sintetice din catalog nu este încă pregătit.

Testarea intrărilor adversariale. Injectați mesaje malformate, AIS falsificat, ploturi radar care violează fizica (urme terestre la Mach 5), CoT XML cu violări de schemă. Adaptorul trebuie să le respingă zgomotos, să nu se prăbușească, să nu propaghe în tăcere. Disciplina se extinde la motorul de fuziune însuși, tratată în Fuziunea datelor militare explicată.

Teste de round-trip ale schemei. Fiecare adaptor trebuie să poată face round-trip intrarea sa nativă prin schema canonică și înapoi, păstrând câmpurile semnificative operațional. Un adaptor cu pierderi este un eșec de proiectare care apare la testarea de conformitate luni mai târziu.

Auditul catalogului față de date reale de producție. Odată ce pipeline-ul rulează în implementare pilot, auditați catalogul surselor față de datele reale de ingerare. Sursele care produc atribute pe care catalogul nu le-a anticipat, latențe care depășesc așteptările catalogului sau moduri de eșec pe care catalogul nu le-a documentat — acestea sunt constatări care actualizează catalogul, adaptorul sau ambele.

Ce urmează

Partea 1 a acoperit fundația. Sursele catalogate, schema canonică de urmărire proiectată cu evoluție aditivă, adaptoarele construite cu izolare strictă, magistrala de mesaje conectată și disciplinele de testare care validează stratul. Pipeline-ul ingereaza acum datele surselor și produce observații canonice de urmărire pe magistrală — dar aceste observații nu sunt încă corelate în urme.

Partea 2: Corelarea urmelor și gestionarea ciclului de viață preia fluxul de observații canonice și construiește inima motorului de fuziune. Filtrare bazată pe reguli, asociere probabilistă de date (JPDA, MHT), mașina de stare a ciclului de viață și stocul de urme ca model de citire bazat pe event sourcing.