Teil 1 hat einen Umfang gewählt, die Vier-Schichten-Architektur festgelegt und das kanonische Track-Schema entworfen. Teil 2 baut die Engine, die Sensormeldungen in vertrauenswürdige Tracks verwandelt: Adapter, die Quellen einbinden, die Korrelationsalgorithmen, die entscheiden, welche Meldungen sich auf dasselbe physische Objekt beziehen, die Lebenszyklusverwaltung, die dem COP mitteilt, wenn ein Track veraltet ist, und der Track Store, der alles verankert. Am Ende von Teil 2 produziert die Plattform einsatzfähige Tracks; sie hat nur keinen Ort, sie anzuzeigen.

Die konzeptionelle Referenz für alles in Teil 2 ist Der vollständige Leitfaden zur Datenfusion in der Verteidigung, der die Disziplin überblickt. Hier treffen wir konkrete Entscheidungen für die laufende Beispielplattform.

Schritt 1: Das Adapter-Muster, strikt umgesetzt

Jeder Sensor produziert Daten in seinem eigenen Format. Radare sprechen ASTERIX; UAVs sprechen STANAG 4586; AIS-Empfänger geben NMEA 0183 aus; ATAK-Clients sprechen CoT; zivile ADS-B-Feeds geben ein anderes Binärprotokoll aus; manuell gemeldete Sichtungen kommen über ein Webformular. Die Aufgabe der Adapterschicht ist es, all dies in das in Teil 1 definierte kanonische Track-Schema zu übersetzen.

Die Regel ist hart und einprägsam: kein sensorspezifisches Konzept dringt am Adapter vorbei. Wenn Ihr Fusion-Engine-Code ASTERIX-Kategorien referenziert, haben Sie eine undichte Architektur. Wenn Ihr Track Store eine Spalte für AIS-Nachrichtentypen hat, haben Sie eine undichte Architektur. Adapter sind Einweg-Datenkonverter mit strikter Isolation; sie exponieren stromaufwärts nur kanonische Tracks.

Die pragmatische Adapterstruktur für jede Quelle:

  • Transport — der Konnektor zur Quelle (UDP-Socket, MQTT-Abonnement, HTTP-Webhook, Datei-Watcher). Widerstandsfähig gegenüber quellseitigem Ausfall: Reconnects, Backoff, Buchführung über verworfene Nachrichten.
  • Parser — übersetzt das Wire-Format in eine streng typisierte In-Process-Struktur. Validiert gegen die Formatspezifikation. Lehnt fehlerhafte Eingaben laut ab, statt sie still zu schlucken.
  • Normalisierer — bildet quellenspezifische Felder auf kanonische Felder ab. Konvertierung des Koordinatensystems (typischerweise nach WGS84). Zeitstempel-Normalisierung (UTC, mit der Drei-Zeitstempel-Disziplin aus Teil 1).
  • Emitter — veröffentlicht das kanonische Track-Update auf dem Nachrichten-Bus. Markiert mit Quell-Kennung, Quellen-Klassifizierung und Releasability.

Jeder Adapter ist ein eigener Dienst oder Prozess. Sie teilen eine codegenerierte Client-Bibliothek für das kanonische Schema, aber keine anderen Codepfade. Einen neuen Sensortyp hinzuzufügen bedeutet, einen neuen Adapter zu schreiben, nicht eine andere Komponente anzufassen. Die detaillierten Integrationsmuster für die gängigen Quellen finden sich in AIS und ADS-B in ein militärisches Lagebild integrieren und für die CoT-Seite in Cursor on Target (CoT): Der XML-Standard hinter taktischen Awareness-Apps.

Schritt 2: Den Nachrichten-Bus verdrahten

Adapter veröffentlichen in einem dauerhaften, geordneten, partitionierten Log. Fusionsdienste konsumieren daraus. Ebenso der Audit-Dienst, der Dienst für historische Wiedergabe und alle nachgelagerten Analysen. Der Message-Bus ist das Rückenmark der Plattform.

