Logiciel de commandement et de contrôle maritimes pour les opérations de guerre de surface

La guerre de surface est l'un des environnements les plus riches en informations qu'un système C2 puisse avoir à gérer. Dans le Centre d'information de combat (CIC) d'une frégate ou d'un destroyer moderne, des dizaines de pistes — contacts de surface, menaces aériennes, signatures sous-marines, unités amies, hélicoptères et véhicules sans équipage — sont mises à jour en continu depuis les capteurs organiques et les liaisons de données, chacune exigeant une classification, une hiérarchisation et une vérification en temps réel par rapport aux zones d'engagement des armes actives. Le logiciel qui gère tout cela n'est pas simplement une application cartographique avec des flux de capteurs : c'est une architecture en couches de moteurs de fusion, de piles de protocoles de liaisons de données, de modules de coordination des armes et de réseaux à séparation cryptographique, le tout fonctionnant sur du matériel qui doit survivre en mer pendant des déploiements prolongés sans fenêtre de mise à jour. Cet article est un examen technique de la façon dont le logiciel C2 maritime est architecturé pour la guerre de surface, couvrant le tableau tactique, l'intégration des liaisons de données, la gestion des WEZ, le C2 ASW, la coordination des aéronefs de patrouille maritime et les contraintes de cybersécurité qu'imposent les environnements embarqués. Pour une perspective plus large sur l'architecture C2 militaire, consultez notre guide complet des systèmes C2 militaires.

Périmètre du C2 maritime : de l'automatisation du CIC au C2 de flotte

Le commandement et le contrôle navals ne constituent pas un système unique, mais un ensemble de trois couches fonctionnelles distinctes, chacune ayant des exigences de latence, des volumes de données et des rôles opérateurs différents. Les confondre au stade de l'architecture produit une conception qui ne satisfait adéquatement aucune d'entre elles.

La couche d'automatisation du CIC au niveau du navire est la plus rapide et la plus immédiatement opérationnelle. Elle fusionne les capteurs organiques — radar de bord, récepteurs ESM, sonar, systèmes électro-optiques — avec les contributions des liaisons de données en une seule base de données de pistes, gère les systèmes d'armes et fournit à l'officier de quart et au commandant les consoles d'affichage nécessaires pour diriger un engagement en temps réel. Les taux de mise à jour sont ici mesurés en secondes ; la latence entre la détection par le capteur et l'affichage pour l'opérateur doit être inférieure à trois secondes pour que le tableau tactique soit exploitable. Cette couche fonctionne à l'intérieur du Centre d'information de combat sur un réseau classifié, physiquement isolé, et doit rester opérationnelle quel que soit l'état des liaisons de communication avec les échelons supérieurs.

La couche C2 du groupe de travail coordonne plusieurs navires. Un groupe d'action de surface ou un groupe de frappe de porte-avions fonctionne comme une unité intégrée, partageant un tableau tactique composite sur toutes les coques, coordonnant les zones d'engagement des armes pour éviter que le volume d'engagement d'un missile d'un navire ne chevauche le couloir de vol d'un hélicoptère de patrouille d'un autre navire, et déconflictuant les tirs au sein du groupe. Le logiciel à cette couche agrège les tableaux de pistes des navires individuels via la liaison de données, résout les doublons lorsque le même contact apparaît sur les capteurs de plusieurs navires, et distribue les mises à jour coordonnées des WEZ à chaque coque. Les taux de mise à jour sont ici mesurés en dizaines de secondes ; le tableau du groupe de travail est un peu moins granulaire que le tableau organique d'un seul navire, mais couvre une zone géographique beaucoup plus vaste.

La couche de commandement de flotte est concernée par la planification opérationnelle et la distribution stratégique des pistes. Elle reçoit des synthèses agrégées des groupes de travail, émet des ordres de mouvement et des règles d'engagement, et maintient le tableau de niveau opérationnel utilisé pour la planification de campagne. Cette couche fonctionne sur des communications longue portée, tolère une latence plus élevée et est généralement hébergée à terre ou sur un navire de commandement dédié plutôt que sur chaque combattant. L'architecture C2 multi-domaine qui régit les opérations interarmées modernes connecte généralement la couche de commandement de flotte à l'image opérationnelle commune interarmées, rendant le tableau maritime visible aux éléments de commandement terrestre et aérien.

Ces trois couches doivent être conçues avec des interfaces propres entre elles. Une couche d'automatisation du CIC qui expose son bus de messages de fusion de capteurs interne à la couche du groupe de travail évolue mal ; un C2 de groupe de travail qui interroge les systèmes CIC individuels pour des données de capteurs brutes submerge la capacité de traitement du CIC. La bonne limite est une interface d'exportation de pistes standardisée : le CIC publie sa liste de pistes faisant autorité selon un calendrier bien défini en utilisant un format de message standard, et le C2 du groupe de travail s'abonne à ces exports sans toucher aux éléments internes du CIC.

Compilation du tableau tactique pour les opérations maritimes

Le tableau tactique dans un CIC maritime est une base de données de pistes fusionnées et multi-domaines. Il contient des contacts de surface, des pistes sous-marines, des pistes aériennes et des positions d'unités amies dans un seul système de coordonnées, chacun avec une classification, un statut d'engagement, une évaluation de la qualité de la piste et une liste des sources contributrices. Maintenir ce tableau avec précision sous les débits de données générés par les capteurs modernes est le défi d'ingénierie central du logiciel CIC.

La gestion des pistes de surface commence par les retours radar bruts du radar de recherche de surface du navire et de tout capteur supplémentaire de surveillance de surface. Le radar fournit la distance et le relèvement pour chaque contact détecté ; le logiciel CIC les convertit en coordonnées géographiques, applique un filtrage de fouillis pour supprimer le fouillis de mer et les retours terrestres, et initie une piste pour chaque contact soutenu. Les pistes sont mises à jour à chaque balayage radar — généralement toutes les deux à six secondes — à l'aide d'un filtre de Kalman qui estime la position, le cap et la vitesse à partir de la séquence de mesures de position. Lorsqu'une contribution de liaison de données arrive pour un contact que le radar suit déjà, le moteur de fusion corrèle le rapport de liaison avec la piste organique et les fusionne en une seule piste faisant autorité qui dispose désormais à la fois de la confirmation du capteur et de toute information d'identité portée par la liaison de données.

L'évaluation de la qualité des pistes est un processus continu. Chaque piste est maintenue à l'un de plusieurs états de qualité — ferme, probable ou tentative — en fonction du nombre de capteurs contributeurs, de la cohérence des rapports entre les sources et du temps écoulé depuis la dernière observation de soutien. Une piste ferme a été confirmée par deux sources indépendantes ou plus et a été mise à jour dans une fenêtre de tolérance courte. Une piste tentative n'a qu'une seule source, ou n'a pas été mise à jour récemment, et est montrée aux opérateurs avec un niveau de confiance réduit. Lorsqu'une piste n'a pas été mise à jour pendant un délai d'expiration configurable, elle est supprimée du tableau tactique plutôt que persistée indéfiniment — des pistes périmées dans le CIC sont plus dangereuses qu'aucune piste, car elles occupent l'attention de l'opérateur et peuvent produire des recommandations d'engagement invalides.

La classification des contacts consiste à attribuer une désignation hostile/inconnu/neutre/ami (HUNF) standardisée à chaque piste. La classification s'appuie sur les données ESM (identifiant les émetteurs radar et de communication du contact par rapport à une bibliothèque d'émetteurs connus), l'identification visuelle depuis la suite de capteurs optiques ou infrarouges du navire, la corrélation AIS pour les contacts de surface et les réponses IFF pour les contacts aériens. La classification n'est jamais entièrement automatique — c'est une recommandation présentée à l'officier de quart qui fait la désignation finale — mais le logiciel fournit la base de preuves qui permet à un officier de quart expérimenté de classifier un contact en quelques secondes plutôt qu'en minutes.

Intégration des liaisons de données en environnement maritime

Le logiciel C2 maritime fonctionne dans un environnement de liaisons de données en couches qui s'est accumulé au cours de décennies de développement naval. Chaque liaison transporte des informations différentes, fonctionne sur des bandes de fréquences différentes et présente des caractéristiques de portée et de fiabilité différentes. Le logiciel CIC doit maintenir un tableau de pistes composite compilé à partir de toutes les liaisons actives et des capteurs organiques, présentant à l'opérateur une liste de pistes dédupliquée unique, quelle que soit la multiplicité des sources sous-jacentes contributrices.

Le Link 16, transporté sur des terminaux MIDS-LVT (Multifunctional Information Distribution System Low Volume Terminals), est la liaison de données tactique principale pour les combattants de surface modernes. Il distribue le tableau tactique interarmées via des messages J-series : pistes de surface, sous-marines et aériennes (J3.x), localisation et identification précises des participants (J2.x), coordination des armes (J7.x et J9.x), et gestion du réseau (J0.x). Le Link 16 est un réseau à accès multiple par répartition dans le temps avec des créneaux horaires assignés, ce qui signifie que chaque participant doit être synchronisé en temps et se voir attribuer une allocation de créneaux avant que le réseau puisse fonctionner — une étape de configuration qui doit être réalisée au cours du processus d'ordre d'opérations avant que le groupe de travail ne prenne la mer. Pour un traitement détaillé du jeu de messages Link 16 et de l'architecture d'intégration, consultez notre article sur l'intégration de la liaison de données tactique Link 16.

Le Link 22 étend le tableau de liaison de données tactique aux portées au-delà de l'horizon en utilisant des bandes de fréquences HF et un protocole de messages différent (NILE). Alors que le Link 16 dépend principalement du relais par satellite pour les longues portées en ligne directe, le Link 22 se propage au-delà de l'horizon par ionosphère HF, donnant à un groupe de travail des données de contacts au-delà de l'horizon sans nécessiter de navire relais ou de bande passante satellite. Le logiciel CIC maintient des contributions de pistes séparées depuis le Link 16 et le Link 22 avant de les fusionner dans le tableau composite, car les deux liaisons peuvent porter le même contact avec des numéros de piste différents assignés par des unités différentes.

Le Link 11 (TADIL-A) reste installé sur les anciennes frégates et patrouilleurs qui n'ont pas encore migré vers le Link 16. Le Link 11 fonctionne en mode de scrutation tournante dans lequel une station de contrôle de réseau scrute chaque participant à tour de rôle — un cycle de mise à jour significativement plus lent que la diffusion continue du Link 16. Dans un groupe de travail mixte, une unité Link 16 agit généralement comme relais, pontant les pistes Link 11 dans le tableau Link 16 pour les unités qui ne peuvent pas recevoir le Link 11 directement. Le logiciel CIC sur le navire relais doit appliquer une résolution des doublons lorsqu'un contact apparaît sur les deux liaisons avec des numéros de piste différents.

La logique de gestion des pistes composite qui sous-tend toute l'intégration des liaisons de données suit le même principe que celui utilisé dans la fusion de capteurs : une piste canonique par contact réel, quel que soit le nombre de liaisons qui le signalent. Le moteur d'association prédit chaque piste existante vers l'avant jusqu'à l'horodatage du rapport de liaison entrant, jauge le rapport par rapport à la position prédite en utilisant la précision positionnelle déclarée de la liaison, et associe si le rapport tombe dans la porte. La piste canonique absorbe alors le rapport de liaison, mettant à jour son estimation de position et ajoutant la liaison comme source contributrice. Une piste de liaison entrante qui ne s'associe à aucune piste existante en initie une nouvelle, marquée comme piste de liaison de données uniquement jusqu'à ce qu'un capteur organique ou une seconde liaison la confirme.

Gestion des zones d'engagement des armes

La gestion des zones d'engagement des armes (WEZ) est le processus par lequel un groupe de travail établit, distribue et applique les zones géographiques dans lesquelles chaque système d'armes ou unité est autorisé à engager. Sans gestion coordonnée des WEZ, un missile tiré par un navire pourrait pénétrer dans l'espace d'engagement aérien d'un autre navire, ou un hélicoptère effectuant un schéma ASW à basse altitude pourrait se trouver dans le volume d'engagement d'un missile surface-air. Dans un groupe de travail multi-navires menant simultanément des opérations de guerre de surface, de défense aérienne et ASW, les conflits de WEZ ne sont pas des cas limites — ce sont des problèmes de coordination routiniers que le logiciel doit résoudre en permanence.

Les définitions de WEZ dans la base de données C2 sont des objets géométriques : des limites polygonales ou circulaires, un type de zone, une autorité désignatrice, une période de validité et un indicateur de diffusion. Les types de zones comprennent :

• Armes libres — tous les contacts hostiles identifiés à l'intérieur de la zone peuvent être engagés sans autorité supplémentaire du commandant désignataire.
• Armes sous contrôle — seuls les contacts qui ont été positivement identifiés comme hostiles peuvent être engagés ; les contacts inconnus ne doivent pas être engagés sans autorisation supplémentaire.
• Armes bloquées — aucun engagement n'est autorisé dans la zone quelle que soit la classification de la piste ; utilisé pour protéger les hélicoptères, les aéronefs de patrouille et les UUV opérant dans une zone définie.

