Tiedustelun fuusioiminen lähteistä SIGINT, IMINT, HUMINT ja OSINT yhdeksi johdonmukaiseksi kuvaksi kuulostaa käsitteellisesti suoraviivaiselta. Käytännössä se on yksi puolustustietoinfrastruktuurin vaikeimmista insinööriongelmista. Kukin tiedustelualan tuottaa tietoa eri nopeudella, eri muodossa ja eri luottamusmallilla — ja järjestelmä, joka vain kokoaa nämä syötteet ilman todellista korrelointia, tuottaa kohuisemman kuvan kuin hyvin hallittu yhden INT-alan syöte, ei paremman. Vakava tietojen integrointi puolustustiedusteluun edellyttää arkkitehtuuria, joka on suunniteltu ensiperiaatteista kunkin lähdetyypin ominaisuuksien ympärille, eikä yleistä tietovarastoa, johon INT-sovittimet on kiinnitetty jälkikäteen.

Tässä artikkelissa käydään läpi reaaliaikaisen monilähteisen fuusiojärjestelmän koko arkkitehtuuri — heterogeenisten syötteiden vastaanottokerroksesta entiteettien ratkaisuun ja korrelaatiomoottoriin sekä luottamuspisteytykseen ja rikastetun tiedustelukuvan julkaisuun C2-järjestelmiin. Kussakin osiossa käsitellään niitä suunnittelupäätöksiä, jotka erottavat tuotantotason fuusiosta prototyypit, jotka näyttävät oikeilta demossa mutta epäonnistuvat operatiivisessa mittakaavassa.

Monilähteisen tiedustelufuusion ongelma — miksi SIGINT/IMINT/HUMINT/OSINT-fuusio on vaikeampaa kuin näyttää

Kolme rakenteellista ongelmaa tekee monilähteisestä fuusiosta laadullisesti vaikeampaa kuin yksittäisen INT-alan skaalaus. Niiden ohittaminen — fuusion käsittely vain tietoputkiongelmana — on yleisin arkkitehtoninen virhe, ja se tuottaa järjestelmän, jota ei voi enää korjata, kun tieto virtaa tuotantomäärissä.

Muotoheterogeenisuus on näkyvin ongelma. ELINT-kuuntelutietueessa on emitterin taajuus, pulssintoistoväli, skannaustyyppi, suunta ja saapumisajankohtaero (TDOA). IMINT-havainnossa on rajauslaatikko, pikselitilan luottamuspiste, maanäytteenmistaväli ja UTM-koordinaatti sekä siihen liittyvä CEP. HUMINT-kertomusote sisältää vapaata tekstiä, analyytikon lähteen arvosanan, nimetyn sijainnin ja tuntiin tai päiviin mitatun aikaikkunan. Nämä kolme tietuetta voivat viitata samaan todelliseen kohteeseen — tutka-ajoneuvoon — mutta niillä ei ole yhteistä kenttää, yhteistä koordinaattijärjestelmän käytäntöä eikä yhteistä tunninta. Niiden normalisointi yhdeksi kanoniseksi skeemaksi edellyttää kunkin lähdetyypin tarkoitukseen rakennettuja sovittimia ja kanonista entiteettimallia, joka mukautuu kaikkiin niihin romahtamatta niiden semantiikkaa. Moni-INT-ensorifuusio sotilaskäytössä -datamallin suunnittelu käsittelee tätä kanonista kerrosta yksityiskohtaisesti.

Luottamusristiriita on hienovaraisempi, mutta aiheuttaa enemmän analyyttisia virheitä. Kukin INT soveltaa omaa luottamusmalliaan. SIGINT-paikannus kantaa CEP:n (Circular Error Probable) metreinä — geometrinen tarkkuusarvio. IMINT-havainnossa on luokittelijan todennäköisyys — hermoverkon logit-arvo objektiluokalle. HUMINT kantaa admiralty-luotettavuusarvosanan — kuusiportaisen inhimillisen arvion asteikon. Nämä kolme lukua tarkoittavat perustavanlaatuisesti eri asioita. Naiivi fuusiojärjestelmä, joka keskiarvottaa ne, tuottaa luvun, joka on matemaattisesti pätevä mutta analyyttisesti merkityksetön. Oikean luottamusmallin on ensin käännettävä jokainen lähteen oma luottamus yhteiseen todennäköisyyskehykseen ja sen jälkeen aggregoitava lähteiden välillä bayesilaisella tai todisteiden yhdistämisen menetelmällä (kuten Dempster-Shafer), joka käsittelee riippuvaisia ja riippumattomia todisteita oikein.

