FR3165331A1 - Procede et dispositif de test d’applications embarquees dans des systemes electroniques - Google Patents

Procede et dispositif de test d’applications embarquees dans des systemes electroniques

Info

Publication number
FR3165331A1
FR3165331A1 FR2408639A FR2408639A FR3165331A1 FR 3165331 A1 FR3165331 A1 FR 3165331A1 FR 2408639 A FR2408639 A FR 2408639A FR 2408639 A FR2408639 A FR 2408639A FR 3165331 A1 FR3165331 A1 FR 3165331A1
Authority
FR
France
Prior art keywords
data
electronic system
communication bus
test device
test
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2408639A
Other languages
English (en)
Inventor
Alexis Masson
Samuel Brillet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
STMicroelectronics International NV Switzerland
STMicroelectronics International NV
Original Assignee
STMicroelectronics International NV Switzerland
STMicroelectronics International NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by STMicroelectronics International NV Switzerland, STMicroelectronics International NV filed Critical STMicroelectronics International NV Switzerland
Priority to FR2408639A priority Critical patent/FR3165331A1/fr
Priority to US19/258,252 priority patent/US20260036622A1/en
Publication of FR3165331A1 publication Critical patent/FR3165331A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/31712—Input or output aspects
    • G01R31/31713—Input or output interfaces for test, e.g. test pins, buffers
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/31703—Comparison aspects, e.g. signature analysis, comparators
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Il est proposé un dispositif de test comprenant au moins une première interface de communication (200) pour recevoir des données d’un système électronique à tester et transmettre des données audit système électronique, au moins une seconde interface de communication, distincte de ladite première interface de communication, pour transmettre des données à un ordinateur de test dudit système électronique, le dispositif de test étant configuré pour recevoir au moins une donnée dudit système électronique et transmettre au moins une donnée audit système électronique, via un premier bus de communication relié à ladite première interface (200), de façon autonome, et étant configuré pour transmettre, via un second bus de communication relié à ladite seconde interface (205), au moins une donnée représentative d’au moins une donnée reçue et/ou d’au moins une donnée transmise via ledit premier bus de communication. Figure pour l’abrégé : Fig. 2

Description

