Solutions économiques pour l'automatisation des tests en boucle fermée du matériel

Dans le monde trépidant d'aujourd'hui où les itérations d'électroniques sont lancées à des vitesses fulgurantes, nous oublions souvent l'un des aspects les plus critiques du développement : les tests. Il est toujours facile de négliger les tests simplement parce que c'est la dernière étape qui nous empêche de lancer notre produit. Dans le développement de produits, nous nous retrouvons constamment dans le camp du "suffisamment bon" versus "testé de manière exhaustive". Cette situation se produit généralement parce que nous n'avons pas le temps de tester, de re-tester, puis de tester encore plus.

Dans la meilleure des situations, nous aurions embauché une équipe de test à part entière qui est équipée pour effectuer des tests exhaustifs. Même si nous avons cette équipe de test sophistiquée, sommes-nous vraiment capables de les utiliser pour chaque modification, chaque petit changement insignifiant que nous apportons à nos prototypes ? Dans la plupart des cas, la réponse est non, et dans cet article, je voudrais aborder le problème avec une solution où vous pouvez avoir le beurre et l'argent du beurre. Dans cet article, nous examinerons un système de test très peu coûteux, mais très efficace et assez exhaustif qui vous donnera ce rapport qualité-prix que vous recherchez.

Test manuel vs. Test automatisé

Il est assez courant dans l'industrie d'avoir une configuration de test automatisée (principalement pour les tests de niveau de production). Cependant, pour le développement de produits, ce n'est pas une pratique courante. Comme mentionné ci-dessus, le coût et le temps de développement pour mettre en place un équipement de test automatisé sophistiqué nécessite un niveau d'effort élevé. Ce type de coût et d'effort n'est justifié que pour la production en grandes quantités ou en faibles volumes avec des configurations de test très sophistiquées (par exemple, des systèmes spatiaux à faible volume devant être testés environnementalement de nombreuses fois). Pour le reste du monde, nous avons recours à des tests manuels basiques et fastidieux. Ce genre de tests peut aller de la validation ADC/DAC, aux vérifications de protocoles, aux tests de consommation d'énergie, etc. Peu importe le type de test, l'espoir est qu'il ne doive être effectué qu'une ou deux fois, puis qu'il puisse être transmis au groupe de test.

Conséquences Inattendues et Automatisation

La réalité est que, durant notre développement, que ce soit lors des phases de conception/matérialisation du matériel ou du développement de logiciels embarqués, nous causons involontairement des dysfonctionnements. Certains exemples pourraient être un pont de soudure entre les pads ou un code de pilote empiétant sur d'autres codes de pilotes pouvant entraîner une panne. Quel que soit le résultat, il est clair que les tests ne se font pas juste une ou deux fois. Des problèmes surviennent, et effectuer des tests exhaustifs devient généralement trop épuisant après la dixième fois de retravail sur une carte. La réponse évidente au problème est de disposer de systèmes automatisés pour effectuer des tests de régression exhaustifs. Mais quelle est la solution pour l'ingénieur en systèmes embarqués qui dispose de peu d'argent et de temps pour développer un système de test automatisé exhaustif ?

La Solution Économique

Pour les systèmes embarqués, il existe une solution de test automatisé à faible coût, très évolutive et pratique. Bien qu'elle ne soit pas parfaite, elle offrira à l'ingénieur concepteur le meilleur retour sur investissement. Le concept consiste à utiliser un dispositif simple capable de générer des signaux analogiques, de lire des signaux analogiques, de générer divers flux sériels de protocoles et d'analyser des formes d'onde. Un exemple de dispositif à faible coût qui possède de telles spécifications est l'Analog Discovery 2. Bien qu'il s'agisse d'un dispositif 5V, il offre néanmoins de grandes performances. Je le considère comme mon couteau suisse pour le développement de systèmes embarqués. Il existe d'autres produits comparables, mais j'ai trouvé que ce dispositif fonctionnait particulièrement bien pour mes applications. Ce dispositif peut fonctionner à partir de votre ordinateur de bureau ou même d'un Raspberry Pi. Il dispose également d'une bibliothèque Python qui permet à l'utilisateur de mettre rapidement en place des exécutifs de test. Pour plus de commodité, j'ai dockerisé la configuration complète et l'ai construite pour toutes les architectures.

Exemple pratique

Considérons un exemple réel que l'on peut trouver dans ce dépôt. Pour simplifier, notre cible embarquée sera un Arduino Duo. Voici à quoi ressemble notre configuration de test complète :

L'idée ici est de démontrer :

• Le PC hôte commande à l'Analog Discovery 2 de générer des signaux analogiques vers l'Arduino
• L'Arduino lit et stocke les valeurs de l'ADC
• Le PC hôte reçoit les valeurs de l'ADC via UART (USB)
• Le PC hôte vérifie que ce qui a été envoyé via l'Analog Discovery 2 correspond à la télémétrie envoyée par l'Arduino

Pourquoi voudrions-nous automatiser quelque chose comme cela ? Supposons que nous retravaillons une carte près de l'ADC, ou que quelqu'un change les pilotes qui interfacent avec l'ADC. Sommes-nous à 100% confiants qu'une simple lecture manuelle de l'ADC avec quelques boutons tournés sur une alimentation est suffisante pour tester notre matériel/logiciel ? Sinon, pourquoi ne pas laisser l'automatisation couvrir chaque permutation et chaque cas limite, pour que nous n'ayons pas à le faire ? Et juste pour être sûr, pourquoi ne pas faire la même chose 100 fois... juste parce que nous le pouvons ! Cela peut devenir bien plus sophistiqué et compliqué (par exemple, tests de protocole, tests de filtrage de l'ADC, etc.), mais cet article se contentera de traiter les bases.

Le script de test est assez basique. En supposant que votre Arduino (c'est-à-dire, le dispositif embarqué en test) a été chargé avec les fichiers de programmation appropriés et que tout a été correctement connecté, vous exécuteriez le script de test sur votre ordinateur comme ceci :

python -m pytest test_arduino_hil.py

Cela déclenchera l'Analog Discovery 2 pour balayer la plage de tension de l'ADC de l'Arduino et valider que la tension d'entrée correspond à la tension de sortie lue sur l'ADC. Plutôt que de balayer manuellement avec une alimentation de laboratoire, le script l'a fait pour vous avec une seule commande. Pour un exemple aussi trivial que celui-ci, cela semble inutile, mais ce processus est très avantageux lorsqu'on combine les tests de manière régressive. En couplant cela avec notre système CI/CD, nous pouvons voir les étapes suivantes s'exécuter et réussir :

Les étapes mentionnées ci-dessus sont :

1. docker_build : Construire l'environnement. Dans ce cas, nous utilisons des images docker sur des PC Linux et des dispositifs basés sur ARM tels que les Raspberry Pis
2. arduino_load_test : Compiler et charger le code Arduino et valider que tout a fonctionné.
3. arduino_hil_test : Exécutez le test matériel en boucle sur un Arduino physique.

Si nous examinons de plus près la section Tests, nous pouvons voir que ces tests ont été capturés et analysés par Gitlab :

Nous disposons maintenant d'une configuration logicielle qui nous permet de tester notre conception localement et à distance (en utilisant notre système CI/CD). Cela permet à l'ingénieur concepteur de continuer à se concentrer sur la conception au lieu de tester et de déboguer par la suite.

Conclusion

Dans cet article, nous avons passé en revue le concept d'utilisation de tests automatisés pour valider une conception de manière concurrente et a posteriori. Que ce soit pour une petite retouche ou un changement de conception monumental, disposer de tests de régression automatisés est très avantageux pour éliminer les conséquences imprévues (c'est-à-dire, corriger une chose, en casser une autre). Le processus encouragé consiste à écrire ces scripts de test en parallèle du processus de développement de la conception (similaire au Développement Piloté par les Tests). Coupler ces tests automatisés avec un système CI/CD ajoute un bonus supplémentaire pour démontrer que nos cartes fonctionnent sur une cible distante et peuvent être testées par n'importe qui, n'importe où, à tout moment.

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. Vous pouvez télécharger un essai gratuit d'Altium Designer ici.