Brevet FR3141539A1 — publié le 20240503

L’invention concerne un procédé de gestion de fonctions d’un véhicule automobile pour un utilisateur dudit véhicule, comprenant notamment les étapes de paramétrage (E4) du calculateur secondaire (20) avec la configuration déterminée, de détection (E5) d’au moins un évènement (EVENT) correspondant à une balise de déclenchement ou à un message reçu du calculateur principal (10), d’obtention (E6), dans la zone mémoire (21) dudit calculateur secondaire (20), d’au moins un script (SCR) associé à l’au moins une balise de déclenchement et/ou à l’au moins un message pour laquelle un évènement (EVENT) a été détecté, d’exécution (E7) par le calculateur secondaire (20) de l’au moins un script (SCR) obtenu. Figure pour l’abrégé : Figure 3 Procédé de gestion de l’accès d’un utilisateur à un véhicule automobile La présente invention se rapporte au domaine de l’automobile et concerne plus particulièrement un procédé de gestion de l’accès d’un utilisateur à un véhicule automobile. De nos jours, il est connu d’utiliser un dispositif porté par un utilisateur d’un véhicule pour lui permettre de déverrouiller l’accès à l’habitacle dudit véhicule depuis l’extérieur et/ou pour déclencher des services d’accueil (lumières, réglages des sièges, …). Le dispositif peut être une clé, un badge ou, de plus en plus souvent, le smartphone de l’utilisateur. Dans une solution connue, ancienne et répandue, la communication entre le dispositif et le véhicule est réalisée sur un lien sans fil de type basse fréquence (Low Frequency ou LF) pour détecter le dispositif puis radiofréquence (RF) pour authentifier le dispositif. Une solution plus récente utilise un lien sans fil de type Bluetooth® ou Bluetooth Low Energy® (BLE®). Enfin, une autre solution encore plus récente est basée sur la communication en bande ultra-large (Ultra Wide Band ou UWB). Dans cette dernière solution, il est connu d’utiliser un calculateur principal et une pluralité de calculateurs secondaires. Le calculateur principal est embarqué dans le véhicule et a pour rôle de commander chaque calculateur secondaire. Chaque calculateur secondaire est placé à un endroit différent dans le véhicule, par exemple à chaque coin du véhicule et en son centre et comporte une antenne permettant de communiquer avec le dispositif sur un lien de communication UWB. Le protocole de communication UWB permet, de manière connue, de communiquer selon deux modes : un mode de communication dit « passif » et un mode de communication dit « actif ». Dans le mode passif, un calculateur secondaire émet des signaux dans son environnement proche et reçoit des signaux réfléchis afin de pouvoir détecter la présence d’un obstacle qui peut être un objet ou une personne, notamment l’utilisateur du véhicule porteur du dispositif. Ce mode est dit passif car il n’y a pas d’échange de données entre le calculateur et l’obstacle. Dans le mode actif, un calculateur secondaire communique avec le dispositif afin d’échanger des données, notamment pour l’authentifier. Dans cette solution de l’art antérieur, le calculateur principal contrôle chaque calculateur secondaire afin de le placer soit en mode passif, soit en mode actif. Chaque calculateur secondaire est programmé pour exécuter un ensemble de tâches prédéterminées selon qu’il a été placé en mode passif ou en mode actif par le calculateur principal. Ainsi, dans cette solution, le calculateur principal doit modifier le mode de fonctionnement de chaque calculateur secondaire, un par un, afin qu’il puisse basculer dans l’autre mode, ce qui peut s’avérer chronophage et donc peu efficace lorsque des fonctions du véhicule doivent être activées le plus vite possible (déverrouillage, accueil, …), ce qui présente un inconvénient. Ensuite, la programmation statique de chaque calculateur secondaire selon le mode passif ou le mode actif ne permet pas au calculateur secondaire de proposer de nouvelles fonctionnalités et d’envoyer de nouvelles données au dispositif en dehors de celles qui sont programmées, ce qui présente un autre inconvénient. Une solution simple, fiable et efficace permettant de remédier au moins en partie à ces inconvénients serait donc avantageuse. A cette fin, l’invention a tout d’abord pour objet un procédé de gestion de fonctions d’un véhicule automobile pour un utilisateur dudit véhicule, ledit utilisateur portant un dispositif d’authentification permettant de déclencher lesdites fonctions en communiquant en ultra-large bande de fréquences, notamment depuis l’extérieur du véhicule, ledit véhicule comprenant un calculateur principal et une pluralité de calculateurs secondaires, chaque calculateur secondaire comportant une zone mémoire dans laquelle est stockée une pluralité de configurations, chaque configuration définissant un mode opératoire différent en étant identifiée par un identifiant, chaque mode opératoire comprenant l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences, ledit procédé, mis en œuvre par au moins l’un des calculateurs secondaires, comprenant les étapes de : - réception d’une requête de configuration envoyée par le calculateur principal, ladite requête comportant l’identifiant d’une configuration, - détermination, dans la zone mémoire dudit calculateur secondaire, de la configuration associée à l’identifiant reçu, - paramétrage du calculateur secondaire avec la configuration déterminée, - détection d’au moins un évènement correspondant à une balise de déclenchement ou à un message reçu du calculateur principal, - obtention, dans la zone mémoire dudit calculateur secondaire, d’au moins un script comprenant des instructions en mode passif et/ou actif associé à l’au moins une balise de déclenchement et/ou à l’au moins un message pour laquelle un évènement a été détecté, - exécution par le calculateur secondaire de l’au moins un script obtenu. La configuration peut utiliser le mode passif UWB, le mode actif UWB ou une combinaison du mode passif UWB et du mode actif UWB. Le procédé selon l’invention permet ainsi au calculateur principal de gérer chaque calculateur secondaire de manière indépendante via un format de requête commun, notamment de déterminer un mode opératoire différent pour chaque calculateur secondaire qui peut ensuite fonctionner de manière autonome en fonction des évènements détectés. Chaque calculateur secondaire peut ainsi lancer un scripte prédéterminé en fonction d’un évènement précis. De plus, l’utilisation de configurations stockées en zone mémoire de chaque calculateur secondaire permet en particulier d’éviter de devoir reparamétrer ledit calculateur secondaire pour le faire basculer entre le mode passif et le mode actif ou réciproquement. En outre, l’utilisation de configurations stockées en zone mémoire de chaque calculateur secondaire permet avantageusement l’utilisation de scriptes mêlant à la fois le mode passif et le mode actif. Les deux types de transmission/réception, passives et actives peuvent tous deux servir à la fois à mesurer une distance ou à évaluer un canal via une mesure de CIR (Channel Impulse Response). Ainsi, gérer ces deux types de requêtes de manière commune et centrale permet d’optimiser (via les scripts) les services rendus au client en répondant potentiellement à plusieurs clients à partir d’une seule communication UWB issue d’une seule requête. Cela permet ainsi de réduire le nombre de communications UWB, de diminuer la consommation de batterie du véhicule et du dispositif (smartphone ou keyfob) qui peut de manière standard présenter une consommation importante lors des phases de réception UWB. Cela permet également d’améliorer les temps de réponses des fonctions servies par les différents clients puisqu’une seule communication a lieu. Avantageusement, la détection de l’au moins un évènement est réalisée à partir de signaux reçus en ultra-large bande de fréquences. Avantageusement encore, les signaux reçus en ultra-large bande de fréquences ont été envoyés par le dispositif. L’invention concerne également un produit programme d’ordinateur caractérisé en ce qu’il comporte un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par un ou plusieurs processeurs, configurent le ou les processeurs pour mettre en œuvre un procédé tel que présenté précédemment. L’invention concerne également un calculateur secondaire de gestion de fonctions d’un véhicule automobile pour un utilisateur dudit véhicule, ledit utilisateur portant un dispositif d’authentification permettant de déclencher lesdites fonctions en communiquant en ultra-large bande de fréquences, notamment depuis l’extérieur du véhicule, ledit véhicule comprenant un calculateur principal et ledit calculateur secondaire, le calculateur secondaire comportant une zone mémoire dans laquelle est stockée une pluralité de configurations, chaque configuration définissant un mode opératoire différent en étant identifiée par un identifiant, chaque mode opératoire comprenant l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences, le calculateur secondaire étant configuré pour: - recevoir une requête de configuration envoyée par le calculateur principal, ladite requête comportant l’identifiant d’une configuration, - déterminer, dans la zone mémoire dudit calculateur secondaire, la configuration associée à l’identifiant reçu, - se paramétrer avec la configuration déterminée, - détecter au moins un évènement correspondant à une balise de déclenchement ou à un message reçu du calculateur principal, - obtenir, dans la zone mémoire, au moins un script comprenant des instructions en mode passif et/ou actif associé à l’au moins une balise de déclenchement et/ou à l’au moins un message pour laquelle un évènement a été détecté, - exécuter l’au moins un script obtenu. Avantageusement, le calculateur secondaire est configuré pour détecter l’au moins un évènement à partir de signaux reçus en ultra-large bande de fréquences. Avantageusement encore, le calculateur secondaire est configuré pour détecter l’au moins un évènement à partir de signaux envoyés par le dispositif en ultra-large bande de fréquences. L’invention concerne également un calculateur principal pour véhicule automobile, ledit calculateur principal étant configuré pour envoyer, sur un lien de communication, à un calculateur secondaire, tel que présenté précédemment, dudit véhicule, une requête de configuration comportant l’identifiant d’une configuration, ladite configuration définissant un mode opératoire, ledit mode opératoire comprenant l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences. Avantageusement, le calculateur principal est configuré pour envoyer des configurations et/ou des scriptes à un calculateur secondaire. L’invention concerne également un véhicule automobile comprenant un calculateur principal tel que présenté précédemment et une pluralité de calculateurs secondaires tel que présenté précédemment. D’autres caractéristiques et avantages de l’invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : La illustre schématiquement une forme de réalisation du système selon l’invention. La illustre schématiquement une forme de réalisation du calculateur secondaire selon l’invention. La illustre schématiquement un mode de réalisation du procédé selon l’invention. La représente un exemple de véhicule 1 selon l’invention. Véhicule 1 Le véhicule 1 comprend un calculateur principal 10 et quatre calculateurs secondaires 20. En variante, le véhicule 1 pourrait comprendre plus ou moins de quatre calculateurs secondaires 20. Le calculateur principal 10 est relié aux quatre calculateurs secondaires 20 par un réseau de communication 30 qui peut être de type filaire ou sans fil. Calculateur principal 1 0 Le calculateur principal 10 est configuré pour envoyer, via le réseau de communication, à un calculateur secondaire dudit véhicule, une requête de configuration comportant l’identifiant d’une configuration. L’identifiant de configuration permet d’identifier une configuration stockée dans la zone mémoire d’un calculateur secondaire 20. Chaque configuration définit un mode opératoire qui implique l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences par ledit calculateur secondaire 20. Le calculateur principal 10 est de préférence configuré pour envoyer des configurations et/ou des scriptes à chacun des calculateurs secondaires 20 afin de les mettre à jour. Le calculateur principal comprend un processeur apte à mettre en œuvre un ensemble d’instructions permettant de réaliser ces fonctions. Calculateur secondaire 20 Chaque calculateur secondaire 20 permet la gestion de fonctions du véhicule 1 pour un utilisateur 40 dudit véhicule 1. Les fonctions peuvent être déclenchées par l’utilisateur 40 via un dispositif 41 d’authentification et via un calculateur secondaire 20 ou bien directement par le calculateur secondaire 20, voire par le calculateur principal 10. Le dispositif 41 est configuré communiquer avec les calculateurs secondaires 20 sur un lien de communication en ultra-large bande de fréquences (UWB), notamment depuis l’extérieur du véhicule 1. Réciproquement, chaque calculateur secondaire 20 est configuré pour communiquer avec le dispositif 41 sur un lien de communication UWB, via une antenne 20A, et avec le calculateur principal 10 via le réseau de communication 30, par exemple en filaire de type bu CAN connu en soi. On a représenté sur la un exemple de calculateur secondaire 20 selon l’invention. Chaque calculateur secondaire 20 comprend une zone mémoire 21 dans laquelle est stockée une pluralité de configurations dudit calculateur secondaire 20. Chaque configuration est caractérisée par un identifiant et définit un mode opératoire différent. Chaque mode opératoire utilise le mode passif de la bande ultra-large ou bien le mode actif de la bande ultra-large ou bien une combinaison dudit mode passif et dudit mode actif. Chaque mode opératoire constitue une machine à états pouvant être exécutée par le calculateur secondaire 20. Chaque calculateur secondaire 20 est configuré pour recevoir des configurations et/ou des scriptes envoyés par le calculateur principal 10 afin de se mettre à jour. Chaque calculateur secondaire 20 est configuré pour recevoir une requête de configuration envoyée par le calculateur principal 10 et comprenant un identifiant de configuration. Chaque calculateur secondaire 20 est configuré pour déterminer, dans sa zone mémoire 21, la configuration associée à l’identifiant reçu dans la requête de configuration. Chaque calculateur secondaire 20 est configuré pour se paramétrer avec la configuration déterminée. Chaque calculateur secondaire 20 est configuré pour détecter au moins un évènement. L’évènement peut correspondre à une balise de déclenchement telle que, par exemple, la réception d’un message envoyé dans un signal UWB envoyé par le dispositif 41 ou bien la détection, via des signaux UWB en mode passif, de la position du dispositif 41 dans une zone prédéterminée autour du véhicule 1. La balise de déclenchement enclenche le déroulement d’un script stocké dans la zone mémoire 21. L’évènement peut également être un message reçu du calculateur principal 10 qui permet de déclencher un script comprenant des instructions en mode passif et/ou actif prédéterminé. Chaque calculateur secondaire 20 est configuré pour obtenir, dans sa zone mémoire, au moins un script comprenant des instructions en mode passif et/ou actif associé à au moins une balise de déclenchement et/ou à au moins un message pour laquelle un évènement a été détecté. Chaque calculateur secondaire 20 est configuré pour exécuter l’au moins un script obtenu. Chaque calculateur secondaire 20 comprend un processeur 22 apte à mettre en œuvre un ensemble d’instructions permettant de réaliser ces fonctions. Exemple de mise en œuvre Dans une étape préliminaire E0 de maintenance, le calculateur principal 10 envoie une pluralité de configurations et de scriptes à chaque calculateur secondaire 20 qui les reçoit et les stocke dans sa zone mémoire 21. En fonctionnement standard du véhicule 1, le calculateur principal 10 gère chaque calculateur secondaire 20 indépendamment dans une étape E1 en lui envoyant via le réseau de communication 30 l’identifiant d’une configuration dans une requête de configuration REQ. Chaque calculateur secondaire 20 reçoit dans une étape E2 la requête de configuration REQ envoyée par le calculateur principal 10 puis détermine, dans sa zone mémoire 21, la configuration CONFIG associée à l’identifiant reçu dans une étape E3. Chaque calculateur secondaire 20 se paramètre alors dans une étape E4 avec la configuration CONFIG déterminée. Lorsqu’un calculateur secondaire 20 détecte, dans une étape E5, un évènement EVENT correspondant à une balise de déclenchement d’un scripte mémorisé en zone mémoire ou à un message reçu du calculateur principal 10, ledit calculateur secondaire 20 obtient, dans sa zone mémoire 21, le script SCR comprenant des instructions en mode passif et/ou actif associé dans une étape E6 puis exécute ledit script SCR obtenu dans une étape E7. Ainsi le calculateur secondaire 20 ne dépend plus du calculateur principal 10 pour réagir à un évènement, il va puiser dans sa zone mémoire le script qui correspond à l’évènement détecté, le script pouvant faire basculer la communication entre le calculateur secondaire 20 et le dispositif 41 en mode de communication ultra large bande passif, passif renforcé (augmentation de la fréquence d’émission) ou actif. Exemples d’application Dans les exemples ci-après, une pluralité de configurations et une pluralité de scriptes ont été préalablement stockés dans la zone mémoire 21 de chaque calculateur secondaire 20. Premier exemple Dans un premier exemple, le calculateur principal 10 envoie une requête de configuration à l’un des calculateurs secondaires 20 afin que ledit calculateur secondaire 20 opère dans un premier mode passif pur dans lequel il émet à basses fréquences. Le calculateur secondaire 20, ainsi paramétré, détecte le dispositif 41 par polling à l’aide de signaux UWB qu’il émet, de manière connue en soi. Cette détection est un évènement qui correspond à une balise de déclenchement qui déclenche un scripte d’authentification associé en deux temps. Dans un premier temps, le scripte fait basculer le calculateur secondaire 20 dans un deuxième mode passif pur, à hautes fréquences, qui permet d’éliminer les objets fixes, autres que l’utilisateur 40 du dispositif 41, afin de s’assurer que le dispositif 41 est bien un dispositif d’authentification adapté pour communiquer avec le véhicule 1, qui s’approche ou s’éloigne du véhicule 1. Dans un deuxième temps, le scripte fait basculer le calculateur secondaire 20 dans un mode actif pur où ledit calculateur secondaire 20 communique avec le dispositif 41 afin de l’authentifier. Une fois authentifié, des fonctions d’accueil du véhicule 1 peuvent par exemple être mises en œuvre comme, par exemple, le déverrouillage des ouvrants du véhicule1, un éclairage, le réglage des sièges selon le profil de l’utilisateur, etc. Deuxième exemple Dans un deuxième exemple, le calculateur principal 10 envoie une requête de configuration à l’un des calculateurs secondaires 20 afin que ledit calculateur secondaire 20 opère dans un mode passif pur avec un dispositif 41 déjà authentifié porté par un utilisateur 40 du véhicule 1. Lorsque le calculateur secondaire 20, ainsi paramétré, détecte par polling, à l’aide de signaux UWB qu’il émet que le dispositif 41 s’éloigne du véhicule 1 et que les ouvrants du véhicule 1 ne sont pas verrouillés, cette détection est un évènement qui correspond à une balise de déclenchement qui déclenche un scripte de dialogue avec le dispositif 41. Dans un premier temps, le scripte fait basculer le calculateur secondaire 20 dans un mode actif pur où ledit calculateur secondaire 20 communique avec le dispositif 41 afin de prévenir que les ouvrants n’ont pas été verrouillés. L’utilisateur peut alors envoyer une commande de fermeture au calculateur secondaire 20 qui la transmet au calculateur principal 10 qui commande alors le verrouillage des ouvrants. Dans un autre exemple, un script peut définir un mode opératoire qui implique que le calculateur secondaire 20 fonctionne dans un mode hybride combinant mode passif et mode actif, sans passer par une balise de déclenchement ou un message du calculateur principal 10 avant chaque changement de mode UWB. Le procédé selon l’invention permet ainsi à un calculateur principal 10 de commander différemment et indépendamment une pluralité de calculateurs secondaires 20 à partir de simples identifiants de configuration, qui permettent de lancer une machine à états sur chaque calculateur secondaire 20, ou bien directement de simples messages de commande sans avoir besoin de reparamétrer à chaque fois le processeur 22 de chaque calculateur secondaire 20. Procédé de gestion de fonctions d’un véhicule (1) automobile pour un utilisateur (40) dudit véhicule (1), ledit utilisateur (40) portant un dispositif (41) d’authentification permettant de déclencher lesdites fonctions en communiquant en ultra-large bande de fréquences, notamment depuis l’extérieur du véhicule (1), ledit véhicule (1) comprenant un calculateur principal (10) et une pluralité de calculateurs secondaires (20), chaque calculateur secondaire (20) comportant une zone mémoire (21) dans laquelle est stockée une pluralité de configurations (CONFIG), chaque configuration (CONFIG) définissant un mode opératoire différent en étant identifiée par un identifiant, chaque mode opératoire comprenant l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences, ledit procédé, mis en œuvre par au moins l’un des calculateurs secondaires (20), comprenant les étapes de : - réception (E2) d’une requête de configuration (REQ) envoyée par le calculateur principal (10), ladite requête (REQ) comportant l’identifiant d’une configuration (CONFIG), - détermination (E3), dans la zone mémoire (21) dudit calculateur secondaire (20), de la configuration associée à l’identifiant reçu, - paramétrage (E4) du calculateur secondaire (20) avec la configuration déterminée, - détection (E5) d’au moins un évènement (EVENT) correspondant à une balise de déclenchement ou à un message reçu du calculateur principal (10), - obtention (E6), dans la zone mémoire (21) dudit calculateur secondaire (20), d’au moins un script (SCR) comprenant des instructions en mode passif et/ou actif associé à l’au moins une balise de déclenchement et/ou à l’au moins un message pour laquelle un évènement (EVENT) a été détecté, - exécution (E7) par le calculateur secondaire (20) de l’au moins un script (SCR) obtenu. Procédé selon la revendication 1, dans lequel la détection (E5) de l’au moins un évènement (EVENT) est réalisée à partir de signaux reçus en ultra-large bande de fréquences. Procédé selon la revendication précédente, dans lequel les signaux reçus en ultra-large bande de fréquences ont été envoyés par le dispositif (41). Produit programme d’ordinateur caractérisé en ce qu’il comporte un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par un ou plusieurs processeurs, configurent le ou les processeurs pour mettre en œuvre un procédé selon l’une quelconque des revendications précédentes. Calculateur secondaire (20) de gestion de fonctions d’un véhicule (1) automobile pour un utilisateur (40) dudit véhicule (1), ledit utilisateur (40) portant un dispositif (41) d’authentification permettant de déclencher lesdites fonctions en communiquant en ultra-large bande de fréquences, notamment depuis l’extérieur du véhicule (1), ledit véhicule (1) comprenant un calculateur principal (10) et ledit calculateur secondaire (20), le calculateur secondaire (20) comportant une zone mémoire (21) dans laquelle est stockée une pluralité de configurations (CONFIG), chaque configuration (CONFIG) définissant un mode opératoire différent en étant identifiée par un identifiant, chaque mode opératoire comprenant l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences, le calculateur secondaire (20) étant configuré pour: - recevoir une requête de configuration (REQ) envoyée par le calculateur principal (10), ladite requête (REQ) comportant l’identifiant d’une configuration (CONFIG), - déterminer, dans la zone mémoire (21) dudit calculateur secondaire (20), la configuration (CONFIG) associée à l’identifiant reçu, - se paramétrer avec la configuration (CONFIG) déterminée, - détecter au moins un évènement (EVENT) correspondant à une balise de déclenchement ou à un message reçu du calculateur principal (10), - obtenir, dans la zone mémoire (21), au moins un script (SCR) comprenant des instructions en mode passif et/ou actif associé à l’au moins une balise de déclenchement et/ou à l’au moins un message pour laquelle un évènement (EVENT) a été détecté, - exécuter l’au moins un script (SCR) obtenu. Calculateur secondaire (20) selon la revendication précédente, ledit calculateur secondaire étant configuré pour détecter l’au moins un évènement (EVENT) à partir de signaux reçus en ultra-large bande de fréquences. Calculateur secondaire (20) selon la revendication précédente, ledit calculateur secondaire (20) étant configuré pour détecter l’au moins un évènement (EVENT) à partir de signaux envoyés par le dispositif (41) en ultra-large bande de fréquences. Calculateur principal (10) pour véhicule automobile, ledit calculateur principal (10) étant configuré pour envoyer, sur un lien de communication, à un calculateur secondaire (20) dudit véhicule (1), une requête de configuration (REQ) comportant l’identifiant d’une configuration (CONFIG), ladite configuration (CONFIG) définissant un mode opératoire, ledit mode opératoire comprenant l’utilisation d’un mode passif et/ou actif de la bande ultra-large de fréquences. Calculateur principal (10) selon la revendication précédente, ledit calculateur principal (10) étant configuré pour envoyer des configurations et/ou des scriptes à un calculateur secondaire (20). Véhicule (1) automobile comprenant un calculateur principal (10) selon la revendication précédente et une pluralité de calculateurs secondaires (20) selon l’une quelconque des revendications 5 à 7.