Gains :
- Possibilité de diviser un scénario d'automatisation en liste d'entrées/sorties et en étapes logiques et de demander un brouillon d'échelle/ST à l'IA
- Capacité à surveiller la logique API générée par l'IA en termes de verrouillages de sécurité, d'arrêt d'urgence et de conditions de concurrence
- Capacité à vérifier les signaux d'étalonnage, de volume et de défaut lors de l'interprétation des données de télémétrie des capteurs et de l'IoT avec l'IA
L'automatisation industrielle est l'un des domaines les plus pertinents de l'ingénierie électrique et électronique : un PLC (Programmable Logic Controller) lit les signaux des capteurs et pilote les moteurs, les vannes et les alarmes selon une certaine logique. Ici, une erreur logique n’est pas simplement une « mauvaise sortie » ; Un convoyeur bloqué, une vanne qui reste ouverte ou un arrêt d'urgence qui ne s'enclenche pas peuvent entraîner de réelles blessures. L'IA est rapide pour décrire la logique d'automatisation, suggérer du code échelle/ST et interpréter les données de télémétrie des capteurs/IoT ; Mais les verrous de sécurité et la conception à sécurité intégrée relèvent de la responsabilité de l'ingénieur. Dans cette unité, nous expliquerons comment définir le scénario d'automatisation pour l'IA, comment contrôler la logique API générée et comment interpréter en toute sécurité les données des capteurs.
Configuration du scénario d'automatisation : liste d'E/S et étapes logiques
Dire à l’IA de « programmer un convoyeur » est inadéquat. Tout d’abord, séparez le processus en étapes d’entrée (capteur, bouton), de sortie (moteur, vanne, lampe) et logiques. Cette distinction clarifie à la fois l'invite et rend la logique contrôlable.
Exemple de liste d'E/S (station de remplissage simple) : Entrées : I0.0 Bouton de démarrage, I0.1 Bouton d'arrêt, I0.2 Arrêt d'urgence (NC), I0.3 Capteur de détection de bouteille, I0.4 Capteur de présence Sorties : Q0.0 Moteur du convoyeur, Q0.1 Vanne de remplissage, Q0.2 Lampe d'erreur Étapes logiques : 1) Autoriser le fonctionnement si l'arrêt d'urgence n'est PAS enfoncé et que le système est prêt. 2) Convoyeur avec retour de démarrage ; Arrêtez le convoyeur lorsque le capteur de bouteille est déclenché.3) Ouvrez la vanne de remplissage ; Fermez la vanne lorsque le capteur de présence est plein.4) Redémarrez le convoyeur ; Le processus se répète.5) L'arrêt d'urgence ou Stop amène toutes les sorties du côté sûr à tout moment.
Invite faible/Invite forte
FAIBLE : "Écrivez le code PLC pour le convoyeur." (Résultat : les adresses d'E/S, les verrouillages de sécurité et la logique d'état ne sont pas clairs ; un code incomplet potentiellement dangereux.) FORT : " Suggérez un projet de logique PLC (texte structuré) pour une station-service en fonction de la liste d'E/S et des étapes logiques ci-dessus. ASSUREZ-VOUS : - L'arrêt d'urgence est configuré avec une logique normalement fermée (NC) et constitue une condition prioritaire qui met toutes les sorties du côté de la sécurité. ne crée pas en même temps une situation dangereuse (verrouillage). - Commentez chaque étape. Indiquez qu'il s'agit d'un brouillon ; la chaîne de sécurité, les tests de sécurité et les tests sur le terrain appartiennent à l'ingénieur.
Contrôle de la logique API : sécurité, sécurité intégrée, conditions de concurrence
Il ne suffit pas que la logique produite « semble fonctionner ». Suivez cette liste de contrôle :
contrôle
Que chercher
arrêt d'urgence
Contact NF, sécurité intégrée, priorité la plus élevée, commutant toutes les sorties du côté sûr
Verrouillages
Les sorties en conflit ne doivent pas être actives en même temps
condition de course
Affectations conflictuelles dans un même cycle, situation indéfinie
état initial
Démarrage dans un état sûr et connu lorsqu'il est sous tension
Minuterie/compteur
Logique correcte, débordement, condition de réinitialisation
dysfonctionnement du capteur
Comportement sûr en cas de rupture de capteur/court-circuit
L'arrêt d'urgence (E-stop) est le point le plus critique. La fonction de sécurité doit être à sécurité intégrée : c'est-à-dire que si un câble se casse, un contact tombe en panne, le système doit tomber du côté sûr et non dangereux. Par conséquent, l'arrêt d'urgence est établi avec un contact normalement fermé (NC) ; Si le câble se casse, le circuit s'ouvre et le système s'arrête. De plus, la logique logicielle à elle seule ne suffit pas ; Une chaîne de sécurité matérielle (relais/contacteur de sécurité) doit être conçue et vérifiée par l'ingénieur.
Avertissement : Si vous voyez dans un code Ladder/ST généré par l'IA que l'arrêt d'urgence est réglé avec un contact normalement ouvert (NO) ou simplement un indicateur logiciel, il s'agit d'une vulnérabilité. Les fonctions de sécurité ne sont jamais laissées aux seuls logiciels ; La chaîne matérielle de sécurité et le respect des normes de sécurité des machines pertinentes relèvent de la responsabilité de l'ingénieur et sont vérifiés par des tests sur le terrain.
Conditions de course et machines d’état
La logique PLC fonctionne de manière cyclique ; Toute la logique est traitée du début à la fin de chaque cycle. L'IA écrit parfois des lignes contradictoires qui définissent la même sortie à un endroit et la réinitialisent à un autre ; cela provoque un scintillement imprévisible de la sortie (condition de concurrence). Construire des processus complexes comme une machine à états explicite réduit ce risque : le système est à tout moment dans un état unique et spécifique, avec des transitions dépendant de conditions claires.
Interprétation des données des capteurs et de l'IoT : étalonnage, unité, signal de défaut
Bien que les données de télémétrie des capteurs et de l’IoT (température, pression, vibration, courant) soient précieuses pour l’analyse, elles peuvent être trompeuses sous leur forme brute. Pendant que l’IA résume ces données, vous devez vérifier trois choses :
- Calibrage et échelle. La sortie du capteur est-elle la valeur brute de l'ADC ou l'unité physique réelle ? AI 4-20 mA peut mettre à l'échelle incorrectement un capteur et confondre la valeur physique.
- Unité. °C ou °F, bar ou kPa, RMS ou crête ? La confusion des unités gâche toute l’interprétation.
- Signaux de défaut. Valeur bloquée, chute soudaine à zéro, lecture hors plage ; Ce ne sont pas des mesures réelles mais il peut s'agir d'un dysfonctionnement du capteur/de la ligne. Si l’IA les interprète comme des « données intéressantes », vous vous trompez.
# Capteur 4-20 mA -> mise à l'échelle de la valeur physique (plage 0-100 °C) def ma_to_temp(ma) : si ma < 3,5 : # En dessous de 4 mA -> ligne interrompue/retour de défaut Aucun # marquer comme retour invalide (ma - 4,0) / (20,0 - 4,0) * 100,0 pour la lecture dans [4.0, 12.0, 20.0, 2.0] : t = ma_to_temp(reading) print(reading, "mA ->", "FAULT" si t est Aucun autre f"{t:.1f} C")
Astuce : lors de l'interprétation des données IoT, demandez d'abord « cette valeur est-elle physiquement possible ? Posez la question. Si un capteur de température ambiante indique 300 °C, ce n'est pas réel, il s'agit probablement d'une erreur d'étalonnage/de ligne. Éliminez les signaux de défaut avant l’interprétation de l’IA.
Mini-étui
Un ingénieur de maintenance demande à l'IA d'interpréter les données de vibration IoT d'une pompe. L'IA indique "les vibrations ont augmenté de 200% la semaine dernière, risque de panne immédiate" et suggère une alarme. L'ingénieur examine les données brutes : la valeur est « bloquée » à un nombre élevé et fixe après un certain temps, sans jamais changer. Il ne s’agit pas d’une augmentation des vibrations, mais d’un gel/d’une panne du capteur. Lors d'une véritable panne mécanique, la valeur fluctue. L'ingénieur vérifie le capteur ; La connexion du câble est lâche. L'IA a interprété la valeur fixe comme « haussière ». Leçon : éliminer les signatures de défauts (bloqués, hors de portée, pulvérisation) avant d'interpréter les données des capteurs ; L'IA n'interroge pas les données brutes.
Erreurs courantes
- Configuration d'un arrêt d'urgence avec contact NO ou uniquement indicateur logiciel (pas de sécurité).
- Laisser la fonction de sécurité uniquement au logiciel, sans chaîne matérielle.
- Création d'une condition de concurrence critique avec des lignes de configuration/réinitialisation contradictoires.
- Ne définit pas un état initial sûr lors de la mise sous tension.
- Interprétation des données du capteur à partir de l'étalonnage et de la vérification de l'unité.
- Confondre les signaux d'erreur (bloqués, hors de portée) avec les mesures réelles.
En résumé
- Divisez le scénario d'automatisation en une liste d'E/S, effacez les étapes logiques et demandez à l'IA de cette façon.
- Les fonctions d'arrêt d'urgence et de sécurité doivent être à sécurité intégrée (NC), avec la priorité la plus élevée et enchaînées matériellement ; vérifié par des tests sur le terrain.
- Les affectations conflictuelles créent une condition de concurrence critique ; Configurez des processus complexes avec une machine à états.
- La sécurité n'est jamais laissée au seul logiciel ; L’approbation de l’ingénieur est obligatoire.
- Les signaux d'étalonnage, d'unité et de défaut dans les données du capteur/IoT sont d'abord vérifiés.
- Les valeurs physiquement impossibles et les lectures bloquées sont des signes de dysfonctionnement et non des données réelles.
Tâche de candidature
Rédiger une liste d'E/S et d'étapes logiques pour un scénario d'automatisation simple (remplissage, contrôle de porte, réglage de niveau) ; Demandez à AI le projet ST/échelle. Vérifiez ensuite la logique générée : (1) L'arrêt d'urgence est-il sécurisé et prioritaire, (2) existe-t-il un verrouillage pour les sorties en conflit, (3) le démarrage sécurisé à la mise sous tension est-il défini ? Par ailleurs, demandez à l'IA des commentaires sur une série de lectures du capteur (plusieurs valeurs normales, une bloquée, une hors plage) et vérifiez qu'elle élimine correctement les valeurs de défaut. Corrigez toutes les erreurs et notez-les.