Comment programmer des zones de sécurité dynamiques pour AMR dans un automate avec la logique LiDAR

Une barrière de sécurité virtuelle pour un AMR est une stratégie de vitesse et d'arrêt contrôlée par automate qui mappe les intrusions dans les champs LiDAR vers des limites de mouvement déterministes. En pratique, le contrôleur bride le robot de sa pleine vitesse vers une consigne de vitesse d'avertissement ou vers zéro, en fonction des champs de protection actifs et d'une logique d'entrée de sécurité conforme à la norme ISO 3691-4.

Une barrière de sécurité virtuelle n'est pas un cercle peint dans un logiciel. Il s'agit d'une réponse de contrôle déterministe à une intrusion spatiale ; si le chemin de réponse est faible, la barrière est imaginaire de la pire des manières.

Pour les AMR, la distinction utile n'est pas « capteur installé ou absent », mais décélération en champ d'avertissement versus arrêt en champ de protection, exécutés via un chemin de balayage que vous pouvez réellement vérifier. La norme ISO 3691-4 définit l'objectif de sécurité ; l'automate et l'architecture de sécurité déterminent si la machine se comporte correctement lorsqu'une personne pénètre dans sa trajectoire.

Métrique Ampergon Vallis : Lors de la validation interne d'un scénario LiDAR AMR dans OLLA Lab, le routage de la réduction de vitesse en zone d'avertissement via un chemin Ethernet standard non sécurisé a ajouté suffisamment de délai de commande pour provoquer un dépassement de zone dans 3 cas sur 12 lors de tests d'approche à haute vitesse, tandis que le mappage direct du signal d'avertissement virtuel vers les entrées locales du contrôleur a éliminé ces dépassements dans le même ensemble de scénarios. Méthodologie : 12 tests d'approche simulés à 2,0 m/s contre une disposition fixe de champs d'avertissement/protection, comparateur de référence = bridage de vitesse routé par réseau, fenêtre temporelle = session de validation de mars 2026. Cela soutient un point précis : la conception du chemin de signal affecte matériellement le comportement d'arrêt simulé. Cela n'établit pas un chiffre de latence universel pour toutes les architectures AMR.

Le rôle d'OLLA Lab ici est limité et pratique. Il s'agit d'un environnement de logique à contacts (ladder) et de jumeau numérique basé sur le web pour répéter des tâches de validation à haut risque — tests de logique, traçage d'E/S, injection de défauts et révision de type mise en service — avant que quiconque ne les tente sur un véhicule réel. La syntaxe ne coûte rien. Le déploiement sécurisé, lui, a un prix.

Une zone de sécurité dynamique est une enveloppe de protection définie par LiDAR qui modifie l'état de mouvement autorisé de l'AMR en fonction de l'intrusion détectée et, dans certaines architectures, de la cinématique du véhicule telle que la vitesse ou l'angle de braquage.

En termes opérationnels, la « barrière de sécurité virtuelle » n'est pas une zone unique mais un ensemble de champs. Une disposition typique comprend :

• une zone libre, où le déplacement commandé est autorisé,
• une zone d'avertissement, où la vitesse est réduite, et
• une zone de protection, où le mouvement est arrêté par une action classée sécurité.

Cette distinction est importante car toute intrusion ne doit pas nécessairement entraîner la même réponse de la machine. Un bridage de vitesse est souvent la réponse appropriée avant qu'un arrêt d'urgence ne devienne nécessaire.

En quoi les champs d'avertissement et de protection diffèrent-ils ?

Le champ d'avertissement est une condition de décélération contrôlée. Le champ de protection est une condition d'arrêt.

| État du champ LiDAR | Condition de déclenchement typique | Réponse automate / sécurité | Consigne de vitesse AMR | Objectif typique | |---|---|---|---|---| | Zone libre | Aucune intrusion détectée | Mouvement normal autorisé | 100 % référence, ex. 2,0 m/s | Déplacement normal | | Zone d'avertissement | Objet ou personne détecté dans le champ extérieur | Bridage de vitesse, souvent avec alarme ou balise | Consigne réduite, ex. 15 % | Décélération contrôlée et réduction des risques | | Zone de protection | Objet ou personne détecté dans le champ intérieur | Arrêt de protection, souvent lié à STO ou chemin d'arrêt sécurisé équivalent | 0 % | Prévenir le contact ou l'approche dangereuse |

