Deel 1 koos een reikwijdte, stelde de vierlaagse architectuur vast en ontwierp het canonieke spoorschema. Deel 2 bouwt de engine die sensorrapporten omzet in betrouwbare sporen: adapters die bronnen inbrengen, de correlatiealgoritmen die bepalen welke rapporten naar hetzelfde fysieke object verwijzen, levenscyclusbeheer dat de COP vertelt wanneer een spoor verouderd is, en de spooropslag die alles verankert. Aan het einde van Deel 2 produceert het platform operationeel bruikbare sporen — maar er is nog geen weergave voor beschikbaar.

De conceptuele referentie voor alles in Deel 2 is De Complete Gids voor Defensie Data-Fusie, die het vakgebied in kaart brengt. Hier nemen we specifieke beslissingen voor het lopende voorbeeldplatform.

Stap 1: Het Adapterpatroon, Strikt Toegepast

Elke sensor produceert data in een eigen formaat. Radars spreken ASTERIX; UAV's spreken STANAG 4586; AIS-ontvangers zenden NMEA 0183 uit; ATAK-clients spreken CoT; civiele ADS-B-feeds zenden een ander binair protocol uit; handmatig gemelde waarnemingen komen binnen via een webformulier. De taak van de adapterlaag is al deze formaten te vertalen naar het canonieke spoorschema dat in Deel 1 is gedefinieerd.

De regel is onontkoombaar en verdient inslijping: geen sensor-specifiek concept lekt voorbij de adapter. Als uw fusie-engine-code verwijst naar ASTERIX-categorieën, heeft u een lekkende architectuur. Als uw spooropslag een kolom heeft voor AIS-berichttypen, heeft u een lekkende architectuur. Adapters zijn eenrichtings-dataconverters met strikte isolatie; zij stellen alleen canonieke sporen beschikbaar aan de bovenstroom.

De pragmatische adapterstructuur voor elke bron:

  • Transport — de connector naar de bron (UDP-socket, MQTT-abonnement, HTTP-webhook, bestandswatcher). Veerkrachtig bij bronzijdige storingen: herverbindingen, exponentiële wachttijd, registratie van verloren berichten.
  • Parser — vertaalt het draadformaat naar een sterk getypeerde in-process structuur. Valideert tegen de formaatspecificatie. Verwerpt misvormd invoer luidruchtig in plaats van stilzwijgend.
  • Normalisator — koppelt bronspecifieke velden aan canonieke velden. Coördinatenstelselconversie (doorgaans naar WGS84). Tijdstempelnormalisatie (UTC, met de drie-tijdstempel-discipline uit Deel 1).
  • Emitter — publiceert de canonieke spoorwijziging naar de berichtbus. Voorzien van bronidentificatie, bronclassificatie en vrijgavebaarheid.

Elke adapter is een afzonderlijke service of proces. Ze delen een codegegenereerde clientbibliotheek voor het canonieke schema, maar geen andere codetrajecten. Het toevoegen van een nieuw sensortype betekent het schrijven van een nieuwe adapter, niet het aanraken van andere componenten. De gedetailleerde integratiepatronen voor de gangbare bronnen zijn te vinden in AIS en ADS-B integreren in een Militair Beeld en de CoT-zijde in Cursor on Target (CoT): De XML-standaard achter Tactische Bewustzijnsapplicaties.

Stap 2: De Berichtbus Aansluiten

Adapters publiceren naar een duurzaam, geordend, gepartitioneerd logboek. Fusiediensten consumeren daarvan. Dat geldt ook voor de auditdienst, de historische-herhalingsservice en alle stroomafwaartse analyses. De berichtbus is het ruggemerg van het platform.

Voor het lopende voorbeeld gebruiken we Kafka met één topic per brontype en aanvullende topics voor fusie-uitvoer. Adapters publiceren naar raw.brontype; de fusie-engine consumeert die en publiceert naar tracks.updates en tracks.lifecycle. Audit abonneert zich op alles. Het buspatroon, inclusief de doorvoer- en duurzaamheidsafwegingen, staat in Berichtwachtrijen voor Defensie Data-pijplijnen.

De architectuurbeslissing die aandacht verdient: geen HTTP-aanroepen tussen fusiecomponenten. Synchrone aanvraag-antwoordkoppeling maakt een fusiepijplijn breekbaar. Een sensorgolf die één consument stopt, mag niet elke bovenstroom producent stoppen. De bus met tegendruk is de structurele oplossing; HTTP tussen fusiecomponenten is een terugkerende bron van uitval.

Stap 3: Spoor-naar-Spoor-Correlatie

