FR3015723A1 - Procede de production de donnees metier en lien avec untest d'une plurialite de produits, serveur mettant en oeuvre ledit procede, systeme et programmes d'ordinateur associes - Google Patents

Abstract

L'invention concerne un système de production et de traitement de données métier (DM, DMC) en lien avec une campagne de tests d'une pluralité de produits (11, 12, li), au moyen d'un ou de plusieurs équipements de test (21, 2j). Elle concerne notamment la production de données automatiquement consolidées, éventuellement corrigées selon le ou les équipements de test utilisés voire encore selon les produits testés. L'invention permet notamment de produire des données fiables, cohérentes au moyen d'un serveur de production (30) mettant en œuvre un procédé de production de données métier élaborées automatiquement à partir de données brutes de test délivrées par le ou les équipements de test.

Description

Procédé de production de données métier en lien avec un test d'une pluralité de produits, serveur mettant en oeuvre ledit procédé, système et programmes d'ordinateur associés L'invention concerne le domaine de la production et du traitement de données en lien avec une campagne de tests d'une pluralité de produits, au moyen d'un ou de plusieurs équipements de test. Elle concerne notamment la production de données automatiquement consolidées, éventuellement corrigées, selon le ou les équipements de test utilisés voire encore selon les produits testés. L'invention permet notamment de produire des données fiables, cohérentes au moyen d'un serveur de production mettant en oeuvre un ou des procédés particulièrement innovants. L'invention concerne plus particulièrement et de manière non limitative le traitement automatique d'un très grand volume de données de tests produites au cours d'une fabrication en grande série, par exemple la fabrication de multiples lots de nombreux composants électroniques. Les fabricants ou intégrateurs de composants électroniques prévus pour être exploités dans des domaines sensibles tels que les transports routier, ferroviaire ou aérien, les télécommunications ou la défense sont soumis à un haut niveau en matière d'exigence qualité. En outre, il existe ainsi des normes prévues à cet effet en lien avec la traçabilité des produits fabriqués ou intégrés. A titre d'exemple, le comité « Automotive Electronics Council (AEC) selon une terminologie anglo-saxonne » a établi des normes connues sous les appellations AEC-QC001 ou AEC-QC002. Il en est de même pour les comités « Joint Electronic Device Engineering Councils (JEDEC) selon une terminologie anglo-saxonne ». Pour satisfaire aux exigences requises par ces normes, les fabricants de composants électroniques doivent par exemple maîtriser leurs processus de fabrication et de tests de leurs produits. Plus précisément, la maîtrise des flux de données brutes produites en très grand volume par les différents équipements de test au cours de la production des lots de produits est décisive. Ainsi, le nombre de données brutes produites par chaque équipement de test couplé à une grande variété de formats et de contenus selon les équipements de test et les produits testés constitue un frein quasi rédhibitoire à une exploitation pertinente et consolidée de données de test produites par une pluralité d'équipements de test. Il est donc très difficile de réaliser des rapprochements, des comparaisons ou des synthèses des différentes données brutes produites et collectées auprès des différents équipements de test. Une action humaine significative est souvent indispensable pour filtrer ou corriger des données incohérentes ou non pertinentes. Selon l'état de la technique connue, des erreurs conduisant à rejeter des produits propres à la consommation sont nombreuses. Plus grave, des produits présentant des capacités insuffisantes à leur exploitation peuvent être considérés comme valides. Les enjeux et analyses de lots de produits (par exemple des composants électroniques) dont des défauts sont détectés après intégration desdits produits, voire après une mise sur le marché, sont lourds de conséquences sur des plans juridiques et financiers.

Prenons l'exemple d'un processus connu de fabrication et de tests de lots de composants électroniques.

