Un composant central des drivers NI, un correctif de sécurité, et une date à laquelle Windows peut décider de ne plus le charger. Le sujet est aride, la vérification prend trois minutes, et elle vaut le coup sur chaque banc qui tourne sur du matériel NI Emerson (ex National Instruments).

Il y a une catégorie de pannes que nous détestons : celles qui arrivent un lundi matin sur un banc auquel personne n'a touché. Le logiciel est le même, le matériel est le même, et pourtant les cartes d'acquisition n'apparaissent plus dans NI MAX. La cause est presque toujours en dessous de l'application, dans la pile de drivers et de services dont le banc dépend sans que quiconque s'en soucie. La prochaine occasion de ce genre a une date : le 10 novembre 2026. NI Emerson a publié un correctif de sécurité pour NI-PAL, un composant de bas niveau présent sur la plupart des PC équipés de drivers NI, et Microsoft a placé les anciennes versions de ce composant dans sa liste de drivers vulnérables, celle que Windows peut refuser de charger. Nos confrères de Mesulog en ont publié le 22 octobre une note d'information qui reprend les consignes de NI point par point ; ici, nous regardons ce que cela change concrètement pour un banc. Cet article explique ce qu'est NI-PAL, ce que dit l'avis de sécurité, pourquoi la date compte, comment vérifier un banc en trois minutes, et où sont les pièges.

Un composant central, mais discret

NI-PAL, pour Platform Abstraction Layer, est le socle commun des drivers NI Emerson. C'est lui qui fournit à NI-DAQmx, NI-VISA, NI-IMAQdx et aux autres l'accès bas niveau au matériel et aux ressources du système, de la même façon quelle que soit la version de Windows. C'est aussi ce qui fait la force de l'écosystème NI : une carte PCIe, un châssis PXI, un cDAQ et un instrument GPIB se pilotent depuis la même application, avec le même comportement, parce qu'ils reposent sur la même fondation. Sur un banc classique, l'empilement ressemble à ceci : l'application LabVIEW ou TestStand pilote l'essai, NI-DAQmx dialogue avec la carte, NI-PAL lui rend les services système dont il a besoin, et Windows arbitre le tout. L'utilisateur voit le premier étage, parfois le deuxième ; le troisième s'installe automatiquement avec les drivers, et c'est très bien ainsi : un bon socle se fait oublier tant qu'il fonctionne.

C'est ce qui rend le sujet plus large qu'il n'y paraît. Un PC qui a eu un jour une carte PCI NI, une interface GPIB ou un simple NI-VISA pour piloter un multimètre a NI-PAL installé, et le garde après que le matériel a été retiré. Il n'est pas nécessaire de développer en LabVIEW pour être concerné ; il suffit d'avoir installé un driver NI. NB : nos propres logiciels sont dans le même cas. Chaque installation Vasco comporte un PC Windows, y compris quand l'acquisition tourne sur une cible temps réel, et ce PC porte des drivers NI : il dépend de NI-PAL exactement comme une application LabVIEW maison. Le critère n'est pas le nom de l'application, c'est la version du composant installé.

Ce que dit l'avis de sécurité

NI a publié un bulletin pour la vulnérabilité CVE-2026-18485, qui touche NI-PAL 26.3.1 et toutes les versions antérieures sous Windows. Il s'agit d'une élévation de privilèges locale : un utilisateur déjà authentifié sur la machine peut obtenir des droits système qu'il ne devrait pas avoir. Ce n'est donc pas une porte ouverte depuis Internet, et sur un banc isolé du réseau avec deux comptes opérateur, le risque de sécurité pur est à relativiser.

Mise en garde cependant : relativiser n'est pas ignorer. Un banc d'essais qui a accès au réseau de l'entreprise, ou sur lequel des sous-traitants se connectent, est exactement le poste où une élévation de privilèges locale devient un problème pour quelqu'un d'autre que le banc. Et surtout, la raison de s'en occuper maintenant n'est pas la sécurité. C'est la disponibilité.

Pourquoi le 10 novembre

Windows tient une liste de drivers considérés comme vulnérables, et peut bloquer leur chargement au démarrage. Les versions concernées de NI-PAL y figurent désormais, avec une prise d'effet annoncée au 10 novembre 2026. Sur Windows 11, cette protection est active par défaut. Sur Windows 10, elle ne l'est généralement pas, sauf si la politique de sécurité de l'entreprise l'a activée, ce qui se voit de plus en plus.

Concrètement, un banc dont NI-PAL est bloqué au démarrage ne reconnaît plus ses cartes dans NI MAX, l'application remonte des erreurs de communication, et l'essai du jour ne se fait pas. Rien ne casse, mais rien ne fonctionne. Il faut être précis sur ce que cela signifie : le 10 novembre n'est pas une date à laquelle tous les bancs vont s'arrêter. C'est la date à partir de laquelle, sur un système où la liste de blocage est active, le risque devient réel. Du coup, la question n'est pas « sommes-nous concernés ? » mais « lesquels de nos postes le sont, et lesquels passeront la date sans rien remarquer ? ».

La vérification en trois minutes

Elle ne demande ni droits particuliers ni modification de l'installation. Sur le PC du banc, ouvrir l'Explorateur, aller dans C:\Windows\System32\drivers, trouver le fichier nipalk.sys, clic droit, Propriétés, onglet Détails, et lire le champ « Version du produit ».

Trois cas. Version 26.3.1 ou antérieure : le correctif est à installer. Version 26.5 (NI-PAL 2026 Q3) ou ultérieure : le correctif est déjà intégré, rien à faire. Fichier introuvable : soit le poste n'a aucun driver NI, soit NI-PAL est installé autrement ; dans le doute, NI MAX ou le panneau « Programmes et fonctionnalités » donnent la réponse. NB : une version ancienne ne veut pas dire qu'un problème s'est produit. Cela veut dire qu'il faut planifier.

Nous conseillons de faire cette vérification sur tous les postes qui portent du matériel NI, y compris ceux dont le banc est « en pause » depuis un an ; ce sont eux qui redémarrent un jour de besoin, et qui révèlent la panne à ce moment-là.

Une mise à jour ciblée, et ce que cela ne change pas

La bonne nouvelle est que NI livre un correctif de NI-PAL seul, et non une mise à jour complète des drivers. Dans les configurations compatibles, il ne faut changer ni de version de LabVIEW, ni de TestStand, ni de DAQmx, ni toucher au code de l'application. NI annonce une compatibilité descendante jusqu'à NI-PAL 17.0. L'installation prend de l'ordre d'une minute et demande un redémarrage ; elle passe par NI Update Service ou par l'installateur téléchargé sur le site NI.

Sur un poste de bureau, c'est l'affaire d'un café. Sur un banc en production, nous appliquons la même règle que pour n'importe quelle modification de l'environnement logiciel : relever les versions installées avant, disposer d'un moyen de revenir en arrière (image disque ou point de restauration), intervenir hors période d'essais, redémarrer, vérifier que tout le matériel est reconnu dans NI MAX, puis dérouler un essai représentatif avant de rendre le banc. Ce n'est pas de la paranoïa ; c'est ce qui garantit qu'une mise à jour d'une minute reste une mise à jour d'une minute, et pas une journée d'arrêt.

Le piège des caméras

Il y a une exception, et elle concerne des bancs que nous connaissons bien. NI a identifié une incompatibilité entre NI-PAL 2026 Q3 et les anciennes versions de NI-IMAQdx, 19.5 et antérieures. Sur un banc de contrôle visuel qui tient grâce à une caméra GigE ou USB3 et un IMAQdx de 2019, appliquer le correctif sans analyse préalable peut faire disparaître la caméra au lieu de la carte. Le cas n'a rien d'exotique : un poste resté en LabVIEW 2019 a toutes les chances d'avoir les drivers de la même génération. C'est le cas typique où la mise à jour « compatible » ne l'est pas, et où il faut regarder l'ensemble de l'installation avant de cliquer.

Plus généralement, chaque banc ancien a une ou deux de ces dépendances qu'il faut connaître avant d'y toucher : un driver de carte tierce, une version de Windows figée pour une raison oubliée, un composant de communication qui n'a pas d'équivalent récent. Les lister une fois, et les tenir à jour, c'est ce que nous appelons connaître son banc.

Ce qu'il faut en retenir

Un banc d'essais ne se résume pas à son application et à ses cartes. Entre les deux, il y a une pile de composants techniques, discrets mais essentiels, qui ont eux aussi besoin d'être maintenus. NI-PAL en est un exemple ordinaire : un correctif de sécurité, une liste de blocage Windows, et une date. Trois minutes de vérification par poste permettent de savoir qui est concerné, et une mise à jour d'une minute, encadrée par les précautions habituelles, règle la question, sauf sur les bancs à caméra ancienne, où il faut analyser avant d'agir.

Rien de révolutionnaire. Mais nous préférons l'écrire maintenant que recevoir l'appel du lundi 16 novembre.

Si vous voulez un inventaire de vos postes concernés, ou un coup de main pour planifier la mise à jour sur un banc en production : web@nerysgroup.com.

Sources : Mesulog, NI-PAL : une mise à jour de sécurité à anticiper pour vos bancs de test et systèmes de mesure ; NI, Required NI-PAL Security Update ; NI, bulletin de sécurité CVE-2026-18485 ; NI, NI-IMAQdx 19.5 et antérieures incompatibles avec NI-PAL 2026 Q3 ; Microsoft, règles de blocage des pilotes recommandées ; NIST, fiche NVD CVE-2026-18485. Informations établies au 23 octobre 2026 ; les consignes de NI restent prioritaires et peuvent évoluer.

Trente minutes, six cas industriels et une seule question : comment passe-t-on d'une mesure à une décision ? À Mesures Solutions Expo, le chronomètre a obligé Luc Desruelle et Amaury Laurent à survoler. Voici la version longue, avec les chiffres, les courbes et les vidéos qu'ils avaient sous la main, et ce qu'ils ont choisi de ne pas montrer.

Mesurer n'est pas une finalité. Personne ne paie un banc d'essais pour obtenir des chiffres ; tout le monde le paie pour décider : conforme ou non, régler ou laisser, alerter ou attendre, et de plus en plus souvent, prédire. Entre la grandeur physique et cette décision, il y a un traitement. C'est lui qui fait la valeur de la mesure, et c'est lui qui est le plus souvent choisi par habitude.

Le 15 octobre, à Lyon, Luc Desruelle, président de Mesulog et de Nerys, et Amaury Laurent, responsable des systèmes embarqués et de la R&D chez Nerys, ont déroulé six exemples tirés de leurs projets, du plus simple au plus pointu : une moyenne glissante, une capabilité de procédé, une régression linéaire sur un nuage de points, une caméra à réseau de neurones, un estimateur embarqué sur FPGA conçu avec Schneider Electric, et une IA générative à qui est confié un fichier de mesures. Le fil conducteur tenait en une phrase, répétée après chaque exemple : « ça a marché parce que nous savions ce que nous cherchions ». La fin de l'atelier montrait ce qui se passe quand ce n'est pas le cas.

1. Une température : quelle valeur retenir ?

Le cas le plus simple qui soit, monté pour l'occasion dans LabVIEW : la température de la salle de Mesures Solutions Expo, stable autour de 18 °C. Une mesure réelle n'est jamais parfaitement stable. Elle porte un bruit, et de temps en temps une valeur franchement aberrante : un parasite sur la liaison, un contact qui bouge, une perturbation électromagnétique au démarrage d'un moteur voisin.

