Modernisation des IHM Bailey INFI 90 Symphony fonctionnant sous OpenVMS Alpha

Moderniser une IHM sans remplacer l’intégralité du système INFI 90

De nombreux systèmes Bailey INFI 90 continuent de fonctionner de manière fiable des décennies après leur installation initiale. Leurs contrôleurs, modules de communication, unités de terminaison et E/S de terrain peuvent encore assurer les fonctions de contrôle requises.

Le problème de cycle de vie le plus immédiat se situe souvent au-dessus de la couche des contrôleurs.

Les stations opérateur peuvent dépendre d’un matériel AlphaStation vieillissant, d’adaptateurs graphiques non pris en charge, de périphériques de stockage obsolètes et d’anciens environnements logiciels OpenVMS Alpha. Les pièces de rechange deviennent difficiles à obtenir, tandis que les ingénieurs expérimentés en OpenVMS et Bailey Symphony sont de moins en moins disponibles.

L’exemple considéré ici comprend quatre stations de travail AlphaStation 255. Chaque station exécute OpenVMS Alpha et héberge les fonctions d’interface opérateur Bailey Symphony d’un système de contrôle distribué Bailey INFI 90.

L’objectif n’est pas nécessairement de remplacer l’intégralité du DCS. Un objectif plus pragmatique consiste à supprimer la dépendance au matériel vieillissant des AlphaStation tout en préservant les contrôleurs stables, le câblage de terrain, les modules d’E/S, la logique de contrôle et les opérations de conduite du procédé.

Cette distinction modifie la stratégie de modernisation.

Le projet consiste principalement en une migration de l’interface opérateur et de la plateforme informatique. Il ne devient une migration complète du DCS que lorsque le cycle de vie des contrôleurs, les exigences de cybersécurité, les objectifs de production ou les conditions de support justifient le remplacement des couches de contrôle inférieures.

Plusieurs voies de modernisation sont possibles. Cependant, elles préservent des parties différentes du système existant.

Un émulateur Alpha peut préserver la quasi-totalité de l’environnement logiciel. Une migration vers OpenVMS x86 préserve la famille de systèmes d’exploitation, mais nécessite la migration des applications. Le remplacement de l’IHM basé sur OPC préserve la couche des contrôleurs tout en reconstruisant l’interface opérateur. Une stratégie d’évolution ABB peut moderniser progressivement l’architecture Symphony étendue.

Aucune voie ne doit être décrite comme un simple remplacement par un PC.

Figure 1. Trois grandes voies de modernisation peuvent préserver différentes composantes de l’investissement existant dans Bailey INFI 90 et Symphony.

Pourquoi le clonage du disque de l’AlphaStation ne suffit pas

Le clonage de disque est utile pour préserver un environnement OpenVMS Alpha installé. Il peut capturer le système d’exploitation, les fichiers d’application, la configuration des périphériques, les comptes utilisateurs, les logiciels Bailey, les bases de données, les éléments graphiques et les paramètres propres au site.

Cependant, le clonage d’un disque ne convertit pas les logiciels Alpha en logiciels x86.

Le système d’exploitation cloné contient toujours des instructions destinées aux processeurs Alpha. Son noyau, son chargeur d’amorçage, ses bibliothèques système, ses applications et ses pilotes matériels ont été conçus pour l’architecture Alpha.

Un PC moderne standard utilise un processeur x86-64. Il présente également des contrôleurs de stockage, des périphériques réseau, des structures d’interruptions, du matériel graphique, des interfaces de microprogramme et des bus périphériques différents.

VMware, VirtualBox, Hyper-V et les hyperviseurs x86 classiques virtualisent du matériel compatible x86. Ils ne traduisent normalement pas les instructions du processeur Alpha en instructions x86.

Par conséquent, placer une image disque OpenVMS Alpha dans une machine virtuelle x86 ordinaire ne rend pas cette image amorçable.

La machine virtuelle peut fournir un disque virtuel, un adaptateur réseau virtuel et un périphérique graphique virtuel. OpenVMS Alpha attend toujours un processeur Alpha et des périphériques compatibles de l’ère Alpha.

C’est pourquoi ces deux concepts doivent rester distincts :

La virtualisation présente normalement du matériel virtuel utilisant la même architecture de processeur que l’hôte.

L’émulation interarchitectures reproduit par logiciel un autre processeur et un autre environnement matériel.

OpenVMS Alpha requiert la deuxième approche lorsque les binaires Alpha et le système d’exploitation d’origine doivent rester inchangés.

Le clonage de disque n’est donc viable que dans trois situations limitées.

La première consiste à effectuer une récupération sur le même modèle d’AlphaStation, avec un stockage et des périphériques compatibles.

La deuxième consiste à effectuer une récupération sur un autre système Alpha pris en charge, après avoir apporté les modifications requises aux périphériques et à la configuration.

La troisième consiste à restaurer le système dans un émulateur Alpha qui reproduit un environnement AlphaServer ou AlphaStation compatible.

Le clonage seul ne résout pas le problème d’architecture. L’environnement cible doit toujours comprendre et exécuter les instructions machine Alpha.

