Cycle d’un automate programmable : étapes, temps de cycle et mesure

Les automates programmables industriels, tout comme les ordinateurs, sont des machines capables de réaliser des tâches complexes avec une vitesse de traitement très élevée. Pour piloter une machine industrielle, ils doivent en permanence acquérir des informations, effectuer des calculs et commander des actionneurs. Ce fonctionnement a une conséquence mesurable : le temps de réponse maximal d’un automate programmable est égal à deux fois son temps de cycle. Un automate dont le cycle dure 5 ms peut donc réagir jusqu’à 10 ms après le changement d’état d’un capteur. (Siemens)

Ces opérations ne peuvent pas être réalisées dans un ordre arbitraire. Pour garantir la fiabilité des procédés et éviter les comportements imprévisibles, les automates s’appuient sur un fonctionnement répétitif appelé cycle d’automate.

Un cycle automate désigne le temps nécessaire à l’acquisition des entrées, l’exécution du programme et à la mise à jour des sorties. Ce mécanisme qui lui permet de traiter les informations de manière cohérente et de réagir aux évolutions du procédé est notamment formulé dans la série de normes internationales IEC 61131. On retrouve notamment la partie 3 (IEC 61131-3) qui définit le modèle d’exécution des programmes, basé sur des tâches qui peuvent être cycliques, périodiques ou déclenchées par des événements.

Le fonctionnement général d’un automate industriel est détaillé dans un article dédié.

Pourquoi les automates programmables fonctionnent-ils en cycle ?

On pourrait imaginer qu’un API réagisse instantanément à chaque changement d’une entrée, comme un interrupteur qui allume une lampe dès qu’on l’actionne. Pourtant, ce n’est pas ainsi qu’il fonctionne.

Un automate programmable industriel doit prendre des décisions à partir d’un grand nombre d’informations. L’état des capteurs, les variables internes, les temporisations, les compteurs ou encore les données échangées avec d’autres équipements. Pour que ces décisions soient fiables, il est indispensable que toutes les informations utilisées correspondent au même instant.

Le fonctionnement cyclique répond précisément à ce besoin. En répétant toujours la même séquence d’opérations dans le même ordre, l’automate dispose d’une vision cohérente de l’installation à chaque exécution de son programme. Les calculs sont réalisés à partir d’un ensemble de données stable, ce qui garantit un comportement prévisible et reproductible.

Cela permet d’obtenir un temps d’exécution déterministe, de faciliter le diagnostic en cas de dysfonctionnement et de garantir que le programme produira le même résultat si les mêmes conditions sont réunies.

Sans ce fonctionnement cyclique, les entrées pourraient changer pendant l’exécution du programme. Une partie de la logique utiliserait alors d’anciennes informations tandis qu’une autre utiliserait les nouvelles, ce qui pourrait entraîner des décisions incohérentes ou des comportements difficiles à reproduire.

Le cycle d’automate constitue donc le socle du fonctionnement des API. Il assure que chaque décision est prise à partir d’un état cohérent du procédé avant qu’un nouveau cycle ne commence avec des informations mises à jour.

Les étapes du cycle de scrutation

L’élément important à retenir est que le programme s’exécute à partir d’une image des entrées mémorisée au début du cycle. Les éventuels changements d’état des capteurs ne seront donc pris en compte qu’au cycle suivant, une fois les sorties mises à jour et une nouvelle lecture des entrées effectuée.

Le même principe s’applique aux sorties. Lorsque le programme décide d’activer ou de désactiver une sortie, cette modification est d’abord enregistrée dans une image des sorties stockée dans la mémoire. Les sorties physiques de l’automate ne sont réellement mises à jour qu’à la fin du cycle, garantissant ainsi que toutes les décisions du programme sont appliquées simultanément.

Ce processus correspond au fonctionnement général des API. Selon les constructeurs (Siemens, Schneider Electric, Rockwell Automation, Beckhoff, etc.), l’ordre exact des différentes étapes peut varier et certaines opérations supplémentaires, comme les diagnostics ou les communications, peuvent être intégrées au cycle. Le principe reste cependant identique. Acquérir les entrées, exécuter le programme et mettre à jour les sorties de manière déterministe.