Für das laufende Beispiel verwenden wir Kafka mit einem Topic pro Quelltyp und zusätzlichen Topics für Fusionsausgaben. Adapter veröffentlichen auf raw.source-type; die Fusion Engine konsumiert diese und veröffentlicht auf tracks.updates und tracks.lifecycle. Audit abonniert alles. Das Bus-Muster, einschließlich der Trade-offs zwischen Durchsatz und Dauerhaftigkeit, findet sich in Message Queues für Datenpipelines in der Verteidigung.

Die architektonische Entscheidung, die hervorgehoben gehört: rufen Sie kein HTTP zwischen Fusionskomponenten auf. Synchrone Request-Response-Kopplung macht eine Fusionspipeline brüchig. Ein Sensorpeak, der einen Konsumenten stocken lässt, darf nicht jeden Produzenten stromaufwärts stocken lassen. Der Bus mit Backpressure ist die strukturelle Lösung; HTTP zwischen Fusionskomponenten ist eine wiederkehrende Ursache für Ausfälle.

Schritt 3: Track-zu-Track-Korrelation

Der Kern der Fusion Engine ist der Algorithmus, der entscheidet, ob eine eingehende Meldung ein Update zu einem bestehenden Track oder die Geburt eines neuen ist. Macht man das falsch, sieht der Bediener Track-Suppe (tausend Symbole, wo es hundert sein sollten) oder Ghost-Tracks (Duplikate, die hätten zusammengeführt werden sollen). Macht man es richtig, wird das COP vertrauenswürdig.

Das pragmatische Muster verwendet einen zweistufigen Filter.

Stufe 1: regelbasiertes Gating. Für jede eingehende Meldung wird die Menge der bestehenden Kandidaten-Tracks innerhalb kinematischer Reichweite berechnet — ein Positions-Zeit-Gate, das besagt: „Ein Track, der sich mit höchstens V m/s bewegt, hätte in diesem Zeitintervall von seiner letzten bekannten Position zur Position dieser Meldung gelangen können". Identitäts-Priors filtern weiter: Eine als „Schiff" markierte Meldung kann nicht zu einem „Luftfahrzeug"-Track passen. Quellenkompatibilitäts-Filter: Eine Meldung eines Bodenradars kann nicht zu einem Luft-Track einer Unterwasser-Plattform passen. Die regelbasierte Stufe verarbeitet 90 % der Eingaben günstig und eindeutig.

Stufe 2: probabilistische Assoziation. Für die strittigen Fälle — mehrere Kandidaten innerhalb des Gates, mehrdeutige Identität, dichte Szenarien mit kreuzenden Trajektorien — wird probabilistische Datenassoziation aufgerufen. Joint Probabilistic Data Association (JPDA) für moderate Dichte; Multiple Hypothesis Tracking (MHT) für die schwersten Fälle. Beide berechnen eine Wahrscheinlichkeit, dass eine eingehende Meldung zu jedem Kandidaten-Track gehört, und aktualisieren die Tracks gewichtet nach dieser Wahrscheinlichkeit.

Das vollständige theoretische Modell mit ingenieurtechnischen Implikationen findet sich in Das JDL-Datenfusionsmodell: Eine praktische Engineering-Referenz. Die ingenieurtechnischen Feinheiten, wann welche Technik anwendbar ist, und das nötige Tuning, finden sich in Militärische Datenfusion erklärt.

Eine konkrete Falle, die Hervorhebung verdient: MHT generiert ohne Pruning eine exponentielle Anzahl von Hypothesen. Die Pruning-Strategie — wie viele Hypothesen zu behalten sind, wann zu mergen, wann zu löschen ist — ist wichtiger als der Kernalgorithmus. Setzen Sie standardmäßig auf aggressives Pruning; lockern Sie nur, wenn das Bedrohungsbild es verlangt.

