Elle concerne plus particulièrement un procédé de connexion d'un système embarqué de véhicule à un appareil électronique, et un système embarqué de véhicule associé.

L'invention s'applique particulièrement avantageusement dans le cas où l'émission d'une requête de connexion est réalisée par un module de communication sans fil en mode balayage.

ARRI ERE-PLAN TECHNOLOGIQUE

Lorsque l'on souhaite établir une connexion sans fil entre un système embarqué de véhicule et un appareil électronique (tel qu'un terminal utilisateur), par exemple afin d'échanger des données entre le système embarqué et l'appareil électronique et/ou afin de commander une fonctionnalité du véhicule au moyen de l'appareil électronique, il est préférable que cette connexion soit commandée par le système embarqué afin de garder une bonne maîtrise sur le mécanisme de connexion (quel que soit l'appareil électronique utilisé).

Ceci impose toutefois (notamment lorsque le protocole utilisé pour la connexion sans fil est de type BLE ou "Bluetooth Low Energy) que le module de communication sans fil du système embarqué soit en mode balayage pour détecter d'éventuelles trames d'annonce émises par les appareils électroniques avoisinants, ce qui entraîne une consommation électrique notable au niveau du système embarqué.

OBJET DE L'INVENTION

Dans ce contexte, la présente invention propose un procédé de connexion d'un système embarqué de véhicule, comprenant un premier module de communication sans fil, à un appareil électronique comprenant un second module de communication sans fil, le procédé de connexion comprenant les étapes suivantes :

- diffusion de trames d'annonce par le premier module de communication sans fil ;

- en réponse à une desdites trames d'annonce diffusées, émission, par le second module de communication sans fil en mode balayage, d'une requête d'informations à destination du premier module de communication ;

- à réception de la requête d'informations, basculement du premier module de communication sans fil en mode balayage ;

- émission par le second module de communication sans fil d'une autre trame d'annonce ;

- à réception de ladite autre trame d'annonce, émission, par le premier module de communication en mode balayage, d'une requête de connexion destinée au second module de communication.

Le premier module de communication sans fil peut ainsi être en mode diffusion tant qu'il n'a pas reçu la requête d'informations, ce qui limite la consommation électrique du système embarqué, puis bascule en mode balayage afin d'initier la connexion de manière maîtrisée.

Selon d'autres caractéristiques envisageables à titre optionnel (et donc non limitatif) :

- la requête d'informations comprend une adresse associée au second module de communication sans fil ou au terminal utilisateur ;

- l'adresse est une adresse résolvable ;

- l'adresse est une adresse fixe ;

- ledit basculement est effectué sous condition de vérification de l'adresse par le système embarqué ;

- les trames d'annonce diffusées sont indicatives de disponibilité du premier module de communication sans fil pour une requête d'informations et/ou d'indisponibilité du premier module de communication sans fil pour une connexion ;

- ladite autre trame d'annonce est indicative de disponibilité du second module de communication sans fil pour une connexion ;

- ladite diffusion des trames d'annonce est périodique ;

- lesdites trames sont diffusées, pour chaque période, pendant une durée inférieure ou égale à 10% de ladite période (par exemple comprise entre 1 % et

10% de ladite période) ;

- à réception de ladite requête d'informations, le premier module de communication sans fil émet en outre une trame en réponse à destination du second module de communication sans fil. L'invention propose également un système embarqué de véhicule comprenant un module de communication sans fil et un processeur conçu pour commander le module de communication sans fil pour :

- diffuser des trames d'annonce ;

- à réception d'une requête d'informations en provenance d'un autre module de communication sans fil, basculer en mode balayage ;

- à réception d'une autre trame d'annonce émise par l'autre module de communication sans fil, émettre une requête de connexion destinée à l'autre module de communication.

Certaines au moins des caractéristiques optionnelles présentées ci- dessus en termes de procédé peut éventuellement s'appliquer à un tel système embarqué.

DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.

Sur les dessins annexés :

- la figure 1 représente un exemple de contexte dans lequel peut être mise en œuvre l'invention ;

- la figure 2 représente schématiquement des composants, utiles à la compréhension de l'invention, d'un véhicule et d'un appareil électronique ;

- la figure 3 représente un exemple de procédé de connexion d'un système embarqué du véhicule à l'appareil électronique.

La figure 1 représente un exemple de contexte dans lequel peut être mise en œuvre l'invention.

Dans ce contexte, un véhicule 1 0 comprend un système embarqué 1 3 qui peut entrer en communication via une liaison sans fil avec un appareil électronique, ici un terminal utilisateur 20 présent au voisinage du véhicule 10.

Ce terminal utilisateur 20 peut être par exemple un téléphone portable (ou téléphone cellulaire), éventuellement de type "téléphone intelligent (ou "smartphone" selon la dénomination anglo-saxonne couramment utilisée).

Un autre type d'appareil électronique (par exemple une clé ou un badge d'accès au véhicule 1 0) peut toutefois être utilisé en lieu et place du terminal utilisateur 20 (dans toute la suite de la description). Grâce à la liaison sans fil établie comme expliqué plus bas, le système embarqué 1 3 et le terminal utilisateur 20 peuvent échanger des données entre eux, par exemple en vue de la commande d'au moins une fonctionnalité du véhicule 10 au moyen du terminal utilisateur 20. Une telle fonctionnalité est par exemple le déverrouillage des portes du véhicule 10.

