Een Defensie Fusiepijplijn Bouwen, Deel 1: Bronnen, Schema's en de Adapterlaag

Een fusiepijplijn die betrouwbaar functioneert onder belasting wordt niet ontworpen — hij wordt geïtereerd. De eerste iteratie mislukt bijna altijd om dezelfde reden: onvoldoende discipline op de bron-en-schema-laag. Adapters laten bronspecifieke concepten stroomopwaarts lekken, het trackschema is niet stabiel genoeg om evolutie te ondersteunen, het canonieke model vermengt concepten die gescheiden moeten blijven, en zes maanden later herschrijft het team de fusiemotor terwijl operators nog steeds de gebroken versie gebruiken. Deze vierdelige reeks legt uit hoe dit resultaat te vermijden. Deel 1 behandelt het fundament: bronnen catalogiseren, het canonieke trackschema ontwerpen en de adapterlaag die alles schoon houdt.

Het architecturale kader voor deze reeks staat in De Complete Gids voor Defensie Datafusie. Het C2-equivalent — het bouwen van de volledige C2-stack met fusie als één component — is de parallelle reeks die begint bij Een C2-systeem Bouwen vanaf de Grond, Deel 1. Deze reeks gaat dieper in op het subsysteem van de fusiemotor plus datalaag.

Stap 1: Catalogiseer de Bronnen Voordat u Code Schrijft

De meest waardevolle activiteit aan het begin van een fusieprogramma is de broncatalogus — een document dat elke sensor, inlichtingenfeed en externe invoer beschrijft die het platform zal verwerken. De catalogus is oninteressant om op te stellen, oninteressant om te lezen en cruciaal om goed te krijgen. Hij wordt het contract waarvan elk stroomafwaarts component afhankelijk is.

De catalogus legt voor elke bron vast:

• Bronidentiteit — stabiele identificator, vriendelijke naam, eigenaarorganisatie.
• Draadformaat — ASTERIX-categorie en -versie, STANAG 4586-release, AIS NMEA 0183, CoT XML-schemaversie, NITF-versie, enz.
• Transport — UDP-multicast, TCP-unicast, MQTT-topic, HTTP-webhook, bestandsneerzetplaats. Inclusief adressering, authenticatie en versleuteling.
• Cadans — berichtsnelheid bij nominale belasting, pieksnelheid, verwachte stilte-intervallen.
• Latentieprofiel — observatietijd vs rapporttijd vs verwerkingstijd. Sommige bronnen zijn realtime; andere hebben batchvertragingen van uren.
• Nauwkeurigheid en onzekerheid — wat de specificatie beweert, wat de operationele data laat zien, hoe faalmodussen eruitzien.
• Classificatiepostuur — op welk classificatieniveau de bron opereert, welke compartimenten van toepassing zijn, welke vrijgaveregels de data beheersen.
• Bekende faalmodussen — verbindingsuitval, bronstoringen, geleidelijke degradatie, mogelijkheden voor opzettelijke manipulatie.
• Schematoewijzingen — hoe elk bronveld overeenkomt met het canonieke trackschema (ingevuld zodra het schema bestaat).

De catalogus is een geversioneerd artefact, opgeslagen in de repository naast broncode, beoordeeld door het engineeringteam en (waar van toepassing) door de operationele gemeenschap wiens sensoren invoer leveren. Een nieuwe bron is pas "geïntegreerd" als hij een catalogusvermelding heeft; deze discipline alleen al voorkomt de meest voorkomende meerjarige herstructurering in fusieprojecten.

De gedetailleerde behandeling van bronintegratieuitdagingen, met name de multi-INT-semantiek die bij defensie naar voren komt, staat in Defensie Data-integratieuitdagingen.

Stap 2: Ontwerp het Canonieke Trackschema

De track is de centrale datastructuur van elk fusieplatform. Elke adapter produceert tracks; elke fusiebeslissing werkt tracks bij; elke consument leest tracks. Het schema is het contract waarmee het platform zijn operationele levensduur doorloopt, doorgaans 15-20 jaar. Besteed een sprint aan het goed krijgen; besteed een week aan de documentatie.

Het minimaal levensvatbare schema omvat:

Track-ID. Wereldwijd uniek, stabiel gedurende de levensduur van de track, nooit hergebruikt. UUIDv7 of een getypeerd voorvoegsel-plus-UUID is de veilige standaard. Het ID is opaak — het codeert geen bron, identiteit of ander attribuut dat kan veranderen.

Identiteit. Een gestructureerd type met drie subvelden: typetaxonomie (vaartuig, vliegtuig, voertuig, persoon, eenheid, signaal, niet-geclassificeerd-overig), subtype (verfijndere classificatie per domein) en identificerende attributen (roepnummer, registratienummer, callsign, MMSI, transponder-ID). Identiteit wordt bijgewerkt door fusie naarmate bewijsmateriaal accumuleert; het ID niet.

