INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
La molécule hybride ici décrite comprend la construction suivante : un fragment Fc lié de façon covalente à au moins un espaceur PEGn, lui-même couplé à un azoture, ledit azoture étant lié de façon covalente à un alcyne, qui est lui-même couplé à un espaceur PEGn lié à un peptide selon l’invention. Une telle molécule peut se lire : Fc-PEGn-N 3 -DBCO-PEGn-peptide. Les deux PEGn peuvent être identiques ou bien différents (par exemple le premier PEGn est PEG 3 et le deuxième PEGn est PEG 2 ).
Pendant la phase d’immersion qui correspond à la première configuration, les surfaces poreuses 122a des éléments plongeurs 122 captent la chaleur du liquide 2 dit « liquide de chauffe ». L’au moins une surface poreuse 122a étant quant à elle immergée dans le liquide 2 de sorte à s’imprégner de celui-ci.
Pendant la phase d'évaporation correspondant à la deuxième configuration, les éléments plongeurs 122 sortent du liquide 2 de sorte que l’au moins une surface poreuse 122a imbibée de liquide 2 chaud devienne à découvert au contact du mélange gazeux 3 pour permettre une évaporation optimale.
De manière préférée, les éléments plongeurs 122 comprennent respectivement des surfaces poreuses 122a et le total de ces surfaces poreuses 122a est préférentiellement supérieur à la surface superficielle 2a du liquide 2. Ainsi l’ensemble des surfaces poreuses 122a viennent s'ajouter à la surface superficielle 2a afin d’optimiser l’évaporation du liquide 2.
Ce procédé peut être également reproduit par analogie pour augmenter la condensation d'un volume de liquide 2 évaporé. Dans ce cas, le liquide 2 dans lequel les éléments plongeurs 122 sont immergés est refroidi.
Comme illustré aux figures 3A et 3B et de la même manière que dans le mode de réalisation précédent, l’élément mobile 12 comprend des éléments plongeurs 122 fixés sur la face inférieure 121a et configurés pour venir s’immerger dans le liquide 2 chaud dans l’espace de chauffe.
Selon ce mode de réalisation, l’élément mobile 12, comprend un rebord 124 et une face supérieure 121b. La face supérieure 121b étant de préférence une face opposée et parallèle à la face inférieure 121a. Le rebord 124 s’étendant depuis la face supérieure 121b de sorte à définir un volume également désigné réservoir 121c apte à contenir un liquide additionnel 4.
Ainsi, le système alterne entre deux configurations : une première configuration illustrée à la , dans laquelle les éléments plongeurs 122 sont immergés dans le liquide 2 et les plongeurs additionnels 112 sont à découvert. Dans cette configuration les surfaces imbibées des plongeurs additionnels 112 à découvert sont froides car elles viennent de tremper dans le liquide additionnel 4 à proximité de la source froide. Elles transmettent alors de la chaleur négative, participant à la condensation du mélange gazeux 3. Dans cette configuration, les surfaces des éléments plongeurs 122 sont dans le liquide 2 et n’ont pas d’influence sur cette configuration de condensation. Une deuxième configuration illustrée à la , dans laquelle, les surfaces des éléments plongeurs 122 sont à découvert et les plongeurs additionnels 112 sont dans le liquide additionnel 4. Dans cette configuration, les surfaces des éléments plongeurs 122 sont imbibés de liquide chaud et transmettent ainsi de l’énergie d’évaporation. Les plongeurs additionnels n’influent pas durant cette configuration d’évaporation car ils sont plongés dans le liquide additionnel 4.
Comme illustré aux figures 4A et 4B et selon un mode de réalisation, l’au moins un plongeur 122 est entrainé en rotation pour passer alternativement de la première configuration à la deuxième configuration. Les éléments plongeurs 122 ayant par exemple une forme de disque et avantageusement les disques comprennent une portion avec une surface poreuse 122a.
Les disques sont montés sur un arbre d’entraînement 123 de sorte à pouvoir être entrainés en rotation selon une direction transversale X1. La direction transversale X1 étant de préférence orthogonale à l’axe principal Y 1 .
Du fait du mouvement rotatif de l’élément mobile 12 selon la direction transversale X 1 , la surface poreuse 122a est dans un premier temps immergée dans le liquide 2 et dans un second temps, la surface poreuse 122a est imbibée du liquide 2 tout en étant à découvert.
Ainsi la plonge des disques dans le liquide 2 entraine une imbibition des surfaces poreuses 122a. Lesdites surfaces poreuses 122a imbibées et hors de l’eau sont alors avantageusement brassées par un flux d’air de sorte à accélérer la phase d’évaporation. Cette phase d’évaporation étant amplifiée par la présence des surfaces poreuses 122a des disques qui s'ajoutent à la surface superficielle 2a du liquide 2.
Ainsi, l'évaporation est entretenue par rotation des éléments plongeurs 122 dans le liquide 2. Les éléments plongeurs 122 sont exposés à un flux d’air. Pour la phase de condensation, le mode de réalisation est identique mais avec de l’eau froide.
Plusieurs caractéristiques optionnelles du moteur vont être décrites ci-dessous. Toutes ces caractéristiques optionnelles sont compatibles et combinables avec chacun des modes de réalisation décrits ci-dessus, en particulier avec chacun des modes de réalisation dans lesquels les plongeurs sont entrainés en translation ou en rotation.
De manière préférée, la source chaude peut être l’un parmi les éléments suivants : un four, un point de chaleur, une résistance chauffante, une source de chaleur solaire, une source de chaleur de récupération, la chaleur de batteries thermiques .
La source chaude étant avantageusement positionnée tout autour et/ou en dessous de la zone de chauffe de sorte à permettre une montée en température la plus performante possible. La source chaude pouvant être obtenue par échange du liquide de travail avec du nouveau liquide chaud en circuit fermé de sorte à garder la pression de fonctionnement. La source chaude pouvant être aussi un serpentin à l’intérieur du moteur.
Selon un mode de réalisation, l’enceinte 11 est un cylindre creux s’étendant selon l’axe principal Y 1 et la zone de chauffe se situe à une première extrémité du cylindre selon l’axe principal Y 1 . L’enceinte 11 s’étend avantageusement entre une face d’enceinte inférieure 11b et une face d’enceinte supérieure 11a selon l’axe principal Y 1 . L’élément mobile étant guidé par son axe de transmission.
La illustre un exemple d’un message de supervision déterminé par un équipement de supervision, selon des modes de réalisation de l’invention.
La est un organigramme représentant des sous-étapes du procédé de gestion de communication sans fil critique pour la supervision des liaisons de communication sans fil direct d’un dispositif de communication sans fil critique, selon des modes de réalisation de l’invention.
Dans une première étape 20, l’entité MCData émettrice 320 obtient une clé DPPK « MCData Payload Protection Key » et un identifiant de la clé DPPK-ID « MCData Payload Protection Key Identifier ». L’obtention de la clé DPPK peut consister en une réception de la clé DPPK et de l’identifiant DPPK-ID. L’obtention de la clé DPPK peut aussi consister en une génération de la clé DPPK en utilisant les éléments de chiffrement. Il faut noter que la clé DPPK n'est pas un type de clé particulier. En effet le terme DPPK regroupe les types de clés existants dans MCData, par exemple une clé privée PCK « Private Call Key » et une clé GMK « Group Master Key », utilisées pour la protection dans le procédé MCData respectivement pour les communications point-à-point et pour les communications de groupe. Par conséquent, plusieurs clés DPPK peuvent être utilisées dans un procédé 1 d’établissement de session MCData IPCON en fonction du canal de communication. De plus, bien qu'une clé privée PCK et une clé GMK puissent toutes deux être utilisées comme clé DPPK pour protéger le procédé MCData dans différents canaux, la clé privée PCK et la clé GMK ne sont pas la même clé et ne seront pas utilisées dans les mêmes canaux.
Le procédé 1 selon l’invention comprend une seconde étape de transmission 30, par l’entité MCData émettrice 320 à l’entité MCData destinataire 370 via le service de transport MCData, d’un message SIP-INVITE comprenant la clé DPPK et l’identifiant de la clé DPPK-IK.
La transmission 30 s’effectue selon le protocole SDP « Session Description Protocol ». Le protocole SDP est un protocole de communication de description de paramètres d’initialisation d’une session de diffusion en flux. Le protocole SDP ne comprend pas la livraison du média. Il est utilisé par l’émetteur et le destinataire pour la négociation du type et du format du média, et les propriétés associées. La transmission 30 s’effectue par l’embarquement d’une charge SDP dans le corps d’un message SIP INVITE. Le message SIP INVITE est envoyé par l’entité MCData émettrice 320 à l’entité MCData destinataire 370. L’entité MCData destinataire 370 répond ensuite si elle accepte ou non l’établissement d’une session MCData IPCON avec l’entité MCData émettrice 320.
Dans une troisième étape 40, l’entité MCData destinataire 370 authentifie le message SIP-INVITE. L’authentification a pour finalité de vérifier que le message SIP-INVITE provient bien de l’entité MCData émettrice et qu’il n’est pas corrompu. L’authentification peut être facilitée par des procédures d’authentification effectuées préalablement à la mise en œuvre du procédé selon l’invention. Ainsi, dans ce cas, l’authentification peut consister à vérifier que le message a bien été envoyé par l’entité MC Data émettrice. L’authentification peut aussi consister à vérifier la signature d’un élément contenu dans le message. La validité de la signature peut être déterminée en vérifiant que l’identité de l’entité MCData émettrice 320 existe dans la liste des identités de confiance de l’entité MCData destinataire 370 et l'intégrité du document.
Le procédé 1 selon l’invention comprend une dernière étape de détermination 50, par l’entité MCData destinataire 370, de la clé DPPK et l’identifiant de la clé DPPK-ID.
La est un schéma synoptique illustrant l’enchaînement des étapes du procédé selon une variante de l’invention. Dans cette variante, le procédé comprend en outre des étapes finales 60, 70, 80, 90 et 100. Cette variante permet l’envoi sécurisé de bout en bout de données entre deux entités applicatives. Chaque entité applicative est par exemple un serveur applicatif. Une première entité applicative 310 est connectée à une entité MCData émettrice 320 et une seconde entité applicative 360 est connectée à une entité MCData destinataire 370.
A l’étape 60, l’entité applicative émettrice 310 transmet des données utiles à l’entité MCData émettrice 320. Ces données utiles peuvent être chiffrées ou non.
Ensuite, l’entité MCData émettrice 320 génère à une étape 70 un paquet de données comprenant les données utiles chiffrées en utilisant la clé DPPK et l’identifiant de la clé DPPK-ID et un entête. Ainsi, avant la génération 70, les données utiles sont chiffrées. Afin d’effectuer le chiffrement, une dérivation de la clé DPPK peut être nécessaire. Par exemple, la clé DPPK est hachée par une fonction de dérivation de clé pour produire une clé de chiffrement DPCK « MCData Payload Cipher Key » des données utiles. Un exemple de format de données protégées compatible avec l’invention est décrit à la clause 8.5.4.1 dans le document de spécifications techniques TS 33.180 du standard 3GPP.
L’étape 80 consiste à envoyer, par l’entité MCData émettrice 320, le paquet de données généré 70 à l’entité MCData destinataire 370. L’entité MCData destinataire 370 retire ensuite à une étape 90 l’entête du paquet de données généré à l’étape 70 et déchiffre les données utiles chiffrées en utilisant la clé DPPK et l’identifiant de la clé DPPK-ID. Enfin, l’entité MCData destinataire 370 transmet à une étape 100 les données utiles déchiffrées à l’entité applicative destinataire 360. Il faut noter que les serveurs MCData du service de transport MCData 330 assurent le transport entre l’entité MCData émettrice 320 et l’entité MCData destinataire 370. Ces serveurs MCData pourront notamment utiliser l’entête du paquet de données généré à l’étape 70 pour identifier l’entité MCData destinataire 370.
Dans une variante compatible avec la variante décrite ci-dessus, le tunnel IP 340 est un tunnel GRE « Generic Routing Encapsulation » dans le protocole UDP « User Datagram Protocol » et l’entête est un entête de type GRE et UDP. Le tunnel GRE in UDP est configuré entre l’entité MCData émettrice 320 et l’entité MCData destinataire 370, chaque entité MCData 320 et 370 agissant comme une extrémité du tunnel IP 340. Les entités MCData 320 et 370 sont configurées pour envoyer et recevoir les paquets GRE directement entre eux. Les serveurs MCData du système de transport MCData 330 situés entre ces deux entités MCData 320 et 370 n'ouvriront pas les paquets de données encapsulés. Ils ne se réfèreront qu'aux entêtes entourant les paquets encapsulés pour pouvoir les transmettre. Ainsi, cette encapsulation permet notamment de ne pas affecter la sécurité des paquets de données encapsulés.
La est un schéma synoptique illustrant l’enchaînement des étapes du procédé selon une variante de l’invention. Dans cette variante, compatible avec les variantes précédentes, le procédé comprend en outre les étapes préalables 110 et 120. A l’étape 110, l’entité MCData émettrice 320 et l’entité MCData destinataire 370 obtiennent 110 des informations d’autorisation d’établissement de session MCData IPCON, configurée avec un plan média MCData, entre l’entité MCData émettrice et l’entité MCData destinataire 370 et des informations concernant la nécessité de mettre en place un procédé assurant la sécurité des données envoyées. Les informations concernant la nécessité de mettre en place le procédé assurant la sécurité des données envoyées peuvent donc être utilisées pour activer ou désactiver la mise en place du procédé par exemple en fonction de la sécurité des données appliquées par les serveurs applicatifs.
Le service MCData IPCON fournit un plan média pour l'échange de tout type de données IP entre des applications IP. Ces applications IP peuvent résider sur des hôtes externes au réseau 3GPP connectés par une interface IP à l'entité MCData ou peuvent être exécutées directement par l’entité MCData. Un plan média pouvant être utilisé dans l’invention est détaillé dans le document de spécifications techniques TS 24.582.
Les informations d’autorisation d’établissement de session MCData IPCON et concernant la nécessité de mettre en place le procédé assurant la sécurité des données envoyées peuvent être insérées dans le document de profil des entités MCData émettrice et destinataire.
En fonction de ces informations, le procédé est mis en œuvre à une étape 120 ou non. Ainsi si les informations autorisent l’établissement de session MCData IPCON, configurée avec un plan média MCData, entre l’entité MCData émettrice 320 et l’entité MCData destinataire 370 et confirme la nécessité de mettre en place le procédé assurant la sécurité des données envoyées, alors le procédé selon, l’invention est mis en œuvre à une étape 120.
Dans un premier mode d’implémentation, le procédé selon l’invention est un procédé d’établissement de session MCData IPCON de groupe. L’entité MCData émettrice est un client MCData émetteur 420 appartenant à un groupe MCData 480, l’entité MCData destinataire est un ensemble de clients MCData destinataires 470 appartenant à un même groupe MCData 480 que le client MCData émetteur 420, la clé DPPK est une clé de type GMK « Group Master Key » et l’identifiant de la clé DPPK-ID est de type GMK-ID « Group Master Key Identifier ».
En effet, la compare la puissance électrique consommée P elec utilisée pour réaliser les tâches L X dans la durée prédéterminée t f en fonction de la flotte de véhicules autonomes N. Lorsque la flotte de véhicules autonomes N est la flotte de véhicules autonomes en fonctionnement normal N normal (c’est-à-dire la flotte de véhicules autonomes préétablie par défaut), les tâches L X sont réalisées dans un temps court mais requièrent une énergie électrique (courbe en trait plein) et donc une puissance électrique P elec importante. Lorsque la flotte de véhicules autonomes N est la flotte de véhicules autonomes optimale N opti , les tâches L X sont réalisées dans un temps plus long mais requièrent une énergie électrique plus faible (courbe en trait pointillé) et donc une puissance électrique P elec plus faible. Ainsi, une perte énergétique E sur la durée prédéterminée t f est réduite. Réduire la flotte de véhicules autonomes N augmente le temps pour réaliser les tâches L X mais réduit la quantité d’énergie électrique consommée sur la même durée.
Selon, une troisième étape 300 il est déterminé des paramètres de fonctionnements P j de la flotte de véhicules autonomes N. Par exemple, par rapport aux valeurs préétablies par défaut, la vitesse de déplacement v j peut être réduite. Le taux d’accélération a j selon les directions longitudinale et latérale x,y peut être réduit. Le taux de décélération d j selon les directions longitudinale et latérale x,y peut être optimisé pour permettre une régénérescence d’énergie. Puisque le véhicule autonome 16 peut se déplacer selon la direction verticale z, il est avantageux de réduire en outre le taux d’accélération en ascension verticale ca j . En effet, la fonction d’ascension est particulièrement gourmande en énergie, et la réduction du taux d’accélération en ascension verticale ca j permet une réduction considérable de la quantité d’énergie consommée. Le taux de décélération en descente verticale fd j peut également être optimisé. Une quantité d’énergie considérable peut ainsi être regénérée lorsque le véhicule autonome effectue une descente. Ces modifications permettent de minimiser la quantité d’énergie consommée par chaque véhicule autonome j de la flotte de véhicules autonomes N pendant leurs déplacements pour réaliser les tâches L X .
Par exemple, la illustre la perte énergétique E par le véhicule autonome 16 lorsque la vitesse de déplacement v j est réduite. On observe qu’une réduction de la vitesse de déplacement v j de 1,5 m/s permet presque une division par deux de la consommation d’énergie pour la réalisation d’une tâche. En pratique, dans le fonctionnement « économique », la vitesse de déplacement v j peut être de 3 m/s. Pour une tâche de 120 s, le temps de réalisation de la tâche augmente alors de 25%, mais la quantité d’énergie économisée peut être réduite de 7%.
Selon une quatrième étape 400, il est déterminé une stratégie de recharge C j . Par exemple, le courant de recharge I j peut être réduit par rapport à la valeur préétablie par défaut. Le temps de charge t j peut être augmenté pour permettre de fournir la même quantité d’énergie au véhicule autonome 16 branché à la borne de recharge. Il peut également être réduit le nombre de bornes de recharges actives.
Comme décrit ci-avant, les paramètres de fonctionnements P j peuvent être commun à l’ensemble des véhicules autonomes de la flotte de véhicules autonomes N, facilitant leur détermination. Alternativement, les paramètres de fonctionnement P j peuvent être déterminés pour chaque véhicule autonome j de la flotte de véhicules autonomes N. En outre, la stratégie de recharge C j peut être commune à l’ensemble des bornes de recharge, propre à chaque borne de recharge ou encore propre à chaque véhicule autonome 16.
On note que les étapes de détermination de la flotte de véhicules autonomes 200, des paramètres de fonctionnements 300 et de stratégie de recharge 400 peuvent être réalisées simultanément, ou du moins dans un ordre quelconque et/ou en plusieurs fois.
On décrit par la suite une méthode pour déterminer la flotte de véhicules autonomes N, les paramètres de fonctionnement P j , et la stratégie de recharge C j permettant de consommer une quantité d’énergie minimale, en référence à la .
La détermination de la flotte de véhicules autonomes N, des paramètres de fonctionnement P j et de la stratégie de recharge C j permettant de consommer la quantité d’énergie minimale peut être réalisée en amont de l’activation du fonctionnement dit « économique ». Il peut être prévu une base de données stockant une pluralité de tâches à réaliser dans une pluralité de durées prédéterminées. Pour chaque nombre de tâches et durée prédéterminée, il peut être associé une flotte de véhicules autonomes N, des paramètres de fonctionnement P j et une stratégie de recharge C j . Ainsi, les valeurs peuvent être retrouvées en parcourant la base de données selon les tâches L X et la durée prédéterminée t f à l’instant présent t0.
Selon une première étape 500, il est défini une pluralité de flottes de véhicules autonomes N. La pluralité de flottes de véhicules autonomes peut prendre la forme d’un vecteur allant de zéro véhicules autonomes au nombre maximum N max de véhicules autonomes.
Selon une deuxième étape 600, il est défini une pluralité de paramètres de fonctionnement P j . Chaque paramètre de fonctionnement P j peut être un vecteur comportant une vitesse de déplacement v j , un taux d’accélération a j , un taux de décélération d j , un taux d’accélération en ascension verticale ca j , un taux de décélération en ascension verticale cd j , un taux d’accélération en descente verticale fa j et un taux de décélération en descente verticale fd j . Les vecteurs peuvent être associés à un véhicule autonome j particulier ou être communs à la flotte de véhicules autonomes N. Les taux d’accélération et de décélération peuvent être constants ou fonction de la vitesse de déplacement.
Selon une troisième étape 700, il est défini une pluralité de stratégies de recharge en énergie C j . Chaque stratégie de recharge en énergie C j . peut être un vecteur comportant un courant de charge I j et un temps de charge t j . Les vecteurs peuvent être associés à un véhicule autonome particulier j, à une borne de recharge particulière, être communs à toutes les bornes de recharge et/ou tous les véhicules autonomes 16.
Selon une quatrième étape 800, il est déterminé une perte énergétique E pour une pluralité de combinaison de flottes de véhicules autonomes N, de paramètres de fonctionnement P j et de stratégies de recharge en énergie C j . La perte énergétique E est déterminée en fonction de la durée prédéterminée t f . La perte énergétique E correspond ici à une différence entre la quantité d’énergie électrique utilisée E elec et une quantité d’énergie mécanique produite E mech pendant la durée prédéterminée t f .
La quantité d’énergie électrique utilisée E elec est fonction des paramètres de fonctionnement P j et de la stratégie de recharge C j . En effet, la quantité d’énergie électrique utilisée E elec correspond à l’énergie électrique consommée par le système 10 pour la réalisation des tâches L X dans la durée prédéterminée t f . La quantité d’énergie électrique utilisée E elec peut notamment être calculée selon l’équation suivante.
La quantité d’énergie mécanique produite E mech est fonction des paramètres de fonctionnement P j . En effet, l’énergie mécanique produite E mech correspond à l’énergie utilisée par la flotte de véhicules autonomes pour réaliser les tâches (pour se déplacer). L’énergie mécanique produite E mech peut notamment être calculée selon l’équation suivante.
On note que la perte énergétique E peut être déterminée expérimentalement ou par simulation.
Selon une cinquième étape 900, il est sélectionné la combinaison C de flotte de véhicules autonomes N, de paramètres de fonctionnement P j et stratégie de recharge C j présentant la perte énergétique E la plus faible. Cette combinaison C correspond à la flotte de véhicules autonomes optimale N opti , aux paramètres de fonctionnement P j et à la stratégie de recharge C j à utiliser pour réaliser l’ensemble des tâches dans la durée prédéterminée t f en consommant une quantité d’énergie minimale. La combinaison peut être regroupée dans un vecteur.
Le moyen de géolocalisation 1 permet en outre de détecter une voie de sortie 210 située sur la route 200, en amont de la position du véhicule automobile 100. Un mode de réalisation de la détection d’une voie de sortie est illustré par la .