Ce qu'apportent les tests « model-in-the-loop » aux premières étapes du modèle en V

Principaux enseignements

• Les tests « Model in the Loop » s’avèrent particulièrement utiles lorsqu’ils permettent de vérifier l’intention de contrôle avant que le logiciel et le matériel n’introduisent du bruit dans le diagnostic.
• La traçabilité des exigences confère aux résultats des essais MIL une valeur durable, car les mêmes données peuvent être réutilisées pour test SIL Simulation HIL.
• Une faible fidélité à la conception et une couverture insuffisante engendrent une fausse confiance, ce qui repousse les défauts de conception fondamentaux vers des étapes ultérieures et plus coûteuses.

Les tests « Model in the Loop » s'avèrent payants dès le début, car ils permettent de mettre en évidence les lacunes au niveau des exigences et les défaillances de contrôle avant que le code, le matériel et le temps passé en laboratoire ne rendent chaque correction coûteuse.

Ce retour sur investissement précoce est important, car la mauvaise qualité des logiciels a coûté aux États-Unis au moins 2,41 billions de dollars en 2022. Pour les équipes chargées de développer des systèmes de contrôle, une grande partie de ce gaspillage commence bien avant le début des essais physiques. Les tests basés sur des modèles réduisent ce gaspillage en vérifiant la cohérence de la logique par rapport aux exigences alors que la conception est encore facile à inspecter. Vous bénéficiez ainsi d’un retour d’information plus rapide, d’une identification plus claire des causes de défaillance et d’un parcours plus fluide vers les étapes de vérification ultérieures.

Les tests « Model in the Loop » permettent de vérifier le comportement avant la mise en œuvre

Les tests « Model in the Loop » consistent à comparer un modèle de contrôleur à un modèle d’installation avant même que la mise en œuvre ne commence. Ils permettent de vérifier la logique, les transitions d’état, les limites et les réponses alors que tout reste encore au stade mathématique. Vous pouvez ainsi observer très tôt le comportement escompté et corriger les défauts de conception avant que la structure du code ou la synchronisation matérielle ne les masquent.

La conception d’un système de contrôle de traction met clairement en évidence cette valeur. Le modèle de contrôleur est capable de lire les signaux de vitesse des roues provenant d’un système de véhicule simulé et de déterminer à quel moment réduire le couple sur une surface glissante. Si le seuil de glissement est incorrect, ou si la machine à états oscille entre les modes de contrôle, le problème se situe au niveau de la conception. Vous n’aurez pas besoin de code compilé ni d’un banc d’essai pour le détecter.

C’est pourquoi le MIL doit intervenir dès le début d’un processus de vérification rigoureux. Il doit constituer une étape précoce de vérification, et non une simple démonstration rapide du modèle. Une campagne de MIL efficace consiste à comparer le comportement du système aux résultats attendus, aux réponses en cas de défaillance et aux seuils définis dans les exigences. Elle permet également de déterminer si le modèle de l’installation est trop simpliste pour être fiable. Dans ce cas, la solution appropriée consiste souvent à améliorer la modélisation, car multiplier les essais ne suffira pas à corriger un modèle d’installation défaillant.

La simulation « Model in the Loop » correspond au modèle en V initial

La simulation « Model in the Loop » s'inscrit dans la partie gauche du modèle en V, là où les exigences du système se transforment en logique de contrôle et en conception exécutable. Elle permet d'obtenir une version testable de la conception avant même que la construction du logiciel ne commence. Ce timing est crucial. Les défauts détectés tôt sont plus faciles à isoler, car ils impliquent moins de détails d'implémentation.

Un contrôleur de gestion de batterie illustre bien ce processus. Les spécifications définissent les limites de tension, la réponse en température et la logique des contacteurs. Le MIL vérifie ensuite le respect de ces règles par rapport à un modèle de batterie dans des conditions de charge, de décharge et de défaillance des capteurs. Si le contacteur s’ouvre trop tard en cas de surchauffe, l’équipe constate que la conception est erronée et que la logique du modèle doit être corrigée avant de commencer le développement logiciel.

Le modèle en V est souvent représenté comme une chaîne bien structurée, mais les équipes peu performantes considèrent la phase MIL comme facultative, car le code et le matériel leur semblent plus concrets. Cette habitude ralentit la validation. Lorsque les premières étapes du modèle en V incluent des vérifications de conception exécutables, les étapes suivantes consacrent moins de temps à démontrer l'intention de base. Elles se concentrent davantage sur la qualité d'exécution du logiciel, le calendrier d'intégration et la fidélité de l'interface physique.

Les modèles de centrale exécutables permettent de visualiser très tôt le comportement des régulateurs

Les modèles d'installation exécutables permettent de visualiser le comportement des régulateurs, car ils fournissent des entrées dynamiques, une rétroaction d'état et des contraintes d'exploitation que les analyses statiques ne peuvent pas mettre en évidence. Ils transforment la logique de commande en un système en boucle fermée. Vous pouvez ainsi observer l'évolution des interactions au fil du temps. C'est là que les réponses instables, retardées ou contradictoires apparaissent clairement.

Prenons l'exemple d'un contrôleur de moteur doté d'une limitation de courant, d'une régulation de vitesse et d'une protection thermique. Un modèle de système peut reproduire les sauts de charge, le bruit des capteurs et les effets de saturation au sein de la boucle de régulation. Si le limiteur de courant entre en conflit avec le régulateur de vitesse lors d'une demande soudaine de couple, cette interaction devient mesurable en simulation. Vous observez alors des dépassements, des retards ou des oscillations bien avant de devoir réserver un variateur ou un dynamomètre.

La qualité de l'asservi détermine la limite supérieure de la valeur MIL. Un asservi simplifié convient pour vérifier la logique d'état ou la gestion des seuils, mais il ne mettra pas en évidence les effets de couplage qui dépendent de phénomènes physiques plus complexes. Il convient d'adapter le niveau de fidélité à la question posée. Si l'objectif du test est d'évaluer la qualité du contrôle en régime transitoire, l'asservi doit représenter le comportement transitoire avec une précision suffisante pour que cela ait une incidence significative.

Les cas de test doivent être directement liés aux exigences du système

Les cas de test en MIL doivent correspondre directement aux exigences du système, afin que chaque résultat apporte une réponse à une question de conception pertinente. Ce lien permet de tirer des enseignements des échecs. Il évite également que les tests basés sur des modèles ne se transforment en une longue série de graphiques intéressants mais sans valeur en termes de vérification. Si un test n'est pas lié à une exigence, il guide rarement l'étape d'ingénierie suivante.

Un contrôleur de répartition de freinage en est un bon exemple. Il est possible de définir des tests à partir des limites de répartition du couple, des règles de coupure de la régénération, du temps de réponse de la pédale et des états de secours en cas de défaillance. Ces liens permettent à l'équipe de rester concentrée sur les exigences du système et de maintenir le travail en lien direct avec la vérification. Les premières séries de tests devraient généralement couvrir les vérifications suivantes, liées aux exigences :

• Les points de fonctionnement normaux doivent correspondre à la consigne de régulation indiquée.
• La perte d'un capteur doit déclencher l'état de secours prévu.
• Les limites des actionneurs doivent garantir la stabilité dans des limites définies.
• Les séquences de démarrage et d'arrêt doivent respecter les règles de synchronisation.
• La reprise après défaillance ne doit rétablir le contrôle qu’après avoir effectué des vérifications valides.

La traçabilité s'avère également utile lorsque les résultats des tests MIL sont examinés lors des revues. Un test lié à une exigence qui a échoué fournit une description précise du problème, la réponse attendue et une piste de vérification. Cela permet d'écourter les discussions et aide les équipes à s'accorder sur les corrections à apporter en priorité. Sans traçabilité, les échecs ont tendance à déboucher sur des débats concernant les hypothèses du modèle, au lieu de déboucher sur des corrections ciblées de la conception.

En quoi le modèle en boucle (Model in the Loop) diffère-t-il du test SIL?

La principale différence entre le « Model-in-the-Loop » (MIL) et test SIL que le MIL teste la conception exécutable, tandis que test SIL l'implémentation logicielle. Le MIL vérifie si l'intention de contrôle est correcte. Le Test SIL vérifie si le code respecte cette intention. Chaque étape répond à une question de vérification différente.

Un régulateur de vitesse permet de visualiser facilement la séparation. Le niveau MIL permet de vérifier que la modulation de gain, la logique anti-windup et les états de défaut fonctionnent comme prévu par rapport à un modèle de système. test SIL vérifie test SIL si le logiciel généré ou codé manuellement produit la même sortie avec les mêmes entrées et les mêmes hypothèses de synchronisation. Une divergence au niveau SIL indique des problèmes liés à l'implémentation, au typage des données, au solveur ou à la génération de code.

« MIL demande si l'intention de commande est correcte. »

Les résultats du MIL devraient orienter la transition vers le SIL

Les résultats de la phase MIL doivent servir de base à la transition vers la phase SIL, car ils définissent les résultats attendus, les plages d'acceptation, les cas limites et la couverture des états avant que l'exécution du code ne devienne la priorité. Cette structure permet d'éviter les débats sur ce que signifie la réussite d'un logiciel. Vous connaissez déjà la réponse attendue. La phase SIL vérifie ensuite si l'implémentation la respecte.

Un contrôleur de suspension active fournit une séquence pratique. Le MIL identifie les commandes attendues des amortisseurs lors du passage sur des nids-de-poule, des mouvements de roulis de la carrosserie et des pertes de signal des capteurs. Ces mêmes scénarios deviennent des cas de régression SIL assortis de tolérances numériques et de critères de réussite. Les équipes utilisant OPAL-RT pour les phases d’exécution ultérieures tirent davantage parti de cet outil lorsque les résultats du MIL décrivent déjà les interfaces, les temps d’échantillonnage et les limites d’acceptation avec ce niveau de rigueur.

Ce transfert fonctionne mieux lorsque vous conservez plus que de simples graphiques. Enregistrez les ensembles de données d'entrée, les transitions d'état attendues, les tolérances des signaux et les remarques relatives aux défaillances sous une forme que l'équipe logicielle pourra réutiliser. Vous passerez ainsi moins de temps à recréer les tests et davantage à vérifier les différences significatives. Le SIL doit être considéré comme une vérification plus rigoureuse de la mise en œuvre, qui réutilise la même base de données que le MIL.

Les tests MIL permettent de réduire les risques liés aux essais matériels avant les tests HIL

Les tests MIL permettent de réduire les risques liés aux essais matériels avant Simulation HIL ils éliminent les défauts de conception que les bancs d'essai physiques ne permettent pas de diagnostiquer efficacement. Ils réduisent le nombre d'inconnues avant que les aspects liés à la synchronisation, aux interfaces et à l'électronique n'entrent en jeu. Cela permet d'économiser du temps de laboratoire, qui est coûteux. De plus, cela permet de concentrer les essais HIL sur le comportement d'intégration plutôt que sur la logique de contrôle de base.

Un contrôleur de direction assistée électrique illustre bien ce point. Si le MIL vérifie déjà les courbes d’assistance, le verrouillage des défauts et les règles de superposition de couple, le HIL peut se concentrer sur la latence des capteurs, la synchronisation du bus et le comportement de l’interface des actionneurs. Si ces aspects fondamentaux ne sont toujours pas résolus à la livraison du matériel, chaque défaillance devient plus difficile à classer. On en arrive alors à se demander si le problème réside dans la conception, le code, le câblage ou la configuration du banc d’essai.

Le HIL a une autre fonction, et il est trop coûteux de le solliciter tant que des ambiguïtés subsistent au stade précoce de la conception. Les ressources en bancs d'essai, les techniciens et le temps d'utilisation des instruments sont limités. Le MIL préserve ces ressources en fournissant la preuve que le comportement de contrôle prévu est stable. Les équipes utilisent alors le HIL pour ce qu'il fait le mieux : vérifier l'exécution dans le respect des contraintes physiques et de la synchronisation des interfaces.

Les lacunes de la couverture MIL suscitent un faux sentiment de sécurité aux stades ultérieurs

Les lacunes dans la couverture MIL suscitent une fausse confiance lorsqu’un modèle réussit des scénarios courants mais passe à côté des conditions limites, de la gestion des défaillances ou des limites des exigences. Ce type de taux de réussite est rassurant, mais trompeur. Les étapes ultérieures révèlent alors des problèmes de conception fondamentaux qui auraient dû être détectés plus tôt. Le coût de cette omission se traduit généralement par des retouches, des retards et une dette technique.

Un contrôleur de gestion thermique peut réussir les tests de refroidissement nominaux tout en échouant lamentablement en cas de gel des capteurs, de dégradation de la pompe ou de fluctuations des seuils. Ces échecs sont souvent dus à des plages de test trop restreintes ou à des hypothèses de fonctionnement erronées. Ils résultent rarement d’une intention malveillante. La dette technique liée à la mauvaise qualité des logiciels a atteint 1 520 milliards de dollars aux États-Unis en 2022. Les lacunes cachées en matière de vérification constituent l’un des mécanismes discrets par lesquels cette dette s’accumule.

« Un bon travail de MIL permet de gagner la confiance, car il permet de déterminer ce qui a été couvert et ce qui ne l’a pas été. »

Il convient de consigner les plages de fonctionnement non prises en charge, les hypothèses simplifiées concernant la centrale et les domaines d'exigences encore en cours d'examen. Cette transparence permet de rendre les défaillances ultérieures moins surprenantes et plus faciles à cerner. OPAL-RT s'inscrit parfaitement dans cette démarche rigoureuse, car la modélisation précoce et la validation en temps réel ultérieure fonctionnent mieux lorsqu'elles sont considérées comme un processus de vérification continu.