Dans la tourmente de la guerre des bus de terrain, plusieurs solutions basées sur Ethernet ont émergé. Le but de ce dossier est de présenter les solutions existantes, de mettre en lumière les différences, mais aussi d’expliquer leurs spécificités.
Tout le monde se souvient de la fin de l’année 1999. De la tempête, bien sûr, du passage à l’an 2000, mais aussi de ce jour pathétique où le projet de normalisation des technologies de bus de terrain s’était conclu sur l’adoption d’un prétendu standard, l’IEC 61158, légitimant l’existence de pas moins de huit protocoles différents et parfaitement incompatibles entre eux pour la communication de terrain. Parmi les grands gagnants de cette débâcle figurent les principaux offreurs de solutions d’automatismes qui trouvèrent là un bon moyen de préserver leurs parts de marché respectives, au grand damne des utilisateurs.
Aujourd’hui, avec Ethernet, l’histoire se répète. Ou plutôt, elle se poursuit. Dans la tourmente de la guerre des bus de terrain, plusieurs solutions basées sur Ethernet et TCP/UDP/IP avaient déjà réussi à se hisser au rang de « standard », en figurant dans l’IEC 61158. Ce fut notamment le cas des technologies High Speed Ethernet (HSE), développée par Foundation FieldBus, Ethernet/IP, soutenue par l’ODVA et Profinet, supportée par Profibus International. Depuis, les technologies ont évolué, et pour répondre aux besoins des applications les plus exigeantes, de nouvelles solutions ont émergé. Elles ont pour nom Profinet IRT, Ethercat, Ethernet Powerlink ou encore Sercos III. Le but de cet article est de vous présenter les principales solutions existantes, de mettre en lumière les différences existantes entre elles, mais aussi d’expliquer leurs spécificités.
Pourquoi Ethernet ?
Commençons par le commencement. Pourquoi Ethernet ? La motivation initiale fut à l’évidence économique. En effet, la popularité déjà établie d’Ethernet dans le milieu de la bureautique, à l’époque où s’ébauchait à peine la volonté industrielle d’intégrer les couches hautes et basses des réseaux d’entreprises, a tout naturellement orienté le choix du marché vers Ethernet pour la communication industrielle. La « descente » d’Ethernet s’est ainsi effectué sans problème jusqu’au niveau 2 de la pyramide de CIM, à savoir la couche contrôle. Ainsi, depuis de nombreuses années déjà, Ethernet fait figure de solution intéressante pour l’interconnexion de contrôleurs et de sous-réseaux de terrain entre eux.
Parallèlement à cela, l’amélioration constante des performances CPU des automates, et surtout des PC industriels, ont été telles que finalement les performances des bus de terrain traditionnels, notamment en termes de vitesses de transferts, se sont vite avérées limitées en raison notamment d’un nombre croissant d’informations que les utilisateurs souhaitaient véhiculer. Ethernet, avec les vitesses de transfert extrêmement rapides qu’il permettait d’envisager, combinées aux avantages économiques liées au fait de mettre en œuvre un standard aussi répandu, constituait une alternative intéressante aux bus de terrain traditionnels.
Figure1.jpg
Seulement voilà : pour être utilisable dans des applications du type entrées-sorties déportées, ou pour des systèmes de commande (domaines jusque là réservés aux bus de terrain traditionnels), un certain nombre de conditions sont à remplir. Outre celles de présenter des vitesses de transfert élevées et un coût avantageux, parmi les principales, on pourra citer : le déterminisme, qui va garantir qu’une action sera réalisée dans un laps de temps déterminé, mais également la capacité à manipuler des paquets de données de faibles tailles, ou encore la capacité à synchroniser avec précision l’ensemble des horloges du système. A cela s’ajoutent la capacité à résister à des contraintes environnementales sévères, l’adaptabilité à la topologie des ateliers de production, et enfin la capacité à garantir un niveau de sécurité élevé.
Or une chose est certaine : tel que défini dans IEEE 802.3, Ethernet ne répondait à aucune de ces exigences. De nouvelles solutions ont donc du être imaginées pour permettre à Ethernet de se frayer un chemin vers les ateliers de production. C’est ce qu’ont fait les principaux offreurs de solutions d’automatismes, chacun y allant de sa petite cuisine.
Dans l’état actuel des développements, deux types de solutions peuvent être distinguées: les solutions dites « encapsulées », d’une part, qui visent à faire remonter des trames issues des équipements de terrain connectés aux bus traditionnels, au travers d’une connexion Ethernet TCP/UDP/IP, et les solutions dites « temps réel », d’autre part, modifiées pour répondre aux exigences des systèmes de commandes et d’entrées-sorties déportées.
Les Solutions « Encapsulées »
Dans le cas des solutions encapsulées, les couches applications sont les mêmes que celles utilisées par les bus de terrain sous-jacents, à quelques extensions près pour permettre le transport des trames au travers d’une liaison Ethernet TCP/UDP/IP. Typiquement ces solutions permettent l’interconnexion de plusieurs sous-réseaux de terrain par l’intermédiaire de contrôleurs reliés entre eux par une liaison Ethernet standard. Ainsi, il est possible de récupérer au niveau des contrôleurs, mais également au niveau des IHM et autres outils de supervision et de contrôle, un grand nombre d’informations concernant la configuration, le fonctionnement et le diagnostic des équipements connectés aux bus de terrain. Typiquement, de telles solutions sont capables de répondre aux besoins d’applications ne nécessitant pas des temps de cycles inférieurs à la centaine de millisecondes. Autrement dit, elles permettent de répondre aux besoins d’applications de monitoring, de même qu’aux besoins de la plupart des applications d’automatisation de process actuelles. Notons que la mise en œuvre de mécanismes de niveau applicatif peut permettre d’améliorer les performances, rendant alors certaines de ces solutions capables de répondre aux exigences d’applications nécessitant des temps de cycle inférieurs à la dizaine de millisecondes. C’est typiquement le cas des systèmes de contrôle de machines-outils.
Figure2.jpg : Architecture de communication Modbus TCP/IP
Modbus TCP/IP
Modbus TCP est le nom de la variante « encapsulée » dans TCP/IP du célèbre protocole Modbus, introduit en 1979 par la société Modicon. Selon l’analyste américain ARC Advisory Group, Modbus TCP est à ce jour le protocole Ethernet Industriel le plus utilisé au monde, avec pas moins de cent mille produits compatibles installés aux quatre coins du globe. Standard géré par l’organisation Modbus IDA, Modbus TCP a récemment été approuvé par l’IEC en tant que spécification ouverte au public. Le protocole Modbus Série est populaire depuis longtemps dans le monde des automatismes. Plus d’un million de produits Modbus sur liaison série ont été installés à ce jour dans le monde, et un grand nombre de passerelles avec les diverses variantes d’Ethernet existent déjà. Ajoutez à cela le fait que les spécifications de Modbus TCP sont téléchargeables gratuitement sur Internet, et qu’il existe un grand nombre d’implémentations open source du protocole, vous comprendrez alors sans mal les raisons du succès de Modbus TCP.
Basé sur un mode de communication client/serveur, Modbus TCP permet d’échanger des informations en temps réel entre différents produits d’automatismes sur Ethernet TCP/IP. Si avec des temps de réponse variant entre 0.2 et 1 seconde, Modbus TCP couvre une grande partie des besoins, notamment pour des applications où l’information est centralisée (entrées/sorties déportées), il ne constitue pas une solution idéale pour des applications nécessitant des temps de réponse beaucoup plus faibles (quelques micro-secondes dans le cas du contrôle de mouvements).
Pour prendre en compte les besoins non satisfaits par la messagerie client/serveur Modbus TCP, la mise en œuvre d’une extension basée sur un protocole de type publication/souscription temps réel, baptisée RTPS (Real Time Publisher Subscriber Protocol), est envisageable. RTPS tourne au-dessus d’UDP et fournit un ensemble de services applicatifs. Ce protocole s’adresse aux stations qui publient l’information qu’elles produisent et à d’autres stations qui souscrivent aux informations dont elles ont besoin. Le principe de publication/souscription offre de nombreux bénéfices par rapport au modèle client/serveur, dont une optimisation de la bande passante. Le principe de requête/réponse utilisée dans les communications client/serveur est en effet réduit de moitié. Il n’y a pas de « pooling » systématique, et un message n’est publié par une station que lorsqu’il y a un changement d’état d’une variable. L’utilisation de la technologie Multicast permet d’envoyer le même message vers de multiples stations, plutôt que plusieurs messages indépendants vers chacune d’entre elles.
Notons que le protocole RTPS constitue la base du modèle objet de distribution de données de l’IDA (Interface for Distributed Automation). La version initiale du protocole RTPS a été rendue publique par le groupe IDA, en même temps que les spécifications des communications et de la description de niveau produit.
Ethernet/IP
Ethernet/IP est le nom d’une autre technologie de communication basée sur Ethernet, développée à l’origine par Rockwell et aujourd’hui supportée par l’organisation internationale ODVA. Ethernet/IP repose sur un modèle d’échange de données critiques de contrôle s’appuyant sur une architecture producteur/consommateurs. Cette architecture permet l’échange d’informations entre un équipement émetteur et plusieurs équipements récepteurs, sans avoir recours à de multiples envois vers de multiples destinataires. Ceci est accompli grâce à l’utilisation combinée des technologies CIP (Control&Information Protocol), technologie de base des protocoles ControlNet, DeviceNet et Ethernet/IP, et de la technologie Multicast d’IP.
Ethernet/IP utilise les technologies standard IEEE 802.3. Aucune transformation ni aucun ajout non-standard n’est apporté afin d’en améliorer le déterminisme. L’ODVA recommande pour cela l’utilisation de switches full-duplex avec 100 Mbps de bande passante. Par ailleurs l’ODVA a récemment ajouté à la liste de ses spécifications CIP Sync, un mécanisme de synchronisation basé sur le standard IEEE 1588, devant permettre une communication isochrone sur Ethernet/IP, capable de satisfaire aux exigences des applications nécessitant des temps de cycle inférieurs à la dizaine de millisecondes.
Figure2 : Architecture d’Ethernet/IP
Les solutions « Temps Réel »
Tel que défini dans IEEE 802.3, Ethernet est par essence non déterministe, et par conséquent impropre à être utilisé pour des applications temps réel. En effet, il existe avec Ethernet un degré de variation sur les temps de transmission qui ne permet pas d’atteindre un niveau de déterminisme satisfaisant pour des applications temps réel dur. Des retards sont introduits principalement par les piles de communication, ou encore en raison du mécanisme de contrôle d’accès au support CSMA/CD, qui engendre des délais aléatoires dans la retransmission des messages en cas de collision.
De nombreuses propositions ont été faites pour améliorer les capacités temps-réel des réseaux Ethernet Industriels. Certaines 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. Néanmoins, dans de nombreuses applications, l’utilisation de switches reste insuffisante pour assurer un fonctionnement en temps réel. D’une part, les temps d’attente provoqués par les switchs sont trop longs et d’autre part, l’inévitable jitter dû à l’exécution des programmes du switch est trop élevé. De plus, au niveau des liaisons, les temps d’exécution requis pour la gestion du protocole ne sont pas négligeables. Pour répondre aux besoins des applications les plus exigeantes, telles que le motion-control, pouvant nécessiter des temps de cycle inférieurs à la milliseconde, avec des jitters n’excédant pas la microseconde, d’autres solutions ont du être développées. Elles ont pour noms Profinet, Ethercat, Ethernet Powerlink ou Sercos III. Elles sont pour la plupart basées sur la neutralisation du protocole d’accès au support CSMA/CD, considéré comme le principal responsable du non-déterminisme de la norme IEEE 802.3, et sur la mise en œuvre de mécanismes permettant de faire circuler les données sur le réseau dans des tranches de temps prédéterminées (time slots).
Ethernet Powerlink
Powerlink a été développé à l’origine par B&R Automation et est aujourd’hui un standard ouvert supporté par l’EPSG (Ethernet Powerlink Standardisation Group). Pour créer un réseau Ethernet vraiment apte à supporter le temps réel, Powerlink remplace les protocoles TCP/IP ou UDP/IP par une pile déterministe adaptée à l’environnement industriel, avec un contexte de communication prédéfini. Ceci est réalisable dans la pratique en faisant circuler les données sur le réseau dans des tranches de temps (time slots) prédéterminées. Dans le cas d’Ethernet Powerlink, ce procédé porte le nom de Slot Communication Network Management. Un mécanisme Maître-Esclave assure un accès temps réel aux données cycliques, tandis que les trames TCP/IP sont passées dans des tranches de temps spécif
ques.
Figure3.jpg : Architecture de communication Ethernet Powerlink
En se basant entièrement sur le standard Fast Ethernet avec un débit de 100 Mbit/s, Powerlink permet d’envisager des temps de cycles de 400 µs, voire inférieurs. Le jitter du réseau s’avère alors inférieur à 1 µs. En raison des exigences de temps réel, dans le cas d’une synchronisation des équipements cyclique ou par échange de message (modes de synchronisation par défaut de Powerlink) seuls des hubs peuvent être utilisés, les switchs n’étant pas adaptés. Pour une plus grande liberté dans le choix de la topologie du réseau et des technologies, les mécanismes de synchronisation de l’IEEE 1588 peuvent être implémentés, autorisant alors l’utilisation de switches et la communication full duplex.
Profinet
C’est à la fin de l’année 1999 que l’association Profibus a commencé à envisager une extension Ethernet pour Profibus. Dans un premier temps, il était question d’encapsuler les trames Profibus dans des trames Ethernet TCP/IP, à l’image d’Ethernet/IP ou Modbus TCP. Mais les avantages de cette solution paraissaient limités. Car parler d’Ethernet c’est bien, mais encore faut-il que cela apporte un plus notable. Il fallait donc tout revoir, et c’est bien ce qu’a fait Profibus International avec Profinet. Premier critère : le déterminisme, qui va garantir qu’une action sera réalisée dans un temps donné. Si ce temps est de l’ordre des 40 ms, comme c’est le cas pour des applications dans le bâtiment ou le tertiaire, le canal standard TCP/IP et UDP/IP est utilisé. C’est la solution pour les communications verticales.
Pour les informations de process, qui nécessitent des temps de cycle de l’ordre de 5/10 ms, le canal TCP/IP est remplacé par une couche temps réel (RT). Le canal RT peut être comparé à une voie spécifique réservée aux bus sur un axe de circulation routière. Les paramètres de qualité de service sont utilisés pour donner la priorité aux trames RT. Profinet RT a un niveau de performances comparable aux bus de terrain actuels. Il autorise le transfert de données cycliques et acycliques avec un débit élevé et une gestion d’événements.
Figure4.jpg
Troisième solution, la transmission des données avec un temps de cycle garanti de 1ms, avec une gigue de 1 microseconde, et cela en utilisant toujours le même câblage. Cette solution est appelée Profinet IRT (Isochronous Real Time). Le terme isochrone signifie que chaque trame est envoyée avec un intervalle de temps très précis. Dans ce cas, les Switch sont directement intégrés dans l’Asic afin de garantir le déterminisme. IRT est un canal de communication optionnel situé à côté du canal Ethernet standard. Un système de découpage temporel répartit la bande passante en créneaux libres, chacun étant dédié à la communication avec un équipement.
IRT va être adaptée aux solutions de Motion control, la version RT étant plutôt destinée aux entraînements simples. Dans le cas d’une application d’imprimerie, les développeurs de Profinet annoncent la possibilité de connecter et de faire dialoguer, avec un délai inférieur à 1 ms, jusqu’à 150 servomoteurs tout en laissant la possibilité de transmettre simultanément jusqu’à 6 Mbits/sec de données TCP/IP. Avec 70 nœuds, le volume des données peut atteindre les 9 Mbits. Une autre possibilité prévoit des temps de cycle de 250 microsecondes, avec 35 nœuds possibles et un volume de données sur TCP/IP de 6 Mbits.
Sercos III
A l’origine, l’interface Sercos a été conçue comme une interface d’entraînement. Aujourd’hui devenue une interface de contrôle universelle, elle définit plus de 400 paramètres standardisés décrivant l’interaction des contrôles et automatismes. Depuis longtemps, Sercos a su trouver des solutions pour les enjeux majeurs que sont la synchronisation matérielle, le découpage en plages de temps pour éviter les collisions, le transfert des données temps réel, etc. En fait, les capacités temps réels actuelles de Sercos suffisent à toutes les applications. Toutefois, les développements novateurs dans le secteur d’Ethernet Industriel nécessitaient la définition de nouveaux profils de communication, d’où l’idée de combiner les mécanismes de Sercos avec Ethernet, et ainsi créer une nouvelle version de Sercos.
Sercos-III est basé sur une structure en anneaux, tout comme la génération précédente d’interfaces Sercos, la mise en œuvre d’une structure linéaire étant toutefois possible. Notons que Sercos III ne nécessite pas l’utilisation de hubs ou de switchs. Sercos-III possède un canal de service cyclique pouvant être utilisé pour le transfert des données de communication ainsi que pour les données de configuration et de diagnostics. En option, un canal TCP/UDP/IP peut être rajouté. Il permettra d’envoyer les données en temps réel ou non vers les trames d’Ethernet standard. Les canaux cycliques et IP sont configurables.
Figure5.jpg : découpage du canal de communication en un canal cyclique et un canal IP avec SercosIII.
La vitesse de transfert sera augmentée substantiellement avec Sercos-III. Quelques valeurs typiques sont données dans le schéma 4.
Données cycliques Temps de cycle Nombre de contrôles d’entraînement Données cycliques
8 octets 31,25 us 8 Valeur de consigne couple, position actuelle
12 octets 250 us 70 Valeur de consigne et valeur actuelle, valeur de consigne position et valeur actuel
32 octets 1 ms 150 Nombreuses valeurs de consigne et valeurs actuelles
16 octets 1 ms 254 Nombre max. d’entraînements
Schéma 4 : Les performances de Sercos-III
Sercos-III prévoit une solution matérielle flexible, nécessitant toutefois le développement d’un noyau Sercos-III IP. Il permettra aux fabricants de composants et de systèmes de combiner l’équipement Sercos-III avec leurs propres composants logiques dans un seul FPGA commun. L’interface IGS (Interest Group Sercos) accepte la propagation des sources matérielles Sercos-III destinées à être intégrées dans les contrôleurs de communication. Ces contrôleurs sont capables de gérer divers protocoles industriels d’Ethernet. Il est donc possible d’implémenter des équipements de commande et de contrôle qui peuvent être adaptés au protocole Ethernet requis, en utilisant le logiciel pilote approprié. L’utilisateur final peut bénéficier de cet avantage s’il utilise différents protocoles Ethernet. Il n’aura plus besoin d’avoir recours à des configurations matérielles différentes. Notons enfin que Sercos-III ne nécessite pas d’ASIC spécifique, mais des modules standard comme des FPGA ou des contrôleurs de communication. Le remplacement des fibres optiques par des liaisons Ethernet est également synonyme de coûts réduits au niveau des connexions.
Ethercat
EtherCat est le nom d’une technologie de bus de terrain basée sur Ethernet, développée à l’origine par Beckhoff et soutenue par une organisation internationale baptisée EtherCat Technology Group. EtherCat est actuellement en cours de standardisation par l’IEC (International Electrotechnical Commission).
Pour élaborer la technologie Ethercat, les développeurs sont partis du constat suivant : lorsque les trames Ethernet sont utilisées de façon individuelle pour chacun des équipements, le taux de données utiles est généralement extrêmement faible. En effet, les trames Ethernet les plus courtes comptant 84 octets, en admettant qu’un contrôleur envoie cycliquement 4 octets de données 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%. Avec la technologie EtherCat, les paquets Ethernet ne sont 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). Les performances d’Ethercat permettent ainsi de répondre à des applications tels que le motion control, nécessitant des temps de cycle de quelques dizaines de microsecondes.
Schéma « Architecture EtherCat et profils d’équipements » Jautomatise 40 p.54
Le protocole Ethernet, tel que défini dans IEEE 802.3, reste intact jusqu’au niveau des terminaux individuels. Afin de satisfaire les spécifications des 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, délivrant un signal LVDS (Low Voltage Differential Signal). 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.
Ce dont a besoin l’Industrie
Nous venons de décrire ici les principales solutions Ethernet Industriel existantes, sachant qu’il en existe d’autre ; une vingtaine au total. Avec elles, les fournisseurs de solutions ont imaginé des parades à l’ensemble des problèmes que pouvait poser l’adaptation d’Ethernet au niveau du terrain. Ils ont notamment apporté des modifications permettant de répondre aux exigences des applications temps réel. Mais aujourd’hui, l’euphorie de ces dernières années doit faire place à des considérations plus pragmatiques. Car force est de constater que malgré tout, Ethernet est encore loin d’avoir gagné sa place au niveau du terrain. Premier constat, et non des moindres : le coût par nœud est aujourd’hui encore plus élevé avec Ethernet que dans le cas des bus de terrain traditionnels. En effet, l’adaptation aux contraintes sévères des environnements de production, l’alimentation en 24VDC ou 48 VDC, le montage sur rail DIN ainsi que les modifications apportées pour rendre les réseaux déterministes rendent l’utilisation du matériel Ethernet standard de la bureautique inenvisageable dans la pratique. En conséquence, seul un nombre restreint de fournisseurs est à ce jour capable de fournir du matériel adapté, et cela est particulièrement vrai pour les switchs, dont le coût par port s’élève entre 50 et 150 €, alors que le coût d’une connexion sur un réseau de terrain traditionnel n’excède pas les 20 €.
Par ailleurs, d’autres problématiques restent pas ou peu adressées par les solutions Ethernet actuelles. La redondance, par exemple. Sa gestion est dans la majeure partie des cas déléguée aux switchs, avec des temps de recouvrement, dans le meilleur des cas, de l’ordre de 50 ms, soit des performances qui s’avèrent encore insuffisantes pour bon nombre d’applications. A cela s’ajoutent les problèmes persistants de compatibilité entre les solutions des différents fournisseurs. Pour s’en rendre compte, il n’y a qu’à regarder l’exemple des connecteurs Ethernet adaptés aux environnements sévères, dont les caractéristiques varient en fonction que l’on utilise du Profinet, du Modbus TCP, de l’Ethernet/IP, etc.
Quoi qu’il en soit, l’industrie devra faire avec Ethernet. Etant donné l’importance des investissements déjà engagés, il n’y aura vraisemblablement pas d’alternative possible. Mais contrairement à ce que prétend l’IEC, il n’y a pas de demande du marché pour une diversité telle que celle qui est aujourd’hui proposée. Ce dont a besoin l’industrie, ce n’est pas d’un bouquet de solutions incompatibles, ce dont elle a besoin, c’est d’un véritable standard, universel, pour la communication et le contrôle-commande. Aujourd’hui nous en sommes encore loin, et la guerre que se livrent en sous-main les différents fournisseurs n’a jamais été aussi flagrante. Cependant il y a fort à parier que la communauté des utilisateurs, forte des enseignements qu’elle aura su tirer de l’épisode des bus de terrain, saura dire le moment venu : « Ce n’est pas ce que nous avons demandé».
j42p5461
Tout le monde se souvient de la fin de l’année 1999. De la tempête, bien sûr, du passage à l’an 2000, mais aussi de ce jour pathétique où le projet de normalisation des technologies de bus de terrain s’était conclu sur l’adoption d’un prétendu standard, l’IEC 61158, légitimant l’existence de pas moins de huit protocoles différents et parfaitement incompatibles entre eux pour la communication de terrain. Parmi les grands gagnants de cette débâcle figurent les principaux offreurs de solutions d’automatismes qui trouvèrent là un bon moyen de préserver leurs parts de marché respectives, au grand damne des utilisateurs.
Aujourd’hui, avec Ethernet, l’histoire se répète. Ou plutôt, elle se poursuit. Dans la tourmente de la guerre des bus de terrain, plusieurs solutions basées sur Ethernet et TCP/UDP/IP avaient déjà réussi à se hisser au rang de « standard », en figurant dans l’IEC 61158. Ce fut notamment le cas des technologies High Speed Ethernet (HSE), développée par Foundation FieldBus, Ethernet/IP, soutenue par l’ODVA et Profinet, supportée par Profibus International. Depuis, les technologies ont évolué, et pour répondre aux besoins des applications les plus exigeantes, de nouvelles solutions ont émergé. Elles ont pour nom Profinet IRT, Ethercat, Ethernet Powerlink ou encore Sercos III. Le but de cet article est de vous présenter les principales solutions existantes, de mettre en lumière les différences existantes entre elles, mais aussi d’expliquer leurs spécificités.
Pourquoi Ethernet ?
Commençons par le commencement. Pourquoi Ethernet ? La motivation initiale fut à l’évidence économique. En effet, la popularité déjà établie d’Ethernet dans le milieu de la bureautique, à l’époque où s’ébauchait à peine la volonté industrielle d’intégrer les couches hautes et basses des réseaux d’entreprises, a tout naturellement orienté le choix du marché vers Ethernet pour la communication industrielle. La « descente » d’Ethernet s’est ainsi effectué sans problème jusqu’au niveau 2 de la pyramide de CIM, à savoir la couche contrôle. Ainsi, depuis de nombreuses années déjà, Ethernet fait figure de solution intéressante pour l’interconnexion de contrôleurs et de sous-réseaux de terrain entre eux.
Parallèlement à cela, l’amélioration constante des performances CPU des automates, et surtout des PC industriels, ont été telles que finalement les performances des bus de terrain traditionnels, notamment en termes de vitesses de transferts, se sont vite avérées limitées en raison notamment d’un nombre croissant d’informations que les utilisateurs souhaitaient véhiculer. Ethernet, avec les vitesses de transfert extrêmement rapides qu’il permettait d’envisager, combinées aux avantages économiques liées au fait de mettre en œuvre un standard aussi répandu, constituait une alternative intéressante aux bus de terrain traditionnels.
Figure1.jpg
Seulement voilà : pour être utilisable dans des applications du type entrées-sorties déportées, ou pour des systèmes de commande (domaines jusque là réservés aux bus de terrain traditionnels), un certain nombre de conditions sont à remplir. Outre celles de présenter des vitesses de transfert élevées et un coût avantageux, parmi les principales, on pourra citer : le déterminisme, qui va garantir qu’une action sera réalisée dans un laps de temps déterminé, mais également la capacité à manipuler des paquets de données de faibles tailles, ou encore la capacité à synchroniser avec précision l’ensemble des horloges du système. A cela s’ajoutent la capacité à résister à des contraintes environnementales sévères, l’adaptabilité à la topologie des ateliers de production, et enfin la capacité à garantir un niveau de sécurité élevé.
Or une chose est certaine : tel que défini dans IEEE 802.3, Ethernet ne répondait à aucune de ces exigences. De nouvelles solutions ont donc du être imaginées pour permettre à Ethernet de se frayer un chemin vers les ateliers de production. C’est ce qu’ont fait les principaux offreurs de solutions d’automatismes, chacun y allant de sa petite cuisine.
Dans l’état actuel des développements, deux types de solutions peuvent être distinguées: les solutions dites « encapsulées », d’une part, qui visent à faire remonter des trames issues des équipements de terrain connectés aux bus traditionnels, au travers d’une connexion Ethernet TCP/UDP/IP, et les solutions dites « temps réel », d’autre part, modifiées pour répondre aux exigences des systèmes de commandes et d’entrées-sorties déportées.
Les Solutions « Encapsulées »
Dans le cas des solutions encapsulées, les couches applications sont les mêmes que celles utilisées par les bus de terrain sous-jacents, à quelques extensions près pour permettre le transport des trames au travers d’une liaison Ethernet TCP/UDP/IP. Typiquement ces solutions permettent l’interconnexion de plusieurs sous-réseaux de terrain par l’intermédiaire de contrôleurs reliés entre eux par une liaison Ethernet standard. Ainsi, il est possible de récupérer au niveau des contrôleurs, mais également au niveau des IHM et autres outils de supervision et de contrôle, un grand nombre d’informations concernant la configuration, le fonctionnement et le diagnostic des équipements connectés aux bus de terrain. Typiquement, de telles solutions sont capables de répondre aux besoins d’applications ne nécessitant pas des temps de cycles inférieurs à la centaine de millisecondes. Autrement dit, elles permettent de répondre aux besoins d’applications de monitoring, de même qu’aux besoins de la plupart des applications d’automatisation de process actuelles. Notons que la mise en œuvre de mécanismes de niveau applicatif peut permettre d’améliorer les performances, rendant alors certaines de ces solutions capables de répondre aux exigences d’applications nécessitant des temps de cycle inférieurs à la dizaine de millisecondes. C’est typiquement le cas des systèmes de contrôle de machines-outils.
Figure2.jpg : Architecture de communication Modbus TCP/IP
Modbus TCP/IP
Modbus TCP est le nom de la variante « encapsulée » dans TCP/IP du célèbre protocole Modbus, introduit en 1979 par la société Modicon. Selon l’analyste américain ARC Advisory Group, Modbus TCP est à ce jour le protocole Ethernet Industriel le plus utilisé au monde, avec pas moins de cent mille produits compatibles installés aux quatre coins du globe. Standard géré par l’organisation Modbus IDA, Modbus TCP a récemment été approuvé par l’IEC en tant que spécification ouverte au public. Le protocole Modbus Série est populaire depuis longtemps dans le monde des automatismes. Plus d’un million de produits Modbus sur liaison série ont été installés à ce jour dans le monde, et un grand nombre de passerelles avec les diverses variantes d’Ethernet existent déjà. Ajoutez à cela le fait que les spécifications de Modbus TCP sont téléchargeables gratuitement sur Internet, et qu’il existe un grand nombre d’implémentations open source du protocole, vous comprendrez alors sans mal les raisons du succès de Modbus TCP.
Basé sur un mode de communication client/serveur, Modbus TCP permet d’échanger des informations en temps réel entre différents produits d’automatismes sur Ethernet TCP/IP. Si avec des temps de réponse variant entre 0.2 et 1 seconde, Modbus TCP couvre une grande partie des besoins, notamment pour des applications où l’information est centralisée (entrées/sorties déportées), il ne constitue pas une solution idéale pour des applications nécessitant des temps de réponse beaucoup plus faibles (quelques micro-secondes dans le cas du contrôle de mouvements).
Pour prendre en compte les besoins non satisfaits par la messagerie client/serveur Modbus TCP, la mise en œuvre d’une extension basée sur un protocole de type publication/souscription temps réel, baptisée RTPS (Real Time Publisher Subscriber Protocol), est envisageable. RTPS tourne au-dessus d’UDP et fournit un ensemble de services applicatifs. Ce protocole s’adresse aux stations qui publient l’information qu’elles produisent et à d’autres stations qui souscrivent aux informations dont elles ont besoin. Le principe de publication/souscription offre de nombreux bénéfices par rapport au modèle client/serveur, dont une optimisation de la bande passante. Le principe de requête/réponse utilisée dans les communications client/serveur est en effet réduit de moitié. Il n’y a pas de « pooling » systématique, et un message n’est publié par une station que lorsqu’il y a un changement d’état d’une variable. L’utilisation de la technologie Multicast permet d’envoyer le même message vers de multiples stations, plutôt que plusieurs messages indépendants vers chacune d’entre elles.
Notons que le protocole RTPS constitue la base du modèle objet de distribution de données de l’IDA (Interface for Distributed Automation). La version initiale du protocole RTPS a été rendue publique par le groupe IDA, en même temps que les spécifications des communications et de la description de niveau produit.
Ethernet/IP
Ethernet/IP est le nom d’une autre technologie de communication basée sur Ethernet, développée à l’origine par Rockwell et aujourd’hui supportée par l’organisation internationale ODVA. Ethernet/IP repose sur un modèle d’échange de données critiques de contrôle s’appuyant sur une architecture producteur/consommateurs. Cette architecture permet l’échange d’informations entre un équipement émetteur et plusieurs équipements récepteurs, sans avoir recours à de multiples envois vers de multiples destinataires. Ceci est accompli grâce à l’utilisation combinée des technologies CIP (Control&Information Protocol), technologie de base des protocoles ControlNet, DeviceNet et Ethernet/IP, et de la technologie Multicast d’IP.
Ethernet/IP utilise les technologies standard IEEE 802.3. Aucune transformation ni aucun ajout non-standard n’est apporté afin d’en améliorer le déterminisme. L’ODVA recommande pour cela l’utilisation de switches full-duplex avec 100 Mbps de bande passante. Par ailleurs l’ODVA a récemment ajouté à la liste de ses spécifications CIP Sync, un mécanisme de synchronisation basé sur le standard IEEE 1588, devant permettre une communication isochrone sur Ethernet/IP, capable de satisfaire aux exigences des applications nécessitant des temps de cycle inférieurs à la dizaine de millisecondes.
Figure2 : Architecture d’Ethernet/IP
Les solutions « Temps Réel »
Tel que défini dans IEEE 802.3, Ethernet est par essence non déterministe, et par conséquent impropre à être utilisé pour des applications temps réel. En effet, il existe avec Ethernet un degré de variation sur les temps de transmission qui ne permet pas d’atteindre un niveau de déterminisme satisfaisant pour des applications temps réel dur. Des retards sont introduits principalement par les piles de communication, ou encore en raison du mécanisme de contrôle d’accès au support CSMA/CD, qui engendre des délais aléatoires dans la retransmission des messages en cas de collision.
De nombreuses propositions ont été faites pour améliorer les capacités temps-réel des réseaux Ethernet Industriels. Certaines 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. Néanmoins, dans de nombreuses applications, l’utilisation de switches reste insuffisante pour assurer un fonctionnement en temps réel. D’une part, les temps d’attente provoqués par les switchs sont trop longs et d’autre part, l’inévitable jitter dû à l’exécution des programmes du switch est trop élevé. De plus, au niveau des liaisons, les temps d’exécution requis pour la gestion du protocole ne sont pas négligeables. Pour répondre aux besoins des applications les plus exigeantes, telles que le motion-control, pouvant nécessiter des temps de cycle inférieurs à la milliseconde, avec des jitters n’excédant pas la microseconde, d’autres solutions ont du être développées. Elles ont pour noms Profinet, Ethercat, Ethernet Powerlink ou Sercos III. Elles sont pour la plupart basées sur la neutralisation du protocole d’accès au support CSMA/CD, considéré comme le principal responsable du non-déterminisme de la norme IEEE 802.3, et sur la mise en œuvre de mécanismes permettant de faire circuler les données sur le réseau dans des tranches de temps prédéterminées (time slots).
Ethernet Powerlink
Powerlink a été développé à l’origine par B&R Automation et est aujourd’hui un standard ouvert supporté par l’EPSG (Ethernet Powerlink Standardisation Group). Pour créer un réseau Ethernet vraiment apte à supporter le temps réel, Powerlink remplace les protocoles TCP/IP ou UDP/IP par une pile déterministe adaptée à l’environnement industriel, avec un contexte de communication prédéfini. Ceci est réalisable dans la pratique en faisant circuler les données sur le réseau dans des tranches de temps (time slots) prédéterminées. Dans le cas d’Ethernet Powerlink, ce procédé porte le nom de Slot Communication Network Management. Un mécanisme Maître-Esclave assure un accès temps réel aux données cycliques, tandis que les trames TCP/IP sont passées dans des tranches de temps spécif
ques.
Figure3.jpg : Architecture de communication Ethernet Powerlink
En se basant entièrement sur le standard Fast Ethernet avec un débit de 100 Mbit/s, Powerlink permet d’envisager des temps de cycles de 400 µs, voire inférieurs. Le jitter du réseau s’avère alors inférieur à 1 µs. En raison des exigences de temps réel, dans le cas d’une synchronisation des équipements cyclique ou par échange de message (modes de synchronisation par défaut de Powerlink) seuls des hubs peuvent être utilisés, les switchs n’étant pas adaptés. Pour une plus grande liberté dans le choix de la topologie du réseau et des technologies, les mécanismes de synchronisation de l’IEEE 1588 peuvent être implémentés, autorisant alors l’utilisation de switches et la communication full duplex.
Profinet
C’est à la fin de l’année 1999 que l’association Profibus a commencé à envisager une extension Ethernet pour Profibus. Dans un premier temps, il était question d’encapsuler les trames Profibus dans des trames Ethernet TCP/IP, à l’image d’Ethernet/IP ou Modbus TCP. Mais les avantages de cette solution paraissaient limités. Car parler d’Ethernet c’est bien, mais encore faut-il que cela apporte un plus notable. Il fallait donc tout revoir, et c’est bien ce qu’a fait Profibus International avec Profinet. Premier critère : le déterminisme, qui va garantir qu’une action sera réalisée dans un temps donné. Si ce temps est de l’ordre des 40 ms, comme c’est le cas pour des applications dans le bâtiment ou le tertiaire, le canal standard TCP/IP et UDP/IP est utilisé. C’est la solution pour les communications verticales.
Pour les informations de process, qui nécessitent des temps de cycle de l’ordre de 5/10 ms, le canal TCP/IP est remplacé par une couche temps réel (RT). Le canal RT peut être comparé à une voie spécifique réservée aux bus sur un axe de circulation routière. Les paramètres de qualité de service sont utilisés pour donner la priorité aux trames RT. Profinet RT a un niveau de performances comparable aux bus de terrain actuels. Il autorise le transfert de données cycliques et acycliques avec un débit élevé et une gestion d’événements.
Figure4.jpg
Troisième solution, la transmission des données avec un temps de cycle garanti de 1ms, avec une gigue de 1 microseconde, et cela en utilisant toujours le même câblage. Cette solution est appelée Profinet IRT (Isochronous Real Time). Le terme isochrone signifie que chaque trame est envoyée avec un intervalle de temps très précis. Dans ce cas, les Switch sont directement intégrés dans l’Asic afin de garantir le déterminisme. IRT est un canal de communication optionnel situé à côté du canal Ethernet standard. Un système de découpage temporel répartit la bande passante en créneaux libres, chacun étant dédié à la communication avec un équipement.
IRT va être adaptée aux solutions de Motion control, la version RT étant plutôt destinée aux entraînements simples. Dans le cas d’une application d’imprimerie, les développeurs de Profinet annoncent la possibilité de connecter et de faire dialoguer, avec un délai inférieur à 1 ms, jusqu’à 150 servomoteurs tout en laissant la possibilité de transmettre simultanément jusqu’à 6 Mbits/sec de données TCP/IP. Avec 70 nœuds, le volume des données peut atteindre les 9 Mbits. Une autre possibilité prévoit des temps de cycle de 250 microsecondes, avec 35 nœuds possibles et un volume de données sur TCP/IP de 6 Mbits.
Sercos III
A l’origine, l’interface Sercos a été conçue comme une interface d’entraînement. Aujourd’hui devenue une interface de contrôle universelle, elle définit plus de 400 paramètres standardisés décrivant l’interaction des contrôles et automatismes. Depuis longtemps, Sercos a su trouver des solutions pour les enjeux majeurs que sont la synchronisation matérielle, le découpage en plages de temps pour éviter les collisions, le transfert des données temps réel, etc. En fait, les capacités temps réels actuelles de Sercos suffisent à toutes les applications. Toutefois, les développements novateurs dans le secteur d’Ethernet Industriel nécessitaient la définition de nouveaux profils de communication, d’où l’idée de combiner les mécanismes de Sercos avec Ethernet, et ainsi créer une nouvelle version de Sercos.
Sercos-III est basé sur une structure en anneaux, tout comme la génération précédente d’interfaces Sercos, la mise en œuvre d’une structure linéaire étant toutefois possible. Notons que Sercos III ne nécessite pas l’utilisation de hubs ou de switchs. Sercos-III possède un canal de service cyclique pouvant être utilisé pour le transfert des données de communication ainsi que pour les données de configuration et de diagnostics. En option, un canal TCP/UDP/IP peut être rajouté. Il permettra d’envoyer les données en temps réel ou non vers les trames d’Ethernet standard. Les canaux cycliques et IP sont configurables.
Figure5.jpg : découpage du canal de communication en un canal cyclique et un canal IP avec SercosIII.
La vitesse de transfert sera augmentée substantiellement avec Sercos-III. Quelques valeurs typiques sont données dans le schéma 4.
Données cycliques Temps de cycle Nombre de contrôles d’entraînement Données cycliques
8 octets 31,25 us 8 Valeur de consigne couple, position actuelle
12 octets 250 us 70 Valeur de consigne et valeur actuelle, valeur de consigne position et valeur actuel
32 octets 1 ms 150 Nombreuses valeurs de consigne et valeurs actuelles
16 octets 1 ms 254 Nombre max. d’entraînements
Schéma 4 : Les performances de Sercos-III
Sercos-III prévoit une solution matérielle flexible, nécessitant toutefois le développement d’un noyau Sercos-III IP. Il permettra aux fabricants de composants et de systèmes de combiner l’équipement Sercos-III avec leurs propres composants logiques dans un seul FPGA commun. L’interface IGS (Interest Group Sercos) accepte la propagation des sources matérielles Sercos-III destinées à être intégrées dans les contrôleurs de communication. Ces contrôleurs sont capables de gérer divers protocoles industriels d’Ethernet. Il est donc possible d’implémenter des équipements de commande et de contrôle qui peuvent être adaptés au protocole Ethernet requis, en utilisant le logiciel pilote approprié. L’utilisateur final peut bénéficier de cet avantage s’il utilise différents protocoles Ethernet. Il n’aura plus besoin d’avoir recours à des configurations matérielles différentes. Notons enfin que Sercos-III ne nécessite pas d’ASIC spécifique, mais des modules standard comme des FPGA ou des contrôleurs de communication. Le remplacement des fibres optiques par des liaisons Ethernet est également synonyme de coûts réduits au niveau des connexions.
Ethercat
EtherCat est le nom d’une technologie de bus de terrain basée sur Ethernet, développée à l’origine par Beckhoff et soutenue par une organisation internationale baptisée EtherCat Technology Group. EtherCat est actuellement en cours de standardisation par l’IEC (International Electrotechnical Commission).
Pour élaborer la technologie Ethercat, les développeurs sont partis du constat suivant : lorsque les trames Ethernet sont utilisées de façon individuelle pour chacun des équipements, le taux de données utiles est généralement extrêmement faible. En effet, les trames Ethernet les plus courtes comptant 84 octets, en admettant qu’un contrôleur envoie cycliquement 4 octets de données 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%. Avec la technologie EtherCat, les paquets Ethernet ne sont 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). Les performances d’Ethercat permettent ainsi de répondre à des applications tels que le motion control, nécessitant des temps de cycle de quelques dizaines de microsecondes.
Schéma « Architecture EtherCat et profils d’équipements » Jautomatise 40 p.54
Le protocole Ethernet, tel que défini dans IEEE 802.3, reste intact jusqu’au niveau des terminaux individuels. Afin de satisfaire les spécifications des 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, délivrant un signal LVDS (Low Voltage Differential Signal). 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.
Ce dont a besoin l’Industrie
Nous venons de décrire ici les principales solutions Ethernet Industriel existantes, sachant qu’il en existe d’autre ; une vingtaine au total. Avec elles, les fournisseurs de solutions ont imaginé des parades à l’ensemble des problèmes que pouvait poser l’adaptation d’Ethernet au niveau du terrain. Ils ont notamment apporté des modifications permettant de répondre aux exigences des applications temps réel. Mais aujourd’hui, l’euphorie de ces dernières années doit faire place à des considérations plus pragmatiques. Car force est de constater que malgré tout, Ethernet est encore loin d’avoir gagné sa place au niveau du terrain. Premier constat, et non des moindres : le coût par nœud est aujourd’hui encore plus élevé avec Ethernet que dans le cas des bus de terrain traditionnels. En effet, l’adaptation aux contraintes sévères des environnements de production, l’alimentation en 24VDC ou 48 VDC, le montage sur rail DIN ainsi que les modifications apportées pour rendre les réseaux déterministes rendent l’utilisation du matériel Ethernet standard de la bureautique inenvisageable dans la pratique. En conséquence, seul un nombre restreint de fournisseurs est à ce jour capable de fournir du matériel adapté, et cela est particulièrement vrai pour les switchs, dont le coût par port s’élève entre 50 et 150 €, alors que le coût d’une connexion sur un réseau de terrain traditionnel n’excède pas les 20 €.
Par ailleurs, d’autres problématiques restent pas ou peu adressées par les solutions Ethernet actuelles. La redondance, par exemple. Sa gestion est dans la majeure partie des cas déléguée aux switchs, avec des temps de recouvrement, dans le meilleur des cas, de l’ordre de 50 ms, soit des performances qui s’avèrent encore insuffisantes pour bon nombre d’applications. A cela s’ajoutent les problèmes persistants de compatibilité entre les solutions des différents fournisseurs. Pour s’en rendre compte, il n’y a qu’à regarder l’exemple des connecteurs Ethernet adaptés aux environnements sévères, dont les caractéristiques varient en fonction que l’on utilise du Profinet, du Modbus TCP, de l’Ethernet/IP, etc.
Quoi qu’il en soit, l’industrie devra faire avec Ethernet. Etant donné l’importance des investissements déjà engagés, il n’y aura vraisemblablement pas d’alternative possible. Mais contrairement à ce que prétend l’IEC, il n’y a pas de demande du marché pour une diversité telle que celle qui est aujourd’hui proposée. Ce dont a besoin l’industrie, ce n’est pas d’un bouquet de solutions incompatibles, ce dont elle a besoin, c’est d’un véritable standard, universel, pour la communication et le contrôle-commande. Aujourd’hui nous en sommes encore loin, et la guerre que se livrent en sous-main les différents fournisseurs n’a jamais été aussi flagrante. Cependant il y a fort à parier que la communauté des utilisateurs, forte des enseignements qu’elle aura su tirer de l’épisode des bus de terrain, saura dire le moment venu : « Ce n’est pas ce que nous avons demandé».
