Échanges automate–robot : machine à états, signaux et reprise après défaut

En bref : Une interface fiable entre automate et robot est une machine à états convenue : chaque demande est acquittée, chaque tâche se termine par « terminé » ou par « défaut », chaque attente a une temporisation et chaque redémarrage a des conditions explicites. Une poignée de bits aux temporisations ajustées à peu près fonctionne jusqu’à la première interruption.

Pourquoi les bits isolés échouent

Deux contrôleurs qui échangent des signaux ne partagent ni horloge ni cycle de programme. L’automate programmable (API/PLC) et le contrôleur du robot lisent leurs entrées, exécutent leur logique et écrivent leurs sorties chacun à son rythme, et le bus de terrain qui les relie ajoute son propre intervalle de rafraîchissement. Un signal qu’un côté active puis désactive rapidement peut ne jamais être vu par l’autre ; un signal laissé actif peut être lu deux fois. En marche normale, ces effets sont rares, et c’est pourquoi une interface faite d’un bit « départ » et d’un bit « fini » peut réussir une démonstration. Les ennuis commencent après un arrêt, un réarmement ou une perte de communication, quand les deux contrôleurs ne s’accordent plus sur ce qui a été demandé et sur ce qui a été terminé.

Définir le contrat sous forme d’états

Décrivez l’échange comme des états ayant chacun un propriétaire, et non comme une liste de variables. Une séquence illustrative est repos/prêt, demande, accepté, occupé, terminé et défaut. Ces noms sont des exemples pédagogiques ; ils ne constituent ni une norme ni la liste de signaux d’un constructeur. Pour chaque transition, notez quel contrôleur la provoque, quelle condition la rend valide, de combien de temps l’autre côté dispose pour répondre et ce qui se passe quand ce temps est écoulé.

Le schéma de base comporte quatre temps : l’automate active la demande, le robot l’acquitte, l’automate retire la demande, puis le robot retire l’acquittement. Maintenir chaque état jusqu’à la réponse évite de dépendre de la détection d’une impulsion brève. Cela ne supprime pas les exigences temporelles : définissez cycles de communication, watchdogs, délais d’acquittement et réactions si l’échange n’avance plus.

Éviter les commandes périmées et les doublons

Une demande maintenue pendant une réinitialisation peut être prise pour un nouvel ordre au redémarrage. Exigez un retour à l’état de repos défini avant toute nouvelle demande. Renvoyez l’identifiant de tâche ou de recette pour confirmer l’opération, mais ne l’utilisez pas seul pour identifier une exécution : plusieurs pièces peuvent partager la même recette. Si l’interface le permet, ajoutez un identifiant de séquence de commande et définissez persistance, rebouclage et règles de session ou de redémarrage. Précisez le traitement des doublons et des achèvements incertains. Après un redémarrage, établissez l’état réel du matériel et de la pièce —préhenseur occupé ou vide, montage chargé ou non— avant l’automatique. Les identifiants seuls ne prouvent pas qu’une opération physique s’est terminée exactement une fois.

Séparer la sécurité de la commande ordinaire

Un bit « prêt », un signal de vie (heartbeat) ou un indicateur nommé « accès sûr » qui transite par l’interface standard est une donnée de commande ordinaire. Ce n’est pas une fonction de sécurité, quel que soit son nom. Les arrêts de protection, la protection des accès et les autres fonctions de sécurité sont conçus et validés séparément, à partir de l’évaluation des risques de l’application robotisée complète, objet de la norme ISO 10218-2:2025. L’échange de signaux doit néanmoins rapporter les événements de sécurité à titre d’information, afin que l’opérateur distingue un défaut de procédé d’un arrêt de sécurité et choisisse la bonne reprise. La reprise manuelle est une opération non routinière, et l’OSHA relève que de nombreux accidents avec des robots surviennent dans des conditions de fonctionnement non routinières.

Essayer les cas interrompus

Assistez à autre chose qu’à la marche normale : des demandes en succession rapide, une interruption de communication, une coupure puis une remise sous tension de chaque contrôleur au milieu d’une tâche, l’absence du retour d’information du préhenseur et une reprise manuelle maîtrisée. Enregistrez les événements avec horodatage sur les deux contrôleurs afin de pouvoir reconstituer leur ordre. Pour le vocabulaire, PackML (ISA-TR88.00.02), développé par l’OMAC et adopté par l’ISA, est un modèle publié d’états de machine. Il décrit des états de machine, pas des signaux de robot.

Liste de contrôle avant d’engager un budget ou un périmètre

• Un tableau de propriété des signaux et un diagramme de transitions d’états validés par les deux programmeurs.
• Une temporisation et une réaction définie pour chaque attente.
• Une règle pour les demandes périmées et les doublons, avec un identifiant de tâche lorsque c’est utile.
• Une procédure de redémarrage après le réamorçage de l’un des contrôleurs, ou des deux.
• Des fonctions de sécurité évaluées et validées séparément de l’échange de signaux.
• Un enregistrement en FAT des cas interrompus, avec les alarmes et les actions de l’opérateur.

Ce que ce guide n’établit pas

Ce guide est une aide à la planification. Il ne définit aucune liste de signaux normalisée, ne décrit aucun robot ni automate particulier et ne rapporte aucun essai. Le comportement des sorties sur arrêt, sur perte du bus et au redémarrage diffère d’un produit à l’autre et doit être tiré de la documentation des constructeurs. Rien ici ne remplace l’évaluation des risques ni la validation des fonctions de sécurité, qui doivent être menées sur le système réel par des personnes dûment qualifiées.

Sources et vérifications complémentaires

• ISO — ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells (applications de robots industriels et cellules robotisées ; page du catalogue ; 2025-02 ; consulté le 2026-10-11).
• OMAC — PackML : page de synthèse présentant PackML comme développé par l’OMAC et adopté par l’ISA sous la référence TR88.00.02 (non daté ; consulté le 2026-10-12).
• OSHA — Robotics : page de synthèse indiquant que de nombreux accidents avec des robots surviennent dans des conditions de fonctionnement non routinières (non daté ; consulté le 2026-10-12).

Prochaine étape utile

Si vous spécifiez une interface entre automate et robot, tracez le diagramme d’états et le tableau des signaux avant d’écrire la moindre ligne de code, puis consultez la page Robotique et automatisation. Les projets qui partent de là sont définis et livrés par l’intermédiaire d’Eurobots/ReBots, et l’évaluation commence par la faisabilité et la répartition des responsabilités, non par une installation clés en main tenue pour acquise. Le parcours d’ingénierie à l’origine de ces guides figure dans le portfolio AYXWORKS.