PROCEDE ET DISPOSITIF DE TEST D’APPLICATIONS EMBARQUEES DANS DES SYSTEMES ELECTRONIQUES
Des modes de réalisation concernent le domaine des tests de systèmes électroniques, en particulier des tests d’applications embarquées dans des systèmes électroniques utilisés selon un mode de type maître ou contrôleur, comprenant des bus de communication rapides, plus particulièrement encore des tests des pilotes (ou drivers en terminologie anglo-saxonne), à l’aide d’ordinateurs standards.
Les systèmes électroniques programmables étant de plus en plus complexes et, souvent, de plus en plus génériques, ils sont utilisés dans de nombreux contextes et connaissent de régulières mises à jour, notamment logicielles. Ces systèmes sont généralement pourvus d’un ou plusieurs bus pour recevoir et/ou transmettre des données, par exemple pour obtenir des données de capteurs et/ou contrôler des actuateurs.
Il en résulte un besoin de tests pour vérifier que le comportement d’applications embarquées dans ces systèmes électroniques, permettant l’utilisation de ces derniers dans de nouvelles situations ou de nouvelles configurations, est conforme aux attentes. Pour tester de telles applications, comprenant la transmission ou la réception de données, le ou les bus de communication du système testé doivent être reliés à des éléments de communication opérationnels, capables d’interagir conformément aux spécificités du bus utilisé, notamment en termes de temps de réponse et de protocole.
Pour tester une application embarquée dans un système électronique, l’application est chargée dans ce système électronique puis exécutée et un système distinct, par exemple un ordinateur de gestion de test, analyse le comportement du système électronique testé, notamment au niveau des échanges de données sur le ou les bus de communication.
Cependant, la présence de bus de communication temps réel ou de faible latence dans les systèmes électroniques à tester, par exemple de bus de type I2C (sigle de Inter-Integrated Circuit), SPI (sigle de Serial Peripheral Interface) ou UART (sigle de Universal Asynchronous Receiver Transmitter), ne permet pas d’effectuer des tests en temps réel avec un ordinateur standard de type personnel, par exemple pour dérouler un scénario de test.
En effet, un ordinateur standard exécutant un scénario de test est trop lent par rapport à un bus de communication de type I2C, SPI ou UART.
Il existe donc un besoin pour une solution de tests simple à mettre en œuvre, suffisamment générique pour être utilisable dans de nombreux contextes et pouvant effectuer un grand nombre de tests de façon autonome. Cette solution doit permettre de tester le comportement d’une application embarquée dans un dispositif électronique recevant et/ou transmettant des données via un bus de communication temps réel ou de faible latence, par exemple de type I2C, SPI ou UART, notamment selon un mode de communication de type « maître » ou « contrôleur » (i.e., selon lequel le dispositif électronique testé est à l’initiative de la transmission et/ou de la réception de données).
Selon un aspect, il est proposé un dispositif de test comprenant au moins une première interface de communication pour recevoir des données d’un système électronique à tester et transmettre des données audit système électronique, au moins une seconde interface de communication, distincte de ladite première interface de communication, pour transmettre des données à un ordinateur de test dudit système électronique, le dispositif de test étant configuré pour recevoir au moins une donnée dudit système électronique et/ou transmettre au moins une donnée audit système électronique, via un premier bus de communication relié à ladite première interface, de façon autonome, et étant configuré pour transmettre, via un second bus de communication relié à ladite seconde interface, au moins une donnée représentative d’au moins une donnée reçue et/ou d’au moins une donnée transmise via ledit premier bus de communication.
Un tel dispositif permet d’effectuer un grand nombre de tests, sans intervention manuelle, d’une application embarquée dans un dispositif électronique.
Selon des modes de réalisation, ladite donnée reçue est une requête, le dispositif de test étant configuré pour transmettre ladite au moins une donnée audit système électronique en réponse à ladite requête.
Selon des modes de réalisation, le dispositif de test comprend une mémoire pour stocker ladite au moins une donnée à transmettre et une unité de traitement de données pour déterminer ladite au moins une donnée à transmettre à partir.
Selon des modes de réalisation, le dispositif comprend en outre un sélecteur pour transmettre ladite au moins une donnée reçue audit système électronique via ledit premier bus de communication.
Selon un autre aspect, il est proposé un ensemble intégré comprenant le dispositif de test décrit précédemment et un système électronique à tester.
Un tel dispositif permet d’effectuer un grand nombre de tests, sans intervention manuelle, d’une application embarquée dans le dispositif électronique.
Selon un autre aspect encore, il est proposé un procédé de test d’une application embarquée dans un système électronique, ledit système électronique étant connecté, via un premier bus de communication, à un dispositif de test tel que décrit précédemment, ledit dispositif de test étant en outre connecté à un ordinateur de test via un second bus de communication distinct dudit premier bus de communication, le procédé étant mis en œuvre dans ledit dispositif de test et comprenant,
  • détection d’un événement pour transmettre au moins une donnée audit système électronique via ledit premier bus de communication et détermination de ladite au moins une donnée à transmettre,
  • transmission, audit système électronique, de ladite au moins une donnée via ledit premier bus de communication et
  • transmission, audit ordinateur de test, via ledit second bus de communication, d’au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication et/ou d’au moins une donnée transmise audit système électronique via ledit premier bus de communication.
Un tel procédé permet d’effectuer un grand nombre de tests, sans intervention manuelle, d’une application embarquée dans un dispositif électronique. Un tel procédé de test peut viser une interaction quelconque à un moment quelconque du cycle de développement du système électronique (e.g., débogage, prototypage, etc.).
Toujours selon un autre aspect, il est proposé un procédé de test d’une application embarquée dans un système électronique, ledit système électronique étant connecté, via un premier bus de communication, à un dispositif de test tel que décrit précédemment, le procédé étant mis en œuvre dans un ordinateur de test connecté audit dispositif de test via un second bus de communication et comprenant,
  • transmission, audit dispositif de test, d’au moins une instruction de configuration pour transmettre au moins une donnée audit système électronique, ladite au moins une instruction comprenant au moins une indication de sélection pour sélectionner ladite au moins une donnée à transmettre audit système électronique via ledit premier bus de communication et
  • transmission, audit dispositif de test, d’au moins une instruction de lecture pour recevoir, via ledit second bus de communication, au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication et/ou d’au moins une donnée transmise audit système électronique via ledit premier bus de communication.