Quel est le lien entre la norme ISO 3691-4 et cette logique ?

La norme ISO 3691-4:2020 traite des exigences de sécurité et de vérification pour les chariots industriels sans conducteur et leurs systèmes. Pour cet article, le point technique pertinent est simple : l'AMR doit détecter les dangers et passer à un état de réduction des risques approprié au sein d'une architecture validée.

Cela ne signifie pas « installer un scanner et espérer que l'entraînement se comporte bien ». Cela signifie que la logique de champ, la catégorie d'arrêt, le comportement de décélération et la méthode de vérification doivent être cohérents en tant que système.

Que signifie « Simulation-Ready » ici ?

« Simulation-Ready » signifie qu'un ingénieur peut prouver, observer, diagnostiquer et durcir la logique de zone contre un comportement machine réaliste avant qu'elle n'atteigne un AMR réel.

Opérationnellement, cela inclut la capacité de :

• observer les changements d'état des champs LiDAR,
• tracer ces changements dans les entrées de l'automate ou du contrôleur de sécurité,
• vérifier la consigne de vitesse ou la commande d'arrêt résultante,
• injecter des conditions anormales telles que des entrées obsolètes ou des commandes retardées,
• comparer l'état du ladder avec le mouvement simulé du véhicule, et
• réviser la logique après un test infructueux.

C'est le seuil utile : non pas simplement dessiner un barreau, mais valider un chemin de réponse.

Vous mappez les données de champ LiDAR vers la logique de l'automate en convertissant les sorties du scanner en états d'entrée déterministes qui représentent le statut du champ, puis en utilisant ces états pour piloter le bridage de vitesse ou le comportement d'arrêt.

Dans de nombreux systèmes réels, les scanners de sécurité exposent le statut du champ via des sorties classées sécurité telles que des paires OSSD, un bus de terrain sécurisé ou une interface de contrôleur de sécurité. Le chemin matériel exact varie, mais le principe de contrôle ne change pas : l'automate ou la couche de sécurité doit recevoir un état sans ambiguïté qui peut être évalué sans interprétation.

Que doit réellement recevoir l'automate ?

Le contrôleur doit recevoir des signaux d'état de champ discrets et bornés tels que :

• `LIDAR_CLEAR_OK`
• `LIDAR_WARNING_ACTIVE`
• `LIDAR_PROTECTIVE_ACTIVE`
• `SCANNER_FAULT`
• `FIELDSET_SELECT_VALID`

Ceci est préférable aux abstractions vagues. Si le nom de la balise ne peut pas vous dire quel état de la machine il représente, la mise en service finira par le faire pour vous.

Pourquoi les conventions d'entrée à sécurité intégrée (fail-safe) sont-elles importantes ?

La conception des entrées à sécurité intégrée est importante car un fil coupé, un signal perdu ou un défaut de scanner doit orienter le système vers un état sûr plutôt que vers la poursuite du mouvement.

Pour les circuits de sécurité, cela signifie généralement concevoir autour d'un comportement de logique de sécurité normalement fermée (NF) au niveau fonctionnel, même si l'interface exacte du dispositif utilise des sorties électroniques à deux canaux plutôt qu'une chaîne NF à contact sec littérale. Le principe d'ingénierie est le point clé : la perte d'un signal sain ne doit pas être interprétée comme une autorisation de fonctionner.

Un mappage pratique pourrait ressembler à ceci :

• Canaux de scanner sains présents = le mouvement peut être évalué
• Champ d'avertissement enfreint = consigne de vitesse réduite
• Champ de protection enfreint = commande d'arrêt
• Désaccord de canal ou défaut de scanner = commande d'arrêt
• Sélection de jeu de champs invalide = arrêt ou inhibition du mouvement, selon l'évaluation des risques

Qu'en est-il de la commutation dynamique de champs ?

La commutation dynamique de champs signifie que le jeu de champs LiDAR actif change avec l'état de la machine, généralement en fonction de :

• la vitesse actuelle,
• l'angle de braquage,
• la direction de déplacement,
• l'état de charge,
• le mode allée ou mode zone ouverte,
• l'état d'amarrage ou d'approche de précision.

