INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le document FR 2 607 169 A1 (ROSSET Claude) décrit un tel dispositif de retenue ; il est fait d’une seule pièce, en tôle emboutie. Coupé verticalement dans le sens de la pente, ce dispositif forme un dièdre dont les parois descendent depuis le sommet du dièdre en direction du toit. Une première des parois, située à l’amont, descend vers l’amont avec une pente abrupte, presque perpendiculairement au toit ; dans des modes de réalisation connus, cette première paroi forme avec le toit un angle qui peut être d’environ quatre-vingt degrés. La deuxième paroi, située en aval, descend en pente douce vers l’aval.
Cependant, les pentes de toit variant entre quinze et cinquante degrés, l’efficacité de l’arrêt décrit dans le document FR 2 607 169 A1 décroit rapidement lorsque la pente augmente.
Le but de l’invention est de proposer un dispositif de retenu dont les performances sont peu ou pas dépendantes de la pente du toit sur lequel il est installé.
Selon l’invention, un dispositif pour retenir de la neige sur un toit comprenant des nervures s’étendant dans la direction d’une pente du toit, notamment un toit en bac-acier, comprend :
- deux pattes, chacune étant prévue pour, dans une position d’usage, reposer au sommet d’une nervure respective parmi deux nervures voisines ;
- une plaque d’arrêt s’étendant entre les pattes et prévue pour, dans la position d’usage, s’étendre au-dessus d’une rigole formée par le toit entre les deux nervures ;
la plaque d’arrêt étant inclinée de sorte que dans la position d’usage elle va de bas en haut en même temps que d’aval en amont et forme un angle d’arrêt aigu avec la direction de la pente, et comprenant une face amont contre laquelle de la neige en amont du dispositif peut s’accumuler. Avantageusement, l’angle d’arrêt est compris entre quarante-cinq et soixante-quinze degrés, de préférence voisin de soixante degrés.
Le dispositif peut en outre comprendre, à l’aval de la plaque d’arrêt, une bavette qui prolonge cette plaque vers l’aval et remonte d’amont en aval. La bavette peut former avec la plaque d’arrêt une gouttière transversale et un angle de gouttière, avantageusement compris entre soixante-dix et cent-dix degrés, de préférence voisin de quatre-vingt-dix degrés. La gouttière peut s’étendre à un niveau le plus bas du dispositif.
Le dispositif peut en outre comprendre, à l’amont de la plaque d’arrêt, un rabat qui prolonge la plaque vers l’amont et descend d’aval en amont. Le rabat peut former avec la plaque d’arrêt une crête transversale et un angle de crête, avantageusement compris entre soixante-dix et cent-dix degrés, de préférence voisin de quatre-vingt-dix degrés. La crête peut s’étendre à un niveau le plus haut du dispositif.
Chaque patte comprend avantageusement un trou pour y introduite des moyens pour fixer le dispositif au toit, ce trou ayant un axe de fixation plus proche d’un bord amont que d’un bord aval de la patte.
Chaque patte peut comprendre un repli vers le bas, formée à son extrémité libre.
est une vue en perspective depuis l’aval et la droite d’un dispositif selon l’invention dans une position d’usage, installé sur un toit en bac-acier ;
est une vue en perspective depuis l’aval et la gauche du dispositif de la , isolément ;
est une vue du dispositif de la , depuis la droite et selon la coupe transversale notée III-III à la ; et,
Users/ /AppData/Roaming/Microsoft/Windows/StartMenu/Programs/Startup
dans lequel est le nom de l’utilisateur tel qu’enregistré dans le système d’exploitation Windows® (correspondant donc à sa session).
Ainsi à chaque ouverture de sa session sous Windows®, le module logiciel sera automatiquement exécuté.
En outre, le module logiciel peut être un programme en langage Python®, et stocké dans l’équipement sous la forme d’un fichier « .pyw ». Cela permet que le module logiciel soit considéré comme un service afin de ne pas être détecté comme un logiciel et rendre plus difficiles sa détection et sa fermeture par l’utilisateur.
De la même façon, sur un équipement fonctionnant avec un système d’exploitation « Mac OS® » de la société Apple®, le module logiciel peut être mémorisé dans le répertoire :
~/Library/LaunchDaemons/
De la sorte, le module logiciel est automatiquement exécuté lors du démarrage de l’équipement.
De la même façon également, le module logiciel peut être un programme en langage Python®, et stocké dans l’équipement sous la forme d’un fichier « .pyw ». Cela permet que le module logiciel soit considéré comme un service afin de ne pas être détecté comme un logiciel et rendre plus difficiles sa détection et sa fermeture par l’utilisateur.
Sur un équipement de type tablette ou terminal de télécommunication, le module logiciel peut être un lanceur (ou « launcher » en anglais) afin d’être automatiquement exécuté lors du démarrage de l’équipement
Ce module logiciel (ou application) peut se déclarer via le mécanisme d’intentions (ou « intent » en anglais) d’Android® pour répondre aux actions « home » et « default » :
Le mécanisme de services en arrière-plan (« background services ») permet d’analyser l’équipement en continu
Le mécanisme de service en avant-plan (« foreground service » en anglais) permet de maintenir le service en arrière-plan indéfiniment.
Le service système « Usage_stat_service » permet d’analyser les applications ouvertes et de remettre le module logiciel au premier plan au besoin.
Sur un équipement fonctionnant avec un système d’exploitation iOS de la société Apple® ou bien un système d’exploitation Android®, l’outil MDM (« Mobile Device Management ») peut être utilisé afin de rentrer l’équipement dans un mode supervisé et permettre l’analyse du téléphone en continu.
Selon des modes de réalisation de l’invention, les mesures 42 sur le comportement des applications installées sur les équipements de traitement de l’information comprennent tout ou partie des mesures suivantes : nom de l’application, durée d’utilisation de chaque application (heure de début, heure de fin), heures d’utilisation de chaque application, fréquence d’ouverture de chaque application.
Selon des modes de réalisation de l’invention, les mesures 43 sur le comportement des équipements de traitement de l’information comprennent tout ou partie des mesures suivantes : Heures de connexion et déconnexion d’une session ; Heures d’allumage et d’extinction de l’équipement ; Déplacement de l’équipement (nombre de pas…) ; Orientation de l’équipement ; Luminosité de l’équipement ; Fréquence d’interactions avec l’équipement (nombre de « clics » ou autres interactions).
Le chiffrement de média voix MCPTT (de l’anglais « Mission Critical Push To Talk » pour « Appuyer Pour Parler en Mission Critique » en français) ou vidéo MCVideo dans une communication de groupe est défini dans la spécification technique TS 33.180. Elle met notamment en œuvre la diversité du point d’extrémité (« endpoint diversity » en anglais).
On appellera par la suite « MCX » tout service Mission-Critique défini par le standard 3GPP MCS, tels que les services MCVideo, MCData (pour « Données » en français) et MCPTT. Un « client » et un serveur sont des dispositifs comprenant au moins un processeur et une mémoire, la mémoire comprenant des instructions qui, lorsqu’elles sont exécutées par le processeur, conduisent le dispositif utilisateur à mettre en œuvre au moins les actions qui lui sont attribuées. Préférentiellement, un client est un dispositif utilisateur. De la même façon, un « serveur » peut être un dispositif utilisateur. Un « client MCX » et un « serveur MCX » sont donc des dispositifs utilisateur configurés pour mettre en œuvre des services Mission Critique.
Lors d’une émission de media depuis un client MCX, le media émis peut être chiffré d’une façon ne dépendant pas de l’émetteur. Dans un tel cas, le concept de « diversité d’extrémité » ou « endpoint diversity » en anglais, n’est pas mise en œuvre. Au contraire, la mise en œuvre de la diversité d’extrémité impose le chiffrement du media émis par une clé propre au client MCX émetteur. Pour cela, l’identité MCX ID de l’utilisateur de ce client MCX émetteur est utilisée pour générer un identifiant de clé utilisateur de groupe (GUK-ID pour « Group User Key Identifier » en anglais). Cet identifiant GUK-ID est utilisé pour : chiffrer un media du flux SRTP (de l’anglais « Secure Real-time Protocol » pour « Protocole Temps Réel Sécurisé » en français) émis par le client MCX émetteur et déchiffrer ce flux media SRTP par les clients MCX récepteurs.
Les procédures de la spécification technique TS 33.180 (clause 7.4.2) prévoient que le client MCX émetteur inclue cet identifiant GUK-ID dans un champ SRTP MKI (de l’anglais « Master Key Identifier » pour « Identifiant de Clé Maitre » en français) de 64 bits transmis avec chaque paquet SRTP. L’identifiant de clé maitre MKI au format long (64 bits) comprend en fait un identifiant de clé maitre de groupe (GMK-ID pour « Group Master Key Identifier » en anglais) concaténé à l’identifiant de clé utilisateur de groupe GUK-ID. Pour créer l'association de sécurité du groupe de communication au sein duquel le media est échangé, une clé maitre de groupe (GMK) et son identifiant associé (GMK-ID) sont distribués aux clients MCX du groupe par un serveur de gestion de groupe (« GMS » pour « Group Management Server » en anglais).
Cette procédure donne aussi la possibilité, lorsque l’identité de l’utilisateur du client MCX émetteur (identité aussi appelée « User Salt » en anglais) est connue des clients MCX récepteurs, de réduire le SRTP MKI à 32 bits en omettant sa composante GUK-ID de l’émetteur, c’est-à-dire en ne comprenant que l’identifiant de clé maitre de groupe GMK-ID. L’identifiant de clé utilisateur de groupe GUK-ID est alors calculé localement par les clients MCX récepteurs en réalisant une opération « OU exclusif » XOR entre l’identité de l’utilisateur du client MCX émetteur connue (« User salt ») et l’identifiant de clé maitre de groupe GMK-ID. De la même façon, l’identifiant de clé maitre de groupe GMK-ID peut être calculé à partir de l’identifiant de clé utilisateur de groupe GUK-ID et de l’identité de l’utilisateur du client MCX émetteur connue (« User salt »). Par contre, l’identité de l’utilisateur du client MCX émetteur ne peut être obtenue à partir de l’identifiant de clé maitre de groupe GMK-ID et de l’identifiant de clé utilisateur de groupe GUK-ID, ce pour garder une certaine confidentialité.
L’identité de l’utilisateur du client MCX émetteur peut être obtenue car elle est comprise dans les messages de contrôle de prise de parole en service voix MCPTT, messages appelés « Floor Control ». En service vidéo MCVideo, cette information est obtenue car elle est comprise dans les messages de contrôle de transmission, messages appelés « transmission control ». En service données MCData, il n’existe pas de diversité des points d’extrémité dans les spécifications 3GPP. En MCData, il est toutefois possible de récupérer l’identité de l’utilisateur du client MCX émetteur dans la charge utile (« payload » en anglais) des messages SIP et/ou HTTP. SIP est un protocole d’initiation de session (« Session Initiation Protocol » en anglais) connu et HTTP (pour « HyperText Transfer Protocol » en anglais) est un protocole de communication connu. En MCData, ce « payload » est chiffré de bout en bout mais sans diversité d’extrémité.
Dans le standard 3GPP MCS, seul le client MCX émetteur détermine quel format d’identifiant MKI (32bits ou 64 bits) il utilise. Son identité d’utilisateur est transmise dans toutes les demandes d’établissement d’appel (« call request » en anglais) et dans toutes les demandes de droit de parole (« floor request » et « transmission control »).
Le client MCX émetteur peut donc légitimement considérer que son identité d’utilisateur est transmise de bout en bout et choisir d’économiser de la bande passante (de 5 à 10% pour de la voix MCPTT selon la compression d’entête utilisée) en utilisant le format de MKI réduit (32 bits) n’incluant pas son identifiant GUK-ID, considérant alors que les client MCX récepteurs seront capables de le recalculer localement en utilisant son identité d’utilisateur récupérées à partir des floor control, transmission control ou messages SIP en MCData.
Or, il existe des cas où l’identité de l’utilisateur du client MCX émetteur ne pourra pas être connue de tous ou de certains client MCX récepteurs, les empêchant de pouvoir déchiffrer les informations reçues, sans que le client MCX émetteur ne le sache : Parce que conformément aux procédures des spécifications techniques TS 24.380 (« media plane » MCPTT) et 24.581 (« media plane » MCVideo), le serveur contrôleur de media du groupe au sein duquel les utilisateurs communiquent considère qu’il y a un besoin d’intimité (« privacy » en anglais) et que l’identité de l’utilisateur à qui le droit d’émettre est accordé ne doit pas être indiquée aux autres participants, ou Parce que conformément aux procédures des spécifications techniques TS 24.380 et 24.581 pour les groupes regroupés, l’identité de l’utilisateur demandant le droit d’émettre est masqué au serveur contrôleur de media du regroupement de groupe par le serveur contrôleur de media du groupe constituant (appelé « Non-controlling server »), le groupe constituant étant le groupe de communication appartenant au groupe regroupe et auquel est affilié le dispositif utilisateur de l’utilisateur demandant le droit d’émettre, Parce que dans le cas d’interconnexion de systèmes, l’identité des utilisateurs d’un des systèmes peut être considérée comme sensible et masquée par un serveur passerelle MCX (« MCX gateway server ») en charge de filtrer de telles informations sensibles dans les messages échangés entre les systèmes ne se faisant pas entièrement confiance. Dans un tel contexte, la portée du groupe de communication (intra ou inter système) n’est pas nécessairement connue des membres du groupe.
Conformément à la spécification technique 3GPP TS 33.180, il existe un besoin de chiffrer les media dans le groupe de communication utilisant de la diversité d’extrémité (« endpoint diversity » en anglais). Ceci n’est valable que pour le media voix (MCPTT) et pour le media video (MCVideo) mais pas pour les « payload » MCData, car il n’existe pas de endpoint diversity dans les spécifications 3GPP MCS du MCData.
Comme décrit précédemment, l'identité de l’utilisateur du client MCX émetteur ne pouvant pas toujours être connue des autres participants, par exemple pour des raisons de confidentialité (privacy), dans des cas d'interconnexion de systèmes dans des domaines de confiance différents, ou dans des cas de regroupement de groupes , il existe donc actuellement des cas dans lesquels les clients MCX récepteurs ne peuvent déchiffrer le media reçu, qu’il soit un media voix (MCPTT), un media vidéo (MCVideo). Le besoin de confidentialité du client MCX émetteur peut être déterminé à tout niveau, par exemple par appel, par utilisateur, par groupe, par organisation, par système ou par pays, ce qui complique la tâche d’identification, dans un réseau, des acteurs et/ou des actions pouvant être amené(e)s à cacher l’identité de l’utilisateur du client MCX émetteur.
Il existe donc un besoin de pouvoir s’assurer, dans un réseau 3GPP MCS, qu’un client MCX récepteur puisse déchiffrer un contenu chiffré émis par un client MCX émetteur.
L’invention offre une solution aux problèmes évoqués précédemment, en permettant à un client émetteur, dans un réseau 3GPP MCS, de choisir le chiffrement qu’il applique à un contenu émis de sorte qu’un client récepteur puisse bien déchiffrer le contenu émis.
Un aspect de l’invention concerne un procédé mis en œuvre par une entité cliente émettrice comprise dans un réseau selon le standard 3GPP MCS « 3rd Generation Partnership Program Mission Critical Services », l’entité cliente émettrice étant configurée pour émettre un contenu destiné à une entité cliente réceptrice comprise dans le réseau, l’entité cliente émettrice et l’entité cliente réceptrice étant affiliées à un même groupe de communication, le procédé comprenant au moins une étape de sélection, par l’entité cliente émettrice à partir d’au moins une information de contexte de sécurité stocké en mémoire de l’entité émettrice, d’un contexte de sécurité parmi les contextes de sécurité suivants: Un contexte de sécurité avec diversité d’extrémité, le contexte de sécurité étant formé de : Un identifiant de clé maître MKI long formé d’un identifiant de clé maitre de groupe GMK-ID et d’un identifiant de clé utilisateur de groupe GUK-ID, l’identifiant de clé maitre de groupe GMK-ID étant propre au groupe de communication, l’identifiant de clé utilisateur de groupe GUK-ID étant propre à un utilisateur de l’entité émettrice, ou Un identifiant de clé maitre MKI court formé de l’identifiant de clé maitre de groupe GMK-ID ou Un identifiant de clé maitre MKI court formé de l’identifiant de clé utilisateur de groupe GUK-ID ou Aucun identifiant de clé maitre MKI. Un contexte de sécurité sans diversité d’extrémité, le contexte de sécurité étant formé de : Un identifiant de clé maitre MKI court formé de l’identifiant de clé maitre de groupe GMK-ID ou Aucun identifiant de clé maitre MKI.
Selon une caractéristique de l’invention, le module thermique comprend au moins un troisième échangeur de chaleur porté par la plaque commune, le troisième échangeur de chaleur étant un refroidisseur, c’est-à-dire un échangeur thermique configuré pour refroidir le liquide caloporteur par évaporation du fluide réfrigérant.
est une vue générale schématique de côté d’un module thermique d’un circuit de fluide réfrigérant selon un premier exemple de l’invention ;
est une vue générale schématique de dessus du module thermique d’un circuit de fluide réfrigérant de la selon un premier exemple de l’invention ;
est une vue schématique du circuit de fluide réfrigérant de la fonctionnant selon un deuxième mode de fonctionnement ;
est une vue générale schématique de côté du module thermique d’un circuit de fluide réfrigérant selon un deuxième exemple de l’invention ;
est une vue générale schématique de côté du module thermique d’un circuit de fluide réfrigérant selon une alternative du deuxième exemple de l’invention ;
est une vue générale schématique de côté d’un module thermique d’un circuit de fluide réfrigérant selon un troisième exemple de l’invention ;
est une vue générale schématique de côté d’un module thermique d’un circuit de fluide réfrigérant selon un quatrième exemple de l’invention;
est une vue schématique du circuit de fluide réfrigérant comprenant le module thermique de la selon un quatrième exemple de l’invention ;
est une vue générale schématique de côté d’un module thermique d’un circuit de fluide réfrigérant selon un cinquième exemple de l’invention;
est une vue schématique du circuit de fluide réfrigérant comprenant le module thermique de la selon un cinquième exemple de l’invention.
Des sorties d’air dans l’habitacle sont prévues et sont ouvertes ou fermées grâce à des volets 21, connus de l’état de l’art.
Par exemple, des sorties d’air principales 22 dirigeant l’air vers les passagers sont prévues.
Des sorties d’air de dégivrage 23 et des sorties d’air 24 vers le plancher sont également prévues.
L’unité de contrôle 6 est agencée pour, en cas de dépassement de la valeur seuil de qualité de l’air ThQ, arrêter le traitement de l’air recyclé par le dispositif d’air conditionné 10, en fermant l’entrée d’air de recyclage 14 de ce dispositif d’air conditionné 10.
En cas de dépassement de la valeur seuil de qualité de l’air ThQ, le dispositif d’air conditionné 10 fonctionne uniquement en prélevant de l’air frais par l’entrée d’air frais 11.
Ainsi l’invention permet d’éviter que de l’air recyclé déjà riche en CO2 ne soit réinjecté dans l’habitacle 2. Au lieu de cela, l’unité de contrôle permet de faire baisser la concentration de CO2 dans l’habitacle en y injectant de l’air frais de concentration plus faible en CO2, notamment de sorte que la concentration de CO2 repasse en dessous de la valeur seuil de qualité de l’air ThQ.
L’unité de contrôle 6 est agencée pour permettre de nouveau le traitement de l’air de recyclage lorsque la concentration de CO2 mesurée par le capteur repasse sous la valeur seuil de qualité de l’air ThQ.
Le système 1 comporte une boucle 30 de gestion thermique du véhicule, le dispositif d’air conditionné 10 faisant partie de cette boucle 30 de gestion thermique et cette boucle 30 utilisant un fluide réfrigérant.
Dans l’exemple décrit, le fluide est du CO2, encore appelé fluide réfrigérant R744.
La boucle 30 de gestion thermique est agencée pour pouvoir fonctionner en mode pompe à chaleur.
Le fluide réfrigérant R744 est utilisé dans un cycle de fonctionnement transcritique, c’est-à-dire faisant intervenir des températures/pressions supérieures à la température/pression critique du fluide.
De manière connue en soi, la boucle 30 de gestion thermique comprend en outre les composants suivants (non représentés) à travers lesquels circule le fluide réfrigérant : un compresseur, un premier dispositif de détente, un échangeur de chaleur extérieur, une vanne, un deuxième dispositif de détente, l’évaporateur 17 et une bouteille déshydratante.
Le compresseur est électrique et est alimenté en énergie par une batterie du véhicule. L'échangeur de chaleur extérieur est localisé en face avant du véhicule automobile et est traversé par un flux d'air en provenance de l'extérieur du véhicule. L'évaporateur 17 est localisé à l'intérieur du dispositif d’air conditionné 10 dans lequel un flux d'air circule pour être traité thermiquement préalablement avant son introduction dans l'habitacle du véhicule automobile.
Le capteur 5 de concentration de CO2 est agencé pour mesurer une concentration de CO2 dans l’air environnant l’évaporateur 17.
L’unité de contrôle 6 est agencée pour recevoir une valeur de concentration de CO2 mesurée par le capteur 5 et comparer cette valeur de concentration mesurée de CO2 avec au moins une valeur seuil d’alerte de fuite ThL et, en cas de dépassement de cette valeur seuil d’alerte de fuite ThL, cette unité de contrôle 6 est agencée pour contrôler le dispositif d’air conditionné 10 du véhicule de manière à faire baisser la concentration de CO2 dans l’habitacle 2, en faisant fonctionner le dispositif d’air conditionné 10 uniquement par prélèvement d’air frais ou en arrêtant complètement le fonctionnement du dispositif d’air conditionné 10.
Cette valeur d’alerte de fuite ThL est choisie comme étant caractéristique de la présence d’une fuite de fluide réfrigérant R744 sur l’évaporateur 17 et/ou sur des jonctions entre des tubulures et cet évaporateur 17.
Par exemple, la valeur seuil de qualité de l’air est choisie dans la plage 800 ppm à 1 500 ppm de CO2, étant par exemple égale à 1 000 ppm.
Par exemple, la valeur seuil d’alerte de fuite est choisie dans la plage 4 000 ppm à 6 000 ppm de CO2, étant par exemple égale à 5 000 ppm.
Selon l’un des aspects de l’invention, le capteur est agencé pour mesurer la concentration de CO2 dans l’air sur une plage de 0 ppm à une borne supérieure qui est supérieure ou égale à 5 000 ppm.
Selon l’un des aspects de l’invention, cette plage est de 0 ppm à 5 000 ppm, ou de 0 ppm à 10 000 ppm.
Il est avantageux d’utiliser un capteur de concentration de CO2 pouvant travailler dans une plage large, notamment pour à la fois évaluer la qualité de l’air dans l’habitacle et détecter une fuite de CO2 sur l’évaporateur.
Selon l’un des aspects de l’invention, le capteur de concentration de CO2 est placé à un emplacement approprié pour pouvoir détecter une fuite de CO2 sur l’évaporateur, notamment une fuite susceptible de faire augmenter la concentration de CO2 dans l’habitacle du véhicule.
Par exemple, le dispositif d’air conditionné comprend un boîter dans lequel l’évaporateur est placé et le capteur est disposé au contact de ce boîtier.
Le dispositif d’air conditionné est généralement placé juste derrière une planche de bord du véhicule, avec des sorties d’air qui sont présentes sur cette planche de bord.
Compte tenu de cette proximité avec l’habitacle, une fuite de fluide réfrigérant sur l’évaporateur est susceptible de générer un apport non désiré de CO2 dans l’habitacle, ce qui peut s’avérer dangereux pour les passagers en cas de trop forte concentration de CO2.