De kern van de fusie-engine is het algoritme dat beslist of een binnenkomend rapport een bijwerking is van een bestaand spoor of de geboorte van een nieuw spoor. Fout gaan hierin leidt ertoe dat de operator een spoorbrei ziet (duizend symbolen waar er honderd zouden moeten zijn) of spooksporen (duplicaten die samengevoegd hadden moeten worden). Het goed doen maakt de COP betrouwbaar.

Het pragmatische patroon gebruikt een tweetraps filter.

Fase 1: regelgebaseerde filtering. Bereken voor elk binnenkomend rapport de set kandidaat-bestaande sporen binnen kinematisch bereik — een positie-tijdpoort die zegt "een spoor dat maximaal V m/s beweegt, kon van zijn laatste bekende positie naar de positie van dit rapport bewegen in dit tijdsinterval". Identiteitsvoorkennis filtert verder: een rapport met het label "vaartuig" kan niet overeenkomen met een "luchtvaartuig"-spoor. Broncompatibiliteitsfilters: een rapport van een grondradar kan niet overeenkomen met een luchtvaartuigspoor van een onderwaterplatform. De regelgebaseerde fase verwerkt 90% van de invoer goedkoop en eenduidig.

Fase 2: probabilistische associatie. Voor de betwiste gevallen — meerdere kandidaten binnen de poort, dubbelzinnige identiteit, dichte scenario's met kruisende trajecten — activeer probabilistische data-associatie. Joint Probabilistic Data Association (JPDA) voor matige dichtheid; Multiple Hypothesis Tracking (MHT) voor de moeilijkste gevallen. Beide berekenen een waarschijnlijkheid dat een binnenkomend rapport tot elk kandidaatspoor behoort en werken sporen bij gewogen naar die waarschijnlijkheid.

Het volledige theoretische model met technische implicaties staat in Het JDL Data-Fusiemodel: een Praktische Technische Referentie. De technische nuances van wanneer elke techniek van toepassing is, en de vereiste afstelling, staan in Militaire Data-Fusie Uitgelegd.

Een specifieke valkuil die vermelding verdient: MHT genereert een exponentieel aantal hypothesen zonder snoeien. Het snoeisbeleid — hoeveel hypothesen te bewaren, wanneer samen te voegen, wanneer te verwijderen — is belangrijker dan het kernalgoritme. Standaard agressief snoeien; alleen uitbreiden wanneer het dreigingsbeeld dat vereist.

Stap 4: Levenscyclusbeheer van Sporen

Een spoor is geen statisch record. Het wordt geboren, bevestigd, veroudert, vervaagt en sterft. De fusie-engine beheert de levenscyclus expliciet; de COP toont de levenscyclusstatus zodat operators weten welke sporen ze kunnen vertrouwen.

De toestandsmachine voor het lopende voorbeeld:

  • Voorlopig — eerste waarneming; nog niet weergegeven in de operationele COP tenzij expliciet gevraagd. Vervalt tot verwijderd als er geen opvolging is binnen een configureerbaar tijdvenster.
  • Bevestigd — twee of meer gecorreleerde rapporten, kinematische consistentie houdt stand. Gepromoveerd vanuit voorlopig. Dit is de standaardstatus voor weergegeven sporen.
  • Volwassen — bevestigd en persistent voor ten minste N minuten met consistente bijwerkingen. Gebruikt door stroomafwaartse analyses die een stabiele identiteit nodig hebben.
  • Vervagend — geen bijwerking binnen het verwachte revisitinterval. Weergave gemarkeerd als verouderd. Configureerbaar per bronklasse (een maritiem spoor van 30 seconden oud is prima; een luchtspoor van 30 seconden oud is vervagend).
  • Verloren — geen bijwerking gedurende een langere periode. Verwijderd uit actieve weergave, maar bewaard in de spooropslag voor audit en historische analyse.

Elke toestandsovergang wordt gelogd. De auditdienst consumeert de overgangsstroom en schrijft onveranderlijke records — het onderwerp van Event Sourcing voor Defensie Auditsporen. De overgangen worden ook op de bus gepubliceerd zodat de COP de levenscyclusstatus kan weergeven zonder polling.

Kernervaring: Operators tolereren een ontbrekend spoor. Ze tolereren geen vol vertrouwen weergegeven verouderd spoor. Levenscyclusbeheer is de laag die het verschil maakt. Bouw het voordat het fusiealgoritme volledig is afgesteld — het is goedkoop en betaalt zich terug elke keer dat een sensorverbinding wegvalt.

Stap 5: De Gezaghebbende Spooropslag

