5 façons dont l'Simulation HIL des contrôleurs et l'ingénierie basée sur des modèles contribuent à réduire les risques

Principaux enseignements

• L'Simulation HIL des contrôleurs permet de réduire les risques le plus rapidement lorsque vous vous concentrez sur les défaillances en boucle fermée qui apparaissent généralement à un stade avancé du développement.
• L'ingénierie basée sur des modèles apporte une valeur ajoutée lorsque les exigences, les tests et les révisions des contrôleurs restent liés entre eux et sont reproductibles.
• Le meilleur point de départ pour le C-HIL est une fonction de contrôle ciblée et à fort impact, dotée de critères de réussite mesurables et de conditions de réexécution stables.

L'Simulation HIL des contrôleurs permet de réduire les risques en mettant en évidence les défaillances des contrôles à un stade où leur correction reste peu coûteuse.

Cette évolution est importante car les problèmes de contrôle les plus coûteux ne commencent que rarement sur un banc d’essai. Ils apparaissent bien plus tôt, lorsque les hypothèses de synchronisation, le comportement de l’installation et les détails d’interface se trouvent encore au sein des modèles et des premières versions logicielles. L’ Simulation HIL du contrôleur, souvent abrégée en C-HIL, place le contrôleur réel en boucle fermée avec une installation simulée, ce qui permet de tester les réponses avant même que les moteurs, les convertisseurs, les véhicules ou les équipements du réseau ne soient prêts. En associant cette configuration à l’ingénierie basée sur des modèles, vous déplacez les vérifications les plus risquées vers le début du modèle en V et vous évitez que des surprises de dernière minute n’entraînent des retards dans le calendrier.

Simulation HIL , développeur de contrôleurs, teste les contrôleurs avant même que le matériel n'existe

Le contrôleur « Simulation HIL » relie un contrôleur physique à une installation simulée et fait fonctionner cette boucle selon des délais réalistes. Le C-HIL réduit les risques, car le contrôleur reçoit des entrées crédibles et ses sorties ont un impact sur une simulation en temps réel. Vous obtenez ainsi très tôt des indications sur le comportement du système. Vous corrigez les défauts avant que le prototype matériel n’entraîne des coûts et des retards irréversibles.

Un contrôleur d'onduleur en est un exemple frappant. Vous pouvez connecter la carte de commande de production à un moteur simulé et à un bus CC, puis observer les commandes de couple, les limites de courant et les états de défaut lors d'accélérations, de régénération et de baisses de tension. Le même principe s'applique à un relais de protection, à un calculateur de commande de vol ou à une unité de gestion de batterie. Chaque cas vous permet de valider plus tôt le comportement du contrôleur, ce qui rend l'Simulation HIL ation des contrôleurs particulièrement utile dans les workflows d'ingénierie basés sur des modèles.

« C-HIL réduit les risques, car le contrôleur reçoit des données d'entrée fiables et ses sorties ont un impact sur une simulation en temps réel. »

5 façons dont le C-HIL, dans le cadre de l'ingénierie basée sur des modèles, permet de réduire les risques

C-HIL réduit les risques de manière optimale lorsque vous l'utilisez pour cibler les types de défaillances qui apparaissent généralement tardivement et dont le diagnostic est le plus coûteux. Ces types de défaillances se répartissent en six catégories pratiques. Chacune d'entre elles correspond à un problème de contrôle courant. Le coût de leur réparation est d'autant plus faible qu'elles sont détectées avant l'intégration sur banc d'essai.

1. Les modèles d'usine virtuels permettent de mettre en évidence les failles de la logique de contrôle avant même la réalisation des prototypes

Les modèles virtuels d'installations vous permettent de tester le contrôleur réel face à un comportement dynamique bien avant qu'un prototype n'existe. C'est important, car les gains instables, une planification inadéquate et une logique de mode défaillante passent généralement inaperçus lors de la révision du code. Un contrôleur d'onduleur de traction, par exemple, peut sembler correct lors d'une simulation sur ordinateur, mais commencer à osciller lorsque l'inertie simulée du moteur, l'ondulation du bus et le retard du capteur sont appliqués en boucle fermée. Vous observerez alors des dépassements, un emballement de l’intégrateur ou des cycles de limite, alors que la solution consiste simplement à mettre à jour un paramètre ou à modifier la machine à états. Cette analyse précoce impose également une plus grande rigueur dans la modélisation, car les hypothèses relatives à l’installation doivent être suffisamment explicites pour garantir la fiabilité des tests.

2. L'injection de défauts permet de mettre en évidence des réactions dangereuses dans des conditions de fonctionnement exceptionnelles

L’injection de défauts permet d’observer le comportement du contrôleur lorsque les entrées perdent tout sens ou que les conditions de l’installation sortent des limites nominales. Ces tests réduisent les risques, car les défauts rares sont difficiles à reproduire en toute sécurité sur du matériel physique ; pourtant, ils mettent souvent en évidence les faiblesses de la logique de récupération. Un contrôleur de batterie confronté à un capteur de température bloqué, à un événement de sous-tension ou à la perte d’une trame de communication permettra de vérifier s’il réduit correctement sa puissance, verrouille le code approprié et se rétablit selon la séquence prévue. Il ne s’agit pas seulement de vérifier qu’un défaut est détecté. Il s’agit de vérifier que la réponse reste maîtrisée, traçable et sans danger pour le reste du système après l’apparition du premier défaut.

