Comment optimiser les coûts de validation sans compromettre la fidélité dans les systèmes PHIL

Principaux enseignements

• Les coûts liés au PHIL diminuent lorsque les tests matériels sont réservés aux risques non résolus liés au matériel, une fois la vérification logicielle terminée.
• La fidélité doit être adaptée à la sensibilité du mode de défaillance, la stabilité en boucle fermée fixant la limite pratique du niveau de détail du modèle.
• Le coût par kW et la main-d'œuvre sont tous deux optimisés lorsque le partitionnement des modèles et automatisation des tests automatisation les équipements matériels superflus et les tâches manuelles.

Le coût de la validation PHIL diminue lorsque vous n'utilisez le matériel que pour les risques que le logiciel ne peut pas couvrir.

La mauvaise qualité des logiciels a coûté à l'économie américaine au moins 2 410 milliards de dollars en 2022. Ce chiffre est significatif, car PHIL est l'un des moyens les plus coûteux de détecter des problèmes que l'on aurait pu repérer plus tôt. Les équipes dépensent trop lorsqu'elles considèrent le banc d'essai comme un outil de validation universel. On préserve la fiabilité tout en réduisant les dépenses lorsque chaque exécution de PHIL répond à une question précise liée au matériel.

Dans le domaine des tests logiciels, la validation consiste à démontrer que le système se comporte de manière acceptable dans les conditions qui comptent, tandis que la vérification permet de s'assurer que les modèles, le code et les interfaces sont conformes à leurs spécifications.Simulation HIL à la jonction entre les tests logiciels et l'interaction avec le matériel. Cette frontière permet de maintenir la cohérence entre les tests logiciels et la validation. Elle offre également un moyen efficace d'optimiser les budgets de simulation sans compromettre la fiabilité des résultats.

Le coût de la validation diminue lorsque PHIL ne cible que le risque résiduel

Le coût de PHIL est moindre lorsque vous l'utilisez pour tester uniquement les comportements qui présentent encore des incertitudes après les vérifications logicielles. Il s'agit généralement des effets d'interface, de la synchronisation des contrôleurs, de la saturation, des déclenchements de protection et des tolérances matérielles. Le temps passé au banc de test diminuera, car vous n'utiliserez plus de matériel de puissance pour valider une logique déjà confirmée par les tests unitaires. La maîtrise des coûts commence par une définition précise des risques pour chaque exécution.

L'équipe chargée de l'entraînement moteur en est un bon exemple. La logique de boucle de courant, l'analyse des défauts et les transitions d'état sont vérifiées dans le cadre de tests « model-in-the-loop » et test SIL ; le banc PHIL est ensuite réservé au temps mort, au bruit des capteurs, à l'affaissement du circuit intermédiaire et à l'interaction des amplificateurs. Ce changement permet de réduire le nombre d'itérations et de raccourcir le temps de configuration. Il renforce également la traçabilité, car chaque cas PHIL correspond à un risque résiduel spécifique plutôt qu'à une demande générale visant à accroître la confiance.

« PHIL revient moins cher lorsqu'on l'utilise pour tester uniquement les comportements qui présentent encore des incertitudes après les vérifications logicielles. »

La distinction entre vérification et validation définit ce que PHIL doit démontrer

La vérification et la validation dans le domaine des tests logiciels répondent à des questions différentes, et PHIL relève du domaine de la validation. La vérification consiste à s'assurer que les modèles, le code, les interfaces et les exigences concordent. La validation consiste à s'assurer que le système de contrôle intégré se comporte de manière acceptable lorsque la dynamique du matériel et les effets en boucle fermée sont présents. PHIL devrait démontrer ce comportement plutôt que de revérifier la justesse fondamentale.

Les équipes confondent validation et vérification lors des tests logiciels lorsqu'un test PHIL échoué les oblige à revenir en arrière pour corriger une exigence manquante ou une conversion d'unité erronée. Il s'agit là d'un travail de vérification, qui aurait dû être détecté plus tôt, à un coût bien moindre. Un projet de convertisseur de réseau illustre bien cette distinction. Le traçage des exigences, les limites du contrôleur et la gestion des messages relèvent des couches de test et de validation du logiciel avant que tout étage de puissance ne soit mis sous tension, tandis qu'un test PHIL doit se concentrer sur le partage de courant, la capacité de résistance aux perturbations et la protection en cas de contrainte électrique.

