Quand utiliser un processeur ou un FPGA pour la simulation en temps réel

Principaux enseignements

• Le choix du processeur et du FPGA doit se faire en fonction des contraintes de synchronisation et de la structure du modèle, et non en raison d'une préférence générale pour davantage de matériel.
• Les sections à commutation rapide doivent être exécutées sur le matériel FPGA, tandis que les modèles d'installation plus généraux sont généralement exécutés sur le processeur.
• Une architecture hybride offre le meilleur compromis entre fidélité, évolutivité et efficacité des tests lorsque la partition est soigneusement planifiée.

Optez pour un FPGA lorsque la commutation d'événements, la logique de protection ou la synchronisation des impulsions doivent être gérées à l'échelle de la sous-microseconde. Cet écart prend de plus en plus d'importance chaque année, à mesure que les systèmes électrifiés gagnent en complexité et que les bancs d'essai laissent de moins en moins de place à l'erreur. Les ventes de voitures électriques ont dépassé 17 millions dans le monde en 2024, ce qui signifie que de plus en plus de conceptions d'onduleurs, de chargeurs et de commandes de moteurs passent par des processus de validation qui dépendent de tests en temps réel précis.

« Optez pour un processeur lorsque votre modèle est volumineux, très étendu sur le plan électrique et capable de gérer des incréments de l'ordre de la microseconde. »

Les équipes se heurtent à des difficultés lorsqu'elles considèrent le CPU et le FPGA comme des options de calcul interchangeables. Il s'agit en effet de modèles d'exécution distincts, présentant chacun des atouts, des limites et des profils de coûts différents. Pour faire les bons choix architecturaux, il faut adapter les contraintes de synchronisation, la structure du modèle et les exigences en matière d'E/S au chemin de traitement approprié, puis ne conserver les calculs physiques les plus rapides que là où le matériel le plus performant est réellement nécessaire.

Les performances de la simulation en temps réel dépendent des choix d'architecture de calcul

Le choix du processeur et du FPGA relève principalement de considérations de synchronisation et de structure du modèle, et non d'une question de marque ou de préférence.

Un processeur central (CPU) est particulièrement performant lorsque votre modèle d'installation comprend de vastes réseaux, des dynamiques électromécaniques plus lentes et de nombreux éléments pouvant partager un pas de temps fixe plus long. Une étude de réseau comprenant des lignes d'alimentation, des transformateurs, des machines et des commandes de supervision correspond généralement à ce profil. Un FPGA devient le choix idéal lorsque la simulation doit prendre en compte les fronts de commutation, les temps morts, les interactions PWM ou les comportements de protection à l'échelle de la nanoseconde, que le processeur séquentiel ne peut pas gérer de manière déterministe.

Cette distinction est importante, car l'exécution en temps réel échoue dès que le temps de calcul dépasse la durée allouée à l'étape concernée. Dès lors, le modèle cesse d'être une reproduction fidèle du matériel. On se retrouve alors à déboguer un problème de synchronisation plutôt que le système lui-même. Le choix le plus sûr consiste rarement à utiliser partout le matériel le plus rapide possible. Le choix le plus sûr consiste à choisir l'architecture qui correspond au comportement le plus rapide devant être représenté, puis à laisser tout ce qui est plus lent sur la plateforme la plus flexible.

La simulation par processeur permet d'adapter des modèles de systèmes de grande envergure présentant une dynamique de commutation modérée

La simulation sur processeur est la solution idéale lorsque la taille du modèle, la souplesse du solveur et la facilité d'itération priment sur une résolution temporelle extrême.

Une étude de protection pour un micro-réseau en est un bon exemple. Vous aurez peut-être besoin de lignes d'alimentation, de sources, de disjoncteurs, de transformateurs et de modèles de machines, mais il n'est pas nécessaire de modéliser chaque événement de commutation à l'intérieur de chaque convertisseur à l'échelle de la nanoseconde. Un processeur est capable de gérer cette vision globale du système avec des pas de temps réalistes et des mises à jour de modèles plus simples. L' étude de cas avec Harvest le montre clairement ce principe. Le côté redresseur d’un variateur moyenne tension utilisait une commutation plus lente ; un pas de temps de l’ordre de quelques dizaines de microsecondes était donc suffisant, faisant de l’exécution sur CPU le choix le plus économique pour cette partie du modèle.

Vous devriez également privilégier l'exécution sur CPU lorsque le flux de travail de test évolue fréquemment. Les équipes chargées des contrôles ont généralement besoin de modifications rapides, de balayages répétés des paramètres et d'un accès plus aisé à de vastes bibliothèques de composants système. Ces tâches revêtent une importance particulière lors des premières phases de validation, où la couverture du modèle prime souvent sur les détails au niveau des commutateurs. La capacité du CPU est certes limitée, mais c'est généralement par là qu'il faut commencer lorsque votre modèle est vaste et que votre objectif de synchronisation se mesure en microsecondes, et non en nanosecondes.

