Liaison API/Robot : comment normaliser les protocoles d'interverrouillage

Pour normaliser une liaison API-robot, les ingénieurs doivent définir des échanges booléens déterministes pour la disponibilité, les autorisations de mouvement, la réinitialisation des défauts et la confirmation de position. L'objectif est d'empêcher la progression de la séquence sur des états ambigus ou transitoires. En pratique, des interverrouillages normalisés réduisent le risque de collision en forçant l'API et le contrôleur du robot à s'accorder avant la poursuite du mouvement.

Une idée reçue courante est que la liaison robot consiste principalement à faire correspondre correctement les bits. Ce n'est pas le cas. Le problème le plus complexe est d'amener deux contrôleurs à s'accorder sur les transitions d'état malgré des comportements de cycle, des synchronisations réseau et des pertes de retour transitoires différents. Un bit mappé peut rester un bit erroné.

Dans l'étude d'Ampergon Vallis portant sur 500 intégrations de cellules robotisées simulées dans OLLA Lab, 68 % des défauts de collision initiaux impliquaient des chutes de retour `In_Position` (en position) ou `Zone_Clear` (zone libre) asynchrones inférieures à 50 ms. Méthodologie : n=500 exécutions de validation de cellules de transfert et de « pick-and-place » simulées, comparateur de référence = logique utilisateur de premier passage avant révisions anti-rebond ou durcissement d'état, fenêtre temporelle = 1er janvier 2026 au 15 mars 2026. Cette mesure soutient un point précis : l'instabilité des retours de courte durée est un mode de défaillance fréquent lors du premier passage en mise en service simulée. Elle ne prétend pas représenter un taux de collision à l'échelle de l'industrie.

Une mauvaise liaison échoue généralement de manière peu glorieuse. Une pince se ferme trop tôt, un convoyeur avance avant que le robot ne se dégage, ou un préhenseur entre dans une zone que l'API supposait vide. La physique est rarement impressionnée par un timing optimiste.

Les signaux essentiels dans une liaison API-robot sont la disponibilité, les autorisations de sécurité, la confirmation de l'état de mouvement, la gestion des défauts et les bits d'exécution de séquence. Si ces signaux ne sont pas explicitement définis et verrouillés dans un modèle de séquence clair, la liaison n'est pas normalisée ; elle est simplement connectée.

Signaux de liaison principaux

Confirme que les prérequis côté API pour le mouvement sont satisfaits. Les conditions typiques incluent : chaîne de sécurité opérationnelle, protections fermées si nécessaire, arrêt d'urgence réinitialisé, aucun défaut de cellule actif et séquence dans un mode autorisé.

• `PLC_System_Ready`

Confirme que le contrôleur du robot est disponible pour participer au fonctionnement automatique. Cela peut inclure : contrôleur opérationnel, aucun défaut de programme actif, aucun arrêt de protection et mode de fonctionnement aligné sur la séquence de la cellule.

• `Robot_System_Ready`

Commande de l'API demandant l'activation de la puissance des servomoteurs ou des variateurs, lorsque l'architecture attribue cette autorité à l'API.

• `PLC_Request_Motors_On`

Retour du robot confirmant que la puissance des variateurs est effectivement activée. La commande et le retour ne sont pas la même chose. Les usines le réapprennent souvent à des heures peu opportunes.

• `Robot_Motors_On`

Une demande de réinitialisation délibérée émise uniquement lorsque les conditions de réinitialisation sont valides.

• `PLC_Fault_Reset_Request`

Retour indiquant que le robot n'est plus dans un état de défaut.

• `Robot_Fault_Clear`

Indication de position atteinte ou de zone libre utilisée pour confirmer qu'un mouvement programmé ou une condition de dégagement sécurisé a réellement eu lieu.

• `Robot_In_Position`

Signal dérivé ou direct confirmant que le robot est en dehors d'une zone d'interférence protégée avant qu'un autre actionneur ne bouge.

• `Zone_Clear`

Déclencheur de séquence émis uniquement lorsque toutes les autorisations requises et les confirmations d'état sont vraies.

• `PLC_Cycle_Start`

Retour indiquant que le robot a terminé la tâche commandée ou a atteint le point de contrôle de séquence attendu.

• `Robot_Cycle_Complete`

