CE PROCEDE

Domaine technique

La présente invention concerne le domaine des logiciels d’enregistrement de séquences de pilotage et de contrôle de robots, en particulier de bancs de test automatisés d’ appareils/d’équipements .

Il peut notamment s’agir de bancs de test automatisés, non intrusifs, destinés à réaliser des tests mécaniques et/ou logiciels et/ou visuels et/ou sonores d’interface homme-machine d’un appareil ou équipement, tel qu’un équipement électronique muni d’une interface homme- machine comprenant un écran et un clavier, ces derniers pouvant être confondus dans le cas d’un écran tactile.

Parmi les appareils et équipements pouvant être soumis à un banc de test automatisé tel qu’envisagé dans le cadre de l’invention, on peut citer les smartphones, les indicateurs de pesage, les terminaux de paiement, les tableaux de bord ou sous-ensembles de tableaux de bords, ou encore les instruments portables.

La présente invention vise plus précisément à permettre de créer et d’enregistrer différentes séquences de pilotage d’un banc de test comprenant une ou plusieurs étapes de tests, et à piloter le banc de test pour mettre en œuvre les séquences de pilotage enregistrées.

Technique antérieure

On peut classer en différentes catégories les solutions de test automatisées d’interface homme-machine d’appareils/équipements qui existent à ce jour.

Les tests qui doivent être mis en œuvre sont des tests fonctionnel ou d’endurance mettant en œuvre le clavier et/ou l’écran et/ou l’application logicielle standard de G appareil/équipement avec l’environnement extérieur.

La première catégorie concerne des bancs à automatismes dédiés spécifiquement aux tests. Ainsi, un développement mécanique et logiciel est fait spécifiquement pour chaque nouveau type d’appareil/équipement que l’on souhaite tester. On perçoit immédiatement l’inconvénient majeur de cette solution : pour chaque nouvel équipement ou évolution de l’équipement, un nouveau développement doit être réalisé. Des logiciels permettent de faciliter ce développement, mais ils restent destinés à un public confidentiel d’informaticiens. On peut citer ici le logiciel de dénomination commerciale « LabView ». Des tests intrusifs ont également été mis en œuvre, comme décrit dans la demande de brevet EP0084454. Ici, un logiciel dédié, dont les fonctions sont de retrouver des informations sur les affichages en cours et également de simuler un appui touche sur un clavier de G appareil/équipement à tester, est chargé dans ce dernier. Dans ce cas, le test peut être automatisé sans mise en œuvre de moyens mécaniques extérieurs. Outre le fait que G appareil/équipement est chargé avec un logiciel supplémentaire, ces tests intrusifs ont pour inconvénient majeur d’introduire des conditions de test qui ne sont pas identiques aux conditions d’exploitation de l’équipement.

Des logiciels de tests spécifiquement dédiés aux interfaces homme-machine ont été développés. Ces logiciels se limitent au test d’applications à utiliser sur le web, et sont rarement utilisables pour des logiciels embarqués. Ces logiciels peuvent être considérés comme intrusifs car ils ne sont pas nécessaires à l’exploitation de G appareil/équipement. On pourra se référer au logiciel « Sélénium », qui est un « framework » de test informatique développé en Java.

Enfin, il existe des fonctions de tests de claviers ou d’écrans. Ces fonctions permettent de réaliser le test physique mais se limitent à un clavier ou à un écran. La combinaison écran et clavier est utilisée pour le test d’un des sous-ensembles, comme divulgué dans les demandes de brevet EP2405356 et EP0175765. Ces solutions ne mettent pas en œuvre l’application d’exploitation de l’appareil/équipement mais une application dédiée, et peuvent donc à ce titre être considérés comme intrusifs.

Aussi, afin de pallier les inconvénients précités, la demande de brevet déposée sous le numéro FR 1858627 divulgue un banc de test automatisé, non intrusif, configuré pour réaliser des tests mécaniques et/ou logiciels et/ou sonores d’interfaces homme-machine d’un appareil/équipement à tester.

