MuSE : clustering, extensibilité et puissance d'E/S presque infinie avec les simulations OPAL-RT

OPAL-RT a amélioré l'expérience de l'utilisateur lorsqu'il utilise plusieurs simulateurs, des cibles distantes ou lorsqu'il a besoin de machines en grappe pour augmenter les E/S ou d'autres capacités. Cette liaison à haut débit est appelée MuSE (Multi-System Expansion Link). MuSE(Multi-System Expansionlink).

Irène Pérès, Product Owner de MuSE à OPAL-RT, nous a récemment rejoints pour nous parler de l'incroyable puissance, de la flexibilité, de la polyvalence et de la convivialité de cet add-on spécial, qui est bien plus qu'un simple kit d'extension.

Enquêteur (IV): Merci de vous joindre à nous, Irène ! J'ai partiellement compris que MuSE est une sorte de kit d'extension matériel, permettant la mise en cluster de plusieurs machines, et fréquemment utilisé pour augmenter les entrées-sorties disponibles. Est-ce ainsi que vous le décririez ?

Irène Pérès (IP) : "MuSE implique effectivement des composants matériels : fibre optique et émetteurs-récepteurs SFP (Small Form-factor Pluggable). Cependant, le matériel n'est que la partie émergée de l'iceberg, car l'essence de MuSE réside dans les couches logicielles que nous avons développées. Le problème que nous devions résoudre était le suivant : lorsqu'un utilisateur a besoin de plus de canaux d'E/S que ceux disponibles dans un châssis, comment pouvons-nous faciliter la connexion avec d'autres châssis pour ajouter cette capacité d'E/S supplémentaire ?

IV : MuSE a été utilisé pour la simulation dans des industries qui ont tendance à utiliser beaucoup d'entrées-sorties, comme l'aviation et l'aéronautique - c'est bien cela ?

IP: "Oui, nous avons d'abord développé le lien en pensant à ces industries. Mais en réalité, nous constatons une tendance émergente à utiliser MuSE dans des applications très diverses et même pour des systèmes plus petits. La convivialité de l'assemblage modulaire des systèmes est un argument de vente très convaincant. Elle facilite grandement les choses. Par exemple, si vous disposez d'un simulateur OP4510 avec 128 canaux d'E/S et que vous avez besoin de plus d'E/S, vous pouvez, grâce à la technologie PCIe, ajouter un châssis d'extension OP4520 et doubler la capacité pour atteindre 256 E/S. Mais qu'en est-il si vous avez besoin d'encore plus d'E/S ? L'OP4510 est un boîtier assez petit, il ne peut donc pas accueillir plus d'une carte PCIe. Mais désormais, grâce aux quatre ports SFP situés à l'avant du châssis, nous pouvons connecter quatre châssis d'extension d'E/S à cet OP4510. Ces châssis peuvent être de n'importe quel type, même des plus grands comme l'OP5607 avec 256 canaux d'E/S, ce qui augmente la capacité d'E/S de manière exponentielle.

IV : Vous voulez donc dire que vous pouvez mélanger n'importe quel type de châssis OPAL-RT avec MuSE ?

IP: "En effet ! Comme je l'ai mentionné, nous utilisions des SFP pour nous connecter à des dispositifs tiers (amplificateurs, contrôleurs MMC) et nous disposions déjà de ports SFP sur tous nos systèmes plus récents. Le logiciel que nous avons développé est donc compatible avec tous les systèmes, ce qui permet à l'utilisateur de construire un réseau de simulateurs et de châssis d'extension de différents types, en fonction de ses besoins et de son budget. Sur notre simulateur OP5707, par exemple, nous disposons de 16 ports SFP, ce qui nous permet de connecter 16 châssis OP5607, chacun ayant jusqu'à 256 E/S. Nous avons même récemment mis à niveau la famille OP5600 pour ajouter la capacité MuSE, avec le nouvel OP5650 qui vient d'être lancé et qui dispose d'un FPGA Artix-7 et de 4 ports SFP.

IV : Donc vraiment : jusqu'à 4 096 connexions d'E/S ? À votre connaissance, avons-nous déjà fait quelque chose de ce genre ?

IP : "Passons en revue quelques défis de simulation assez exceptionnels, qui vous donneront une idée de la flexibilité et de l'extensibilité que nous pouvons offrir. De telles configurations n'étaient tout simplement pas possibles avec PCIe de manière conviviale, voire pas du tout :

• Un de nos clients avait besoin d'étendre son simulateur OP4510 (fonctionnant avec RT-LAB) pour effectuer le contrôle en temps réel de l'électronique de puissance et des machines électriques sur un banc d'essai. Dans ce cas, l'ajout de quatre OP4200 en cluster leur a permis d'exécuter le contrôle sur un calculateur temps réel de l'OP4510 tout en pilotant les onduleurs et en collectant des données à partir de mesures sur les OP4200 ;
• Un autre client a deux installations, une OP5707 avec quatre OP4520 et une autre OP5707 avec quatre OP4200, fonctionnant avec HYPERSIM. Dans ce cas, les unités distantes sont situées à ~100 mètres du simulateur, et le client a besoin d'utiliser la fibre optique pré-installée dans son bâtiment. Nous n'avons pas pu ajouter de câbles de synchronisation en temps réel entre les unités, comme nous l'avions fait précédemment, et avec cette configuration en tête, nous avons intégré notre signal de synchronisation en temps réel dans le lien MuSE, de sorte que toutes les communications se font maintenant sur un seul lien.
• Enfin, l'un de nos clients de longue date avait acheté plusieurs de nos châssis (OP5600, OP4520, OP5707, OP4510) et souhaitait les réutiliser pour un projet plus important qu'il préparait. L'ajout de la fonction MuSE lui permet de connecter ses OP4510 et OP4520 à l'OP5707 pour collecter des données de mesure, tout en étant capable de déconnecter facilement un OP4510 pour l'utiliser comme châssis autonome dans d'autres expériences, si nécessaire".

