Comment construire des portes logiques XOR et NAND dans un automate avec OLLA Lab

Pour traduire l'algèbre de Boole en logique à contacts IEC 61131-3, les ingénieurs mappent des états logiques abstraits vers le comportement des contacts basés sur la scrutation et les bobines de sortie. Dans OLLA Lab, les portes XOR et NAND ne sont pas simplement dessinées sous forme de symboles ; elles sont validées par rapport à des E/S simulées, des états de défaut et une logique de réponse machine avant tout déploiement réel.

L'algèbre de Boole et la logique à contacts sont liées, mais ne sont pas interchangeables. Les expressions booléennes sont abstraites et théoriquement intemporelles sur papier ; la logique à contacts est exécutée par un automate dans un cycle de scrutation, avec des entrées réelles, des états mémorisés et des mises à jour de sorties. C'est dans cette différence que naissent de nombreuses erreurs de débutants.

Une étude comparative interne d'Ampergon Vallis souligne ce point : 68 % des utilisateurs ont échoué lors de la création de leur première alarme de discordance en implémentant un comportement XOR dans OLLA Lab [Méthodologie : n=500 séquences logiques de débutants, tâche définie comme la construction et le test d'une alarme de discordance à deux entrées dans l'environnement de simulation, comparateur de référence = succès/échec à la première tentative par rapport à la table de vérité attendue et au comportement simulé, fenêtre temporelle = janv.-fév. 2026]. Cela soutient une affirmation limitée : traduire une intention booléenne en une structure à contacts correcte est plus difficile que de reconnaître la table de vérité. Cela ne soutient aucune affirmation plus large sur la compétence des ingénieurs à l'échelle de l'industrie.

L'algèbre de Boole décrit des relations logiques. Le schéma à contacts (LD) IEC 61131-3 décrit comment ces relations sont implémentées dans un système de contrôle basé sur la scrutation.

La distinction pratique est la suivante :

- La logique d'automate est exécutée de manière cyclique : lecture des entrées -> exécution de la logique -> écriture des sorties.

• L'algèbre de Boole traite les variables telles que A et B comme des états logiques abstraits.
• La logique à contacts mappe ces états vers des tags, des bits de mémoire et des E/S physiques ou simulées.
• Les expressions booléennes sont lues comme des relations statiques.

Ce comportement de cycle de scrutation est important car un barreau (rung) n'est pas simplement une équation symbolique. Il est évalué en séquence en utilisant l'image actuelle du processus par le contrôleur.

### Matrice de traduction de base : du booléen à la logique à contacts

Les premiers mappages standard sont directs :

• ET (AND) -> contacts en série
• OU (OR) -> contacts en parallèle
• NON (NOT) -> représentation par contact normalement fermé (NF)
• Condition de sortie VRAIE -> bobine alimentée ou bit interne
• Condition de sortie FAUSSE -> bobine non alimentée ou bit effacé

Ces mappages sont fondamentaux, mais ils ne constituent pas toute l'histoire. La tâche de l'ingénieur n'est pas seulement de représenter la logique. C'est de représenter la logique sous une forme qui reste observable, testable et sûre dans des conditions de processus réalistes.

Pourquoi la couche physique change la signification

Une variable booléenne n'est pas un fil. Dans un automate, un tag peut représenter :

• une entrée terrain 24 VDC,
• un bit de mémoire interne,
• un état dérivé,
• une condition de marche (permissive),
• une condition de déclenchement (trip),
• ou un état d'équipement simulé.

C'est pourquoi « correct » doit être défini de manière opérationnelle. Dans cet article, correct signifie que le barreau produit la sortie attendue pour toutes les combinaisons d'entrées pertinentes et se comporte de manière cohérente lorsqu'il est testé par rapport à des états de processus simulés et des cas de défaut.

Pourquoi l'IEC 61131-3 est importante

L'IEC 61131-3 normalise les langages de programmation, y compris le schéma à contacts, le bloc fonctionnel et le texte structuré pour les automates programmables (IEC, 2013). Elle n'efface pas les différences d'implémentation entre les fournisseurs, mais elle fournit un modèle d'exécution et un cadre linguistique communs.

Cela est important car la logique booléenne est universelle, tandis que l'implémentation à contacts est toujours liée à un modèle de contrôleur, à un comportement de scrutation et au contexte de l'installation.

