Intelligence aus SIGINT, IMINT, HUMINT und OSINT zu einem einzigen kohärenten Bild zu fusionieren, klingt im Konzept einfach. In der Praxis ist es eines der härtesten Engineering-Probleme der Verteidigungsdaten-Infrastruktur. Jede Disziplin erzeugt Daten mit unterschiedlicher Geschwindigkeit, in unterschiedlichem Format und mit unterschiedlichem Konfidenzmodell – und ein System, das diese Feeds lediglich aggregiert, ohne sie wirklich zu korrelieren, erzeugt ein verrauschteres Bild als ein gut geführter Einzel-INT-Feed, kein besseres. Ernsthaft Datenintegration für Defense Intelligence erfordert eine Architektur, die von Grund auf um die Eigenschaften jedes Quelltyps herum entworfen ist, nicht ein generisches Data Warehouse mit nachgerüsteten INT-Adaptoren.

Dieser Artikel führt durch die vollständige Architektur eines Echtzeit-Multi-Source-Fusionssystems – von der Stream-Ingestion-Schicht, die heterogene Feeds aufnimmt, über Entity Resolution und die Korrelations-Engine bis zur Konfidenzbewertung und der Veröffentlichung eines angereicherten Intelligence-Bilds an C2-Systeme. Jeder Abschnitt behandelt die konkreten Entwurfsentscheidungen, die produktionsreife Fusion von Prototypsystemen trennen, die in einer Demo korrekt wirken, aber im operativen Maßstab scheitern.

Das Multi-Source-Intelligence-Fusionsproblem – warum die Fusion von SIGINT/IMINT/HUMINT/OSINT schwerer ist, als sie aussieht

Drei strukturelle Probleme machen die Multi-Source-Fusion qualitativ härter als die Verarbeitung eines einzelnen INT im Maßstab. Sie zu ignorieren – Fusion als reines Datenpipeline-Problem zu behandeln – ist der häufigste architektonische Fehler, und er erzeugt ein System, das nicht mehr korrigierbar ist, sobald Daten im Produktionsvolumen fließen.

Heterogenität der Formate ist das sichtbarste Problem. Ein ELINT-Intercept-Datensatz enthält Senderfrequenz, Pulswiederholrate, Scantyp, Peilung und Time-Difference-of-Arrival-Daten. Eine IMINT-Detektion enthält eine Bounding Box, eine pixelbasierte Konfidenzbewertung, eine Bodenauflösung (Ground Sample Distance) und eine UTM-Koordinate mit zugehörigem CEP. Ein HUMINT-Narrativ-Extrakt enthält Freitext, eine Quellennote des Analysten, einen benannten Ort und ein Zeitfenster in Stunden oder Tagen. Diese drei Datensätze können sich alle auf dasselbe reale Objekt beziehen – ein Radarfahrzeug –, doch sie teilen kein gemeinsames Feld, keine gemeinsame Koordinatensystemkonvention und keine gemeinsame Kennung. Ihre Normalisierung in ein einziges kanonisches Schema erfordert eigens gebaute Adapter für jeden Quelltyp und ein kanonisches Entitätsmodell, das sie alle aufnehmen kann, ohne ihre Semantik einzuebnen. Das Datenmodell-Design für militärische Multi-INT-Sensorfusion behandelt diese kanonische Schicht im Detail.

Konfidenz-Unstimmigkeit ist subtiler, verursacht aber mehr analytische Fehler. Jeder INT wendet sein eigenes Konfidenzmodell an. SIGINT-Geolokalisierung trägt einen CEP (Circular Error Probable) in Metern – eine geometrische Genauigkeitsschätzung. Eine IMINT-Detektion trägt eine Klassifikatorwahrscheinlichkeit – das Ausgabelogit des neuronalen Netzes für die Objektklasse. HUMINT trägt eine Admiralty-Zuverlässigkeitsnote – eine sechsstufige menschliche Beurteilungsskala. Diese drei Zahlen bedeuten grundlegend Verschiedenes. Ein naives Fusionssystem, das sie mittelt, erzeugt eine Zahl, die mathematisch gültig, analytisch aber bedeutungslos ist. Ein korrektes Konfidenzmodell muss zuerst jede quellnative Konfidenz in ein gemeinsames probabilistisches Rahmenwerk übersetzen und dann über die Quellen hinweg mit einem Bayes'schen oder Evidenzkombinations-Schema (etwa Dempster-Shafer) aggregieren, das abhängige und unabhängige Evidenz korrekt behandelt.

