Teil 1 hat die Konformitäts-Hülle festgelegt. Teil 2 implementiert die taktischen Datenlinks, die die meisten NATO-interoperablen Plattformen verankern: Link 16 für Luft- und Luftverteidigungsoperationen, Cursor on Target für den taktischen Edge, MIP4-IES für den C2-Austausch der Bodentruppen und STANAG 4559 für den ISR-Produktaustausch. Jeder hat sein eigenes Engineering-Muster, seine eigene Konformitätsdisziplin und seine eigenen Fehlermodi. Teil 2 führt durch sie hindurch.

Die architektonische Rahmung steht in Der vollständige Leitfaden zur NATO-Interoperabilität. Die begleitende Serie zur C2-Fusion-Engine unter Aufbau einer Verteidigungs-Fusion-Pipeline behandelt die Adapter-Schicht, die diese Datenlinks innerhalb der Plattform konsumiert.

Link 16 ist der kanonische taktische NATO-Datenlink für Luft- und Luftverteidigung. Er ist auch der von Software-Ingenieuren, die in die Verteidigung einsteigen, am häufigsten missverstandene Standard. Das Protokoll ist zeitschlitzbasiert (Time Division Multiple Access), der Nachrichtenkatalog (J-series-Nachrichten) ist klassifiziert, die Teilnahmeregeln sind bandbreitenverwaltet, und die Integration erfolgt fast immer über ein Hardware-MIDS-Terminal statt über ein Software-Radio.

Das pragmatische Implementierungsmuster für Software:

Integration über die MIDS-Terminal-API. Das Hardware-Terminal behandelt das zeitschlitzbasierte Protokoll; die Software behandelt das Nachrichten-Marshalling darüber. Das Terminal exponiert eine vom Anbieter bereitgestellte API — SIMPLE (Standard Interface for Multiple Platform Link Evaluation) ist die häufigste — über die die Software J-series-Nachrichten zur Übertragung übermittelt und eingehende J-series zur Verarbeitung empfängt.

Behandeln Sie die SIMPLE-Schnittstelle als stabilen Vertrag. Die Schnittstelle entwickelt sich langsam; der Nachrichtenkatalog entwickelt sich schneller. Versionieren Sie die Integration anhand der Ausgaben des Nachrichtenkatalogs, nicht der SIMPLE-Version. Katalog-Updates sind geplante Ereignisse mit eigenen Konformitäts-Nachprüfungen.

Marshallen Sie Nachrichten mit strikter Typisierung. J-series-Nachrichten haben starre Strukturen, die im klassifizierten Katalog definiert sind. Implementieren Sie sie als codegenerierte Typen (wo der Katalogzugriff es erlaubt) oder als handgeschriebene Typen mit umfangreicher Validierung. Lockere Typisierung im Link-16-Marshalling ist die Hauptursache der meisten CWIX-Konformitätsausfälle.

Ausgehend puffern, eingehend validieren. Ausgehende Nachrichten werden nach Priorität in die Warteschlange gestellt; die Plattform darf das Terminal nicht überfluten. Eingehende Nachrichten werden vor der Weiterleitung gegen den Katalog validiert; fehlgeformte J-series werden mit strukturiertem Logging zurückgewiesen, nicht stillschweigend durchgereicht.

Die tiefere Engineering-Sicht, einschließlich der Integrationstopologie und der häufigsten Fallstricke, steht in Link 16 Taktische Datenlinks: Engineering-Sicht.

Schritt 2: Cursor-on-Target-Integration

CoT ist die De-facto-taktische Lingua franca außerhalb formeller NATO-Kataloge. Entstanden in der U.S. Air Force, übernommen über das ATAK/WinTAK-Ökosystem hinweg, zunehmend in Koalitionsoperationen erforderlich, unabhängig vom formellen NATO-Status. Eine NATO-interoperable Plattform, die neben U.S.- oder ATAK-ausgestatteten alliierten Streitkräften operiert, wird auf CoT treffen, ob die formelle Konformitäts-Hülle es einschließt oder nicht.

