FR3025337A1 - 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
FR3025337A1
FR3025337A1 FR1557885A FR1557885A FR3025337A1 FR 3025337 A1 FR3025337 A1 FR 3025337A1 FR 1557885 A FR1557885 A FR 1557885A FR 1557885 A FR1557885 A FR 1557885A FR 3025337 A1 FR3025337 A1 FR 3025337A1
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.)
Granted
Application number
FR1557885A
Other languages
English (en)
Other versions
FR3025337B1 (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

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/04Inference or reasoning models
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B17/00Systems involving the use of models or simulators of said systems
    • G05B17/02Systems involving the use of models or simulators of said systems electric
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218Electric 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/0224Process history based detection method, e.g. whereby history implies the availability of large amounts of data
    • G05B23/024Quantitative 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
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218Electric 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/0243Electric 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/20Administration of product repair or maintenance

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (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)
  • Tourism & Hospitality (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Computational Linguistics (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (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

1 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.
3025337 2 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 5 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 10 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 15 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 20 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 25 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 3025337 3 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 5 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.
10 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 15 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) 20 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 : 25 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 ; 3025337 4 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 5 é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 10 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 15 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 20 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 25 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 : 3025337 5 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 5 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) ; 10 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 15 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 20 é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 25 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 3025337 6 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 : 5 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 10 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 15 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 20 é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 25 é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, 30 l'application de création de modèle recevant les données de 3025337 7 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 5 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 10 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 15 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 20 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).
25 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 30 commande de vol d'un aéronef ou une turbine éolienne. Ces 3025337 8 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 à 5 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 10 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) 15 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 20 é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 25 é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 30 fonctionnement de l'application de création de modèle dans lequel 3025337 9 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 5 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 10 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.
15 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 20 é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 25 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 30 d'avoir une complexité moindre que et une fonctionnalité différente 3025337 10 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 5 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é 10 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, 15 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 20 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 25 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 30 le modèle de moteur donné a été amené à fonctionner. De 3025337 11 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 5 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 10 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é.
15 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 20 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.
25 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 30 contenues dans les données de configuration de modèles reçues du 3025337 12 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, 5 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.
10 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 15 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 20 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 25 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 30 emplacement pour définir des données spécifiques des 3025337 13 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 5 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 10 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 15 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 20 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 25 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 30 configuration de modèles, le système (et le procédé correspondant) 3025337 14 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 5 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 10 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 15 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 20 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 25 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 30 configuration en présentant un compilateur sur un circuit de 3025337 15 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 5 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 10 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 15 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 20 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 25 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 30 données de configuration ainsi que de modifier des données de 3025337 16 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 5 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.
10 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 15 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 20 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) 25 é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é 30 de niveau bas et utiliser les résultats de ces algorithmes de niveau 3025337 17 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 5 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 10 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 15 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 20 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 25 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 30 modèles sont adaptées au premier équipement et au(x) modèle(s) 3025337 18 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 5 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) ; 10 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 15 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 20 é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 25 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 30 l'information selon laquelle le modèle d'inférence voulu à construire 3025337 19 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 à 5 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 10 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 15 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, 20 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 25 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) 30 physique(s) du premier équipement ; 3025337 20 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 ; 5 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 10 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 15 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 20 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 ; 25 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 30 fonctionnement qui, si elles étaient présentes dans les données 3025337 21 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 5 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 10 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 15 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 20 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 à 25 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 30 dépendra de la catégorie du premier équipement. Si le premier 3025337 22 é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 5 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 10 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 15 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 ; 20 -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 25 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 30 dont les éléments sont représentés entourés par une délimitation en 3025337 23 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 5 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 10 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 15 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 20 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 à 25 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.
3025337 24 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 5 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 10 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 15 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 20 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 25 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 30 d'aéronef), et le fonctionnement en régime de croisière à un certain 3025337 25 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 5 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 10 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.
15 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 20 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 25 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 30 de permettre à l'application de création de modèle de construire un 3025337 26 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 5 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 10 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 15 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 20 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 25 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.
3025337 27 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 5 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 10 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 15 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 20 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 25 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 : 3025337 28 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.
5 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 10 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 15 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 20 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 25 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 à 30 gaz et au(x) modèle(s) d'inférence voulu(s) par l'utilisateur U. Dans 3025337 29 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 5 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 10 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 15 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, 20 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 25 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 30 modèles mathématiques sont à même de tirer des conclusions 3025337 30 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 5 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 10 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 15 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 20 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 25 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 30 modèles 111 comprennent : 3025337 31 - 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 à 5 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 10 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 15 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 20 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 25 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 30 1115 comprend/comprennent la pression, la température et les 3025337 32 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) 5 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 10 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) 15 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 20 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 25 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 30 dans le mode apprentissage ou dans le mode exécution ; et 3025337 33 - 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 5 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 10 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.
15 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 20 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 25 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 30 utilisé dans un certain nombre d'aéronefs. Par conséquent, on peut 3025337 34 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 5 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 10 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 15 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, 20 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 25 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 à 3025337 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 5 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 10 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 15 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 20 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 25 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 30 modèle 13 utilise la série respective de modèles d'inférence 19, 29 3025337 36 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) 5 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 10 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 15 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, 20 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. REVENDICATIONS1. 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) ; 3025337 38 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 5 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 10 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 : 15 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 20 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 25 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 3025337 39 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), 5 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 10 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 15 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 20 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 25 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 30 compilées (12). 3025337 40
  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 5 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 10 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 15 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 20 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 25 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 ; 3025337 41 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 5 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 10 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 15 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 20 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 25 (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) ; 3025337 42 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) ; 5 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 10 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 15 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 20 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 25 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é 30 comportant en outre la réalisation de la base de données de 3025337 43 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 (11) et stocker les données de configuration de modèles (111) ainsi 5 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é 10 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 15 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 20 (111) 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 25 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). 3025337 44
  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 5 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 10 (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) ; 15 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) 20 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 25 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 ; 3025337 45 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 5 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 10 à 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 : 15 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 20 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 25 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) 30 afin de réaliser, pour le second équipement (200), un fichier de 3025337 46 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 5 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) 10 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 15 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 true FR3025337A1 (fr) 2016-03-04