L’émulation Alpha préserve la plus grande partie de l’investissement existant

L’émulation Alpha est généralement la solution la moins perturbatrice lorsque le logiciel Symphony existant doit rester opérationnel sans modification du code source.

Un émulateur Alpha s’exécute sur du matériel x86 moderne, mais présente à OpenVMS un système Alpha virtuel. Le système d’exploitation et les applications d’origine continuent de voir un environnement matériel compatible Alpha.

Des produits tels que CHARON-AXP sont conçus à cette fin. L’émulateur remplace le processeur Alpha physique, l’architecture mémoire, les contrôleurs de stockage, les adaptateurs Ethernet et les autres périphériques pris en charge par des équivalents définis par logiciel.

Le serveur x86 exécute Windows ou Linux comme environnement hôte. L’émulateur Alpha s’exécute au-dessus de cet hôte. OpenVMS Alpha s’exécute ensuite au sein du système Alpha émulé.

Cette approche diffère du portage d’OpenVMS vers x86.

L’installation originale d’OpenVMS Alpha reste une installation Alpha. Les binaires Bailey Symphony restent des binaires Alpha. L’émulateur traduit ou reproduit le comportement matériel Alpha requis.

Cela permet de préserver :

• Le système d’exploitation OpenVMS Alpha installé.

• Applications Bailey Symphony existantes.

• Graphiques opérateur et bases de données d’affichage.

• Configurations d’alarme et fichiers historiques.

• Comptes utilisateur et procédures de commande.

• Utilitaires existants propres au site.

• Interfaces applicatives qui dépendent de l’environnement Alpha.

• Flux de travail des opérateurs qui nécessiteraient autrement une nouvelle formation.

En pratique, la migration consiste généralement à créer une image vérifiée ou une sauvegarde des disques Alpha d’origine. Ces données sont restaurées dans des conteneurs de disques virtuels utilisés par l’émulateur.

La configuration de l’émulateur doit reproduire des caractéristiques appropriées du processeur, de la mémoire, des disques, du réseau et des périphériques. L’équipe peut également devoir mapper les ports série physiques ou les interfaces réseau via le système hôte.

L’émulation d’Alpha peut réduire considérablement la dépendance au matériel physique obsolète. Elle peut également simplifier les sauvegardes, car les fichiers de disques virtuels peuvent être copiés à l’aide d’une infrastructure de stockage moderne.

Toutefois, il convient d’employer l’expression « zéro changement » avec prudence.

Le code de l’application peut rester inchangé, mais l’environnement nécessite tout de même une étude technique. Les mappages des périphériques doivent être vérifiés. Les interfaces réseau doivent être configurées. Les licences OpenVMS et les licences applicatives doivent être examinées.

L’émulateur doit également être testé avec l’interface de communication Bailey utilisée sur le site.

Une application OpenVMS générique peut fonctionner correctement tandis qu’une interface DCS spécialisée échoue parce qu’elle dépend d’un adaptateur réseau, d’une interface de bus, d’un périphérique série ou d’un comportement temporel particulier.

La configuration exacte de l’AlphaStation 255 doit donc être inventoriée avant de sélectionner un profil d’émulateur.

L’interface de communication Bailey est le test d’émulation critique

La question la plus importante concernant l’émulation n’est pas de savoir si OpenVMS atteint l’invite de connexion.

La question importante est de savoir si la station émulée communique correctement avec le système Bailey INFI 90 dans les conditions d’exploitation normales.

L’interface peut dépendre d’Ethernet, d’une communication série, d’une interface réseau Bailey ou d’un matériel de communication spécialisé. Les configurations des sites peuvent varier considérablement.

Avant de s’engager dans l’émulation d’Alpha, les ingénieurs doivent documenter les éléments suivants :

• Interface réseau physique installée dans chaque AlphaStation.

• Protocole de communication utilisé entre Symphony et INFI 90.

• Noms de périphériques attribués dans OpenVMS.

• Adresses réseau et définitions des nœuds.

• Services DECnet, TCP/IP, LAT ou propriétaires requis.

• Paramètres des ports série, le cas échéant.

• Clés de licence externes ou dongles matériels éventuels.

• Comportement de la redondance et du basculement entre les stations opérateur.

• Exigences de synchronisation de l’heure.

• Fonctions graphiques et fonctions du clavier utilisées par les opérateurs.

Un fournisseur d’émulateurs peut prendre en charge les périphériques Ethernet et de stockage Alpha courants. Cela ne confirme pas automatiquement la prise en charge de chaque interface propriétaire Bailey.

Si l’IHM existante dépend d’un adaptateur physique spécialisé qui ne peut pas être virtualisé, l’approche par émulation peut nécessiter une passerelle de communication différente.

Le projet doit donc inclure un test sur banc utilisant une station clonée et un accès à un réseau Bailey représentatif.

Le test doit aller au-delà de la simple lecture statique des tags. Les opérateurs doivent vérifier les valeurs en temps réel, les commandes, les alarmes, les acquittements, les tendances, la navigation entre les écrans, l’impression, la gestion des événements et la récupération des stations.

Les performances doivent également être testées lors des pointes d’alarmes et des activités élevées de mise à jour des tags.

