Automate MFC3000, utilisé par le SNCC Alstom Alspa P320 S6
Généralités
Alstom (initialement CEGELEC) a mis en œuvre différentes solutions de contrôle commande et d’automatisme au fil du temps, basées :
- Sur des automates fournis par des tiers (GE Fanuc, B&R automation ; AdLink) en procédant la plupart du temps à une personnalisation de la couche système (GE Fanuc 90-30 C80-35 ; GE Fanuc 90-70 C80-75 ; GE Fanuc Rx3i ; B&R automation APC620 MFC1000; AdLink MFC3000 ; B&R automation X20 CE1000 ; B&R automation X20 CE1500 ; ICS Triplex Trusted CE3500).
- Sur des automates conçus entièrement par Alstom (C350 ; C370 ; CE2000 ; CE3000).
- Sur des cellules d’automatisme spécifiques : Controbloc T20 (destiné aux centrales thermiques), Controbloc N20 (destiné aux centrales nucléaires).
- Sur des réseaux Ethernet standard, en personnalisant ou non le protocole utilisé : réseau de terrain EPL, réseaux d’unité S-8000 E900 et S-8000 E920.
- Sur le réseau industriel FIP : réseau de terrain F-8000, réseau d’unité F-900.
- Sur des superviseurs conçus par Alstom et installés sur différents types de cibles : Centralog renommé par la suite Alspa HMI, qui a évolué au fil du temps et des séries : Centralog VME, Centralog Unix, Centralog Windows, Alspa HMI. L’obsolescence des matériels (racks VME, stations Sun) a rendu les premières séries de superviseurs de moins en moins utilisées. Centralog Windows (à partir de la Série 5) a l’avantage de pouvoir être exécuté sur des machines virtuelles.
- Sur un outil d’ingénierie global, utilisé ou non en fonction des projets (contrôle machine ou système numérique de contrôle commande), Controcad, qui se décline en une multitude de versions, fonctionnant initialement uniquement sous Unix, puis par la suite sous Windows à partir de la version 3 de Controcad.
Le nom des solutions d’automatisme et de contrôle commande fournies par Alstom varie en fonction du type de projet (contrôle machine uniquement ou système numérique de contrôle commande complet), on retrouvera notamment :
- Des contrôleurs de turbine vapeur : TGC820 ; P320 TGC V1 ; P320 TGC V2 ; P320 TGC V2+ ; Alspa ControSteam V3 ; Alspa ControSteam V4E (le contrôleur d’ABB Turbotrol est également fréquemment utilisé sur les centrales fournies par Alstom, interfacé avec un SNCC Alstom).
- Un contrôleur de turbine à gaz : Alspa ControGas V3. Il s’agit en fait d’une reprise de la logique initialement implémentée dans le contrôleur d’ABB Egatrol, utilisé sur projets Alstom comportant une turbine à gaz avec qu’Alstom ne développe sa propre solution.
- Des solutions d’excitation : AVR820 ; AVR820E ; AVR920 ; P320 AVR V1 ; P320 AVR V2 ; Alspa ControGen…
- Des labels faisant références à la globalité du système numérique de contrôle commande : Alspa P320 S4 ; Alspa P320 S5 ; Alspa P320 S6 ; Alspa ControPlant…
Les solutions d’automatismes proposées par Alstom sont essentiellement utilisées, en ce qui concerne la gamme Alspa P320, dans le domaine de la production d’énergie :
- Centrales complètes (conventionnel, cycle combiné, énergie renouvelables).
- Contrôle machine : turbine à vapeur ou turbine à gaz.
- Rarement, contrôle d’uniquement une partie de la centrale qui n’est pas une machine tournante : AVR seulement par exemple.
L’outil Controcad
L’outil Controcad permet d’interagir avec l’ensemble des éléments qui constituent un système numérique de contrôle commande Alspa.
Dans un domaine où l’on retrouve souvent un automate, un logiciel permettant de modifier la logique, un superviseur spécifique, une ouverture de l’automate sur l’extérieur par le biais de protocoles de communication, Controcad propose une approche différente, un niveau plus élevé de gestion de l’ensemble du contrôle-commande.
Cette approche présente de nombreux avantages (un export d’un projet Controcad comporte toutes les informations, un contrôle de cohérence lorsqu’une partie du contrôle commande est modifié alerte le technicien dans le cas où il omet de répercuter sa modification ailleurs, Controcad répercute de lui-même la majorité des modifications, la plupart des modifications et chargement peuvent être effectués en utilisant un seul outil, la gestion des échanges est automatisée, etc.) comme quelques inconvénients (la vérification de cohérence effectuée lors de chaque génération de code dure un certain temps, des modifications basiques sur les vues doivent être effectuées dans Controcad puis générées et chargées, il en va de même pour les modifications basiques concernant par exemple les alarmes ou libellés de variables, le système est tellement complexe qu’un ingénieur système est souvent nécessaire pour profiter pleinement de ses avantages, etc.)
L’ensemble d’un projet Controcad est stocké sous deux formes :
- Fichiers
Contient l’imagerie, les librairies et basic functions utilisées, le code automate déjà généré, les informations de debug, les fichiers utilisés par des programmes tiers interfacés avec Controcad, certains paramètres spécifiques : configuration des réseaux Profibus, configuration des passerelles CSS-G, de certains automates qui ne sont pas complètement interfacés avec Controcad et sont programmés et chargés par un outil tiers (par exemple sécurités chaudière Trusted CE3500), la documentation et les templates associés… - Base de données
Contient toute la configuration du projet, l’intégralité des variables et des échanges, la configuration des blocs fonctionnels, la configuration des superviseurs et des données de supervision, tous les schémas d’automatisme avant compilation, et bien d’autres information.
La base de données Controcad, qui utilise Oracle, est accessible en lecture comme en écriture par n’importe quel client SQL s’interfaçant avec Oracle. Il est donc possible, assez aisément, d’effectuer des modifications de masse dans un projet via de simples scripts (par exemple, décaler tous les blocs ET du projet d’une case vers la gauche, modifier les libellés de toutes les variables produites par un bloc spécifique et consommées par un autre et utilisées par un superviseur, etc.) mais également de regrouper plusieurs projets Controcad en un seul, d’exporter la totalité de la configuration du système de contrôle commande en vue d’un rétrofit, ou de comparer la logiques et les valeurs de réglages de deux projets différents en se connectant simultanément aux deux bases de données. Il s’agit là d’un standard unique dans le domaine des systèmes numériques de contrôle commande, qui rend possible certains traitements qui seraient tout simplement irréalisables sur d’autres systèmes. Toutefois, une connaissance de la structure de la base de donnée est nécessaire. Sur ce point, vous pouvez nous contacter si vous avez un besoin spécifique.
L’ensemble des composants du système numérique de contrôle commande (automates, réseaux, superviseurs, liens avec des systèmes tiers, horloges, etc) est normalement (il existe quelques exceptions, nous y reviendrons) défini dans l’arborescence matérielle (Hard) du projet. On y retrouve également les différents espaces de travail, l’ordre d’exécution des programmes automates, etc.
L’ensemble des blocs d’automatisme est défini dans l’arborescence des librairies (Lib). Les blocs peuvent être écrit directement au format LEA (Langage Elaboré Automatisme), ou sous forme de schéma blocs qui seront par la suite convertis au format LEA (dans Controcad, tous les diagrammes sont exportés au format LEA lors de leur sauvegarde). Les blocs d’automatisme peuvent appeler d’autres blocs d’automatisme ainsi que des sous-fonctions (basic functions), qui peuvent être notamment écrites en LEA ou en C. Un outil, le Basic Function Editor, permet de compiler facilement ces sous-fonctions pour les différentes cibles gérées par Controcad.
L’ensemble de la logique (lien entre les blocs d’automatisme issus des librairies) se retrouve dans l’arborescence fonctionnelle (Fct), sous forme de diagrammes d’automatisme. Après génération de code, si ces diagrammes sont affectés à un automate (par le biais des POU), ils sont copiés en lecture seule dans l’arborescence matérielle et toutes les variables utilisés se voient affecter une adresse dans l’automate cible. Les diagrammes peuvent également être générés pour simulation, directement dans l’arborescence fonctionnelle. La documentation du projet peut être automatiquement configurée et générée dans l’arborescence fonctionnelle.
L’ensemble des traitements de supervisions et traité dans l’arborescence de supervision (Hmi). On y retrouve notamment la configuration des médaillons de commande, des variables de synthèse, des vues de supervision, etc.
Le contenu des vues, des sous-dessins et des fiches d’alarmes est pour sa part traité dans l’arborescence des vues (Views). C’est l’éditeur DV-Draw, appelé depuis l’arborescence des vues, qui permet de modifier une vue.
Enfin, la configuration des variables et des traitements associés est accessible depuis la grille des variables, elle-même affichable depuis l’arborescence fonctionnelle.
Cette organisation présente des avantages et des inconvénients, comme toute interface. Dans la mesure où il est possible de s’interfacer directement avec la base de données pour répondre à des besoins spécifiques et effectuer des modifications simultanées dans les différentes arborescences, l’utilisateur avancé peut en règle générale effectuer aisément tout type de modification.
Il existe trois type de générations dans Controcad :
- La génération du code automate. Les échanges de variables sont générés automatiquement par Controcad (sauf en cas de configuration manuelle d’adresses particulières). Controcad s’efforce, dans la mesure du possible, de conserver les adresses des échanges déjà existants (il existe plusieurs modes de génération, dans le cas d’une génération en ligne, un échange déjà existant ne peut pas se voir affecter une nouvelle adresse). Le code des diagrammes et des blocs d’automatisme est converti en C. Les basic functions, déjà compilées, sont appelées directement. Le code C est ensuite compilé par le compilateur utilisé par l’automate cible.
- La génération HMI. L’ensemble des données de supervision est exporté sous forme de fichiers texte (fichiers .UO ou .CSV en fonction des versions) après vérification de cohérence. Le superviseur Centralog CIS par le biais du CCC ou Alspa RTDS se charge de leur interprétation.
- La génération des vues. L’ensemble des vues, sous-dessins et fiches d’alarmes est exporté sous forme d’archive après vérification de cohérence. L’outil de visualisation des synoptiques EXP ou Alspa HMI se charge de leur affichage sur les stations opérateur.
Le code automate généré peut être chargé dans les automates cibles par le biais de l’outil Cell Loader, intégré à Controcad, ou des outils généralement utilisés pour charger le type d’automate utilisé (P80, Machine Edition, etc). L’outil Cell Loader présente l’avantage de vérifier la cohérence globale de la cellule d’automatisme, de gérer la cohérence réseau, de vérifier les versions des programmes chargés, etc.