Een defensie-fusiepijplijn bouwen, deel 2: spoorCorrelatie en levenscyclusbeheer

Deel 1 liet de pijplijn achter met een stroom van canonieke spoorobservaties op de berichtenbus. Elke observatie is een geïsoleerd atoom — "bron X meldt object op positie Y met snelheid Z op tijdstip T". De taak van de fusie-engine is te bepalen welke observaties verwijzen naar hetzelfde fysieke object, ze te accumuleren in stabiele tracks met groeiende identiteitszekerheid, de levenscyclus te beheren wanneer observaties ophouden of nieuwe arriveren, en een opvraagbare kijk op de wereld bloot te stellen aan de COP en downstreamconsumenten. Deel 2 gaat over het bouwen van die engine.

De conceptuele referentie is Militaire gegevensfusie uitgelegd voor het disciplineoverzicht, het JDL-gegevensfusiemodel voor de niveaumapping, en de pilaarartikelen Volledige gids voor defensie-gegevensfusie voor het bredere architectuurkader.

Stap 1: het tweeledige correlatiefilter

De kernbeslissing van de fusie-engine — of een binnenkomende observatie een update van een bestaande track is of de geboorte van een nieuwe — hoeft niet met één algoritme te worden genomen. Het patroon dat in productie schaalt, gebruikt twee fasen: een goedkoop regelgebaseerd filter dat de gemakkelijke gevallen afhandelt, en een probabilistische associatie-engine die alleen wordt aangeroepen wanneer de regellaag dubbelzinnig is.

De regelgebaseerde fase behandelt de 90% observaties die ondubbelzinnig zijn. Voor elke binnenkomende observatie berekent het de verzameling kandidaat-bestaande tracks binnen kinematisch bereik — een positie-tijdpoort. Identiteitsvooroordelen filteren verder: een observatie getagd als "vaartuig" kan niet overeenkomen met een "vliegtuig"-track. Broncompatibiliteitsregels filteren ook: een observatie van een grondradar kan niet overeenkomen met een luchttrack van een onderwater platform. Wanneer de poort precies één kandidaat oplevert die de identiteits- en bronregels doorstaat, werkt de observatie die kandidaat direct bij. Wanneer de poort nul kandidaten oplevert, initieert de observatie een tentatieve nieuwe track. Goedkoop, snel, verklaarbaar.

De probabilistische fase wordt aangeroepen wanneer de regellaag meerdere kandidaten teruggeeft of wanneer de trackdichtheid hoog genoeg is dat betrouwbare poortvorming onmogelijk is. Joint Probabilistic Data Association (JPDA) berekent de kans dat een observatie bij elke kandidaattrack hoort en werkt elke track bij gewogen naar kans. Multiple Hypothesis Tracking (MHT) handhaaft meerdere trackhypothesen over observaties, waardoor associatiebeslissingen worden uitgesteld totdat voldoende bewijs is verzameld. Beide zijn computationeel zwaarder en moeilijker af te stemmen; beide zijn alleen correct voor de gevallen waarin de regellaag het fout had om te committen.

Een specifieke valkuil die het vermelden waard is: MHT genereert een exponentieel aantal hypothesen zonder snoei. Het snoeibeleid — hoeveel hypothesen te bewaren, wanneer samen te voegen, wanneer te verwijderen — is belangrijker dan het kernalgoritme. Standaard naar agressief snoeien; alleen naar buiten bijstellen wanneer operationeel bewijs dit vereist.

Stap 2: de regellaag afstemmen

De regellaag is waar de meeste fusietechnische inspanning terechtkomt. Het algoritme is eenvoudig; het afstemmen is vakmanschap.

De poortparameters die er toe doen:

• Kinematische poortgrootte — hoe ver een observatie van de voorspelde positie van de track kan zijn om nog steeds overeen te komen. Te klein mist echte updates na sensorstoring; te groot produceert valse correlaties in drukke scenario's.
• Identiteitspoort — welke identiteitsattributen moeten overeenkomen (altijd: type-taxonomie; soms: subtype, roepnummer, roepnaam).
• Bronsetregels — welke bronnen welke tracktypen kunnen bijwerken. Domeinspecifiek (een maritieme radar mag een onderwater track niet bijwerken) en platformspecifiek (een SIGINT-alleen-peilingcontact mag niet associëren met een kinematische track zonder peilingovereenkomst).
• Tolerantie voor tijd-sinds-laatste-update — observaties voor tracks die te lang stil zijn geweest, produceren een nieuwe tentatieve track in plaats van opnieuw te associëren met de oude.

Standaardwaarden komen van de nauwkeurigheids- en latentieprofielen van de broncatalogus. Operationeel afstemmen komt van herhaling op vastgelegde gegevens, met statistieken over valse-correlatieratio en miss-associatieratio. Aanbestedingsklasse fusie-engines hebben deze afstemknoppen beschikbaar voor het operationele team om per implementatie aan te passen; op maat gemaakte programma's hardcoderen de waarden vaak en spijten hiervan wanneer de implementatiecontext verandert.