Le logiciel C2 évalue continuellement la position géographique de chaque piste par rapport à toutes les zones actives. Lorsqu'une piste franchit une limite de zone, le système met à jour les contraintes d'engagement sur cette piste, alerte l'officier des armes et, si la piste est sous évaluation TEWA active, recalcule la recommandation d'engagement. Cette vérification position-vers-zone doit s'exécuter en temps réel — une piste se déplaçant à trente nœuds couvre près de seize mètres par seconde, et une limite de zone n'est pas une bande de tolérance.

La diffusion des zones à travers le groupe de travail utilise les messages de piste et de gestion du Link 16 pour distribuer les définitions WEZ actuelles à chaque navire du groupe. Les navires récepteurs fusionnent les définitions de zones entrantes dans leur propre base de données WEZ en utilisant le même type de logique de corrélation que celui utilisé pour les pistes — une zone reçue du commandant du groupe de travail remplace toute zone définie localement couvrant la même zone. Cela garantit que la logique d'engagement de chaque navire fonctionne selon les mêmes règles, même lorsque la communication est intermittente.

La détection des conflits entre zones est une fonction distincte. Une zone d'armes libres qui chevauche une zone d'armes bloquées couvrant une zone opérationnelle d'hélicoptère est une erreur de planification fatale ; le logiciel C2 doit détecter et alerter sur ce conflit avant qu'il ne soit diffusé, et non après qu'un hélicoptère est entré dans ce qu'il croit être une zone sûre. La détection des conflits évalue tous les couples de zones pour le chevauchement spatial et met en évidence les cas où la combinaison des types de zones produirait des règles d'engagement contradictoires sur le même contact.

C2 de lutte anti-sous-marine (ASW)

Le C2 ASW est architecturalement distinct du C2 de guerre de surface, mais il partage la même base de données de pistes et doit être déconflictualisé avec les tableaux de surface et aérien. Le module ASW gère une classe différente de capteurs — sonobuées, sonar à coque, sonar remorqué — et fonctionne sur des échelles de temps et géographiques qui diffèrent du suivi des contacts de surface.

La gestion du champ de sonobuées est le fondement opérationnel de l'ASW aéroportée. Le logiciel CIC maintient une base de données de chaque sonobuée déployée : sa position géographique (connue au moment du largage et dérivant avec le courant par la suite), son type (LOFAR passif, DIFAR actif, portée seulement), la durée de vie restante de sa batterie et son état de détection actuel. Lorsqu'une sonobuée produit une ligne de gisement acoustique, le logiciel CIC corrèle ce gisement par rapport aux pistes sous-marines existantes et les met à jour, ou initie une nouvelle piste tentative. Plusieurs lignes de gisement provenant de différentes bouées du champ sont triangulées pour produire une estimation de position pour le contact.

La gestion des pistes acoustiques est substantiellement plus difficile que la gestion des pistes de surface. Les détections acoustiques sont ambiguës en portée et en gisement, et la profondeur de la piste — qui peut aller de la profondeur périscopique à plusieurs centaines de mètres — affecte à la fois sa détectabilité et sa géométrie de menace. Le gestionnaire de pistes ASW maintient des pistes sous-marines avec des ellipses d'incertitude de position plus grandes que les pistes de surface, et le modèle de mouvement du filtre de Kalman doit tenir compte de la capacité de manœuvre tridimensionnelle complète d'un sous-marin plutôt que du mouvement essentiellement bidimensionnel d'un contact de surface.

Le flux de travail de poursuite coordonnée lie la gestion des capteurs au tableau de coordination des armes. Une fois qu'un contact sous-marin est classifié comme hostile et que la poursuite est autorisée, le module ASW calcule un schéma de recherche optimal pour les hélicoptères coopérants, génère des instructions de repositionnement de bouées pour affiner l'estimation de position, et maintient un journal de poursuite qui enregistre chaque détection et action de plateforme. Lorsque le contact est suffisamment localisé, le module présente une solution de torpille à l'officier des armes pour autorisation, avec la géométrie d'engagement affichée sur le même tableau tactique qui montre les pistes de surface et aériennes — afin que le commandant puisse simultanément évaluer la menace sous-marine et la situation de surface et aérienne avant d'autoriser un engagement.

Coordination des aéronefs de patrouille maritime et des UUV

