FR3026511A1 - Procede de test d'un composant logiciel - Google Patents

Abstract

La présente invention concerne un procédé de procédé de test d'un composant logiciel, caractérisé en ce qu'il comprend la mise en œuvre par des moyens de traitement de données (11) d'un équipement (1) d'étapes de : (a) Expression sur une interface (13) de l'équipement (1) d'un ou plusieurs stimuli, chaque stimulus définissant sur un intervalle temporel : ○ des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; ○ des conditions sur des paramètres de sortie dudit composant logiciel ; (b) Pour chaque stimulus, ○ génération de premiers signaux conformes auxdites valeurs des paramètres d'entrée ; ○ exécution dudit composant logiciel et application en entrée desdits premiers signaux générés ; ○ Observation de seconds signaux en sortie dudit composant logiciel ; (c) confirmation de la fiabilité du composant logiciel seulement si pour chaque stimulus les seconds signaux respectent lesdites conditions sur les paramètres de sortie.

Description

DOMAINE TECHNIQUE GENERAL La présente invention concerne la certification des logiciels critiques de l'avionique, et en particulier un procédé de test d'un composant logiciel.

ETAT DE L'ART Les aéronefs de dernière génération recourent massivement à l'informatique et utilisent pour cela des logiciels embarqués.

Des environnements de modélisation et génération permettent à des utilisateurs de produire automatiquement du code source à partir de modèles. On connait par exemple la génération automatique de code avec la Scade0 Suite, ou la génération automatique de code à partir de modèles Matlab® Simulink®.

Les normes DO-178 fixent les conditions de sécurité applicables aux logiciels critiques de l'avionique utilisés dans des aéronefs. Elles présentent cinq niveaux de criticité (de A à E) appelés niveaux DAL (« Development Assurance Level »), culminant au niveau A: un défaut du système ou sous-système étudié peut provoquer un problème catastrophique pouvant compromettre la sécurité du vol ou l'atterrissage, voire provoquer un crash de l'avion. Une fiabilité irréprochable de tout code informatique utilisé dans des logiciels critiques DO-178 DAL A (qu'il soit généré automatiquement ou manuellement) est par conséquent requise. Pour cela, il est nécessaire de mettre en oeuvre des procédures de test draconiennes permettant de vérifier les propriétés de ces logiciels embarqués. L'état de la technique actuelle consiste à soit réaliser cette vérification manuellement (via le débogueur d'un environnement de développement), soit à utiliser certains outils automatisés. Par exemple, on connait : - RTRT (« Rational Test RealTime »), qui est un outil permettant la réalisation de tests unitaires et la mesure de couverture structurelle de code. Il crée un squelette, à compléter avec les différents cas de tests. Il génère à partir de ce squelette des « stubs » (c'est-à-dire des modules logiciels simulant à minima la présence d'un autre), compile le tout et lance un simulateur avec lequel il est interfacé. Enfin il récupère les résultats d'exécution et génère un rapport. Cet outil permet de réellement tester du code comme s'il était déjà intégré à un calculateur, mais dans la mesure où il ne permet que des tests unitaires, toute opération de vérification demande une préparation extrêmement rigoureuse et donc très coûteuse en temps si l'on souhaite que les résultats soient vraiment fiables (en d'autres termes que l'on soit sûr que le composant fonctionne correctement dans tous les cas). - le Framework Eclipse, qui est un environnement de développement (IDE) permettant d'interfacer des plugins avec des objectifs de développement/vérification ciblés (par exemple le plugin CDT (« C/C++ Development Tooling) ») pour le développement de code source en C/C++). Le domaine d'application est toutefois restreint dans la mesure où il ne permet que la vérification de code manuellement saisi (et pas de composants générés avec une technologie Scade® ou Simulink® par exemple). Il serait ainsi souhaitable de disposer d'une méthode fiable et reproductible permettant d'automatiser le test de composants logiciels 25 critiques (jusqu'au niveau DO-178 DAL A), qu'ils soient générés automatiquement ou manuellement, et ce quelle que soit la complexité des systèmes à tester : mono/multi fréquentiels, calculs matriciels/flottants, etc. De plus il serait souhaitable que cette méthode minimise les impacts sur l'atelier de test et sur l'environnement de test d'un changement de 30 technologie d'un composant sous test. PRESENTATION DE L'INVENTION Selon un premier aspect, la présente invention se rapporte donc à un procédé de test d'un composant logiciel, caractérisé en ce qu'il comprend la mise en oeuvre par des moyens de traitement de données d'un équipement d'étapes de : (a) Expression sur une interface de l'équipement d'un ou plusieurs stimuli, chaque stimulus définissant sur un intervalle temporel : o des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; o des conditions sur des paramètres de sortie dudit composant logiciel ; (b) Pour chaque stimulus, o génération de premiers signaux conformes auxdites valeurs des paramètres d'entrée ; o exécution dudit composant logiciel et application en entrée desdits premiers signaux générés ; o Observation de seconds signaux en sortie dudit composant logiciel, (c) confirmation de la fiabilité du composant logiciel seulement si pour chaque stimulus les seconds signaux respectent lesdites conditions sur les paramètres de sortie. Selon d'autres caractéristiques avantageuses et non limitatives : - chaque stimulus définit une combinaison de fonctions élémentaires des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; - ladite combinaison de fonctions élémentaires comprend au moins une séquence temporelle de fonctions élémentaires ; - lesdites fonctions élémentaires sont choisies parmi un ensemble comprenant des rampes, des échelons et des attentes. - le procédé est tel que : Une attente est définie par une durée ; un échelon est défini par un paramètre choisi parmi une valeur d'un paramètre d'entrée et une valeur d'incrément, et - une rampe est définie par deux paramètres choisis parmi une valeur cible d'un paramètre d'entrée, une durée de variation dudit paramètre d'entrée, une vitesse de variation dudit paramètre d'entrée, et une valeur d'incrément. - chaque stimulus définit une combinaison de conditions comprenant au moins une séquence temporelle de conditions ; - au moins une condition de ladite séquence de conditions est une condition principale associée à au moins une condition auxiliaire définissant un intervalle de temps réduit au sein de la séquence sur lequel les seconds signaux doivent respecter la condition principale pour que la fiabilité du composant logiciel soit vérifiée à l'étape (c) ; - au moins une condition principale est associée à au moins deux conditions auxiliaires dont une condition de départ et une condition de fin ; - un code informatique dudit composant logiciel est généré automatiquement par les moyens de traitement de données de l'équipement préalablement à l'étape (a) ; - ladite génération de code informatique est de type Scade®, Simulink® ou VHDL ; - le procédé comprend en outre une étape (d) d'embarquement du composant logiciel sur un calculateur d'un appareil si la fiabilité du composant logiciel est confirmée.

