Quand les servomoteurs rencontrent les microservices : une conversation architecturale détendue

Avez-vous rencontré quelque chose de similaire ? Un moteur est fiable, mais lorsqu'il fonctionne avec des dizaines d'autres appareils, le système devient imprévisible ? Au lieu de parler aujourd’hui de théorie avancée, parlons de la manière de repenser l’organisation du système de contrôle comme des éléments de base.

Le problème est caché dans les détails

Imaginez que vous êtes responsable d'une chaîne de montage. Six servomoteurs sont responsables du positionnement précis, trois servos complètent le réglage fin de l'angle et le bras robotique transporte les pièces à un rythme fixe. Initialement, toute la logique de contrôle était écrite dans un contrôleur central - c'est très courant, comme si l'on entassait tous les meubles dans une pièce. Cela semble soigné au début, mais à mesure que les besoins évoluent, vous devez fouiller dans les cases à chaque fois que vous vous ajustez.

Un jour, la vitesse de la section d'emballage doit être temporairement augmentée de 20 %, mais vous constatez que l'ajustement d'un paramètre affectera en réalité la précision du positionnement en amont. Ou, lorsqu'une donnée donnée du capteur est anormale, l'ensemble du journal du système devient un désordre et il est difficile de retracer la source du problème. Le plus souvent, lorsque l'on souhaite changer un des modèles de moteur, il faut réécrire une grande partie du code associé.

Ce ne sont pas des « problèmes », mais l’architecture murmure qu’il est temps d’organiser votre système différemment.

Microservices : donnez à chaque fonction une salle séparée

Nous pouvons changer notre façon de penser : et si la logique de contrôle de chaque moteur pouvait fonctionner indépendamment ? Par exemple:

• Le servomoteur de positionnement décide lui-même comment répondre à la commande cible et indique uniquement au système « Je suis en position » via une interface claire.
• L'unité de détection de pression se concentre sur l'analyse des données du capteur et émet des rappels dans un format standard lorsque des anomalies se produisent.
• Le module de planification de mouvement se concentre sur le calcul du chemin optimal et n'est pas affecté par les modifications de code dans les autres modules.

Cette approche porte un nom, appelé architecture de microservices. Ne vous laissez pas intimider par la terminologie, son essence est simple : décomposer un grand système en un ensemble de petits services qui peuvent être développés, déployés et étendus indépendamment. Tout comme les briques Lego, chaque pièce a une fonction claire, mais la méthode d'assemblage peut être ajustée de manière flexible.

On peut se demander : « Est-ce que cela ajoute de la complexité ? Bonne question. À court terme, vous devez concevoir certaines normes de communication entre les services (comme des formats de données clairement définis), mais à long terme, cela réduit le couplage involontaire du système. Lorsqu'un module nécessite une mise à niveau, vous n'avez pas besoin d'arrêter toute la chaîne de production pour tester toutes les fonctionnalités.

Pourquoi cette idée est-elle adaptée aux scénarios de contrôle matériel ?

Les servomoteurs et les systèmes mécaniques ont une particularité : ils ont tendance à fonctionner longtemps. La chaîne de production peut continuer à fonctionner pendant cinq ou dix ans, au cours desquels d'innombrables remplacements partiels et de composants ainsi que de nouvelles fonctions seront effectués. L’architecture monolithique traditionnelle est comme une immense peinture à l’huile, et modifier n’importe quel détail peut nécessiter de redessiner la toile entière.

L'architecture des microservices est comme un ensemble de carnets de croquis, chaque feuille enregistrant des fonctions spécifiques. Vous souhaitez modifier la logique de préhension du bras robotique ? Il vous suffit de mettre à jour cette partie du service et de vous assurer qu'elle communique normalement avec les autres modules tandis que l'interface reste inchangée.

kpuissanceLorsqu’on accompagne les clients dans la mise en œuvre de ce type d’architecture, nous constatons souvent plusieurs changements intéressants :

• Le temps de dépannage est réduit de 40 % en moyenne car les journaux sont naturellement séparés par service
• Le cycle d'itération du matériel est devenu plus flexible et le changement de modèle de moteur ne nécessite souvent que l'ajustement des services correspondants.
• Le coût de test de nouvelles fonctionnalités est réduit et des modules spécifiques peuvent être testés dans un environnement isolé sans affecter l'ensemble de la gamme.

Trois étapes du concept à la pratique

Si vous trouvez cette architecture intéressante, vous pouvez l’essayer en trois étapes :

Étape 1 : Tracez les limites fonctionnelles. Sortez un morceau de papier et divisez votre système de contrôle en fonction des fonctions physiques. Quelles pièces sont étroitement couplées (telles que le traitement du variateur et du feedback du même moteur) ? Quelles pièces n'échangent des données qu'occasionnellement (par ex. mécanisme d'alimentation et unité de contrôle qualité) ? Les limites physiques naturelles constituent souvent un bon point de départ pour le partitionnement des microservices.

Étape 2 : Définir les règles de dialogue Les services doivent communiquer, tout comme les ouvriers sur une chaîne de production doivent remettre des produits semi-finis. Convenez du format des données : par exemple, toutes les informations de localisation incluent l'horodatage, l'unité et le niveau de confiance ; toutes les instructions ont des numéros uniques pour un suivi facile. Il n’est pas nécessaire que ces règles soient parfaites dès le départ, mais des conventions claires peuvent éviter toute confusion par la suite.

Étape 3 : Refactoriser à partir de zéro Il n'est pas nécessaire de réécrire l'intégralité du système en une seule fois. Choisissez un module qui a besoin d'être amélioré récemment (comme ce servomoteur de la section d'emballage qui vous donne mal à la tête) et transformez-le d'abord en un service indépendant. Après avoir vérifié que le fonctionnement est stable, développez-le progressivement. Ce changement progressif est plus favorable au fonctionnement continu de la chaîne de production.

Parfois la réponse se situe en dehors de la question

Je pense souvent à l’ami dont j’ai parlé au début. Lorsqu'il a commencé à réorganiser une partie de la logique de contrôle à l'aide d'idées de microservices, il a non seulement résolu le problème des délais de réponse, mais a également découvert de manière inattendue que son équipe commençait à diviser le travail plus naturellement. Les ingénieurs responsables de la structure mécanique se concentrent sur les services de planification de mouvement, et les ingénieurs électriciens sont profondément impliqués dans les modules de commande d'entraînement. Les deux collaborent via des interfaces clairement définies, plutôt que de s'annoter mutuellement dans le même fichier de code.

C’est peut-être un autre don de l’architecture : elle organise non seulement le code, mais aussi la manière dont les gens collaborent. Lorsque chaque module fonctionnel a des limites claires de responsabilités, la maintenance et la réparation deviennent des choses qui peuvent être promues en parallèle.

Bien entendu, aucune architecture n’est une solution miracle. Les microservices apporteront des considérations de communication réseau entre les services et nécessiteront une conception de surveillance plus détaillée. Mais pour les systèmes de contrôle matériel qui nécessitent une évolution à long terme et une localisation fréquente, cette philosophie « diviser pour régner » peut souvent apporter une facilité inattendue.

En fin de compte, l’architecture technique est comme l’aménagement d’une pièce. Certaines personnes aiment tout mettre dans un espace ouvert, clair au premier coup d'œil mais difficile à ajuster localement ; certains préfèrent attribuer à chaque fonction une pièce séparée, ce qui nécessite quelques étapes supplémentaires dans un premier temps, mais chaque espace peut être rénové à son rythme.

À quel type de pièce votre système ressemble-t-il actuellement ?

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. 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.