Couverture ElectroniqueS n°127

Envisager une solution universelle de connectivité en temps réel, déterministe et performante, mais compatible avec l'existant pour assurer une rupture en douceur, ne serait plus la recherche de la quadrature du cercle ? C'est le défi auquel le français Arion s'attaque avec sa technologie de communication multiapplicative. La technologie Ethernet avance tous les jours un peu plus par le fait de sa large utilisation dans des domaines aussi variés que l'informatique ou les applications de grande consommation, pour ne citer que ceux-ci. Cette évolution passe notamment par des performances en hausse permanente : en l'espace de quelques années, le Fast Ethernet a fait place au Gigabit Ethernet, alors que les solutions à 10 Gbits/s fonctionnent déjà. A quand les 100 gigas ? De plus, une connectivité accrue venant des protocoles comme TCP-IP ou UDP-IP permet la mise en &oelig;uvre d'applications « interopérables ».Et comme le marché grand public brasse des volumes conséquents, elle est à ce jour la solution universelle la moins onéreuse : une carte Ethernet ne coûte qu'une dizaine d'euros chez le revendeur local ; les commutateurs, même évolués, sont vendus dans une gamme de prix ne dépassant pas quelques centaines d'euros. Cette marche en avant permanente fait que beaucoup de décideurs voient en Ethernet et le tout IP le remède à tous leurs maux.S'appuyant sur cet existant technologique prolifique, des solutions dites « Ethernet temps réel » se développent dans différents domaines :dans l'industriel, on peut citer sans être exhaustif Powerlink (B&R), Profinet (Siemens), Ethercat (Beekoff) ou encore EtherModbus (Schneider) ;dans l'avionique, Airbus a mis en avant la solution AFDX ;dans le ferroviaire, les solutions dites « standard » sont expérimentées, voire mises en &oelig;uvre pour des fonctions non critiques.Alors, pourquoi ces solutions sont-elles toutes incompatibles les unes avec les autres ? Pourquoi leur coût n'est-il pas de quelques euros ? Pour quelles raisons posent-elles tant de problèmes en intégration et en déploiement ? A ces nombreuses questions les causes sont bien entendu multiples et dépendent des champs d'application. En environnement industriel, le déterminisme est primordial. Pour l'aéronautique, c'est la preuve d'un temps de communication borné entre applications qui pose un problème crucial. Et pour l'automobile, c'est le prix de la solution qui la rend inutilisable.Mais, quel que soit le domaine, on retrouve au moins comme constantes les raisons suivantes :la difficulté d'intégration et de déploiement du fait des protocoles logiciels à mettre en &oelig;uvre au niveau de chaque calculateur ;le fait de ne pouvoir démontrer mathématiquement le comportement des moyens de commutation et, en particulier, le problème posé par les tentatives de modélisation de ces mêmes ressources (encadré) ;le besoin d'assurer un niveau de sûreté de fonctionnement global pour le système ;le besoin de déterminisme du système : celui-ci peut être pris au premier degré (gestion à la microseconde des moteurs de la rotative pour l'imprimerie), ou utilisé comme moyen pour assurer la connectivité des équipements dans le système, par exemple, réservation de bande passante dans l'automobile avec FlexRay).Une heure système distribuée précise à la microsecondeLe moyen de communication apportant une interopérabilité entre réseaux différents, il peut être utile dans certains cas de disposer d'une puissance de calcul pour effectuer des fonctions de niveau passerelle. Afin de parfaitement ségréguer le traitement des protocoles, qui est de niveau des interfaces, et la gestion des données, qui elle est de niveau application, il est possible d'embarquer un processeur avec une interface de type Arion supportant les commandes de type Read() et Write().Le besoin de distribution des applications nécessite la mise en &oelig;uvre de protocoles de communication de type « point à point » , « multipoint » et « diffusion ». A cela s'ajoute un besoin de performance. Il est donc important de paralléliser au maximum tous les flux de données dans le moyen de commutation et d'en maîtriser les aspects temporels. Cette assertion se décline alors sous deux aspects complémentaires. D'une part, le moyen de commutation global se comporte comme une machine parallèle de type MIMD (de l'anglais Multiple Instruction stream, Multiple Data stream, technique de parallélisation indépendante et asynchrone), afin d'optimiser la transmission des données. D'autre part, chaque moyen de commutation élémentaire optimise la communication au niveau du noyau Arion ; celle-ci permettant une gestion simultanée de plusieurs flux (figure 4). Le but est de voir le système de commutation global comme un système temps réel composé d'une pluralité d'éléments d'aiguillage du trafic des données, dont le comportement est connu et maîtrisé. Le système résultant est alors déterminé, en conformité aux règles établies (normes…). De ce fait, il est qualifiable par des équations mathématiques simples pour chaque flux d'information, où chacun de ces derniers est identifié de façon unique dans le moyen de commutation global.Le flot est alors encapsulé avec un identifiant, une date de production prélevée à partir de l'heure système gérée par le moyen de commutation, et un CRC (Cyclic redundancy check) 32 bits pour garantir l'intégrité de bout en bout des données.Il est possible de qualifier chaque flux de données échangé entre entités distantes par un ensemble de paramètres. Les flux de données, décrits dans un fichier au format XML, sont exploités par le configurateur pour générer les éléments de paramétrage de chaque commutateur élémentaire. Ces fichiers téléchargeables servent à la configuration du système de commutation. Devant le volume des flux de données échangés dans le moyen de commutation et afin d'en assurer une gestion correcte, il est possible de les affecter de priorités.Le comportement intègre aussi la gestion des trames au niveau du système de commutation. A titre d'exemple, la réémission du flux de données peut être demandée en cas d'accusé de réception de l'entité distante invalide ou absente. Le nombre de réémissions est un paramètre associé au flux. En cas d'erreur confirmée, il est possible de générer un message d'erreur. La structure modulaire de la commutation doit permettre l'interconnexion de tout type de bus et pouvoir gérer les flux de données, indépendamment de leur origine ou de leur destination. De la même manière, il doit être possible de connecter une mémoire pour assurer une fonction serveur de données distribué au niveau du système de commutation.Modéliser le moyen de commutation : des résultats contestablesCe point qui pourrait sembler encore bien occulte, y compris pour les initiés aux problèmatiques des structures communicantes, mérite une petite explication. Dans les applications industrielles, il est nécessaire de travailler au niveau de la communication avec des temps bornés (le pire cas). Nous arrivons à faire ces démonstrations sur des réseaux dont le comportement est facilement modélisable (en règle générale on utilise pour ce faire des réseaux dits « à gestion centralisée » comme Fip, Profibus DP, Mil-Std 1553…). Dans le cas d'Ethernet commuté, un des moyens de communication utilisé pour assurer l'interconnexion des différents équipements est le commutateur (switch). Or son comportement varie en fonction de sa charge instantanée (le nombre de messages reçus à l'instant t), pouvant aller jusqu'à perdre des messages en cas de congestion.Dans ce cas, il est difficile de borner la communication car nous ne disposons pas de modèles mathématiques simples. Pour tenter malgré cela de cadrer ces temps d'échanges de données, on exporte des contraintes au niveau de l'application de façon que celle-ci ne génère pas plus de données que le commutateur est susceptible d'en traiter. Mais, en règle générale, le résultat est à la hauteur de la méthode : pas très convaincant.

Mettre Ethernet à l’heure du temps réel : fantasme ou réalité ?

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Mettre Ethernet à l’heure du temps réel : fantasme ou réalité ?

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure