Interfaçage SI/OT en industrie : mapping des tags, normalisation des données et traçabilité vers ERP/GMAO

Interopérabilité SI/OT : objectifs et périmètre

Pourquoi le « simple tag » ne suffit plus

En environnement industriel, l'interface entre le monde OT (automates, capteurs, variateurs, postes de comptage, SCADA) et le monde SI (ERP, GMAO, MES, plateformes de données) doit garantir bien plus qu'un transfert de valeurs. L'enjeu est d'obtenir une donnée exploitable et fiable, c'est-à-dire :

• Compréhensible (même signification d'un site à l'autre, même contexte d'équipement, mêmes conventions),
• Qualifiée (unités, résolution, valeurs invalides, états qualité, conditions de calcul),
• Traçable (qui a émis, quand, avec quel identifiant, quel statut, et quelle réception/prise en compte côté SI).

Dans les architectures modernes, ces exigences s'appliquent à des flux variés : lecture/écriture temps réel, événements (alarmes/états), mesures historisées, et transactions structurées (création d'OT de maintenance, déclarations de consommations, remontées qualité, etc.).

Mapping de tags : risques classiques en multi-sites

Fragilité du point à point et perte de sémantique

Beaucoup de sites s'appuient encore sur des raccordements « point à point » : variable automate → tag supervision → export (CSV), script, passerelle spécifique ou interface dédiée vers l'ERP/GMAO. Cette approche peut fonctionner sur un périmètre limité, mais elle devient rapidement instable avec le multi-sites, la diversité des constructeurs, les évolutions d'automatismes et les contraintes de sécurité.

Le tag n'est pas une donnée métier

Un adressage PLC (par ex. %MW, DBx.DBDy) ou un nom de variable (par ex. P101_FT_Val) ne porte généralement pas l'information nécessaire à l'exploitation SI : unité, plage de validité, criticité, état qualité (good/bad/uncertain), temporalité (cyclique, sur variation, événement), contexte d'actif et interprétation métier (ex. « marche », « disponible », « en défaut », « en auto »). Sans couche de normalisation, le SI reçoit une valeur « brute » difficile à consolider et à auditer.

Hétérogénéité de nommage et de structure

Dans un parc industriel, les conventions divergent : préfixes, séparateurs, hiérarchies, modèles d'alarmes, équipements « similaires » mais instrumentés différemment, ou réutilisation de noms pour des sémantiques différentes. Résultat : la consolidation par site/atelier/ligne/actif revient à refaire un projet de reprise de données, coûteux et source d'erreurs.

Normalisation partielle et non gouvernée

Les référentiels existent, notamment ISA-95 / IEC 62264 pour structurer les niveaux entreprise → site → atelier → ligne, et ISA-88 / IEC 61512 pour les procédés batch. Dans la pratique, ils sont souvent appliqués « à la main » et partiellement, faute de modèles réutilisables, d'outils d'ingénierie et de gouvernance des identifiants. On obtient alors des semi-standards difficiles à maintenir.

Traçabilité insuffisante et incidents difficiles à diagnostiquer

Un flux OT vers ERP/GMAO doit être traçable : horodatage source OT, horodatage d'émission, statut de publication, accusé de réception, statut de traitement applicatif, gestion des erreurs, mise en quarantaine, reprise. Sans journalisation structurée et sans corrélation d'identifiants, les équipes OT/IT peinent à expliquer les pertes de messages, doublons, réordonnancements ou dérives de temps.

Méthode : modèle canonique, normalisation et audit

Transformer des tags en objets « SI-ready »

La démarche portée par ARC INFORMATIQUE consiste à convertir des tags hétérogènes en objets industriels normalisés et documentés, puis à les exposer vers le SI via des règles de transformation, des métadonnées et une traçabilité bout en bout. L'objectif est de découpler :

• la variabilité OT (constructeurs, adressages, protocoles),
• de la sémantique métier attendue par l'ERP/GMAO.

1) Définir un modèle canonique minimal

Avant tout mapping, on construit un modèle canonique qui stabilise les identifiants et la structure de la donnée :

• Identifiants d'actifs (AssetID) et rattachement à une hiérarchie type ISA-95 / IEC 62264,
• Classes d'équipements (pompe, compresseur, sous-station, poste de comptage, utilité, etc.),
• Types de mesures (débit, pression, énergie, état, compteur, KPI) et unités,
• Qualité de données : état qualité, valeurs par défaut/substituées, saturation, valeurs hors plage,
• Politique temporelle : période fixe, sur variation (deadband), événement, agrégation.

Pour cadrer la notion de qualité des données, on peut s'inspirer des concepts de la famille ISO 8000 (qualité des données), notamment pour clarifier les critères « exactitude, complétude, cohérence, actualité, traçabilité » appliqués aux mesures industrielles.

2) Industrialiser le mapping par modèles objet

Pour fiabiliser et accélérer les déploiements, le principe est de modéliser une fois les « briques récurrentes » (équipement + mesures + événements + alarmes + historisation + synoptiques + paramètres com), puis d'instancier ces modèles en ne modifiant que les paramètres variables (adresse, offsets, identifiants, contexte). Cette approche réduit le sur-mesure, homogénéise les conventions et facilite le maintien en condition opérationnelle.

3) Automatiser la normalisation depuis des sources d'ingénierie

Dès que le volume dépasse quelques milliers de points, l'automatisation devient un levier majeur. Plutôt que de ressaisir, on importe des sources existantes (listes PLC, exports des outils d'automatisme, inventaires d'actifs, extraits GMAO, nomenclatures) et on applique des règles :