3. Les tests de synchronisation permettent de détecter les variations de latence avant l'intégration dans le banc d'essai

Les défauts de synchronisation sont des défauts de contrôle, et le C-HIL les rend visibles alors que le système est encore facile à inspecter. L’exécution en boucle fermée met en évidence les délais non respectés, la latence variable des tâches et le décalage des E/S qui n’apparaissent pas lors d’une analyse de modèle statique. Une unité de commande de moteur peut calculer le bon rapport cyclique, mais une mise à jour PWM retardée ou un horodatage perturbé peut tout de même faire sortir la régulation du courant hors des limites de tolérance. Les équipes utilisant OPAL-RT effectuent souvent ces tests avec une exécution déterministe de l’installation, afin de pouvoir mesurer la synchronisation du contrôleur sous une charge reproductible. Cela est important car cela permet de distinguer les problèmes de logique logicielle des problèmes de synchronisation d’exécution avant qu’ils ne se confondent en un échec de banc d’essai difficile à interpréter.

« Les défauts de synchronisation sont des défauts de contrôle, et le C-HIL permet de les mettre en évidence alors que le système est encore facile à inspecter. »

4. L'ingénierie basée sur des modèles permet d'assurer la traçabilité des exigences à chaque révision

L'ingénierie basée sur des modèles réduit les risques lorsque chaque exigence de contrôle reste liée à l'élément du modèle, au cas de test et au résultat observé. Cette traçabilité prend toute son importance lorsque les révisions s'accumulent et que plus personne ne se souvient quelle hypothèse a été modifiée en premier. Une exigence relative à un limiteur de vitesse, par exemple, doit rester liée à la logique d’état, aux valeurs seuils et au test C-HIL qui prouve que le limiteur s’enclenche dans le délai autorisé. Lorsque le seuil est modifié à la suite d’une revue de sécurité, vous pouvez réexécuter le test associé et vérifier immédiatement l’effet de cette modification. Vous n’avez pas à deviner quelle feuille de calcul, quel script ou quelle branche logicielle reflète encore l’intention de contrôle actuelle.

5. Les tests de régression détectent les dérives logicielles après chaque mise à jour du contrôleur

Les tests de régression réduisent les risques, car les logiciels de contrôle tombent rarement en panne à des endroits évidents. De légères modifications apportées aux filtres, à la logique anti-emballement, aux tables d'étalonnage ou aux séquences de démarrage peuvent modifier le comportement de manière significative, loin du bloc de code qui a été modifié. Une mise à jour de la limite de courant sur un entraînement électrique, par exemple, peut modifier le temps de récupération en cas de défaut ou la réponse en couple lors d'un événement de chute de tension, même si le nouveau code passe avec succès un test fonctionnel sur banc d'essai. Le C-HIL vous offre des scénarios en boucle fermée reproductibles pouvant être exécutés après chaque version, ce qui permet de détecter la dérive logicielle sous la forme d'un écart mesurable plutôt que d'une surprise coûteuse. Cette discipline aide également les équipes à comparer les révisions en utilisant les mêmes conditions de l'installation et les mêmes critères de réussite.

Par où commencer la C-HIL pour les cas présentant le risque le plus élevé ?

Commencez par la fonction de contrôle dont la défaillance aurait les conséquences les plus graves en termes de sécurité, de performances ou de respect des délais. Il n’est pas nécessaire de disposer d’emblée d’un modèle parfait de l’installation. Ce qu’il vous faut, c’est une boucle fermée fiable autour de la fonction la plus susceptible d’entraîner des retouches de dernière minute. C’est le moyen le plus rapide de réduire efficacement les risques.

Un bon point de départ consiste à choisir la configuration la plus restrictive capable de reproduire une défaillance que vous ne pouvez pas vous permettre de manquer, comme le contrôle du courant sur un onduleur, la reprise après défaut d’un relais ou l’arbitrage de couple dans un contrôleur de véhicule. Les équipes qui travaillent avec OPAL-RT obtiennent souvent de meilleurs résultats lorsqu’elles considèrent le C-HIL comme faisant partie intégrante de la discipline d’ingénierie basée sur les modèles, plutôt que comme une tâche de laboratoire effectuée en fin de cycle. Les bénéfices découlent du choix de critères de réussite stricts, du respect de la reproductibilité des tests et de l’élargissement de la portée uniquement une fois que la première boucle est stable.

• Choisissez une boucle de régulation ayant un impact évident sur le projet.
• Définissez dès le départ des seuils mesurables pour déterminer si un critère est satisfait ou non.
• Ne modélisez que les dynamiques de l'installation qui influent sur cette boucle.
• Automatiser les réexécutions après chaque mise à jour logicielle.
• Transférer les tests dont l'efficacité a été démontrée vers les phases ultérieures de développement en laboratoire sans les modifier.