Définition opérationnelle d'une liaison normalisée

Une liaison API-robot normalisée est un échange bidirectionnel et déterministe d'états booléens avec une propriété définie, des transitions valides, un comportement en cas de temporisation dépassée et une réponse aux défauts. La normalisation importe moins pour l'élégance que pour la répétabilité : chaque bit doit répondre clairement à quatre questions :

1. Qui en est le propriétaire ?
2. Quand peut-il s'activer ?
3. Quand doit-il se désactiver ?
4. Que fait la séquence s'il n'arrive jamais, arrive en retard ou vacille ?

Si ces réponses manquent, l'interface n'est que de l'optimisme non documenté.

Contexte normatif

Les normes et directives pertinentes incluent :

• ISO 10218-1 / ISO 10218-2 pour les exigences de sécurité des robots et des systèmes robotisés.
• RIA TR R15.406 pour les pratiques de protection dans les cellules robotisées.
• IEC 61508 comme cadre général de sécurité fonctionnelle pour les systèmes électriques/électroniques/programmables.

Ces normes ne fournissent pas une liste de bits universelle pour chaque cellule. Elles exigent cependant un traitement discipliné des fonctions de sécurité, des modes de fonctionnement et de la réduction des risques.

Les conditions de concurrence provoquent des collisions lorsque l'API fait avancer la logique de séquence sur la base d'un état transitoire ou obsolète que le contrôleur du robot n'a pas maintenu de manière stable. Le mécanisme habituel est simple : l'API voit une autorisation vraie pendant un ou deux cycles, avance une action en aval, alors que le robot a déjà quitté l'état supposé ou ne l'a jamais totalement atteint.

Pourquoi le timing de l'API et du robot diverge

Un API et un contrôleur de robot n'évaluent pas nécessairement l'état sur la même cadence.

• Une tâche API peut s'exécuter toutes les 2 à 10 ms.
• Les mises à jour des E/S du robot peuvent se rafraîchir à un intervalle différent.
• Le transport réseau ajoute de la gigue (jitter).
• Le lissage de mouvement peut invalider brièvement un bit de position.
• La logique IHM ou de supervision peut écrire des commandes de séquence de manière asynchrone.

Ce décalage suffit à créer un faux sentiment de certitude. Les bugs de séquence vivent souvent dans l'écart entre « vrai une fois » et « vrai assez longtemps pour être fiable ».

Modèles courants de conditions de concurrence

#### 1. Perte transitoire de `In_Position` pendant un mouvement lissé

Un robot atteint une zone apprise, active `In_Position`, puis le perd brièvement pendant le lissage de trajectoire ou la transition de zone. L'API voit le bit assez longtemps pour libérer une pince, démarrer un indexeur ou ouvrir une porte. Le robot peut encore être physiquement à l'intérieur de l'enveloppe d'interférence.

#### 2. Confusion commande-retour

L'API active une `Motors_On_Request` et traite immédiatement le robot comme capable de mouvement avant de recevoir le retour vérifié `Robot_Motors_On`. C'est une logique d'état de commande qui se fait passer pour une logique d'état d'équipement.

#### 3. Comportement de double bobine ou de bit fantôme

Le même état de séquence est écrit à partir de plus d'un barreau, d'une tâche ou d'un chemin de contrôleur. Le résultat est un bit qui semble valide dans les instantanés de tendance mais qui n'est pas détenu de manière déterministe.

#### 4. Substitution de la preuve par une temporisation

Un programmeur insère un délai fixe au lieu d'attendre une confirmation positive telle que `Zone_Clear` ou `Robot_In_Position_Stable`. Les temporisateurs sont utiles pour l'anti-rebond et la supervision des délais. Ils ne sont pas la preuve qu'un mouvement s'est terminé en toute sécurité.

Pourquoi une logique normalisée réduit ce risque

Une logique normalisée réduit les conditions de concurrence en forçant l'avancement de la séquence à dépendre d'un état vérifié, et non d'un temps écoulé supposé. La distinction est concise et importante : le timing n'est pas une preuve ; le retour d'information est une preuve.

C'est aussi là que le terme « Simulation-Ready » doit être correctement défini. Un ingénieur « Simulation-Ready » n'est pas quelqu'un qui peut dessiner une syntaxe Ladder de mémoire. C'est quelqu'un qui peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne une machine réelle.

