Exécution déterministe dans une simulation en temps réel basée sur un FPGA

Principaux enseignements

• Le timing déterministe est la couche de crédibilité dans HIL, car il maintient le délai en boucle fermée limité et reproductible d'une exécution à l'autre et d'une charge de travail à l'autre.
• L'exécution FPGA améliore la latence HIL et le contrôle de la gigue grâce à des chemins de synchronisation matériels fixes et des E/S alignées sur les ticks, ce qui permet aux contrôleurs de bénéficier d'une synchronisation cause-effet cohérente.
• Des résultats stables sont obtenus grâce à des budgets de temps explicites, à un partitionnement minutieux entre CPU et FPGA, et à une validation basée sur des horodatages qui vérifie le comportement dans le pire des cas de bout en bout.

Le timing déterministe est ce qui rend crédible Simulation HIL .

Lorsque le timing est décalé, vous pouvez toujours obtenir des graphiques et des indicateurs de réussite ou d'échec, mais vous ne saurez pas si vous avez testé votre contrôleur ou simplement votre configuration de test. Les erreurs de timing difficiles à détecter se cachent souvent sous forme de « bruit » jusqu'à ce que vous expédiez le code vers une cible qui se comporte différemment sous la charge. Selon une estimation publique, le coût annuel d'une infrastructure de test logiciel inadéquate s'élève à 59,5 milliards de dollars, ce qui nous rappelle que la crédibilité des tests a un poids financier réel, et ne se résume pas à une simple fierté technique.

La simulation en temps réel basée sur FPGA est populaire car elle remplace la synchronisation au mieux par une exécution et des E/S fixes et reproductibles. Son utilité est simple. Si vous ne pouvez pas expliquer et mesurer la latence et la gigue de bout en bout, la précision de la simulation en boucle fermée devient une hypothèse. Si vous le pouvez, le HIL devient un moyen fiable de détecter rapidement et en toute confiance les cas limites.

« Lorsque ces deux éléments s'alignent, le simulateur se comporte comme un équipement de laboratoire stable. »

Le timing déterministe définit le niveau de confiance dans les tests HIL

Le timing déterministe signifie que chaque étape de simulation et chaque mise à jour d'E/S se déroulent selon le calendrier prévu, avec un délai limité et reproductible. Votre contrôleur réagira au même profil de timing à chaque exécution, et non à un profil différent à chaque fois que le CPU est occupé. Cette reproductibilité constitue la couche de confiance dans le HIL. Sans elle, les résultats semblent précis, mais le comportement temporel reste inconnu.

Vous pouvez considérer le déterminisme comme un contrat qui couvre trois éléments. L'étape de résolution doit être terminée avant une date limite stricte, l'échantillonnage d'E/S doit s'aligner sur la limite de l'étape et le temps entre la « sortie du contrôleur » et la « réponse de l'installation » doit rester constant. Lorsque l'un de ces éléments dérape, la boucle se referme toujours, mais vous ne validez plus les hypothèses de synchronisation dans votre conception de contrôle. C'est à ce moment-là qu'un test devient difficile à défendre auprès d'une équipe chargée de la sécurité ou de la validation.

La simulation déterministe en temps réel réduit également le besoin de « régler » le laboratoire. Un contrôleur réglé pour compenser la gigue semblera souvent stable, mais cette stabilité peut être un artefact du laboratoire. Un déterminisme strict vous oblige à effectuer le réglage en fonction de la physique de l'installation et du taux d'échantillonnage prévu. Au fil du temps, cette discipline améliore la réutilisation, car le même modèle et le même contrôleur se comportent de la même manière lorsque vous étendez la couverture des tests.

Les erreurs de gigue et de latence réduisent la précision de la simulation en boucle fermée.

La latence est le délai fixe entre la cause et l'effet, tandis que la gigue est la variation de ce délai d'un cycle à l'autre. La précision de la simulation en boucle fermée diminue plus rapidement en présence de gigue, car le délai de la boucle n'est plus prévisible. Le contrôleur perçoit alors une installation variable dans le temps. Cette variance temporelle se traduit par un déphasage supplémentaire et un retour bruité, même avec des calculs mathématiques parfaits.

Les équipes se concentrent souvent sur la latence moyenne et négligent les cas extrêmes. Un délai moyen stable peut néanmoins masquer des retards occasionnels importants qui font dépasser à une boucle sa marge de stabilité. La gigue nuit également à la répétabilité, ce qui rend les régressions plus difficiles à reproduire et plus difficiles à attribuer à un changement de modèle. Lorsqu'un échec de test dépend de la charge du processeur, d'un conflit de bus ou de services en arrière-plan, il s'agit d'abord d'un échec de synchronisation, puis d'un échec de contrôle.

