FR3012636A1

FR3012636A1 - Procede de non-regression d'un outil de conception d'un systeme de surveillance de moteur d'aeronef

Info

Publication number: FR3012636A1
Application number: FR1360356A
Authority: FR
Inventors: Aurelie Gouby; Jerome Henri Noel Lacaille
Original assignee: SNECMA SAS
Current assignee: Safran Aircraft Engines SAS
Priority date: 2013-10-24
Filing date: 2013-10-24
Publication date: 2015-05-01
Anticipated expiration: 2033-10-24
Also published as: US20150120214A1; FR3012636B1; US10094740B2

Abstract

L'invention concerne un système de tests de non-régression d'un outil de conception comportant des modules (13) utilisés pour construire un dispositif de surveillance (11) de moteur (7) d'aéronef, ledit système de tests comportant : - des moyens de traitement (9) configurés pour créer de manière automatique une base d'expérience (9e) en instrumentant des tests de comportement lors de l'exécution des modules, ladite base d'expérience comportant des signaux d'entrée de référence (SIN_ref), des jeux de paramètres de référence, des signaux de sortie de référence (SOUT_ref), et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - des moyens de traitement (9) configurés pour relancer lesdits tests de comportement sur lesdits modules (13) selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test (SOUT_test) et des ensembles de résultats d'exécutions de test, et - des moyens de traitement (9) configurés pour comparer lesdits signaux de sortie de test aux signaux de sortie de référence correspondants et lesdits ensembles de résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception.

Description

PROCÉDÉ DE NON-RÉGRESSION D'UN OUTIL DE CONCEPTION D'UN SYSTÈME DE SURVEILLANCE DE MOTEUR D'AÉRONEF DOMAINE TECHNIQUE La présente invention concerne un outil de conception d'un système de surveillance d'un moteur d'aéronef, et plus particulièrement, un procédé et un système de tests de non-régression de l'outil de conception. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Différents systèmes de surveillance de moteurs d'aéronefs ont été mis en oeuvre pour vérifier le bon fonctionnement des différents équipements du moteur d'aéronef. Il existe par exemple, un système de surveillance pour analyser le comportement du moteur pendant le processus d'allumage, un autre pour analyser la trajectoire des gaz, un autre encore pour détecter le colmatage des filtres, et un autre pour analyser la consommation d'huile, etc. Tous ces systèmes de surveillance permettent d'améliorer la sécurité et la fiabilité des moteurs d'aéronef. En particulier, ils permettent d'éviter ou de limiter l'arrêt en vol, de réduire les retards ou annulation des vols, et plus particulièrement, facilitent la maintenance du moteur en anticipant les défaillances et en identifiant les composants fautifs ou défaillants. Cependant, la conception de chaque système de surveillance nécessite des moyens spécifiques et complexes pour résoudre les différents aspects techniques de la surveillance liée à chaque équipement particulier du moteur. Pour cela il faut construire un modèle spécifique à l'équipement surveillé et gérer des données de test et de validation correspondant à cet équipement du moteur. Ainsi, pour chaque équipement, il faut déployer beaucoup de ressources et de temps pour modéliser, développer, et valider le système de surveillance correspondant. En particulier, la validation d'un système de surveillance est une étape qui nécessite de manipuler un très grand nombre de données qui réclament un important temps de calcul afin de les analyser. En outre, il est important de bien choisir les indicateurs de validation afin d'éviter qu'une anomalie soit signalée par erreur ou qu'un élément du moteur soit en défaut sans que l'événement soit décelé. De plus, il peut arriver que le niveau de validation d'un système de surveillance soit différent de celui d'un autre système de surveillance. Ceci peut compliquer l'analyse des données issues des différents systèmes de surveillance du moteur. La demande de brevet FR2957170 de la demanderesse résout ces problèmes en proposant un outil de conception d'un système de surveillance de moteur d'aéronef. Cet outil est composé de modules élémentaires génériques intégrant des fonctions algorithmiques dédiées à des tâches spécifiques. Les modules sont instanciés en fonction de l'application de surveillance. L'outil de conception permet de définir un environnement de modalisation indépendant du contexte applicatif tout en permettant une validation fiable et une réutilisation des modules pour des taches ou applications différentes. Toutefois, les modules sont susceptibles d'évoluer. Par exemple des demandes spécifiques à un composant moteur peuvent conduire à une modification ou amélioration du module. Ceci peut avoir un impact sur d'autres applications utilisant ce même module. De façon analogue, l'environnement dans lequel se développent ces modules peut aussi évoluer. En effet, le langage de programmation des codes algorithmiques ainsi que le système d'exploitation des machines utilisées peuvent évoluer ou être continuellement mis à jour. Ces modifications aussi peuvent avoir des effets sur le fonctionnement des modules. L'objet de la présente invention est par conséquent, de remédier aux inconvénients précités en proposant un procédé de tests de non-régression de l'outil de conception d'un système de surveillance d'un moteur d'aéronef, permettant de détecter rapidement l'impact d'une modification sur le comportement d'un ou de plusieurs modules de l'outil de conception. EXPOSÉ DE L'INVENTION La présente invention est définie par un procédé de tests de non-régression d'un outil de conception d'un dispositif de surveillance de moteur d'aéronef, ledit outil de conception comportant des modules utilisés pour construire le dispositif de surveillance, chaque module intégrant des fonctions algorithmiques dédiées à des tâches spécifiques et étant configuré par un jeu de paramètres, chaque module étant adapté pour être exécuté sur un signal d'entrée pour délivrer un signal de sortie, ledit procédé comportant les étapes suivantes : - création automatique d'une base d'expérience en instrumentant des tests de comportement lors de l'exécution des modules, ladite base d'expérience comportant des signaux d'entrée de référence, des jeux de paramètres de référence, des signaux de sortie de référence, et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - relance desdits tests de comportement sur lesdits modules selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test et des ensembles de résultats d'exécutions de test, et - comparaison desdits signaux de sortie de test aux signaux de sortie de référence correspondants et desdits ensembles de résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception.