Les unités de guerre de surface modernes opèrent avec des hélicoptères organiques et, de plus en plus, avec des aéronefs de patrouille maritime à voilure fixe affectés au groupe de travail. Le CIC doit coordonner le ciblage des capteurs, le partage du tableau et la gestion de l'espace aérien pour toutes ces plateformes simultanément.

La coordination des aéronefs de patrouille maritime est centrée sur le tableau de liaison de données bilatéral. Le P-8 Poseidon, par exemple, participe au réseau Link 16 du groupe de travail, contribuant ses propres pistes radar et capteurs sous forme de messages J-series qui fusionnent dans le tableau CIC composite. Le CIC retourne le tableau de surface du groupe de travail à l'aéronef afin que l'équipage puisse voir la situation tactique lors des approches à basse altitude. La coordination vocale — sur des fréquences UHF ou HF désignées — gère le flux de travail de poursuite qui nécessite un dialogue en temps réel : demandes de repositionnement de bouées, mises à jour de la classification des contacts et coordination de la mise à feu lorsqu'un engagement de torpille est autorisé.

Le module C2 ASW génère des missions numériques formelles pour le MPA : un schéma de barrière de recherche défini par des points de cheminement géographiques, les types de bouées à déployer à chaque position, les périodes d'écoute passive entre les cycles de transmission active, et le format de rapport pour les détections acoustiques. Ces missions sont transmises sous forme de message numérique structuré plutôt que de voix en texte libre, de sorte que le CIC peut suivre quelles instructions ont été accusées de réception, quand chaque bouée a été déployée et combien de temps avant l'expiration de la batterie de chaque bouée.

La coordination des hélicoptères depuis le CIC suit le même schéma mais avec une latence plus faible, car l'hélicoptère organique est en contact vocal UHF continu et les distances plus courtes permettent des mises à jour de liaison de données plus rapides. Le CIC suit l'hélicoptère comme un contact aérien ami, maintient sa zone d'armes bloquées autour de l'aéronef, et reçoit les données de sonobuées sous forme de flux continu plutôt que de rapports périodiques. La gestion de la zone d'armes bloquées pour l'hélicoptère est l'une des fonctions WEZ les plus opérationnellement critiques — un système de missiles surface-air qui ne sait pas que l'hélicoptère organique du navire se trouve dans son volume d'engagement est un risque de tir fratricide.

Les véhicules sous-marins sans équipage introduisent un modèle de coordination basé sur la télémétrie que le logiciel CIC doit prendre en charge comme une interface distincte. La mission est transmise à l'UUV sous forme de fichier de mission pré-planifié — une séquence de points de cheminement, de modes opératoires des capteurs et de déclencheurs de rapport — et l'UUV s'exécute de manière autonome. Le CIC reçoit des rapports de position et de capteurs sous forme de messages de télémétrie à des intervalles configurés, peuplant la position de l'UUV sur l'affichage tactique et fusionnant ses détections acoustiques dans le tableau de pistes ASW. La remise en mission en temps réel est possible mais limitée en bande passante ; le logiciel CIC doit gérer le calendrier de communication pour équilibrer la surveillance UUV par rapport à la bande passante de liaison de données nécessaire pour le reste du tableau tactique.

Cybersécurité pour les systèmes C2 embarqués

La cybersécurité des C2 embarqués est régie par des contraintes qui ne s'appliquent pas aux systèmes équivalents à terre : isolation physique en mer, exigences de continuité opérationnelle extrêmes, contrôles d'émissions TEMPEST et processus de mise à jour qui doivent tenir compte de déploiements de plusieurs mois sans connexion fiable à l'infrastructure de mise à jour.

La segmentation du réseau sur un navire de guerre moderne est appliquée par séparation physique, et non uniquement par des règles de pare-feu. Une frégate exploite généralement quatre segments de réseau distincts : un segment top secret/informations compartimentées sensibles (TS/SCI) pour les flux de renseignement et les communications les plus sensibles ; un segment secret transportant le tableau tactique, les données de coordination des armes et le trafic Link 16 ; un segment non classifié pour le trafic administratif, logistique et de bien-être de l'équipage ; et un réseau de gestion de plateforme pour le contrôle de la propulsion, le contrôle des avaries et la surveillance des systèmes du navire. La séparation physique signifie que chaque segment fonctionne sur des câblages séparés, une infrastructure de commutation séparée et des postes de travail séparés — un utilisateur sur une console administrative ne peut pas atteindre le réseau CIC en traversant un pare-feu mal configuré car il n'y a pas de pare-feu entre eux ; il n'y a aucun chemin du tout.

