FR3025337B1 - Systeme pour creer et deployer un modele d'inference - Google Patents

Systeme pour creer et deployer un modele d'inference Download PDF

Info

Publication number
FR3025337B1
FR3025337B1 FR1557885A FR1557885A FR3025337B1 FR 3025337 B1 FR3025337 B1 FR 3025337B1 FR 1557885 A FR1557885 A FR 1557885A FR 1557885 A FR1557885 A FR 1557885A FR 3025337 B1 FR3025337 B1 FR 3025337B1
Authority
FR
France
Prior art keywords
model
equipment
configuration
compiled
data
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.)
Active
Application number
FR1557885A
Other languages
English (en)
Other versions
FR3025337A1 (fr
Inventor
Donna Louise Green
Brian David Larder
Peter Robin Knight
Olivier THUONG
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.)
GE Aviation Systems Ltd
Original Assignee
GE Aviation Systems Ltd
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 GE Aviation Systems Ltd filed Critical GE Aviation Systems Ltd
Publication of FR3025337A1 publication Critical patent/FR3025337A1/fr
Application granted granted Critical
Publication of FR3025337B1 publication Critical patent/FR3025337B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/04—Inference or reasoning models
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B17/00—Systems involving the use of models or simulators of said systems
    • G05B17/02—Systems involving the use of models or simulators of said systems electric
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0224—Process history based detection method, e.g. whereby history implies the availability of large amounts of data
    • G05B23/024—Quantitative history assessment, e.g. mathematical relationships between available data; Functions therefor; Principal component analysis [PCA]; Partial least square [PLS]; Statistical classifiers, e.g. Bayesian networks, linear regression or correlation analysis; Neural networks
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/20—Administration of product repair or maintenance

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Mathematical Physics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Human Resources & Organizations (AREA)
  • Automation & Control Theory (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computational Linguistics (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

Il est proposé un système (1) et un procédé correspondant pour créer et déployer un ou plusieurs modèle(s) d'inférence (19) destiné(s) à servir au télécontrôle de l'état d'un premier parc d'un premier équipement (100). Le système (1) comprend des données de configuration de modèles (111) destinées à servir ultérieurement à une application de création de modèle (13) pour construire un ou plusieurs modèle(s) d'inférence voulu(s) (19) pour le premier équipement. Les données de configuration de modèles (111) sont adaptées au premier équipement (100) et au(x) modèle(s) d'inférence voulu(s) (19), et sont fournies sous un format facilement lisible et modifiable par un utilisateur (U) du système (1). Les données de configuration de modèles (111) sont séparées des algorithmes de traitement sous-jacents qui sont employés par l'application de création de modèle (13) lors de la construction du/des modèle(s) d'inférence voulu(s) (19) pendant un mode apprentissage de fonctionnement du système (1). Le système (1) est également utilisable en mode exécution pour déduire un état d'un ou de plusieurs des premier(s) équipement(s) (100) d'après des données de fonctionnement reçues du/des équipement(s) donné(s).

Description

Système pour créer et déployer un modèle d’inférence
La présente invention concerne des systèmes pour créer et déployer des modèles d'inférence destinés à servir pour le télécontrôle de l'état de parcs de différents équipements. Sans chercher à limiter l'applicabilité de l'invention, l'invention s'applique au télécontrôle de l'état de moteurs d'aéronefs ou d'organes de ceux-ci, d'autres systèmes ou organes d'un aéronef ou d'autres formes d'équipements importants.
Dans de nombreux secteurs de l'industrie et du transport, le télécontrôle de l'état d'un équipement est entrepris pour permettre à un exploitant d'en déduire l'état de santé de l’équipement au même moment et/ou de prédire son futur état de santé. De tels systèmes sont connus dans l'aéronautique, des constructeurs de moteurs d'aéronefs contrôlant des données reçues des moteurs d'un ou de plusieurs aéronef(s) en vol. Le contrôle peut être entrepris tout d'abord pour détecter un éventuel comportement anormal d'un équipement (par exemple, un relevé de température ou de pression extrêmement élevé dans un étage d'une turbine à haute pression d'un moteur à turbine à gaz) et, ensuite, pour établir si ce comportement anormal indique ou non une anomalie existante et, dans l'affirmative, évaluer l'anomalie existante. Les systèmes de contrôle d'état selon la technique antérieure emploient des modèles statistiques qui, à la réception de données de fonctionnement émanant d'un équipement en marche, sont à même de déduire des données reçues si, oui ou non, elles indiquent une anomalie dans l'équipement.
Cependant, les modèles statistiques à la base de ces systèmes de télécontrôle d'état selon la technique antérieure nécessitent une abondante réécriture du code source sous-jacent servant à créer les modèles statistiques pour prendre en compte les différentes caractéristiques de différents équipements. On entend par "différents" équipements des équipements qui sont de la même catégorie mais qui diffèrent par un ou plusieurs aspect(s) de leur construction. Cette réécriture du code source nécessite des compétences de spécialistes et ne doit normalement être entreprise que par des informaticiens expérimentés. Cette réécriture risque d'être nécessaire même si les différents équipements sont dans une catégorie commune (par exemple, une catégorie de "moteurs à turbine à gaz"), mais diffèrent les uns des autres par un ou plusieurs aspect(s) de leur construction. Par exemple, les modèles statistiques utilisés pour le contrôle d'état d'un parc d'un premier modèle de moteur à turbine à gaz d'aéronef différeront des modèles utilisés pour le contrôle d'état d'un parc d'un second modèle de moteur à turbine à gaz d'aéronef, même s'il y a des points communs entre certaines des pièces constituant les deux modèles de moteurs. Cela vaut même si les deux modèles de moteurs proviennent du même constructeur de moteurs. Des différences de construction entre les deux modèles de moteurs peuvent très bien aboutir à des limites d'exploitation différentes et à des comportements de réaction différents pour des paramètres communs dans des organes correspondants des deux modèles de moteurs. Par conséquent, les systèmes de télécontrôle d'état selon la technique antérieure ont nécessité beaucoup de temps et de travail de la part d'informaticiens expérimentés pour absolument chaque modèle de moteur afin d'assurer que les modèles statistiques mis au point puissent détecter et évaluer avec précision une anomalie de comportement d'un modèle de moteur donné. Ce problème concerne tout autant les systèmes de télécontrôle d'état servant à détecter et évaluer une anomalie de comportement dans d'autres catégories d'équipements.
Par conséquent, on a besoin de trouver une manière plus efficace de créer un modèle d'inférence destiné au télécontrôle d'état d'équipements importants, qui soit adaptable pour réduire le temps et le travail nécessaires à la création de systèmes de télécontrôle d'état pour des équipements qui sont dans la même catégorie mais qui diffèrent par leur création.
Il est donc proposé un système pour créer et déployer un ou plusieurs modèle(s) d'inférence destiné au télécontrôle de l'état d'un premier parc d'un premier équipement important, le système comportant : a) un fichier de configuration et/ou une base de données de configuration compilées, le fichier de configuration et/ou la base de données de configuration compilées étant modifiable et lisible par un utilisateur et comprenant des données de configuration de modèles destinées à être utilisées ultérieurement par une application de création de modèle pour construire un ou plusieurs modèle(s) d'inférence voulu(s) pour le premier équipement, les données de configuration de modèles étant adaptées au premier équipement et au(x) modèle(s) d'inférence voulu(s) ; b) une application de création de modèle, l'application de création de modèle étant conçue pour : recevoir les données de configuration de modèles issues du fichier de configuration et/ou de la base de données de configuration compilées ; et fonctionner en mode apprentissage et en mode exécution, suivant les données de configuration de modèles reçues ; pour le mode apprentissage, l'application de création de modèle étant conçue pour : recevoir des données d'historique de fonctionnement correspondant à la pluralité d'états de fonctionnement du premier équipement ; solliciter un ou plusieurs algorithme(s) de traitement, le/les algorithme(s) de traitement sollicité(s) étant déterminé(s) par les données de configuration de modèles ; et construire - à l'aide des données de configuration de modèles reçues, des données d'historique de fonctionnement reçues et du/des algorithme(s) de traitement sollicité(s) - le/les modèle(s) d'inférence voulu(s) de façon que le/les modèle(s) d'inférence puisse(nt) servir à déduire un état d'un ou de plusieurs des premier(s) équipement(s) du premier parc d’après des données de fonctionnement reçues du/des premier(s) équipement(s) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) ; pendant le mode exécution, l'application de création de modèle étant conçue pour : recevoir des données de fonctionnement émanant d'un ou de plusieurs des premier(s) équipement(s) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) ; et utiliser le ou au moins un des modèles d'inférence construits pour traiter les données de fonctionnement reçues, pour ainsi déduire des données de fonctionnement reçues à un état du/des premier(s) équipement(s).
Un deuxième aspect de l'invention propose un procédé de construction d'un ou de plusieurs modèle(s) d'inférence destiné(s) à servir au télécontrôle d'état d'un premier parc d'un premier équipement important, le procédé comportant : a) la réalisation d'un fichier de configuration et/ou d'une base de données de configuration compilées, le fichier de configuration et/ou la base de données de configuration compilées étant modifiable(s) et lisible(s) par un utilisateur et comprenant des données de configuration de modèles à utiliser ultérieurement par une application de création de modèle pour construire un ou plusieurs modèle(s) d'inférence voulu(s) pour le premier équipement, les données de configuration de modèles étant adaptées au premier équipement et au(x) modèle(s) d’inférence voulu(s) ; b) réaliser l’application de création de modèle ; c) l’application de création de modèle recevant les données de configuration de modèles issues du fichier de configuration et/ou de la base de données de configuration compilées ; d) faire fonctionner l’application de création de modèle en mode apprentissage en fonction des données de configuration de modèles reçues, l’application de création de modèle, en mode apprentissage : recevant des données d’historique de fonctionnement correspondant à une pluralité d’états de fonctionnement du premier équipement ; sollicitant un ou plusieurs algorithme(s) de traitement, le/les algorithme(s) de traitement sollicité(s) étant déterminé(s) par les données de configuration de modèles ; et construisant- à l'aide des données de configuration de modèles reçues, des données d'historique de fonctionnement reçues et du/des algorithme(s) de traitement sollicité(s) - le/les modèle(s) d'inférence voulu(s), les modèles d'inférence pouvant de ce fait servir à déduire un état d'un ou de plusieurs des premier(s) équipement(s) du premier parc d’après des données de fonctionnement reçues du/des premier(s) équipement(s) du premier parc pendant le fonctionnement du/des premier(s) équipement(s).
Selon un troisième aspect de l’invention, le procédé comporte des étapes successives de : exploitation de l’application de création de modèle en mode exécution en fonction des données de configuration de modèles reçues par l’application de création de modèle, l’application de création de modèle, en mode exécution : recevant des données d’exploitation issues d’un ou de plusieurs des premier(s) équipement(s) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) ; et utilisant le modèle d’inférence construit ou au moins un des modèles d’inférence construits pour traiter les données de fonctionnement reçues afin de déduire de la sorte, d’après les données de fonctionnement reçues, un état du/des premier(s) équipement(s).
Selon un quatrième aspect, le procédé est en outre conçu pour construire un ou plusieurs modèle(s) d’inférence destiné(s) à servir au télécontrôle d’état d’un second parc d’un second équipement important, les premier et second équipements relevant d’une même catégorie mais différant par leur construction ; sachant que : l’étape (a) est effectuée pour le second équipement afin de réaliser un fichier correspondant de configuration de second équipement et/ou une deuxième base de données correspondante de configuration compilées contenant des données de configuration de modèles adaptées au second équipement et un ou plusieurs modèle(s) d’inférence voulu(s) pour le second équipement ; l’étape (c) est effectuée pour le second équipement, l’application de création de modèle recevant les données de configuration de modèles issues du deuxième fichier correspondant de configuration d’équipements et/ou de la deuxième base de données correspondante de configuration compilées ; et sachant que l’étape (d) est effectuée pour le second équipement afin de construire de la sorte le/les modèle(s) d’inférence voulu(s) pour le second équipement, le/les modèle(s) d’inférence voulu(s) pouvant ainsi servir à déduire un état d’un ou de plusieurs des deuxième(s) équipement(s) du second parc d’après des données de fonctionnement reçues du/des deuxième(s) équipement(s) du second parc pendant le fonctionnement du/des deuxième(s) équipement(s).
Selon un autre aspect, le procédé selon le quatrième aspect est conçu pour comporter des étapes successives de : exploitation de l’application de création de modèle en mode exécution conformément aux données adaptées de configuration de modèles de second équipement reçues par l’application de création de modèle, l’application de création de modèle, en mode exécution: recevant des données de fonctionnement issues d’un ou de plusieurs des second(s) équipement(s) du second parc pendant le fonctionnement du/des deuxième(s) équipement(s) ; et utilisant le modèle d’inférence construit ou au moins un des modèles d’inférence construits du second équipement afin de traiter les données de fonctionnement du/des second(s) équipement(s) reçues pour déduire de la sorte des données de fonctionnement reçues un état du/des second(s) équipement(s). L’équipement n’est limité à aucun domaine de technologie et peut comprendre (sans restriction) des systèmes mécaniques, électriques, électromécaniques, logiciels/matériels. Uniquement à titre d’exemple et sans chercher à limiter la portée de l’invention, l’équipement peut être un moteur d’aéronef, un système de commande de vol d’un aéronef ou une turbine éolienne. Ces exemples de catégories d’équipements sont ordinairement prévus pour fonctionner d’une manière semi-autonome ou entièrement autonome sans la présence de personnel d’entretien. Des systèmes de télécontrôle d’état sont utiles pour contribuer à identifier ou à prédire la survenance d’une anomalie dans ces équipements à fonctionnement autonome. Un exemple nullement limitatif de premier et second équipements partageant une même catégorie consiste en un premier modèle de moteur à turbine à gaz d’aéronef et un deuxième modèle de moteur à turbine à gaz d’aéronef. Tout en figurant dans une même catégorie de moteurs de turbines à gaz d’aéronefs, les premier et deuxième modèles de moteur à turbine à gaz d’aéronef (c’est-à-dire le premier et le second équipements) diffèrent l’un de l’autre par leur construction et donc par leur comportement de réaction. Par conséquent, le/les modèle(s) d’inférence nécessaire(s) pour déduire un état d’un premier équipement donné (par exemple, le premier modèle de moteur) d’après des données de fonctionnement reçues du premier équipement donné sera/seront forcément différent(s) du/des modèle(s) nécessaire(s) pour déduire un état d’un second équipement donné (par exemple, le deuxième modèle de moteur) d’après des données de fonctionnement reçues du second équipement donné. Un modèle d’inférence construit par le système ou le procédé selon l’invention pour le premier équipement doit être utilisable pour déduire l’état de l’un quelconque des premiers équipements du premier parc d’après des données de fonctionnement reçues du premier équipement pendant son fonctionnement.
Le mode apprentissage est un mode de fonctionnement de l’application de création de modèle dans lequel le/les modèle(s) d’inférence est/sont construit(s). Le mode exécution est un mode de fonctionnement de l’application de création de modèle dans lequel le/les modèle(s) d’inférence construit(s) dans un mode apprentissage antérieur pour le premier équipement sont employé(s) dans l’analyse de données de fonctionnement reçues d’un ou de plusieurs des premier(s) équipement(s) du premier parc pendant le fonctionnement du/des premier(s) équipement(s). Le système et le procédé selon l’invention s’appliquent tout aussi bien à une utilisation pour le second parc de deuxièmes équipements - à la fois dans le mode apprentissage et dans le mode exécution. Par conséquent, lorsque le système et le procédé seront décrits plus loin en référence au premier équipement, sauf mention contraire, le système et le procédé devront également être considérés comme appropriés au second équipement. Les données de configuration de modèles pour le second équipement présenteront forcément des différences par rapport à celles du premier équipement. L'état déduit résultant du mode exécution est de préférence : i) un indicateur de présence d'une anomalie de fonctionnement du/des premier(s) équipement(s) du premier parc ; et/ou ii) un classement de l'anomalie indiquée dans un ou plusieurs état(s) d'anomalie(s) probable(s) du/des premier(s) équipement(s) du premier parc. Selon la complexité du/des modèle(s) d'inférence construit(s), le/les modèle(s) peut/peuvent même être aptes à estimer le temps restant avant une panne pour un ou plusieurs des premier(s) équipement(s) (ou un organe de celui-ci/ceux-ci). L'état déduit voulu par un utilisateur résultant du mode exécution est susceptible d'affecter la nature du modèle d'inférence nécessité par et construit dans le mode apprentissage. A titre d'exemple, un modèle d'inférence qui convient pour produire un indicateur de présence d'une anomalie (comme en (i) ci-dessus) est susceptible d'avoir une complexité moindre que et une fonctionnalité différente de celles d'un modèle d'inférence qui convient pour évaluer l'anomalie indiquée (comme en (ii) ci-dessus).
La précision et les fonctionnalités d'un modèle d'inférence donné pour déduire l'état d'un, donné, des premiers équipements d'après ses données de fonctionnement en mode exécution dépendent de la qualité et de la diversité des données d'historique de fonctionnement fournies à l'application de création de modèle dans le mode apprentissage. Les données d'historique de fonctionnement doivent de préférence correspondre à une pluralité d'états de fonctionnement normaux et à une pluralité d'états d'anomalies possibles pour le premier équipement. Les données d'historique de fonctionnement sont de préférence issues de l'ensemble du premier parc des premiers équipements au lieu de provenir uniquement d'un seul des premiers équipements. De ce fait, cela doit accroître l'aptitude du/des modèle(s) d'inférence construit(s) à déduire (en mode exécution) si, oui ou non, des données de fonctionnement reçues de l'un, donné, des premiers équipements et pendant le fonctionnement de l'un, donné, des premiers équipements, indiquent un état d'anomalie et/ou à évaluer l'état d'anomalie. Revenant à l'exemple du cas où le premier équipement est un premier modèle de moteur à turbine à gaz d'aéronef, les états de fonctionnement normaux des données d'historique de fonctionnement peuvent comprendre les conditions d'efforts de poussée maximum rencontrées pendant le décollage d'un aéronef doté d'un tel modèle de moteur, ainsi que les conditions de poussée en régime de croisière à un certain nombre d'altitudes différentes de l'aéronef, ainsi que de conditions de poussée pendant l'atterrissage ; les données peuvent également être fournies d'après une pluralité de conditions climatiques différentes dans lesquelles le modèle de moteur donné a été amené à fonctionner. De préférence, la même diversité doit être également présente dans la partie des données d'historique de fonctionnement représentative d'une ou de plusieurs condition(s) d'anomalie(s). En plus de reposer sur des données recueillies en service, les données d'historique peuvent comprendre des données expérimentales résultant d'essais du modèle de moteur sur un montage d'essai afin de simuler différents régimes normaux et des conditions d'anomalies. Des exemples nullement limitatifs de conditions d'anomalies comprennent une panne d'aube mobile de turbine, l'ingestion d'un ou de plusieurs oiseaux par le moteur et la panne d'un ou de plusieurs des injecteur(s) présent(s) dans la chambre de combustion du moteur. Evidemment, la nature des données d'historique de fonctionnement changera en fonction du type particulier d'équipement considéré.
Comme expliqué dans des paragraphes ultérieurs, le système et le procédé selon l'invention peuvent fonctionner en présence du fichier de configuration et en l'absence d'une base de données de configuration compilées, ou encore en présence de la base de données de configuration compilées et en l'absence d'un fichier de configuration. Selon encore une autre possibilité, un exemple préféré de l'invention utilise à la fois le fichier de configuration et la base de données de configuration compilées. L'emploi de l'expression "le fichier de configuration et/ou la base de données de configuration compilées" couvre ces divers scenarii différents.
De préférence, l'application de création de modèle est un fichier exécutable par informatique. L'application de création de modèle entreprend la construction du/des modèle(s) d'inférence dans le mode apprentissage. L'application de création de modèle construit le/les modèle(s) d'inférence d'après les informations contenues dans les données de configuration de modèles reçues du fichier de configuration et/ou de la base de données de configuration compilées, ces informations ayant été adaptées au premier équipement et au(x) modèle(s) d'inférence voulu(s). Comme énoncé dans les revendications annexées, dans le mode exécution, l'application de création de modèle emploie également au moins un modèle d'inférence construit pour déduire un état d'un ou de plusieurs des premier(s) équipement(s) d'après les données de fonctionnement reçues du/des premier(s) équipement(s) pendant son/leur fonctionnement.
Pour l'essentiel, le système et le procédé selon l'invention segmentent i) les informations de niveau haut qui définissent diverses caractéristiques associées au premier équipement et au(x) modèle(s) d'inférence voulu(s) d'après ii) les algorithmes de traitement complexes et le codage logiciel complexe nécessaires pour construire le/les modèle(s) d'inférence. Les informations de niveau haut de i) sont contenues dans les données de configuration de modèles du fichier de configuration et/ou de la base de données de configuration compilées modifiable(s) et lisible(s). Les algorithmes de traitement complexes et le codage logiciel à l'appui de ii) sont contenus dans l'application de création de modèle ou communiquent avec celle-ci. Cette segmentation bénéficie du fait que, pour des équipements différents appartenant à une même catégorie (par exemple, les premier et deuxième modèles de moteurs à turbine à gaz d'aéronefs mentionnés plus haut), la construction de modèles d'inférence correspondants pour les différents équipements est susceptible d'employer un outillage commun d'algorithmes de traitement sous-jacents et de codes logiciels de soutien. L'utilisation du fichier de configuration et/ou de la base de données de configuration compilées modifiable(s) et lisible(s) assure un emplacement pour définir des données spécifiques des caractéristiques de structures et/ou de performances pour le premier équipement (ou, selon une autre possibilité, le second équipement), ainsi que pour indiquer une fonctionnalité requise du/des modèle(s) d'inférence voulu(s) pour le premier (ou le deuxième) équipement important, c’est-à-dire les "données de configuration de modèles". Dans le contexte de l'exemple nullement limitatif ci-dessus d'un premier et d'un second équipements constituant un premier et un deuxième modèles respectifs de moteurs à turbine à gaz d'aéronefs, les données de configuration de modèles adaptées au premier modèle de moteur à turbine à gaz d'aéronef seront différentes des données de configuration de modèles adaptées pour le deuxième modèle de moteur à turbine à gaz d'aéronef.
De préférence, le système (et le procédé correspondant) comprend le fichier de configuration, lequel fichier de configuration est directement modifiable et lisible par un utilisateur et contenant les données de configuration de modèles. Le fichier de configuration est avantageusement réalisé sous la forme d'une feuille de calcul ou d'un fichier à format de langage de balisage extensible (XML). Si le fichier se présente sous la forme d'une feuille de calcul, la feuille de calcul peut comprendre une seule feuille ou plusieurs feuille(s) de calcul en lien les unes avec les autres. Quel que soit le format du fichier spécifique du fichier de configuration, le fichier de configuration est directement modifiable et lisible par un utilisateur. Un avantage offert par ce fichier de configuration est qu'il crée une interface relativement simple pour un utilisateur non expérimenté afin de fournir les informations nécessaires pour que l'application de création de modèle construise le/les modèle(s) d'inférence.
Si le fichier de configuration contient les données de configuration de modèles, le système (et le procédé correspondant) comprend également, de préférence, la base de données de configuration compilées, la base de données de configuration compilées étant conçue pour recevoir du fichier de configuration les données de configuration de modèles et stocker les données de configuration de modèles ainsi reçues sous un format de code objet lisible par l'application de création de modèle, l'application de création de modèle étant conçue pour recevoir les données de configuration de modèles compilées en accédant à la base de données de configuration compilées. Avantageusement, la base de données de configuration compilées comprend ou est couplée à un compilateur pour compiler des données reçues du fichier de configuration directement modifiable et lisible. En stockant les données de configuration de modèles sous un format de code objet compilé, la base de données de configuration compilées accroît la vitesse à laquelle l'application de création de modèle peut accéder aux données de configuration de modèles et comprendre celles-ci. Cela offre des avantages si l'application de création de modèle nécessite en de multiples occasions (par exemple, pendant le mode apprentissage) un accès aux mêmes données de configuration de modèles, le stockage des données de configuration de modèles sous un format de code objet compilé facilitant la réduction du temps nécessaire à l'application de création de modèle pour accéder aux données de configuration de modèles en comparaison du cas où les données de configuration de modèles sont stockées sous un format non compilé. Les données de configuration de modèles du fichier de configuration comprennent avantageusement une adresse pour l'emplacement de la base de données de configuration compilées.
Selon une autre possibilité, le système (et le procédé correspondant) peut éviter l'utilisation de la base de données de configuration en présentant un compilateur sur un circuit de communication entre le fichier de configuration et l'application de création de modèle, l'application de création de modèle étant conçue pour recevoir les données de configuration de modèles directement du fichier de configuration via le compilateur sans stockage intermédiaire sous un format compilé, le compilateur servant à convertir les données de configuration de modèles sous un format de code objet compilé lisible par l'application de création de modèle. Cette variante permet d'éviter l'utilisation d'une base de données de configuration (ou d'une base de données analogue) pour stocker les données de configuration de modèles sous un format compilé, mais peut nécessiter une utilisation répétée du compilateur absolument chaque fois que l'application de création de modèle souhaite accéder aux mêmes données de configuration de modèles.
Selon une autre configuration possible, le système (et le procédé correspondant) peut éviter l'utilisation du fichier de configuration et, à la place, comporter la base de données de configuration compilées, la base de données de configuration compilées contenant les données de configuration de modèles sous un format compilé, le système comportant en outre une interface utilisateur permettant à un utilisateur d'être directement en interaction avec la base de données de configuration compilées pour réaliser au moins une des deux opérations suivantes : i) saisir les données de configuration de modèles dans la base de données de configuration compilées ; et ii) modifier les données de configuration de modèles déjà stockées dans la base de données de configuration compilées.
Cette variante de l'invention permet à un utilisateur d'être directement en interaction avec la base de données de configuration pour saisir des données de configuration de modèles dans la base de données de configuration ainsi que de modifier des données de configuration de modèles déjà contenues dans celle-ci. Dans un exemple préféré, l'interface utilisateur comprend une application logicielle compilée qui communique avec la base de données de configuration compilées pour permettre la saisie et/ou la modification des données de configuration de modèles par un utilisateur. Une telle application logicielle compilée constituerait une interface commode pour permettre à un utilisateur de saisir et/ou de modifier les données de configuration de modèles dans la base de données de configuration.
La segmentation décrite plus haut et l'utilisation d'un fichier de configuration et/ou d'une base de données de configuration compilées modifiable(s) et lisible(s) permet à quelqu'un d'autre qu'un spécialiste des logiciels de fournir au système des instructions suffisantes pour permettre à l'application de création de modèle de créer un ou plusieurs modèle(s) d'inférence adapté(s) au premier équipement (ou également au second équipement). Les algorithmes de traitement sollicités et employés par l'application de création de modèle auront une complexité variable, dépendant de la complexité de la tâche qu'ils exécutent. Certains des algorithmes de traitement auront une fonctionnalité de niveau bas ; par exemple, pour exécuter des tâches de lissage, de dégagement de tendances et de filtrage sur les données d'historique de fonctionnement reçues pour le premier équipement pendant le mode apprentissage ou sur les données de fonctionnement reçues d'un ou de plusieurs des premier(s) équipement(s) du premier parc pendant le mode exécution. D'autres algorithmes de traitement auront une fonctionnalité d'un niveau relativement plus élevé pour construire le/les modèle(s) d'inférence. Par exemple, ces algorithmes de traitement de niveau plus haut peuvent coordonner les opérations des algorithmes à fonctionnalité de niveau bas et utiliser les résultats de ces algorithmes de niveau bas pour ainsi construire le/les modèle(s) d'inférence pendant le mode apprentissage. L'algorithme de traitement ou au moins un des algorithmes de traitement est avantageusement intégré dans l'application de création de modèle. Selon une autre possibilité ou en outre, l'algorithme de traitement ou au moins un des algorithmes de traitement est présent dans un ou plusieurs serveur(s) et/ou base(s) de données avec lequel/lesquels ou laquelle/lesquelles communique l'application de création de modèle. Dans ce dernier cas, les données de configuration de modèles comprennent de préférence une adresse pour l'emplacement du serveur ou d'au moins un des serveurs et/ou de la base de données/des bases de données avec lequel/lesquels ou laquelle/lesquelles communique l'application de création de modèle. Dans l'un et l'autre cas, les algorithmes de traitement sont séparés et distincts des données de configuration de modèles. Ainsi, alors que le fichier de configuration et/ou la base de données de configuration compilées peut/peuvent contenir des instructions, des saisies ou autres données (c’est-à-dire les "données de configuration de modèles") qui seront ensuite utilisées par un algorithme de traitement donné mentionné dans le fichier et/ou la base de données, le fichier et/ou la base de données ne contient/contiennent pas lui-même/elle-même la totalité des algorithmes de traitement nécessaires à la construction du/des modèle(s) d'inférence. Cela facilite la modification et la compréhension du fichier de configuration et/ou de la base de données de configuration compilées pour un utilisateur non spécialisé du système, c’est-à-dire quelqu'un d'autre qu'un informaticien expérimenté.
Comme indiqué plus haut, les données de configuration de modèles sont adaptées au premier équipement et au(x) modèle(s) d'inférence voulu(s). Les données de configuration de modèles comprennent avantageusement une ou plusieurs des donnée(s) suivante(s) : un identifiant du premier équipement et une classification dans une catégorie dont relève le premier équipement ; un indicateur de la fonctionnalité nécessaire du/des modèle(s) d'inférence voulu(s) ; un indicateur de la fonctionnalité requise du/des modèle(s) d'inférence voulu(s) ; des valeurs attribuées à un ou plusieurs paramètre(s) associé(s) au fonctionnement du premier équipement ; une identité de l'algorithme de traitement ou d'au moins un des algorithmes de traitement pour une utilisation ultérieure par l'application de création de modèle afin de construire le/les modèle(s) d'inférence voulu(s) ; et un ou plusieurs paramètre(s) de saisie associé(s) à l'algorithme de traitement ou à au moins un des algorithmes de traitement.
Dans le contexte de l'exemple nullement limitatif du premier équipement constitué d'un moteur à turbine à gaz d'aéronef d'une marque et d'un modèle donnés, l'identifiant du premier équipement peut être la marque et le modèle du moteur, la classification étant celle de moteurs à turbine à gaz. Cependant, la nature de l'identifiant et la classification dans une catégorie varieront en fonction de la nature du premier équipement.
Des exemples nullement limitatifs d'indicateurs de la fonctionnalité requise du/des modèle(s) d'inférence voulu(s) comprennent la spécification d'un résultat voulu requis de l'utilisation d'un modèle d'inférence dans le mode exécution, et l'information selon laquelle le modèle d'inférence voulu à construire dans le mode apprentissage est destiné à n'indiquer que la présence d'une anomalie de fonctionnement d'un équipement donné et/ou est destiné à évaluer la classe de l'anomalie révélée.
Des exemples nullement limitatifs des valeurs attribuées à un ou plusieurs paramètre(s) associé(s) au fonctionnement du premier équipement comprennent des valeurs de poussée maximale au décollage, de poussée à l'altitude de croisière et de débits spécifiques de consommation de carburant pour un premier modèle de moteur à turbine à gaz d'aéronef. Cependant, la nature de ces valeurs et leurs paramètres associés varieront suivant la nature du premier équipement ; par exemple, si le premier équipement était un système de commande de vol, ces valeurs comprendraient vraisemblablement des valeurs de tension ou d'intensité.
On mentionnera, comme exemples nullement limitatifs du/des paramètre(s) d'entrée associé(s) à l'algorithme de traitement ou au moins à l'un des algorithmes de traitement, la pression, la température ou les variations de pression et de température dans l'espace et/ou le temps, rencontrées dans un élément donné d'un premier modèle de moteur à turbine à gaz d'aéronef. Là encore, cependant, la nature des paramètres d'entrée variera en fonction de la catégorie de l'équipement. Comme indiqué plus haut, si le premier équipement était, par exemple, dans la catégorie des systèmes de commande de vol, les paramètres d'entrée comprendraient vraisemblablement diverses tensions ou intensités dans une ou plusieurs partie(s) du système de commande de vol.
De plus, les données de configuration de modèles comprennent avantageusement en outre une ou plusieurs des donnée(s) suivante(s) : des valeurs attribuées à une ou plusieurs propriété(s) physique(s) du premier équipement ; des valeurs définissant une limite supérieure et/ou inférieure pour le paramètre d'entrée ou au moins un des paramètres d'entrée ; des valeurs de consigne pour l'algorithme de traitement ou au moins un des algorithmes de traitement ; une valeur de consigne de commande définissant si, oui ou non, l'application de création de modèle doit fonctionner dans le mode apprentissage ou le mode exécution ; et une valeur de consigne d'alerte définissant une action à effectuer ou un avertissement à fournir à un utilisateur du système en fonction d'un résultat du/des outil(s) d'inférence construit(s) pendant l'utilisation dans le mode exécution.
Un exemple nullement limitatif de valeurs attribuées à une ou plusieurs propriété(s) physique(s) du premier équipement comprend une masse ou une/des dimension(s) d'un ou de plusieurs organe(s) d'un premier modèle de moteur à turbine à gaz d'un aéronef. Cependant, les propriétés physiques utilisées varieront en fonction de la nature du premier équipement.
Un exemple nullement limitatif de valeurs définissant une limite supérieure et/ou inférieure pour le paramètre d'entrée et/ou au moins un des paramètres d'entrée comprend une valeur maximale de pression ou de température. Ces valeurs limites peuvent comprendre la température et/ou la pression maximale(s) admissible(s) qui peut/peuvent être supportée(s) par un ou plusieurs organe(s) d'un premier modèle de moteur à turbine à gaz d'aéronef ; par exemple, une température maximale admissible dans la chambre de combustion ou une température maximale admissible pour une ou plusieurs des aubes mobiles d'une turbine dans la section turbine du moteur. De plus ou selon une autre possibilité, ces valeurs peuvent représenter des minima ou des maxima de paramètres de fonctionnement qui, si elles étaient présentes dans les données d'historique de fonctionnement reçues (pour le mode apprentissage) ou dans les données de fonctionnement reçues pendant le fonctionnement des premiers équipements (pour le mode exécution), seraient indiscutablement aberrantes et, de ce fait, indiqueraient plutôt la présence d'une anomalie dans un capteur prévu pour fournir les données. De préférence, dans ce cas, l'application de création de modèle ne tiendrait pas compte de données reçues pendant les modes apprentissage ou exécution, dont les valeurs dépasseraient les minima ou les maxima définis, ce qui éviterait que l'application de création de modèle ne soit biaisée par des erreurs de relevés de capteur pendant i) la construction des modèles d'inférence (pendant le mode apprentissage) ou ii) l'utilisation des modèles d'inférence construits (pendant le mode exécution).
Des exemples nullement limitatifs de valeur de consigne d'alerte définissant une action à effecteur ou un avertissement à communiquer à un utilisateur du système en fonction d'un résultat du/des outil(s) d'inférence construit(s) pendant l'utilisation dans le mode exécution comprennent la production d'un signal d'alerte sonore ou visuel à l'attention de l'utilisateur du système pour lui signaler en temps utile une anomalie détectée par le système et/ou pour lui fournir des informations identifiant la cause de l'anomalie. L'anomalie détectée peut, par exemple, être une variabilité excessive d'un intervalle de valeurs donné pour le débit massique dans la section turbine d'un premier modèle de moteur à turbine à gaz d'aéronef, la cause identifiée de l'anomalie étant une rupture d'aube de rotor de turbine ou un défaut dans l'écoulement de carburant jusqu'à la chambre de combustion du moteur.
La nature précise des identifiants, des indicateurs, des paramètres, des valeurs et des valeurs de consigne ci-dessus dépendra de la catégorie du premier équipement. Si le premier équipement relevait, par exemple, de la catégorie des systèmes de commande de vol d'aéronef, les valeurs et valeurs de consigne pourraient très bien concerner des signaux électriques d'entrée/sortie fournis par le système de commande de vol. Comme indiqué plus haut dans la description, le système et le procédé selon l'invention peuvent s'appliquer à tout équipement dans lequel existe un besoin ou un désir de télécontrôler l'état de l'équipement. Ces équipements peuvent comprendre des systèmes mécaniques, électriques, électromécaniques et matériels/logiciels (ou une combinaison de ceux-ci). L'invention sera mieux comprise à l'étude de la description détaillée d'un mode de réalisation pris à titre d'exemple non limitatif et illustré par les dessins annexés sur lesquels : -la Figure 1 représente un premier exemple de système selon l'invention, associé à un premier parc d'un premier modèle de moteur à turbine à gaz d'aéronef ; -la Figure 2 représente un deuxième exemple de système selon l'invention, associé au premier parc du premier modèle de moteur à turbine à gaz d'aéronef ; -la Figure 3 illustre un exemple du contenu d'un fichier de configuration utilisable avec les exemples de systèmes des figures 1 et 2 ; et -la Figure 4 représente les flux de données entre différentes parties du système de la Figure 1 pendant son fonctionnement pour un premier et un second parcs de premiers et deuxièmes équipements correspondants.
On notera que les figures visent à illustrer des exemples nullement limitatifs de l'invention.
La Figure 1 représente un premier exemple de système 1 dont les éléments sont représentés entourés par une délimitation en trait discontinu. La Figure 1 représente le système 1 utilisé avec un premier parc de premiers équipements 100. Le premier parc de premiers équipements 100 illustré consiste en une pluralité de moteurs d'un premier modèle de moteur à turbine à gaz d'aéronef utilisé dans un certain nombre d'aéronefs. Cependant, comme indiqué dans la description générale qui précède, l'équipement ne se limite à aucun secteur technologique. Dans d'autres formes de réalisation non illustrées, l'équipement peut être un système de commande de vol d'un aéronef, une turbine éolienne ou prendre n'importe quelle autre forme. Le système et le procédé selon l'invention sont applicables à tout équipement pour lequel il peut être nécessaire ou souhaitable de télécontrôler l'état de l'équipement.
Le système 1 de la Figure 1 comporte un fichier de configuration 11, une base de données de configuration compilées 12 et une application de création de modèle 13. Le fichier de configuration 11 est contenu dans un module de mémoire 141 d'un ordinateur 14. L'ordinateur 14 comprend aussi un processeur 142 couplé au module de mémoire 141, le processeur étant conçu pour exécuter l'application de création de modèle 13. L'application de création de modèle 13 est une application informatique exécutable apte à exécuter une ou plusieurs tâches lorsqu'elle est exécutée par le processeur 142. L'ordinateur 14 est couplé à un écran d'affichage 143 visible par un utilisateur U du système 1 pour permettre à l'utilisateur de lire le contenu du fichier de configuration 11. L'ordinateur 14 est également couplé à un dispositif de saisie 144 tel qu'un clavier pour permettre à l'utilisateur U de modifier le fichier de configuration 11 et d'agir ainsi sur le fonctionnement de l'application de création de modèle 13.
Dans l'exemple illustré de la Figure 1, l'ordinateur communique avec un premier serveur 15, un deuxième serveur 16 et un troisième serveur 17. La communication peut être assurée par une connexion câblée et/ou radioélectrique entre l'ordinateur 14 et chacun des serveurs 15, 16, 17, comme indiqué sur la Figure 1 par les traits continus s'étendant entre les serveurs 15, 16, 17 et l'ordinateur 14. Dans l'exemple illustré, le premier serveur 15 contient la base de données de configuration compilées 12. Le deuxième serveur 16 contient une bibliothèque d'algorithmes de traitement accessible et utilisée par l'application de création de modèle 13. Dans un autre exemple possible non illustré sur les figures, les algorithmes de traitement sont contenus dans l'ordinateur 14, par exemple en étant stockés localement dans le module de mémoire 141 ou en étant codés pour être intégrés directement dans l'application de création de modèle 13. Le troisième serveur 17 contient une bibliothèque de données d'historique de fonctionnement correspondant à un fonctionnement normal et à des anomalies pour le premier modèle de moteur 100 à turbine à gaz d'aéronef. L'origine de ces données d'historique de fonctionnement est présentée dans la description générale qui précède. Il est préférable que ces données d'historique de fonctionnement proviennent de multiples moteurs du premier modèle de moteur 100 de turbine à gaz d'aéronef qui constituent collectivement le premier parc 100. Les états de fonctionnement normaux couverts par les données d'historique de fonctionnement peuvent comprendre le fonctionnement du premier modèle de moteur à turbine à gaz d'aéronef à la poussée nominale maximale (telle qu'elle pourrait être rencontrée pendant le décollage d'un aéronef correspondant au premier modèle de moteur à turbine à gaz d'aéronef), et le fonctionnement en régime de croisière à un certain nombre d'altitudes différentes et pour un certain nombre de conditions météorologiques différentes. Les conditions d'anomalies couvertes par les données d'historique de fonctionnement peuvent comprendre une rupture d'une aube mobile de turbine dans le premier modèle de moteur à turbine à gaz d'aéronef, l'ingestion d'un ou de plusieurs oiseaux par le moteur et la panne d'un ou de plusieurs des injecteurs dans la chambre de combustion du moteur. Dans d'autres formes de réalisation possibles non illustrées sur les figures, le contenu des trois serveurs différents 15, 16, 17 peut être rassemblé dans un plus petit nombre de serveurs ; par exemple, la base de données de configuration compilées 12, les algorithmes de traitement et les données d'historique de fonctionnement peuvent être placés dans un serveur commun communiquant avec l'ordinateur 14.
Pour le système 1 de la Figure 1, le fichier de configuration 11 est sous un format directement modifiable et lisible par l'utilisateur U. Des exemples nullement limitatifs du format du fichier de configuration 11 comprennent un fichier de tableur comprenant une ou plusieurs feuille(s) de calcul liées les unes aux autres, ou un fichier à format de langage de balisage extensible (XML). A titre d'exemple, le fichier de configuration 11 peut comprendre un ou plusieurs menu(s) déroulant(s) permettant à l'utilisateur U de choisir une ou plusieurs option(s) correspondant à des caractéristiques du premier équipement 100 et au modèle d'inférence voulu par l'utilisateur U. Comme représenté sur la Figure 1 (ainsi que sur la Figure 3), le fichier de configuration 11 contient des données de configuration de modèles 111. Les données de configuration de modèles 111 sont configurées pour une utilisation ultérieure par l'application de création de modèle 13 afin de permettre à l'application de création de modèle de construire un ou plusieurs modèle(s) d'inférence pour le premier modèle de moteur 100 à turbine à gaz d'aéronef. Les données de configuration de modèles 111 sont adaptées au premier modèle de moteur 100 de turbine à gaz d'aéronef et à tout modèle d'inférence voulu par l'utilisateur U. Un exemple de forme de ces données de configuration de modèles 111 est expliqué plus en détail dans des paragraphes ultérieurs, en référence à la Figure 3.
La base de données de configuration compilées 12 représentée sur la Figure 1 est conçue pour recevoir du fichier de configuration 11 les données de configuration de modèles 111 et pour stocker les données de configuration de modèles ainsi reçues sous un format de code objet compilé lisible par l'application de création de modèle 13. Dans l'exemple de système 1 illustré sur la Figure 1, la base de données de configuration compilées 12 est contenue dans le premier serveur 15. L'application de création de modèle 13 est conçue pour accéder à la base de données de configuration compilées 12 dans le premier serveur 15 pour ainsi accéder aux données de configuration de modèles compilées 111 stockées dans la base de données de configuration 12. En stockant les données de configuration 111 de modèles sous un format de code objet compilé, la base de données de configuration compilées 12 assure un accès rapide de l'application de création de modèle 13 aux données de configuration de modèles 111 sous un format facilement compréhensible par l'application de création de modèle. Bien que cela ne soit pas représenté sur la Figure 1, la base de données de configuration compilées 12 peut comprendre ou être couplée à un compilateur servant à compiler des données de configuration de modèles 111 reçues du fichier de configuration directement modifiables et lisibles 11.
Dans le deuxième exemple de système 2 représenté sur la Figure 2, un compilateur C est présent entre le module de mémoire 141 et l'application de création de modèle 13, aucune base de données de configuration compilées 12 ni aucun moyen équivalent n'étant prévu pour stocker les données de configuration de modèles 111 sous un format de code objet compilé. Les données de configuration de modèles 111 sont communiquées à l'application de création de modèle 13 directement par le compilateur C, sans stockage intermédiaire sous un format de code objet compilé. Dans ce deuxième exemple de système 2, chaque fois que l'application de création de modèle 13 doit accéder aux données de configuration de modèles 111, le compilateur C intervient pour compiler sous un format de code objet les données de configuration de modèles 111 reçues du fichier de configuration 11. Par conséquent, le compilateur C intervient pour compiler les données de configuration de modèles 111 comme l'exige l'application de création de modèle 13. De la sorte, le système 2 de la Figure 2 évite le recours à une base de données de configuration 12 (ou un équivalent) pour stocker les données de configuration de modèles 111 sous un format compilé.
Dans un autre exemple possible de système non représenté sur les dessins, on se passe de l'utilisation du fichier de configuration 11. Dans cet autre système possible, la base de données de configuration compilées 12 contient les données de configuration de modèles 11 sous un format compilé, le système comportant une interface utilisateur utilisable pour permettre à l'utilisateur U d'être directement en interaction avec la base de données de configuration compilées pour effectuer au moins une des opérations suivantes : i) saisir les données de configuration de modèles 111 dans la base de données de configuration compilées 12 ; et ii) modifier les données de configuration de modèles déjà stockées dans la base de données de configuration compilées.
Cette variante de l'invention permet à l'utilisateur d'interagir directement avec la base de données de configuration 12 pour saisir directement les données de configuration de modèles 111 dans la base de données de configuration ainsi que de modifier les données de configuration de modèles 111 déjà contenues dans celle-ci. Dans un exemple préféré, l'interface utilisateur comprendrait une application logicielle compilée communiquant avec la base de données de configuration compilées 12 pour permettre la saisie et/ou la modification des données de configuration de modèles par un utilisateur. Une telle application logicielle compilée constitue une interface commode pour permettre à un utilisateur de saisir et/ou de modifier les données de configuration de modèles dans la base de données de configuration. L'interface utilisateur peut également comprendre un écran d'affichage et un dispositif de saisie par clavier (similaires ou identiques à l'écran d'affichage 143 et au clavier 144) pour faciliter l'interaction entre l'utilisateur U et l'interface utilisateur.
Pour tous les systèmes décrits et/ou illustrés, l'application de création de modèle 13 est utilisable dans deux modes distincts : un mode apprentissage et un mode exécution - comme expliqué dans la description générale qui précède. Le fonctionnement de l'application de création de modèle 13 dans les deux modes apprentissage et exécution est déterminé par les données de configuration de modèles 111, les données de configuration de modèles étant adaptées au premier modèle de moteur 100 à turbine à gaz et au(x) modèle(s) d'inférence voulu(s) par l'utilisateur U. Dans le mode apprentissage, l'application de création de modèle 13 sert à construire un ou plusieurs modèle(s) d'inférence 19 (cf. Figure 4) pour le premier modèle de moteur 100 de turbine à gaz d'aéronef. Dans le mode apprentissage, l'application de création de modèle 13 de l'exemple illustrée est conçue pour : • accéder au troisième serveur 17 pour acquérir les données d'historique de fonctionnement représentatives du premier modèle de moteur 100 de turbine à gaz d'aéronef ; • accéder au deuxième serveur 16 pour solliciter un ou plusieurs des algorithmes de traitement contenus dans le deuxième serveur, en fonction des données de configuration de modèles 111 ; et • construire - à l'aide i) des données de configuration de modèles compilées 111, ii) des données d'historique de fonctionnement acquises et iii) du/des algorithme(s) de traitement sollicité(s) - un ou plusieurs modèle(s) d'inférence 19 pour le premier modèle de moteur 100 de turbine à gaz d'aéronef.
Comme indiqué dans la description générale qui précède, les modèles d'inférence 19 sont construits de manière à être aptes, pendant un mode exécution ultérieur de fonctionnement de l'application de création de modèle 13, à déduire, de données de fonctionnement reçues du moteur donné, un état de l'un quelconque des moteurs du premier parc 100 du premier modèle de moteur à turbine à gaz d'aéronef. Les modèles d'inférence 19 sont des modèles mathématiques de calcul relatifs au premier parc 100 du premier modèle de moteur à turbine à gaz d'aéronef. Grâce au fait que les modèles d'inférence 19 (cf. Figure 4) sont construits d'après des données d'historique de fonctionnement représentatives du premier modèle de moteur 100 de turbine à gaz d'aéronef, ces modèles mathématiques sont à même de tirer des conclusions d’après des données de fonctionnement en temps réel reçues d'un ou de plusieurs des moteurs du premier parc 100. Ces inférences comprennent une indication de ce que, oui ou non, une anomalie est présente lors du fonctionnement d'un moteur donné du premier parc 100, et/ou la classification de la nature de l'anomalie indiquée.
Le fonctionnement de l'application de création de modèle 13 dans les modes apprentissage et exécution dépend du contenu des données de configuration de modèles 111 - cela vaut quel que soit le format dans lequel sont stockées les données de configuration de modèles, c’est-à-dire indépendamment de ce que soit/soient employé(s) un fichier de configuration 11 et/ou une base de données de configuration compilées 12. Les données de configuration de modèles 111 sont adaptées au premier modèle de moteur à turbine à gaz d'aéronef du premier parc 100 et à tout modèle d'inférence 19 voulu par l'utilisateur U. Le modèle d'inférence voulu 19 peut être d'un type qui, lors de l'utilisation dans le mode exécution, fournit à l'utilisateur U un indicateur quant à la présence d'une anomalie dans le fonctionnement de l'un quelconque des moteurs du premier parc 100. Selon une autre possibilité ou en outre, le modèle d'inférence voulu peut être d'un type qui, lors d'une utilisation en mode exécution, fournit à l'utilisateur U un classement de l'anomalie indiquée dans un ou plusieurs état(s) d'anomalie(s) vraisemblable(s) pour le moteur donné. Suivant la complexité du modèle d'inférence voulu 19 construit par l'application de création de modèle 13, le modèle d'inférence fournit une estimation du temps restant avant une panne pour le moteur donné du premier parc 100.
Comme indiqué plus haut, la Figure 3 illustre un exemple d'agencement des données de configuration de modèles 111 du fichier de configuration 11. Les données de configuration de modèles 111 comprennent : • un identifiant 1111 du premier équipement 100 et un classement dans une catégorie correspondant au premier équipement. Dans l'exemple illustré, l'identifiant comprend la marque et le modèle du premier modèle de moteur 100 de turbine à gaz d'aéronef qui doit faire l'objet du/des modèle(s) d'inférence 19. Dans l'exemple illustré, la catégorie de classement est celle de moteurs à turbine à gaz d'aéronefs ; • un indicateur 1112 de la fonctionnalité requise du/des modèle(s) d'inférence voulu(s). Dans l'exemple illustré, cela comprend la spécification d'un ou de plusieurs résultat(s) nécessaire(s) à la suite de l'utilisation d'un modèle d'inférence 19 dans le mode exécution, et de ce que, oui ou non, le modèle d'inférence voulu est destiné à permettre l'indication de la présence d'une anomalie de fonctionnement d'un moteur du premier parc 100 et/ou est destiné à classer l'anomalie indiquée ; • des valeurs 1113 attribuées à un ou plusieurs paramètre(s) associé(s) au fonctionnement du premier modèle de moteur 100 à turbine à gaz d'aéronef. Dans l'exemple illustré, ces valeurs 1113 comprennent des valeurs de poussée maximale au décollage, de poussée à une altitude de croisière et de débits spécifiques de consommation de carburant pour le premier modèle de moteur à turbine à gaz d'aéronef ; • une identité 1114 de l'algorithme de traitement ou d'au moins un des algorithmes de traitement en vue d'une utilisation ultérieure par l'application de traitement de modèle 13 pour construire le/les modèle(s) d'inférence 19 ; • un ou plusieurs paramètre(s) d'entrée 1115 associé(s) à l'algorithme de traitement ou à au moins l'un des algorithmes de traitement. Dans l'exemple illustré, le/les paramètre(s) d'entrée 1115 comprend/comprennent la pression, la température et les variations de pression et de température dans l'espace et/ou le temps rencontrées dans un organe donné du premier modèle de moteur 100 à turbine à gaz d'aéronef ; • des valeurs 1116 attribuées à une ou plusieurs propriété(s) physique(s) du premier modèle de moteur à turbine à gaz d'aéronef. Dans l'exemple illustré, ces valeurs 1116 comprennent une masse ou une dimension d'un ou de plusieurs organe(s) du premier modèle de moteur 100 de turbine à gaz d'aéronef ; • des valeurs 1117 définissant une limite supérieure et/ou inférieure pour le paramètre d'entrée et/ou au moins un des paramètre(s) d'entrée. Dans l'exemple illustré, ces valeurs 1117 comprennent des valeurs maximales de pression et/ou de température, notamment la température et/ou pression maximale(s) admissible(s) que peut/peuvent supporter un ou plusieurs organe(s) du premier modèle de moteur 100 à turbine à gaz d'aéronef. De plus ou selon une autre possibilité, ces valeurs peuvent représenter des minima ou des maxima de pression ou de température (ou de tout autre paramètre d'entrée) qui, si elles sont présentes dans les données d'historique de fonctionnement reçues pour le mode apprentissage ou si elles sont présentes dans les données de fonctionnement reçues pendant le fonctionnement du premier modèle de moteur à turbine à gaz d'aéronef dans le mode exécution, seraient indiscutablement aberrantes et, de ce fait, indiqueraient plutôt l'existence d'une anomalie dans un capteur chargé de fournir les données ; • des valeurs de consigne 1118 pour l'algorithme de traitement ou au moins un des algorithme(s) de traitement ; • une valeur de consigne de commande 1119 définissant si, oui ou non, l'application de création de modèle 13 doit fonctionner dans le mode apprentissage ou dans le mode exécution ; et • une valeur de consigne d'alarme 1120 définissant une mesure à prendre ou une alerte à communiquer à un utilisateur du système 1, 2 en fonction d'un résultat du/des modèle(s) d'inférence construit(s) pendant l'utilisation dans le mode exécution. Les mesures définies par la valeur de consigne d'alarme 1120 peuvent comprendre la fourniture d'un signal d'avertissement sonore ou d'un signal d'avertissement visuel à l'utilisateur U pour l'avertir en temps utile d'une anomalie détectée par le système 1, 2 et/ou pour fournir à l'utilisateur une identité de la cause de l'anomalie. Un tel signal d'avertissement visuel peut être communiqué à l'utilisateur U par l'écran d'affichage 143, l'écran d'affichage comprenant également une enceinte acoustique (non représentée sur les figures) pour permettre une communication du signal d'avertissement sonore à l'utilisateur. L'adaptabilité des systèmes 1, 2 à la création de modèles d'inférence adaptés à des parcs de différents équipements est expliquée en référence à la Figure 4. La Figure 4 est une représentation simplifiée des éléments du système 1 (certains éléments étant absents), mais annotée pour indiquer le flux de données dans le système 1 et la nature des résultats du système pendant le mode apprentissage de fonctionnement de l'application de création de modèle 13. La Figure 4 illustre la présence du premier parc 100 de premiers équipements qui (comme indiqué précédemment) consiste en une pluralité de moteurs d'un premier modèle de moteur à turbine à gaz d'aéronef utilisé sur un certain nombre d'aéronefs. Cependant, la Figure 4 illustre aussi la présence d'un second parc 200 de deuxièmes équipements. Le second parc de deuxièmes équipements 200 illustré consiste en une pluralité de moteurs d'un deuxième modèle de moteur à turbine à gaz d'aéronef utilisé dans un certain nombre d'aéronefs. Par conséquent, on peut constater que les premiers et deuxièmes équipements 100, 200 relèvent d'une même catégorie de moteurs à turbine à gaz d'aéronefs. Cependant, les premiers et deuxièmes équipements 100, 200 diffèrent les uns des autres par un ou plusieurs aspects de leur construction (et donc de leurs performances) résultant du fait qu'il s'agit de deux modèles de moteurs différents. Le fichier de configuration 11 et la base de données de configuration compilées 12 correspondent au premier modèle 100 de moteur à turbine à gaz d'aéronef. Cependant, sur la Figure 4 sont également représentés un fichier de configuration 21 et une base de données de configuration compilées 22 séparés qui correspondent au deuxième modèle 200 de moteur à turbine à gaz d'aéronef. Bien que cela ne soit pas illustré sur la Figure 4, dans un exemple, les bases de données de configuration 12, 22 sont situées l'une et l'autre dans le premier serveur 15. Selon une autre possibilité, les bases de données de configuration 12, 22 peuvent être situées dans des serveurs respectifs différents aptes à communiquer avec l'ordinateur 14 et l'application de création de modèle 13. Les données de configuration de modèles 111, 211 des fichiers de configuration 11, 21 sont adaptées aux premier et second modèle respectifs de moteur 100, 200 et à tout modèle d'inférence 19, 29 voulu pour les premiers et deuxièmes modèles respectifs de moteurs à turbine à gaz 100, 200 d'aéronefs.
Dans l'exemple illustré sur la Figure 4, le deuxième serveur 16 contient les algorithmes de traitement (présentés antérieurement pour le système 1 de la Figure 1). Par ailleurs, le troisième serveur 17 contient des bibliothèques respectives de données d'historique de fonctionnement correspondant à des conditions de fonctionnement normales et d'anomalies pour le premier modèle de moteur 100 à turbine à gaz d'aéronef et le deuxième modèle de moteur 200 de turbine à gaz d'aéronef.
Lors de l'utilisation dans le mode apprentissage, l'application de création de modèle 13 construit une première série de modèles d'inférence 19 correspondant au premier modèle de moteur 100 de turbine à gaz d'aéronef et une deuxième série de modèles d'inférence 29 correspondant au deuxième modèle de moteur 200 à turbine à gaz d'aéronef. L'application de création de modèle 13 construit les séries respectives de modèles d'inférence 19, 29 pour le premier et le deuxième modèles 100, 200 de moteurs en utilisant respectivement i) les données de configuration de modèles compilées 111, 211 stockées dans les bases de données de configuration compilées respectives 12, 22, ii) les données d'historique de fonctionnement contenues dans le troisième serveur 17, correspondant aux premier et deuxième modèles respectifs 100, 200 de moteurs ; et iii) le/les algorithme(s) de traitement sollicité(s) contenu(s) dans le deuxième serveur 16. Dans l'exemple illustré sur la Figure 4, les fichiers de configuration 11, 21 et les bases de données de configuration compilées 12, 22 pour les premier et deuxième modèles de moteur à turbine à gaz d'aéronef 100, 200 coexistent les uns avec les autres, l'application de création de modèle 13 accédant successivement ou simultanément aux bases de données de configuration respectives 12, 22 lorsqu'elle sert à construire les séries respectives de modèles d'inférence 19, 20. Dans un autre exemple possible, le fichier de configuration 22 peut être obtenu en modifiant le contenu du fichier de configuration 11, un seul des fichiers de configuration 11, 22 pouvant exister à un instant donné.
Pendant le mode exécution, l'application de création de modèle 13 utilise la série respective de modèles d'inférence 19, 29 pour déduire l'état d'un ou de plusieurs, quelconque, des moteurs du premier ou du second parc 100, 200. Dans le mode exécution, l'application de création de modèle 13 reçoit des données de fonctionnement 101, 201 (de préférence en temps réel ou presque) d'un ou de plusieurs des moteurs des premier et second parcs respectifs 100, 200 (cf. Figure 4). Dans l'exemple illustré de la Figure 4, ces données de fonctionnement 101, 201 sont transmises par voie radioélectrique depuis les premier et second parcs 100, 200 de moteurs pour être reçues par un émetteur-récepteur (non représenté) couplé à l'application de création de modèle 13. L'application de création de modèle 13 utilise ensuite la série de modèles d'inférence 19 qui correspond au parc respectif 100, 200 duquel sont reçues les données de fonctionnement 101, 201 afin de traiter les données de fonctionnement reçues conformément aux données de configuration de modèles respectives 111, 211 pour déduire de la sorte un état d'un ou de plusieurs des moteurs du premier ou du second parc 100, 200. Comme expliqué dans la description générale qui précède, l'état déduit peut être une indication de la présence d'une anomalie de fonctionnement de l'un, donné, des moteurs du premier ou du second parc 100, 200. Selon une autre possibilité ou en outre, l'état déduit peut être un classement de l'anomalie détectée et/ou un temps restant prédit avant la panne d'un ou de plusieurs organe(s) du moteur donné.

