Aufbau einer Verteidigungs-Fusions-Pipeline, Teil 1: Quellen, Schemata und die Adapter-Schicht

Eine Fusions-Pipeline, die unter Last zuverlässig arbeitet, wird nicht entworfen — sie wird iteriert. Die erste Iteration scheitert fast immer aus demselben Grund: unzureichende Disziplin auf der Quellen- und Schema-Ebene. Adapter lassen quellspezifische Konzepte nach oben durchsickern, das Track-Schema ist nicht stabil genug, um Evolution zu tragen, das kanonische Modell vermengt Konzepte, die getrennt bleiben sollten, und sechs Monate später schreibt das Team die Fusions-Engine neu, während Operatoren noch die kaputte verwenden. Diese vierteilige Serie zeigt, wie dieses Ergebnis zu vermeiden ist. Teil 1 behandelt das Fundament: Katalogisierung der Quellen, Entwurf des kanonischen Track-Schemas und die Adapter-Schicht, die alles andere sauber hält.

Die architektonische Einbettung dieser Serie steht im Vollständigen Leitfaden zur Datenfusion in der Verteidigung. Das C2-seitige Pendant — Aufbau des vollen C2-Stacks mit Fusion als einer Komponente — ist die parallele Serie, beginnend mit Aufbau eines C2-Systems von Grund auf, Teil 1. Diese Serie fokussiert eng auf das Subsystem aus Fusions-Engine und Datenschicht.

Schritt 1: Katalogisieren Sie die Quellen, bevor Sie Code schreiben

Die mit Abstand wirksamste Tätigkeit zu Beginn eines Fusionsprogramms ist der Quellenkatalog — ein Dokument, das jeden Sensor, jeden Nachrichten-Feed und jede externe Eingabe beschreibt, die die Plattform aufnehmen wird. Der Katalog ist uninteressant zu erstellen, uninteressant zu lesen und entscheidend, ihn richtig zu machen. Er wird zum Vertrag, von dem jede nachgelagerte Komponente abhängt.

Der Katalog erfasst für jede Quelle:

• Quellenidentität — stabiler Identifikator, Klarname, betreibende Organisation.
• Wire-Format — ASTERIX-Kategorie und -Version, STANAG-4586-Release, AIS NMEA 0183, CoT-XML-Schemaversion, NITF-Version usw.
• Transport — UDP-Multicast, TCP-Unicast, MQTT-Topic, HTTP-Webhook, File-Drop. Einschließlich Adressierung, Authentifizierung, Verschlüsselungslage.
• Kadenz — Nachrichtenrate bei Nominallast, Spitzenrate, erwartete Stilleintervalle.
• Latenzprofil — Beobachtungszeit vs. Berichtszeit vs. Aufnahmezeit. Manche Quellen sind in Echtzeit; andere haben Batch-Verzögerungen, die in Stunden gemessen werden.
• Genauigkeit und Unsicherheit — was die Spezifikation behauptet, was die operativen Daten zeigen, wie die Fehlermodi aussehen.
• Klassifizierungslage — auf welcher Klassifizierungsstufe die Quelle operiert, welche Kompartimente gelten, welche Freigabe-Regeln die Daten regeln.
• Bekannte Fehlermodi — Verbindungsabbrüche, quellseitige Ausfälle, schleichende Degradation, Möglichkeiten gezielter Manipulation.
• Schema-Mappings — wie jedes Quellfeld auf das kanonische Track-Schema abgebildet wird (wird ergänzt, sobald das Schema existiert).

Der Katalog ist ein versioniertes Artefakt, im Repository neben dem Quellcode abgelegt, vom Engineering-Team und (wo angebracht) von der operativen Gemeinschaft, deren Sensoren einspeisen, geprüft. Eine neue Quelle ist nicht „integriert", bis sie einen Katalogeintrag hat; allein diese Disziplin verhindert das häufigste mehrjährige Refactoring in Fusionsprojekten.

Die ausführliche Behandlung der Herausforderungen der Quellenintegration, insbesondere der Multi-INT-Semantik, die in der Verteidigung auftaucht, findet sich in Herausforderungen der Verteidigungsdatenintegration.

Schritt 2: Entwerfen Sie das kanonische Track-Schema