Zeitliche Verschiebung ist das Problem, das Echtzeit-Fusionsarchitekturen am sichtbarsten bricht. Verschiedene Quellen haben sehr unterschiedliche Latenzen vom Eintreten des Ereignisses bis zum Eintreffen der Daten in der Pipeline. Ein SIGINT-Intercept kann innerhalb von Sekunden nach der Übertragung in der Pipeline eintreffen. IMINT von einem angeforderten Satelliten kann 60–90 Minuten Bildverarbeitung benötigen, bevor ein Detektionsdatensatz entsteht. Ein HUMINT-Bericht über die Ereignisse von gestern kann an Tag D+2 aufgenommen werden. Eine Fusions-Engine, die Datensätze nach Ankunftszeitstempel in der Pipeline korreliert, wird Ereignisse systematisch falsch zuordnen – sie wird das SIGINT-Intercept und die IMINT-Bestätigung nicht verknüpfen, weil sie 90 Minuten auseinander eintrafen, obwohl sie dasselbe Ereignis beschreiben. Die Architektur muss Ereigniszeit (wann das Ereignis in der Welt stattfand) von Ingestionszeit (wann die Nachricht in der Pipeline eintraf) trennen und die gesamte zeitliche Korrelation auf der Ereigniszeit durchführen, die Ingestionszeit nur für Pipeline-Leistungsmonitoring verwenden.

Stream-Ingestions-Architektur – Kafka versus Pulsar für Intelligence-Feeds, Schema-Registry für heterogene Nachrichtentypen, Umgang mit Backpressure

Die Stream-Ingestion-Schicht muss Nachrichten verkraften, die mit Raten von wenigen HUMINT-Berichten pro Stunde bis zu Millionen SIGINT-Datensätzen pro Stunde aus einem einzelnen Erfassungssystem eintreffen – alle in dieselbe Fusionspipeline fließend. Das Design muss Burst-Verkehr von Quellen mit hoher Datenrate aufnehmen, ohne diesen Backpressure auf Quellen mit niedriger Datenrate und hoher Priorität anzuwenden – ein HUMINT-Bericht, der in einem Burst neben einer SIGINT-Flut eintrifft, darf nicht verzögert werden, weil die Pipeline gesättigt ist.

Die primäre architektonische Entscheidung auf dieser Schicht liegt zwischen Apache Kafka und Apache Pulsar. Beide sind verteilt, fehlertolerant und im Maßstab verteidigungsreifer Systeme kampferprobt. Kafka hat ein größeres Ökosystem und eine engere Integration mit Stream-Processing-Frameworks – Kafka Streams und Apache Flink haben beide erstklassige Kafka-Source-Konnektoren. Pulsar bietet native Multi-Tenancy, Topic-Isolation pro Namespace und eine getrennte Compute-Storage-Architektur. Für eine Single-Tenant-Fusionsplattform innerhalb einer Einstufungsdomäne ist Kafka die pragmatische Wahl. Für eine Plattform, die Feeds nach Einstufungsstufe isolieren, abgekoppelte vorgeschobene Knoten unterstützen muss, die asynchron zu einem rückwärtigen Cluster synchronisieren, oder mehrere Mandantenorganisationen bedienen muss, liefert Pulsars Architektur sauberere Isolationsprimitiven ohne Ad-hoc-Workarounds.

Unabhängig von der Broker-Wahl muss die Topic-Struktur ein Topic pro Quelltyp durchsetzen, nicht ein Topic pro INT-Disziplin:

# Topic-Namenskonvention: {classification}.{int-type}.{source-id}.raw ts.sigint.comint-system-alpha.raw ts.sigint.elint-collection-bravo.raw ts.imint.uav-sensor-charlie.raw ts.imint.sat-proc-delta.raw ts.humint.field-reports.raw ts.osint.ais-feed.raw ts.osint.social-monitor.raw # Normalisierte Ausgabe-Topics (nach dem Adapter) ts.fusion.observations.normalized ts.fusion.entities.enriched ts.fusion.correlations.output

Eine Schema-Registry ist für die normalisierten Ausgabe-Topics zwingend. Ohne durchgesetzte Schemas kann eine einzige fehlerhafte Nachricht eines beliebigen Adapters den Deserialisierungskontext eines nachgelagerten Konsumenten verderben und die gesamte Fusionspipeline zum Stillstand bringen. Die Registry erzwingt Avro- oder Protobuf-Schemas bei jedem Schreibvorgang auf Fusion-Topics und lehnt Nachrichten ab, die die Validierung nicht bestehen, bevor sie den Broker erreichen. Schema-Kompatibilitätsregeln – BACKWARD, FORWARD oder FULL – müssen pro Topic danach gesetzt werden, wie sich Konsumenten weiterentwickeln. Für das normalisierte Beobachtungsschema ist BACKWARD-Kompatibilität angemessen: Neue Schemaversionen können optionale Felder hinzufügen, und alte Konsumenten, die neue Felder nicht kennen, funktionieren weiter korrekt.

