Mise en place d'un pipeline de tests de régression pour HIL dans les équipes chargées de l'électrification

Principaux enseignements

• Les tests de régression HIL ne resteront fiables que si la configuration du banc d'essai et les entrées sont reproductibles et versionnées.
• automatisation des tests automatisation lorsque chaque test contrôlera l'état initial, le stimulus et une règle numérique de réussite ou d'échec.
• Les portes CI resteront rapides lorsque le temps de banc limité sera réservé aux petites suites stables, tandis que les exécutions plus longues resteront programmées et limitées dans le temps.

Les tests de régression HIL automatisés permettront à votre programme d'électrification de continuer à avancer. Les voitures électriques représentaient près de 20 % des ventes mondiales de voitures en 2023. La multiplication des variantes et l'accélération des mises à jour logicielles poussent les laboratoires HIL à faire du triage. Un pipeline de régression reproductible transforme chaque changement en un contrôle fiable.

automatisation HIL automatisation que lorsque le banc agit comme un système de construction, et non comme une expérience. Les entrées versionnées, le timing déterministe et les règles de réussite ou d'échec l'emportent sur « ça avait l'air correct à l'oscilloscope ». Les preuves doivent survivre aux transferts entre les équipes et les sites. Chaque exécution doit être reliée au micrologiciel, au modèle, à l'étalonnage et à l'état du câblage.

Ce que les tests de régression HIL doivent accomplir pour les groupes motopropulseurs électrifiés

Les tests de régression HIL doivent prouver que le comportement de contrôle reste sûr après chaque modification. Ils doivent détecter rapidement les décalages de synchronisation, la saturation et les erreurs de logique de protection. Chaque exécution doit maintenir constants le mappage des E/S, le modèle d'installation et l'étape du solveur. Les résultats doivent aboutir à une réussite ou à un échec que vous pouvez réexécuter sans discussion.

Une mise à jour du convertisseur de traction peut passer les tests unitaires et échouer malgré tout sur HIL. Un nouveau gain de boucle de courant peut sembler stable sur un modèle de bureau, puis déclencher une surintensité lors d'une étape de couple de régénération. La logique de défaut peut régresser, comme un verrouillage qui s'efface prématurément et masque une chute de la liaison CC. La régression HIL révèle ces problèmes, car le timing, les interfaces et les limites se rejoignent en un seul passage.

Les suites robustes se concentrent sur les invariants qui ne doivent pas bouger. Les contrôles de sécurité et de protection viennent en premier, puis les contrôles de performance au niveau de l'acceptation. Dix tests stables valent mieux que cinquante tests fragiles. Chaque porte doit être numérique et traçable.

« automatisation HIL ne automatisation que lorsque le banc agit comme un système de construction, et non comme une expérience. »

Pourquoi les tests HIL manuels échouent à l'échelle de l'électrification

Les exécutions manuelles HIL échouent lorsque le nombre de variantes et la cadence de fusion dépassent le temps disponible. Les étapes de configuration entraînent des dérives dans le câblage, les étalonnages et les scripts de charge. Les résultats se transforment en captures d'écran et en jugements subjectifs plutôt qu'en preuves tangibles. L'équipe passe plus de temps à préparer les tests qu'à en tirer des enseignements.

Une situation courante consiste en deux ingénieurs effectuant le « même » test d'onduleur sur deux bancs d'essai et obtenant des formes d'onde différentes. L'un des bancs utilise un fichier de mise à l'échelle des capteurs différent, tandis que l'autre dispose d'un profil de charge obsolète. Les deux tests sont réussis, mais personne ne peut expliquer l'écart ni le reproduire. L'incertitude grandit à mesure que les branches atterrissent et que les bancs tournent pendant la maintenance.

Les surprises de dernière minute sont pénibles, car les calendriers sont serrés et le matériel est réservé. Les failles logicielles coûtent encore 59,5 milliards de dollars par an à l'économie américaine 59,5 milliards de dollars chaque année. Une régression manquée dans une trajectoire de contrôle du couple peut entraîner un nouveau test au banc, puis un nouveau test sur véhicule, puis une nouvelle version candidate. automatisation ne plus gaspiller des heures de laboratoire en dérives et en réanalyses.

