Normalizarea datelor de la senzori: construirea unui model canonical de date de apărare

Un motor de fuziune este la fel de bun ca datele care îi sunt furnizate, iar datele care îi sunt furnizate aproape niciodată nu sunt curate. Un radar raportează distanța în metri și direcția în miliradiani; un receptor AIS raportează poziția în grade zecimale WGS84 și viteza în noduri; un produs imagistic poartă un marcaj temporal de achiziție în ora locală; un interceptor SIGINT nu poartă nicio geolocalizare. Înainte ca orice corelație, urmărire sau analiză să poată rula, fiecare dintre aceste ieșiri eterogene trebuie remodelată într-o singură reprezentare internă consistentă. Această remodelare este normalizarea datelor senzorilor, iar singura reprezentare pe care o vizează este modelul de date canonical. Acest articol acoperă cum să proiectezi modelul canonical, cum să construiești adaptoarele per sursă care mapează la acesta, cum să normalizezi unitățile, coordonatele și timpul, cum să transmiți proveniența prin fiecare înregistrare și cum să evoluezi schema de-a lungul anilor fără a strica consumatorii care depind de aceasta.

De ce un model de date canonical

Abordarea naivă a unui sistem multi-senzor este de a lăsa fiecare consumator să înțeleagă direct formatul fiecărei surse. Motorul de fuziune parsează mesaje radar, apoi mesaje AIS, apoi detecții imagistice și așa mai departe. Aceasta funcționează pentru două sau trei surse și se prăbușește sub greutatea celei de-a patra. Fiecare nou tip de senzor forțează o schimbare în codul de fuziune, în stratul de stocare, în renderer-ul COP și în fiecare analiză care atinge datele. Cuplarea este pătratică: N surse înmulțit cu M consumatori.

Un model de date canonical rupe acea cuplare. Definești o singură schemă internă — o observație normalizată — și ceri ca fiecare sursă să fie mapată la aceasta înainte de a intra în pipeline. Motorul de fuziune, depozitul de piste și stratul analitic consumă doar modelul canonical și nu văd niciodată un format nativ de senzor. Adăugarea unui senzor nou înseamnă scrierea unui singur adaptor; nicio componentă din aval nu se schimbă. Cuplarea scade de la N înmulțit cu M la N plus M.

Modelul canonical nu este un format cel mai mic numitor comun. Este un superset deliberat de bogat: poartă câmpurile de care orice consumator ar putea avea nevoie — cinematică, identitate, încredere, incertitudine, clasificare și proveniență — chiar și atunci când o sursă dată populează doar un subset al lor. Un contact radar și un raport HUMINT arată structural identice în modelul canonical; diferă doar prin câmpurile prezente și cât de încrezătoare este fiecare.

Anatomia unei observații normalizate

O observație canonică bine proiectată are cinci grupuri de câmpuri, fiecare cu un scop clar.

Identitate și tip. Un ID de observație unic la nivel global, un cod de tip-entitate extras dintr-o taxonomie controlată (vehicul terestru, navă de suprafață, aeronavă, emițător, pedestru) și orice identitate afirmată de sursă, cum ar fi un număr de pistă, MMSI sau indicativ de apel. Taxonomia tipurilor trebuie partajată între toate sursele, astfel încât o navă raportată de AIS și o navă detectată de radar să se mapeze la același tip canonical.

Cinematică. Poziție în cadrul canonical de coordonate, viteză și direcție în unități canonice și altitudine sau adâncime acolo unde este aplicabil. Fiecare câmp cinematic poartă o incertitudine asociată — o covarianță sau, cel puțin, o rază de eroare — deoarece algoritmii de fuziune nu pot ponderat o observație pe care nu o pot limita.

Timp. Un timp al evenimentului (când a avut loc observația), distinct de timpul de ingestie (când l-a primit pipeline-ul). Timpul evenimentului este baza pentru toată corelația; timpul de ingestie este pentru diagnostice și măsurarea latenței. Fiecare marcaj temporal poartă o limită de incertitudine.

Încredere. Un scor de încredere normalizat și, separat, propriul rating de fiabilitate al sursei. O detecție de mare încredere de la o sursă nesigură nu este același lucru cu o detecție de încredere moderată de la una de încredere, iar modelul canonical trebuie să le mențină distincte.

