Quand les servomoteurs rencontrent les microservices : une mise à niveau architecturale de la pensée mécanique

Avez-vous déjà essayé d'assembler un robot de précision à l'aide d'un vieux jeu de clés ? Je suppose que vous connaissez la sensation de serrer une vis pour constater qu'un autre joint est coincé. Dans le domaine des machines et de l’automatisation, les servomoteurs, les boîtiers de direction et divers dispositifs de transmission sont à l’image de ces pièces de précision. Ils fonctionnent à merveille individuellement, mais une fois intégrés dans un vaste système, la coordination devient un cauchemar. Retards de signal, congestion des données, arrêts de lignes de production entières lors de maintenance... ces problèmes surviennent quotidiennement dans l'atelier.

Puis quelqu’un a commencé à parler d’« architecture de microservices ». Cela ressemble à une affaire de service informatique ? Mais si vous avez démonté un bras robotique multi-axes, vous constaterez que son unité de contrôle, son module d'alimentation et son retour de capteur sont naturellement des modules orientés service. C'est juste que nous sommes habitués à les relier ensemble.

Pourquoi les personnes ayant une formation en mécanique devraient-elles se tourner vers les microservices ?

Imaginez ceci : vous avez un projet de bras robotique à six degrés de liberté. Le servomoteur de chaque articulation doit recevoir des instructions de position en temps réel. Dans le même temps, le servo ajuste la force de serrage et le capteur visuel continue de renvoyer les données de coordonnées. L'approche traditionnelle consiste à regrouper toute la logique de contrôle dans un automate central. Le résultat ? Si un pilote de moteur est mis à jour, l'ensemble du système doit être re-débogué ; si un module tombe en panne, la ligne entière s'arrêtera.

N'est-ce pas comme utiliser une machine à vapeur pour alimenter toutes les machines textiles ? Inefficacité et risque concentré.

L’idée des microservices vient justement de cette pensée modulaire. Il divise le grand système en petits services indépendants, chaque service ne fait qu'une seule chose, comme traiter spécifiquement le contrôle de couple du servomoteur ou calculer spécifiquement le retour d'angle de l'appareil à gouverner. Ces services communiquent via des protocoles légers, comme des interfaces à bride standardisées dans les appareils mécaniques.

Un a participékpuissanceLes étudiants du cours d'architecture de microservices l'ont comparé ainsi : "Dans le passé, ajuster la chaîne de production, c'était comme construire un pont en arc de pierre. Si vous déplacez une pierre, le pont entier peut s'effondrer. Aujourd'hui, c'est comme construire un Lego. Si un module est défectueux, remplacez simplement le bloc de construction."

Démontage et remontage : de la logique mécanique à la logique numérique

La question est donc : comment réellement appliquer ce concept informatique aux projets mécaniques ?

Tout d’abord, identifiez les limites naturelles. Votre système de commande de servomoteur est lui-même candidat au service : il doit recevoir des commandes, exécuter des mouvements et fournir des informations sur l'état. Votre module de surveillance de la température en est un autre. Le capteur de vibrations en est un autre. Chacun a des entrées et des sorties claires, tout comme les dimensions de l'interface indiquées sur le dessin mécanique.

Deuxièmement, définissez le protocole de communication. Dans le domaine mécanique, nous avons l'habitude d'utiliser des signaux 4-20 mA ou des séquences d'impulsions. Dans les microservices, cela devient l'interface API. La clé est la standardisation, comme l'utilisation des mêmes spécifications de filetage pour tous les joints de cylindre.

Troisièmement, permettre une évolution indépendante. C'est la partie qui ressemble le plus à une philosophie de conception mécanique : lorsque vous mettez à niveau le module d'entraînement d'un moteur pas à pas vers un servomoteur, vous n'avez pas besoin de refaire toute la machine. De même, les microservices vous permettent de mettre à niveau un service individuellement sans avoir à redéployer l'ensemble du système.

