Contrôleurs de moteur à communication Ethernet : protocoles, intégration et sélection

Pourquoi Ethernet a remplacé l'ancien bus de terrain dans le contrôle moteur

Pendant deux décennies, les protocoles basés sur RS-485 tels que Modbus RTU et CANopen ont dominé la communication de commande de moteur. Ils étaient fiables, déterministes et peu coûteux à mettre en œuvre. Ils étaient également lents, limités en topologie et de plus en plus incompatibles avec les exigences en matière de données des lignes de production automatisées modernes. Le passage à l’Ethernet industriel n’a pas été motivé par la mode, mais par les mathématiques.

Les systèmes de bus de terrain existants fonctionnent généralement entre 1 et 12 Mbit/s avec des topologies de réseau qui se limitent à quelques dizaines de nœuds avant que les performances ne se dégradent. Les protocoles Ethernet industriel fonctionnent entre 100 Mbit/s et 1 Gbit/s, prennent en charge des centaines de nœuds sur un seul segment de réseau et offrent les temps de cycle inférieurs à la milliseconde requis par la coordination des mouvements multi-axes. Selon le rapport sur les parts de marché des réseaux industriels 2025 de HMS Networks, 79 % des nouveaux nœuds d'automatisation industrielle sont désormais livrés avec un protocole Ethernet industriel plutôt qu'un bus de terrain traditionnel, un chiffre qui aurait semblé invraisemblable il y a dix ans.

Pour les concepteurs de contrôleurs de moteur et les intégrateurs de systèmes, cette transition a une conséquence pratique directe : l'interface de communication n'est plus une spécification secondaire. Il détermine ce que le contrôleur peut faire dans un système d'entraînement coordonné, comment il s'intègre aux automates et aux IHM, et s'il peut participer aux pipelines de données IIoT sans passerelle intermédiaire. Contrôleurs de moteurs CC sans balais pour applications industrielles B2B de plus en plus d'interfaces Ethernet sont proposées en standard plutôt qu'en option, ce qui reflète la profondeur avec laquelle le changement de protocole a pénétré le marché des disques.

Principaux protocoles Ethernet industriels pour les contrôleurs de moteur

Quatre protocoles représentent la grande majorité des installations de commande de moteurs connectées via Ethernet dans le monde. Chacun adopte une approche architecturale différente pour relever le même défi principal : transmettre des données de contrôle de manière fiable et prévisible via du matériel Ethernet standard.

