PI18 - Banc de mesures automatiques pour validation d’un composant programmables par tests physiques

2011-2012

AUBERTIN Paul
GIRAULT Clémentine
RIVIERE Elie


 

THALES Avionics est une filiale du groupe THALES qui se positionne en maître d'œuvre, architecte systèmes, et fournisseur d'équipements et services dans le domaine des systèmes avioniques.  La filiale regroupe environ 6200 personnes. Le site de Valence, pour lequel nous travaillons, comporte environ 700 employés dont 70% sont des cadres. L'entreprise est le leader européen de l'électronique de vol et l'un des trois plus grands constructeurs mondiaux capables de fournir des ensembles complets d'électronique de vol. Parmi les composants qu'ils conçoivent, le contrôleur TPII. Les équipements aéronautiques ont besoin d'alimentation pour fonctionner. Ces alimentations sont conçues à Valence et le contrôleur TP2 est un constituant embarqué dans plusieurs des alimentations de dernière génération.

Le contrôleur TPII a pour fonction de superviser le fonctionnement de tensions d'alimentations (allumage, extensions, contrôles des seuils...). Il s'agit d'un FPGA A3PN250 composé d'un code générique et d'un code paramétrable à partir d'une table de configuration. Pour assurer le bon fonctionnement de ce composant et pour répondre à des contraintes de certification fortes en aéronautique, le fonctionnement du composant contrôleur TPII doit être rigoureusement testé et vérifié. Actuellement, les tests du code du composant FPGA A3PN se font exclusivement manuellement. La procédure de test est longue (environ 1 mois pour un code, c'est-à-dire pour une unique table de configuration) et partielle puisque certains tests ne sont pas réalisables sur action humaine (fréquence de 4MHz).

L'objectif est de réduire ce temps à une journée par un moyen automatique tout en étant conforme aux exigences de certification aéronautique. Le but est de pouvoir valider toutes les fonctionnalités de ce composant en utilisant un banc de mesures automatiques. Ce banc devra permettre de générer des stimuli complexes sur les entrées du composant et de venir vérifier le comportement de celui-ci en mesurant ses sorties. L'utilisation d'un banc automatique permettra de réaliser une procédure de tests plus complète et plus rapidement.
 

La première étape du projet a été d'identifier clairement le besoin de l'entreprise en étudiant en détail le fonctionnement du contrôleur TPII. Cette première étape nous a permis d'identifier les premières difficultés techniques du projet comme la communication par liaisons SPI, la contrainte de temps réel, le besoin de déclencher un événement sur le changement de valeur d'un bit d'une liaison SPI et enfin le nombre important de tests nécessaires. Cette étape nous a également permis de définir les types de test à réaliser sur le contrôleur TPII pour vérifier son fonctionnement. Enfin, nous avons alors défini avec THALES, un planning à respecter.
Une des premières nécessités qui s'est imposée a été l'utilisation de cartes d'acquisition permettant l'interfaçage entre le contrôleur TPII et le PC. Notre choix s'est porté sur des cartes d'acquisition National Instrument (fournisseur fortement conseillé par THALES) 6541 qui offraient plus d'entrées/sorties que les autres cartes et dont la gamme de fréquences pouvaient répondre à nos attentes.
Ces cartes d'acquisition n'offraient malheureusement pas la possibilité de déclencher un événement (trigger) sur un bit d'une liaison SPI. Or, ce besoin était essentiel pour réaliser certains tests déjà identifiés. C'est pourquoi il nous a fallu concevoir une carte hardware complexe (plus de 1800 composants). Nous avons décidé de créer la carte sous Kicad, logiciel pour lequel une formation nous était proposée à l'ESISAR. Cette carte permet également d'émuler les seuils des tensions pendant toute la procédure de test. Toutes ces fonctionnalités aurait été réalisables à partir d'une autre carte d'acquisition NI incluant un FPGA mais la contrainte de certification nous interdisait d'utiliser des composants programmables (FPGA ou PLD).
En parallèle de la création de la carte hardware qui nous a demandé de gérer les délais de fabrication et les demandes des sous-traitants, nous avons programmé une procédure de tests sous LabVIEW qui permet de séquencer les tests, de les adapter à la table de configuration et de traiter la réponse du contrôleur TPII pour déterminer si le test est valide.
Nous avons défini le formalisme à adopter pour définir un stimulus à envoyer ainsi que le logiciel utilisé. Notre choix s'est arrêté sur NI Waveform Editor, conçu justement pour fonctionner avec les cartes d'acquisition achetées et compatible avec LabVIEW. Le contrôleur TPII évoluant encore, les tests à réaliser évoluent eux aussi. THALES nous a donc imposé la création de nouveaux tests la plus simple possible et donc sans codage sous LabVIEW.
 

Les choix matériels et logiciels ont été validés par l'entreprise : les 4 cartes d'acquisition NI 6541, LabVIEW pour coder le banc de tests et NI Waveform Editor pour définir les stimuli.
La carte hardware a été produite et testée. La procédure LabVIEW permet le séquencement et la génération des fichiers à envoyer automatiquement à partir de la table de configuration et des fichiers Waveform de test génériques pour toutes les tables de configuration.
La création de nouveaux tests automatique est réalisable sans aucun codage LabVIEW. Le post-traitement est automatique pour certains tests ; il reste cependant à le coder sous LabVIEW pour tous les tests non-répétitifs. En attendant, l'analyse du résultat doit être faite manuellement.