INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Lorsque les céramiques et les électrodes sont empilées, les perçages axiaux délimitent un alésage central coaxial à l'axe du pilier 4’. Cet alésage central permet le passage d'une tige qui assure le centrage, l'alignement et participe au maintien des céramiques et des électrodes. Des moyens de fixation sont disposés aux extrémités de la tige. Ces moyens de fixation se présentent par exemple sous la forme de pièces rigides fixées aux extrémités de la tige de manière à venir enserrer l'empilement des céramiques et des électrodes. La pièce se présente par exemple sous la forme d'un écrou vissé à l'extrémité filetée de la tige. La pièce peut également être un écrou, ou une pièce taraudée, fixée à un châssis, et dans laquelle se visse l'autre extrémité filetée de la tige.
Pour des raisons de sécurité, l'empilement des céramiques et des électrodes est avantageusement isolé électriquement. Pour ce faire, la tige peut être placée dans un fourreau ou gaine fabriquée dans un matériau isolant électrique tel qu'un plastique. On peut également prévoir de loger l'empilement dans un fourreau ou dans une gaine extérieure également fabriquée dans un matériau isolant électrique.
- l'on pilote le fonctionnement dudit circulateur (211) dès lors qu'une sonde de mesure de ladite température ambiante Tamb est défectueuse ou que ladite température ambiante Tamb est inférieure à 5°C.
Grâce à ce procédé, on fait usage de la quantité d'énergie juste nécessaire au refroidissement du lait, tandis que les calories dégagées au niveau du condenseur sont utilisées au mieux pour le chauffage de l'eau.
L'invention concerne également un programme d'ordinateur comportant des instructions de code pour la mise en œuvre du procédé selon l’une des caractéristiques ci-dessus, lorsqu’il est exécuté sur un calculateur tel qu’un automate programmable ou un ordinateur.
Elle concerne aussi une mémoire d’ordinateur dans laquelle est stocké un programme d’ordinateur, ledit programme comportant des instructions de code qui permettent à une machine de mettre en œuvre les étapes du procédé selon l’une des caractéristiques précédentes, quand ce programme est exécuté par ladite machine.
DESCRIPTION DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront de la description qui va maintenant en être faite, en référence au dessin annexé, qui en représente, à titre indicatif mais non limitatif, un mode de réalisation possibles.
est une vue très schématique d'une installation au sein de laquelle le procédé selon l'invention est susceptible d'être mis en œuvre.
DESCRIPTION DETAILLEE DE L'INVENTION Le procédé selon l'invention sera décrit en référence à la annexée qui représente à titre non limitatif un exemple d'installation au sein duquel le procédé est susceptible d'être mis en œuvre.
Il s’agit d’une représentation purement illustrative.
Dans le cadre de cet exemple, on suppose que cette installation est en place dans une ferme et est prévue pour refroidir le lait issu de la traite de vaches.
Ainsi, l'installation I de la comporte un réservoir RS de stockage et de refroidissement de lait (tank à lait) pourvu d'un équipement 1 de refroidissement du lait.
Elle comporte aussi un ballon 3 de stockage d'eau, que l'on peut également désigner sous l'appellation "ballon de récupération d'énergie".
L'installation comporte également un chauffe-eau 4 en communication de fluide avec le ballon BR.
Enfin, elle également pourvue d'une boucle BR de récupération de chaleur sur laquelle on reviendra en détail plus loin dans la description.
Le réservoir RS de stockage et de refroidissement 1 a une capacité qui peut aller de quelques centaines à plusieurs dizaines de milliers de litres, en fonction du nombre d’animaux dont le lait est collecté.
Pour faciliter la lecture de la , il n'a pas été représenté en détail.
La sonde réseau P3 1001 calcule en outre une éventuelle perte de volume de données (de paquets, d’octets…) sur l’intervalle de numéros de séquence réellement considéré (à cause des pertes éventuelles de paquets fanions). La perte de volume de données correspond à la différence entre la volumétrie calculée par la sonde réseau P3 1001 vis-à-vis de son propre historique d’échantillonnages, sur l’intervalle de numéros de séquence réellement considéré, et la volumétrie calculée par la sonde réseau P3 1001 vis-à-vis de l’historique d’échantillonnages reçu dans la réponse MeasResp.
Lorsque les numéros de séquence constituant les bornes de l’intervalle de numéros de séquence de l’historique retourné dans la réponse MeasResp sont les mêmes, une perte totale des paquets fanions entre deux mesures successives est survenue. Dans ce cas, les valeurs de latence et gigue ne sont pas calculées par la sonde réseau P3 1001. La sonde réseau P3 1001 calcule alors une valeur approximée de la perte de volume de données, comme déjà expliqué ci-dessus en relation avec la . Ainsi, en considérant deux réponses MeasResp successives, la sonde réseau P3 1001 peut estimer la perte de volume de données en déterminant la différence d’informations de « volumétrie actuelle » telles qu’indiquées dans lesdites deux réponses MeasResp successives, et en la comparant avec la différence d’informations de « volumétrie actuelle » telles que mémorisées à l’envoi des requêtes MeasReq correspondantes.
Dans une étape 1017, la sonde réseau P3 1001 mémorise des informations permettant de savoir où en est la surveillance du tunnel de communication vis-à-vis des historiques d’échantillonnages, pour le ou les types de service (e.g., DSCP) considérés. Typiquement, la sonde réseau P3 1001 mémorise le numéro de séquence Seq du dernier paquet fanion reçu et la volumétrie actuelle, tels que fournis par la sonde réseau P4 1002 dans la réponse MeasResp.
Dans une étape 1018, grâce aux calculs de latence, de gigue et d’éventuelle perte de volume de données à l’étape 1016, la sonde réseau P3 1001 évalue si une éventuelle situation de congestion est rencontrée par le tunnel de communication, que ce soit en termes de latence, de gigue, ou de pertes de paquet lors du transit dans le tunnel de communication. Grâce à cette évaluation de situation de congestion, la sonde réseau P3 1001 peut instruire le routeur local pour modifier des profils de transmission de données dans le ou les réseaux de communication 100a de sorte à prendre en compte, préférentiellement améliorer (e.g., gestion d’admission de services), les situations de congestion qui seraient révélées. En variante, la sonde réseau P3 1001 remonte à l’orchestrateur 180 des informations relatives aux calculs, de sorte à permettre à l’orchestrateur 180 d’ajuster la gestion d’admission de services.
Il convient de noter que l’algorithme de la peut être inversé, c’est-à-dire que la sonde aval obtient l’historique d’échantillonnages de la sonde amont et effectue l’ensemble des calculs.
Dans un mode de réalisation particulier applicable aux algorithmes des Figs. 9 et 10, la sonde réseau P3 1001 calcule une information supplémentaire de latence et une information supplémentaire de gigue, qui sont liées à la qualité de service QoS (« Quality of Service » en anglais) du routeur local lui-même, en comparant les informations d’horodatage contenues dans les paquets fanions émis et les informations d’horodatage de capture des paquets fanions capturés par ladite sonde réseau P3 1001. La latence dans le tunnel de communication est alors ajustée en retranchant la latence induite par le routeur au calcul de latence effectué sur la base des échantillons reçus de la sonde réseau P4 1002. De même, la gigue dans le tunnel de communication est alors ajustée en retranchant la gigue induite par le routeur au calcul de gigue effectué sur la base des échantillons reçus de la sonde réseau P4 1002. Selon un mode de réalisation complémentaire, la sonde réseau P3 1001 estime en outre une éventuelle perte de volume de données liée au routeur local lui-même. Etant donné que la sonde réseau P3 1001 ne connaît pas le volume de données effectivement issu du réseau de communication 100b en amont du point de terminaison 120 100b, la sonde réseau P3 1001 effectue une estimation d’éventuelle perte de volume des données issues du réseau de communication 100b en se basant sur les éventuelles pertes subies par ses propres paquets fanions (i.e., ceux injectés par l’injecteur 150 local et qui doivent être normalement détectés par le point de capture local de la sonde réseau amont).
Dans un mode de réalisation particulier applicable aux algorithmes des Figs. 9 et 10, lorsque les tunnels de communication sont implémentés grâce au protocole GRE ou au protocole mGRE, les paquets fanions peuvent être injectés et capturés par type de service (e.g., DSCP) et en outre par flux (e.g., flux IP LAN). Les informations de flux par paquet fanion sont alors prises en compte par les sondes réseau et les calculs de volumétrie et d’éventuelle perte de volume de données sont réalisés par flux et par type de service, au lieu d’être réalisés par type de service uniquement.
Un mode de réalisation particulier hybride par rapport aux algorithmes des Figs. 9 et 10 peut aussi être implémenté. Le calcul de volumétrie est alors réalisé par la sonde réseau aval, et les calculs de latence et de gigue sont réalisés par la sonde réseau amont. Pour ce faire, la réponse MeasResp est de type MeasResp3. La réponse MeasResp inclut alors les informations de numéro de séquence Seq et d’horodatages, mais pas les informations de volume de données. En relation avec la , les données contenues dans les colonnes 805 et 806 sont omises. La réponse MeasResp inclut aussi le résultat de calcul de volumétrie effectué par la sonde réseau aval. La réponse MeasResp peut toutefois aussi inclure la volumétrie actuelle (c’est-à-dire, au moment où la requête MeasReq est reçue) du dernier paquet fanion reçu et le numéro de séquence Seq dudit dernier paquet fanion reçu. Cela permet de trouver un compromis de consommation de bande passante par le protocole inter-sondes, tout en conservant la justesse des résultats de calculs de latence et de gigue.
Système de dissémination de contenus dans une fédération de réseaux ; Procédé de dissémination et produit programme d’ordinateur associés La présente invention concerne la dissémination de contenus dans une fédération de réseaux.
Pour des usages civils, on connaît le concept de réseau de diffusion de contenu, ou réseau CDN (« Content Delivery Network » en anglais). Il s’agit d’un ensemble de serveurs d’un réseau d’infrastructure, comportant un serveur d’origine et un ensemble de serveurs miroirs, qui sont implantés à des endroits différents du réseau d’infrastructure. Une copie du contenu déposé sur le serveur d’origine est transmise vers un ou plusieurs serveur(s) miroir(s) de manière à être stockée au plus proche des utilisateurs effectifs de ce contenu. Ceci a pour but de limiter les flux sur le réseau d’infrastructure et de réduire la latence entre la demande d’un contenu par un utilisateur et sa réception par cet utilisateur.
Une requête d’accès au contenu, émise par un utilisateur, doit être redirigée vers le serveur miroir sur lequel ce contenu est effectivement recopié. Cette redirection s’appuie sur le mécanisme de routage des requêtes (« Request-Routing ») mis en œuvre par un serveur de nom de domaine - DNS (« Domain Name System ») dédié au réseau CDN. La requête d’accès est transmise au serveur DNS, qui renvoie l’adresse IP du serveur miroir où est stocké le contenu objet de la requête d’accès.
- le module NN met en œuvre un algorithme du type réseau de neurones artificiels, de préférence un perceptron multicouche, de préférence encore du type totalement connecté.
- le module NN est capable d’associer un score à chaque scénario d’une pluralité de scénarios prédéfinis, et de produire une liste de scénarios, la liste de scénarios comportant N scénarios présentant les meilleurs scores pour la situation opérationnelle courante.
- l’unité de moteur d’inférence utilise des données fournies par un système de support opérationnel – OSS et/ou par un système de support fonctionnel – BSS, pour instancier les valeurs des paramètres d’un scénario et obtenir le fichier de configuration associé.
- l’orchestrateur de services comporte, en outre, une interface homme / machine permettant à un opérateur de choisir de transmettre un fichier de configuration préparé par l’unité de moteur d’inférence, au serveur d’API pour réaliser un déploiement dans le réseau de communication.
L’invention a également pour objet un système d’orchestration comportant une pluralité de contrôleurs et un orchestrateur de services supervisant la pluralité de contrôleurs, la pluralité de contrôleurs comportant au moins un contrôleur de réseau un contrôleur de système d’information et un contrôleur de sécurité, l’orchestrateur de services étant conforme à l’orchestrateur précédent.
L’invention a également pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un orchestrateur de services, fournissent les unités d’acquisition de données, de réseaux de neurones et de moteur d’inférence, de sorte que l’orchestrateur de services soit conforme à l’orchestrateur précédent.
L’invention a également pour objet un produit programme d’ordinateur permettant de programmer convenablement un système d’orchestration pour qu’il soit conforme au système d’orchestration précédent.
La est une représentation schématique d’un exemple d’infrastructure intégrant un système d’orchestration de services selon l’invention ; et,
La est une représentation sous forme de blocs fonctionnels d’un mode de réalisation du système d’orchestration de la .
Infrastructure En se référant à la , l’infrastructure 1 comporte un premier réseau 100 et un second réseau 200, destinés à être fédérés au travers un réseau sous-jacent 20. Le réseau 20 est un réseau étendu – WAN (« Wide area network » en anglais).
Le premier réseau 100 comporte par exemple :
- un premier réseau radio 110, intégrant notamment une pluralité de points d’accès ou eNB (« e-Node B » en 4G) 112. Sur la deux eNB sont représentés et référencés 112a et 112b. Un eNB permet à un équipement utilisateur - UE, tel que l’UE 2, de se connecter, au moyen d’une liaison radio, au premier réseau 100. Le premier réseau radio est de préférence un réseau de bordure embarqué par exemple dans un premier véhicule blindé, les utilisateurs de ce réseau étant des fantassins évoluant sur une première zone du théâtre d’opération.
- un second réseau radio 140, intégrant notamment une pluralité de points d’accès ou eNB (« e-Node B » en 4G) 142. Sur la deux eNB sont représentés et référencés 142a et 142b. Un eNB permet à un UE, tel que l’UE 3, de se connecter, au moyen d’une liaison radio, au premier réseau 100. Le second réseau radio est de préférence un réseau de bordure embarqué par exemple dans un second véhicule blindé, les utilisateurs de ce réseau étant des fantassins évoluant sur une seconde zone du théâtre d’opération.
- un réseau d’accueil 102.
Le réseau d’accueil comporte :
Plus précisément, l’adresse de la sonde réseau est déterminée en appliquant une fonction de translation bijective par rapport à l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée.
Dans un mode de réalisation particulier, l’adresse de ladite sonde réseau est obtenue en appliquant une règle de conversion (« mapping » en anglais) prédéfinie à partir de l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée.
Dans un mode de réalisation particulier, l’adresse de ladite sonde réseau est obtenue en appliquant un décalage (« offset » en anglais) prédéfini (positif ou négatif) par rapport à l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée.
Dans un mode de réalisation particulier, l’adresse de ladite sonde réseau est obtenue en ajoutant un ( i.e. , une unité) à l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée.
Le même mécanisme s’applique pour la définition des adresses des autres sondes réseau du système de communication. Ainsi, l’adresse d’une sonde réseau distante (i.e., de l’autre côté d’un tunnel de communication supervisé) est déterminée en appliquant la fonction de translation bijective par rapport à l’adresse du point de terminaison 120 auquel ladite sonde réseau distante est associée.
En variante de réalisation, les sondes réseau ont des adresses indépendantes des adresses des points de terminaison 120 de tunnel de communication. Eventuellement, les injecteurs 150 ont des adresses qui leur sont propres. A la découverte d’un tunnel de communication, la sonde réseau en question notifie son plan d’adressage à la sonde réseau distante. Pour ce faire, un message est envoyé sur un port dédié (par exemple, un port UDP dédié) aux messages inter-sondes, avec un identifiant de message dédié. Le message en question indique quels points de terminaison 120 sont concernés par le tunnel de communication découvert. La sonde distante étant configurée pour recevoir (écouter) les messages reçus sur ce port dédié, cette sonde distante peut reconnaître le tunnel de communication (le point de terminaison 120) qui la concerne, et le plan d’adressage utilisé de l’autre côté du tunnel de communication lui devient connu. Cette sonde distante peut à son tour transmettre son propre plan d’adressage de la même manière. Dans un mode de réalisation particulier, les paquets fanions incluent une information indiquant quels points de terminaison 120 sont concernés par le tunnel de communication auquel sont associés lesdits paquets fanions, ainsi que le plan d’adressage évoqué ci-dessus.
Les messages échangés dans le cadre du protocole inter-sondes sont préférentiellement d’un type de trafic de plus haute priorité. Par exemple, les messages échangés dans le cadre du protocole inter-sondes ont une valeur de champ DSCP plus prioritaire que les paquets qui sont encapsulés dans les tunnels de communication supervisés (i.e., plus prioritaire que les paquets communications entre les réseaux de communication 100b). Dans un mode de réalisation particulier, les messages échangés dans le cadre du protocole inter-sondes ont une valeur de champ DSCP qui correspond à une priorité maximale possible. Cela permet de limiter l’impact des situations de congestions sur le transit desdits messages échangés dans le cadre du protocole inter-sondes et ainsi permettre une meilleure réactivité, au besoin, aux situations de congestion.
Le module applicatif 165 est en charge de collecter des informations relatives à une variation de cadencement de flux de données dans le tunnel de communication supervisé par ladite sonde réseau, la variation de cadencement étant mesurée grâce à une variation de différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture desdits paquets fanions. Le module applicatif 165 peut effectuer des calculs sur lesdites mesures afin de détecter et d’évaluer des situations de congestion, en prenant en compte des mesures aussi effectuées par un module applicatif équivalent dans une sonde réseau distante en charge de superviser le tunnel de communication à son autre point de terminaison.
Par exemple, le module applicatif 165 peut être en charge d’instruire le routeur local pour modifier des profils de transmission de données dans le ou les réseaux de communication 100a de sorte à prendre en compte, préférentiellement améliorer (e.g., gestion d’admission de services), les situations de congestion qui seraient révélées par les mesures effectuées ou des calculs qui en découlent. En variante, le module applicatif 165 est en charge de remonter à un orchestrateur des informations relatives aux mesures effectuées ou aux calculs qui en découlent.
La illustre schématiquement un agencement complémentaire de sonde réseau.
Dans le schéma de la , le gestionnaire de sonde réseau 160 comporte un gestionnaire de plan de contrôle (« control plane » en anglais) pour chaque tunnel de communication impliquant le routeur 110 auquel est associée la sonde réseau considérée, c’est-à-dire pour chaque injecteur 150 local et chaque module de capture 155 local.
Chaque gestionnaire de plan de contrôle gère et configure les opérations d’un injecteur 150 et d’un module de capture 155 qui lui sont associés. Ledit gestionnaire de plan de contrôle implémente le protocole de communication inter-sondes pour la supervision du tunnel de communication pour lequel ledit injecteur 150 et ledit module de capture 155 opèrent. Ledit gestionnaire de plan de contrôle effectue, ou coordonne, les opérations de mesure de trafic via ledit tunnel de communication, ainsi que les calculs qui en découlent éventuellement.
Sur la , la sonde réseau considérée est associée à un routeur en extrémité de deux tunnels de communication. Ces tunnels de communication peuvent avoir un même point de terminaison 120 dans le routeur 110 en question, ou deux points de terminaison 120 distincts. Deux injecteurs INJ1 150a et INJ2 150b, et deux modules de capture CAP1 155a et CAP 2 155b respectifs, sont ainsi représentés sur la . Le gestionnaire de sonde réseau 160 comporte alors deux gestionnaires de plan de contrôle respectifs CPM1 170a et CPM2 170b.
Dans le schéma de la , le gestionnaire de sonde réseau 160 comporte en outre une mémoire 175, par exemple sous forme d’une base de données DB (« Database » en anglais). La mémoire en question peut en variante être externe au gestionnaire de sonde réseau 160, voire à la sonde réseau elle-même, et le gestionnaire de sonde réseau 160 est connecté à ladite mémoire et a accès en lecture, écriture, et effacement à ladite mémoire. La mémoire 175 est notamment utilisée par le gestionnaire de sonde réseau 160 pour stocker des informations de captures effectuées par chaque module de capture 155 local, des mesures qui en découlent, des métriques liées à ces mesures, et éventuellement des résultats de calculs effectués sur lesdites métriques.
D’autres architectures modulaires que celle présentée ci-dessus en relation avec les Figs. 1B et 1C peuvent être conçues sans départir des principes et comportement décrits ici, notamment en répartissant autrement les fonctions réalisées par les modules exposés ci-dessus.
Dans un mode de réalisation particulier tel qu’illustré sur la , les sondes réseau sont en communication avec un orchestrateur 180, plus particulièrement par le biais de leurs modules applicatifs 165. Les mesures effectuées par les sondes réseau ou des calculs qui en découlent peuvent ainsi être partagés avec l’orchestrateur 180, afin notamment de détecter et d’évaluer des situations de congestion sur le ou les réseaux de communication 100a et ainsi d’adapter des admissions de service en conséquence. Ainsi, le système de communication est particulièrement adapté aux infrastructures de type SD-WAN (« Software-Defined Wide Area Network » en anglais). Dans un mode de réalisation particulier, l’orchestrateur 180 définit et impose (« enforce » en anglais) une politique d’admission de services dans le ou les réseaux de communication 100a qui tient compte des capacités effectives de communication dans ledit ou lesdits réseaux de communication 100a et qui prend donc en compte les situations de congestion révélées par les sondes réseau.