Contrôleur logique programmable : guide complet sur le fonctionnement, les types, la programmation et la sélection des automates

Qu'est-ce qu'un automate programmable et pourquoi l'industrie en dépend

Un automate programmable (PLC) est un ordinateur industriel robuste conçu spécifiquement pour surveiller les entrées des capteurs et des appareils de terrain, exécuter un programme de contrôle stocké et contrôler les sorties, telles que les moteurs, les vannes, les actionneurs et les indicateurs, en temps réel. Contrairement à un ordinateur à usage général, un API est conçu pour fonctionner de manière fiable dans des environnements industriels difficiles caractérisés par du bruit électrique, des vibrations, des températures extrêmes et de la poussière, tout en exécutant des programmes de contrôle avec une synchronisation déterministe, ce qui signifie que le contrôleur termine son cycle de scrutation dans un temps prévisible et reproductible quelles que soient les conditions du processus. Cette combinaison de durcissement industriel et de déterminisme en temps réel fait des automates le contrôleur d'automatisation standard dans les secteurs de la fabrication, des industries de transformation, des services publics, de l'automatisation des bâtiments et des infrastructures du monde entier.

Le PLC a été développé à la fin des années 1960 spécifiquement pour remplacer les grands ensembles de relais électromécaniques qui contrôlaient les chaînes d'assemblage automobile – des systèmes coûteux à installer, nécessitant un recâblage important pour être modifiés et exigeant une maintenance constante à mesure que les contacts des relais s'usaient et tombaient en panne. En remplaçant la logique de relais physique par un équivalent logiciel programmable, l'API a permis aux ingénieurs de production de modifier le comportement de la machine en modifiant un programme plutôt qu'en recâblant un panneau, réduisant ainsi considérablement le temps et le coût des changements de production. Soixante ans plus tard, le concept de base reste inchangé, mais moderne automates programmables sont passés du simple remplacement de relais à des plates-formes d'automatisation sophistiquées prenant en charge le contrôle de mouvement à grande vitesse, le contrôle de processus, les fonctions de sécurité, l'intégration de la vision industrielle et la communication en réseau industriel à travers des architectures multi-systèmes complexes.

Comment fonctionne un automate : le cycle de scrutation expliqué

Le principe de fonctionnement fondamental d'un automate programmable est le cycle de scrutation, une séquence répétitive d'opérations que l'automate exécute en continu tant qu'il est en mode exécution. Comprendre le cycle de scrutation est essentiel pour comprendre le comportement d'un automate, en particulier dans les applications à temps critique où le temps de réponse à un changement d'entrée détermine si le système de contrôle fonctionne correctement.

Un cycle de scrutation API standard se compose de quatre étapes séquentielles. Tout d'abord, l'analyse des entrées lit l'état actuel de toutes les entrées numériques et analogiques connectées (capteurs, commutateurs, encodeurs, transmetteurs) et copie ces valeurs dans un registre d'images d'entrée en mémoire. Deuxièmement, l'analyse du programme exécute le programme de contrôle stocké en mémoire, en utilisant les valeurs d'image d'entrée (et non les lectures d'entrée en direct) pour évaluer les conditions logiques et déterminer l'état requis des sorties. Troisièmement, l'analyse de sortie écrit les valeurs d'image de sortie déterminées par le programme sur le matériel de sortie physique, activant ou désactivant les appareils connectés. Quatrièmement, l'étape de maintenance gère les communications, les autodiagnostics et la mise à jour des minuteries et des compteurs internes avant la répétition du cycle.

Le temps requis pour terminer un cycle d'analyse (le temps d'analyse) est généralement de 1 à 10 millisecondes pour la plupart des applications standard, bien qu'il augmente avec la complexité du programme et le nombre de points d'E/S. L'architecture du cycle de scrutation signifie que les changements d'état d'entrée ne sont pas pris en compte avant le cycle de scrutation suivant, ce qui introduit une latence maximale d'un cycle de scrutation dans la réponse de contrôle. Pour la plupart des applications d'automatisation industrielle, cette latence est tout à fait acceptable. Pour les applications à grande vitesse (asservissement de mouvement, comptage haute fréquence ou fonctions de sécurité nécessitant une réponse inférieure à la milliseconde), des routines d'interruption spécialisées, des processeurs de mouvement dédiés ou des automates de sécurité séparés sont utilisés pour contourner la latence du cycle de scrutation standard.

