Quand les servomoteurs rencontrent .NET Core : comment les microservices rendent les systèmes mécaniques « vivants »

Imaginez ce scénario : vous déboguez une chaîne de montage et trois servos doivent être synchronisés en temps réel, mais l'un d'eux est toujours lent d'un demi-temps. Les données sur l'écran de surveillance continuent de sauter, mais vous ne trouvez pas le problème : s'agit-il d'une usure mécanique ? Interférence de signal ? Ou y a-t-il une faille dans la logique de contrôle elle-même ?

À ce stade, la plupart des gens vérifient le circuit et réécrivent le code à partir de zéro, en passant des heures, voire des jours. Mais existe-t-il un moyen plus intelligent ?

Pourquoi les méthodes de contrôle traditionnelles restent « bloquées »

Les systèmes mécaniques deviennent de plus en plus complexes. Il y a dix ans, un simple programme PLC pouvait gérer toute la chaîne de production ; désormais, vous devrez peut-être gérer simultanément le retour de couple du servomoteur, l'étalonnage de l'angle de l'appareil à gouverner et le flux de données en temps réel du capteur, et les faire communiquer en douceur.

Le problème réside souvent ici : vous regroupez toute la logique dans un énorme programme. C'est comme utiliser une conduite d'eau pour arroser dix parterres de fleurs en même temps. Dès qu’un lien est bloqué, c’est tout le système qui est affecté. Encore plus gênant est de devoir arrêter la ligne entière lors de la mise à niveau ou du débogage d'une partie de celle-ci.

Microservices : Donner à chaque unité mécanique une « suite indépendante »

C'est pourquoi certaines personnes ont commencé à reconstruire le système de contrôle en utilisant une architecture de microservices. Pour faire simple, chaque module fonctionnel se voit attribuer une « pièce » indépendante. Laissez le programme de contrôle du servomoteur fonctionner seul, démarrez un nouveau programme de gestion de l'appareil à gouverner et ouvrez un autre service pour la collecte de données. Ils communiquent via des protocoles légers, tout comme des voisins se disant bonjour sur le balcon sans avoir à entrer à chaque fois dans la maison de l'autre.

Mais quels en sont les avantages pratiques ?

Le débogage simplifié. Si le servo répond anormalement, il vous suffit de vérifier les quelques centaines de lignes de code du service servo, au lieu de chercher une aiguille dans une botte de foin composée de dizaines de milliers de lignes de programmes géants. Les mises à niveau peuvent être effectuées une par une. Vous voulez les paramètres PID du servomoteur ? Mettez simplement à jour ce service seul et le reste continuera à fonctionner comme d'habitude. L’expansion devient également naturelle. Vous souhaitez ajouter un poste d’inspection visuelle ? Déployez simplement un nouveau service et laissez-le communiquer avec le service existant.

Quelqu'un pourrait se demander : "Cela ressemble à un concept de génie logiciel, peut-il vraiment être utilisé dans le contrôle moteur ?"

Absolument. Le goulot d’étranglement des systèmes mécaniques modernes n’est souvent pas le matériel, mais la flexibilité de la logique de contrôle. La précision du servomoteur lui-même est suffisamment élevée, mais si le programme de contrôle ne peut pas répondre rapidement aux changements, quelle que soit la qualité du matériel, il n'aura aucune valeur. L'architecture des microservices permet à chaque unité matérielle d'avoir un « cerveau » indépendant et la vitesse de réponse est naturellement plus rapide.

Quand .NET Core rencontre le contrôle des machines

Beaucoup de gens hésitent lorsqu’ils choisissent une pile technologique. Il existe plusieurs points de convergence inattendus dans l’utilisation de .NET Core pour créer de tels microservices.

Sa fonctionnalité multiplateforme élimine le besoin de se soucier du système d'exploitation : qu'il s'agisse de Windows sur les ordinateurs industriels ou de Linux sur les appareils de pointe, le service peut fonctionner de manière cohérente. Pour les systèmes mécaniques, cela signifie plus de liberté dans les environnements de déploiement. Les usines sont souvent confrontées à des situations dans lesquelles divers anciens ordinateurs industriels sont mélangés à de nouveaux équipements. Un cadre de développement unifié réduit les coûts d’adaptation.

Les performances de .NET Core sont suffisantes pour la plupart des scénarios en temps réel. La boucle de contrôle d'un servomoteur se situe généralement au niveau de la milliseconde, et le temps de traitement des requêtes d'un bon microservice peut être contrôlé au niveau inférieur à la milliseconde. Il reste encore beaucoup de place entre les deux.

