Comment valider les verrouillages de sécurité robotique ISO 10218-1:2025 en logique Ladder

La validation de la logique de sécurité robotique selon la norme ISO 10218-1:2025 exige bien plus qu'une simple vérification de la syntaxe Ladder. Les ingénieurs doivent tester le comportement des arrêts de catégorie 0 et 1 par rapport au mouvement, à la décélération, au timing du retour d'information et au séquencement des verrouillages dans une simulation à risque maîtrisé avant la mise en service physique.

La logique de sécurité robotique n'est pas validée parce que le barreau (rung) semble propre. Elle est validée lorsque l'arrêt commandé, le chemin de retour d'information et le comportement physique de la machine concordent dans des conditions de défaut et de sensibilité temporelle.

Cette distinction est d'autant plus importante sous la norme ISO 10218-1:2025, qui pousse la sécurité robotique vers une surveillance dynamique, des transitions d'état coordonnées et une intégrité cyber-physique. L'examen statique conserve sa valeur, mais il ne vous indique pas si un robot transportant une charge inertielle sera réellement immobile avant que le couple ne soit supprimé.

Indicateur Ampergon Vallis : Dans un benchmark interne au OLLA Lab, des ingénieurs effectuant une tâche de validation délimitée d'arrêt de catégorie 1 ont initialement manqué des défauts de timing dans la séquence de décélération lors de 34 essais sur 50, avant d'observer la même logique en simulation 3D et via le traçage de variables, après quoi ils ont corrigé la séquence en une durée médiane de 14 minutes. Méthodologie : Taille de l'échantillon = 50 essais de validation sur des exercices guidés en cellule robotisée ; définition de la tâche = identifier et corriger les défauts de timing/ordre dans une séquence Ladder d'arrêt de catégorie 1 simulée ; comparateur de référence = examen statique du Ladder avant simulation ; fenêtre temporelle = sessions de laboratoire interne Ampergon Vallis, T1 2026. Cela soutient une affirmation restreinte : la simulation a amélioré la détection des défauts dans cette tâche. Cela ne soutient pas une affirmation générale concernant tous les ingénieurs, toutes les fonctions de sécurité ou la conformité formelle.

Le changement pratique réside dans le fait que la sécurité robotique repose moins sur des protections matérielles isolées que sur une interaction validée entre la logique, la détection, l'état du mouvement et l'intégrité du système. Les programmeurs d'automates (PLC) sont désormais plus proches du centre de la charge de la preuve.

Pour le travail en logique Ladder, le changement important n'est pas d'« écrire plus de code de sécurité », mais de « prouver que la séquence de contrôle reste sûre lorsque le mouvement, la détection et les communications se comportent de manière imparfaite ». C'est un standard de preuve différent.

Mises à jour critiques de la norme à intégrer en logique Ladder

Les fonctions de sécurité dépendent de plus en plus de transitions surveillées plutôt que de simples déclenchements binaires. Lorsqu'une opération collaborative ou basée sur la proximité est impliquée, la logique doit répondre à un changement d'état, et non seulement à un contact ouvert.

• Le comportement protecteur dynamique est plus important.

En pratique, cela signifie que l'automate ou le contrôleur de sécurité doit traiter les informations changeantes de distance, de vitesse et d'état de zone plutôt que de traiter la détection de présence comme un simple événement booléen.

• La surveillance de la vitesse et de la séparation (SSM) nécessite une évaluation continue.

La transition de la vitesse de production normale à une vitesse réduite ou collaborative doit être contrôlée, vérifiée et souvent verrouillée avec un retour d'information. « Commandé » n'est pas synonyme d'« atteint ».

• Les modes de transition collaborative nécessitent une gestion explicite des états.

Le lien de la norme ISO 10218-1:2025 avec le risque cyber-physique global signifie que les ingénieurs doivent considérer les communications dégradées, les modifications non autorisées et la perte d'état de confiance comme des conditions pertinentes pour la sécurité, en particulier là où existent une sécurité en réseau ou une intégration de supervision.