Ce procédé présente un mécanisme automatique de tests assurant la non- régression des modules et un suivi de la qualité des résultats permettant ainsi d'améliorer la sécurité et la fiabilité de surveillance des moteurs d'aéronef. Avantageusement, lors de l'exécution d'un module, la création de la base d'expérience comporte les étapes suivantes: - création des ensembles d'instances de modules de référence pour les différents modules, chaque module étant associé à un ensemble d'instances de modules de référence et chaque instance de module de référence étant définie par les fonctions algorithmiques du module correspondant, ainsi que par son jeu de paramètres de référence, chaque instance de module de référence étant associée à un signal d'entrée de référence, un signal de sortie de référence, et un ensemble de résultats d'exécutions de référence, et - enregistrement des différentes instances de modules de référence dans un système de stockage. Avantageusement, l'ensemble de résultats d'exécutions de référence associé à une instance de module de référence comporte un débit d'exécution de référence et une durée d'exécution de référence. Avantageusement, le test de non-régression d'un module à tester comporte les étapes suivantes : - création d'un ensemble d'instances de module de test associé à l'ensemble d'instances de module de référence correspondant audit module à tester, - attribution pour chaque instance de module de test le jeu de paramètres de référence de l'instance de module de référence correspondant, - exécution de chaque instance de module de test sur le signal d'entrée de référence de l'instance de module de référence correspondant pour générer un signal de sortie de test et un ensemble de résultats d'exécutions de test correspondants, ledit ensemble de résultats d'exécutions de test comportant un débit d'exécution de test et une durée d'exécution de test, - comparaison du débit d'exécution de test de chaque instance de module de test au débit d'exécution de référence de l'instance de module de référence correspondant, - comparaison du signal de sortie de test de chaque instance de module de test au signal de sortie de référence de l'instance de module de référence correspondant, et - comparaison de la durée d'exécution de test de chaque instance de module de test à la durée d'exécution de référence de l'instance de module de référence correspondant. Avantageusement, le test de non-régression dudit module à tester comporte les étapes suivantes : - calcul d'un écart de débit d'exécution entre le débit d'exécution de test de chaque instance de module de test et le débit d'exécution de référence de l'instance de module de référence correspondant, et comparaison dudit écart de débit d'exécution à un seuil de débit, - vérification d'une égalité non-régressive entre le signal de sortie de test de chaque instance de module de test et le signal de sortie de référence de l'instance de module de référence correspondant, et - calcul d'un écart de durée d'exécution entre la durée d'exécution de test de chaque instance de module de test et la durée d'exécution de référence de l'instance de module de référence correspondant, et comparaison dudit écart de durée d'exécution à un seuil de durée.