CoT ist technisch einfacher als Link 16 — XML-basiert, wohldefiniertes Schema, kein klassifizierter Nachrichtenkatalog, kein zeitschlitzbasiertes Protokoll. Die erforderliche Engineering-Strenge ist dieselbe.

Das Implementierungsmuster:

Schema-Validierung an der Grenze. Jede eingehende CoT-Nachricht wird vor der weiteren Verarbeitung gegen das Schema validiert. Fehlgeformte Nachrichten werden laut protokolliert und zurückgewiesen; stillschweigende Akzeptanz ist die falsche Voreinstellung.

Strikte Zeitstempel-Behandlung. CoT-Nachrichten tragen Beobachtungszeit, Nachrichten-Veraltungszeit und Veraltungszeit. Die Drei-Zeitstempel-Disziplin aus früheren Engineering-Walkthroughs gilt — die Beobachtungszeit steuert die Korrelation, die Veraltungszeit steuert die Lebenszyklus-Entscheidungen, und sie zu verwechseln ist eine wiederkehrende Bug-Quelle.

Konservatives Parsen optionaler Felder. CoT-Erweiterungen sind häufig; nicht alle Erweiterungen sind dokumentiert. Parsen Sie, was dokumentiert ist; ignorieren Sie, was nicht ist (mit Logging); stürzen Sie niemals bei unerwartetem Inhalt ab.

Transportflexibilität. CoT bewegt sich über Multicast-UDP, TCP Punkt-zu-Punkt, TCP-via-TAK-Server und (zunehmend) MQTT. Die Adapter-Schicht berücksichtigt alle vier mit einem gemeinsamen Verarbeitungspfad nachgelagert.

Die detaillierte Engineering-Behandlung von CoT steht in Cursor on Target (CoT): Der XML-Standard hinter taktischen Lagebewusstseins-Apps. Die Perspektive der ATAK-Plugin-Entwicklung steht in ATAK-Plugin-Entwicklung.

Schritt 3: MIP4-IES-Implementierung

Für den Austausch mit nationalen C2-Systemen oberhalb der Brigadeebene ist MIP4-IES das Schema. Es ist dicht, versionsgepflegt und unnachgiebig in Konformitätstests. Das Multilateral Interoperability Programme definiert das Modell; die Information Exchange Specification serialisiert es.

Das Engineering-Muster, das erfolgreich ist:

Behandeln Sie MIP4 als strikte Schnittstelle, nicht als internes Modell. Das interne Datenmodell der Plattform ist, was auch immer das Engineering-Team entwirft; MIP4 ist das Drahtformat, das die Plattform an der Koalitionsgrenze spricht. Die Abbildung zwischen ihnen ist bidirektional und verlustfrei für operativ signifikante Felder.

Round-Trip-Erhaltung ist der Test. Eine MIP4-Nachricht, die aus der Plattform heraus marshallt und dann wieder zurück unmarshallt wird, muss dasselbe interne Modell erzeugen (modulo absichtliche Kanonisierung). Round-Trip-Fehler decken verlustbehaftete Abbildungen, Typumwandlungs-Bugs und Feld-Aliasing-Fehler auf.

Schema-getriebene Codegenerierung. Das MIP4-IES-Schema ist groß genug, dass handgeschriebener Marshalling-Code abdriftet. Generieren Sie die Typen aus dem veröffentlichten Schema; pflegen Sie den Mapping-Code separat und überprüfen Sie ihn explizit.

Versions-Pinning mit expliziten Übergängen. MIP4-Ausgaben ändern sich. Die Plattform pinnt auf eine spezifische Ausgabe für ihren aktuellen operativen Einsatz; Übergänge sind geplante Projekte mit Konformitäts-Nachtests.

Die tiefe Engineering-Sicht von MIP4-IES, einschließlich der Datenmodell-Anatomie und der Realität der Konformitätstests, steht in MIP4-IES: Der NATO-Bodenstandard.

Schritt 4: STANAG-4559-ISR-Austausch

