Aviation & MRO Testing

Test au banc et analyse des LRU avioniques

Découvrez le déroulement des tests au banc d'un LRU avionique, de l'induction à la remise en service, et comment exploiter les résultats CMM.

JJulien Buteau
intermediate7 min de lecture16 juillet 2026

Un LRU avionique (line-replaceable unit) déposé d'un aéronef suit un cheminement d'atelier bien défini : induction, test fonctionnel, isolation de panne, réparation, test d'acceptation final, remise en service. Chaque étape produit des mesures. Dans la plupart des ateliers, ces mesures finissent leur vie sous forme d'un listing ATE ou d'un PDF joint au certificat de remise en service, ce qui veut dire que l'atelier n'en apprend rien au-delà du seul verdict pass/fail. Ce guide parcourt le déroulement au banc d'un LRU et montre comment capturer le même test sous forme de données structurées que vous pouvez suivre dans le temps.

Le cheminement d'un LRU en atelier

Une unité déposée arrive avec son dossier de dépose et passe par :

  1. Induction. Inspection à réception, vérification d'identité par rapport au dossier de dépose.
  2. Test fonctionnel. Exécuté selon le CMM (component maintenance manual) de l'OEM, qui définit les conditions de test, les limites et les niveaux de maintenance de l'unité.
  3. Isolation de panne. Si le test fonctionnel échoue, isoler jusqu'à la carte ou au sous-ensemble.
  4. Réparation. Remplacer ou reprendre l'élément défectueux.
  5. Test d'acceptation final. Test CMM complet à nouveau, depuis le début, sur l'unité réparée.
  6. Remise en service. Certificat de remise en service appuyé sur les preuves du test d'acceptation.

Notez la boucle dissimulée à l'étape 2 : une part significative des unités avioniques inductées passent le test fonctionnel sans panne constatée. Les chiffres publiés situent le NFF entre 20 et 50 pour cent des inductions d'atelier avionique. Ces unités consomment un cycle de banc complet et retournent en stock sans que rien n'ait été appris, sauf si les mesures sont conservées.

Ce que le banc mesure

Un test d'acceptation typique d'un LRU avionique couvre quelques domaines fonctionnels, chacun avec ses propres mesures et limites issues du CMM :

  • Alimentation. Courant d'entrée, tensions d'alimentation, comportement à l'appel de courant.
  • Communication de bus. Taux d'erreur mot ARINC 429, temps de réponse, lecture des messages BITE.
  • Signal et étalonnage. Précision de sortie par rapport à la référence, retards, rapport signal sur bruit.
  • Criblage environnemental. Pour les suspects intermittents, température et vibration pendant le test, informellement appelé bake and shake.

Écrire le test d'acceptation en données structurées

Le test ci-dessous est un test d'acceptation final d'un LRU réparé, écrit avec le framework TofuPilot. Le fichier de procédure déclare les phases et les limites ; chaque phase est une simple fonction Python qui lit depuis le banc.

procedure.yaml
48 lines
name: LRU Final Acceptance Testversion: 1.0.0description: Final acceptance test for a repaired avionics LRU before releaseunit:  auto_identify: true  serial_number:    default_value: "LRU000042"  part_number:    default_value: "622-1234-001"plugs:  - name: bench    python: plugs.bench:Benchmain:  - name: Power Consumption    python: phases.power    measurements:      - name: input_current        unit: A        validators:          - operator: "<="            expected_value: 1.8  - name: Bus Communication    python: phases.bus_comms    measurements:      - name: arinc429_word_error_rate        validators:          - operator: "<="            expected_value: 0.00001      - name: response_time        unit: ms        validators:          - operator: "<="            expected_value: 50  - name: Output Calibration    python: phases.calibration    measurements:      - name: output_accuracy_error        unit: "%"        validators:          - operator: ">="            expected_value: -0.5          - operator: "<="            expected_value: 0.5
phases/power.py
def power(measurements, bench):    measurements.input_current = bench.read_input_current()
phases/bus_comms.py
def bus_comms(measurements, bench):    measurements.arinc429_word_error_rate = bench.read_word_error_rate()    measurements.response_time = bench.read_response_time()
phases/calibration.py
def calibration(measurements, bench):    measurements.output_accuracy_error = bench.read_accuracy_error()
plugs/bench.py
class Bench:    def read_input_current(self) -> float:        return 1.42    def read_word_error_rate(self) -> float:        return 0.0    def read_response_time(self) -> float:        return 31.5    def read_accuracy_error(self) -> float:        return 0.12

Lancez-le depuis le répertoire de la procédure :

tofupilot run ./lru-acceptance-test
text
→ Phase: Power Consumption→ Phase: Bus Communication→ Phase: Output Calibration✓ Phase Output Calibration: PASS→   output_accuracy_error = 0.12 % [PASS]✓ Phase Bus Communication: PASS→   arinc429_word_error_rate = 0.0 [PASS]→   response_time = 31.5 ms [PASS]✓ Phase Power Consumption: PASS→   input_current = 1.42 A [PASS]✓ Run complete: PASS

Le plug de cet exemple renvoie des valeurs fixes pour que le test s'exécute partout ; sur un banc réel, les mêmes fonctions lisent vos instruments via VISA, une liaison série ou tout autre protocole que parle le montage. C'est la structure qui compte : chaque valeur est enregistrée avec son unité et sa limite, rattachée au numéro de série et au numéro de pièce.

Des enregistrements de test aux analyses

Dès que les tests d'acceptation arrivent sous forme de runs structurés, les analyses viennent sans effort supplémentaire :

  • Par numéro de pièce. Le rendement au premier passage sur toutes les unités d'une pièce, le Pareto des défaillances qui montre quelle phase et quelle mesure échouent le plus, et le Cpk de chaque mesure qui indique la marge réelle de la flotte d'unités face aux limites du CMM.
  • Par numéro de série. La page d'historique de l'unité liste chaque passage en atelier et chaque valeur mesurée pour un numéro de série. Une unité inductée pour la quatrième fois se repère d'un coup d'œil, avec l'évolution de ses mesures entre les passages.
  • Dans le temps. La dérive d'une mesure sur des mois d'inductions signale un vieillissement sur le terrain, un changement de fournisseur dans un sous-ensemble réparé, ou le banc lui-même qui bouge.

Rien de tout cela n'exige le logiciel ou les données de l'OEM. Les mesures sont produites par votre propre banc sous votre propre procédure de test ; les enregistrer de façon structurée plutôt que de les imprimer est le seul changement.

À quoi ressemble une bonne pratique

Un atelier de composants qui travaille ainsi remet chaque unité en service avec le même certificat qu'avant, mais garde interrogeables les preuves qui le soutiennent. L'ingénieur à qui l'on demande « avons-nous déjà vu cette défaillance » répond depuis l'historique du numéro de pièce au lieu d'une armoire à dossiers. Les unités qui reviennent sans cesse ressortent par leur nombre de retests. Et quand les mesures d'une pièce commencent à se rapprocher d'une limite CMM sur de nombreux numéros de série, l'atelier le voit pendant que c'est encore une tendance, avant que cela ne devienne un arriéré.

Plus de guides

Mettez ce guide en pratique