Schritt 4: Track-Lebenszyklusverwaltung

Ein Track ist kein statischer Datensatz. Er wird geboren, bestätigt, altert, verblasst und stirbt. Die Fusion Engine verwaltet den Track-Lebenszyklus explizit; das COP zeigt den Lebenszyklusstatus, damit Bediener wissen, welchen Tracks zu vertrauen ist.

Die Zustandsmaschine für das laufende Beispiel:

  • Vorläufig (tentative) — erste Beobachtung; wird im operativen COP noch nicht angezeigt, sofern nicht ausdrücklich angefordert. Verfällt zu gelöscht, wenn innerhalb eines konfigurierbaren Zeitfensters kein Folge-Update eintrifft.
  • Bestätigt (confirmed) — zwei oder mehr korrelierte Meldungen, kinematische Konsistenz gegeben. Aus „vorläufig" hochgestuft. Dies ist der Standardzustand für angezeigte Tracks.
  • Gereift (mature) — bestätigt und mindestens N Minuten lang persistent mit konsistenten Updates. Wird von nachgelagerten Analysen genutzt, die eine stabile Identität benötigen.
  • Verblassend (fading) — kein Update innerhalb des erwarteten Revisit-Intervalls. In der Anzeige als veraltet markiert. Pro Quellenklasse konfigurierbar (ein 30 Sekunden alter maritimer Track ist in Ordnung; ein 30 Sekunden alter Luft-Track ist verblassend).
  • Verloren (lost) — kein Update über einen längeren Zeitraum. Aus der aktiven Anzeige entfernt, aber für Audit und historische Analyse im Track Store erhalten.

Jeder Zustandsübergang wird protokolliert. Der Audit-Dienst konsumiert den Übergangsstrom und schreibt unveränderliche Datensätze — Thema von Event Sourcing für Audit-Trails in der Verteidigung. Die Übergänge werden ebenfalls auf dem Bus exponiert, sodass das COP den Lebenszyklusstatus ohne Polling rendern kann.

Zentrale Erkenntnis: Bediener tolerieren einen fehlenden Track. Sie tolerieren keinen selbstbewusst angezeigten veralteten Track. Die Lebenszyklusverwaltung ist die Schicht, die den Unterschied macht. Bauen Sie sie, bevor der Fusionsalgorithmus vollständig getunt ist — sie ist billig und zahlt sich jedes Mal aus, wenn ein Sensor-Link abreißt.

Schritt 5: Der autoritative Track Store

Die Fusion gibt einen Strom von Track-Updates und Lebenszyklusübergängen aus. Der Track Store ist die materialisierte Sicht: der aktuelle Zustand jedes aktiven Tracks, abfragbar durch das COP und die Analysen. Die architektonische Entscheidung, die früh getroffen werden sollte: der Track Store ist ein Read Model, keine autoritative Quelle. Die autoritative Quelle ist das Event-Log auf dem Nachrichten-Bus. Der Track Store wird auf Anforderung aus dem Log neu aufgebaut.

Dieses Muster — Event Sourcing mit Read-Model-Projektionen — hat drei operative Vorteile. Der Store kann ohne Datenverlust geleert und neu aufgebaut werden. Mehrere Read Models mit unterschiedlichen Formen können koexistieren (eines für das COP, eines für Analysen, eines für eine externe API). Zeitreise-Abfragen werden trivial: Spielen Sie das Log bis zu einem gewählten Zeitpunkt ab, um zu rekonstruieren, was die Plattform damals glaubte.

Der Store selbst ist PostgreSQL mit PostGIS für geospatial Indizierung. Hot Tracks leben im Speicher oder in einer Redis-Schicht vor PostgreSQL für Lesezugriffe unter einer Millisekunde; der relationale Store bewältigt die längeren Anfragen und Persistenzgarantien. Die detaillierte ingenieurtechnische Sicht findet sich in PostGIS für geospatial Daten in der Verteidigung.