STANAG 4559 (NSILI — NATO Standard ISR Library Interface) regelt den Austausch von ISR-Bildgebung und -Produkten über Koalitions-C2-Plattformen hinweg. Erforderlich für jede Plattform, die nationale Bildquellen in einem Koalitionskontext konsumiert oder produziert.

Die Implementierungsrealität:

Zuerst die Konsumentenseite. Die meisten Verteidigungssoftware-Programme sind NSILI-Konsumenten — sie fragen Koalitions-Bildbibliotheken ab und integrieren die Ergebnisse — statt NSILI-Anbieter. Die konsumentenseitige Schnittstelle ist wohldefiniert und handhabbar; die anbieterseitige Implementierung ist ein gewichtigeres Programm mit zusätzlichem Akkreditierungsaufwand.

Bandbreitenbewusster Abruf. ISR-Bildgebung ist groß. Der Abruf über taktische Links muss bandbreitenbewusst sein — Vorschau-Thumbnails zuerst, volle Auflösung auf Anfrage des Bedieners, progressiver Download für die größten Produkte. Die UI der Plattform stellt den Bandbreitenzustand dar, damit die Bediener den Trade-off verstehen.

Trennung des Bilddatenspeichers. Abgerufene Bildgebung lebt in einem dedizierten Objektspeicher, nicht in der operativen Spur-Datenbank. Metadaten bilden Bilder auf den Spur-Kontext ab; die Bilder selbst werden referenziert, nicht eingebettet.

Klassifikationskennzeichnung auf Bildgebung. Abgerufene Bildgebung trägt die Quellklassifikation gemäß STANAG 4774/4778. Die Klassifikation folgt der Bildgebung durch die Plattform — Anzeige-Schicht, Audit-Trail, nachgelagerte Analytik. Die Bindung „der Bequemlichkeit halber" zu entfernen ist genau die Art von Abkürzung, nach der Akkreditierungsprüfer gezielt suchen; Teil 3 dieser Serie behandelt die Disziplin im Detail.

Das tiefere STANAG-4559-Implementierungsmuster steht in STANAG 4559 Implementierung: NSILI in der Praxis.

Schritt 5: ADatP-34-Profil-Bindung

Die einzelnen Datenlinks — Link 16, CoT, MIP4, STANAG 4559 — implementieren spezifische Standards. Die ADatP-34-Profil-Ausrichtung erfordert, dass die Plattform die richtigen Kombinationen dieser Standards implementiert und dass die Kombinationen die Interoperabilitätsszenarien des Profils erfüllen.

Die Disziplin der Profil-Bindung:

Profilgetriebene Testszenarien. Für jedes ADatP-34-Profil, das die Plattform anvisiert, enthält die Konformitäts-Test-Suite Szenarien, die die Datenlinks in Kombination ausüben. Ein Szenario könnte erfordern: Empfang einer Link-16-Luftspur-Aktualisierung, Korrelation mit einer CoT-Bodenspur aus ATAK, NSILI-Abfrage nach Gebietsbildgebung, Fusion aller drei in eine einzige COP-Anzeige. Das Szenario testet die Kombination, nicht die einzelnen Standards.

Profilgetriebene Nachrichtenkataloge. Das Profil definiert, welche J-series-Nachrichten erforderlich sind, welche MIP4-Nachrichtentypen ausgetauscht werden müssen, welche CoT-Erweiterungen erwartet werden. Die Plattform implementiert die erforderliche Teilmenge, nicht den gesamten Katalog.

Verfolgung der Profil-Evolution. ADatP-34-Profile entwickeln sich. Die Plattform verfolgt das aktuelle operative Profil und das Profil der nächsten Spirale. Engineering-Arbeit, die auf das aktuelle Profil zielt, aber das nächste antizipiert, ist die Disziplin, die Versionsübergänge überlebt.

Kernerkenntnis: Konformität ist profil-geformt, nicht standard-geformt. Eine Plattform, die jeden erforderlichen Standard implementiert, aber sie nicht gemäß den Szenarien des Profils integriert, wird Konformitätstests nicht bestehen. Bauen Sie die Implementierung ab Sprint eins gegen das Profil, nicht gegen die Standards in Isolation.

