Unité 1 / 9

Introduction à l'intelligence artificielle en mécatronique, cadre de sécurité et de vérification

Gains :

  • Capacité à distinguer à quelles étapes du flux de travail mécatronique (conception, code, analyse) l'IA ajoute de la valeur et quelles décisions doivent rester du ressort de l'ingénieur
  • Capacité à appliquer les principes de sécurité fonctionnelle (SIL/PL), de vérification préalable au matériel et de tests en simulation
  • Capacité à identifier le risque que les résultats de l'IA endommagent le système physique et la discipline de vérification à plusieurs niveaux qui réduit ce risque

La mécatronique se situe à l'intersection de la mécanique, de l'électronique, du contrôle et des logiciels. Votre journée en tant qu'ingénieur ; Cela implique d'écrire le code de pilotage d'un servomoteur, de filtrer le bruit d'un capteur, de régler un contrôleur PID, d'établir une logique PLC et de vérifier que tout cela fonctionne en toute sécurité dans le monde physique. L'IA peut être un accélérateur dans chacune de ces tâches : générer un brouillon de code, vous aider à résoudre une équation, extraire un modèle d'un ensemble de données, vous guider pour déboguer un bug. Mais il existe une différence cruciale en mécatronique : ce que vous produisez ne reste pas sur l’écran, il fait tourner un moteur, ouvre une vanne, déplace un levier dans le monde physique. Les règles d’utilisation de l’IA ici sont donc plus strictes que dans les logiciels purs. Dans cette unité, nous établissons comment intégrer en toute sécurité l'IA dans le flux de travail mécatronique et quelles décisions ne doivent jamais quitter l'ingénieur.

Où l’IA ajoute-t-elle de la valeur à la mécatronique et où ne l’apporte-t-elle pas ?

Délimiter clairement le rôle de l’IA dans la mécatronique est la première étape vers l’efficacité et la sécurité. Le tableau ci-dessous montre la place de l'IA dans un projet mécatronique typique.

Scène

Le rôle de l'IA

La décision laissée à la personne

conception/conception

Génération d'alternatives, établissement d'équations, synthèse de la littérature

Sélection de l'architecture, objectif de sécurité

écrire du code

Projet de code de conduite/lecture, squelette

Précision du registre, timing, tests

Analyse

Résumé des données, modèle, suggestion d'anomalie

Interprétation physique, seuil de décision

vérification

Suggestion de scénario de test, liste de contrôle

Approbation des opérations sur le terrain

Documentation

Projet de rapport, ligne de commentaires

Exactitude technique, signature

Le modèle ici est le même : l’IA donne de la vitesse, l’ingénieur assure la précision et la sécurité. L'IA peut écrire un code de conduite moteur en 30 secondes ; mais c'est l'ingénieur qui décide si ce code va brûler le pilote en raison d'une mauvaise fréquence PWM ou d'un bit de direction incorrect.

Astuce : considérez l’IA comme un « stagiaire senior qui n’a pas vu le terrain ». Ses idées sont rapides et souvent bonnes ; Mais avant de toucher la carte, vous testez chaque sortie.

Risque physique : différence avec le logiciel

Dans une application Web, un code défectueux fait planter une page ; l'utilisateur se rafraîchit, continue. En mécatronique, un code défectueux heurte un actionneur contre un interrupteur de fin de course, casse une boîte de vitesses, projette un bras de robot vers l'opérateur. Les risques sont concrets :

  • Surintensité/tension : un mauvais PWM ou une limite de courant manquante brûlera le pilote et le moteur.
  • Emballement : un signal erroné ou un retour déformé entraîne une accélération incontrôlée.
  • Violation de synchronisation : si une boucle en temps réel est retardée, le contrôle devient instable.
  • Contournement de sécurité : l'IA peut suggérer sans le savoir un code qui contourne la logique de verrouillage.

Aucun de ces risques n'est complètement éliminé par une "lecture unique du code". C'est pourquoi la vérification en mécatronique n'est pas une étape unique, mais un processus à plusieurs niveaux.

Cadre d'authentification en couches

Faites passer la sortie de l'IA à travers les couches suivantes avant de la recevoir dans le système physique. Chaque couche est là pour capturer ce que la précédente a manqué.

1. Revue statique : lisez le code/logique ligne par ligne ; registre, unité, contrôle des signes.2. Tests unitaires/logiques : tester les fonctions de manière isolée (par exemple, calcul cinématique avec valeur connue).3. Simulation (pré-HIL) : Exécuter sur modèle ; Observez la réponse échelonnée, la stabilité et la violation des limites.4. Tests matériels limités : courant/vitesse limité, arrêt d'urgence accessible, démarrage à faible consommation.5. Activation progressive : augmentez la charge et la vitesse étape par étape ; mesurer et comparer à chaque étape.

Par exemple, pour un contrôle de position d'asservissement : d'abord vous vérifiez le calcul avec un angle connu dans la main (couche 2), puis vous simulez le modèle du moteur en Python et voyez le dépassement (couche 3), puis vous fixez le moteur sur la table et essayez un petit mouvement avec une faible limite de courant (couche 4), enfin vous attachez la charge et accélérez à pleine vitesse (couche 5). L’IA peut vous aider à chacune de ces étapes ; mais l'ingénieur appuie sur le bouton "run".

Sécurité fonctionnelle : SIL et PL en bref