• La cybersécurité est désormais plus proche de la sécurité fonctionnelle.

La norme ne réduit pas la sécurité à la syntaxe Ladder. Elle pousse vers un comportement démontrable dans des conditions d'exploitation réalistes.

• Les attentes en matière de validation sont plus difficiles à satisfaire par un simple examen documentaire.

Ce que cela signifie en termes de logique Ladder

Un programmeur d'automate doit être prêt à modéliser et valider :

• les autorisations (permissives),
• les séquences d'arrêt surveillées,
• les transitions de mode,
• la confirmation du retour d'information,
• la gestion des temporisations (timeout),
• le verrouillage des défauts,
• les conditions de réinitialisation,
• le comportement en état dégradé.

C'est la différence entre la syntaxe et la déployabilité. L'une compile ; l'autre survit à la mise en service.

La distinction technique utile se situe entre la suppression immédiate de l'énergie et l'arrêt contrôlé surveillé. L'article utilise « classe I » et « classe II » comme étiquettes de travail, mais la correspondance formelle la plus sûre se réfère aux catégories d'arrêt de la norme IEC 60204-1 et aux concepts d'architecture/niveau de performance de la norme ISO 13849-1, et non à un système de classe informel.

### Arrêt de catégorie 0 : suppression immédiate de l'énergie

Un arrêt de catégorie 0 supprime l'énergie immédiatement. Dans les applications robotiques, c'est l'outil brutal : interruption directe de l'énergie d'entraînement, généralement via des chemins matériels classés sécurité.

#### Implications en logique Ladder

- La séquence est simple car elle est intentionnellement sans concession :

• La logique de contrôle peut demander ou indiquer l'arrêt, mais la fonction de sécurité est fondamentalement liée à la suppression immédiate de l'énergie.
• condition dangereuse détectée,
• chaîne de sécurité ouverte,
• énergie supprimée,
• le mouvement cesse par dynamique d'arrêt incontrôlée.

#### Caractéristiques opérationnelles

• Approprié là où la suppression immédiate est la réponse au risque requise.
• Mécaniquement plus rude pour le système.
• Moins dépendant de la coordination temporelle entre la commande et le retour d'information.
• Nécessite tout de même la validation du câblage, de l'indication d'état et du comportement de réinitialisation.

Un barreau peut représenter cette logique, mais la preuve réelle réside dans l'architecture.

### Arrêt de catégorie 1 : arrêt contrôlé avant suppression de l'énergie

Un arrêt de catégorie 1 commande à la machine de décélérer de manière contrôlée et ne supprime l'énergie qu'une fois la séquence d'arrêt terminée ou confirmée. C'est ici que la logique Ladder devient critique en termes de timing.

#### Implications en logique Ladder

Une séquence typique comprend :

• la détection de l'événement de sécurité,
• l'émission d'une commande d'arrêt contrôlé,
• le maintien de l'activation de l'entraînement pendant la décélération,
• la confirmation de la vitesse nulle ou de l'arrêt atteint,
• la supervision du délai d'attente,
• et seulement ensuite la suppression du couple ou de l'énergie des contacteurs.

#### Caractéristiques opérationnelles

• Mieux adapté aux systèmes où un arrêt incontrôlé crée un risque supplémentaire ou une contrainte mécanique excessive.
• Dépend d'une gestion correcte du retour d'information.
• Vulnérable aux conditions de course, aux erreurs de temporisation, aux bits obsolètes et aux mauvaises hypothèses sur la décélération du mouvement.
• Doit être validé par rapport au comportement de décélération réel, et non seulement par rapport à la séquence prévue.

C'est le type d'arrêt qui semble souvent correct lors de l'examen et qui échoue en mouvement.

Exemple de structure Ladder pour une séquence d'arrêt de catégorie 1

// Concept d'exemple uniquement. L'implémentation réelle de la sécurité doit suivre // l'architecture de sécurité requise, les spécifications des dispositifs et le plan de validation.