Moyenne ou médiane : deux hypothèses sur le bruit

Premier réflexe : lisser par une moyenne glissante. Sur la démonstration, l'afficheur passe d'une mesure brute à 18,2 °C ± 3,7 °C à une valeur traitée à 18,7 °C ± 0,4 °C : le bruit est divisé par neuf, mais les pics ont décalé la valeur affichée d'un demi-degré. La moyenne lisse très bien le bruit, mais une seule valeur aberrante la tire vers elle. Avec une fenêtre de 25 points, un pic isolé à 50 °C décale la moyenne d'environ 1,3 °C, et il la décale pendant toute la durée où il reste dans la fenêtre, soit 25 échantillons. Sur la courbe, la moyenne « décroche » en marche d'escalier à chaque pic.

La médiane glissante, calculée sur la même fenêtre, ne bouge pas : un point aberrant sur 25 est rangé en bout de liste et n'influe pas sur la valeur centrale. Elle reste juste tant que la majorité des points de la fenêtre est saine, c'est-à-dire tant que les valeurs aberrantes restent minoritaires et isolées.

Ce n'est pas que l'une soit meilleure que l'autre. Ce sont deux hypothèses différentes sur la nature du bruit : la moyenne suppose un bruit symétrique et sans valeurs extrêmes, la médiane suppose que les valeurs extrêmes sont rares et sans signification. Choisir l'une, c'est déjà décider quelque chose sur le phénomène et sur la chaîne de mesure.

Le prix du lissage : le retard

Puis le phénomène physique évolue réellement : la température monte de 20 à 25 °C, puis à 30 °C. Le filtre qui protégeait du bruit devient alors un handicap. Une moyenne ou une médiane sur 25 points ne suit un échelon qu'après une douzaine d'échantillons, la moitié de la fenêtre, et la moyenne le suit en rampe là où la médiane bascule d'un coup quand la majorité de la fenêtre a changé. Plus le lissage est fort, plus la réaction est tardive.

C'est le compromis de base de tout traitement, et il ne se règle pas par la technique. Il se règle en répondant à une question métier : combien de temps a-t-on pour réagir, et combien de fausses alarmes est-on prêt à accepter ? Un banc d'endurance qui enregistre une température d'huile sur trois semaines et une boucle de sécurité qui doit couper en une seconde n'appellent pas le même filtre, même avec le même capteur.

NB : la moyenne elle-même demande de savoir ce qui est manipulé. La moyenne arithmétique de 350° et de 10° vaut 180°, soit exactement l'opposé de la réalité, alors que les deux directions sont à 10° du nord. Le calcul est juste, l'outil est juste, et le résultat est faux, parce qu'un angle est une grandeur circulaire. La bonne méthode moyenne les sinus et les cosinus, puis recompose l'angle avec un arc tangente à deux arguments : le résultat est 0°. La même précaution vaut pour une phase, une heure de la journée ou une position angulaire de codeur.

2. Un pic ou une rupture ?

Même signal, un point sort du lot. Faut-il l'éliminer ou le conserver ? S'il s'agit d'un parasite, il faut l'éliminer. S'il s'agit du premier point d'un nouveau régime, ou du début d'une rupture, l'éliminer revient à masquer exactement ce qui était recherché. Sur un seul échantillon, les deux cas se ressemblent trait pour trait. C'est ce qui se passe après qui les distingue, et c'est ce que la statistique permet de décider proprement.

La loi gaussienne comme règle de décision

Si le bruit de mesure résulte de nombreux petits effets indépendants, ce qui est le cas du bruit thermique, du bruit de quantification et de la plupart des perturbations d'une chaîne bien conçue, sa distribution est gaussienne. Deux nombres la décrivent entièrement : la moyenne μ et l'écart-type σ. Dans l'exemple présenté, μ = 20,50 °C et σ = 0,45 °C.

La fenêtre μ ± 3σ contient 99,73 % des mesures d'un régime stable : un point sur 370 en sort, ce qui est bien trop fréquent pour déclencher une décision. La fenêtre μ ± 6σ en contient 99,9999998 % : un point sur 500 millions environ. Avec une mesure par seconde, c'est une fausse alarme tous les seize ans. Un point hors de cette fenêtre a donc deux explications plausibles : le système a changé, ou la mesure est corrompue. Dans les deux cas, il faut faire quelque chose.

Dans la démonstration, la fenêtre μ ± 6σ va de 17,80 à 23,20 °C. Un point arrive à 25,5 °C, puis un deuxième, puis un troisième : la rupture est détectée, le filtre est réinitialisé sur le nouveau régime au lieu de le lisser pendant 25 échantillons, et la décision suit immédiatement le phénomène.

Mise en garde : un écart supérieur à 6σ ne prouve pas une rupture. Il signale une observation incompatible avec le modèle de bruit retenu, à condition que les hypothèses de ce modèle tiennent. Si le bruit n'est pas gaussien, s'il comporte des impulsions régulières ou une dérive lente, la règle ne vaut rien, et c'est l'analyse de la chaîne de mesure qui doit dire quel modèle de bruit retenir. Retour à la même phrase : ça marche quand nous savons ce que nous cherchons.

Les mêmes outils pour piloter la qualité d'une production

Ces outils servent à autre chose qu'à filtrer : ils mesurent la qualité d'un procédé. Sur les bancs de production que Mesulog et Nerys développent avec un séquenceur de tests TestStand, chaque pas de test est une mesure, avec ses limites, son verdict et son contexte (numéro de série, station, opérateur). La plateforme WATS collecte ces résultats sans ressaisie : un reporter branché sur TestStand envoie le rapport de chaque pièce en fin de test vers une base centralisée, dans le nuage ou sur les serveurs du client. À partir de là, toute l'équipe analyse les mêmes données, dès la première pièce.

L'exemple présenté vient d'un vrai banc : le pas de test « Measure VCC », une alimentation théorique de 5 V, avec 9 862 mesures collectées. La moyenne vaut 4,996 V : le procédé est centré. L'écart-type vaut environ 0,026 V : la dispersion μ ± 3σ va de 4,918 à 5,074 V, loin des limites de spécification fixées à 4,8 et 5,2 V.

« Loin des limites » est un ressenti. La capabilité du procédé en fait un chiffre comparable d'un banc à l'autre : Cpk = min[(LSS − μ) / 3σ ; (μ − LSI) / 3σ], où LSS et LSI sont les limites supérieure et inférieure. Ici, (5,2 − 4,996) / 0,078 ≈ 2,6 côté haut et (4,996 − 4,8) / 0,078 ≈ 2,5 côté bas : le Cpk vaut environ 2,5, là où l'objectif courant en production est de 1,33. Un Cpk inférieur à 1 signifie qu'une part de la production sortira des limites même si le procédé ne dérive pas ; un Cpk de 2,5 laisse une marge confortable, et permet par exemple de discuter d'un allègement de contrôle.

Les indicateurs de rendement complètent le tableau. Le FPY (first pass yield) est le taux de produits conformes dès le premier passage ; le SPY, le TPY et le LPY suivent les deuxième, troisième et dernier passages. L'écart entre FPY et LPY mesure ce que coûtent les retests. Le Pareto des dix pas de test les plus souvent en échec dit où se concentrent les défauts, celui des dix Cpk les plus faibles dit où agir en priorité, et une carte CUSUM, qui cumule les écarts à la cible, signale une dérive lente avant le premier échec.

WATS propose depuis peu deux prolongements qui relèvent de l'IA : un assistant intégré qui suggère des regroupements et des causes racines (par opérateur, par lot), et un connecteur MCP qui permet à un assistant comme Claude ou ChatGPT d'interroger directement la base de tests en langage naturel : « qu'est-ce qui a fait chuter le FPY la semaine dernière ? », « quelles stations génèrent le plus de retests ? ». La question reste posée par quelqu'un qui sait ce qu'est un FPY et pourquoi il a chuté ; l'outil va simplement chercher plus vite.

3. L'épaisseur d'une plaque : la régression linéaire

Troisième exemple, une mesure dimensionnelle : l'épaisseur d'une plaque de marbre sur un convoyeur, avec une cote nominale de 20,0 mm. Un profilomètre laser 2D (un Keyence, dans le montage réel) projette une ligne laser sur le bord de la plaque et renvoie, à chaque profil, un nuage de points hauteur en fonction de la position. Il faut en extraire une épaisseur, avec son incertitude.

Le nuage est imparfait : bruit de mesure, points manquants sur les surfaces brillantes ou trop inclinées, arête arrondie qui ne donne pas d'angle net. Prendre le point le plus haut et le point le plus bas ne donne pas une épaisseur, mais la hauteur du grain le plus saillant.

La méthode, en trois temps

Premier temps, découper le profil en zones : la zone supérieure, quasi horizontale, et la zone latérale, quasi verticale. La frontière se trouve en cherchant la rupture géométrique, l'endroit où la pente locale change brutalement. Deuxième temps, modéliser la surface supérieure par une droite, ajustée par la méthode des moindres carrés : la droite qui minimise la somme des carrés des écarts verticaux entre les points et le modèle. Avec quelques centaines de points, le bruit de chaque point se moyenne, et la droite est bien plus juste que n'importe quel point isolé. Troisième temps, calculer l'épaisseur par projection orthogonale du point extrême de la face latérale sur cette droite. La dispersion des résidus de l'ajustement donne, au passage, une estimation de l'incertitude de la mesure.

Rien de révolutionnaire : la méthode des moindres carrés est publiée par Legendre en 1805. Elle fonctionne parce que la géométrie de la pièce est connue : la surface supérieure est plane, le bord est sensiblement perpendiculaire. Sur une pièce bombée, la même droite donnerait un résultat faux, avec des résidus plus grands mais une incertitude d'apparence rassurante si personne ne regarde leur forme. Là encore, c'est la connaissance de l'objet mesuré qui choisit le modèle.

Une régression linéaire, c'est un neurone

Cet exemple servait aussi de passerelle vers la suite. Une régression linéaire, y = a·x + b, c'est un neurone : le coefficient a est le poids, l'ordonnée à l'origine b est le biais, et l'ajustement par moindres carrés est son apprentissage. Tout le monde dans la salle en faisait depuis des années sans le savoir.

Un réseau de neurones combine beaucoup de ces éléments, et intercale entre eux une fonction non linéaire qui permet de représenter autre chose qu'une droite. Presque toutes les méthodes appelées aujourd'hui intelligence artificielle sont anciennes : la régression date de 1805, les cartes de contrôle de 1924, le perceptron de 1958, la rétropropagation qui rend les réseaux multicouches entraînables de 1986, les réseaux convolutifs de 1989. Ce qui a changé, c'est la puissance de calcul et le volume de données disponibles, pas la nature mathématique des outils.

Les intervenants ont présenté cette évolution comme cinq verbes plutôt que cinq technologies : décrire, modéliser, classer, percevoir, générer. Classer, c'est ce qui décide bon ou mauvais en bout de banc ; ça tourne chez la plupart des industriels depuis vingt ans, et personne ne l'appelait IA. La frontière est assez arbitraire. Quant au MCP (Model Context Protocol), ce n'est pas une famille de modèles mais un protocole de connexion entre un modèle et vos outils, vos bancs et vos données : un branchement, pas un cerveau de plus.