Ajallinen vinouma on ongelma, joka rikkoo reaaliaikaiset fuusioarkkitehtuurit näkyvimmin. Eri lähteillä on täysin erilaiset viiveet tapahtuman ja putkeen saapuvan tiedon välillä. SIGINT-kuuntelu voi saapua putkeen sekunneissa lähetyksestä. Tehtävöitetyn satelliitin IMINT voi vaatia 60–90 minuutin kuvankäsittelyn ennen havaintotietueen tuottamista. Eilisiä tapahtumia kuvaava HUMINT-raportti voidaan ottaa vastaan päivänä D+2. Fuusiomootori, joka korreloi tietueet putken saapumisaikaleiman mukaan, liittää tapahtumat järjestelmällisesti väärin — se ei onnistu linkittämään SIGINT-kuuntelua ja IMINT-vahvistusta, vaikka ne kuvaavat samaa tapahtumaa, koska ne saapuivat 90 minuutin välein. Arkkitehtuurin on erotettava tapahtuma-aika (milloin tapahtuma maailmassa tapahtui) saapumisajasta (milloin viesti saapui putkeen) ja tehtävä kaikki ajallinen korrelointi tapahtuma-ajassa käyttäen saapumisaikaa vain putken suorituskyvyn seurantaan.

Virran vastaanottoarkkitehtuuri — Kafka vs Pulsar tiedustelusyötteille, skeemarekisteri heterogeenisille viestityypeille, takapaineen käsittely

Virran vastaanottokerroksen on käsiteltäviä viestejä, joiden nopeudet vaihtelevat muutamasta HUMINT-raportista tunnissa miljooniin SIGINT-tietueisiin tunnissa yhdestäkeräysjärjestelmästä, kaikki virtaavat samaan fuusioputkeen. Suunnittelun on imevä räjähdysmäinen liikenne korkeanopeuksisista lähteistä soveltamatta takapainetta matalanopeuksisiin, korkean prioriteetin lähteisiin — HUMINT-raportti, joka saapuu räjähdyksenä SIGINT-tulvan rinnalla, ei saa viivästyä putken ollessa kyllästynyt.

Tämän kerroksen ensisijainen arkkitehtoninen valinta on Apache Kafkan ja Apache Pulsarin välillä. Molemmat ovat hajautettuja, vikasietoisia ja taistelukelpoisia puolustustason järjestelmien mittakaavassa. Kafkalla on laajempi ekosysteemi ja tiiviimpi integraatio virrankäsittelykehyksiin — sekä Kafka Streamsillä että Apache Flinkillä on ensiluokkaiset Kafka-lähdekonnektorit. Pulsar tarjoaa natiivin monivuokralaisuuden, nimitilan mukaisen topikkien eristämisen ja erillisen laskenta-tallennus-arkkitehtuurin. Yhden vuokralaisen fuusioalustalle, joka toimii yhden turvaluokituksen alueella, Kafka on käytännöllinen valinta. Alustalle, jonka on eristettävä syötteet turvaluokituksen mukaan, tuettava yhteydettömiä eteen sijoitettuja solmuja, jotka synkronoivat asynkronisesti takalinjan klusteriin, tai palveltava useita vuokralaisorganisaatioita, Pulsarin arkkitehtuuri tarjoaa siistimpiä eristysprimitiivejä ilman tilapäisiä työkaluja.

Välittimen valinnasta riippumatta topikkirakenteen on pakotettava yksi topikki lähdetyypille, ei yksi topikki INT-alalle:

# Topic naming convention: {classification}.{int-type}.{source-id}.raw ts.sigint.comint-system-alpha.raw ts.sigint.elint-collection-bravo.raw ts.imint.uav-sensor-charlie.raw ts.imint.sat-proc-delta.raw ts.humint.field-reports.raw ts.osint.ais-feed.raw ts.osint.social-monitor.raw # Normalized output topics (post-adapter) ts.fusion.observations.normalized ts.fusion.entities.enriched ts.fusion.correlations.output

Skeemarekisteri on pakollinen normalisoiduille tulostopikeille. Ilman pakotettuja skeemoja yksi virheellinen viesti mistä tahansa sovittimesta voi rikkoa alavirran kuluttajan deserialisointikontekstin ja pysäyttää koko fuusioputken. Rekisteri pakottaa Avro- tai Protobuf-skeemat jokaiseen fuusiopikkeille tehtyyn kirjoitukseen ja hylkää validoinnin epäonnistuneet viestit ennen kuin ne saavat välittimeen. Skeemayhteensopivuussäännöt — BACKWARD, FORWARD tai FULL — on asetettava pikeittäin kuluttajien kehityksen mukaan. Normalisoidulle havaintoskeemalle BACKWARD-yhteensopivuus on sopiva: uudet skeemaversiot voivat lisätä valinnaisia kenttiä, ja vanhat kuluttajat, jotka eivät ymmärrä uusia kenttiä, jatkavat toimintaansa oikein.

