Concevoir un banc de test : mécanique, électronique et logiciel

Un banc de test n'est pas une machine mécanique à laquelle on ajoute des capteurs, puis un programme. C'est un seul système, où chaque choix de mécanique a une conséquence sur le câblage, et chaque choix de câblage sur le logiciel. Avant de détailler la démarche que j'applique pour concevoir un banc clés en main, un détour par le vocabulaire et par l'état de l'art : banc de test, banc d'essai et banc métrologique ne désignent pas tout à fait la même chose.

Banc de test, banc d'essai, banc métrologique : de quoi parle-t-on ?

Les trois termes s'emploient souvent l'un pour l'autre. Les normes permettent pourtant de les distinguer par ce que le banc doit produire.

• Le banc d'essai réalise des essais au sens de la norme ISO/IEC 17000 : déterminer une ou plusieurs caractéristiques d'un objet selon une procédure. Endurance, vieillissement, fatigue, essais climatiques ou de qualification : le produit est soumis à des sollicitations, et son comportement est observé.
• Le banc de test vérifie qu'un produit est conforme à ses exigences. Le résultat attendu est souvent un verdict, conforme ou non, en développement comme en fin de ligne de production. En anglais, test bench désigne plus largement tout environnement qui permet de vérifier une conception ; en électronique et en logiciel, il peut même être entièrement virtuel.
• Le banc métrologique a pour objet la mesure elle-même. C'est un système de mesure au sens du Vocabulaire international de métrologie (VIM) : un ensemble d'instruments assemblés pour fournir des valeurs mesurées. Il repose sur trois notions : l'étalonnage, l'incertitude de mesure et la traçabilité métrologique, c'est-à-dire le rattachement du résultat à une référence par une chaîne ininterrompue et documentée d'étalonnages.

Dans la pratique, la frontière est poreuse. Un banc d'essai a besoin d'une métrologie maîtrisée pour que ses résultats aient un sens, et un banc métrologique se pilote comme un banc de test. Les bancs de métrologie des miroirs de l'ELT en sont un bon exemple : la mesure y est l'objectif, mais elle repose sur un contrôle-commande complet. Les laboratoires qui font reconnaître leurs essais et leurs étalonnages s'appuient, eux, sur la norme ISO/IEC 17025.

L'état de l'art : ce qui a changé

• De l'instrument au système : le banc d'origine était un poste où un technicien relevait des valeurs à l'oscilloscope et au multimètre. Aujourd'hui, l'acquisition, le pilotage et l'enregistrement sont automatisés.
• Des plateformes modulaires : contrôleurs temps réel, châssis et modules d'acquisition du marché remplacent les électroniques développées pour un seul banc. Les exemples sont donnés plus bas.
• La simulation dans la boucle : avec le hardware-in-the-loop (HIL), une partie du système réel est remplacée par un modèle qui tourne en temps réel. Un calculateur se teste ainsi avant que la machine qu'il commande n'existe.
• Le logiciel au centre : séquenceurs de tests, environnements de test temps réel, langages de script pour l'analyse, communications ouvertes (TCP/IP, gRPC) avec les systèmes du client.
• La donnée et la traçabilité : chaque résultat doit pouvoir être relié à la pièce testée, à la configuration du banc et à l'état d'étalonnage de ses capteurs.
• Le cycle de vie : un banc vit souvent plus longtemps que le produit pour lequel il a été conçu. La modularité, la configuration hors du code et la documentation permettent de le faire évoluer.

Partir du besoin, pas de la solution

• Ce que le banc doit prouver : quelle grandeur mesurer, avec quelle incertitude, sur quelle plage. C'est la question qui fixe tout le reste.
• Le contexte d'utilisation : en laboratoire ou en production, par un ingénieur d'essais ou par un opérateur, quelques essais par an ou plusieurs par jour. Un même besoin de mesure donne deux bancs très différents.
• Les contraintes du site : place disponible, alimentations, réseau informatique, règles de sécurité du client.

