FPGA ou CPU pour la simulation en temps réel de l'électronique de puissance

Principaux enseignements

• Commencez par choisir entre un processeur central (CPU) et un processeur à porte logique programmable (FPGA) en tenant compte du pas de temps fixe, de la latence dans le pire des cas et des limites de gigue, car le non-respect des délais invalidera les résultats HIL plus rapidement que n'importe quel compromis de modélisation.
• Utilisez les processeurs pour les itérations rapides, les modèles multi-domaines plus volumineux et les mises à jour fréquentes, et utilisez les FPGA lorsque la commutation, la protection et la synchronisation des E/S doivent rester déterministes à chaque échantillon.
• Obtenez les meilleurs résultats en termes de coûts et de délais grâce à un partitionnement rigoureux, en conservant uniquement les chemins critiques en termes de timing sur le FPGA et en laissant le reste sur le CPU, afin que votre équipe puisse déboguer et mettre à jour les modèles sans difficulté.

Choisissez un processeur lorsque votre modèle nécessite de la flexibilité, et optez pour un FPGA lorsqu'il nécessite un timing déterministe inférieur à la microseconde.

Ce choix est important car la simulation en temps réel de l'électronique de puissance est rarement limitée par les mathématiques seules ; elle est limitée par le pas de temps, le timing des E/S et le niveau de détail de commutation que vous conservez. L'électronique de puissance traite déjà environ 70 % de l'électricité utilisée aux États-Unis, c'est pourquoi la pression de validation s'exerce à la fois sur les étages de puissance, les commandes, la protection et l'interaction avec le réseau. Si votre simulateur ne respecte pas les délais, votre test de contrôleur devient un test de synchronisation, et non un test de commande.

La simulation basée sur CPU couvrira une grande partie du travail Simulation HIL HIL) car elle est rapide à construire, à itérer et à déboguer. La simulation basée sur FPGA est utile lorsque vos chemins de commutation, de détection ou de protection doivent se comporter comme du matériel sur chaque échantillon, avec des limites strictes en matière de latence et de gigue. Les équipes qui traitent cela comme un problème de partitionnement et de synchronisation, et non comme une rivalité entre processeurs, obtiennent des résultats stables plus rapidement.

Adapter les cibles de pas de temps du solveur de match au CPU ou au FPGA

Un processeur central (CPU) est le mieux adapté lorsque votre intervalle de temps fixe peut être de l'ordre de quelques dizaines de microsecondes tout en permettant d'atteindre vos objectifs de test. Un circuit intégré programmable (FPGA) est le mieux adapté lorsque votre intervalle de temps fixe doit être réduit à quelques microsecondes ou moins tout en respectant tous les délais. La première décision à prendre ne concerne pas la fidélité, mais la planification. Si le simulateur ne peut pas terminer chaque étape à temps, les résultats ne sont plus fiables.

Commencez par la boucle la plus rapide qui doit être fermée en temps réel, puis travaillez vers l'extérieur. La logique de commande et de protection vous pousse vers les plus petits intervalles de temps, tandis que les modèles Énergie thermique ou Énergie tolèrent des intervalles plus importants. Les solveurs CPU gèrent bien de nombreux états continus et sont particulièrement efficaces lorsque vous devez échanger quotidiennement des variantes de modèles, régler des paramètres en direct ou effectuer des balayages par lots sur plusieurs cœurs. Les solveurs FPGA sont particulièrement efficaces lorsque l'exécution parallèle à latence fixe est plus importante que la commodité des nombres à virgule flottante.

Le choix du pas de temps détermine également ce que vous pouvez représenter sans artefacts numériques. Les arêtes de commutation qui sont « trop nettes » pour votre pas se fondront dans l'échantillon suivant et déformeront les valeurs actuelles d'ondulation et de crête. Si votre objectif est la stabilité du contrôleur et le flux de puissance moyen, un pas plus grand et un modèle moyen peuvent être la bonne solution. Si votre objectif est le timing de protection ou la limitation de courant cycle par cycle, le pas de temps fixe une limite inférieure stricte à ce que peut fournir un CPU.

Comparez les exigences en matière de latence, de gigue et de synchronisation des E/S.

« La principale différence entre la synchronisation CPU et FPGA réside dans le déterminisme. »

Un processeur peut offrir une latence moyenne faible, mais il présentera des fluctuations dues à la planification, aux interruptions et aux conflits de bus, à moins que l'ensemble de la pile ne soit conçu pour être déterministe. Un FPGA exécute la logique avec un timing prévisible que vous pouvez définir à l'avance. Si votre test tient compte du pire scénario en termes de timing, les fluctuations sont plus importantes que la vitesse moyenne.