La liaison sans fil utilisée pour communiquer entre le système embarqué 13 et le terminal utilisateur 20 est par exemple de type Bluetooth, ici en particulier de type Bluetooth Low Energy (BLE).

On considère dans la suite que le système embarqué 1 3 et le terminal utilisateur 20 ont déjà échangé des données au cours d'une phase d'appairage conduite avec succès de sorte que le système embarqué 13 et le terminal utilisateur 20 sont appairés.

Le terminal utilisateur 20 peut être en outre conçu pour se connecter à un réseau de téléphonie mobile (non représenté).

La figure 2 représente schématiquement des composants, utiles à la compréhension de l'invention, du véhicule 1 0 et du terminal utilisateur 20.

Le véhicule 1 0 comprend notamment le système embarqué 13 déjà mentionné et un actionneur 15 conçu pour mettre en œuvre la fonctionnalité commandée (à réception d'une commande correspondante en provenance du système embarqué 13).

Le système embarqué 13 comprend quant à lui une unité électronique de commande 1 1 (ou ECU pour "Electronic Control Unit) et un module de communication sans fil 1 6, ici selon la technologie Bluetooth Low Energy (BLE).

L'unité électronique de commande 1 1 comprend un processeur 12 et une unité de mémorisation 14, par exemple une mémoire non-volatile réinscriptible ou un disque dur.

L'unité de mémorisation 14 mémorise notamment des programmes d'ordinateur comprenant des instructions dont l'exécution par le processeur 1 2 permet la mise en œuvre par l'unité électronique de commande 1 1 du procédé décrit ci-dessous en référence à la figure 3.

L'unité de mémorisation 14 mémorise également des données utilisées dans le cadre des procédés décrits ci-dessous, notamment une clé secrète K.

La clé secrète K est ici une clé associée au terminal utilisateur 20 susmentionné. Il s'agit par exemple d'une clé de type I RK (pour "Identity Resolving Key") telle que prévue dans le cadre de la technologie BLE. Une telle clé I RK est propre au terminal utilisateur 20 et a été communiqué (sous forme chiffrée) du terminal utilisateur 20 au sytème embarqué 1 3 lors de la phase d'appairage susmentionnée.

Le terminal utilisateur 20 comprend un processeur 22, une mémoire 24

(par exemple une mémoire non-volatile réinscriptible), un module de communication sans fil 26, ici selon la technologie Bluetooth Low Energy (BLE), une interface utilisateur 21 (ici un écran tactile) et un module 28 de communication sur le réseau de téléphonie mobile susmentionné.

Dans certains modes de réalisation, le module de communication 28 peut comprendre une carte à puce qui mémorise des données de connexion associées à un abonnement au service de téléphonie mobile et permettant d'établir la connexion sur le réseau de téléphonie mobile.

La mémoire 24 mémorise la clé secrète K susmentionnée (également mémorisée comme déjà indiqué au sein de l'unité de mémorisation 14 de l'unité électronique de commande 1 1 du véhicule 10). La clé secrète K (ici comme déjà indiqué une clé de type IRK) a par exemple été mémorisée dans la mémoire 24 du terminal utilisateur 20 lors de la fabrication du terminal utilisateur 20 (dans le cadre de la préparation de ce terminal utilisateur 20 pour fonctionner selon la technologie BLE).

Le module de communication sans fil 26 du terminal utilisateur 20 permet d'établir une liaison sans fil (ici de type Bluetooth Low Energy comme déjà indiqué) avec le module de communication sans fil 1 6 du véhicule 10 à travers laquelle le processeur 12 de l'unité électronique de commande 1 1 et le processeur 22 du terminal utilisateur 20 peuvent échanger des données, comme expliqué ci- après.

Avant connexion, le module de communication sans fil 1 6 du véhicule 1 0 et le module de communication sans fil 26 du terminal utilisateur 20 peuvent chacun être dans un mode diffusion (mode " advertising" en technologie Bluetooth) et/ou dans un mode balayage (mode "scanning" ou mode "initiating" en technologie Bluetooth comme expliqué ci-dessous).

Lorsqu'un module de communication sans fil 1 6, 26 est en mode diffusion, il diffuse des trames d'annonce (ou "advertising packets" selon la terminologie anglo-saxonne) qui peuvent avoir l'un des types suivants : - ADV_NONCONN_IND (trames indicatives d'indisponibilité) ;

- ADVJND (trames indicatives de disponibilité indirecte, c'est-à-dire de disponibilité pour une connexion avec un appareil quelconque) ;

- ADV_SCAN_IND (trames indicatives de disponibilité pour répondre à un requête d'informations - voir ci-dessous - mais d'indisponibilité pour une connexion) ;

- ADV_DIRECT (trames indicatives de disponibilité directe).

Lorsqu'un module de communication sans fil 1 6, 26 est en mode balayage, il peut être dans l'un des deux sous-modes suivants :

- sous-mode recherche ("scanning") : le module de communication sans fil peut alors émettre une requête d'informations (trame de type SCAN_REQ ou "scan requesf selon la terminologie utilisée dans le protocole Bluetooth Low Energy) destinée à un appareil en mode diffusion afin que cet appareil lui communique des informations complémentaires ;

- sous-mode établissement {"initiating") : le module de communication sans fil peut alors émettre une requête de connexion (trame de type CONNECT_REQ ou "connection requesf selon la terminologie utilisée dans le protocole Bluetooth Low Energy) destinée à un appareil en mode diffusion afin d'initier une connexion avec cet appareil.

Lorsqu'un module de communication sans fil 1 6, 26 en mode diffusion reçoit une requête d'informations en provenance d'un module en mode balayage (sous-mode recherche), le module en mode diffusion répond à cette requête par l'émission d'une réponse (trame d'annonce de type SCAN_RSP ou "scan response" selon la terminologie utilisée dans le protocole Bluetooth Low Energy) destinée à l'appareil en mode balayage et contenant les informations complémentaires.

Dans le cadre du protocole Bluetooth Low Energy, il est prévu que les trames d'établissement d'une connexion (listées ci-dessus) soit échangées au sein de canaux spécifiques, dits canaux d'annonce (en anglais "advertising channels"), distincts des canaux de données (en anglais : "data channels") utilisés pour transmettre les trames d'échange de données applicatives relatives à des connexions établies.

Le protocole Bluetooth Low Energy prévoit 3 canaux d'annonce (référencés canal 37, canal 38 et canal 39 et ayant des fréquences centrales respectives égales à 2402 MHz, 2426 MHz, 2480 MHz) et 37 canaux de données (référencés canal 0 à canal 36).

Ainsi les 3 canaux d'annonces ont respectivement des fréquences centrales situées à l'extrémité inférieure, dans une région centrale et à l'extrémité supérieure de la bande de fréquence concernée (ici la bande à 2,4 GHz).

La figure 3 représente un exemple de procédé de connexion du système embarqué 13 du véhicule 10 au terminal utilisateur 20.

Ce procédé débute par une étape E2 à laquelle le processeur 1 2 commande le module de communication sans fil 1 6 en mode diffusion seule (c'est- à-dire sans balayage).

Cette étape est par exemple réalisée en préalable à l'ensemble des étapes ci-dessous, dès que le système embarqué 13 est en attente d'une connexion potentielle avec un terminal utilisateur. L'étape E2 est ainsi par exemple mise en œuvre lors de la mise sous tension du système embarqué 13 ou après l'achèvement d'une précédente communication.

Le module de communication sans fil 1 6 diffuse alors périodiquement des trames d'annonce ADV1 (étape E4). Dans le mode de réalisation décrit ici, les trames d'annonce sont de type ADV_SCAN_IND (ce type de trames indique comme expliqué plus haut que le module de communication sans fil 1 6 est disponible pour répondre à une requête d'informations SCAN_REQ mais indisponible pour une connexion). En variante, il pourrait s'agir de trames de type ADVJND.

Le module de communication sans fil 1 6 reste ainsi en mode diffusion tant qu'un autre module de communication sans fil (en l'occurrence celui d'un terminal utilisateur) ne s'adresse pas à lui comme expliqué ci-dessous. Ceci est avantageux puisque, pendant cette phase d'attente, la consommation du module de communication sans fil 16 est très limitée. En effet, les trames d'annonce ne sont diffusées que pendant une brève partie du temps (typiquement 10% du temps ou moins, ici environ 5% du temps) pour chaque période, à comparer à une utilisation pendant environ 30% à 40% du temps (selon des valeurs typiquement utilisées) en mode balayage.

Le processeur 22 commande quant à lui le module de communication sans fil 26 en mode diffusion et balayage, en sous-mode recherche (étape E6).

Cette étape peut être réalisée dès la mise sous tension du terminal utilisateur 20. On peut toutefois prévoir en variante que cette étape E6 ne soit réalisée que lorsque l'utilisateur indique, au moyen de l'interface utilisateur 21 , qu'il souhaite une connexion du terminal utilisateur 20 et du système embarqué 13, ou qu'il souhaite commander une fonctionnalité du véhicule 1 0 au moyen du terminal utilisateur 20.

Le module de communication sans fil 26 effectue donc (étape E8) d'une part une diffusion de trames d'annonce ADV2 et d'autre part un balayage (sous- mode recherche ou "scanning" selon l'appellation anglo-saxonne) afin de détecter d'éventuelles trames d'annonce émises par d'autres dispositifs.

Les trames d'annonce ADV2 diffusées par le module de communication sans fil 26 sont ici des trames de type ADVJND (ce type de trames indique comme expliqué plus haut que le module de communication sans fil 26 est disponible pour une connexion avec un dispositif quelconque).

Dans cette situation, et lorsque le terminal utilisateur 20 est suffisamment proche du véhicule 10 pour que le module de communication sans fil 26 en mode balayage reçoive l'une des trames d'annonce ADV1 diffusées par le module de communication sans fil 1 6, le module de communication sans fil 26 (étant en sous- mode recherche ou "scanning") émet à l'étape E1 0 (en réponse à la trame d'annonce ADV1 reçue) une requête d'informations SCAN_REQ destinée au module de communication sans fil 16 du système embarqué 13.

On prévoit ici en outre que la requête d'informations SCAN REQ comprenne une adresse ADR associée au terminal utilisateur 20 ou au module de communication sans fil 26. L'adresse peut être une adresse résolvable (ou RPA pour "Résolvable Private Address"). Une telle adresse résolvable ADR comprend par exemple un nombre aléatoire RND et un condensât HSH obtenu par application d'une fonction cryptographique f au nombre aléatoire RND et à la clé secrète K. Précisément, l'adresse résolvable ADR est ici la concaténation du condensât HSH et du nombre aléatoire RDN : ADR = HSH | | RND, avec HSH=f(RND,K).

L'adresse résolvable ADR est par exemple déterminée (lors d'une étape antérieure non représentée) par le processeur 22.

En variante, l'adresse ADR associée au terminal utilisateur 20 ou au module de communication sans fil 26 pourrait être une adresse fixe, par exemple un identifiant du terminal utilisateur 20 ou du module de communication sans fil 26.

Le module de communication sans fil 1 6 reçoit la requête d'informations SCAN_REQ (accompagnée de l'adresse ADR) à l'étape E1 2 et transmet cette information au processeur 12 de l'unité électronique de commande 1 1 .