Selon un mode de réalisation préféré de la présente invention, le procédé comporte une réexécution une à une des instances de modules de référence enregistrées dans la base d'expérience afin de tester la non-régression des différents modules. Avantageusement, le procédé comporte un déclenchement automatique d'une alerte de régression au cas où le test de non-régression n'est pas validé pour au moins un module, l'alerte étant accompagnée d'un rapport de régression comportant une identification de chaque module concerné ainsi que le test de non-régression correspondant. L'invention vise également un système de tests de non-régression d'un outil de conception d'un dispositif de surveillance de moteur d'aéronef, ledit outil de conception comportant des modules utilisés pour construire le dispositif de surveillance, chaque module intégrant des fonctions algorithmiques dédiées à des tâches spécifiques et étant configuré par un jeu de paramètres, chaque module étant adapté pour être exécuté sur un signal d'entrée pour délivrer un signal de sortie, ledit système de tests comportant : - des moyens de traitement configurés pour créer de manière automatique une base d'expérience en instrumentant des tests de comportement lors de l'exécution des modules, ladite base d'expérience comportant des signaux d'entrée de référence, des jeux de paramètres de référence, des signaux de sortie de référence, et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - des moyens de traitement configurés pour relancer lesdits tests de comportement sur lesdits modules selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test et des ensembles de résultats d'exécutions de test, et - des moyens de traitement configurés pour comparer lesdits signaux de sortie de test aux signaux de sortie de référence correspondants et lesdits ensembles de résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception. L'invention vise aussi un outil de conception d'un dispositif de surveillance de moteur d'aéronef, comportant des modules utilisés pour construire le dispositif de surveillance, chaque module intégrant des fonctions algorithmiques dédiées à des tâches spécifiques et étant configuré par un jeu de paramètres, chaque module étant adapté pour être exécuté sur un signal d'entrée pour délivrer un signal de sortie, caractérisé en ce que ledit outil de conception comporte : - des moyens de traitement configurés pour créer de manière automatique une base d'expérience en instrumentant des tests de comportement lors de l'exécution des modules, ladite base d'expérience comportant des signaux d'entrée de référence, des jeux de paramètres de référence, des signaux de sortie de référence, et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - des moyens de traitement configurés pour relancer lesdits tests de 20 comportement sur lesdits modules selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test et des ensembles de résultats d'exécutions de test, et - des moyens de traitement configurés pour créer comparer lesdits signaux de sortie de test aux signaux de sortie de référence correspondants et lesdits ensembles de 25 résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception. L'invention vise également un système de surveillance d'au moins un équipement d'un moteur d'aéronef conçu par l'outil de conception selon les caractéristiques ci-dessus. 30 BRÈVE DESCRIPTION DES DESSINS La Fig. 1 illustre des moyens matériels mis en oeuvre dans un système de surveillance d'un équipement d'un moteur d'aéronef ; La Fig. 2 illustre de manière schématique un outil de conception du système de surveillance de la Fig. 1, selon l'invention ; La Fig. 3 illustre de manière schématique un système de tests de non-régression de l'outil de conception, selon l'invention ; La Fig. 4 illustre de manière schématique une instrumentation d'un module lors de la création de la base d'expérience, selon l'invention ; et La Fig. 5 illustre de manière schématique un procédé de tests de non- régression d'un module à tester, selon l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS La Fig. 1 illustre des moyens matériels mis en oeuvre dans le système de surveillance d'un équipement d'un moteur d'aéronef. Ces moyens matériels 1 comportent des capteurs 3 pour mesurer des données concernant un équipement particulier 5 du moteur d'aéronef 7 et son environnement et des moyens de traitement 9 de l'information tel un calculateur ou ordinateur pour l'exécution d'un ou de plusieurs programmes d'ordinateur comprenant des instructions de code de programme, stockés dans les moyens de stockage de l'ordinateur et conçus pour mettre en oeuvre un système de surveillance 11 de l'équipement 5. Le système de surveillance 11 est configuré pour recevoir des mesures spécifiques à l'équipement 5 et pour délivrer un résultat diagnostiquant l'état de cet 25 équipement. Plus particulièrement, le système de surveillance 11 est configuré pour recueillir et numériser les mesures spécifiques acquises par les capteurs 3 sur l'équipement 5 du moteur 7 et son environnement. Le système de surveillance 11 est configuré aussi pour définir des variables spécifiques donnant des indications sur des éléments physiques ou logiques de l'équipement 5. Le système de surveillance 11 peut aussi être configuré pour standardiser ou normaliser ces variables spécifiques et pour construire des signatures ou vecteur d'anomalies représentatives du comportement de l'équipement 5.

Le système de surveillance 11 permet également d'évaluer des scores afin de diagnostiquer ou de détecter si la signature d'anomalie révèle une anomalie. Selon la valeur du score par rapport à un seuil prédéfini, le système de surveillance 11 peut générer une alarme indiquant qu'une anomalie est détectée. Le système de surveillance 11 peut aussi être utilisé pour identifier ou classifier les anomalies détectées. En outre, le système de surveillance 11 peut être utilisé pour faire des pronostics et prendre des décisions. Ainsi, selon le type d'application, le système de surveillance 11 permet de réaliser plusieurs tâches pouvant comprendre l'acquisition des données, la normalisation des données, la détection d'anomalies, et éventuellement la classification des anomalies détectées. La Fig. 2 illustre de manière schématique un outil de conception du système de surveillance d'un équipement du moteur d'aéronef, selon l'invention. L'outil de conception comporte des moyens de traitement 9 de l'information comprenant les moyens que l'on trouve habituellement dans un ordinateur : une unité centrale 9a, des moyens de stockage 9b, des périphériques d'entrées 9c ainsi que des périphériques de sorties 9d. Les moyens de traitement 9 sont utilisés pour construire le système de surveillance 11 selon un assemblage de différents composantes ou modules 13a-13x dédiés à des tâches particulières du système de surveillance 11. En effet, les moyens de stockage 9b comprennent une pluralité de modules 13a-13x qui peuvent être accessibles par exemple, depuis une représentation graphique interactive et où chaque module indique les tâches spécifiques ou fonctions exécutables qu'il utilise.

Ainsi, le système de surveillance 11 peut être construit selon une structure assemblant une chaîne de modules 13 sélectionnés parmi la pluralité de modules 13a-13x selon les tâches particulières du système de surveillance. La chaîne de modules 13 comprend au moins un module d'entrée 13a à 13c, au moins un module de sortie 13f et 13g, et éventuellement un ou plusieurs modules intermédiaires 13d et 13e. Il existe des modules pour toutes les tâches nécessaires à la surveillance et à la détection des anomalies. Par exemple, quelques modules peuvent être spécialisés pour l'acquisition des données, d'autres pour des tâches d'arithmétique, encore d'autres pour faire un filtrage ou pour l'exploitation des données stochastiques, etc.