4. Reconnaître des dés : la vision industrielle par réseau de neurones

Sur le stand B53, Nerys et Mesulog avaient monté un jeu : Humain contre IA. Le visiteur lance deux dés dans un bac, calcule la somme des faces visibles et la tape sur un clavier ; pendant ce temps, une caméra intelligente identifie les faces, calcule la somme et rend son verdict. Le plus rapide des deux gagne. Le jeu tourne dans Vasco, le logiciel de pilotage de bancs édité par Nerys : il déclenche la caméra, récupère son résultat, chronomètre les deux joueurs et affiche le score. Pour compliquer la tâche, le bac contenait aussi des dés blancs illustrés, souvenir des dix ans du salon, qui comptent pour zéro point.

Une image, treize décisions

Derrière le jeu, un réseau de détection d'objets de la famille des réseaux convolutifs (CNN), le principe des détecteurs de type YOLO : à partir d'une seule image, il localise chaque objet, l'encadre et le classe. Sur l'image ci-dessous, treize objets sont détectés : trois dés noirs, classés « 4 points », « 5 points » et « 6 points » avec une confiance de 0,99, et dix dés blancs classés « image », qui valent zéro. La somme, 15, n'est pas calculée par le réseau.

À l'intérieur du réseau, les premières couches ne voient que des contours : sur une vignette de 64 × 64 pixels autour d'un dé, huit cartes de convolution font ressortir les bords et les points. Les couches suivantes combinent ces motifs, et la sortie n'est pas « 5 » mais une probabilité par classe : 96,4 % pour « 5 points », 1,9 % pour « 6 points », 0,9 % pour « 4 points », 0,8 % pour « image ».

Ce point a une conséquence directe : l'IA reconnaît les objets, c'est le logiciel qui applique les règles du jeu et prend la décision. Il vérifie qu'il y a bien deux dés comptables, additionne, compare et chronomètre ; les seuils de confiance, eux, se règlent et se tracent comme des paramètres du programme. Cette répartition vaut pour n'importe quel contrôle visuel en bout de ligne : le réseau perçoit, le logiciel décide, et le logiciel, lui, se vérifie, se versionne et se recette comme n'importe quel autre.

Ce qu'il n'a pas fallu faire

Sur le stand, la reconnaissance tournait dans une caméra Keyence IV4, qui embarque son propre apprentissage : pas de PC dédié, pas de code. La configuration se fait en quatre étapes guidées : optimiser l'image (déclenchement, éclairage), enregistrer une image de référence, régler les outils, attribuer les sorties. L'équipe avait défini huit outils : un par face de dé, un pour le total, un pour le logo. Le cycle complet de contrôle prend environ une seconde, et le verdict, le comptage et le taux de correspondance sortent sur des entrées-sorties et sur Ethernet, que Vasco exploite directement.

Ce qui surprend, c'est ce qu'il n'a pas fallu faire : écrire le réseau, ou programmer des règles de reconnaissance des faces (« compter les taches noires sur fond blanc… »). Il suffit de définir les objets à reconnaître et de fournir des images annotées de chaque face : le réseau apprend à les séparer. Quand une cible est manquée en production, l'opérateur l'encadre sur l'image, lui donne son étiquette et relance l'apprentissage, en quelques secondes.

Mise en garde, valable pour toutes les caméras de ce type : un réapprentissage est une modification du programme de contrôle. Qui a réappris quoi, quand, et sur quelles images, doit être tracé comme une version de logiciel. Une caméra qui « apprend » sans trace est un instrument dont plus personne ne sait dire ce qu'il mesure.

5. Prédire le passage à zéro d'un courant de court-circuit, avec Schneider Electric

C'est l'exemple qu'Amaury Laurent a dû le plus survoler, et celui qui mérite le plus de place. Il répond à une question qui paraît absurde posée comme ça : peut-on agir avant que le signal soit là ?

Un siècle d'essais à Grenoble. Pour comprendre le besoin, il faut dire deux mots du lieu. Schneider Electric est née en 1836 au Creusot sous le nom de Schneider et Cie ; le groupe compte aujourd'hui plus de 150 000 salariés dans plus de 100 pays, pour 40 milliards d'euros de chiffre d'affaires en 2025. Son ancrage grenoblois vient de Merlin Gerin, fondée en 1920 par deux ingénieurs des Arts et Métiers, Paul-Louis Merlin et Gaston Gerin, autour des disjoncteurs moyenne et haute tension à bain d'huile. Dès 1921, l'entreprise se dote d'un laboratoire d'essais, le laboratoire Volta, pour éprouver ses appareils en haute tension ; il montera à 800 kV dans les années 1930. En 1946, Merlin Gerin présente son premier disjoncteur capable de couper un court-circuit de 10 000 A sous 15 000 V, et dans les années 1960 Grenoble abrite l'un des plus grands laboratoires d'essais diélectriques d'Europe. Rachetée par Schneider en 1992, l'entreprise est aujourd'hui entièrement intégrée à Schneider Electric, qui a gardé la marque. Le site de Technopole, dans les anciens locaux de Merlin Gerin, reste le cœur grenoblois du groupe pour l'appareillage de coupure : 1 200 salariés, ses laboratoires et ses fonctions support.

F-Lab et le LEMT. Deux laboratoires principaux y cohabitent. F-Lab est le laboratoire d'essais et de certification de Schneider Electric en France : deux plateformes dans l'agglomération, Volta à Grenoble et Amplitude à Eybens, 14 000 m² d'essais basse et moyenne tension, une centaine d'ingénieurs et techniciens, une accréditation COFRAC selon l'ISO/IEC 17025, et des essais réalisés sous le regard d'organismes tiers comme l'ASEFA ou le LCIE pour la certification des produits. Pour les essais de forte puissance, il dispose de trois alternateurs d'essai, deux de 600 MVA et un de 2 500 MVA, capables de délivrer de l'ordre de 300 kA pendant une seconde en basse tension ; c'est ce genre de machine qui produit les courants de court-circuit de cette histoire. À côté, le LEMT, laboratoire d'essais moyenne tension, prend en charge les essais spécifiques et les développements sur l'appareillage de coupure. C'est avec ses équipes que Nerys et Mesulog ont travaillé.

Ce que ces laboratoires savent faire, et ce qu'ils ont demandé. L'expertise du site tient en trois mots : appareillage de coupure, physique de l'arc, normes d'essai. Couper un courant de court-circuit, c'est maîtriser un arc électrique qui s'établit entre deux contacts qui s'ouvrent, avec ses phénomènes de pré-arc, et les normes de certification décrivent précisément les conditions dans lesquelles la coupure doit réussir.

Certains de ces essais imposent de commander des commutateurs rapides à un instant précis par rapport au passage à zéro du courant, pour assurer la transition entre des sources de forte puissance tout en limitant l'énergie d'arc dans l'objet testé s'il venait à s'amorcer. Les ordres doivent partir plusieurs centaines de microsecondes avant le zéro, pour absorber les latences de la chaîne de commutation, avec une précision de l'ordre de la dizaine de microsecondes. Les corrections d'anticipation doivent pouvoir se régler finement et indépendamment pour chaque action et chaque phase, y compris sur des séquences d'actions rapprochées, et certaines actions doivent partir à l'échelle de la microseconde sur dépassement d'une grandeur. Et tout cela sur une onde dont ni la fréquence ni l'amplitude ne sont stables. Voilà le besoin tel qu'il a été posé à Nerys et Mesulog.

Ce que le signal impose. Avant toute méthode, l'équipe a regardé les enregistrements du laboratoire, acquis à 1 MHz sur le banc de court-circuit : douze enregistrements de référence, treize voies de courant exploitables, des pics de plusieurs dizaines de kiloampères. Aucune simulation ne remplace une campagne d'essai, et tout ce qui suit est contraint par ce que ces enregistrements contiennent. Ils imposent quatre contraintes.

D'abord une composante apériodique : le circuit est inductif, et le courant de défaut est une sinusoïde décalée par une exponentielle décroissante dont la constante de temps vaut une vingtaine de millisecondes. Sur l'essai ci-dessus, l'onde monte à +62 kA d'un côté et redescend à −28 kA de l'autre ; les zéros ne sont donc pas espacés de 10 ms. Ensuite, la fréquence n'est pas à 50 Hz : la génératrice du banc ralentit sous le couple de court-circuit, et l'équipe a mesuré de 50,7 à 48,7 Hz selon les voies. À 2,6 % d'écart, une prédiction émise 1 ms avant le zéro en supposant 50 Hz se trompe déjà de 26 µs. Sur ces enregistrements, le défaut ne dure que 50 à 65 ms, soit trois périodes : le début du ralentissement est visible, pas son installation. Troisième contrainte, le bruit exclut toute méthode locale : avec un écart-type d'environ 48 A avant le défaut et une pente au zéro qui descend jusqu'à 5,9 A/µs, une détection par seuil gigue de 16 µs, pour un budget de 10. Estimer la fréquence sur une seule alternance donne n'importe quoi entre 42 et 60 Hz, parce que l'offset décale les zéros ; sur une période entière, l'asymétrie se compense et la mesure donne 50,1 Hz. Il faut un modèle qui sépare explicitement l'offset de la sinusoïde. Enfin, il faut être prêt à piloter 5 ms après l'établissement du courant, soit un quart de période : l'estimateur n'a pas le droit d'être lent à converger.

La méthode, dans les grandes lignes. Tout part d'un modèle analytique du courant de défaut, qui n'a rien de secret puisque c'est la physique d'un circuit inductif mis en court-circuit :

I(t) = a·sin(ωt) + b·cos(ωt) + C + d·e^−t/τ

Les termes en sinus et cosinus portent l'amplitude et la phase du fondamental, C est un offset continu résiduel, et le terme exponentiel est la composante apériodique, avec sa constante de temps τ. La pulsation ω n'est pas fixée à 50 Hz : elle fait partie des inconnues.

Le principe est alors d'identifier ces paramètres en continu, par moindres carrés, sur les échantillons déjà acquis. À chaque nouvel échantillon, l'écart entre la mesure et ce que prédit le modèle, l'innovation, sert à corriger l'estimation de façon récursive, avec un oubli progressif des échantillons anciens pour suivre l'évolution du signal. C'est la régression linéaire de l'exemple 3, mise à jour un million de fois par seconde. En parallèle, une boucle à verrouillage de fréquence corrige la pulsation : la fréquence est suivie, pas supposée. Une fois les paramètres connus, l'instant du prochain passage à zéro se déduit du modèle par une formule fermée : pas de recherche, pas d'itération. C'est ce point qui rend le coût de calcul constant par échantillon, et donc compatible avec un FPGA qui traite un échantillon par microseconde sur trois voies de courant simultanées. En virgule fixe, la manière d'écrire la récursion n'est pas anodine : certaines formulations classiques dérivent numériquement jusqu'à faire diverger l'estimation, et l'équipe en a retenu une qui reste stable. Le détail de ces rouages, les pondérations et le paramétrage restent entre Nerys, Mesulog et Schneider.

La vidéo ci-dessous rejoue un enregistrement réel du laboratoire. En haut, la mesure et le modèle estimé, superposés dès les premières millisecondes ; en bas, la distance au prochain passage à zéro calculée à chaque microseconde. Le déclenchement est demandé 100 µs avant le zéro prédit ; l'écart entre le zéro réel et l'instant visé est affiché à chaque passage.