OpenVMS x86-64 constitue une autre voie de migration

Les versions modernes d’OpenVMS sont disponibles pour l’architecture x86-64. Elles peuvent fonctionner dans des environnements virtualisés pris en charge sur des serveurs modernes.

Cela crée une option de migration supplémentaire qui n’était pas disponible lors de nombreuses discussions antérieures sur la modernisation d’INFI 90.

Cependant, OpenVMS x86-64 n’exécute pas directement les binaires OpenVMS Alpha comme s’il s’agissait d’applications x86 natives.

L’environnement applicatif doit être migré.

Le code source devra peut-être être transféré, analysé, recompilé, lié et testé pour x86-64. Les bibliothèques tierces et les produits en couches doivent également être disponibles pour la version cible.

La question centrale est de savoir si le logiciel Bailey Symphony installé possède une version OpenVMS compatible avec x86.

Si l’éditeur du logiciel n’a jamais publié cette application pour OpenVMS x86-64, le simple déplacement du système d’exploitation ne préserve pas l’IHM.

Les programmes développés sur site peuvent être portables lorsque leur code source et leur environnement de compilation restent disponibles. Les applications commerciales fermées ne peuvent normalement pas être recompilées sans l’assistance du fournisseur.

Cette voie peut néanmoins rester pratique pour les serveurs de données personnalisés, les historiques, les utilitaires, les rapports et les applications d’intégration qui fonctionnent aux côtés de l’IHM Symphony.

Elle a moins de chances de préserver un ancien environnement opérateur propriétaire Symphony sans version prise en charge de l’application.

Une évaluation de la migration OpenVMS x86 doit identifier les éléments suivants :

• Chaque exécutable installé et chaque produit en couches.

• Code source et procédures de compilation disponibles.

• Dépendances vis-à-vis du compilateur et de l’environnement d’exécution.

• Produits de base de données et formats de fichiers.

• Bibliothèques de communication propriétaires.

• Dépendances graphiques ou liées au système de fenêtrage.

• Disponibilité des licences pour x86-64.

• Modifications nécessaires en raison des différences d’architecture.

• Hypothèses de performance et de synchronisation.

Cette voie offre un potentiel à long terme supérieur à celui d’un passage d’Alpha à une autre architecture matérielle abandonnée. Elle peut permettre d’exécuter des charges OpenVMS compatibles sur une infrastructure de virtualisation x86 prise en charge.

Il convient néanmoins de la décrire comme un projet de migration d’application, et non comme un projet de clonage de disque.

Pourquoi une migration Itanium constitue généralement une solution transitoire

OpenVMS a également été commercialisé pour les serveurs HPE Integrity utilisant l’architecture Itanium.

Il existe des outils de migration et des méthodes d’ingénierie pour transférer certaines applications Alpha vers OpenVMS Integrity. Cette solution offrait autrefois une voie prise en charge pour abandonner le matériel Alpha vieillissant.

Aujourd’hui, cependant, le matériel Itanium est lui-même une plateforme héritée.

Le passage d’Alpha à Integrity peut supprimer une dépendance à un matériel obsolète tout en en créant une autre. Les serveurs, pièces, interfaces de stockage et compétences spécialisées adaptés deviendront de moins en moins disponibles.

Itanium peut encore être pertinent lorsqu’un site possède déjà une infrastructure Integrity prise en charge. Il peut également être pertinent lorsqu’un produit logiciel requis existe pour Integrity, mais pas pour x86-64.

Pour un nouveau projet de modernisation, cette option doit généralement être évaluée comme une voie de compatibilité intermédiaire.

Le dossier commercial doit expliquer pourquoi le passage à Integrity est préférable à l’émulation Alpha, à la migration d’OpenVMS vers x86 ou à la remise en plateforme de l’IHM.

La remise en plateforme via OPC préserve la couche de contrôle

La remise en plateforme via OPC remplace la couche d’interface opérateur tout en conservant les contrôleurs INFI 90 et les E/S de terrain existants.

Un serveur de communication se connecte au système Bailey et expose les tags de processus à une plateforme IHM ou SCADA moderne.

La nouvelle IHM gère les écrans, les alarmes, les tendances, la sécurité, les commandes opérateur, les rapports et les services des postes de travail.

Cette approche élimine la dépendance à l’application opérateur Symphony d’origine. Elle évite également de devoir exécuter OpenVMS Alpha sur les nouveaux postes opérateur.

L’architecture comprend généralement :

• Les contrôleurs et E/S Bailey INFI 90 existants.

• Une interface de communication Bailey compatible.

• Un serveur de données OPC DA, OPC UA ou spécifique au fournisseur.

• Une plateforme IHM ou SCADA moderne.

• Postes de travail opérateur et d’ingénierie.

• Services facultatifs d’historisation, de création de rapports et d’analyse des alarmes.

Un exemple de terrain cité dans les sources utilisait un serveur OPC RoviSys avec GE CIMPLICITY. Le système signalé fonctionnait correctement, mais le projet nécessitait de reconstruire les écrans opérateur et la logique d’animation.

