test SIL Simulation HIL test SIL à l'intention des ingénieurs

Principaux enseignements

• test SIL prendre en charge la validation logique dès le début, car il permet de maintenir un niveau élevé de couverture de test alors que les modifications de conception sont encore fréquentes.
• Simulation HIL son coût plus élevé lorsque la synchronisation, les E/S électriques et l'exécution du contrôleur sur le matériel cible constituent le principal risque.
• Le fait de disposer d'une base de référence commune pour le modèle est plus important que le choix de l'étape, car une faible fidélité du modèle va fausser les deux parcours de test.

test SIL opter pour test SIL et passez à Simulation HIL lorsque le respect des délais et le comportement des entrées/sorties doivent être vérifiés.

Cette séquence permet de réduire le gaspillage, car test SIL un retour rapide sur le code et la logique de commande avant même que les bancs d'essai, le câblage et le matériel d'injection de défauts ne soient prêts. Les véhicules légers utilisent généralement 70 à 100 unités de contrôle électronique, c'est pourquoi une validation par étapes est essentielle bien avant l'intégration finale. Vous obtiendrez les meilleurs résultats lorsque chaque étape de test vérifie un risque distinct, plutôt que de demander à une seule étape de répondre à toutes les questions.

«test SIL la logique du contrôleur avant que le matériel cible n'entre en phase de configuration. »

SIL teste le comportement des logiciels sans matériel cible

test SIL vérifie la logique du contrôleur avant que le matériel cible n'entre en phase de configuration. Vous exécutez un logiciel de contrôle compilé ou interprété sur un modèle d'installation simulé. Cela en fait l'environnement le plus rapide pour détecter les défauts d'état, de limite et de séquencement. Il ne permet toutefois pas de valider les interfaces électriques ni la synchronisation matérielle sur le contrôleur final.

Un algorithme de contrôle de traction en est un bon exemple. En quelques heures, vous pouvez simuler des données de vitesse de roue, des estimations de patinage et des demandes de couple pour des milliers de cas de configuration route-pneus sur une station de travail. Cela permet de repérer rapidement des seuils inadaptés, des choix de gain instables ou des mécanismes de verrouillage des défauts incorrects. Comme vous observez le comportement du logiciel dans un environnement numérique sécurisé, les modifications restent peu coûteuses et la couverture des tests augmente rapidement.

Cette rapidité est essentielle lorsque votre conception évolue encore au quotidien. Les équipes chargées de l'étalonnage peuvent ajuster les limites, les équipes logicielles peuvent corriger la logique, et les ingénieurs systèmes peuvent vérifier que la réponse de contrôle prévue est toujours valable. Si vous vous précipitez pour tester le matériel en laboratoire trop tôt, celui-ci devient un goulot d'étranglement et chaque problème de câblage ou de flashage vous fait perdre un temps précieux qui pourrait être consacré à la validation proprement dite. Le SIL s'avère particulièrement efficace en tant que premier filtre pour évaluer la fiabilité de la logique, surtout lorsque les exigences sont encore en cours de définition.

Les tests HIL évaluent le comportement du système de commande par le biais de canaux d'entrée-sortie physiques

Simulation HIL vérifie le contrôleur via des canaux d'entrée/sortie physiques tandis que l'installation reste simulée. Le contrôleur peut être l'unité de production ou une carte cible similaire. Cette configuration met en évidence les variations du planificateur, la mise à l'échelle des signaux et les défauts d'interface. Elle répond aux questions liées au couplage matériel auxquelles test SIL répondre avec certitude.

Un contrôleur d'onduleur met clairement en évidence ces différences. Les commandes d'impulsion, le retour analogique, les défauts discrets et le trafic de communication empruntent tous des circuits électriques réels, ce qui permet de voir comment le contrôleur réagit à un décalage de synchronisation ou à des entrées parasitées. Un essai au banc de mesure révélera qu'un décalage du capteur de courant provoque un déclenchement de protection, même si la logique logicielle semblait fonctionner correctement auparavant. Ce genre d'erreur est fréquent lorsque les tests sur ordinateur masquent les détails électriques.