Le module de communication sans fil 1 6 émet alors en réponse une trame de type SCAN_RSP (étape E14) contenant notamment les informations complémentaires suivantes : un identifiant local du véhicule 10 et/ou un identifiant complet du véhicule 1 0 et/ou une liste de services sollicités et/ou une liste de services supportés et/ou des données de service et/ou des données spécifiques à l'utilisateur.

Le module de communication sans fil 26 reçoit la trame SCAN_RSP (et les informations complémentaires) à l'étape E1 6.

De son côté, le processeur 12 vérifie à l'étape E1 8 si l'adresse ADR correspond à un terminal utilisateur 20 avec lequel le système embarqué 1 3 doit entrer en connexion. Les conditions dans lesquelles un système embarqué peut nécessiter une connexion avec un terminal utilisateur dépendent des applications envisagées et ne seront donc pas décrites ici en détail. Il peut s'agir par exemple d'un terminal utilisateur qui vient d'entrer dans la portée du module de communication sans fil 1 6. Il peut également s'agir d'un terminal utilisateur qui n'a pas échangé de données avec le système embarqué 13 depuis un laps de temps prédéterminé.

Dans l'exemple décrit ici où une adresse résolvable ADR est utilisée, la vérification de l'étape E1 8 consiste à vérifier, au moyen de l'adresse ADR reçue à l'étape E12 et de la clé secrète K mémorisée dans l'unité de mémorisation 14 en association avec le terminal utilisateur 20, si l'adresse reçue ADR = HSH || RND est correcte, c'est-à-dire si on a bien : HSH=f(RND,K).