La simulation basée sur un FPGA prend en charge des pas de temps de l'ordre de la nanoseconde et des modèles à haute fréquence de commutation

La simulation sur FPGA est la solution idéale lorsque votre modèle doit s'exécuter avec une synchronisation hautement déterministe et par très petits pas.

Un banc d'essai HIL pour convertisseurs de puissance en est l'exemple le plus parlant. Si votre contrôleur réagit au comportement PWM au niveau de la porteuse, aux effets de temps mort ou aux transitions rapides en cas de défaut, un processeur ne pourra pas offrir la même précision de synchronisation qu'une logique matérielle dédiée. L'exemple de variateur mis en ligne mentionne l'utilisation de FPGA pour les modèles d'électronique de puissance dont les fréquences de commutation dépassent 200 kHz et dont les pas de temps sont de l'ordre de la nanoseconde. C'est précisément dans ce domaine que le recours aux FPGA cesse d'être facultatif pour devenir indispensable.

Le revers de la médaille, c'est la rigueur en matière de développement. Les ressources des FPGA sont limitées, et les modèles de commutation détaillés les épuisent rapidement. Il faut un partitionnement plus rigoureux, une planification plus claire des signaux et une bonne compréhension des comportements qui doivent rester explicites. Cet effort s'avère payant lorsque le contrôleur testé est sensible à l'ordre exact et au timing des événements électriques. Les FPGA ne sont pas simplement des processeurs plus rapides. Ils sont mieux adaptés aux opérations parallèles répétitives qui doivent se dérouler à des intervalles précis, avec très peu de variations de timing.

Le comportement de commutation de l'électronique de puissance détermine souvent à quel moment il devient nécessaire d'utiliser un FPGA

Le comportement de commutation est généralement le premier indice technique qui permet de deviner qu'un modèle basé uniquement sur le CPU passera à côté d'événements importants.

Prenons l'exemple d'un système d'entraînement moyenne tension en cascade. Le Cette réussite de Harvest décrit des sous-modules à pont complet unique commutant à une fréquence comprise entre 500 et 1 000 Hz, tandis que le déphasage et le temps mort PWM font grimper la fréquence de commutation globale par phase jusqu’à 10 kHz. Ce même modèle comprenait 24 modules triphasés à pont complet, 72 connexions transformateur-redresseur et jusqu’à 96 commutateurs. Un processeur peut encore simuler certaines parties de ce système, mais c'est dans les sections à commutation intensive que la pression temporelle s'accumule rapidement.

Cette pression ne se limite pas aux variateurs. On observe le même phénomène dans les onduleurs de traction, les bancs d'essai de batteries, les convertisseurs de formation de réseau et la validation des chargeurs rapides. Dès lors que les décisions de votre contrôleur dépendent de la synchronisation des fronts plutôt que de la réponse électrique moyenne, les petites erreurs de synchronisation cessent d'être anodines. La demande mondiale en électricité devrait augmenter de 4,3 % en 2024, ce qui a accru la pression sur les ingénieurs pour qu'ils valident avec une plus grande fiabilité des systèmes comportant davantage de convertisseurs. C'est l'une des raisons pour lesquelles la fidélité de commutation est passée d'une préoccupation de spécialistes à un critère d'architecture courant.

Modéliser des stratégies de partitionnement qui combinent efficacement l'exécution sur CPU et sur FPGA

L'exécution hybride est particulièrement efficace lorsque le FPGA gère les domaines à commutation rapide et que le processeur gère les dynamiques plus lentes au niveau électrique et au niveau du système.

Un variateur moyenne tension offre un modèle pratique. L'onduleur et l'électronique de puissance côté moteur peuvent rester sur le FPGA, là où la résolution de commutation et les E/S déterministes sont les plus importantes. Le transformateur, le redresseur, la logique de supervision et le contexte global de l'installation peuvent rester sur le CPU si leur dynamique s'accorde mieux à des pas plus grands. La section de redressement, plus lente, est restée sur le CPU, tandis que le comportement du convertisseur à grande vitesse a été confié à l'exécution sur le FPGA.

Un bon partitionnement obéit à quelques règles simples :

• Intégrer la commutation au niveau du support et des chemins de protection rapides dans le FPGA.
• Conservez les réseaux électriques étendus et les dynamiques d'installation plus lentes sur le processeur.
• Ne franchissez la frontière entre le processeur et le FPGA que lorsque les signaux varient suffisamment lentement.
• Réduire au minimum les interactions bidirectionnelles qui imposent une charge importante liée à la synchronisation.
• Testez les marges de temps dès le début à l'aide d'une exécution en boucle ouverte avant l'intégration du contrôleur.