Chaque module intègre des fonctions algorithmiques qui sont appelées quand c'est nécessaire. En fait, il peut exister une fonction pour initialiser l'état du module, une autre pour faire le calibrage ou le paramétrage, d'autres fonctions pour l'exécution de l'algorithme et éventuellement une autre pour tracer les résultats. La structure des modules est décrite par J. Lacaille dans une publication intitulé «A Maturation Environment to Develop and Manage Health Monitoring Algorithms », PHM 2009, San Diego, CA. Chaque module 13i est paramétrable par un jeu de paramètres et est muni d'une interface d'entrée 13a1-13g1 et d'une interface de sortie 13a2-13g2 lui permettant de communiquer avec au moins un autre module et/ou avec les capteurs 3 et/ou avec les périphériques de sortie 9d. Chacun des modules 13a-13x est configuré pour recevoir via son interface d'entrée 13a1-13g1, un signal d'entrée SIN et pour délivrer sur son interface de sortie 13a2-13g2, un signal de sortie SouT. Les signaux d'entrée SIN et de sortie SouT présentent des formats très spécifiques aux applications de surveillance des équipements du moteur d'aéronef. En outre, le signal d'entrée SIN est composé en général d'une entrée IN (Input) et d'une valeur de qualité d'entrée DQV (Data Quality Value) associée à l'entrée IN. De même, le signal de sortie SouT est composé d'une sortie OUT (Output) correspondant à une sévérité (Risk) et une valeur de qualité de sortie (c'est-à-dire, une valeur de qualité de la sévérité) PQV (Predictive Quality Value) associée à la sortie OUT. On notera qu'une entrée peut comporter plusieurs entrées élémentaires et de même, une sortie peut comporter plusieurs sorties élémentaires. Plus particulièrement, un module d'entrée 13a correspond à un module d'acquisition de données configuré pour recevoir via son interface d'entrée 13a1, un signal d'entrée composé d'une entrée IN1 correspondant à des mesures spécifiques à l'équipement 5 et son environnent en provenance des capteurs 3 et une valeur de qualité d'entrée DQV1 associée aux mesures spécifiques. En particulier, les moyens de traitement 9 attribuent une valeur de qualité DQV1 prédéterminée aux mesures spécifiques. Par exemple, au départ, les moyens de traitement 9 attribuent une valeur de qualité DQV1 égale à un (DQV1=1) aux mesures spécifiques. Chaque module est responsable de ses données de sortie. Ainsi, le module d'entrée 13a délivre sur son interface de sortie 13a2, un signal de sortie composé d'une sortie OUT1 et d'une valeur de qualité de la sortie PQV1. Le signal de sortie est récupéré par le module suivant 13d via son interface d'entrée 13d1. De module en module, on arrive au dernier (ou derniers) module(s) 13f, 13g de la chaîne 13 correspondant au module(s) de sortie. Plus particulièrement, un module de sortie peut correspondre à un module d'évaluation d'anomalies 13f ou un module de classification 13g. Par exemple, le module 13f est configuré pour recevoir via son interface d'entrée 13f1, un signal d'entrée en provenance du module précédent 13e. Le signal d'entrée est composé d'une entrée IN4 correspondant à la sortie du module précédent (IN4=OUT3) et une valeur de qualité d'entrée DQV4 correspondant à la valeur de qualité de sortie du module précédent (DQV4=PQV3). Le module 13f est configuré pour délivrer via son interface de sortie 13f2, un signal de sortie composé d'une sortie OUT4 correspondant au résultat du système de surveillance et d'une valeur de qualité du résultat PQV4. Le résultat OUT4 du système de surveillance 11 est un diagnostic de l'anomalie ; c'est une mesure qui reflète un comportement anormal de l'équipement 5. Par exemple, si la valeur du résultat OUT4 dépasse un seuil prédéfini, une détection d'anomalie apparaît et éventuellement, génère une alarme 17 sur les périphériques de sorties 9d. A ce résultat est associée une qualité de sortie PQV4 indicatrice de la fiabilité du résultat OUT4. Cette qualité PQV4 qui représente une précision de chaque sortie peut être utilisée pour moduler tout le système de décision qui arrive après. Par exemple, si un résultat OUT4 dépasse le seuil prédéfini indiquant l'existence d'une anomalie, mais que la qualité du résultat PQV4 est faible, alors on peut éventuellement supposer que la détection de l'anomalie n'est pas très fiable. Comme la qualité du résultat dépend de la qualité de chacun des modules, les moyens de traitement 9 sont configurés pour calculer pour chaque module 13i, la valeur de qualité de sortie PQV du module 13i selon une fonction de transfert associant une imprécision de la sortie OUT en réponse à une imprécision de l'entrée IN en utilisant au moins un indicateur de qualité intrinsèque au module 13i correspondant à une mesure de sensibilité du module. Conformément à l'invention, l'outil de conception comporte un système de tests de non-régression. En effet, la Fig. 3 illustre de manière schématique un système de tests de non- 1 5 régression de l'outil de conception, selon l'invention. Le système de tests a pour but de créer dans un premier temps une base d'expériences où se trouvent les tests à relancer et d'élaborer dans un second temps un script de tests de non-régression pour ré-exécuter par exemple une à une les expériences enregistrées dans la base. 20 Le système de tests de non-régression comporte des moyens de traitement 9 comprenant une unité centrale 9a, des moyens de stockage 9b, 9e, et des périphériques d'entrées 9c et de sorties 9d. Avantageusement, le système de tests de non-régression est intégré à l'outil de conception permettant d'utiliser les mêmes moyens de traitement 9 de l'information. 25 Ces moyens de traitement 9 sont configurés pour créer de manière automatique une base d'expérience 9e en instrumentant des tests de comportement lors de l'exécution des modules 13a-13x. En effet, lors de l'exécution d'un module 13i configuré par un jeu de paramètres donné sur un signal d'entrée SIN donné, les moyens de traitement 9 30 enregistrent dans la base d'expérience 9e le jeu de paramètres, le signal d'entrée SIN ainsi que le signal de sortie SouT délivré par le module 13i. La base d'expérience 9e comporte ainsi des signaux d'entrée SIN de référence, des jeux de paramètres de référence, et des signaux de sortie SouT de référence associés aux modules 13a-13x.

Les moyens de traitement 9 enregistrent également dans la base d'expérience 9e des ensembles de résultats d'exécutions de référence relatives aux modules 13a-13x exécutés. Chaque ensemble de résultats d'exécutions de référence comporte un débit d'exécution du module concerné ainsi que la durée d'exécution. Ainsi, les moyens de traitement 9 instrumentent les modules 13a-13x pour créer la base d'expérience 9e en enregistrant pour chaque instance de module les entrées et sorties, le paramétrage et les résultats d'exécution (débit, temps, etc.). La procédure d'instrumentation s'exécute de manière automatique au lancement d'une représentation graphique interactive de modélisation par exemple de type SIMULINK. Avantageusement, plusieurs ensembles d'instances de modules de référence sont crées par les moyens de traitement 9 pour les différents modules. Chaque module 13i est associé à un ensemble d'instances de modules de référence et chaque instance de module de référence est définie par les fonctions algorithmiques du module correspondant, ainsi que par son jeu de paramètres de référence. En outre, chaque instance de module de référence est associée à un signal d'entrée de référence, un signal de sortie de référence, et un ensemble de résultats d'exécutions de référence. L'ensemble de résultats d'exécutions de référence associé à une instance de module de référence peut également comporter la date d'exécution de référence, le nombre d'observations de référence, le volume de données de référence en plus du débit d'exécution de référence et de la durée d'exécution de référence. Les instances de modules sont stockées dans un système de stockage de type base de données ou système de fichiers. A titre d'exemple, dans le cas d'un système de fichiers, les différentes instances de modules de référence d'un même module sont enregistrées dans des fichiers différents regroupés dans un même dossier. Autrement dit, chaque module 13 possède un dossier à son nom. Ce dernier contient un fichier au nom du module et chaque instance de module instrumentée possède une feuille (par exemple, une feuille EXCEL) à son nom dans le fichier. On peut donner comme nom d'instance le nom du module associé à un numéro qui s'incrémente. Les deux signaux d'entrée et de sortie sont également enregistrés dans le dossier du module.

Les résultats de l'exécution de l'instance sont écris automatiquement dans la feuille d'instance. Ils peuvent être divisés en catégories sous forme de tableaux. Par exemple, un premier tableau rappelle le nom du module 13, l'application de provenance de l'instance de module (si elle vient par exemple d'un graphe SIMULINK) et le nom de l'instance de module. Un deuxième tableau peut comporter des informations qui concernent le module (notamment son auteur, sa date de création) et qui permettent aussi de vérifier s'il est testable, s'il a une sortie graphique et le nombre d'éléments qu'il prend en entrée et en sortie. Un troisième tableau peut décrire le paramétrage de l'instance de module où on trouve les valeurs ou jeux de paramètres au moment de l'exécution mais aussi leur description qui sont utiles pour les tests de non-régression. Un quatrième tableau peut contenir le nom des signaux d'entrée et de sortie qui ont été enregistrés dans la base d'expériences 9e suite à l'instrumentation. Finalement, dans un dernier tableau on trouve le résultat de l'exécution du module (date, temps de traitement, nombre d'observations, débit du module, et volume des données), qui va servir pour les tests de non-régression.

