Guide de mise en œuvre de l'interopérabilité OTAN, Partie 2 : implémenter les liaisons de données tactiques — Link 16, CoT et MIP4

La partie 1 a fixé l'enveloppe de conformité. La partie 2 implémente les liaisons de données tactiques qui ancrent la plupart des plateformes interopérables OTAN : Link 16 pour les opérations aériennes et de défense aérienne, Cursor on Target pour l'extrémité tactique, MIP4-IES pour l'échange C2 entre forces terrestres, et STANAG 4559 pour l'échange de produits ISR. Chacune a son propre schéma d'ingénierie, sa propre discipline de conformité et ses propres modes de défaillance. La partie 2 les parcourt.

Le cadrage architectural figure dans Le guide complet de l'interopérabilité OTAN. La série compagnon sur le moteur de fusion C2, Construire un pipeline de fusion défense, couvre la couche d'adaptateurs qui consomme ces liaisons de données à l'intérieur de la plateforme.

Étape 1 : intégration de Link 16

Link 16 est la liaison de données tactique OTAN canonique pour l'aérien et la défense aérienne. C'est aussi la norme la plus mal comprise par les ingénieurs logiciels qui entrent dans la défense. Le protocole est à créneaux temporels (Time Division Multiple Access), le catalogue de messages (messages J-series) est classifié, les règles de participation sont gérées en bande passante, et l'intégration passe presque toujours par un terminal MIDS matériel plutôt qu'une radio logicielle.

Le schéma d'implémentation pragmatique côté logiciel :

Intégrer via l'API du terminal MIDS. Le terminal matériel gère le protocole à créneaux temporels ; le logiciel gère le marshalling des messages au-dessus. Le terminal expose une API fournie par le constructeur — SIMPLE (Standard Interface for Multiple Platform Link Evaluation) est la plus courante — par laquelle le logiciel soumet des messages J-series pour transmission et reçoit les J-series entrants à traiter.

Traiter l'interface SIMPLE comme un contrat stable. L'interface évolue lentement ; le catalogue de messages évolue plus vite. Versionner l'intégration autour des éditions du catalogue de messages, pas de la version SIMPLE. Les mises à jour du catalogue sont des événements planifiés avec leurs propres re-tests de conformité.