Un tel processus de production est relativement complexe. Il comporte principalement quatre principales 5 étapes : - une étape de fabrication des composants en tant que tels que l'on nomme souvent familièrement puces électroniques ; - une étape de tests sur support desdits 10 composants que l'on nomme « wafer » selon une terminologie anglo-saxonne, un « wafer » constituant ainsi un lot de composants ; - une étape de désolidarisation des différents composants suivie d'une phase d'assemblage 15 desdits composants ainsi séparés sur des modules de connexion ou des boîtiers ; - une étape consistant en un test fonctionnel desdits assemblages. 20 Chaque étape peut être subdivisée en plusieurs sous- étapes. Le nombre de ces sous-étapes est variable et dépend directement des matériaux employés pour constituer les puces et les assemblages ainsi que des fonctions préprogrammées desdites puces. 25 Durant l'étape de fabrication d'une puce électronique présentant plusieurs couches de matériaux actifs, un cycle de tests est réalisé pour chaque couche. Le nombre de couches peut varier de quelques centaines à plusieurs milliers. Des tests de défectivités ont pour objectif de 30 détecter des erreurs de gravure, par exemple une largeur de contacts trop faible ou trop grande, des erreurs d'épaisseur de couche ou encore la présence de particules de poussière. Certains défauts détectés peuvent ne pas avoir d'impact réel sur le fonctionnement nominal de la 35 puce. D'autres peuvent en revanche compromettre son exploitation future. Dans ce dernier cas, il est impératif de rejeter toute puce défectueuse ou présentant un risque de défectuosité. Une puce peut être testée plusieurs fois à différentes températures et à des instants différents. Les tests sont réalisés en exécutant une ou plusieurs séquences de tests délivrant des signaux électriques à chaque puce. Des données brutes sont produites par l'équipement de test relatant des mesures effectuées ou des résultats de séquences de test. Pour tester fonctionnellement ou électriquement une 10 puce, il est généralement nécessaire de disposer de deux équipements de test distincts : - un équipement appelé « prober » selon une terminologie anglo-saxonne apte à manipuler les supports des puces (« wafers » selon une 15 terminologie anglo-saxonne) et à positionner lesdites puces en contact avec une matrice de pointes ou de sondes ; - un équipement appelé testeur mettant en oeuvre un programme ou une séquence de tests pour 20 chaque puce ; cet équipement de test génère et collecte des signaux électriques respectivement adressés à ladite puce ou délivrés par cette dernière. 25 Le « prober » est généralement paramétré selon des caractéristiques structurelles, plus précisément géométriques, des puces à tester. On peut ainsi adapter le positionnement des sondes à la longueur et à la largeur des puces ainsi qu'à l'espacement séparant deux 30 puces voisines. Cet équipement de test définit une première identification des puces au regard d'un référentiel, généralement le centre du « wafer ». Le testeur exécute un ou plusieurs tests électriques sur chaque puce et compare les résultats au regard de 35 données attendues. Cet équipement de test transmet au « prober » une donnée brute caractérisant un résultat de test. Les puces positionnées sur un « wafer » peuvent en outre être testées par un troisième équipement de test 5 chargé de détecter, au moyen d'un ou plusieurs capteurs optiques des défauts de surface, des rayures ou autres défauts de nature à engendrer des défaillances de puces. Cet équipement de test identifie les puces selon un référentiel éventuellement distinct de celui du 10 « prober » ou du testeur et recense les défauts détectés par la production de données brutes de test. Quel que soit l'équipement de test utilisé, celui-ci structure les données brutes de test selon un format spécifique à l'équipement, voire au produit testé, et 15 associe des données de résultat de test à des données d'identification de puce voire d'autres informations en lien avec le test, telles que l'horodatage de la séquence de test, ou les conditions de test, à titre d'exemples non limitatifs la température, l'hydrométrie, etc. Ces 20 données constituent généralement des enregistrements de données brutes, généralement groupés au sein d'un ou plusieurs fichiers de données, et sont mémorisées dans des moyens de mémorisation coopérant avec l'équipement de test. La syntaxe, la teneur et la qualité de données 25 brutes produites pour tester une pluralité de produits sont généralement différentes d'un équipement de test à un autre. Les données d'identification des puces sont également différentes selon l'équipement de test utilisé : identification géométrique pour l'un, 30 identification numérique, par exemple un numéro de série, pour un autre. En effet, pour certains équipements de test tels que le « prober » par exemple, les données générées ne sont pas exactement liées directement à une puce en tant que 35 telle. Les défauts détectés sont associés à des zones géographiques du support des puces. Les mesures physiques sont également représentées par zone géographique. En revanche, pour un équipement de test fonctionnel, des données brutes de résultat de test sont associées à une puce en tant que telle, par exemple le numéro de série de 5 ladite puce, indépendamment de la localisation de la puce sur son support. Il peut donc devenir rapidement peu évident de consolider deux ensembles de données brutes de test pouvant respectivement être hétérogènes en matière de formats, de contenus et d'identification de puces. 10 En l'état des solutions de test, des analyses ou synthèses de test sont partielles et intègrent des données erronées principalement en raison : - de disparités de formats, de teneurs et de 15 complétude des données brutes de test produites par différents équipements de test voire selon les caractéristiques structurelles et fonctionnelles des produits testés ; - d'interprétations multiples et parfois 20 contradictoires de certaines données brutes de test au regard de différentes normes ou exigences conduisant à des niveaux de pertinence de validation disparates et, dans certains cas, à des erreurs de validation ou de 25 rejet indus de produits ; - de l'utilisation éventuelle de différents moyens de mémorisation de données brutes produites, à des instants et dans des lieux distincts ; 30 - du grand volume de données brutes qu'il faut analyser, croiser et consolider nécessitant des ressources humaines et matérielles conséquentes et onéreuses. 35 La présente invention se propose de remédier tout ou partie des inconvénients précités et propose une solution permettant la mise en oeuvre de procédés automatiques de vérification, de correction et de consolidation de données brutes produites par un ou plusieurs équipements de test. La mise en oeuvre de tels procédés permet d'élaborer des données métier selon un format déterminé dont les qualités et pertinences respectives sont décuplées par rapport aux systèmes existants. L'invention permet également de s'affranchir des spécificités des produits testés, des équipements de test employés et de consolider lesdites données métier selon des exigences de fournisseurs, de clients ou de normes. L'invention permet en outre d'offrir une grande souplesse d'adaptation tout en maximisant la rigueur et la qualité des données métier élaborées. Elle répond notamment avec une très grande efficacité aux difficultés soulevées par l'analyse de données brutes produites en très grandes quantités du fait de tests appliqués à des lots de nombreux produits et/ou de très nombreux tests appliqués à des lots de produits, quelle que soit la quantité de produits constituant de tels lots. A cet effet, l'invention concerne tout d'abord un procédé de production de données métier en lien avec un test d'une pluralité de produits. Un tel procédé est prévu pour être mis en oeuvre par des moyens de traitement d'un serveur de production de données métier. Un tel procédé comporte : - une étape pour lire des données brutes préalablement produites par un équipement de test mettant en oeuvre une batterie de tests respectivement sur ladite pluralité de produits, lesdites données brutes étant mémorisées dans des moyens de mémorisation de données brutes coopérant avec ledit serveur de production de données métier, lesdites données brutes consistant en des enregistrements de données brutes respectivement associés aux produits testés, un enregistrement de données brutes comportant des données brutes d'identification de produit et des données brutes de résultat de test ; - une étape pour interpréter lesdites données brutes et produire des données métiers. Pour permettre un traitement automatique et reproductible des données brutes et s'affranchir de 10 spécificités de l'équipement de test, ladite étape pour interpréter des données brutes comporte : - une étape pour décoder un enregistrement de données brutes selon une règle d'interprétation syntaxique propre à l'équipement de test ayant 15 produit lesdites données ; - une étape pour traduire les données brutes d'identification et de résultat de test ainsi décodées en données métier d'identification de produit et de test selon une règle 20 d'interprétation sémantique propre à l'équipement de test ; - une étape pour élaborer un enregistrement de données métier propre au produit testé et mémoriser ledit enregistrement dans des moyens 25 de mémorisation de données métier coopérant avec le serveur de production de données métier. Pour décoder un enregistrement de données brutes selon une règle d'interprétation syntaxique propre à 30 l'équipement de test, ce dernier peut être associé avantageusement à un identificateur dédié. Chaque enregistrement de données brutes peut comporter dès lors ou être associé à la valeur dudit identificateur. L'étape pour décoder peut consister : 35 - à sélectionner, dans des moyens de mémorisation coopérant avec le serveur, selon la valeur de l'identificateur de l'équipement compris dans ledit enregistrement de données brutes ou associé à celui-ci : o un ou plusieurs paramètres spécifiques à l'équipement de test dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de décodage rend ce dernier spécifique à l'équipement de test ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement déclenchent la mise en oeuvre d'un procédé de décodage spécifique à l'équipement de test ; à mettre en oeuvre par les moyens de traitement du serveur le procédé de décodage spécifique à l'équipement de test. De la même manière, en complément ou en variante, l'étape pour traduire les données brutes selon une règle 20 d'interprétation sémantique peut consister : - à sélectionner, dans des moyens de mémorisation coopérant avec le serveur, selon la valeur de l'identificateur de l'équipement compris dans ledit enregistrement de données brutes ou 25 associé à celui-ci : o un ou plusieurs paramètres spécifiques à l'équipement de test dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de traduction 30 rend ce dernier spécifique à l'équipement de test ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement déclenchent la 35 mise en oeuvre d'un procédé de traduction spécifique à l'équipement de test ; - à mettre en oeuvre par les moyens de traitement du serveur le procédé de traduction spécifique à l'équipement de test. Afin de s'affranchir de caractéristiques structurelles ou fonctionnelles des produits à tester et ainsi conserver une grande aptitude à exploiter les données métier élaborées, quels que soient lesdits produits, l'étape pour traduire les données brutes d'identification et de résultat de test en données métier 10 d'identification de produit et de test peut en outre être mise en oeuvre selon une règle d'interprétation sémantique propre aux produits testés. Selon cette variante, l'étape pour traduire les données brutes selon une règle d'interprétation 15 sémantique propre aux produits testés peut avantageusement consister : - à sélectionner, dans des moyens de mémorisation coopérant avec le serveur, selon la valeur d'un paramètre prédéterminé caractérisant la 20 pluralité de produits testés : o un ou plusieurs paramètres spécifiques à l'équipement de test dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de traduction 25 rend ce dernier spécifique aux produits testés ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement déclenchent la 30 mise en oeuvre d'un procédé de traduction spécifique aux produits testés ; - à mettre en oeuvre par les moyens de traitement du serveur le procédé de traduction spécifique aux produits testés. 35 Pour analyser conjointement des données brutes produites par une pluralité d'équipements de test, ces dernières consistant en des premières et deuxièmes données brutes produites respectivement par des premier 5 et deuxième équipements de test distincts, les étapes pour lire et interpréter les données brutes d'un procédé conforme à l'invention peuvent consister à lire et interpréter conjointement ou successivement lesdites premières et deuxièmes données brutes pour produire les 10 données métiers, ces dernières consistant en un agrégat des données métiers produites respectivement à partir des premières et deuxièmes données brutes. L'invention prévoit que l'on puisse consolider les données métier élaborées de sorte à associer à un produit 15 parmi la pluralité à tester des données métiers en lien avec une campagne de test globale. Un tel procédé peut à ce titre comporter en outre une étape pour consolider ledit agrégat et produire des données métiers consolidées, ces dernières consistant en un 20 enregistrement par produit testé comportant des données d'identification du produit et des données de synthèse de test. Pour pouvoir échanger les données métier produites selon l'invention, permettre un traitement de celles-ci 25 éventuellement délocalisé ou préparer une restitution, un procédé selon l'invention peut comporter avantageusement une étape pour encoder les données métiers produites selon un mode de transport et/ou de restitution déterminés. 30 Dans le cas où un serveur mettant en oeuvre un procédé conforme à l'invention comporterait ou coopérerait avec une interface de restitution de type homme-machine, un procédé conforme à l'invention peut comporter une étape pour restituer les données métiers produites via ladite 35 interface.

