Praxis-Leitfaden zur Umsetzung der NATO-Interoperabilität, Teil 1: STANAG-Auswahl und ADatP-34-Profilausrichtung

Die folgenreichste Einzelentscheidung in einem NATO-interoperablen Verteidigungssoftware-Programm ist, welche STANAGs implementiert werden — und entscheidend, welche nicht. Die Liste der NATO-Standardisierungsvereinbarungen umfasst Tausende; die für eine konkrete Plattform relevante Teilmenge ist begrenzt, aber von außen niemals offensichtlich. Ein Programm, das einen zu schmalen STANAG-Envelope wählt, scheitert sechs Monate nach Beginn am Koalitionseinsatz; ein Programm, das einen zu breiten Envelope wählt, versenkt Engineering-Zeit in Konformitätsarbeit, für die es keinen operativen Abnehmer gibt. Diese vierteilige Serie zeigt, wie diese Entscheidungen gut getroffen werden. Teil 1 behandelt das Fundament: STANAG-Auswahl und ADatP-34-Profilausrichtung.

Die architektonische Einordnung dieser Serie steht im Vollständigen Leitfaden zur NATO-Interoperabilität. Der begleitende Engineering-Praxis-Leitfaden für die C2-Plattform, die diese Standards konsumiert, steht in Aufbau eines C2-Systems von Grund auf. Diese Serie konzentriert sich eng auf das Interop-Subsystem.

Schritt 1: Den Konformitäts-Envelope zuerst festlegen — vor allem anderen

Der Konformitäts-Envelope ist die Menge der STANAGs, deren Implementierung sich die Plattform verpflichtet. Der Envelope ist ebenso sehr ein Beschaffungs- wie ein Engineering-Dokument — er erscheint in RFP-Antworten, in Akkreditierungsunterlagen und in der Festlegung des Umfangs von Koalitionsübungen. Wer ihn früh richtig setzt, hat klare Grenzen für die Engineering-Arbeit; wer ihn falsch setzt, sieht den Arbeitsumfang während der gesamten Plattformlebensdauer unter dem Team wegrutschen.

Die Fragen, die den Envelope definieren:

• Führungsebene. Brigadeebene und darunter hat andere STANAG-Prioritäten als Korpsebene oder strategische Ebene. Eine taktische Plattform muss Link 16 und CoT sprechen; eine strategische Plattform braucht möglicherweise keines von beidem, muss aber MIP4 und den breiteren Stabskatalog beherrschen.
• Domäne. Land, See, Luft, Joint oder Multi-Domain. Jede zieht unterschiedliche STANAG-Familien nach sich — Luftverteidigung bringt Link 16 sowie die umgebenden Zeitverteilungs- und Nachrichtenformat-STANAGs; maritim bringt COMPD und AIS-Integration; Boden bringt MIP4-IES.
• Koalitionspartner. Eine Plattform, die bilateral mit den USA arbeitet, hat andere Anforderungen als eine, die multilateral NATO-weit operiert. Bilaterale Beziehungen funktionieren oft mit engeren Teilmengen; multilateraler Koalitionseinsatz verlangt die breiteren ADatP-34-Profile.
• Klassifikationsobergrenze. Höhere Klassifikationsstufen ziehen verbindliche STANAG-4774/4778-Anforderungen nach sich, die Plattformen niedrigerer Klassifikation aufschieben können.
• Zeithorizont. Eine Plattform, die in zwei Jahren eingeführt wird, kann auf die aktuellen STANAG-Editionen abzielen; eine Plattform mit Einführung in fünf Jahren sollte die nächste Spirale verfolgen und den Versionsübergang einplanen.

Schreiben Sie die Antworten auf. Versehen Sie jedes Architektur-Ticket mit dem Tag, welcher Envelope-Entscheidung es dient. Das häufigste Fehlermuster in NATO-Interop-Programmen ist stille Envelope-Verschiebung — ein Programm zielt anfangs auf „taktische NATO-Interop" und implementiert am Ende jeden in irgendeiner RFI-Antwort genannten STANAG, ohne Begründung, welche davon operativ erforderlich sind.

Schritt 2: Den relevanten STANAG-Katalog aufbauen

Die NATO veröffentlicht Tausende von STANAGs; die softwarerelevante Teilmenge liegt im niedrigen dreistelligen Bereich; die für eine einzelne Plattform relevante Teilmenge umfasst meist 20–40. Bauen Sie den Katalog explizit auf.

Der Katalog erfasst zu jedem Kandidaten-STANAG:

• STANAG-Nummer und Edition. Die Version zählt: STANAG 4559 Edition 4 unterscheidet sich substanziell von Edition 3.
• Sprechender Name und Umfang. Was der Standard in operativen Begriffen regelt — nicht nur „Bildaustausch", sondern „Austausch nationaler ISR-Bilddaten zwischen Koalitions-C2-Systemen".
• Operativer Treiber. Warum diese Plattform ihn benötigt. „Im Beschaffungs-RFP gefordert" reicht nicht; der operative Anwendungsfall zählt ebenfalls.
• Schätzung des Umsetzungsaufwands. Grobe Kategorisierung: leicht (unter 2 Personenmonate), moderat (2–6), schwer (6–18), extrem (über 18). Die Schätzung ist grob; ihr Zweck ist, das Kosten-Nutzen-Verhältnis früh sichtbar zu machen.
• Quelle des Konformitätstests. Wo der Konformitätstest läuft — interne CI, NATO CWIX, bilateral mit einem bestimmten Partner, herstellergeliefertes Test-Harness.
• Umsetzungsstand. Nicht begonnen, in Arbeit, konformitätsgeprüft, ausgerollt.

Der Katalog ist ein lebendiges Dokument, abgelegt im Programm-Repository neben dem Quellcode, geprüft von Engineering- und Beschaffungsleitung. Die ausführliche Behandlung der wichtigsten STANAG-Familien — Link 16, MIP4, STANAG 4559, ADatP-34 — steht in NATO-Interoperabilitätsstandards für Software.

Schritt 3: An einem ADatP-34-Profil ausrichten

ADatP-34 ist der NATO-Master-Katalog der Interoperabilitätsprofile. Während einzelne STANAGs Standards isoliert definieren, definiert ADatP-34 Kombinationen — „taktisches Brigadeprofil", „operatives Korpsprofil", „strategisches Joint-Profil" —, welche die in realen operativen Kontexten gemeinsam genutzten Standards bündeln.

Die strategische Konsequenz: Richten Sie den Konformitäts-Envelope der Plattform an einem oder mehreren ADatP-34-Profilen aus, nicht an Ad-hoc-STANAG-Kombinationen. Eine Plattform, die behauptet „wir implementieren Link 16, MIP4 und STANAG 4559", ohne das ADatP-34-Profil zu nennen, dem sie sich zuordnet, stellt eine ungerichtete Behauptung auf, die Beschaffungsprüfer kaum verifizieren können.

Die detaillierte Aufschlüsselung von ADatP-34 — einschließlich struktureller Anatomie, Profilversionierungsmodell und Beschaffungsimplikationen — steht in ADatP-34-Datenstrukturen: Was NATO-Interoperabilität tatsächlich verlangt.

Für die durchgängige Beispielplattform — ein taktisches C2-System auf Brigadeebene, das auf einen Koalitionseinsatz auf Stufe NATO RESTRICTED zielt — ist das passende ADatP-34-Profil das taktisch-operative Profil, das Link 16, MIP4-IES, CoT, STANAG 4559 (Konsumentenseite) sowie den unterstützenden Katalog der Zeitverteilungs-, Nachrichtenformat- und Klassifikations-STANAGs bündelt. Andere Umfangsentscheidungen würden die Profilwahl verschieben, nicht aber die architektonische Begründung.

Schritt 4: Entscheidung zur FMN-Spiral-Ausrichtung

Federated Mission Networking (FMN) Spiral ist ein eigenständiges, aber angrenzendes Beschaffungsthema. Während ADatP-34 Profilbündel definiert, definiert FMN eine Missionsnetzwerk-Fähigkeit, die diese mit Sicherheits- und Dienstprofilanforderungen integriert. Die aktuelle operative Spirale ist Spiral 4; Spiral 5 ist in Entwicklung.

Die Fragen für das Programm:

Benötigt die Plattform FMN-Konformität? Koalitions-Missionsnetzwerk-Einsatz — Nachfolgemissionen von Resolute Support, Allied Reaction Force oder Äquivalente — verlangt FMN. Rein nationaler Einsatz möglicherweise nicht. Die Programmentscheidung prägt den Kosten-Envelope erheblich.

Welche Spirale? Wer innerhalb von 18 Monaten in den Einsatz geht, zielt auf Spiral 4. Wer später einsteigt, zielt auf Spiral 5 — mit dem ausdrücklichen Bewusstsein, dass die Anforderungen sich noch bewegen. Eine Spirale zu überspringen, ist selten praktikabel; die Upgrade-Arbeit wird zu einem eigenen mehrjährigen Projekt.

Wie sieht der Konformitätsprüfpfad aus? FMN-Konformität wird durch formelle NATO-Konformitätstests gesteuert, nicht durch Selbstbewertung. Testslots sind begrenzt und weit im Voraus terminiert. Ein Programm, das auf Spiral 4 zielt, sollte 12–18 Monate vor dem geplanten Einsatz in der NATO-Konformitäts-Warteschlange stehen.

Die detaillierten Engineering-Anforderungen für FMN Spiral 4 stehen in FMN Spiral 4: Anforderungen und Umsetzungsnotizen.

Schritt 5: Anforderungen außerhalb der NATO bilateral entscheiden

Die meisten Verteidigungsplattformen operieren auch neben Nicht-NATO-Partnern — Ukraine, Israel, Japan, Australien, Korea und andere. Diese Beziehungen bringen Standards außerhalb des NATO-Katalogs ein, die mit dem Interop-Envelope der Plattform interagieren.