Le partitionnement n'est pas seulement un choix technique. Il influe sur la fiabilité du modèle. Une mauvaise répartition engendre des goulots d'étranglement au niveau des interfaces, des retards artificiels et un travail de débogage qui masque le véritable problème de contrôle. Une répartition rigoureuse transforme l'architecture hybride en un avantage technique indéniable.

Les contraintes liées au coût, à l'évolutivité et à l'intégration qui déterminent les choix architecturaux

Le choix de l'architecture doit privilégier la configuration la moins coûteuse qui permette néanmoins de garantir le comportement auquel vous devez pouvoir vous fier.

Un laboratoire qui teste un contrôleur de moteur sur de nombreux points de fonctionnement tire généralement un meilleur parti d'une configuration axée sur le calcul CPU dans un premier temps. Il est ainsi possible de modéliser l'installation environnante, de tester les E/S du contrôleur et d'affiner les cas limites sans surcharger un matériel rapide et coûteux avec des détails de modèle qui n'apportent que peu de valeur ajoutée. 

L'évolutivité est également un facteur important. Dès lors que l'on passe à un plus grand nombre de convertisseurs, à davantage de capteurs ou à des exigences d'E/S d'une grande densité, la question ne porte plus uniquement sur la puissance de calcul brute, mais aussi sur l'architecture du système. Les liaisons optiques, l'extension synchronisée et les E/S modulaires prennent alors autant d'importance que le choix du solveur. C'est là que plateforme s'intègre à la conception de l'architecture. Les systèmes OPAL-RT sont souvent utilisés dans ce type de workflow, car les équipes ont besoin d'une évolution des capacités CPU, FPGA et E/S au sein d'un même chemin de test, et non pas de décisions distinctes. La leçon à en tirer dépasse le cadre d'une plateforme particulière. Vous devez considérer l'architecture, les E/S et la synchronisation comme un seul et même problème de conception dès le départ.

Erreurs courantes de modélisation qui empêchent les simulations sur CPU de respecter les délais en temps réel

Les simulations sur processeur ne respectent pas les délais lorsque le modèle contient trop de détails de calcul rapide à des endroits qui ne sont pas adaptés à un solveur séquentiel.

Une erreur courante se produit dans les études de convertisseurs où l'on importe directement des modèles hors ligne dans un environnement en temps réel. Le modèle conserve tous les dispositifs de commutation sous forme explicite, maintient des couplages inutiles entre les sous-systèmes et utilise un pas de temps agressif pour l'ensemble du système. Cela semble rigoureux, mais entraîne généralement des dépassements. Une autre erreur fréquente consiste à lier trop étroitement les sections de convertisseurs à haute vitesse à des réseaux plus lents, ce qui oblige l'ensemble du modèle à fonctionner plus vite que nécessaire.

La partie redresseur, plus lente, est restée sur le processeur central, tandis que les comportements de commutation plus exigeants ont été déplacés ailleurs. Le modèle s'est également appuyé sur le partitionnement du solveur pour découpler plus de vingt convertisseurs d'un transformateur à enroulements multiples, afin de respecter les contraintes de synchronisation en temps réel. Vous devriez adopter la même approche dans votre propre travail. Éliminez les détails superflus, séparez dès le début les domaines rapides et lents, et testez les marges de synchronisation avant de déclarer le modèle prêt pour les essais HIL.

Les plateformes hybrides associant CPU et FPGA offrent des performances évolutives pour les essais HIL complexes

« Les plateformes hybrides constituent le meilleur choix à long terme pour les simulations HIL complexes lorsque seule une partie du système nécessite une précision temporelle extrême. »

Ce constat découle de la mise en œuvre pratique, et non de la théorie. La plupart des bancs d'essai avancés combinent des processus physiques lents et rapides, un contexte d'installation étendu et des E/S orientées vers le contrôleur qui doivent rester fiables même en cas de défaillance. Une approche purement CPU manque de marge de manœuvre en termes de synchronisation. Une approche purement FPGA devient coûteuse et rigide si l'on impose à l'ensemble de l'installation une logique matérielle. Une architecture hybride résout ce problème lorsque la répartition est bien définie et que les interfaces sont claires.

Un seul banc d'essai a permis de prendre en charge plusieurs types de moteurs, les conditions de défaillance ont été reproduites en toute sécurité et les problèmes de contrôle ont été mis en évidence plus tôt dans le processus de développement. C'est le résultat auquel vous devez aspirer. OPAL-RT s'inscrit naturellement dans ce tableau final, car son travail sur la co-exécution CPU-FPGA reflète la manière dont les laboratoires de pointe construisent déjà des systèmes de test performants. Une bonne simulation en temps réel ne consiste pas à choisir un processeur au hasard en espérant que tout se passe bien. Il s'agit d'adapter chaque partie du modèle au matériel qui l'exécutera fidèlement.