Pourquoi votre projet de servomoteur rencontre-t-il toujours des problèmes sur le « moment » ?

Imaginez ceci : vous avez passé des semaines à assembler une seule partie d’un bras robotique. L'appareil est mis sous tension et vous appuyez sur le bouton de démarrage. En conséquence, le servo répond un demi-temps plus lentement ou ne bouge pas du tout. Pour aggraver les choses, l’ensemble du système de contrôle semblait être possédé par un mauvais esprit, perdant des signaux de temps en temps. Vous avez vérifié les lignes et le code et constaté que le problème ne venait pas du tout du matériel, mais des services en arrière-plan qui se « disputaient » les uns avec les autres.

Cela vous semble-t-il familier ?

De nombreuses personnes travaillant sur des projets de machines ou d’automatisation ont rencontré des problèmes similaires. Le matériel est clairement sélectionné, mais le système est instable. Le problème est souvent caché dans des endroits invisibles : si les services d’arrière-plan responsables du traitement des données, du contrôle des mouvements et de la coordination des communications ne sont pas conçus pour être suffisamment puissants, quelle que soit la qualité du moteur, il ne sera pas en mesure de faire son travail.

Comment créer des coulisses « sans querelles » ?

Dans le passé, les gens regroupaient toutes les fonctions dans un seul vaste programme. C'est comme mettre tous vos œufs dans un grand panier : secouez le panier et ils se briseront tous. L'idée la plus populaire aujourd'hui est celle des « microservices » : diviser différentes fonctions en petits modules indépendants, et chaque module se concentre uniquement sur une seule chose. Par exemple, un service lit uniquement les données des capteurs, un autre est responsable du calcul des trajectoires de mouvement et le troisième est responsable de l'envoi des instructions au servomoteur. Ils communiquent entre eux via une interface claire, afin que personne ne gêne l'autre.

L'avantage de faire cela ? flexible. Si vous souhaitez mettre à niveau une certaine fonction, comme rendre le mouvement du servo plus fluide, il vous suffit de modifier le petit service correspondant, sans avoir à réécrire l'ensemble du système. S'il y a un problème avec un certain service, toute la chaîne de production ne sera pas arrêtée.

Mais voici la question : comment pouvons-nous les faire collaborer efficacement avec autant de petits services ? Comment s’assurer qu’aucune donnée n’est perdue lors de leur communication ? Il y a aussi le déploiement, les tests, la surveillance... c'est écrasant rien que d'y penser.

Peut-être que vous avez besoin d'un ensemble d'outils qui « comprennent le langage machine »

Choisir un outil, c'est comme choisir une pièce : s'il ne convient pas, il ne conviendra pas. Dans le développement de microservices, le cadre et l'écologie sont très importants. Certains frameworks sont plus adaptés aux applications Web, mais sont un peu difficiles en ce qui concerne les exigences de contrôle en temps réel ; certains ne sont pas très conviviaux avec la communication matérielle.

kpuissanceAprès avoir été exposé à un grand nombre de projets de servomoteurs et de bras robotisés, j'ai découvert que ce qui manque à de nombreuses équipes, ce ne sont pas des idées, mais une base technique capable de soutenir fermement leur créativité. Nous avons donc accumulé notre expérience et développé un ensemble d'idées et de modèles pratiques pour la conception de microservices autour de .NET Core.

Il ne s’agit pas de magie, mais d’une traduction d’exigences communes dans le domaine du contrôle mécanique, telles que les performances en temps réel, la synchronisation de haute précision et la compatibilité matérielle, en principes de conception au niveau logiciel. Par exemple, la commande d’un servomoteur nécessite que les instructions arrivent à temps. S'il y a trop de retard, l'effet sera considérablement réduit. Conformément à la conception des microservices, il est nécessaire de prendre en compte la priorité de la file d'attente des messages, le réglage du délai d'attente des appels entre services et même la sélection des protocoles réseau.

Quelques problèmes pouvant survenir en pratique

Q : Sera-t-il plus compliqué de le diviser en microservices ? Au départ, je ne devais gérer qu’un seul programme, mais maintenant je dois en gérer plus d’une douzaine. En effet, avec davantage de services, les défis de déploiement et de surveillance deviendront plus grands. Mais l’avantage est que chaque service devient plus petit et plus facile à comprendre, tester et remplacer. Vous pouvez utiliser la technologie des conteneurs pour regrouper chaque service et utiliser des outils d'orchestration pour le gérer de manière uniforme. Il faudra peut-être un certain temps pour s'y habituer au début, mais à long terme, le système est plus contrôlable.

Question : L'architecture des microservices est-elle fiable pour le contrôle des données en temps réel ? La clé est la conception. Pour les pièces ayant des exigences en temps réel extrêmement élevées (telles que la boucle fermée de position en temps réel du moteur), elles peuvent être placées dans le même service pour éviter les retards du réseau. Pour les liaisons légèrement plus lentes (telles que la planification de chemin et la surveillance de l'état), elles sont divisées en services indépendants et communiquées via un mécanisme de message efficace. Traitement en couches pour plus de rapidité et de flexibilité.

Q : Comment garantir que les données ne sont pas gâchées lors du transfert entre différents services ? Des contrats clairement définis. L'interface que chaque service fournit avec le monde extérieur, le format de données qu'il accepte et la manière de réagir en cas d'erreur doivent être convenus à l'avance. Ajouter des mécanismes de vérification et de nouvelle tentative appropriés revient à ajouter des tampons et des vannes à un pipeline. Quel que soit le débit, il ne sera pas facilement dépassé.

Des parties au tout, étape par étape

Si vous envisagez de créer des microservices avec .NET Core, commencez petit. N'essayez pas de tout détruire dès le premier jour. Par exemple, séparez d'abord le module d'envoi d'instructions de contrôle manuel en un service et laissez-le communiquer avec le programme principal via l'API. Découvrez comment tracer les limites du fractionnement des services et comment concevoir la communication. Supprimez ensuite progressivement les fonctions telles que le contrôle de mouvement et la surveillance de l'état de l'équipement.

Au cours du processus, vous constaterez peut-être que certains services sont censés rester ensemble ; certains sont détendus après avoir été laissés seuls. Il n’y a pas de réponse standard, c’est comme assembler des machines : parfois il faut les resserrer, parfois il faut leur laisser un certain dégagement.

kpuissanceLors de divers projets mécaniques, j'ai découvert que les meilleures conceptions sont souvent issues de problèmes réels plutôt que copiées à partir de manuels. Par conséquent, au lieu de rechercher une architecture théoriquement parfaite, il est préférable de laisser d'abord le système fonctionner, puis d'observer quels liens ont tendance à rester bloqués et quels services sont souvent « malades » pendant le fonctionnement, puis de procéder à des ajustements ciblés.

Parlons de choses réelles. Les microservices ne sont pas une solution miracle. Ils résolvent d’anciens problèmes et apportent de nouveaux défis. Mais pour les systèmes de contrôle mécanique qui nécessitent des itérations fréquentes, des interfaces matérielles complexes et un fonctionnement à long terme, cela peut souvent apporter une plus grande flexibilité et une plus grande facilité de maintenance. Tout comme un bon appareil à gouverner doit non seulement être puissant, mais aussi réagir avec précision et résister à des mouvements répétés, il en va de même pour une bonne architecture logicielle, qui doit trouver un équilibre entre stabilité et flexibilité.

Si le projet en question est confronté à des difficultés d'expansion et de maintenance, vous voudrez peut-être vous demander s'il est temps de réorganiser les sièges des services cachés dans les coulisses.

Créé en 2005,kpuissancea été dédié à 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.