Qu'est-ce que le hardware-in-the-loop (HIL) ?

L’impact significatif du délai de mise sur le marché est devenu très visible dans les années 1980 grâce aux travaux révolutionnaires de l’ancien consultant de McKinsey Donald G. Reinertsen, indiquant qu’un « retard de six mois peut valoir 33 % des bénéfices du cycle de vie »i causés par le développement de produits. En outre, le lancement et la destruction de la fusée Ariane 5 le 4 juin 1996, connue comme l’un des bugs logiciels les plus tristement célèbres de l’histoire, ont appris au monde de l’ingénierie l’importance de la qualité des logiciels embarqués et la nécessité de tests appropriés. Il en a résulté une perte de plus de 370 millions de dollars.ii Ces chiffres démontrent clairement les conséquences des retards et la nécessité de réduire les délais de mise sur le marché ainsi que les coûts en identifiant les bugs et les erreurs par des tests appropriés plus tôt dans le cycle de vie de la conception et du développement du produit.

Il est essentiel d’utiliser une technologie qui détecte les défauts avant le début de la production. Il est de plus en plus crucial de faire du test un atout stratégique et intégral, dans le cadre du cycle complet de conception et de développement des produits, et pas seulement une réflexion après coup ou même une démonstration à la toute fin du processus. Cette compréhension a mené au développement et à la mise en œuvre de méthodes et de stratégies connues sous le nom de test de chargement frontal, de déplacement vers la gauche, de conception basée sur modèle et de test XIL (tout-dans-la-boucle). Ce white paper met fortement l’accent sur les tests HIL comme l’une des méthodologies de test cruciales pour la validation des logiciels embarqués.

Avant de plonger directement dans le test HIL, il est primordial de regarder le produit réel à développer : le dispositif ou le système sous test (DUT/SUT). Les produits d’aujourd’hui et de demain sont clairement devenus beaucoup plus centrés sur le logiciel et complexes. Lorsque l’on considère des exemples comme les routeurs Wi-Fi, les lave-vaisselle, les robots culinaires, etc., ils sont tous basés sur des logiciels ou firmware embarqués maintenant. Les voitures, les avions et les smartphones sont de parfaits exemples, non seulement parce qu’ils sont hautement définis par logiciel, mais aussi parce qu’ils sont un système de systèmes basés sur logiciel. En fin de compte, ils ont tous en commun que le logiciel est l’élément déterminant de leur ensemble de fonctionnalités actuel et des améliorations futures à publier. Les applications modifiables sur un smartphone qui en font un multioutil de milliers de fonctionnalités et de fonctions sont l’incarnation claire de cette tendance, qui a évolué vers l’attente indéniable des clients actuels pour presque tous les autres produits également.

Les applications, Firmware et logiciels en général ne peuvent pas être autonomes, car ils ont besoin de matériel pour être exécutés. En général, le matériel est un ordinateur ou un processeur, ou tout simplement un contrôleur. Cela signifie qu’un produit ou un système (y compris les systèmes de systèmes) nécessite la combinaison et l’intégration de matériel (contrôleur) et de logiciel, qui devient alors le DUT. De plus, le contrôleur nécessite également que son environnement interagisse avec. Par exemple, le contrôleur d’une machine à laver doit vérifier s’il y a suffisamment d’eau, mesurer la température de l’eau, contrôler la vitesse (RPM) du tambour de lave-linge, etc. Par conséquent, le contrôleur nécessite la connexion à des capteurs (température, RPM) et des actionneurs (chauffeur, moteur électrique) fournissant des données ou une rétroaction en entrée et envoyant des commandes ou des consignes en sortie. Ce ne sont que les éléments de base de la théorie de conception de boucle de contrôle, comme le montre la figure 1. Ici, l’environnement autour du contrôleur est généralement appelé plante.

Figure 1. Fondamentaux de la conception de boucles de contrôle

En examinant le cycle de conception et de développement du produit, il est évident que tous les composants de la boucle de contrôle ne seront pas disponibles au début d’un projet. Plus encore, il est irréaliste d’avoir tous les composants matériels et logiciels nécessaires prêts et disponibles dès les premières étapes du développement. C’est là que la simulation et la conception basée sur des modèles commencent à combler les lacunes.

La figure 2 montre le cycle de vie du développement du produit dans une représentation typique du diagramme en V, avec ses différentes étapes de la conception au prototypage, aux tests de logiciels et de contrôleurs, et aux tests physiques. Il montre également les méthodologies de test du modèle dans la boucle (MIL), du logiciel dans la boucle (SIL) et du matériel dans la boucle (HIL).