L'exemple de la Fig. 3 montre deux dossiers D13a et D13b associés à deux modules différents 13a et 13b. Le premier dossier D13a comprend un fichier F13a au nom du module 13a comportant une feuille d'instance au nom de l'instance de module de référence mod_ref_a définie par les fonctions algorithmiques du premier module 13a, le jeu de paramètres de référence ainsi que le résultat de l'exécution. Le premier dossier D13a comprend également les données correspondant à un signal d'entrée Sin_ref_a et un signal de sortie Sou-r_ref_a. Le deuxième dossier D13b comprend deux fichiers F13b1 et F13b2 comprenant chacun une instance de module de référence mod_ref_b1, mod_ref_b2 et les données correspondant à deux signaux d'entrée Sin_ref_b1, Sin_ref_b2 et deux signaux de sortie Sou-r_ref_b1 Sou-r_ref_b2.

La Fig. 4 illustre de manière schématique une instrumentation d'un module lors de la création de la base d'expérience, selon l'invention. Au départ, on considère que l'option de l'instrumentation est activée. On notera que l'opérateur peut volontairement activer ou désactiver l'option de l'instrumentation utilisée pour la création de la base d'expérience.

A l'étape El, l'instance de module de référence mod_ref associée au module est enregistrée dans la base d'expérience 9e. Par exemple, à chaque instrumentation d'une nouvelle instance de module, une feuille est créée et rajoutée au fichier portant le nom du module contenu dans le dossier attribué au module. A l'étape E2, un jeu de paramètres de référence param_ref est attribué à l'instance de module de référence mod_ref et ce même jeu de paramètres est enregistré en association avec l'instance de module de référence. Le jeu de paramètres est par exemple indiqué sur la feuille attribuée à l'instance de module. A l'étape E3, l'instance de module de référence mod_ref est exécutée sur un signal d'entrée de SIN_ref qui est également enregistré en association avec l'instance de module de référence. A l'étape E4, le débit d'exécution D_ref, le signal de sortie Souuref, la durée d'exécution T_ref, et la date d'exécution date_ref sont également enregistrés en association avec l'instance de module de référence. Ces données sont par exemple indiquées sur la feuille d'instance du module.