Takapaineen käsittely edellyttää lähdetyypikohtaisia nopeusrajoja ja prioriteettiluokittelua. Korkean prioriteetin lähteitä — SIGINT ja IMINT reaaliaikaisista keräysjärjestelmistä — ei saa milloinkaan rajoittaa. Matalan prioriteetin lähteiden — joukko-OSINT-otaus, historiallisen HUMINT-latauksen — olisi kannettava nimenomaisia prioriteettipainoja, jotka sallivat välittimen kuristaa niiden kuluttajia, kun putken läpivirtaus on rajoitettu. Kafkassa tämä toteutetaan kuluttajaryhmien kiintiöillä ja ositusstrategioilla. Pulsarissa nimitilan nopeusrajoitus ja lähetyskiintiöt tarjoavat vastaavan hallinnan. Tiedusteludataputki sotilaskäytössä -arkkitehtuurimallit käsittelevät jononhallintaa ja kuluttajaryhmien suunnittelua perusteellisesti.

Entiteettien ratkaisu ja deduplikointi — estostrategiat entiteettiehdokkaiden luontiin, koneoppimispohjainen samankaltaisuuspisteytys, graafipohjainen entiteettien yhdistäminen

Entiteettien ratkaisu on komponentti, joka muuntaa virran itsenäisiä havaintoja — kukin kuvaa havaittua kohdetta tai raportoitua tapahtumaa — joukoksi yhtenäisiä entiteettitietueita, joissa kaikki samasta todellisesta kohteesta tehdyt havainnot on yhdistetty. Se on vaikein komponentti saada oikein ja herkin hiljaisesti heikkenemään: heikolla entiteettien ratkaisulla varustettu järjestelmä ei kaadu; se tuottaa kuvan, jossa on liian monta entiteettiä (pirstoutuneet reitit) tai liian vähän (virheelliset yhdistelmät), ja nämä virheet kasaantuvat ajan myötä, kun fuusio rakentuu vialliseen entiteettitilaan.

Naiivi lähestymistapa — vertaa jokaista saapuvaa havaintoa jokaiseen olemassa olevaan entiteettiin — on laskennallisesti mahdoton missään realistisessa mittakaavassa. ELINT-keräysjärjestelmä, joka tuottaa 10 000 kuuntelutietuetta minuutissa 50 000 aktiivisen entiteettireitin aineistoa vasten, vaatisi 500 miljoonaa vertailua minuutissa ennen minkään samankaltaisuuspisteytyksen aloittamista. Estostrategiat vähentävät tämän käsiteltäväksi ehdokasjoukoksi hyödyntämällä tiedusteludatan rakennetta:

  • Geosolu-estointi — indeksoi jokainen entiteetti arvioidun sijaintinsa mukaan H3-hexaruudukolla resoluutiotasolla 9 (noin 0,1 km² solut). Saapuva havainto luo ehdokasparit vain samassa solussa ja sen kuudessa välittömässä naapurissa oleville entiteeteille. Tämä yksi estoavain poistaa yli 99,9 % ehdokaspareista aineistoissa, joilla on paikkatieto, saavuttaen samalla korkean herkkyyden aidosti samassa paikassa oleville havainnoille.
  • Ajallinen estointi — rajaa ehdokkaat entiteetteihin, joiden voimassaoloaikaväli leikkaa määritettävissä olevan ikkunan ympäriltä havaintotapahtuman aikaa. Liikkuvalle ajoneuvolle ikkunan on huomioitava suurin uskottava nopeus edellisen havainnon ja nykyhavainnon sijainnin välillä — panssarivaunu ei ehdi 50 km:n matkaa 5 minuutissa. Ajallinen estointi ilman geosolu-estointia tuottaa valtavia ehdokasjoukkoja globaalisti aktiiviselle entiteetille; ne toimivat yhdessä yhdistettynä avaimena.
  • Kovan tunnisteen estointi — ryhmitä kaikki tietueet, joilla on sama deterministinen tunniste (IMSI, rekisterikilven OCR-tulos, biometrinen tiiviste, ilma-aluksen Mode-S-transponderikoodi), yhdeksi ehdokasklusteriksi sijainnista ja ajasta riippumatta. Kovat tunnisteet ohittavat kaiken muun estoinnin ja niitä pidetään lopullisina yhdistämissignaaleina, kunnes tunnisteen oma deduplikointitarkistus on tehty.
  • INT-tyypin affiniteettiestointi — tietyt INT-rajat ylittävät parit ovat rakenteellisesti epätodennäköisiä osumia eikä niitä pitäisi pisteyttää. Merellistä SIGINT-säteilyhavaintoa ei pitäisi pisteyttää maajoneuvon IMINT-reittiä vasten. Entiteettityypeittäin määritellyt affiniteettisäännöt poistavat rakenteellisesti epätodennäköiset ehdokasparit ennen pisteytystä.