Une porte NAND devient fausse uniquement lorsque les deux entrées sont vraies. Dans le contrôle industriel, cela la rend utile pour les modèles de conditions de marche et d'inhibition où une sortie reste disponible à moins qu'une combinaison spécifique de conditions ne soit simultanément satisfaite.

La forme booléenne est :

• C = NON (A ET B)

L'interprétation en logique à contacts équivalente est :

• La sortie C est activée lorsque A est faux, ou B est faux, ou les deux sont faux.
• La sortie C se désactive uniquement lorsque A et B sont tous deux vrais.

Pourquoi la porte NAND apparaît dans la logique industrielle

En électronique, la porte NAND est souvent présentée comme une porte universelle. Dans l'automatisation industrielle, le cadre le plus utile est plus restreint : c'est un moyen pratique d'exprimer « autoriser sauf si ces conditions coïncident ».

Les exemples typiques incluent :

• la logique de coupure de conditions de marche,
• les conditions d'inhibition combinées,
• les modèles d'agrégation de défauts,
• les conditions de maintien de séquence,
• la suppression d'états anormaux.

Cela doit être encadré avec soin. Une implémentation à contacts d'une porte NAND n'est pas un substitut à une conception formelle de sécurité fonctionnelle selon l'IEC 61508 ou à une validation de sécurité machine. C'est un modèle de logique de contrôle, pas un dossier de sécurité automatique.

Implémentation à contacts d'une porte NAND

Une forme à contacts courante à deux branches est :

[Langage : Schéma à contacts (Ladder Diagram)] // Porte NAND : La sortie est activée sauf si l'entrée A et l'entrée B sont activées.

|----[/]----------------------------------------( )----| | Entrée A Sortie C| | | |----[/]------------------------------------------------| | Entrée B |

Ce barreau utilise des contacts normalement fermés (NF) en parallèle :

• Si Entrée A = 0, la branche supérieure est vraie.
• Si Entrée B = 0, la branche inférieure est vraie.
• Si l'une des branches est vraie, la Sortie C est alimentée.
• Ce n'est que lorsque A = 1 et B = 1 que les deux contacts NF s'évaluent comme faux, faisant tomber la sortie.

Table de vérité pour NAND en termes de contacts

| Entrée A | Entrée B | Sortie C | |--------|--------|----------| | 0 | 0 | 1 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

Comment construire la porte NAND dans OLLA Lab

Utilisez l'éditeur de logique à contacts basé sur le web pour construire un test de condition de marche à deux entrées compact :

L'étape importante n'est pas de dessiner le barreau. C'est de prouver le comportement :

• deux entrées fausses -> sortie activée,
• une entrée vraie -> sortie activée,
• deux entrées vraies -> sortie désactivée.

1. Créez des tags pour Entrée_A, Entrée_B et Sortie_C.
2. Insérez deux contacts normalement fermés sur des branches parallèles séparées.
3. Assignez une branche à Entrée_A et l'autre à Entrée_B.
4. Placez Sortie_C comme bobine pilotée.
5. Lancez la simulation.
6. Basculez les entrées dans le panneau des variables et vérifiez la table de vérité.

Un exemple réaliste de condition de marche

Considérez une condition de marche simplifiée où une inhibition de maintenance doit rester disponible sauf si :

• A = Mode distant sélectionné
• B = Séquence de démarrage automatique active

Un barreau de type NAND peut maintenir une sortie vraie jusqu'à ce que les deux conditions soient simultanément présentes. En pratique, ce modèle est souvent intégré dans des réseaux de conditions de marche plus larges, et non affiché comme une porte de manuel scolaire.

Une porte XOR devient vraie uniquement lorsqu'exactement une entrée est vraie. Dans l'automatisation industrielle, cela la rend utile pour la détection de discordance, la vérification à double état et l'identification de défauts où deux signaux ne devraient pas être en désaccord de certaines manières.

La forme booléenne est :

• C = (A ET NON B) OU (NON A ET B)

En termes de contacts, le XOR est généralement construit sous forme de deux branches parallèles avec des contacts NO et NF couplés.

Pourquoi le XOR est important dans les diagnostics de machine et de processus

Le XOR devient précieux lorsque deux signaux représentent des états d'équipement mutuellement exclusifs.

Un exemple classique est une vanne avec :

• Fin de course ouverture
• Fin de course fermeture