Positie en onzekerheid. Breedtegraad, lengtegraad, hoogte in WGS84 als standaard. Onzekerheid weergegeven als covariantiematrix (voorkeur voor kinematische fusie) of grote/kleine as met peiling (acceptabel voor eenvoudigere gevallen). Nooit een enkel onzekerheidsgetal — dat verliest de geometrische informatie die fusie nodig heeft.

Kinematische toestand. Snelheidsvector, draaipunt, afgeleid koers/snelheid voor weergave. Tijdgestempeld met het moment van schatting.

Bronset. Welke adapters observaties hebben bijgedragen aan deze track, met per-bron classificatie, vrijgavebaarheid en betrouwbaarheid. De bronset is het fundament voor classificatievoortplanting en audit. De gedetailleerde behandeling staat in Militaire Datafusie Uitgelegd.

Drie tijdstempels. Observatietijd (wanneer de sensor het object zag), rapporttijd (wanneer het bericht de sensor verliet), verwerkingstijd (wanneer het platform het ontving). Deze verwarren is de meest voorkomende bugbron in fusie-engineering. Operators hebben observatietijd nodig; herhalingsanalyses hebben verwerkingstijd nodig; het verschil ertussen onthult sensorlatentie voor monitoring.

Levenscyclustoestand. Voorlopig, bevestigd, volwassen, verdwijnend, verloren. Details van de toestandsmachine komen in Deel 2.

Classificatie-enveloppe. Effectieve classificatie berekend uit de bronset. Vrijgavebaarheidstags berekend uit de doorsnede van bronvrijgavebaarheid. Compartimentmarkeringen waar van toepassing.

Betrouwbaarheid en zekerheid. Track-niveau betrouwbaarheid als een gecalibreerde score. Per-attribuut zekerheid waar dit materieel verschilt — een track kan bijvoorbeeld hoge positiezekerheid maar voorlopige identiteit hebben.

Stap 3: Bevestig u aan Additieve Schema-evolutie

Het schema zal evolueren. Nieuwe attributen zullen nodig zijn; zeldzame gevallen zullen opduiken die het originele ontwerp niet anticipeerde. De discipline die het platform operationeel houdt doorheen deze evolutie is alleen-additieve versiebeheer.

De regels:

• Nieuwe velden zijn optioneel. Bestaande consumenten negeren ze totdat ze zijn geüpgraded. Producenten vullen ze in wanneer relevante data beschikbaar is.
• Bestaande velden veranderen nooit van semantiek. Een veld dat vandaag "snelheid in m/s" betekent, moet dat voor altijd betekenen. Een semantiekwijziging vereist een nieuw veld, niet een in-place wijziging.
• Verwijderingen zijn deprecaties. Een als verouderd gemarkeerd veld blijft in het schema; nieuwe producenten stoppen ermee te schrijven; nieuwe consumenten stoppen ermee te lezen; oude data blijft onbeperkt werken.
• Baanbrekende wijzigingen zijn major-versiebumps. Ze gebeuren — zelden. Wanneer ze dat doen, wordt de migratie gedocumenteerd, getest en gecoördineerd over alle consumenten. Een baanbrekende wijziging mag hooguit eenmaal per platformlevensduur voorkomen, niet eenmaal per release.

Wikkel het schema in een codegegenereerde clientbibliotheek die door elke consumententaal wordt gedeeld. Schema-als-code voorkomt de langzame divergentie die anders resulteert in "fusieplatform v3.4 in service A, v3.6 in service B, v4.0 in service C" — de operationele nachtmerrie die elk fusieprogramma zal tegenkomen zonder deze discipline.

Stap 4: Bouw de Adapterlaag met Strikte Isolatie

De adapterlaag vertaalt het native formaat van elke bron naar het canonieke trackschema. De architectuurregel is meedogenloos en de moeite waard om te memoriseren: geen sensorspecifiek concept lekt voorbij de adapter. Als uw fusiemotorcode ASTERIX-categorieën verwijst, heeft u een lekkende architectuur. Als uw trackopslag een kolom heeft voor AIS-berichttypes, heeft u een lekkende architectuur. De regel is structureel — breek hem eenmaal, en de kosten compounderen over jaren.

De structuur van een goed ontworpen adapter, in vier lagen:

Transport. De connector naar de bron. UDP-socket, TCP-listener, MQTT-abonnement, HTTP-webhook, bestandswatcher. Veerkrachtig voor bronstoringen: automatisch opnieuw verbinden met backoff, administratie van verwijderde berichten, telemetrie geëxporteerd naar de monitoringstack van het platform.

Parser. Vertaalt het draadformaat naar een sterk-getypeerde in-process structuur. Valideert tegen de formaatspecificatie. Verwerpt misvormde invoer luidruchtig, met gestructureerde logboekregistratie die de misvorming, de bronidentificator en het tijdstempel toont. Stil weggooien van slechte invoer is de verkeerde standaard — het verbergt operationele problemen die zichtbaar moeten zijn.