La latence reste importante car elle définit la bande passante utilisable de la boucle. Si le délai de la boucle fermée est trop important pour la fréquence d'échantillonnage, vous serez obligé d'atténuer les gains, d'ajouter un filtrage ou d'accepter une réponse plus lente. Ces « corrections » peuvent masquer les problèmes de l'installation et également dissimuler la sensibilité au bruit des capteurs. Un budget de temps clair vous permet de rester honnête, car chaque microseconde a sa place et sa raison d'être.

L'exécution FPGA réduit la latence de simulation en temps réel et le délai d'E/S.

Les FPGA réduisent la latence et la gigue, car la logique s'exécute sous forme de chemins matériels fixes, et non de tâches logicielles réparties dans le temps. Une fois compilée, une conception FPGA exécute la même séquence à chaque cycle d'horloge avec des retards de pipeline prévisibles. Ce déterminisme s'applique à la fois au calcul et à la gestion des E/S. Par conséquent, la latence des FPGA dans les systèmes HIL devient un budget que vous pouvez intégrer à votre conception, et non une variable que vous espérez voir rester faible.

Un cas concret illustre bien ce point. Un contrôleur d'onduleur qui met à jour le PWM à 20 kHz a une période de contrôle de 50 microsecondes, et même quelques microsecondes de variation du délai d'E/S peuvent modifier l'ondulation du courant et la réponse du couple d'une manière que votre modèle ne peut pas prédire. Le fait de placer les fonctions de commutation rapide, la capture PWM et la logique de protection sur un FPGA permet de maintenir la répétabilité du timing des fronts d'E/S, de sorte que la boucle voit le même retard à chaque cycle. Ce simple changement contribue souvent davantage à la précision de la simulation en boucle fermée que l'ajout de détails au modèle.

Les FPGA vous permettent également de traiter les E/S comme des données synchrones, et non comme des interruptions asynchrones. L'échantillonnage ADC, les captures numériques et le décodage des encodeurs peuvent tous être alignés sur une horloge et un tick partagés. Cet alignement réduit le « décalage » caché entre les canaux qui, autrement, se traduirait par des déphasages fantômes. Le compromis réside dans l'effort de conception, car le partitionnement des FPGA récompense une planification précoce et des objectifs de synchronisation clairs.

Répartition des modèles entre FPGA et CPU pour respecter les délais

Le partitionnement consiste à placer chaque tâche du modèle sur la ressource informatique capable de respecter son délai dans des délais stables. Le CPU gère les tâches numériques lourdes ou à pas variables qui s'adaptent néanmoins à un calendrier à pas fixes. Le FPGA gère les parties rapides, répétitives et sensibles au timing, où la gigue nuit le plus à la boucle. Bien fait, cela permet d'obtenir un déterminisme sans avoir à intégrer l'ensemble du modèle de l'usine dans le matériel.

Une partition pratique commence généralement par la limite d'E/S et fonctionne vers l'intérieur. Tout ce qui est lié aux événements de commutation, à la synchronisation des fronts ou aux verrouillages de protection doit se trouver près de l'E/S, car les mises à jour tardives modifient le comportement, et pas seulement la précision. Les dynamiques plus lentes, la logique de supervision et la journalisation conviennent mieux au CPU, où la flexibilité est plus grande. Les plateformes qui combinent des solveurs CPU et des E/S FPGA, telles que les systèmes OPAL-RT, rendent cette séparation possible tant que vous traitez l'interface comme faisant partie du budget de synchronisation.

Le principal mode de défaillance consiste à traiter la limite entre le CPU et le FPGA comme une boîte aux lettres gratuite. Chaque passage ajoute une mise en mémoire tampon, une négociation et une gestion du domaine d'horloge, ce qui peut ajouter un retard et une variation s'il n'est pas planifié. Les transitions de débit doivent également être prises en compte, car une tâche FPGA rapide alimentant une tâche CPU plus lente créera un aliasing si vous ne définissez pas le comportement d'échantillonnage et de maintien. Un bon partitionnement dépend moins de la vitesse brute que du fait de garder chaque retard de boucle explicite et reproductible.

Synchronisation des E/S et choix de planification qui garantissent la répétabilité du timing