Backpressure-Handling erfordert ratenbegrenzende Maßnahmen pro Quelltyp mit Prioritätsklassifizierung. Quellen mit hoher Priorität – SIGINT und IMINT aus Live-Erfassungssystemen – dürfen nie ratenbegrenzt werden. Quellen mit niedriger Priorität – Massen-OSINT-Aufnahme, historisches HUMINT-Laden – sollten explizite Prioritätsgewichte tragen, die es dem Broker erlauben, ihre Konsumenten zu drosseln, wenn der Durchsatz der Pipeline begrenzt ist. In Kafka wird dies über Consumer-Group-Quoten und Partitionierungsstrategien umgesetzt. In Pulsar bieten ratenbegrenzende Maßnahmen pro Namespace und Dispatch-Quoten eine äquivalente Kontrolle. Die Architekturmuster der Intelligence-Datenpipeline militärisch behandeln Warteschlangenmanagement und Consumer-Group-Entwurf im Detail.

Entity Resolution und Deduplizierung – Blocking-Strategien zur Generierung von Entitätskandidaten, ML-basiertes Ähnlichkeitsscoring, graphbasiertes Entitäts-Merging

Entity Resolution ist die Komponente, die einen Strom unabhängiger Beobachtungen – jede beschreibt ein erkanntes Objekt oder ein berichtetes Ereignis – in einen Satz vereinheitlichter Entitätsdatensätze überführt, in dem alle Beobachtungen desselben realen Objekts zusammengeführt sind. Sie ist die Komponente, die am schwersten richtig zu bekommen ist, und die am ehesten stillschlechtert: Ein System mit schwacher Entity Resolution stürzt nicht ab; es erzeugt ein Bild mit zu vielen Entitäten (fragmentierte Tracks) oder zu wenigen (falsche Zusammenführungen), und diese Fehler verstärken sich mit der Zeit, wenn die Fusion auf verderbtem Entitätszustand aufbaut.

Der naive Ansatz — jede eingehende Beobachtung mit jeder vorhandenen Entität zu vergleichen — ist in jeder realistischen Größenordnung rechnerisch nicht durchführbar. Ein ELINT-Erfassungssystem, das 10.000 Intercept-Datensätze pro Minute gegen einen Bestand von 50.000 aktiven Entitäts-Tracks erzeugt, würde vor jeder Ähnlichkeitsbewertung 500 Millionen Vergleiche pro Minute erfordern. Blocking-Strategien reduzieren dies auf eine beherrschbare Kandidatenmenge, indem sie die Struktur von Intelligence-Daten ausnutzen:

  • Geo-Zellen-Blocking — Jede Entität wird anhand ihres geschätzten Standorts in einem hexagonalen H3-Raster der Auflösungsstufe 9 (Zellen von etwa 0,1 km²) indiziert. Dieser einzelne Blocking-Schlüssel eliminiert über 99,9 % der Kandidatenpaare.
  • Zeitliches Blocking – beschränkt Kandidaten auf Entitäten, deren Gültigkeitszeitintervall ein konfigurierbares Fenster um die Ereigniszeit der Beobachtung überlappt. Für ein bewegliches Fahrzeug muss das Fenster die maximal plausible Geschwindigkeit zwischen letzter Beobachtung und aktuellem Beobachtungsort berücksichtigen – ein Kampfpanzer kann nicht 50 km in 5 Minuten zurücklegen. Zeitliches Blocking ohne Geo-Zellen-Blocking erzeugt für jede global aktive Entität enorme Kandidatenmengen; beide wirken zusammengesetzter Schlüssel.
  • Hard-Identifier-Blocking – fasst alle Datensätze, die eine deterministische Kennung teilen (IMSI, OCR-Ergebnis des Nummernschilds, biometrischer Hash, Mode-S-Transpondercode eines Luftfahrzeugs), unabhängig von Ort und Zeit in einem einzigen Kandidatencluster zusammen. Hard-Identifier umgehen alles andere Blocking und gelten als definitive Zusammenführungssignale, vorbehaltlich einer Deduplizierungsprüfung der Kennung selbst.
  • INT-Typ-Affinitäts-Blocking – bestimmte INT-übergreifende Paare sind strukturell unwahrscheinlich passend und sollten nicht bewertet werden. Eine maritime SIGINT-Emissionsbeobachtung sollte nicht gegen einen Landfahrzeug-IMINT-Track bewertet werden. Affinitätsregeln, pro Entitätstyp definiert, eliminieren strukturell unplausible Kandidatenpaare vor dem Scoring.