Un banc de test tel que décrit dans cette demande est représenté en figures 1 et 2.

La figure 1 est une vue en perspective avec transparence d’un exemple de banc de test automatisé selon la demande FR 1858627, désigné par la référence 1. La figure 2 illustre en vue de côté le banc de test 1.

Le banc de test 1 est constitué d’un module avec un bâti 10 assemblé de pluralité de profilés 11 et qui est muni de pieds 12. Une unité centrale 2, une enceinte 3, un coffret électrique de commande 4 de l’unité centrale et une connectique extérieure 5, de préférence une connectique d’alimentation en 220V et/ou une connectique de type Ethernet sont fixés au bâti.

Le fond de l’enceinte 3 comprend un support 6 qui permet de maintenir l’appareil à tester dans une position fixe de référence, pendant des séquences de tests.

Une autre connectique d’alimentation 7 qui peut alimenter G appareil/équipement à tester et être pilotée est agencée à proximité du support 6.

L’enceinte 3 comprend une pluralité de parois transparentes 30 dont une peut s’ouvrir et constitue pour un opérateur, un accès sécurisé au support 6 depuis l’extérieur. Pour faciliter l’accès, la paroi d’accès 30 est munie d’une poignée P.

Des moyens électroniques 31 permettant la coupure des alimentations de puissance et le cas échéant le verrouillage/déverrouillage de la porte d’accès sont prévus. En outre, un bouton d’urgence 32 fixé sur le bâti 10 à proximité de la porte d’accès permet à un opérateur d’interrompre tout test en cas d’urgence.

Un portique à trois axes (X, Y, Z) 8 est fixé à l’intérieur de l’enceinte 3.

Un palpeur 9 est fixé au portique 8 qui peut donc déplacer en translation le palpeur 9 selon chacun des trois axes X, Y et Z. Le palpeur 9 peut donc venir en contact à souhait avec n’importe quelle zone de l’appareil pendant le(s) test(s), chaque zone de contact constituant une interface (IHM) d’acquisition.

Une caméra 13 est également fixée au portique 8. Cette caméra permet la prise d’images et/ou de vidéos de l’appareil/équipement, plus particulièrement de la ou des interfaces (IHM) de restitution visuelle de l’appareil/équipement, pendant le(s) test(s).

Pour maîtriser les conditions d’éclairage à l’intérieur de l’enceinte et donc augmenter la qualité des prises d’image et/ou de la vidéo de la caméra 13, des moyens d’éclairage 14 du support de l’appareil/équipement sont fixés au bâti 10.

L’unité centrale 2 peut piloter l’allumage, l’extinction et le cas échéant le réglage de l’intensité du faisceau L des moyens d’éclairage 14 lors de la ou des séquence(s) de test(s) de l’appareil/équipement.

Un microphone 15 est fixé à l’intérieur de l’enceinte 3. Ce microphone 15 est adapté pour capter les sons émis par au moins une interface de restitution sonore de l’appareil/équipement, pendant le(s) test(s). Le fonctionnement du banc de test 1 qui vient d’être décrit va maintenant être brièvement expliqué.

L’opérateur vient positionner et le cas échéant fixer G appareil/équipement à tester sur le support 6.

Puis, il branche une alimentation de G appareil/équipement à tester sur la prise d’alimentation 7 que l’unité centrale 2 peut piloter.

L’opérateur ferme alors la porte d’accès 30 de l’enceinte 3 qui est verrouillée par les moyens ad’hoc 31.

Une séquence de test de G appareil/équipement peut alors être initiée.

Un logiciel de contrôle-commande chargé dans l’unité centrale 2 a déjà récupéré ou récupère la liste des tests à exécuter dans un langage dédié.

Le logiciel pilote et synchronise alors tout ou partie des composants internes à l’enceinte 3 selon une séquence de test prédéfinie: le portique 8 à trois axes et donc le palpeur 9, la caméra 13 et le cas échéant les moyens d’éclairage 14, le microphone 15, et le cas échéant la prise d’alimentation électrique.