Figure 2. Le diagramme en V : De tout dans la boucle (XIL) au test physique

La simulation numérique et la conception basée sur des modèles sont essentielles tout au long du processus de conception car elles :

• Permettre le développement et les tests avant que les composants physiques requis ne soient disponibles
• Augmentez la couverture des tests, créez des itérations de conception plus rapides
• Améliorez la vitesse en minimisant le nombre de tests redondants (physiques)
• Accélérer les tests de qualité des produits pour les cas particuliers et tous les scénarios possibles

La simulation et la conception basée sur des modèles permettent le démarrage des tests beaucoup plus tôt (appelé test de chargement initial) grâce à des méthodologies de test telles que MIL, SIL et HIL. Comme le montre le bas de la figure 2, les composants de la boucle de contrôle sont remplacés étape par étape lors du déplacement de droite à gauche sur le diagramme en V (également appelé décalage vers la gauche), tout en se déplaçant vers la droite conformément au cycle de vie réel de la conception et du développement du produit, les composants sont remplacés par le matériel et les logiciels réels dès qu’ils sont disponibles.

De plus, les tests virtuels maximisent la couverture des tests et réduisent la quantité de tests physiques longs et coûteux. Une estimation approximative du nombre de défauts détectés dans les logiciels embarqués est de 10 à 20 pour 1000 lignes de code. Cela peut paraître peu à première vue, mais en regardant combien de lignes de code sont maintenant dans les systèmes quotidiens, le nombre estimé de défauts peut être incroyablement élevé. Si l’on considère les dispositifs médicaux, tels que les stimulateurs cardiaques, qui ont 80 000 lignes de code (environ 800 à 1 600 défauts), ou un scanner IRM avec 7 000 000 (environ 70 000 à 140 000 défauts), l’impact de l’expansion de la complexité logicielle devient évident, et bien plus grave.

La complexité de ces systèmes est écrasante au point qu’il devient impossible de les tester de manière exhaustive de manière traditionnelle. Tester physiquement tous les scénarios est impossible, et cela prend une quantité déraisonnable de temps et d’argent. De plus, il est important de s’assurer que les cas de test couvrent toutes les conditions réelles possibles. Les grosses pannes, les catastrophes et les rappels d’appareils coûtent très cher, comme l’indique l’exemple d’Ariane 5 en introduction de ce white paper. Mais plus encore, l’impact négatif de ces conséquences sur l’image de marque et la réputation de l’entreprise est tout simplement inestimable. Il est possible d'atténuer ce risque par la modélisation et la simulation. Pratiquement, il est possible de tester les produits dans tous les scénarios possibles, reproductibles et en toute confiance, de sorte que le test physique final n’est que le dernier contrôle et n’est pas un événement catastrophique coûteux.

Les tests de logiciels embarqués servent de méthodologie pour la détection de problèmes, connectant les équipes de conception et de test avec un flux de travail compatible qui utilise fortement la simulation et la conception basée sur des modèles.

Figure 3. Représentation MIL, SIL, HIL et test physique dans la boucle de contrôle

La première étape, MIL (quadrant 1 de la figure 3), simule tout, y compris le régulateur et toute l’installation (environnement) autour du régulateur.

Au cours de la deuxième étape, SIL (quadrant 2 de la figure 3), les ingénieurs logiciels génèrent du code prêt pour la cible uniquement à partir du modèle de contrôle, remplaçant le bloc et créant un prototype logiciel alors que l’installation est encore simulée. Ces deux premières étapes permettent l’exécution de tests à l’aide de la simulation et les modèles nécessitent à peine des composants matériels physiques réels.

La troisième étape, HIL (quadrant 3 de la figure 3), est essentielle à cette méthodologie. Le code est déployé et exécuté sur une unité de contrôle matérielle physique (une plate-forme de prototypage de contrôle rapide ou un contrôleur produit), ce qui permet de tester tous les scénarios réels possibles en utilisant l’installation simulée et à nouveau avant de passer au test physique (final) (quadrant 4 de la figure 3).

Par conséquent, HIL peut être considéré comme l’équivalent du mariage entre le châssis et la chaîne de traction d’un véhicule avec sa carrosserie sur une ligne de production de véhicule. Il est essentiel d’exécuter le code logiciel développé sur le matériel du contrôleur réel, pour s’assurer que toutes les failles de cadencement, de synchronisation et d’exécution peuvent être identifiées, qui ne sont généralement pas présentes lors de l’exécution du code embarqué dans un environnement SIL, par exemple.

