PROCEDE DE REALISATION D'UN OUTIL UNIVERSEL PERENNE DE DEVELOPPEMENT DE TESTS D'EQUIPEMENTS ET OUTIL DE MISE EN

OEUVRE

La présente invention se rapporte à un procédé de réalisation d'un outil universel pérenne de développement de tests d'équipements ainsi qu'à un outil de mise en œuvre de ce procédé.

Le développement d'un banc de test, s'apparente au développement d'un système opérationnel avec ses contraintes, ses problématiques d'obsolescences, ses exigences de traçabilité et de ré-utilisation.

Aujourd'hui, le développement d'un programme de test se fait sans exigence de lien entre la spécification de test et le code

Cette absence de lien est à l'origine de surcoûts que le client final ne peut plus supporter aujourd'hui: - lors du développement des programmes de test (lourdeur des itérations successives spécification / documentation / code),

- lors du maintien en condition opérationnel de ces programmes (correction logicielle, ré -utilisation, capitalisation amont / aval) et plus globalement lors du maintien en condition opérationnelle du banc de test (obsolescence matérielle provoquant des évolutions de spécifications et donc de la chaîne complète).

- d'autre part, tout traitement d' obsolescence (tant pour le logiciel que pour le matériel) associé à un manque de capitalisation, génère des coûts non justifiables aujourd'hui.

La présente invention a pour objet un procédé de réalisation d'un banc de test permettant le développement d'un programme de test au coût le plus faible possible. Elle a également pour objet un banc de test réalisé selon ce procédé.

Le procédé conforme à l'invention est un procédé de réalisation d'un outil universel pérenne de développement de programmes de tests d'équipements à l'aide d'un banc de test, et il est caractérisé en ce qu'il comporte les étapes suivantes,

mises en œuvre avec un outil de développement de tests comportant un calculateur, des moyens de saisie d'informations et de visualisation et au moins une mémoire : un opérateur conçoit les différentes tâches et sous-tâches du programme de test sur un banc de test que l'outil mémorise, - il saisit les spécifications des exigences du programme de test, il choisit les exigences du scénario à suivre en fonction des résultats du test, lorsque l'opérateur a saisi les informations relatives aux tests, l'outil génère automatiquement la documentation relative aux tests ainsi conçus, puis un opérateur de développement décrit le mode opératoire pour chacun des tests dont les exigences ont été formulées en utilisant les commandes fournies par une bibliothèque de commandes génériques de l'outil, l'opérateur procède à la conception de chaque test élémentaire, l'outil génère automatiquement un fichier exportable traduit en un langage approprié au banc de test utilisé lors des tests.

La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel : la figure 1 est un bloc-diagramme d'un exemple de réalisation d'un outil de développement de tests mettant en œuvre le procédé de l'invention, les figures 2 à 7 sont des exemples de vues d'écran prises à différents stades de mise en œuvre des étapes de conception du procédé conforme à la présente invention, - la figure 8 est une vue d'écran d'un exemple de documents correspondant à la spécification des exigences de test, la figure 9 est une vue d'écran d'un exemple d'organigramme de test tel que pouvant être produit selon le procédé de l'invention, les figures 10 à 12 sont des exemples de vues d'écran prises à différents stades de mise en œuvre des étapes de conception de tests selon le procédé conforme à la présente invention, et

la figure 13 est un diagramme servant à expliquer la génération, selon le procédé de l'invention, d'un code de test utilisable par un banc de test.

Le procédé de l'invention est essentiellement caractérisé par la mise en place d'un outil assurant un lien réel entre la spécification de test et le code, et il permet d'optimiser les phases de spécification, conception et codage d'un programme de test.

On a schématisé sur le bloc -diagramme de la figure 1 un exemple de réalisation d'un outil 1 universel et pérenne de développement de tests d'équipements mettant en œuvre le procédé de l'invention. Cet outil 1 comporte une fonction 2 de saisie de données. Cette fonction sert à saisir les spécifications des exigences relatives aux tests à réaliser, et en particulier la définition de l'arborescence de ces tests en modes « GO » et « NO GO » , c'est-à-dire en mode binaire BON ou MAUVAIS et des tolérances applicables aux résultats de ces tests. Cette fonction 2 est reliée à un moteur 3 de génération d'exigences produisant de la documentation relative à la spécification des exigences des tests logiciels, spécification répondant à une mise en forme particulière (4), et elle est suivie d'une fonction 5 de conception de tests. La fonction 5 consiste en particulier à définir des conditions d'entrée permettant de répondre aux exigences relatives aux tests à effectuer. La mise en œuvre des fonctions 2 et 5 est expliquée en détail ci-dessous en référence aux figures 2 à 7.