HIL offre également à votre équipe un environnement commun pour tester la gestion des défaillances avant même qu’un prototype de véhicule ou un banc d’essai ne soit prêt. Vous pouvez simuler des pertes de signal des capteurs, des erreurs de bus et des valeurs hors plage sans mettre en péril du matériel coûteux. Le temps passé en laboratoire a un coût, l’enjeu ne réside donc pas uniquement dans le volume. L’objectif est de démontrer de manière ciblée que le contrôleur se comporte correctement une fois que les signaux réels et l’exécution matérielle sont intégrés à la boucle.

Commencez par utiliser SIL lorsque les modifications de conception sont encore fréquentes

Commencez par test SIL l'architecture de votre contrôleur, les spécifications ou les étalonnages changent encore fréquemment. Cette approche permet d'intégrer les modifications sans avoir à refaire les tests au banc et permet aux ingénieurs de se concentrer sur la qualité du contrôle. Vous pouvez effectuer des tests de régression à grande échelle après chaque révision du code. Cela en fait la phase de démarrage idéale pour les périodes de conception instables.

Une fonction d'arbitrage du couple pour un véhicule électrique correspond à ce schéma. Les limites de puissance, les demandes du conducteur, les contraintes de traction et les déclassements thermiques évoluent souvent au cours des premières versions. Vous pouvez mettre à jour le modèle de contrôle, réexécuter les mêmes cycles de conduite et comparer les comportements le jour même. Un banc d'essai matériel ralentirait cette boucle, car la programmation de la mémoire, la configuration des E/S et l'accès au laboratoire prendraient le dessus sur le planning.

À ce stade, les équipes bénéficient également d'un retour d'information plus précis. Si un test échoue en SIL, vous saurez généralement que le problème réside dans la logique, le traitement des données ou les hypothèses relatives à l'installation, plutôt que dans le câblage, les planificateurs ou la mise à l'échelle analogique. Cette clarté permet à vos équipes chargées du logiciel et des commandes de travailler plus rapidement et avec moins de confusion. Vous ne devriez quitter la phase SIL qu'une fois que la logique semble suffisamment stable pour que les questions liées au matériel, et non plus les modifications de conception, constituent désormais la principale source de risque.

Passez au HIL lorsque le risque lié au timing devient un problème

La principale différence entre rester en test SIL passer à Simulation HIL que le HIL permet de valider le comportement dans les conditions de synchronisation et d'interface cibles. Une fois que la logique semble stable, c'est la synchronisation d'exécution qui devient le risque le plus important. Le HIL montre comment le contrôleur réagit à la latence, à la quantification et au conditionnement des signaux. C'est là que les essais au banc justifient leur coût.

Un contrôleur de moteur électrique atteint souvent ce stade après que les circuits de couple et de protection ont cessé de fonctionner chaque semaine. Les véhicules légers ont utilisé en moyenne 949 semi-conducteurs en 2021, de sorte que la synchronisation des interfaces et l’intégrité des signaux ne resteront pas longtemps théoriques. Un banc HIL montrera qu’une limite de courant arrive avec un échantillon de retard, ou qu’un bit de défaut s’efface trop lentement après la récupération d’un capteur bruyant. Le SIL met rarement en évidence ce type de problème avec suffisamment de certitude.

Vous devez également intervenir lorsque les équipes d'intégration ont besoin de vérifier que le logiciel et l'électronique fonctionnent comme un tout. Les délais de communication, le filtrage des entrées, la synchronisation de la modulation de largeur d'impulsion et la charge des interruptions sont autant de facteurs importants. Si vous attendez trop longtemps, les tests au banc s'accumulent à l'approche de la mise en production et le temps de matériel coûteux est consacré à des erreurs logiques qui auraient dû être corrigées plus tôt. Une bonne planification permet de concentrer les tests HIL sur la vérification de la synchronisation et des E/S plutôt que sur la correction du logiciel.

Les coûts liés à l'HIL augmentent à mesure que l'étendue des activités du laboratoire s'élargit

Simulation HIL plus cher, car chaque test utile nécessite du matériel, des cartes d'interface, la mise en place d'un banc d'essai et la coordination au sein du laboratoire. test SIL , quant à elle, mobilise test SIL du temps de calcul et des efforts de modélisation. La simulation HIL implique des investissements en équipement et du temps de configuration par le personnel. Cela ne rend pas pour autant la simulation HIL facultative ; vous devriez donc l'utiliser de manière plus ciblée.