Cet exemple ne doit pas être interprété comme une recommandation automatique de produit pour chaque installation INFI 90.

Le serveur sélectionné doit prendre en charge le réseau Bailey spécifique, les modules de communication, la génération de contrôleurs, le nombre de tags, la fréquence de mise à jour, les exigences de redondance et les fonctions de commande du site.

Il en va de même pour la plateforme IHM.

GE CIMPLICITY est une plateforme IHM/SCADA d’entreprise possible. D’autres systèmes peuvent également convenir s’ils fournissent la connectivité OPC requise, les graphiques, les alarmes, les scripts, la redondance, la sécurité et la prise en charge du cycle de vie.

Figure 2. Une migration basée sur OPC préserve la couche de contrôle INFI 90 tout en remplaçant l’environnement opérateur Symphony existant.

La connectivité OPC ne convertit pas les écrans existants

Un serveur OPC fournit la connectivité aux données. Il ne convertit généralement pas les anciens écrans IHM dans un nouveau format IHM.

Les écrans Symphony d’origine peuvent contenir des graphiques statiques, des symboles dynamiques, des changements de couleur, des valeurs numériques, des graphiques à barres, des indicateurs d’alarme, des boutons de navigation, des commandes, des tendances et des modèles de fonctions personnalisés.

Ces éléments doivent être recréés dans l’IHM cible.

Les affichages simples peuvent être redessinés directement. Les affichages complexes peuvent contenir des scripts ou des expressions masqués qui ne sont pas immédiatement visibles.

Les ingénieurs doivent comprendre comment chaque objet animé obtient et traite ses données.

Un symbole de vanne ne suit pas nécessairement une seule balise de sortie. Sa couleur et sa position peuvent dépendre du retour d’ouverture, du retour de fermeture, de l’état de la commande, de l’état de l’interverrouillage, de la qualité de la communication et du mode de l’équipement.

Un symbole de moteur peut utiliser des balises distinctes pour la commande de démarrage, le retour d’information de fonctionnement, l’état à l’arrêt, le déclenchement, la commande locale, l’état de maintenance, les permissifs et l’inhibition des alarmes.

Le simple transfert des graphiques visibles peut donc créer une IHM qui semble correcte, mais qui se comporte de manière incorrecte.

L’équipe de migration doit documenter la signification fonctionnelle de chaque élément d’affichage.

Ce travail comprend les éléments suivants :

• Associer chaque objet dynamique à sa source de données.

• Recréer les expressions d’animation.

• Vérifier la confirmation des commandes et la sécurité.

• Reconstituer la navigation et les hiérarchies d’affichage.

• Recréer les classes et les niveaux de priorité des alarmes.

• Confirmer les unités d’ingénierie et la précision décimale.

• Reconstituer les tendances historiques et en temps réel.

• Tester les états de communication invalides, incertains et défaillants.

• Reproduire les messages et les consignes destinés aux opérateurs.

• Remplacer les polices et les symboles non pris en charge.

L’effort dépend donc de la complexité des affichages, et pas uniquement de leur nombre.

Une IHM moderne ne doit pas copier aveuglément chaque affichage existant

La recréation manuelle offre la possibilité d’améliorer l’interface opérateur.

Les graphiques IHM existants utilisent souvent des couleurs vives pour les équipements en fonctionnement normal, des schémas de procédé denses, des tuyauteries décoratives et des indications d’alarme incohérentes.

Ces conventions pouvaient être raisonnables lors du développement du système d’origine. Elles ne sont pas toujours idéales pour les pratiques actuelles des salles de commande.

Un projet de modernisation doit examiner les éléments suivants :

• Hiérarchie des affichages.

• Visibilité des alarmes.

• Cohérence de la navigation.

• Présentation de l’état des équipements.

• Utilisation des couleurs.

• Accessibilité des tendances.

• Exigences en matière de réaction des opérateurs.

• Résolution de l’écran et agencement du poste de travail.

• Accessibilité et lisibilité.

Les conditions normales d’exploitation doivent rester visuellement discrètes. Des couleurs vives doivent identifier les états anormaux qui nécessitent une intervention.

Les opérateurs doivent pouvoir passer d’une vue d’ensemble de l’usine à l’unité concernée, à la face-avant de l’équipement, à une tendance, à l’historique des alarmes et à un affichage de diagnostic sans naviguer excessivement.

Cependant, une refonte excessive peut créer un autre risque.

Les opérateurs ont peut-être utilisé les écrans d’origine pendant de nombreuses années. Modifier tous les symboles, toutes les couleurs et tous les parcours de navigation au cours du même projet peut accroître les besoins de formation et les risques liés à la mise en service.

Une approche équilibrée conserve les relations familières entre les processus tout en améliorant la présentation et la navigation des alarmes.

L’extraction des balises doit être traitée comme un lot de travaux d’ingénierie

Le contenu source évoque la possibilité d’exporter les données des balises Bailey au format CSV. Il ne fournit pas de procédure universelle confirmée.

Il ne faut donc pas supposer qu’une seule commande d’exportation produira une base de données IHM complète et propre.

Les sources possibles d’informations sur les balises comprennent :

• Bases de données de configuration Symphony.