Trois étapes, de mai à août 2026. Les contraintes d'intégration, FPGA, 1 MHz, virgule fixe, n'offrent aucune souplesse pour concevoir un algorithme. Les ingénieurs ont donc séparé les problèmes. En mai, un prototype Python en virgule flottante, rejoué sur les enregistrements de référence du laboratoire : c'est là que se décide ce que l'algorithme doit faire et s'il en est capable, avant toute contrainte matérielle. En juin et juillet, un banc LabVIEW FPGA monophasé à 500 kHz : portage en virgule fixe, fonction par fonction, chacune comparée à son équivalent Python sur les mêmes vecteurs. En août, un moteur VHDL triphasé à 1 MHz, les trois voies partageant un même pipeline, comparé bit à bit contre la référence Python de bout en bout : aucun écart.

Le mot important de l'étape 2 est « banc ». Les essais sur données réelles ont fait remonter ce qu'aucune simulation n'avait montré : des rebonds de détection au voisinage du zéro, dus au bruit du convertisseur, et des formats de virgule fixe trop courts sur certains accumulateurs. C'est une information qui ne peut venir que du matériel, et les retours de l'équipe Schneider sur le comportement réel près du zéro ont réorienté plusieurs choix d'implémentation et de paramétrage. Et le zéro écart bit à bit de l'étape 3 n'est pas une formalité : c'est ce qui autorise à dire que le VHDL fait exactement ce que fait le prototype, ni plus ni moins.

Comment l'IA générative a été utilisée. C'est la partie qui a le plus étonné la salle, et c'est celle qu'il faut décrire précisément pour ne pas la survendre. L'IA n'a pas conçu l'algorithme. Elle a porté un algorithme conçu et validé en virgule flottante vers la virgule fixe, LabVIEW puis VHDL, écrit les bancs de test et leurs vecteurs en même temps que le code, et tenu la documentation à jour. Ce qui a rendu cela possible tient en trois idées.

La première : l'écart revient chiffré. Un harnais compare chaque implémentation à la référence, échantillon par échantillon, en microsecondes et en bits. Le retour n'est jamais « ça ne marche pas », mais « à l'échantillon 1247, cet état diverge de 3 LSB ». Le harnais produit un écart, pas un avis, et la correction qui suit est ciblée. La deuxième : ce qui a été compris une fois est écrit. Chaque piège trouvé, un décalage d'indice dans une récursion, un format trop court, part dans un fichier relu à chaque session ; il n'est jamais repayé. La troisième : le plan passe avant le code. Les gros lots, comme la mutualisation des trois voies sur un seul moteur, sont spécifiés dans un document validé avant la première ligne. Une direction ne se corrige pas après 2 000 lignes.

La condition de tout le reste, et ce qui a coûté le plus cher à construire : un modèle Python bit-exact de l'arithmétique en virgule fixe. Sans lui, la boucle n'a pas de capteur, et aucune itération n'est vérifiable. L'image donnée par Amaury Laurent est celle d'un asservissement : « l'IA produit, l'humain mesure l'écart et le renvoie ». Ce qui rend la boucle stable, c'est que l'écart est une mesure et non une appréciation, et que l'expertise humaine fixe le gain. Une boucle qui n'accroche pas s'arrête, et le travail repart d'un plan neuf plutôt que d'empiler les correctifs.

Ce qui est resté humain. Le savoir-faire. La spécification et le critère d'acceptation. La lecture physique d'un résultat, bruit de convertisseur ou vrai bug. Les arbitrages d'architecture, et l'abandon des pistes qui ne tenaient pas. Le banc, les données, et ce qui part chez le client. En trois mois, de l'ordre de dix mille lignes de VHDL, trois fois plus de modèle et de harnais Python, plus de vingt mille lignes de documentation et plus de deux cents itérations versionnées. Le facteur limitant n'a jamais été la vitesse d'écriture du code, mais celle de la vérification ; c'est là que l'outil a servi. Chaque modification était comparée à la référence en quelques minutes, là où un portage classique se vérifie par campagnes de simulation.

Où en est la précision. L'estimation s'affine en continu : plus la prédiction est émise tard, plus elle est juste. Sur les neuf voies des essais triphasés, l'erreur médiane sur l'instant du zéro vaut environ 50 µs quand la prédiction est émise 1 ms avant le zéro, 15 µs à 0,5 ms, 5 µs à 100 µs et 2 µs à 10 µs. Le compromis se négocie donc avec le temps de réponse de l'organe de coupure : plus il est lent, plus il faut décider tôt, et plus l'erreur est grande.

1 ms avant50 µs

0,5 ms avant15 µs

0,1 ms avant5 µs

10 µs avant2 µs

Avec le paramétrage actuel, la cible de moins de 10 µs est atteinte au plus près sur trois voies sur neuf, et cinq autres se situent entre 12 et 40 µs. Ces chiffres ne sont pas figés, et les intervenants ont préféré le dire tel quel plutôt que de présenter comme acquis un résultat qui ne l'est pas. Côté ressources, le moteur VHDL triphasé reste identique bit à bit à la référence Python, occupe 29 % des blocs DSP du FPGA Kintex-7 et consomme 22 des 40 cycles d'horloge disponibles pour chaque échantillon : il reste de la marge pour la suite.

6. Un fichier de mesures et une IA générative : ce qui marche, et ce qui ne marche pas

L'atelier avait commencé par une question à main levée : « qui a déjà demandé quelque chose à une IA sans trop savoir ce qu'il cherchait ? » Les mains s'étaient levées, avec des rires. Le dernier exemple y répondait.

Le plus quotidien des six : un fichier CSV de mesures en entrée, une IA générative, et une demande volontairement vague, « analyse-moi ça ». Le fichier de démonstration contient 200 pièces passées sur un banc de test électronique : horodatage, numéro de série, banc, opérateur, tensions 3,3 V et 5 V, courant de repos, fréquence d'horloge (25 MHz nominal), température, bruit RMS, durée du test, verdict et liste des mesures hors limites.

Le résultat est impressionnant. En quelques minutes : statistiques par colonne, histogrammes, répartition des échecs par opérateur et par banc, corrélations, et un classeur Excel mis en forme avec ses graphiques. C'est là que les équipes de Mesulog et de Nerys gagnent le plus de temps aujourd'hui, sans projet à six mois : l'analyse d'un journal d'erreurs, la mise en forme d'un rapport, le premier dégrossissage d'un fichier encore inconnu.

Mais l'information obtenue permet-elle de décider ? Pas nécessairement. Un point de départ, oui ; une finalité d'analyse métier, non. « Cette fois, ça n'a pas vraiment marché, parce que nous ne savions pas ce que nous cherchions », ont reconnu les intervenants. Un système à qui il est demandé de trouver quelque chose trouvera toujours quelque chose : une corrélation entre un opérateur et le bruit RMS, par exemple, ou une tendance qui suit la température de la journée. Ce n'est pas parce qu'il y a 250 pompiers sur un incendie que tous les événements où se trouvent 250 pompiers sont des incendies. La corrélation est réelle, l'explication n'est pas dans le fichier, et c'est celui qui connaît le banc qui sait si elle a un sens.

La différence avec l'exemple 2 est là. Interroger WATS sur la chute du FPY la semaine dernière, c'est poser une question précise à des données structurées ; demander « analyse-moi ça », c'est déléguer la question elle-même. L'outil est le même, le résultat ne l'est pas.

Le retournement : un signal stable, qui valide ?

L'atelier s'est terminé sur une mesure. Un signal acquis chaque jour sur un banc, plat, propre, répétable d'un jour sur l'autre. Question à la salle, à main levée : « ce signal est stable, qui valide ? » Des mains se sont levées.

Puis le signal réel : une oscillation franche, échantillonnée à une fréquence malheureuse. Les points de mesure n'avaient pas bougé. Chaque échantillon tombait au même endroit de la période, si bien que l'oscillation entière disparaissait derrière une droite.

Ce n'est pas une erreur de mesure : l'instrument a répondu exactement à ce qui lui était demandé. C'est du repliement de spectre. Le théorème d'échantillonnage le dit depuis Nyquist et Shannon : pour représenter un signal, il faut échantillonner à plus de deux fois sa fréquence la plus haute. En dessous, une oscillation rapide se replie en une fréquence plus basse, et dans le cas extrême d'un échantillonnage synchrone, en une constante. Aucun traitement en aval ne le rattrape : ni les statistiques, puisque l'écart-type est nul, ni un réseau convolutif, ni un modèle de langage. La parade est en amont : connaître la bande de fréquence du phénomène, choisir la fréquence d'échantillonnage en conséquence, et placer un filtre anti-repliement avant le convertisseur. Seule la connaissance du phénomène physique permettait de voir le piège, avant la mesure, pas après.

Qui décide ?

La conclusion de l'atelier tenait en un schéma : au centre, le responsable de la mesure ; autour, les pupitres, statistiques, classification, vision, génératif, et les protocoles qui branchent un modèle sur vos bancs et vos données. L'ingénieur n'est plus celui qui fabrique les outils : l'IA en a tant simplifié l'usage que chacun peut les utiliser. Il devient celui qui gère leur puissance, et il la pilote d'autant mieux qu'il la comprend. L'IA est un outil, extraordinaire de puissance, mais un outil.

Il n'y a pas d'un côté les statistiques et de l'autre l'IA. Il y a un continuum d'outils, et un ingénieur qui choisit le bon barreau de l'échelle.

Pour réduire du bruit, un filtre, moyenne ou médiane selon la nature du bruit. Pour détecter une dérive, une variance ou une carte CUSUM. Pour qualifier un banc, une capabilité. Pour extraire une grandeur physique d'un nuage de points, un modèle géométrique. Pour reconnaître un défaut complexe, un réseau convolutif. Pour anticiper un comportement simple, une régression ; un comportement complexe, un estimateur ou un modèle appris. La bonne technologie n'est pas la plus complexe. C'est celle qui permet de prendre la bonne décision.

Une mesure dont vous ne savez pas quoi tirer, un signal à anticiper plutôt qu'à subir ? Les équipes de Nerys et de Mesulog en parlent volontiers : web@nerysgroup.com.

Depuis octobre 2025, Windows 10 n’est plus supporté. Avez-vous mesuré l'impact de ce changement sur vos systèmes industriels et les bancs de test ?

Cette évolution ne se limite pas à une mise à jour informatique : elle impacte directement la fiabilité des essais, la cybersécurité et la conformité réglementaire.

Chez MESULOG, nous accompagnons les industriels pour transformer cette contrainte en opportunité de modernisation et de sécurisation des environnements de mesure.

Windows 11 : un changement structurel

Windows 11 introduit un durcissement majeur de la sécurité et de l’architecture système.

Cela modifie les règles d’exécution des logiciels industriels, notamment pour les environnements utilisant :

• châssis PXI
• cartes d’acquisition
• drivers spécifiques
• logiciels de test historiques

Un système stable sous Windows 10 peut rencontrer des blocages ou dégradations silencieuses sous Windows 11 s’il n’a pas été préparé.

Windows 11 : Pourquoi les bancs de mesure sont particulièrement sensibles ?

Les systèmes de test cumulent plusieurs contraintes critiques :

• Accès matériel bas niveau
• Pilotage PXI, DAQ ou bus terrain (EtherCAT, CAN).
• Dépendances drivers
• Runtimes spécifiques et parfois anciens.
• Cycle de vie très long
• Les logiciels industriels restent en production 15 à 20 ans.
• Traçabilité et interconnexions
• Connexion aux MES et bases de données de production.