Le logiciel récupère alors les informations fonctionnelles de G appareil/équipement testé.

En particulier, le logiciel peut effectuer un traitement d’images issues de la caméra 13 de préférence, avec de la reconnaissance de caractère OCR, 7 segments, 16 segments, et/ou de la reconnaissance de couleur, et/ou de la reconnaissance de forme, et/ou de la reconnaissance d’icônes.

En outre, le logiciel peut effectuer un traitement des sons émis par l’appareil/équipement testé, afin de distinguer les opérations issues des IHM.

Au final, le logiciel permet de remonter les résultats et les traces des tests exécutés dans un format dédié, qui peuvent enregistrer dans un ou plusieurs fichiers dans l’unité centrale 2 ou dans un support d’enregistrement extérieur via la connectique extérieure 5.

En plus des fonctions décrites, on peut implanter d’autres fonctions de test au banc 1 selon l’invention, et ce en fonction du type d’appareil/équipement à tester.

Ainsi, par exemple, si ce dernier est un terminal de paiement électronique, on peut implanter à l’intérieur de l’enceinte 3, des moyens d’insertion mécanique d’une carte de paiement électronique à l’intérieur du terminal. Cependant, les méthodes existantes pour définir la ou les séquences de test à exécuter par le logiciel de contrôle-commande de G unité centrale, en général à l’aide d’un langage informatique dédié, ne donnent pas entière satisfaction.

Il est par exemple connu de définir les étapes successives d’une séquence de test en écrivant un ensemble de lignes de commande.

Cela représente une opération longue et relativement complexe à mettre en œuvre, nécessitant des connaissances plus ou moins avancées dans le domaine informatique.

Il existe des logiciels de définition de séquences de pilotage permettant de simplifier l’écriture des lignes de commande, mais cela reste destiné à un public ayant des connaissances avancées en informatique.

Il est par ailleurs connu d’enregistrer une séquence de test par déplacement d’un robot : bien que cela limite le besoin de recourir à l’écriture de lignes de commande, cela reste une méthode peu pratique et lente à mettre en œuvre en particulier pour des séquences de test. La demande WO 2018/062156 Al divulgue un robot destiné à déplacer une galette de matériau semi-conducteur à l’aide d’un bras de robot, un dispositif de contrôle du robot ainsi qu’un procédé d’apprentissage de la position du robot. Le procédé d’apprentissage repose sur la comparaison d’informations visuelles obtenues par une caméra avec un substrat virtuel : lorsque les deux coïncident, la position du bras du robot est enregistrée.

La demande WO 2011/065035 Al porte sur un procédé de génération de données d’apprentissage pour un robot comportant un bras de robot, ainsi qu’un dispositif d’apprentissage basé sur les mouvements dans l’espace d’un opérateur. Le procédé d’apprentissage requiert l’intervention d’une personne humaine.

La demande EP 1710649 A2 divulgue un dispositif de contrôle de mouvement qui permet d’apprendre à un robot à se positionner. La demande décrit également un dispositif d’apprentissage de la position du robot, un procédé d’apprentissage de la position du robot et un logiciel pour l’apprentissage de la position du robot.

Par conséquent, il existe un besoin pour proposer une solution de génération de séquences de test qui soit rapide, simple d’utilisation et qui ne nécessite pas la mise en place d’un environnement matériel spécifique.

Le but de l’invention est de répondre au moins partiellement à ce besoin. Exposé de l’invention

Pour ce faire, l’invention concerne un procédé d’enregistrement d’une séquence de test pour tester un appareil/équipement, la séquence de test comprenant une ou plusieurs actions de contrôle ou de commande destinées à contrôler ou commander un robot configuré pour tester G appareil/équipement, le robot pouvant notamment être un banc de test automatisé, le procédé exécutant un logiciel de pilotage du robot sur un dispositif, tel qu’un ordinateur, comportant un processeur, une mémoire et un écran, le procédé comprenant les étapes suivantes : a) sélection par un utilisateur, à partir d’une interface graphique, d’une action de contrôle ou de commande du robot ; b) caractérisation par un ou plusieurs paramètres de l’action sélectionnée par l’utilisateur, à partir de l’interface graphique ; c) réitération des étapes a) et b) autant de fois que souhaité par l’utilisateur pour obtenir une séquence de test ; d) enregistrement par l’utilisateur de la séquence de test obtenue selon l’étape c).