Si le processeur 12 détermine que l'adresse ADR ne correspond pas à un terminal utilisateur avec lequel le système embarqué 13 doit entrer en connexion (flèche N à l'étape E18), les échanges précédents restent sans suite et le procédé boucle à l'étape E4.

Si le processeur 12 détermine que l'adresse ADR correspond au contraire à un terminal utilisateur 20 avec lequel le système embarqué 13 souhaite entrer en connexion (flèche P à l'étape E18), le procédé se poursuit à l'étape E20 à laquelle le processeur 1 2 commande le basculement du module de communication sans fil 1 6 en mode balayage et en sous-mode établissement ("initiating"), ici précisément en mode balayage sans diffusion de trames d'annonce.

Comme indiqué plus haut, on considère dans l'exemple décrit ici que le système embarqué 13 et le terminal utilisateur 20 ont été préalablement appairés. Si tel n'était pas le cas, le processeur 1 2 ne pourrait pas résoudre l'adresse ADR reçue à l'étape E12 (ou, de manière générale, ne pourrait pas déterminer sur la seule base des informations reçues avec la requête d'informations SCAN_REQ si le terminal utilisateur est compatible pour coopérer avec le système embarqué 13).

On peut alors prévoir dans ce cas (où le système embarqué 13 et le terminal utilisateur 20 ne sont pas appairés) que le processeur 12 commande le basculement du module de communication sans fil 16 en mode balayage, sous- mode recherche ("scanning") afin de recevoir les trames d'annonce ADV2, de prendre en considération les informations contenues dans ces trames d'annonce ADV2 et de basculer alors éventuellement en mode d'établissement ("initiating") pour se connecter et entreprendre un processus d'appairage. Le fonctionnement pourrait alors reprendre, après appairage, comme exposé ci-dessus.

On rappelle par ailleurs que (comme indiqué ci-dessus) le module de communication sans fil 26 est en mode diffusion et balayage depuis l'étape E6. En variante, on pourrait prévoir que le module de communication sans fil 26 soit en mode balayage seul (sans diffusion de trames d'annonce) depuis l'étape E6, et bascule en mode diffusion (ou en mode diffusion et balayage) à réception de la réponse SCAN_RSP à l'étape E1 6.