Prenons un exemple concret pour illustrer ce fonctionnement. Un capteur inductif TOR détecte le passage d’une pièce métallique et l’API doit commander une électrovanne afin de l’éjecter.

Au début du cycle, si le capteur est actif, l’automate mémorise l’état « 1 » de cette entrée et utilise cette information pour exécuter son programme. L’ordre d’éjection sera alors envoyé à la sortie correspondante à la fin du traitement.

En revanche, si le capteur change d’état pendant l’exécution du programme, cette modification ne sera pas visible immédiatement par l’automate. Elle sera prise en compte uniquement lors de la prochaine acquisition des entrées. C’est ce fonctionnement qui garantit que le programme travaille toujours avec un ensemble d’informations stable pendant son exécution.

Dans la plupart des applications industrielles, ces cycles sont extrêmement rapides. Un automate programmable peut exécuter son programme en quelques millisecondes seulement. Cependant, lorsqu’un signal est plus court que la durée nécessaire pour réaliser un cycle complet, celui-ci peut ne pas être détecté par l’automate.

Temps de cycle : définition et ordres de grandeur

Dans la majorité des installations industrielles, le temps de cycle est de l’ordre de quelques millisecondes. Siemens situe la pratique courante entre 10 et 20 ms selon la taille du programme, et considère qu’un cycle d’une milliseconde relève déjà du fonctionnement rapide, en particulier lorsque la périphérie d’entrées et de sorties doit traiter les signaux au même rythme. Malheureusement, il ne s’agit pas d’une valeur fixe. Plus le programme est complexe, plus le temps de cycle augmente.

Le temps de cycle dépend de nombreux paramètres, parmi lesquels :

• les performances du processeur de l’automate
• la taille et la complexité du programme utilisateur
• le langage de programmation (Ladder, SFC et autres)
• le nombre d’entrées et de sorties à traiter
• les échanges de données avec les variateurs, les interfaces homme-machine (IHM), les API ou les systèmes de supervision
• l’utilisation de blocs fonctionnels, d’instructions de calcul ou d’algorithmes plus ou moins gourmands en ressources

Cette durée influence directement la réactivité de la machine.

Pour bien comprendre l’impact de ces temps, prenons l’exemple d’un automate dont le temps de cycle est de 5 ms. Si un capteur change d’état juste après l’acquisition des entrées, cette information ne sera traitée qu’au cycle suivant. Le délai avant son exécution pourra donc atteindre près de 5 ms, auxquels s’ajoute le temps nécessaire à la mise à jour des sorties. C’est la règle énoncée en introduction : le temps de réponse maximal d’un automate programmable est égal à deux fois son temps de cycle. Un automate dont le cycle dure 5 ms peut donc réagir jusqu’à 10 ms après le changement d’état d’un capteur. Il en découle une règle de dimensionnement : la durée minimale détectable sur une entrée standard est égale au temps de cycle. Un signal plus court peut ne jamais être vu par l’automate.

Dans la plupart des applications, ce délai reste imperceptible. En revanche, sur des machines à haute cadence, des systèmes de vision ou des applications de positionnement précis, le temps de cycle devient un paramètre déterminant.

Pour répondre à ces contraintes, les constructeurs proposent différentes solutions permettant de traiter certains événements sans attendre le cycle principal. Selon les automates, il est par exemple possible d’utiliser des tâches périodiques, des interruptions matérielles ou des entrées rapides afin d’améliorer la réactivité sur des fonctions critiques.

Comment mesurer le temps de cycle d’un automate ?

Connaître le temps de cycle permet de vérifier que l’automate dispose de suffisamment de temps pour exécuter son programme dans les conditions normales de fonctionnement. Un temps de cycle trop élevé peut réduire la réactivité de la machine et, dans certaines applications, provoquer des retards dans la prise en compte des entrées ou la mise à jour des sorties.