La base d'expérience 9e permet ainsi de faciliter l'accès aux résultats d'exécution des modules et aux entrées et sorties pour relancer les tests. En effet, les signaux d'entrée de référence SIN_ref, les jeux de paramètres de référence param_ref, les signaux de sortie de référence Souuref, ainsi que les ensembles de résultats d'exécutions de référence (D_ref, T_ref, date) constituent des tests de comportement sur les différents modules. Une relance des tests de la base d'expériences 9e et une comparaison des résultats obtenus avec ceux enregistrés permet alors de tester la non-régression des modules de l'outil de conception. Plus particulièrement, les moyens de traitement 9 sont configurés pour relancer les tests de comportement sur les modules 13 selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants enregistrés dans la base d'expérience 9e. Les modules 13 génèrent alors des signaux de sortie de test et des ensembles de résultats d'exécutions de test que les moyens de traitement 9 comparent respectivement aux signaux de sortie de référence correspondants et aux ensembles de résultats d'exécutions de référence correspondants.

On notera que le fait de relancer l'exécution d'un module avec le même paramétrage et les mêmes données en entrée permet de vérifier si les données de sortie et leur qualité ont été impactées par une éventuelle modification sur le code du module ou de son environnement. La Fig. 5 illustre de manière schématique un procédé de tests de non- régression d'un module à tester, selon l'invention. Ce procédé consiste à créer pour chaque module 13, une nouvelle instance qu'on appellera instance de module de test qui sera paramétrée de la même façon que la première instance instrumentée (i.e., l'instance de référence correspondant). Ensuite, les résultats à la fin de l'exécution de l'instance de module de test sont vérifiés s'ils sont les mêmes que les résultats de référence. Plus particulièrement, à l'étape Ell, les moyens de traitement 9 sont configurés pour créer un ensemble d'instances de module de test mod_test associé à l'ensemble d'instances de module de référence correspondant au module à tester. Par souci de simplification, l'exemple de la Fig. 5 montre la création d'un seul module de test mod_test associé à une instance de module de référence mod_ref du module à tester. A l'étape E12, les moyens de traitement 9 attribuent pour chaque instance de module de test mod_test le jeu de paramètres de référence param_ref de l'instance de module de référence mod_ref correspondant. A l'étape E13, les moyens de traitement 9 exécutent chaque instance de module de test mod_test sur le signal d'entrée de référence SIN_ref de l'instance de module de référence mod_ref correspondant. Si un plantage ou un bug est détecté E14 alors une alerte de régression Al du module est déclenchée par les moyens de traitement 9. Sinon, l'exécution (étape E13) de l'instance de module de test mod_test génère un signal de sortie de test Souutest et un ensemble de résultats d'exécutions de test correspondants. L'ensemble de résultats d'exécutions de test comporte un débit d'exécution de test D_test, une durée d'exécution de test T_test, et éventuellement la date de test, un nombre d'observations de test, et le volume de données de test. A l'étape E15, les moyens de traitement 9 comparent le débit d'exécution de test D_test de chaque instance de module de test au débit d'exécution de référence D_ref de l'instance de module de référence correspondant. Par exemple, les moyens de traitement 9 calculent un écart de débit d'exécution entre le débit d'exécution de test D_test de chaque instance de module de test et le débit d'exécution de référence D_ref de l'instance de module de référence correspondant. Cet écart de débit d'exécution est comparé à un seuil de débit. Si le seuil de débit est dépassé, alors une alerte de régression A2 du module est déclenchée, sinon on passe à l'étape E16. On notera que le débit d'exécution de référence ou de test est un débit standardisé indépendant des moyens de traitement sur lesquels le code est exécuté. La vitesse de traitement, pour être générique, est estimée par calcul après des tests d'étalonnage des moyens de traitement courants par rapport à des moyens de traitement de référence. A l'étape E16, les moyens de traitement 9 comparent le signal de sortie de test Souutest de chaque instance de module de test au signal de sortie de référence Souuref de l'instance de module de référence correspondant. Par exemple, les moyens de traitement 9 vérifient une égalité non-régressive entre le signal de sortie de test Souutest de chaque instance de module de test et le signal de sortie de référence Souuref de l'instance de module de référence correspondant. On notera que le signal de sortie de test ou de référence comporte bien entendu les valeurs calculées mais aussi des informations supplémentaires comme des noms de variables, leurs unités, leurs tailles, etc. Ainsi, on s'assure dans un premier temps que la signification ou le type des signaux, leur taille, leur index sont identiques et ensuite on compare leur contenu ou valeur. L'égalité entre deux signaux dépend de la nature des signaux (discrets ou continus). Pour une valeur discrète, l'égalité entre les signaux est une égalité normale. Toutefois, pour une valeur continue, on peut par exemple considérer que deux signaux sont égaux si l'écart est plus petit qu'une proportion de la variance normale du signal.

