INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
La présente divulgation concerne encore un élément de garniture de siège en tant que tel, ainsi qu’un siège de véhicule comprenant une structure métallique et un tel élément de garniture.
Selon un premier aspect , la présente divulgation est relative à un procédé de fabrication d’un élément de garnissage de siège comprenant : /G1/ fourniture d’une matelassure comprenant un enchevêtrement 3D de fibres thermoplastiques, continues disposées irrégulièrement formant des boucles soudées entre elles, /G2/ fourniture d’une coiffe, /G3/ fourniture d’une feuille d’interface, /G4/ formation d’un assemblage comprenant en superposition trois couches successives comprenant la matelassure, la coiffe et ladite feuille d’interface intercalée entre la coiffe et la matelassure , /G5/ solidarisation par soudure des trois couches de l’assemblage au moins par compression de l’assemblage entre une premier partie de presse et une deuxième partie de presse dans un outillage.
Selon des caractéristiques optionnelles de la présente divulgation, prises seules ou en combinaison ;
5.2.3 Politique d’ordonnancement de paquets de données
Comme indiqué ci-dessus, notamment en relation avec le principe général de l’invention, au moins une politique d’ordonnancement de paquets de données (PSS) peut être sélectionnée pour un couple entité source / entité destinataire. Une telle politique d’ordonnancement de paquets de données peut notamment supporter tout ou partie des fonctions suivantes : gestion des chemins disponibles, gestion de la congestion, réassemblage des paquets, réordonnancement des paquets, etc.
Une PSS peut éventuellement prendre en compte d’autres paramètres pour l’exécution des fonctions précédemment décrites, tels que : des conditions tarifaires, renseignées par exemple dans les contrats établis avec les opérateurs des différents réseaux externes, des instructions de l’utilisateur, par exemple une minimisation des coûts induits, un équilibrage de l’utilisation des chemins, etc.), l’expérience de l’utilisation (passée, historique) des ressources associées à chaque réseau externe, qui permet par exemple de qualifier la stabilité de certaines ressources à l’usage et de mettre en place des politiques de maintenance adaptées.
Une entité mettant en œuvre l’invention (par exemple un CE ou un concentrateur) peut notamment prendre en compte différents paramètres pour sélectionner au moins une PSS de données applicatives échangées entre l’entité source et l’entité destinataire, en tenant compte d’au moins une caractéristique d’une application associée aux données applicatives. Par exemple, une entité mettant en œuvre l’invention peut sélectionner au moins une PSS permettant d’adapter l’utilisation des ressources, et/ou d’optimiser la latence, et/ou de maximiser l’usage des ressources, et/ou d’améliorer leur disponibilité, etc.
Une entité mettant en œuvre l’invention (par exemple un CE ou un concentrateur) peut notamment établir au moins une connexion de référence entre l’entité source et l’entité destinataire, sur laquelle est mise en œuvre la PSS sélectionnée. Dans certains modes de réalisation, une telle connexion de référence repose au moins sur deux sous-connexions associées chacune à un chemin distinct entre l’entité source et l’entité destinataire. Le choix de la ou des sous-connexions utilisées pour acheminer les données applicatives peut dépendre notamment du mode d’application de la PSS sélectionnée.
Une entité mettant en œuvre l’invention (par exemple un CE ou un concentrateur) peut notamment maintenir des informations caractéristiques d’au moins un réseau externe, qui alimentent par exemple une fonction locale de suivi et de détection de symptômes caractéristiques de la détérioration de la qualité de service ou de la qualité d’expérience (QoE, « Quality of Experience ») pour une application donnée. Une telle fonction repose par exemple sur l’exploitation de données qui peuvent être traitées par des techniques d’intelligence artificielle telles que l’apprentissage machine (« Machine Learning » en anglais) et l’utilisation d’algorithmes d’apprentissage spécifiques (par exemple un algorithme d’apprentissage par renforcement, ou « Reinforcement Learning » en anglais) et est exécutée localement (typiquement supportée par un CE). Une telle fonction permet par exemple de surveiller : le taux de remplissage des files d’attente : suivi des files d’attente observées sur chaque interface utilisée par un CE pour se connecter à un réseau externe. Le taux de remplissage des files d’attente peut renseigner un CE sur la qualité de la transmission via l’interface concernée. Cette information peut être utilisée pour décider des interfaces à utiliser pour acheminer des données en fonction des besoins de qualité de service ou de QoE d’une application donnée, par exemple, un délai de transit (« One-way transit delay ») tel qu’observé sur un chemin, un temps de trajet aller-retour RTT (« Round-Trip Time » en anglais) tel qu’observé sur un chemin, et notamment un chemin permettant d’accéder à un concentrateur, une perte de paquets observée sur un chemin, une variation d’un délai inter-paquets (« Inter-Packet Delay Variation ») ou gigue, des paramètres applicatifs avancés calculés par des robots qui émulent certaines applications (par exemple de type robot VoIP, robot Webex®), un historique des congestions observées sur un chemin, etc.
Le suivi de la qualité de service ou de la QoE pour une application donnée, par exemple, à partir de la fonction de suivi permet notamment de mettre à jour le mode d’application de la PSS sélectionnée. En d’autres termes, ces différentes informations peuvent être utilisées par un CE (resp. un concentrateur) pour exécuter plusieurs actions caractéristiques de l’application d’une PSS, en fonction des contraintes de qualité de service ou de QoE des applications, par exemple. De telles actions peuvent consister à exécuter certains algorithmes tels que : algorithme de type « Round-robin » : les chemins (également appelés « liens ») sont invoqués de façon cyclique en fonction d’un point de sortie (CE, pour un trafic du LAN vers un réseau externe), associé à chaque chemin. Par exemple, le poids de chaque chemin peut être fixé par un administrateur ou être calculé (dynamiquement) en fonction de plusieurs paramètres (par exemple optimisation des coûts de la connexion de référence), optimisation du temps de stockage des paquets dans les files d’attente au moyen d’une gestion d’intervalles temporels, « Priority-based » : des priorités sont affectées à chaque chemin, par exemple en tenant compte d’une politique PBR (« Policy-Based Routing » en anglais), un seuil RTT (« RTT threshold » en anglais) : les chemins sont utilisés jusqu’à ce qu’un certain seuil RTT soit atteint. Par exemple, le seuil est fixé de sorte que l’application de la PSS puisse garantir que les chemins utilisés ne présentent pas une RTT non-conforme aux attentes des applications. Le ou les algorithmes impliqués (algorithmes de gestion de files d’attente, notamment) dans l’application de la PSS permet notamment une gestion proactive de la détérioration de la latence, une priorité affectée aux chemins présentant le plus faible RTT (« Lowest RTT first » en anglais) : de tels chemins sont par exemple privilégiés pour acheminer le trafic à destination d’un concentrateur etc.
Différents histogrammes et distributions statistiques peuvent aussi être maintenus pour la gestion proactive des paramètres de qualité de service et de QoE. Le trafic peut alors être distribué entre différents chemins selon un objectif de QoE par exemple, et pas seulement en fonction la QoE observée à un instant donné. Par exemple, un CE peut procéder : à la réplication d’une partie des paquets de données (exprimé par exemple en pourcentage du trafic total) entre plusieurs chemins pendant une durée déterminée, au basculement de tout ou partie du trafic vers une ou plusieurs entités source selon l’observation du taux de remplissage des files d’attente, de l’évolution du paramètre RTT, ou selon d’autres critères ou symptômes observés par l’entité source.
Dans un mode de réalisation particulier, une politique d’ordonnancement de paquets de données PSS peut être identifiée par un identifiant unique. Par exemple, une PSS peut être identifiée par un entier, un nom, etc. Les PSS par « couple » entité source/ entité destinataire peuvent notamment être référencées dans un registre (par exemple PSS1 entre un CE donné et un concentrateur donné, PSS2 entre un concentrateur donné et un serveur donné, PSS3 entre un terminal donné et un serveur donné).
5.2.4 Sélection et mise en œuvre d’une politique d’ordonnancement de paquets de données
On revient à la et à l’exemple selon lequel ni le terminal H1, ni le serveur S ne supportent la procédure de sélection d’au moins une politique d’ordonnancement de paquets.
Lors de l’établissement d’une première connexion de référence d’un CE à un concentrateur, le CE (par exemple le CE1) vérifie si le concentrateur 23 supporte la procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention. En variante, le CE peut utiliser une connexion dédiée pour vérifier si le concentrateur supporte ladite procédure. Cette connexion est ensuite clôturée et n’est donc pas utilisée pour transporter des données applicatives.
Par exemple, une première connexion de référence utilisant un protocole de la couche transport, par exemple QUIC, est établie entre le CE1 et le concentrateur 23.
Selon un mode de réalisation particulier, le CE peut utiliser un nouveau paramètre de transport QUIC appelé ici « Customized_PSS », pour signaler que l’entité émettrice du paramètre (CE1 ou concentrateur 23 par exemple) supporte la procédure de sélection d’au moins une politique d’ordonnancement de paquets.
Par exemple, un paramètre « Customized_PSS » valorisé à « 0x1 » indique que la procédure de sélection d’au moins une politique d’ordonnancement de paquets est supportée par l’entité émettrice du paramètre, et un paramètre « Customized_PSS » valorisé à « 0x0 » (ou l’absence d’un tel paramètre) de transport indique que la procédure de sélection d’au moins une politique d’ordonnancement de paquets n’est pas supportée par l’entité émettrice (CE1 ou concentrateur 23 par exemple).
Si l’entité source (CE1 par exemple) reçoit le paramètre « Customized_PSS » valorisé à « 0x1 » en provenance de l’entité destinataire (concentrateur 23 par exemple), l’entité source peut envoyer à l’entité destinataire une liste de la ou des politiques d’ordonnancement de paquets supportées par l’entité source.
SI le protocole QUIC est utilisé sur la première connexion (dédiée ou de référence) établie entre l’entité source et l’entité destinataire, l’entité source peut utiliser une nouvelle trame QUIC, appelée ici trame QUIC PSS, pour informer l’entité destinataire de la ou des politiques d’ordonnancement de paquets supportée par l’entité source. L’entité destinataire peut conserver en mémoire la liste des PSS supportées par l’entité source, notamment pour la gestion du trafic retour.
L’entité destinataire peut envoyer à l’entité source une liste de la ou des politiques d’ordonnancement de paquets supportées par l’entité destinataire (notamment si l’entité source n’a pas communiqué à l’entité destinataire les PSS supportées par l’entité source), ou une sélection des politiques d’ordonnancement de paquets supportées par l’entité source et l’entité destinataire.
Par exemple, l’entité source reçoit une liste des PSS supportées par l’entité destinataire dans une trame QUIC PSS : PSS#1, …, PSS#i.
L’entité source peut notamment garder en mémoire la liste des PSS supportées par l’entité destinataire.
Par exemple, la transmission de l’entité destinataire vers l’entité source de la liste des PSS supportées par l’entité destinataire peut être mise en œuvre de façon régulière, par exemple toutes les 24h, pour rafraichir la liste des PSS conservée dans une mémoire de l’entité source.
On considère par la suite qu’au moins une PSS commune est supportée par l’entité source et l’entité destinataire. On suppose également que l’entité source et l’entité destinataire supportent également au moins un même mode d’application de la PSS.
Parmi les PSS supportées par l’entité source et l’entité destinataire, au moins une PSS est sélectionnée en tenant compte des caractéristiques d’une application associée aux données applicatives échangées entre l’entité source et l’entité destinataire. De telles caractéristiques peuvent inclure notamment des contraintes de l’application en question.
Au moins une connexion de référence, sur laquelle est mise en œuvre au moins une PSS sélectionnée, est établie entre l’entité source et l’entité destinataire (par exemple au démarrage ou redémarrage de l’entité source, ou lors de l’établissement de la communication caractéristique de l’application utilisée – par exemple au moment de l’établissement d’une connexion (applicative) HTTP à partir d’un terminal connecté au réseau local dans lequel sont déployés un ou plusieurs CE selon l’invention, également appelée connexion applicative).
Une telle connexion de référence repose par exemple sur le protocole QUIC.
Dans un mode de réalisation, la sélection d’au moins une PSS est effectuée préalablement à l’établissement de la connexion de référence. Par exemple, l’entité source sélectionne une PSS à activer pour la connexion de référence (associée à une application ou un groupe d’applications de même type) et communique l’identifiant PSS à l’entité destinataire. L’entité source et l’entité destinataire activent alors la même PSS pour cette connexion de référence. Dans un autre mode de réalisation, la sélection d’au moins une PSS est effectuée simultanément à l’établissement de la connexion de référence. On note que l’application d’une même PSS peut être effectuée pour une ou plusieurs connexions de référence établies entre l’entité source et l’entité destinataire.
En particulier, la connexion de référence est acceptée par l’entité destinataire si la PSS est supportée par l’entité destinataire. Cette étape de vérification de capacité (à supporter ladite PSS) n’est pas requise si la négociation de la PSS est effectuée au préalable entre l’entité source et l’entité destinataire, et non lors de l’établissement de la connexion de référence. La demande d’établissement de connexion de référence est refusée si la PSS indiquée par l’entité source n’est pas supportée par l’entité destinataire ou si le paramètre « Customized_PSS » valorisé à un « 0x1 » n’a pas été échangé entre l’entité source et l’entité destinataire.
L’entité source, par exemple le CE, peut notamment établir une connexion de référence comprenant plusieurs sous-connexions (également appelée connexion multi-chemins) avec l’entité destinataire (par exemple le concentrateur). Comme déjà indiqué, l’établissement de sous-connexions permet de pouvoir basculer/rediriger le trafic vers un chemin ou un autre, par exemple en fonction des objectifs de QoE fixés par une application ou selon l’évolution des conditions de transmission (dégradation du temps de transit par exemple).
Pour ce faire, pour une connexion de référence pour laquelle au moins une PSS a été sélectionnée, l’entité source négocie avec le concentrateur le mode d’application de la PSS à mettre en place pour les flux applicatifs transportés sur cette connexion de référence. Éventuellement, la négociation est effectuée lors de l’établissement de la communication caractéristique de l’application utilisée entre le terminal et le serveur, également appelée connexion applicative. Les paquets de données transmis sur la connexion de référence sont alors répartis entre les différents chemins en fonction du mode d’application de la PSS activée et selon les conditions de qualité de service et de QoE observées par l’entité source.
5.2.5 Variantes
Dans un mode de réalisation particulier, des informations de classification de trafic peuvent être fournies à l’entité source et/ou à l’entité destinataire pour associer un type d’application à une politique d’ordonnancement de paquets qui permettrait de satisfaire, par exemple, les exigences de qualité liées à ce type application.
Autrement dit, l’entité source et/ou l’entité destinataire peuvent associer une connexion « applicative » (qui transporte les données applicatives) à une connexion de référence sur laquelle est mise en œuvre une PSS sélectionnée pour satisfaire les exigences de qualité liées à ce type d’application.
Ainsi, l’implémentation d’un mode veille permet de réduire la consommation de la batterie et l’activation du mode veille se fait automatiquement lorsqu’aucune instruction n’est reçue pendant une durée prédéfinie. En outre, le mode veille peut être aisément désactivé afin d’augmenter la réactivité du contrôleur lors d’une installation.
Selon un mode de réalisation particulier, le procédé comporte en outre de réactiver le mode standard si le contrôleur est remis sous tension après une extinction lorsque le mode veille est activé.
Ainsi, il est possible de réactiver le mode standard lorsque le dispositif de pilotage est introuvable.
Selon un mode de réalisation particulier, le procédé comporte en outre de bloquer l’activation du mode veille si le mode standard est réactivé après l’activation du mode veille.
Selon un mode de réalisation particulier, le procédé comporte en outre de bloquer l’activation du mode veille lorsqu’un nombre d’instructions reçues après un enregistrement de positions extrêmes de l’élément occultant atteint le nombre prédéfini.
Ainsi, l’activation du mode veille est empêchée après une installation, ce qui permet d’éviter un dysfonctionnement à l’utilisation, par exemple lorsqu’une phase de stockage et/ou de livraison est inférieure à la durée prédéfinie.
Selon un mode de réalisation particulier, l’instruction de sortie du mode veille comporte une trame comportant un préambule suivi d’un champ de données, le préambule étant d’une durée supérieure à la durée prédéfinie.
L’invention concerne également un procédé d’arrêt d’un mode veille, le procédé étant implémenté par un dispositif de pilotage configuré pour émettre des instructions à un contrôleur d’un moteur destiné à entraîner en montée et en descente un élément occultant, les instructions pouvant être des instructions d’un premier type et des instructions d’un second type, le préambule de chaque trame d’une instruction du premier type étant de durée inférieure au préambule de chaque trame d’une instruction du second type. Le procédé comporte : émettre une instruction du second type lorsque l’instruction est une instruction de sortie du mode de veille ; et émettre une instruction du premier type sinon.
L’invention concerne également un contrôleur d’un moteur destiné à entraîner en montée et en descente un élément occultant, le contrôleur étant configuré pour recevoir des instructions en provenance d’un dispositif de pilotage et pour appliquer des commandes au moteur, le contrôleur comportant une interface radio fonctionnant dans deux modes de communication, dits mode standard et mode veille, pouvant être activés alternativement, le contrôleur commandant à l’interface radio, pour chaque mode de communication, une détection périodique de réception d’instructions, le contrôleur et l’interface radio restant au repos entre deux détections lorsqu’aucune instruction n’est reçue. La périodicité de détection du mode standard est inférieure à la périodicité de détection du mode veille, et le contrôleur comporte des moyens pour : activer le mode standard lors d’une initialisation du contrôleur ; activer le mode veille si le contrôleur est associé à au moins un dispositif de pilotage et lorsqu’aucune instruction n’est reçue pendant une durée prédéfinie et qu’un nombre d’instructions reçues après un enregistrement de positions extrêmes de l’élément occultant est inférieur à un nombre prédéfini ; et réactiver le mode standard si une instruction de sortie du mode veille est reçue lorsque le mode veille est activé.
L’invention concerne également un système comportant un dispositif d’obturation et comportant un tel contrôleur dans l’un quelconque de ses modes de réalisation.
L’invention concerne également un dispositif de pilotage configuré pour émettre des instructions à un contrôleur d’un moteur destiné à entraîner en montée et en descente un élément occultant, le dispositif de pilotage comportant des moyens pour émettre des instructions d’un premier type et des instructions d’un second type, le préambule de chaque trame d’une instruction du premier type étant de durée inférieure au préambule de chaque trame d’une instruction du second type, le dispositif de pilotage comportant des moyens pour : émettre une instruction du second type lorsque l’instruction est une instruction de sortie du mode de veille ; et émettre une instruction du premier type sinon.
L’invention concerne également un programme d’ordinateur pouvant être stocké sur un support et/ou téléchargé d’un réseau de communication, afin d’être lu par un processeur. Ce programme d’ordinateur comprend des instructions pour implémenter le procédé mentionné ci-dessus dans l’un quelconque de ses modes de réalisation, lorsque ledit programme d’ordinateur est exécuté par le processeur.
illustre schématiquement un dispositif d'obturation motorisé d'une baie comportant un moteur contrôlé par un contrôleur ;
illustre schématiquement un exemple d’architecture matérielle du contrôleur ;
La illustre schématiquement des étapes d’un algorithme d’activation et de désactivation du mode veille du contrôleur 200, implémenté par le contrôleur 200.
Dans une première étape 300, le mode standard est activé lors d’une initialisation du contrôleur 200. C’est le cas par exemple lorsque le contrôleur 200 est mis sous tension lors d’un branchement du contrôleur 200 à la batterie. Si le contrôleur 200 est déjà initialisé et si le mode standard est déjà activé, alors le mode standard reste activé.
Dans une étape 302 suivante, le contrôleur 200 détermine si au moins un dispositif de pilotage 120 est associé au contrôleur 200. Un dispositif de pilotage 120 est associé au contrôleur 200 lorsque le contrôleur 200 est capable d’identifier qu’une instruction reçue en provenance du dispositif de pilotage 120 lui est adressée. Si c’est le cas, une étape 304 est effectuée. Sinon, le contrôleur 200 retourne à l’étape 300.
A l’étape 304, le contrôleur 200 initialise une variable n à zéro. La variable n est utilisée pour compter un nombre d’instructions reçues par le contrôleur 200.
Dans une étape 306 suivante, le contrôleur 200 initialise un compteur de temps C à un instant initial, par exemple t 0 . L’instant initial, lorsque l’étape 306 est réalisée pour la première fois par le contrôleur 200, correspond à un instant d’association entre le au moins un dispositif de pilotage 120 et le contrôleur 200. L’instant initial, lorsque l’étape 306 est réalisée après une étape 318, correspond à un instant d’un arrêt précédent du moteur 103.
Dans une étape 308 suivante, le contrôleur 200 détermine si le compteur de temps C est supérieur à une durée prédéfinie Δt . La durée prédéfinie Δt est très supérieure à la périodicité de détection du mode veille et est par exemple comprise entre 24h et 72h. Si c’est le cas, le procédé se poursuit à une étape A, décrite ci-après dans la . Sinon, le contrôleur 200 passe à une étape 310.
A l’étape 310, le contrôleur 200 détermine si des positions d’arrêt sont mémorisées par le contrôleur 200. Une position d’arrêt est une position extrême que l’élément occultant 106 peut atteindre lorsque l’élément occultant 106 monte ou descend. Il existe deux positions d’arrêt : la position basse et la position haute. Si c’est le cas, une étape 312 est effectuée. Sinon, une étape 318 et effectuée.
A l’étape 312, le contrôleur 200 détermine si une instruction est reçue en provenance d’un dispositif de pilotage 120 associé. Si c’est le cas, une étape 314 est effectuée ; sinon, l’étape 318 est effectuée.
A l’étape 314, le contrôleur 200 incrémente la variable n . La variable n permet ainsi de déterminer le nombre d’instructions reçues par le contrôleur 200 à partir de l’association entre le au moins un dispositif de pilotage 120 et le contrôleur 200.