Composants matériels API et leurs fonctions

Un système API se compose de plusieurs composants matériels distincts qui forment ensemble le contrôleur d'automatisation complet. Comprendre la fonction de chaque composant clarifie la façon dont un système PLC est spécifié, assemblé et entretenu.

Unité centrale de traitement (CPU)

Le module CPU est le cerveau de l'automate : il contient le processeur qui exécute le programme de contrôle, la mémoire qui stocke le programme et les données, ainsi que les interfaces de communication qui se connectent aux outils de programmation et autres systèmes d'automatisation. La capacité du processeur est caractérisée par la vitesse de traitement (temps de scrutation pour 1 000 instructions de logique à relais), la capacité de la mémoire du programme (généralement de kilo-octets à mégaoctets selon la classe de l'automate), la mémoire de données pour stocker les valeurs variables et les données de processus, et la gamme de protocoles de communication pris en charge. Les modules CPU haut de gamme contiennent également des horloges en temps réel, une capacité d'enregistrement de données et des serveurs OPC UA ou MQTT intégrés pour une connexion directe aux systèmes IoT industriels et cloud sans matériel supplémentaire.

Modules d'entrée/sortie (E/S)

Les modules d'E/S constituent l'interface physique entre l'API et les appareils de terrain (capteurs, commutateurs, vannes, moteurs et instruments) que le système de contrôle surveille et commande. Les modules d'entrée numérique reçoivent des signaux marche/arrêt provenant de dispositifs tels que des capteurs de proximité, des boutons-poussoirs et des interrupteurs de fin de course, convertissant la tension au niveau du champ (généralement 24 V CC ou 120/240 V CA) en un signal de niveau logique que le processeur peut lire. Les modules de sortie numérique commutent l'alimentation des appareils de terrain tels que les électrovannes, les démarreurs de moteur et les voyants lumineux. Les modules d'entrée analogiques convertissent les signaux variables en continu (boucles de courant 4-20 mA, signaux de tension 0-10 V, tensions de thermocouple, valeurs de résistance RTD) en valeurs numériques que le processeur peut traiter. Les modules de sortie analogique convertissent les valeurs numériques du processeur en signaux analogiques proportionnels pour contrôler les variateurs de vitesse, les vannes proportionnelles et autres dispositifs à variation continue. Les modules d'E/S spécialisés comprennent des entrées de compteur à grande vitesse pour le retour du codeur, des modules de communication série et des E/S de sécurité pour les applications de sécurité fonctionnelle.

Alimentation

Le module d'alimentation PLC convertit l'alimentation secteur entrante (généralement 120 V CA ou 240 V CA) ou l'alimentation du bus CC en tensions CC régulées requises par le processeur et les modules d'E/S. La sélection de l'alimentation électrique implique d'adapter la capacité de courant de sortie à la consommation totale de courant de tous les modules du rack ou du système, avec une marge d'au moins 20 à 30 % pour la fiabilité et pour s'adapter à une expansion future. Les configurations d'alimentation redondantes, dans lesquelles deux modules d'alimentation fonctionnent en parallèle avec basculement automatique, sont la norme dans les systèmes à haute disponibilité où un arrêt imprévu suite à une panne d'alimentation serait d'un coût inacceptable.

Fond de panier et rack

Dans les systèmes API modulaires montés en rack, le fond de panier est la carte de circuit imprimé qui supporte mécaniquement et connecte électriquement le processeur, l'alimentation et les modules d'E/S. Le fond de panier transporte le bus de données interne, la distribution d'énergie et, dans certains systèmes, les signaux de synchronisation en temps réel nécessaires au fonctionnement coordonné de plusieurs modules. La taille du rack (spécifiée par le nombre d'emplacements de module) détermine le nombre de modules d'E/S pouvant être installés dans un seul rack. Pour les systèmes nécessitant plus d'E/S qu'un seul rack ne peut en accueillir, plusieurs racks sont connectés via des câbles d'extension ou des E/S distantes sur un réseau industriel.