Dans des conditions normales, ces deux indications ne devraient pas être toutes deux vraies en même temps pour une vanne simple à deux positions. Selon le timing et l'état de déplacement, elles ne devraient pas non plus rester toutes deux fausses indéfiniment. La philosophie exacte de l'alarme dépend de l'appareil et de la conception de la séquence, mais la logique de discordance est souvent construite autour du XOR ou de son complément.

Implémentation à contacts d'une porte XOR

[Langage : Schéma à contacts (Ladder Diagram)] // Porte XOR : La sortie est activée si A ou B est activé, mais pas les deux.

|----[ ]--------[/]----------------------------( )----| | Entrée A Entrée B Alarme C| | | |----[/]--------[ ]------------------------------------| | Entrée A Entrée B |

Ce barreau fonctionne comme suit :

• La branche supérieure est vraie quand A = 1 et B = 0
• La branche inférieure est vraie quand A = 0 et B = 1
• Si l'une des branches est vraie, l'Alarme C est alimentée
• Si les deux entrées sont identiques, l'alarme reste éteinte

Table de vérité pour XOR en termes de contacts

| Entrée A | Entrée B | Alarme C | |--------|--------|---------| | 0 | 0 | 0 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

Comment le XOR soutient les alarmes de discordance

Pour une alarme de discordance, le XOR est utile lorsque la condition d'alarme est définie comme « les deux signaux d'état sont en désaccord ».

Les exemples incluent :

• désaccord d'indication ouverture/fermeture,
• non-concordance de capteurs redondants,
• non-concordance entre l'état commandé et le retour d'état,
• désaccord de commutateur sélecteur,
• bits d'état appariés censés être mutuellement exclusifs.

Cela doit toujours être conçu avec le contexte. Une vanne en transit peut légitimement produire un désaccord temporaire ou une perte temporaire des deux confirmations d'état final. Une bonne logique d'alarme ajoute généralement du timing, un état de séquence ou un contexte de mouvement. Le XOR brut est un noyau utile, pas la philosophie finie.

Comment construire la porte XOR dans OLLA Lab

Utilisez OLLA Lab pour construire et tester le barreau de discordance directement dans le navigateur :

La séquence de test doit confirmer :

• 00 -> alarme éteinte
• 01 -> alarme activée
• 10 -> alarme activée
• 11 -> alarme éteinte

Si le barreau fait autre chose, le problème vient généralement de l'une des trois causes suivantes :

• type de contact inversé,
• structure de branche incorrecte,
• signification du tag mal définie.

1. Créez des tags pour Entrée_A, Entrée_B et Alarme_C.
2. Ajoutez deux branches parallèles.
3. Sur la première branche, placez NO Entrée_A en série avec NF Entrée_B.
4. Sur la deuxième branche, placez NF Entrée_A en série avec NO Entrée_B.
5. Pilotez Alarme_C avec la sortie de branche.
6. Lancez la simulation et basculez les deux entrées à travers les quatre états.

Le cycle de scrutation de l'automate rend la logique à contacts temporelle, et non simplement logique. Les entrées sont lues, la logique est résolue et les sorties sont écrites en séquence, ce qui signifie que le comportement dépend du moment où les changements d'état sont observés.

Pour des exemples de base à deux entrées, le cycle de scrutation peut sembler invisible. Pour des équipements réels, ce n'est pas le cas.

La séquence de scrutation standard

La plupart des exécutions d'automates suivent ce modèle général :

1. Lecture des entrées
2. Exécution de la logique du programme
3. Mise à jour des sorties
4. Exécution des communications, diagnostics, tâches de maintenance

Les détails exacts varient selon la plateforme, le modèle de tâche et le fournisseur, mais le principe est stable.

Pourquoi cela est important pour la logique de discordance

Une alarme de discordance XOR peut se comporter différemment selon :

• le timing de mise à jour des entrées,
• le traitement du rebond (debounce),
• l'état de la séquence,
• la logique d'impulsion (one-shot),
• l'utilisation de temporisateurs,
• le mouvement asynchrone de l'appareil.

Par exemple :

• une vanne peut laisser les deux fins de course faux pendant le déplacement,
• un interrupteur peut vibrer,
• un retour d'état peut être en retard par rapport à l'autre de plusieurs scrutations,
• une entrée simulée ou forcée peut changer proprement alors qu'un appareil réel ne le fait pas.

C'est pourquoi la validation tenant compte de la scrutation est importante. L'algèbre de Boole suppose des relations d'état idéalisées. L'équipement introduit souvent des délais, des rebonds et des ambiguïtés.