Ainsi, l’invention consiste essentiellement en la mise en œuvre d’un procédé permettant à un utilisateur de sélectionner et de caractériser à partir d’une interface graphique, de manière simple et intuitive, un ensemble d’étapes formant une séquence de test d’un robot de test. Le procédé selon l’invention permet de sélectionner, de caractériser et d’enregistrer une suite d’actions physiques et/ou logiques à effectuer sur l’équipement sous test. Cette suite d’actions forme une séquence de test qui peut être exécutée directement par le robot sur l’équipement sous test en un mode non intrusif : aucune adaptation mécanique, électronique ou logicielle n’est à prévoir pour l’équipement sous test.

Selon un mode de réalisation avantageux, la séquence de test obtenue comporte au moins une action d’appui sur G appareil/équipement à tester, l’action d’appui étant sélectionnée parmi un appui simple sur G appareil/équipement, une suite d’appuis sur G appareil/équipement ou un mouvement de glissement sur G appareil/équipement.

De préférence, l’interface graphique comprend une interface de visualisation adaptée pour permettre à l’utilisateur de visualiser G appareil/équipement sous test.

De manière avantageuse, la caractérisation de l’action d’appui est faite en interaction avec l’interface de visualisation. Selon une caractéristique avantageuse, la séquence de test obtenue comporte au moins une action de contrôle visuel, l’action de contrôle visuel consistant en la recherche sur un écran de G appareil/équipement d’un élément défini par l’utilisateur, tel qu’un texte, une icône ou une couleur.

Avantageusement, l’action de contrôle visuel est suivie par une action d’appui sur l’élément défini par G utilisateur.

Selon un mode de réalisation avantageux, la séquence de test obtenue comporte au moins une action de contrôle sonore sélectionnée parmi une détection d’un dépassement d’un niveau sonore prédéfini, une détection d’un son choisi par G utilisateur.

Selon une variante de réalisation, la séquence de test obtenue comporte au moins une action de contrôle-commande d’entrées-sorties du dispositif sélectionnée parmi un paramétrage d’une ou plusieurs valeurs de sortie du dispositif, une comparaison des valeurs d’une ou plusieurs valeurs d’entrée du dispositif.

Selon une caractéristique avantageuse, le procédé comporte en outre l’étape suivante : e) modification par G utilisateur des paramètres des actions et/ou de l’ordre des actions de la séquence de test obtenue selon l’étape c).

De manière avantageuse, le procédé comporte en outre l’étape suivante : f) exécution par l’utilisateur de manière partielle ou totale de la séquence de test. L’invention concerne également un produit programme d’ordinateur comportant un support et, enregistrées sur ce support, des instructions lisibles par un processeur pour que, lorsqu’exécutées, elles permettent de :

- générer une interface graphique sur le dispositif ;

- visualiser un appareil/équipement sous test ;

- visualiser ou écouter un enregistrement sonore de G appareil/équipement sous test ;

- piloter les entrées/sorties du robot ;

- mettre en œuvre le procédé d’enregistrement selon l’invention.

Brève description des dessins

[Fig 1] La figure 1 représente une vue en perspective d’un banc de test automatisé selon l’état de l’art.

[Fig 2] La figure 2 illustre en vue de côté le banc de test selon la figure 1. [Fig 3] La figure 3 représente de manière schématique un ordinateur exécutant un logiciel selon l’invention et connecté à un banc de test selon la figure 1.

Description détaillée

Les figures 1 et 2 ont déjà été commentées en préambule et ne seront donc pas décrites ci- dessous.

Les références numériques des figures 1 à 3 sont identiques pour les éléments communs représentés sur ces figures.