Types d'automates : systèmes compacts, modulaires et basés sur rack

Les automates sont fabriqués sous plusieurs facteurs de forme adaptés à différentes exigences d'échelle et de complexité. La sélection du facteur de forme PLC approprié pour une application implique d'adapter la capacité d'E/S, l'évolutivité et la capacité de traitement du contrôleur aux exigences actuelles et futures projetées de la machine ou du processus contrôlé.

La catégorie des automates compacts est devenue le domaine de croissance le plus important sur le marché des automates, tirée par la classe de produits Siemens S7-1200 et Allen-Bradley Micro820 qui offrent des capacités auparavant associées uniquement aux systèmes modulaires de taille réelle, notamment le contrôle de mouvement, le contrôle de processus PID et la communication industrielle basée sur Ethernet, dans un petit format adapté au montage sur panneau sans rack dédié. Pour les nouveaux projets d'automatisation de machines avec un nombre d'E/S inférieur à 200 points, un automate modulaire compact constitue désormais le point de départ par défaut pour la plupart des ingénieurs en automatisation, plutôt que les systèmes en rack plus grands qui étaient nécessaires il y a dix ans.

Langages de programmation API selon CEI 61131-3

La programmation des automates est normalisée selon la norme CEI 61131-3, qui définit cinq langages de programmation que les environnements de développement d'automates conformes doivent prendre en charge. Différents langages conviennent à différents types de logique de contrôle et à différents parcours d'ingénierie, et la plupart des outils de programmation d'automates modernes permettent d'utiliser plusieurs langages au sein d'un même projet, permettant ainsi aux ingénieurs de choisir le langage le plus approprié pour chaque section du programme.

Diagramme à contacts (LD)

Le diagramme à contacts est le langage de programmation d'automate le plus largement utilisé, en particulier en Amérique du Nord et dans les environnements de fabrication discrets. La représentation graphique imite les schémas logiques de relais que les automates ont été initialement conçus pour remplacer : des échelons logiques horizontaux connectent les rails d'alimentation gauche et droit, avec des symboles de contact normalement ouverts et normalement fermés représentant les conditions d'entrée et des symboles de bobine représentant les commandes de sortie. La logique à relais est intuitive pour les ingénieurs électriciens familiarisés avec les schémas de circuits de relais et est facile à lire et à dépanner en ligne (avec l'automate en mode d'exécution, les éléments actifs sont mis en évidence dans le logiciel de programmation, permettant de tracer visuellement les conditions de défaut). La limitation du diagramme à contacts est qu'il devient difficile à manier pour les opérations mathématiques complexes, la manipulation de données et la programmation séquentielle qui sont plus naturellement exprimées dans les langages textuels.

Diagramme de blocs fonctionnels (FBD)

Le diagramme de blocs fonctionnels représente la logique de contrôle sous forme de blocs graphiques interconnectés — chaque bloc encapsule une fonction spécifique (porte ET, contrôleur PID, compteur, minuterie, bloc fonctionnel moteur) avec des connexions d'entrée et de sortie représentées sous forme de fils entre les blocs. FBD est le langage dominant dans les applications de contrôle de processus : il correspond naturellement à la représentation des schémas de tuyauterie et d'instrumentation (P&ID) familière aux ingénieurs de processus, et l'encapsulation de fonctions complexes (boucles PID, contrôle de vannes, protection du moteur) dans des blocs fonctionnels réutilisables standardisés réduit considérablement les efforts de programmation dans les applications d'usine de traitement. La plupart des plates-formes API orientées processus et sécurité offrent des bibliothèques complètes de blocs fonctionnels conformes à la norme CEI 61511 pour les fonctions courantes de contrôle de processus et de sécurité.