Proveniență. ID-ul sursei de origine, tipul senzorului, ID-ul mesajului nativ, versiunea adaptorului și a schemei care a produs înregistrarea și clasificarea și avertismentele moștenite de la sursă. Proveniența este cea care face ca fiecare afirmație din aval să fie trasabilă.

Adaptoare: unde trăiește complexitatea specifică sursei

Adaptorul este singurul loc din sistem care înțelege formatul nativ al unui senzor. Parsează mesajul brut, extrage câmpurile relevante, efectuează toate conversiile, atașează proveniența și emite o observație canonică. Tot ceea ce este ciudat la o sursă — layout-ul său binar proprietar, câmpurile lipsă, cadența de actualizare neregulată, deriva ceasului — este absorbit în interiorul adaptorului și nu se scurge niciodată în aval. Aceasta este aceeași disciplină de separare a preocupărilor pe care se bazează arhitectura de fuziune multi-senzor: miezul de fuziune rămâne generic tocmai pentru că adaptoarele fac munca murdară.

Adaptoarele ar trebui să fie mici, testabile independent și fără stare oriunde este posibil. Un adaptor fără stare care mapează un mesaj de intrare la o observație canonică este trivial de testat în unitate față de mesaje de probă înregistrate. Când un adaptor trebuie să mențină stare — de exemplu, pentru a interpola o poziție între actualizări rare sau pentru a aplica o corecție de offset de ceas în rulare — acea stare ar trebui să fie explicită și delimitată, niciodată o acumulare implicită care derivă pe parcursul unei misiuni lungi.

Maparea schemei în practică

Maparea schemei este traducerea câmp cu câmp de la structura nativă a unei surse la observația canonică. Partea grea este rareori câmpurile care se mapează unu-la-unu; sunt neconcordanțele. O sursă poate împacheta două concepte canonice într-un singur câmp sau poate împărți un concept canonical pe mai multe. O sursă poate folosi o enumerare fără echivalent canonical, necesitând un tabel de căutare și o valoare implicită documentată pentru valorile nerecunoscute. O sursă poate omite un câmp pe care modelul canonical îl tratează ca obligatoriu, forțând adaptorul să-l derive, să marcheze observația ca parțială sau să o respingă.

Maparea în sine ar trebui exprimată declarativ unde este posibil — un tabel de mapare sau configurație care afirmă „câmpul nativ X cu unitatea U devine câmpul canonical Y" — astfel încât traducerea să fie auditabilă și modificările să nu necesite recompilarea motorului. Codul imperativ este rezervat pentru transformările cu adevărat complexe pe care un tabel nu le poate exprima. Aceleași probleme de eterogenitate sunt la rădăcina mai largelor provocări de integrare a datelor în sistemele de apărare, iar un strat de mapare disciplinat este cea mai eficientă atenuare unică.

Unități, coordonate și timp

Trei sarcini de normalizare cauzează mai multe erori tăcute, greu de diagnosticat, decât orice altceva într-un pipeline de fuziune: conversia unităților, transformarea coordonatelor și alinierea timpului. Fiecare produce ieșire care pare plauzibilă în timp ce este greșită.

Unități. Alege un singur sistem canonical de unități — SI este alegerea convențională: metri, metri pe secundă, radiani sau grade consistent — și convertește fiecare valoare de intrare la limita adaptorului. Nodurile devin metri pe secundă; picioarele devin metri; direcțiile magnetice sunt convertite la adevărate folosind declinația magnetică locală. Pericolul nu este aritmetica de conversie, care este trivială, ci câmpul neconvertit care trece prin filtru deoarece unitatea sursei a fost presupusă mai degrabă decât verificată. Un câmp de viteză lăsat în noduri și tratat ca metri pe secundă produce o pistă care se mișcă la aproximativ de două ori viteza sa reală — o pistă care se corelează greșit și este greu de detectat deoarece nu este absurdă, ci pur și simplu incorectă.

Coordonate. Senzorii raportează în geodezic WGS84, MGRS, rețele de plan tangent local sau cadre relative platformei. Toate trebuie transformate la un singur cadru canonical de referință înainte de corelație. Folosește o bibliotecă geodezică testată mai degrabă decât trigonometrie scrisă manual; o nepotrivire de datum sau o eroare de semn într-o transformare de coordonate introduce erori de poziție de zeci de metri care sunt operațional semnificative și notabil de greu de urmărit înapoi la sursa lor.

