Démarrer avec TofuPilot en MRO aéronautique

Les ateliers de maintenance de composants construisent leurs bancs de test en interne, et la partie logicielle est en général un mélange de scripts de pilotage d'instruments, de tableurs et d'impressions. TofuPilot ajoute une couche structurée par-dessus les scripts que vous écrivez déjà : des tests définis dans une procédure YAML, des phases en Python simple, et chaque mesure enregistrée avec ses limites et l'identité de l'unité. Ce tutoriel vous mène de zéro à un test de banc composant fonctionnel, entièrement en local. Aucun compte n'est nécessaire pour démarrer, et rien ici ne touche aux logiciels OEM ni aux données propriétaires ; le framework ne traite que les mesures produites par votre propre banc.

Prérequis

• Une machine sous Windows, Linux ou macOS
• Python installé (le CLI peut provisionner un environnement virtuel pour vous)

Étape 1 : Installer le CLI

Le CLI TofuPilot est un exécutable unique. Le framework et le CLI sont tous deux open source sous licence MIT.

Sous Linux ou macOS :

Sous Windows (PowerShell) :

Étape 2 : Créer la procédure

Une procédure est un répertoire contenant un procedure.yaml qui déclare la séquence de test, ainsi que le code Python qu'il référence. Créez cette arborescence :

lru-bench-test/  procedure.yaml  phases/    power_check.py  plugs/    bench.py

Le YAML déclare une phase avec une mesure validée, et identifie l'unité sous test par son numéro de série et son numéro de pièce, ce qui relie chaque résultat à l'historique d'une unité :

name: LRU Bench Acceptance Testversion: 1.0.0description: First bench test for a returned componentunit:  auto_identify: true  serial_number:    default_value: "LRU000001"  part_number:    default_value: "622-1234-001"plugs:  - name: bench    python: plugs.bench:Benchmain:  - name: Power Supply Check    python: phases.power_check    measurements:      - name: supply_voltage        unit: V        validators:          - operator: ">="            expected_value: 27.5          - operator: "<="            expected_value: 28.5

Étape 3 : Écrire la phase et le plug

La phase est une simple fonction Python. Elle reçoit l'objet de mesures et les plugs dont elle a besoin, par nom :

def power_check(measurements, bench):    measurements.supply_voltage = bench.read_supply_voltage()

Le plug est une classe qui encapsule votre instrument. Celui-ci renvoie une valeur fixe pour que l'exemple fonctionne partout ; sur un banc réel, la même méthode lirait votre alimentation via VISA ou liaison série :

class Bench:    def read_supply_voltage(self) -> float:        return 28.01

Cette séparation est le motif utilisé pour tout ce qui suit : les procédures déclarent ce qui est mesuré et quelles sont les limites, les phases contiennent la logique de test, les plugs contiennent les pilotes d'instruments. Votre code de pilotage d'instruments existant se déplace dans les plugs quasiment sans modification.

Étape 4 : L'exécuter

Depuis le répertoire parent :

Le CLI résout un environnement Python (en proposant d'en créer un s'il manque), exécute les phases, évalue chaque mesure face à ses validateurs et affiche le résultat :

→ Phase: Power Supply Check✓ Phase Power Supply Check: PASS→   supply_voltage = 28.01 V [PASS]✓ Run complete: PASS

Le run s'est exécuté entièrement sur votre machine, sans contacter quoi que ce soit.

Étape 5 : Connecter le dashboard

Lorsque vous voulez de l'historique et des analyses par-dessus les runs locaux, connectez la procédure à un dashboard. Les runs téléversés à partir de ce moment alimentent le rendement et les tendances de mesure du numéro de pièce, ainsi que l'historique des passages de chaque numéro de série.

tofupilot logintofupilot link ./lru-bench-testtofupilot run ./lru-bench-test --upload

Un usage à faible volume entre dans le forfait gratuit, ce qui convient bien à la maintenance de composants : un atelier voyant quelques unités par numéro de pièce et par mois génère bien moins de runs qu'une ligne de production, alors que chaque run porte davantage de valeur historique.

À partir de là, faites grandir la procédure comme grandit votre test CMM : plus de phases pour plus de domaines fonctionnels, plus de mesures par phase, un plug pour chaque instrument du banc. Les mesures s'accumulent dans le dossier du numéro de pièce, d'où proviennent les analyses de no-fault-found, de dérive et de retours répétés.