Die Ähnlichkeitsbewertung der Kandidatenpaare verwendet ein Gradient-Boosting-Modell (XGBoost oder LightGBM), das auf annotierten Treffer-/Nicht-Treffer-Paaren aus historischen Intelligence-Daten trainiert wurde. Das Modell gibt eine Trefferwahrscheinlichkeit in [0, 1] aus. Paare oberhalb eines hohen Schwellenwerts (typischerweise 0,85–0,92) werden automatisch zusammengeführt.

Graphbasiertes Entitäts-Merging behandelt den Mehrfachfall – bei dem drei oder mehr Beobachtungen alle auf dieselbe Entität aufgelöst werden müssen. Ein Graph wird gepflegt, in dem Knoten Beobachtungsdatensätze sind und Kanten Zusammenführungsentscheidungen mit zugehörigen Konfidenzbewertungen. Zusammenhangskomponenten des Graphen stellen Kandidaten-Entitätscluster dar. Der Golden Record jedes Clusters wird berechnet, indem die definierte Merging-Richtlinie auf alle beitragenden Beobachtungen angewendet wird. Wird eine neue Kante mit hoher Konfidenz hinzugefügt, die zuvor disjunkte Komponenten verbindet, werden die Komponenten zusammengeführt und ihre Golden Records kombiniert. Die Graphdarstellung ermöglicht auch Split-Operationen: Das Entfernen einer Kante mit hoher Konfidenz und das Neuberechnen der Zusammenhangskomponenten ist der Mechanismus zur Korrektur einer falschen Zusammenführung.

Architekturreferenz
Entity-Resolution-Pipeline – Stufenfluss
1
Blocking – Kandidatenpaare über Geo-Zellen-, zeitliche und Hard-Identifier-Schlüssel erzeugen. Recall-Ziel: über 99,5 % der echten Treffer im Kandidatensatz.
2
Merkmalsextraktion – räumliche Distanz, Zeitdelta, Attributüberlappung und INT-Typ-Kompatibilität für jedes Kandidatenpaar berechnen.
3
ML-Scoring – Gradient-Boosting-Modell gibt Trefferwahrscheinlichkeit pro Paar aus. Hard-Identifier-Paare umgehen das Scoring und gehen direkt zur Zusammenführung.
4
Schwellenwert-Routing – Score ≥ 0,88: Auto-Merge. 0,55–0,87: Analystenprüfwarteschlange. < 0,55: verwerfen (getrennte Entitäten).
5
Graph-Merge – Entitätsgraph mit neuen Kanten aktualisieren; Golden Records der Zusammenhangskomponenten neu berechnen; aktualisierte Entitäten an den angereicherten Entitätsstrom ausgeben.
Fünfstufige Entity-Resolution-Pipeline von der Kandidatengenerierung bis zur Veröffentlichung des Golden Record.

Entwurf der Korrelations-Engine – fensterbasierte Korrelation (zeitliche Nähe), räumliche Korrelation (Geo-Zellen-Bucketing), semantische Korrelation (Entitätsattribut-Matching)

Wo Entity Resolution fragt: „Beziehen sich diese Beobachtungen auf dasselbe Objekt?“, fragt die Korrelations-Engine: „Bilden diese Ereignisse mit verschiedenen Objekten ein aussagekräftiges Muster?“. Ein Fahrzeug in der Nähe eines Logistikdepots, 20 Minuten später dasselbe Fahrzeug an einer Betankungsstelle, gefolgt von einem SIGINT-Intercept eines Funkspruchs, der zu einer Einheitspositionsmeldung von der Betankungsstelle passt – diese drei Ereignisse betreffen dasselbe Fahrzeug, beschreiben aber auch ein Lagemuster (Nachschubtätigkeit), das analytisch bedeutsamer ist als jede einzelne Beobachtung. Die Korrelations-Engine erzeugt dieses Intelligence-Objekt höherer Ordnung.

Korrelation arbeitet gleichzeitig auf drei Ebenen:

Zeitliche Korrelation gruppiert Ereignisse nach ihrem Ereigniszeitstempel in Fenster und sucht in jedem Fenster nach Ko-Okkurrenz-Mustern. Die Fensterdefinition ist pro Regel konfigurierbar: Eine Regel, die gleichzeitigen Beginn von Störungen (Jamming) und Unterbrechung eigener Kommunikation erkennt, kann ein 30-Sekunden-Fenster verwenden; eine Regel, die ein Fahrzeug an einem Wegpunkt und später ein anderes Fahrzeug am selben Wegpunkt erkennt, kann ein 2-Stunden-Fenster verwenden. Gleitende Fenster (zur Hälfte der Fensterdauer überlappend) stellen sicher, dass Ereignisse an Fenstergrenzen nicht verpasst werden. Apache Flinks Event-Time-Windowing mit Watermarks ist die Standardimplementierung, weil es verspätetes Eintreffen von Ereignissen korrekt behandelt – entscheidend für eine Pipeline, in der IMINT und HUMINT sehr unterschiedliche Ingestions-Latenzen haben.