Selon un deuxième aspect, l'invention concerne un équipement de test d'un composant logiciel, caractérisé en ce qu'il comprend : - une interface permettant l'expression d'un ou plusieurs stimuli, chaque stimulus définissant sur un intervalle temporel : o des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; o des conditions sur des paramètres de sortie dudit composant logiciel ; des moyens de traitement de données configurés pour la mise en oeuvre de : o un module de génération de premiers signaux conformes auxdites valeurs des paramètres d'entrée pour chaque stimulus ; o un module d'exécution dudit composant logiciel et d'application en entrée desdits premiers signaux générés pour chaque stimulus ; o un module d'observation de seconds signaux en sortie dudit composant logiciel pour chaque stimulus ; o un module de confirmation de la fiabilité du composant logiciel seulement si pour chaque stimulus les seconds signaux respectent lesdites conditions sur les paramètres de sortie. Selon un troisième et un quatrième aspect, l'invention concerne respectivement un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention ; et des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention.

PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux 30 figures annexées dont : - la figure 1 représente un système pour la mise en oeuvre du procédé selon l'invention ; - les figures 2a-2c illustrent divers exemples de structures de séquences de fonctions élémentaires des valeurs de paramètres d'entrée définissant un stimulus, utilisables dans le procédé selon l'invention ; la figure 3 représente les principales fonctions élémentaires permettant d'exprimer des stimuli utilisables dans le procédé selon l'invention ; les figures 4a-4d illustrent divers exemples de structures de séquences de conditions sur des paramètres de sortie définissant un stimulus, utilisables dans le procédé selon l'invention ; la figure 5 représente une interface utilisateur pour la mise en oeuvre du procédé selon l'invention.