Texte structuré (ST)

Le texte structuré est un langage textuel de haut niveau syntaxiquement similaire à Pascal ou C, prenant en charge les instructions conditionnelles, les boucles, les expressions mathématiques, la gestion des chaînes et les structures de données complexes qui sont lourdes ou impossibles dans les langages graphiques. ST est de plus en plus utilisé par les ingénieurs en automatisation ayant une formation en développement de logiciels et constitue le langage préféré pour le traitement de données complexes, la gestion de recettes, la gestion des communications et toute application nécessitant une logique algorithmique sophistiquée que les langages graphiques ne peuvent pas exprimer efficacement. La définition du texte structuré de la norme CEI 61131-3 l'a rendu véritablement portable entre différentes plates-formes d'automate : le code écrit en ST pour l'automate d'une marque peut être adapté à la plate-forme d'une autre marque avec des modifications relativement mineures, contrairement au code de schéma à contacts qui a tendance à utiliser des instructions et des conventions spécifiques au fabricant.

Diagramme de fonctions séquentielles (SFC)

Le diagramme de fonctions séquentielles représente les programmes de contrôle sous la forme d'un organigramme d'étapes et de transitions : chaque étape contient des actions (programmées en LD, FBD ou ST) et chaque transition définit la condition qui doit être remplie pour que le programme passe à l'étape suivante. SFC est le langage naturel pour les applications de séquençage : cycles de machine à laver, séquences de processus par lots, opérations d'assemblage en plusieurs étapes et toute application dans laquelle une machine doit effectuer une série définie d'opérations dans l'ordre. La programmation d'un processus séquentiel complexe dans le schéma à contacts produit des programmes volumineux et difficiles à suivre ; la même séquence exprimée dans SFC est immédiatement lisible en tant que flux de processus et est nettement plus facile à déboguer et à modifier.

Protocoles de communication industriels pris en charge par les automates modernes

Les automates programmables modernes sont autant des périphériques réseau que des contrôleurs d'automatisation. Les capacités de communication d'un automate déterminent la manière dont il s'intègre à d'autres équipements d'automatisation, systèmes de supervision, bases de données d'entreprise et plates-formes cloud — une considération de plus en plus importante à mesure que l'automatisation industrielle évolue vers des architectures connectées de l'Industrie 4.0.

