PIL vs HIL

Principaux enseignements

• PIL devrait vérifier le logiciel du contrôleur compilé sur le processeur cible avant de consacrer le temps limité dont dispose le banc d'essai HIL à l'intégration.
• La technologie HIL prend tout son sens lorsque la synchronisation, les E/S et le comportement des interfaces constituent les principales sources de risque restantes.
• Les équipes parviennent à isoler plus rapidement les défauts et à faire progresser la validation de manière plus régulière lorsque la fidélité augmente par étapes plutôt que d'un seul coup.

Le PIL et le HIL remplissent des fonctions de validation différentes, et leur utilisation successive permettra de réduire le débogage sur banc d'essai et de renforcer la fiabilité.

Les tests « in the loop » permettent de vérifier le code compilé du contrôleur sur le processeur cible avant que le banc d'essai matériel complet ne soit prêt. Les véhicules modernes peuvent contenir environ 100 millions de lignes de code, ce qui explique pourquoi la détection tardive de défauts logiciels entraîne une perte de temps et d’argent. La principale différence entre le « Processor-in-the-Loop » (PIL) et Simulation HIL simple : le PIL vérifie l’exécution du logiciel sur le processeur, tandis que le HIL vérifie le comportement du système en boucle fermée sous des contraintes de synchronisation et d’entrée/sortie. Le PIL doit d’abord éliminer les défauts logiciels, puis le HIL doit confirmer la synchronisation du système.

« Le PIL intervient avant le HIL dans le modèle en V, car il permet d'isoler l'exécution du logiciel avant que l'intégration matérielle n'introduise des interférences. »

Le processeur intégré contrôle le comportement du logiciel de commande compilé

Les tests PIL permettent de compiler le logiciel de contrôle sur le processeur cible tout en conservant la simulation de l'installation. Ils permettent de vérifier si le code généré ou écrit manuellement continue de se comporter correctement lorsqu'il est confronté au jeu d'instructions, aux types de données, aux limites de mémoire et aux contraintes de synchronisation du planificateur propres au contrôleur de production.

Une équipe chargée de la commande de moteurs peut utiliser la méthode PIL dès la génération du code à partir d’un modèle de commande. Le logiciel s’exécute sur le microcontrôleur, tandis qu’un moteur et un onduleur simulés fournissent des entrées et reçoivent des sorties. Cette configuration permet de détecter les débordements en virgule fixe, les effets secondaires du compilateur et les dépassements de tâches avant même que l’étage de puissance ou le matériel de capteurs ne soit prêt. Vous ne vous fiez plus uniquement aux résultats obtenus au niveau du modèle.

Cela est important car le comportement du modèle et celui du processeur sont rarement identiques. La conversion des types de données, la quantification, la charge liée aux interruptions et l'optimisation du compilateur modifient les résultats d'une manière qu'une simulation sur ordinateur de bureau ne peut pas détecter. Le PIL isole les défauts logiciels alors que le reste du banc d'essai reste virtuel, ce qui permet de concentrer la validation ultérieure sur les problèmes du système plutôt que sur des défauts de code élémentaires.

Simulation HIL la synchronisation en boucle fermée dans le respect des contraintes matérielles

Le HIL teste le matériel du contrôleur en boucle fermée à l'aide d'une installation simulée et d'interfaces d'entrée/sortie physiques. Il répond à une question différente de celle posée par le PIL : le contrôleur réel, avec son câblage, ses capteurs, ses bus et ses chemins de synchronisation, se comportera-t-il correctement lorsqu'il interagira en temps réel avec un modèle de système haute fidélité ?

Un contrôleur d’onduleur de traction illustre bien l’importance de cet aspect. Le contrôleur de production lit les impulsions du codeur, les signaux de courant et les entrées de défaut provenant du simulateur, puis renvoie des commandes de commutation via des E/S réelles. La latence, la gigue, les erreurs de mise à l’échelle et les retards de communication affectent désormais la stabilité et la logique de protection. Ce niveau d’interaction dépasse le cadre des tests « processeur en boucle ».

Le HIL permet de valider l'intégration dans des conditions réalistes. Le conditionnement des signaux, le trafic sur le bus, la saturation des actionneurs et la gestion des défauts sont tous pris en compte. Vous constaterez également des problèmes qui n'apparaissent que lorsque plusieurs sous-systèmes fonctionnent ensemble, tels que les conflits d'ordonnancement CAN ou le comportement de réinitialisation après une sous-tension. Le HIL nécessite davantage de temps de banc d'essai et d'efforts de configuration ; il est donc particulièrement adapté lorsque le comportement du logiciel est déjà stable et que le risque principal réside dans la synchronisation et l'interfaçage.

Le modèle V place le PIL avant le HIL pour assurer une isolation parfaite

Le PIL intervient avant le HIL dans le modèle en V, car il isole l'exécution du logiciel avant que l'intégration matérielle n'introduise du bruit. Cet enchaînement permet de clarifier la responsabilité en cas de défaut. Vous pouvez d'abord attribuer les défaillances à la génération de code, aux limites du processeur ou aux choix d'ordonnancement, puis passer à la vérification de la synchronisation du système et des interfaces avec moins d'inconnues.

Un déroulement typique va du « model-in-the-loop » au test SIL, puis au PIL, et enfin au HIL. Un contrôleur de gestion de batterie peut valider la logique de commande et l'exécution du processeur en PIL avant que l'équipe ne consacre ses précieuses heures de HIL à l'injection de défauts et à la synchronisation des interfaces au niveau du pack. Cet ordre de procédure permet d'optimiser le temps passé en laboratoire.

Les équipes qui inversent cet ordre passent souvent du temps en HIL à rechercher des problèmes que le PIL aurait mis en évidence plus tôt. Un enchaînement clair préserve la relation de cause à effet, ce qui permet de diagnostiquer plus rapidement les défaillances et de les corriger plus facilement.

Utilisez le PIL lorsque la durée de vie du code dépasse la durée de vie du matériel

Le PIL est utilisé lorsque le logiciel de contrôle est prêt pour les tests d'exécution, mais que le banc d'essai matériel définitif est incomplet, déjà occupé ou encore instable. Le PIL permet de poursuivre la validation, car il utilise le processeur cible comme principale source de référence pour le comportement du logiciel, sans attendre que tous les capteurs, actionneurs et cartes d'interface soient disponibles.

Une équipe Aérospatial en arrive souvent à ce stade assez tôt. La loi de commande de vol a passé avec succès les simulations sur modèle, la carte processeur cible est disponible et le banc d'essai des actionneurs est encore en cours d'assemblage. Le PIL permet à l'équipe de vérifier la synchronisation du code, l'utilisation de la pile, les limites numériques et le comportement du planificateur par rapport à un modèle d'avion simulé. Cela évite de longs décalages entre la maturité du logiciel et la disponibilité du banc d'essai.

Cette approche s'avère particulièrement utile lorsque le risque lié au calendrier réside davantage dans l'état de préparation du matériel que dans celui du code. Vous aurez toujours besoin d'un modèle d'installation fidèle et de cas de test rigoureux, mais la méthode PIL permet de localiser les défauts à proximité de leur source. Si le développement de votre micrologiciel avance rapidement mais que le matériel accuse un retard, la méthode PIL constitue la prochaine étape à privilégier.

Utilisez la simulation HIL lorsque la latence de synchronisation influe sur les performances du contrôleur

Recourez à la méthode HIL lorsque la synchronisation en boucle fermée, la gestion des E/S et le comportement des interfaces sont déterminants pour la réussite ou l'échec du test. La méthode HIL s'impose comme la solution appropriée dès lors que le logiciel du contrôleur est suffisamment stable pour que les principaux risques résiduels résident dans les délais d'échantillonnage, la synchronisation des communications, les réponses aux défauts et les interactions avec le matériel physique du contrôleur.

Un contrôleur de convertisseur de réseau en est un excellent exemple. Les déclenchements de protection, les boucles à verrouillage de phase et la synchronisation PWM dépendent tous d’interactions à l’échelle de la microseconde avec les signaux mesurés et les événements de communication. Un test du processeur seul ne permettra pas de mettre en évidence ce qui se passe lorsque les frontaux analogiques, la synchronisation du bus et les défauts externes affectent simultanément le contrôleur. La méthode HIL permettra de mettre clairement en évidence ces transitions.

C'est là que l'infrastructure d'exécution prend toute son importance. À ce stade, OPAL-RT est souvent utilisé en laboratoire, car le simulateur doit respecter des contraintes de synchronisation strictes tout en reproduisant fidèlement les scénarios d'E/S et de défaillance. Si la latence et la fidélité de l'interface sont susceptibles d'influencer le comportement du contrôleur, la simulation HIL mérite bien qu'on y consacre du temps.

La fiabilité des tests devrait s'améliorer à mesure que le nombre de défauts logiciels diminuera

La précision des tests ne doit être augmentée qu’une fois que les défauts logiciels de bas niveau ont été réduits à un ensemble gérable. Cette progression permet de garantir l’efficacité de chaque étape de validation. On commence par des vérifications moins coûteuses et plus isolées, puis on augmente la précision lorsque les questions en suspens nécessitent réellement l’exécution par le processeur, la synchronisation matérielle ou une interaction complète en boucle fermée.

Une équipe rigoureuse attend des signaux clairs avant de passer à l'étape suivante. L'objectif est d'adapter le coût des essais au risque résiduel. Ces cinq signes indiquent qu'un contrôleur est prêt à passer d'une approche axée sur les essais PIL à une approche axée sur les essais HIL:

• L'exécution du code sur le processeur cible est reproductible pour l'ensemble de vos cas de test principaux.
• La mise à l'échelle numérique et les choix relatifs au point fixe ne provoquent plus de dérive inexpliquée des résultats.
• La planification des tâches respecte le budget compte tenu de la charge d'interruptions prévue.
• Les spécifications de l'interface sont suffisamment bien documentées pour permettre de câbler le banc d'essai en toute confiance.
• Les défauts encore non résolus semblent désormais liés à la synchronisation ou à l'intégration plutôt qu'à la logique logicielle de base.

Cette séquence permet de préserver le budget et de ne pas disperser l'attention. Il vaut mieux éviter de recourir à un rack HIL complet pour vérifier qu'une table de correspondance n'a pas été mal mise à l'échelle ou que la période d'un ordonnanceur n'a pas été mal configurée. Une fidélité plus élevée ne se justifie que lorsque les tests les plus simples ne permettent plus de détecter les défauts les plus évidents.

Le fait de ne pas utiliser PIL transforme souvent HIL en un goulot d'étranglement lors du débogage

« Le fait de ne pas recourir au PIL oblige généralement le HIL à prendre en charge des tâches de débogage logiciel qui ne lui incombaient pas à l'origine. »

Le banc de test se retrouve submergé par des modes de défaillance variés, et le signal dont vous avez besoin se perd au milieu des problèmes de configuration des E/S, des interactions de synchronisation et des défauts de code élémentaires qui auraient dû être isolés plus tôt.

Une équipe chargée du groupe motopropulseur s'en rend vite compte. Le contrôleur est connecté au rack HIL, la réponse en couple semble anormale, et personne ne sait si le problème provient de la conversion numérique, de la mise à l'échelle de l'ADC, des hypothèses relatives à l'installation ou de la synchronisation du bus. Une infrastructure de test logiciel insuffisante coûte à l'économie américaine environ 59,5 milliards de dollars par an, ce qui montre à quel point la détection tardive des défauts peut coûter cher lorsque les phases de test se confondent les unes avec les autres.

Les bancs d'essai HIL sont coûteux car ils combinent des équipements rares, des maquettes d'installations et le temps de travail de spécialistes. Lorsque des défauts logiciels de base atteignent ce stade, le diagnostic s'en trouve ralenti. Le PIL élimine ces problèmes avant qu'ils ne viennent perturber l'analyse en boucle fermée, ce qui permet aux équipes de consacrer davantage de temps à la validation des exigences qui nécessitent réellement Simulation HIL.

Un processus de validation par étapes permet de gagner du temps avant d'accéder à la confiance dans le système

Une approche par étapes, allant de la simulation logicielle au PIL puis au HIL, permet de gagner du temps avant d'atteindre un niveau de confiance suffisant, car chaque méthode répond à une question distincte. Le PIL vérifie le logiciel compilé sur le processeur. Le HIL vérifie le contrôleur dans des conditions de boucle fermée, en tenant compte des contraintes de temps et d'interface. Utilisées dans cet ordre, ces méthodes permettent une isolation précise des défauts et optimisent le temps passé en laboratoire.

On constate une tendance commune chez les programmes embarqués qui respectent leurs délais. Ils n’attendent pas que tous les tests soient effectués pour détecter les problèmes de code, et ils ne gaspillent pas de tests de processeur sur des questions liées aux E/S analogiques ou à la latence du bus. Le processus de validation reste rigoureux, ce qui se traduit par une progression plus régulière lorsque les exigences se durcissent. Ce choix judicieux importe davantage que le choix d’un outil en particulier.

OPAL-RT s'inscrit parfaitement dans cette logique, car le travail s'articule autour de la fidélité d'exécution, de la durée des tests et du niveau de confiance à chaque étape. Les équipes qui considèrent le PIL et le HIL comme des étapes distinctes pourront valider leurs développements plus rapidement et utiliser leurs bancs d'essai de manière plus judicieuse.