// La violation de zone initie une demande d'arrêt contrôlé |---[/] Light_Curtain_Clear --------------------( ) Robot_Stop_Request---|

// Maintenir la fenêtre de décélération après la demande d'arrêt |---[ ] Robot_Stop_Request ----[TOF Decel_Window 500 ms]-----------------|

// Confirmer la vitesse nulle avant de supprimer le couple |---[ ] Robot_Zero_Speed -----------------------( ) Safe_To_Remove_Torque-|

// Supprimer le couple si la vitesse nulle est confirmée ou si la fenêtre de décélération expire |---[ ] Safe_To_Remove_Torque --+----------------( ) STO_Command---------| | | |---[ ] Decel_Window.DN --------+

Cet exemple est pédagogique, non certifiant. L'implémentation réelle de la sécurité dépend de l'architecture de sécurité requise, du comportement des dispositifs, de la couverture de diagnostic, de la réponse aux défauts et de la validation selon les normes applicables.

La bonne approche consiste à éviter de traiter « classe I » et « classe II » comme des catégories universelles formelles, à moins qu'une spécification propre au projet ne les définisse. Le travail basé sur les normes doit plutôt s'ancrer sur des termes reconnus.

Une correspondance aux normes plus sûre

• Le comportement d'arrêt immédiat correspond le mieux à la catégorie d'arrêt 0 de la norme IEC 60204-1.
• La décélération contrôlée avant suppression de l'énergie correspond à la catégorie d'arrêt 1 de la norme IEC 60204-1.
• La structure de fiabilité et de diagnostic derrière la fonction de sécurité doit ensuite être évaluée en utilisant la norme ISO 13849-1 ou le cadre de sécurité fonctionnelle pertinent.

Pourquoi cette distinction est importante

La catégorie d'arrêt décrit comment la machine s'arrête. La catégorie d'architecture de sécurité ou le niveau de performance décrit avec quelle fiabilité la fonction de sécurité est atteinte.

Ces éléments ne sont pas interchangeables. Les confondre peut produire une documentation qui semble précise tout en laissant le risque de mise en service non résolu.

Ils échouent parce que la syntaxe n'est pas le mouvement. Une revue Ladder peut confirmer l'intention de la séquence, mais elle ne peut pas prouver par elle-même que le robot a physiquement décéléré avant que l'état de sécurité suivant ne soit imposé.

Un LLM peut identifier une temporisation manquante, un verrouillage mal formé ou un modèle de séquencement probable. Il ne peut pas observer l'inertie, le déplacement de la charge, le retard de freinage ou un retour d'information obsolète à moins que ces comportements ne soient explicitement modélisés.

Le sophisme du « semble correct »

Un barreau d'arrêt de catégorie 1 peut sembler logiquement complet s'il contient :

• une demande d'arrêt,
• une temporisation,
• un bit de vitesse nulle,
• et une sortie de suppression de couple.

Mais le risque réel réside dans les relations temporelles :

• Le bit de vitesse nulle a-t-il été retardé ?
• La temporisation a-t-elle expiré avant que le robot ne s'arrête réellement ?
• La source du retour d'information s'est-elle figée lors d'un défaut de communication ?
• L'ordre de balayage (scan) a-t-il permis un état dangereux transitoire ?
• La logique a-t-elle supposé une charge nominale plutôt que l'inertie du pire des cas ?

L'examen statique est bon pour la structure. Il est médiocre pour les conséquences concrètes.

Pourquoi l'inertie change le problème de validation

Un robot en mouvement ne se soucie pas de l'élégance du barreau. Il répond au couple, à la charge, à la vitesse, au profil de freinage et à l'état mécanique.

Pour cette raison, la validation par jumeau numérique doit être définie opérationnellement, et non rhétoriquement :

