HIL, SIL ou MIL : choisir le bon niveau de test pour un projet calculateur

Trois semaines avant une livraison d'échantillons, l'équipe d'intégration branche le premier calculateur sur le banc HIL, et la consigne de couple oscille à 8 Hz. Les essais en model-in-the-loop étaient propres. Les essais en software-in-the-loop aussi. La cause : un écart de 2 ms entre la période d'échantillonnage supposée par le modèle et celle que l'ordonnanceur fournit réellement sur la cible, plus un filtre du premier ordre sur l'entrée capteur que personne n'avait modélisé. Aucun niveau n'était « faux ». L'erreur était d'attendre d'un niveau qu'il trouve un défaut que seul un autre peut voir.

C'est la vraie question derrière « HIL, SIL ou MIL ». Ce ne sont pas des options concurrentes, ce sont des filtres de mailles différentes. La décision d'ingénierie consiste à choisir quel défaut on veut attraper à quel endroit, et à quel coût par essai.

1. Les quatre niveaux, définis par ce qui est réel

Le plus simple pour distinguer les niveaux est de se demander, pour chacun, ce qui est réel et ce qui est simulé.

• MIL (model-in-the-loop) : le contrôleur est un modèle, le procédé aussi. Les deux tournent dans le même outil de simulation, en général sur un PC, souvent hors temps réel. On teste l' algorithme.
• SIL (software-in-the-loop) : le contrôleur devient le code de production, généré ou écrit à la main, compilé pour le PC, toujours relié au modèle du procédé. On teste le code par rapport à l'algorithme : types de données, mise à l'échelle en virgule fixe, saturations, initialisation, machines d'état.
• PIL (processor-in-the-loop) : le même code est compilé avec le compilateur cible et tourne sur le processeur cible (ou une carte d'évaluation), en échangeant toujours avec le modèle par une liaison de debug ou de communication. On teste les effets du compilateur et du processeur: temps d'exécution, pile, comportement numérique.
• HIL (hardware-in-the-loop) : le vrai calculateur, avec son matériel et un logiciel proche de la série, est relié par de vraies interfaces électriques à un modèle du procédé qui tourne sur une cible temps réel. On teste le calculateur en tant que produit: entrées, sorties, drivers, diagnostics, timing, comportement en alimentation, communication.

Le PIL est souvent oublié, mais il répond à une question que ni le SIL ni le HIL ne traitent à faible coût : le code tient-il, en temps et en mémoire, sur la puce qui sera livrée ?

1.1 Schéma de principe (décrit)

Imaginez quatre blocs alignés de gauche à droite ; à chaque étape, un bloc simulé est remplacé par un bloc réel :

1. MIL : [modèle du contrôleur] ⇄ [modèle du procédé], dans une seule simulation, reliés par des signaux sans réalité physique.
2. SIL : [code C compilé sur PC] ⇄ [modèle du procédé], via une enveloppe logicielle.
3. PIL : [code sur le processeur cible] ⇄ liaison série ou debug ⇄ [modèle sur PC].
4. HIL : [calculateur réel] ⇄ faisceau ⇄ breakout et injection de défauts ⇄ conditionnement ⇄ cartes d'E/S ⇄ [modèle sur cible temps réel], avec un PC hôte pour l'automatisation et l'enregistrement.

Chaque pas vers la droite ajoute du réalisme, du coût par essai et du temps de mise en place. Chaque pas vers la gauche ajoute de la vitesse, de la répétabilité et de la couverture par heure.

2. Ce que chaque niveau peut trouver, ou non

Type de défaut	MIL	SIL	PIL	HIL
Loi de commande fausse, exigence mal interprétée	Oui	Oui	Oui	Oui, mais cher
Débordement en virgule fixe, mise à l'échelle, types	Non	Oui	Oui	Oui
Dépassement de temps d'exécution, débordement de pile	Non	Non	Oui	Oui
Seuils d'entrée, filtrage, référence ADC	Non	Non	Non	Oui
Diagnostics des drivers (charge ouverte, court-circuit à la batterie ou à la masse)	Non	Non	Non	Oui
Démarrage, reset, comportement en sous-tension	Non	Non	Non	Oui
Timing bus, gestion réseau, diagnostic sur CAN	En partie (simulé)	En partie	En partie	Oui

Le tableau porte à lui seul l'argument économique. Toute ligne qui peut être fermée en MIL ou en SIL doit l'être, parce qu'un essai y coûte quelques secondes de calcul et peut tourner la nuit par milliers. Le temps HIL est la ressource rare : un banc, un calculateur, du temps réel. Il doit servir aux lignes que seul le HIL peut fermer.

3. Exemple de calcul 1 : pourquoi une hypothèse de timing casse entre deux niveaux

Exemple (valeurs d'illustration, pas des spécifications RAYNOV).

Un régulateur PI de vitesse est conçu en MIL avec une période d'échantillonnage Ts = 10 ms. Sur la cible, la tâche tourne bien toutes les 10 ms, mais la mesure qu'elle lit a été acquise par l'ADC à la fin de la tâche précédente : le retard effectif entre mesure et commande est proche d'une période complète, τ ≈ 10 ms (un bloqueur d'ordre zéro ajoute environ une demi-période de plus ; nous gardons 10 ms pour simplifier).

Un retard pur τ ajoute, à la fréquence f, un déphasage :

φ = 360° × f × τ

Si la fréquence de coupure en boucle fermée est de 8 Hz :

φ = 360 × 8 × 0,010 = 28,8°

Si la conception MIL avait une marge de phase de 40°, la marge réelle tombe à environ 11°. La boucle ne diverge pas, mais elle oscille : exactement le comportement de l'histoire d'ouverture. La correction est peu coûteuse si on la trouve tôt : modéliser le retard (un bloc de retard unitaire) en MIL, et l'effet y apparaît. En HIL, il apparaît de toute façon, mais il coûte alors une journée de banc et une livraison logicielle.

Leçon : intégrer dès le MIL les vraies hypothèses de timing de la cible (périodes de tâches, instants d'échantillonnage, retards de communication). Le HIL les confirme alors au lieu de les découvrir.

4. Exemple de calcul 2 : le pas temps réel du HIL

Exemple (valeurs d'illustration, pas des spécifications RAYNOV).

Un banc HIL doit faire tourner le modèle du procédé assez vite pour que le calculateur ne puisse pas savoir qu'il est simulé. Une règle pratique courante consiste à prendre un pas de modèle 10 à 20 fois plus court que la constante de temps la plus rapide (ou au moins 10 échantillons par période du signal le plus rapide) que le calculateur commande ou observe ; 5× est un strict minimum.

Supposons que le calculateur pilote un injecteur ou une électrovanne en PWM à 1 kHz et relise un courant moyenné. La dynamique utile est la constante de temps électrique de la bobine, τ = L / R. Avec L = 10 mH et R = 5 Ω :

τ = 0,010 / 5 = 2 ms

Un pas de 200 µs (τ / 10) représente correctement la montée du courant. Si le calculateur mesure au contraire le courant à l'intérieur de chaque période PWM, le modèle doit résoudre la période de 1 ms elle-même, et un pas de 200 µs ne donne que 5 points par période : c'est trop grossier. Il faut alors un pas bien plus court, ou des E/S sur FPGA qui génèrent et mesurent la PWM en matériel pendant que le modèle tourne plus lentement.

Leçon : l'architecture du HIL (pas de modèle sur CPU ou E/S sur FPGA) découle du signal le plus rapide que le calculateur regarde réellement, pas de la taille du modèle. Le guide sur l'architecture d'un banc HIL détaille les blocs et les contraintes de timing, et le guide sur le timing d'acquisition et la gigue explique pourquoi un système d'exploitation de bureau ne peut pas fermer une telle boucle.

5. Répartir le plan de test entre les niveaux

Une approche pratique consiste à associer chaque exigence au niveau le plus bas capable de la vérifier, puis à ne monter que si nécessaire.

1. Logique fonctionnelle et lois de commande → d'abord en MIL, puis en régression SIL à chaque modification du code.
2. Qualité du code et comportement numérique → SIL (tests dos à dos : mêmes stimuli au modèle et au code, comparaison des sorties avec une tolérance).
3. Budgets de ressources et de temps → PIL, ou HIL avec mesure du temps d'exécution si le PIL n'est pas en place.
4. Interfaces électriques, diagnostics, modes d'alimentation, réactions aux défauts → HIL uniquement.
5. Intégration avec les autres calculateurs et le réseau → HIL avec simulation du reste du bus, puis véhicule.

Les tests dos à dos méritent un mot. Faire passer les mêmes vecteurs de stimuli en MIL et en SIL, puis comparer les sorties échantillon par échantillon, est l'un des moyens les moins chers de prouver que la génération de code, le passage en virgule fixe ou le codage manuel n'ont pas changé le comportement. La tolérance doit être écrite (par exemple un nombre fixe de LSB par sortie), sinon chaque écart de quantification devient un débat.

5.1 Réutiliser d'un niveau à l'autre

Le gain le plus important ne vient pas d'un niveau, il vient de la réutilisation :

• Le même modèle du procédé du MIL au HIL, après vérification qu'il tourne en temps réel au pas requis. Échanger les modèles sous forme de FMU grâce au standard FMI aide quand plusieurs outils sont en jeu.
• Les mêmes cas de test, écrits sur des noms de signaux plutôt que sur des variables propres à un outil, pour qu'un test MIL puisse être rejoué en HIL en changeant seulement l'affectation. Le guide des scripts au séquenceur de test explique comment structurer cela.
• Les mêmes critères de réussite, avec des tolérances élargies explicitement là où le matériel réel ajoute du bruit, et pas en silence.

6. Ce que seul le HIL apporte, et comment s'y préparer

Quand le calculateur est sur le banc, la valeur se trouve dans les essais électriques et système qu'aucune simulation ne remplace :

• L'injection de défauts broche par broche : circuit ouvert, court-circuit à la masse, à la batterie, entre broches, piloté par le séquenceur. Voir le guide sur l'injection de défauts sur faisceaux et calculateurs.
• L'accès à la mesure sur chaque signal sans couper le faisceau, grâce à une breakout box. Sa spécification est traitée dans le guide de spécification d'une breakout box.
• Le comportement en alimentation: profils de démarrage, rampes lentes de tension, micro-coupures, inversion de polarité.
• Le conditionnement des entrées: les vrais seuils et filtres des entrées numériques et analogiques. Le guide sur le conditionnement des entrées numériques montre pourquoi ils comptent.

Un banc compact et économique comme le Mini HIL de RAYNOV apporte la simulation temps réel, l'injection de défauts et l'exécution automatisée au laboratoire, en R&D ou en production, sans l'encombrement d'un système complet.

7. Erreurs fréquentes

• Faire du HIL le niveau principal de test fonctionnel. Il devient le goulot d'étranglement, et le banc passe son temps à retrouver des bugs de logique que le SIL aurait trouvés en quelques minutes.
• Oublier le timing dans le modèle. Pas de retards, pas d'échantillonnage, des capteurs idéaux en MIL, puis la surprise en HIL.
• Des cas de test différents à chaque niveau. Deux équipes, deux langages de test, aucune traçabilité entre un résultat MIL et un résultat HIL.
• Valider le calculateur sur un banc non validé. Si le banc lui-même n'a pas été vérifié (précision des E/S, timing, chemins d'injection de défauts), un essai en échec peut venir du banc. La qualification du banc est traitée dans le guide FAT et SAT.
• Négliger le faisceau. Un faisceau de banc dont les longueurs, les masses ou les connecteurs diffèrent du véhicule peut masquer ou créer des défauts.
• Aucun critère de sortie par niveau. Sans eux, un niveau ne se termine jamais, ou se termine parce que le calendrier le dit.

8. Check-list : choisir et planifier les niveaux de test

• [ ] Chaque exigence associée au niveau le plus bas capable de la vérifier.
• [ ] Périodes de tâches, retards d'échantillonnage et latences bus modélisés dès le MIL.
• [ ] Comparaison dos à dos MIL/SIL avec des tolérances écrites.
• [ ] Temps d'exécution et pile mesurés sur la cible (PIL ou HIL).
• [ ] Signal le plus rapide observé par le calculateur identifié ; pas du modèle HIL ou E/S FPGA choisis en conséquence.
• [ ] Cas de test écrits une fois, affectés à chaque niveau.
• [ ] Liste d'injection de défauts par broche définie avant la commande du banc HIL.
• [ ] Banc qualifié avant de servir à accepter un logiciel calculateur.
• [ ] Critères de sortie et objectif de couverture écrits pour chaque niveau.
• [ ] Essais de réception distingués des essais de qualification (voir ATP vs QTP).

9. Conclusion

MIL, SIL, PIL et HIL ne sont pas une échelle que l'on gravit une seule fois. Ce sont des filtres parallèles, chacun bon marché pour certains défauts et aveugle à d'autres. Un projet calculateur bien planifié dépense largement les heures de simulation et prudemment les heures de HIL, réutilise modèles et cas de test d'un niveau à l'autre, et arrive au banc avec uniquement les questions qui exigent du matériel réel.

Pour aller plus loin, l'article général sur la simulation hardware-in-the-loop et la norme de sécurité fonctionnelle ISO 26262 , qui décrit la vérification aux niveaux d'intégration logicielle et matérielle, sont de bons points de départ.

Vous préparez un banc HIL ou vous hésitez sur le niveau de test adapté à votre calculateur ? Demandez un devis à RAYNOV : nos ingénieurs examineront votre plan de test avec vous.