IV : Nous avons beaucoup parlé du matériel, mais vous avez mentionné que la couche logicielle constituait une grande partie du lien. Qu'apporte-t-elle exactement en termes d'extensibilité ?

IP : "La facilité d'utilisation, tant pendant la préparation du modèle que pendant l'exécution de la simulation, était notre principal objectif. Dans le passé, nous avions développé une interface générique Xilinx Aurora que les utilisateurs pouvaient utiliser pour préparer les flux de bits FPGA pour notre châssis. Mais la gestion de l'empaquetage/dépaquetage des données et des contraintes temporelles du protocole était fastidieuse, et nous avons compris que nos utilisateurs étaient manifestement plus intéressés par le développement de leurs algorithmes de contrôle que par la résolution de ces problèmes de bas niveau. Désormais, l'intégration d'Aurora dans le flux binaire est entièrement prise en charge par notre boîte à outils RT-XSG lors de la génération du flux binaire".

"Pour le modèle CPU, nous avons facilité les choses grâce aux interfaces RT-LAB et HYPERSIM : l'utilisateur n'a qu'à ajouter des unités distantes par le biais des interfaces graphiques. Le flux binaire du simulateur n'aura pas besoin d'être modifié si les utilisateurs ont besoin d'utiliser une unité distante supplémentaire plus tard - tout est pris en charge. C'est beaucoup plus convivial et c'est un grand pas en avant !"

IV : Assez exceptionnel, et nous les avons tous aidés. Ce que nous appelons MEA (More Electric Aircraft), ou les bateaux électriques, par exemple, il n'est pas difficile d'imaginer un scénario dans lequel nous aurions besoin de 4 056 connecteurs ! Compte tenu de la complexité électrique/électronique croissante de certains réseaux et infrastructures de transport et autres réseaux et infrastructures électroniques, en l'occurrence.

IP : "Nous savons, grâce aux installations que je vous ai décrites plus haut, que ces configurations fonctionnent de manière fiable. En sachant cela et en allant de l'avant, en termes d'extensibilité, c'est plus une question de temps, de latence - quelle quantité de données pouvez-vous transférer dans un pas de temps ? Mais les considérations sont les mêmes que pour le PCIe. Nous commençons à atteindre le plafond à un moment donné, mais il ne s'agit pas d'une limitation propre à MuSE ou imposée par OPAL-RT.

IV : Et en termes de performances, les fibres optiques réduisent-elles le temps de latence ?

IP : "En fait, ce n'est pas le lien lui-même qui supprime la latence, mais le fait que nous n'avons plus besoin d'utiliser un ou plusieurs slots PCIe gérés par la carte mère du châssis, et différentes cartes et câbles d'interconnexion PCIe avec différents châssis. Nous avons donc gagné un meilleur contrôle en utilisant le lien Aurora, et la seule connexion PCIe restante est entre la carte mère du simulateur et le FPGA interne du simulateur. Le reste de la communication se fait directement entre les FPGA des différents châssis. Nous contrôlons également l'énumération du réseau, la détection du nombre et du type de châssis connectés, etc.

IV : D'après votre expérience, s'agit-il d'une configuration très spécialisée pour un certain type d'utilisateur ?

IP: "Pas du tout, peut-être même au contraire. Auparavant, lorsque nous avions des connexions PCIe, les utilisateurs ne devaient pas s'en préoccuper, c'était la carte mère qui s'en chargeait. Nous voulions donc avoir la même facilité d'utilisation avec les SFP et les fibres optiques. En général, tout ce que l'utilisateur a à faire est de câbler les SFP et de configurer le simulateur et son châssis distant dans RT-LAB ou HYPERSIM. La façon dont les utilisateurs interagissent dans le modèle est la même qu'avec n'importe quel autre châssis - il n'y a rien de spécial à programmer.

IV : Si j'ai bien compris, cela n'augmente pas seulement les E/S de la machine, mais permet également de nombreux autres schémas de connexion. Il ne s'agit donc pas d'une amélioration linéaire de l'utilisation, mais d'une amélioration exponentielle. D'autres développements sont-ils prévus ?

IP: Bien sûr ! Nous sommes parvenus à faciliter l'utilisation du modèle de l'unité centrale et la préparation du flux binaire. Mais nous nous attaquons maintenant à d'autres aspects des communications entre FPGA dont nos utilisateurs ont besoin : modèles distribués sur plusieurs FPGA, communication avec les amplificateurs de puissance, avec les contrôleurs MMC, etc. Je pense que nous n'en sommes qu'à la première phase de ce projet MuSE, et que de nombreuses fonctionnalités intéressantes sont encore à venir !

À propos de la personne interrogée

Irène Pérès a rejoint OPAL-RT en 2001 et a participé au développement des simulateurs OPAL-RT, y compris les pilotes logiciels, les microprogrammes et les aspects de la gestion du matériel.

Elle est aujourd'hui chef de produit et collaboratrice technique et se concentre sur l'évolution des plates-formes OPAL-RT multi-FPGA.
Depuis le début de sa carrière (elle a obtenu un doctorat en physique des plasmas à l'université Paul Sabatier de Toulouse, en France, en 1990), elle conserve un intérêt marqué pour les projets techniques complexes et stimulants, et s'efforce d'apporter de la simplicité à ces défis.