On a illustré en figure 3 un dispositif 100 comportant un processeur, une mémoire et un écran, pouvant par exemple être un ordinateur. Le dispositif 100 exécute un logiciel de pilotage 102 selon l’invention.

Le logiciel de pilotage 102 génère une interface graphique 104 qui peut en particulier comporter une interface de visualisation 106 et une interface de contrôle 108.

L’interface de visualisation 106 permet avantageusement de visualiser en temps réel l’appareil qui est en train d’être testé dans le banc de test automatisé 1, grâce aux données recueillies par la caméra 13 du banc de test.

L’interface de contrôle 108 permet avantageusement de sélectionner et de caractériser facilement une ou plusieurs actions de contrôle ou de commande du banc de test 1, afin de créer puis d’enregistrer une séquence de test.

La caractérisation d’une action peut être réalisée par un opérateur à partir de l’interface de contrôle 108 ; elle peut également consister en l’application de paramètres par défaut sans intervention de l’opérateur.

L’interface de contrôle 108 permet également de lancer partiellement ou en totalité l’exécution d’une ou de plusieurs séquences de test.

Elle permet aussi d’éditer une séquence de test, notamment en modifiant l’ordre des actions de contrôle ou de commande constituant la séquence de test, et de copier-coller une séquence de test existante afin de la modifier.

Les actions de contrôle ou de commande du banc de test 1 comprennent différents types d’actions.

Il peut s’agir d’actions physiques d’appui sur une touche ou sur un écran tactile de l’appareil/équipement à tester. Une fois caractérisé par l’utilisateur et enregistré dans une séquence de test, l’appui sur appareil/équipement peut être reproduit par le palpeur 9 du banc de test 1 lorsque la séquence de test est exécutée par le banc de test.

De manière avantageuse, G utilisateur peut choisir parmi les quatre types d’actions d’appui décrits ci-après. Une fois le type d’action d’appui sélectionné, l’utilisateur peut caractériser l’action d’appui, en particulier en définissant la zone de contact de l’appareil sous test où sera réalisée l’action d’appui. La caractérisation de l’action d’appui peut également se faire via des paramètres tels que la durée de l’action d’appui, la force exercée au cours de l’appui, G utilisation d’un clic simple ou d’un double clic, la position du palpeur selon l’axe Z, etc. Ainsi, l’action d’appui peut en premier lieu consister en un clic sur l’interface de visualisation de l’équipement sous test à la position d’un bouton physique qui définit un appui du palpeur 9 sur le bouton physique de l’appareil sous test, par exemple un bouton de mise sous tension de l’appareil.

L’action d’appui peut également être un clic, par exemple un clic de souris, sur l’image de l’appareil sous test dans l’interface de visualisation 106 : le palpeur 9 reproduit alors le clic sur la zone correspondante de l’appareil sous test.

L’action d’appui peut également consister en un mouvement de glissement (« slide »), réalisé par exemple avec une souris, sur l’image de l’appareil à tester dans l’interface de visualisation 106 : le palpeur 9 reproduit le mouvement de glissement sur l’appareil à tester dans la zone correspondante.

Enfin, l’action d’appui peut consister en un dessin libre d’une suite de points réalisée par une suite de clics sur l’image de l’appareil à tester dans l’interface de visualisation 106 : le palpeur 9 reproduit alors la suite de clics sur l’appareil à tester.

De préférence, la sélection du type d’action d’appui peut être réalisée directement avec les différentes touches d’une souris.

De manière avantageuse, lorsque plusieurs actions d’appui se suivent dans une séquence de test, le logiciel 102 permet d’enregistrer un temps minimum entre l’exécution de deux actions d’appui successives afin d’éviter des appuis successifs trop rapides.

Les actions de contrôle ou de commande du banc de test 1 peuvent également comprendre des actions de contrôle visuel. Une action de contrôle visuel repose sur l’acquisition de prises de vue de l’appareil sous test par la caméra 13 et consiste essentiellement en la recherche d’un élément dans une zone de l’appareil sous test définie par l’utilisateur. Ainsi, le logiciel 102 de pilotage autorise G utilisateur à définir dans l’interface de vision 106 une zone de l’écran de l’appareil sous test dans laquelle chercher du texte, une icône ou encore une couleur.