Ce travail se fait avec le client, souvent dès la réponse à l'appel d'offres. Un besoin mal compris coûte bien plus cher à corriger en recette qu'au moment de la spécification.

Découper en trois métiers, soigner les interfaces

Le banc se découpe en trois sous-ensembles : mécanique, électronique et logiciel. Chacun a son concepteur, mais les difficultés se trouvent presque toujours entre les trois :

• Mécanique et électronique : emplacement des capteurs, passage des câbles, place de l'armoire électrique, mise à la terre.
• Électronique et logiciel : liste des voies, types de signaux, cadence d'acquisition, comportement en cas de défaut.
• Logiciel et mécanique : séquences de mouvement, butées, sécurités.

Je fige ces interfaces tôt, dans un document partagé par toute l'équipe : la liste des voies, en particulier, sert de référence commune au câbleur et au développeur.

La mécanique : tenir la pièce, protéger l'opérateur

• Le bâti doit être assez rigide pour ne pas fausser la mesure, et isolé des vibrations quand la mesure y est sensible.
• Le montage de la pièce doit être répétable : une pièce mal positionnée donne une mesure fausse, même avec la meilleure chaîne d'acquisition.
• L'opérateur doit pouvoir charger la pièce, accéder aux réglages et intervenir en maintenance sans démonter le banc.
• La sécurité se conçoit dès le départ : carters, arrêt d'urgence, protections, plutôt qu'ajoutés à la fin.

La maquette 3D, réalisée par exemple sous FreeCAD, sert aussi à vérifier l'encombrement de l'armoire et le cheminement des câbles.

L'électronique : de la grandeur physique au signal

• Les capteurs sont choisis pour la grandeur, la plage et l'incertitude visées ; vient ensuite le choix du conditionnement adapté à chacun.
• L'acquisition et le contrôle : acquisition rapide pour la mesure, automate ou contrôleur temps réel pour le pilotage et les sécurités. Le choix dépend de la cadence et du niveau de sûreté demandés.
• L'armoire électrique est dessinée avec un logiciel de schéma électrique, QElectroTech par exemple : schémas, borniers et repérage des câbles forment la documentation de référence pour le câblage comme pour la maintenance.
• L'état sûr : chaque sortie est câblée pour que l'absence de commande mette le banc en sécurité, même en cas de perte de communication.

Le logiciel : piloter, mesurer, tracer

• Le séquencement des essais : chaque essai suit une séquence décrite, avec des étapes, des critères de réussite et des réactions aux défauts.
• L'interface opérateur montre l'essentiel : l'état du banc, l'étape en cours, les alarmes. Les réglages avancés restent réservés à l'ingénieur.
• La traçabilité : chaque résultat est enregistré avec la pièce testée, la configuration du banc, la version du logiciel et la date.
• La configuration hors du code : voies, seuils et séquences sont décrits dans des fichiers, pour faire évoluer le banc sans tout recompiler.

Le langage et les outils suivent ceux du client et de son équipe de maintenance. Quelques exemples ci-dessous.

Exemples : le matériel d'acquisition et de contrôle

Les mêmes fonctions se retrouvent chez les principaux fournisseurs. Le choix dépend de la cadence, de l'environnement du banc et des outils déjà en place chez le client.

• National Instruments (NI) : CompactDAQ (cDAQ) pour la mesure pilotée par un PC, CompactRIO (cRIO) pour le contrôle temps réel et le FPGA, PXI pour les systèmes de test les plus exigeants.
• Dewesoft : des systèmes d'acquisition (SIRIUS, KRYPTON) exploités avec le logiciel DewesoftX, et IOLITE, qui associe acquisition et contrôle temps réel de banc, avec des sorties analogiques, numériques et EtherCAT.
• WAGO : le système d'E/S modulaire 750/753, raccordé à un bus de terrain (EtherCAT, Modbus TCP…) par un coupleur, ou associé à un contrôleur PFC programmable en CODESYS.
• Gantner Instruments : des modules d'E/S et des contrôleurs Q.station pour l'acquisition distribuée, configurés et exploités avec le logiciel GI.bench, et des API pour l'intégration, notamment en Python.

