Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus. Cet article ne cite pas suffisamment ses sources (octobre 2019). Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ». En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

Cet article est une ébauche concernant la science et l’électronique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

Deux automates programmables industriels & leurs périphériques, montés en volant, pour test et analyse.
Automate industriel WAGO pour un système de monitoring en industrie pharmaceutique.

Un automate programmable industriel, ou API (en anglais programmable logic controller, PLC), est un dispositif électronique numérique programmable destiné à la commande de processus industriels par un traitement séquentiel. Il envoie des ordres vers les préactionneurs (partie opérative ou PO côté actionneur) à partir de données d’entrées (capteurs) (partie commande ou PC côté capteur), de consignes et d’un programme informatique.

Lorsqu'un automate programmable remplit une fonction de sécurité, il est alors appelé automate programmable de sécurité ou APS.

Présentation

[modifier | modifier le code]
Automate de Allen-Bradley installé dans une armoire.
Automate dans une armoire électrique.

On nomme automate programmable industriel (API) un type particulier d'ordinateur, robuste et réactif, ayant des entrées et des sorties physiques, utilisé pour automatiser des processus comme la commande des machines sur une ligne de montage dans une usine, ou le pilotage de systèmes de manutention automatique. Là où les systèmes automatisés plus anciens employaient des centaines ou des milliers de relais et de cames, un simple automate suffit. On nomme automaticiens les programmeurs de ces API.

Constitution

[modifier | modifier le code]

L'API est structuré autour d'une unité de calcul ou processeur (en anglais Central Processing Unit, CPU), d'une alimentation par des sources de tension alternative (AC) ou continue (DC), et de modules dépendant des besoins de l'application, tels que :

D'autres automates, plus anciens, étaient constitués d'une simple mémoire dont l'adresse d'entrée était constituée d'une concaténation de données d'entrée (senseurs, horloge) et de l'état précédent. Beaucoup moins onéreux, ils se prêtaient en revanche mal à une augmentation rapide du nombre d'états. Ils sont restés très utilisés pour des automatisations simples du style système anti-blocage des roues (ABS) ou feux de signalisation aux carrefours.

Par rapport aux ordinateurs, les API se caractérisent par :

L'absence d'Interface Homme-machine (IHM) permanente pour visualiser l'action et le fonctionnement du programme sur la partie opérative font que les automates sont souvent reliés à un pupitre opérateur, une interface graphique (écran d'affichage ou écran tactile) ou un PC. Dans ce dernier cas, on parle de supervision. Le PC peut d'ailleurs être utilisé seul en regroupant les fonctions de l'API et de la supervision, grâce à l'utilisation d'un softPLC.

En automatisme industriel, on parle aussi beaucoup d'automates de télégestion. Dans ce cas, on vient, via Internet, modifier ou visualiser à distance les données ou le programme des automates de gestion des installations commandées: chaudières collectives, stations d'épuration, etc. Cela se fait par le biais de modem-routeurs souvent associés à un logiciel assurant une liaison sécurisée (VPN).

En général, si API et PC coexistent dans un atelier, les API fonctionnent au plus près des processus physiques et prennent en charge les questions de sécurité, les PC s'occupant plutôt de supervision et des rapports extérieurs. Les PC peuvent ainsi fixer au mieux les consignes aux API, qui donnent les ordres détaillés, traitent les urgences, et rendent compte de l'état des processus.

Programmation

[modifier | modifier le code]

Les programmes des API sont traités selon un cycle précis, le plus souvent[1] :

  1. Diagnostic (auto-test) ;
  2. Acquisition de toutes les entrées (recopie dans une mémoire image) ;
  3. Traitements du programme ;
  4. Mise à jour des sorties.

Le temps d'un cycle d'API varie selon la taille du programme, la complexité des calculs, le nombre d'entrées/sorties, la puissance de l'API, et les besoins du procédé piloté. Il varie de une à quelques dizaines de millisecondes et est protégé par un chien de garde, au cas par exemple où l'algorithme exécuterait indéfiniment une même boucle de programme.

Lecture des capteurs et commande des actionneurs sont réalisés par scrutation, la gestion d'interruptions pouvant être victime d'un effet d'avalanche en cas d'incident.

Différents langages de programmation

[modifier | modifier le code]

Il existe différents langages de programmation définis par la CEI 61131-3 :