Les tests logiciels doivent éliminer les risques avant l'exécution de PHIL

Les tests logiciels doivent éliminer autant d'incertitudes que possible avant le lancement de PHIL. Cela implique des tests unitaires, des vérifications de modèles, une validation des interfaces, l'injection de défauts et des tests de régression automatisés sur la version du contrôleur. PHIL s'avère plus économique lorsque son objectif est précis et explicite. Il devient un gaspillage lorsqu'il sert également de phase de débogage à grande échelle.

Une équipe chargée des onduleurs de batterie peut programmer des milliers de combinaisons de contrôle en une nuit, puis ne tester le lendemain matin que les quelques cas présentant un comportement instable. Cette approche permet de réaliser des économies, car on estime que le manque d’infrastructures de test logiciel coûte à l’économie américaine entre 22,2 et 59,5 milliards de dollars chaque année. Les défaillances tardives sont coûteuses dans tous les domaines, et PHIL ajoute à cette facture le matériel d'alimentation, les procédures de sécurité et le personnel de laboratoire. Vous ne réduirez pas les coûts de validation tant que vos tests de validation dans le cadre des tests logiciels n'auront pas éliminé en premier lieu les défaillances faciles à détecter.

La fidélité devrait être fonction de la sensibilité aux défaillances plutôt que de l'ambition du modèle

La haute fidélité ne se justifie financièrement que lorsque les détails manquants peuvent faire la différence entre la réussite et l'échec. Le niveau de détail du modèle doit être déterminé en fonction de la sensibilité aux défaillances, et non en fonction des préférences personnelles ou de la fierté liée au modèle. Si une représentation simplifiée permet de reproduire le comportement testé, elle constitue le meilleur choix pour la validation. Un niveau de détail accru n'est pas automatiquement plus utile.

Prenons l'exemple d'un contrôleur de chargeur pour véhicules électriques. Un modèle de commutation détaillé s'avère pertinent lorsqu'il s'agit d'étudier la protection contre les courts-circuits, le contenu harmonique ou les limites de courant sous-cycliques. Un système de modèle d'ordre réduit suffit pour vérifier le séquencement de supervision, les rampes de consigne ou les pertes de communication. Cette distinction permet de maîtriser la charge du solveur et de réduire le temps de recalibrage. On ne peut justifier un budget où chaque milliseconde compte avec un modèle à l'échelle de la microseconde, à moins que le mode de défaillance ne se situe réellement à cette échelle de temps.

La stabilité en boucle fermée définit la limite supérieure de la fidélité

La stabilité en boucle fermée constitue la limite supérieure de la fidélité utile dans PHIL. Dès que la latence, les limites de l'amplificateur, le bruit des capteurs ou les algorithmes d'interface déstabilisent la boucle, l'ajout de détails supplémentaires au modèle ne sert plus à rien. L'équipe du laboratoire passera alors son temps à régler le dispositif plutôt qu'à tester le produit. La stabilité du couplage prime sur la richesse de la représentation.

Un micro-réseau illustre clairement ce point. Si l'amplificateur sature lors d'un test de chute de tension, ou si le retard de boucle fausse la rétroaction de courant, le résultat en dit plus long sur le banc d'essai que sur le contrôleur. Les algorithmes d'interface, les choix d'amortissement et le filtrage des capteurs doivent être soumis à des limites explicites avant le début des campagnes de test. L'objectif est d'obtenir une boucle qui reste prévisible, mesurable et reproductible dans tous les cas qui comptent.

Le coût par kW de PHIL dépend de la configuration matérielle

Le coût par kW d'un système PHIL dépend du matériel et des dispositifs de protection associés à chaque kilowatt testé, et non pas uniquement de la puissance nominale. Les amplificateurs de puissance, les capteurs, le refroidissement, les fixations, les systèmes de sécurité et le temps de travail des opérateurs varient tous en fonction de l'ampleur du projet. Un petit banc d'essai doté d'un système de conditionnement complexe peut coûter plus cher par kW qu'un banc plus grand mais plus simple. C'est pourquoi l'ampleur du matériel est le premier facteur à prendre en compte.

