Getting Started with TofuPilot for Aviation MRO

Component maintenance shops build their test benches in-house, and the software side is usually a mix of instrument-control scripts, spreadsheets, and printouts. TofuPilot adds a structured layer on top of the scripts you already write: tests defined in a YAML procedure, phases in plain Python, and every measurement recorded with its limits and unit identity. This tutorial takes you from nothing to a running component bench test, entirely locally. No account is needed to start, and nothing here touches OEM software or proprietary data; the framework only handles measurements your own bench produces.

Prerequisites

• A machine running Windows, Linux, or macOS
• Python installed (the CLI can provision a virtual environment for you)

Step 1: Install the CLI

The TofuPilot CLI is a single executable. The framework and CLI are both open source under the MIT license.

On Linux or macOS:

On Windows (PowerShell):

Step 2: Create the Procedure

A procedure is a directory with a procedure.yaml declaring the test sequence, plus the Python it references. Create this layout:

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

The YAML declares one phase with one validated measurement, and identifies the unit under test by serial number and part number, which is what ties every result to a unit's history:

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

Step 3: Write the Phase and the Plug

The phase is a plain Python function. It receives the measurements object and any plugs it needs by name:

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

The plug is a class wrapping your instrument. This one returns a fixed value so the example runs anywhere; on a real bench the same method would read from your power supply over VISA or serial:

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

This split is the pattern for everything that follows: procedures declare what is measured and what its limits are, phases contain the test logic, plugs contain the instrument drivers. Your existing instrument-control code moves into plugs mostly unchanged.

Step 4: Run It

From the parent directory:

The CLI resolves a Python environment (offering to create one if missing), executes the phases, evaluates each measurement against its validators, and prints the result:

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

The run executed entirely on your machine, without contacting anything.

Step 5: Connect the Dashboard

When you want history and analytics on top of local runs, connect the procedure to a dashboard. Runs uploaded from then on build the part number's yield and measurement trends and each serial number's visit history.

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

Low-volume use fits the free tier, which suits component maintenance well: a shop seeing a handful of units per part number per month generates far fewer runs than a production line, while each run carries more history value.

From here, grow the procedure the way your CMM test grows: more phases for more functional areas, more measurements per phase, plugs for each instrument on the bench. The measurements accumulate into the part number's record, which is where the analytics for no-fault-found, drift, and repeat visitors come from.