Timp. Convertește fiecare marcaj temporal la o singură bază autoritară — UTC sincronizat GPS este standardul — și stochează-l ca timp al evenimentului, nu timp de sosire. Senzorii vechi cu ceasuri libere sau locale necesită tabele de corecție a offset-ului per sursă, iar fiecare marcaj temporal trebuie să poarte o limită explicită de incertitudine. Observațiile a căror incertitudine a marcajului temporal depășește un prag configurat ar trebui marcate sau respinse înainte de a ajunge la corelator, deoarece o observație cu etichetă temporală greșită se asociază cu obiectul greșit și corupte pista la care se alătură.

Proveniența: făcând ieșirea fuzionată responsabilă

Când o pistă fuzionată este prezentată unui comandant, întrebarea care urmează în cele din urmă este „de unde provine aceasta?" Dacă răspunsul este „motorul de fuziune a afirmat-o", nu este suficient pentru un sistem care informează decizii de angajare sau de acreditare. Proveniența este lanțul de probe care răspunde corect la întrebare: această pistă a fost construită din aceste trei observații, produse de acești doi senzori, normalizate de aceste versiuni de adaptor, la aceste timpi ale evenimentelor, purtând aceste clasificări.

Proveniența trebuie atașată la normalizare, nu reconstruită ulterior. Fiecare observație canonică poartă ID-ul sursei sale, tipul senzorului, ID-ul mesajului nativ, versiunea adaptorului și a schemei și clasificarea și avertismentele sursei. Când motorul de fuziune combină observații într-o pistă, acumulează proveniența lor în loc să o arunce, astfel încât clasificarea compusă a pistei este cea mai restrictivă dintre intrările sale și lista de surse este uniunea lor. Necesitatea de a cunoaște este aplicată la momentul interogării față de acea clasificare compusă — niciodată la ingestie, deoarece sensibilitatea eventuală a unei înregistrări depinde de ceea ce este combinată ulterior. Aceasta este aceeași disciplină de responsabilitate pe care se bazează pipeline-urile de date de apărare cu coadă de mesaje pentru a face fiecare eveniment trasabil pe măsură ce se mișcă între etape.

Evoluția schemei fără a strica consumatorii

Un model canonical este un contract de lungă durată. Sosesc noi tipuri de senzori, noi atribute devin relevante și modelul trebuie să le absoarbă fără a forța o redesfășurare sincronizată a fiecărui consumator din sistem. Disciplina care face acest lucru posibil este schimbarea aditivă și versionată.

Aditiv înseamnă că noile câmpuri sunt întotdeauna opționale și cu valori implicite, astfel încât un consumator care nu înțelege un câmp nou pur și simplu îl ignoră. Câmpurile existente nu sunt niciodată reutilizate și niciodată eliminate în loc — reutilizarea unui câmp este cel mai rapid mod de a corupe în tăcere un consumator care nu a fost actualizat. Versionat înseamnă că fiecare observație este etichetată cu versiunea schemei sub care a fost produsă, iar fiecare consumator declară versiunea minimă de schemă necesară. Un producător poate începe să emită un nou câmp opțional în ziua în care este adăugat; consumatorii îl adoptă conform propriului calendar.

Când o schimbare cu adevărat incompatibilă este inevitabilă, aceasta este introdusă ca o nouă versiune majoră de schemă care rulează în paralel cu cea veche. Producătorii emit ambele sau un shim de traducere retrogradat înregistrările noi la forma veche, până când toți consumatorii au migrat; numai atunci este retrasă versiunea veche. Această disciplină de rulare paralelă este nestrălucitoare, dar este cea care permite unei rețele de senzori să crească continuu — în același mod în care o rețea militară de senzori IoT bine proiectată îmbarcă noi tipuri de noduri — fără a opri vreodată pipeline-ul pentru o tranziție coordonată.

Versionarea schemei aduce dividende și în testare. Deoarece fiecare înregistrare poartă versiunea și proveniența sa, o capacitate de reluare poate ingesta date brute înregistrate, le poate rula printr-o nouă versiune de adaptor sau schemă și poate compara ieșirea canonică față de o bază de referință cunoscută. Modificările adaptorului sunt validate față de intrări reale înregistrate înainte de a atinge vreodată datele live, iar regresiile apar în reluare mai degrabă decât pe teren.