Räumliche Korrelation gruppiert Entitäten nach ihrer geschätzten Position über Geo-Zellen-Bucketing mit einer Auflösung, die auf die räumliche Skala der Korrelationsregel kalibriert ist. H3-Auflösung 8 (etwa 0,7 km²) eignet sich zum Nachweis von Fahrzeugen, die in derselben Zone operieren; H3-Auflösung 6 (etwa 36 km²) zum Nachweis von Aktivitätsmustern über eine Region. Anders als das Geo-Zellen-Blocking der Entity Resolution (das hohe Recall braucht), benötigt das räumliche Bucketing der Korrelation regeldefinierte Precision: Eine Korrelationsregel, die Ko-Location eines Kommandofahrzeugs mit einem Logistikfahrzeug erkennt, sollte eine engere Zelle verwenden als eine Regel, die flächenweite Versorgungstätigkeit erkennt. Regeln kodieren ihren eigenen räumlichen Auflösungsparameter, statt eine globale Einstellung zu erben.

Semantische Korrelation gleicht Entitäten anhand von Attributwerten ab, nicht anhand räumlicher oder zeitlicher Nähe. Eine als Luftverteidigungsradar klassifizierte Entität, die zu senden beginnt, korreliert mit einer als Kampfflugzeug klassifizierten Entität, die in die Erfassungszone des Radars eintritt – die Korrelation wird von Attributsemantik getrieben (Radartyp versus Flugzeugtyp und Trajektorie), nicht davon, dass sie am selben Ort sind. Semantische Regeln kodieren Attributprädikate über Entitätstypen: entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Diese Prädikatsausdrücke wertet der Stream-Prozessor gegen jedes Entitätsaktualisierungsereignis aus; wenn alle Prädikate einer Regel innerhalb des Fensters feuern, feuert die Korrelation.

Korrelationsregeln werden als deklarative Definitionen in einer Regelregistry gespeichert, nicht als fest verdrahtete Logik. Das ermöglicht Intelligence-Analysten, ohne Beteiligung der Entwicklung neue Regeln zu erstellen, und erlaubt Regeländerungen ohne Neubereitstellung der Korrelations-Engine:

# Beispiel einer Korrelationsregel-Definition (YAML) rule_id: RESUPPLY-PATTERN-001 name: "Erkennung einer Fahrzeug-Nachschubsequenz" description: "Erkennt ein Fahrzeug, das einen Logistikknoten und danach innerhalb des Fensters eine Betankungsstelle aufsucht" confidence_weight: 0,72 spatial_resolution: H3_LEVEL_8 temporal_window_minutes: 90 events: - alias: VEH entity_type: EQUIPMENT attribute_predicates: - "attributes.platform_class IN [APC, IFV, TRUCK, LOGISTICS_VEHICLE]" - alias: NODE_VISIT entity_type: EVENT attribute_predicates: - "attributes.event_class == LOCATION_VISIT" - "attributes.location_type IN [LOGISTICS_NODE, DEPOT, FUEL_POINT]" linked_entity: VEH temporal_order: AFTER VEH.last_seen output: entity_type: SITUATION situation_class: RESUPPLY_ACTIVITY contributing_entity_refs: [VEH.entity_id, NODE_VISIT.entity_id]

Jede gefeuerte Korrelation erzeugt eine Situation-Entität – ein neues Intelligence-Objekt auf der JDL-Level-2-Schicht, das auf die beitragenden Entitäts-UUIDs verweist, die Regel-ID und das Regelkonfidenzgewicht trägt und zusammen mit den Standard-Entitätsaktualisierungen an den angereicherten Entitätsstrom veröffentlicht wird.

Konfidenzbewertung und Provenienz – Matrix aus Quellzuverlässigkeit × Informationsglaubwürdigkeit (NATO-Admiralty-System), Konfidenzweitergabe über fusionierte Entitäten

Jede Entität im fusionierten Bild trägt eine Konfidenzbewertung, doch Konfidenz in einem Multi-Source-Fusionssystem ist keine einzelne Zahl – sie ist ein Zusammensetzteil, das in mehrere Dimensionen zerlegt werden muss, um analytisch nützlich zu sein. Ein Score von 0,73, der aus drei bestätigenden SIGINT-Datensätzen entstand, bedeutet etwas sehr anderes als ein Score von 0,73, der aus einem unzuverlässigen HUMINT-Bericht und sonst nichts kam. Die Architektur muss die Zerlegung bewahren, nicht nur das Aggregat.