Stap 3: wanneer en hoe probabilistische associatie te gebruiken

Probabilistische associatie is het juiste middel wanneer regelgebaseerde poortvorming geen betrouwbare enkelvoudige overeenkomst kan produceren. Het signaal dat probabilistisch nodig is: de poort geeft meer dan één kandidaat terug bij een percentage boven (zeg) 5% in het operationele scenario.

Het pragmatische aanroepatroon:

JPDA voor matige dichtheid. Wanneer de poort 2-4 kandidaten per dubbelzinnige observatie teruggeeft, berekent JPDA associatiekansen met kinematische vooroordelen (Mahalanobis-afstand van voorspelde positie) en identiteitsvooroordelen. Trackupdates worden gewogen naar de kans; geen enkele track krijgt een "definitieve" update, maar de meest waarschijnlijke kandidaten verzamelen het bewijs sneller.

MHT voor de moeilijkste gevallen. Wanneer de poort veel kandidaten teruggeeft en associatiedubbelzinnigheid aanhoudt over observaties, stelt MHT de beslissing uit. Het handhaaft hypothesen (alternatieve interpretaties van welke observatie bij welke track hoort) en snoeit op kans. Na meerdere observaties komt de dominante hypothese naar voren en worden de andere verwijderd.

Gecombineerde uitvoer. Beide algoritmen produceren updates die terugvloeien naar dezelfde trackopslag als regelgebaseerde updates. Vanuit het perspectief van downstreamconsumenten zien alle updates er identiek uit; het verschil zit in de zekerheids- en herkomstmetadata die eraan is gekoppeld.

De implementatierealiteit: goed geteste open-source-bibliotheken bestaan voor zowel JPDA als MHT (Stone Soup, FilterPy en aanverwante tools). De meeste operationele fusie-engines omhullen een getest bibliotheek in plaats van het van scratch te implementeren. De technische inspanning zit in de integratie, het afstemmen en de operationele hardening — niet in het algoritme.

Stap 4: de levenscyclus-toestandsmachine van de track

Tracks hebben levenscycli. De toestandsmachine die ze bestuurt, is een van de meest operationeel consequente beslissingen van het platform: operators tolereren ontbrekende tracks, maar tolereren geen met vertrouwen weergegeven verouderde tracks. De levenscyclus is de grens tussen betrouwbare en onbetrouwbare weergave.

De toestandsmachine voor het lopende voorbeeld:

• Tentatief. Eerste observatie; wacht op bevestiging. Niet weergegeven in de operationele COP tenzij een operator expliciet om lage-zekerheidsweergave verzoekt. Vervalt naar verwijderd als er geen opvolging is binnen een configureerbaar venster.
• Bevestigd. Twee of meer gecorreleerde observaties binnen het kinematisch-consistentievenster. Bevorderd vanuit tentatief. De standaardstatus voor weergegeven tracks.
• Volwassen. Bevestigd en persistent voor ten minste N minuten met consistente updates. Gebruikt door downstreamanalytics die stabiele identiteit nodig hebben voor patroon-van-leven- of gedragsanalyse.
• Vervagend. Geen update binnen het verwachte revisit-interval voor deze bronklasse. Weergave gemarkeerd als verouderd (dimmersymbool, leeftijdindicator). Configureerbaar per bronklasse — een 30 seconden oud maritieme track is prima; een 30 seconden oud luchttrack vervagt.
• Verloren. Geen update voor een langere periode. Verwijderd uit actieve weergave maar bewaard in de trackopslag voor audit en historische analyse.

De overgangen zijn tijdgebaseerd en updategebaseerd, waarbij beide een enkele beslissingsboom voeden. Elke overgang wordt gelogd met de triggergebeurtenis (observatie-update, time-out-verval, operatoroverschrijving). Het overgangslogboek voedt het event-sourced audittraject behandeld in Event Sourcing voor defensie-audittrails.

Een praktisch detail: de levenscyclusservice is een apart proces van de correlatie-engine. Het abonneert op track-update-events van correlatie, berekent levenscyclusovergangen en publiceert ze als een aparte stroom op de bus. Ontkoppeling laat het levenscyclusbeleid evolueren zonder de correlatie-engine aan te raken.

Stap 5: de trackopslag als event-sourced leesmodel

Fusie produceert een stroom van trackupdates en levenscyclusovergangen. De trackopslag is de gematerialiseerde weergave: de huidige status van elke actieve track, opvraagbaar door de COP, door analytics en door externe API's. De architectuurbeslissing die vroeg de moeite waard is, is dat de trackopslag een leesmodel is, geen autoritatieve bron. De autoritatieve bron is het gebeurtenislogboek op de berichtenbus. De trackopslag wordt herbouwd vanuit het logboek op aanvraag.

De voordelen van dit patroon:

Wissen en herbouwen. De opslag kan worden gewist en herbouwd vanuit het logboek zonder gegevensverlies. Schema-migraties, prestatieoptimalisatie en herstel van beschadigde gegevens worden allemaal routine in plaats van riskant.

Meerdere leesmodellen. Een COP-geoptimaliseerd leesmodel (geospatiaal geïndexeerd, hot-track-cache, lage-latentie-leesbewerkingen) bestaat naast een analytics-geoptimaliseerd model (gedenormaliseerd, batchvriendelijk) en een extern-API-model (gefilterd, ingedeeld per consument). Alle zijn projecties van dezelfde onderliggende gebeurtenisstroom.

Tijdreisquery's. "Wat geloofde het platform om 14:32?" wordt triviaal: speel het logboek opnieuw af tot 14:32 tegen een nieuwe projectie. Nabeschouwingen, trainingen en accreditatieaudits profiteren allemaal.

De implementatie: PostgreSQL met PostGIS-extensie voor geospatiale query's (standaard voor het lopende voorbeeld). Een Redis-laag ervoor voor sub-milliseconde hot-track-leesbewerkingen op het COP-kritieke pad. De relationele opslag behandelt query's met een langere staart en persistentiegaranties. De gedetailleerde technische weergave, inclusief de indexeringsstrategieën die schalen naar miljarden punten, staat in PostGIS voor defensie-geospatiale gegevens.

Stap 6: weersta de graafDatabase (voorlopig)

Een voorspelbare verleiding in fusieontwerp is het toevoegen van een graafDatabase "voor relaties". Konvooidetectie, formatieerkenning, contactnetwerken — deze klinken allemaal graafvormig. De verleiding is ze te modelleren in Neo4j of equivalent en "natuurlijke" relatiequery's te krijgen.

De pragmatische tegenstelling: relaties tussen tracks zijn JDL-niveau 2-fusie, een afzonderlijke zorg van niveau 1-trackonderhoud. Bouw eerst niveau 1, draai het een jaar in operaties en herzie niveau 2 daarna pas met operationeel bewijs. De niveau 2-relaties blijken vaak een andere vorm nodig te hebben dan de graafDatabase-intuïtie voorspelde — temporeel-relationeel in plaats van puur topologisch, classificatiebewust in plaats van open, uitgedrukt op een hoger abstractieniveau dan per-track-kanten.

De platforms die slagen, beginnen met PostGIS + Redis voor het leesmodel, bewijzen fusie op niveau 1 en voegen niveau 2-mogelijkheden toe als afzonderlijke services die dezelfde gebeurtenisstroom consumeren. De platforms die falen, voegen de graafDatabase in week één toe en brengen twee jaar door met het debuggen van de onjuiste abstractie.

Stap 7: test de fusie-engine tegen de realiteit

Een fusie-engine die alleen met speelgoedlading is getest, slaagt voor integratietests en faalt in operaties. De disciplines die problemen vangen vóór implementatie:

Herhaalbare testharnesses. Vastgelegde sensorsporen van echte operaties, opnieuw afgespeeld op volledig tempo en versneld tempo tegen de fusie-engine. De sporen zijn de regressietestsuite: elke algoritme- of schemawijziging moet equivalente of betere resultaten produceren, niet alleen op synthetische lading.

Trackkwaliteitsstatistieken in CI. Valse-correlatieratio, miss-associatieratio, trackfragmentatieratio, tijdstip van levenscyclusovergang. Elke statistiek bijgehouden in de loop van de tijd; regressies blokkeren de release. De statistieken worden geëvalueerd tegen de herhaalsporen, niet tegen synthetische lading.

Testen van adversariale scenario's. Vervalste AIS-berichten met onplausibele kinematica. Radarplots die de fysica schenden. Uitval van bronnen op kritieke momenten. De fusie-engine moet gracieus degraderen bij slechte invoer — niet crashen, geen betrouwbare-maar-onjuiste tracks produceren. Het bredere technische patroon voor adversariale robuustheid in defensie staat in Testen van missionkritische C2-systemen.

Belasting- en piektest. 95e-percentiel fusielatentie onder 500 ms bij 10.000 observaties/seconde; 99e-percentiel onder 1,5 s. Gedurende de duur van een operationele rotatie, niet alleen voor de marketingbenchmark. Het platform moet een CPU-kopruimte van enkele procenten hebben voor piekverwerking.

Wat volgt

Deel 2 heeft de engine gebouwd. Tweeledige correlatie behandelt de eenvoudige en moeilijke gevallen. De levenscyclus-toestandsmachine toont versheid aan operators. De trackopslag als event-sourced leesmodel ondersteunt query's zonder een autoritatieve bron te worden. De testdisciplines valideren de laag tegen de realiteit.

Deel 3 gaat dieper in op het multi-INT-geval — het combineren van SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT in dezelfde fusiestroom terwijl hun semantische verschillen worden bewaard — en pakt de classificatie- en vrijgaveverspreiding aan die defensiefusie uniek vereist.