Ehdokasparien samankaltaisuuspisteytys käyttää gradient boost -mallia (XGBoost tai LightGBM), joka on koulutettu merkityillä osuma/ei-osuma-pareilla historiallisesta tiedusteludatasta. Piirrevektorit sisältävät: paikallisen etäisyyden normalisoituna sijaintiepävarmuudella, ajallisen etäisyyden normalisoituna entiteettityypin nopeuskattimella, attribuuttien limittymispisteen tyypityille attribuuteille (entiteettiluokka, liittouma, kalustotyyppi) ja INT-tyypin yhteensopivuuspainon. Malli antaa osumatodennäköisyyden välillä [0, 1]. Parit, jotka ylittävät korkean kynnyksen (tyypillisesti 0,85–0,92), yhdistetään automaattisesti; välialueen parit ohjataan analyytikon tarkastettaviksi; matalan kynnyksen alittavia pidetään erillisinä entiteetteinä.

Graafipohjainen entiteettien yhdistäminen hoitaa monitapauksen — jossa kolme tai useampi havainto on ratkaistava samaan entiteettiin. Ylläpidetään graafia, jonka solmut ovat havaintotietueita ja kaaret yhdistämispäätöksiä, joilla on mukanaan luottamuspisteet. Graafin yhdistetyt komponentit edustavat entiteettiehdokasklustereita. Kunkin klusterin kultainen tietue lasketaan soveltamalla määriteltyä yhdistämispolitiikkaa kaikkiin osallistuviin havaintoihin. Kun uusi korkean luottamuksen kaari lisätään ja se yhdistää kaksi aiemmin erillistä komponenttia, komponentit yhdistetään ja niiden kultaiset tietueet yhdistetään. Graafiesitys mahdollistaa myös jakotoimenpiteet: korkean luottamuken kaaren poistaminen ja yhdistettyjen komponenttien uudelleenlaskenta on mekanismi virheellisen yhdistelmän korjaamiseksi.

Arkkitehtuuriviite
Entiteettien ratkaisuputki — vaihevirta
1
Estointi — luo ehdokasparit geosolu-, aika- ja kovatunnisteavaimilla. Herkkyystavoite: yli 99,5 % todellisista osumista ehdokasjoukossa.
2
Piirre-otto — laskee paikallisen etäisyyden, ajallisen eron, attribuuttien limittymisen ja INT-tyypin yhteensopivuuden jokaiselle ehdokasparille.
3
ML-pisteytys — gradient boost -malli antaa osumatodennäköisyyden parille. Kovatunnisteparit ohittavat pisteytyksen ja siirtyvät suoraan yhdistämiseen.
4
Kynnysten reititys — piste ≥ 0.88: automaattiyhdistäminen. 0.55–0.87: analyytikon tarkastusjono. < 0.55: hylkää (erilliset entiteetit).
5
Graafiyhdistäminen — päivitä entiteettigraafi uusilla kaarilla; laske uudelleen yhdistettyjen komponenttien kultaiset tietueet; lähetä päivitetyt entiteetit rikastettuun entiteettivirtaan.
Viisivaiheinen entiteettien ratkaisuputki ehdokkaiden luonnista kultaisen tietueen julkaisuun.

Korrelaatiomoottorin suunnittelu — aikaikkunapohjainen korrelointi (ajallinen läheisyys), paikallinen korrelointi (geosolujen ryhmittely), semanttinen korrelointi (entiteettiattribuuttien vastaavuus)

Kun entiteettien ratkaisu kysyy ”ovatko nämä havainnot samasta kohteesta?”, korrelaatiomoottori kysyy ”muodostavatko nämä eri kohteisiin liittyvät tapahtumat merkitsevän kaavan?”. Ajoneuvo, joka havaitaan logistiikkapaikan lähellä, ja 20 minuuttia myöhemmin sama ajoneuvo polttoainepisteessä, ja sitten SIGINT-kuuntelu radiokeskustelusta, joka vastaa yksikön sijaintiraporttia polttoainepisteestä — nämä kolme tapahtumaa liittyvät samaan ajoneuvoon mutta kuvaavat myös tilannekaavaa (täydennystoimintaa), joka on analyyttisesti merkittävämpi kuin yksikäs havainto. Korrelaatiomoottori tuottaa tämän korkeamman tason tiedusteluobjektin.

Korrelointi toimii kolmella tasolla samanaikaisesti:

Ajallinen korrelointi ryhmittelee tapahtumat aikaikkunoihin tapahtuma-aikaleiman mukaan ja etsii samanaikaisuuskaavoja kussakin ikkunassa. Ikkunan määritys on sääntökohtaisesti muokattavissa: sääntö, joka havaitsee samanaikaisen häirinnän alkamisen ja oman viestinnän häiriintymisen, voi käyttää 30 sekunnin ikkunaa; sääntö, joka havaitsee ajoneuvon kulkupisteessä ja toisen ajoneuvon samassa kulkupisteessä, voi käyttää 2 tunnin ikkunaa. Liukuvat ikkunat (limittäin puolella ikkunan kestolla) varmistavat, ettei ikkunan reunoilla olevia tapahtumia jäädä välistä. Apache Flinkin tapahtuma-ajan ikkunointi watermarkeilla on standardi toteutusvalinta, koska se käsittelee järjestyksettömän tapahtumasaapumisen oikein — kriittistä putkessa, jossa IMINT:llä ja HUMINT:llä on hyvin erilaiset otausviiveet.