Die häufigsten Nicht-NATO-Eingaben:

Integration mit ukrainischem Delta und DZVIN. Bilateraler Datenaustausch mit ukrainischen C2-Plattformen nutzt Formate außerhalb des NATO-Katalogs. Das Engineering-Muster, einschließlich Delta-Formatdetails und Integrationsansatz, steht in Delta-Format und Integration des ukrainischen Militärs. Den Kontext des Brave1-Ökosystems liefert Das Brave1-Verteidigungsökosystem.

FVEY-exklusive Protokolle. Five-Eyes-Partner teilen Aufklärungsdaten über Protokolle außerhalb des NATO-Katalogs. Plattformen, die sowohl NATO- als auch FVEY-Kontexte adressieren, müssen die doppelgleisige Konformität abdecken.

Bilaterale nationale Standards. Die USA besitzen zusätzliche Protokolle (CRD, JREAP-Varianten), die formell keine NATO-Standards sind, aber in bilateralen Programmen auftauchen. Großbritannien, Frankreich und Deutschland haben nationale Aufsätze. Jeder davon ist eine programmspezifische Entscheidung.

Die Nicht-NATO-Eingaben ersetzen den NATO-Konformitäts-Envelope nicht; sie erweitern ihn. Dokumentieren Sie sie im Katalog neben den STANAGs, mit eigenem Umsetzungsstand und Konformitätsprüfpfad.

Schritt 6: STANAG-Versions- und Spiralstrategie

STANAGs entwickeln sich weiter. Editionen ändern sich, Nachrichtenformate werden erweitert, Anforderungen werden strenger. Die Plattform muss eine explizite Strategie für die Versionsübergänge haben, die über ihre operative Lebensdauer auftreten werden.

Das Muster, das funktioniert:

Aktuelle operative Editionen verfolgen. Die Plattform implementiert die Editionen, die aktuelle NATO-Einsätze verlangen. Ältere Editionen werden zur Rückwärtskompatibilität weiter unterstützt; neuere Editionen werden verfolgt, aber nicht implementiert, bis sie operativ verlangt werden.

Übergänge explizit planen. Wenn eine neue Edition operativ verlangt wird, ist der Übergang ein geplantes Projekt mit eigenem Engineering-Budget, erneutem Konformitätstest und aktualisierter Akkreditierung. Den Übergang als Routinewartung zu behandeln, erzeugt mehrjährige Verzögerung.

Dual-Edition-Support während Übergängen aufrechterhalten. Reale Einsätze überspannen Editionen. Die Plattform unterstützt beide für die Dauer des Koalitions-Übergangsfensters.

Sich am Standardisierungsprozess beteiligen. Anbieter mit erheblichem Programmengagement nehmen an NATO-Standardisierungsarbeitsgruppen teil. Die Teilnahme bringt anstehende Änderungen früh zutage, gibt dem Team eine Stimme bei den Anforderungen und liefert Marktintelligenz, die Beschaffungswettbewerber nicht haben.

Schritt 7: Repository-Struktur für Interop-Code

Interop-Code ist sensibel — falsche Eingriffe brechen den Koalitionseinsatz. Repository-Disziplin reduziert das Risiko.

Die Struktur, die funktioniert:

• interop/stanags/<stanag-id>/ — ein Verzeichnis pro STANAG, mit eigener Implementierung, Konformitätstests und Dokumentation.
• interop/profiles/<adatp-34-profile>/ — Profilaggregationen, die einzelne STANAG-Implementierungen zusammensetzen.
• interop/conformance-tests/ — automatisierte Testsuiten, mit Unterverzeichnissen passend zur Konformitätsprüfquelle (CI, CWIX-Vorbereitung, bilaterale Testpläne).
• interop/catalogue.md — der lebendige STANAG-Katalog.
• interop/profile-decisions/ — Architecture Decision Records, welche die Envelope-Entscheidungen dokumentieren.

Die Struktur macht die Interop-Arbeit prüffähig, erlaubt einzelnen STANAGs unabhängige Weiterentwicklung und unterstützt den Konformitätsprüf-Workflow, der die Releases steuert.

Wie geht es weiter

Teil 1 hat das Interop-Subsystem eingerahmt. Konformitäts-Envelope festgelegt, STANAG-Katalog aufgebaut, ADatP-34-Profilausrichtung gewählt, FMN-Spiral-Entscheidung getroffen, bilaterale Anforderungen dokumentiert, Versionsstrategie explizit, Repository-Struktur verbindlich. Die Plattform hat nun eine verteidigbare Beschaffungserzählung; die Umsetzungsarbeit folgt.

Teil 2 geht in die Implementierung der taktischen Datenlinks, die die meisten NATO-interoperablen Plattformen verankern — Link 16, CoT, MIP4. Hardware-Integration, Nachrichten-Marshalling, Aufbau des Konformitäts-Harness und die Engineering-Disziplinen, die eine Koalitionsübung überstehen.