Il y a de grandes attentes et des développements considérables en cours pour mettre davantage l'accent et l'utilisation de MIL et SIL. Mais HIL sera et doit toujours être le point de preuve pour exécuter des logiciels embarqués sur la plate-forme de contrôleur réelle, afin de commercialiser des produits sûrs et sécurisés centrés sur le logiciel en toute confiance. En résumé, les tests HIL présentent les avantages suivants :

• Test sûr : évite les risques d’endommager des équipements coûteux ou dangereux
• Rentabilité : réduit le besoin de prototypes complets
• Développement rapide : permet des tests précoces avant la construction du système complet
• Scénarios répétables : simulez des cas et des défaillances courants et/ou périphériques de manière fiable

Figure 4. L'analogie de poisson : Un système HIL est l’équivalent d’un aquarium.

HIL est une méthodologie de test qui fournit un environnement virtuel ou une réalité virtuelle (jumeau numérique) autour du DUT physique (logiciel embarqué s’exécutant sur un contrôleur) pour lui faire « croire » qu’il est réellement connecté à l’environnement réel (jumeau physique). Une analogie très simple à cela est un poisson dans un aquarium ou un bassin à poissons, comme le montre la figure 4. L’aquarium imite parfaitement l’environnement réel de l’océan, en fournissant un environnement simulé contrôlé, pour s’assurer que les poissons ont tout ce dont ils ont besoin pour survivre (nourriture, eau, température, salinité, etc.).

Lorsque l’on examine le côté technique et que l’on se concentre sur des produits centrés sur le logiciel tels qu’un DUT, le HIL est une technique de test de logiciel embarqué au cours de laquelle les signaux réels d’un contrôleur sont connectés à un système de test (installation). HIL simule la réalité en utilisant des modèles logiciels et une simulation. Ainsi, le système de test HIL imitant l’environnement réel est l’équivalent de l’aquarium, et le DUT (contrôleur physique exécutant le logiciel embarqué) est l’équivalent du poisson. Cela fait croire que le contrôleur (ou DUT) est installé dans le produit assemblé comme une machine à laver, un avion ou une voiture.

Les itérations de test et de conception se déroulent comme si elles étaient connectées au système réel, mais via une installation simulée. En utilisant des scénarios virtualisés répétables, les ingénieurs peuvent exercer le contrôleur dans des milliers de conditions sans avoir besoin d’avoir tous les composants réels disponibles, le coût, la complexité ou les contraintes de planification des tests physiques basés sur le matériel. Le contrôleur réel ou DUT obtient ses entrées du système HIL et renvoie ses sorties au système HIL. Le système HIL comprend des entrées et des sorties, y compris des interfaces de bus, ainsi qu’un noyau de calcul en temps réel qui exécute le logiciel d’application HIL, y compris les modèles d’installation requis. Pour s’assurer qu’une configuration de système de test HIL répond à toutes les exigences afin de fournir une réalité virtuelle étendue autour du DUT, elle doit comprendre au moins ces éléments de base, comme le montre la figure 5 :

• DUT (logiciel embarqué fonctionnant sur un contrôleur)
• Interfaces E/S et bus pour se connecter au DUT
• Calcul temps réel pour lire, écrire et contrôler les bus d'E/S et de communication de manière déterministe, ainsi que pour exécuter des logiciels d'application
• Logiciel d'application pour configurer le système de test, intégrer et déployer des modèles de simulation, exécuter un test ou plusieurs cas de test (manuels et automatisés) ainsi qu'analyser et mettre au point les résultats et les comportements
• Modèle(s) de simulation

Figure 5. Boucle de contrôle dans une configuration de système de test HIL

Comme mentionné précédemment, ce ne sont que les éléments fondamentaux d’un système HIL. Les éléments supplémentaires peuvent également inclure les éléments suivants :