• Le matériel de banc nécessite des achats, de l'entretien et des pièces de rechange.
• Le traitement des signaux et l'injection de défauts compliquent la configuration.
• Le clignotement du contrôleur et les opérations de calibrage mobilisent le temps des techniciens.
• La planification des salles limite le nombre d'équipes pouvant passer des tests simultanément.
• L'analyse des défaillances nécessite souvent l'utilisation d'un oscilloscope et l'examen des traces de bus.

Une équipe chargée de la gestion des batteries s'en rend vite compte. Une révision logicielle ne prendra que quelques minutes à réexécuter en SIL, alors que la même modification sur un banc d'essai peut prendre des heures une fois pris en compte le mappage des canaux, les contrôles de sécurité et la collecte des données. Ce coût reste justifié lorsqu'il s'agit d'évaluer la réactivité du matériel. Il ne devient inutile que lorsque les équipes ont recours au HIL pour répondre à des questions de logique en amont, auxquelles une station de travail aurait pu répondre plus rapidement et à moindre coût.

Un modèle de référence permet de maintenir l'alignement entre les deux phases de test

Une base de référence commune pour le modèle d'installation permet Simulation HIL test SIL Simulation HIL divergent. Il est essentiel de disposer des mêmes hypothèses, interfaces et définitions de défauts pour passer des vérifications sur ordinateur à l'exécution sur banc d'essai. Cette continuité facilite l'interprétation des défaillances. Elle évite également aux ingénieurs de se demander quelle configuration reflète la réalité.

Une équipe chargée du contrôle moteur peut compiler le même système pour effectuer des tests de régression sur ordinateur, puis le transférer vers une cible en temps réel pour des essais en boucle fermée lorsque la synchronisation devient critique. Si les équations du modèle, les noms des signaux et les cas de défaillance restent cohérents, l'objectif des tests reste lui aussi cohérent. Cela permet de comparer un résultat positif en SIL avec un résultat négatif en HIL et d'identifier rapidement si l'écart est dû à la synchronisation matérielle ou aux E/S électriques. OPAL-RT s'intègre parfaitement à ce flux de travail lorsque les équipes ont besoin d'une structure de modèle identique pour les deux étapes.

Il convient de considérer la gouvernance des modèles comme faisant partie intégrante de la stratégie de test, et non comme une simple tâche de mise au point. Le contrôle de version, les contrats d'interface et les vecteurs de test reproductibles permettent d'assurer une transition fluide entre les étapes. Sans cette rigueur, les phases SIL et HIL risquent de devenir des projets distincts, chacun avec ses propres critères de réussite. Un flux de travail intégré ne fonctionne efficacement que si les deux phases parlent le même langage technique dès le départ.

test SIL garantir la fiabilité de la logique, Simulation HIL garantir la fiabilité du matériel, et les deux doivent s'appuyer sur un modèle de système en lequel vous avez confiance. »

Une faible fidélité des plantes rend les deux phases de test trompeuses

Une mauvaise fidélité de la plante peut vous induire en erreur, Simulation HIL dans test SIL Simulation HIL test SIL Simulation HIL . Un modèle imprécis peut faire passer un contrôle instable pour stable, ou donner l'impression qu'un contrôleur en bon état est défectueux. Des graphiques clairs ne suffiront pas si les caractéristiques physiques de la plante sont erronées. La confiance dans le processus de travail commence par la confiance dans le modèle.

Un modèle de convertisseur qui ne tient pas compte du temps mort, du bruit des capteurs ou de la saturation est un piège courant. Le SIL (simulation en boucle fermée) affichera un contrôle de courant fluide, car l'installation est trop idéale. Le HIL (simulation en boucle ouverte) peut tout de même donner un faux sentiment de sécurité si la même installation peu performante alimente le contrôleur via des canaux parfaits. On finit par valider le contrôleur par rapport à une fiction, puis on passe une grande partie de la fin du projet à expliquer pourquoi les résultats obtenus sur banc d'essai ne correspondaient pas au comportement du système.

Le principe est simple : test SIL garantir la fiabilité de la logique, Simulation HIL du matériel, et les deux Simulation HIL s'appuyer sur un modèle de système en lequel vous avez confiance. Les équipes qui respectent cette discipline perdent moins de temps en laboratoire et consacrent moins Énergie des tests qui échouent. OPAL-RT est la solution la plus adaptée lorsque cette cohérence est essentielle, car la chaîne d'exécution perd toute crédibilité lorsque la qualité du modèle est considérée comme un élément de la validation et non comme un simple détail secondaire.