INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon une troisième étape 203 du procédé selon l’invention, le dispositif 100 selon l’invention provoque l’immobilisation du véhicule dès la prochaine extinction du contact d’allumage s’il établit qu’aucun défaut engendrant une immobilisation du véhicule n’est répertorié, et ce, tant que des données caractérisant l’authentification d’au moins un conducteur autorisé ne sont pas générées. En d’autres termes, le dispositif 100 selon l’invention contrôle dans un premier temps qu’aucun défaut n’engendrant une immobilisation du véhicule 1 n’est répertorié, en interagissant pour ce faire, par exemple, avec le système de diagnostic embarqué (i.e. OBD) du véhicule 1. Et s’il établit que tel est le cas, il provoque alors l’immobilisation du véhicule dès la prochaine extinction du contact d’allumage, en interagissant pour ce faire avec le système de gestion d’accès et de démarrage 5, et ce, tant que des données caractérisant l’authentification d’un conducteur autorisé ne sont pas générées, ce qu’il détermine en interagissant avec l’interface homme-machine 3 du véhicule 1. En effet, selon l’invention, un conducteur autorisé du véhicule a la possibilité de s’authentifier, par exemple en saisissant un code d’identification au moyen d’un écran tactile ou de tout autre appareillage de saisie traditionnel (e.g. clavier, joystick, pavé tactile) qui fait partie intégrante de l’interface homme-machine 3. Alternativement ou cumulativement, un conducteur autorisé peut s’authentifier en réalisant une combinaison d’actions avec les pédales et/ou au moins un organe d’activation d’un équipement d’éclairage et/ou de signalisation du véhicule 1 ou, selon encore une autre alternative, en vérifiant une ou plusieurs de ses empreintes digitales au moyen du lecteur d’empreintes digitales de l’interface homme-machine 3. Et lorsque de tels moyens d’authentification sont utilisés et que le conducteur est authentifié en tant que conducteur autorisé, des données caractérisant l’authentification d’un conducteur autorisé sont générées. En revanche, tant qu’un conducteur autorisé ne s’est pas authentifié, de telles données ne sont pas générées et, dans ce cas, le dispositif 100 selon l’invention provoque alors l’immobilisation du véhicule 1 dès la prochaine extinction du contact d’allumage. C’est ainsi que le dispositif 100 selon l’invention assure avantageusement la protection antivol du véhicule en considérant dans un premier temps la variation de localisation de celui-ci entre l’extinction du contact d’allumage et sa prochaine activation. Il prémunit donc contre ces vols de véhicules qui consistent à déplacer le véhicule sans pour autant le démarrer.
Au contraire, lorsqu’il a établi au cours de la deuxième étape 202 du procédé selon l’invention que la condition n’est pas remplie, ce qui signifie que le véhicule 1 n’a pas été déplacé entre la dernière extinction du contact d’allumage et son activation, le dispositif 100 selon l’invention procède alors en réalisant les étapes du procédé selon l’invention décrites ci-dessous.
Selon une quatrième étape 204 du procédé selon l’invention, le dispositif 100 selon l’invention détermine des données caractérisant le comportement de conduite du conducteur courant du véhicule. De manière avantageuse, ces données contiennent des données caractérisant la vitesse du véhicule au passage d’au moins un dos-d’âne, des données caractérisant la durée d’un intervalle de temps s’écoulant entre les réalisations de deux changements de rapport de boite de vitesse ou l’amplitude d’une pression exercée sur la pédale d’accélérateur du véhicule, des données caractérisant la durée d’un intervalle de temps s’écoulant entre l’activation d’un équipement de signalisation du véhicule et un changement de direction, des données caractérisant la durée d’un intervalle de temps s’écoulant entre l’activation d’un équipement de signalisation du véhicule et un changement de l’orientation du regard du conducteur, des données caractérisant l’orientation du regard du conducteur avant la réalisation d’un changement de voie de circulation et des données caractérisant la durée d’un intervalle de temps s’écoulant entre l’ouverture ou la fermeture d’une portière d’accès au poste de conduite du véhicule et l’allumage ou l’extinction du contact d’allumage. Et pour déterminer de telles données, le dispositif 100 selon l’invention interagit avec le système d’aide à la conduite 2, avec l’interface homme-machine 3, avec l’appareillage de surveillance du conducteur 4, avec le système de gestion d’accès et de démarrage 5 et avec le système de navigation 6. Ainsi, au terme de cette étape, le dispositif 100 selon l’invention a avantageusement établi ce que l’on peut appeler une sorte de signature de conduite du conducteur courant du véhicule.
Ensuite, selon une cinquième étape 205 du procédé selon l’invention, le dispositif 100 selon l’invention obtient des données caractérisant le comportement de conduite d’au moins un conducteur habituel du véhicule qui ont été précédemment établie. En effet, comme il a déterminé au cours de l’étape précédente des données caractérisant le comportement de conduite du conducteur courant du véhicule, le dispositif 100 selon l’invention a procédé précédemment de manière identique pour déterminer les données caractérisant le comportement de conduite du conducteur habituel du véhicule lors d’un ou plusieurs trajets précédents effectués alors que le conducteur habituel (ou précédent) s’était valablement authentifié. Ces données caractérisant le comportement de conduite d’au moins un conducteur habituel du véhicule, qui contiennent la même variété de données que celles énoncées ci-dessus (vitesse de passages de dos-d’âne, dynamique d’accélération ou de passages de rapports de boite de vitesse, surveillance d’angles morts, habitude de démarrage ou d’extinction du contact d’allumage et d’ouverture ou de fermeture de la portière d’accès au poste de conduite), ont alors été enregistrées sur le support de stockage de données 102 en vue de leur utilisation ultérieure au cours de cette étape du procédé. Ainsi, au terme de cette cinquième étape 205, le dispositif 100 selon l’invention a obtenu des données qui établissent une signature de conduite du conducteur habituel (ou précédent) du véhicule 1.
Enfin, selon une sixième étape 206 du procédé selon l’invention, le dispositif 100 selon l’invention provoque l’immobilisation du véhicule dès la prochaine extinction du contact d’allumage s’il établit que les données caractérisant le comportement de conduite du conducteur courant du véhicule, celles déterminées au cours de la quatrième étape 204, diffèrent des données caractérisant le comportement de conduite d’au moins un conducteur habituel du véhicule, celles obtenues au cours de la cinquième étape 205, et ce, tant que des données caractérisant l’authentification d’au moins un conducteur autorisé ne sont pas générées. Et pour établir si des données caractérisant l’authentification d’au moins un conducteur autorisé sont générées, le dispositif 100 selon l’invention procède de la même manière que celle décrite plus haut en relation avec troisième étape 203 du procédé. Il provoque également l’immobilisation du véhicule en interagissant aussi avec le système de gestion d’accès et de démarrage 5, par exemple en transmettant des données caractérisant une commande d’immobilisation du véhicule dès la prochaine extinction du contact d’allumage, et le système de gestion d’accès et de démarrage 5 exécute la commande au moment opportun. C’est donc ainsi que le dispositif 100 selon l’invention assure avantageusement une protection antivol du véhicule en surveillant le comportement de conduite d’un conducteur courant et en déterminant si celui-ci est en adéquation avec le comportement de conduite d’au moins un conducteur autorisé du véhicule 1. Il prémunit donc contre ces vols de véhicules dans lesquels le voleur parvient à pirater aussi bien le système d’alarme que le système antidémarrage du véhicule.
Par conséquent, grâce au procédé et au dispositif selon l’invention décrits ci-dessus, une solution est fournie pour assurer une protection antivol d’un véhicule automobile même si le véhicule a pu être dérobé. Par ce biais, l’invention contribue pour minimiser les vols de véhicules automobiles qui ennuient les propriétaires et enrichissent les criminels.
ZONE DE CHARGEMENT D’UN VÉHICULE DOMAINE DE L’INVENTION La présente invention concerne la gestion d’un chargement dans des véhicules automobiles. La présente invention concerne, plus particulièrement, une zone de chargement faisant appel à un revêtement repliable.
L’objet abordé dans la partie arrière-plan technologique ne saurait être considéré comme constituant l’art antérieur du fait de sa simple mention dans la partie arrière-plan technologique. De la même façon, un problème évoqué dans la partie arrière-plan technologique ou associé à l’objet de la partie arrière-plan technologique ne saurait être considéré comme ayant été précédemment identifié dans l’art antérieur. L’objet dans la partie arrière-plan technologique représente tout au plus des approches différentes qui, en soi, pourront correspondre à des mises en œuvre de la technologie revendiquée.
Un coffre d’un véhicule, également connu sous le nom de zone de chargement, sert au rangement de bagages. La taille de la zone de chargement varie en fonction du type et de la taille des véhicules. À titre d’exemple, la zone de chargement est petite dans les voitures à hayon et grande dans les berlines ou les véhicules utilitaires sportifs (ou SUV pour Sport Utility Vehicle en anglais). On trouvera davantage de précisions en se reportant aux figures 1A et 1B qui illustrent une structure classique de zones de chargement dans des véhicules. Une surface de dessous d’une zone de chargement porte le nom de plancher de charge 102, autrement dit un panneau plat sur lequel on place les bagages. D’une façon générale, sous le plancher de charge 102, des objets tels que des pneus de secours et des crics sont rangés dans une zone prédéfinie. Le plancher de charge 102 recouvre ces objets et procure une surface plate pour la mise en place d’autres objets à transporter dans un véhicule.
En outre, la connexion de différentes applications à de tels systèmes de stockage de données est complexe. Dans de nombreux systèmes et applications existants, des tentatives ont été menées pour implémenter les algorithmes nécessaires au respect de la protection des données au niveau local, c’est-à-dire dans l’application respective, mais cette approche est très complexe. Les systèmes les plus récents reposent sur une gestion centralisée des données, dans lesquels la connexion des applications existantes est techniquement complexe. Dans ce cas, il est souvent nécessaire de réimplémenter complètement les applications existantes.
Le brevet US 10 572 684 B2 décrit un système dans lequel des données personnelles sont stockées dans une base de données distribuée, de préférence dans une chaîne de blocs. Le brevet EP 1 226 524 A2 décrit un système dans lequel des données peuvent être partagées entre des entités. Avec ce système, il est également possible de libérer des données pour le système de soins de santé, la sécurité des données étant garantie au moyen d’un chiffrement et de certificats appropriés.
Le brevet EP 2 656 274 B1 décrit un système d’échange ou de mise à disposition de documents. Le système implémente une restriction d’accès qui permet de protéger les données personnelles.
En se basant sur cette technique antérieure, la présente invention a pour objet de créer un système efficace et sécurisé pour le stockage des données. En particulier, le système doit permettre d’intégrer facilement et efficacement les applications existantes.
L’objet est atteint par un système et par un procédé comme décrits ci-après.
En particulier, l’objet est atteint par un système de stockage de données, en particulier de données personnelles, qui comprend : - une interface, en particulier une API REST ; - un module d’authentification ; - au moins une base de données cible pour le stockage des données ; - un module d’accès aux données, conçu pour a) recevoir des requêtes d’un ordinateur client au moyen de l’interface ; b) interroger des données de l’au moins une base de données cible en réponse à la requête reçue ; c) déterminer si l’ordinateur client et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et d) générer un ensemble de données de réponse pour répondre à la requête et le transmettre à l’ordinateur client, au moins certaines données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée.
L’une des idées de la présente invention est de stocker les données dans des bases de données cibles (centrales). Les bases de données cibles possèdent un module d’accès aux données (central) en amont qui gère l’accès aux données. Le module d’authentification régule quelle application peut accéder à quelles données. Grâce à l’invention, il n’est donc plus possible pour les applications d’accéder directement aux données. Au lieu de cela, l’accès doit se faire par l’intermédiaire du module d’accès aux données, qui reçoit des requêtes, par exemple d’ordinateurs clients, par l’intermédiaire d’une interface de préférence prédéterminée. Les données demandées peuvent alors être interrogées, au moins en partie à partir des bases de données cibles. Comme expliqué précédemment, il est vérifié si et dans quelle mesure il existe une autorisation d’accès aux données interrogées ou demandées. Une réglementation d’accès correspondante peut être basée sur les utilisateurs et/ou les rôles et/ou les dispositifs, dans laquelle des applications individuelles peuvent se voir attribuer des comptes utilisateur, comme il est d’usage dans les systèmes d’exploitation courants. Selon l’invention, d’autres concepts d’authentification connus sont également concevables.
Afin de répondre à la requête, le module d’accès aux données est conçu selon l’invention pour générer un ensemble de données de réponse et pour le transmettre à l’ordinateur client, les éléments de données individuels dans l’ensemble de données de réponse étant anonymisés. Une anonymisation correspondante peut être effectuée en ligne - c’est-à-dire au moment de l’interrogation - ou hors ligne - à un moment antérieur à la requête, par exemple lors de la collecte des données ou dans le cadre d’une routine de nuit.
Dans un mode de réalisation de l’invention, l’interface utilisée pour interroger et/ou fournir les données est une interface basée sur un REST (« transfert d’état représentationnel »). Une API REST correspondante peut être implémentée en tant que service Web et permet de traiter les requêtes de manière efficace.
Dans un mode de réalisation, le système comprend un pilote de base de données, installé en particulier sur au moins un ordinateur client, qui est configuré pour communiquer avec l’interface. Un pilote de base de données correspondant peut être un pilote JDBC. Des modules d’accès à des bases de données très sophistiqués existent sur de nombreux systèmes d’exploitation existants. Beaucoup de ces modules d’accès aux bases de données sont basés sur une ODBC. Ainsi, les applications sur les ordinateurs clients n’accèdent pas directement à la source de données, mais utilisent les pilotes ODBC installés pour implémenter l’accès approprié. Par rapport aux pilotes ODBC classiques, les API REST sont relativement récentes. L’invention envisage de fournir des pilotes ODBC, en particulier des pilotes JDBC, qui permettent aux applications de communiquer avec l’interface du système selon l’invention par l’intermédiaire de ces pilotes. Leur accès au système est donc clairement structuré et les applications existantes peuvent communiquer avec le système au moyen du pilote ODBC ou du pilote JDBC. Le coût d’une migration est donc extrêmement faible, en particulier si l’on considère que le système selon l’invention peut se comporter comme une base de données cible classique malgré les fonctionnalités supplémentaires des modules d’authentification et d’accès aux données.
Dans un mode de réalisation, le module d’accès aux bases de données comprend une unité d’analyse qui est conçue pour recevoir une chaîne de caractères avec une expression SQL et pour extraire les noms de champs de l’expression SQL. Les configurations peuvent tout de même être appliquées à l’interrogation SQL dans le module d’accès aux bases de données.
Il est possible d’implémenter le pilote de base de données de manière à ce qu’il traduise en grande partie automatiquement une requête SQL en une requête qui est transmise à l’interface. Par exemple, dans un mode de réalisation, la requête SQL est traduite en une requête qui est conforme à la norme REST. Dans un mode de réalisation, une unité d’analyse est utilisée à cet effet, qui, par exemple, extrait les noms de tables et/ou les noms de colonnes de l’expression SQL ou de la requête ODBC. Ces données peuvent être utilisées pour créer des requêtes de données spécifiques par l’intermédiaire de l’interface. Par exemple, une requête GET peut être envoyée par l’intermédiaire d’un HTTP, les noms de tables et/ou les noms de colonnes indiquant la ressource à interroger.
Dans un (autre) mode de réalisation, la requête SQL est encapsulée sous forme de chaîne de caractères dans une requête REST ou un appel REST qui est envoyé à l’interface.
Dans un mode de réalisation, le système comprend une base de données stockant une pluralité de rôles et/ou d’utilisateurs, des autorisations étant attribuées à chacun des rôles/utilisateurs. Il est possible d’utiliser le concept d’authentification des bases de données cibles individuelles afin de permettre au système, en particulier au module d’authentification, de gérer l’accès. Dans un mode de réalisation préféré, une base de données (distincte) est utilisée pour gérer les rôles et/ou les utilisateurs sur l’ensemble des bases de données cibles et pour leur attribuer des autorisations.
Le module d’authentification peut être conçu pour attribuer au moins une sélection de requêtes reçues au moyen de l’interface à au moins un rôle ou utilisateur de la base de données et, sur la base de l’autorisation attribuée, pour déterminer quelles données sont transmises en réponse à la requête respective au moyen de l’interface.
Dans un mode de réalisation, le module d’authentification peut décider de refuser complètement à un utilisateur ou à un rôle l’accès à certaines données. Dans un (autre) mode de réalisation, les autorisations affectent quelle base de données cible et/ou quels sous-composants (par exemple, tables et/ou vues) d’une base de données cible particulière sont interrogés. Selon l’invention, il est également possible de sélectionner au moins une fonction d’anonymisation, sur la base de l’autorisation, afin d’anonymiser des données spécifiques d’une base de données cible (en ligne).
40 : deuxième ligne
41 : deuxième ligne supérieure
42 : différence de valeurs
44, 46, 52, 56, 62, 68 : étapes
48, 50, 54, 58, 64, 66 : branches
CONTRÔLE DES COUPLES FOURNIS PAR DES MACHINES MOTRICES THERMIQUE ET ÉLECTRIQUE D’UN VÉHICULE TERRESTRE À FONCTION DE CONTRÔLE DE VITESSE Domaine technique de l’invention L’invention concerne les véhicules terrestres comprenant un groupe motopropulseur (ou GMP) hybride (et donc à machines motrices thermique(s) et électrique(s)) propre à fournir du couple à des roues motrices et au moins une fonction de contrôle de vitesse propre à contrôler leur vitesse, et plus précisément le contrôle de la fourniture de couple par la machine motrice thermique lorsque la machine motrice électrique fournit du couple.
- un groupe motopropulseur (ou GMP) comprenant des machine motrice thermique et machine motrice électrique propres à fournir à des roues motrices un couple qui est fonction d’une consigne de couple, et
- une fonction de contrôle de vitesse propre, en cas d’activation, à générer cette consigne de couple en fonction d’une consigne de vitesse devant être respectée dans des phases de contrôle de vitesse assisté.
Tout type de fonction de contrôle de vitesse est ici concerné, qu’il s’agisse d’une fonction de limitation de vitesse, d’une fonction de régulation de vitesse, d’une fonction de bridage de vitesse, ou d’une fonction de régulation de vitesse et de distance entre véhicules (ou ACC (« Adaptative Cruise Control » - régulateur de vitesse adaptatif)).
Comme le sait l’homme de l’art, pour des raisons de prestations, et notamment d’optimisation énergétique, d’acoustique, de vibrations, de performances, de stabilité et d’agrément de conduite, il faut gérer les activations et désactivations des différentes machines motrices d’un véhicule à GMP hybride au moment le plus opportun, y compris pendant les phases de contrôle de vitesse assisté.
Pour ce faire, sur un GMP hybride, il est important de pouvoir activer ou désactiver la machine motrice thermique au juste nécessaire quelle que soit la situation de vie rencontrée. Actuellement, il s’avère impossible de gérer finement, et de façon robuste, les demandes de (re)démarrage de la machine motrice thermique alors que la machine motrice électrique fournit du couple, pour les besoins de la fonction de contrôle de vitesse. En effet, en présence de la gestion actuelle les (re)démarrages de la machine motrice thermique sont soit trop précoces, ce qui induit une dégradation du bilan énergétique et des conforts acoustique et vibratoire, soit trop tardifs, ce qui induit une perte de vitesse du véhicule par rapport à la consigne de vitesse.
De préférence, au cours de l’étape de sélection du mode d’estimation de l’autonomie de roulage, une information relative au mode automatique et / ou une information relative au mode utilisateur est affichée à destination du conducteur. Le conducteur peut ainsi être informé des différents modes d’estimation possibles de l’autonomie, de la façon dont l’autonomie est estimée dans chaque mode et de ses possibilités de choix.
Bien sûr, en mode automatique comme en mode utilisateur, après chaque estimation, l’autonomie est affichée, mise à disposition du conducteur.
Le procédé selon l’invention décrit ci-dessus peut être mise en œuvre à l’aide d’un système d’estimation caractérisé en ce qu’il comprend : - un premier moyen d’interface Homme-Machine (ou dispositif IHM) configuré pour sélectionner manuellement un mode d’estimation parmi un mode automatique et un mode utilisateur, - un deuxième moyen IHM adapté pour fournir manuellement une consommation moyenne utilisateur - un moyen de calcul configuré pour mettre en œuvre un procédé tel que décrit ci-dessus pour l’estimation de l’autonomie de roulage du véhicule selon le mode d’estimation sélectionné et - un moyen d’affichage agencé pour afficher à chaque instant l’autonomie estimée selon le mode d’estimation sélectionné.
Le système selon l’invention peut être de manière classique intégré au système informatique (ou ordinateur de bord) du véhicule qui comprend notamment : - des moyens de calcul comprenant au moins une mémoire de données pour mémoriser des paramètres de calcul (comme par exemple la consommation moyenne de référence), au moins une mémoire de programme configurée pour mémoriser un programme comprenant une pluralité de lignes de code exécutable définissant les étapes d’un procédé, et un microprocesseur pour exécuter les lignes de codes, - un écran servant de moyen d’affichage d’information à destination du conducteur, et éventuellement d’interface IHM si l’écran est tactile ; sur l’écran peuvent être affichées successivement des pages ; sur chaque page peuvent être prévues des zones d’information et / ou des zones (ou boutons tactiles) susceptibles d’être sélectionnées ou modifiées pour permettre au conducteur de transmettre une instruction ou une donnée au moyen de calcul de l’ordinateur de bord, - des dispositifs d’IHM tels que des boutons mécaniques de commande.
Dans le système d’estimation selon l’invention, le premier moyen d’interface peut être également configuré pour afficher une information relative au mode automatique et / ou une information relative au mode utilisateur à destination du conducteur.