• Définitions des affichages existants.

• Configuration des contrôleurs et dossiers d’ingénierie.

• Bases de données des serveurs de communication Bailey.

• Fonctions de navigation du serveur OPC.

• Fichiers de configuration des alarmes.

• Bases de données historiques.

• Listes de balises imprimées ou archivées.

• Feuilles de calcul d’ingénierie du site.

La navigation OPC peut constituer un point de départ pratique une fois que le serveur a établi la communication avec le système Bailey.

Il peut exposer les noms des balises, les identifiants des éléments, les descriptions, la qualité et les valeurs actuelles. Certains serveurs prennent également en charge l’exportation de l’espace de noms parcouru.

Toutefois, un espace de noms OPC peut ne pas inclure tous les champs nécessaires à la nouvelle IHM.

Les priorités des alarmes, les limites d’ingénierie, les regroupements d’affichages, les notes opérateur, la sécurité des commandes et les relations entre équipements peuvent être stockés ailleurs.

Certains serveurs OPC exposent les balises à l’aide de noms générés qui diffèrent des noms Symphony d’origine.

Le projet doit constituer un référentiel contrôlé des balises contenant au moins :

• Nom de la balise d’origine.

• Nom de la balise de la nouvelle IHM.

• Identifiant de l’élément OPC.

• Description.

• Type de données.

• Autorisation de lecture ou d’écriture.

• Unités d’ingénierie.

• Informations de mise à l’échelle.

• Limites et priorité des alarmes.

• Taux de mise à jour.

• Affichage associé.

• État de validation.

• Résultat du test.

Ce référentiel devient le registre de rapprochement entre les anciens et les nouveaux systèmes.

Le nombre de balises n’est pas la seule exigence de communication

Un test de navigation réussi ne prouve pas que l’architecture OPC peut prendre en charge l’IHM complète.

Les ingénieurs doivent évaluer le nombre de balises actives, le taux de mise à jour demandé, la fréquence des changements, l’activité des alarmes, le trafic des commandes et la redondance des serveurs.

Un système peut contenir des dizaines de milliers de balises configurées. Une seule partie d’entre elles peut être active simultanément sur les affichages opérateur.

Le serveur et l’IHM doivent être testés dans des conditions réalistes.

Les vérifications importantes des performances comprennent :

• Temps nécessaire pour ouvrir un affichage complexe.

• Délai entre une modification sur le terrain et l’animation sur l’IHM.

• Transmission des alarmes lors de pointes d’événements.

• Collecte des tendances au taux d’échantillonnage requis.

• Temps d’exécution de la commande et de retour d’information.

• Rétablissement après une interruption réseau.

• Basculement entre serveurs redondants.

• Comportement après le redémarrage du contrôleur.

• État de qualité pendant une défaillance de communication.

• Charge du processeur, de la mémoire et du réseau.

Les commandes nécessitent une attention particulière.

La lecture des valeurs via OPC peut être relativement simple. L’écriture sécurisée des valeurs nécessite un contrôle d’accès, une validation des commandes, une confirmation du retour d’information et une gestion correcte des défaillances de communication.

L’équipe doit tester chaque type de commande opérateur, et pas seulement une balise représentative.

ABB Symphony Plus propose une voie d’évolution plus large

Le remplacement d’OPC n’est pas la seule solution pour un système Bailey installé.

ABB continue de présenter Symphony Plus comme une plateforme d’évolution pour les anciennes installations Bailey, INFI 90, Harmony Rack et Symphony.

Une modernisation ABB progressive peut préserver certaines parties de l’architecture de contrôle et d’E/S installée tout en introduisant de nouveaux composants opérateur, d’ingénierie, réseau, de contrôle ou d’E/S.

Cette approche peut être intéressante lorsque l’organisation souhaite une stratégie de cycle de vie prise en charge par le fournisseur plutôt qu’un remplacement indépendant de l’IHM.

Le projet peut commencer par moderniser l’environnement opérateur. Les contrôleurs et les E/S peuvent rester en service jusqu’à ce que leur cycle de vie ou leur valeur opérationnelle justifie leur remplacement.

Les phases ultérieures peuvent traiter les communications, les contrôleurs, les outils d’ingénierie et les interfaces de terrain.

L’architecture exacte de la migration dépend de la génération du système installé.

Les installations Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony et Symphony Plus n’utilisent pas toutes les mêmes interfaces.

Les noms des modules et la terminologie réseau doivent être vérifiés à partir des schémas du site et des inventaires du matériel.

Les organisations qui maintiennent la couche de contrôle existante peuvent également examiner les composants ABB Bailey INFI 90 et Network 90 disponibles lors de la planification des pièces de rechange, du support du cycle de vie et d’une modernisation progressive.

Ce lien interne est pertinent, car les projets de modernisation exigent souvent que l’ancien système reste opérationnel pendant l’ingénierie, les tests et la bascule progressive.

Le maintien de contrôleurs de rechange, de modules de communication, d’alimentations et de modules d’E/S appropriés peut réduire les risques pendant cette transition.

Une IHM personnalisée ou open source est possible, mais elle exige une prise en charge interne