> La validation par jumeau numérique est le processus consistant à tester la logique de contrôle par rapport à un modèle de machine virtuelle représentatif du comportement, afin que l'ingénieur puisse observer si les états commandés, les états détectés et la réponse physique restent alignés dans des conditions normales et de défaut.

Si le robot virtuel occupe toujours un espace dangereux après que la logique a déclaré « sûr », le problème n'est pas philosophique.

« Simulation-Ready » ne devrait pas signifier être familier avec un éditeur Ladder. Cela devrait signifier être capable de prouver et de durcir la logique de contrôle par rapport à un comportement machine réaliste avant de toucher à une cellule réelle.

Définition opérationnelle de Simulation-Ready

Un ingénieur est Simulation-Ready lorsqu'il peut :

• construire ou inspecter la séquence Ladder pour une fonction de sécurité,
• mapper les états d'E/S et de retour d'information pertinents,
• définir ce que signifie « correct » en termes de comportement machine observable,
• injecter un défaut ou une condition anormale,
• comparer l'état du Ladder par rapport à l'état de l'équipement simulé,
• réviser la logique,
• et documenter pourquoi la révision clôt le mode de défaillance.

C'est une définition de mise en service, pas une définition scolaire.

Le dossier de preuves que les ingénieurs doivent produire

Pour démontrer vos compétences, construisez un dossier d'ingénierie compact plutôt qu'une galerie de captures d'écran :

Énoncez le comportement d'arrêt attendu en termes mesurables : commande émise, début de la décélération, vitesse nulle confirmée, couple supprimé, réinitialisation inhibée jusqu'à ce que les conditions soient sûres.

Exemple : retour de vitesse nulle retardé, entrée de zone figée, temporisation trop courte, ou réinitialisation tentée pendant une occupation dangereuse.

1. Description du système Définissez la cellule robotisée, les dispositifs de protection, les états de mouvement et l'objectif de sécurité.
2. Définition opérationnelle du « correct »
3. Logique Ladder et état de l'équipement simulé Montrez la séquence des barreaux avec le mouvement simulé du robot, l'état de la zone et les bits de retour d'information.
4. Le cas de défaut injecté
5. La révision effectuée Documentez le changement de logique, l'ajustement de la temporisation, la condition de verrouillage ou la restructuration du verrouillage.
6. Leçons apprises Énoncez ce qui a échoué, pourquoi cela a échoué et ce que la séquence corrigée prouve désormais.

Cette structure est utile car elle crée une preuve de jugement.

OLLA Lab est mieux compris ici comme un environnement de validation délimité pour répéter des comportements de contrôle à haut risque. Il ne certifie pas une fonction de sécurité, ne remplace pas la validation formelle et ne rend pas une machine conforme par proximité. Il offre aux ingénieurs un lieu pour observer si leur logique survit au stress d'une séquence réaliste avant que le matériel ne soit impliqué.

Ce que OLLA Lab apporte dans ce flux de travail

Basé sur la description du produit dans le matériel source, OLLA Lab fournit :

• un éditeur de logique Ladder basé sur le web pour construire et réviser la séquence,
• un mode simulation pour exécuter la logique sans matériel physique,
• un panneau de variables pour observer les E/S, les tags, les valeurs analogiques et les états de contrôle,
• des simulations industrielles 3D / WebXR / VR pour visualiser le comportement de la machine,
• une validation par jumeau numérique par rapport à des modèles de machines réalistes,
• et des exercices basés sur des scénarios avec des objectifs, des dangers, des verrouillages, des besoins de séquencement et des notes de mise en service.

Cette combinaison est opérationnellement utile car la validation de la sécurité robotique n'est pas une tâche unique. C'est une chaîne : construire, exécuter, observer, provoquer un défaut, réviser, vérifier.

Le flux de travail de validation dans OLLA Lab

#### 1. Sélectionner un scénario de cellule robotisée

Choisissez un scénario qui inclut :

• le mouvement du robot,
• le comportement de la zone protégée,
• les entrées de sécurité,
• et les attentes en matière de séquence d'arrêt.