Exemples : programmer le banc

• LabVIEW : un langage graphique taillé pour l'acquisition et le contrôle-commande. Une application de banc s'organise souvent en boucles parallèles qui échangent des messages : acquisition, pilotage, interface et enregistrement. LabVIEW Real-Time et LabVIEW FPGA déploient le même langage sur un cRIO.
• NI TestStand : un séquenceur de tests (test executive). Il enchaîne des étapes qui appellent des modules de code écrits en LabVIEW, en C, en .NET ou en Python, compare chaque mesure à ses limites, exécute les tests en série ou en parallèle et génère les rapports.
• NI VeriStand : un environnement de test temps réel, pensé pour le hardware-in-the-loop. Voies, modèles de simulation et alarmes se configurent dans une définition système, sans programmer la boucle temps réel ; les scénarios s'écrivent en profils de stimulus ou en séquences temps réel.
• Python : très utilisé pour l'analyse des données et l'automatisation des tests. Les fournisseurs proposent leurs bibliothèques : nidaqmx pour le matériel NI, niveristand pour écrire des séquences VeriStand en Python, ainsi que des API chez Dewesoft et Gantner.

Un exemple minimal en Python, qui lit une tension sur la première voie d'un module NI cDAQ :

import nidaqmx

with nidaqmx.Task() as task:
    task.ai_channels.add_ai_voltage_chan("cDAQ1Mod1/ai0")
    print(task.read())

Sur un banc, la même lecture s'insère dans une séquence TestStand ou dans un script de test, avec ses limites et son enregistrement.

Intégrer, valider, livrer

• Les essais de recette se préparent dès la spécification : chaque exigence du cahier des charges a un essai qui la vérifie.
• L'intégration se fait par étapes : chaque sous-ensemble est testé seul avant le banc complet, pour trouver un défaut là où il est.
• La documentation livrée comprend les plans, les schémas, le manuel d'utilisation et les rapports de recette.
• La formation des utilisateurs fait partie de la livraison : un banc que personne ne sait utiliser n'est pas terminé.

Un exemple : un système de test de freinage aéronautique

Chez STYREL, nous avons modernisé le système de test de freinage d'un client de l'aéronautique. Ses enjeux : garantir des performances temps réel, fiabiliser les échanges de données et pouvoir faire évoluer lui-même ses algorithmes de freinage.

• Une architecture logicielle hybride sur plateforme cRIO : LabVIEW pour la gestion des données, C embarqué pour les traitements temps réel. Elle allie performance, déterminisme et modularité.
• Une API dédiée assure une communication fiable en TCP/IP avec le système de supervision du client.
• Les résultats : une réactivité temps réel inférieure à 1 ms, une précision inférieure à 10 µs, et quatre fois plus de scénarios de test.
• Un projet mené de bout en bout, de la preuve de concept à la mise en service, en passant par la conception, le développement et la validation, en méthode Agile (Scrum).

Cet exemple résume la démarche : partir des enjeux du client, choisir l'architecture en conséquence, et lui laisser la main sur ce qui doit évoluer.

À retenir

• Un banc de test se conçoit comme un seul système : les problèmes viennent surtout des interfaces entre mécanique, électronique et logiciel.
• Le contexte d'utilisation chez le client compte autant que la mesure elle-même.
• La sécurité, la traçabilité et la recette se préparent dès le début du projet, pas à la fin.

Pour aller plus loin

Deux articles détaillent des parties de cette démarche : cRIO et WAGO en EtherCAT pour l'acquisition et le contrôle, et Python et LabVIEW pour le logiciel.

BIPM, Vocabulaire international de métrologie (VIM), JCGM 200:2012, bipm.org ; ISO, ISO/IEC 17025:2017, Exigences générales concernant la compétence des laboratoires d'étalonnages et d'essais, iso.org