Normalisator. Wijst bronspecifieke velden toe aan canonieke-schemavelden. Coördinatensysteemconversie (doorgaans naar WGS84). Tijdstempelnormalisatie naar UTC met de drie-tijdstempel-discipline. Identiteitsveldnormalisatie over de verschillende manieren waarop hetzelfde roepnummer of callsign in verschillende bronnen kan worden opgemaakt.

Emitter. Publiceert de canonieke trackupdate naar de berichtenbus van het platform, getagd met bronidentificator, bronclassificatie, vrijgavebaarheid en een vers verwerkingstijdstempel. De emitter is het enige component in de adapter dat weet van het platform; alles stroomopwaarts ervan is bronspecifieke geïsoleerde code.

Elke adapter draait als een afzonderlijke service of proces. Ze delen een codegegenereerde clientbibliotheek voor het canonieke schema, maar geen andere codepaden. Een nieuwe bron toevoegen betekent een nieuwe adapter schrijven; het raakt geen enkel ander component. De gedetailleerde integratiepatronen voor de meest voorkomende defensiebronnen staan in AIS en ADS-B integreren in een Militair Beeld en de CoT-kant in Cursor on Target (CoT).

Stap 5: Koppel de Adapters aan een Duurzame Berichtenbus

Adapters publiceren naar een duurzaam, geordend, gepartitioneerd logboek. Fusieservices consumeren ervan. Dat geldt ook voor audit, historische herhaling en stroomafwaartse analyses. De bus is het ruggenmerg van het fusieplatform.

Het patroon dat schaalt: Kafka of NATS JetStream als het duurzame gebeurtenislogboek; topic-per-brontype aan de invoerkant; topic-per-uitvoertype aan de fusiekant. Adapters publiceren naar raw.<source-type>; de fusiemotor consumeert deze en publiceert naar tracks.updates, tracks.lifecycle, tracks.classification. Consumenten abonneren op welke topics ze nodig hebben.

De gedetailleerde afwegingen tussen Kafka en NATS, de topic-modelleerdiscipline en de operationele overwegingen staan in Berichtenwachtrijen voor Defensie Datapijplijnen.

De architectuurregel die vermelding verdient: gebruik geen HTTP tussen fusiecomponenten. Synchrone verzoek-antwoord koppeling tussen adapters, fusieservices en consumenten maakt de pijplijn breekbaar. Een sensorpiek die één consument blokkeert, mag de producentkant niet blokkeren. De bus met backpressure-afhandeling is de structurele oplossing; HTTP tussen fusiecomponenten is een terugkerende bron van uitval.

Stap 6: Test de Broncatalogus Tegen de Werkelijkheid

De broncatalogus is een hypothese totdat hij wordt getest. De disciplines die hem valideren voordat de pijplijn operationeel gaat:

Vastgelegde-data-herhaling. Leg voor elke bron dagen of weken aan echt draadformaatvrachtsverkeer vast in een bestand. Herhaal het bestand tegen de adapter op oorspronkelijke snelheid en op versnelde snelheid. De adapter die echte data op 10× snelheid verwerkt, is de adapter die operationele sensorpieken aankan; de adapter die alleen catalogus-synthetische data verwerkt, is nog niet klaar.

Adversarieel invoertesten. Injecteer misvormde berichten, vervalste AIS, radarplots die de fysica schenden (Mach 5 grondsporen), CoT XML met schemaschendingen. De adapter moet deze luidruchtig verwerpen, niet crashen, niet stilletjes doorgeven. De discipline strekt zich uit tot de fusiemotor zelf, behandeld in Militaire Datafusie Uitgelegd.

Schema-rondreis-tests. Elke adapter moet zijn native invoer door het canonieke schema en terug kunnen verwerken, waarbij operationeel significante velden behouden blijven. Een verliesgevende adapter is een ontwerpfout die maanden later tijdens conformiteitstests naar boven komt.

Catalogusaudit tegen echte productiedata. Zodra de pijplijn in proefimplementatie draait, auditeer de broncatalogus tegen echte verwerkingsdata. Bronnen die attributen produceren die de catalogus niet anticipeerde, latenties die de verwachtingen van de catalogus overschrijden, of faalmodussen die de catalogus niet documenteerde — dit zijn bevindingen die de catalogus, de adapter of beide bijwerken.

Wat Volgt

Deel 1 heeft het fundament behandeld. Bronnen gecatalogiseerd, canoniek trackschema ontworpen met additieve evolutie, adapters gebouwd met strikte isolatie, de berichtenbus gekoppeld en de testdisciplines die de laag valideren. De pijplijn verwerkt nu brondata en produceert canonieke trackobservaties op de bus — maar die observaties zijn nog niet gecorreleerd tot tracks.

Deel 2: Trackcorrelatie en Levenscyclusbeheer neemt de canonieke observatiestroom en bouwt het hart van de fusiemotor. Regelgebaseerde poortbewaking, probabilistische data-associatie (JPDA, MHT), levenscyclustoestandsmachine en de trackopslag als evenementgesourced leesmodel.