Pourquoi cela est important pour les conditions de marche

Une condition de marche de type NAND peut couper une sortie uniquement lorsque les deux conditions deviennent vraies dans le même état évalué. Si une condition est verrouillée, retardée ou dérivée via un autre barreau, le comportement observé peut différer de la simple table de vérité à moins que la logique environnante ne soit comprise.

OLLA Lab simule le comportement des portes logiques en permettant aux utilisateurs de construire des barreaux à contacts, de les exécuter dans un environnement contrôlé, de basculer les entrées, d'inspecter les états des variables et de comparer les résultats à contacts avec le comportement simulé de l'équipement.

Cela en fait un environnement de validation borné pour les tâches d'apprentissage à haut risque, et non un substitut aux tests de réception sur site ou à la validation formelle de sécurité.

Ce que signifie « Simulation-Ready » ici

Dans cet article, Simulation-Ready signifie qu'un ingénieur peut :

• prouver le comportement logique attendu par rapport à des états de test définis,
• observer la causalité des E/S en simulation,
• diagnostiquer un comportement de barreau incorrect,
• injecter des conditions anormales,
• réviser la logique,
• et vérifier le comportement révisé avant de toucher à l'équipement réel.

Comment tester un cas de défaillance NAND dans OLLA Lab

Utilisez le panneau des variables pour parcourir les combinaisons d'entrées :

• Réglez Entrée_A = 0, Entrée_B = 0 -> confirmez Sortie_C = 1
• Réglez Entrée_A = 1, Entrée_B = 0 -> confirmez Sortie_C = 1
• Réglez Entrée_A = 0, Entrée_B = 1 -> confirmez Sortie_C = 1
• Réglez Entrée_A = 1, Entrée_B = 1 -> confirmez Sortie_C = 0

Ensuite, injectez un scénario de défaut :

• redéfinissez conceptuellement une entrée comme une source de condition de marche bloquée à l'état haut,
• observez si la sortie peut encore être expliquée par la structure du barreau,
• révisez la logique ou la définition du tag si le comportement ne correspond plus à la philosophie de contrôle prévue.

Comment tester une défaillance de discordance XOR dans OLLA Lab

Pour un modèle d'alarme de discordance :

- Ensuite, simulez un cas de défaut tel que :

• Basculez Entrée_A et Entrée_B à travers les quatre états de la table de vérité.
• Confirmez que les états de désaccord activent Alarme_C.
• un fin de course bloqué à l'état activé,
• les deux interrupteurs forcés à vrai,
• les deux interrupteurs faux plus longtemps que prévu,
• état de commande incohérent avec l'état de retour.

Le panneau des variables est utile ici car il expose directement l'état.

Pourquoi cela est important au-delà de l'apprentissage de la syntaxe

La simulation comble le fossé entre la construction du barreau et la preuve comportementale. La recherche sur les jumeaux numériques, la formation basée sur la simulation et la validation cyber-physique souligne la valeur des tests virtuels pour réduire les risques, améliorer la compréhension du comportement du système et soutenir une découverte plus précoce des défauts dans les flux de travail d'automatisation (Tao et al., 2019 ; Fuller et al., 2020 ; Villalonga et al., 2021).

Cela ne signifie pas qu'un simulateur certifie une conception. Cela signifie qu'un simulateur donne aux ingénieurs un endroit plus sûr pour trouver des erreurs évidentes avant que l'installation ne le fasse.

Un bon flux de travail définit la correction avant que les tests ne commencent. Si « correct » est laissé vague, la simulation devient du théâtre.

Utilisez cette structure de preuve compacte lors de la documentation d'une construction ou d'une révision de porte logique :

Définissez l'équipement ou la fonction de contrôle. Exemple : « Vanne à deux positions avec retour d'état ouverture et fermeture utilisé pour l'alarme de discordance. »

Énoncez le comportement attendu en termes observables. Exemple : « L'alarme s'active lorsqu'exactement un retour d'état est vrai ; l'alarme reste éteinte lorsque les deux sont égaux, sous réserve de toute exception de timing documentée séparément. »

Définissez la condition anormale. Exemple : « Fin de course fermeture bloqué à l'état haut pendant la transition de commande d'ouverture. »

Montrez ce qui a changé. Exemple : « Ajout d'un temporisateur de transition et d'un qualificateur d'état de commande pour supprimer l'alarme intempestive pendant le déplacement normal. »