Das Konfidenzmodell legt drei Eingaben übereinander. Erstens das Gewicht der Quellzuverlässigkeit, abgeleitet aus der Admiralty-Note zur Quellzuverlässigkeit: A=1,0, B=0,8, C=0,6, D=0,4, E=0,2, F=0,1. Dieses Gewicht skaliert den Beitrag jeder Quellbeobachtung zur Fusionsberechnung. Zweitens das Gewicht der Informationsglaubwürdigkeit, abgeleitet aus der Admiralty-Glaubwürdigkeitsnote: 1=1,0, 2=0,8, 3=0,6, 4=0,4, 5=0,2, 6=0,1. Dieses Gewicht wird pro Beobachtung unabhängig von der Quellzuverlässigkeit angewendet, weil eine zuverlässige Quelle unsichere Informationen melden kann. Drittens der Quellenübereinstimmungswert – der Anteil unabhängig bestätigender Quellen, die beim Schlüsselattributwert übereinstimmen, gewichtet mit ihrer Quellzuverlässigkeit. Ein Positionswert, bestätigt von drei Quellen der Note A mit Informationsnoten B2, bewertet sich sehr anders als ein Wert, der von zwei Quellen der Note E mit Noten D4 bestätigt wird.

Die zusammengesetzte Konfidenz für ein Attribut ist:

# Konfidenzformel pro fusioniertem Attribut # Für jede beitragende Beobachtung i: # w_i = source_reliability_weight(admiralty_grade_A_to_F) # × info_credibility_weight(admiralty_grade_1_to_6) # # Gewichteter Übereinstimmungswert: # agreement = sum(w_i for i in corroborating sources) # / sum(w_i for i in all contributing sources) # # Fusionskonfidenz: # confidence = agreement × source_coverage_penalty # # wobei source_coverage_penalty Einzel-INT-Bestätigung abschmilzt: # 1,0 wenn ≥ 2 verschiedene INT-Typen bestätigen # 0,75 wenn genau 1 INT-Typ mit ≥ 2 Quellen # 0,5 wenn insgesamt genau 1 Quelle

Die Weitergabe von Konfidenz über abgeleitete Entitäten folgt einer Verwässerungsregel: Eine Situation-Entität, die die Korrelations-Engine aus zwei beitragenden Entitäts-Golden-Records ableitet, kann keine höhere Konfidenz haben als die beitragende Entität mit der niedrigeren Konfidenz. Konfidenz kann nur steigen, wenn zusätzliche unabhängige bestätigende Beobachtungen zu den beitragenden Entitäten hinzukommen. Das verhindert, dass die Korrelations-Engine Konfidenz künstlich aufbläht, indem sie Entitäten mit niedriger Qualität verknüpft.

Provenienz-Verweise werden als Kette gespeichert: Jeder Golden Record verweist auf die Beobachtungs-UUIDs, die zu ihm beigetragen haben; jede Beobachtung verweist auf ihre Quell-ID, ihr Erfassungssystem und ihre Admiralty-Noten. Die Kette ist unveränderlich – sie wird nie an Ort und Stelle aktualisiert. Wird eine beitragende Quelle später als unzuverlässig oder irreführend eingestuft, liefert die Kette die vollständige Menge von Entitäten, die unter Ausschluss der Beiträge dieser Quelle neu bewertet werden müssen. Der Rückruf einer Quelle ist eine Operation erster Klasse, kein Notfallverfahren.

Veröffentlichung des Intelligence-Bilds – Veröffentlichung angereicherter Entitäten an C2-Systeme über CoT/NIEM, Latenzziele für zeitkritische Intelligence

Der angereicherte Entitätsstrom ist die interne Darstellung. Die Veröffentlichung übersetzt diese Darstellung in die Wire-Formate, die C2-Systeme und nachgelagerte Konsumenten tatsächlich verstehen. Für die meisten Verteidigungseinsätze bedeutet das Cursor on Target (CoT) für Track-Daten und NIEM-basierte Nachrichtenformate für strukturierte Intelligence-Berichte.

Die CoT-Veröffentlichung bildet jede Aktualisierung eines angereicherten Entitäts-Updates auf ein CoT-Ereignis ab. Die Abbildung muss drei Aktualisierungstypen behandeln: Positionsaktualisierungen (neue Koordinaten mit aktualisierter Unsicherheit), Attributaktualisierungen (Konfidenzänderung, Änderung des Aktivitätszustands, Änderung der Zugehörigkeitsbewertung) und Entitäts-Lebenszyklusereignisse (Anlage der Entität, Retirement sowie Split-/Merge-Ereignisse). Positionsaktualisierungen sind einfach – sie übersetzen in ein CoT-Punktereignis mit der geschätzten Position der Entität und der Positionskonfidenz im CoT-Fehlerfeld. Attributaktualisierungen übersetzen in CoT-Remarks oder Detail-Element-Aktualisierungen der bestehenden Entität. Lebenszyklusereignisse – insbesondere Merge und Split – erfordern besondere Behandlung: Ein Merge-Ereignis beendet den CoT-Track der Entität mit niedrigerer Konfidenz und aktualisiert das CoT-Detail der überlebenden Entität mit Provenienzinformationen; ein Split-Ereignis erzeugt einen neuen CoT-Track für die neu getrennte Entität.