Der Track ist die zentrale Datenstruktur jeder Fusionsplattform. Jeder Adapter produziert Tracks; jede Fusionsentscheidung aktualisiert Tracks; jeder Konsument liest Tracks. Das Schema ist der Vertrag, mit dem die Plattform ihre gesamte operative Lebenszeit lebt, typischerweise 15–20 Jahre. Investieren Sie einen Sprint, um es richtig zu machen; investieren Sie eine Woche, um es zu dokumentieren.

Das minimal tragfähige Schema umfasst:

Track-ID. Global eindeutig, über die Lebensdauer des Tracks stabil, niemals wiederverwendet. UUIDv7 oder ein typisiertes Präfix-plus-UUID ist der sichere Standard. Die ID ist opak — sie kodiert weder Quelle noch Identität noch irgendein anderes Attribut, das sich ändern könnte.

Identität. Ein strukturierter Typ mit drei Unterfeldern: Typtaxonomie (Schiff, Flugzeug, Fahrzeug, Person, Einheit, Signal, sonstiges nicht klassifiziert), Subtyp (domänenspezifische feinere Klassifizierung) und identifizierende Attribute (Rumpfnummer, Kennung, Rufzeichen, MMSI, Transponder-ID). Die Identität wird von der Fusion aktualisiert, sobald Evidenz akkumuliert; die ID nicht.

Position und Unsicherheit. Breite, Länge, Höhe in WGS84 als Standard. Unsicherheit dargestellt entweder als Kovarianzmatrix (bevorzugt für kinematische Fusion) oder als Haupt-/Nebenachse mit Peilung (für einfachere Anwendungsfälle akzeptabel). Niemals eine einzelne Unsicherheitszahl — sie verliert die geometrische Information, die die Fusion braucht.

Kinematischer Zustand. Geschwindigkeitsvektor, Drehrate, abgeleiteter Kurs/Geschwindigkeit für die Anzeige. Mit dem Zeitpunkt der Schätzung zeitgestempelt.

Quellenmenge. Welche Adapter Beobachtungen zu diesem Track beigetragen haben, mit quellweiser Klassifizierung, Freigabefähigkeit und Konfidenz. Die Quellenmenge ist das Fundament für die Klassifizierungspropagation und das Audit. Die detaillierte Behandlung findet sich in Militärische Datenfusion erklärt.

Drei Zeitstempel. Beobachtungszeit (wann der Sensor das Objekt sah), Berichtszeit (wann die Nachricht den Sensor verließ), Aufnahmezeit (wann die Plattform sie empfing). Das Verschmelzen dieser drei ist die häufigste Fehlerquelle in der Fusions-Entwicklung. Operatoren brauchen die Beobachtungszeit; Replay-Analysen brauchen die Aufnahmezeit; die Differenz zwischen ihnen macht die Sensorlatenz für das Monitoring sichtbar.

Lebenszykluszustand. Tentativ, bestätigt, reif, verblassend, verloren. Die Details des Zustandsautomaten folgen in Teil 2.

Klassifizierungshülle. Effektive Klassifizierung, berechnet aus der Quellenmenge. Freigabe-Tags berechnet aus dem Schnitt der Quellenfreigaben. Kompartiment-Markierungen, wo zutreffend.

Konfidenz und Gewissheit. Track-weite Konfidenz als einzelne kalibrierte Bewertung. Pro-Attribut-Gewissheit, wo sie sich wesentlich unterscheidet — beispielsweise kann ein Track hohe Positionsgewissheit, aber eine tentative Identität haben.

Schritt 3: Verpflichten Sie sich zu additiver Schema-Evolution

Das Schema wird sich weiterentwickeln. Neue Attribute werden benötigt; seltene Fälle werden auftauchen, die der ursprüngliche Entwurf nicht antizipierte. Die Disziplin, die die Plattform durch diese Evolution operativ hält, ist additive-only-Versionierung.

Die Regeln:

• Neue Felder sind optional. Bestehende Konsumenten ignorieren sie, bis sie aktualisiert werden. Produzenten füllen sie, wenn relevante Daten verfügbar sind.
• Bestehende Felder ändern niemals ihre Semantik. Ein Feld, das heute „Geschwindigkeit in m/s" bedeutet, muss für immer „Geschwindigkeit in m/s" bedeuten. Eine Bedeutungsänderung erfordert ein neues Feld, keine In-Place-Änderung.
• Entfernungen sind Deprecations. Ein als deprecated markiertes Feld bleibt im Schema; neue Produzenten schreiben es nicht mehr; neue Konsumenten lesen es nicht mehr; alte Daten funktionieren unbegrenzt weiter.
• Breaking Changes sind Major-Version-Bumps. Sie kommen vor — selten. Wenn sie kommen, wird die Migration dokumentiert, getestet und über alle Konsumenten hinweg koordiniert. Ein Breaking Change sollte höchstens einmal pro Plattformlebensdauer auftreten, nicht einmal pro Release.

Verpacken Sie das Schema in eine codegenerierte Client-Bibliothek, die von jeder Konsumentensprache geteilt wird. Schema-as-Code verhindert das langsame Auseinanderdriften, das andernfalls „Fusionsplattform v3.4 in Dienst A, v3.6 in Dienst B, v4.0 in Dienst C" produziert — den operativen Albtraum, dem jedes Fusionsprogramm ohne diese Disziplin begegnen wird.

Schritt 4: Bauen Sie die Adapter-Schicht mit strikter Isolation

Die Adapter-Schicht übersetzt das native Format jeder Quelle in das kanonische Track-Schema. Die architektonische Regel ist brutal und wert, sich einzuprägen: kein sensorspezifisches Konzept dringt am Adapter vorbei nach oben durch. Wenn der Code Ihrer Fusions-Engine ASTERIX-Kategorien referenziert, haben Sie eine undichte Architektur. Wenn Ihr Track-Store eine Spalte für AIS-Nachrichtentypen hat, haben Sie eine undichte Architektur. Die Regel ist strukturell — brechen Sie sie einmal, und die Kosten kumulieren sich über Jahre.

Die Struktur eines gut entworfenen Adapters in vier Schichten:

Transport. Der Konnektor zur Quelle. UDP-Socket, TCP-Listener, MQTT-Subscription, HTTP-Webhook, File-Watcher. Resilient gegen quellseitige Ausfälle: automatischer Reconnect mit Backoff, Abrechnung verlorener Nachrichten, Telemetrie exportiert in den Monitoring-Stack der Plattform.

Parser. Übersetzt das Wire-Format in eine stark typisierte In-Process-Struktur. Validiert gegen die Format-Spezifikation. Weist fehlerhafte Eingaben laut zurück, mit strukturiertem Logging, das die Fehlerhaftigkeit, den Quellen-Identifikator und den Zeitstempel sichtbar macht. Stilles Verwerfen schlechter Eingaben ist der falsche Standard — es verbirgt operative Probleme, die sichtbar gemacht werden sollten.

Normalizer. Bildet quellspezifische Felder auf kanonische Schemafelder ab. Koordinatensystem-Konvertierung (typischerweise nach WGS84). Zeitstempel-Normalisierung nach UTC mit der Drei-Zeitstempel-Disziplin. Identitätsfeld-Normalisierung über die verschiedenen Arten, wie dieselbe Rumpfnummer oder dasselbe Rufzeichen in unterschiedlichen Quellen formatiert sein kann.

Emitter. Veröffentlicht das kanonische Track-Update auf dem Nachrichten-Bus der Plattform, getaggt mit Quellen-Identifikator, Quellenklassifizierung, Freigabefähigkeit und einem frischen Aufnahmezeitstempel. Der Emitter ist die einzige Komponente im Adapter, die über die Plattform Bescheid weiß; alles oberhalb davon ist quellenspezifisch isolierter Code.

Jeder Adapter läuft als eigener Dienst oder Prozess. Sie teilen eine codegenerierte Client-Bibliothek für das kanonische Schema, aber keine anderen Codepfade. Eine neue Quelle hinzuzufügen, bedeutet, einen neuen Adapter zu schreiben; keine andere Komponente wird berührt. Die detaillierten Integrationsmuster für die häufigsten Verteidigungsquellen finden sich in Integration von AIS und ADS-B in ein militärisches Lagebild und auf der CoT-Seite in Cursor on Target (CoT).

Schritt 5: Verdrahten Sie die Adapter zu einem dauerhaften Nachrichten-Bus