On notera que dans des cas assez rares, certains algorithmes peuvent avoir un comportement non déterministe (dit stochastique). Dans ce cas, on utilise une fonction de distance pour comparer les signaux. Plus particulièrement, on compare les distributions pour chaque signal (référence et courante) afin de vérifier que les sorties sont issues de trajectoires ayant un sens analogue. Par exemple, la comparaison peut consister à mesurer la vraisemblance de la sortie courante (signal de test) au vu d'une série de sorties possibles (signaux de référence). Une autre méthode de comparaison peut consister à se ramener au cas déterministe en faisant toujours générer la même séquence de nombres pseudo aléatoires par les moyens de traitement. Si l'égalité non-régressive n'est pas attestée, alors une alerte de régression A3 du module est déclenchée, sinon, on passe à l'étape E17. A l'étape E17, les moyens de traitement 9 comparent finalement la durée d'exécution de test T_test de chaque instance de module de test à la durée d'exécution de référence T_ref de l'instance de module de référence correspondant. Par exemple, les moyens de traitement 9 calculent un écart de durée d'exécution entre la durée d'exécution de test T_test de chaque instance de module de test et la durée d'exécution de référence T_test de l'instance de module de référence correspondant. Cet écart de durée d'exécution est comparé à un seuil de durée prédéterminé. Par exemple, le seuil peut être choisi de sorte que la durée de traitement n'augmente pas de plus de 15%. Si le seuil de durée est dépassé, alors une alerte de régression A4 du module est déclenchée, sinon, on indique à l'étape E18 que le module ne présente pas de régression. Comme à l'étape E15, on notera que la durée d'exécution de référence ou de test est une durée standardisée indépendante des moyens de traitement sur lesquels le code est exécuté. Ainsi, une alerte de régression est déclenchée automatiquement au cas où au moins un test de non-régression n'est pas validé pour un module. En particulier, le système de tests peut délivrer un signal booléen : 1 si le module a régressé et 0 sinon. Avantageusement, un rapport de régression est édité automatiquement avec l'alerte. Ce rapport comporte une identification de chaque module concerné ainsi que le test de non-régression correspondant. En variante, si la sortie du test vaut 1 (i.e., le module a régressé), le rapport n'est pas édité de manière automatique et une boîte de dialogue demandera à l'utilisateur s'il veut éditer un rapport de régression. Avantageusement, le rapport contient toutes les informations concernant le module : son nom, son auteur, sa date de création, etc. Il contient également un résumé des renseignements contenus dans les tableaux de la feuille d'instance concernée par la régression. Celui-ci permet de connaître ce qui a été pris comme référence pour cette instance de module. Enfin, le rapport contient les résultats des tests, notamment les nouveaux temps d'exécution et le débit. Pour le résultat des tests sur les signaux de sortie, le rapport peut par exemple comporter un graphique du signal de sortie de référence et un autre du signal de sortie de test pour que le lecteur du rapport puisse se faire une idée de la différence entre les deux. Avantageusement, les tests de non-régression s'exécutent de manière automatisée. Selon un premier mode de réalisation, les moyens de traitement 9 parcourent toute la base d'expériences 9e pour tester une à une les instances de modules de référence qui s'y trouvent. Selon un deuxième mode de réalisation, les moyens de traitement 9 vérifient les dates des tests de non-régression pour ré-exécuter ceux qui n'ont pas été testés depuis longtemps. Ce deuxième mode permet de diminuer le coût du temps d'exécution. Selon un troisième mode de réalisation, quand un utilisateur lance une exécution de module en mode instrumentation et que cette instance a déjà été instrumentée, un message le lui signale. En outre, un autre message peut lui demander s'il veut plutôt lancer un test de non-régression sur le module en question. Le lancement des tests serait donc dans ce cas semi-automatique. Les tests de non-régression selon l'invention assurent que l'outil de conception fonctionne correctement et que toute modification d'un code ou d'un module n'introduit pas d'erreur dans la conception du système de surveillance du moteur d'aéronef.

Claims