Widerstehen Sie der Versuchung, eine Graphdatenbank „für Beziehungen" hinzuzufügen. Beziehungen zwischen Tracks — Konvoi-Erkennung, Formationserkennung, Kontaktnetzwerke — sind JDL-Level-2-Fusion, ein gesondertes Anliegen von der Level-1-Track-Pflege. Bauen Sie Level 1 zuerst, betreiben Sie es ein Jahr lang im Einsatz, und kehren Sie dann mit den operativen Belegen zu Level 2 zurück.

Schritt 6: Mit realistischen Eingaben testen

Eine Fusion Engine, die nur mit Spielzeuglast getestet wurde, besteht den Integrationstest und scheitert im Einsatz. Die Disziplinen, die Probleme vor dem Deployment abfangen:

Replay-Testumgebungen. Erfassen Sie echte Sensor-Traces in der Entwicklung und spielen Sie diese mit voller Rate gegen die Fusion Engine ab. Die Traces dienen als Regressions-Testsuite: Ein neuer Algorithmus oder eine Schemaänderung muss auf den vorhandenen Traces gleichwertige oder bessere Ergebnisse liefern, nicht nur auf synthetischer Last.

Adversariale Eingaben. Gefälschte AIS-Nachrichten mit unplausibler Kinematik. Fehlerhaftes CoT-XML. Radar-Plots, die die Physik verletzen (Mach-5-Bodentracks). Die Fusion Engine muss diese ablehnen oder markieren, nicht in Panik geraten, nicht abstürzen, keine selbstbewussten-aber-falschen Tracks produzieren. Die Disziplin entspricht der breiteren Testdisziplin in Einsatzkritische C2-Systeme testen.

Pattern-of-Life-Erkennung. Sobald die Grundfusion funktioniert, kann PoL-Analytik aufgesetzt werden — siehe Pattern-of-Life-Analyse in der militärischen Aufklärung. Der PoL-Dienst konsumiert dieselben Bus-Topics; er produziert angereicherte Track-Zustands-Annotationen, statt mit der Fusion Engine zu konkurrieren.

Schritt 7: Performance-Ziele und Headroom

Fusionslatenz ist operativ folgenreich. Ziele für die laufende Beispielplattform: 95. Perzentil End-to-End-Fusionslatenz unter 500 ms (vom Eingang der Sensormeldung bis zur Track-Update-Nachricht auf dem Bus); 99. Perzentil unter 1,5 s; Durchsatz dauerhaft bei 10 000 Meldungen pro Sekunde mit einstelligem Prozent-CPU-Headroom.

Dies sind Ziele auf Ebene einer taktischen Brigade. Strategische Plattformen haben lockerere Latenztoleranzen und höhere Durchsatzobergrenzen. Die Ziele treiben architektonische Entscheidungen: synchrone dienstübergreifende Aufrufe auf dem Hot Path vermeiden; Hot-Track-Zustand vorab allokieren; nur dort batchen, wo der Bus es zulässt; jede Pipeline-Stufe instrumentieren, damit Latenzregressionen in CI auftauchen statt im Einsatz.

Wie es weitergeht

Teil 2 hat die Engine gebaut. Sensoradapter konvertieren in kanonische Tracks; der Nachrichten-Bus trägt die Ereignisse; die Fusion Engine korreliert Meldungen zu Tracks; die Lebenszyklusverwaltung hält Bediener bezüglich Aktualität ehrlich; der Track Store exponiert den aktuellen Zustand. Die Plattform produziert nun vertrauenswürdige Trackdaten. Sie hat nur keine bedienerseitige Oberfläche.

Teil 3 baut das Gemeinsame Lagebild — das Frontend, das Tracks in die Karte verwandelt, die der Bediener tatsächlich nutzt. Symbologie, Echtzeit-Updates, rollenbasierte Filterung und die ingenieurtechnischen Entscheidungen, die bestimmen, ob die Plattform im Feld angenommen wird.