Paikallinen korrelointi ryhmittelee entiteetit arvioidun sijaintinsa mukaan geosolujen avulla resoluutiolla, joka on kalibroitu korrelaatiosäännön paikalliseen mittakaavaan. H3-resoluutio 8 (noin 0,7 km²) sopii ajoneuvojen havaitsemiseen samalla vyöhykkeellä; H3-resoluutio 6 (noin 36 km²) toimintakaavojen havaitsemiseen alueella. Toisin kuin entiteettien ratkaisun geosolu-estointi (joka tarvitsee korkean herkkyyden), korrelaation paikallinen ryhmittely tarvitsee sääntömääritteisen tarkkuuden: korrelaatiosääntö, joka havaitsee komentoajoneuvon ja logistiikka-ajoneuvon samanpaikkaisuuden, käyttää tiukempaa solua kuin sääntö, joka havaitsee alueellisen huoltotoiminnan. Säännöt koodaavat oman paikallisen resoluutionsa eivätkä peri yleistä asetusta.

Semanttinen korrelointi vastaa entiteettejä attribuuttiarvojen eikä paikallisen tai ajallisen läheisyyden perusteella. Ilmapuolustustutkaksi luokiteltu entiteetti, joka alkaa säteillä, korreloituu hävittäjään, joka tulee tutkan peittoalueelle — korrelointi johtuu attribuuttien semantiikasta (tutkatyyppi vs lentokonetyppi ja rata), ei niiden samassa paikassa olemisesta. Semanttiset säännöt koodaavat attribuuttipredikaatteja entiteettityypeille: entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Nämä predikaattilausekkeet arvioidaan virrankäsittimessä jokaista entiteetin päivitystapahtumaa kohtaan; kun kaikki säännön predikaatit laukeavat ikkunan sisällä, korrelointi laukeaa.

Korrelaatiosäännöt tallennetaan deklaratiivisina määrityksinä sääntörekisteriin, eivät koodattuun logiikkaan. Tämä mahdollistaa sen, että tiedusteluanalyytikot voivat laatia uusia sääntöjä ilman insinöörityötä, ja sääntömuutokset voidaan ottaa käyttöön uudelleenjulkaisematta korrelaatiomoottoria:

# Example correlation rule definition (YAML) rule_id: RESUPPLY-PATTERN-001 name: "Vehicle resupply sequence detection" description: "Detects a vehicle visiting a logistics node followed by a fuel point within window" confidence_weight: 0.72 spatial_resolution: H3_LEVEL_8 temporal_window_minutes: 90 events: - alias: VEH entity_type: EQUIPMENT attribute_predicates: - "attributes.platform_class IN [APC, IFV, TRUCK, LOGISTICS_VEHICLE]" - alias: NODE_VISIT entity_type: EVENT attribute_predicates: - "attributes.event_class == LOCATION_VISIT" - "attributes.location_type IN [LOGISTICS_NODE, DEPOT, FUEL_POINT]" linked_entity: VEH temporal_order: AFTER VEH.last_seen output: entity_type: SITUATION situation_class: RESUPPLY_ACTIVITY contributing_entity_refs: [VEH.entity_id, NODE_VISIT.entity_id]

Jokainen laukeava korrelointi tuottaa tilanne-entiteetin — uuden tiedusteluobjektin JDL-tasolla 2, joka viittaa osallistuviin entiteetti-UUID:hin, kantaa säännön tunnuksen ja säännön luottamuspainon ja julkaistaan rikastettuun entiteettivirtaan standardien entiteettipäivitysten rinnalla.

Luottamuspisteytys ja alkuperätiedot — lähteen luotettavuus × tiedon uskottavuus -matriisi (NATO:n admiralliteettijärjestelmä), luottamuksen levittäytyminen yhdistettyihin entiteetteihin

Jokainen yhdistetyn kuvan entiteetti kantaa luottamuspisteen, mutta luottamus monilähteisessä fuusiojärjestelmässä ei ole yksi luku — se on yhdistelmä, joka on purettava useisiin ulottuvuuksiin ollakseen analyyttisesti hyödyllinen. Piste 0.73, joka on saatu kolmesta vahvistavasta SIGINT-tietueesta, tarkoittaa hyvin eri asiaa kuin piste 0.73, joka on tullut yhdestä epäluotettavasta HUMINT-raportista eikä mistään muusta. Arkkitehtuurin on säilytettävä purkaus, ei vain aggregaatti.