Fusie produceert een stroom spoorbijwerkingen en levenscyclusovergangen. De spooropslag is de gematerialiseerde weergave: de huidige toestand van elk actief spoor, bevraagbaar door de COP en analyses. De architectuurbeslissing die vroeg gemaakt moet worden: de spooropslag is een leesmodel, geen gezaghebbende bron. De gezaghebbende bron is het gebeurtenislogboek op de berichtbus. De spooropslag wordt op verzoek opnieuw opgebouwd vanuit het logboek.

Dit patroon — ereignisgebaseerde toestand met leesmodelprojecties — heeft drie operationele voordelen. De opslag kan worden gewist en opnieuw opgebouwd zonder dataverlies. Meerdere leesmodellen met verschillende vormen kunnen naast elkaar bestaan (één voor de COP, één voor analyses, één voor een externe API). Tijdreisquery's worden triviaal: speel het logboek opnieuw af tot een gekozen tijdstip om te reconstrueren wat het platform toen geloofde.

De opslag zelf is PostgreSQL met PostGIS voor geospatiale indexering. Actieve sporen leven in het geheugen of een Redis-laag voor PostgreSQL voor sub-milliseconde leestijden; de relationele opslag handelt langstaartvragen en persistentiegaranties af. De gedetailleerde technische weergave staat in PostGIS voor Defensie Geospatiale Data.

Weersta de drang om een grafendatabase toe te voegen "voor relaties". Relaties tussen sporen — convooidetectie, formaatherkenning, contactnetwerken — zijn JDL Niveau 2-fusie, een afzonderlijk vraagstuk van Niveau 1-spoorbeheer. Bouw eerst Niveau 1, draai het een jaar in operaties, bekijk dan Niveau 2 opnieuw met de operationele bewijslast in handen.

Stap 6: Testen met Realistische Invoer

Een fusie-engine die alleen getest is met speelgoedbelasting doorstaat integratietest en faalt in operaties. De disciplines die problemen opsporen vóór uitrol:

Testopstellingen met herhalingen. Leg echte sensorsporen vast in ontwikkeling en speel ze op volledige snelheid opnieuw af tegen de fusie-engine. De sporen dienen als regressietestsuite: een nieuw algoritme of schemawijziging moet gelijkwaardige of betere resultaten produceren op de bestaande sporen, niet alleen op synthetische belasting.

Vijandige invoer. Vervalste AIS-berichten met onplausibele kinematica. Misvormd CoT-XML. Radarplots die de fysica schenden (Mach 5 grondsporen). De fusie-engine moet deze afwijzen of markeren, niet in paniek raken, niet crashen, geen vol vertrouwen maar foutieve sporen produceren. De discipline is gelijk aan de bredere testdiscipline in Testen van Missiekritieke C2-Systemen.

Gedragspatroondetectie. Zodra de basisfusie werkt, laag PoL-analyses bovenop — zie Gedragspatroonanalyse in Militaire Inlichting. De PoL-service consumeert dezelfde bustopics; ze produceert verrijkte spoorstatusannotaties in plaats van te concurreren met de fusie-engine.

Stap 7: Prestatiedoelstellingen en Vrije Capaciteit

Fusielatentie heeft operationele gevolgen. Doelstellingen voor het lopende voorbeeldplatform: 95e-percentiel end-to-end fusielatentie onder 500 ms (sensorrapport ingest tot spoorwijzigingsbericht op de bus); 99e percentiel onder 1,5 s; doorvoer gehandhaafd op 10.000 rapporten per seconde met eencijferig CPU-overcapaciteitspercentage.

Dit zijn tactische-brigadedoelstellingen. Strategische platforms hebben ruimere latentietoleranties en hogere doorvoerplafonds. De doelstellingen sturen architectuurbeslissingen: vermijd synchrone cross-service aanroepen op het kritieke pad; pre-alloceer actieve-spoorstatus; batch alleen waar de bus het toelaat; instrumenteer elke fase van de pijplijn zodat latentieregressies zichtbaar worden in CI in plaats van in operaties.

Wat Volgt

Deel 2 heeft de engine gebouwd. Sensoradapters converteren naar canonieke sporen; de berichtbus draagt de gebeurtenissen; de fusie-engine correleert rapporten tot sporen; levenscyclusbeheer houdt operators eerlijk over versheid; de spooropslag stelt de huidige toestand beschikbaar. Het platform produceert nu betrouwbare spoordata. Het heeft alleen nog geen operatorgericht oppervlak.

Deel 3 bouwt het Common Operational Picture — de frontend die sporen omzet in de kaart die de operator werkelijk gebruikt. Symbologie, realtime bijwerkingen, rolgebaseerde filtering, en de technische beslissingen die bepalen of het platform in het veld wordt geadopteerd.