INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Avantageusement, selon une première variante de réalisation de l’invention qui est illustrée aux figures 3 et 4, l’accessoire de protection comprend uniquement deux volets, à savoir le premier volet 9 et le deuxième volet 10 qui sont saillants dans la première ouverture 14. Cette variante de réalisation est adaptée pour un appareillage électrique de protection D fixe selon la deuxième possibilité.
De préférence, la deuxième ouverture 15 est fermée par un obturateur 16.
Avantageusement, l’obturateur 16 permet de recouvrir au moins la deuxième ouverture 15 qui n’est pas utile, car l’appareillage électrique de protection D ne dispose dans ce cas pas d’une interface I de commande de la position.
Selon un autre possibilité et comme l’illustre la , l’obturateur 16 permet de recouvrir à la fois la deuxième ouverture 15 et l’entretoise de séparation 13.
L’obturateur 16 présente de préférence une forme essentiellement plane et rectangulaire. L’obturateur 16 peut être fixé au cadre 3 par des moyens de fixation par exemple du type par emboîtement ou par clippage.
De préférence et comme l’illustre la , la première longueur LV1 du premier volet 9 et la deuxième longueur LV2 du deuxième volet 10 sont égales à une longueur LO1 de la première ouverture 14.
De préférence, selon une deuxième variante de réalisation de l’invention, l’accessoire de protection comprend en outre au moins :
un troisième volet 17 configuré pour occulter partiellement la deuxième ouverture 15 dans une position initiale PI et étant monté mobile autour du premier axe de rotation A1 parallèle sur la première bordure 5 entre la position initiale PI et la position d’ouverture maximale,
un quatrième volet 18 configuré pour occulter partiellement la deuxième ouverture 15 dans une position initiale PI et étant monté mobile autour du deuxième axe de rotation A2 sur la deuxième bordure 6 entre la position initiale PI et la position d’ouverture maximale,
un troisième organe de rappel 19 configuré pour permettre le retour automatique de la position d’ouverture maximale vers la position initiale PI du troisième volet 17,
un quatrième organe de rappel 20 configuré pour permettre le retour automatique de la position d’ouverture maximale vers la position initiale PI du quatrième volet 18.
Avantageusement, selon la deuxième variante de réalisation de l’invention qui est illustrée aux figures 1, 2, 5 à 16, l’accessoire de protection comprend en tout quatre volets, à savoir le premier volet 9 et le deuxième volet 10 qui sont saillants dans la première ouverture 14 et le troisième volet 17 et le quatrième volet 18 qui sont saillants dans la deuxième ouverture 15. Cette variante de réalisation est adaptée pour un appareillage électrique de protection D débrochable selon la première possibilité.
Le troisième volet 17 et le quatrième volet 18 présentent par exemple chacun une forme essentiellement plane et rectangulaire. De préférence, le troisième volet 17 et le quatrième volet 18 comportent chacun une première face 29 qui est lisse et du côté de l’interface avant 26 et une deuxième face 30 qui est nervurée et du côté de l’interface de montage 27.
La largeur du troisième volet 17 et la largeur du quatrième volet 18 peuvent être égales ou différente respectivement de la largeur du premier volet 9 et de la largeur du deuxième volet 10.
La position initiale PI du troisième volet 17 correspond de préférence à une position du troisième volet 17 dans laquelle celui-ci occulte une portion de la deuxième ouverture 15 à proximité de la première bordure 5.
La position initiale PI du quatrième volet 18 correspond de préférence à une position du quatrième volet 18 dans laquelle celui-ci occulte une portion de la deuxième ouverture 15 à proximité de la deuxième bordure 6.
Comme évoqué précédemment, la notion de « dispositif applicatif » désigne aussi bien ici un dispositif matériel qu’un dispositif logiciel ou virtuel. Ainsi l’invention s’applique indifféremment à des dispositifs applicatifs logiciels ou virtuels et à des dispositif applicatifs matériels hébergeant des fonctions réseau. Lorsque les dispositifs applicatifs considérés sont des dispositifs matériels (par exemple des serveurs d’une infrastructure du réseau cœur CN), ils ont alors l’architecture matérielle d’un ordinateur 5, tel qu’illustrée à la . Cette architecture matérielle s’appuie sur un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communications avec d’autres entités, par exemple, d’autres entités du réseau cœur CN. Ces moyens COM de communication peuvent notamment s’appuyer sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles et notamment ici sur une interface de programmation applicative (API) utilisant le protocole HTTP/2 comme détaillé davantage ultérieurement. Lorsque les dispositifs applicatifs sont logiciels, ils sont eux-mêmes hébergés par un dispositif matériel ayant l’architecture matérielle de l’ordinateur 5, et peuvent alors s’appuyer sur les moyens matériels de l’ordinateur 5 évoqués précédemment (PROC, MEM, ROM, NVM, COM). Dans la suite de la description, par souci de simplification, on fait référence aux moyens PROC, MEM, ROM, NVM, COM du dispositif applicatif, que celui-ci soit matériel ou logiciel.
Conformément au standard 3GPP, chaque dispositif applicatif 3 hébergeant une fonction réseau NF du réseau cœur CN est configuré pour enregistrer auprès du dispositif NRF 2 son profil NFProfile. Ce profil comprend une pluralité d’attributs caractérisant l’état opérationnel de la fonction NF (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. son identifiant, son nom de domaine pleinement qualifié ou FQDN (pour « Fully Qualified Domain Name » en anglais)), le type de fonction NF correspondant, comment elle peut être jointe, etc.), les services qu’elle offre, les ressources qu’elle gère, etc. Les attributs peuvent être définis au niveau de la fonction NF et/ou de chaque service implémenté par celle-ci. Cet enregistrement est réalisé, comme décrit dans les documents 3GPP TS 23.502 et TS 29.510 en utilisant une API du service de gestion Nnrf_NFManagement, désignée dans la suite par API_MNG. L’interface API_MNG est ici l’API standardisée « Nnrf_NFManagement API » décrite en annexe A.2 du document 3GPP TS 29.510. Elle s’appuie sur le protocole HTTP/2 et comprend une pluralité d’opérations, parmi lesquelles les opérations RegisterNFInstance, UpdateNFInstance et DeregisterNFInstance qui peuvent être utilisées respectivement par les dispositifs applicatifs 3 pour enregistrer, mettre à jour et désenregistrer leur profil auprès du service de gestion Nnrf_NFManagement du dispositif NRF 2. L’API « Nnrf_NFManagement API » comprend également une opération Heart-Beat selon laquelle chaque fonction NF enregistrée auprès du dispositif NRF 2 doit contacter le dispositif NRF 2 périodiquement (selon une période dite de « Heart Beat ») pour lui montrer qu’elle est toujours opérationnelle ; lorsque le dispositif NRF 2 détecte qu’une fonction NF n’a pas mis à jour son profil depuis un intervalle de temps configurable supérieur à la période de Heart-Beat, il change le statut (c’est-à-dire l’état) de la fonction NF dans son profil de « Registered » (état enregistré) à « Suspended » (état suspendu).
Dans le mode de réalisation décrit ici, les profils des dispositifs applicatifs 3 hébergeant les fonctions NF1, NF2, …, référencés par NFProfile(NF1), NFProfile(NF2), …, sont stockés dans une couche de persistance 6 du service de gestion Nnrf_NFManagement du dispositif NRF 2, par exemple dans une base de données. Une telle couche de persistance 6 est située dans un espace mémoire de la mémoire NVM non volatile du dispositif NRF 2, et est propre au service de gestion Nnrf_NFManagement. Par couche de persistance, on entend une mémoire fiable et persistant au-delà de la fin du processus à l’origine des données (dans notre exemple de l’enregistrement des fonctions NF ou de la modification de leurs profils). Dans le mode de réalisation décrit ici, on suppose que la persistance de la couche de persistance 6 s’étend sur une longue durée, potentiellement non limitée (c’est-à-dire que les données stockées dans cette couche de persistance perdurent ou survivent dans le temps potentiellement sur une durée non bornée).
La couche de persistance 6 (et incidemment la base de données contenant les profils) est accessible en lecture et en écriture par le service de gestion Nnrf_NFManagement du dispositif NRF 2 uniquement (autrement dit, elle n’est pas directement accessible par des services autres que le service de gestion Nnrf_NFManagement). Le service de découverte Nnrf_NFDiscovery du dispositif NRF 2 peut accéder (en lecture uniquement) au contenu de la couche de persistance 6 (et plus particulièrement de la base de données contenant les profils) par l’intermédiaire du service de gestion Nnrf_NFManagement avec lequel il communique via l’interface API_MNG du service de gestion Nnrf_NFManagement. Plus spécifiquement, le service de découverte Nnrf_NFDiscovery peut accéder par l’intermédiaire de l’interface API_MNG et du service de gestion Nnrf_NFManagement à tout ou partie des attributs des profils stockés dans la couche de persistance 6 en utilisant les opérations GetNFInstances, GetNFInstance, CreateSubscription, UpdateSubscription, onNFStatusEvent, comme évoqué plus en détail ultérieurement.
Lorsqu’un dispositif applicatif 4 hébergeant une fonction NF « consumer » souhaite accéder à (i.e. consommer) un service offert par un dispositif applicatif 3 hébergeant une fonction NF « producer », conformément au standard 3GPP, le dispositif applicatif 4 sollicite le dispositif NRF 2, et plus particulièrement son service de découverte Nnrf_NFDiscovery, en lui envoyant une requête afin d’obtenir une liste de dispositifs applicatifs candidats répondant à un ou plusieurs critères de recherche. A cet effet, le dispositif applicatif 4 utilise une API, désignée ici par API_DISC, du service de découverte Nnrf_NFDiscovery. Cette API est l’API standardisée « Nnrf_NFDiscovery API » décrite en annexe A.3 du document 3GPP TS 29.510, qui s’appuie sur le protocole HTTP/2. Elle comprend notamment l’opération SearchNFInstances, qui permet au dispositif applicatif 4 d’indiquer au service de découverte Nnrf_NFDiscovery son ou ses critères de recherche (ex. type de fonction NF recherché, zone géographique, etc.). Il convient de noter que l’opération SearchNFInstances (requête au sens de l’invention) comporte deux paramètres d’entrée obligatoires, à savoir le type target-nf-type de la fonction NF recherchée (fonction réseau « producer ») et le type requester-nf-type de la fonction NF à l’origine de la requête (fonction NF implémentée par le dispositif applicatif 4). D’autres paramètres d’entrée optionnels peuvent être ajoutés pour préciser davantage de critères de recherche et permettre ainsi au service de découverte Nnrf_NFDiscovery d’affiner le filtrage des fonctions NF « producer » candidates à fournir au dispositif applicatif 4 en réponse à sa requête.
Dans le mode de réalisation décrit ici, les différents services implémentés par le dispositif NRF 2, et en particulier les services de gestion Nnrf_NFManagement et de découverte Nnrf_NFDiscovery du dispositif NRF 2 sont implémentés sous la forme de micro-services. Le micro-service implémentant le service de gestion Nnrf_NFManagement est désigné ici par MS_MNG, tandis que le micro-service implémentant le service de découverte Nnrf_NFDiscovery est désigné par MS_DISC. Le micro-service MS_MNG, et a fortiori le support sur lequel est enregistré ce micro-service MS_MNG (typiquement un espace mémoire de la mémoire non volatile NVM du dispositif applicatif NRF 2), sont chacun des entités configurées pour mettre en œuvre le service de gestion Nnrf_NFManagement du dispositif NRF 2. Le micro-service MS_DISC, et a fortiori le support sur lequel est enregistré ce micro-service MS_DISC (typiquement un espace mémoire de la mémoire non volatile NVM du dispositif applicatif NRF 2), sont chacun des entités configurées pour mettre en œuvre le service de découverte Nnrf_NFDiscovery du dispositif NRF 2, conformes à l’invention.
Dans la suite de la description, seuls les modules du micro-service MS_DISC sont décrits en détail ; il est toutefois évident pour l’homme du métier que le support sur lequel est enregistré le micro-service MS_DISC dispose des mêmes modules, et donc ce qui caractérise le micro-service MS_DISC caractérise également le support sur lequel il est enregistré. Par ailleurs, les services de gestion Nnrf_NFManagement et de découverte Nnrf_NFDiscovery étant implémentés sous la forme des micro-services MS_MNG et MS_DISC, il est considéré dans la suite comme équivalent de faire référence au service de gestion Nnrf_NFManagement, respectivement au service de découverte Nnrf_NFDiscovery, et au micro-service MS_MNG, respectivement au micro-service MS_DISC.
Conformément à l’invention et comme illustré sur la , le micro-service MS_DISC comprend, sous la forme d’instructions de programme d’ordinateur exécutable par le processeur PROC du dispositif NRF 2, les modules logiciels suivants : un module 7 de gestion (aussi désigné ici par nnrf-nfmanagement-agent ) configuré pour obtenir via l’interface API_MNG du micro-service MS_MNG du dispositif NRF 2, des données gérées par le micro-service MS_MNG, relatives à au moins une fonction NF « producer » NF1, NF2, … du réseau cœur CN et contenues dans la couche de persistance 6. Le module 7 de gestion est configuré pour mémoriser les données obtenues dans un cache 8 dit primaire (ou « backend »), propre au micro-service MS_DISC, et accessible que par ce dernier. Le cache primaire 8 est ici un cache volatile, initialement vide au démarrage du dispositif NRF 2, qui se caractérise par une faible latence et un débit élevé, autrement dit par sa rapidité d’exécution et d’accès, notamment par rapport à la couche de persistance 6 du micro-service MS_MNG. Il convient de noter que, dans le mode de réalisation décrit ici, on privilégie surtout pour le choix du cache 8 sa rapidité d’accès (c’est-à-dire sa faible ou très faible latence) et sa bande passante élevée (versus une éventuelle persistance comme pour la couche de persistance 6) ; un module 9 de mise à jour (aussi désigné ici par nfprofile-notifications-receiver ) configuré pour, suite à une modification d’une des données gérées par le micro-service MS_MNG et contenues dans la couche de persistance 6, mettre à jour le cache primaire 8 pour refléter cette modification. Le module 9 de mise à jour utilise, pour être informé des modifications des données gérées par le micro-service MS_MNG, l’interface API_MNG, comme détaillé davantage ultérieurement ; et un module 10 de traitement, configuré pour accéder en lecture seulement au cache primaire 8 et utiliser au moins les données mémorisées dans le cache primaire 8 lorsque le micro-service MS_DISC est sollicité pour exécuter une opération du service Nnrf_NFDiscovery. Ainsi l’exécution de l’opération en question se fait sans adhérence avec la couche de persistance 6 du micro-service MS_MNG. Une telle opération est par exemple la réception d’un dispositif applicatif 4 implémentant une fonction NF « consumer » d’une requête de découverte SearchNFInstances, l’élaboration d’une réponse à cette requête de découverte en interrogeant le cache primaire 8 et la fourniture de la réponse au dispositif applicatif 4 à l’origine de la requête.
Dans le mode de réalisation décrit ici, les données obtenues du micro-service MS_MNG et mémorisées par le module 7 de gestion sont des attributs des profils NFProfile des fonctions NF « producer » NF1, NF2, …, gérées par le micro-service MS_MNG du dispositif NRF 2. Le module 7 de gestion peut être configuré pour obtenir l’intégralité de chaque profil NFProfile contenu dans la couche de persistance 6 du micro-service MS_MNG ou seulement une partie d’entre eux (i.e. certains attributs seulement).
La illustre notamment les relations entre les différents éléments du système 1. Nous allons en référence à cette figure , détailler le fonctionnement des modules du micro-service MS_DISC et les étapes du procédé d’exécution selon l’invention telles que mises en œuvre par ces modules. Comme mentionné précédemment, dans le mode de réalisation décrit ici, le micro-service MS_DISC et les éléments du système 1 communiquent en utilisant les opérations d’API (API_MNG et API_DISC) standardisées, et décrites en annexes A.2 et A.3 du document 3GPP TS 29.510. L’homme du métier est invité à se référer à ces annexes pour une description détaillée de ces opérations et des API en question.
Comme évoqué précédemment, on suppose ici que les dispositifs applicatifs 3 hébergeant des fonctions NF « producer » NF1, NF2, … ont enregistré leurs profils NFProfile respectifs auprès du dispositif NRF 2, via l’interface API_MNG du micro-service MS_MNG, et notamment l’opération RegisterNFInstance (étape E10). Ces profils sont stockés dans la couche de persistance 6 du micro-service MS_MNG, dans la base de données évoquée précédemment. Ils peuvent être mis à jour par les dispositifs applicatifs 3, en cas de modification d’un ou de plusieurs attributs en utilisant l’opération UpdateNFInstance de l’interface MS_MNG, ou être supprimés, par exemple en cas d’extinction d’une instance de fonction NF, au moyen de l’opération DeregisterNFInstance (étape E10b). Comme évoqué précédemment, le dispositif NRF 2, et plus particulièrement le micro-service MS_MNG, peut également mettre à jour un profil d’un dispositif applicatif 3 pour basculer son état de « Registered » à « Suspended » en cas d’inactivité de la fonction NF hébergée par ce dispositif applicatif 3.
Au démarrage du dispositif NRF 2, le cache primaire 8 volatile du micro-service MS_DISC est vide. Le module 7 de gestion du micro-service MS_DISC est chargé d’initialiser le cache primaire 8 et de mettre en place le processus de mise à jour du cache primaire 8 par le module 9 de mise à jour.
Plus particulièrement, le module 7 de gestion copie dans un premier temps ici tous les profils NFProfile des fonctions NF NF1, NF2, …, contenus dans la couche de persistance 6 du micro-service MS_MNG (étape E20). Il utilise à cet effet les opérations GetNFInstances et GetNFInstance de l’interface API_MNG. L’opération GetNFInstances permet au module 7 de gestion d’interroger le micro-service MS_MNG pour obtenir la liste des identifiants (des URI ici pour « Uniform Resource Identifier » en anglais) des profils de fonctions NF contenus dans la couche de persistance 6 du micro-service MS_MNG. Pour chaque URI de la liste d’URI obtenue du micro-service MS_MNG, le module 7 de gestion envoie une requête au micro-service MS_MNG, en utilisant l’opération GetNFInstance afin d’obtenir le profil NFProfile de la fonction NF associée géré par le micro-service MS_MNG et stocké dans la couche de persistance 6. Cette opération peut être réalisée en parallèle pour les différentes URI de la liste d’URI obtenue pour des raisons de performance.
Les profils de fonctions NF ainsi obtenus par le module 7 de gestion sont alors mémorisés par ce dernier dans le cache primaire 8 (étape E30).
Dans le même temps, le module 7 de gestion souscrit auprès du micro-service MS_MNG à la notification du module 9 de mise à jour de toute modification (création de profils, mise à jour d’attributs, suspension de fonction NF ou suppression de profils) affectant les profils de fonctions NF gérés par le micro-service MS_MNG (étape E40).
En variante, il peut limiter la notification à certains événements particuliers, par exemple aux modifications de certains attributs seulement des profils, typiquement lorsque le module 7 de gestion n’a répliqué qu’une partie des profils dans le cache primaire 8, aux attributs qu’il a répliqués ou souhaite répliquer.
Le principal défaut des systèmes de détection d’obstacle réalisés à l’aide d’un radar concerne les cas de vie où l’assiette (ou position) du véhicule est différente de celle utilisée pour définir le volume de référence d’ouverture du volet et la distance d’arrêt du volet par rapport aux obstacles détectés dans le volume de référence. Par exemple, lorsque le véhicule est très peu chargé, ou, à l’inverse, très chargé, le volume réel d’ouverture du volet n’est pas positionné au même endroit que le volume de référence, car l’assiette, ou l’assisse, du véhicule va être modifiée par le chargement. De ce fait, la distance entre l’obstacle et le volume d’ouverture réel du volet peut être plus faible que celle obtenue par rapport au volume de référence, ce qui peut produire un choc du volet avec l’obstacle et donc rendre inutile le système de détection par radar.
Il existe donc un réel besoin d’un procédé et d’un dispositif d’ouverture automatique d’un ouvrant qui prenne en compte les différentes modalités d’utilisation du véhicule pour garantir une ouverture sans choc.
Description de l’invention Pour résoudre un ou plusieurs des inconvénients cités précédemment, selon un premier mode de réalisation, un procédé d’ouverture motorisée automatique d’un ouvrant arrière d’un véhicule automobile comprend les étapes de : détermination du volume d’ouverture de l’ouvrant ; détection d’un obstacle éventuel à l’intérieur du volume d’ouverture de l’ouvrant ; ouverture de l’ouvrant, complète si aucun obstacle n’a été détecté, ou incomplète jusqu’à une position de sécurité évitant le contact avec l’obstacle détecté sinon, et, en outre la détermination du volume d’ouverture est fonction de l’assiette du véhicule au moment de l’ouverture.
Ainsi, la détection d’obstacle est fiabilisée.
Des caractéristiques ou des modes de réalisation particuliers, utilisables seuls ou en combinaison sont : la détermination du volume d’ouverture utilise un volume d’ouverture de référence associé à une assiette de référence sur lequel est appliquée une transformation géométrique basée sur l’évolution de l’assiette entre l’assiette de référence et l’assiette du véhicule au moment de l’ouverture ; le volume d’ouverture se définit par un volume de débattement et une position du volume de débattement dans un référentiel lié au véhicule, et la transformation géométrique s’applique à la position ; et/ou l’évolution de l’assiette entre l’assiette de référence et l’assiette du véhicule au moment de l’ouverture étant définie par un axe de rotation et un angle dans le référentiel, la transformation géométrique correspond à une rotation de même angle autour de l’axe.
Dans un deuxième mode de réalisation, un dispositif d’ouverture motorisée automatique d’un ouvrant arrière d’un véhicule automobile comprend : un détecteur d’obstacle adapté pour détecter un obstacle à l’intérieur du volume d’ouverture de l’ouvrant ; des moyens d’ouverture motorisés de l’ouvrant ; et un contrôleur d’ouverture connecté au détecteur d’obstacle et aux moyens d’ouverture et adapté pour envoyer un signal d’ouverture complète si aucun obstacle n’a été détecté par le détecteur d’obstacle, ou un signal d’ouverture incomplète jusqu’à une position de sécurité évitant le contact avec l’obstacle détecté sinon ; des moyens de détermination de l’assiette du véhicule connectés au contrôleur d’ouverture et au détecteur d’obstacle, le dispositif étant adapté pour déterminer le volume d’ouverture en fonction de l’assiette du véhicule au moment de l’ouverture.
Brève description des figures L’invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d’exemple, et en référence aux figures en annexe dans lesquelles : représente une vue de côté d’un véhicule comprenant un dispositif d’ouverture selon un mode de réalisation ; représente un ordinogramme d’un procédé d’ouverture selon un mode de réalisation ; représente le véhicule de la dans une configuration où son coffre est chargé d’objets ; et représente le véhicule de la dans une configuration où son coffre est allégé.
Modes de réalisation Les modes de réalisation présentés ci-après font référence à un véhicule automobile, une voiture. Cependant, l’homme du métier comprend que ceux-ci sont également utilisables avec d’autres types de véhicule tels que les camionnettes, les vans, etc.