C'est ici que le terme « dynamique » dans zone de sécurité dynamique devient réel. L'enveloppe de protection pour une manœuvre d'amarrage lente ne doit pas nécessairement correspondre à l'enveloppe pour un déplacement en zone ouverte à pleine vitesse.

Vous écrivez la logique de bridage de vitesse d'un AMR en évaluant l'état de la zone LiDAR active, en attribuant une consigne de vitesse bornée pour chaque condition valide, et en forçant un chemin de vitesse nulle ou d'arrêt pour tout état de protection ou de défaut.

La logique ladder doit être suffisamment lisible pour qu'un autre ingénieur puisse l'auditer rapidement. La logique adjacente à la sécurité n'est pas l'endroit pour faire preuve d'une ingéniosité ornementale.

### Étape 1 : Lire et normaliser les entrées LiDAR

Commencez par amener le statut du scanner ou du contrôleur de sécurité dans des balises nommées.

Exemple de balises d'entrée :

• `LIDAR_Healthy`
• `Zone_Warning`
• `Zone_Protective`
• `AMR_Enable`
• `Drive_Permissive`
• `Scanner_Fault`

À ce stade, normalisez les états contradictoires. Si `Zone_Warning` et `Zone_Protective` sont tous deux actifs, la logique doit se résoudre vers l'état le plus restrictif.

### Étape 2 : Créer une décision d'état de zone unique

Utilisez des bits internes ou un registre d'état entier pour établir une condition de mouvement faisant autorité.

Exemple de priorité d'état :

1. Défaut ou scanner non sain
2. Zone de protection active
3. Zone d'avertissement active
4. Zone libre

La priorité est importante car la logique de mouvement doit se dégrader en toute sécurité en cas d'ambiguïté.

### Étape 3 : Déplacer la consigne de vitesse correcte

Utilisez des valeurs entières ou réelles bornées pour piloter la consigne de vitesse de l'AMR.

Concept de ladder illustratif :

Langage : Ladder Diagram

// Logique d'arrêt de protection |---[/]-------------------------------[MOV]---|     LIDAR_Healthy                       0                                             AMR_Speed_Ref

|---[ ]--------------------------------[MOV]---|     Zone_Protective                    0                                             AMR_Speed_Ref

// Logique de bridage de vitesse en zone d'avertissement |---[ ]---[/]--------------------------[MOV]---|     Zone_Warning  Zone_Protective       15                                             AMR_Speed_Ref

// Vitesse normale en zone libre |---[/]---[/]---[ ]--------------------[MOV]---|     Zone_Warning Zone_Protective AMR_Enable                                             100                                             AMR_Speed_Ref

Ceci est volontairement simple. Dans une architecture de production, vous sépareriez souvent la logique de consigne de vitesse standard du chemin d'arrêt classé sécurité et vérifieriez soigneusement l'interaction.

### Étape 4 : Séparer le bridage de vitesse du chemin d'arrêt de protection

Une commande de vitesse réduite n'est pas la même chose qu'un arrêt de sécurité.

Cette distinction est facile à brouiller dans un simulateur et dangereuse à brouiller sur une machine réelle. Une consigne de vitesse de zéro émise via une logique de contrôle standard n'est pas automatiquement équivalente à une fonction d'arrêt classée sécurité. Selon l'architecture, l'action de protection peut nécessiter de déclencher un Safe Torque Off (STO), un Safe Stop 1 (SS1) ou une autre fonction de sécurité validée selon les principes de conception alignés sur les normes IEC 62061 / IEC 61508.

### Étape 5 : Ajouter des diagnostics et un verrouillage si justifié

Les diagnostics améliorent la mise en service et l'isolation des défauts.

Les ajouts utiles incluent :

• alarme de scanner non sain,
• alarme d'état invalide,
• journalisation des événements de dépassement de zone,
• registre de cause d'arrêt,
• exigence de réinitialisation manuelle après un arrêt de protection, lorsque l'évaluation des risques l'exige.

Une machine qui s'arrête sans vous dire pourquoi n'est qu'à moitié coopérative.

Le comportement d'arrêt correct dépend de l'évaluation des risques de la machine, de la charge utile, de la dynamique et de la conception de la fonction de sécurité validée.