La fonction 5 est reliée à un moteur 6 de génération de tests de type connu en soi, produisant de la documentation 7 exposant les procédures de test conçues à l'aide de la fonction 5, et éventuellement de la documentation 8 exposant les procédés de validation des tests produits et la documentation prévue pour enregistrer les résultats de cette validation.

D'autre part, la fonction 5 est reliée à un moteur 9 produisant un organigramme de test 10, et elle est reliée à une bibliothèque 11 de commandes génériques pré-existante. Cette bibliothèque 11 est reliée à son tour à des bibliothèques de langages spécifiques. Dans le cas présent, on utilise deux

bibliothèques de langages spécifiques, par exemple la bibliothèque 12 de langage « Labview » produisant des codes 12A de test en langage « Labview » ® et la bibliothèque 13 de langage « ATEasy » ® produisant des codes 13A de test en langage « ATEasy », mais il est bien entendu que l'outil 1 peut comporter une seule bibliothèque de codes de langages de test ou bien une ou plusieurs autres bibliothèques produisant des codes de programmes de test appropriés aux bancs de test utilisés avec l'outil 1 de l'invention dans le présent ou dans le futur. En effet, les tests doivent pouvoir être menés sur des matériels pendant toute leur durée de vie, qui peut dépasser 20 ans, avec des bancs de test dont les programmes de test sont généralement renouvelés ou modifiés au bout d'un laps de temps nettement inférieur à la durée de vie des matériels à tester. Grâce à l'invention, on peut garder (dans la mémoire du calculateur de l'outil 1 et/ou sur des supports de mémoire amovibles) une trace des protocoles de test et de la façon dont ils ont été conçus au moins aussi longtemps que les matériels à tester sont utilisés. Du fait de la modularité de l'outil 1 (bibliothèques 12 et 13 indépendantes des autres fonctions de l'outil 1 ), il suffit de changer la bibliothèque de codes (bibliothèque telle que 12 ou 13) pour l'adapter aussitôt à un nouveau langage de test.

Les figures 2 à 7, décrites ci-dessous, se rapportent à des vues d'écran d'un terminal de visualisation d'un calculateur, tel qu'un micro-ordinateur, utilisé par un opérateur (qui est, dans cette première phase de spécification des exigences, le spécialiste du matériel à tester) pour effectuer les spécifications d'exigences du programme de test et incorporant l'outil 1.

La figure 2 représente une vue d'écran 14 s 'ouvrant au lancement du processus PSE de spécification d'exigences de l'outil 1 (fonction X). Cet écran affiche, dans le présent exemple, quatre fenêtres différentes référencées 15 à 18, la fenêtre 17 comportant trois « sous-fenêtres » 19 à 21. Ces fenêtres sont respectivement les suivantes :

Fenêtre 15 : fenêtre principale destinée à afficher les différentes tâches et sous-tâches du programme de test, utilisé ultérieurement sur un banc de test, au fur et à mesure de leur conception. Au lancement du programme PSE, cette fenêtre ne contient qu'une ligne initiale « PROGRAMME SANS

TITRE », qui sera complétée par un premier opérateur qui est ici l'opérateur de spécification des exigences du processus PSE au cours de la mise en oeuvre de ce processus.

Fenêtre 16 : initialement intitulée « PROGRAMME SANS TITRE », comme la seule ligne de la fenêtre 15, et comportant, dans le présent exemple, quatre onglets : « Description » (activé ici), « Propriétés », « Saut en fin de test Vi » et « Saut en fin de test 2/2 ». Dans cette fenêtre 16, figure une légende « Vous pouvez mettre ici une description », en vue de mettre une description du programme . - Fenêtre 17 : intitulée « Liste des commandes ». Elle comporte initialement, dans la sous-fenêtre 19, deux lignes : « PROGRAMME » et « SYSTEME ». Ses deux autres sous-fenêtres 20 (« Paramètre ») et 21 (« Valeur ») sont initialement vides. En outre, la fenêtre 17 comporte trois boutons 22 à 24. Ces trois boutons sont respectivement intitulés « Créer Macro », « Supprimer Macro » et « Ajouter ».