Luottamusmalli kerrostaa kolme syötettä. Ensinnäkin lähteen luotettavuuspaino, joka johdetaan NATO:n admiralliteetin lähteen luotettavuusarvosta: A=1.0, B=0.8, C=0.6, D=0.4, E=0.2, F=0.1. Tämä paino skaalaa kunkin lähdehavainnon panoksen fuusiolaskentaan. Toiseksi tiedon uskottavuuspaino, joka johdetaan admiralliteetin uskottavuusarvosta: 1=1.0, 2=0.8, 3=0.6, 4=0.4, 5=0.2, 6=0.1. Tätä painoa sovelletaan havaintokohtaisesti lähteen luotettavuudesta riippumatta, koska luotettava lähde voi raportoida epävarmaa tietoa. Kolmanneksi lähteiden välinen yhteensopimispiste — niiden itsenäisesti vahvistavien lähteiden osuus, jotka ovat samaa mieltä avainattribuutin arvosta, painotettuna niiden lähteen luotettavuudella. Sijaintiarvo, jonka ovat vahvistaneet kolme A-arvoista lähdettä B2-tiedoilla, saa hyvin eri pisteen kuin arvo, jonka ovat vahvistaneet kaksi E-arvoista lähdettä D4-tiedoilla.

Attribuutin yhdistetty luottamus on:

# Luottamuskaava yhdistetylle attribuutille # Jokaiselle osallistuvalle havainnolle i: # w_i = source_reliability_weight(admiralty_grade_A_to_F) # × info_credibility_weight(admiralty_grade_1_to_6) # # Painotettu yhteensopimispiste: # agreement = sum(w_i for i in corroborating sources) # / sum(w_i for i in all contributing sources) # # Fuusioluottamus: # confidence = agreement × source_coverage_penalty # # jossa source_coverage_penalty alentaa yhden INT-alan vahvistusta: # 1.0 jos ≥ 2 eri INT-tyyppiä vahvistaa # 0.75 jos täsmälleen 1 INT-tyyppi ja vähintään 2 lähdettä # 0.5 jos täsmälleen 1 lähde yhteensä

Luottamuksen levittäytyminen johdettuihin entiteetteihin noudattaa laimenemissääntöä: korrelaatiomoottorin kahdesta osallistuvan entiteetin kultaisesta tietueesta johtama tilanne-entiteetti ei voi olla korkeammalla luottamuksella kuin matalamman luottamuksen osallistuva entiteetti. Luottamus voi nousta vain, kun osallistuviin entiteetteihin lisätään itsenäisiä vahvistavia havaintoja. Tämä estää korrelaatiomoottorin keinotekoisesti korottamasta luottamusta yhdistämällä heikkolaatuisia entiteettejä.

Alkuperälinkit tallennetaan ketjuna: jokainen kultainen tietue viittaa niihin havainto-UUID:hin, jotka ovat vaikuttaneet siihen; jokainen havainto viittaa lähdetunnukseensa, keräysjärjestelmäänsä ja admiralty-arvoihinsa. Ketju on muuttumaton — sitä ei koskaan päivitetä paikallaan. Kun osallistuva lähde myöhemmin arvioidaan epäluotettavaksi tai harhauttavaksi, ketju tarjoaa sen entiteettien täydellisen joukon, jotka on arvioitava uudelleen kyseisen lähteen panokset pois lukien. Lähteen peruuttaminen on ensisijainen toimenpide, ei hätämenettely.

Tiedustelukuvan julkaisu — rikastettujen entiteettien julkaisu C2-järjestelmiin CoT/NIEM-muodossa, viivekohteet aikakriittiselle tiedustelulle

Rikastettu entiteettivirta on sisäinen esitystapa. Julkaisu muuntaa tämän esitystavan johtoformaateiksi, joita C2-järjestelmät ja alavirran kuluttajat todella ymmärtävät. Useimmissa puolustuksen käyttöönotoissa tämä tarkoittaa Cursor on Target (CoT) -muotoa reittitiedoille ja NIEM-pohjaisia viestimuotoja rakennetuille tiedusteluraporteille.

CoT-julkaisu kuvaa jokaisen rikastetun entiteetin päivityksen CoT-tapahtumaksi. Kuvauksen on käsiteltävä kolmea päivitystyyppiä: sijaintipäivitykset (uudet koordinaatit päivitetyllä epävarmuudella), attribuuttipäivitykset (luottamuksen muutos, toimintatilan muutos, liittouma-arvion muutos) ja entiteetin elinkaaritapahtumat (entiteetin luonti, poisto ja jako/yhdistäminen). Sijaintipäivitykset ovat suoraviivaisia — ne kääntyvät CoT-pistetapahtumaksi, jossa on entiteetin arvioitu sijainti ja sijaintiluottamus koodattuna CoT-virhekenttään. Attribuuttipäivitykset kääntyvät CoT-huomioiksi tai yksityiskohtaelementin päivityksiksi olemassa olevaan entiteettiin. Elkaaritapahtumat — erityisesti yhdistäminen ja jako — vaativat erityiskäsittelyä: yhdistämistapahtuma poistaa matalamman luottamuksen entiteetin CoT-reitin ja päivittää säilyvän entiteetin CoT-yksityiskohdat alkuperätiedoilla; jakotapahtuma luo uuden CoT-reitin juuri erkaantuneelle entiteetille.