Composants essentiels d'un pipeline de régression HIL automatisé

Un pipeline de régression HIL nécessite un programme d'exécution de tests, un profil de banc d'essai reproductible et un service de résultats. Il doit extraire les versions correctes du modèle, du micrologiciel et de l'étalonnage pour chaque exécution. Il doit réserver le banc d'essai, provisionner les cibles, exécuter les scripts et collecter les signaux automatiquement. Il doit publier les résultats qui renvoient aux entrées exactes.

Une exécution pratique commence par une demande de tâche et se termine par un résultat signé. Un boîtier d'entraînement moteur peut charger une machine synchrone à aimant permanent à 12 phases sur FPGA, injecter un défaut de phase ouverte, puis exécuter des rampes de couple pour vérifier la tenue de ligne. Les équipes qui utilisent les bancs OPAL-RT peuvent répartir les phases de puissance et les phases de puissance entre le CPU et le FPGA afin de maintenir une synchronisation stable. La tâche capture les métadonnées d'exécution afin qu'une nouvelle exécution sur un deuxième banc reste comparable.

Les pipelines échouent lorsque le banc ne respecte pas les règles d'hygiène logicielle. La configuration du banc nécessite un contrôle des versions et une révision. Le temps de banc est limité, c'est pourquoi les limites d'exécution et les délais d'attente stricts sont importants. Un système petit et fiable s'adaptera mieux qu'un système grand et fragile.

Comment structurer les cas de test pour automatisation HIL reproductible

Les tests HIL automatisables commencent par une exigence nommée et se terminent par une vérification numérique. Chaque test doit contrôler les conditions initiales, les stimuli et les critères d'arrêt afin que les réexécutions correspondent. Les tests doivent s'exécuter rapidement et isoler une fonctionnalité à la fois. Traitez les tests comme du code, avec des révisions et un historique des versions.

Un test du régulateur de charge peut régler la température de la batterie à -10 °C, appliquer une demande de courant par paliers et vérifier que le courant se stabilise dans les limites. Un test de commande du moteur peut commander une rampe de vitesse, puis vérifier que l'ondulation du couple reste en dessous d'un seuil après l'activation de l'affaiblissement du champ. Un test de protection peut forcer un circuit ouvert du capteur, puis confirmer que le chemin de secours se déclenche dans un délai défini. Ces tests restent stables car les stimuli et les vérifications sont explicites.

• Verrouillez chaque test à un identifiant de profil de banc d'essai et à des entrées.
• Réinitialiser les états et les indicateurs de défaut avant la stimulation.
• Déclencher des défauts et des étapes sur des horodatages.
• Utilisez les tolérances et le filtrage afin que le bruit ne déclenche pas d'erreur.
• Enregistrer uniquement les signaux nécessaires pour expliquer une défaillance.

Une bonne structuration implique de résister à la tentation d'un « test unique qui vérifie tout ». Les tests polyvalents masquent la cause profonde et font perdre du temps en les réexécutant. Un test court qui échoue pour une raison donnée sera corrigé plus rapidement. Il est important d'utiliser des noms et des balises clairs, car personne ne continue à exécuter des tests qu'il ne peut pas interpréter.

« Dix tests stables valent mieux que cinquante tests fragiles. »

Gestion des données et critères de réussite/échec auxquels les ingénieurs font confiance

La confiance repose sur des données que vous pouvez suivre, rejouer et comparer d'une exécution à l'autre. Chaque exécution doit stocker les signaux bruts, les métriques dérivées et les entrées qui les ont générés. Les règles de réussite ou d'échec doivent rester cohérentes entre les bancs d'essai et les versions. Lorsqu'un test échoue, le rapport doit indiquer ce qui a changé, et pas seulement qu'il a échoué.