kpuissanceIl y a un cas pratique dans le cours : après qu'une usine d'équipements d'automatisation a transformé son système de positionnement visuel d'une architecture monolithique à un microservice, le cycle de mise à jour a été raccourci d'une moyenne de deux semaines à deux jours. Parce qu'ils peuvent mettre à jour uniquement le service de traitement d'image tandis que d'autres services tels que le contrôle de mouvement, l'enregistrement des données, etc. continuent de fonctionner correctement.

Quand la pensée mécanique rencontre la pensée architecturale

Certains disent que les mécaniciens pensent de manière trop linéaire. Je pense que c'est un avantage - nous sommes habitués à penser au flux de force, au flux de signaux et aux chemins de transfert d'énergie. Cette façon de penser s’avère être une formation naturelle pour concevoir les limites des services.

L'architecture des microservices ne vous oblige pas à jeter la clé et à écrire du code, mais vous offre un nouveau langage de conception. Lorsque vous regardez ces servomoteurs et réseaux de capteurs, vous pouvez commencer à penser :

• Quels modules doivent avoir des « cycles de vie » indépendants ?
• Comment les données et les signaux de commande doivent-ils circuler aussi clairement que les conduites hydrauliques ?
• L’isolation des défauts doit-elle être conçue pour être aussi fiable qu’un dispositif de sécurité mécanique ?

Il y a quelque chose de mécaniquement beau dans ces problèmes en eux-mêmes.

Du dessin à la réalité : par où commencer ?

Si vous pensez que cela semble génial mais que vous ne savez pas par où commencer, voici comment commencer :

Commencez par dessiner un schéma fonctionnel d'un projet que vous avez sous la main - comme un schéma d'assemblage mécanique. Utilisez ensuite des stylos de différentes couleurs pour encercler les pièces qui peuvent théoriquement fonctionner de manière indépendante. Alors demandez-vous : si cette pièce doit être mise à niveau ou réparée, est-ce que je souhaite que les autres pièces soient le moins affectées ?

À l’heure actuelle, vous constaterez que certains modules sont intrinsèquement adaptés pour être « orientés service ».

kpuissanceLe cours d'architecture des microservices part de ce scénario réel. Il n'y a pas d'accumulation de théories vides de sens, mais tout comme le démontage d'une machine complexe, il vous apprend étape par étape à identifier les limites des services, à concevoir des mécanismes de communication et à traiter les données distribuées - le tout en utilisant des analogies de pensée familières avec les robots.

Un étudiant a partagé après le cours : « Avant, je pensais que l'architecture logicielle venait d'un autre monde. Mais maintenant, lorsque je concevrai un nouveau système de contrôle de ligne de convoyeur, je ferai naturellement de l'entraînement moteur, de la détection photoélectrique et du traitement des alarmes des services indépendants. L'efficacité du débogage a été améliorée et l'expansion est beaucoup plus facile.

Écrit dans : La nature des outils

De bons outils devraient inciter les gens à se concentrer davantage sur le problème lui-même plutôt que sur l’utilisation de l’outil. Qu'il s'agisse de l'encodeur du servomoteur ou de la passerelle API du microservice, le but de leur existence est de rendre le système plus clair, plus fiable et plus facile à maintenir.

Aujourd’hui, alors que les machines et l’automatisation deviennent de plus en plus intelligentes, les frontières entre matériel et logiciel s’estompent. Comprendre l'architecture des microservices ne vous oblige pas à changer de carrière et à devenir programmeur, mais vous donne plutôt un ensemble supplémentaire d'outils de réflexion - tout comme vous pouvez utiliser à la fois un tour et une imprimante 3D, tous deux pour concrétiser plus rapidement les bonnes idées.

Lorsque vous pouvez réexaminer ces servomoteurs et mécanismes de transmission familiers avec une réflexion orientée service, vous constaterez peut-être que les meilleures conceptions de système sont toujours celles avec des modules clairs, des interfaces standard, et que chaque pièce peut fonctionner de manière indépendante et élégante - que le système soit en acier ou construit avec du code.

Après tout, une bonne réflexion en ingénierie est toujours liée.

Créée en 2005, Kpower se consacre à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, dans la province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire, Kpower intè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. Kpower a 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.