Quoiqu'il en soit, le module de communication sans fil 26 émet périodiquement des trames d'annonce ADV2 (ici de type ADVJND), et ce notamment à l'étape E22 (postérieure à l'étape E20).

Le module de communication sans fil 1 6, en mode balayage (sous-mode établissement ou "initiating") depuis l'étape E20, reçoit ainsi à l'étape E24 la trame d'annonce ADV2 émise (i.e. diffusée) à l'étape E22.

Le module de communication sans fil 1 6 peut ainsi (sous la commande du processeur 12) émettre, en réponse à cette trame d'annonce ADV2 (indicative ici, comme déjà indiqué, de disponibilité du module de communication sans fil 26 pour une connexion), une requête de connexion CONNECT_REQ à destination du module de communication 26 du terminal utilisateur 20 (étape E26).

Le module de communication sans fil 26 reçoit cette requête de connexion CONNECT_REQ (étape E28) et une connexion s'établit ainsi entre les modules de communication sans fil 1 6, 26.

Comme déjà indiqué, le système embarqué 1 3 (précisément le processeur 12) et le terminal utilisateur 20 (précisément le processeur 22) peuvent ainsi échanger des données entre eux via la connexion établie, par exemple en vue d'une authentification mutuelle et/ou d'une commande d'une fonctionnalité du véhicule 10 par le terminal utilisateur 20.