Le point le plus important est l’expérience de développement. Les ingénieurs mécaniciens ne sont généralement pas des programmeurs à temps plein et ils ont besoin de structures de code claires et maintenables. Le système de types puissant de .NET Core et la riche prise en charge des bibliothèques font que l'écriture de la logique de contrôle ressemble davantage à une description du comportement mécanique lui-même, plutôt qu'à une lutte contre la syntaxe informatique.

Extraits de mise en œuvre du concept à l'atelier

Comment le faire concrètement ? Il ne s’agit pas de renverser tout le système existant.

Vous pouvez démarrer le pilote à partir d'un lien qui pose le plus de problèmes. Par exemple, le « module de servocommande d'alimentation » initialement intégré dans le programme de contrôle maître a été extrait séparément et transformé en microservice. Ce service ne fait qu'une seule chose : reçoit la commande d'angle cible, entraîne le servo en rotation et renvoie un retour de position réelle.

Après l'avoir exécuté pendant quelques jours, vous remarquerez quelques changements. Lors du débogage de ce servo, il n'est pas nécessaire d'arrêter toute la chaîne de production. Vous pouvez redémarrer ce service indépendamment, observer les journaux et même modifier temporairement les paramètres sans affecter les autres unités.

Ensuite, le contrôle de boucle de position du servomoteur est également indépendant. Ensuite, la collecte des données du capteur est intégrée à un autre service. Avant de vous en rendre compte, vous avez construit un petit cluster de microservices : chaque unité mécanique possède son propre « pilote ».

Questions fréquemment posées et réponses réelles

« Est-ce que cela augmentera le délai de communication ?

Dans des conditions de conception raisonnables, l'augmentation du délai est souvent de l'ordre de la microseconde, mais l'amélioration de la stabilité est de plusieurs ordres de grandeur. Les cycles de contrôle de la plupart des systèmes mécaniques ne nécessitent pas de synchronisation extrême au niveau de la microseconde. Ce qui est plus important, c'est que chaque unité fonctionne de manière stable sans se tirer mutuellement vers le bas.

« Est-il plus difficile de maintenir plusieurs services ?

Bien au contraire. Imaginez que les ingénieurs qui avaient initialement besoin de comprendre l'ensemble du système dans son ensemble puissent désormais se concentrer sur un service spécifique. Lorsque de nouvelles personnes se lancent, elles n'ont plus à faire face à l'intimidante base de code « épique ». Avec moins de code pour chaque service, les problèmes sont plus faciles à localiser.

Un responsable de la maintenance d'une ligne de production a déclaré un jour : "Dans le passé, lorsqu'il y avait un problème avec le système, nous devions appeler l'ingénieur logiciel du bureau à l'atelier pour vérifier ensemble pendant une longue période. Aujourd'hui, je peux souvent voir quel journal de service signale l'erreur en un coup d'œil - c'est comme savoir quel engrenage de la machine est bloqué, au lieu que la machine entière ne devienne une boîte noire."

Écrit dans : Le système devrait également avoir une pensée « modulaire »

La conception mécanique a depuis longtemps popularisé l'idée de modularité : des engrenages, des roulements et des moteurs standardisés peuvent être combinés dans des machines aux possibilités infinies. Mais le logiciel qui contrôle ces machines est souvent écrit comme un monolithe hermétique.

L'architecture des microservices n'est rien d'autre qu'étendre la logique de la modularisation matérielle au monde du code. Laissez le programme de contrôle du servomoteur devenir une pièce standard qui peut être remplacée et améliorée indépendamment comme le servomoteur lui-même. Laissez le programme de gestion de l'appareil à gouverner être comme la structure de l'appareil à gouverner, concis, ciblé et remplir ses fonctions.

Lorsque chaque unité mécanique obtiendra également une « indépendance physique » au niveau du code, le système aura un autre type de vitalité. Les pannes sont isolées, les mises à niveau se font en douceur et la mise à l’échelle n’est plus pénible. Il ne s'agit plus d'une simple reconstruction logicielle, mais d'une re-compréhension de la nature opérationnelle du système mécanique à travers le code : chaque partie doit avoir juste ce qu'il faut d'autonomie, puis atteindre l'objectif global en collaboration.

C’est peut-être à cela que devraient ressembler les systèmes mécaniques modernes : le matériel fait son travail et les logiciels ont leur place.

Créé en 2005,kpuissancea été dédié à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire,kpuissanceintègre des moteurs hautes performances, des réducteurs de précision et des systèmes de contrôle multiprotocoles pour fournir des solutions de systèmes d'entraînement intelligents efficaces et personnalisées.kpuissancea fourni des solutions de systèmes d'entraînement professionnelles à plus de 500 entreprises clientes dans le monde avec des produits couvrant divers domaines tels que les systèmes de maison intelligente, l'électronique automatique, la robotique, l'agriculture de précision, les drones et l'automatisation industrielle.