Un tel procédé permet d’effectuer un grand nombre de tests, sans intervention manuelle, d’une application embarquée dans un dispositif électronique.
Selon des modes de réalisation, ladite transmission d’au moins une instruction de lecture est répétée selon un scénario de test de ladite application embarquée.
Toujours selon des modes de réalisation, ladite transmission d’au moins une instruction de configuration est effectuée avant la transmission répétée d’instructions de lecture.
Toujours selon des modes de réalisation, le procédé comprend en outre une réception de ladite au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication et/ou d’au moins une donnée transmise audit système électronique via ledit premier bus de communication et une comparaison de ladite au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication et/ou d’au moins une donnée transmise audit système électronique via ledit premier bus de communication avec une donnée attendue.
D’autres avantages et caractéristiques apparaîtront à l’examen de la description détaillée de modes de réalisation et de mise en œuvre, nullement limitatifs, et des dessins annexés sur lesquels :
FIG. 1 ;
FIG. 2 ;
FIG. 3;
FIG. 4;
FIG. 5;
FIG. 5;
FIG. 6illustrent des modes de réalisation.
Selon des modes de réalisation, un environnement de test d’une application à tester, embarquée dans un système électronique, comprend un ordinateur de test configuré pour exécuter un scénario de test et un dispositif de test configuré pour échanger des données avec le système électronique, selon des caractéristiques d’un bus de communication de ce dernier. Des données représentatives de données reçues du système électronique, par le dispositif de test, et/ou de données transmises, au système électronique, par le dispositif de test sont mémorisées dans le dispositif de test et peuvent être transmises à l’ordinateur de test, indépendamment des échanges de données entre le système électronique et le dispositif de test. L’ordinateur de test peut ainsi accéder aux données de tests sans devoir interagir directement avec le bus de communication du système électronique. L’ordinateur de test est par exemple un ordinateur de type PC, un serveur, un système embarqué, etc., pouvant aussi être appelé contrôleur ou orchestrateur.
LaFIG. 1illustre schématiquement un environnement de test 100 comprenant un système électronique 105 embarquant une application à tester, aussi appelé DUT (sigle de Device Under Test), un ordinateur de test 110 et un dispositif de test 115.
Comme illustré, le système électronique 105 est relié au dispositif de test 115 par un premier bus de communication 120, par exemple un bus de communication de type I2C (sigle de Inter-Integrated Circuit), SPI sigle de Serial Peripheral Interface) ou UART (sigle de Universal Asynchronous Receiver Transmitter). Le système électronique 105 est ici de type « maître » ou « contrôleur », c’est-à-dire qu’il est à l’initiative de la transmission et/ou de la réception de données sur le bus de communication 120. Le dispositif de test 115 est configuré pour recevoir et/ou transmettre des données sur le bus de communication 120, selon le protocole de ce dernier, et répondre aux sollicitations du système électronique 105. Le dispositif de test permet ainsi le test de l’application embarquée dans le système électronique 105 lorsqu’elle fait appel à ce bus (en vérifiant que les accès au bus sont conformes aux attentes).
Comme illustré également, le dispositif de test 115 est par ailleurs relié à l’ordinateur de test 110 par un second bus de communication 125, distinct du premier bus de communication, par exemple un bus de communication de type USB (sigle de Universal Serial Bus). L’ordinateur de test 110 peut ainsi configurer le dispositif de test 115, par exemple pour lui indiquer comment répondre aux sollicitations du système électronique 105 sur le bus de communication 120 et pour accéder à des données mémorisées dans le dispositif de test 115. Les données mémorisées sont par exemple des données représentatives de données reçues du système électronique, par le dispositif de test, et/ou de données transmises, au système électronique, par le dispositif de test. Elles sont mémorisées dans le dispositif de test et peuvent être transmises à l’ordinateur de test, via le second bus de communication 125, indépendamment de la transmission et/ou réception de ces données via le premier bus de communication 120.
Enfin, selon des modes de réalisation particuliers, le système électronique 105 est relié à l’ordinateur de test 110 par un troisième bus de communication 130, par exemple un bus de communication de type USB. Le bus de communication 130 peut notamment être utilisé avant le test de l’application embarquée dans le système électronique 105, par exemple pour charger l’application et initialiser le système électronique 105.
Il est observé ici que le système électronique 105 et le dispositif de test 115 peuvent être des éléments distincts, peuvent être montés sur une même carte ou peuvent être intégrés dans un même circuit, par exemple sous forme d’un SoC (acronyme de System on a Chip).
LaFIG. 2illustre schématiquement un exemple d’architecture du dispositif de test 115.
Comme illustré, le dispositif de test 115 comprend ici une première interface 200 vers le premier bus de communication 120, par exemple de type I2C, SPI ou UART, et une seconde interface 205 vers le second bus de communication 125, par exemple de type USB. Ces interfaces permettent de recevoir et/ou transmettre des données selon un protocole déterminé lié au type de bus utilisé. Le dispositif de test 115 comprend également une unité de traitement de données 210, par exemple pour analyser des commandes reçues via l’interface 205, configurer le dispositif de test selon des commandes reçues, sélectionner des données à transmettre sur le premier bus de communication et/ou sur le second bus de communication, etc.
Le dispositif de test 115 comprend en outre une mémoire tampon de réception 215 (ou une zone de mémoire tampon de réception) pour stocker des données reçues via la première interface 200. Selon des modes de réalisation particuliers, il comprend aussi une mémoire tampon de transmission 220 (ou une zone de mémoire tampon de transmission) pour stocker des données reçues via la seconde interface 205, à transmettre via la première interface 200. A titre d’illustration, les zones de mémoire tampon 215 et 220 peuvent apaprtenir à un même élément de mémoire, par exemple de type RAM (acronyme de random memory access), mais à des adresses différentes, ou à des éléments de mémoire différents. Toujours selon des modes de réalisation particuliers, le dispositif de test 115 comprend un agent 225 comprenant lui-même un sélecteur 230 pour utiliser la mémoire tampon de réception 215 ou la mémoire tampon de transmission 220 comme source de données à transmettre via la première interface 200. L’agent 225 permet également d’identifier les données reçues via la première interface 200, à mémoriser dans la mémoire tampon de réception 215. Il est ici configuré ou mis en œuvre par l’unité de traitement de données 210.
Comme illustré, l’accès en écriture de la mémoire tampon de réception 215 est reliée à la première interface 200, via l’agent 225, et son accès en lecture est reliée à l’unité de traitement de données 210. Cette dernière peut ainsi transférer des données reçues via la première interface et stockées dans cette mémoire vers le second bus de communication, via la seconde interface 205. Selon des modes de réalisation particuliers, l’accès en lecture de la mémoire tampon de réception 215 est en outre reliée au sélecteur 230. Selon d’autres modes de réalisation, par exemple en l’absence de mémoire tampon de transmission 220, l’accès en lecture de la mémoire tampon de réception 215 est reliée directement à la première interface 200, via l’agent 225, sans utiliser de sélecteur.
Comme illustré également, l’accès en écriture de la mémoire tampon de transmission 220 est reliée à l’unité de traitement de données 210 et son accès en lecture est reliée au sélecteur 230. Selon d’autres modes de réalisation, par exemple si l’accès en lecture de la mémoire tampon de réception 215 n’est reliée qu’à l’unité de traitement de données 210, l’accès en lecture de la mémoire tampon de transmission 220 est reliée directement à la première interface 200, via l’agent 225, sans utiliser de sélecteur.
Le dispositif de test 115 permet ainsi d’interagir en temps réel avec le premier bus de communication et transmettre, en temps différé, vers le second bus de communication, des données relatives à cette interaction.
LaFIG. 3illustre schématiquement un diagramme temporel d’un exemple de test d’une application embarquée dans le système électronique 105, à l’aide d’un ordinateur de test 110, ici de type PC (sigle de Personal Computer), et d’un dispositif de test 115.
Comme illustré, une première étape (étape 300) a ici pour objet la transmission, par l’ordinateur de test 110 au dispositif de test 115, d’une commande de configuration de test 300. Cette commande est ici transmise via le second bus de communication 125, par exemple de type USB. Cette étape comprend notamment la configuration du comportement du dispositif de test pour émettre des données sur le bus de communication le reliant au système de test, par exemple pour transmettre une donnée en réponse à une requête, et l’initialisation de ce bus de communication. Les données transmises peuvent être des données prédéterminées, des données préalablement reçues du système électronique, etc.
Dans une étape suivante (étape 305), l’ordinateur de test 110 transmet au système électronique 105 le programme à exécuter et une instruction d’initialisation. Après chargement, le système électronique 105 exécute l’application. Certaines étapes ne font pas appel au bus de communication (e.g., étape 310) alors que d’autres étapes ont pour objet la transmission de données ou l’obtention de données. A titre d’illustration, l’étape 315 est une requête pour obtenir des données. Cette requête est transmise par le système électronique 105, via le premier bus de communication 120. En réponse à cette requête, le dispositif de test 115 transmet au système électronique 105, via le premier bus de communication 120, une donnée (étape 320). Selon des modes de réalisation, la réponse doit être conforme au standard, notamment en termes de format et de temps de réponse, et aux attentes de l’application à tester (c’est elle qui impose le contenu de la réponse et le délai maximum). Son contenu, lié à la configuration du dispositif de test, peut être quelconque ou correspondre à un scénario contrôlé par l’ordinateur de test. Il peut notamment s’agir d’une donnée prédéterminée ou d’une donnée reçue du système électronique 105.
L’exécution de l’application se poursuit (étape 325) avec ou sans autres échanges de données.
Parallèlement à l’exécution de l’application dans le système électronique testé, l’ordinateur de test peut interroger le dispositif de test (étape 330), par exemple pour obtenir des données échangées entre le dispositif de test 115 et le système électronique 105 ou des données représentatives des données échangées. Les données échangées peuvent être les données transmises par le dispositif de test au système électronique et les données transmises par le système électronique au dispositif de test, uniquement les données transmises par le dispositif de test au système électronique, uniquement les données transmises par le système électronique au dispositif de test ou certaines de ces données.
En réponse à la requête de l’ordinateur de test reçue par le second bus de communication, le dispositif de test transmet les données demandées, stockées dans une mémoire interne, à l’ordinateur de test, via le même bus (étape 335).
LaFIG. 4illustre un exemple d’étapes mises en œuvre dans l’ordinateur de test 110 pour tester une application embarquée dans le système électronique 105.
Comme illustré, une première étape (étape 400) a pour objet la transmission d’une commande de configuration d’un dispositif de test. Comme décrit précédemment, cette commande comprend notamment la configuration de l’interface de communication vers ce bus de communication (e.g., l’interface 200 sur laFIG. 2).
Selon des modes de réalisation particuliers, la commande de configuration du dispositif de test indique en outre au dispositif de test comment interagir avec le système électronique auquel il est relié par un bus de communication, par exemple dans quelles conditions transmettre des données et/ou comment déterminer les données à transmettre.
Toujours selon des modes de réalisation particuliers, l’étape de transmission d’une commande de configuration comprend une étape de transmission d’une commande d’écriture de données, pour mémoriser des données dans le dispositif de test, ces données étant potentiellement transmises ulétrieurement, selon des conditions particulières, au système électronique. Selon d’autres modes de réalisation, la transmission de commandes d’écriture de données est effectuée indépendamment de la transmission de commandes de configuration.
Dans une étape suivante (étape 405), l’ordinateur de test adresse une commande de lecture au dispositif de test pour obtenir des données échangées entre le système électronique et le dispositif de test ou des données représentatives de ces données échangées. Comme décrit précédemment, les données échangées sont les données transmises par le système électronique au dispositif de test et les données transmises par le dispositif de test au système électronique, uniquement les données transmises par le système électronique au dispositif de test, uniquement données transmises par le dispositif de test au système électronique ou une partie de ces données.
En réponse, l’ordinateur de test reçoit les données demandées (étape 410) qui peuvent être comparées à des données attendues (étape 415). Les données reçues et, le cas échéant, les données attendues et/ou le résultat de la comparaion entre les données demandées et les données attendues sont mémorisées pour permettre une analyse a posteriori (étape 420). Les données mémorisées sont par exemple les données reçues et des données de contextes, par exemple liées au scénario de test.
Comme illustré, d’autres données peuvent être obtenues de la même façon et/ou le dispositif de test peut être reconfiguré pour effectuer d’autres tests.
Après que tous les tests aient été effectués (ou au fur et à mesure qu’ils sont effectués), un rapport de test peut être généré (étape 425).
LaFIG. 5illustre un exemple d’étapes mises en œuvre dans le dispositif de test 115 pour tester une application embarquée dans le système électronique 105.
Comme illustré, une première étape (étape 500) a pour objet la réception d’une commande. Cette commande peut être reçue d’un ordinateur de test. Suite à la réception d’une commande, un test est effectué pour déterminer si la commande reçue est une commande de configuration du dispositif de test (étape 505), par exemple pour indiquer au dispositif de test comment interagir avec le système électronique auquel il est relié par un bus de communication. Selon des modes de réalisation, cette commande comprend également la configuration de l’interface de ce bus de communication.
Après réception de la commande et si la commande reçue est une commande de configuration, le dispositif de test est configuré selon la commande reçue (étape 505). Par exemple, en lien avec laFIG. 2, l’unité de traitement de données 210 configure la première interface 200 et l’agent 225.
Si la commande reçue n’est pas une commande de configuration, un test est ici effectué pour déterminer si la commande reçue est une commande de lecture de données mémorisées dans le dispositif de test, c’est-à-dire une commande d’obtention d’un rapport d’exécution (étape 515). Si une commande d’obtention d’un rapport d’exécution est reçue, les données correspondantes sont transmises (étape 520). Selon des modes de réalisation particuliers, les données à transmettre sont déterminées lors de la configuration du dispositif de test. Selon d’autres modes de réalisation, les données à transmettre sont indiquées dans la commande de lecture ou d’obtention de données. Par exemple, en lien avec laFIG. 2, l’unité de traitement de données 210 lit les données demandées dans la mémoire tampon de réception 215 et les transmet.
Si la commande reçue n’est ni une commande de configuration ni une commande d’obtention d’un rapport d’exécution, un test est ici effectué pour déterminer si la commande reçue est une commande d’écriture de données, par exemple de données à mémoriser pour être transmises au système électronique (étape 525). Si une commande d’écriture de données est reçue, par exemple avec les données à mémoriser, les données sont mémorisées (étape 530). Par exemple, en lien avec laFIG. 2, l’unité de traitement de données 210 stocke les données reçues dans la mémoire tampon de transmission 220.
Après avoir configuré le dispositif de test, lu des données ou mémorisé des données ou si la commande reçue n’est, selon cet exemple, ni une commande de configuration, ni une commande d’obtention d’un rapport d’exécution, ni une commmande d’écriture de données, l’algorithme boucle sur lui-même pour traiter de nouvelles commandes jusqu’à ce qu’il y soit mis fin.
Les étapes décrites sur laFIG. 5sont par exemple mise en œuvre dans l’unité de traitement de données 210 sur laFIG. 2à laquelle peut être associée une mémoire pour mémoriser des instructions à exécuter, des variables temporaires et des données à traiter ou traitées, comme décrit en référence à laFIG. 6.
Parallèlement et indépendamment des étapes de traitement de commandes reçues, le dispositif de test exécute une routine (par exemple l’agent 225 de laFIG. 2) pour déterminer si des conditions pour transmettre des données sont remplies ou si un événement particulier devant déclencher la transmission de données est détecté et, le cas échéant pour déterminer les données à transmettre au système électronique par le bus de communication reliant le dispositif de test au système électronique. Selon des modes de réalisation particuliers et comme illustré sur laFIG. 5, cette routine peut comprendre l’identification de conditions particulières ou d’événements (étape 550), par exemple la réception, du système électronique, d’une requête pour l’obtention de données (étape 560). Si des données sont à transmettre, elles sont transmises (étape 555). Comme décrit précédemment, des données à transmettre peuvent notamment être des données prédéterminées ou des données préalablement reçues du système électronique. Les conditions pour transmettre des données et/ou les paramètres de détermination des données à transmettre peuvent être liés à la configuration du dipositif de test, peuvent être préconfigurés dans le dispositif de test avec la possibilité de modifier la configuration ou peuvent être définis, sans possibilité de modification, dans le dispositif de test.
Les étapes décrites sur laFIG. 5sont par exemple mise en œuvre dans une unité dédiée de traitement de données ou dans l’unité de traitement de données 210 sur laFIG. 2, sous forme d’un processus indépendant du processus décrit en référence à laFIG. 5.
LaFIG. 6illustre un exemple d’un ordinateur de test pouvant mettre en œuvre un procédé selon des modes de réalisation particuliers de l’invention, notamment les procédés illustrés sur les figures 3 et 4. Le calculateur 600 est par exemple un ordinateur de type PC (sigle de personal computer en terminologie anglo-saxonne) embarqué.
Comme illustré, le calculateur 600 comprend un ou plusieurs bus interne de communication, partagés au non, auxquels sont reliés :
- une unité centrale de traitement ou microprocesseur 605 (CPU, sigle de central processing unit en terminologie anglo-saxonne) ;
- une mémoire vive ou mémoire cache 610 (RAM, acronyme de random access memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes mettant en œuvre les étapes décrites précédemment ;
- une mémoire morte 615 (ROM, acronyme de read only memory en terminologie anglo-saxonne) pouvant comporter un système d’exploitation et des programmes mettant en œuvre les étapes décrites précédemment ;
- un support de stockage 620, fixe ou amovible, pouvant notamment être utilisé pour stocker des instructions et/ou des données à traiter ou traitées ; et
- une interface de communication 625, permettant une connexion avec un dispositif de test.
Le calculateur 600 comprend en outre, de préférence, une interface réseau 640 reliée à un réseau de communication, par exemple un réseau de communication sans fil et/ou un réseau de communication local, l'interface étant apte à transmettre et à recevoir des données, notamment vers ou depuis un autre des serveurs, des ordinateurs, des tablettes et/ou des smartphones. L’interface de communication 640 est par exemple conforme à l’un des standards Bluetooth, WiFi, 3G, 4G, 5G, 6G, etc.
Le calculateur 600 peut également disposer d’un écran 645, notamment d’un afficheur tactile permettant à un utilisateur d’interagir avec des programmes mis en œuvre par le calculateur 600, et de moyens de saisie 650 tels qu’un clavier et/ou une souris permettant à un utilisateur d’interagir avec des programmes mis en œuvre par le calculateur 600.
Le bus interne de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le calculateur 600 ou reliés à lui. La représentation du bus interne de communication n'est pas limitative et, notamment, l'unité centrale de traitement est susceptible de communiquer des instructions à tout élément du calculateur 600 directement ou par l'intermédiaire d'un autre élément du calculateur 600.
Le code exécutable des programmes permettant au calculateur 600 de mettre en œuvre, en totalité ou en partie, le procédé selon l'invention, peut être stocké, par exemple, dans la mémoire morte 615. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication, via l'interface 640, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du calculateur 600 avant d'être exécutés.
L'unité centrale de traitement 605 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées, par exemple, dans la mémoire morte 615 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple la mémoire morte 615, sont transférés dans la mémoire vive 610 qui contient alors le code exécutable du ou des programmes, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre du procédé selon l'invention.
Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples. Elle s’étend à d’autres variantes.
En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.
Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le dispositif, le système et le procédé proposés comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.

Claims (10)

  1. Dispositif de test (115) comprenant au moins une première interface de communication (200) pour recevoir des données d’un système électronique (105) à tester et transmettre des données audit système électronique, au moins une seconde interface de communication, distincte de ladite première interface de communication, pour transmettre des données à un ordinateur de test (110) dudit système électronique, le dispositif de test (115) étant configuré pour recevoir au moins une donnée dudit système électronique (105) et/ou transmettre au moins une donnée audit système électronique (105), via un premier bus de communication (120) relié à ladite première interface, de façon autonome, et étant configuré pour transmettre, via un second bus de communication (125) relié à ladite seconde interface, au moins une donnée représentative d’au moins une donnée reçue et/ou d’au moins une donnée transmise via ledit premier bus de communication.
  2. Dispositif selon la revendication 1, selon lequel ladite donnée reçue est une requête, le dispositif de test étant configuré pour transmettre ladite au moins une donnée audit système électronique en réponse à ladite requête.
  3. Dispositif selon la revendication 1 ou la revendication 2, comprenant une mémoire (220) pour stocker ladite au moins une donnée à transmettre et une unité de traitement de données (210) pour déterminer ladite au moins une donnée à transmettre.
  4. Dispositif selon l’une quelconque des revendications 1 à 3, comprenant en outre un sélecteur (230) pour transmettre ladite au moins une donnée reçue audit système électronique via ledit premier bus de communication.
  5. Ensemble intégré comprenant le dispositif de test selon l’une quelconque des revendications 1 à 4 et un système électronique à tester.
  6. Procédé de test d’une application embarquée dans un système électronique (105), ledit système électronique étant connecté, via un premier bus de communication (120), à un dispositif de test (115) selon l’une quelconque des revendications 1 à 4, ledit dispositif de test (115) étant en outre connecté à un ordinateur de test (110) via un second bus de communication (125) distinct dudit premier bus de communication, le procédé étant mis en œuvre dans ledit dispositif de test et comprenant,
    • détection (550) d’un événement pour transmettre au moins une donnée audit système électronique via ledit premier bus de communication (120) et détermination de ladite au moins une donnée à transmettre,
    • transmission (555), audit système électronique (105), de ladite au moins une donnée via ledit premier bus de communication (120) et
    • transmission (520), audit ordinateur de test (110), via ledit second bus de communication (125), d’au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication (120) et/ou d’au moins une donnée transmise audit système électronique (105) via ledit premier bus de communication (120).
  7. Procédé de test d’une application embarquée dans un système électronique (105), ledit système électronique étant connecté, via un premier bus de communication (120), à un dispositif de test (115) selon l’une quelconque des revendications 1 à 4, le procédé étant mis en œuvre dans un ordinateur de test (110) connecté audit dispositif de test (115) via un second bus de communication (125) et comprenant,
    • transmission (400), audit dispositif de test (115), d’au moins une instruction de configuration pour transmettre au moins une donnée audit système électronique (105), ladite au moins une instruction comprenant au moins une indication de sélection pour sélectionner ladite au moins une donnée à transmettre audit système électronique (105) via ledit premier bus de communication (120) et
    • transmission (405), audit dispositif de test (115), d’au moins une instruction de lecture pour recevoir, via ledit second bus de communication (125), au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication (120) et/ou d’au moins une donnée transmise audit système électronique (105) via ledit premier bus de communication (120).
  8. Procédé selon la revendication 7, selon lequel ladite transmission d’au moins une instruction de lecture est répétée selon un scénario de test de ladite application embarquée.
  9. Procédé selon la revendication 8, selon lequel ladite transmission d’au moins une instruction de configuration est effectuée avant la transmission répétée d’instructions de lecture.
  10. Procédé selon l’une quelconque des revendications 7 à 9, comprenant en outre une réception (410) de ladite au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication (120) et/ou d’au moins une donnée transmise audit système électronique (105) via ledit premier bus de communication (120) et une comparaison (415) de ladite au moins une donnée représentative d’au moins une donnée reçue dudit système électronique via ledit premier bus de communication (120) et/ou d’au moins une donnée transmise audit système électronique (105) via ledit premier bus de communication (120) avec une donnée attendue.
FR2408639A 2024-08-05 2024-08-05 Procede et dispositif de test d’applications embarquees dans des systemes electroniques Pending FR3165331A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2408639A FR3165331A1 (fr) 2024-08-05 2024-08-05 Procede et dispositif de test d’applications embarquees dans des systemes electroniques
US19/258,252 US20260036622A1 (en) 2024-08-05 2025-07-02 Method and device for testing applications embedded in electronic systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2408639A FR3165331A1 (fr) 2024-08-05 2024-08-05 Procede et dispositif de test d’applications embarquees dans des systemes electroniques
FR2408639 2024-08-05

Publications (1)

Publication Number Publication Date
FR3165331A1 true FR3165331A1 (fr) 2026-02-06

Family

ID=93211888

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2408639A Pending FR3165331A1 (fr) 2024-08-05 2024-08-05 Procede et dispositif de test d’applications embarquees dans des systemes electroniques

Country Status (2)

Country Link
US (1) US20260036622A1 (fr)
FR (1) FR3165331A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200225286A1 (en) * 2019-01-15 2020-07-16 Advantest Corporation Test apparatus and test method
CN117707864A (zh) * 2022-09-15 2024-03-15 爱德万测试公司 用于测试仪系统的处理器测试模式的生成和应用

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200225286A1 (en) * 2019-01-15 2020-07-16 Advantest Corporation Test apparatus and test method
CN117707864A (zh) * 2022-09-15 2024-03-15 爱德万测试公司 用于测试仪系统的处理器测试模式的生成和应用

Also Published As

Publication number Publication date
US20260036622A1 (en) 2026-02-05

Similar Documents

Publication Publication Date Title
US11762763B2 (en) Orchestration for automated performance testing
US20150082094A1 (en) Test Execution Spanning Cloud and Local Devices
US10474826B2 (en) Methods and apparatuses for improved app security testing
US9229758B2 (en) Passive monitoring of virtual systems using extensible indexing
CN113918373B (zh) 一种内存泄露监控方法、内存泄露检测方法及相应装置
CN109324962B (zh) 一种基于云物联技术的应用程序的测试方法及设备
CN110928770B (zh) 软件测试的方法、装置、系统、存储介质和电子设备
EP2380079B1 (fr) Cadre d'applications de réalisation de tâches en parallèle
US20190073249A1 (en) Message oriented middleware with integrated rules engine
CN110569046A (zh) 数据处理方法、装置、设备和存储介质
EP2553584A1 (fr) Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs
EP3502895A1 (fr) Commande de la consommation énergétique d'une grappe de serveurs
EP1310847A1 (fr) Système de téléchargement et de télémaintenance d'une carte électronique
FR3165331A1 (fr) Procede et dispositif de test d’applications embarquees dans des systemes electroniques
US20070234126A1 (en) Accelerating the testing and validation of new firmware components
CN119201603A (zh) 主机总线适配器的监测方法、装置和主板管理控制器
CN118227160A (zh) 服务更新方法及相关产品
CN113626295A (zh) 压测数据的处理方法、系统及计算机可读存储介质
CN111736841B (zh) 一种基于移动互联网的应用集成开发方法及系统
EP2798498B1 (fr) Mesure de performance d'une infrastructure informatique
US20170286181A1 (en) Deployment and execution of sensing and computational tasks in a network of computing devices
CN114090357A (zh) 一种硬盘性能测试方法、装置、电子设备及存储介质
CN119892614B (zh) 一种日志数据传输方法及系统、计算机设备及介质
CN112559090B (zh) 一种应用程序运行时性能事件的收集方法及相关装置
US7870276B1 (en) Interface plugin

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20260206