Puolustuksen fuusioputken rakentaminen, osa 1: lähteet, skeemot ja adapterikerros

Fuusioputkea, joka toimii luotettavasti kuormituksen alla, ei suunnitella; se iteroidaan. Ensimmäinen iteraatio epäonnistuu lähes aina samasta syystä: riittämättömästä kurista lähde- ja skeemakerroksessa. Adapterit vuotavat lähdekohtaisia käsitteitä ylävirtaan, jälkiskeema ei ole tarpeeksi vakaa tukeakseen kehittymistä, kanoninen malli sekoittaa toisiinsa käsitteitä, joiden pitäisi pysyä erillään, ja puolen vuoden kuluttua tiimi kirjoittaa fuusiomoottoria uudelleen samalla kun operaattorit käyttävät yhä rikkinäistä versiota. Tämä neliosainen sarja käy läpi, miten tällaisen lopputuloksen voi välttää. Osa 1 käsittelee perustaa: lähteiden luetteloimista, kanonisen jälkiskeeman suunnittelua ja adapterikerrosta, joka pitää kaiken muun puhtaana.

Tämän sarjan arkkitehtoninen kehys on artikkelissa Täydellinen opas puolustuksen datafuusioon. C2-puolen vastine — koko C2-pinon rakentaminen niin, että fuusio on yksi komponentti — on rinnakkainen sarja, joka alkaa artikkelista C2-järjestelmän rakentaminen tyhjästä, osa 1. Tämä sarja keskittyy kapeasti fuusiomoottorin ja datakerroksen alajärjestelmään.

Vaihe 1: luetteloi lähteet ennen koodin kirjoittamista

Fuusioohjelman alussa korkeimman vipuvaikutuksen toiminto on lähdekatalogi — dokumentti, joka kuvaa jokaisen sensorin, tiedustelusyötteen ja ulkoisen syötteen, jota alusta tulee ottamaan vastaan. Katalogi on tylsä rakentaa, tylsä lukea ja ratkaisevan tärkeä saada oikein. Siitä tulee sopimus, josta jokainen alavirran komponentti riippuu.

Katalogi tallentaa jokaisesta lähteestä:

• Lähteen identiteetti — vakaa tunniste, helppokäyttöinen nimi, omistava organisaatio.
• Siirtomuoto — ASTERIX-kategoria ja -versio, STANAG 4586 -julkaisu, AIS NMEA 0183, CoT XML -skeeman versio, NITF-versio jne.
• Kuljetus — UDP-multicast, TCP-unicast, MQTT-aihe, HTTP-webhook, tiedostopudotus. Sisältää osoitteistuksen, todennuksen ja salauksen tilan.
• Tahti — viestimäärä nimellisellä kuormalla, huipputaso, odotetut hiljaisuusvälit.
• Viiveprofiili — havaintoaika vs. raportointiaika vs. vastaanottoaika. Osa lähteistä on reaaliaikaisia; toisilla on tunneissa mitattavia eräviiveitä.
• Tarkkuus ja epävarmuus — mitä spesifikaatio väittää, mitä operatiivinen data osoittaa, miltä vikatilat näyttävät.
• Luokitustila — millä luokitustasolla lähde toimii, mitkä lokerot pätevät, mitkä jaettavuussäännöt ohjaavat dataa.
• Tunnetut vikatilat — yhteyskatkokset, lähdepuolen häiriöt, asteittainen heikkeneminen, tahallisen manipuloinnin mahdollisuudet.
• Skeemakartoitukset — miten kukin lähdekenttä kartoittuu kanoniseen jälkiskeemaan (täytetään, kun skeema on olemassa).

Katalogi on versioitu artefakti, joka tallennetaan repositoryyn lähdekoodin rinnalle, ja jonka tarkastaa insinööritiimi ja (tarvittaessa) operatiivinen yhteisö, jonka sensorit syöttävät dataa. Uutta lähdettä ei ole "integroitu", ennen kuin sillä on katalogimerkintä; pelkästään tämä kuri estää yleisimmän monivuotisen uudelleenkirjoituksen fuusioprojekteissa.

Lähteiden integroinnin haasteiden, erityisesti puolustuksessa esiin nousevan multi-INT-semantiikan, yksityiskohtainen käsittely on artikkelissa Puolustuksen dataintegraation haasteet.

Vaihe 2: suunnittele kanoninen jälkiskeema