Das CoT-Stale-Time-Feld ist der natürliche Mechanismus für TTL-Management beim C2-Empfänger. Jedes veröffentlichte CoT-Ereignis setzt stale_time auf entity_publication_time + entity_TTL. Das empfangende C2-System (ATAK, CURSOR oder ähnlich) entfernt die Entität aus seiner Anzeige, wenn stale_time ohne Aktualisierung verstreicht. Das Fusionssystem muss sicherstellen, dass Entitäten mit aktiven Beobachtungen CoT-Aktualisierungsereignisse in einem Intervall kürzer als ihre TTL erhalten – typischerweise bei 50 % der TTL –, damit gültige Entitäten im Normalbetrieb nicht aus dem Bild verschwinden.

Latenzziele bestimmen, wie die Veröffentlichungsschicht implementiert werden muss. Für zeitkritische Targeting-Workflows muss die End-to-End-Latenz vom Sensorereignis bis zur C2-Anzeige unter 30 Sekunden liegen. Das zu erreichen erfordert: asynchrone, nicht blockierende Verarbeitungsarbeiter; parallelisierte CoT-Serialisierung über Entitätspartitionen; priorisierte Ausgabewarteschlangen, die beweglichen Tracks mit hoher Konfidenz Vorrang vor statischen Entitätsaktualisierungen geben; und direkte TCP-Multicast-Zustellung an C2-Empfänger statt REST-API-Polling. Für allgemeine Lageaufklärung auf operativer Ebene sind 60–120 Sekunden Latenz typischerweise akzeptabel, was einfachere synchrone Batch-Veröffentlichungsmuster ermöglicht.

Die NIEM-Veröffentlichung bedient Konsumenten von Intelligence-Berichten – Systeme, die strukturierte, maschinenlesbare Intelligence-Bewertungen brauchen statt Track-Daten. Eine von der Korrelations-Engine ausgegebene Situation-Entität wird als NIEM Intelligence Message veröffentlicht, mit den beitragenden Entitäts-UUIDs als Verweisen, der Situation-Klasse als Betreff und den Konfidenz- und Provenienzdaten im NIEM-Nachrichtenmetadatenblock. NIEM-Konsumenten sind domänenübergreifende Intelligence-Austauschplattformen, Interoperabilitäts-Gateways zu Systemen von Partnernationen und Archivsysteme, die strukturierte Provenienz für Audit-Compliance benötigen.

Umgang mit zeitlicher Unsicherheit und veralteter Intelligence – TTL-Management für Intelligence-Entitäten, Abfallkurven für Positions-/Aktivitätskonfidenz, Neu-Bewertungs-Auslöser

Intelligence ist verderblich. Eine Positionsmeldung für einen Fahrzeugtrack, die vor 20 Minuten korrekt war, ist es jetzt weniger – das Fahrzeug könnte sich bewegt haben. Eine Aktivitätsbewertung auf Basis eines einzelnen SIGINT-Intercepts von vor 4 Stunden bildet das aktuelle Verhalten möglicherweise nicht mehr ab. Ein Fusionssystem, das diese Degradation nicht modelliert und nicht an das veröffentlichte Bild weitergibt, veranlasst Analysten, Entscheidungen auf Basis veralteter Informationen mit hohen Konfidenzbewertungen zu treffen, die von älteren Beobachtungen erarbeitet wurden.

TTL-Management beginnt mit der TTL-Zuweisung bei der Anlage der Entität. TTL-Werte sind entitätstyp- und konfidenzstufenspezifisch:

  • Beweglicher Fahrzeugtrack mit hoher Konfidenz (Konfidenz ≥ 0,80, Mobilitätsklasse = WHEELED/TRACKED): TTL 8–15 Minuten
  • Beweglicher Track mit mittlerer Konfidenz (Konfidenz 0,50–0,79): TTL 4–8 Minuten
  • Vorläufiger Track mit niedriger Konfidenz (Konfidenz < 0,50): TTL 2–4 Minuten
  • Feste Einrichtung mit hoher Konfidenz (Konfidenz ≥ 0,80, Mobilitätsklasse = STATIC): TTL 24–72 Stunden
  • Personalentität (aktivitätsbasiert, nicht positionsbasiert): TTL 30–120 Minuten je nach Art der letzten Aktivität
  • Situation-Entität (abgeleitete Korrelation): TTL gleich der kürzesten TTL einer beliebigen beitragenden Entität, gedeckelt auf 60 Minuten