Un banc instable peut entraîner :

• arrêt de production
• données de test invalides
• risques réglementaires

Cybersécurité et non conformité

Windows 11 introduit de nouveaux mécanismes de protection :

• Smart App Control
• ancrage matériel TPM 2.0
• renforcement de la protection contre les attaques OT

En parallèle, le Cyber Resilience Act européen impose désormais que les systèmes numériques soient maintenus et sécurisés pendant tout leur cycle de vie.

Utiliser un système basé sur un OS non supporté peut devenir un risque lors d’un audit de conformité.

La méthodologie MESULOG

Pour sécuriser une migration industrielle, nous appliquons un processus structuré :

1. Audit global

Compatibilité matérielle, inventaire des drivers et analyse des architectures.

2. Modernisation

Migration des applications vers le 64 bits et mise à niveau des environnements logiciels.

3. Durcissement maîtrisé

Configuration de la sécurité Windows adaptée aux systèmes industriels.

4. Validation et non-régression

Tests intensifs pour garantir la continuité et la fiabilité des mesures

Retour d'expérience

Migration d’un banc critique de validation MEMS pour Tronics Microsystems

Avant migration

• Windows 10
• LabVIEW 2016 (32 bits)
• TestStand 2016 (32 bits)

Après migration

• Windows 11
• LabVIEW 2023 (64 bits)
• TestStand 2023 (64 bits)

Résultats :

• système pérenne
• sécurité renforcée
• conformité aux standards industriels

Les risques à ne pas migrer

• vulnérabilités de sécurité non corrigées
• incompatibilités avec les nouveaux matériels
• coûts de maintenance croissants
• arrêts de production imprévus

Conclusion

La question n’est plus faut-il migrer ? mais comment sécuriser la transition vers Windows 11 sans impacter la production.

MESULOG vous accompagne dans cette transformation en concevant des solutions de migration adaptées aux environnements de test et de mesure les plus exigeants.

Vous souhaitez évaluer la compatibilité de vos bancs ou anticiper votre migration Windows 11?

Contactez notre équipe MESULOG pour réaliser un audit de votre environnement de test.

Contactez-nous :

• contact@mesulog.fr

Le 2 juin dernier, les équipes Nerys ont participé aux NI Days France 2026 à Paris, le rendez-vous annuel des professionnels du test, de la mesure et de l'automatisation industrielle.
Cette édition marquait deux anniversaires emblématiques : les 50 ans de NI et les 40 ans de LabVIEW, une technologie qui a profondément transformé la façon de concevoir les systèmes de test et de mesure dans l'industrie.

Retour sur notre conférence

À cette occasion, nos experts ont animé la session : « LabVIEW Debugging – Secrets d'architectes, bonnes pratiques de développeurs »

Au programme : méthodes de débogage, qualité logicielle et retours d'expérience issus de projets industriels.

La conférence a permis d'aborder plusieurs sujets concrets :

• Les bonnes pratiques pour limiter l'apparition des bugs dès les phases de conception ;
• Les outils de diagnostic de l'environnement NI tels que VI Analyzer, InstrumentStudio ou DETT ;
• Les apports de Nigel™, la nouvelle intelligence artificielle développée par NI pour faciliter le diagnostic des communications instrument ;
• L'utilisation de l'IA générative pour l'analyse de journaux d'événements et l'identification des causes de dysfonctionnements.

Les nombreux échanges avec les participants ont témoigné de l'intérêt grandissant pour les sujets liés à l'intelligence artificielle, à la cybersécurité et à la robustesse des architectures logicielles industrielles.

Visionnez la présentation sur youtube

Une démonstration pensée et réalisée par nos équipes

Sur notre stand, les visiteurs ont également pu découvrir une démonstration conçue par notre bureau d'études électrotechnique.

De la conception du coffret à son intégration finale, cette réalisation illustrait notre approche : transformer un besoin technique en solution opérationnelle. Une belle occasion d'échanger autour des technologies NI et de nos domaines d'expertise :

• Bancs de test automatisés ;
• Automatisation industrielle ;
• Architectures LabVIEW et TestStand ;
• Intelligence artificielle appliquée aux systèmes de mesure ;
• Cybersécurité des environnements industriels.

Un anniversaire tourné vers l’avenir

Les célébrations des 50 ans de NI et des 40 ans de LabVIEW ont rappelé l'impact considérable de ces technologies sur le monde de l'ingénierie. L'arrivée de Nigel™ ouvre une nouvelle étape dans cette évolution en intégrant l'intelligence artificielle directement au sein des outils utilisés par les ingénieurs.

Depuis plus de 25 ans, Nerys Group accompagne ses clients dans la conception, le développement et l'industrialisation de solutions de test et de mesure : bancs de test, systèmes PXI et CompactRIO, développement LabVIEW et TestStand, acquisition et valorisation des données industrielles. Une expertise construite au rythme des évolutions technologiques portées par NI, et que nous continuons de faire évoluer aux côtés de nos clients.

Nous remercions les équipes NI pour l'organisation de cet événement ainsi que l'ensemble des visiteurs venus assister à notre conférence et échanger avec nos experts.

« Des projets comme celui-ci, on en réalise un, voire deux dans une carrière ! », souligne Amaury Laurent, responsable projet systèmes embarqués et R&D chez Nerys. Cette aventure exceptionnelle, à laquelle il est si fier d’avoir participé, c’est le projet Tyrex-2, du nom d’une machine unique au monde, conçue et utilisée à l’Institut Laue-Langevin (ILL) basé à Grenoble. Tyrex-2 permet de produire de l’hélium 3 polarisé, un gaz qui a pour vocation d’augmenter l’acuité des faisceaux de neutrons utilisés pour étudier les propriétés électromagnétiques de la matière, dans le cadre d’expériences majeures en recherche fondamentale, tout comme en R&D. Le logiciel standard Vasco, développé par Nerys, pour piloter des installations de tests, a été retenu par l’ILL pour piloter Tyrex-2. Un an après la mise en fonction de la machine, le logiciel qui tourne en continu 24 h sur 24, avec près de 2 700 lignes de scénarios, a démontré sa fiabilité et sa capacité à piloter une machine spéciale d’une grande complexité.

L’ILL, une des plus intenses sources de neutrons au monde

Contribuer au projet Tyrex-2, c’est apporter sa modeste pierre à l’édifice de la recherche mondiale que représente l’ILL. Créé en 1967 pour consacrer l’amitié et la coopération franco-allemande, dans le domaine de la recherche, l’ILL fournit aux scientifiques du monde entier des faisceaux de neutrons générés par des réactions nucléaires.

Vue du réacteur de l’ILL, lumière bleue produite par l’effet Tcherenkov.

Pourquoi produit-on des neutrons ? Composants électriquement neutres des atomes, les neutrons permettent de voir avec une résolution très fine les propriétés de la matière, particulièrement dans les métaux.

L’hélium 3 polarisé renforce cette faculté. Polarisés sous l’effet du gaz, les neutrons permettent de mesurer avec précision les propriétés magnétiques.

Chaque année, environ 1 400 chercheurs de plus de 40 pays viennent à l'ILL réaliser quelque 1 000 expériences, sélectionnées par un comité d’experts. Ces expériences permettent de faire progresser la recherche fondamentale dans des domaines aussi variés que la biologie, la chimie, la physique nucléaire ou encore la science des matériaux, etc. L’ILL collabore aussi étroitement avec les départements R&D de nombreuses entreprises industrielles.

Tyrex-2 : une installation pour polariser l’hélium 3

Certaines expériences menées à l’ILL nécessitent de l’hélium 3 polarisé. C’est le service optique des neutrons qui est chargé de sa production. David Jullien y officie depuis plus de 20 ans. « Il y a très peu de traces de l’hélium 3 à l’état naturel sur Terre. Les stocks existants proviennent de rebuts de l’industrie nucléaire et de la décomposition des ogives. Ce gaz est présent en quantité conséquente dans l’atmosphère lunaire », précise-t-il.

Afin de développer l’utilisation d’hélium 3 polarisé pour les expériences neutroniques, l’ILL s’est doté d’une équipe dédiée et a conçu en 2000 une machine, baptisée Tyrex, pour polariser le gaz et le conditionner dans des cellules expérimentales. L’installation permet aussi de récupérer l’hélium 3 polarisé, utilisé lors des expériences, et de le purifier avant réemploi.

« La mise en fonctionnement de Tyrex a été stratégique. Elle a permis de limiter les pertes d’hélium 3 et à l’ILL de recycler et polariser en moyenne 200 litres de gaz par an », souligne David Jullien. « La machine a montré des premiers signes de vieillissement en 2017. Nous avons alors entrepris d’en réaliser une nouvelle », explique l’expert, qui a assuré la programmation de la machine. Et d’ajouter : « Nous avons profité de l’arrêt du réacteur, pour maintenance, durant deux ans, pour réaliser sa construction. Nous avons conçu une machine plus grande et plus fiable pour augmenter les débits de production. Nous l’avons aussi rendue plus autonome et facile d’utilisation », détaille le technicien.

Le fonctionnement de Tyrex-2

Construite en granit, titane et autres matériaux amagnétiques, équipée d’un compresseur de trois mètres de long, dotée d’une tuyauterie en verre réalisée et soudée par un artisan verrier, meilleur ouvrier de France, de lasers et systèmes optiques sur mesure, Tyrex-2 détonne aussi bien par son esthétique léchée, sa technicité, que par la complexité du procédé de polarisation de l’hélium 3.

La machine Tyrex-2 conçue par le service optique des neutrons de l’ILL. Elle permet de polariser et « recycler » l’hélium 3.

L’hélium 3 sous pression

Pour être polarisé, l’hélium 3 doit être maintenu à basse pression (1 mbar). À l’inverse, la polarisation d’un flux de neutrons nécessite que l’hélium soit à haute pression (2 ou 3 bar). Tyrex-2 permet de résoudre cette problématique, grâce à un processus complexe de transfert de l’hélium 3 qui permet de conserver sa polarisation lors de sa compression à la bonne pression jusqu’à sa livraison sur les sites d’expériences.

La polarisation de l’hélium 3

Pour éviter de polluer le gaz, Tyrex-2 est équipée de multiples systèmes de purification. Une première étape consiste à descendre en pression à 1 mbar, l’hélium contenu dans un réservoir. Cet hélium est injecté dans des tubes en verre qui sont soumis à un champ électrique et à un faisceau laser infrarouge polarisé de forte puissance. La polarisation s’obtient par pompage optique d’un état excité de l’hélium 3 généré par l’action combinée du champ électrique et du faisceau laser. C’est ainsi que l’hélium est polarisé. Cette technique appelée MEOP (Metastability Exchange Optical Pumping) ne marche qu’à basse pression (ici 1 mbar) pour obtenir de forts taux de polarisation.

Conserver la polarisation

La polarisation de l’hélium 3 est un état fragile qui peut être facilement « rompu ». Pour que l’hélium reste polarisé, il ne doit pas être soumis à des variations importantes de champ magnétique. Tyrex-2 est équipée de 9 bobines générant un champ magnétique extrêmement homogène et est conçue entièrement en matériaux amagnétiques. Grâce à un appareil spécial développé par l’ILL, on mesure à ce stade la polarisation du gaz qui doit atteindre un niveau d’environ 80 %.