Une IHM personnalisée peut être développée à l’aide de frameworks logiciels open source ou commerciaux.

Le matériel source mentionne un serveur résidant sous VMS avec un client moderne basé sur Qt. Les architectures de ce type peuvent séparer la connexion aux données côté serveur du client opérateur.

Cette approche peut offrir davantage de flexibilité et éviter de dépendre d’un seul fournisseur d’IHM.

Cela peut également devenir un engagement de développement logiciel à long terme.

L’organisation doit prendre en charge ou maintenir :

• Serveur de communication.

• Base de données des tags.

• Application cliente.

• Framework graphique.

• Traitement des alarmes.

• Intégration de l’historien.

• Authentification des utilisateurs.

• Mises à jour de cybersécurité.

• Déploiement et contrôle des versions.

• Documentation et formation.

Qt, Python, C++, les technologies web ou d’autres frameworks peuvent produire des interfaces industrielles performantes. La difficulté ne consiste pas à dessiner un graphique de procédé.

La difficulté consiste à créer un système opérateur fiable, qui fonctionne correctement en cas de défaillances de communication, de redémarrages de serveurs, de vagues d’alarmes, de changements d’utilisateurs et de conditions anormales dans l’installation.

Une plateforme personnalisée ne doit être sélectionnée que lorsque l’organisation dispose d’une équipe d’ingénierie pérenne ou d’un intégrateur fiable sur le long terme.

Les licences peuvent déterminer si une voie technique est réalisable

Les logiciels industriels hérités utilisent souvent des mécanismes de licence liés aux identifiants matériels, aux adresses Ethernet, aux bases de données de licences, aux dongles ou aux clés d’autorisation délivrées par le fournisseur.

Un système cloné peut démarrer correctement, mais refuser de lancer l’application Symphony parce que l’identité du matériel virtuel a changé.

L’inventaire de migration doit inclure :

• Licences du système d’exploitation OpenVMS.

• Licences d’application Bailey Symphony.

• Licences de base de données.

• Licences réseau et de communication.

• Licences d’émulateur.

• Licences de comptage des points IHM et OPC.

• Licences d’historian.

• Options de redondance.

• Licences de client d’ingénierie.

• Licences de client d’exécution.

Il convient d’obtenir une confirmation écrite avant de choisir la plateforme finale.

La compatibilité technique sans disponibilité légale des licences ne permet pas de créer une solution déployable.

La cybersécurité doit être intégrée à la conception du remplacement

Les anciens systèmes AlphaStation étaient souvent installés avant que les pratiques modernes de cybersécurité industrielle ne deviennent courantes.

Ils peuvent fonctionner sur des réseaux isolés avec un accès à distance limité. Les remplacer par des serveurs Windows, des clients SCADA modernes, des serveurs OPC et une infrastructure Ethernet modifie la surface d’attaque.

La nouvelle architecture doit définir des zones réseau distinctes pour le contrôle, les serveurs, l’ingénierie et l’entreprise.

Les pare-feu doivent autoriser uniquement les chemins de communication nécessaires. L’accès à distance doit utiliser une authentification gérée et faire l’objet d’un enregistrement.

Les comptes opérateur doivent respecter des autorisations fondées sur les rôles. Les fonctions d’ingénierie ne doivent pas être accessibles depuis chaque client IHM.

L’accès en écriture OPC doit être limité aux tags et aux stations qui en ont besoin.

La conception doit également traiter les points suivants :

• Application des correctifs du système d’exploitation.

• Antivirus ou contrôle des applications.

• Sauvegarde et restauration.

• Synchronisation de l’heure.

• Journalisation de la sécurité.

• Contrôles des supports amovibles.

• Support à distance du fournisseur.

• Gestion des certificats pour OPC UA.

• Gestion du cycle de vie des comptes.

Les contrôles de cybersécurité ne doivent pas empêcher les opérateurs d’intervenir lors d’événements survenant dans l’usine. La conception doit établir un équilibre entre protection, disponibilité et fonctionnement déterministe.

La migration doit commencer par un inventaire fondé sur des éléments probants

Avant de choisir une voie, les ingénieurs doivent documenter en détail le système existant.

L’inventaire doit inclure les quatre AlphaStations et indiquer si leurs configurations sont réellement identiques.

Consigner :

• Modèle d’AlphaStation et configuration du processeur.

• Capacité mémoire.

• Type de disque et volumes logiques.

• Version d’OpenVMS et niveau de correctifs.

• Versions des logiciels Bailey installés.

• Produits et bases de données en couches.

• Matériel graphique et résolution d’affichage.

• Adaptateurs réseau.

• Interfaces série.

• Matériel de communication Bailey.

• Noms et adresses des nœuds.

• Procédures de commande de démarrage.

• Fichiers de licence.

• Procédures de secours.

• Redondance des postes opérateur.

• Imprimantes connectées et appareils externes.

• Conservation des données historiques et des données d’alarme.

L’équipe doit également recueillir des captures d’écran de chaque affichage. Les états dynamiques doivent être capturés lorsque cela est possible.

Consignez les états normal, arrêté, en marche, en alarme, inhibé, local, manuel, automatique et en échec de communication.