Fenêtre 18 : en fait, elle se présente comme un onglet, intitulé « Sélectionnez un test ...». Initialement, elle n'est pas activée, du fait qu'il n'existe encore aucun test.

La vue 14 comporte également un ensemble 25 de boutons. Cet ensemble de boutons comporte des boutons portant des symboles classiques tels que « Ouvrir un dossier », « Enregistrer », « Couper », etc, ainsi que certains boutons qui sont spécifiques à l'invention, comme celui utilisé dans l'exemple illustré en figure 13.

La vue 26 de la figure 3 montre le début de la phase de saisie des tâches et sous-tâches du processus PSE . A ce stade, des informations 27 ont été saisies seulement dans la fenêtre 15. Le programme de test s'appelle maintenant « TEST DE MON EQUIPEMENT ». Ce programme comporte plusieurs tâches, appelées ici « FONCTION ALIMENTATION », « FONCTION PRE-AMPLI », etc. Ces tâches se composent de sous-tâches. Par exemple, la fonction alimentation comporte des sous-tâches telles que « TEST SECTEUR », « TEST TENSION », etc.

Dans cette vue 26, on a cliqué, à titre d'exemple, sur la sous-fonction « DEPANNAGE ALIMENTATION », qui s'affiche dans le titre de la fenêtre 16.

La vue 28 de la figure 4 montre les détails relatifs à une sous-tâche. Dans cet exemple, cette sous-tâche est « TEST -24V » qui a été activée en cliquant sur la ligne correspondante de la fenêtre 15. Le nom de cette sous-tâche s'affiche alors en tant que titre des fenêtres 16 et 18.Dans la sous-fenêtre 19, s'affichent différentes commandes pouvant être intégrées au « TEST -24V ». La fenêtre 16 affiche la description, rédigée par l'opérateur, du test activé en question.

La première étape de saisie d'informations, illustrée à la figure 5 par la vue 29, consiste à faire saisir par l'opérateur , pour chaque test élémentaire sélectionné, les exigences associées, telles que type de mesure, unités de mesure, tolérances applicables aux valeurs mesurées pour les reconnaître comme bonnes, etc. Pour cela, l'opérateur active l'onglet « Propriétés » de la fenêtre 16 se rapportant, dans le présent exemple, au test « TEST -24V ». Dans cet exemple, les différentes propriétés, qui sont sélectionnées dans des sous-fenêtres, sont : « Min/max » pour le type, « J2-21 » pour le nom du point de mesure de la tension, « V » (pour Volts ») pour l'unité de mesure, -25 pour la valeur minimale tolérable de la tension mesurée pour la reconnaître comme bonne, et -23 pour la valeur maximale tolérable. Le bandeau représenté tout en bas de la vue de cette figure 5 (de même que sur les figures 3 et 4 et les figures 6, 7, 10 et 11 ) fournit des indications complémentaires telles que le niveau du test dans l'arborescence du programme de test, l'index associé à ce test, l'identité du test et l'heure.