Pour programmer un interverrouillage sûr, utilisez une vérification en série de la disponibilité, de l'état sans défaut et du retour stable avant de verrouiller la commande de séquence suivante. L'objectif n'est pas de rendre le barreau esthétique. L'objectif est de rendre le mouvement prématuré difficile.

### Exemple : structure d'interverrouillage `PLC_Cycle_Start`

Voici un exemple de logique Ladder sous forme textuelle montrant un modèle borné. Le nommage des tags varie selon la plateforme ; le principe logique, non.

|----[XIC PLC_System_Ready]----[XIC Robot_Fault_Clear]----[XIC Robot_Motors_On]----[XIC Zone_Clear]----[TON T4:0 50ms]----| | | |----[XIC T4:0.DN]------------------------------------------------------------------------------------------------[OTE PLC_Cycle_Start]----|

Ce que fait ce barreau

• `PLC_System_Ready` vérifie que la cellule est autorisée à fonctionner.
• `Robot_Fault_Clear` empêche l'avancement de la séquence vers un état anormal connu.
• `Robot_Motors_On` confirme que le robot est effectivement sous tension.
• `Zone_Clear` confirme que le robot est physiquement hors de la zone d'interférence.
• `TON` (anti-rebond) exige que la chaîne d'autorisation reste vraie pendant une période stable minimale avant d'émettre `PLC_Cycle_Start`.

Pourquoi le temporisateur anti-rebond est important

Un temporisateur anti-rebond filtre l'instabilité des signaux de courte durée causée par :

• la gigue réseau,
• les transitions d'état de mouvement,
• une logique de zone dérivée bruyante,
• le battement de capteurs,
• les brèves chutes d'état du contrôleur lors des transitions de programme.

Utilisé correctement, un temporisateur anti-rebond valide la stabilité du signal. Utilisé paresseusement, un temporisateur devient une superstition avec des millisecondes attachées.

Règles de programmation recommandées

#### Définissez explicitement la propriété

Chaque bit de liaison doit avoir une source faisant autorité. Si `Robot_In_Position` peut être synthétisé à trois endroits, ce n'est pas un signal ; c'est un argument.

#### Séparez les bits de commande des bits de retour

N'utilisez pas `Request_Motors_On` comme preuve que les moteurs sont allumés. Gardez les commandes et les preuves distinctes.

#### Ajoutez une supervision des délais (timeout)

Chaque retour attendu doit avoir un chemin de dépassement de délai :

• commande émise,
• retour attendu,
• délai dépassé,
• défaut verrouillé,
• chemin de récupération défini.

Une séquence sans comportement de dépassement de délai n'est pas robuste. Elle est juste patiente jusqu'à ce qu'elle échoue.

#### Verrouillez les états de séquence, pas les espoirs momentanés

Utilisez une logique d'état explicite ou des étapes de séquence afin que la progression dépende de transitions validées. C'est particulièrement important lorsque le mouvement du robot et les actionneurs auxiliaires partagent la même enveloppe de travail.

#### Concevez la réponse aux défauts avant de terminer le chemin nominal

Si `In_Position` chute en cours de cycle, définissez si la cellule :

• fait une pause,
• se rétracte,
• se met en défaut et nécessite une intervention de l'opérateur,
• ou revient à une étape sûre connue.

La machine finira par poser cette question. Mieux vaut y répondre avant le démarrage.

OLLA Lab simule les échecs de timing asynchrones en permettant aux ingénieurs de tester la logique Ladder contre un jumeau numérique tout en observant les changements d'état des E/S, le comportement de la séquence et la réponse aux défauts dans un environnement à risque maîtrisé. Cela le rend utile pour la répétition et la validation, et non comme un substitut à la réception formelle sur site ou à la certification de sécurité.

Définition opérationnelle de la validation par jumeau numérique dans ce contexte

Dans cet article, la validation par jumeau numérique signifie tester si la logique Ladder produit le comportement machine souhaité par rapport à un modèle d'équipement virtuel réaliste, dans des conditions normales et anormales. Les comportements observables incluent :