Konfidenzabfallkurven modellieren, wie Positions- und Aktivitätskonfidenz zwischen bestätigenden Beobachtungen degradieren. Statt eines binären Zustands aktiv/veraltet liefert die Abfallkurve eine stetige Konfidenzfunktion über die Zeit seit der letzten Beobachtung:

# Positionskonfidenz-Abfall – exponentielles Modell # c(t) = c_0 × exp(-λ × t) # wobei: # c_0 = Konfidenz zum Zeitpunkt der letzten bestätigenden Beobachtung # t = verstrichene Zeit seit der letzten Beobachtung (Sekunden) # λ = Abfallkonstante, entitätstypspezifisch # # Abfallkonstanten (beispielhaft): # TRACKED_VEHICLE: λ = 0,003 (Halbwertszeit ≈ 3,8 min) # WHEELED_VEHICLE: λ = 0,004 (Halbwertszeit ≈ 2,9 min) # SLOW_MOVER: λ = 0,001 (Halbwertszeit ≈ 11,5 min) # STATIC_SITE: λ = 0,00001 (Halbwertszeit ≈ 19 Stunden) # MARITIME_SURFACE: λ = 0,002 (Halbwertszeit ≈ 5,8 min) # # Die Entität geht in STALE über, wenn c(t) < staleness_threshold # (typischerweise 0,15 für bewegliche Tracks, 0,05 für statische Standorte)

Neu-Bewertungs-Auslöser feuern, wenn eine neue Beobachtung eintrifft, die räumlich und zeitlich zu einer veralteten Entität passt. Statt für die neue Beobachtung eine neue Entität anzulegen, leitet der Auslöser sie gegen die veraltete Entität als Kandidaten durch die Entity-Resolution-Pipeline. Übersteigt die Trefferkonfidenz den Zusammenführungsschwellenwert, aktualisiert die neue Beobachtung die veraltete Entität: Die TTL-Uhr wird zurückgesetzt, die Konfidenz aus der neuen Beobachtung neu berechnet (möglicherweise nach oben vom abgefallenen Wert, wenn die neue Beobachtung starke Konfidenz hat), und die Entität geht von STALE zurück in den Status ACTIVE. Die Aktualisierung wird als Update-Ereignis im Audit-Trail der Entität protokolliert.

Das Abfallmodell muss auch an C2-Konsumenten kommuniziert werden, nicht nur intern angewendet. Eine Position mit hoher Konfidenz an CoT zu veröffentlichen, ohne zu signalisieren, dass die Position 18 Minuten alt ist, führt dazu, dass die C2-Anzeige ein scharfes, zuversichtliches Track-Symbol zeigt, das der Analyst als Echtzeitbeobachtung deuten kann. Zwei Mechanismen adressieren das: Das CoT-stale_time-Feld (bereits besprochen) stellt sicher, dass die Entität aus der Anzeige verschwindet, wenn sie definitiv veraltet ist; und ein Alter-seit-letzter-Beobachtung-Feld im CoT-Detail-Element gibt dem Analysten Echtzeit-Sichtbarkeit darauf, wie alt die zugrunde liegende Beobachtung ist, auch bei Entitäten, die ihre Stale-Time noch nicht erreicht haben. Manche C2-Systeme nutzen dieses Feld, um die visuelle Konfidenzdarstellung zu modulieren – Deckkraft oder Größe des Track-Symbols als Funktion des Beobachtungsalters.

Zusammen bilden die sieben in diesem Artikel beschriebenen architektonischen Komponenten – heterogene Stream-Ingestion, schemadurchgesetzte Normalisierung, Blocking-plus-ML-Entity Resolution, mehrstufige Korrelations-Engine, geschichtete Konfidenzbewertung, CoT/NIEM-Veröffentlichung und TTL-Abfallmanagement – eine vollständige Echtzeit-Multi-Source-Intelligence-Fusionsplattform. Keine dieser Komponenten ist für sich genommen neu. Was die Architektur produktionsreif macht, ist der explizite Entwurf der Schnittstellen zwischen ihnen: das kanonische Beobachtungsschema, das die Normalisierung erzeugt und Entity Resolution verbraucht; das Entitätsgraphformat, das Entity Resolution erzeugt und die Korrelations-Engine verbraucht; der angereicherte Entitätsstrom, den sowohl Entity Resolution als auch die Korrelations-Engine schreiben und die Veröffentlichungsschicht liest. Ein System, in dem diese Schnittstellen implizit oder undokumentiert sind – in dem jede Komponente ein bestimmtes Verhalten ihres Upstream annimmt – ist genau dort brüchig, wo Intelligence-Daten in ihrem Charakter am variabelsten sind.