Monter le gaz en pression

Par un “jeu” d’ouverture de vannes, et sous l’action d’un compresseur linéaire de 3 mètres de long, animé par un vérin hydraulique, le gaz contenu dans les tubes en verre à très basse pression est transféré via plusieurs séquences de compression dans un réservoir en verre (un buffer). Quand ce buffer atteint la pression nominale de 300 mbar, le gaz est transféré dans les cellules expérimentales via le même compresseur. L’opération se répète alors jusqu’à atteindre la pression désirée dans les cellules expérimentales. Le gaz est transféré en une seule fois pour les cellules de petites tailles jusqu’à une dizaine de fois pour les plus grosses. Le remplissage des cellules, en verre ou en silicium, peut prendre jusqu’à quatre heures. Tyrex-2 traite également l’hélium « sale » de retour d’expérience via un « autre circuit » balisé par différents filtres.

L’installation de polarisation et recyclage de l’hélium 3 a été conçue pour être plus autonome que la première. Tout l’enjeu de recourir à une solution telle que Vasco était d’optimiser, au maximum, les différents temps de cycles de compression de la machine et d’éviter les déperditions du précieux gaz.

Synoptique de Tyrex-2.

Une collaboration réussie

« Malgré de réelles compétences en interne, à l’issue de la construction de la machine, nous avons décidé de nous faire accompagner dans le choix et la mise en place d’un logiciel de pilotage de la machine », raconte David Jullien.

« Nous avons lancé un appel d’offres. Parmi les solutions proposées, celle de Nerys est sortie du lot à plusieurs titres. L’entreprise affichait une expertise forte en développement LabVIEW. Je connaissais aussi la bonne réputation de Mesulog qui l’avait rejointe au sein de Nerys Group. J’ai enfin tout de suite noté les possibilités qu’offrait Vasco », explique David Jullien.

Du côté de Nerys Group, porté par le binôme Amaury Laurent et Benjamin Lerch, développeur, l’enthousiasme a été au rendez-vous pour travailler sur un tel projet. « La machine est magnifique et techniquement incroyable », souligne Amaury Laurent, admiratif du savoir-faire exceptionnel qui existe à l’ILL. « Le capteur capable de mesurer la polarisation de l’hélium, de même que les cellules expérimentales en silicium, entre autres, sont des réalisations internes ! »

« Sur le plan technique, ce type de projet vous fait forcément progresser », reconnait Amaury Laurent.

Et de souligner : « Nous avons rencontré des problématiques importantes liées à la complexité de la machine. En particulier, il fallait être capable de gérer le fait que plusieurs actions se déroulent en même temps quand la machine est en fonctionnement (prise en compte en simultané de deux cellules de remplissage, ouverture et fermeture des vannes…). Nous avons su apporter des solutions qui viennent encore enrichir Vasco comme la mise en place d’un mécanisme pour exécuter des instructions à distance et la mise en place de verrous d’exclusion qui évitent les états non souhaités lors d’exécutions simultanées de deux scénarios identiques ».

« Les échanges avec David Jullien ont été très constructifs. Il possède une connaissance extrêmement pointue de la machine et avait une idée très précise de ce qu’il souhaitait. Il nous a apporté des organigrammes fonctionnels, ainsi que des formules mathématiques pour élaborer les seuils de déclenchement, des calculs de pression de consigne, etc. que nous avons directement intégrés dans Vasco », explique Amaury Laurent.

En partant du premier plan, David Jullien, Benjamin Lerch et Amaury Laurent devant Tyrex-2.

Concernant le matériel d’acquisition associé à la machine, l’organisation suivante a été mise en place :

• Un PC sous Windows exécute Vasco et permet l’affichage de l’interface de pilotage.
• Un CompactRIO exécute Vasco RT (temps réel). Ce dernier assure le pilotage général de la machine, des vannes et des lasers. Il acquiert également les pressions. Il intègre aussi un compteur kilométrique et un compteur horaire pour le vérin.
• Un CompactDAQ, déporté au niveau des tubes en verre, permet de collecter d’autres mesures, notamment des champs électriques et celles liées à la polarisation.

Les deux équipements de mesure sont synchronisés en TSN (Time-Sensitive Networking).

Matériel d’acquisition CompactRIO (photo 1) et CompactDAQ (photo 2) de NI (Emerson) utilisé sur Tyrex-2.

Les deux développeurs soulignent également la forte valeur ajoutée qui a été apportée sur la partie scénarios. Près de 2 700 lignes de scénarios applicatifs ont été générées via le module Blockscript de Vasco !

Vue de scénarios Blockscript.

Enfin, ils sont aussi particulièrement fiers du rendu de l’interface d’affichage et de pilotage de Tyrex-2, à la fois ergonomique, esthétique et pratique.

L’interface montre l’état de la machine au fil de l’eau. Le tableau de bord général affiche deux postes de remplissage (deux cellules) nourris par une base de données qui recense toutes les cellules en stock de la machine. Cette base de données intègre près de 400 paramètres d’application tels que les seuils de déclenchement d’ouverture des vannes, les consignes de pression, la vitesse de déplacement, les constantes de calculs…

Des interfaces spécifiques ont été développées, notamment celle qui permet l'affichage et le pilotage du volet optique, une autre supervise le groupe hydraulique. Un affichage offre aussi une visualisation réaliste du remplissage des tubes en verre.

Vue des interfaces de la machine Tyrex-2.

« Nous avons travaillé en étroite collaboration avec David Jullien. Il a réalisé certains visuels directement sous LabVIEW et nous les avons intégrés dans Vasco. Le résultat est vraiment très sympa », analyse Amaury.

David Jullien se réjouit également de la qualité de la collaboration avec Nerys. « Amaury, qui a été mon interlocuteur, tout au long du projet, a une très bonne compréhension des choses. Il possède une grande polyvalence, précieuse pour comprendre les rouages et subtilités d’une machine comme Tyrex-2. Benjamin et lui ont fait preuve de réactivité et d’une grande disponibilité pour nous permettre d’achever la machine dans les délais attendus », souligne David Jullien. « Vasco a aussi tenu toutes ses promesses. J’ai particulièrement apprécié la programmation des scénarios via Blockscript qui m’a fait gagner énormément de temps durant la mise au point de la machine », précise-t-il.

La plupart des développements réalisés pour Tyrex-2 n’ont pas nécessité de code spécifique, ce qui illustre que Vasco est une solution avec une forte adaptabilité. Surtout, alors qu’il a été conçu pour superviser des bancs de tests, Vasco démontre sa capacité à piloter des machines spéciales complexes. Une machine similaire à Tyrex-2 a été commandée par un centre suédois qui produira également des faisceaux de neutrons. Vasco sera installé sur cette machine. Quelle meilleure reconnaissance ?

Pour en savoir plus sur Vasco : la page VascoSuite.

Propos recueillis et rédigés par Khady Bathily.
Remerciements à David Jullien et Amaury Laurent pour leurs témoignages.
Crédit photos : ILL - Tous droits réservés.

Télécharger la newsletter au format PDF

Si vous êtes amateur de matchs de foot ou de rugby, vous avez forcément déjà vu des arbitres équipés d’un système audio de la société VOGO. L’entreprise, spécialisée dans le développement de systèmes de communication audio et de diffusion live & replay vidéo, propose notamment des systèmes radio VOKKERO, conçus et développés pour les professionnels du sport (arbitres, médecins, coachs, analystes vidéo), et les équipes terrain de l’industrie (en particulier BTP, industries bruyantes, transports, énergies et sécurité) et de l’audiovisuel.

La signature de ces systèmes ? Ils sont dotés d’un filtre de bruit breveté, qui rend la communication et le travail possibles dans des environnements très bruyants tels que les stades, les usines, les chantiers et les lieux de spectacles/tournages.

Afin de garantir une fiabilité irréprochable, ces produits sont systématiquement soumis à des tests rigoureux. MESULOG, spécialisée dans le développement de logiciels de tests et de mesure pour l’industrie, a accompagné VOGO dans le déploiement de procédures de tests automatisées, sous NI TestStand, pour tout un écosystème de produits.

Les systèmes radio VOKKERO permettent de communiquer dans des environnements très bruyants.

Un logiciel unique pour tester la production de trois catégories de produits

« NI TestStand est un séquenceur de tests prêt à l’emploi utilisé pour l’automatisation des tests de validation et de production. Il offre la possibilité de tester des produits un à un (mode séquentiel), en parallèle ou par lots. Quel que soit le mode utilisé, chaque produit fait l’objet d’un rapport de test, ce qui garantit une traçabilité de l’ensemble des opérations », explique Damien Lamy, référent architecte NI TestStand chez MESULOG.

« À l’origine, nous avions développé un moteur de test sous NI TestStand pour la société ADEUNIS, qui développait les systèmes VOKKERO, avant leur rachat par VOGO en 2019. Ce moteur de test était destiné aux produits IOT d’ADEUNIS. Fabien de Barros, responsable technique chez VOGO, y a vu un intérêt pour l’entreprise, qui souhaitait automatiser le plus possible ses procédures de tests pour différents produits », détaille Damien Lamy. « Nous avons adapté le moteur de test en conséquence, notamment pour déployer une partie tests multiproduits. Nous avons également développé un logiciel unique qui permet de tester toute la production des cartes électroniques nues, des produits assemblés et des configurateurs-chargeurs pour les gammes VOKKERO ELITE et VOKKERO GUARDIAN », souligne l’architecte NI TestStand.

VOGO est le leader mondial de l’équipement audio des arbitres.

L’optimisation des séquences de test monoproduit

« Pour comprendre nos exigences en matière de fiabilité et traçabilité des produits, il faut considérer l'usage de nos produits, en particulier dans le domaine du sport. Les enjeux télévisuels sont considérables. Nous sommes le leader mondial de l’équipement audio des arbitres. Nous ne pouvons pas accepter que nos systèmes tombent en panne au cours d’un match ! », explique Fabien de Barros. « Avant notre collaboration avec MESULOG, nous disposions déjà d’un banc pour tester les cartes électroniques nues et les produits assemblés, mais nous n’avions pas accès à des informations pourtant essentielles, comme le suivi des quantités testées, les taux de panne... Ces remontées d’informations étaient d’autant plus difficiles que notre fabricant de l’époque était basé en Malaisie. Nous avons depuis rapatrié la production en France », détaille Fabien de Barros.

Aujourd’hui, toutes les cartes électroniques nues et les produits assemblés sont respectivement testés via deux plateformes différentes (ou systèmes de posage). L’opérateur qui devait, auparavant, suivre un fichier de consignes, doit simplement choisir la référence du produit à tester via une interface opérateur. Celle-ci permet également de démarrer le test et d’en afficher les résultats. Certaines séquences de tests réclament des actions manuelles des opérateurs. Elles sont indiquées par des supports média vidéo, photo ou audio que MESULOG a intégrés à l’interface. « C'est une véritable amélioration d’un point de vue ergonomique et opérationnel. Elle offre un plus grand confort de travail et de la sérénité à nos opérateurs qui ne craignent plus de commettre des erreurs », constate Fabien de Barros.