CoT:n vanhentumisaika-kenttä on luonnollinen mekanismi TTL-hallintaan C2-vastaanottajalla. Jokainen julkaistu CoT-tapahtuma asettaa stale_time-arvoksi entity_publication_time + entity_TTL. Vastaanottava C2-järjestelmä (ATAK, CURSOR tai vastaava) poistaa entiteetin näytöltään, kun stale_time ylittyy ilman päivitystä. Fuusiojärjestelmän on varmistettava, että entiteetit, joilla on aktiivisia havaintoja, saavat CoT-päivitystapahtumia lyhyemmällä väleillä kuin TTL:llään — tyypillisesti 50 % TTL:stä — jotta kelvolliset entiteetit eivät katoaisi kuvasta normaalitoiminnan aikana.

Viivekohteet määrittävät, miten julkaisukerros on toteutettava. Aikakriittisissä kohdennustyönkulkuissa viiveen tapahtumasta sensorista C2-näytölle on oltava alle 30 sekuntia. Tämän saavuttaminen edellyttää: asynkronisia, ei-lukitsevia julkaisutyöntekijöitä; rinnakkain ajettua CoT-serialisointia entiteettiosituksissa; priorisoituja tulostusjonoja, jotka antavat etusijan korkean luottamuksen liikkuville reiteille staattisiin entiteettipäivityksiin nähden; ja suoraa TCP-multicast-lähetystä C2-vastaanottajille REST API -kyselyiden sijaan. Operatiivisen tason yleiseen tilannekuvaan 60–120 sekunnin viive on tyypillisesti hyväksyttävä, mikä mahdollistaa yksinkertaisemmat synkroniset eräjulkaisumallit.

NIEM-julkaisu palvelee tiedusteluraporttien kuluttajia — järjestelmiä, jotka tarvitsevat rakennettua, koneellisesti luettavaa tiedusteluarviota reittitietojen sijaan. Korrelaatiomoottorin tuottama tilanne-entiteetti julkaistaan NIEM Intelligence Message -viestinä, jossa osallistuvat entiteetti-UUID:t ovat viitteitä, tilaneluokka aiheena ja luottamus- ja alkuperätiedot NIEM-viestin metadatablokissa. NIEM-kuluttajiin kuuluvat monialaiset tiedustelunjakojärjestelmät, yhteentoimivuuden yhdyskäytävät kumppanimaiden järjestelmiin ja arkistojärjestelmät, jotka vaativat rakennettuja alkuperätietoja auditointivaatimusten täyttämiseksi.

Ajallisen epävarmuuden ja vanhentuneen tiedustelun käsittely — TTL-hallinta tiedustelu-entiteeteille, heikkenemiskäyrät sijainti-/toimintaluottamukselle, uudelleenarvioinnin laukaisimet

Tiedustelu on herkkää. Ajoneuvoreitin sijaintiraportti, joka oli tarkka 20 minuuttia sitten, on sitä nyt vähemmän — ajoneuvo on voinut liikkua. Yhteen SIGINT-kuunteluun 4 tuntia sitten perustuva toiminta-arvio ei välttämättä enää vastaa nykykäyttäytymistä. Fuusiojärjestelmä, joka ei mallinna tätä heikkenemistä eikä levitä sitä julkaistuun kuvaan, saa analyytikot tekemään päätöksiä vanhentuneen tiedon pohjalta korkeilla luottamuspisteillä, jotka on ansaittu vanhemmilla havainnoilla.

TTL-hallinta alkaa TTL:n asettamisesta entiteetin luonnissa. TTL-arvot ovat entiteettityyppi- ja luottamustasokohtaisia:

  • Korkean luottamuksen liikkuva ajoneuvoreitti (luottamus ≥ 0.80, liikkuvuusluokka = WHEELED/TRACKED): TTL 8–15 minuuttia
  • Keskitason liikkuva reitti (luottamus 0.50–0.79): TTL 4–8 minuuttia
  • Matalan luottamuksen alustava reitti (luottamus < 0.50): TTL 2–4 minuuttia
  • Korkean luottamuksen kiinteä kohde (luottamus ≥ 0.80, liikkuvuusluokka = STATIC): TTL 24–72 tuntia
  • Henkilöstöentiteetti (toimintapohjainen, ei sijaintipohjainen): TTL 30–120 minuuttia viimeisimmän toimintatyypin mukaan
  • Tilanne-entiteetti (johdettu korrelointi): TTL yhtä suuri kuin lyhin osallistuvan entiteetin TTL, enintään 60 minuuttia