Selon un deuxième objet, l'invention concerne un serveur de production de données métier en lien avec un test d'une pluralité de produits, lesdites données métiers étant élaborées à partir de données brutes 5 préalablement produites par un équipement de test mettant en oeuvre une batterie de tests respectivement sur ladite pluralité de produits. Un tel serveur comporte des moyens de traitement coopérant avec des moyens de mémorisation. Pour traiter automatiquement et efficacement des données 10 brutes de test, les moyens de traitement dudit serveur sont agencés pour mettre en oeuvre un procédé de production de données métier selon l'invention. Selon un mode de réalisation particulièrement avantageux, un tel serveur de production peut comporter 15 tout ou partie des moyens de mémorisation. Selon un troisième objet, l'invention concerne en outre un système de test d'une pluralité de produits comportant un ou plusieurs équipements de test et un 20 serveur de production de données métier selon l'invention. Pour pouvoir adapter un serveur de production afin qu'il mette en oeuvre un traitement de données de test 25 conforme à l'invention, l'invention selon un quatrième objet concerne en outre un programme d'ordinateur comportant une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par des moyens de traitement d'un tel serveur, déclenchent la 30 mise en oeuvre d'un procédé de production de données métier en lien avec un test d'une pluralité de produits selon l'invention. Pour rendre capable un tel serveur de lire et 35 traduire automatiquement des données brutes de test produites par tout équipement de test voire en lien avec tout produit testé, l'invention selon un cinquième objet concerne en outre un autre programme d'ordinateur comportant une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par des moyens de traitement. du serveur, déclenchent la mise en oeuvre d'un procédé de décodage ou de traduction de données brutes selon une règle d'interprétation syntaxique ou sémantique propre à l'équipement de test ou une pluralité de produits testés.

D'autres caractéristiques et avantages apparaîtront plus clairement à la lecture de la description qui suit, se rapportant à un exemple de réalisation donné à titre indicatif et non limitatif, et à l'examen des figures qui l'accompagnent parmi lesquelles : - la figure 1 décrit un système de test conforme à l'invention comportant une pluralité d'équipements de test pour tester un lot de produits et un serveur de production de données métier élaborées à partir de données brutes délivrées par lesdits équipements de test ; - les figures 2a, 2b et 2c décrivent respectivement des exemples de structures de données brutes délivrées par un équipement de test, de données métier et de données métier consolidées élaborées selon l'invention ; - la figure 3 présente les principales étapes d'un procédé de production de données métier éventuellement consolidées et restituées selon l'invention. La figure 1 présente un système conforme à l'invention permettant de tester un lot 10 de produits, par exemple et de manière non limitative, des composants ou puces électroniques présentes sur un support ou « wafer » selon une terminologie anglo-saxonne.

Un lot 10 comporte une pluralité de produits parmi lesquels les produits 11, 12 et li. Selon le processus de validation et/ou de fabrication illustré en liaison avec la figure 1, le lot 10 est analysé par deux équipements de test distincts, les équipements 21 et 2j. Ces derniers ont pour mission de valider les produits sains et permettre in fine de rejeter les produits défectueux. A l'issue dudit processus de validation et/ou de fabrication, le lot 10 est évalué, c'est-à-dire que les produits défectueux sont notamment clairement identifiés. L'invention ne serait être limitée à ce seul exemple de système de test. On pourrait en variante utiliser un seul équipement de test, par exemple l'équipement 2j, ou en revanche utiliser plus de deux équipements de test. En liaison avec la figure 1, chaque équipement de test met en oeuvre un test ou une batterie de tests sur tout ou partie des produits 11 à li. Les équipements 21 et 2j produisent ainsi respectivement des données brutes de test DB21 et DB2i. Celles-ci sont respectivement mémorisées dans des moyens de mémorisation MB1 et MBj coopérant respectivement avec les équipements de test 21 et 2j. En variante, lesdits moyens de mémorisation pourraient constituer une seule et même entité physique communiquant avec lesdits équipements de test 21 et 2j par exemple via un bus de données. Tout autre mode de communication ou d'interaction entre les équipements de test et lesdits moyens de mémorisation pourraient être envisagés.

Un exemple de données brutes de test DB2j produites par l'équipement 2j est décrit en liaison avec la figure 2a. De telles données consistent en un ou plusieurs enregistrements de données, référencés en figure 2a, 2 2 2 DB11 , DB12 , DBli, lesdits enregistrements formant un ou 2j plusieurs fichiers de test. Les enregistrements DB11' DB12 , DBl2ij , sont associés respectivement aux produits 11, 12 et li. Selon l'exemple non limitatif illustré en figure 2a, un enregistrement de données brutes, par exemple l'enregistrement DBli2j , comporte notamment des données brutes d'identification du produit li testé par l'équipement de test 2j. Ces données d'identification, en l'espèce ID2jli, peuvent consister en des coordonnées « géométriques » du produit li positionné au sein du lot 10 au regard d'un référentiel voire en un numéro de série du produit li, si ledit numéro de série peut être lu par l'équipement de test 2j. Un tel enregistrement peut en outre comporter des données informatives brutes Cd121 décrivant par exemple les conditions de réalisation d'un test appliqué sur le produit li par l'équipement 2j : 15 température environnante, durée du test voire encore un horodatage du test, etc. Un enregistrement In1j correspondant à un test appliqué par l'équipement 2j au produit li comporte des données brutes de résultat T1i dudit test. Ces données brutes de résultat relatent par 20 exemple un code de classification de test, des mesures de certaines caractéristiques du produit li, un temps de réponse dudit produit li à une sollicitation de l'équipement de test 2j, un code d'erreur ou plus généralement toute information découlant dudit test. Un 25 tel enregistrement DBPJ_ peut en outre comporter un identificateur ID2j dédié à l'équipement de test 2j. Il pourrait en complément comporter d'autres données susceptibles de décrire davantage un test appliqué au produit li. En variante, un enregistrement DBli2j peut 30 simplement être associé à des données brutes si ces dernières peuvent être communes à d'autres enregistrements. Ainsi par exemple, l'identificateur de l'équipement de test ID2i, certaines données informatives de test peuvent être factorisées dans un ou plusieurs enregistrements dédiés. Dans ce cas, les enregistrements 2j DB2j DB12, DBll ne sont qu'associés à 11 ces données en lieu et place de comporter celles-ci explicitement. En liaison avec la figure 2a, à l'instar de l'enregistrement DEI2i correspondant à un test appliqué par l'équipement 2j sur le produit li, l'enregistrement DB112j correspondant à un test appliqué par l'équipement 2j sur le produit 11 peut comporter : - l'identificateur ID2i de l'équipement 2j ayant appliqué le test ; des données brutes d'identification DB2j du 11 produit 11 ; - des données informatives brutes Cd2j décrivant 11 par exemple les conditions de réalisation du test ; des données de résultat brutes TI,2j découlant du test décrivant par exemple les conditions de réalisation d'un test appliqué sur le produit 11 par l'équipement 2j. De la même manière, un enregistrement de données brutes DEI22j associé à un test appliqué sur le produit 12 par l'équipement 2j comporte : - l'identificateur ID2j de l'équipement 2j ayant appliqué le test ; - des données brutes d'identification DB122j du produit 12 ; - des données informatives brutes CdP2 décrivant par exemple les conditions de réalisation du test ; - des données de résultat brutes T2j découlant 12 du test décrivant par exemple les conditions de réalisation d'un test appliqué sur le produit 12 par l'équipement 2j. Les données brutes DB21 = {DB1233: D 12, -.-, DB1i} produites par l'équipement 21 pourraient être structurées de manière équivalente ou différente par rapport aux données DB2i = 2j DB122j , , DB3_1} produites par l'équipement 2j en lien avec des tests appliqués sur les produits 11, 12, ..., li du lot 10.