• La puissance nominale détermine la taille de l'amplificateur, la conception du câble d'alimentation et la marge thermique.
• La plage de tension influe sur les équipements d'isolation, de protection et de mesure.
• Les coûts liés aux disjoncteurs, aux contacteurs et aux coffrets de sécurité augmentent en cas de défaillance.
• Les besoins en bande passante déterminent le type d'amplificateur et les efforts de réglage de l'interface.
• La durée des essais implique une charge de travail supplémentaire, Énergie et un temps de réinitialisation entre chaque série d'essais.

Un banc d'essai à onduleur de 50 kW conçu pour la résistance aux pannes peut coûter plus cher par kW qu'un banc de 500 kW utilisé pour les contrôles de régulation en régime permanent. Une large bande passante, Énergie des pannes Énergie et une logique de protection stricte font grimper le prix de chaque kilowatt testé. C'est la manière la plus claire d'appréhender le coût par kW d'un banc d'essai PHIL, expliqué en termes simples. Vous réalisez des économies lorsque la puissance nominale correspond à la contrainte matérielle la plus restrictive à laquelle vous devez encore répondre.

Le partitionnement des modèles permet de réduire les coûts informatiques sans compromettre la fiabilité des résultats

Le partitionnement des modèles permet de réduire les coûts en affectant uniquement les comportements sensibles au temps à la cible de calcul la plus rapide. Les chemins de commutation rapides, la logique de protection et la synchronisation des entrées/sorties restent proches du matériel déterministe. Les modèles thermiques, de supervision ou de réseau, plus lents, peuvent s'exécuter sur des ressources moins coûteuses. La fiabilité des résultats est préservée, car chaque sous-modèle est adapté à ses exigences de synchronisation.

Un laboratoire de convertisseurs peut choisir de conserver l'interface du réseau et l'interaction PWM sur le matériel FPGA, tandis que le modèle d'alimentation et le séquenceur de test s'exécutent sur les cœurs du processeur. Cette répartition permet de réduire les coûts liés à la capacité haute vitesse sans compromettre la fiabilité des résultats attendus de l'exécution. Sur des plateformes telles qu'OPAL-RT, les équipes ont souvent recours au partitionnement pour réserver les ressources les plus déterministes aux quelques boucles qui en ont réellement besoin. Vous obtiendrez un meilleur budget de simulation lorsque c'est la contrainte de temps, et non la taille du modèle, qui détermine le placement.

« Ajouter du matériel ne suffira pas à remédier à un processus manuel qui nécessite des heures de préparation pour chaque dossier. »

automatisation des tests automatisation davantage la charge de travail liée à la validation que l'ajout de matériel

automatisation l'effort de validation, car elle élimine le travail manuel associé à chaque exécution de PHIL. Les vérifications automatisées des builds, les balayages de paramètres, les réinitialisations, la collecte de données et la logique de verdict transforment le temps de banc limité en données exploitables. Un surcroît de matériel ne suffira pas à remédier à un processus manuel qui nécessite des heures de préparation pour chaque cas. La reproductibilité passe avant tout par le contrôle du flux de travail.

Un laboratoire capable d'automatiser le démarrage, d'injecter des défauts, d'enregistrer les traces et d'évaluer les critères de réussite après chaque exécution permettra de traiter davantage de cas utiles qu'un banc d'essai plus grand exploité manuellement. Les équipes retiennent les performances de l'amplificateur, mais le coût caché réside dans les écarts de configuration, le jugement de l'opérateur et la compilation des rapports. C'est pourquoi, à long terme, des tests et une validation logiciels rigoureux s'avéreront plus rentables que les dépenses brutes en matériel. OPAL-RT s'inscrit parfaitement dans ce schéma lorsque la plateforme considérée comme faisant partie d'un système de test contrôlé, où automatisation la portée prennent le relais de la taille du banc d'essai pour effectuer le gros du travail.