Claims (15)

  1. REVENDICATIONS
    1. Système (1) pour créer et déployer un ou plusieurs modèle(s) d'inférence (19) destiné à servir au télécontrôle de l'état d'un premier parc d'un premier équipement (100), le système (1) est caractérisé en ce qu’il comprend : a) un fichier de configuration (11) et/ou une base de données de configuration compilées (12), le fichier de configuration (11) et/ou la base de données de configuration compilées (12) étant modifiables et lisibles par un utilisateur (U) et contenant des données de configuration de modèles (111) destinées à être utilisées par une application de création de modèle (13) pour construire un ou plusieurs modèle(s) d'inférence voulu(s) pour le premier équipement (100), les données de configuration de modèles (111) étant adaptées au premier équipement (100) et au(x) modèle(s) d'inférence voulu(s) (19) ; b) une application de création de modèle (13), l'application de modèle (13) étant conçue pour : recevoir les données de configuration de modèles (111) issues du fichier de configuration (11) et/ou de la base de données de configuration compilées (12) ; et fonctionner en mode apprentissage et en mode exécution, en fonction des données de configuration de modèles reçues (111) ; pour le mode apprentissage, l'application de création de modèle (13) étant conçue pour : recevoir des données d'historique de fonctionnement correspondant à une pluralité d'états de fonctionnement du premier équipement (100) ; solliciter un ou plusieurs algorithme(s) de traitement, le/les algorithme(s) de traitement sollicité(s) étant déterminé(s) par les données de configuration de modèles (111) ; et construire - à l'aide des données de configuration de modèles reçues (111), des données d'historique de fonctionnement reçues et du/des algorithme(s) de traitement sollicité(s) - le/les modèle(s) d'inférence voulu(s) (19) de façon que le/les modèle(s) d'inférence voulu(s) (19) puisse(nt) servir à déduire un état d'un ou de plusieurs des premier(s) équipement(s) (100) du premier parc d’après des données de fonctionnement reçues du/des premier(s) équipement(s) (100) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) (100) ; pour le mode exécution, l'application de création de modèle (13) étant conçue pour : recevoir des données de fonctionnement d'un ou de plusieurs des premier(s) équipement(s) (100) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) (100) ; et utiliser le modèle d'inférence construit (19) ou au moins un des modèle(s) d'inférence construit(s) (19) pour traiter les données de fonctionnement reçues afin de déduire de la sorte un état du/des premier(s) équipement(s) (100) d'après les données de fonctionnement reçues.
  2. 2. Système (1) selon la revendication 1, le système (1) comportant le fichier de configuration (11), le fichier de configuration (11) étant directement modifiable et lisible par un utilisateur et contenant les données de configuration de modèles (111).
  3. 3. Système selon la revendication 2, le système (1) comportant en outre la base de données de configuration compilées (12), la base de données de configuration compilées (12) étant conçue pour recevoir du fichier de configuration (11) les données de configuration de modèles (111) et stocker les données de configuration de modèles (111) ainsi reçues sous un format de code objet compilé lisible par l'application de création de modèle (13), l'application de création de modèle (13) étant conçue pour recevoir les données de configuration de modèles compilées (111) en accédant à la base de données de configuration compilées (12).
  4. 4. Système (1) selon la revendication 2, le système comportant en outre un compilateur (C) disposé sur un circuit de communication entre le fichier de configuration (11) et l'application de création de modèle (13), l'application de création de modèle (13) étant conçue pour recevoir les données de configuration de modèles (111) directement du fichier de configuration (11) via le compilateur (C) sans stockage intermédiaire sous un format compilé, le compilateur (C) servant à convertir les données de configuration de modèles (111) sous un format de code objet compilé lisible par l'application de création de modèle (13).
  5. 5. Système (1) selon la revendication 1, le système (1) comportant la base de données de configuration compilées (12), la base de données de configuration compilées (12) contenant les données de configuration de modèles (111) sous un format compilé, le système (1) comportant en outre une interface utilisateur utilisable par un utilisateur (U) pour interagir directement avec la base de données de configuration compilées (12) pour réaliser au moins une des opérations suivantes : i) saisie des données de configuration de modèles (111) dans la base de données de configuration compilées (12) ; et ii) modification des données de configuration de modèles (111) déjà stockées dans la base de données de configuration compilées (12).
  6. 6. Système (1) selon l'une quelconque des revendications précédentes, dans lequel l'algorithme de traitement ou au moins un des algorithmes de traitement (i) est/sont intégré(s) dans l'application de création de modèle (13) et/ou (ii) est/sont compris dans un ou plusieurs serveur(s) (15, 16, 17) et/ou d'une base de données ou d'au moins une des bases de données avec lesquels/lesquelles communique l'application de création de modèle (13).
  7. 7. Système (1) selon la revendication 6, dans lequel les données de configuration de modèles (111) comprennent une ou plusieurs des données suivantes : une adresse pour l'emplacement du serveur ou d'au moins un des serveur(s) (15, 16, 17) et/ou d'une base de données ou d'au moins une des bases de données avec lesquels/lesquelles communique l'application de création de modèle (13) ; un identifiant (1111) du premier équipement (100) et une classification dans une catégorie dont relève le premier équipement (100) ; un indicateur (1112) de la fonctionnalité requise du/des modèle(s) d'inférence voulu(s) (19) ; des valeurs attribuées (1113) à un ou plusieurs paramètres associés au fonctionnement du premier équipement (100) ; une identité (1114) d'un algorithme de traitement ou d'au moins un des algorithmes de traitement en vue d'une utilisation ultérieure par l'application de création de modèle (13) pour construire le/les modèle(s) d'inférence voulu(s) (19) ; un ou plusieurs paramètres d'entrée (1115) associé(s) à l'algorithme de traitement ou au moins à l'un des algorithmes de traitement ; des valeurs (1116) attribuées à une ou plusieurs propriétés physiques du premier équipement (100) ; des valeurs (1117) définissant une limite supérieure et/ou inférieure pour le paramètre d'entrée ou au moins un des paramètres d'entrée (1115) ; des valeurs de consigne (1118) pour l'algorithme de traitement ou au moins un des algorithmes de traitement ; une valeur de consigne de commande (1119) définissant si, oui ou non, l'application de création de modèle (13) doit fonctionner dans le mode apprentissage ou le mode exécution ; et une valeur de consigne d'alerte (1120) définissant une mesure à prendre ou un avertissement à communiquer à un utilisateur (U) du système (1) en fonction d'un résultat obtenu par le/les outil(s) d'inférence construit(s) pendant l'utilisation dans le mode exécution.
  8. 8. Procédé pour construire un ou plusieurs modèle(s) d'inférence destiné(s) à servir au télécontrôle de l'état d'un premier parc d'un premier équipement (100), le procédé comportant : a) la réalisation d'un fichier de configuration (11) et/ou d'une base de données de configuration compilées (12), le fichier de configuration (11) et/ou la base de données de configuration compilées (12) étant modifiable(s) et lisible(s) par un utilisateur (U) et contenant des données de configuration de modèles (111) à utiliser ultérieurement par une application de création de modèle (13) pour construire-un ou plusieurs modèle(s) d'inférence voulu(s) (19) pour le premier équipement (100), les données de configuration de modèles (111) étant adaptées au premier équipement (100) et au(x) modèle(s) d'inférence voulu(s) (19) ; b) réaliser l'application de création de modèle (13) ; c) l'application de création de modèle (13) recevant les données de configuration de modèles (111) issues du fichier de configuration (11) et/ou de la base de données de configuration compilées (12) ; d) faire fonctionner l'application de création de modèle (13) en mode apprentissage en fonction des données de configuration de modèles reçues (111), l'application de création de modèle (13), dans le mode apprentissage : recevant des données d’historique de fonctionnement correspondant à une pluralité d’états de fonctionnement du premier équipement (100) ; sollicitant un ou plusieurs algorithme(s) de traitement, le/les algorithme(s) de traitement sollicité(s) étant déterminé(s) par les données de configuration de modèles (111) ; et construisant- à l'aide des données de configuration de modèles reçues (111), des données d'historique de fonctionnement reçues et du/des algorithme(s) de traitement sollicité(s) - le/les modèle(s) d'inférence voulu(s) (19), les modèles d'inférence (19) pouvant de la sorte servir à déduire un état d'un ou de plusieurs des premier(s) équipement(s) (100) du premier parc d’après des données de fonctionnement reçues du/des premier(s) équipement(s) (100) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) (100).
  9. 9. Procédé selon la revendication 8, le procédé comportant la réalisation du fichier de configuration (11), le fichier de configuration (11) étant directement modifiable et lisible par un utilisateur et contenant les données de configuration de modèles (111).
  10. 10. Procédé selon la revendication 9, le procédé comportant en outre la réalisation de la base de données de configuration compilées (12), la base de données de configuration compilées (12) étant conçue pour recevoir les données de configuration de modèles (111) issues du fichier de configuration (II) et stocker les données de configuration de modèles (111) ainsi reçues sous un format de code objet compilé lisible par l'application de création de modèle (13), l'application de création de modèle (13) recevant les données de configuration de modèles compilées (111) en accédant à la base de données de configuration compilées (12).
  11. 11. Procédé selon la revendication 8, le procédé comportant la réalisation de la base de données de configuration compilées (12), la base de données de configuration compilées (12) contenant les données de configuration de modèles (111) sous un format compilé, le système (1) comprenant en outre une interface utilisateur servant à un utilisateur pour interagir avec la base de données de configuration compilées (12) afin de réaliser au moins une des opérations suivantes : i) saisie des données de configuration de modèles (111) dans la base de données de configuration compilées (12) ; et ii) modification des données de configuration de modèles (III) déjà stockées dans la base de données de configuration compilées (12).
  12. 12. Procédé selon l'une quelconque des revendications 8 à 11, dans lequel l'algorithme de traitement ou au moins un des algorithmes de traitement (i) est/sont intégré(s) dans l'application de création de modèle (13) et/ou (ii) est/sont inclus dans un ou plusieurs serveurs (15, 16, 17) et/ou une ou plusieurs base(s) de données avec lequel/lesquels et/ou laquelle/lesquelles communique l'application de création de modèle (13).
  13. 13. Procédé selon la revendication 12, dans lequel les données de configuration de modèles (111) contiennent une ou plusieurs des données suivantes : une adresse pour l'emplacement du serveur ou d'un des serveurs (15, 16, 17) et/ou d'une base de données ou de bases de données avec lequel/lesquels et/ou avec laquelle/lesquelles communique l'application de création de modèle (13) ; un identifiant (1111) du premier équipement (100) et un classement dans une catégorie dont relève le premier équipement (100) ; un indicateur (1112) de la fonctionnalité requise du/des modèle(s) d'inférence (19) ; des valeurs (1113) attribuées à un ou plusieurs paramètre(s) associé(s) au fonctionnement du premier équipement (100) ; une identité (1114) de l'algorithme de traitement ou d'au moins un des algorithmes de traitement pour une utilisation ultérieure par l'application de création de modèle (13) lors de la construction du/des modèle(s) d'inférence voulu(s) (19) ; un ou plusieurs paramètres d'entrée (1115) associé(s) à l'algorithme de traitement ou au moins à l'un des algorithmes de traitement ; des valeurs (1116) attribuées à une ou plusieurs propriété(s) physique(s) du premier équipement (100) ; des valeurs (1117) définissant une limite supérieure et/ou inférieure pour le paramètre d'entrée ou au moins un des paramètres d'entrée (1115) ; des valeurs de consigne (1118) pour l'algorithme de traitement ou au moins un des algorithmes de traitement ; une valeur de consigne de commande (1119) définissant si, oui ou non, l'application de création de modèle (13) doit fonctionner dans le mode apprentissage ou dans un mode exécution ; et une valeur de consigne d'alerte (1120) définissant une mesure à prendre ou un avertissement à communiquer à un utilisateur (U) du système (1) en fonction d'un résultat obtenu par le/les outil(s) d'inférence construit(s) pendant une utilisation en mode exécution.
  14. 14. Procédé selon l'une quelconque des revendications 8 à 13, le procédé comportant les étapes successives de : fonctionnement de l'application de création de modèle (13) en mode exécution en fonction des données de configuration de modèles (111) reçues par l'application de création de modèle (13), l'application de création de modèle (13), en mode exécution : recevant des données de fonctionnement d’un ou de plusieurs des premier(s) équipement(s) (100) du premier parc pendant le fonctionnement du/des premier(s) équipement(s) (100) ; et utilisant le modèle d’inférence ou au moins un des modèles d’inférence construit(s) (19) pour traiter les données de fonctionnement reçues afin de déduire de la sorte un état du/des premier(s) équipement(s) (100) d'après les données de fonctionnement reçues.
  15. 15. Procédé selon l'une quelconque des revendications 8 à 14, le procédé étant en outre conçu pour construire un ou plusieurs modèle(s) d'inférence (19) à utiliser lors du télécontrôle de l'état d'un second parc d'un second équipement (200), les premier(s) et deuxième(s) équipement(s) (100, 200) relevant d'une même catégorie mais différant par leur construction, sachant que : l'étape (a) est effectuée pour le second équipement (200) afin de réaliser, pour le second équipement (200), un fichier de configuration (21) et/ou une base de données de configuration compilées (22) correspondant(s), contenant des données de configuration de modèles (211) adaptées au second équipement (200) et un ou plusieurs modèle(s) d'inférence voulu(s) (29) pour le second équipement (200) ; l’étape (c) est réalisée pour le second équipement (200), l’application de création de modèle (13) recevant les données de configuration de modèles (211) issues du fichier de configuration (21) et/ou de la base de données de configuration compilées (22) correspondant(s) pour le second équipement ; et sachant que l’étape (d) est réalisée pour le second équipement (200) pour ainsi construire le/les modèle(s) d’inférence voulu(s) (29) pour le second équipement (200), le/les modèle(s) d’inférence voulu(s) (29) pouvant de ce fait servir à déduire un état d’un ou de plusieurs des deuxième(s) équipement(s) (200) du second parc d’après des données de fonctionnement reçues du/des deuxième(s) équipement(s) (200) du second parc pendant le fonctionnement du/des deuxième(s) équipement(s) (200).