FR3025337B1 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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040243636A1 (en) * 2003-03-18 2004-12-02 Smartsignal Corporation Equipment health monitoring architecture for fleets of assets
US7853431B2 (en) * 2006-09-29 2010-12-14 Fisher-Rosemount Systems, Inc. On-line monitoring and diagnostics of a process using multivariate statistical analysis

Family Cites Families (12)

* 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
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.
GB2496386A (en) * 2011-11-08 2013-05-15 Ge Aviat Systems Ltd Method for integrating models of a vehicle health management system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040243636A1 (en) * 2003-03-18 2004-12-02 Smartsignal Corporation Equipment health monitoring architecture for fleets of assets
US7853431B2 (en) * 2006-09-29 2010-12-14 Fisher-Rosemount Systems, Inc. On-line monitoring and diagnostics of a process using multivariate statistical analysis

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JIANGYUN LI ET AL: "Computer system for process control based on data-driven", ELECTRICAL&ELECTRONICS ENGINEERING (EEESYM), 2012 IEEE SYMPOSIUM ON, IEEE, 24 June 2012 (2012-06-24), pages 463 - 467, XP032217545, ISBN: 978-1-4673-2363-5, DOI: 10.1109/EEESYM.2012.6258693 *

Also Published As

Publication number Publication date
GB2529637A (en) 2016-03-02
GB201415079D0 (en) 2014-10-08
FR3025337B1 (fr) 2019-08-16
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
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
AU2017238862A1 (en) Computer systems and methods for creating asset-related tasks based on predictive models
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
FR2869698A1 (fr) Procede pour le controle et le diagnostic de machines
CA2746537A1 (fr) Standardisation de donnees utilisees pour la surveillance d'un moteur d'aeronef
EP3163445B1 (fr) Mécanisme d'analyse de corrélation lors de la dégradation des performances d'une chaîne applicative
FR2950177A1 (fr) Procede et dispositif de gestion d'informations dans un aeronef
EP3871078A1 (fr) Système d'environnement informatique pour la surveillance de moteurs d'aéronefs
FR3095424A1 (fr) Système et procédé de surveillance d’un moteur d’aéronef
US20210150386A1 (en) Utilizing vehicle sensors and machine learning training to target confident responses to user queries
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
WO2021069824A1 (fr) Dispositif, procédé et programme d'ordinateur de suivi de moteur d'aéronef
FR2989806A1 (fr) Procede et dispositif de mise au point d'un systeme de gestion des alertes et des procedures d'un aeronef
FR2957170A1 (fr) Outil de conception d'un systeme de surveillance d'un moteur d'aeronef
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
CA2813619C (fr) Procede et dispositif de configuration d'un systeme de gestion d'alertes pour aeronef
Prist et al. Machine learning-as-a-service for consumer electronics fault diagnosis: A comparison between Matlab and Azure ML
Bense Prognosis and health monitoring systems for aircraft engines

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