Un contrôle du freinage par régénération peut enregistrer la tension du bus CC, les courants de phase, l'estimation de la température et les indicateurs de défaut, puis calculer la valeur de crête et le temps de stabilisation. Le contexte d'exécution doit capturer l'étape du solveur, le hachage de la carte d'E/S, la somme de contrôle de l'étalonnage et le calendrier des défauts. Ce package vous permet de rejouer un échec, de le comparer au dernier passage et d'expliquer le delta. Sans ce contexte, les équipes recommencent jusqu'à ce que le voyant rouge s'éteigne.

Les critères inspirent confiance lorsqu'ils correspondent aux limites physiques et de mesure. Une règle telle que « doit se déclencher dans les 5 ms » sera trompeuse si votre chaîne de mesure ajoute 2 ms. Les contrôles doivent donc correspondre à ce que vous pouvez mesurer. Les références doivent être choisies avec soin, car une trace qui varie en fonction de la température créera de fausses alarmes. Effectuez des contrôles stricts pour les chemins de sécurité et des contrôles de tendance pour les performances.

Intégrer la régression HIL dans les workflows CI sans ralentir les équipes

L'intégration CI fonctionne lorsque HIL est considéré comme une ressource rare et partagée. Votre système de compilation doit déclencher un petit ensemble de tests à chaque fusion et une suite plus importante selon un calendrier défini. Les exécutions doivent être mises en file d'attente, limitées dans le temps et annulées lorsque les entrées changent. Les résultats ne doivent autoriser les fusions que lorsque les tests sont stables.

Un modèle pratique consiste en une suite de 10 à 20 minutes après chaque fusion. Les exécutions nocturnes couvrent des campagnes thermiques et de défaillance plus longues qui durent une heure. La réservation des bancs est importante, la file d'attente doit donc être hiérarchisée et suivre une règle d'accès claire. Lorsqu'un banc tombe en panne, le pipeline doit marquer l'exécution comme bloquée et passer à la suivante.

L'intégration implique également de choisir ce qui sera bloqué et ce qui sera communiqué. Les barrières de blocage doivent rester petites et stables, sinon les développeurs les éviteront. Les suites plus longues sont importantes, mais elles fonctionnent mieux en tant que retour d'information qui renforce les critères une fois les problèmes de stabilité résolus. Un flux de travail clair permet d'intégrer le HIL dans le rythme de travail plutôt que de le traiter à la dernière minute.

Modes de défaillance courants dans automatisation HIL automatisation comment les éviter

La plupart automatisation HIL échouent pour des raisons banales : tests instables, dérive non gérée du banc d'essai et responsabilité mal définie. Les résultats instables incitent les équipes à ignorer complètement les builds rouges. Des étapes manuelles cachées refont surface lorsque les outils semblent peu pratiques. Pour résoudre ces problèmes, il faut des règles, pas des exploits héroïques.

Le bruit peut rapidement miner la confiance. Une équipe vérifie le courant de crête d'un échantillon unique et obtient un échec une fois par semaine en raison d'un problème d'ADC. Les ingénieurs relancent donc le test jusqu'à ce qu'il soit réussi. Une autre équipe met à jour le micrologiciel du banc d'essai sans l'enregistrer, puis se demande pourquoi les marges de synchronisation diminuent et les tests de protection commencent à échouer. Ces deux situations peuvent être évitées si l'instabilité et la dérive sont considérées comme des défauts par les responsables et corrigées.

La discipline permet à la régression HIL de rester utile pendant des mois, et non pendant quelques jours. Les modifications apportées au banc d'essai nécessitent un contrôle des changements, et les modifications apportées aux tests doivent être examinées et justifiées. Le triage des échecs doit suivre une procédure claire : ne relancer que les tests en cas de défaillance du banc d'essai, signaler les bogues pour les problèmes liés au produit et mettre en quarantaine les tests instables. OPAL-RT peut fournir une exécution déterministe en temps réel, mais les résultats ne restent fiables que si votre processus est aussi strict que votre matériel.