CI/CD pour les tests matériels avec TofuPilot

Les équipes logicielles ont le CI/CD depuis des années. Les équipes matérielles valident encore leurs releases avec des tableurs et des approbations manuelles. TofuPilot comble ce fossé en traitant les résultats de tests matériels comme des artefacts de pipeline, pour que vous puissiez automatiser la validation de la même manière que vous automatisez les builds.

Pourquoi le CI/CD est important pour le matériel

Les données de test matériel sont l'équivalent d'une suite de tests logiciels. Chaque unité sortant de la ligne passe par des tests fonctionnels, des vérifications de calibration et des tests environnementaux. La question n'est pas de savoir si vous avez des tests. C'est de savoir si vous pouvez automatiquement bloquer une expédition quand les données de test disent « stop ».

Les flux de travail matériels traditionnels reposent sur quelqu'un qui examine un rapport. Le CI/CD pour le matériel signifie que le pipeline examine les données et prend la décision.

Architecture

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Station de  │────▶│   TofuPilot  │────▶│  Porte CI/CD │
│  test        │     │  (Résultats  │     │  (Décision   │
│  (OpenHTF /  │     │    + API)    │     │   Pass/Fail) │
│   pytest)    │     │              │     │              │
└──────────────┘     └──────────────┘     └──────────────┘

Les stations de test poussent les résultats vers TofuPilot. Votre système CI/CD interroge l'API de TofuPilot pour vérifier si un lot répond aux critères de release.

Mettre en place la validation matérielle continue

Étape 1 : Pousser les résultats depuis les stations de test

Chaque exécution de test se téléverse automatiquement vers TofuPilot. Si vous utilisez OpenHTF, ajoutez le callback de sortie TofuPilot. Si vous utilisez pytest ou un framework personnalisé, utilisez le client Python.

station_test.py

from tofupilot import TofuPilotClient

client = TofuPilotClient()

client.create_run(
    procedure_id="EVT-POWER-CYCLE",
    unit_under_test={"serial_number": "UNIT-4521"},
    run_passed=True,
    steps=[{
        "name": "Power Rail Check",
        "step_type": "measurement",
        "status": True,
        "measurements": [{
            "name": "vcc_3v3",
            "value": 3.31,
            "unit": "V",
            "limit_low": 3.25,
            "limit_high": 3.35,
        }],
    }],
)

Étape 2 : Interroger les résultats dans votre pipeline

Utilisez l'API de TofuPilot pour vérifier les taux de réussite au niveau du lot avant d'autoriser une release.

ci_gate.py

# Script de porte CI/CD : vérifier le FPY du lot avant la release
import requests
import sys

API_KEY = os.environ["TOFUPILOT_API_KEY"]
PROCEDURE = "EVT-POWER-CYCLE"
MIN_FPY = 0.95
MIN_UNITS = 50

response = requests.get(
    "https://app.tofupilot.com/api/v1/runs",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"procedure_id": PROCEDURE, "limit": 200},
)

runs = response.json()
passed = sum(1 for r in runs if r["run_passed"])
total = len(runs)
fpy = passed / total if total > 0 else 0

print(f"FPY : {fpy:.1%} ({passed}/{total} unités)")

if total < MIN_UNITS:
    print(f"Pas assez d'unités testées ({total} < {MIN_UNITS})")
    sys.exit(1)

if fpy < MIN_FPY:
    print(f"FPY sous le seuil ({fpy:.1%} < {MIN_FPY:.0%})")
    sys.exit(1)

print("Porte franchie. Lot approuvé pour la release.")

Étape 3 : Intégrer avec GitHub Actions ou GitLab CI

.github/workflows/hardware-gate.yml

name: Hardware Release Gate
on:
  workflow_dispatch:
    inputs:
      batch_id:
        description: "Lot à valider"
        required: true

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - run: pip install requests
      - run: python ci_gate.py
        env:
          TOFUPILOT_API_KEY: ${{ secrets.TOFUPILOT_API_KEY }}

Stratégies de contrôle d'accès

Stratégie	Quand l'utiliser	Fonctionnement
Seuil de FPY	Release de production	Bloquer si le rendement au premier passage descend sous l'objectif
Zéro défaillance critique	Produits critiques pour la sécurité	Bloquer si une mesure critique échoue
Cpk minimum	Validation de processus	Bloquer si l'indice de capabilité du processus est trop bas
Détection de tendance	Alerte précoce	Alerter si le rendement décline sur les N derniers lots

Tester comme en vol

Le principe aérospatial « test like you fly » signifie que les tests de production doivent refléter les conditions opérationnelles réelles. Le CI/CD pour le matériel rend cela pratique en automatisant la boucle de rétroaction :

Exécutez les mêmes tests en EVT, DVT et PVT
Comparez les résultats entre les phases dans TofuPilot
Conditionnez chaque transition de phase sur des données mesurées, pas des opinions

Quand votre cyclage thermique DVT montre une baisse de rendement de 3 % par rapport à l'EVT, les tableaux de bord de comparaison de TofuPilot le révèlent immédiatement. Sans attendre que quelqu'un produise un rapport.

Ce que cela remplace

La plupart des équipes matérielles conditionnent les releases avec une combinaison de rapports Excel, de chaînes d'emails et de réunions d'approbation. Le CI/CD pour le matériel n'élimine pas le jugement humain. Il élimine la collecte manuelle de données qui retarde le jugement. Les ingénieurs passent leur temps à analyser plutôt qu'à agréger.

CI/CD pour les tests matériels avec TofuPilot