L'objectif est la validation contextuelle, pas la pratique abstraite des barreaux.

#### 2. Mapper les entrées de sécurité et les états de la machine

Utilisez le panneau des variables pour lier et observer des états tels que :

• rideau lumineux clair ou franchi,
• porte fermée ou ouverte,
• commande de marche du robot,
• demande d'arrêt,
• retour de vitesse nulle,
• activation de l'entraînement,
• commande de coupure de couple,
• bits de verrouillage de défaut.

Si les tags sont vagues, l'analyse sera vague.

#### 3. Construire la séquence d'arrêt dans l'éditeur Ladder

Implémentez la logique requise pour :

• la détection d'événement,
• la demande d'arrêt contrôlé,
• le timing de décélération,
• la confirmation du retour d'information,
• la suppression du couple,
• le délai d'attente de défaut,
• et les conditions de réinitialisation.

C'est là qu'OLLA Lab devient opérationnellement utile. L'ingénieur peut passer de l'intention symbolique au comportement observable sans attendre l'accès à la machine.

#### 4. Déclencher des violations de zone pendant le mouvement

Exécutez la simulation et déclenchez une violation de zone pendant que le robot est :

• à vitesse nominale,
• à vitesse maximale,
• et, là où le scénario le permet, dans différentes conditions de mouvement.

Une séquence d'arrêt qui ne fonctionne que dans le cas facile n'est pas validée.

#### 5. Tracer la séquence par rapport au comportement de la machine

Observez si :

• la demande d'arrêt est émise immédiatement,
• le robot décélère comme prévu,
• le bit de vitesse nulle change au point correct,
• le couple est supprimé uniquement après que les critères d'arrêt sûr sont atteints,
• et la logique de défaut s'active si la confirmation attendue n'arrive pas.

C'est la valeur fondamentale de la simulation : comparer l'état du Ladder à l'état de l'équipement dans le temps, et non en théorie.

#### 6. Injecter des conditions anormales

Testez au moins un défaut, tel que :

• retour de vitesse nulle retardé,
• état du capteur bloqué en sécurité,
• expiration du délai d'attente avant confirmation de l'arrêt,
• réinitialisation tentée alors que la zone reste dangereuse,
• ou état de mode contradictoire.

Cette étape est importante car de nombreuses séquences de sécurité échouent aux limites, et non sur le chemin nominal.

La méthode de validation correcte consiste à prouver l'intégrité de la séquence dans des conditions normales et anormales. Un seul arrêt réussi ne suffit pas.

Liste de contrôle de validation minimale

• Confirmer que l'événement déclencheur est détecté de manière déterministe.
• Confirmer que la commande d'arrêt est émise sans retard involontaire.
• Confirmer que la machine reste sous tension uniquement pendant la fenêtre de décélération prévue par la conception.
• Confirmer que le retour d'information de vitesse nulle ou équivalent est requis là où la conception en dépend.
• Confirmer que la suppression du couple ne se produit qu'après que la condition d'arrêt est atteinte ou que le chemin de temporisation supervisé est invoqué.
• Confirmer que le comportement de temporisation conduit le système vers un état sûr défini.
• Confirmer que la réinitialisation est inhibée jusqu'à ce que toutes les autorisations soient rétablies.
• Confirmer que le comportement des tags et le comportement de la machine restent alignés sur des cycles répétés.

À surveiller en simulation

• Conditions de course entre les bits de fin de temporisation et les bits de retour d'information
• Artefacts liés à l'ordre de balayage (scan)
• Sorties verrouillées qui survivent à une transition dangereuse
• Chemins de réinitialisation inappropriés
• Retour d'information supposé qui n'est jamais validé indépendamment
• Transitions de mode qui contournent la séquence d'arrêt prévue

La plupart des logiques dangereuses ne s'annoncent pas avec une syntaxe spectaculaire.