Vous devez connaître deux concepts standards dans les systèmes critiques pour la sécurité. SIL (niveau d'intégrité de sécurité, 1-4) selon la norme CEI 61508 / CEI 62061 et PL (niveau de performance, a-e) selon la norme ISO 13849 en matière de sécurité des machines quantifient le degré de fiabilité d'une fonction de sécurité.

notion

échelle

qu'est-ce que ça dit

SUPPRIMER

1 (faible) – 4 (élevé)

Objectif de probabilité de défaillance dangereuse de la fonction de sécurité

P.L.

a (faible) – e (élevé)

Niveau de performance requis de la fonction de sécurité de la machine

Le point clé est que si une fonction de sécurité (par exemple l'arrêt du moteur avec E-stop) répond à un objectif SIL/PL spécifique, la conception, la vérification et la documentation de cette fonction sont effectuées conformément aux exigences de la norme. AI ne peut pas faire cette évaluation à votre place et ne peut en assumer la responsabilité. L’IA peut résumer les éléments pertinents ou produire un projet de liste de contrôle ; mais la déclaration de conformité relève de la responsabilité de l'ingénieur et de l'organisme.

Attention : vérifiez toujours le numéro de substance, la valeur seuil ou la formule fournie par AI concernant ses normes de sécurité à partir du texte standard officiel. L’IA peut de manière plausible halluciner des objets standards ; Il est inacceptable de fonder une décision critique en matière de sécurité sur une sortie d’IA non vérifiée.

Invite faible/Invite forte

En mécatronique, la qualité de l’invite affecte directement la sécurité de la sortie. Une requête sans contexte produit un code générique qui ne connaît pas votre matériel.

FAIBLE : "Écrivez-moi un code de contrôle du moteur." (Résultat : quelle carte ? Quel pilote ? Quelle tension ? Inconnu ; code aveugle.) FORT : "Sur STM32F103 (bibliothèque HAL), écrivez le code pour contrôler un pilote de moteur pas à pas DRV8825. Moteur NEMA17, 200 pas/tour, 1/16 micropas. STEP pin PA0, DIR pin PA1, EN pin PA2. Limitez-le à un maximum de 3000 pas/sec. Soyez non bloquant (n'utilisez pas de délai), générez des étapes avec une interruption TIM2. Expliquez ce que fait chaque fonction avec une ligne de commentaire et listez vos hypothèses au début.

Invite puissante ; Il donne la carte, le driver, les pins, les limites et la contrainte architecturale (non bloquante). Cela réduit l'espace dont dispose l'IA pour « deviner » et le résultat devient vérifiable.

Mini-étui

Deniz, un ingénieur R&D, demande à l'IA d'écrire le code de contrôle de vitesse pour un nouveau convoyeur. L'IA produit un code épuré et accélère directement le moteur à plein régime dans la boucle principale. Au lieu de charger le code tel quel, Deniz applique une vérification en couches : il lit d'abord le code et remarque qu'il n'y a pas de montée en puissance ; Si le moteur accélère soudainement à pleine vitesse, il y aura un choc mécanique et une surintensité. "Ajoutez un profil de vitesse en courbe en S et limitez le courant maximum à 4A", donne-t-il un retour à l'IA. Ensuite, il vérifie le profil actuel avec une simple simulation en Python, puis fait tourner le moteur sans charge ni limite de courant. Au premier essai, il découvre que le sens du codeur est connecté en sens inverse ; Des tests matériels limités, et non une simulation, capturent cela. Résultat : l'IA a renvoyé une esquisse rapide, mais trois couches de vérification distinctes ont débogué trois problèmes distincts et le matériel n'a pas été endommagé du tout.

Erreurs courantes

  • Chargement de la sortie IA directement dans le matériel sans simulation ni tests limités.
  • Demander un code générique sans donner le contexte de la carte, du pilote, du code PIN et de la limite.
  • Accepter les éléments/seuils des normes de sécurité sans vérifier à partir de la mémoire de l'IA.
  • Reporter les arrêts d'urgence et les verrouillages car "je les ajouterai plus tard" et réaliser le premier test sans sécurité.
  • Considérer le code généré par l’IA comme validé parce qu’il « semble fonctionner ».
  • Oublier de mettre des contraintes physiques telles que l'accélération, la limite de courant/vitesse sur l'invite.

En résumé

  • L'IA ajoute de la vitesse à la mécatronique ; La précision, la sécurité et l’approbation de mise en service restent du ressort de l’ingénieur.
  • Le risque physique (surintensité, sens inverse, violation du timing) est différent et concret de la défaillance logicielle.
  • La vérification en couches (statique → volume → simulation → matériel limité → déploiement progressif) est obligatoire.
  • L'évaluation et la documentation des objectifs de sécurité fonctionnelle tels que SIL/PL relèvent de la responsabilité humaine.
  • Invite puissante ; Contient la carte, le pilote, les broches, les limites et la contrainte architecturale comme contexte.
  • Les informations sur les normes de sécurité sont toujours vérifiées à partir d'une source officielle ; On ne peut pas faire confiance à la mémoire de l'IA.

Tâche de candidature

Pour un véritable composant mécatronique que vous possédez (par exemple un moteur pas à pas + un pilote), remplissez le modèle « invite forte » ci-dessus : notez la carte, le pilote, les broches, la tension, le courant et les limites de vitesse. Demandez à l'IA de générer un code de conduite non bloquant avec ce contexte. Passez ensuite le résultat à travers les trois premières couches du cadre de vérification en couches : (1) lisez le code ligne par ligne et trouvez au moins deux risques potentiels, (2) vérifiez manuellement une valeur calculée (par exemple, une période de pas à une vitesse donnée), (3) effectuez une simple simulation ou un essai à sec si possible. Notez quelle couche capture quel problème.