Jälki on minkä tahansa fuusioalustan keskeinen tietorakenne. Jokainen adapteri tuottaa jälkiä; jokainen fuusiopäätös päivittää jälkiä; jokainen kuluttaja lukee jälkiä. Skeema on sopimus, jonka kanssa alusta elää koko operatiivisen elinkaarensa, tyypillisesti 15–20 vuotta. Käytä sprintti sen tekemiseen oikein; käytä viikko sen dokumentointiin.

Minimitoteutuskelpoinen skeema sisältää:

Jälki-ID. Globaalisti yksilöllinen, vakaa jäljen koko elinkaaren ajan, ei koskaan uudelleenkäytetty. UUIDv7 tai tyypitetty etuliite-plus-UUID on turvallinen oletus. ID on läpinäkymätön — se ei koodaa lähdettä, identiteettiä tai mitään muuta attribuuttia, joka saattaa muuttua.

Identiteetti. Rakenteinen tyyppi kolmella alikentällä: tyyppitaksonomia (alus, ilma-alus, ajoneuvo, henkilö, yksikkö, signaali, luokittelematon-muu), alatyyppi (toimialakohtainen tarkempi luokittelu) ja yksilöivät attribuutit (runkonumero, häntänumero, kutsutunnus, MMSI, transponderitunnus). Fuusio päivittää identiteettiä, kun näyttöä kertyy; ID:tä ei.

Sijainti ja epävarmuus. Leveys-, pituus- ja korkeusaste WGS84:ssä oletuksena. Epävarmuus esitetään joko kovarianssimatriisina (suositeltu kinemaattiseen fuusioon) tai pää-/sivuakselina suuntakulman kanssa (hyväksyttävä yksinkertaisempiin käyttötapauksiin). Ei koskaan yhtenä epävarmuuslukuna — se hävittää geometrisen tiedon, jota fuusio tarvitsee.

Kinemaattinen tila. Nopeusvektori, kääntymisnopeus, näytölle johdettu suunta/nopeus. Aikaleimattu estimoinnin hetkellä.

Lähdejoukko. Mitkä adapterit ovat tuottaneet havaintoja tähän jälkeen, lähdekohtaisella luokituksella, jaettavuudella ja luottamuksella. Lähdejoukko on luokituksen propagoinnin ja auditoinnin perusta. Yksityiskohtainen käsittely on artikkelissa Sotilaallinen datafuusio selitettynä.

Kolme aikaleimaa. Havaintoaika (kun sensori näki kohteen), raportointiaika (kun viesti lähti sensorista), vastaanottoaika (kun alusta vastaanotti sen). Näiden sekoittaminen toisiinsa on yleisin bugilähde fuusiotyössä. Operaattorit tarvitsevat havaintoaikaa; toistoanalytiikka tarvitsee vastaanottoaikaa; niiden ero paljastaa sensoriviiveen valvontaa varten.

Elinkaaritila. Alustava, vahvistettu, kypsä, hiipuva, kadonnut. Tilakoneen yksityiskohdat ovat osassa 2.

Luokitusverho. Lähdejoukosta laskettu efektiivinen luokitus. Lähteiden jaettavuuksien leikkauksesta lasketut jaettavuustunnisteet. Lokeromerkinnät tarvittaessa.

Luottamus ja varmuus. Jälkitason luottamus yhtenä kalibroituna pistemääränä. Attribuuttikohtainen varmuus, kun se eroaa olennaisesti — esimerkiksi jäljellä voi olla korkea sijaintivarmuus mutta alustava identiteetti.

Vaihe 3: sitoudu additiiviseen skeeman kehittymiseen

Skeema tulee kehittymään. Uusia attribuutteja tarvitaan; esiin nousee harvinaisia tapauksia, joita alkuperäinen suunnittelu ei osannut ennakoida. Kuri, joka pitää alustan operatiivisena tämän kehityksen läpi, on vain additiivinen versiointi.

Säännöt:

• Uudet kentät ovat valinnaisia. Olemassa olevat kuluttajat sivuuttavat ne, kunnes ne päivitetään. Tuottajat täyttävät ne, kun olennaista dataa on saatavilla.
• Olemassa olevat kentät eivät koskaan muuta semantiikkaansa. Kentän, joka tänään tarkoittaa "nopeus m/s", on tarkoitettava "nopeus m/s" ikuisesti. Merkityksen muutos vaatii uuden kentän, ei paikallista muutosta.
• Poistot ovat vanhentamisia. Vanhentuneeksi merkitty kenttä on yhä skeemassa; uudet tuottajat lakkaavat kirjoittamasta sitä; uudet kuluttajat lakkaavat lukemasta sitä; vanha data toimii edelleen rajattomasti.
• Rikkovat muutokset ovat pääversionostoja. Niitä tapahtuu — harvoin. Kun niitä tapahtuu, migraatio dokumentoidaan, testataan ja koordinoidaan kaikkien kuluttajien kesken. Rikkovan muutoksen tulisi tapahtua korkeintaan kerran alustan elinkaaren aikana, ei kerran julkaisua kohti.

Käärinkää skeema koodista generoituun asiakaskirjastoon, jonka jokainen kuluttajakieli jakaa. Skeema koodina estää hitaan eriytymisen, joka muutoin tuottaa "fuusioalusta v3.4 palvelussa A, v3.6 palvelussa B, v4.0 palvelussa C" — operatiivisen painajaisen, jonka jokainen fuusioohjelma kohtaa ilman tätä kuria.

Vaihe 4: rakenna adapterikerros tiukalla eristyksellä

Adapterikerros kääntää kunkin lähteen natiivimuodon kanoniseksi jälkiskeemaksi. Arkkitehtoninen sääntö on raaka ja muistamisen arvoinen: mikään sensorikohtainen käsite ei vuoda adapterin ohi. Jos fuusiomoottorisi koodi viittaa ASTERIX-kategorioihin, sinulla on vuotava arkkitehtuuri. Jos jälkivarastossasi on sarake AIS-viestityypeille, sinulla on vuotava arkkitehtuuri. Sääntö on rakenteellinen — riko se kerran, ja kustannus kertaantuu vuosien yli.

Hyvin suunnitellun adapterin rakenne, neljässä kerroksessa:

Kuljetus. Liitäntä lähteeseen. UDP-soketti, TCP-kuuntelija, MQTT-tilaus, HTTP-webhook, tiedostonvalvoja. Kestävä lähdepuolen vikaa vastaan: automaattinen uudelleenyhdistys peräytymisellä, pudonneiden viestien kirjanpito, telemetria vietynä alustan valvontapinoon.

Jäsentäjä. Kääntää siirtomuodon vahvasti tyypitetyksi prosessinsisäiseksi rakenteeksi. Validoi muotospesifikaatiota vasten. Hylkää virheellisen syötteen äänekkäästi, rakenteisella lokituksella, joka tuo esiin virheellisyyden, lähdetunnisteen ja aikaleiman. Virheellisen syötteen hiljainen pudottaminen on väärä oletus — se piilottaa operatiiviset ongelmat, jotka pitäisi tuoda esiin.

Normalisoija. Kartoittaa lähdekohtaiset kentät kanonisen skeeman kenttiin. Koordinaattijärjestelmän muunnos (tyypillisesti WGS84:ään). Aikaleiman normalisointi UTC:hen kolmen aikaleiman kurilla. Identiteettikenttien normalisointi niiden eri tapojen läpi, joilla sama runkonumero tai kutsutunnus saatetaan muotoilla eri lähteissä.

Lähettäjä. Julkaisee kanonisen jälkipäivityksen alustan viestiväylälle, merkittynä lähdetunnisteella, lähteen luokituksella, jaettavuudella ja tuoreella vastaanottoaikaleimalla. Lähettäjä on adapterin ainoa komponentti, joka tietää alustasta; kaikki sen yläpuolella on lähdekohtaista eristettyä koodia.

Kukin adapteri toimii erillisenä palveluna tai prosessina. Ne jakavat koodista generoidun asiakaskirjaston kanoniselle skeemalle, mutta eivät muita koodipolkuja. Uuden lähteen lisääminen tarkoittaa uuden adapterin kirjoittamista; se ei kosketa mihinkään muuhun komponenttiin. Yleisimpien puolustuslähteiden yksityiskohtaiset integrointimallit ovat artikkeleissa AIS:n ja ADS-B:n integrointi sotilaalliseen tilannekuvaan ja CoT-puolelta Cursor on Target (CoT).

Vaihe 5: kytke adapterit kestävään viestiväylään