• Normalisation de nommage (conventions, séparation des niveaux, suffixes unités),
• Enrichissement (unités, seuils, criticité, règles d'agrégation),
• Génération contrôlée (objets, points, historiques, événements), avec versioning et capacité de régénération.

Connectivité et cybersécurité sans casser la sémantique

Découpler protocoles et identifiants métier

Une architecture durable ne doit pas « coller » à un protocole unique : l'OT agrège des environnements mixtes (OPC UA, Modbus, protocoles constructeurs, MQTT, API). La normalisation doit agir comme une couche d'abstraction : changer un automate, une adresse ou un protocole ne doit pas changer l'identifiant métier ni la structure consommée par l'ERP/GMAO.

OPC UA : sécurité et gestion des certificats

Lorsque l'OPC UA est utilisé, la sécurité repose notamment sur des mécanismes de signature et de chiffrement, et sur l'usage de certificats X.509 pour établir la confiance entre client et serveur. Les choix de politiques de sécurité, le cycle de vie des certificats et la gestion de la « trust list » deviennent des points d'ingénierie à part entière, à documenter et à auditer. (Référence : OPC Foundation - OPC UA Part 2 Security.)

Architecture réseau industrielle : principes ANSSI

Sur la cybersécurité, il est recommandé de s'appuyer sur des guides nationaux. En France, l'ANSSI propose une approche de sécurisation des systèmes industriels (segmentation, zones/conduits, maîtrise des flux, principes d'architecture) dans son guide La cybersécurité des systèmes industriels. Ces principes aident à construire des architectures compatibles avec exploitation 24/7 : filtrage des flux, supervision sécurité, réduction de surface d'attaque et contrôle des échanges entre OT et SI (souvent via une zone d'échange de type DMZ industrielle).

Traçabilité vers ERP/GMAO : mécanismes concrets

Traçabilité technique : prouver le transport

Pour rendre les échanges auditables, mettez en place une journalisation structurée, horodatée, et corrélée :

• MessageID et CorrelationID (corrélation émission → réception → traitement),
• Statuts : émis, en file, envoyé, accusé, rejeté, rejoué,
• Mesures de latence et causes de rejet (schéma invalide, donnée hors plage, actif inconnu),
• Traçage des transformations (règle appliquée, version de modèle, conversions d'unités).

Traçabilité métier : relier un événement OT à une action SI

Au-delà du transport, l'ERP/GMAO doit pouvoir expliquer « pourquoi » une transaction existe. Exemples :

• Une alarme confirmée + persistance > X minutes sur un actif critique → création automatique d'un ordre de travail,
• Un compteur d'énergie rattaché à une zone → alimentation d'un reporting consolidé,
• Un dépassement de seuil process → création d'une non-conformité qualité.

Cette traçabilité nécessite des IDs stables (AssetID, EventID), des règles versionnées, et des preuves de traitement côté SI (ack applicatif, statut final, horodatage de clôture).

Points de vigilance : qualité, gouvernance, robustesse

Gouvernance des identifiants et référentiel d'actifs

Le principal risque ne vient pas du protocole mais des identifiants instables. Sans référentiel d'actifs robuste (création, modification, déclassement, responsabilités OT/maintenance/IT), le mapping devient une réconciliation permanente. Formalisez : conventions de nommage, règles de gestion, et un processus de validation des changements.

Horodatage, unités et conversions traçables

Les erreurs d'analyse proviennent souvent d'unités implicites ou de conversions non documentées (ex. m3/h vs Nm3/h), et de mélanges entre temps automate, temps SCADA et temps serveur SI. Conservez systématiquement :

• Timestamp source (OT) et timestamp d'acquisition,
• Fuseau horaire et gestion DST,
• Règles d'agrégation (moyenne, intégrale, comptage) et leur périodicité.

Idempotence et déduplication

Les doublons surviennent lors des reprises réseau/redémarrages. Pour éviter des OT de maintenance en double ou des consommations comptabilisées deux fois, implémentez :

• IDs déterministes (EventID stable),
• Idempotence côté SI (un même message n'est traité qu'une seule fois),
• Store-and-forward selon criticité, et politiques de retry/backoff,
• Tableaux de bord : erreurs, rejets, latence, taux de reprise.

Projection : vers des données OT plus contextualisées

Du tag à la donnée contextualisée

À mesure que les exigences de maintenance, performance et cybersécurité augmentent, la valeur se déplace vers des modèles d'information plus riches et des échanges mieux contextualisés (services/API/événements), tout en conservant une traçabilité et une gouvernance compatibles avec les contraintes d'exploitation industrielle.

Mettre en oeuvre avec une plateforme SCADA connectée

Standardiser, modéliser et exposer vers le SI

Pour outiller cette démarche, la plateforme SCADA PcVue est utilisée pour structurer une supervision orientée objet, industrialiser l'ingénierie, gérer une connectivité multi-protocoles et soutenir l'intégration vers les systèmes SI, tout en conservant une logique de normalisation et de traçabilité des échanges. (Voir la description produit sur FranceEnvironnement.)

Conclusion : sécuriser le passage du tag à la transaction SI

Résumé des bénéfices et prochaine étape

Un interfaçage SI/OT robuste transforme des tags OT en données métier normalisées et auditables grâce à : un modèle canonique (identifiants stables), une normalisation sémantique/temporale, une ingénierie industrialisée par modèles, et une traçabilité technique et métier de bout en bout. Cette approche réduit les erreurs, accélère les déploiements multi-sites et fiabilise l'exploitation 24/7.

Pour cadrer votre stratégie de mapping, définir un modèle canonique et mettre en place une traçabilité adaptée à vos flux ERP/GMAO, contactez ARC INFORMATIQUE afin de demander un devis et une étude d'intégration adaptée à votre contexte industriel.