DESCRIPTION DETAILLEE Architecture En référence à la figure 1, le présent procédé est un procédé de test automatisé d'un composant logiciel (par « composant logiciel », comme l'on verra on entend des instructions de code directement exécutables par un processeur, mais également une configuration d'un circuit logique de type FPGA (« field-programmable gate array »), qui peut être reprogrammé). Ce procédé est avantageusement conforme aux objectifs de la norme DO-330 TQL5 (qui est le pendant de la norme DO-178 DAL A relatif à la qualification des outils). Dans la suite de la présente description, par « outil de test » on entendra un programme utilisant le présent procédé. Le procédé est mis en oeuvre via un équipement 1 qui peut être n'importe quel poste informatique comprenant des moyens de traitement de données 11 (par exemple un processeur), des moyens de stockage de données 12 (par exemple un disque dur) et des moyens d'affichage d'une interface graphique 13 (par exemple un écran).

Des moyens de saisie 14 (tels qu'un clavier et une souris) permettent à un utilisateur souhaitant utiliser le procédé (et/ou programmer graphiquement) d'interagir avec l'interface graphique 13. Il est à noter que le présent procédé n'est pas limité à l'utilisation d'un poste de travail, et que d'autres types d'équipements tels qu'un serveur peuvent tout à fait être utilisés. Le composant logiciel est destiné à être embarqué (la terminologie « enfoui » est utilisée pour illustrer le fait que le composant logiciel est inaccessible par un utilisateur) sur un calculateur 21 d'un appareil 2, en particulier un véhicule tel qu'aéronef, un équipement de sécurité tel qu'une système de planification et de restitution de mission ou un système de combat individuel, etc. l'embarquement consiste en général en l'écriture du code du composant logiciel dans une mémoire morte du calculateur 21, en vue d'une exécution par un processeur du calculateur 21. Dans le cas où le composant logiciel est mis en oeuvre par un circuit logique de type FPGA, l'embarquement consiste en une reconfiguration adéquate du circuit logique (faisant partie du calculateur 21), ou à la réalisation d'un circuit intégré de type ASIC (« Application-Specific Integrated Circuit ») conforme à la configuration du FPGA et son intégration dans le calculateur 21.

Le composant logiciel consiste comme expliqué en des instructions de code compilées, qu'elles aient été générées manuellement par un programmeur, ou automatiquement par un générateur de code, en particulier via une technologie Scade®, Simulink® ou VHDL. Ce dernier 25 (« VHSIC1 Hardware Description Language ») est un langage de description de matériel, destiné à la programmation de circuits logiques de type FPGA. Le composant logiciel présente une entrée et une sortie. Il reçoit ainsi un signal d'entrée définissant des valeurs de paramètres d'entrée (les 30 variables du composant), qu'il traite, et produit en conséquence un signal de sortie définissant des valeurs de paramètres de sorties.

Le composant peut être mono ou multi fréquentiel. Dans le cas du mono-fréquentiel, il n'existe qu'une seule « tache » qui est exécutée à période constante, alors que dans le cas du multi-fréquentiel, il existe plusieurs « taches » qui sont exécuté à des fréquences différentes, bien que leurs fréquences propres soit constantes. Stimulus Le présent procédé vise à garantir que le code du composant logiciel est correctement généré, et que le composant logiciel est ainsi fiable. Le test consiste à vérifier que pour n'importe quelles valeurs des paramètres d'entrée, les valeurs des paramètres de sorties obtenues sont conformes à des valeurs obtenues. Il propose pour cela la construction de « stimuli » complexes (dont un une représentation schématique est donnée par la figure 2a), par opposition aux tests unitaires, qui permettent de réaliser des observations continues sur le logiciel. Un seul stimulus remplace ainsi efficacement un très grand nombre de tests unitaires, et permet même un niveau de sécurité accru.

Par stimulus, on entend des données de test dynamiques sur un intervalle temporel, données à la fois « d'entrée », et « de sortie » (respectivement en haut et en bas sur la figure 2a). Plus précisément, un stimulus définit sur un tel intervalle temporel : o des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; o des conditions sur des paramètres de sortie dudit composant logiciel. Dans une étape (a), un ou plusieurs stimuli sont exprimés par un utilisateur sur l'interface 13, 14 de l'équipement. Cette expression est par exemple une saisie sur les moyens de saisie 14. Pour cela, le présent procédé propose un langage structuré appelé TCML (« Test Case Modeling Language ») qui permet facilement de définir n'importe quel stimulus, via des mots clés proches du langage naturel. Dans ce langage, chaque stimulus définit une combinaison de 5 fonctions élémentaires (chacune associée à des mots-clés) des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps. Cette combinaison est plus particulièrement au moins une séquence temporelle (plusieurs séquences peuvent être enchaînées comme l'on voit sur la figure 2b, et/ou déroulées en parallèle comme l'on voit sur la figure 2c, et ce le 10 cas échéant à plusieurs niveaux puisque chaque « boite » représente une fonction élémentaire ou une combinaison de fonctions élémentaires. Des architectures encore plus complexes sont possibles, comme l'on verra plus loin) de fonctions élémentaires. Ces dernières sont en particulier choisies parmi un ensemble comprenant des « rampes », des « échelons », des 15 « attentes ». Ces trois fonctions basiques (déclinées en hausse/baisse pour l'échelon et la rampe) sont représentées sur la figure 3, avec les mots-clés possibles. Par exemple, si l'on souhaite augmenter la valeur d'un paramètre d'entrée « data » jusqu'à [Seuil+1] à la vitesse de [0.1] par seconde, 20 attendre [2.3] secondes, puis positionner instantanément « data » à la valeur [Seuil/2], on saisit en TCML le stimulus : rampUntil data [Seuil+1, 0.1] wait [2.3] s setFloat data [Seuil/2] 25 Ce stimulus comprend une première fonction élémentaire de type « rampe » (rampUntil), une deuxième fonction élémentaire de type « attente » (Wait) et une troisième fonction élémentaire de type « échelon » (setFloat). Une fonction élémentaire attente définit une durée séparant deux 30 autres fonctions élémentaires de la séquence (ici l'intervalle temporel d'attente est de 2.3 secondes). Une fonction élémentaire échelon est définie par un paramètre choisi parmi une valeur d'un paramètre d'entrée (ici [Seuil/2]) et une valeur d'incrément (qui peut être positif ou négatif). Une rampe est définie par deux paramètres choisis parmi une valeur cible d'un paramètre d'entrée (ici [Seuil+1]) une durée de variation dudit paramètre d'entrée, i.e. la durée pour atteindre la valeur cible (ici ce n'est pas le paramètre choisi, mais il aurait eu pour valeur [ABS(Seuil+1 - valeur initale)/0.1]), et une vitesse de variation dudit paramètre d'entrée (ici [0.1] par seconde), et une valeur d'incrément (ici ce n'est pas le paramètre choisi, il aurait eu pour valeur [Seuil+1 - valeur initiale]). Pour la rampe, 5 combinaisons de paramètres sont préférentiellement utilisées : valeur cible et durée pour l'atteindre ; incrément et durée pour l'atteindre ; valeur-cible et une vitesse de variation ; incrément et vitesse de variation ; vitesse et durée de variation. On peut également faire intervenir une notion de « condition d'arêt », par exemple Ramp data with [0.1] until [mesure > 12.0]. On comprendra que le présent procédé n'est pas limité aux fonctions élémentaires rampe échelon et attente, et que l'homme du métier saura utiliser d'autres fonctions contrôlant la valeur d'un paramètre en fonction du temps, éventuellement plus complexes (par exemple une fonction sinusoïdale). On notera en outre que chaque fonction peut contrôler plus d'un paramètre d'entrée, et que des combinaisons complexes peuvent être envisagées. Par exemple, le stimulus peut comprendre simultanément une fonction rampe sur un premier paramètre et une fonction échelon sur un deuxième paramètre. Un stimulus peut même comprendre autant de séquences de fonctions élémentaires que de paramètres d'entrée. De plus plusieurs séquences peuvent se dérouler en parallèle (figure 2c).

Comme expliqué, chaque stimulus définit en outre des conditions sur des paramètres de sortie dudit composant logiciel (dont un exemple est schématisé par la figure 4a). Comme pour les fonctions élémentaires, chaque stimulus définit les conditions sous forme d'une combinaison comprenant une ou plusieurs séquences temporelles (figure 4b) disposées le cas échéant en parallèle (figure 4c). Chaque élément rond (le « V » signifie vérification) désigne une condition ou une combinaison de conditions, au même titre qu'une boite désigne une fonction élémentaire ou une combinaison de fonctions élémentaires. La figure 4a représente par exemple comme l'on verra plus loin trois conditions principales. Dans le langage TCML, chaque condition de ladite séquence de 10 conditions peut être mise en parallèle avec une ou plusieurs fonctions élémentaires et/ou chaque fonction élémentaire peut être mise en correspondance avec une ou plusieurs conditions. Cela définit les intervalles de temps pendant lesquels les conditions doivent être vérifiées. Par exemple, sur la figure 4b, les six conditions représentées sont 15 associées aux neuf fonctions élémentaires, et doivent potentiellement être simultanément vérifiées sur toute la durée du stimulus. De façon plus complexe, la figure 4c propose six conditions et dix fonctions élémentaires, la condition Cl étant associée aux fonctions élémentaires F2 et F3, la condition C2 étant associée aux fonctions élémentaires F4 et F5, la 20 condition C3 étant associée aux fonctions élémentaires F6 à F8, la condition C4 étant associée aux fonctions élémentaires F9 et F10 (on note que les fonctions F6 à F8 d'une part et F9 et F10 d'autre part sont effectuées en parallèle, ce qui fait que pendant un intervalle de temps au moins les conditions C3 et C4 devront être vérifiées simultanément), et 25 enfin la condition C5 est associée à tout le stimulus (et doit être vérifiée en même temps que toutes les autres conditions). Chaque condition de la séquence peut être une condition simple, c'est-à-dire à vérifier uniformément sur l'ensemble de l'intervalle de temps prévu, ou une condition plus complexe. De façon générale, on parle de 30 « réduction de contexte », c'est-à-dire de conditions annexes réduisant l'intervalle de temps durant laquelle chaque condition d'une séquence de conditions doit être vérifiée.

Par exemple, la figure 4a représente trois conditions principales (conditions portant réellement sur les paramètres de sortie), chacune associée à une ou deux conditions auxiliaires. Par exemple la deuxième condition principale représentée est «Si a pour valeur Cl », et les deux conditions auxiliaires sont « A<=B » et « A<C » (A et B étant des paramètres d'entrée). Ainsi, les conditions auxiliaires nuancent la condition principale : il n'est pas nécessaire que la condition principale soit vérifiée sur tout l'intervalle de temps, mais seulement sur une sous-partie de celui-ci ou les deux conditions auxiliaire « A<=B » et « A<C » sont vérifiées. Ladite sous-partie n'est pas nécessairement continue, puisque les conditions auxiliaires peuvent dynamiquement varier. Et si par exemple A était toujours supérieur à B ou C, alors, la condition principale serait toujours vraie (puisque le sous-intervalle de temps associé est vide). De façon générale, on comprendra que pour réduire le contexte il suffit qu'au moins une condition de ladite séquence de conditions soit une condition principale associée à au moins une condition auxiliaire définissant un intervalle de temps réduit au sein de la séquence sur lequel les seconds signaux doivent respecter la condition principale pour que la fiabilité du composant logiciel soit vérifiée à l'étape (c).

Un cas particulier et non-limitatif de réduction de contexte est l'association d'une condition de départ (première condition auxiliaire) et une condition de fin (deuxième condition auxiliaire). Par exemple, si l'on souhaite vérifier qu'à partir de l'instant où [Conditionl =condition de départ] et avant que [Condition2=condition de fin], on observe toujours [Condition3=condition de la séquence à tester], on saisit en TCML le stimulus : FROM [Condition1] BEFORE [Condition?' ALWAYS [Condition3] On note à nouveau que seule la condition de la séquence à tester porte nécessairement sur les valeurs des paramètres de sortie (elle définit des valeurs de paramètres de sortie « attendus ») fonction le cas échéant des paramètres d'entrée que l'on peut aussi prendre pour référence, alors que les conditions de départ et de sortie peuvent par exemple être simplement des conditions temporelles.

L'homme du métier comprendra que des séquences bien plus complexes (utilisant davantage de mots clés) sont possibles. On citera par exemple les mots SINCE et WHILE. Test du composant Dans une étape (b), chaque stimulus va être « injecté » dans le composant logiciel à tester par les moyens de traitement de données 11. Pour cela sont générés des premiers signaux (évoluant dans le temps) conformes auxdites valeurs des paramètres d'entrée définies par le stimulus. Les premiers signaux sont des signaux d'entrée. Le composant logiciel est alors exécuté et lesdits premiers signaux générés sont appliqués à son entrée. En réponse, sont observés des seconds signaux en sortie dudit composant logiciel. Cette architecture permet que les parties de l'outil dépendantes des 20 technologies d'implémentation des composants logiciels sous test soient dé-corrélées du moteur de test. Ceci permet une forte évolutivité de l'outil puisque l'ajout d'une nouvelle configuration de l'outil, telle que l'implémentation d'une nouvelle technologie de modélisation par exemple, ne vient pas remettre en cause les scénarios de tests existants qui peuvent 25 ainsi être réutilisés. En particulier, les stimulii sont écrit en fonction de paramètres dont les valeurs peuvent êtres « centralisées » dans un fichier de configuration. La réutilisabilité est aussi possible en cas de modification paramétrique. De façon préférée, les interfaces des composants logiciels sous test 30 sont entièrement décrites dans un langage générique, en particulier XML (« eXtensible Markup Langage »), et fournies ainsi à l'atelier de test dans un format agnostique vis-à-vis des particularités des technologies telles que ScadeeSimulink®/VHDL. Dans une dernière étape (c) du procédé, l'outil de test conclut sur la vérification : la fiabilité du composant logiciel est confirmée seulement si pour chaque stimulus les seconds signaux respectent ladite séquence de conditions sur les paramètres de sortie, en d'autres termes si à tout instant de l'intervalle temporel la partie « condition sur la sortie » du stimulus est vraie.

Au moindre écart supérieur à un seuil de tolérance donné, un problème est détecté sur le composant logiciel, et son code sera réexaminé. Si la fiabilité est confirmée, le procédé peut comprendre une étape (d) ultérieure d'embarquement du composant logiciel sur le calculateur 21 du véhicule 2 (l'aéronef).

Système Selon un deuxième aspect, l'invention concerne un équipement 1 pour la mise en oeuvre du précédent procédé. L'équipement 1 est 20 éventuellement un poste de génération de code informatique. Cet équipement comprend des moyens d'interface 13, 14 (plus précisément des moyens d'affichage 13 tel qu'un écran et des moyens de saisie 14 tels qu'un clavier) permettant l'expression d'un ou plusieurs stimuli, chaque stimulus définissant sur un intervalle temporel : 25 o des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; o des conditions sur des paramètres de sortie dudit composant logiciel ; L'équipement 1 comprend également des moyens de traitement de 30 données (par exemple un processeur) configurés pour la mise en oeuvre de : o un module de génération de premiers signaux conformes auxdites valeurs des paramètres d'entrée pour chaque stimulus ; o un module d'exécution dudit composant logiciel et d'application en entrée desdits premiers signaux générés pour chaque stimulus ; o un module d'observation de seconds signaux en sortie dudit composant logiciel pour chaque stimulus ; o un module de confirmation de la fiabilité du composant logiciel seulement si pour chaque stimulus les seconds signaux respectent lesdites conditions sur les paramètres de sortie. La figure 5 représente un exemple de vue de l'interface 14 de l'équipement 1. Cette interface permet facilement de programmer graphiquement (en partie gauche) un stimulus en sélectionnant et configurant d'une part des blocs correspondant à des fonctions élémentaires (on voit successivement une attente, un échelon, une rampe et une attente), et d'autre part des blocs correspondant aux conditions (ici une seule condition pour la séquence de quatre fonctions élémentaires évoquée). Les blocs graphiques sont sélectionnés depuis un catalogue en partie droite. La partie du milieu affiche le code en TCML associé généré. Produit programme d'ordinateur Selon un troisième et un quatrième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur les moyens de traitement 11 de l'équipement 1) de test du composant logiciel, ainsi que des moyens de stockage lisibles par un équipement informatique (notamment une mémoire 12 de l'équipement 1) sur lequel on trouve ce produit programme d'ordinateur.