Une idée fausse courante est que l'arrêt le plus rapide est toujours l'arrêt le plus sûr. Ce n'est pas le cas. Un arrêt de catégorie 0 coupe l'alimentation immédiatement ; sur certains AMR, en particulier ceux transportant des charges instables ou des liquides, cela peut créer des risques secondaires par inertie, ballottement ou perte de freinage contrôlé.

Quand la réduction de vitesse en zone d'avertissement est-elle appropriée ?

La réduction en zone d'avertissement est appropriée lorsque l'objectif est d'abaisser l'énergie cinétique avant qu'un arrêt de protection ne devienne nécessaire.

Les utilisations typiques incluent :

• le déplacement en zone ouverte où la présence de piétons est plausible,
• les distances d'arrêt longues à vitesse plus élevée,
• les environnements avec intrusion intermittente dans les champs de détection extérieurs,
• les applications où la décélération contrôlée améliore la stabilité.

Quand un arrêt de protection est-il requis ?

Un arrêt de protection est requis lorsque l'intrusion atteint le champ intérieur ou lorsque le scanner ou le chemin de sécurité ne peut plus garantir un mouvement sûr.

Cela peut entraîner :

• un Safe Torque Off (STO),
• un arrêt contrôlé suivi d'une coupure de couple,
• une séquence d'inhibition de mouvement plus réinitialisation,
• ou une autre réponse de sécurité validée définie par la fonction de sécurité de la machine.

La norme ne récompense pas l'improvisation. Elle récompense la preuve.

Vous validez la logique LiDAR de l'automate par rapport à un jumeau numérique en comparant l'état du contrôleur, la vitesse commandée et le mouvement simulé de l'AMR dans des conditions normales et défectueuses.

C'est là qu'OLLA Lab devient opérationnellement utile. Son éditeur ladder basé sur navigateur, son mode simulation, son panneau de variables et ses scénarios 3D/WebXR permettent aux ingénieurs de tester la relation de cause à effet sans exposer des personnes ou du matériel au premier jet de la logique.

Que tester en premier ?

Commencez par les cas déterministes minimaux :

• zone libre active, aucun état d'avertissement ou de protection,
• intrusion en zone d'avertissement à vitesse nominale,
• intrusion en zone de protection à vitesse nominale,
• défaut de scanner,
• perte de signal sain,
• entrée d'état de zone contradictoire,
• comportement de réinitialisation et de redémarrage après un arrêt.

Utilisez le panneau des variables pour surveiller :

• les bits de zone active,
• `AMR_Speed_Ref`,
• l'état d'activation de l'entraînement,
• la balise de cause d'arrêt,
• les bits d'alarme,
• toute logique de temporisation ou d'anti-rebond.

À quoi ressemble un test de jumeau numérique valide ?

Un test valide n'est pas « le robot a ralenti une fois ». C'est une comparaison répétable entre le comportement attendu et observé.

Dans OLLA Lab, cela signifie que vous pouvez :

• basculer ou induire des états de zone,
• observer la transition du ladder,
• inspecter le registre de consigne de vitesse,
• visualiser la réponse de l'AMR dans le scénario 3D,
• répéter le test dans les mêmes conditions,
• et réviser la logique lorsque la réponse de la machine ne correspond pas à la philosophie de contrôle prévue.

C'est la différence entre l'animation et la validation.

Pourquoi les tests en direct sur un AMR physique sont-ils un mauvais endroit pour apprendre cela ?

Les tests en direct sont coûteux, dangereux et généralement peu tolérants aux erreurs exploratoires.

Un ingénieur junior ne devrait pas avoir à découvrir, sur un véhicule chargé en mouvement, qu'un bridage en zone d'avertissement était routé via un chemin lent ou non déterministe. OLLA Lab fournit un environnement de répétition borné pour exactement ce type d'erreur : conséquences élevées, assez courantes pour être importantes, et difficiles à pratiquer en toute sécurité sur un équipement réel.

Vous devez documenter un ensemble compact de preuves d'ingénierie, pas une galerie de captures d'écran.

Utilisez cette structure :

Résumez l'aperçu du contrôle, pas seulement le résultat. Par exemple : « la réduction en zone d'avertissement via un contrôle réseau standard était fonctionnellement correcte mais trop lente pour ce cas de vitesse d'approche. »