Adapter veröffentlichen auf einem dauerhaften, geordneten, partitionierten Log. Fusionsdienste konsumieren daraus. Audit, historisches Replay und nachgelagerte Analytik ebenso. Der Bus ist das Rückgrat der Fusionsplattform.

Das Muster, das skaliert: Kafka oder NATS JetStream als dauerhaftes Event-Log; Topic-pro-Quellentyp auf der Eingangsseite; Topic-pro-Ausgangstyp auf der Fusionsseite. Adapter veröffentlichen auf raw.<source-type>; die Fusions-Engine konsumiert diese und veröffentlicht auf tracks.updates, tracks.lifecycle, tracks.classification. Konsumenten abonnieren die Topics, die sie jeweils brauchen.

Die detaillierten Abwägungen zwischen Kafka und NATS, die Disziplin der Topic-Modellierung und die operativen Erwägungen finden sich in Message Queues für Verteidigungsdatenpipelines.

Die architektonische Regel, die es zu betonen lohnt: kein HTTP zwischen Fusionskomponenten. Synchrone Request-Response-Kopplung zwischen Adaptern, Fusionsdiensten und Konsumenten macht die Pipeline spröde. Eine Sensor-Spitze, die einen Konsumenten ins Stocken bringt, darf die Produzentenseite nicht ins Stocken bringen. Der Bus mit Backpressure-Handhabung ist die strukturelle Lösung; HTTP zwischen Fusionskomponenten ist eine wiederkehrende Ausfallquelle.

Schritt 6: Testen Sie den Quellenkatalog gegen die Realität

Der Quellenkatalog ist eine Hypothese, bis er getestet wurde. Die Disziplinen, die ihn validieren, bevor die Pipeline operativ geht:

Replay aufgezeichneter Daten. Erfassen Sie für jede Quelle Tage oder Wochen echten Wire-Format-Verkehrs in eine Datei. Spielen Sie die Datei mit Originalrate und mit beschleunigter Rate gegen den Adapter ab. Der Adapter, der reale Daten mit 10-facher Geschwindigkeit verarbeitet, ist der Adapter, der operative Sensor-Spitzen verarbeitet; der Adapter, der nur katalogsynthetische Daten verarbeitet, ist noch nicht bereit.

Adversariale Eingabetests. Injizieren Sie fehlerhafte Nachrichten, gespoofte AIS, Radarplots, die gegen die Physik verstoßen (Mach-5-Bodenspuren), CoT-XML mit Schemaverletzungen. Der Adapter muss diese laut zurückweisen, nicht abstürzen, nicht stillschweigend weiterleiten. Die Disziplin trägt sich bis in die Fusions-Engine selbst, behandelt in Militärische Datenfusion erklärt.

Schema-Round-Trip-Tests. Jeder Adapter muss seine native Eingabe durch das kanonische Schema und zurück führen können, wobei operativ signifikante Felder erhalten bleiben. Ein verlustbehafteter Adapter ist ein Designfehler, der Monate später beim Konformitätstest sichtbar wird.

Katalog-Audit gegen reale Produktionsdaten. Sobald die Pipeline im Pilotbetrieb läuft, prüfen Sie den Quellenkatalog gegen reale Aufnahmedaten. Quellen, die Attribute produzieren, die der Katalog nicht antizipierte, Latenzen, die die Erwartungen des Katalogs überschreiten, oder Fehlermodi, die der Katalog nicht dokumentierte — das sind Befunde, die den Katalog, den Adapter oder beides aktualisieren.

Was als Nächstes kommt

Teil 1 hat das Fundament behandelt. Quellen katalogisiert, kanonisches Track-Schema mit additiver Evolution entworfen, Adapter mit strikter Isolation gebaut, der Nachrichten-Bus verdrahtet und die Testdisziplinen, die die Schicht validieren. Die Pipeline nimmt nun Quelldaten auf und produziert kanonische Track-Beobachtungen auf dem Bus — aber diese Beobachtungen sind noch nicht zu Tracks korreliert.

Teil 2: Track-Korrelation und Lebenszyklusverwaltung nimmt den kanonischen Beobachtungsstrom auf und baut das Herz der Fusions-Engine. Regelbasiertes Gating, probabilistische Datenassoziation (JPDA, MHT), Lebenszyklus-Zustandsautomat und der Track-Store als event-sourced Read-Model.