Ces éléments probants sont essentiels lors du test des nouveaux écrans.

Un système de banc est obligatoire

Aucune voie de modernisation ne doit être testée pour la première fois sur le système de production en fonctionnement.

Un environnement de banc doit reproduire une partie suffisante de l’architecture installée pour valider les communications et les fonctions opérateur.

Pour un projet d’émulation, le banc doit contenir un environnement OpenVMS Alpha cloné et la configuration d’émulateur proposée.

Pour un projet OPC, il doit inclure le serveur de communication sélectionné, le logiciel IHM, des graphiques représentatifs et l’accès à un nœud de test Bailey sécurisé ou à une source de données simulée.

Le test sur banc doit vérifier :

• Démarrage du système et lancement de l’application.

• Communication avec le système Bailey.

• Nombre total de tags accessibles.

• Opérations de lecture et d’écriture.

• Mise à l’échelle des tags et unités d’ingénierie.

• Génération et acquittement des alarmes.

• Collecte des tendances.

• Animation des écrans.

• Sécurité des commandes.

• Fonctions d’impression et de génération de rapports.

• Comportement au redémarrage du serveur.

• Comportement en cas de défaillance du réseau.

• Redondance et basculement.

• Restauration des sauvegardes.

• Temps de réaction de l’opérateur.

Les résultats des tests doivent être examinés par des représentants de l’exploitation, de l’ingénierie des systèmes de contrôle, de la maintenance et de la cybersécurité.

Le fonctionnement en parallèle réduit le risque lié à la bascule

Les AlphaStations d’origine doivent rester disponibles pendant le déploiement initial du système de remplacement.

La nouvelle IHM peut fonctionner en parallèle pendant que les ingénieurs comparent les valeurs, les alarmes, les tendances et les commandes.

Le fonctionnement en parallèle permet d’identifier les écarts avant le retrait de la station existante.

L’équipe doit comparer :

• Valeurs de processus affichées.

• Indications d’état.

• Priorités des alarmes.

• Horodatage des alarmes.

• Résultats des commandes.

• Valeurs des tendances.

• Mode de fonctionnement de l’équipement.

• Qualité des communications.

• Autorisations de sécurité.

Toute différence ne constitue pas nécessairement une erreur. Le nouveau système peut utiliser une mise à l’échelle améliorée ou une présentation améliorée des alarmes.

Chaque différence doit néanmoins être expliquée et approuvée.

Les stations existantes doivent rester récupérables jusqu’à ce que la nouvelle IHM ait réussi un test d’acceptation sur site observé et une période opérationnelle convenue.

Choisir la bonne voie de migration

Choisissez l’émulation Alpha lorsque :

L’application Symphony existante doit rester inchangée. Le code source n’est pas disponible. Les graphiques opérateur sont complexes. La reconversion doit être réduite au minimum. L’interface de communication Bailey peut être prise en charge par l’architecture de l’émulateur.

Choisissez la migration vers OpenVMS x86 lorsque :

Les applications requises sont disponibles pour x86-64 ou peuvent être recompilées. Le code source et les connaissances techniques restent disponibles. L’organisation souhaite conserver OpenVMS tout en passant à un environnement x86 pris en charge.

Choisissez une migration vers une nouvelle plateforme OPC lorsque :

Le contrôleur INFI 90 et les couches d’E/S restent fiables. L’organisation souhaite une plateforme IHM moderne. Des ressources d’ingénierie sont disponibles pour reconstruire et valider les écrans, les alarmes, les tags et la logique des commandes.

Choisissez une voie d’évolution ABB lorsque :

L’organisation souhaite un programme de modernisation plus vaste, pris en charge par un fournisseur. Les phases futures peuvent inclure les systèmes opérateurs, les outils d’ingénierie, les interfaces réseau, les contrôleurs et les E/S.

Choisissez une IHM personnalisée lorsque :

L’organisation a des exigences spécialisées et peut prendre en charge le développement logiciel, les tests, la cybersécurité et la maintenance sur l’ensemble du cycle de vie à long terme.

Conservez temporairement le système existant lorsque :

Les interfaces de migration restent floues. Les sauvegardes sont incomplètes. Les licences ne sont pas résolues. Les bases de données de tags sont indisponibles. Les tests sur banc ne permettent pas encore de reproduire le chemin de communication Bailey.

Un plan pratique de modernisation par phases

Phase 1 : Préserver l’environnement existant.

Créez des sauvegardes d’image vérifiées de chaque AlphaStation. Consignez les informations relatives au matériel, aux logiciels, au réseau, aux licences et au démarrage. Testez la restauration lorsque cela est possible.

Phase 2 : Identifier l’architecture de communication.

Documentez précisément la manière dont chaque station Symphony communique avec INFI 90. Vérifiez si l’interface peut être émulée ou remplacée par un serveur pris en charge.

Phase 3 : Élaborer une preuve de concept.

Testez une station clonée sur un émulateur Alpha ou connectez un serveur OPC à un nœud Bailey représentatif.

Phase 4 : Créer le référentiel des tags.