• Insertion de défauts
• E/S numériques FPGA
• Commutation d'E/S
• Conditionnement de signal
• Connexions à des charges ou charges émulées
• Simulation Restbus (entrées requises d'autres contrôleurs; par exemple, dans un système de systèmes)
• Testez l’automatisation jusqu’aux pipelines d’intégration continue et de déploiement continu (CI/CD)

L’approche de test HIL basée sur la plate-forme NI fournit aux développeurs et aux utilisateurs une boîte à outils de blocs de construction ouverts et flexibles, qui permettent une personnalisation intensive à l’aide de produits commerciaux de rayon (COTS), et d’évoluer de la petite paillasse au composant et au système ainsi que des configurations HIL d’intégration complète. Les utilisateurs peuvent décider quoi utiliser et comment étendre et étendre pour relever les défis actuels et futurs. Ils gardent le contrôle total de leur flux de travail ainsi que du développement et de la maintenance de leurs équipements de test, tout en minimisant la dépendance des fournisseurs.

L’architecture du système de test HIL de NI offre une plate-forme matérielle et logicielle complète traitant les différents éléments d’un système HIL. Sa chaîne d’outils ouverte et personnalisable maximise la capacité d’adapter, d’étendre et d’étendre un système de test HIL avec une combinaison de matériel et de logiciels NI, partenaires NI et tiers.

PXI est une plate-forme matérielle standard de l’industrie basée sur une véritable technologie COTS. Il offre les meilleures capacités de cadencement et de synchronisation et constitue un élément fondamental des systèmes de test HIL. Le PXI prend également en charge une large gamme d’interfaces d’E/S et de bus, du CC au RF, y compris la technologie basée sur FPGA, les interfaces à usage général et les protocoles de communication spécifiques à l’industrie.

Ces offres d’E/S et de bus peuvent être encore étendues par l’ajout de la plate-forme NI Switch Load and Signal Conditioning (SLSC). SLSC ajoute des modules frontaux personnalisés au chemin du signal entre les interfaces d’E/S et de bus réelles du côté du système de test et du DUT. Grâce à une connectivité standardisée COTS et à des facteurs de forme, il élimine le processus de câblage point à point sujet aux défaillances. Cela simplifie le système global et permet la commutation et le conditionnement du signal, l’intégration de la charge, l’insertion de défauts, etc.

NI VeriStand est le logiciel d’application de base pour le test de systèmes HIL et de logiciels embarqués NI en temps réel. Il accélère le cycle de vie du développement de produits grâce à la configuration et au contrôle du système HIL (IU et API), à la mise au point, à l’intégration de modèles, à la génération de stimulus en temps réel, à l’automatisation du produit ainsi qu’à de nombreuses fonctionnalités d’API d’automatisation personnalisée via NI LabVIEW, C/C++, Python, etc.

Pour en savoir plus sur l’architecture NI HIL Test System, cliquez ici.

Les produits d’aujourd’hui sont devenus centrés sur le logiciel, et le fondement sous-jacent de l’attente du client est qu’un produit évolue et s’améliore à l’avenir, fournissant une valeur continue et même nouvelle. Les tests de validation virtuelle utilisant la simulation, la conception basée sur modèle et les tests HIL sont des méthodologies clés pour augmenter la couverture des tests et la qualité des produits. Ces méthodologies réduisent également le temps de mise sur le marché en commençant et en intégrant les tests dans les premiers cycles de conception et de développement, tout en minimisant le besoin de tests physiques coûteux et longs.

Cela transforme le mot « test », qui est souvent défini et utilisé comme les étapes finales nécessaires pour mettre une conception en production et finalement sur le marché, en un avantage stratégique pour l’innovation globale du produit. HIL élève les tests à plus qu’une case à cocher sur un plan de projet. Il devient partie intégrante de l’innovation qui fait le succès d’un design et d’une entreprise (voir « un délai de six mois peut valoir 33 % des bénéfices du cycle de vie »).

Les entreprises avant-gardistes utilisent HIL en dehors de la voie traditionnelle des tests de mise sur le marché. Bien que l’objectif à long terme de HIL soit d’éviter les erreurs coûteuses (comme dans l’exemple d’Ariane 5) dans un produit final coûteux et/ou fabriqué en série, c’est également un outil de conception que les ingénieurs logiciels peuvent utiliser pour tester et modifier itérativement leurs conceptions logicielles. Cela conduit à un produit vérifié avant même que les tests officiels ne commencent. De plus, les ingénieurs logiciels peuvent concevoir et tester rapidement de nouvelles idées, ce qui les aide à maximiser l’innovation grâce à un feedback opportun.

• Architecture du système de test HIL
• Voir comment Whirlpool utilise les tests HIL
• Découvrez comment HIL a accéléré Archer Aviation
• Voir comment ZF valide ADAS avec HIL