Quand ajouter l'accélération FPGA à un simulateur temps réel existant ?

Principaux enseignements

• N'ajoutez l'accélération FPGA qu'après que les données de synchronisation aient révélé un goulot d'étranglement déterministe qui bloque votre intervalle de temps requis, votre latence de bout en bout ou vos limites de gigue.
• Ciblez le travail FPGA sur la plus petite tranche à haut débit que vous ne pouvez pas planifier de manière fiable sur les CPU, en particulier les services d'E/S serrés et les chemins de rétroaction répétables à faible latence.
• Contrôlez les coûts et les risques grâce à un contrat d'interface fixe, une référence CPU pour la vérification et des tests d'acceptation qui prouvent à la fois la correspondance numérique et la stabilité du timing en boucle fermée.

Ajoutez l'accélération FPGA lorsque votre simulateur en temps réel ne parvient pas à respecter les délais déterministes avec la fidélité dont vous avez besoin.

Lorsque le timing est décalé, vous cessez de tester la qualité du contrôle et commencez à tester la chance en matière de planification. Cet écart se traduit par un comportement en boucle fermée instable, de faux échecs et des solutions de contournement telles que la décimation, qui masquent les problèmes mêmes que le HIL est censé mettre en évidence. Les défauts logiciels coûtent à l'économie américaine environ 59,5 milliards de dollars chaque année, ce qui nous rappelle que la découverte tardive coûte cher, même avant d'ajouter le risque de dommages matériels et les temps d'arrêt des laboratoires.

« La position pratique est simple : le travail sur FPGA se justifie lorsqu'il élimine un goulot d'étranglement spécifique et mesurable qui bloque le pas de temps, la latence ou le déterminisme d'E/S requis. »

Si vous ne pouvez pas identifier le goulot d'étranglement et le prouver à l'aide de données de synchronisation, vous n'êtes pas prêt à passer à la vitesse supérieure. Si vous le pouvez, un FPGA est souvent le moyen le plus direct d'obtenir des résultats HIL stables et reproductibles sans dégrader le modèle.

Signes indiquant que votre modèle HIL basé sur CPU ne respecte pas les délais

Le HIL basé sur CPU est hors service lorsque le simulateur manque son pas de temps fixe, présente une instabilité temporelle qui se répercute sur les E/S ou impose des simplifications du modèle qui modifient les résultats de contrôle. Vous constaterez des dépassements, des ralentissements sporadiques du solveur et des horodatages d'E/S qui ne correspondent plus à l'horloge d'échantillonnage prévue. Ces symptômes indiquent que le déterminisme est déjà compromis.

Commencez par des mesures, pas par des intuitions. Votre première vérification concerne le compteur de dépassement et le pire cas de figure en termes de temps d'exécution pour le modèle, plus le service d'E/S. Si le pire cas se rapproche de la taille du pas, le laboratoire fonctionnera « correctement » jusqu'à ce qu'un pic de planification rare déséquilibre la boucle. C'est également à ce moment-là que les ingénieurs commencent à ajouter des délais tampons, à réduire les taux d'échantillonnage ou à désactiver certaines parties de l'usine, et ces corrections modifient discrètement ce que vous validez.

Soyez également attentif aux problèmes qui n'apparaissent que dans des conditions de stress en boucle fermée. Un modèle qui fonctionne sans matériel connecté peut tout de même échouer dès que des interruptions, des pilotes de périphériques et des E/S à haut débit viennent s'ajouter à la boucle. Lorsque vous avez besoin d'une réponse déterministe, la question n'est pas la charge moyenne du processeur. La question est la latence et la gigue dans le pire des cas, aux points exacts où le contrôleur échange des données avec l'installation.

Charges de travail qui bénéficient le plus de l'accélération FPGA dans la simulation

L'accélération FPGA est rentable lorsque le goulot d'étranglement est un travail parallèle et urgent qu'un CPU ne peut pas planifier de manière déterministe à votre rythme cible. Cela inclut les services d'E/S serrés, l'horodatage sous-cycle et les calculs mathématiques pouvant être exécutés en pipelines parallèles. Si le travail se répète à chaque étape et doit être terminé à temps, un FPGA est tout indiqué.

Les performances des processeurs à un seul cœur n'ont augmenté que de 2,9 % par an entre 2011 et 2018. Attendre le « processeur de l'année prochaine » ne permettra donc pas de sauver un modèle à pas fixe surchargé. Cela est important pour le HIL, car les cas les plus difficiles ne sont pas seulement ceux qui nécessitent des calculs lourds, mais aussi ceux qui doivent être effectués dans un délai strict à chaque cycle, avec la même latence à chaque fois.

Un cas concret est celui d'un banc HIL pour onduleur de traction EV, où vous devez ingérer plusieurs signaux PWM, calculer le comportement de l'installation lié à la commutation en quelques microsecondes et renvoyer le courant et la tension suffisamment rapidement pour maintenir la stabilité d'un contrôleur à large bande passante. Un CPU peut résoudre une grande partie du problème, mais la capture PWM, la gestion du temps mort et le chemin de retour à très faible latence deviennent souvent des facteurs limitants. La logique FPGA peut prendre en charge cette partie déterministe tandis que le CPU conserve intactes la dynamique plus lente et la logique de supervision.

Cibles de latence, d'E/S et de gigue qui justifient l'utilisation d'un FPGA