Adapterit julkaisevat kestävään, järjestettyyn, partitioituun lokiin. Fuusiopalvelut kuluttavat siitä. Niin tekevät myös auditointi, historiallinen toisto ja alavirran analytiikka. Väylä on fuusioalustan selkäydin.

Skaalautuva malli: Kafka tai NATS JetStream kestävänä tapahtumalokina; aihe lähdetyyppiä kohti syöttöpuolella; aihe tulostetyyppiä kohti fuusiopuolella. Adapterit julkaisevat aiheeseen raw.<source-type>; fuusiomoottori kuluttaa nämä ja julkaisee aiheisiin tracks.updates, tracks.lifecycle, tracks.classification. Kuluttajat tilaavat ne aiheet, joita tarvitsevat.

Kafkan ja NATS:n väliset yksityiskohtaiset kompromissit, aiheiden mallinnuksen kuri ja operatiiviset näkökohdat ovat artikkelissa Viestijonot puolustuksen dataputkille.

Esiin nostamisen arvoinen arkkitehtoninen sääntö: älä kutsu HTTP:tä fuusiokomponenttien välillä. Synkroninen pyyntö–vastaus-kytkentä adapterien, fuusiopalvelujen ja kuluttajien välillä tekee putkesta hauraan. Sensoripiikin, joka pysäyttää yhden kuluttajan, ei saa pysäyttää tuottajapuolta. Vastapaineenkäsittelyllä varustettu väylä on rakenteellinen ratkaisu; HTTP fuusiokomponenttien välillä on toistuva häiriölähde.

Vaihe 6: testaa lähdekatalogi todellisuutta vasten

Lähdekatalogi on hypoteesi, kunnes se testataan. Kurit, jotka validoivat sen ennen kuin putki menee operatiiviseksi:

Talletetun datan toisto. Tallenna kustakin lähteestä päiviä tai viikkoja todellista siirtomuotoista liikennettä tiedostoon. Toista tiedosto adapteria vasten alkuperäisellä nopeudella ja kiihdytetyllä nopeudella. Adapteri, joka käsittelee todellista dataa 10× nopeudella, on adapteri, joka käsittelee operatiiviset sensoripiikit; adapteri, joka käsittelee vain katalogisynteettistä dataa, ei ole vielä valmis.

Vihamielisen syötteen testaus. Syötä virheellisiä viestejä, väärennettyä AIS:ää, fysiikan rikkovia tutkahavaintoja (Mach 5 -maajäljet), CoT XML:ää skeemarikkomuksilla. Adapterin on hylättävä nämä äänekkäästi, ei kaatua, ei hiljaa levittää eteenpäin. Kuri jatkuu fuusiomoottoriin itseensä, jota käsitellään artikkelissa Sotilaallinen datafuusio selitettynä.

Skeeman edestakaistestit. Jokaisen adapterin on pystyttävä viemään natiivisyötteensä kanonisen skeeman läpi ja takaisin, säilyttäen operatiivisesti merkittävät kentät. Häviöllinen adapteri on suunnitteluvirhe, joka paljastuu konformanssitestauksessa kuukausia myöhemmin.

Katalogin auditointi todellista tuotantodataa vasten. Kun putki toimii pilottikäyttöönotossa, auditoi lähdekatalogi todellista vastaanottodataa vasten. Lähteet, jotka tuottavat attribuutteja, joita katalogi ei osannut ennakoida, viiveitä, jotka ylittävät katalogin odotukset, tai vikatiloja, joita katalogi ei dokumentoinut — nämä ovat havaintoja, jotka päivittävät katalogin, adapterin tai molemmat.

Mitä seuraavaksi

Osa 1 on käsitellyt perustan. Lähteet luetteloitu, kanoninen jälkiskeema suunniteltu additiivisella kehittymisellä, adapterit rakennettu tiukalla eristyksellä, viestiväylä kytketty ja testauskurit, jotka validoivat kerroksen. Putki ottaa nyt vastaan lähdedataa ja tuottaa kanonisia jälkihavaintoja väylälle — mutta näitä havaintoja ei ole vielä koreloitu jäljiksi.

Osa 2: jälkien korrelointi ja elinkaaren hallinta ottaa kanonisen havaintovirran ja rakentaa fuusiomoottorin ytimen. Sääntöpohjainen portitus, probabilistinen data-assosiaatio (JPDA, MHT), elinkaaritilakone ja jälkivarasto tapahtumalähteisenä lukumallina.