Marshaller les messages avec un typage strict. Les messages J-series ont des structures rigides définies dans le catalogue classifié. Les implémenter comme types générés par code (lorsque l'accès au catalogue le permet) ou comme types écrits à la main avec validation poussée. Le typage lâche dans le marshalling Link 16 est la cause racine de la plupart des échecs de conformité à CWIX.

Bufferiser en sortie, valider en entrée. Les messages sortants sont mis en file selon leur priorité ; la plateforme ne doit pas inonder le terminal. Les messages entrants sont validés contre le catalogue avant propagation ; les J-series mal formés sont rejetés avec journalisation structurée, pas passés en silence.

La vue d'ingénierie plus approfondie, incluant la topologie d'intégration et les pièges les plus courants, figure dans Link 16 et les liaisons de données tactiques : vue d'ingénierie.

Étape 2 : intégration de Cursor on Target

CoT est la lingua franca tactique de fait hors des catalogues OTAN formels. Issue de l'U.S. Air Force, adoptée dans tout l'écosystème ATAK/WinTAK, de plus en plus exigée dans les opérations de coalition indépendamment de son statut OTAN formel. Une plateforme interopérable OTAN opérant aux côtés de forces américaines ou alliées équipées d'ATAK rencontrera CoT que l'enveloppe de conformité formelle l'inclue ou non.

CoT est techniquement plus simple que Link 16 — basé sur XML, schéma bien défini, pas de catalogue de messages classifié, pas de protocole à créneaux temporels. La rigueur d'ingénierie requise est la même.

Le schéma d'implémentation :

Validation de schéma à la frontière. Chaque message CoT entrant est validé contre le schéma avant tout traitement ultérieur. Les messages mal formés sont journalisés bruyamment et rejetés ; l'acceptation silencieuse est le mauvais comportement par défaut.

Gestion stricte des horodatages. Les messages CoT portent un temps d'observation, un temps de péremption du message et un temps de péremption. La discipline des trois horodatages des guides d'ingénierie précédents s'applique — le temps d'observation pilote la corrélation, le temps de péremption pilote les décisions de cycle de vie, les confondre est une source récurrente de bogues.

Analyse conservatrice des champs optionnels. Les extensions CoT sont courantes ; toutes les extensions ne sont pas documentées. Analyser ce qui est documenté ; ignorer ce qui ne l'est pas (en journalisant) ; ne jamais crasher sur un contenu inattendu.

Souplesse de transport. CoT circule sur multicast UDP, TCP point-à-point, TCP via TAK Server et (de plus en plus) MQTT. La couche d'adaptateurs accommode les quatre avec un chemin de traitement commun en aval.

Le traitement détaillé de CoT en ingénierie figure dans Cursor on Target (CoT) : la norme XML derrière les applis de connaissance tactique. La perspective de développement de plugins ATAK est dans Développement de plugins ATAK.

Étape 3 : implémentation de MIP4-IES

Pour l'échange avec les systèmes C2 nationaux au-dessus du niveau brigade, MIP4-IES est le schéma. Il est dense, contrôlé en version et impitoyable en tests de conformité. Le Multilateral Interoperability Programme définit le modèle ; l'Information Exchange Specification le sérialise.

Le schéma d'ingénierie qui réussit :

Traiter MIP4 comme une interface stricte, pas un modèle interne. Le modèle de données interne de la plateforme est ce que l'équipe d'ingénierie conçoit ; MIP4 est le format filaire que la plateforme parle à la frontière de coalition. Le mapping entre les deux est bidirectionnel et sans perte pour les champs opérationnellement significatifs.

La préservation du round-trip est le test. Un message MIP4 marshallé en sortie de la plateforme, puis dé-marshallé en entrée, doit produire le même modèle interne (modulo canonicalisation intentionnelle). Les échecs de round-trip révèlent les mappings avec perte, les bogues de coercition de type et les erreurs d'aliasing de champs.

Génération de code pilotée par schéma. Le schéma MIP4-IES est assez vaste pour que le code de marshalling écrit à la main dérive. Générer les types à partir du schéma publié ; maintenir le code de mapping séparément et le revoir explicitement.

Verrouillage de version avec transitions explicites. Les éditions de MIP4 changent. La plateforme se verrouille à une édition spécifique pour son déploiement opérationnel courant ; les transitions sont des projets planifiés avec re-tests de conformité.

La vue d'ingénierie approfondie de MIP4-IES, incluant l'anatomie du modèle de données et la réalité des tests de conformité, figure dans MIP4-IES : la norme sol OTAN.

Étape 4 : échange ISR via STANAG 4559

STANAG 4559 (NSILI — NATO Standard ISR Library Interface) régit l'échange d'imagerie et de produits ISR entre plateformes C2 de coalition. Requis pour toute plateforme qui consomme ou produit de l'imagerie d'origine nationale dans un contexte de coalition.

La réalité d'implémentation :

Côté consommateur d'abord. La plupart des programmes logiciels de défense sont consommateurs NSILI — ils interrogent les bibliothèques d'imagerie de coalition et intègrent les résultats — plutôt que fournisseurs NSILI. L'interface côté consommateur est bien définie et tractable ; l'implémentation côté fournisseur est un programme plus lourd avec une charge d'accréditation supplémentaire.

Récupération attentive à la bande passante. L'imagerie ISR est volumineuse. La récupération sur liaisons tactiques doit être économe en bande passante — vignettes d'aperçu d'abord, pleine résolution sur demande de l'opérateur, téléchargement progressif pour les plus gros produits. L'IHM de la plateforme expose l'état de bande passante pour que les opérateurs comprennent l'arbitrage.

Séparation du magasin d'imagerie. L'imagerie récupérée vit dans un magasin d'objets dédié, pas la base de données de pistes opérationnelles. Les métadonnées relient l'imagerie au contexte de piste ; l'imagerie elle-même est référencée, pas embarquée.

Marquage de classification sur l'imagerie. L'imagerie récupérée porte la classification source au titre de STANAG 4774/4778. La classification suit l'imagerie à travers la plateforme — couche d'affichage, piste d'audit, analytique en aval. Retirer la liaison « par commodité » est le genre de raccourci que les évaluateurs d'accréditation recherchent spécifiquement ; la partie 3 de cette série couvre la discipline en détail.

Le schéma d'implémentation STANAG 4559 plus approfondi figure dans Implémentation de STANAG 4559 : NSILI en pratique.

Étape 5 : liaison aux profils ADatP-34

Les liaisons de données individuelles — Link 16, CoT, MIP4, STANAG 4559 — implémentent des normes spécifiques. L'alignement sur les profils ADatP-34 exige que la plateforme implémente les bonnes combinaisons de ces normes et que les combinaisons satisfassent les scénarios d'interopérabilité du profil.

La discipline de la liaison aux profils :

Scénarios de test pilotés par profil. Pour chaque profil ADatP-34 visé par la plateforme, la suite de tests de conformité inclut des scénarios qui exercent les liaisons de données en combinaison. Un scénario peut exiger : recevoir une mise à jour de piste aérienne Link 16, corréler avec une piste sol CoT venant d'ATAK, interroger NSILI pour de l'imagerie de zone, fusionner les trois en un affichage COP unique. Le scénario teste la combinaison, pas les normes individuelles.

Catalogues de messages pilotés par profil. Le profil définit quels messages J-series sont requis, quels types de messages MIP4 doivent être échangés, quelles extensions CoT sont attendues. La plateforme implémente le sous-ensemble requis, pas l'intégralité du catalogue.

Suivi de l'évolution des profils. Les profils ADatP-34 évoluent. La plateforme suit le profil opérationnel courant et le profil de la prochaine spirale. Le travail d'ingénierie qui cible le profil courant tout en anticipant le suivant est la discipline qui survit aux transitions de version.

Étape 6 : ponts bilatéraux et hors-OTAN

Les plateformes qui opèrent dans de vrais déploiements de coalition ont besoin de ponts au-delà du catalogue OTAN. Intégration au Delta ukrainien, protocoles FVEY uniquement, extensions spécifiques à un partenaire — chacun est un pont à côté des liaisons de données OTAN formelles.

Le schéma d'ingénierie du format Delta figure dans Format Delta et intégration militaire ukrainienne. Les schémas plus larges de partage en coalition, y compris les considérations de politique, sont dans Défis du partage de données en coalition.

La règle architecturale : les ponts bilatéraux sont des adaptateurs séparés, pas des modifications du code des liaisons de données OTAN. Un pont vers Delta ne touche pas au marshalling Link 16 ; un pont vers un protocole national américain ne touche pas au traitement CoT. L'isolation des adaptateurs s'étend aux protocoles, pas seulement aux types de capteurs.

Étape 7 : construire tôt le banc de conformité

Les tests de conformité sont le travail qui distingue les plateformes qui passent CWIX de celles qui échouent. Le banc qui exécute ces tests est une infrastructure d'ingénierie aussi importante que la plateforme elle-même.

Les composants du banc :

• Suites de tests par norme. Round-trip de messages J-series Link 16 ; bonne forme et correction sémantique CoT ; échange et round-trip d'entités MIP4 ; requête, récupération et mapping des métadonnées STANAG 4559. Chaque suite est automatisée, mise en porte dans la CI, et produit des rapports structurés.
• Rejeu de données capturées. Trafic filaire capturé lors d'exercices réels et de déploiements opérationnels, rejoué contre la plateforme. Vérité terrain pour les tests de régression.
• Simulateurs de systèmes partenaires. Là où les vrais systèmes partenaires ne sont pas disponibles pour les tests unitaires, des simulateurs prennent leur place. Ils échangent des messages conformes avec la plateforme et vérifient que les réponses correspondent à la norme.
• Tests d'intégration basés sur scénarios. Scénarios des profils ADatP-34 exercés de bout en bout. La plateforme reçoit des entrées, effectue la fusion, produit des sorties que le banc de tests valide contre la vérité terrain attendue.
• Suivi de la préparation CWIX. Les cas de tests que la plateforme prévoit de soumettre à CWIX sont suivis séparément, avec statut pass-fail visible par la direction du programme bien avant l'exercice.

Le coût de construire cette discipline tôt est réel mais borné ; le coût de l'éluder se manifeste en retards de plusieurs mois pendant la période de conformité réelle. Les programmes qui livrent à temps des plateformes interopérables OTAN sont les programmes qui ont construit le banc de conformité dès l'année un.

Suite

La partie 2 a implémenté les liaisons de données tactiques. Link 16 via le terminal MIDS, CoT via l'adaptateur à validation de schéma, MIP4-IES via le mapping préservant le round-trip, STANAG 4559 via l'interface de requête côté consommateur, le tout lié par le profil ADatP-34 et exercé par le banc de conformité.

La partie 3 couvre la machinerie de classification et de diffusion — liaison STANAG 4774/4778, implémentation du moteur de politique, flux de données entre enclaves, et la discipline de diffusion en coalition qui rend la plateforme déployable en contextes classifiés.