• EtherNet/IP : Le protocole Ethernet industriel dominant dans l'écosystème Allen-Bradley/Rockwell Automation, et largement pris en charge par les E/S, les lecteurs et les instruments tiers. EtherNet/IP utilise l'infrastructure TCP/IP et UDP standard, permettant aux automates de partager le même réseau Ethernet physique que les systèmes de bureau tout en maintenant des performances industrielles déterministes grâce à la gestion du trafic. Il s’agit du protocole de choix pour les grands systèmes d’automatisation de la fabrication nord-américains.
• PROFINET : Le protocole Ethernet industriel développé et promu par Siemens et l'organisation PROFIBUS et PROFINET International (PI). PROFINET est l'épine dorsale de communication standard pour les systèmes API Siemens S7 et est largement pris en charge dans l'automatisation industrielle européenne. PROFINET IRT (Isochronous Real Time) fournit des temps de cycle inférieurs à la milliseconde pour les applications de contrôle de mouvement nécessitant une synchronisation étroite entre plusieurs axes.
• Modbus TCP/RTU : Le protocole de communication industrielle le plus ancien et le plus universellement pris en charge, disponible dans pratiquement tous les automates, instruments et appareils de terrain du marché. Modbus est simple, bien documenté et libre de droits, ce qui en fait le choix par défaut pour intégrer des instruments tiers et des équipements existants dans les systèmes API modernes. Ses limites (absence de fonctionnalités de sécurité natives, capacité de diagnostic limitée et architecture maître-esclave qui restreint les configurations multi-maîtres) ont conduit à son remplacement par EtherNet/IP et PROFINET dans les nouveaux systèmes d'automatisation, mais sa disponibilité universelle garantit qu'il restera utilisé pendant des décennies.
• OPC UA (Architecture Unifiée) : La norme moderne pour l'échange de données sécurisé et indépendant de la plate-forme entre les systèmes d'automatisation industrielle et les systèmes de niveau supérieur, notamment les plates-formes SCADA, MES, ERP et cloud. OPC UA fournit un modèle d'information standardisé, une sécurité intégrée (authentification, autorisation et cryptage) et la capacité de représenter des structures et des relations de données complexes plutôt que de simples valeurs de registre brutes. L'adoption d'OPC UA comme interface de communication pour les architectures Industrie 4.0 et IIoT a fait de la capacité native du serveur OPC UA dans les processeurs d'automates une fonctionnalité standard des plates-formes d'automatisation haut de gamme.
• Lien IO : Une norme de communication série point à point pour connecter des capteurs et des actionneurs intelligents au système d'E/S de l'API, fournissant une communication numérique bidirectionnelle qui permet l'échange de données de paramétrage, de diagnostic et d'identification entre l'appareil de terrain et l'API en plus de la valeur de processus principale. IO-Link remplace rapidement les connexions E/S classiques 4-20 mA et numériques pour les nouvelles installations de capteurs et d'actionneurs, car la capacité de diagnostic et de paramétrage supplémentaire qu'elle offre réduit le temps de mise en service et améliore considérablement la capacité de maintenance prédictive.

Principaux fabricants d’automates et leurs écosystèmes

Le marché des automates est dominé par un petit nombre de grandes sociétés d'automatisation, chacune offrant un écosystème complet de matériel automate, de logiciels de programmation, de modules d'E/S, de variateurs, de panneaux IHM et d'infrastructures de communication conçus pour fonctionner ensemble de manière transparente. Choisir un automate d'un fabricant particulier signifie généralement s'engager dans l'écosystème de ce fabricant pour le système d'automatisation complet, ce qui a des implications significatives en termes d'intégration, de pièces de rechange, de formation et de support à long terme.

PLC vs DCS vs SCADA : comprendre les différences

Les automates sont fréquemment évoqués aux côtés des systèmes de contrôle distribués (DCS) et des systèmes de contrôle et d'acquisition de données (SCADA), et les frontières entre ces catégories se sont considérablement estompées à mesure que la technologie a évolué. Comprendre les distinctions – et où elles ont convergé – est important pour spécifier l'architecture d'automatisation appropriée pour une application donnée.