Le recours au FPGA se justifie lorsque votre budget de latence est plus serré que ce que peuvent garantir un CPU et sa pile d'E/S, même si les performances moyennes semblent satisfaisantes. Le déclencheur le plus évident est lorsque vous ne pouvez pas respecter le pas de temps fixe requis avec une marge, ou lorsque la gigue modifie le temps d'échantillonnage effectif vu par le contrôleur. Cela transforme les tests répétables en tests incohérents.

Définissez des objectifs à l'aide de la boucle de contrôle que vous validez, et non un objectif générique du type « rapide, c'est bien ». Si un contrôleur attend un retour d'information toutes les 50 microsecondes, une latence de bout en bout constante est tout aussi importante que la taille brute du pas. Une gigue qui retarde une petite fraction des cycles peut être pire qu'une boucle légèrement plus lente mais stable, car elle introduit un bruit de synchronisation dans l'algorithme de contrôle et peut déclencher des protections.

Comment estimer l'effort, le coût et les risques avant la mise à niveau

« La victoire, c'est un comportement HIL stable auquel vous pouvez vous fier à chaque exécution. »

L'effort et le coût dépendent moins du matériel FPGA que de la capacité à isoler clairement ce qui doit être déterministe. Une bonne estimation commence par un budget de temps, une limite de partition claire et un plan de vérification qui prouve que le chemin FPGA correspond au modèle CPU là où il le devrait. Le risque augmente lorsque les exigences sont vagues ou lorsque la portée du FPGA ne cesse de s'étendre.

Rassemblez quelques informations avant de consacrer du temps à l'ingénierie. Ces données vous permettent de rester honnête quant à ce que vous corrigez et ce que vous déplacez simplement.

• Votre pas de temps fixe requis et le budget de latence stable minimum
• Le temps d'exécution le plus long mesuré et la fréquence de dépassement sous charge
• Le nombre d'E/S, les taux de mise à jour et la précision des horodatages que vous devez respecter
• Le sous-ensemble d'équations du modèle qui doit s'exécuter à chaque cycle sans instabilité
• La méthode de validation qui détectera les incohérences numériques et temporelles

Prévoyez un budget pour la vérification et la maintenance, pas seulement pour le développement. Les calculs FPGA utilisent souvent une précision fixe ou contrainte, et les plus grosses surprises en termes de coûts proviennent de la recherche de petites différences numériques qui n'apparaissent que dans des cas particuliers. Une portée contrôlée, des tests d'acceptation clairs et un plan de retour en arrière permettront d'éviter que la mise à niveau ne se transforme en une réécriture sans fin.

Chemin de migration pratique du solveur CPU vers les noyaux FPGA

La mise à niveau la plus fiable consiste à conserver votre modèle de CPU et à transférer uniquement la partie critique en termes de timing vers les noyaux FPGA. Cette approche protège vos installations et vos équipements de test existants tout en vous offrant des E/S déterministes et des calculs à faible latence là où cela compte. Considérez le FPGA comme un coprocesseur soumis à un contrat strict, et non comme un substitut à votre solveur complet.

Commencez par une partition dont les limites sont claires : les entrées arrivent, un ensemble limité de calculs s'exécute, les sorties reviennent, le tout dans un délai connu. Figez rapidement les interfaces, y compris la mise à l'échelle, les unités et les taux de mise à jour, puis créez un harnais de test précis au bit près qui compare les sorties du FPGA à la référence du CPU sur des stimuli représentatifs. Une fois que le noyau correspond, resserrez le timing, puis relancez les tests en boucle fermée pour confirmer que les améliorations de stabilité proviennent du déterminisme et non d'une dynamique modifiée.

L'exécution est plus facile lorsque votre chaîne d'outils prend en charge des flux de travail mixtes CPU et FPGA avec une instrumentation de synchronisation cohérente. Les équipes qui utilisent les plateformes OPAL-RT conservent souvent le modèle principal sur le CPU et mappent des E/S à haut débit et des noyaux de calcul spécifiques sur les ressources FPGA afin que le laboratoire puisse respecter les délais sans compromettre la fidélité de l'installation.

Pièges courants lors de l'ajout d'un FPGA à un simulateur existant

Le mode de défaillance le plus courant consiste à considérer l'accélération FPGA comme une amélioration de la vitesse plutôt que comme une amélioration du déterminisme. Le transfert de grandes parties d'un modèle vers le FPGA sans contrat de synchronisation strict entraîne un nouveau travail d'intégration, de nouveaux comportements numériques et de nouvelles frictions de débogage. Le succès passe par l'isolation du goulot d'étranglement que vous avez mesuré et par la résolution de celui-ci uniquement.

Le glissement de périmètre est un tueur silencieux. Un petit déchargement destiné à corriger la gigue d'E/S peut se transformer en une réimplémentation complète dès lors que les équipes se mettent à rechercher une « marge » de performance sans vérifier si le contrôleur en a réellement besoin. Un autre piège fréquent consiste à ignorer la validation de la synchronisation de bout en bout, ce qui vous laisse avec des noyaux rapides mais une latence de boucle incohérente dès lors que les signaux passent entre les domaines CPU et FPGA.

Un bon jugement technique peut sembler ennuyeux dans ce cas. Définissez la date limite, mesurez l'écart, déchargez la plus petite partie déterministe qui élimine l'écart, puis verrouillez-la à l'aide de tests reproductibles et d'une mise à l'échelle documentée. C'est également cette discipline que nous préconisons chez OPAL-RT lorsque les équipes nous interrogent sur l'accélération FPGA, car le gain n'est pas la vitesse brute. Le gain réside dans un comportement HIL stable auquel vous pouvez vous fier à chaque exécution.