1. Description du système Définissez le mode AMR, la disposition du scanner, la logique de champ, l'interface d'entraînement et les hypothèses pertinentes.
2. Définition opérationnelle de « correct » Indiquez exactement ce qui doit se produire dans les états libre, d'avertissement, de protection et de défaut.
3. Logique ladder et état de l'équipement simulé Capturez les barreaux pertinents, les balises et le comportement correspondant de l'AMR dans le simulateur.
4. Le cas de défaut injecté Enregistrez la condition anormale introduite, telle qu'un défaut de scanner, un bit d'avertissement obsolète ou un bridage de vitesse retardé.
5. La révision effectuée Montrez ce qui a changé dans la logique, le séquençage ou le chemin de signal.
6. Leçons apprises

Cette forme de preuve est plus utile qu'une image de tableau de bord polie sans historique de défaillance. La mémoire de mise en service est construite à partir de révisions, pas de cosmétiques.

Les normes et cadres techniques primaires sont la sécurité fonctionnelle et la sécurité des robots mobiles, pas l'optimisme robotique générique.

Les références les plus pertinentes incluent :

- ISO 3691-4:2020 pour les chariots industriels sans conducteur et leurs systèmes,

• IEC 62061 pour la sécurité fonctionnelle des machines,
• IEC 61508 comme cadre fondamental de sécurité fonctionnelle,
• les manuels des fabricants de scanners de sécurité pour la configuration des champs et le comportement de réponse,
• et les évaluations des risques spécifiques à l'application qui définissent les fonctions de sécurité requises et le comportement d'arrêt.

La littérature académique et industrielle sur les jumeaux numériques et la validation basée sur la simulation est également pertinente, mais elle doit être utilisée avec précaution. La simulation peut améliorer la qualité de la répétition, la visibilité des défauts et la préparation à la mise en service ; elle ne remplace pas la validation formelle de sécurité sur le système réel.

OLLA Lab s'intègre comme un environnement de validation et de répétition à risque contenu pour la logique ladder, le comportement des E/S, l'observation par jumeau numérique et le dépannage de type mise en service.

Correctement borné, c'est une affirmation forte et utile. OLLA Lab permet aux ingénieurs de :

• construire une logique ladder dans un éditeur basé sur le web,
• exécuter une simulation sans matériel physique,
• surveiller les balises et les E/S dans le panneau des variables,
• travailler sur des scénarios de type AMR dans des environnements 3D/WebXR,
• et tester comment la logique de contrôle mappe le comportement de la machine avant l'exposition sur site.

Il ne certifie pas une fonction de sécurité, ne remplace pas une évaluation formelle des risques et ne rend pas un AMR réel sûr par association. Un simulateur est une salle de répétition, pas un tampon de conformité.

Programmer une barrière de sécurité virtuelle est un problème de contrôle avec des conséquences sur la sécurité. La tâche principale consiste à mapper les états des champs LiDAR vers des réponses machine déterministes, puis à vérifier que l'AMR ralentit ou s'arrête réellement comme prévu dans des conditions normales et défectueuses.

La distinction durable est simple : présence du capteur versus chemin de réponse validé. De nombreux problèmes d'intégration résident dans cet écart.

Un ingénieur utile dans ce domaine n'est pas seulement fluide dans la syntaxe ladder. Un ingénieur utile peut définir un comportement correct, le tester contre un équipement simulé, injecter des défauts, réviser la logique et expliquer pourquoi le chemin de contrôle final est plus sûr que le premier jet.

- Pour le contexte de sécurité robotique adjacent, voir ISO 10218-1:2025: Navigating the New Robot Safety Classifications. - Pour l'intégration au niveau de l'usine et la pression de conformité, voir Collaborative Application Standards 2026: The OEM Survival Guide.

• Pour placer cette logique dans un comportement de système de contrôle plus large, consultez Advanced Process Control and PID Simulation Lab.
• Tester cela sur du matériel physique est risqué. Ouvrez le scénario LiDAR AMR dans OLLA Lab pour valider la logique de zone par rapport à un jumeau numérique 3D.

- ISO 3691-4 exigences de sécurité pour les chariots industriels sans conducteur - IEC 62061 sécurité fonctionnelle des systèmes de commande de machines - IEC 61508 Aperçu de la sécurité fonctionnelle - Revue du jumeau numérique dans la fabrication (IFAC-PapersOnLine) - Systèmes cyber-physiques dans l'Industrie 4.0 (AQTR)