EtherCat est le nom d’une technologie de bus de terrain basée sur Ethernet. Soutenue par une organisation internationale baptisée EtherCat Technology Group, composée de plus de 140 sociétés membres utilisateurs et constructeurs, EtherCat est en cours de standardisation par l’IEC (International Electrotechnical Commission).
Au cours des dix dernières années, les technologies réseau de type « bus de terrain » se sont largement imposées dans le monde des automatismes industriels en tant qu’alternative au câblage traditionnel des entrées/sorties d’automates programmables. Ces technologies ont permis l’apparition de systèmes de contrôle-commande étendus. Mais avec l’amélioration constante des performances CPU des automates – et surtout des PC industriels – les bus de terrain deviennent de véritables goulets d’étranglement qui limitent finalement les performances des systèmes automatisés. Le fait que les architectures de contrôle soient souvent constituées d’un empilement de différents sous-systèmes hardware et software, généralement cycliques, constitue un facteur aggravant (cf figure 1) : les temps de réponse peuvent être entre trois et cinq fois supérieurs au temps de traitement effectif des automates !
Image scannée Temps de Réaction avec les systèmes traditionnels
Image scannée Temps de Réaction avec Ethercat
Un cran au-dessus des bus de terrain, c’est-à-dire pour l’interconnexion de plusieurs automates entre eux, Ethernet constitue depuis longtemps déjà un choix intéressant. La nouveauté est l’introduction d’Ethernet au niveau des entrées/sorties déportées et pour les systèmes de commande, domaines jusque là réservés aux bus de terrain traditionnels. Les principales conditions à remplir par un bus de communication pour être utilisable dans ce type d’applications sont de posséder des capacités temps-réel, l’aptitude à manipuler des paquets de données de tailles faibles, et un coût peu élevé.
Ethernet et le temps réel
De nombreuses propositions ont été faites pour améliorer les capacités temps-réel des réseaux Ethernet. Certaines solutions sont basées sur la désactivation du protocole d’accès au support CSMA/CD (responsable du non-déterminisme de la norme IEEE 802.3) et sur la mise en œuvre d’autres mécanismes permettant de faire circuler les données sur le réseau dans des tranches de temps prédéterminés (time slots).
D’autres solutions préconisent l’introduction de switches, permettant de segmenter les réseaux en domaines exempts de collision, et chargés de distribuer les paquets de données de façon très contrôlée et précise dans le temps. Mais si ces solutions s’avèrent efficaces pour le transfert des données, les temps de redirection vers les sorties ou vers les contrôleurs, ainsi que les temps de lecture des entrées dépendent en général fortement de l’implémentation.
Si les trames Ethernet sont utilisées de façon individuelle pour chacun des équipements, le taux de données utiles est en principe très faible. Les trames Ethernet les plus courtes comptent 84 octets (en comptant le délai inter-trame).
Image ComparisonBandwidth.jpg : Comparaison de l’utilisation de la bande passante
Si par exemple un contrôleur envoie cycliquement 4 octets de données et d’informations de statut, et reçoit 4 octets de commandes et de requêtes de contrôle, à 100% de charge réseau (c’est-à-dire avec des temps de réponse infiniment courts), le taux de données utiles sera de 4/84 = 4.7%. Avec un temps de réponse moyen de l’ordre de la dizaine de microsecondes, ce taux chute à 1.9%. Ces limitations touchent tous les systèmes utilisant des trames Ethernet dédiées pour chacun des équipements.
Principes de fonctionnement
La technologie EtherCat apporte des réponses à ces limitations. Avec elle, les paquets Ethernet ne sont désormais plus reçus, interprétés et stockés au niveau de chaque équipement. Les esclaves EtherCat lisent et écrivent les données durant le passage de la trame à l’intérieur du nœud. Et ils ne lisent que celles qui leur sont spécifiquement adressées. Les trames subissent ainsi des délais de l’ordre de quelques nanosecondes seulement.
Etant données que les trames Ethernet contiennent des données en provenance et en direction de nombreux équipements, le taux de données utiles peut grimper jusqu’à 90% ! Les capacités full-duplex du 100BaseTX peuvent ainsi être pleinement exploitées pour atteindre des débits effectifs supérieurs à 100Mbps (supérieurs à 90% de 2×100 Mbps).
Le protocole Ethernet tel que défini dans IEEE 802.3 reste intact jusqu’au niveau des terminaux individuels ; aucun sous-bus n’est nécessaire. Afin de satisfaire les spécifications des équipements terminaux électroniques, seule la couche physique doit être modifiée au niveau du coupleur : la paire torsadée ou la fibre optique doit être remplacée par une couche physique de type E-bus, qui délivre un signal LVDS (Low Voltage Differential Signal). Ce type de signal se prêtant par ailleurs bien à des transferts sur des distances courtes (jusqu’à 10m) sur paire torsadée ou sur fibre optique, le block terminal peut ainsi être étendu de façon relativement économique.
Le Protocole
Le protocole EtherCat est encapsulé dans les trames Ethernet grâce à un champ Ethertype spécifique. Celui-ci consiste en une série de sous-télégrammes, adressant des zones mémoire particulières de l’image logique du process, pouvant atteindre une taille de 4 GigaOctets. La séquence des données est indépendante de l’ordre dans lequel sont reliés physiquement les terminaux ; l’adressage peut ainsi être effectué dans n’importe quel ordre. Le transfert direct de trames Ethernet est utilisé dans les cas où de très hautes performances sont requises et lorsque les composants EtherCat opèrent à l’intérieur d’un même sous-réseau.
Quoi qu’il en soit, l’utilisation d’EtherCat n’est pas limitée aux sous-réseaux. EtherCat UDP permet d’encapsuler le protocole EtherCat à l’intérieur de datagrammes UDP/IP. La communication au travers de plusieurs sous-réseaux devient alors possible, par exemple par l’intermédiaire de routeurs. Dans cette configuration, les performances dépendent des capacités temps réel du réseau et de l’implémentation qui est faite d’Ethernet.
Image Structure.jpeg : Ethercat supporte aussi bien les architectures linéaires qu’arborescentes ou en étoile.
EtherCat supporte tout type de topologie : en ligne, arborescente ou en étoile. La structure en ligne bien connue des architectures de bus de terrain devient ainsi envisageable avec Ethernet. La combinaison de structures linéaires et de branches s’avère particulièrement pratique pour le câblage des installations : les interfaces nécessaires sont disponibles sur les coupleurs et aucun switch supplémentaire n’est requis. Néanmoins, il est toujours possible de mettre en œuvre une architecture Ethernet commutée classique.
Les câbles patch Ethernet standard peuvent transmettre les signaux au choix en mode Ethernet (100Base-TX) ou en mode E-bus. L’architecture Fast-Ethernet autorise une longueur de câble de 100 mètres entre deux éléments du réseau. Le câble E-bus est quant à lui prévu pour des distances allant jusqu’à 10 mètres.
Pour ce qui est de l’extension du réseau, il est possible de connecter jusqu’à 65535 éléments.
Horloges distribuées
La synchronisation précise des équipements s’avère très importante, notamment dans le cas de systèmes distribués, lorsque plusieurs entités distantes doivent agir de façon simultanée. La méthode de synchronisation la plus performante connue à ce jour pour les réseaux distribués consiste en un « alignement » des horloges du système, tel que décrit dans IEEE 1588 (voir à ce sujet notre article paru dans le numéro 39 de Jautomatise). Contrairement aux systèmes de communication dits « synchrones », pour lesquels la qualité de la synchronisation des équipements souffre en cas de défaut, les systèmes synchronisés avec la méthode d’alignement des horloges présentent une certaine tolérance vis-à-vis des délais engendrés par d’éventuelles erreurs de communication.
Avec EtherCat, l’échange des données repose sur un mécanisme purement hardware. Etant donné que la communication se base, à la fois logiquement et physiquement sur une structure en anneau, l’horloge maître peut déterminer les délais de propagation ainsi que l’offset des horloges esclaves de façon très simple et précise – et vice versa. Les horloges distribuées sont ajustées en fonction de ces valeurs. Il est ainsi possible d’atteindre une précision de synchronisme inférieure à une microseconde. La synchronisation externe au réseaux EtherCat, par exemple au travers d’une usine, est, quant à elle, basée sur le protocole IEEE 1558.
Image Photo2.jpeg
La synchronisation des horloges permet également d’obtenir des informations précises concernant les instants d’acquisition ou de transfert des données. Par exemple, pour calculer une vitesse, un contrôleur de mouvement se base généralement sur une série de mesures de position effectuées séquentiellement. Plus la fréquence d’échantillonnage est importante, plus les jitters ont un impact important sur la précision de la valeur de vitesse calculée. Grâce à la synchronisation des horloges, la même notion de temps est partagée par tous les équipements. Les données sont horodatées avec précision et la vitesse calculée ne dépend plus des jitters du système.
Quelques chiffres
Grâce à l’intégration hardware au niveau esclave et à un accès direct à la mémoire de la carte réseau du maître, le traitement complet du protocole est réalisé au niveau hardware. Il est par conséquent totalement indépendant des temps de traitement des piles protocolaires de niveaux supérieurs, ainsi que des performances CPU ou encore de l’implémentation software. EtherCat permet de balayer 1000 E/S digitales en 30 microsecondes, à la fois en lecture et en écriture, grâce au mode full duplex intégral. 200 valeurs analogiques nécessitent 50 microsecondes, tandis que 100 axes sont contrôlés en 100 microsecondes. Durant ce laps de temps, tous les axes reçoivent des valeurs de commande et de contrôle, et renvoient leur position ainsi que des informations concernant leur état de fonctionnement. La technique des horloges distribuées permet de synchroniser les axes avec une précision sensiblement inférieure à la microseconde.
Image StandardFrames.jpeg
L’expérience des bus de terrain montre clairement que la disponibilité des installations ainsi que les temps de recouvrement en cas de panne dépendent fortement des capacités de diagnostic des systèmes. Seuls les défauts détectés rapidement et précisément, puis localisés sans ambiguïté peuvent être corrigés dans les meilleurs délais. EtherCat possède des fonctionnalités permettant de reconnaître automatiquement la topologie du réseau et de vérifier la configuration des nœuds. Les erreurs de bit sont détectées de façon très fiable grâce à des contrôles de redondance cycliques (CRC). Le polynôme CRC à 32bits assure une distance de hamming de 4. Le protocole, la couche physique ainsi que la topologie du système EtherCat permettent outre la détection et la localisation des canaux défectueux, la supervision individuelle de chacun des segments. L’évaluation des compteurs d’erreurs associés permet la localisation des portions critiques du réseau. Les sources d’erreurs changeantes ou progressives telles que les interférences électromagnétiques (IEM), les connecteurs défectueux ou les câbles endommagés sont détectés et localisés, et ce, même lorsqu’ils ne remettent pas encore en cause les capacités de cicatrisation du réseau.
Image Photo1.jpeg
Avec la miniaturisation progressive des composants PC, la taille des PC industriels est de plus en plus déterminée par le nombre de slots utilisés. Grâce à la bande passante de Fast Ethernet, les interfaces habituellement situées dans les PC Industriels peuvent être transférées au niveau de terminaux EtherCat intelligents. Outre les entrées/sorties décentralisées, drives et unités de contrôle, d’autres systèmes plus complexes tels que des bus de terrain, passerelles et autres interfaces de communication peuvent être adressées.
Image BusTerrain.jpeg
Même d’autres équipements Ethernet (sans restriction sur les variantes du protocole) peuvent être connectés via des terminaux hub décentralisés. Le PC Industriel central devient ainsi plus petit et par conséquent plus économique. Une seule interface Ethernet est suffisante pour communiquer avec l’ensemble des périphériques. (cf figure 8)
Profils et ouverture
Image scannée ArchitectureEtherCat
Le profil d’un équipement décrit les paramètres de l’application ainsi que le comportement fonctionnel de l’équipement, incluant la machine d’état caractéristique de la classe à laquelle il appartient. Pour de nombreuses classes, les technologies de bus de terrain fournissent déjà des profils largement utilisés, par exemple p
ur les entrées/sorties, les systèmes d’entraînement ou encore les valves. Les utilisateurs se sont familiarisés avec ces profils, et connaissent bien les paramètres ainsi que les outils associés. C’est la raison pour laquelle aucun profil EtherCat n’a été développé pour ces classes d’équipements. A la place, de simples interfaces pour les profils existants sont proposées, de quoi faciliter la tâche des utilisateurs et des constructeurs lors des migrations des bus de terrain existants vers EtherCat.
EtherCat et CanOpen
Des profils matériels et applicatifs CanOpen existent déjà pour les équipements, allant des modules d’entrées/sorties, systèmes d’entraînement, encodeurs, valves proportionnelles, jusqu’aux profils d’applications pour le traitement plastique ou les machines textiles par exemple. EtherCat peut fournir les mêmes mécanismes de communication que CanOpen : dictionnaire d’objet (Object Dictionary), PDO (Process Data Objects) et SDO (Service Data Objects). EtherCat peut ainsi être implémenté avec un minimum d’efforts sur des équipements CanOpen. Une grande partie des firmware CanOpen peuvent être réutilisés.
Servo-entraînement avec EtherCat
L’interface Sercos est reconnue en tant qu’interface de communication temps-réel hautes performances, particulièrement dans des applications de contrôle de mouvement. Les profils Sercos pour servo-entraînements ainsi que la technologie de communication sont couverts par le standard IEC 61491. Ces profils peuvent très facilement être mappés sur EtherCat. Le canal de service, et par conséquent l’ensemble des paramètres et fonctions du système d’entraînement dépendent de la mailbox EtherCat (voir figure 9). Ici aussi, une attention particulière a été portée sur la compatibilité avec les protocoles existants. Les données de process, sous forme de données AT (Amplifier Telegram) et MDT (Master Data Telegram), sont transférées par le biais des mécanismes EtherCat du contrôleur esclave. Le mapping est similaire à celui de Sercos. La machine d’état esclave d’EtherCat peut également être mappée sur les phases du protocole Sercos.
La technologie Ethernet temps réel est par conséquent disponible pour ce type de profil matériel, répandu dans les applications CNC. En option, il est également possible de transférer la commande de position, de vitesse ou de couple. En fonction de l’implémentation, il est même possible de continuer à utiliser les mêmes outils de configuration des systèmes d’entraînement.
EtherCat et Ethernet
La technologie EtherCat n’est pas seulement compatible avec Ethernet, elle est également ouverte : le protocole tolère sur le même support physique les autres services et protocoles basés sur Ethernet. Il n’existe aucune restriction concernant le type d’équipement Ethernet pouvant être connecté par le biais d’un port switch à l’intérieur d’un segment EtherCat. Le réseau EtherCat est transparent pour l’équipement Ethernet, et les caractéristiques temps-réel ne sont pas affectées.
Image ProtoEthernet.jpeg : Les équipements EtherCat peuvent se comporter comme des éléments Ethernet standard
Les équipements EtherCat peuvent par ailleurs se comporter comme des éléments Ethernet standard. Le maître agit comme un switch de niveau 2 qui redirige les trames vers les équipements correspondants. Toutes les technologies Ethernet peuvent par conséquent être utilisées dans l’environnement EtherCat : serveur web intégré, e-mail, transferts FTP, etc.
L’accès aux données
Un protocole similaire à TFTP permet d’accéder à n’importe quelle structure de données au niveau de l’équipement. Le chargement de firmware standardisés est par conséquent possible, sans tenir compte du fait que l’équipement supporte ou non TCP/IP.
Implémentation
EtherCat utilise des contrôleurs Ethernet standard là où des économies peuvent être réalisées, c’est-à-dire au niveau du contrôleur maître. Etant donné qu’une seule trame Ethernet doit être envoyée par cycle, aucun coprocesseur n’est nécessaire pour la communication. Cette caractéristique fait d’EtherCat une solution Ethernet temps réel ne nécessitant pas l’ajout d’un plug-in au niveau du contrôleur maître. Le contrôleur Ethernet embarqué ou une simple carte NIC sont suffisants. Le maître est en général implémenté de façon purement logicielle.
L’implémentation d’un maître EtherCat reste simple, surtout dans le cas d’applications petites ou moyennes parfaitement définies. Par exemple pour un API avec une seule image process : si celle-ci ne dépasse pas 1488 octets, l’envoi cyclique d’une seule trame Ethernet avec le temps de cycle de l’API est suffisant. Etant donné que le Header ne change pas, il suffit d’ajouter un Header constant à l’image du process et transférer le résultat au contrôleur Ethernet (cf figure 11).
Image MasterImplementation.jpeg
Des contrôleurs EtherCat de type ASIC ou FPGA sont utilisés au niveau des équipements esclaves. Ils sont d’ores et déjà disponibles ou en cours de préparation chez un certain nombre de constructeurs. Par exemple, les contrôleurs esclaves développés par Beckhoff possèdent une DPRAM interne et offrent une série d’interfaces permettant d’accéder à la mémoire de l’application. L’interface série SPI (Serial Peripheral Interface) est destinée aux équipements manipulant de faibles quantités de données de process, tels que les modules d’entrées/sorties analogiques, les capteurs, les encodeurs ou les drives simples. L’interface d’entrées/sorties parallèles 32 bits peut-être utilisée pour connecter jusqu’à 32 entrées/sorties digitales, ou pour de simples capteurs ou actionneurs manipulant des données 32 bits. L’interface microcontrôleur 8/16 bits parallèle est souhaitable quant à elle dans le cas d’équipements plus complexes manipulant de plus grandes quantités de données.
Christian Groeppelin
Article réalisé sur la base du document « EtherCat, Technical Introduction and Overview », publié par l’ETG (EtherCat Technology Group) en octobre 2004.