Plus précisément, dans un premier temps, l’utilisateur choisit une zone de l’écran de l’appareil sous test qui peut être l’écran dans sa totalité. Il choisit ensuite un type d’action de contrôle visuel à effectuer (recherche de texte, recherche d’une icône, recherche d’une couleur) puis il caractérise l’action en renseignant l’élément à chercher.

Dans le cas du texte, il s’agit d’une saisie de texte. La saisie du texte est libre. De préférence, G utilisateur peut entrer des caractères spéciaux pour rendre une partie ou la totalité du texte optionnelle.

Dans le cas d’une icône, l’utilisateur peut sélectionner une icône dans une liste de référence faisant partie du logiciel 102. Il peut également ajouter une nouvelle icône à cette liste de référence en sélectionnant et en enregistrant une zone de l’écran de l’appareil sous test sur l’interface de visualisation 106.

Dans le cas d’une couleur, l’utilisateur sélectionne une couleur à chercher parmi une liste de couleurs de référence faisant partie du logiciel 102 de pilotage.

Après l’exécution d’une séquence de test comportant une action de contrôle visuel, le logiciel 102 indique si la recherche est concluante ou non.

De manière avantageuse, le contrôle de la présence d’un élément sur l’écran de l’appareil sous test peut permettre d’attendre un changement d’état du système sous test avant de passer à l’action suivante de la séquence de test. Le contrôle peut être réalisé une seule fois ou il peut être répété plusieurs fois pendant un intervalle de temps imparti par l’utilisateur. Dans ce dernier cas, si l’action de contrôle ne donne pas de résultat positif au bout du temps imparti, le logiciel 102 peut arrêter la séquence de test.

Par « changement d’état du système », on entend ici un changement de l’affichage de l’écran de l’appareil sous test, ou encore un changement d’une indication visuelle située en-dehors de l’écran de l’appareil, comme par exemple l’allumage d’un voyant lumineux.

A titre d’exemple, dans le cadre du test d’un terminal de paiement électronique, une action de contrôle visuel peut s’insérer dans une séquence de test de la façon suivante. Dans un premier temps, le banc de test insère une carte dans le terminal de paiement électronique et le palpeur du banc de test entre le code de la carte et presse sur le bouton de validation. Une succession d’actions de contrôle visuel peut alors être mise en œuvre pour rechercher successivement sur l’écran du terminal de paiement, les mots « CODE BON », « AUTORISATION EN COURS », « PAIEMENT ACCEPTE » puis « APPUYER SUR V POUR 2 ^ème TICKET ».

Les actions de contrôle visuel peuvent également être conditionnelles. En reprenant l’exemple précédent, après la recherche des mots « AUTORISATION EN COURS », cela peut se traduire par la recherche soit des mots « PAIEMENT ACCEPTE » soit des mots « CENTRE NON ATTEINT, REESSAYER ? », en prévision d’une difficulté du terminal de paiement à joindre le centre bancaire. Des actions différentes peuvent ensuite être mises en œuvre en fonction du résultat de cette action de contrôle visuel.

Une action de contrôle visuel peut être associée à une action d’appui. Ainsi, l’utilisateur peut définir une action de recherche d’un élément, par exemple un texte ou une icône, à la suite de laquelle le logiciel 102 commande au banc de test 1 d’effectuer un appui sur l’élément recherché.

Avantageusement, cela permet d’effectuer un appui automatisé sur un élément dont la position peut changer d’un test à un autre.

A titre d’exemple, cela peut servir à la sélection d’un réseau sans fil de type WiFi dans une page de configuration d’un appareil. Une fois la recherche de réseau lancée, les réseaux s’affichent dans Tordre de détection qui varie en permanence. L’utilisateur du banc de test ne peut donc pas enregistrer de position fixe pour la sélection du réseau WiFi voulu. L’association d’une action de contrôle visuel et d’une action d’appui permet avantageusement de chercher le nom du réseau WiFi désiré sur l’écran de l’appareil et de retrouver sa position dans l’espace pour effectuer un appui permettant de sélectionner le bon réseau.

