INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
SYSTEME DE CHANGEMENT DE PAS AVEC CHAINE D’ENTRAINEMENT ET TURBOMACHINE EQUIPEE D’UN TEL SYSTEME DE CHANGEMENT DE PAS Domaine de l’invention La présente invention concerne le domaine aéronautique, notamment la propulsion d’aéronef. Elle vise une turbomachine comprenant des aubes à calage variable. Elle vise plus particulièrement un système de changement de pas des aubes à calage variable.
Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de détection d’anomalie dans une série temporelle observée de valeurs d’une grandeur physique représentative des performances d’un système ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de détection d’anomalie dans une série temporelle observée de valeurs d’une grandeur physique représentative des performances d’un système.
PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :
la précédemment décrite représente un exemple de série temporelle avec les anomalies constatées ;
la est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ;
la est un logigramme représentant les étapes d’un mode de réalisation préféré de l’invention ;
la illustre la détermination du résidu à partir d’un exemple de série temporelle observée ;
la représente un cas de segment de référence construit sur la base du segment courant en cours d’analyse et le segment très similaire en terme de moyenne et de variance déjà analysé dans le passé proche ;
la illustre la segmentation du résidu de l’exemple de la ;
la représente un exemple de densité de probabilité sur le segment de la .
la illustre le résultat de la mise en œuvre de l’analyse statistique sur le segment courant de l’exemple des figures 4, 6 et 7. Le segment courant de la correspond à celui de la alimenté avec plus de données permettant une détection d’anomalie robuste.
DESCRIPTION DÉTAILLÉE Architecture
La présente invention concerne un procédé de détection d’anomalie dans une série temporelle observée de valeurs d’une grandeur physique représentative des performances d’un système 2.
Le système 2 est typiquement un serveur informatique fournissant un service, par exemple un équipement réseau, un serveur bancaire mettant en œuvre des transactions, un équipement de contrôle industriel, etc. On suppose qu’on dispose d’une grandeur physique représentative des performances dudit système 2.
Ladite grandeur physique est naturellement choisie en accord avec la nature du système 2 et le service qu’il fournit, par exemple pour un équipement réseau on pourra prendre l’usage CPU (exemple de la décrite précédemment), mais également un usage mémoire, une bande-passante, un nombre d’utilisateurs connectés, un nombre de paquets passés, etc. Pour un serveur bancaire, cette grandeur peut être le nombre de transactions accomplies, le taux de transactions rejetées, etc. Pour un équipement de contrôle industriel, il peut s’agir d’une grandeur impliquée dans le processus industriel comme une température, une pression, etc.
On ne sera limité ni à un type de système ni à une grandeur physique, il importe juste que ladite grandeur physique soit représentative des performances de ce système 2, i.e. ait un sens pour l’homme du métier vis-à-vis du service fourni par le système 2.
Composés bis- benzoazolyle :
Composés méthylène bis-( hydroxyphényl benzotriazole ) :
Methylène bis-Benzotriazolyl Tetramethylbutylphénol notamment sous forme solide comme le produit vendu sous le nom commercial « MIXXIM BB/100 ®» par FAIRMOUNT CHEMICAL ou sous forme de dispersion aqueuse de particules micronisées ayant une taille moyenne des particules qui varie de 0,01 à 5μm et plus préférentiellement de 0,01 à 2 μm et plus particulièrement de 0,020 à 2 μm avec au moins un tensioactif alkylpolyglycoside de structure C n H 2n+1 O(C 6 H 10 O 5 ) x H dans laquelle n est un entier de 8 à 16 et x est le degré moyen de polymérisation de l’unité (C 6 H 10 O 5 ) et varie de 1,4 à 1,6 telle que décrite dans le brevet GB-A-2 303 549 notamment vendue sous le nom commercial « TINOSORB M® » par BASF ou sous la forme d’une dispersion aqueuse de particules micronisées ayant une taille moyenne des particules qui varie de 0,02 à 2μm et plus préférentiellement de 0,01 à 1,5 μm et plus particulièrement de 0,02 à 1 μm en présence d’au moins un mono-(C 8 -C 20 )alkyl-ester de polyglycérol ayant un dégré de polymérisation de glycérol d’au moins 5 telles que les dispersions aqueuses décrites dans la demande WO2009/063392.
[formule 49]
a) fournir un substrat 100 en un premier matériau, recouvert localement par une couche métallique 300 formant des ilots en troisième matériau,
b) déposer un plot thermoélectrique 200 en un deuxième matériau sur chaque ilot de la couche métallique 300, par fabrication additive, de préférence par SLS ou FLLP, la surface de la base des plots étant avantageusement de la même taille que la surface des ilots,
c) retirer le substrat 100, moyennant quoi on obtient une structure thermoélectrique comprenant des plots thermoélectriques 200 recouverts par une couche métallique 300.
Ce premier mode de réalisation est avantageux car il permet de métalliser simplement les plots en déposant une couche métallique 300 sur le plateau de la machine de fabrication additive.
a) fournir un substrat 100 en un premier matériau, recouvert localement par une couche métallique 300 formant des ilots en un troisième matériau,
b) déposer un plot thermoélectrique 200 en un deuxième matériau sur chaque ilot de la couche métallique 300, par fabrication additive, de préférence par SLS ou FLLP, la surface de la base des plots étant avantageusement inférieure à la surface des ilots, moyennant quoi on obtient une première structure thermoélectrique comprenant un substrat 100 recouvert localement par une couche métallique 300 formant des ilots, un plot thermoélectrique 200 étant disposé sur chaque ilot,
d) répéter les étapes a) et b) pour former une deuxième structure thermoélectrique comprenant un substrat 110 recouvert localement par une couche métallique 310 formant des ilots, chaque ilot étant recouvert par un plot thermoélectrique 210, le matériau thermoélectrique des plots thermoélectriques de la deuxième structure étant de conductivité opposée à celle du deuxième matériau de la première structure ( ),
e) assembler et connecter électriquement la première structure thermoélectrique et la deuxième structure thermoélectrique ( ).
Ce deuxième mode de réalisation est avantageux car il permet également de réaliser des modules squelettes.
Selon un troisième mode de réalisation, représenté aux figures 3A à 3E, le procédé comprend les étapes suivantes :
b) déposer un plot thermoélectrique 200 en un deuxième matériau sur chaque ilot de la couche métallique 300, par fabrication additive, de préférence par SLS ou FLLP, la surface de la base des plots étant avantageusement inférieure à la surface des ilots,
c) retirer le substrat 100, moyennant quoi on obtient une première structure thermoélectrique comprenant des plots thermoélectriques 200 recouverts par une couche métallique 300,
d) répéter les étapes a) à c) pour former une deuxième structure thermoélectrique ( ),
Dans au moins certains de ses modes de réalisation, le procédé peut aider un utilisateur à mettre en œuvre diverses applications, en les intégrant de façon simple, au moins partiellement automatique, à son propre environnement, et ceci sans multiplier les interfaces utilisateurs, les matériels etc...
On décrit à présent, en lien avec la , de façon plus détaillée la présente demande. La représente un système de télécommunication 100 dans lequel certains modes de réalisation de l’invention peuvent être mis en œuvre. Le système 100 comporte un ou plusieurs dispositifs électroniques, certains au moins pouvant communiquer entre eux via un ou plusieurs réseaux de communication, éventuellement interconnectés, comme un réseau local ou LAN (Local Area Network) et/ou un réseau de type étendu, ou WAN (Wide Area Network). Par exemple, le réseau peut comprendre un réseau LAN d’entreprise ou domestique et/ou un réseau WAN de type internet, ou cellulaire, GSM - Global System for Mobile Communications, UMTS - Universal Mobile Telecommunications System, Wi-Fi - Wireless, etc.) . Un exemple de tel réseau de communication est le bus de données 420 illustré en .
Comme illustré en , le système 100 peut également comprendre plusieurs dispositifs électroniques, comme des terminaux (tel qu’un ordinateur portable 110, un smartphone 130, une tablette 120), des objets connectés 160 ( par exemple des machines de production (comme des outillages électroniques) ou des capteurs, et/ou un serveur 140 (par exemple un serveur d’applications) et/ou un dispositif de stockage 150.
Le système peut également comprendre des éléments de gestion et/ou d’interconnexion réseau (non représentés).
La illustre une structure simplifiée d’un dispositif électronique 200 du système 100, par exemple l’un des dispositifs 110, 120, 130, 140, 150, 160 de la , adapté à mettre en œuvre le procédé de la présente demande. Comme illustré, selon les modes de réalisation, il peut s’agir d’un serveur, d’un terminal ou d’un objet connecté. Le dispositif 200 peut par exemple jouer le rôle de plateforme de gestion d’exécutables dans la présente demande. Il peut dans certains modes de réalisation est compatible avec des plateformes du commerce (comme la plateforme « Kubernetes » ©) de déploiement d’applications.
Le dispositif 200 comprend notamment au moins une mémoire M 210 comme une mémoire tampon, une mémoire volatile, par exemple de type RAM (pour « Random Access Memory » selon la terminologie anglaise), et/ou une mémoire non volatile (par exemple de type ROM (pour « Read Only Memory » selon la terminologie anglaise). Le dispositif 200 peut également comprendre une unité de traitement UT 220, équipée par exemple d'au moins un processeur P 222, et pilotée par un programme d'ordinateur PG 212 stocké en mémoire M 210. A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur P. Ledit au moins un processeur P 222 de l'unité de traitement UT 220 peut notamment mettre en œuvre, individuellement ou collectivement, l'un quelconque des modes de réalisation du procédé de la présente demande (décrit notamment en relation avec la figures 3), selon les instructions du programme d'ordinateur PG.
Le dispositif peut également comporter, ou être couplé à, au moins un module d’entrée/ sortie I/O 230, tel qu’un module de communication, permettant par exemple au dispositif 200 de communiquer avec d’autres dispositifs du système 100, via des interfaces de communication filaires ou sans fils, et/ou tel qu’un module d’interfaçage avec un utilisateur du dispositif (aussi appelé plus simplement dans cette demande « interface utilisateur »).
Par interface utilisateur du dispositif, on entend par exemple une interface intégrée au dispositif 200, ou une partie d’un dispositif tiers couplé à ce dispositif par des moyens de communication filaires ou sans fils. Par exemple, il peut s’agir d’un écran secondaire du dispositif ou d’un ensemble de hauts parleurs connectés par une technologie sans fils au dispositif.
Une interface utilisateur peut notamment être une interface utilisateur, dite «de sortie», adaptée à un rendu (ou au contrôle d’un rendu) d’un élément de sortie d‘une application informatique utilisée par le dispositif 200, par exemple une application s’exécutant au moins partiellement sur le dispositif 200 ou une application « en ligne » s’exécutant au moins partiellement à distance, par exemple sur le serveur 140 du système 100. Des exemples d’interface utilisateur de sortie du dispositif incluent un ou plusieurs écrans, notamment au moins un écran graphique (tactile par exemple), un ou plusieurs haut-parleurs, un casque connecté.
Par ailleurs, une interface utilisateur peut être une interface utilisateur, dite «d’entrée», adaptée à une acquisition d’une commande d’un utilisateur du dispositif 200. Il peut s’agir notamment d’une action à effectuer en lien avec un item rendu sur une interface de sortie du dispositif, et/ou d’une commande à transmettre à une application informatique utilisée par le dispositif 200 (par exemple un exécutable actif comme introduit ci-avant), par exemple une application s’exécutant au moins partiellement sur le dispositif 200 ou une application « en ligne » s’exécutant au moins partiellement à distance, par exemple sur le serveur 140 du système 100. Des exemples d’interface utilisateur d’entrée du dispositif 200 incluent un moyen d’acquisition audio et/ou vidéo (microphone, caméra (webcam) par exemple), un clavier, une souris.
De tels moyens d’entrées/sorties peuvent par exemple être adaptés à une gestion (création, mémorisation, sélection, lancement, paramétrage etc.) d’au moins un exécutable. Ils peuvent permettre par exemple un paramétrage des entrées/sorties d’une ressource (ou application) « passive » à déployer sous forme d’un exécutable actif (par exemple une désignation d’au moins un canal de données à utiliser pour fournir des paramètres d’entrée à la ressource via l’exécutable à déployer et/ou une désignation d’au moins un canal de données à alimenter, via l’exécutable, avec des paramètres de sortie fournis par cette ressource, une désignation d’au moins une source de données pour cet exécutable à déployer et/ou d’un destinataire de données pour cet exécutable).
Dans certains modes de réalisation, les modules d’entrées/ sorties peuvent également comprendre des moyens de communication adaptés à recevoir des données (par exemple des données acquises par un autre dispositif comme des images, des mesures etc..) et/ou de moyens d’acquisitions de ces données. Ces moyens d’acquisition peuvent comprendre des capteurs physiques ou logiciels aptes à l’acquisition de telles données. De tels modules d’entrées/sorties peuvent notamment être adaptés à consommer des données circulant sur au moins un canal 422, 424 d’un bus 420 de données et/ou à émettre des données sur au moins un canal 426 d’un bus 420 de données (voir ).
Ledit au moins un microprocesseur du dispositif 200 peut notamment être adapté pour un déploiement au moins partiellement automatique d’une première application logicielle passive dans un réseau de communication. Ledit processeur peut notamment être configuré pour: Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins une source de données dudit réseau et/ou d’au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données mises à disposition et/ou attendues dans ledit réseau; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée mise à disposition par ladite source de données sélectionnée et/ou avec en paramètre(s) de sortie au moins une donnée attendue par ledit au moins un consommateur sélectionné.
Dans certains modes de réalisation, le procédé de la présente demande peut être mis en œuvre de façon distribuée entre au moins deux dispositifs 110, 120, 130, 140, 150 ou 160 du système 100. Ainsi, dans certains modes de réalisation, un premier dispositif (par exemple un serveur 140 du système 100) peut construire un exécutable « actif » (selon le procédé de la présente demande) qu’il communique à au moins un second dispositif (par exemple un terminal 110 ou le dispositif de stockage 150 du système 100), de qui un troisième dispositif (comme le terminal 110, ou le serveur 140) pourra ultérieurement obtenir ce modèle. L’exécutable peut ensuite être lancé sur le second et/ou le troisième dispositif (par exemple le serveur 140, ou un autre serveur, ou le terminal 110) (selon le procédé de la présente demande).
Dans d’autres modes de réalisation, le procédé de la présente demande peut être mis en œuvre localement par le dispositif 200.
Une mise en œuvre distribuée du procédé peut permettre de déployer en parallèle un même exécutable sur plusieurs dispositifs (par exemple pour permettre une redondance de traitements critiques) en mettant en commun certains traitements pour l’obtention de l’exécutable « actif » à partir d’une application passive.
Ainsi, ce parcours d’un arbre des nœuds favorise une sélection des groupes de nœuds les plus proches, car les groupes de nœuds sont parcourus du plus proche vers le plus éloigné du terminal demandant le déploiement. Dès lors qu’un groupe répond au critère le plus élevé, alors il peut être sélectionné.
Dans certains modes de réalisation, lorsque ladite sélection est opérée lors de l’exécution de ladite application, elle comprend : - une sélection d’au moins un second groupe de nœuds pour le déploiement de l’application, lorsque le second groupe de nœuds est associé à une capacité correspondant à un des critères d’ordre plus élevé que le groupe de nœuds sur lequel l’application était déployée, - une suppression de l’application du au moins groupe de nœuds sur lequel elle était précédemment déployée.
Dans certains modes de réalisation, lorsque la sélection est opérée lors de l’exécution de ladite application, elle comprend - une sélection d’au moins un nouveau nœud pour le déploiement de l’application, lorsque le nouveau nœud est associé à une capacité correspondant à un des critères d’ordre plus élevé que le ou les nœuds sur lequel l’application était déployée, le au moins un nouveau nœud pouvant être un nœud du groupe de nœuds sur lequel l’application était déployée ou un nœud d’un autre groupe de nœud que le groupe de nœud sur lequel l’application était déployée, - une suppression de l’application du au moins un ou plusieurs nœuds sur lequel elle était précédemment déployée.
Dans certains modes de réalisation, où la sélection peut être faite lors du déploiement de l’application et /ou lors de l’exécution de l’application (par exemple dans ces deux cas), il est possible de sélectionner un nouveau groupe de nœuds en cours d’exécution, de manière dynamique, afin de déployer l’application sur un nouveau nœud dont les informations de capacité seraient plus adaptées au déploiement de ladite application.
Dans certains modes de réalisation, lors de l’exécution de l’application, les groupes de nœuds sont parcourus, par exemple de manière régulière ou périodique, de façon aléatoire ou lors d’évènements occasionnant une utilisation de l’application, afin de déterminer leur capacité courante. Si l’un des groupes de nœuds a changé de capacité par rapport au moment de la sélection initiale faite lors du déploiement de l’application, alors si la nouvelle capacité du groupe de nœud dont les capacités ont changé, est plus adaptée au critère d’exécution de l’application, le déploiement se fera de nouveau sur ce groupe de nœuds et l’application peut être supprimée du premier groupe de nœuds sur lequel elle était installée.
Ainsi, la sélection est faite dynamiquement lors d’un déploiement de ladite application et dynamiquement lors d’une exécution de ladite application. Plus généralement il est envisagé que la capacité des groupes de nœuds soit évaluée de manière régulière ou périodique, de façon aléatoire ou lors d’évènements occasionnant une utilisation de l’application, et dès que la capacité d’un groupe de nœuds répond mieux au besoin que le groupe de nœuds sur lequel l’application est installée, alors elle est - soit réinstallée sur ce nouveau groupe de nœuds ou -soit l’instance de l’application qui aurait été déjà installée sur ce groupe de nœuds est de nouveau utilisée et l’instance courante est désinstallée ou du moins indiquée comme non utilisée sur le groupe de nœuds ou les groupes de nœuds sur lesquels elle était utilisée.
En d’autres mots, lorsqu’il est indiqué qu’un groupe de nœuds (ou de plusieurs groupes de nœuds ensemble) satisfait mieux, de par sa capacité par exemple, à un critère qu’un autre groupe de nœuds (ou que plusieurs groupes de nœuds ensemble), l’application est déployée sur ce nouveau groupe de nœuds. Par exemple, lorsqu’un critère est relatif à un temps de latence maximal demandé par l’application, si un groupe de nœuds ne peut pas satisfaire ce temps de latence, alors il est exclu de la sélection. Un autre critère peut être une capacité mémoire nécessaire à l’exécution de l’application. Si le groupe de nœuds ne dispose pas de cette capacité mémoire alors il n’est pas non plus sélectionné.
Suite à la sélection d’un second groupe de nœuds, l’application peut être déployée sur ce nouveau groupe de nœuds et elle peut être supprimée du premier groupe de nœuds. Dans certains modes de réalisation, une instance de cette application peut aussi être conservée sur le premier groupe de nœuds mais indiquée comme non utilisée. De cette manière, si le premier groupe de nœuds redevient le groupe de nœuds dont l’information de capacité correspond le plus au critère d’exécution de l’application, cette instance pourra être utilisée sans devoir la réinstaller sur ce premier groupe de nœuds. De la même manière, l’instance installée sur le second groupe de nœuds peut être conservée en tant qu’instance non utilisée ou supprimée.
Le module de gestion 11 et le module de pilotage 12 peuvent être avantageusement des couches logicielles situées dans le terminal T1 et transparentes pour l’utilisateur du terminal T1. Ainsi, la présente divulgation peut être implémentée sous la forme d’une API (interface de programmation d’application).
Dans certains modes de réalisation, la présente invention peut être implémentée dans un environnement utilisant Kubernetes ©. Kubernetes est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Le procédé tel que décrit précédemment peut ainsi être intégré à l’API Kubernetes ou être intégré dans une API extérieure à Kubernetes qui se connecte à l’application Kubernetes pour la piloter.
Comme mentionné précédemment, chaque groupe de nœuds est en charge de répartir la charge sur les différents nœuds qui le composent grâce au répartiteur de charge et l’API est en charge de piloter les groupes de nœuds grâce au module de pilotage. Ainsi, il y a une répartition de charge à double niveaux, au niveau groupe de nœuds et au niveau nœuds.
Dans certains modes de réalisation, les critères d’exécution de l’application peuvent être décrits dans au moins un fichier descriptif, comme un fichier de type yaML ou HELM. Un tel fichier descriptif peut par exemple utiliser des labels Kubernetes dans certains modes de réalisation. On présente ci-après un exemple de fichier descriptif de type yaML définissant des labels: apiVersion: apps/v1 kind: Deployment metadata: name: mon_app labels: app: mon_app min_cpu: 2 min_ram: 2 min_latency: 10ms max_pods_parallel: 10 capabilities: usb, 5g
Dans cet exemple, les critères suivants sont listés : - capacité mémoire : 2GO de mémoire Ram au minimum, - deux processeurs minimum - temps de latence maximale : 10 ms - le nœud doit disposer d’un port USB et d’une connexion cellulaire conforme au protocole 5G. – le nombre maximal d’applications déployées sur le nœud ne doit pas être supérieur à 10.
Dans certains modes de réalisation, les capacités d’au moins un (par exemple chaque) nœud ou groupe de nœuds peuvent également être indiqués dans le fichier descriptif.