Programmation de PLC et SCADA

Ce que nous faisons pour la ligne du client

Nous écrivons les programmes de commande pour les automates industriels et les systèmes SCADA qui pilotent du matériel déjà installé chez le client : convoyeurs, presses, doseurs, groupes de pompage et fours. Les machines et les entraînements coupent, pressent et déplacent le produit physiquement, et notre périmètre de responsabilité, c'est la logique de leur fonctionnement, l'échange de données et la visualisation sur les pupitres opérateur. Dans le cadre de la prestation, nous analysons le schéma technologique de la ligne, décrivons les entrées et sorties de l'automate, programmons les séquences de démarrage et d'arrêt, les verrouillages et le traitement des avaries. À part, nous assemblons le projet SCADA : synoptiques, courbes de tendance, journaux d'événements et d'alarmes, droits d'accès des opérateurs. En sortie, le client reçoit un programme opérationnel, chargé dans son PLC, et un système de supervision configuré, et non du nouveau matériel.

Comment fonctionne le couple PLC et SCADA

L'automate programmable interroge cycliquement les capteurs, exécute la logique de commande et envoie les ordres aux actionneurs en quelques millisecondes. Ce cycle se répète en continu, c'est pourquoi la réaction à l'activation d'un fin de course ou au déclenchement d'un capteur de pression est déterministe et prévisible. SCADA se situe un niveau au-dessus : il récupère les données des automates via des protocoles industriels comme Modbus, Profinet ou OPC UA et montre à l'opérateur l'état de la ligne en temps réel. La programmation du PLC est responsable des décisions rapides sur place, et SCADA de la surveillance, de l'archivage et de l'intervention manuelle là où elle est admissible. Nous concevons les deux parties de sorte que l'automate conserve le contrôle de la ligne même en cas de perte de liaison avec le niveau supérieur.

D'où viennent les automates industriels

Le premier automate programmable apparut en 1969 : l'équipe de Dick Morley, au sein du bureau d'études Bedford Associates, réalisa l'appareil à la demande de la division General Motors Hydramatic, qui cherchait en 1968 à remplacer les armoires d'automatismes à relais. Le projet reçut la désignation 084, car il s'agissait du quatre-vingt-quatrième développement de l'entreprise, et l'automate lui-même fut nommé Modicon — abréviation de modular digital controller. General Motors reçut le premier lot en novembre 1969, ce qui remplaça les schémas à relais câblés en dur par une logique reprogrammable. Une armoire à relais devait être physiquement recâblée à chaque changement de procédé, alors qu'un automate, il suffit de le reprogrammer. C'est de cet appareil qu'est née toute la branche dans laquelle nous travaillons aussi, en préparant des programmes pour les automates des lignes en service des clients.

Pourquoi le logiciel et le réglage sont critiques

L'automate en lui-même est neutre : un même PLC peut conduire correctement la ligne ou la précipiter dans l'avarie — tout dépend de la logique programmée. Une erreur dans une condition de verrouillage signifie que la presse descendra alors que le carter est ouvert, et un scénario d'urgence oublié laissera la pompe tourner à sec. C'est pourquoi nous travaillons non seulement le cycle nominal, mais aussi le comportement en cas de défaillance d'un capteur, de coupure de liaison, d'appui sur le coup-de-poing d'arrêt d'urgence et de baisse d'alimentation. La précision du réglage des temporisations, des consignes et de l'ordre de coupure des mécanismes influe directement sur le rebut, l'usure du matériel du client et la sécurité du personnel. C'est physiquement le matériel du client qui coupe et presse, mais ce qui détermine quand et dans quelles conditions cela se produit, c'est précisément le programme de commande.

Notre stack et nos langages

L'outil de base pour les automates d'un large éventail de fabricants, c'est Codesys, un environnement conforme à la norme IEC 61131-3, dans lequel nous écrivons aussi bien une logique à relais explicite qu'un code structuré. Pour le matériel Siemens, nous travaillons sous TIA Portal, qui réunit la programmation des PLC de la série S7, la configuration réseau et le développement des pupitres opérateur dans un seul projet. Le ladder logic, c'est-à-dire le langage des schémas à contacts, nous l'appliquons aux verrouillages et à la logique discrète, où le schéma visuel est plus proche des électriciens et des metteurs en service du client. Le structured text, langage texte de type Pascal, nous le prenons pour les calculs, le traitement de tableaux, les recettes et les algorithmes qui, sous forme de relais, deviendraient lourds. Le choix du langage est dicté par la tâche : une partie du programme reste en relais pour la lisibilité lors de la maintenance, une partie s'écrit en texte pour la compacité et le contrôle des calculs.

Quand sont apparus les langages et normes

La norme sectorielle unique pour les langages de programmation des automates — IEC 61131-3 — fut publiée pour la première fois en décembre 1993 et largement révisée en 2013 ; c'est elle qui consacra les schémas à contacts et le texte structuré comme partie d'un jeu commun. L'environnement Codesys remonte à 1994, quand Dieter Hess et Manfred Werner fondèrent la société 3S-Smart Software Solutions et sortirent la première version conforme à cette norme. Siemens présenta TIA Portal plus tard, en novembre 2010, en réunissant des paquets auparavant dispersés pour automates et pupitres en un environnement d'ingénierie unique. Les langages de logique à relais eux-mêmes remontent aux schémas électriques à relais de l'ère pré-automate, et les langages texte vinrent plus tard avec la normalisation. Nous gardons en service des outils de différentes années de sortie, car on rencontre chez les clients du matériel de générations aussi récentes que plus anciennes.

Pourquoi vous pouvez nous confier la tâche

L'expérience cumulée de notre équipe de développement en informatique dépasse 45 ans, et nous abordons les programmes de commande comme un système d'ingénierie, et non comme un assortiment de schémas disparates. Avant la mise en production, nous vérifions la logique en simulation et sur des émulateurs d'automates, nous testons les scénarios d'urgence et les modes de mise en service, afin que la ligne du client ne devienne pas un banc d'essai. Nous documentons les entrées, les sorties et la logique de verrouillage de sorte que les metteurs en service et le service technique du client puissent comprendre le projet sans nous. La programmation du PLC et le réglage du SCADA, nous les remettons avec la description des consignes, des alarmes et de la marche à suivre de l'opérateur, et non comme une boîte fermée. Les capacités de production et le matériel restent au client — nous répondons du fait que ses machines fonctionnent selon une logique éprouvée et prévisible.