Ensuite, comme représenté sur la vue 29A en figure 6, pour chaque test élémentaire sélectionné (il s'agit toujours ici du test -24V), l'opérateur choisit les exigences du scénario à suivre en fonction des résultats du test. Dans le cas présent, ces résultats sont soit « réussi » (« PASS ») soit « non réussi » (« FAIL »). Les intitulés de ces types de résultats figurent dans l'onglet activé « Saut en fin de test ¹ A » de la fenêtre 16. Pour chacun de ces types de résultats, il est prévu deux sous- fenêtres « On saute vers » et « en exécutant avant le saut ». Ainsi, l'opérateur peut facilement indiquer la suite du scénario de test quel que soit le résultat de ce test élémentaire, et éventuellement indiquer une procédure particulière (par exemple,

comme représenté dans la deuxième sous-fenêtre du résultat « FAIL », la procédure « MSGOP »).

En variante, comme représenté sur la vue 30 de la figure 7, dans la fenêtre de l'onglet « Saut en fin de test 2/2 », au lieu d'indiquer la suite du scénario de ce programme automatique, l'opérateur de saisie peut faire apparaître un message à destination de l'opérateur effectuant le test. Dans l'exemple de la figure 7, si le test échoue, ce message est « DEFAUT SUR LE -24V. COUPER LE DISJONCTEUR. PROCEDER AU DEMONTAGE DU BLOC ALIM (PSl) ».

Une fois que l'ensemble des tâches et sous-tâches a été ainsi renseigné et les scénarii de test et de dépannage créés, l'outil 1 est en mesure de générer automatiquement un document (document imprimé, par exemple tel que le document 4 de la figure 1, ou bien un document visualisé sur un écran, tel que celui de la figure 8) correspondant à la spécification des exigences de test. Ce document est par exemple du type de celui représenté partiellement en figure 8, et éventuellement tout autre type de document utilisant les informations saisies par le premier opérateur. Ces autres documents ainsi générés sont, par exemple, des documents décrivant diverses phases de la conception des exigences, des procédures de validation, etc. La partie de gauche de la vue de la figure 8 montre quelques-unes des premières pages de la spécification des exigences de test. La partie de droite de la vue 31 de la figure 8 montre le détail d'une page sélectionnée dans la partie de gauche, et dans le cas présent la page 8 a été sélectionnée.

Sur la figure 9, on a représenté un exemple d'organigramme de scénario de test 32 , tel que celui du document 10 de la figure 1.

Une fois que les exigences des tests ont été formulées par le premier opérateur, un opérateur de développement (qui peut être le premier opérateur ou bien un programmeur) décrit le mode opératoire pour chacun des tests dont les exigences ont été formulées par le premier opérateur. A cet effet, il utilise les commandes fournies par la bibliothèque de l'outil, qui est la bibliothèque 11 de commandes génériques illustrée en figure 1. On a représenté dans la sous-fenêtre 19 de la vue 33 de la figure 10 quelques-unes des commandes génériques, qui sont disponibles pour

tous les tests, et dans le cas présent, on a représenté celles relatives au test « TEST + 24V » et référencées 34 sur cette figure.

A partir de ces commandes, l'opérateur procède à la conception de chaque test élémentaire. Ainsi, pour le test « TEST + 24V » en question, l'opérateur choisit dans la sous-fenêtre 19(vue 35 de la figure 11) la commande « (mesurer) une tension continue ». Les sous-fenêtres 20 et 21 indiquent pour cette commande les paramètres correspondants. Pour l'exemple représenté, il s'agit du paramètre d'affichage du résultat de la mesure de la tension (+ 24V). Ce paramètre est simplement dénommé « RESULTAT » et sa valeur est la variable « résultat » qui représente le résultat de la mesure effectuée en activant la sous-tâche de mesure de tension continue (apparaissant dans la fenêtre 19). La fenêtre 16 affiche le commentaire correspondant « Test de la présence du +24V au point J2-19 du bloc alimentation » dans l'onglet « Description ». L'onglet « TEST +24V » de la fenêtre 18 affiche, en langage dit de « haut niveau », les différentes lignes du programme correspondant , dont les intitulés des routines visibles sur le dessin sont successivement : « préparation opérateur », « Mise en route du secteur », branchement automatique sur J2-19 » et « Mesure de la tension +24V ».

Comme représenté sur la vue 36 de la figure 12, lorsque des opérations doivent être répétées, l'opérateur peut créer des routines pouvant être appelées à tout moment. Pour l'exemple représenté, une routine (macro-commande) dénommée « COUPURE SECTEUR », qui peut être appelée plusieurs fois au cours de la conception du programme, a été créée à cet effet et est accessible à partir d'un onglet supplémentaire de la fenêtre 18 dénommé « COUPURE_S ECTEUR ». En cliquant sur cet onglet, l'opérateur fait apparaître cette routine. Cette routine est insérable dans le programme :

- soit grâce à une commande « exécuter une procédure » de la fenêtre 16 (et en la nommant dans ses paramètres),

- soit en sélectionnant cette procédure dans la fenêtre 16.

Lorsque l'opérateur a terminé l'ensemble de la conception des tests, l'outil 1 génère automatiquement un fichier exportable traduit en un langage approprié au

banc de test utilisé lors des tests, par exemple l'un des deux langages disponibles de l'outil de la figure 1, à savoir « ATEasy » et « Labview » .

Sur le diagramme de la figure 13 on a schématiquement illustré les dernières étapes de la conception des programmes de test. En cliquant sur le bouton 37 (vue d'écran 38) qui correspond à la conversion de programmes, on ouvre une fenêtre 39 dénommée « Convertir » et dans laquelle sont affichés les différents types de conversion disponibles dans l'outil 1. Dans le cas présent, on sélectionne la ligne

« Fichier de sauvegarde [*.ACP] <— > Programme de test ATEasy ® [*.PGT] », ce qui déclenche la conversion du programme de test ainsi conçu en langage de haut niveau vers un langage « bas niveau », et on obtient le code (40) du programme de test en langage « ATEasy » qui peut ensuite être exploité par tout appareil de test approprié, par exemple un PC 41.

En conclusion, l'outil de l'invention permet, à partir des données saisies par l'utilisateur, de générer automatiquement de la documentation et du code (avec choix du langage utilisé).

Il permet grâce à des moteurs de génération automatique (comme illustré en figures 2 à 5), de gagner sur les temps de développement et donc sur les coûts.

Les liens et la traçabilité (obtenue grâce à mémorisation de toutes les exigences de test et des différents paramètres et procédures de test dans l'outil 1), déployés à travers les différentes phases de développement, permettent d'autre part, d'assurer la qualité du produit de sortie.

L'architecture de l'outil, associée à l'architecture du processus de développement, permet une ré-utilisation maximum qui ne devient pas obsolète dans le temps.

Selon un exemple de réalisation, l'outil a été développé, dans un premier temps à l'aide d' 'Excel' puis en langage 'cSharp' .

Il permet à tout opérateur de spécification du programme de test : de spécifier aisément et structurellement ses besoins de test (mise à disposition d'une méthode de spécification des test, voir figures 2 à

7),

de produire et de mettre à jour automatiquement, les documents de spécifications ou de conception (mise à disposition d'un moteur de génération automatique de documents, voir figures 8 et 9), de générer et de mettre à jour automatiquement, le logiciel de test dans un langage quelconque (mise à disposition d'une bibliothèque de commandes et d'un moteur de génération automatique de code, voir figures 10 à 13), de pouvoir transmettre, tout au long des phases de développement du système opérationnel, les informations essentielles de soutien de ce système et ainsi accroître fortement le taux de ré-utilisation. Les informations saisies dans l'outil sont universelles et donc pérennes, tout au long des phases de vie du moyen de soutien, de pouvoir traiter à moindre coût les obsolescences logicielles et matérielles survenues sur des bancs de test existants. Cet exemple de réalisation a permis de constater : un gain en temps de développement sur les différentes phases

(spécification, conception, codage, documentation, évolutions, traçabilité,...), une réduction des coûts de développement (réduction de 15 à 20%), - que l'utilisation de l'outil, a grandement aidé à la certification

CMMI2, la lisibilité des programmes obtenus : informations claires et compréhensibles (en langage « haut niveau », comme précisé ci- dessus), garantissant ainsi leur pérennité. Finalement, un outil selon l'invention est universel dans le monde du test et de la mesure, il n'est absolument pas lié à un produit existant.

Un outil selon l'invention, n'est pas un séquenceur de test. Cependant, comme dans toute procédure de test d'équipement, y est notifié l'architecture à respecter pour obtenir un produit de sortie final : un programme de test automatisé d'équipement, une documentation de développement, de validation, etc.

Un outil selon l'invention est pérenne parce qu'il n'est justement pas associé à un langage ou un applicatif de test d'équipement existant. Un séquenceur de test est au contraire, associé à des applications commercialisées, souvent propriétaires, d'où risques forts d'obsolescence et de non-pérennité. Un outil selon l'invention est orienté test d'équipement mais est dé-corrélé d'un banc de test existant, équipé d'instruments de mesure et chargé d'une application de test existante, avec séquenceur intégré ou non. Il s'utilise sur simple PC. Ses produits de sortie, documentation de développement, de soutien, de validation et procédures de test d'équipement, sont totalement indépendants de, et transportables sur, n'importe quel type d'applications ou de langages existants ou à venir. L'indépendance des produits de sorties à l'origine des critères "universel" et "pérenne".

L'invention permet de réaliser une procédure de test d'équipement selon l'architecture exigée de tout programme de test.

Avantageusement, l'invention permet à l'opérateur de concevoir ses différentes tâches et sous-tâches de sa procédure de test d'équipement, hors banc de test. L'outil mémorise sa procédure et permet l'exportation de cette procédure sur un banc de test équipé, quelle que soit l'application, le séquenceur utilisé ou le code employé.

L'invention permet de spécifier à plus haut niveau la procédure de test. L'effet le plus immédiat, est qu'il est capable de produire un document de spécification, cahier des charges, où sont consignées toutes les exigences attendues du test de l'équipement, de produire une procédure de test et a posteriori, un programme de test d'équipement à porter sur un banc.

Ces spécifications en fonction des informations saisies par l'outil traitent notamment: des exigences sur les capacités du produit en sortie : programme de test, des fonctions testées par la procédure de test d'équipements, - de l'indépendance des sous modules ainsi conçus, des exigences d'interface interne et externe avec le programme de sortie,

des exigences sur le dimensionnement et le temps de traitement, des exigences en matières de sûreté et de sécurité, des contraintes de conception, des performances spécifiques liées au programme de test en produit de sortie, des différents modes de fonctionnement autour du déroulement de la procédure, des taux de couvertures et taux de localisations associées,... et enfin des exigences détaillées sur les tâches et les à produire, donnant l'aspect contractuel nécessaire au développement et à la validation du produit de sortie.

L'invention permet donc la saisie de l'ensemble des exigences associées à la procédure de test ainsi que leur traçabilité, en même temps que la saisie des tests unitaires.

Le procédé selon l'invention, donne dès l'ingénierie d'une procédure de test d'équipement et hors séquenceur et banc défini, la capacité, et la nouveauté dans le domaine, de définir les exigences de scénarii de la procédure de test à produire. Ces exigences saisies dans l'outil sont indépendantes d'un quelconque banc ou d'un quelconque séquenceur. Ce qui fait sa particularité, sa force d'universalité et traduit un saut technologique par rapport à ce qui existe aujourd'hui sur le marché. Aujourd'hui, la compétition commerciale, oblige les constructeurs à proposer des produits propriétaires donc concurrents et non universels.

L'invention fournit une bibliothèque de commandes génériques. Cette bibliothèque, toujours sur l'aspect "universalité et pérennité", apporte un saut technologique par rapport à l'art antérieur ou il n'y a pas de commandes génériques permettant de spécifier sa procédure de test d'équipements, de manière universelle, mais plutôt de produire directement du code bas niveau conformément à des logiciels pré-définis d'écritures de test dans le monde de l'instrumentation. L'invention se démarque de ces applications de l'art antérieur. Le produit de sortie pourra ensuite être appliqué à n'importe quelle plate-forme de test

d'équipements, provenant d'un fournisseur ou d'un autre. Un des objectifs de l'outil est notamment d'architecturer une procédure de test, quelle que soit la plate-forme à utiliser. Aujourd'hui le choix de la plate-forme est un vrai dilemme pour les industriels. Ils sont obligés de faire un choix entre les différentes plate-formes disponibles et prennent alors le risque d'assurer eux même les obsolescences successives.

De plus, la génération automatique par l'outil, de documents de spécification, de développement et de validation, permet de garantir une traçabilité et une maintenabilité de l'ingénierie de test de leurs équipements dans le temps.

Ainsi un opérateur de développement peut décrire le mode opératoire pour l'ensemble des tests de son équipement, pour lequel les exigences ont été formulées en utilisant des commandes de haut-niveau, totalement génériques, non associées à un quelconque langage, et de ce fait pérennes. Ces commandes sont fournies par une bibliothèque de commandes créée pour l'outil et unique dans ce domaine. Ces commandes sont proches aussi d'une spécification de type "ingénierie de test", que d'un code informatique pour initiés.

L'invention permet à partir de la procédure de test universelle d'un équipement, spécifiée, conçue et documentée à partir du même outil, d'exporter vers un langage choisi à posteriori, le code final, programme de test d'équipement, fonctionnant sur la plate-forme désirée.

Il n'y a donc plus de code à produire par l'utilisateur de l'outil, contrairement aux séquenceurs couplés aux langages de l'art antérieur. Le spécificateur/concepteur du test, n'a plus besoin d'être un informaticien chevronné mais un technicien/ingénieur maîtrisant l'équipement à tester.

Une base de donnée couplée à l'outil, est chargée de générer automatiquement le code, bas niveau. Cela a un double avantage : pas de connaissance en informatique et sur les langages orientés test d'équipements,

portage possible de l'ingénierie de test d'un langage vers un autre, présent ou futur, en cas d'obsolescence du langage et/ou de la plate-forme.

Un outil selon l'invention génère donc automatiquement en fonction du langage choisi, un fichier directement exécutable sur le banc de test d'accueil. En cas d'obsolescence de l'environnement, langage, plate-forme, séquenceur de test utilisés..., l'outil permet de générer à nouveau, à partir de la même source, un fichier sous un langage différent.

Les étapes du procédé selon l'invention permettent notamment de décrire la généricité, la pérennité, la facilité du traitement d'obsolescence des travaux d'ingénierie effectués sur un outil objet de l'invention. L'invention est facile à mettre en œuvre, l'utilisation d'un simple PC par un non-spécialiste du logiciel, alors que dans les solutions existantes, il faut avoir choisi et s'être équipé d'une plate-forme de test, de disposer de ressources compétentes sur les langages disponibles sur le marché, et surtout d'avoir à sa disposition le banc de test pour l'ingénierie et le développement, coûteux.

L'aspect universel d'un outil selon l'invention est traduit par le fait que: les travaux d'ingénierie et de développement sont menés en dehors de toutes solutions pré-définies, les produits de sortie de type documentation sont universels, ne traitant pas d'une plate-forme ou d'un langage propriétaires, de ce fait totalement pérennes et transportables sur des environnements différents, les produits de sortie de type procédures de test d'équipement, sont exportables quel que soit le code et sur tout type d'application, grâce aux bases de données de conversion générique/spécifique de l'outil. Contrairement à l'art antérieur, l'invention permet de spécifier un test, au vrai niveau d'une spécification, donc haut niveau, et non pas en écrivant directement le code de sortie bas niveau.

L'invention permet encore de générer automatiquement toute la documentation de développement, spécification, conception, test, validation,... au format normatif industriel type DOD XX, en fonction des données et de la forme de saisie que l'outil impose.

L'invention garantit notamment : un outil complet d'ingénierie, de la spécification haut-niveau de la procédure de test, jusqu'à la production de tous les documents de développement liés au cycle industriel de développement, dit en V, d'un langage universel, donc pérenne, conçu pour être transportable vers tout type de langage de test d'équipement actuel ou futur.

La résolution de la problématique rencontrée actuellement par les industriels, qui doivent réduire les coûts de développement pour tester les équipements qu'ils produisent. Ces industriels sont confrontés à la somme des coûts des différentes phases de développement : rédaction de la spécification de test par un spécialiste de l'équipement à tester, conception du test par un spécialiste du test et mesure, codage par un spécialiste du langage de test choisi, - vérification de la conformité et de la cohérence de toutes ces phases par un spécialiste qualité, l'outil regroupe toutes ces phases, et c'est une première, pour optimiser au maximum le développement et la traçabilité des évolutions, la résolution de la problématique d'obsolescence rencontrée par les industriels, lorsque les plate-formes sont obsolètes, logiciel de test employé ou instrumentation plus au catalogue, puisque l'outil collecte et travaille à partir du cœur même du test et non pas des moyens choisis pour le mettre en œuvre.

Aujourd'hui les industriels doivent : - spécifier leurs tests, haut niveau, par la rédaction d'un document de spécification, s'adresser aux équipes test et mesures pour concevoir leurs tests dans le langage déployé dans leur société tout en s'assurant du maintien de la compétence de développement, - s'adresser à ces mêmes équipes ou à des spécialistes du code pour produire le programme de test automatique qui pilotera les instruments,

s'adresser à l'ensemble des intervenants pour mettre au point les programmes de test et les valider, avec nécessité de re-boucler toutes les phases en cas d'évolution,

En cas d'obsolescence du langage, de l'instrumentation ou de l'équipement à tester, se heurter aux difficultés de re-développement de tout ou partie des phases précédentes, donc peu de "re-use" et un coût de possession élevé non maîtrisé.

Un outil selon l'invention est mis dans les mains du spécialiste de l'équipement à tester. De là est produit l'ensemble de la documentation et la procédure de test dans une écriture totalement générique. La procédure permet de générer le code dans un langage de test choisi a posteriori, existant ou à venir. Toute évolution de l'ingénierie ainsi faite est automatiquement prise en compte par l'outil, documentation du langage.

En cas d'obsolescence, l'industriel porte sa procédure de test sur un autre langage, sans revenir sur son ingénierie et sur la documentation produite.