Les données brutes DB = {DB21, . . - , DB2i par les différents équipements de test peuvent être très volumineuses et hétéroclites. Pour pouvoir analyser automatiquement lesdites données et permettre un traitement in fine consolidé de celles-ci, l'invention prévoit, comme l'indique à titre d'exemple préféré la figure 1, un serveur de production de données métiers 30. Un tel serveur de production 30 comporte des moyens de traitement 31, par exemple sous la forme d'au moins un microcontrôleur ou microprocesseur apte à mettre en oeuvre un procédé de production de données métier selon l'invention dont un exemple de description fonctionnelle préféré et non limitatif est illustré en liaison avec la figure 3. Pour cela, le serveur peut comporter ou coopérer avec des moyens de mémorisation MR comportant de manière avantageuse un programme d'ordinateur préalablement inscrit ou téléchargé au sein desdits moyens de mémorisation MR. Un tel programme comporte alors avantageusement une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par les moyens de traitement 31 du serveur 30, déclenchent la mise en oeuvre d'un procédé de production de données métier tel que décrit ultérieurement en liaison avec la figure 3. En variante, l'unité de traitement peut être préprogrammée pour mettre en oeuvre un tel traitement voire mettre en oeuvre une logique câblée dédiée à cet effet.

Pour produire des données métier, dont un exemple est décrit en liaison avec la figure 2b, le serveur 30 est adapté pour coopérer avec des moyens de mémorisation stockant les données brutes produites par les équipements de test. A titre d'exemple, ledit serveur 30 peut accéder en lecture aux moyens de mémorisation MB1 et MBj au travers d'un réseau de communication Rl. Il peut en variante coopérer ou comporter des moyens de mémorisation comportant une copie des dites données brutes DB = {DB211. }DB2i . Le serveur 30 comporte en outre des moyens de mémorisation MM ou, en variante, il coopère avec de tels moyens par communication filaire ou sans fil, ces derniers étant distants, pour mémoriser des données métier DM voire des données métier consolidées DMC élaborées par l'unité 31 à partir des données brutes de test DB. Ces données peuvent faire l'objet d'une restitution à un utilisateur ou superviseur U au moyen d'une interface homme-machine adaptée 32 intégrée ou distante au serveur et en communication avec ledit serveur. L'invention prévoit en outre qu'un tel utilisateur puisse transmettre aux moyens de traitement 31 du serveur 30 un ou plusieurs paramètres P via ladite interface 32. Un paramètre P peut être exploité par lesdits moyens pour adapter le procédé de production de données métier.

Les données métiers produites DM ou DMC peuvent en outre faire l'objet d'un traitement subséquent par le serveur 30 ou par une entité distante 40. Pour cela, lesdites données métiers peuvent faire l'objet d'un encodage mis en oeuvre par les moyens de traitement 31 préalablement à une transmission, par exemple au travers d'un réseau de communication R2, avantageusement mais non limitativement un réseau Internet ou Intranet. L'encodage peut notamment comporter une phase de signature voire de chiffrement pour en garantir la confidentialité, l'intégrité et la provenance selon toute technologie connue et adaptée à cet usage. Un exemple de données métier produites par un serveur 30 adapté selon l'invention est décrit en liaison avec la figure 2b. Examinons la teneur de ces données à la 10 lumière du procédé de production 100 illustré par la figure 3. Au sens de l'invention, une donnée métier est une donnée apte à être interprétée directement par un système de traitement ou un utilisateur via une interface de restitution. Elle se distingue d'une donnée brute qui 15 relate des résultats sous la forme de mesures ou de codes propres à un équipement ou un produit. Une donnée métier apporte naturellement un niveau d'abstraction rendant son exploitation indépendante des spécificités techniques d'un équipement ou d'un produit. Elle traduit 20 généralement une information fonctionnelle. Les données métier sont en outre formatées et constituées de manière homogène et déterminée. Deux données métier distinctes issues de données brutes délivrées respectivement par deux équipements de test distincts peuvent ainsi être 25 facilement rapprochées, comparées, synthétisées. Bien qu'une donnée métier se traduise avantageusement en une donnée structurée ou composite comportant plusieurs champs ou composantes, une donnée métier peut être le fruit d'une fusion de plusieurs données brutes voire d'un 30 calcul basé sur une pluralité de données brutes distinctes. Un tel calcul ou plus généralement une interprétation de données brutes permet de corriger voire d'ignorer des données brutes jugées incohérentes ou contradictoires. De tels correctifs traduits sous la 35 forme de données métier permettent de conserver les données brutes inchangées.

A titre d'exemple non limitatif, la figure 2b présente un exemple de données métier DM = {De e 2j 1P D 12, - ' DM12ii} en lien avec des tests réalisés par l'équipement de test 2j décrit en liaison avec la 5 figure 1. Ces données métier consistent en un ensemble nm2i nm2i nm2i d'enregistrements 1-'1:-`11f "12f - - - respectivement associés aux différents produits 11, 12, ..., li testés par l'équipement de test 2j. Prenons l'exemple particulier de l'enregistrement DM112j en lien avec un test appliqué par 10 l'équipement 2j sur le produit 11 du lot 10. Avantageusement un tel enregistrement peut comporter ou être associé à l'identificateur ID2j de l'équipement de test 2j. Il comporte en outre des données d'identification IDt112j du produit concerné par le test. 15 Ces données peuvent être identiques aux données brutes d'identification ID2j produites par l'équipement 2j. 11 Elles sont avantageusement déduites de celles-ci pour être rapprochées d'autres données métier portant sur un même produit testé par un deuxième équipement de test. De 20 la même manière toutes ou parties des données informatives brutes sont traduites sous la forme de données métier ITj décrivant selon un format et un 11 contenu déterminés les données métiers décrivant le contexte du test. L'enregistrement DEjl_ comporte en outre 25 des données Tt2j traduisant les données brutes de 11 résultat de test T en un résultat selon un format 11 déterminé éventuellement après corrections. De la même manière les données métiers DMi22 propres au produit 12 testé par l'équipement 2j comportent ou 30 sont associés à l'identificateur ID2j de l'équipement de test, à un identificateur de produit IDt122j , des données 2j informatives traduites II'12 et des données métier de résultat Tt12. A leur tour, les données métiers DM11 portant sur le produit li testé par l'équipement 2j comportent ou sont associées à l'identificateur ID2i de l'équipement de test, à un identificateur de produit IDt122j ' des données informatives traduites IT/2 et des données métier de résultat Tt 2. Pour parvenir à élaborer de telles données métier DM = {DM un serveur de production de données métier tel que le serveur 30 décrit en liaison avec la figure 1 met en oeuvre un procédé de production de données métier 100 tel qu'illustré par la figure 3. Un tel procédé 100 comporte une première étape 110 pour lire au sein de moyens de mémorisation MB1, MBj des données brutes DB = {DB21,...,DB2i} préalablement produites par des équipements de test 2j. De telles données peuvent être conformes à celles décrites en liaison avec la figure 2a. Le procédé 100 comporte en outre une étape 120 pour 20 interpréter lesdites données brutes DB et produire des données métiers DM. L'interprétation 120 des données brutes comprend une première étape 121 pour décoder un ou plusieurs enregistrements de données brutes, par exemple 252j l'enregistrement DB11 en lien avec les données brutes de test produites par l'équipement 2j. Le format, la teneur desdites données brutes étant dépendants de l'équipement de test, l'invention prévoit que ladite étape 121 pour décoder soit mise en oeuvre par les moyens de traitement 30 31 du serveur 30 selon une règle d'interprétation syntaxique propre à l'équipement de test ayant produit lesdites données brutes. En l'espèce, le décodage des données brutes DB2i est réalisé selon une règle syntaxique RD2j propre à l'équipement 2j. L'invention prévoit pour cela que lesdits moyens de 5 traitement 31 mettent en oeuvre un procédé de décodage adapté voire dédié à un équipement de test en particulier, par exemple l'équipement de test 2j décrit en liaison avec la figure 1 et dont les données brutes de test qu'il produit sont décrites à titre d'exemple non 10 limitatif par la figure 2a. Selon un premier mode de réalisation, un tel procédé de décodage dédié peut résulter d'un procédé de décodage commun ou déterminé auquel les moyens de traitement appliquent un ou plusieurs paramètres spécifiques 15 caractérisant ledit équipement de test. De tels paramètres peuvent à titre d'exemple non limitatif identifier l'ordre relatif et/ou la position des éléments d'un enregistrement de données brutes lorsque celui-ci est produit par l'équipement de test. De tels paramètres 20 peuvent avantageusement consister en une ou plusieurs règles ou prédicats exploitables par un moteur d'inférence mis en oeuvre par les moyens de traitement du serveur. Le ou les paramètres sont alors préalablement 25 mémorisés dans des moyens de mémorisation, par exemple les moyens MR décrits en liaison avec la figure 1, lesdits moyens coopérant avec le serveur de production de données métier. Pour adapter le décodage à l'équipement de test 2j, 30 après avoir lu en 110 des données brutes DB2i produites dont un enregistrement parmi DB11, DB12 ou DBli2j , l'étape 121 peut consister dès lors à sélectionner dans les moyens de mémorisation coopérant avec le serveur, en fonction de la valeur de l'identificateur ID2j de 35 l'équipement 2j contenue dans ledit enregistrement de données brutes ou associée à celui-ci, le ou les paramètres spécifiques à l'équipement de test 2j. A l'issue de la sélection du ou des paramètres idoines, l'étape 121 comporte la mise en oeuvre du procédé 5 de décodage ainsi adapté à l'équipement de test 2j pour produire des donnés brutes décodées DBd. Selon un deuxième mode de réalisation, l'étape 121 peut consister en la sélection d'un ensemble d'instructions de programme dont l'exécution ou 10 l'interprétation par les moyens de traitement 31 du serveur 30 déclenchent la mise en oeuvre d'un procédé de décodage spécifique à l'équipement de test 2j. Un tel ensemble d'instructions peut, à l'instar des paramètres évoqués précédemment, être préalablement mémorisé ou 15 téléchargé dans des moyens de mémorisation, par exemple les moyens MR décrits en liaison avec la figure 1, coopérant ou compris avec les moyens de traitement du serveur de production de données métier. A l'issue de la sélection de l'ensemble d'instructions de programme 20 idoines, l'étape 121 comporte la mise en oeuvre du procédé de décodage ainsi adapté à l'équipement de test 2j pour produire des donnés brutes décodées DBd. L'étape 120 d'interprétation des données brutes 25 comprend en outre une étape 122 pour traduire lesdites données brutes décodées DBd en données métier Dm. Au même titre que pour l'étape de décodage 121, l'étape 122 pour traduire les données DBd en données métier Dm peut être réalisée par les moyens de traitement 30 du serveur selon une règle d'interprétation sémantique propre à l'équipement de test ayant produit des données brutes décodés. A titre d'exemple, ladite traduction des données brutes produites par l'équipement de test 2j est basée sur une règle RS2 dédiée à l'équipement 2j. Une 35 telle règle permet de générer des données métier dont la structure, l'organisation et la teneur sont homogènes que les données brutes décodées émanent de l'équipement 2j ou d'un autre équipement de test. Tout comme pour la mise en oeuvre d'une règle de décodage, l'étape pour traduire 122 les données brutes DBd selon une règle d'interprétation sémantique propre à un équipement de test peut résulter de la mise en oeuvre d'un procédé de traduction commun ou déterminé auquel les moyens de traitement appliquent un ou plusieurs paramètres spécifiques caractérisant ledit équipement de test. De tels paramètres peuvent à titre d'exemple non limitatif spécifier les opérations correctives ou d'enrichissement à appliquer sur une ou plusieurs données brutes. On peut par exemple élaborer selon un tel paramétrage des données métier d'identification du produit testé ou de résultat traduisant un code de test en lieu et place de mesures brutes par exemple. De tels paramètres peuvent avantageusement consister en une ou plusieurs règles ou prédicats exploitables par un moteur d'inférence mis en oeuvre par les moyens de traitement du serveur. Le ou les paramètres sont alors préalablement mémorisés dans des moyens de mémorisation, par exemple les moyens MR décrits en liaison avec la figure 1, lesdits moyens coopérant avec le serveur de production de données métier. Pour adapter la traduction de données brutes préalablement décodées en 121 produites par l'équipement de test 21, l'étape 122 peut consister dès lors à sélectionner dans les moyens de mémorisation coopérant avec le serveur, en fonction de la valeur de l'identificateur ID21 de l'équipement 21 contenue dans un enregistrement de données brutes ou associée à celui-ci, le ou les paramètres spécifiques à l'équipement de test 21.

A l'issue de la sélection du ou des paramètres idoines, l'étape 122 comporte la mise en oeuvre du procédé de traduction ainsi adapté à l'équipement de test 21 pour produire des donnés métier Dm. Selon un deuxième mode de réalisation, l'étape 122 peut consister en la sélection d'un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement 31 du serveur 30 déclenchent la mise en oeuvre d'un procédé de traduction spécifique à l'équipement de test 2j. Un tel ensemble d'instructions peut, à l'instar des paramètres évoqués précédemment, être préalablement mémorisé ou téléchargé dans des moyens de mémorisation, par exemple les moyens MR décrits en liaison avec la figure 1, coopérant ou compris avec les moyens de traitement du serveur de production de données métier. A l'issue de la sélection de l'ensemble d'instructions de programme idoines, l'étape 122 comporte la mise en oeuvre du procédé de traduction ainsi adapté à l'équipement de test 2j pour traduire des donnés brutes décodées DBd en données métier Dm.

L'étape 122 pour traduire des données brutes DBd en données métier Dm, les données étant par exemple d'identification de produit et/ou de test, peut en outre ou en variante être mise en oeuvre selon une règle d'interprétation sémantique propre aux produits testés. En effet, les fonctions d'un produit que l'on peut tester avec un équipement de test dépendent des fonctions disponibles par ledit produit. L'exploitation d'une règle sémantique dédiée à un produit permet également de s'affranchir automatiquement de certaines caractéristiques fonctionnelles voire structurelles d'un produit au regard d'un autre. En outre, l'étape 122 peut exploiter une règle sémantique dédiée à un contexte de test permettant éventuellement d'enrichir ou de modifier la teneur de certaines données brutes de test lors de leur traduction pour produire des données métier tenant compte dudit contexte de test. Pour mettre en oeuvre une telle variante, l'étape 122 du procédé 100 pour traduire des données brutes DBd selon une règle d'interprétation sémantique propre à un produit testé, tel que le produit 5 11, 12 ou li du lot 10 décrit en liaison avec la figure 1, voire à un contexte de test, peut consister : - à sélectionner, dans des moyens de mémorisation coopérant avec le serveur et plus précisément avec les moyens de traitement dudit serveur, 10 selon la valeur d'un paramètre prédéterminé et éventuellement communiqué audit serveur via une interface homme-machine adaptée, comme par exemple le paramètre P établi via l'interface 32 décrite en figure 1, caractérisant la 15 pluralité de produits testés (par exemple les produits 11, 12, ..., li décrits en liaison avec la figure 1) ou un contexte de test : o un ou plusieurs paramètres spécifiques aux produits testés ou audit contexte dont 20 l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de traduction rend ce dernier spécifique aux produits testés ou au contexte de test ; 25 o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement du serveur déclenchent la mise en oeuvre d'un procédé de traduction spécifique aux produits 30 testés ou au contexte de test ; - à mettre en oeuvre par lesdits moyens de traitement du serveur le procédé de traduction spécifique aux produits testés ou au contexte de test. 35 L'étape d'interprétation 120 d'un procédé de production 100 de données métier selon l'invention permet ainsi de traduire automatiquement les données brutes de test produites par un équipement test selon des règles 5 syntaxiques et sémantiques propres audit équipement de test, aux produits testés ou à un contexte de test. Dans le cas où les données brutes de test DB sont produites par une pluralité d'équipements de test, par exemple les équipements de test 21 et 2j décrits en liaison avec la 10 figure 1, les données brutes DB consistent en des premières et deuxièmes données brutes DB21 et DB2i produites respectivement par des premier et deuxième équipements de test distincts, par exemple respectivement les équipements de test 21 et 2j décrits en liaison avec 15 la figure 1. Dans ce cas, les étapes pour lire 110 et interpréter 120 les données brutes DB = {DB21, DB2j} consistent à lire et interpréter conjointement ou successivement lesdites premières et deuxièmes données brutes DB21 et DB2i pour 20 produire les données métiers Dm, ces dernières consistant en un agrégat des données métiers produites respectivement à partir des premières et deuxièmes données brutes de test. 25 Dans tous les cas, l'étape d'interprétation 120 comporte une étape 123 pour élaborer, formater, structurer les données Dm produites en 122 selon un format et/ou une structure déterminés. Les données métier DM sont ainsi élaborées et inscrites au sein de moyens de 30 mémorisation, tels les moyens MM décrit en liaison avec la figure 1, coopérant avec les moyens de traitement du serveur mettant en oeuvre le procédé de production selon l'invention. Dans le derniers cas, si les données brutes sont composites c'est-à-dire produite par plusieurs équipement de test, par exemple DB = {DB21' DB23' 1 les données métier DM élaborées en 123 sont également composites, soit DM =DM21'DM[2j}* { De telles données métier sont avantageusement structurées en tant qu'agrégat d'enregistrements tels que ceux décrits précédemment en liaison avec la figure 2b. Chaque enregistrement de données métier est alors homogène au regard de ses pairs. Ils sont chacun associés à un test d'un produit réalisé par un équipement de test.

L'invention prévoit de réaliser automatiquement des rapprochements de données métier ainsi produites en 120 ou plus généralement de consolider lesdites données métiers en lien avec un produit particulier durant un processus de fabrication ou validation. Cette étape optionnelle 130 peut être avantageusement mise en oeuvre lorsqu'une pluralité de tests a été effectuée sur un même produit par un même équipement de test ou si plusieurs tests ont été respectivement réalisés sur ledit produit par une pluralité d'équipements de test. On obtient ainsi des données métier consolidées DMC dont chaque enregistrement est associé à un produit testé, qui synthétisent les tests opérés sur ledit produit. Un exemple de données métier consolidées DMC est décrit à titre d'exemple non limitatif en liaison avec la figure 2c. Selon cet exemple, les produits 11, 12 et li d'un lot ont été testés par un ou plusieurs équipements de test. Les données métier consolidées DMC comportent ainsi un enregistrement DMCil associé au produit ll, un enregistrement DMC12 associé au produit 12 et un enregistrement DMCii associé au produit li. Respectivement lesdits enregistrements DMC11, DMC12 et DMCii comportent des données métier d'identification d'un produit testé et des données métier de synthèse de test appliqué audit produit. Ainsi l'enregistrement DMC11 associé au produit 11, comporte une donnée d'identification ID11 du produit 11 5 et des données de synthèse de test TR11. Le nouvel identificateur 'Di, peut être identique à des données d'identification du produit comprises dans des données métier associées au produit en lien avec un test réalisé par un équipement particulier, par exemple les données 10 d'identification du produit 11 suivant l'équipement de test 2j. L'identificateur ID11 peut découler en variante d'un calcul ou d'une conversion. Il en est de même pour les données métier consolidées de synthèse de test TR11- Celles-ci peuvent simplement résulter de la concaténation 15 de données résultat de tests réalisés par une pluralité d'équipement de test ou en variante d'une résultante de ces derniers. Ainsi par exemple, un échec d'un test réalisé par un équipement peut suffire à rejeter un produit. L'échec s'impose aux succès rencontrés durant la 20 réalisation d'autres tests éventuellement par d'autres équipements de test. L'enregistrement DMC11 peut en outre comporter des données métiers consolidées ITc11 traduisant des conditions ou plus généralement des données informatives en lien avec la synthèse des tests 25 réalisés. Il en est de même pour l'enregistrement DMC12 associé au produit 12 qui comporte des données métier consolidées d'identification ID12 dudit produit, des données de synthèse de test TR12 voire des données informatives 30 ITc12. De la même manière, l'enregistrement DMCii associé au produit li comporte avantageusement des données métier consolidées d'identification 'Du_ dudit produit, des données de synthèse de test TRii voire des données informatives. Pour élaborer automatiquement des données métier consolidées, l'étape 130 peut, à l'instar des étapes de 5 décodage 121 et de traduction 122 détaillées précédemment, consister à mettre en oeuvre un procédé de consolidation des données métier DM selon une ou plusieurs règles Rc de consolidation déterminées. Le choix de ladite règle peut avantageusement découler de 10 l'interprétation par les moyens de traitement du serveur de production d'un paramètre utilisateur P transmis depuis une interface homme-machine adaptée à cet effet. Ledit paramètre P peut caractériser avantageusement des exigences d'une unité de production, de fournisseurs, de 15 clients ou de normes. La consolidation opérée par les moyens de traitement du serveur à l'étape 130 peut consister : - à sélectionner, dans des moyens de mémorisation coopérant avec le serveur (par exemple les 20 moyens MR décrits en liaison avec la figure 1), selon la valeur du paramètre utilisateur P caractérisant un mode de consolidation déterminé : o un ou plusieurs paramètres spécifiques 25 audit mode de consolidation dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de consolidation rend ce dernier conforme aux attentes en lien avec la 30 teneur du paramètre utilisateur P ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement du serveur déclenchent la mise en oeuvre d'un procédé 35 de consolidation conforme aux attentes en lien avec la teneur du paramètre utilisateur P ; à mettre en oeuvre par lesdits moyens de traitement du serveur le procédé de consolidation ainsi adapté. Le ou les paramètres spécifiques à un mode de consolidation déterminé peuvent avantageusement consister en une ou plusieurs règles ou prédicats exploitables par un moteur d'inférence mis en oeuvre par les moyens de traitement du serveur pour mettre en oeuvre l'étape de consolidation des données métier 130. Comme l'indique la figure 1 décrivant un mode de réalisation préféré d'un système de test conforme à l'invention, les données métier DM élaborées à l'étape 120 ou encore des données métier éventuellement consolidées à l'étape 130 peuvent être restituées à un utilisateur U chargé de superviser le processus via une interface homme-machine adaptée 32. Cette interface peut être directement disponible via le serveur 30 ou être distante de ce dernier. Selon un mode de restitution choisi, les données DM ou DMC peuvent être avantageusement formatées ou encodées selon ledit mode de restitution attendu.

A ce titre, un procédé 100 de production de données métier conforme à l'invention peut comporter avantageusement une étape 140 pour encoder lesdites données métiers DM ou DMC selon un mode de restitution déterminé.

De la même manière, les données métier produites selon l'invention peuvent faire l'objet d'un traitement subséquent 150 par le serveur de production ou par une entité tierce distante, à des fins par exemple de contre expertises ou d'analyses approfondies. En liaison avec la figure 1, une telle entité distante 40 peut coopérer avec le serveur de production 30 via un réseau de communication R2, tel qu'un réseau Internet, Intranet, etc. En variante, ladite entité 40 peut ne pas être en communication avec le serveur 30. Les données DM ou DMC doivent alors être véhiculées sur un support adéquat. Quelles que soient les modalités du traitement subséquent 150, préalablement à l'exportation des données métier produites conformément à l'invention, l'étape 140 d'un procédé 100 selon l'invention décrit à titre d'exemple en liaison avec la figure 3 peut encoder lesdites données métiers DM ou DMC selon un mode de transport déterminé. Avantageusement, l'étape 140 peut comporter la mise en oeuvre d'un procédé de signature des données DM ou DMC à l'aide d'une clé privée et dédiée au serveur de production pour en garantir l'intégrité et la provenance. L'étape 140 peut en outre déclencher un chiffrement desdites données pour en garantir la confidentialité. Un tel chiffrement peut être réalisé à l'aide d'une clé publique propre à l'identité tierce 40. De cette manière, cette dernière peut vérifier la signature des données DM et DMC à l'aide d'une clé publique propre au serveur de production, voire déchiffrer lesdites données métier à l'aide d'une clé privée de ladite entité, seule à même de pouvoir accéder à la teneur des données métiers exportées. Toute technologie connue et adaptée à encoder les données pourrait en variante ou en complément être mise en oeuvre à l'étape 140 par les moyens de traitement du serveur de production.

Un serveur 30 conforme à l'invention exploité au sein d'un système de test d'une pluralité de produits par un ou plusieurs équipements de test 21, 2j tel que celui décrit en liaison avec la figure 1, peut être adapté voire mis à jour pour mettre en oeuvre un mode de réalisation particulier d'un procédé de production de données métier 100 décrit en liaison avec la figure 3. Pour cela, comme exprimé précédemment, l'invention prévoit que puissent être téléchargés ou mémorisés au sein de moyens de mémorisation (par exemple les moyens MR) coopérant avec les moyens de traitement 31 du serveur 30 un ou plusieurs programmes d'ordinateur consistant en une ou plusieurs instructions de programme interprétables ou exécutables par lesdits moyens de traitement, dont l'interprétation ou l'exécution déclenchent la mise en oeuvre d'un procédé de production de données métier selon l'invention. Un tel programme d'ordinateur peut en outre comporter une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par les moyens de traitement 31 du serveur 30, déclenchent la mise en oeuvre d'un procédé de décodage 121 ou de traduction 122 de données brutes selon une règle d'interprétation syntaxique RD2j ou sémantique RS2j propre à un équipement de test (par exemple l'équipement 2j) ou à une pluralité de produits testés tels que les produits 11, 12, li. Un tel programme peut en outre comporter une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par les moyens de traitement 31 du serveur 30, déclenchent la mise en oeuvre d'un mode de consolidation 130 conforme à l'invention.

Claims (14)

1. REVENDICATIONS1. Procédé (100) de production de données métier (DM, DMC) en lien avec un test d'une pluralité de produits (11, 12, li), ledit procédé étant mis en oeuvre par des moyens de traitement (31) d'un serveur de production (30) de données métier, ledit procédé comportant : - une étape pour lire (110) des données brutes (DB21f DB2j) préalablement produites par un équipement de test (21, 2j) mettant en oeuvre une batterie de tests respectivement sur ladite pluralité de produits (11, 12, li), lesdites données brutes (DB) étant mémorisées dans des moyens de mémorisation de données brutes (MB1, MBj) coopérant avec ledit serveur de production (30) de données métier, lesdites données brutes (DB) consistant en des enregistrements (DB112j , DB122j , DB,i2j ) de données brutes respectivement associés aux produits testés (11, 12, li), un 202j enregistrement (DBli) de données brutes comportant des données brutes d'identification (ID121) de produit et des données brutes de résultat de test (7î*J.j») ; - une étape pour interpréter (120) lesdites 25 données brutes (DB) et produire des données métiers (DM) ; ledit procédé (100) étant caractérisé en ce que l'étape pour interpréter (120) des données brutes comporte :- une étape pour décoder (121) un enregistrement (DB112j ' DB122j ' DBli2j ) de données brutes selon une règle d'interprétation syntaxique (RD2i) propre à l'équipement de test (2j) ayant produit lesdites données (DB2j), - une étape pour traduire (122) les données brutes d'identification et de résultat de test ainsi décodées (DBd) en données métier (Dm) d'identification de produit et de test selon une règle d'interprétation sémantique (RS2j) propre à l'équipement de test (2j), - une étape pour élaborer (123) un enregistrement de données métier (DM11, 2 DM].j) propre au produit testé (11, 12, li) et mémoriser ledit enregistrement dans des moyens de mémorisation de données métier (MM) coopérant avec le serveur de production (30) de données métier (DM).
2. 2. Procédé selon la revendication 1, l'équipement de test (2j) étant associé à un identificateur dédié (ID2i), chaque enregistrement de données brutes j (DB121j , DB122j ' DBl2i) la valeur dudit comportant ou étant associé à identificateur, pour lequel l'étape pour décoder (121) un enregistrement de données brutes selon une règle d'interprétation syntaxique (RD2i) propre à l'équipement de test (2j) ayant produit lesdites données brutes (DB2i) consiste : - à sélectionner, dans des moyens de mémorisation (MR) coopérant avec le serveur (30), selon lavaleur de l'identificateur (ID21) de l'équipement (2j) compris dans ledit enregistrement de données brutes (DBn, DBM, DEi2j .) ou associé à celui-ci : n o un ou plusieurs paramètres spécifiques à l'équipement de test (2j) dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de décodage rend ce dernier spécifique à l'équipement de test (2j) ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement (31) déclenchent la mise en oeuvre d'un procédé de décodage spécifique à l'équipement de test (2j) ; - à mettre en oeuvre par les moyens de traitement (31) du serveur (30) le procédé de décodage spécifique à l'équipement de test (2j).
3. 3. Procédé selon les revendications 1 ou 2, l'équipement de test (2j) étant associé à un identificateur dédié (ID2j), chaque enregistrement de données brutes (DBn, DB12, D1311) comportant ou étant associé à la valeur dudit identificateur, pour lequel l'étape pour traduire (122) les données brutes selon une règle d'interprétation sémantique (RS2j) propre à l'équipement de test (2j) ayant produit lesdites données brutes (DB2i) consiste : - à sélectionner, dans des moyens de mémorisation (MR) coopérant avec le serveur (30), selon la valeur de l'identificateur (ID2i) del'équipement (2j) compris dans ledit enregistrement de données brutes (DB211, De 12 ' DBi2ij ) ou associé à celui-ci : o un ou plusieurs paramètres spécifiques à l'équipement de test (2j) dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de traduction rend ce dernier spécifique à l'équipement de test (2j) ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement (31) déclenchent la mise en oeuvre d'un procédé de traduction spécifique à l'équipement de test (2j) ; à mettre en oeuvre par les moyens de traitement (31) du serveur (30) le procédé de traduction spécifique à l'équipement de test (2j).
4. 4. Procédé selon l'une quelconque des revendications précédentes, pour lequel l'étape pour traduire (122) les données brutes (DBd) d'identification et de résultat de test en données métier (Dm) d'identification de produit et de test est en outre mise en oeuvre selon une règle d'interprétation sémantique propre aux produits testés.
5. 5. Procédé selon la revendication 4, pour lequel l'étape pour traduire (122) les données brutes (DBd) selon une règle d'interprétation sémantique propre aux produits testés (11, 12, li) consiste :à sélectionner, dans des moyens de mémorisation (MR) coopérant avec le serveur (30), selon la valeur d'un paramètre prédéterminé (P) caractérisant la pluralité. de produits testés (11, 12, li) : o un ou plusieurs paramètres spécifiques à l'équipement de test (2j) dont l'exploitation par les moyens de traitement durant la mise en oeuvre d'un procédé de traduction rend ce dernier spécifique aux produits testés (11, 12, 1i) ; o un ensemble d'instructions de programme dont l'exécution ou l'interprétation par les moyens de traitement (31) déclenchent la mise en oeuvre d'un procédé de traduction spécifique aux produits testés (11, 12, li) ; - à mettre en oeuvre par les moyens de traitement (31) du serveur (30) le procédé de traduction spécifique aux produits testés (11, 12, li).
6. 6. Procédé selon l'une quelconque de revendications précédentes, pour lequel les données brutes (DB) consistent en des premières (DB21) et deuxièmes (DB2i) données brutes produites respectivement par des premier (21) et deuxième (2j) équipements de test distincts, et pour lequel les étapes pour lire (110) et interpréter (120) les données brutes consistent à lire et interpréter conjointement ou successivement lesdites premières et deuxièmes données brutes (DB21, DB2j) pour produire les données métiers, ces dernières consistant en unagrégat (DM) des données métiers produites (DM21, DM2i) respectivement à partir des premières et deuxièmes données brutes.
7. 7. Procédé selon la revendication précédente, comportant une étape pour consolider (130) ledit agrégat (DM) et produire des données métiers consolidées (DMC), ces dernières consistant en un enregistrement (DMC11, DMC12, DMC11) par produit testé (11, 12, 1i) comportant des données d'identification (ID11) du produit et des données de synthèse de test (TR11).
8. 8. Procédé selon l'une quelconque des revendications précédentes, comportant une étape pour encoder (140) les données métiers produites (DM, DMC) selon un mode de transport et/ou de restitution déterminés.
9. 9 Procédé selon l'une quelconque des revendications précédentes, ledit serveur (30) comportant ou coopérant avec une interface homme-machine (32) et comportant une étape pour restituer (160) les données métiers produites (DM, DMC) via ladite interface (32).
10. 10. Procédé selon l'une quelconque des revendications précédentes, comportant une étape pour traiter (150) les données métiers produites (DM, DMC).
11. 11. Serveur de production (30) de données métier (DM, DMC) en lien avec un test d'une pluralité deproduits (11, 12, li), lesdites données métiers étant élaborées à partir de données brutes (DB) préalablement produites par un équipement de test (21, 2j) mettant en oeuvre une batterie de tests respectivement sur ladite pluralité de produits, ledit serveur (30) comportant des moyens de traitement (31) coopérant avec des moyens de mémorisation (MB1, Mbj, MR, MM), caractérisé en ce que les moyens de traitement dudit serveur sont agencés pour mettre en oeuvre un procédé de production de données métier selon l'une quelconque des revendications 1 à 10.
12. 12. Serveur de production (30) selon la revendication précédente, comportant tout ou partie des moyens de mémorisation (MB1, Mbj, MR, MM) coopérant avec les moyens de traitement (31).
13. 13. Système de test d'une pluralité de produits (11, 12, li) comportant un ou plusieurs équipements de test (21, 2j) et un serveur (30) selon les revendications 11 ou 12.
14. 14. Programme d'ordinateur comportant une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par des moyens de traitement (31) d'un serveur (30) conforme aux revendications 11 ou 12, déclenchent la mise en oeuvre d'un procédé de production (100) de données métier en lien avec un test d'une pluralité de produits selon l'une quelconque des revendications 1 à 10.15. Programme d'ordinateur comportant une ou plusieurs instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par des moyens de traitement (31) d'un serveur (30) conforme aux revendications 11 ou 12, déclenchent la mise en oeuvre d'un procédé de décodage (121) ou de traduction (122) de données brutes selon une règle d'interprétation syntaxique (RD2j) ou sémantique (RS2j) propre à un équipement de test (2j) ou une pluralité de produits testés (11, 12, 1i).