Le timing des E/S devient souvent une exigence cachée. L'échantillonnage des E/S analogiques et numériques doit s'aligner sur le pas du solveur, et les mises à jour des actionneurs doivent se produire à des instants cohérents si vous validez une protection rapide ou une synchronisation PWM. Les systèmes CPU peuvent maintenir un timing serré lorsque le modèle est léger et que la pile logicielle est réglée, mais les modèles lourds et l'activité en arrière-plan augmentent le risque de gigue. Les E/S FPGA peuvent être alignées sur l'horloge, ce qui permet de maintenir la cohérence de l'échantillonnage, du verrouillage et de la détection des fronts entre les exécutions.

Évaluer les limites de fidélité des modèles pour les convertisseurs de puissance à découpage

La fidélité du modèle correspond au budget que vous consacrez au calcul et à la marge de temps. La simulation CPU gère bien les modèles moyens et de type phasor, et elle peut gérer les modèles de commutation uniquement si le pas de temps reste gérable. La simulation FPGA est conçue pour la logique au niveau des commutateurs à des pas de temps très courts, mais vous sacrifiez une partie de la commodité de la modélisation. La bonne cible est le modèle le plus simple qui répond toujours à votre question de test.

Les dispositifs de commutation sont de plus en plus rapides, ce qui augmente la pression sur le timing dans le simulateur. Des transitions de commutation proches de 50 ns ont été démontrées dans des dispositifs en carbure de silicium, ce qui montre à quel point un comportement d'une microseconde peut être détaillé. Vous ne simulerez pas les fronts nanosecondes en temps réel, mais cette vitesse met en évidence pourquoi le temps mort, la récupération des diodes et les effets liés au dv/dt peuvent être sensibles aux choix des étapes du solveur. Si vos critères d'acceptation incluent le courant de crête, les déclenchements par surtension ou les temps de suppression, vous ressentirez rapidement ces limites.

Les décisions de fidélité modifient également ce que vous pouvez valider en toute confiance. Les modèles moyennés permettent un réglage précis de la boucle de contrôle et du comportement du flux de puissance, mais ils peuvent masquer les défauts au niveau du cycle et les ondulations de commutation qui interagissent avec la détection du courant. Les modèles de commutation capturent ces effets, mais ils peuvent vous obliger à simplifier d'autres aspects pour respecter les délais. Une approche pratique consiste à aligner la fidélité sur le signal que vous évaluez, puis à traiter tout détail supplémentaire comme un risque pour l'exécution en temps réel, à moins que vous ne puissiez prouver qu'il reste stable sur tous les points de fonctionnement.

« Choisissez un processeur lorsque votre modèle nécessite de la flexibilité, et optez pour un FPGA lorsqu'il nécessite une synchronisation déterministe inférieure à la microseconde. »

Planification du partitionnement entre CPU et FPGA dans les configurations HIL

Le partitionnement fonctionne lorsque vous attribuez chaque tâche au processeur qui correspond à ses besoins en termes de timing. Les chemins de commutation et de protection rapides ont leur place là où l'exécution est déterministe, tandis que la dynamique des installations plus lentes et la logique de supervision ont leur place là où la modélisation est flexible. L'interface entre les deux doit être échantillonnée, mise à l'échelle et synchronisée avec intention. Si la frontière est floue, vous poursuivrez des artefacts qui ressemblent à des problèmes de contrôle.

Un exemple concret illustre bien ce principe. Une équipe chargée de valider un onduleur à deux niveaux connecté au réseau peut exécuter la génération PWM, la protection contre les surintensités de type comparateur et l'étage de puissance au niveau du commutateur sur FPGA à une cadence inférieure à la microseconde, tandis que l'impédance du réseau, la boucle à verrouillage de phase et les calculs de puissance s'exécutent sur le CPU à une cadence plus élevée avec des transitions de fréquence. Cette séparation permet de respecter les délais serrés là où la protection et la commutation en ont besoin, tout en préservant la marge de manœuvre du CPU pour automatisation des tests automatisation les balayages de paramètres. Les systèmes OPAL-RT sont souvent utilisés dans ce style de calcul mixte, car ils prennent en charge l'exécution du CPU et du FPGA dans un seul flux de travail HIL, ce qui facilite la conception de cette frontière sans avoir à inventer de plomberie personnalisée.