L’entreprise a par ailleurs souscrit à la solution WATS, développée par l’entreprise VIRINCO dont MESULOG est le partenaire France. L’utilisation sous NI TestStand ne nécessite pas de développement supplémentaire : « Il suffit de cocher une case », explique Damien Lamy. « Nous utilisons beaucoup WATS pour le suivi de production fournisseur. Cela nous permet de voir les quantités de produits passés sous test, les taux de panne, les taux de rebut, de voir la nature des principales pannes, etc. Nous animons avec les fournisseurs des points réguliers et leur demandons par exemple de prendre des mesures lorsqu’un défaut est récurrent. Cet outil nous permet aussi, à distance, de savoir beaucoup plus facilement ce qui se passe, de faire évoluer le banc et de voir aussi s’il n’y a pas de problème au niveau des séquences de tests. Nous sommes beaucoup plus sereins sur les éventuelles non-conformités qui sont rédigées par les clients, car nous disposons de tout l’historique des produits », illustre Fabien de Barros.

Des tests multiproduits totalement automatisés

« L’apport majeur de notre partenariat avec MESULOG a été la mise en place d’un banc de tests multiproduits fin de ligne et le développement d’outils de paramétrisation des systèmes en fin de chaîne », rappelle Fabien de Barros. Après avoir testé les PCB et produits assemblés, VOGO vérifie également les configurateurs qui servent à charger les systèmes de communication radio. Ils sont également utilisés pour paramétrer les terminaux.

Ce travail de test et de paramétrage des appareils était réalisé, produit par produit, par un opérateur qui consultait un fichier pour connaître le logiciel (firmware) à intégrer dans chaque produit. « Il faut savoir que nos clients commandent des kits composés d’appareils équipés d’options différentes. C'était long et surtout source d'erreurs pour les opérateurs. Nous avons remplacé ce travail manuel par une automatisation pure. Ce qui est remarquable, c’est que cette innovation majeure dans notre process n’a pas nécessité le développement d’outils spécifiques. MESULOG a su s'adapter exactement à ce que font nos produits. Nous n’avons pas eu besoin de venir rajouter du matériel autre que le nôtre. C'est vraiment une force importante, car l'écosystème de produits reste celui que nous connaissons, y compris au niveau du test », souligne le responsable technique.

La configuration et le test de tout un lot de produits sont possibles simplement en branchant les configurateurs via un câble USB relié au PC. On peut mettre en test autant de configurateurs que le PC accepte de ports USB et sur chaque configurateur, on peut mettre jusqu’à 12 produits. L’opérateur a uniquement à mettre en route les essais et à lancer la paramétrisation des produits. Chaque configurateur vient adresser chaque produit indépendamment. Une interface opérateur permet de consulter le statut de tous les produits sous test.

L’entreprise estime que le temps de programmation pour chaque produit est d’environ trois minutes. Pour cinquante produits paramétrés en parallèle sur cinq configurateurs, l’opération va durer une demi-heure contre deux heures trente auparavant. Un temps durant lequel l’opérateur peut accomplir d’autres tâches en parallèle, alors que préalablement des interventions régulières étaient requises, en particulier le contrôle et la relance des programmations entre chaque configurateur. « Nous pouvons traiter une grande quantité d’appareils en même temps ! C’est du temps masqué et des gains de productivité », se réjouit Fabien de Barros.

Une vue de l’interface opérateur du banc de tests multiproduits développée pour VOGO.

Simple comme remplir un fichier Excel

MESULOG a aussi su répondre aux spécificités de l’offre de VOGO qui est extrêmement diversifiée. « Nous proposons un écosystème de produits assez varié, car chaque demande client peut être unique. Bâtis autour de produits standards, nos systèmes sont personnalisés, ce qui nous amène très régulièrement à créer de nouvelles références produits. Cette particularité aurait pu être une vraie difficulté pour nos procédures de tests en plus des travaux de R&D si ajouter de nouvelles références nécessitait l’intervention de Damien ou d’un de ses collègues de MESULOG. Ajouter une référence produit au test nécessite tout simplement de mettre à jour un fichier Excel. C’est un outil facile à la lecture et à l’entretien. Cette méthode nous offre une liberté appréciable. Nous pouvons in fine gérer des outils de test puissants sans avoir à entrer dans le cœur du système ».

« Dans la même logique, MESULOG a développé une couche d'abstraction matérielle (dite HAL) multi-appareils, qui permet de ne pas impacter l’ensemble du système. Lorsque nous remplaçons du matériel et des instruments, il suffit de sélectionner le nouveau driver. Outre l’expertise technique apportée par MESULOG, j’ai beaucoup apprécié leur volonté de favoriser notre autonomie et la disponibilité de Damien », témoigne Fabien de Barros.

VOGO, qui est aussi reconnue pour ses solutions de diffusion vidéo replay, envisage à court terme une nouvelle collaboration avec MESULOG. « Nous allons les solliciter sur le déploiement d’une solution de tests automatisés pour des casques audio. C’est le dernier élément de l’offre VOGO qui est encore testé manuellement chez nous. Cela représente un volume de 8 000 pièces par an. Les tests sont difficiles à mener pour nos opérateurs et nous rencontrons les mêmes écueils propres aux opérations manuelles. C’est un vrai défi technique, car il faudra imbriquer dans le développement des outils de traitement de signal pointus », challenge Fabien de Barros.

VOGO est aussi reconnue pour ses solutions de diffusion vidéo replay.

Rédaction : Khady Bathily.
Remerciements à Fabien de Barros et Damien Lamy pour leurs témoignages.
Crédit photos : VOGO - Tous droits réservés.

Télécharger la newsletter au format PDF

Caroline Couvert, cofondatrice de NERYS, a transmis les rênes de l'entreprise et de NERYS GROUP à l’occasion de son départ à la retraite, le 2 février dernier.

Cette transition marque la reprise de NERYS GROUP à 100% par les salariés de NERYS et MESULOG et l’arrivée à la tête du groupe de Sylvain Bistagne et Luc Desruelle.

Expert en management et conduite du changement, Sylvain Bistagne a accompagné NERYS durant de nombreuses années dans sa structuration et pilote d’ores et déjà le développement des activités de conseil, de services et de formation de NERYS GROUP. Il assurera la direction de NERYS et de NERYS GROUP.

Luc Desruelle, directeur de MESULOG, assurera la présidence de NERYS GROUP, garantissant ainsi une continuité technique et stratégique au sein du groupe. Son expertise technique, notamment en développement logiciel (NI LabVIEW), fait référence dans le secteur des essais et mesures.

Pour Sylvain Bistagne et Luc Desruelle :

« Nous croyons fermement que cette transmission aux collaborateurs était la meilleure voie. Nous sommes fiers que l'équipe partage cette vision et adhère unanimement à cette évolution. Avec leurs enthousiasmes, leurs implications et leurs compétences, nous sommes prêts à relever les défis technologiques de demain et à continuer d’innover aux côtés de nos clients et partenaires ».

« En 2007, lorsque nous avons créé NERYS, avec mes associés, Marcel Auboiroux, Jean-Philippe Roth et Thierry Pugliesi, notre objectif était de bâtir une entreprise innovante, mais nous avions aussi à cœur de créer une entreprise à taille humaine pour garantir une proximité avec notre équipe et nos partenaires. Cette transmission aux salariés est pleine de sens. Ils s'investissent au quotidien auprès des clients et sont leurs interlocuteurs privilégiés. Les partenaires apprécient la reprise et la continuité des activités par l’équipe", souligne Caroline Couvert.

Caroline Couvert a guidé NERYS vers une croissance progressive, en réalisant des projets d’envergure pour des secteurs exigeants tels que la défense, l’aéronautique, le spatial, le nucléaire et l’automobile. L’entreprise a franchi un tournant décisif en 2022 avec la création de NERYS GROUP, à la suite de l’acquisition stratégique de MESULOG.

Parmi ses nombreux accomplissements, Caroline Couvert a été à l’initiative d’un modèle d’entreprise vertueux bâti autour de valeurs de gouvernance participative. Alors qu’elle passe le flambeau à Sylvain Bistagne et Luc Desruelle, elle transmet une organisation solide, tournée vers l’avenir et prête à répondre aux attentes et défis les plus exigeants des partenaires de NERYS GROUP.

Toute l’équipe NERYS GROUP lui exprime sa plus profonde gratitude et ses remerciements pour son leadership, sa passion, son engagement et sa bienveillance durant ces 18 années.

Merci Caroline !!!

Du 16 au 17 octobre, Nerys Group est présent au Salon Mesure Solutions Expo qui se déroule au Centre de Congrès de Lyon. Vous pouvez retrouver notre équipe au stand B41.
Nous avons eu aussi le plaisir d'animer pour la première journée de cet événement un exposé technique sur le thème « Performance des systèmes de mesure : est-il possible de transmettre des signaux sans “bruits” ? »
Un grand merci à tous les participants venus nombreux, au Réseau Mesure à l'initiative du salon pour cette opportunité et à notre binôme d'experts, Amaury Laurent et Frédéric Bernard, pour sa brillante et vivante présentation.

Sur une machine, dans un labo ou dans une usine, réaliser une mesure de qualité est un défi. Nos deux experts, forts de leurs années d’expérience professionnelle et issus de formations instrumentation et physique appliquée, racontent la folle histoire d’un signal analogique dans un monde hostile de bruit et de parasites.

Objectifs de cette présentation

Comprendre et traiter le bruit dans les différents éléments du système de mesure.

• Est-il possible de transmettre des signaux sans bruits ?
• La performance est fonction de votre application : performance = subjectif
• Comprendre les enjeux pour éviter les pièges

Notre présentation n’est pas un cours – c’est notre vision – notre expertise.

Qu’est-ce qu’un système de mesure ?

• C’est l'ensemble du matériel et du logiciel permettant de réaliser des mesures
• Une mesure est un processus qui consiste à évaluer une grandeur physique
• Il est indispensable de comprendre le rôle des éléments qui le constituent

La chaîne de mesure : grandeurs physiques, capteurs, conditionneur, systèmes d’entrée/sorties (acquisition et restitution), ordinateur, logiciel.

De la théorie à la pratique

Il suffit de brancher les éléments et ça mesure. Parfois en laboratoire… mais rarement dans la vraie vie. Pourquoi ? Parce qu’il y a du bruit sur la mesure…

Bruits de mesure : définition

Le bruit est l’ensemble des signaux parasites qui se superposent à une information.

• Dans notre cas, ils sont induits par des sources externes ou internes au système de mesure
• Origines diverses :
  • Mécanique : vibrations, dilatation…
  • Électrique : alimentation à découpage, terre de mauvaise qualité…
  • Environnement : température, rayonnements…
  • Câblage : interférences entre les signaux
• On quantifie généralement le rapport signal / bruit en dB

Mesure = signal + bruits. Les bruits possibles : périodique, impulsionnel, aléatoire, mathématique.

L’histoire commence par le capteur…

C’est l’origine de la mesure.

• Transducteur : convertit un signal physique en signal électrique
• Le capteur est celui par qui « le bruit » commence
• Quelques exemples de caractéristiques pour sélectionner un capteur : précision, étendue – pleine échelle…

… pour atteindre la numérisation…

• La numérisation convertit le signal électrique en information exploitable
• De nombreux critères sont à prendre en compte
• Il faut souvent faire des compromis : type de signaux, nombre de voies d’entrées/sorties, amplitude, fréquence d’acquisition, résolution, bande passante, prix…

Attention à ne pas introduire un nouveau bruit.

Bruits induits par la numérisation : bruit mathématique (Shannon), stabilité d’horloge (distorsion), quantification (crénelage).