Les flux de données inter-domaines sont gérés par des diodes de données approuvées et des gardes inter-domaines aux points précis où l'information doit circuler entre les niveaux de classification. Une diode de données est un lien optique unidirectionnel — les données ne peuvent circuler que dans un seul sens par construction physique, et non par configuration de politique. Un garde inter-domaines est un dispositif plus capable qui évalue les messages franchissant la limite par rapport à un schéma de format strict et une politique de contenu, rejetant tout message non conforme. Les deux types de dispositifs doivent être approuvés selon les normes nationales ou alliées pour les niveaux de classification qu'ils relient.

Les exigences TEMPEST mandatent que l'équipement dans le CIC émette un rayonnement électromagnétique en dessous des niveaux auxquels un adversaire pourrait reconstruire des informations classifiées à partir des émanations. Cela a des implications directes pour la sélection du matériel : les postes de travail et serveurs disponibles dans le commerce ne sont presque jamais certifiés TEMPEST au niveau requis pour les segments CIC TS/SCI ou Secret. Les programmes doivent s'approvisionner dans l'ensemble étroit de plateformes durcies et certifiées TEMPEST validées pour l'utilisation embarquée, acceptant des coûts unitaires plus élevés et des délais d'approvisionnement plus longs en échange de la conformité. Le compartiment CIC lui-même — son câblage, son filtrage d'alimentation et son blindage physique — doit également être conçu pour répondre à la norme TEMPEST applicable et validé avant la mise en service.

La mise à jour du logiciel C2 embarqué est opérationnellement contrainte d'une manière qui n'a pas de parallèle dans l'informatique d'entreprise. Le navire peut être en mer pendant six à neuf mois ; le réseau CIC n'a pas de connexion routinière à un serveur de mises à jour vendeur ; et le tableau tactique ne peut pas être mis hors ligne pour mise à jour pendant que le navire se trouve dans une zone de menace. L'approche standard implique trois éléments. Premièrement, un package de mise à jour pré-déploiement est construit et soumis à des tests de régression par rapport à la configuration matérielle et logicielle spécifique de la classe de plateforme avant le déploiement du navire, puis appliqué au port. Deuxièmement, le contrôle de configuration est maintenu tout au long du déploiement afin que l'état exact de chaque composant du système CIC soit connu à tout moment, permettant une analyse médico-légale si une anomalie se produit. Troisièmement, un processus d'exception pour les vulnérabilités critiques permet d'envoyer des mises à jour d'urgence via une liaison satellite lorsqu'une vulnérabilité est activement exploitée contre la classe de plateforme — ces mises à jour passent par un cycle de régression compressé mais obligatoire avant la transmission plutôt que d'être poussées directement depuis un avis vendeur.

/* Exemple : vérification de la limite de segment réseau CIC au niveau d'un garde inter-domaines */

CICMessage msg = receivedFromClassifiedSegment();

// Validation du schéma : rejeter les messages avec des champs de texte non structurés
if (!msg.conformsToSchema(ALLOWED_MESSAGE_TYPES)) {
    guard.reject(msg, "Violation du schéma : champ non structuré détecté");
    return;
}

// Vérification de direction : les données ne circulent que Secret → Non classifié
if (msg.destinationClassification() > SECRET) {
    guard.reject(msg, "Violation du flux ascendant");
    return;
}

// Politique de contenu : seuls les résumés de pistes déclassifiés sont autorisés
if (msg.containsRawSensorData() || msg.containsKeyingMaterial()) {
    guard.reject(msg, "Violation de la politique de contenu");
    return;
}

guard.forward(msg, unclassifiedSegment);

La surveillance de l'intégrité complète la posture de cybersécurité embarquée. Chaque exécutable CIC, fichier de configuration et fichier de données est haché lors du déploiement et les valeurs de hachage stockées dans un journal inviolable. Le système de surveillance re-hache les fichiers selon un calendrier continu et alerte si une divergence est détectée — le signal qu'un fichier a été modifié en dehors d'une fenêtre de mise à jour autorisée. Dans un environnement embarqué où l'intrusion externe est difficile mais où la menace interne et la compromission de la chaîne d'approvisionnement sont des risques réalistes, la surveillance de l'intégrité est un mécanisme de détection primaire plutôt que secondaire.