Vérifiez la correspondance entre les tags des contrôleurs, les identifiants des éléments OPC, les unités d’ingénierie, les commandes, les alarmes et l’utilisation des écrans.

Phase 5 : Reconstituer des écrans représentatifs.

Sélectionnez plusieurs écrans présentant des exigences différentes en matière d’animations, d’alarmes, de commandes et de tendances.

Phase 6 : Achever la validation sur banc.

Testez le chargement complet des tags, les défaillances de communication, le redémarrage du serveur, les rafales d’alarmes, le comportement des commandes et la restauration des sauvegardes.

Phase 7 : Déployer en parallèle.

Faites fonctionner simultanément les IHM nouvelles et anciennes. Comparez les valeurs et les réponses des opérateurs.

Phase 8 : Effectuer la bascule sous observation.

Utilisez une procédure de test approuvée. Gardez les AlphaStations disponibles comme solution de secours.

Phase 9 : Retirer progressivement le matériel obsolète.

Ne détruisez pas les images d’origine, les enregistrements de configuration, les licences ou le matériel avant la fin de la validation à long terme.

Foire aux questions

Un disque d’OpenVMS AlphaStation peut-il être cloné directement vers un PC moderne ?

Non. L’image contient du code machine Alpha et nécessite un matériel compatible Alpha. Un PC x86 moderne ne peut pas démarrer directement cette image. Celle-ci doit être restaurée sur un matériel Alpha compatible ou dans un émulateur Alpha.

VMware ou VirtualBox peuvent-ils exécuter OpenVMS ?

Ils peuvent exécuter les versions prises en charge d’OpenVMS x86-64. Ils ne convertissent pas une ancienne installation OpenVMS Alpha en application x86. OpenVMS Alpha nécessite une émulation Alpha.

Les écrans Symphony d’origine peuvent-ils être conservés ?

Elles peuvent généralement être préservées lorsque l’environnement Alpha complet s’exécute sous un émulateur compatible. Elles doivent normalement être recréées manuellement lors du passage à une autre plateforme d’IHM.

Un serveur OPC exporte-t-il automatiquement chaque balise Bailey ?

Pas nécessairement. La navigation OPC peut fournir un espace de noms utile, mais la configuration des alarmes, les relations entre les écrans, les commandes, les descriptions et les métadonnées d’ingénierie peuvent nécessiter une extraction et une réconciliation supplémentaires.

GE CIMPLICITY est-il le seul remplacement possible pour l’IHM ?

Non. Il s’agit d’une plateforme possible, mentionnée dans l’exemple de terrain fourni avec la source. La sélection finale doit dépendre de la prise en charge des communications, de la redondance, des licences, de la cybersécurité, des ressources d’ingénierie et des besoins des opérateurs.

La migration d’Alpha vers Itanium est-elle toujours pertinente ?

Cela peut se justifier lorsque les logiciels requis ne sont disponibles que pour les systèmes Integrity ou lorsque l’infrastructure Integrity existante est déjà prise en charge. Il s’agit généralement d’une voie transitoire plutôt que de la meilleure stratégie de modernisation à long terme.

Les contrôleurs et les E/S INFI 90 peuvent-ils rester installés ?

Oui, lorsqu’elles restent fiables et que l’architecture de communication retenue les prend en charge. La modernisation de l’IHM peut être réalisée séparément du remplacement des contrôleurs et des E/S.

Les anciennes AlphaStations doivent-elles être retirées immédiatement après la bascule ?

Non. Elles doivent rester disponibles comme solution de repli testée jusqu’à ce que le nouvel environnement opérateur ait réussi les tests fonctionnels, de performance et de réception opérationnelle.

La solution correcte dépend de ce qui doit être préservé

La principale erreur technique de nombreux projets d’IHM anciennes consiste à traiter la station opérateur comme un PC ordinaire.

Une AlphaStation exécutant OpenVMS Alpha et Bailey Symphony constitue un environnement matériel et logiciel complet. Son architecture de processeur, son système d’exploitation, ses interfaces de communication, ses binaires applicatifs, ses licences, ses graphiques et ses connexions au système de contrôle sont interdépendants.

Un clone de disque préserve les données. Il ne traduit pas cet environnement vers une autre architecture.

L’émulation Alpha offre la voie la plus directe lorsque l’installation Symphony complète doit rester inchangée.

OpenVMS x86-64 offre une voie de modernisation du système d’exploitation lorsque les applications peuvent être migrées ou recompilées.

La refonte de la plateforme OPC constitue une voie pratique lorsque la couche de contrôle INFI 90 reste utile, mais que la couche opérateur doit être remplacée.

L’évolution vers ABB Symphony Plus peut offrir une stratégie progressive plus large lorsque l’organisation souhaite moderniser au-delà de l’IHM.

La décision finale doit s’appuyer sur un inventaire vérifié, une étude des interfaces de communication, une revue des licences, une preuve de concept, un essai sur banc et une réception opérationnelle en présence des parties prenantes.

Il n’existe pas de remplacement sans effort. Il existe toutefois plusieurs voies de migration contrôlées qui peuvent protéger l’investissement existant dans le contrôle des procédés tout en supprimant la dépendance au matériel AlphaStation vieillissant.