REVENDICATIONS1. Procédé de tests de non-régression d'un outil de conception d'un dispositif de surveillance (11) de moteur (7) d'aéronef, ledit outil de conception comportant des modules (13) utilisés pour construire le dispositif de surveillance, chaque module intégrant des fonctions algorithmiques dédiées à des tâches spécifiques et étant configuré par un jeu de paramètres, chaque module étant adapté pour être exécuté sur un signal d'entrée pour délivrer un signal de sortie, caractérisé en ce que ledit procédé comporte les étapes suivantes : - création automatique d'une base d'expérience (9e) en instrumentant des tests de comportement lors de l'exécution des modules (13), ladite base d'expérience comportant des signaux d'entrée de référence (SIN_ref), des jeux de paramètres de référence (param_ref), des signaux de sortie de référence (Sou-r_ref), et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - relance desdits tests de comportement sur lesdits modules selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test (Souutest) et des ensembles de résultats d'exécutions de test, et - comparaison desdits signaux de sortie de test aux signaux de sortie de référence correspondants et desdits ensembles de résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception.
2. Procédé selon la revendication 1, caractérisé en ce que lors de l'exécution d'un module, la création de la base d'expérience comporte les étapes suivantes: - création des ensembles d'instances de modules de référence (mod_ref) pour les différents modules (13), chaque module étant associé à un ensemble d'instances de modules de référence et chaque instance de module de référence (mod_ref) étant définie par les fonctions algorithmiques du module correspondant, ainsique par son jeu de paramètres de référence, chaque instance de module de référence (mod_ref) étant associée à un signal d'entrée de référence (SIN_ref), un signal de sortie de référence (Sou-r_ref), et un ensemble de résultats d'exécutions de référence, et - enregistrement des différentes instances de modules de référence d'un même module dans un système de stockage.
3. Procédé selon la revendication 2, caractérisé en ce que l'ensemble de résultats d'exécutions de référence associé à une instance de module de référence (mod_ref) comporte un débit d'exécution de référence (D_ref) et une durée d'exécution de référence (T_ref).
4. Procédé selon la revendication 2 ou 3, caractérisé en ce que le test de non-régression d'un module à tester comporte les étapes suivantes : - création d'un ensemble d'instances de module de test (mod_test) associé à l'ensemble d'instances de module de référence (mod_ref) correspondant audit module à tester, - attribution pour chaque instance de module de test le jeu de paramètres de référence de l'instance de module de référence correspondant, - exécution de chaque instance de module de test (mod_test) sur le signal d'entrée de référence (SIN_ref) de l'instance de module de référence correspondant pour générer un signal de sortie de test (Souutest) et un ensemble de résultats d'exécutions de test correspondants, ledit ensemble de résultats d'exécutions de test comportant un débit d'exécution de test (D_test) et une durée d'exécution de test (T_test), - comparaison du débit d'exécution de test de chaque instance de module de test au débit d'exécution de référence de l'instance de module de référence correspondant, - comparaison du signal de sortie de test de chaque instance de module de test au signal de sortie de référence de l'instance de module de référence correspondant, et- comparaison de la durée d'exécution de test de chaque instance de module de test à la durée d'exécution de référence de l'instance de module de référence correspondant.
5. Procédé selon la revendication 4, caractérisé en ce que le test de non- régression dudit module à tester comporte les étapes suivantes : - calcul d'un écart de débit d'exécution entre le débit d'exécution de test de chaque instance de module de test et le débit d'exécution de référence de l'instance de module de référence correspondant, et comparaison dudit écart de débit d'exécution à un seuil de débit, - vérification d'une égalité non-régressive entre le signal de sortie de test de chaque instance de module de test et le signal de sortie de référence de l'instance de module de référence correspondant, et - calcul d'un écart de durée d'exécution entre la durée d'exécution de test de chaque instance de module de test et la durée d'exécution de référence de l'instance de module de référence correspondant, et comparaison dudit écart de durée d'exécution à un seuil de durée.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une réexécution une à une des instances de modules de référence enregistrées dans la base d'expérience afin de tester la non-régression des différents modules.
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte un déclenchement automatique d'une alerte de régression au cas où le test de non-régression n'est pas validé pour au moins un module, l'alerte étant accompagnée d'un rapport de régression comportant une identification de chaque module concerné ainsi que le test de non-régression correspondant.
8. Système de tests de non-régression d'un outil de conception d'un dispositif de surveillance (11) de moteur (7) d'aéronef, ledit outil de conception comportant des modules (13) utilisés pour construire le dispositif de surveillance, chaque module intégrant des fonctions algorithmiques dédiées à des tâches spécifiques et étant configuré par un jeu de paramètres, chaque module étant adapté pour être exécuté sur un signal d'entrée pour délivrer un signal de sortie, caractérisé en ce que ledit système de tests comporte : - des moyens de traitement (9) configurés pour créer de manière automatique une base d'expérience (9e) en instrumentant des tests de comportement lors de l'exécution des modules, ladite base d'expérience comportant des signaux d'entrée de référence (SIN_ref), des jeux de paramètres de référence, des signaux de sortie de référence (Souuref), et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - des moyens de traitement (9) configurés pour relancer lesdits tests de comportement sur lesdits modules (13) selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test (SouT_test) et des ensembles de résultats d'exécutions de test, et - des moyens de traitement (9) configurés pour comparer lesdits signaux de sortie de test aux signaux de sortie de référence correspondants et lesdits ensembles de résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception.
9. Outil de conception d'un dispositif de surveillance (11) de moteur (7) d'aéronef, comportant des modules (13) utilisés pour construire le dispositif de surveillance, chaque module intégrant des fonctions algorithmiques dédiées à des tâches spécifiques et étant configuré par un jeu de paramètres, chaque module étant adapté pour être exécuté sur un signal d'entrée pour délivrer un signal de sortie, caractérisé en ce que ledit outil de conception comporte : - des moyens de traitement (9) configurés pour créer de manière automatique une base d'expérience (9e) en instrumentant des tests de comportementlors de l'exécution des modules, ladite base d'expérience comportant des signaux d'entrée de référence, des jeux de paramètres de référence, des signaux de sortie de référence, et des ensembles de résultats d'exécutions de référence relatives auxdits modules, - des moyens de traitement configurés pour relancer lesdits tests de comportement sur lesdits modules selon les signaux d'entrée de référence correspondants et les jeux de paramètres de référence correspondants générant ainsi des signaux de sortie de test et des ensembles de résultats d'exécutions de test, et - des moyens de traitement configurés pour créer comparer lesdits signaux de sortie de test aux signaux de sortie de référence correspondants et lesdits ensembles de résultats d'exécutions de test auxdits ensembles de résultats d'exécutions de référence correspondants afin de tester la non-régression de l'outil de conception.
10. Système de surveillance d'au moins un équipement (5) d'un moteur (7) d'aéronef conçu par l'outil de conception selon la revendication 9.20