Un système de contrôle distribué est une architecture d'automatisation dans laquelle les fonctions de contrôle sont réparties sur plusieurs contrôleurs déployés à proximité du processus contrôlé, tous connectés à un système de supervision centralisé via un réseau d'usine de haute fiabilité. Les systèmes DCS ont été développés pour les grandes applications de processus continus (pétrole et gaz, pétrochimie, production d'énergie, fabrication pharmaceutique) où des milliers de boucles de contrôle analogiques, une logique de verrouillage complexe et une gestion complète des alarmes sont nécessaires dans une grande usine physique. Les systèmes DCS privilégient la haute disponibilité (contrôleurs, E/S, alimentation et réseaux redondants en standard), la capacité complète d'historique des données de processus et les affichages intégrés du poste de commande. La distinction entre un système API modulaire haut de gamme moderne et un DCS d'entrée de gamme est désormais marginale en termes de fonctionnalités : les principales différences résident dans l'environnement logiciel, l'orientation applicative du fournisseur et le modèle commercial.

SCADA (Supervisory Control and Data Acquisition) fait spécifiquement référence à la couche de supervision : le système logiciel qui collecte les données des automates et autres contrôleurs de terrain, présente les informations de processus aux opérateurs via des écrans IHM graphiques, enregistre les données historiques et peut renvoyer des commandes de point de consigne aux contrôleurs. SCADA ne remplace pas un automate : c'est la couche située au-dessus de l'automate qui assure la surveillance humaine et la gestion des données. Une architecture d'automatisation industrielle typique combine des automates au niveau du contrôle des machines ou des processus, un réseau industriel transportant des données entre les automates et les systèmes de supervision, et un système SCADA ou MES fournissant une interface opérateur, des données historiques et une intégration avec les systèmes d'entreprise.

Facteurs clés à évaluer lors de la sélection d'un automate pour une nouvelle application

La sélection du bon automate programmable pour une nouvelle application de contrôle de machine ou de processus implique l'évaluation d'une série de facteurs techniques et commerciaux qui, ensemble, déterminent si le système répondra à ses exigences fonctionnelles, sera livré dans les délais et sera supportable tout au long de sa durée de vie opérationnelle. Le cadre suivant couvre les critères d’évaluation les plus importants.

• Nombre et type d'E/S : Identifiez toutes les entrées et sorties requises (entrées numériques, sorties numériques, entrées analogiques, sorties analogiques, entrées de compteur à grande vitesse, sorties de train d'impulsions pour moteurs pas à pas) et ajoutez une marge de capacité disponible de 20 à 25 % pour les modifications et ajouts futurs. Assurez-vous que la gamme de modules d'E/S pour la famille d'API sélectionnée comprend les types et plages de tension spécifiques nécessaires à vos appareils de terrain : toutes les plates-formes d'API n'offrent pas toutes les variantes d'E/S, et l'adaptation d'appareils de terrain non standard à une plage d'E/S limitée ajoute du coût et de la complexité.
• Exigences de performances de traitement : Déterminez si l'application nécessite une logique standard de remplacement de relais (n'importe quel API moderne est adéquat), un contrôle de processus PID (la plupart des API compacts et modulaires le prennent en charge en standard), un contrôle de mouvement (nécessite un API avec une capacité de contrôle de mouvement intégrée ou un contrôleur de mouvement séparé) ou des fonctions de sécurité (nécessite un API de sécurité ou un module de fonction de sécurité classé SIL). Faites correspondre les spécifications du temps de scrutation du processeur à la réponse de contrôle la plus rapide requise dans l'application : pour les applications de contrôle de mouvement ou de comptage à grande vitesse, des temps de scrutation standard de 5 à 10 ms peuvent s'avérer insuffisants.
• Exigences de communication : Identifiez les protocoles requis pour interagir avec tous les autres équipements du système : lecteurs, panneaux IHM, instruments, systèmes de vision, robots et systèmes de supervision. Confirmez que l'automate peut agir en tant que maître, esclave ou homologue requis dans chaque relation de communication. Si une connectivité OPC UA à un système SCADA ou MES est requise, vérifiez si elle est native dans la CPU ou nécessite un module de communication supplémentaire.
• Exigences environnementales et d'installation : Vérifiez la plage de température de fonctionnement, l'indice de protection IP (indice de protection) du processeur et des modules d'E/S, les indices de vibration et de choc, ainsi que toutes les certifications spécifiques requises pour l'environnement d'installation : ATEX ou IECEx pour les atmosphères explosives, les certifications marines pour les installations offshore ou sur navires, ou les certifications industrielles spécifiques pour les applications alimentaires et pharmaceutiques.
• Logiciel de programmation et disponibilité des formations : Évaluer la facilité d'utilisation de l'environnement de programmation, la qualité de la documentation et la disponibilité de formations pour les équipes de programmation et de maintenance qui travailleront avec le système. Une plate-forme API puissante que l'équipe d'ingénierie ne peut pas programmer efficacement donnera de moins bons résultats qu'un système aux spécifications plus modestes que l'équipe connaît bien. Si le projet implique une plate-forme inconnue, tenez compte d’un temps de formation et d’apprentissage réaliste dans le calendrier du projet.
• Support à long terme et cycle de vie du produit : Vérifiez le cycle de vie du produit indiqué par le fabricant pour la famille d'automates spécifique : combien d'années de disponibilité et d'assistance en matière de pièces de rechange sont engagées. Certaines familles d'automates ont été abandonnées avec des chemins de transition limités, laissant les systèmes installés orphelins d'un matériel obsolète. Préférez les plates-formes de fabricants ayant démontré leur engagement en faveur d’un support à long terme et des voies de migration claires lorsque d’éventuelles modifications de produits sont nécessaires. Vérifiez si les modules CPU et E/S sélectionnés sont des éléments de production actuels ou des produits existants en fin de vie.