Schritt 6: Bilaterale und Nicht-NATO-Brücken

Die Plattformen, die in echten Koalitions-Einsätzen operieren, brauchen Brücken jenseits des NATO-Katalogs. Ukrainische Delta-Integration, FVEY-only-Protokolle, partner-spezifische Erweiterungen — jede ist eine Brücke, die neben den formellen NATO-Datenlinks sitzt.

Das Engineering-Muster des Delta-Formats steht in Delta-Format und ukrainische Militärintegration. Die breiteren Muster des Koalitions-Austauschs, einschließlich der politischen Überlegungen, stehen in Herausforderungen des Koalitions-Datenaustauschs.

Die architektonische Regel: bilaterale Brücken sind separate Adapter, keine Modifikationen am NATO-Datenlink-Code. Eine Brücke zu Delta berührt nicht das Link-16-Marshalling; eine Brücke zu einem U.S.-nationalen Protokoll berührt nicht die CoT-Verarbeitung. Adapter-Isolation erstreckt sich über Protokolle hinweg, nicht nur über Sensortypen.

Schritt 7: Bauen Sie den Konformitäts-Harness frühzeitig

Konformitätstests sind die Arbeit, die Plattformen, die CWIX bestehen, von Plattformen, die scheitern, unterscheidet. Der Harness, der diese Tests ausführt, ist eine Engineering-Infrastruktur, die ebenso bedeutsam ist wie die Plattform selbst.

Die Harness-Komponenten:

  • Test-Suites pro Standard. Link-16-J-series-Nachrichten-Round-Trip; CoT-Wohlgeformtheit und semantische Korrektheit; MIP4-Entitäten-Austausch und -Round-Trip; STANAG-4559-Abfrage, -Abruf und -Metadaten-Mapping. Jede Suite ist automatisiert, in CI gegatet und erzeugt strukturierte Berichte.
  • Wiedergabe aufgezeichneter Daten. Aufgezeichneter Drahtverkehr aus echten Übungen und operativen Einsätzen wird gegen die Plattform wiedergegeben. Ground Truth für Regressionstests.
  • Partner-System-Simulatoren. Wo echte Partner-Systeme für Unit-Tests nicht verfügbar sind, treten Simulatoren an ihre Stelle. Sie tauschen konforme Nachrichten mit der Plattform aus und verifizieren, dass die Antworten dem Standard entsprechen.
  • Szenario-basierte Integrationstests. ADatP-34-Profilszenarien werden End-to-End ausgeübt. Die Plattform empfängt Eingaben, führt Fusion durch, produziert Ausgaben, die der Test-Harness gegen die erwartete Ground Truth validiert.
  • CWIX-Vorbereitungs-Tracking. Testfälle, die die Plattform bei CWIX einzureichen plant, werden separat verfolgt, mit Pass-Fail-Status sichtbar für die Programmleitung deutlich vor der Übung.

Die Kosten, diese Disziplin früh aufzubauen, sind real, aber begrenzt; die Kosten des Überspringens manifestieren sich als mehrmonatige Verzögerungen während der eigentlichen Konformitäts-Periode. Programme, die NATO-interoperable Plattformen pünktlich ausliefern, sind Programme, die den Konformitäts-Harness im ersten Jahr gebaut haben.

Wie es weitergeht

Teil 2 hat die taktischen Datenlinks implementiert. Link 16 über das MIDS-Terminal, CoT über den schema-validierenden Adapter, MIP4-IES über die Round-Trip-erhaltende Abbildung, STANAG 4559 über die konsumentenseitige Abfrage-Schnittstelle, alles zusammengebunden durch das ADatP-34-Profil und ausgeübt durch den Konformitäts-Harness.

Teil 3 behandelt die Klassifikations- und Freigabe-Maschinerie — STANAG-4774/4778-Bindung, Implementierung der Policy-Engine, Datenflüsse über Enklaven hinweg und die Koalitions-Freigabe-Disziplin, die die Plattform in klassifizierten Kontexten einsatzfähig macht.