Planifiez la limite comme un contrat d'E/S, et non comme une commodité logicielle. Décidez quels signaux traversent la ligne CPU vers FPGA, choisissez des fréquences d'échantillonnage explicites et définissez comment vous gérez la quantification et la saturation. La latence doit être calculée de bout en bout, y compris l'A/N, l'alignement des étapes du solveur et les mises à jour N/A. Lorsque vous traitez le partitionnement comme une architecture de synchronisation, vous savez quelle partie du système est responsable de chaque microseconde de retard.

Prendre en compte les efforts liés à la chaîne d'outils, au débogage et à la mise à jour des modèles

Les modèles CPU sont rapidement mis à jour, et la boucle de débogage semble familière à la plupart des équipes d'ingénieurs. Les modèles FPGA nécessitent davantage de planification en amont, car la compilation, les limites de ressources et les choix de points fixes font partie intégrante du travail d'ingénierie. Cet effort est payant lorsque vous avez besoin d'un timing déterministe, mais il ralentira l'itération si vous avancez trop tôt. Une approche par étapes permet de faire avancer le projet tout en verrouillant ce qui doit être déterministe.

Le débogage est également différent. Les workflows CPU prennent en charge les points d'arrêt, les profileurs et les reconstructions rapides, tandis que les workflows FPGA s'appuient davantage sur les assertions, la capture de signaux et la vérification minutieuse du timing et de la mise à l'échelle. Les modifications de modèle qui sont insignifiantes sur CPU peuvent nécessiter de retester les plages numériques, de vérifier le comportement de saturation et de valider l'alignement des E/S sur FPGA. Les équipes obtiennent des résultats plus fluides lorsqu'elles traitent le travail FPGA comme une conception embarquée avec des vérifications formelles, et non comme un correctif de performance de dernière minute.

• Votre plus petit pas de temps requis et la marge de calcul la plus défavorable à ce pas.
• Votre pire cas autorisé en matière de gigue sur les signaux PWM, de déclenchement et de protection échantillonnée.
• Votre plan pour les vérifications de plage de virgule fixe, de mise à l'échelle et de saturation.
• Fréquence prévue des modifications apportées au modèle après la première base de référence stable.
• Votre capacité à reproduire le timing et le comportement numérique sur différents bancs d'essai.

Les risques liés aux coûts et au calendrier proviennent généralement des frictions dans le flux de travail, et non du calcul brut. Le travail du processeur peut s'étendre si vous continuez à ajouter des détails jusqu'à ce que les délais soient dépassés, tandis que le travail du FPGA peut être bloqué si vous commencez avec une portée trop large et une structure de vérification trop faible. Définissez des garde-fous autour de ce que signifie « terminé » en termes de timing, de fidélité et de comportement des E/S. Cette discipline permet à l'équipe de rester alignée lorsque les résultats des tests deviennent bruyants.

Choisissez une plateforme de simulation HIL plateforme s'adapte à vos projets

plateforme HIL vous plateforme utile lorsqu'elle vous permettra de respecter les délais, de maintenir un comportement traçable du modèle et de conserver une vitesse d'itération élevée à mesure que les projets prennent de l'ampleur. La capacité du processeur à elle seule ne suffira pas à sauver un banc d'essai qui nécessite des E/S déterministes, et le déterminisme du FPGA à lui seul ne suffira pas à sauver un banc qui nécessite des changements constants de modèle et une portée multidomaine. Le meilleur choix est généralement une plateforme prend en charge le calcul CPU et FPGA et vous permet de repousser les limites sans tout réécrire. Vous achetez davantage un modèle d'exécution reproductible qu'un type de processeur.

Concentrez-vous sur quelques plateforme qui ont une incidence sur le travail quotidien. La synchronisation déterministe des E/S, la gestion claire des transitions de débit et les outils de synchronisation fiables seront importants chaque semaine. La modularité du matériel est importante, car le nombre de canaux et les types de capteurs ont tendance à augmenter d'un programme à l'autre. L'ouverture du logiciel est importante, car votre équipe connectera MATLAB, Python, des séquenceurs de test et des pipelines de données, et les piles fermées transforment une simple intégration en un projet.

Un bon jugement technique se reflète dans la manière dont vous maintenez l'intégrité du simulateur au fil du temps. Définissez rapidement les contraintes de temps, puis ajoutez de la fidélité uniquement lorsque cela modifie le résultat positif ou négatif. Gardez les modèles CPU flexibles pour l'apprentissage et concentrez les modèles FPGA sur les parties où le déterminisme est incontournable. OPAL-RT correspond à cette approche axée sur l'exécution lorsque vous avez besoin des deux types de calcul sur le même banc, ce qui vous permet de traiter le FPGA comme un outil de synchronisation précis et le CPU comme un outil d'itération, au lieu de forcer l'un à faire les deux tâches.