INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Les différents aspects ainsi évoqués participent à une structure générale de commande de clonage et contribuent chacun à une gestion dynamique et optimisée des ressources hébergeant des services dans l’environnement informatique en nuage. En effet, grâce au déclenchement du clonage en fonction des contraintes spécifiques de chaque service, en tenant compte des caractéristiques du service à cloner et des conditions du réseau, et en réalisant une mise à jour dynamique du routage en fonction des changements de topologie, les différents aspects évoqués offrent une capacité d'adaptation et de réactivité face aux variations de la demande et des conditions du réseau. Ainsi, lorsqu'un incident survient sur un service hébergé dans un environnement de travail initial, les aspects ainsi évoqués permettent de déclencher et de mettre en œuvre le clonage de ce service vers un nouvel environnement de travail, tout en tenant compte de contraintes relatives par exemple à la sécurité et/ou à la qualité de service. Ceci permet d'assurer une continuité de service même dans les cas, par exemple, d’une défaillance ou d’une augmentation soudaine de la demande pour le service considéré.
Il est également proposé un procédé d’orchestration de ressources dans un environnement informatique en nuage, le procédé comprenant les étapes suivantes mises en œuvre par un orchestrateur : recevoir d’un gestionnaire une instruction de clonage pour désigner une ressource au sein d’une infrastructure de communication initiale, la ressource désignée définissant un déploiement initial d’un service, recevoir du gestionnaire une contrainte associée à l’instruction de clonage, recueillir une information sur une utilisation de ressources individuelles issues d’une pluralité d’agglomérations de traitement de données, l’information étant obtenue avec une granularité suffisante pour permettre une analyse de l'utilisation de chaque ressource individuelle, et identifier, en tenant compte à la fois de l’instruction de clonage reçues, de la contrainte reçue et de l’information recueillie, une ressource cible dans au moins une nouvelle infrastructure de communication en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.
Ce procédé d'orchestration de ressources offre une méthode systématique et automatisée pour le clonage des services, qui prend en compte les contraintes de déploiement et l'utilisation des ressources en temps réel. Cela permet une meilleure gestion des ressources et une plus grande efficacité dans le déploiement des services.
Optionnellement, l’information recueillie est issue de proxys intégrés dans les agglomérations de traitement de données et associés à des ressources formant une pluralité d’infrastructures de communication candidates, et la nouvelle infrastructure de communication est choisi parmi la pluralité d’infrastructures de communication candidates.
Ceci contribue ainsi à faciliter l'identification par l'orchestrateur de cibles appropriées pour le clonage des ressources désignées et la création du nouvel environnement de travail pour le nouveau déploiement du service. Cela contribue à une répartition optimale des ressources, améliorant ainsi l'efficacité et la performance du système.
Il est également proposé un procédé de gestion de service dans un environnement informatique en nuage, le procédé comprenant les étapes suivantes mises en œuvre par un gestionnaire : détecter un événement déclencheur résultant d’une application d’une stratégie de gestion du service, définir une contrainte associée à l’événement déclencheur, envoyer, suite à la détection de l’événement déclencheur, une instruction de clonage à un orchestrateur, l’instruction de clonage permettant à l’orchestrateur de désigner une ressource dans une infrastructure de communication initiale, définissant un déploiement initial du service, et envoyer la contrainte définie à l’orchestrateur, la contrainte permettant à l’orchestrateur d’identifier, dans au moins une nouvelle infrastructure de communication, une ressource cible en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.
Ce procédé de gestion de service offre une méthode proactive pour le clonage et le déploiement de services basée sur la détection d'événements spécifiques. Cela permet une réaction rapide et adaptée aux changements dans l'environnement de travail, améliorant la résilience et la disponibilité des services.
Optionnellement, le procédé comprend en outre l’étape suivante mise en œuvre par le gestionnaire : recueillir une information fournie par l’orchestrateur sur une utilisation d’un ensemble de ressources incluant, au moins, la ressource définissant le déploiement initial du service, et dans lequel la détection de l’événement déclencheur est basée sur l’information obtenue.
La collecte en temps réel d'informations sur l'utilisation des ressources par le gestionnaire permet une détection précise des événements déclencheurs. Cela augmente la précision de la gestion des services et la réactivité face aux changements.
Optionnellement, la détection de l’événement déclencheur est relative à une application d’une politique incluant au moins un critère d’optimisation choisi parmi le partage de charge, la résilience, la sécurité, la disponibilité, le coût, l’énergie et/ou l’impact environnemental.
La capacité de détecter un événement déclencheur basé sur une variété de politiques, en particulier sur celles mentionnées ici, offre une flexibilité et une adaptabilité accrues dans la gestion des services.
Optionnellement, les procédés précités comprennent en outre l’étape suivante mise en œuvre par l’orchestrateur ou le gestionnaire : transmettre une information concernant une modification de topologie suite au clonage à un service virtuel configuré comme un dispositif de routage, l’information transmise permettant au service virtuel de rediriger, à l'issue du clonage, un trafic du déploiement initial du service vers le nouveau déploiement du service, de manière transparente pour l'orchestrateur et le gestionnaire.
Dans l’exemple de réalisation des figures 1 à 3, le rotor 201 s’étend autour du stator 200. Dans une variante représentée à la , le stator 200 peut s’étendre autour du rotor 201.
Le moteur comporte en outre une pièce d’interface 203. La pièce d’interface 203 est configurée pour être fixée au bâti du contacteur 1. La pièce d’interface 203 est ici fixée à une extrémité 204 du stator 200.
Le moteur 2 est par exemple du type à aimants permanent à débattement limité. Le moteur à débattement limité comprend un seul enroulement bobinage. L’alimentation de l’enroulement en courant continu, dans le sens positif, permet de faire tourner le moteur dans un sens de rotation donné. L’alimentation de l’enroulement en courant continu, dans le sens négatif, permet de faire tourner le moteur dans le sens contraire.
L’utilisation d’un moteur à aimants est également avantageuse en ce que le moteur est intrinsèquement équilibré. Le moteur est d’autant plus équilibré lorsque les aimants sont identiquement décalés les uns des autres.
Dans une variante, le moteur comporte deux bobinages en opposition de phase. L’alimentation d’un premier desdits bobinages par un courant continu positif permet par exemple la rotation dans un premier sens, et l’alimentation d’un deuxième desdits bobinages par un courant continu positif permet la rotation du moteur dans un deuxième sens contraire au premier sens.
Dans un exemple de réalisation, l’un ou les deux bobinages du moteur sont connectés en série avec une diode d’anti-inversion de polarité. Cela permet d’éviter les erreurs de branchement ou d’ordre de commande.
Le système balais-collecteur 3 constitue la partie contact électrique du contacteur.
Le système collecteur-balais 3 comporte un collecteur 300 et un dispositif à balais 301.
Le collecteur 300 présente une forme cylindrique. En particulier, le collecteur 300 présente ici une forme annulaire.
Le collecteur 300 comprend au moins une portion conductrice 302 et au moins une portion non conductrice 303.
Dans l’exemple illustré aux figures 1 à 3, le collecteur comprend plusieurs portions conductrices 302 et portions non conductrices 303. Le collecteur 300 comprend une alternance de portions conductrices 302 et de portions non conductrices 303. Autrement dit, toute portion conductrice 302 est circonférentiellement adjacente à une portion non conductrice 303. Les portions conductrices 302 sont hachurées sur les figures 1 à 3 et 6.
Dans l’exemple illustré et comme bien visible sur la , les portions conductrices 302 sont insérées dans un support isolant. Les parties du support isolant s’étendant entre les portions conductrices 302 forment les portions non conductrices 303. Alternativement, les portions conductrices 302 et les portions non conductrices 303 peuvent être complètement disjointes.
Les portions conductrices 302 et les portions non conductrices 303 forment le pourtour du collecteur 300. Autrement dit, des faces des portions conductrices 302 et des portions non conductrices 303 forment une surface latérale du collecteur 300.
Les portions conductrices 302 et les portions non conductrices 303 présentent ici la même forme. Les portions conductrices 302 et les portions non conductrices 303 sont ici des lames. Les portions conductrices 302 et les portions non conductrices 303 présentent une forme rectangulaire. Les portions conductrices 302 sont ici plus étroites que les portions non conductrices 303.
L’utilisation de portions conductrices et portions non conductrices identiques, par exemple des lames, permet un équilibrage du collecteur.
Dans d’autres exemples de réalisation, les portions conductrices 302 et les portions non conductrices 303 peuvent présenter une forme et/ou des dimensions différentes. Par exemple, les portions conductrices 302 et les portions non conductrices 303 peuvent être des lames rectangulaires de même largeur.
39d: région droite de la butée de lèvre
39d’: extrémité libre de la région droite de la butée de lèvre
39g : région gauche de la butée de lèvre
39g’: extrémité libre de la région gauche de la butée de lèvre
40, 40’ : saillies de guidage
42 : fenêtres de supports labiaux, de manière générique
46 : embase
48 1 : premier mors
48 2 : deuxième mors
50d : zone de glissement de la commissure labiale droite
Oo : ouverture orale
Oa : ouverture d'acquisition
X : axe longitudinal de l’espaceur
B OO : Bord de l’ouverture orale
P OO : Plan général de l’ouverture orale
F : exemple de force de poussée centripète appliquée sur la partie tubulaire
Notamment, le verrou 38 comprend une patte 42 qui présente une forme allongée qui s’étend selon un axe transversal T horizontal, perpendiculaire à l’axe longitudinal L.
Le verrou 38 est articulé de manière élastique par rapport à la base 36, via une charnière élastique 44 à effet ressort, autour d’un axe de charnière C parallèle à l’axe longitudinal L.
La charnière élastique 44 est ici formée par une portion amincie 46 qui s’étend entre la base 36 et le verrou 38 et de telle sorte à conférer des propriétés de rappel élastique audit verrou38.
Le verrou 38 est mobile en rotation par rapport à la base 36, via la charnière élastique 44, entre une position de repos verrouillée illustrée à la , et une position sous contrainte déverrouillée illustrée à la .
On comprend que la position de repos du verrou 38 correspond à une position dans laquelle la charnière élastique 44 n’est pas mise sous contrainte et subsiste dans son état neutre.
Ainsi, dans la position verrouillée, la patte 42 du verrou 38 est positionnée parallèlement au plan principal P horizontal de la base 36 tel que visible à la .
Dans cette position, l’organe de butée 40 du verrou 44 est adossé contre le deuxième organe d’accrochage 28, de sorte à former un bloc 48 comprenant une première face 50 formée sur le deuxième organe d’accrochage 28, et une deuxième face 52 formée sur l’organe de butée 40, les faces 50, 52 étant opposées l’une de l’autre selon l’axe longitudinal L ( ).
Tel que visible à la , la première face 50 est destinée à être en appui contre le premier bord 20a du deuxième alésage 20 et la deuxième face 52 est destinée à être en appui contre le deuxième bord 20b du deuxième alésage 20 dans une position de blocage du dispositif 10 sur l’élément de support 14.
La coopération entre le bloc 48 et le deuxième alésage 20 sera détaillée plus loin dans la description.
Dans la position déverrouillée du verrou 38, l’organe de butée 40 est décalé par rapport au deuxième élément d’accrochage 28 selon l’axe vertical V du dispositif 10 tel que visible à la .
Tel que visible aux figures 3 à 6, l’organe de butée 40 comprend une face de contact 54 qui s’étend selon l’axe vertical V entre la deuxième face 52 et un bord d’attaque 56 de l’organe de butée 40.
De manière plus précise, on définit le bord d’attaque 56 de l’organe de butée 40 comme un bord d’extrémité de l’organe de butée 40, opposé à la base 36 de la platine de fixation 22.
Selon l’exemple illustré et visible à la , dans la position verrouillée du verrou 38, le bord d’attaque 56 de l’organe de butée 40 s’étend dans un premier plan incliné I1 par rapport au plan principal P de la base 36.
Plus particulièrement, le bord d’attaque 56 s’étend de telle sorte que l’inclinaison évolue de façon croissante en s’éloignant de l’axe de charnière.
On définit ainsi une dimension verticale DV de l’organe de butée 40 prise le long de l’axe vertical V du dispositif 10, la dimension verticale DV étant croissante en s’éloignant de l’axe de charnière de la droite vers la gauche en considérant la .
L’avantage d’une telle configuration de l’organe de butée 40 sera détaillé plus loin dans la suite de la description, notamment lors de la description du procédé de montage.
L’orchestrateur, dans l’environnement informatique en nuage, est conçu pour recevoir du gestionnaire une ou plusieurs instructions de clonage, éventuellement sérialisées. L’interprétation de cette ou de ces instructions par l’orchestrateur lui permet de désigner une ou plusieurs ressources définissant un déploiement initial d'un service au sein d'une infrastructure de communication initiale (ou environnement de travail initial). En outre, l'orchestrateur reçoit du gestionnaire une contrainte associée à cette ou ces instructions de clonage.
L'orchestrateur est également capable de recueillir une ou plusieurs informations sur l'utilisation de ressources individuelles issues de diverses agglomérations de traitement de données. Cette ou ces informations sont obtenues avec une granularité suffisante pour permettre une analyse détaillée de l'utilisation de chaque ressource individuelle.
La collecte d’informations sur l'utilisation des ressources dans l'infrastructure de communication peut se faire de diverses manières, dépendamment de la spécificité du contexte. Elle peut être effectuée en temps réel, ce qui signifie que l'information est collectée et analysée au fur et à mesure qu'elle est générée. Cette méthode permet une réaction rapide à des changements dans l'utilisation des ressources et peut être utile pour la gestion des ressources en temps réel. Alternativement, une approche dynamique de la collecte d'informations peut être adoptée. Dans ce contexte, la dynamique se réfère à la capacité de s'adapter à des changements dans le système de clonage ou l'infrastructure de communication, en modifiant la fréquence ou le type d'informations collectées en fonction des circonstances. Par exemple, l'orchestrateur peut être configuré pour collecter plus fréquemment des informations lorsqu'une augmentation de l'utilisation des ressources est détectée, ou pour collecter des types d'informations spécifiques en réponse à certains événements ou conditions. Enfin, la collecte d'informations peut aussi se faire en réponse à une notification. Dans ce cas, l'orchestrateur est configuré pour collecter des informations lorsque certaines conditions sont remplies, ou lorsque certaines notifications sont reçues. Par exemple, une notification peut être émise lorsque l'utilisation d'une ressource atteint un certain seuil, déclenchant la collecte d'informations par l'orchestrateur. Ces méthodes de collecte d'informations ne sont pas mutuellement exclusives et peuvent être utilisées conjointement.
En tenant compte de la ou des instructions de clonage, de la contrainte reçue, et de la ou des informations recueillies, l'orchestrateur peut alors identifier une ou plusieurs ressources cibles dans au moins une nouvelle infrastructure de communication. Cela permet un clonage de la ou des ressources désignées, facilitant ainsi un nouveau déploiement du service qui respecte la contrainte spécifiée.
Le gestionnaire joue un rôle clé dans le déclenchement du processus de clonage. Il est capable de détecter un événement déclencheur résultant de l'application d'une stratégie de gestion du service. Une telle stratégie de gestion peut viser à optimiser ou co-optimiser différents critères tels que le partage de charge, la résilience, la sécurité, la gestion du coût, de l'énergie, de l’impact environnemental, etc. Suite à la détection de cet événement, le gestionnaire définit une contrainte associée à l'événement et envoie des instructions de clonage à l'orchestrateur.
Ces instructions permettent à l'orchestrateur de désigner des ressources dans l'environnement de travail initial, définissant ainsi un déploiement initial du service. Le gestionnaire envoie également la contrainte définie à l'orchestrateur, ce qui permet à ce dernier d'identifier, dans au moins un nouvel environnement de travail, des ressources cibles pour le clonage.
Le système de clonage peut comprendre également un service virtuel configuré comme un dispositif de routage. A l'issue d'une opération de clonage, ce service redirige le trafic d'un déploiement initial d'un service vers un nouveau déploiement du service, de manière transparente pour l'orchestrateur et le gestionnaire. Cela permet une transition fluide et efficace entre le déploiement initial et le nouveau déploiement, contribuant ainsi à la continuité du service.
En résumé, le système de clonage proposé offre une solution efficace pour répliquer les configurations nécessaires aux services et applications déployés dans un environnement informatique en nuage distribué. Il permet une gestion fine et coordonnée des ressources, une réponse agile à des événements déclencheurs et une transition transparente vers de nouveaux déploiements de services et d'applications. Il répond aux défis de répartition des ressources, de reconfiguration et de redondance.
Dans la gestion des ressources cloud, la répartition des services, des applications et des données sur différents environnements informatiques est un défi majeur, en particulier lorsque ces ressources proviennent de différents fournisseurs. Jusqu'à présent, l'absence d'un système de clonage adapté compliquait les opérations de distribution des ressources, de reconfiguration et de redondance. Le système de clonage proposé résout ce problème technique en offrant une solution efficace pour configurer les services et applications déployés dans un environnement distribué.
En plus de faciliter la réplication des configurations, le système de clonage répond également à d'autres besoins importants. Il offre un accès simplifié et sécurisé aux fonctions et micro-services, permettant ainsi la réplication de la logique d'accès aux données et la gestion de la sécurité associée. Cela se révèle extrêmement bénéfique pour les opérateurs et les entreprises cherchant à améliorer l'efficacité et la sécurité de leurs applications et services dans des environnements de conteneurs et de micro-services.
Le système de clonage peut être appliqué dans une grande variété d'environnements, notamment la gestion de systèmes informatiques distribués, le déploiement de réseaux d'accès radio dans les systèmes de télécommunications, et le déploiement de configurations distribuées sur plusieurs sites, avec des acteurs et des zones multiples, et éventuellement des réplicas répartis sur plusieurs centres de données, de telles configurations étant susceptibles de supporter des ensembles fonctionnels variés.
Peu importe l'environnement de travail spécifique d’un service donné à cloner – qu'il s'agisse d'un nœud unique, d'un ensemble de serveurs, d'une zone géographique spécifique ou d'un sous-réseau IP – le système de clonage est conçu pour s'adapter à ces différents contextes.
Avant d'aller plus loin dans la description de l'invention, il est important de clarifier quelques termes spécifiques aux environnements informatiques en nuage.
Dans ces environnements, l'unité d'hébergement de base est souvent appelée un « conteneur ». Ces conteneurs sont des unités logicielles légères qui encapsulent le code et toutes ses dépendances, permettant ainsi à une application de s’exécuter de manière fiable d'un environnement informatique à un autre.
Pour la gestion de ces conteneurs, une solution appelée Kubernetes, K8S, est fréquemment employée. Kubernetes est un système qui facilite le déploiement, la mise à l'échelle et la gestion des applications conteneurisées.
Dans l'architecture de Kubernetes, les conteneurs sont regroupés en « pods », qui constituent l’unité de base représentant un déploiement d'une application. Plusieurs pods peuvent être regroupés en un « Node » ou « nœud », qui symbolise un serveur. Ces nœuds sont ensuite regroupés en « clusters », soit des ensembles de serveurs qui travaillent ensemble et peuvent être perçus comme un système unique.
Le compteur 1 comprend de plus un module de communication 15 qui est susceptible de mettre en œuvre tout type de communication, et par exemple une communication via un réseau cellulaire de type 2G, 3G, 4G, Cat-M ou NB-IOT, une communication selon le protocole LoRa, selon le protocole W-Mbus, une communication radio selon le standard Wize opérant à la fréquence de 169MHz, etc.
On décrit maintenant le principe de l’invention.
Si la vanne 12 est ouverte et que le compteur 1 mesure un débit non nul, pendant une durée relativement importante, de plusieurs heures typiquement, il existe trois possibilités : soit il y a une véritable fuite en aval du compteur 1, qui se produit donc soit dans l’installation 2 de l’abonné, soit à l'interface entre l’aval du compteur 1 et l’installation 2 (dans le cas par exemple où le compteur 1 est mal connecté) ; soit le dispositif de mesure 6 a un problème d’offset (offset mal calibré ou dérive de l’offset en fonction du temps et/ou de la température) ; soit la vanne 12 présente un défaut de fonctionnement.
Le procédé de surveillance comporte tout d’abord une phase préliminaire au cours de laquelle l’unité de traitement 5 acquiert des premières mesures de débit.
Si, au cours de la phase préliminaire, le débit demeure non nul et inférieur à un premier seuil prédéterminé pendant au moins une durée prédéterminée, l’unité de traitement 5 démarre une phase de détection.
Le premier seuil prédéterminé est par exemple égal à 3 L/h ou 5 L/h. La durée prédéterminée est par exemple égale à 1 h ou 2 h.
Lors de la phase de détection, l’unité de traitement 5 vérifie tout d’abord que la vanne 12 est bien ouverte.
Si la vanne 12 est fermée, l’unité de traitement 5 détecte un problème d’offset dans le dispositif de mesure 6. En effet, le débit mesuré aurait dû être nul (car le débit réel est bien nul, la vanne 12 étant fermée).
Si la vanne 12 est bien ouverte, l’unité de traitement 5 ferme la vanne 12.
L’unité de traitement 5 acquiert au moins une deuxième mesure de débit, en l’occurrence ici plusieurs deuxièmes mesures de débit.
L’unité de traitement 5 détecte alors une fuite d’eau si le débit est nul. En fermant la vanne 12, on a en effet généré un débit réellement nul. Si le dispositif de mesure 6 mesure correctement ce débit nul, cela signifie qu’il n’y a pas de problème d’offset ni de problème sur la vanne 12.
Par contre, suite à l’acquisition de la au moins une deuxième mesure de débit, si le débit n’est pas nul, l’unité de traitement 5 : vérifie au moins une première condition, comprenant une première condition primaire, qui est que le débit est constant ; si la au moins une première condition est vérifiée, détecte un problème d’offset dans le dispositif de mesure 6.