Simulation CPU contre FPGA pour les essais de moteurs à grande vitesse

Principaux enseignements

• Choisissez la simulation CPU lorsque vos objectifs HIL tolèrent des pas fixes plus importants et un délai d'E/S constant, et que vos critères de réussite se concentrent sur la logique de contrôle et le comportement électrique moyen.
• Exigez une simulation FPGA lorsque vos tests dépendent de fronts de commutation, d'un timing à la microseconde près et d'une réponse de protection déterministe qu'un CPU ne peut garantir dans les conditions de charge les plus défavorables.
• Verrouillez votre choix à l'aide de critères d'acceptation mesurables pour la taille des étapes, la marge de dépassement et la latence d'E/S de bout en bout, puis adaptez la fidélité du modèle aux défauts que vous devez valider.

Optez pour la simulation CPU jusqu'à ce que la synchronisation à la microseconde près devienne une exigence incontournable pour les tests.

Les tests à grande vitesse des entraînements à moteur échouent lorsque votre simulateur lisse les événements qui déclenchent la protection, saturent les capteurs de courant ou déstabilisent une boucle de courant rapide. Les moteurs électriques représentent environ, il est donc important de bien comprendre le comportement des entraînements, bien au-delà d'un simple projet de contrôleur.

La simulation CPU vs FPGA n'est pas un concours de fiches techniques.

Le séparateur pratique est la certitude du timing à la taille de pas dont vous avez besoin, ainsi que la latence d'E/S qui reste prévisible lorsque la boucle est fermée via Simulation HIL HIL). Commencez par vos objectifs de test, rédigez des critères d'acceptation et choisissez le calcul le plus simple qui les satisfera à chaque fois.

Choisissez un CPU ou un FPGA en fonction des objectifs HIL du variateur moteur.

La principale différence entre la simulation CPU et FPGA réside dans la manière dont elles gèrent le temps et la concurrence dans l'exécution en temps réel. Un CPU exécute très rapidement le code séquentiel, mais reste confronté aux fluctuations de planification et aux limites de taille de pas. Un FPGA exécute de nombreuses opérations en parallèle avec un timing déterministe, ce qui est important lorsque votre test dépend du comportement de commutation sous-cycle.

Le HIL basé sur CPU est idéal pour valider la logique de contrôle, les séquences de démarrage, les machines à états de défaut et la surveillance qui dépend du comportement électrique moyen. Le HIL basé sur FPGA est idéal lorsque vous devez représenter les fronts de commutation, les effets de temps mort et les chemins de protection rapides sans les masquer dans un grand pas de temps. Une approche mixte fonctionne également bien lorsque seul l'étage de puissance nécessite une résolution de l'ordre de la microseconde.

Connaître les limites temporelles qui interrompent la simulation basée sur le CPU

La simulation CPU s'interrompt lorsque le pas de temps fixe requis devient si petit que le solveur et les tâches d'E/S ne peuvent pas être terminés avant le prochain tick. Les délais non respectés se traduisent par des dépassements, des fluctuations ou des augmentations forcées de la taille des pas, et ces artefacts corrompent les mesures que vous utilisez pour évaluer la qualité du contrôleur.

Le risque lié au timing augmente lorsque vous empilez des modèles de commutation, le filtrage des capteurs et la gestion des interfaces dans la même boucle. Un processeur plus rapide aide, mais le déterminisme dépend toujours du temps d'exécution dans le pire des cas, et non des performances moyennes. Les configurations multicœurs peuvent également vous surprendre si les threads se disputent la mémoire ou si la gestion des E/S vole des cycles au mauvais moment.

L'acceptation pratique commence par un budget de temps serré : temps de résolution de l'installation plus échantillonnage E/S, plus toute journalisation, plus marge de sécurité. Si vos tests nécessitent des étapes de l'ordre de quelques microsecondes et une boucle de fermeture serrée vers les contrôleurs physiques, une approche basée uniquement sur le CPU se transforme en une lutte constante contre la marge. Lorsque l'étape requise est moins stricte, la simulation CPU reste productive et plus facile à itérer.

Utiliser la simulation FPGA pour la fidélité de l'électronique de puissance à commutation

La simulation FPGA est nécessaire lorsque la fidélité au niveau de la commutation est le critère de test, et non un détail que vous pouvez ignorer. L'exécution parallèle déterministe vous permet de représenter le comportement au niveau du dispositif, la synchronisation PWM et les chemins de protection rapides à des intervalles de temps très courts. Cette fidélité permet de garder les défauts, les ondulations et les effets de commutation visibles pour le contrôleur.

Des fréquences de commutation plus élevées vous poussent vers cette approche, car le système électrique change davantage au cours de chaque période de contrôle. Les semi-conducteurs à large bande interdite peuvent prendre en charge des fréquences de commutation jusqu'à 10 fois supérieures que les dispositifs en silicium, ce qui resserre les exigences de synchronisation pour tout test qui tient compte de l'ondulation du courant, des effets liés au dv/dt ou de la protection cycle par cycle.