Claims (14)

1. REVENDICATIONS1. Procédé de test d'un composant logiciel, caractérisé en ce qu'il comprend la mise en oeuvre par des moyens de traitement de données (11) d'un équipement (1) d'étapes de : (a) Expression sur une interface (13) de l'équipement (1) d'un ou plusieurs stimuli, chaque stimulus définissant sur un intervalle temporel : o des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; o des conditions sur des paramètres de sortie dudit composant logiciel ; (b) Pour chaque stimulus, o génération de premiers signaux conformes auxdites valeurs des paramètres d'entrée ; o exécution dudit composant logiciel et application en entrée desdits premiers signaux générés ; o Observation de seconds signaux en sortie dudit composant logiciel, (c) confirmation de la fiabilité du composant logiciel seulement si pour chaque stimulus les seconds signaux respectent lesdites conditions sur les paramètres de sortie.
2. 2. Procédé selon la revendication 1, dans lequel chaque stimulus définit une combinaison de fonctions élémentaires des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps.
3. 3. Procédé selon la revendication 2, dans lequel ladite combinaison de fonctions élémentaires comprend au moins une séquence temporelle de fonctions élémentaires.
4. 4. Procédé selon l'une des revendications 2 et 3, dans lequel lesdites fonctions élémentaires sont choisies parmi un ensemble comprenant des rampes, des échelons et des attentes.
5. 5. Procédé selon la revendication 4, dans lequel - Une attente est définie par une durée ; un échelon est défini par un paramètre choisi parmi une valeur d'un paramètre d'entrée et une valeur d'incrément, et une rampe est définie par deux paramètres choisis parmi une valeur cible d'un paramètre d'entrée, une durée de variation dudit paramètre d'entrée, une vitesse de variation dudit paramètre d'entrée, et une valeur d'incrément.
6. 6. Procédé selon l'une des revendications précédentes, dans lequel chaque stimulus définit une combinaison de conditions comprenant au moins une séquence temporelle de conditions.
7. 7. Procédé selon la revendication 6, dans lequel au moins une condition de ladite séquence de conditions est une condition principale associée à au moins une condition auxiliaire définissant un intervalle de temps réduit au sein de la séquence sur lequel les seconds signaux doivent respecter la condition principale pour que la fiabilité du composant logiciel soit vérifiée à l'étape (c).
8. 8. Procédé selon la revendication 7, dans lequel au moins une condition principale est associée à au moins deux conditions auxiliaires dont une condition de départ et une condition de fin.
9. 9. Procédé selon l'une des revendications précédentes, dans lequel un code informatique dudit composant logiciel est généréautomatiquement par les moyens de traitement de données (11) de l'équipement (1) préalablement à l'étape (a).
10. 10. Procédé selon la revendication 9, dans lequel ladite génération de code informatique est de type Scade0, Simulink® ou VHDL.
11. 11. Procédé selon l'une des revendications précédentes, comprenant en outre une étape (d) d'embarquement du composant logiciel sur un calculateur (21) d'un appareil (2) si la fiabilité du composant logiciel est confirmée.
12. 12. Equipement (1) de test d'un composant logiciel, caractérisé en ce qu'il comprend : - une interface (13, 14) permettant l'expression d'un ou plusieurs stimuli, chaque stimulus définissant sur un intervalle temporel : o des valeurs de paramètres d'entrée dudit composant logiciel en fonction du temps ; o des conditions sur des paramètres de sortie dudit composant logiciel ; - des moyens de traitement de données (11) configurés pour la mise en oeuvre de : o un module de génération de premiers signaux conformes auxdites valeurs des paramètres d'entrée pour chaque stimulus ; o un module d'exécution dudit composant logiciel et d'application en entrée desdits premiers signaux générés pour chaque stimulus ; o un module d'observation de seconds signaux en sortie dudit composant logiciel pour chaque stimulus ; o un module de confirmation de la fiabilité du composant logiciel seulement si pour chaque stimulus les seconds signaux respectent lesdites conditions sur les paramètres de sortie.
13. 13. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 11 de test d'un composant logiciel, lorsque ledit 5 programme est exécuté par un ordinateur.
14. 14. Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon l'une des 10 revendications 1 à 11 de test d'un composant logiciel.