La répétabilité du timing dépend de la synchronisation des E/S avec le tick de simulation et de la planification de chaque mise à jour selon une séquence prévisible. L'échantillonnage synchrone signifie que chaque canal est capturé à un instant connu, et non « lorsque le pilote en a le temps ». La sortie déterministe signifie que les mises à jour sont appliquées à un moment défini, et non réparties sur une fenêtre variable. Lorsque ces deux éléments s'alignent, le simulateur se comporte comme un équipement de laboratoire stable.

Trois choix sont particulièrement importants. Premièrement, alignez l'ADC et la capture numérique sur une horloge partagée et un déclencheur défini afin que les canaux restent cohérents. Deuxièmement, veillez à ce que la mise en mémoire tampon reste explicite et limitée afin que les files d'attente « utiles » n'ajoutent pas de retard caché. Troisièmement, traitez les bus asynchrones comme des interfaces synchronisées, en définissant clairement quand les valeurs sont valides par rapport au tick. Ces détails peuvent sembler insignifiants, mais ils déterminent si le retard de votre boucle est constant ou variable.

« Si vous ne pouvez pas expliquer et mesurer la latence et la gigue de bout en bout, la précision de la simulation en boucle fermée devient une hypothèse. »

Définition et validation des budgets de latence à l'aide de mesures basées sur l'horodatage

Un budget de latence est une limite écrite pour chaque composant de retard dans la boucle fermée, de la conversion E/S au calcul jusqu'à la mise à jour de la sortie. La validation basée sur l'horodatage vérifie que le budget est respecté sous une charge réaliste, et pas seulement dans un laboratoire au calme. L'objectif est de prouver les limites, et non d'obtenir le meilleur chiffre possible. Une fois que vous pouvez le mesurer, vous pouvez le gérer.

Les horodatages doivent avoir une résolution suffisante pour afficher les petites variations, ce que les formats de synchronisation courants prennent déjà en charge. Un horodatage NTP 64 bits standard utilise un champ fractionnaire 32 bits avec une résolution théorique d'environ 233 picosecondes. Ce niveau de résolution dépasse largement les besoins typiques du HIL, mais il renforce le principe selon lequel les outils de mesure peuvent être beaucoup plus précis que les délais que vous prévoyez. Ce qui importe, c'est de placer les horodatages aux bons endroits, par exemple au niveau du verrouillage de l'ADC, du début et de la fin d'une étape de résolution, et de l'application de la sortie.

Une routine de validation utile combine instrumentation et contrainte. Enregistrez les horodatages pendant que vous exécutez votre charge de travail normale, puis répétez l'opération en ajoutant la journalisation, le trafic de communication et la configuration du modèle la plus défavorable que vous prévoyez de livrer. Comparez les valeurs les plus défavorables et les valeurs typiques, et non pas seulement les moyennes, et traitez les valeurs aberrantes comme des défauts à corriger. Les équipes qui procèdent ainsi dès le début évitent les surprises de dernière minute où « le modèle est correct », mais le timing ne l'est pas.

Erreurs courantes de configuration HIL qui entraînent un comportement non déterministe

Le comportement non déterministe dans HIL provient généralement d'un petit ensemble d'erreurs répétitives, et non d'une physique mystérieuse. Les erreurs de synchronisation apparaissent lorsque certaines parties de la boucle fonctionnent sur des horloges différentes, lorsque la planification logicielle est considérée comme « suffisante » ou lorsque la mise en mémoire tampon masque un retard. La résolution de ces problèmes est rarement prestigieuse, mais c'est un travail qui protège la crédibilité. Si la synchronisation est rigoureuse, vos résultats résisteront aux examens et aux audits.

• Laisser les E/S s'exécuter librement au lieu de les aligner sur le tick
• Ignorer la gigue dans le pire des cas et se fier à la latence moyenne
• Autorisation de files d'attente illimitées dans les chemins de données
• Mélange de domaines d'horloge sans délais de pipeline définis
• Mesurer la latence à un point plutôt que de bout en bout

Le jugement pratique est simple. Vous devez considérer le timing déterministe comme une exigence de test, au même titre que le calibrage des capteurs ou les verrouillages de sécurité, car le timing définit la boucle que vous validez. Les projets OPAL-RT qui réussissent à long terme ont tendance à institutionnaliser cette pratique, avec des budgets écrits et des mesures reproductibles, plutôt que de la considérer comme un exercice ponctuel. Cette habitude permet de maintenir la précision de la simulation en boucle fermée liée à l'intention technique plutôt qu'aux conditions momentanées du laboratoire.