Le travail sur FPGA ajoute effectivement des contraintes. Le développement de modèles utilise souvent l'arithmétique en virgule fixe, une mise à l'échelle minutieuse et un partitionnement explicite entre ce qui doit fonctionner en microsecondes et ce qui peut fonctionner plus lentement. Des plateformes telles que OPAL-RT sont couramment utilisées pour répartir clairement les charges de travail entre le CPU et le FPGA, ce qui vous permet de conserver un timing déterministe rapide pour l'étage de puissance tout en laissant la logique de supervision et le contexte système plus large sur le CPU.

Adapter la taille des pas du solveur de correspondance à la fréquence PWM et aux boucles de contrôle

La sélection de la taille des pas doit commencer par le phénomène le plus rapide que votre test doit observer, puis remonter jusqu'à ce que le contrôleur fera avec ces informations. Si vous n'avez besoin que d'un couple moyen et d'une réponse de vitesse, vous pouvez utiliser des pas plus grands et simplifier la commutation. Si vous avez besoin d'un comportement cycle par cycle, la taille des pas doit être suffisamment petite pour le préserver.

Une vérification concrète aide : une période PWM de 20 kHz est de 50 µs, et une boucle de courant peut fonctionner à plusieurs kHz en plus de cela. L'utilisation d'un pas de 25 µs ne vous laissera que deux points par période de commutation, ce qui étalera l'ondulation de commutation et pourra masquer le courant de crête qui déclenche la protection. Un pas de 1 µs à 2 µs résout une bien plus grande partie de la période de commutation et maintient le comportement de crête visible à la fois pour la logique de défaut logicielle et matérielle.

Le choix du solveur et le partitionnement sont tout aussi importants que la taille brute du pas. Les modèles d'onduleurs moyens peuvent être valables pour le réglage des commandes et les études d'efficacité, mais ils ne permettent pas de valider la synchronisation des portes, la compensation du temps mort ou les chemins de désaturation précis au cycle près. Les modèles de commutation exigent également que vous traitiez l'échantillonnage, la quantification et le retard comme des éléments essentiels du test, et non comme des éléments secondaires.

Vérifier la latence d'E/S et les besoins en matière d'interface pour les essais de moteurs

La latence d'E/S fait partie intégrante de l'installation lorsque vous fermez la boucle via HIL. Le contrôleur réagit aux courants, tensions et positions mesurés, et s'attend à ce que ces signaux arrivent avec un délai stable. Si ce délai varie, les résultats du réglage ne seront pas pris en compte et la validation de la protection perdra toute crédibilité.

Commencez par les interfaces que votre contrôleur utilise réellement : sorties PWM, commandes de porte, rétroaction de courant, détection de liaison CC, position du codeur ou du résolveur et lignes de défaut. Chaque chemin de signal ajoute un temps de conversion, une mise en mémoire tampon et une surcharge de planification, et le total doit rester dans les limites de votre budget de boucle. La latence déterministe est souvent plus importante que la latence minimale, car un retard constant peut être compensé, tandis que la gigue se transforme en bruit de phase.

Le partitionnement matériel est un outil de synchronisation, pas seulement un outil de calcul. La capture et la génération rapides d'E/S s'associent naturellement à l'exécution FPGA lorsque vous avez besoin d'une réponse répétable à l'échelle de la microseconde. L'exécution CPU convient lorsque vos interfaces sont plus lentes, vos périodes de contrôle plus longues ou votre objectif principal est le comportement fonctionnel plutôt que la synchronisation au niveau de la périphérie.

Évitez les erreurs courantes dans la sélection et définissez des critères d'acceptation clairs.

L'erreur courante consiste à choisir d'abord le calcul, puis l'intention du test. Les configurations basées uniquement sur le CPU échouent lorsque les équipes supposent que les performances moyennes sont égales aux performances déterministes, ou lorsqu'elles demandent à un modèle d'usine de grande taille de fonctionner à des intervalles de l'ordre de la microseconde. Les configurations basées uniquement sur le FPGA échouent lorsque les équipes passent du temps à modifier des détails que le plan de test n'utilise jamais.

Rédigez des critères d'acceptation mesurables lors de la mise en service, puis respectez-les. Veillez à ce que ces critères soient liés aux chemins d'échantillonnage et de protection réels de votre contrôleur, et non aux performances générales déclarées du simulateur. Alignez les détails du modèle sur les cas de défaillance que vous devez approuver, et réduisez tout le reste à ce qui prend en charge ces cas.

• Votre pas de temps fixe restera stable dans les pires scénarios de défaillance.
• Le délai d'E/S de bout en bout sera répétable dans les limites de votre budget de boucle.
• Les détails de commutation n'apparaîtront que lorsque votre test en aura besoin.
• Les dépassements et les variations seront consignés et traités comme des échecs de test.
• La portée du modèle correspondra aux questions de validation, et non aux préférences de l'équipe.

La simulation CPU vs FPGA cesse d'être un sujet de débat lorsque vous considérez le timing et la latence comme des exigences techniques.

Choisissez le CPU lorsqu'il répond aux critères de taille de pas et de stabilité des E/S que vous pouvez prouver lors de la vérification HIL, et choisissez le FPGA lorsque la dynamique de commutation et la réponse déterministe font partie des critères de réussite. Les équipes qui appliquent cette discipline sur les plateformes OPAL-RT ont tendance à avancer plus rapidement en laboratoire, car le choix du simulateur est fondé sur un comportement mesurable et non sur des hypothèses.