Énoncez ce que le test a révélé. Exemple : « Le XOR brut a détecté correctement le désaccord mais a généré des alarmes excessives pendant les transitions d'état légitimes. »

1. Description du système
2. Définition opérationnelle de « correct »
3. Logique à contacts et état de l'équipement simulé Incluez le barreau réel et les états des tags simulés ou les états de l'équipement correspondants.
4. Le cas de défaut injecté
5. La révision effectuée
6. Leçons apprises

L'erreur la plus courante est de supposer que la table de vérité est la conception. Ce n'est pas le cas. La table de vérité n'est que la contrainte de départ.

Erreurs d'implémentation fréquentes

• Inverser les contacts NO et NF
• Confondre la signification du signal avec l'état du signal
• Ignorer les effets du cycle de scrutation
• Tester uniquement le cas attendu
• Traiter la logique de condition de marche comme équivalente à la logique de sécurité
• Ne pas définir le modèle d'état du processus

Une correction pratique

Lors de la construction de tout barreau basé sur des portes, définissez trois choses avant de simuler :

• ce que chaque tag représente physiquement ou logiquement,
• quel comportement de sortie est considéré comme correct,
• quels états anormaux doivent être tolérés par rapport à ceux qui doivent déclencher une alarme.

Cette discipline élimine une quantité surprenante de confusion. De nombreux « bugs logiques » sont en réalité des bugs de spécification.

Utilisez OLLA Lab lorsque la tâche d'ingénierie nécessite une répétition du comportement logique, de la causalité des E/S, de l'injection de défauts ou de la validation de séquence sans exposer l'équipement réel à des risques inutiles.

Cela inclut :

• la pratique de la logique à contacts de débutant à intermédiaire,
• la répétition d'alarme de discordance,
• les tests de logique de condition de marche,
• le travail sur des scénarios de contrôle de vanne et de moteur,
• la revue d'interaction analogique/discrète,
• les exercices de laboratoire dirigés par un instructeur,
• les visites de logique de pré-mise en service dans un environnement borné.

Basé sur la documentation du produit, OLLA Lab prend en charge cela via :

• un éditeur de logique à contacts basé sur le navigateur,
• un mode simulation,
• la visibilité des variables et des E/S,
• des préréglages industriels basés sur des scénarios,
• des flux de travail de validation orientés jumeau numérique,
• un accès à la simulation 3D/WebXR/VR là où il est activé,
• des instructions de construction guidées,
• un coaching de laboratoire par IA via GeniAI.

L'affirmation bornée est simple : OLLA Lab donne aux ingénieurs un environnement pratique pour construire et tester la logique à contacts par rapport à un comportement simulé. Il ne remplace pas la mise en service de l'installation, les procédures sur site, les manuels des fournisseurs ou les obligations du cycle de vie de la sécurité fonctionnelle.

L'algèbre de Boole vous donne la forme logique. La logique à contacts IEC 61131-3 vous donne la structure exécutable. Le défi de l'ingénierie est la traduction entre les deux, surtout une fois que le timing de scrutation, le comportement de l'appareil et les états de défaut entrent en jeu.

NAND et XOR sont des exemples utiles car ils exposent cette traduction clairement :

• NAND exprime une logique de condition de marche qui coupe uniquement lorsque les conditions coïncident.
• XOR exprime une logique de désaccord qui identifie une non-concordance d'état.

Dans les deux cas, le barreau n'est que le début. Le vrai travail consiste à prouver le comportement dans des conditions normales et anormales. C'est là qu'un environnement de simulation justifie son existence.

Lectures connexes

- Voir Le passage à la pensée systémique : aller au-delà du dessin de barreaux.

• Pour un contexte de normes plus large, visitez notre Hub de maîtrise de la logique à contacts (Ladder Logic Mastery Hub).
• Voir Pourquoi les contacts « normalement fermés » sont les barreaux les plus importants que vous écrirez.
• Prêt à tester cette logique de discordance ? Ouvrez le préréglage de contrôle de vanne dans OLLA Lab.

- IEC 61131-3: Automates programmables — Partie 3 - Famille de normes de sécurité fonctionnelle IEC 61508 - Ressources de sécurité fonctionnelle et de validation exida - Recommandation de signalisation d'état NAMUR NE 107 - Jumeau numérique dans l'industrie : état de l'art (DOI)