• basculer des entrées discrètes et vérifier la réponse des sorties,
• surveiller les transitions d'état des tags dans la séquence,
• injecter une perte de retour transitoire,
• vérifier si les interverrouillages bloquent les mouvements dangereux,
• comparer l'état du Ladder à l'état de l'équipement simulé,
• réviser la logique après un défaut et retester.

À quoi ressemble le flux de travail dans OLLA Lab

En utilisant OLLA Lab, un ingénieur peut :

• construire la logique de liaison dans l'éditeur Ladder basé sur le web,
• exécuter le programme en mode simulation,
• inspecter les tags, les E/S et les valeurs analogiques dans le panneau des variables,
• observer le comportement de la cellule robotisée ou de la machine dans la simulation 3D/WebXR,
• injecter des conditions anormales telles qu'une chute du signal `Robot_In_Position`,
• confirmer si la séquence s'arrête, se met en défaut ou récupère comme prévu.

C'est là qu'OLLA Lab devient opérationnellement utile. Il offre aux ingénieurs un espace pour répéter la classe exacte d'erreurs trop coûteuses, trop dangereuses ou trop perturbatrices pour être pratiquées sur du matériel réel.

Un exercice de validation concret

Un test de liaison pratique dans OLLA Lab pourrait ressembler à ceci :

1. Construire une séquence de « pick-and-place » avec `PLC_System_Ready`, `Robot_Motors_On`, `Zone_Clear` et `PLC_Cycle_Start`.
2. Exécuter la cellule normalement et confirmer que le robot libère la zone avant que le convoyeur n'indexe.
3. Injecter une brève chute en cours de cycle sur `Robot_In_Position` ou `Zone_Clear`.
4. Observer si la logique anti-rebond filtre correctement le transitoire.
5. Augmenter la durée du défaut et vérifier que l'API arrête l'avancement de la séquence et verrouille un défaut.
6. Réviser la logique du barreau ou de l'état, puis relancer le même test.

Cette boucle — construire, observer, injecter un défaut, réviser, retester — est la véritable valeur de formation. La syntaxe seule n'enseigne pas le jugement de mise en service.

OLLA Lab peut aider les ingénieurs à valider la logique de séquence, le comportement des E/S et la gestion des défauts avant le déploiement. Il peut soutenir la répétition des tâches de mise en service telles que la vérification des interverrouillages et les tests d'états anormaux.

OLLA Lab ne prouve pas par lui-même :

• l'exactitude du câblage sur site,
• la performance finale des fonctions de sécurité,
• l'atteinte du niveau SIL,
• la conformité réglementaire,
• ou la compétence sur site selon les contraintes spécifiques de l'usine.

Un simulateur est un espace de répétition discipliné. Ce n'est pas une dérogation aux normes.

La liaison API-robot doit être guidée par des normes de sécurité formelles, une philosophie de contrôle documentée et une conception d'état déterministe. Les normes établissent le cadre de sécurité ; la conception de la séquence détermine si la cellule se comporte de manière cohérente à l'intérieur de ce cadre.

Normes et conseils pour ancrer le travail

Définissent les exigences de sécurité pour les robots industriels et les systèmes robotisés, y compris les responsabilités d'intégration.

• ISO 10218-1 / ISO 10218-2

Fournit des conseils pratiques de protection pour les applications robotiques et la conception de cellules.

• RIA TR R15.406

Encadre la discipline plus large de la sécurité fonctionnelle pour les systèmes programmables.

• IEC 61508

Définissent la sémantique des signaux spécifiques au contrôleur, les bits d'état de mouvement et le comportement des E/S de sécurité.

• Manuels d'interface robot du fabricant

Pratiques d'ingénierie qui comptent plus que les slogans

#### Rédigez une matrice d'interface

Documentez chaque bit de liaison avec :

• source,
• destination,
• état normal,
• signification lorsqu'il est activé,
• comportement de réinitialisation,
• attente de délai (timeout),
• conséquence en cas de défaut.

#### Définissez le comportement « correct » avant de tester

Ne commencez pas la simulation ou la validation de type FAT sans une définition opérationnelle du succès. « Le robot fonctionne » n'est pas une définition. « Le convoyeur indexe uniquement après que `Zone_Clear` soit resté vrai pendant 50 ms et qu'aucun défaut robot actif n'existe » est une définition.

#### Traitez les états anormaux comme des exigences de premier ordre