Comme vous vous en doutez, il n’est pas possible de mesurer ce temps manuellement avec un chronomètre. La plupart des constructeurs proposent directement cette information dans leur logiciel de programmation ou dans les outils de diagnostic de l’API. Selon la marque et le modèle, on peut notamment retrouver le temps de cycle actuel, le temps de cycle minimum et le temps de cycle maximum.

Par exemple, avec un automate Rockwell Automation programmé sous Studio 5000 Logix Designer, il est possible de consulter les performances d’une tâche directement depuis ses propriétés. Dans l’onglet Monitor, le logiciel affiche notamment les temps de scrutation ainsi que l’intervalle entre les déclenchements. Pour une mesure plus précise, les informations du système peuvent également être récupérées dans le programme avec l’instruction GSV (Get System Value), notamment l’attribut LastScanTime, exprimé en microsecondes. Évidemment, il en va de même chez les autres constructeurs tels que Siemens, Omron, Schneider Electric, WAGO ou encore Mitsubishi.

Sur une installation en fonctionnement, il est intéressant de regarder ces valeurs dans différentes conditions. L’activation d’une fonction, le lancement d’un mouvement ou une communication supplémentaire peuvent par exemple augmenter temporairement le temps de cycle. Un écart important entre le temps minimal et le temps maximal peut alors indiquer que la charge de l’automate varie fortement selon les opérations réalisées.

Il faut également surveiller le watchdog. Celui-ci déclenche une faute lorsque le temps d’exécution d’une tâche dépasse le délai maximal configuré. Ce seuil n’est pas universel. Il dépend du constructeur, du type de tâche et de la configuration de l’automate.

Les cas particuliers : automates de sécurité et variantes constructeurs

Le cycle présenté dans cet article correspond à une vue simplifiée du fonctionnement général des API. Il permet de comprendre le principe de fonctionnement cyclique, mais il ne faut pas le considérer comme une représentation exacte de tous les API. Selon les constructeurs et les gammes d’automates, certaines opérations liées aux communications, aux diagnostics ou à la gestion du système peuvent être organisées différemment.

Les automates programmables de sécurité (Safety PLC) présentent également des particularités. Leur fonctionnement intègre des contrôles supplémentaires destinés à détecter les défauts et à garantir l’intégrité des fonctions de sécurité. Selon l’architecture retenue, ces contrôles peuvent notamment utiliser des traitements redondants ou des comparaisons de résultats. Ils peuvent donc avoir une influence sur le temps d’exécution, mais il n’est pas possible d’affirmer qu’un Safety PLC est systématiquement plus lent qu’un API standard. Cela dépend du constructeur, du matériel et du programme utilisé.

Glossaire

Temps de cycle (Scan Time)

Durée totale nécessaire à l’automate pour réaliser un cycle complet (lecture des entrées → exécution du programme → écriture des sorties + tâches système).

Image des entrées

Zone mémoire de l’automate contenant l’état des entrées, utilisée par le programme pendant l’exécution d’un cycle.

Watchdog

Mécanisme de surveillance qui vérifie que l’automate exécute son programme dans le temps prévu et déclenche une action de sécurité en cas de dépassement.

Exécution déterministe

Propriété qui garantit que le programme produit toujours le même résultat dans le même temps lorsqu’il est exécuté dans les mêmes conditions.

Tâche périodique

Mode d’exécution défini par la norme IEC 61131-3 dans lequel un programme s’exécute à intervalle de temps fixe (ex. toutes les 10 ms), indépendamment de la durée du cycle principal.

Interruption matérielle

Mécanisme permettant d’interrompre temporairement le cycle principal pour traiter immédiatement un événement prioritaire (changement d’état d’une entrée critique, alarme, etc.).

Entrée rapide (High-Speed Input)

Entrée capable de détecter des signaux très courts (microsecondes) indépendamment du temps de cycle principal de l’automate.

Safety PLC (Automate de sécurité)

Automate spécialement conçu et certifié pour réaliser des fonctions de sécurité (arrêt d’urgence, protection de zone, etc.) conformément aux exigences de la norme IEC 61508 et des normes sectorielles associées.

FAQ