La cybersécurité doit être traitée comme une condition pouvant dégrader la fiabilité de l'état pertinent pour la sécurité. Là où la sécurité robotique dépend de signaux en réseau, d'écritures de supervision ou de coordination distribuée, la perte d'intégrité peut devenir un problème de sécurité.

Implications pratiques pour la logique Ladder

Les ingénieurs doivent considérer comment la logique répond à :

• la perte de communications avec un sous-système pertinent pour la sécurité,
• des valeurs d'état obsolètes ou figées,
• des changements de mode non autorisés,
• des changements de paramètres inattendus,
• et une inadéquation entre l'état commandé et l'état rapporté.

Un principe d'ingénierie délimité

Le Ladder ne devrait pas simplement demander : « Ai-je reçu un bit de sécurité ? ». Il devrait aussi demander : « Ai-je encore des raisons de faire confiance à ce bit ? ».

Ce principe ne remplace pas un programme complet IEC 62443. Il aide cependant à maintenir la santé des communications au sein de la discussion sur la sécurité là où c'est pertinent.

La simulation est précieuse, mais elle ne remplace pas l'ingénierie de sécurité formelle, la sélection des dispositifs ou la validation sur machine. Elle réduit le risque de mise en service ; elle n'efface pas la responsabilité.

Ce que la simulation peut soutenir

• la validation de séquence,
• le traçage des E/S,
• l'injection de défauts,
• l'analyse temporelle,
• la répétition des états de l'opérateur,
• la détection précoce des défauts de logique avant l'exposition au matériel.

Ce que la simulation n'établit pas par elle-même

• la conformité formelle,
• l'architecture de sécurité certifiée,
• le niveau de performance ou SIL atteint,
• la tolérance aux pannes matérielles,
• la performance d'arrêt finale sur la machine réelle,
• l'acceptation du risque spécifique au site.

Cette limite est importante pour la crédibilité. OLLA Lab est le plus efficace lorsqu'il est utilisé comme environnement de répétition et de validation pour des tâches à haut risque difficiles à pratiquer en toute sécurité sur un équipement réel.

Utilisez-le avant la mise en service physique, et non à la place de la mise en service physique. Le flux de travail crédible est étagé.

Un flux de travail délimité

1. Définir la fonction de sécurité et les critères d'acceptation.
2. Construire la séquence Ladder et le modèle de tags.
3. Valider le comportement normal et en cas de défaut dans OLLA Lab.
4. Enregistrer le dossier de preuves d'ingénierie.
5. Transférer la logique révisée dans le cycle de vie de sécurité formel du projet.
6. Effectuer la vérification spécifique au matériel et la réception sur site sur le système réel.

C'est le bon niveau d'ambition. Un simulateur doit réduire les erreurs évitables avant que la partie coûteuse ne commence.

La norme ISO 10218-1:2025 élève le standard pratique de la logique de sécurité robotique car elle exige une preuve de comportement, et non seulement une preuve d'intention. Pour les programmeurs d'automates, la tâche centrale est de valider les séquences d'arrêt, les dépendances de retour d'information, le comportement protecteur dynamique et la réponse en état dégradé par rapport au mouvement réel de la machine.

La distinction clé est simple : un barreau de sécurité n'est pas validé lorsqu'il semble correct ; il est validé lorsque la machine devient sûre de la manière requise par la conception, y compris dans des conditions de défaut.

C'est pourquoi la simulation a sa place dans le flux de travail. Un environnement de jumeau numérique délimité tel que OLLA Lab donne aux ingénieurs un lieu pour tester les violations de zone, observer le timing de décélération, comparer l'état du Ladder à l'état de la machine et réviser la logique avant que la mise en service physique ne transforme chaque erreur en un centre de coûts.

- Page des normes ISO 10218 pour les robots et dispositifs robotiques - IEC 60204-1 équipement électrique des machines - IEC 61508 Aperçu de la sécurité fonctionnelle - ISO 13849-1 parties des systèmes de commande relatives à la sécurité - NIST Cybersecurity Framework 2.0