EtherCAT (Ethernet pour la technologie d'automatisation de contrôle) a été développé par Beckhoff Automation et est devenu une norme CEI en 2005. Son innovation déterminante est le « traitement à la volée » : au lieu que chaque nœud reçoive un paquet dédié, une seule trame EtherCAT circule à travers tous les nœuds esclaves en séquence, chaque nœud lisant ses propres données et insérant des données de réponse au fur et à mesure du passage de la trame. Cela élimine la surcharge liée à la commutation de paquets et offre des temps de cycle inférieurs à 100 microsecondes avec une gigue inférieure à 1 microseconde, des performances qui rendent la synchronisation de dizaines d'axes d'asservissement réellement réalisable. Le Documentation technique officielle d'EtherCAT Technology Group détaille comment le protocole atteint la conformité CEI 61158 tout en prenant en charge les topologies en ligne, en arbre, en étoile et en anneau sans commutateurs gérés.

PROFINET , régi par PROFIBUS & PROFINET International (PI), est le successeur direct de Profibus et domine les marchés industriels européens. Il fonctionne selon deux modes : PROFINETRT (Real Time) avec des temps de cycle de 1 à 10 millisecondes pour les applications d'E/S standard, et IRT PROFINET (Isochronous Real Time) avec des temps de cycle aussi faibles que 250 microsecondes pour un contrôle de mouvement précis. Un avantage clé pour les projets de mise à niveau est la prise en charge native du proxy Profibus : les appareils Profibus existants peuvent communiquer sur un réseau PROFINET via des proxys de passerelle, permettant une migration progressive sans remplacer l'équipement installé.

EtherNet/IP , maintenu par l'ODVA et construit sur le protocole industriel commun (CIP) superposé aux standards TCP/IP et UDP/IP, est le protocole dominant dans la fabrication discrète en Amérique du Nord. Fonctionnant sur une infrastructure informatique conventionnelle sans commutateurs spécialisés, il offre une intégration simple dans les réseaux d'usine existants et prend en charge un large écosystème d'automates, de lecteurs et de modules d'E/S de plusieurs fournisseurs. Des temps de cycle typiques de 2 à 10 millisecondes conviennent à la plupart des applications d'E/S discrètes et de variateurs à vitesse modérée ; une synchronisation plus étroite est disponible via l'extension CIPsync.

Modbus-TCP est l'option la plus simple et la plus largement prise en charge : une traduction directe du modèle de registre Modbus RTU classique sur TCP/IP. Il n'offre aucune garantie native en temps réel, ce qui le disqualifie des rôles exigeants de contrôle de mouvement, mais sa prise en charge universelle des appareils et son coût de licence nul en font un choix pratique pour les couches de surveillance, de configuration et d'enregistrement de données où le déterminisme n'est pas requis.

Comparaison des protocoles : temps de cycle, topologie et compatibilité

La sélection parmi ces protocoles nécessite de faire correspondre les caractéristiques du protocole aux exigences de l'application, sans choisir par défaut celui qui vous est le plus familier. Le tableau ci-dessous résume les principaux différenciateurs entre les quatre principales options :

Une tendance ressort des données : l'avantage en termes de temps de cycle d'EtherCAT n'est pas marginal : il est d'un ordre de grandeur plus rapide que celui d'EtherNet/IP dans des conditions équivalentes. Pour les applications nécessitant une synchronisation étroite sur plusieurs axes moteurs, telles que les machines-outils CNC, les bras robotisés ou les systèmes de convoyeurs coordonnés, cet écart se traduit directement par la précision du positionnement. Pour les entraînements mono-axe dans les équipements de processus standard, la différence compte rarement dans la pratique, et la familiarité et la compatibilité de l'infrastructure avec EtherNet/IP ou PROFINET RT l'emportent souvent sur la vitesse brute.

La topologie du réseau a également un poids pratique. L'architecture en guirlande d'EtherCAT élimine le besoin de commutateurs gérés, réduisant ainsi à la fois l'espace dans l'armoire et les coûts dans les systèmes comportant de nombreux nœuds de disques distribués. L'exigence de PROFINET IRT en matière de commutateurs capables de synchroniser augmente les coûts d'infrastructure mais permet la synchronisation d'horloge sur des nœuds géographiquement répartis que la topologie linéaire d'EtherCAT ne peut pas facilement prendre en charge.

Intégration de la communication Ethernet dans les contrôleurs de moteur BLDC

L'ajout d'une interface Ethernet à un contrôleur de moteur CC sans balais implique des décisions à trois niveaux : le matériel physique, le micrologiciel de la pile de communication et la mise en œuvre du profil de lecteur au niveau de l'application.

Au niveau matériel, l'intégration EtherCAT repose généralement sur des ASIC de contrôleur esclave dédiés, tels que les familles ET1100 ou ESC10, qui gèrent le traitement des trames indépendamment du MCU principal. C'est ce déchargement qui permet des temps de cycle inférieurs à 100 microsecondes : le traitement Ethernet n'entre jamais en compétition pour les cycles du processeur avec la boucle de contrôle du moteur. Les implémentations PROFINET et EtherNet/IP utilisent plus couramment des modules RAM à double port ou des implémentations soft-core sur FPGA, qui offrent une plus grande flexibilité mais nécessitent une gestion plus minutieuse de la latence dans l'architecture du micrologiciel.

Au niveau du micrologiciel, le profil du variateur définit la façon dont les commandes de contrôle du moteur sont mappées sur le protocole réseau. Le profil de variateur CiA 402, initialement développé pour CANopen, est devenu la norme de couche application dominante pour les variateurs de moteur dans les implémentations EtherCAT (via CoE, CANopen sur EtherCAT), PROFINET et EtherNet/IP. Il définit des machines à états pour l'activation/la désactivation du variateur, les modes de fonctionnement (position, vitesse, couple) et la gestion des défauts d'une manière indépendante du fournisseur, ce qui simplifie la programmation des automates pour toutes les marques de contrôleurs. Les contrôleurs implémentant correctement CiA 402 peuvent généralement être mis en service avec n'importe quel automate conforme à la norme CEI 61131-3 sans blocs de fonction personnalisés.

Pour les systèmes multi-axes coordonnés, la synchronisation d'horloge distribuée est la fonctionnalité critique du micrologiciel. Le mécanisme d'horloges distribuées d'EtherCAT synchronise tous les nœuds esclaves à 1 microseconde les uns des autres, une condition préalable à l'engrenage électronique, au profilage de cames et à d'autres fonctions de mouvement synchronisées. La mise en œuvre correcte de cela nécessite une attention particulière à la compensation du délai de propagation et à la correction de la dérive d'horloge dans le micrologiciel esclave. Contrôleurs de moteur hautes performances de la série T intègrent l'architecture de traitement nécessaire pour maintenir des taux de mise à jour serrés de la boucle de courant ainsi que la gestion des communications réseau, un équilibre que les conceptions de contrôleurs d'entrée de gamme compromettent souvent.

Au-delà des simples variateurs de vitesse, l'intégration de la communication au niveau du système s'étend aux unités de supervision. Unités de commande de véhicule avec communication réseau intégrée regrouper les données de variateur de plusieurs contrôleurs de moteur, gérer les machines d'état au niveau du système et fournir la passerelle Ethernet en amont pour la télématique et les diagnostics à distance, une fonction qui devient de plus en plus importante à mesure que les flottes et les équipements industriels évoluent vers des modèles de maintenance prédictive. Pour les applications de véhicules électriques et de vélos électriques plus légers, contrôleurs de moteurs de vélos électriques et de véhicules électriques légers intègrent de plus en plus les interfaces Bluetooth et CAN comme couche de communication, servant de pont entre les interfaces utilisateur simplifiées et la boucle de commande moteur sous-jacente.

Sélection du bon protocole pour votre application de commande de moteur

La sélection du protocole se résume rarement à un seul facteur. Six questions couvrent l'espace de décision pratique pour la plupart des conceptions de systèmes de commande de moteur :

1. Quel temps de cycle l’application de mouvement nécessite-t-elle ? La coordination d'asservissement multi-axes nécessite généralement des temps de cycle inférieurs à 1 milliseconde, ce qui pointe vers EtherCAT ou PROFINET IRT. Les variateurs de vitesse mono-axe des équipements de processus fonctionnent généralement confortablement à des taux de mise à jour de 5 à 10 millisecondes, là où EtherNet/IP ou PROFINET RT fonctionnent de manière adéquate.
2. Quel API ou contrôleur de mouvement est déjà présent dans le système ? C’est souvent le facteur décisif. Les contrôleurs Siemens S7 privilégient PROFINET ; Les systèmes Rockwell/Allen-Bradley sont construits autour d'EtherNet/IP ; Les plates-formes de mouvement Beckhoff et Omron se normalisent sur EtherCAT. Le franchissement des frontières du protocole est possible via les passerelles, mais cela ajoute une latence et une complexité qui érodent les avantages en termes de performances du protocole natif.
3. Combien d’axes d’entraînement le réseau prendra-t-il en charge ? La limite théorique de nœuds d'EtherCAT de 65 535 appareils sur un seul réseau dépasse de loin toute installation réaliste, mais sa topologie en guirlande signifie que l'ajout de nœuds allonge légèrement le temps de parcours des trames. Pour les très grandes installations comportant des centaines de points d'E/S distribuées, la topologie en étoile basée sur un commutateur PROFINET peut offrir une disposition physique plus flexible.
4. La sécurité fonctionnelle est-elle requise au niveau de la couche réseau ? EtherCAT (via FSoE, Functional Safety over EtherCAT) et PROFINET (via PROFIsafe) prennent en charge la communication de sécurité conforme à la norme CEI 61508 sur la même infrastructure de câbles que les données de processus standard. EtherNet/IP prend en charge CIP Safety pour des applications équivalentes. Si des fonctions d'arrêt sécurisé du couple ou de vitesse sûre SIL 2 ou SIL 3 sont requises, confirmez que le micrologiciel de sécurité du contrôleur de moteur est certifié pour l'extension de sécurité du protocole choisi.
5. Quelles sont les contraintes d’infrastructure et de maintenance ? L'élimination des commutateurs gérés par EtherCAT simplifie la conception des armoires et réduit les points de défaillance. PROFINET et EtherNet/IP exploitent une infrastructure de commutation informatique standard pour laquelle les équipes de maintenance des usines peuvent déjà gérer et stocker des pièces de rechange : un avantage pratique dans les installations ne disposant pas d'une expertise dédiée en matière de réseau d'automatisation.
6. Comment le contrôleur s'associe-t-il au moteur cible ? Le protocole de communication et l'adaptation du moteur sont interdépendants : un contrôleur optimisé pour la communication réseau à large bande passante doit également maintenir le taux de mise à jour de la boucle de courant requis par la constante de temps électrique du moteur. Révision Contrôleur de moteur et conseils d'appairage de moteur avant de s'engager dans une combinaison contrôleur-protocole, on s'assure que la spécification de l'interface réseau ne dépasse pas les performances sous-jacentes du variateur que le moteur peut réellement utiliser.

L'essentiel pour les équipes d'approvisionnement et d'ingénierie : le protocole correct est celui qui correspond à l'écosystème API, répond aux exigences de temps de cycle de mouvement et s'adapte à la topologie d'installation, dans cet ordre. L'optimisation de la vitesse brute du protocole dans une application qui n'en a pas besoin ajoute des coûts sans avantage. Une sous-spécification pour une application nécessitant une synchronisation déterministe crée des problèmes de fiabilité qu'aucun réglage ne pourra complètement corriger.