Dans la programmation d’un automate, il est possible également de choisir de programmer en SFC, dérivé du grafcet. À chaque action élémentaire est associé un programme écrit en IL, ST, LD ou FBD. Le grafcet, très populaire en France, est un outil graphique de définition de l'automatisme séquentiel, en un nombre fini d'étapes, séparées par des conditions de transition. Il utilise une représentation graphique claire, permettant par exemple au réalisateur de montrer au donneur d'ordre comment il a compris le cahier des charges. Langage universel, indépendant (dans un premier temps) de la réalisation pratique, il peut se "câbler" par séquenceurs, être programmé sur automate voire sur ordinateur. De plus, il permet :

Dans le cas des automates programmables logiciels (softplc), il existe également différents langages de programmation non définis par la CEI 61131-3 qui étendent considérablement les possibilités de configuration, par exemple:

Toutefois, la popularité de ces langages ne doit pas masquer leurs faiblesses en matière de sécurité des processus.

Usage

[modifier | modifier le code]

Exemples

[modifier | modifier le code]

Les automates sont largement utilisés dans l'industrie, tant manufacturière (fabrication d'objets finis ou de sous-ensembles) que de processus (élaboration de matières premières). On en trouve aussi beaucoup dans la gestion de bâtiments, la logistique et le conditionnement, tel celui des colis de la vente par correspondance. Ils conviennent parfaitement pour tout type d'activité exigeant du réflexe plutôt que des calculs élaborés. Pour des systèmes exigeant une grande sécurité (ferroviaire, machineries d'ascenseur, accès à des machines dangereuses), on utilise des automates de sécurité (APIS) dont l'unité centrale est doublée et les procédures de test renforcées. Pour la gestion des feux de circulation d'un carrefour, ce sont toutefois des automates particuliers et totalement différents, qui sont utilisés et destinés à cette tâche. Il s'agit de contrôleurs de carrefours, qui doivent respecter des normes de sécurité particulières au domaine.

Avantages et inconvénients

[modifier | modifier le code]

Les API présentent de nombreux intérêts :

En contrepartie, ils sont plus chers que des solutions informatiques classiques à base de microcontrôleurs par exemple mais restent à l'heure actuelle les seules plateformes d'exécution considérées comme fiables en milieu industriel (avec les ordinateurs industriels). Le prix est notamment dépendant du nombre d'entrées/sorties nécessaires, de la mémoire dont on veut disposer pour réaliser le programme, de la présence ou non de modules métier. De plus ils nécessitent la maîtrise de langages spécifiques conformes à la norme CEI 61131-3 qui reprennent dans leur forme la logique d'exécution interne de l'automate. Ces langages apparaissent toutefois à beaucoup d'utilisateurs plus accessibles et plus visuels que les langages informatiques classiques.

Automate de sécurité

[modifier | modifier le code]
Module de sécurité SP-COP, samos Pro, 16 entrées de sécurité , 4 sorties de sécurité (Wieland)

Au-delà des applications classiques, un automate peut avoir des caractéristiques dites « de sécurité ». Elles lui permettent, soit d'avoir une garantie de fonctionnement, même après la ruine d'un élément, soit de garantir un fonctionnement qui générera des actions toujours plus contraignantes en cas de ruine d'un élément, garantissant la sécurité des personnes et des biens.

Ces caractéristiques peuvent porter sur :

Exemples

[modifier | modifier le code]

Nano Automates Embarqués

[modifier | modifier le code]

Une variante à l'automate industriel classique consiste en un automate concentré dans un mini boitier (inférieur à 10 cm), donc simplifié au maximum

Automate logiciel

[modifier | modifier le code]

Une variante à l'automate programmable matériel consiste en un automate logiciel, donc sans matériel lié à proprement parler, mais réutilisant les mêmes concepts et langages du monde de l'automatisme. Certains langages supplémentaires, plus orientés informatiques et donc moins accessibles à un électricien, peuvent également figurer (comme évoqué ci-dessus).

On parle parfois de SoftPlc. Afin de garantir un traitement dans les temps, la plateforme matérielle utilisée pour exécuter le moteur d'automatisme doit fonctionner sur un Système d'exploitation temps réel.

Il peut également exister des simulateurs d'automates programmables, mais dans ce cas il s'agit juste de pouvoir tester une programmation pour des essais, sans lire de capteurs et piloter de vrais actionneurs. Ce type de logiciel peut s'exécuter sur un système d'exploitation classique non temps-réel.

Notes et références

[modifier | modifier le code]

Voir aussi

[modifier | modifier le code]

Articles connexes

[modifier | modifier le code]

Sur les autres projets Wikimedia :