Maintenance, dépannage et gestion du cycle de vie des automates

Un système API en fonctionnement continu nécessite une maintenance proactive et une gestion du cycle de vie pour maintenir la fiabilité et éviter les temps d'arrêt imprévus. Les pratiques suivantes sont standard dans les opérations d’ingénierie d’automatisation bien gérées.

• Sauvegarde du programme et contrôle de version : Conservez des sauvegardes actuelles et vérifiées de tous les programmes API et fichiers de configuration dans un référentiel sécurisé et contrôlé en version. Un automate qui perd son programme en raison d'une panne de batterie, d'une panne de processeur ou d'un écrasement involontaire peut arrêter complètement une ligne de production jusqu'à ce que le programme soit restauré. Testez la procédure de restauration à partir de la sauvegarde au moins une fois par an pour confirmer que la sauvegarde est terminée et que le processus de restauration fonctionne correctement.
• Entretien de la batterie : La plupart des processeurs d'automate utilisent une batterie au lithium pour conserver la mémoire du programme et les valeurs de l'horloge en temps réel pendant les pannes de courant. La durée de vie de la batterie est généralement de trois à cinq ans et la plupart des processeurs émettent un signal d'avertissement de batterie faible avant une panne. Remplacez les batteries de manière programmée – chaque année dans les applications critiques – plutôt que d'attendre l'alarme de batterie faible, ce qui laisse une marge insuffisante pour les pannes prolongées imprévues.
• Mises à jour du micrologiciel : Les fabricants d'automates publient régulièrement des mises à jour de micrologiciels qui corrigent les vulnérabilités de sécurité, corrigent des bogues et ajoutent des fonctionnalités. Établissez un processus d'évaluation et d'application des mises à jour du micrologiciel : toutes les mises à jour ne doivent pas être appliquées immédiatement dans les systèmes de production, mais ignorer toutes les mises à jour crée des risques de sécurité et peut laisser des bogues connus non résolus. Testez les mises à jour du micrologiciel sur un système hors production avant de les appliquer aux automates de production.
• Gestion des pièces détachées : Maintenir un inventaire de pièces de rechange adapté à la criticité du processus contrôlé. Conservez au minimum une pièce de rechange de chaque module CPU et des types de modules d'E/S les plus couramment utilisés. Pour les applications critiques où le coût des temps d’arrêt est très élevé, conservez les racks ou systèmes de rechange complets dans un état prêt à être déployé. La bonne approche en matière de pièces de rechange consiste à déterminer le temps d'arrêt maximum acceptable pour le système et à travailler en amont pour déterminer quel stock de pièces de rechange est nécessaire pour atteindre cet objectif.
• Renforcement de la cybersécurité : Les systèmes CPL connectés aux réseaux des usines et au-delà sont de plus en plus la cible de cyberattaques : l'incident Stuxnet a démontré que même les systèmes de contrôle industriels isolés peuvent être compromis. L'hygiène de base en matière de cybersécurité pour les systèmes CPL comprend la segmentation du réseau (isoler le réseau de contrôle du réseau informatique de l'entreprise derrière une zone démilitarisée), la désactivation des ports et services de communication inutilisés sur le processeur de l'CPL, la mise en œuvre de contrôles d'accès des utilisateurs et de politiques de mot de passe sur les logiciels de programmation et la surveillance du trafic réseau pour détecter les anomalies à l'aide de systèmes de détection d'intrusion industriels.