Comment les analyseurs NIR s'intègrent aux automates et aux systèmes SCADA : un aperçu pratique

La place de l'analyseur dans la hiérarchie d'automatisation

Un analyseur NIR en ligne produit des valeurs de composition qui ne sont utiles à la régulation que si elles parviennent aux systèmes qui agissent sur elles. L'IEC 62264-1 (ISA-95) décrit cette interface par niveaux : les niveaux 1 à 3 forment le domaine des opérations de fabrication et du contrôle-commande, le niveau 3 correspond à la gestion des opérations de fabrication et le niveau 4 au domaine de l'entreprise [1]. Le guide PAT de la FDA note que les analyseurs de procédé génèrent généralement de grands volumes de données, qu'un accès facile et sécurisé à celles-ci est important pour la régulation en temps réel et l'assurance qualité, et que les attributs de qualité mesurés peuvent piloter une régulation par anticipation ou par rétroaction [2]. Cela compte dans les industries chimique et pharmaceutique et au-delà ; le dosage PID en boucle fermée est traité dans un guide distinct.

Protocoles : de la boucle de courant à OPC UA

La voie la plus ancienne est le signal analogique en courant continu de l'IEC 60381-1 [3], la plage de signalisation 4–20 mA étant spécifiée par l'ISA-50.00.01 [4]. Tous les automates l'acceptent, mais un analyseur multiparamètre a besoin d'une boucle par paramètre, et le signal ne transporte ni mot d'état ni horodatage. Modbus est un protocole client/serveur de type requête/réponse dont le serveur expose des entrées discrètes, des bobines (coils), des registres d'entrée et des registres de maintien, les registres étant des mots de 16 bits ; sur TCP/IP, il utilise le port 502 [5]. Un résultat en virgule flottante occupe donc plus d'un registre et, comme la spécification ne définit ni horodatage ni champ de qualité, le statut doit être mappé dans des registres supplémentaires par l'intégrateur [5].

EtherNet/IP et PROFINET sont des systèmes Ethernet temps réel cycliques, qui relèvent dans les normes de profils IEC de la famille de profils de communication 2 (CIP) et de la famille 3 (PROFIBUS & PROFINET) [6][7] ; ils conviennent à un analyseur qui doit apparaître comme un périphérique d'E/S dans le cycle de l'automate. OPC UA (IEC 62541) est une norme indépendante de la plateforme dont les serveurs exposent un espace d'adressage de nœuds typés, avec des services de lecture, d'écriture et d'abonnement aux changements de données, aux événements et aux alarmes, et qui intègre authentification, intégrité et confidentialité des messages [8]. C'est la voie habituelle vers le SCADA, le MES et les historiens.

L'enregistrement de résultat : valeur, statut, horodatage

Un résultat ne peut être exploité en toute sécurité que s'il porte trois éléments. OPC UA les formalise dans le DataValue : la valeur, un StatusCode de sévérité Good, Uncertain ou Bad, et un SourceTimestamp fixé par la source d'origine et transmis sans modification par les serveurs intermédiaires [9]. Le statut indique si l'automate peut utiliser le nombre ; l'horodatage indique quand la matière a été mesurée.

Pour l'état de santé des appareils, la recommandation NAMUR NE 107 décrit des signaux d'état normalisés, leurs symboles et leur hiérarchisation [10] : défaillance, contrôle de fonctionnement, hors spécification et maintenance requise [11]. Ces états doivent être exposés sous forme de mot d'état à côté de chaque valeur : avec Modbus, ce mappage doit être conçu [5] ; avec OPC UA, le StatusCode existe mais c'est le logiciel de l'analyseur qui doit le renseigner [9].

Latence : mesure, échantillonnage et publication

La latence est la somme de l'acquisition spectrale, de l'évaluation du modèle et de la communication. Dans OPC UA, la part de communication est fixée par l'intervalle d'échantillonnage auquel le serveur interroge la source et par l'intervalle de publication auquel les notifications sont livrées ; la spécification note qu'un cycle de mise à jour de la source plus lent et non synchronisé ajoute un retard supplémentaire [9]. Dans Modbus, l'équivalent est la période de scrutation du client [5]. Les valeurs de l'analyseur arrivent donc en retard et à intervalles variables ; Griesing-Scheiwe et al. montrent que des estimateurs supposant un retard et une période d'échantillonnage constants peuvent devenir instables lorsque ceux-ci varient [12]. Trois recommandations pratiques en découlent :

• Aligner la scrutation ou la publication sur le cycle de l'analyseur. Lire plus vite que l'analyseur ne produit de résultats ne fait que relire la même valeur ; c'est l'horodatage de la source, et non la scrutation, qui identifie une nouvelle mesure [9].
• Transmettre le statut avec chaque valeur. L'automate doit conserver sa dernière valeur valide ou passer dans un mode défini lorsque le statut est Bad ou Uncertain, ou lorsque l'appareil signale une défaillance [9][11].
• Documenter la mise à l'échelle, les unités et les types de données. Les registres Modbus ne portent aucune de ces informations ; la spécification d'interface doit donc les fournir [5].

Alarmes, historiens et cybersécurité

L'IEC 62682 énonce des principes de gestion des systèmes d'alarme dans les industries de procédé, compte l'historien d'alarmes et les indicateurs de performance parmi les composantes du système d'alarme, et définit sa finalité comme l'information des opérateurs sur des situations anormales exigeant une réponse [13]. Les limites de composition de l'analyseur doivent donc être rationalisées avec les autres alarmes de l'usine, et les résultats doivent être stockés avec leur statut et leur horodatage dans l'historien de l'usine, en cohérence avec les fonctions de niveau 3 de l'ISA-95 [1] et avec le guide PAT sur les dossiers de lot [2].

Côté réseau, l'IEC 62443-3-3 définit des exigences de sécurité système et des niveaux de sécurité, appliqués à travers les zones et conduits du système pour fixer un niveau cible à chaque actif [14]. Un analyseur placé dans sa propre zone, avec un conduit ne transportant que les variables convenues, suit ce modèle ; OPC UA le prend en charge avec l'authentification des applications et des utilisateurs et des messages signés et chiffrés [8].

L'approche d'USTECH en matière d'intégration

Le logiciel ProChem d'USTECH relie les analyseurs USTECH à l'automate et au SCADA de l'usine pour des tableaux de bord en direct, des alarmes et un pilotage automatique des consignes, en communiquant avec les automates via une interface HTTP sur Ethernet ; les ProLine2550 et ProLine17EC fournissent les mesures et caliX les modèles d'étalonnage. Le mappage des statuts et l'intervalle de mise à jour adaptés à un système de contrôle-commande donné sont définis avec les automaticiens de l'usine lors d'une étude de faisabilité menée avec vos propres échantillons.