Testez :

• robot en défaut au démarrage du cycle,
• moteurs arrêtés pendant la séquence,
• `Cycle_Complete` obsolète,
• `In_Position` perdu,
• réinitialisation tentée dans des conditions invalides.

#### Gardez la logique de sécurité et la logique de séquence distinctes

Les fonctions classées sécurité doivent être conçues et validées selon l'architecture et les normes applicables. Les bits de séquence standard ne remplacent pas les fonctions de sécurité. Mélanger ces rôles négligemment est la façon dont la documentation devient de la fiction.

Les ingénieurs doivent démontrer leurs compétences en liaison avec un ensemble compact de preuves techniques montrant l'intention de la séquence, la gestion des défauts et la discipline de révision. Une galerie de captures d'écran ne suffit pas. N'importe qui peut collecter des bits verts.

Utilisez cette structure :

1) Description du système

Indiquez clairement l'objectif de la cellule et les interfaces.

Exemple : « Cellule de transfert à convoyeur à deux axes avec un robot articulé effectuant du pick-and-place entre l'entrée et le nid de montage. L'API contrôle le convoyeur, la pince et l'état de la séquence. Le robot fournit les retours moteurs activés, défaut effacé, en position et cycle terminé. »

2) Définition opérationnelle du « correct »

Définissez ce que signifie « correct » en termes de comportement observable.

Exemple : « `PLC_Cycle_Start` ne peut s'activer que lorsque les autorisations de sécurité sont saines, que les moteurs du robot sont activés et que `Zone_Clear` est vrai en continu pendant 50 ms. Le mouvement du convoyeur est inhibé pendant que le robot est dans la zone de transfert. »

3) Logique Ladder et état de l'équipement simulé

Montrez la logique du barreau ou de l'état avec la réponse de la machine simulée.

Inclure :

• extrait de Ladder,
• liste de tags,
• matrice de séquence,
• preuve 3D ou d'état de simulation montrant le robot hors de la zone lorsque le convoyeur démarre.

4) Le cas de défaut injecté

Introduisez délibérément une condition anormale.

Exemple : « Chute injectée de 30 ms sur `Robot_In_Position` pendant le mouvement de sortie lissé. »

5) La révision effectuée

Expliquez le changement logique et pourquoi il était nécessaire.

Exemple : « Ajout d'un anti-rebond de 50 ms sur `Zone_Clear`, séparation des tags de commande et de retour, et verrouillage d'un état de maintien de séquence en cas de dépassement de délai. »

6) Leçons apprises

Énoncez clairement la conclusion technique.

Exemple : « La logique initiale traitait la preuve de position transitoire comme un dégagement stable. La logique révisée a nécessité une confirmation soutenue et a empêché le mouvement prématuré du convoyeur. »

Ce type d'artefact est utile car il démontre un raisonnement, pas seulement une familiarité avec l'outil.

Une liaison normalisée est meilleure car elle rend le comportement prévisible à travers les cellules, les équipes et les conditions de défaut. La logique ad hoc peut fonctionner lors d'une démonstration et échouer sous l'effet de la dérive, de la latence, des modifications de maintenance ou des scénarios de récupération.

Avantages pratiques de la normalisation

Tout le monde sait ce que signifie chaque bit et quand il est valide.

• Ambiguïté de mise en service réduite

Une propriété claire et une logique de temporisation rendent les défaillances traçables.

• Isolation des défauts plus rapide

Le mouvement dépend de preuves, pas d'hypothèses.

• Comportement de séquence plus sûr

Les modèles standard réduisent la réinvention sans figer le jugement technique.

• Meilleure réutilisation entre les projets

Une liaison documentée est plus facile à tester systématiquement dans un jumeau numérique ou un environnement de simulation.

• Flux de travail de simulation et FAT amélioré

Le but n'est pas la propreté bureaucratique. Le but est que les interfaces répétées échouent moins mystérieusement.

- Portail des spécifications OPC UA - Page des normes ISO 10218 sur les robots et dispositifs robotiques - Aperçu de la sécurité fonctionnelle IEC 61508 - Revue de la mise en service virtuelle et du jumeau numérique (Journal of Manufacturing Systems) - Ressources du banc d'essai de fabrication intelligente du NIST