Si vous effectuez une recherche sur les tests "Hardware-in-the-Loop" (HIL), vous trouverez souvent des exemples de systèmes complexes en temps réel. Cet article de National Instruments, par exemple, fournit une bonne explication et un contexte sur ce qu'est le hardware-in-the-loop (HIL), et présente un exemple de test des unités de contrôle électronique au sein d'une automobile. Dans cet article, nous nous concentrerons sur une version plus petite et plus facile à appréhender des concepts de test HIL.
Pour les besoins de cet article, nous définirons le test hardware-in-the-loop un peu différemment de la manière dont il est présenté conventionnellement (par exemple, dans les applications automobiles). Observons trois différentes couches de complexité lorsqu'il s'agit de tester un produit.
Dans cette forme de test, un ingénieur testera manuellement le dispositif. Cela peut consister à sonder des points de test sur une carte avec un multimètre numérique, à observer des formes d'onde sur un oscilloscope, ou à analyser manuellement une lecture de télémétrie sur un écran d'ordinateur. L'ingénieur testera le produit via un test de vérification de conception manuel.
Cette configuration de test effectue les mêmes mesures et vérifications normalement réalisées par un ingénieur, mais est exécutée par un ordinateur de manière automatisée. L'ordinateur hôte communique directement avec les instruments (par exemple, multimètres, oscilloscopes, etc.), analyse la télémétrie provenant du dispositif, puis vérifie l'ensemble de test basé sur les critères établis par l'ingénieur.
Le test Hardware-in-the-Loop porte les tests automatisés à un nouveau niveau en ajoutant des stimuli supplémentaires pour simuler une application réelle. Par exemple, le dispositif sous test (DUT) peut avoir une série de capteurs qui nécessitent une excitation. L'équipement de test simulerait l'autre extrémité de ces capteurs pour exciter le côté capteur du DUT. Un autre exemple pourrait être quelque chose d'aussi simple que d'envoyer du trafic RS-422 dans un récepteur RS-422 sur le DUT. L'idée est que nous sommes capables d'introduire un nouveau stimulus dans le DUT, de lire la télémétrie à partir de l'ordinateur hôte et d'ajuster nos tests en conséquence si nécessaire (par exemple, augmenter la vitesse et la quantité du trafic RS-422 après avoir réussi un test initial).
Selon l'application, il peut être évident pourquoi on choisirait d'adopter les tests matériel-en-boucle plutôt que les tests automatisés (et certainement les tests manuels). Si l'on tente d'intégrer un système complexe ou des systèmes de systèmes, avec beaucoup de stimuli externes nécessaires, un simple test de vérification automatisé ne suffira pas. Considérons un chargeur de batterie basique. Bien que vous pourriez simuler une source d'alimentation, une charge et une batterie pour tester votre circuit de contrôle (soit physiquement soit par logiciel), il serait plus réaliste d'utiliser une alimentation électrique réelle, une batterie et une charge pour tester la conception. De plus, si vous pouvez automatiser ce processus, vos ingénieurs peuvent désormais consacrer leur temps au développement plutôt qu'aux tests.
Lors de la décision d'adopter les tests matériel-en-boucle, on devrait considérer les facteurs suivants :
Une fois que vous avez pris en compte ces facteurs et d'autres, vous pouvez commencer à prendre une décision sur le fait de rester avec les tests manuels ou d'investir dans les tests automatisés/matériel en boucle fermée.
Basé sur mon expérience, j'ai trouvé que, de loin, l'entrée la plus facile dans les tests matériel en boucle fermée serait d'utiliser un cadre de test tout inclus tel que celui fourni par National Instruments (NI). NI propose une plateforme matérielle/logicielle tout inclus qui est prête à l'emploi. Voici quelques avantages et inconvénients à considérer lors de l'envisagement d'un cadre tout inclus :
Pendant le temps que j'ai passé à travailler sur des systèmes complexes, LabVIEW était mon choix privilégié pour les tests automatisés, y compris la construction d'un pipeline complet d'Intégration Continue et de Déploiement Continu pour les projets et VIs LabVIEW. Lorsque je suis passé à des systèmes plus petits nécessitant un support plus simple en boucle fermée, j'ai commencé à me tourner vers du matériel personnalisé ou commercial disponible sur étagère (COTS) et des scripts Python (en utilisant le cadre de test pytest). Encore une fois, tout dépend de l'application et, comme mentionné précédemment, le temps de test, la récurrence des tests et l'équipement de test sont les principaux facteurs qui guident cette décision.
Dans cet article, nous avons examiné le concept de test en boucle fermée matériel et comment il se différencie à la fois du test manuel et automatisé. Nous avons également passé en revue les avantages de l'adoption du test en boucle fermée matériel et comment évaluer s'il répond vraiment aux besoins de l'utilisateur. Enfin, nous avons discuté de quelques façons de commencer. Bien que le test en boucle fermée matériel ne soit pas adapté à tout le monde, il est clair que pour l'application appropriée, l'investissement sera très rapidement rentabilisé.
Souhaitez-vous en savoir plus sur la manière dont Altium peut vous aider avec votre prochain design de PCB ? Parlez à un expert chez Altium ou découvrez-en plus sur les principaux problèmes de DFM et leurs solutions.