… en passant par le conditionneur…

La grandeur électrique fournie par le capteur peut être une tension, une résistance, une fréquence ou tout autre attribut électrique.

• Conditionner le signal : adapter le type de grandeur électrique
• Amplifier : adapter la dynamique du signal
• Isoler : adapter la référence électrique du signal

Le capteur est rarement compatible avec le système de numérisation. Il a besoin d’être adapté.

En plus d’adapter le capteur, le conditionneur peut renforcer le signal pour diminuer l’influence du bruit :

• Amplifier car trop faible (100 µV → 10 V)
• Filtrer car bruité (réjecteur à 50 Hz)
• Isoler galvaniquement (adaptation de référence)

Le conditionneur doit être au plus proche du capteur pour éviter de propager le bruit.

Exemple : conditionneur discret. Exemple d’une tension faible : le conditionneur amplifie, isole et filtre un signal faible. Amplifier le signal augmente le rapport signal/bruit, si le bruit ne s’est pas introduit avant…

Exemple : conditionneur intégré. Exemple d’une jauge de contrainte : le module pont de jauges NI 9237 offre des options pour se configurer en quart, en demi et en pont complet. L’utilisation d’une connectique et de câbles blindés améliore l’immunité de la mesure aux bruits.

… de câbles en câbles…

L’influence du câblage est trop souvent oubliée ! De bonnes pratiques sont indispensables. Ne pas les respecter peut vous conduire à mesurer plus de bruit que de signal.

Quelques rappels

• Certains signaux sont plus sensibles au bruit : une tension est plus facilement bruitée qu’un courant ou une fréquence
• Une mesure est souvent une tension
• La tension est la différence de potentiel électrique entre deux points
• La masse est la référence des potentiels électriques
• La masse est souvent référencée à 0 V en étant reliée à la terre

Les bonnes pratiques…

• Séparer les courants forts et les courants faibles
• Respecter les modes de référencement (référencé, non référencé, différentiel, pseudo-différentiel)
• Éviter les courants de circulation :
  • Éviter les boucles de masse
  • Assurer la bonne qualité des équipotentielles
• Équilibrer les impédances
• Éviter les signaux flottants

… pour éviter

• Les couplages capacitifs et inductifs
• Les courants circulant dans des boucles de masse
• Les signaux flottants ou mal référencés
• L’apparition de diaphonie
• L’apparition de signaux fantômes

Le choix du câble est déterminant : paires torsadées, blindées…

Exemple : boucle de masse. Deux points de masse distants ne sont pas équipotentiels : une tension existe.

• Connectés, ils donnent naissance à une circulation de courant
• Ce courant induit une tension entre la masse de la source du signal et la masse du système de mesure
• Ces deux tensions sont un bruit qui altère la mesure

Si possible : câbler les capteurs en différentiel.

Exemple : impact d’un hacheur. Quel est l’impact d’une voiture électrique dont le chargeur est mal filtré ? Ça fait mal à la tête et aux appareils électriques !

Attention aux ordinateurs. L’ordinateur est actuellement la plate-forme privilégiée pour les systèmes d’instrumentation. Un matériel d’acquisition partage souvent la même référence que son ordinateur.

• Un ordinateur de bureau est référencé à la terre via la prise murale : le système d’acquisition peut être mal référencé.
• Un ordinateur portable est non référencé sur batterie et rarement référencé par son chargeur : le système d’acquisition peut être flottant. L’ajout d'une référence au système doit alors être envisagé en raccordant son 0 V à la masse.

N'oublions pas que pour une mesure de qualité il est impératif d’avoir un seul point de contact à la masse.

… et finit dans le logiciel

Trop tard !

• Le bruit s’est imposé
• Il a été amplifié
• Il s'est multiplié
• Il a distordu le signal

Il reste possible de l’atténuer à l’aide du logiciel (filtrage) ou de le quantifier (FFT…).

Quelques points d’attention

• La résolution doit être cohérente avec la précision
• Attention aux calculs non linéaires (RMS, log…)
• L’encodage des données peut dégrader le signal
• Des arrondis ou des troncatures peuvent se nicher dans les algorithmes
• Des accumulations de résidus sont possibles (filtres récursifs)
• Des phénomènes mathématiques peuvent modifier le signal (convolution, fenêtrage…)

Conclusions

Transmettre des signaux sans bruit dans un système de mesure performant :

• Pas de mesures sans bruit, l’objectif est de le minimiser
• Plus un bruit pénètre en amont dans la chaîne de mesure plus son impact est important
• Pour bien transmettre un signal, il est important de le connaître
• Traiter le bruit au plus tôt évite sa propagation
• Le respect de la référence électrique est un point fondamental

Bibliographie

• NI, Measurement fundamentals
• LabVIEW Programmation et applications (Dunod – ISBN : 978-2-10-078283-3)

Télécharger la présentation complète au format PDF

Nous sommes heureux de vous informer que NERYS GROUP participera les 16 et 17 octobre 2024 au SALON MESURES SOLUTIONS EXPO, au Centre de Congrès de Lyon.
Cette deuxième participation de notre entreprise, à ce grand salon, organisé par le Réseau MESURE, aura une saveur particulière, car nous y interviendrons de différentes manières.

En premier lieu, Stéphanie GARRON et Florent FONTEIX auront le plaisir de vous accueillir sur notre stand B41 le mercredi 16 octobre et le jeudi 17 octobre. N’hésitez pas à venir les rencontrer pour vous présenter et découvrir nos différents métiers : concepteur de bancs de tests et de systèmes de mesure, développeur de logiciels industriels, formateur…

Amaury LAURENT et Frédéric BERNARD vous présenteront un exposé technique sur le thème : « Performance des systèmes de mesure : est-il possible de transmettre des signaux sans " bruits" ? », le mercredi 16 octobre à 15 h 30. En savoir plus sur cette conférence

Nous attendons avec impatience de vous retrouver lors de cet évènement de référence pour notre filière. Il promet d’être riche en découvertes et en échanges de qualité.

N’hésitez pas à contacter Stéphanie GARRON pour toutes questions.

Un projet exceptionnel

Des projets comme celui-ci, on en réalise un, voire deux dans une carrière ! », souligne Amaury Laurent, responsable projet systèmes embarqués et R&D chez Nerys. Cette aventure exceptionnelle, à laquelle il est si fier d’avoir participé, c’est le projet Tyrex-2, du nom d’une machine unique au monde, conçue et utilisée à l’Institut Laue-Langevin (ILL) basé à Grenoble.

Tyrex-2 permet de produire de l’hélium 3 polarisé, un gaz qui a pour vocation d’augmenter l’acuité des faisceaux de neutrons utilisés pour étudier les propriétés électromagnétiques de la matière, dans le cadre d’expériences majeures en recherche fondamentale, tout comme en R&D.

Le logiciel standard Vasco, développé par Nerys, pour piloter des installations de tests, a été retenu par l’ILL pour piloter Tyrex-2. Un an après la mise en fonction de la machine, le logiciel qui tourne en continu 24h sur 24, avec près de 2700 lignes de scénarios, a démontré sa fiabilité et sa capacité à piloter une machine spéciale d’une grande complexité.

Lire le cas d’usage complet : Vasco sur la machine Tyrex-2 de l’ILL

Mesulog est partenaire officiel de la société Virinco et aide ainsi ses clients à la mise en place de la solution WATS Test Data Management dans leur entreprise tout en assurant le support et la formation à l'analyse des données collectées.

Dans le cadre de ses projets de développement de bancs d'essais et de caractérisation, Mesulog est confronté aux exigences des clients sur la collecte et l’analyse des données. La solution proposée par Virinco avec son produit WATS est particulièrement adaptée et puissante pour répondre à cette problématique. Elle est mise en place dans de nombreux projets réalisés sous NI TestStand et NI LabVIEW avec le plugin WATS.

Que ce soit en recherche et développement ou en production, les bancs d'essais permettent la collecte de quantités importantes de données. Dans une démarche de suivi des indicateurs de contrôle qualité (KPIs), de réparation et d'amélioration de la production, il est nécessaire de les exploiter et de les analyser. La finalité est d’avoir la maitrise de vos données de production.

WATS Test Data Management est un outil de gestion des données de test. Il permet d'exploiter pleinement les données générées par les bancs de tests développés entre autres sous NI TestStand, NI LabVIEW. Avec WATS Test Data Management, vous pouvez collecter et visualiser vos données de test et de réparation. Vous identifiez rapidement les problèmes de rendement de production, les pannes fréquentes de produits, la mauvaise couverture des tests ou les problèmes de performances.

Quelques exemples de fonctionnalités :

• Calcul des indicateurs de qualité KPIs et « First Pass Yield » (taux de premier passage) ;
• Mise en avant du « Top 10 » des principales étapes de test ayant échoué ;
• Mise en avant du « Top 10 » des tests les plus longs ;
• Analyse des causes à l’origine des défauts « Root Cause Analysis » dit RCA
• Gestion détaillée et analytique des réparations dit RMA ;
• Création d’évènements et alarmes sur scénarii de déclenchement ;
• Explorer rapidement des informations ;
• Personnaliser facilement la vue de votre tableau de bord pour suivre les rendements de production et les indicateurs de qualité en temps réel.

Pour une expertise, une formation, ou pour sous-traiter un développement, n'hésitez pas à faire appel à l'équipe Mesulog. Nous pouvons vous aider à mettre en place un outil pour collecter et analyser vos données de production.

Contacter Mesulog, partenaire VIRINCO du produit WATS Test Data Management

L’équipe Mesulog est fière d’avoir été choisie par Brice Blanc Solutest pour reprendre ses activités. Durant près de 20 ans, Brice Blanc Solutest a proposé des prestations de développement logiciel autour de LabVIEW pour des acteurs évoluant principalement dans les domaines de l'énergie, de la microélectronique et du BTP.

Cette transmission d’activité fait suite à l’engagement de Brice Blanc, vers un nouveau défi professionnel, au sein de la société Hprobe qui développe et produit des équipements permettant de tester les composants magnétiques dans l'industrie du semi-conducteur.

L’objectif de ce passage de relais est avant tout de permettre aux clients de Solutest de continuer à bénéficier d’interlocuteurs de proximité, qualifiés dans le développement sous LabVIEW, pour maintenir ou faire évoluer leurs solutions logicielles, également pour porter de nouveaux projets.

« J’ai pleinement confiance dans les compétences des développeurs de Mesulog. La culture de la certification y est solidement ancrée et Mesulog est partenaire NI depuis 20 ans. Je côtoie l’entreprise depuis mes débuts. J’ai pu mesurer et apprécier leur niveau d’expertise, la rigueur et l’écoute accordée aux clients à travers notamment des projets menés ensemble. L’entreprise fait référence dans notre métier. », souligne Brice Blanc.

« C’est très appréciable d’être reconnu par ses pairs. Je remercie Brice Blanc pour sa confiance. À nous de gagner celle de ses anciens clients. Nous mettons à leur disposition toutes nos compétences en développement logiciel sous LabVIEW/TestStand également notre connaissance des matériels NI, déclare Luc Desruelle, directeur de Mesulog.

Et d’ajouter : « Ils pourront également bénéficier de nos compétences élargies notamment en matière de conception et intégration de banc de tests, issues de notre rapprochement avec l’entreprise Nerys, au sein de Nerys Group, opéré il y a un peu moins de deux ans. »