FR1557885A 2014-08-26 2015-08-24 Systeme pour creer et deployer un modele d'inference Active FR3025337B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1415079.1A GB2529637B (en) 2014-08-26 2014-08-26 System for building and deploying inference model
GB1415079.1 2014-08-26

Publications (2)

Publication Number Publication Date
FR3025337A1 FR3025337A1 (fr) 2016-03-04
FR3025337B1 true FR3025337B1 (fr) 2019-08-16

Family

ID=51727044

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1557885A Active FR3025337B1 (fr) 2014-08-26 2015-08-24 Systeme pour creer et deployer un modele d'inference

Country Status (3)

Country Link
US (1) US11113610B2 (fr)
FR (1) FR3025337B1 (fr)
GB (1) GB2529637B (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11181898B2 (en) * 2017-11-10 2021-11-23 General Electric Company Methods and apparatus to generate a predictive asset health quantifier of a turbine engine
US11086637B1 (en) * 2018-04-03 2021-08-10 Akamai Technologies, Inc. Configuration transformation and delivery
US11200069B1 (en) 2020-08-21 2021-12-14 Honeywell International Inc. Systems and methods for generating a software application
US20230083443A1 (en) * 2021-09-16 2023-03-16 Evgeny Saveliev Detecting anomalies in physical access event streams by computing probability density functions and cumulative probability density functions for current and future events using plurality of small scale machine learning models and historical context of events obtained from stored event stream history via transformations of the history into a time series of event counts or via augmenting the event stream records with delay/lag information

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100223211A1 (en) * 2000-10-11 2010-09-02 Johnson Gregory A Decision service method and system
US6609051B2 (en) * 2001-09-10 2003-08-19 Daimlerchrysler Ag Method and system for condition monitoring of vehicles
US7107585B2 (en) * 2002-07-29 2006-09-12 Arm Limited Compilation of application code in a data processing apparatus
US6751536B1 (en) * 2002-12-04 2004-06-15 The Boeing Company Diagnostic system and method for enabling multistage decision optimization for aircraft preflight dispatch
US20040243636A1 (en) * 2003-03-18 2004-12-02 Smartsignal Corporation Equipment health monitoring architecture for fleets of assets
US7640145B2 (en) 2005-04-25 2009-12-29 Smartsignal Corporation Automated model configuration and deployment system for equipment health monitoring
US20070088570A1 (en) * 2005-10-18 2007-04-19 Honeywell International, Inc. System and method for predicting device deterioration
US7818276B2 (en) 2006-02-03 2010-10-19 Recherche 2000 Inc. Intelligent monitoring system and method for building predictive models and detecting anomalies
EP1818746A1 (fr) * 2006-02-10 2007-08-15 ALSTOM Technology Ltd Procédé de surveillance de condition
US20070203869A1 (en) * 2006-02-28 2007-08-30 Microsoft Corporation Adaptive semantic platform architecture
US20090234710A1 (en) * 2006-07-17 2009-09-17 Asma Belgaied Hassine Customer centric revenue management
FR2905763B1 (fr) * 2006-09-11 2008-12-12 Eurocopter France Procede et systeme de diagnostic d'un aeronef a partir de mesures effectuees sur l'aeronef.
US7917240B2 (en) * 2006-09-29 2011-03-29 Fisher-Rosemount Systems, Inc. Univariate method for monitoring and analysis of multivariate data
GB2496386A (en) * 2011-11-08 2013-05-15 Ge Aviat Systems Ltd Method for integrating models of a vehicle health management system

Also Published As

Publication number Publication date
GB2529637A (en) 2016-03-02
GB201415079D0 (en) 2014-10-08
FR3025337A1 (fr) 2016-03-04
US20160063384A1 (en) 2016-03-03
US11113610B2 (en) 2021-09-07
GB2529637B (en) 2017-07-05

Similar Documents

Publication Publication Date Title
EP3123139B1 (fr) Procédé d'estimation du caractère normal ou non d'une valeur mesurée d'un paramètre physique d'un moteur d'aéronef
FR3025337B1 (fr) Systeme pour creer et deployer un modele d'inference
CA2746537C (fr) Standardisation de donnees utilisees pour la surveillance d'un moteur d'aeronef
CA2944120C (fr) Procede et dispositif de surveillance d'un parametre d'un moteur de fusee
EP2912526B1 (fr) Système de surveillance d'un ensemble de composants d'un équipement
EP2756280B1 (fr) Système de surveillance d'une chaîne de mesure d'un turboréacteur
EP3350660B1 (fr) Système et procédé d'aide à la decision pour la maintenance d'une machine avec apprentissage d'un modèle de décision supervisé par avis d'experts
EP3871078A1 (fr) Système d'environnement informatique pour la surveillance de moteurs d'aéronefs
FR3037679A1 (fr)
FR3035232A1 (fr) Systeme de surveillance de l'etat de sante d'un moteur et procede de configuration associe
FR2990547A1 (fr) Systeme de maintenance centralisee parametrable destine a un aeronef
CA2918215C (fr) Procede d'estimation sur une courbe d'un point pertinent pour la detection d'anomalie d'un moteur et systeme de traitement de donnees pour sa mise en oeuvre
WO2021069824A1 (fr) Dispositif, procédé et programme d'ordinateur de suivi de moteur d'aéronef
FR3010200A1 (fr) Procede et dispositif de normalisation de valeurs de parametres de fonctionnement d'un moteur d'aeronef
FR3026785B1 (fr) Surveillance d'un ensemble du systeme propulsif d'un aeronef
WO2016087770A1 (fr) Procédé de surveillance du fonctionnement d'une turbomachine
Prist et al. Machine learning-as-a-service for consumer electronics fault diagnosis: A comparison between Matlab and Azure ML
CA2813619C (fr) Procede et dispositif de configuration d'un systeme de gestion d'alertes pour aeronef
EP2796955B1 (fr) Système de détection d'anomalie
EP3839450B1 (fr) Procede et dispositif d'analyse des vibrations d'un element
WO2021180726A1 (fr) Procédé et système de contrôle non destructif d'une pièce aéronautique
WO2023187287A1 (fr) Procédé de surveillance de l'état de santé de turbomachine d'aéronef
FR3076634A1 (fr) Procede d'analyse de symptomes de panne de plateformes, et systeme associe
WO2023099849A1 (fr) Procédé de diagnostic automatique d'une pièce
FR3076632A1 (fr) Procede d'analyse de messages de maintenance generes par au moins une plateforme, et systeme associe

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLFP Fee payment

Year of fee payment: 3

PLSC Publication of the preliminary search report

Effective date: 20171117

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9