Le calcul de la position dans l’espace prend avantageusement en compte la position du mot recherché dans l’image capturée par la caméra, la position de la caméra et la configuration de l’appareil sous test (notamment ses dimensions et la position de l’écran). Ce calcul peut être mis en œuvre lorsque l’écran est parallèle à la caméra mais également lorsque l’écran est incliné par rapport à la caméra.

Les actions de contrôle ou de commande du banc de test 1 peuvent également comprendre des actions de contrôle sonore. Ce type d’actions permet d’analyser un son émis par l’appareil sous test. De préférence, l’utilisateur peut choisir une action de contrôle de dépassement d’un niveau sonore déterminé par l’utilisateur ou encore une action de détection d’un son particulier.

Le logiciel 102 permet, dans le cas du contrôle d’un niveau sonore, de déterminer un seuil, par exemple exprimé en décibel, et de choisir si le niveau sonore doit être supérieur ou inférieur à ce seuil.

Le logiciel 102 permet, dans le cas d’une action de détection d’un son, de choisir un son dans une liste de référence faisant partie du logiciel 102 ou d’enregistrer un nouveau son et de l’intégrer à cette liste de référence.

Ces actions de contrôle ou de détection de son peuvent être mises en œuvre pendant une seule étape d’une séquence de test ou pendant plusieurs étapes d’une séquence de test. Par exemple, une action de détection d’un son peut être réalisée pendant une action d’appui spécifique, ou encore tout au long d’une durée déterminée au cours de l’exécution de la séquence de test.

Les actions de contrôle ou de commande du banc de test 1 peuvent également comprendre des actions de contrôle-commande des entrées- sorties du dispositif 100.

De préférence, le logiciel 102 permet d’afficher l’état courant des entrées-sorties du dispositif 100.

Il permet également à l’utilisateur de choisir et de caractériser une action de commande consistant à définir l’état à appliquer sur une ou plusieurs sorties lors de l’action suivante de la séquence de test.

Il permet également de choisir et de caractériser une action de contrôle consistant à définir un test logique appliqué sur une ou plusieurs entrées lors de l’action suivante de la séquence de test.

Ce test logique peut par exemple consister à comparer les valeurs de plusieurs entrées ou à comparer la valeur d’une entrée avec une valeur de référence.

Avantageusement, le contrôle de l’état d’une entrée peut permettre d’attendre un changement d’état du système de l’appareil sous test.

De préférence, G utilisateur peut caractériser l’action de contrôle en déterminant si le test logique doit être réalisé une seule fois ou s’il doit être répété pendant un intervalle de temps maximum défini par l’utilisateur. De préférence encore, si le test logique ne réussit pas pendant l’intervalle de temps imparti, la séquence de test est interrompue. Une fois qu’une séquence de test est enregistrée sur le dispositif 100, le logiciel 102 autorise l’exécution totale ou partielle de la séquence de test lorsque le dispositif 100 est connecté à un robot 1 configuré pour tester un appareil/équipement.

De manière avantageuse, au cours de l’exécution d’une séquence de test, le logiciel 102 affiche pour chaque action de contrôle effectuée le résultat de l’action. Si le test réalisé n’est pas concluant (par exemple, la recherche d’un élément n’a pas donné de résultat ou un test logique n’a pas donné de résultat positif), une erreur est générée. De préférence, si une erreur empêche la poursuite d’une séquence de test, le logiciel 102 interrompt la séquence de test. L’invention n’est pas limitée aux exemples qui viennent d’être décrits ; on peut notamment combiner entre elles des caractéristiques des exemples illustrés au sein de variantes non illustrées.

D’autres variantes et améliorations peuvent être envisagées sans pour autant sortir du cadre de l’invention.