Luottamuksen heikkenemiskäyrät mallintavat, miten sijainti- ja toimintaluottamus heikkenevät vahvistavien havaintojen välillä. Binaarisen aktiivinen/vanhentunut -tilan sijaan heikkenemiskäyrä antaa jatkuvan luottamusfunktion ajasta viimeisestä havainnosta:

# Sijaintiluottamuksen heikkeneminen — eksponentiaalinen malli # c(t) = c_0 × exp(-λ × t) # jossa: # c_0 = luottamus viimeisen vahvistavan havainnon hetkellä # t = kulunut aika viimeisestä havainnosta (sekuntia) # λ = heikkenemisvakio, entiteettityyppikohtainen # # Heikkenemisvakiot (esimerkkimäärä): # TRACKED_VEHICLE: λ = 0.003 (puoliintumisaika ≈ 3.8 min) # WHEELED_VEHICLE: λ = 0.004 (puoliintumisaika ≈ 2.9 min) # SLOW_MOVER: λ = 0.001 (puoliintumisaika ≈ 11.5 min) # STATIC_SITE: λ = 0.00001 (puoliintumisaika ≈ 19 tuntia) # MARITIME_SURFACE: λ = 0.002 (puoliintumisaika ≈ 5.8 min) # # Entiteetti siirtyy tilaan STALE, kun c(t) < staleness_threshold # (tyypillisesti 0.15 liikkuville reiteille, 0.05 staattisille kohteille)

Uudelleenarvioinnin laukaisimet laukeavat, kun uusi havainto saapuu ja on paikallisesti ja ajallisesti yhteensopiva vanhentuneen entiteetin kanssa. Uuden havainnon luomisen sijaan uudelleen laukaisin ohjaa sen entiteettien ratkaisuputkeen ehdokkaana vanhentunutta entiteettiä vasten. Jos osumaluottamus ylittää yhdistämiskynnyksen, uusi havainto virkistää vanhentuneen entiteetin: TTL-kello nollautuu, luottamus lasketaan uudelleen uudesta havainnosta (mahdollisesti ylöspäin heikentyneestä arvosta, jos uusi havainto on vahva), ja entiteetti siirtyy takaisin tilasta STALE tilaan ACTIVE. Virkistys kirjataan päivitystapahtumaksi entiteetin auditointiketjuun.

Heikkenemismalli on myös välitettävä C2-kuluttajille, ei vain sovelletta sisäisesti. Korkean luottamuksen sijainnin julkaiseminen CoT-muodossa ilman signaalia siitä, että sijainti on 18 minuuttia vanha, saa C2-näytön näyttämään terävän, luotetun reittikuvakkeen, jonka analyytikko voi tulkita reaaliaikaiseksi havainnoksi. Kaksi mekanismia käsittelee tätä: CoT:n stale_time-kenttä (jo käsitelty) varmistaa, että entiteetti katoaa näytöltä, kun se on ehdottomasti vanhentunut; ja CoT-yksityiskohtaelementissä julkaistu aika viimeisestä havainnosta -kenttä antaa analyytikolle reaaliaikaisen näkymän siihen, kuinka vanha taustalla oleva havainto on, myös entiteeteille, jotka eivät ole vielä saavuttaneet vanhentumisaikaansa. Jotkin C2-järjestelmät käyttävät tätä kenttää visuaalisen luottamuksen esityksen säätämiseen — reittikuvakkeen läpinäkyvyyden tai koon muuttamiseen havainnon iän funktiona.

Yhdessä tässä artikkelissa kuvatut seitsemän arkkitehtonista komponenttia — heterogeinen virran vastaanotto, skeemapakotettu normalisointi, esto- ja ML-pohjainen entiteettien ratkaisu, monitasoinen korrelaatiomoottori, kerrostettu luottamuspisteytys, CoT/NIEM-julkaisu ja TTL-heikkenemisen hallinta — muodostavat kokonaisen reaaliaikaisen monilähteisen tiedustelufuusioalustan. Mikään näistä komponenteista ei ole itsenäisesti uutta. Tuotantotasoiseksi arkkitehtuurin tekee niiden välisten rajapintojen nimenomainen suunnittelu: kanoninen havaintoskeema, jonka normalisointi tuottaa ja entiteettien ratkaisu kuluttaa; entiteettigraafin muoto, jonka entiteettien ratkaisu tuottaa ja korrelaatiomoottori kuluttaa; rikastettu entiteettivirta, johon sekä entiteettien ratkaisu että korrelaatiomoottori kirjoittavat ja jota julkaisukerros lukee. Järjestelmä, jossa nämä rajapinnat ovat epäselviä tai dokumentoimattomia — jossa jokainen komponentti olettaa tietyn käyttäytymisen ylävirraltaan — on hauras juuri niissä kohdissa, joissa tiedusteludata on luonteeltaan vaihtelevinta.