FR3152330A1 - Procédé et dispositif de contrôle de mise à jour logicielle d’un véhicule - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif de contrôle de mise à jour logicielle d’un véhicule (10). A cet effet, des premières données représentatives d’un historique d’utilisation du véhicule sont reçues, les premières données comprenant des données représentatives d’un ensemble de localisations géographiques historiques du véhicule et des données représentatives d’un ensemble de valeurs horodatées de paramètres d’utilisation du véhicule. Des deuxièmes données représentatives d’un instant temporel courant et d’une localisation géographique courante du véhicule sont reçues. Un instant temporel de mise à jour logicielle du véhicule est déterminé en fonction des premières et deuxièmes données. Une information de validation de la mise à jour logicielle du véhicule à l’instant temporel déterminé est reçue et la mise à jour logicielle est contrôlée en fonction de l’information de validation et de l’instant temporel de mise à jour logicielle. Figure pour l’abrégé : Figure 1

Description

Procédé et dispositif de contrôle de mise à jour logicielle d’un véhicule

La présente invention concerne les procédés et dispositifs de contrôle de la mise à jour logicielle d’un véhicule, notamment mais non exclusivement un véhicule automobile. La présente invention concerne également un procédé et un dispositif de mise à jour de logiciel(s) embarqué(s) dans un ou plusieurs calculateurs d’un véhicule.

Arrière-plan technologique

Les véhicules contemporains embarquent nombre de calculateurs assurant chacun une ou plusieurs fonctions, telles que par exemple la gestion de l’aide à la conduite, de l’antipatinage, de la répartition électronique du freinage ou encore la commande d’actionneurs pour assurer le fonctionnement optimal du véhicule ainsi que la sécurité et le confort des passagers.

Ces calculateurs sont aussi appelés UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit »). Ces calculateurs embarquent des logiciels qui sont exécutés pour assurer les fonctions dont ils ont la charge. Des mises à jour de ces logiciels sont parfois nécessaires, par exemple pour améliorer une fonction ou pour corriger une erreur, aussi appelée « bug » en informatique. Ces mises à jour peuvent s’avérer critiques, notamment pour les logiciels qui assurent le bon fonctionnement du véhicule et la sécurité des passagers du véhicule. Le contrôle de ces mises à jour est par conséquent particulièrement important.

De telles mises à jour sont généralement mises en œuvre via le téléchargement des données pour la mise à jour d’un ou plusieurs logiciels par le véhicule, selon un mode de communication sans fil, aussi appelé OTA (de l’anglais « Over The Air » ou en français « par voie aérienne »).

Une telle mise à jour logicielle est généralement proposée au conducteur du véhicule avant que ce dernier ne coupe le contact, lorsque le véhicule est à l’arrêt mais sous tension. L’installation d’une mise à jour logicielle pouvant durer jusqu’à plusieurs minutes, voire plusieurs dizaines de minutes selon le volume de la mise à jour, le conducteur refuse souvent la mise à jour logicielle faute de disponibilité ou de temps.

L’absence d’installation des mises à jour disponibles peut alors entrainer des risques de dysfonctionnement pour les systèmes à mettre à jour et/ou des risques de sécurité pour le véhicule électrique et ses passagers.

Résumé de la présente invention

Un objet de la présente invention est de résoudre au moins l’un des problèmes de l’arrière-plan technologique décrit précédemment.

Un autre objet de la présente invention est d’améliorer la mise à jour logicielle d’un véhicule.

Selon un premier aspect, la présente invention concerne un procédé de contrôle de mise à jour logicielle d’un véhicule, le procédé comprenant les étapes suivantes :
- réception de premières données représentatives d’un historique d’utilisation du véhicule, les premières données comprenant des données représentatives d’un ensemble de localisations géographiques historiques du véhicule et des données représentatives d’un ensemble de valeurs horodatées d’un ensemble de paramètres d’utilisation du véhicule ;
- réception de deuxièmes données représentatives d’un instant temporel courant et d’une localisation géographique courante du véhicule ;
- première détermination d’un instant temporel de mise à jour logicielle du véhicule en fonction des premières et deuxièmes données ;
- réception d’une information de validation de la mise à jour logicielle du véhicule à l’instant temporel de mise à jour logicielle ; et
- contrôle de la mise à jour logicielle en fonction de l’information de validation et de l’instant temporel de mise à jour logicielle.

Un tel procédé permet ainsi de déterminer un instant temporel, c’est à dire planifier une mise à jour logicielle du véhicule, proposant ainsi à un utilisateur de mettre en œuvre la mise à jour logicielle à un moment opportun. Ainsi, un utilisateur validera facilement la mise à jour logicielle du véhicule.

Selon une variante, le procédé comprend en outre une étape de réception de troisièmes données représentatives d’une disponibilité d’un service après-vente, dit SAV, ladite première détermination étant en outre fonction des troisièmes données.

La mise à jour logicielle est ainsi planifiée en fonction de la disponibilité du SAV. En cas d’échec de la mise à jour logicielle ou en cas de problème technique, un utilisateur peut alors facilement contacter le SAV afin que ce dernier lui vienne en aide.

Selon une autre variante du procédé, les premières données comprennent en outre des données d’horodatage d’au moins une mise à jour logicielle antérieure du véhicule.

La mise à jour logicielle antérieure ayant été validée par l’utilisateur, il est possible qu’elle ait été proposée à un moment judicieux. Une mise à jour logicielle proposée à un instant similaire a par conséquent davantage de chances d’être validée.

Selon une variante supplémentaire, le procédé comprend en outre une étape de téléchargement de quatrièmes données comprenant des informations et instructions pour la mise à jour logicielle.

En effet, les données nécessaires à une mise à jour logicielle sont généralement stockées sur un serveur distant.

Selon encore une variante du procédé, l’information de validation correspond à des cinquièmes données représentatives d’un appui tactile sur un objet graphique affiché sur un écran tactile du véhicule.

De nombreux véhicules contemporains disposent d’une interface homme-machine, dite IHM, comprenant un écran tactile. Un objet graphique est alors affiché sur un écran tactile et permet la validation d’une mise à jour logicielle par un utilisateur par simple appui tactile sur cet objet graphique.

Selon une autre variante du procédé, la première détermination comprend les étapes de :
- deuxième détermination d’une distance entre la localisation géographique courante et une localisation géographique historique de l’ensemble de localisations géographiques historiques la plus proche de la localisation géographique courante ;
- comparaison de la distance à une valeur seuil ;
la première détermination étant en outre fonction d’un résultat de la comparaison.

La valeur seuil permet de définir une distance à partir de laquelle le véhicule est en dehors d’une zone où il se situe habituellement. Lorsque le véhicule est loin d’une telle zone, celui-ci est par exemple loin de sa zone de stationnement habituelle ou parcourt un trajet inhabituel, par exemple lors de départ ou retour de vacances. Le moment n’est alors pas opportun pour une mise à jour logicielle. En effet, en cas de défaillance de la mise à jour logicielle rendant par exemple le véhicule inutilisable, un utilisateur loin de son domicile peut se trouver en grande difficulté.

Selon encore une autre variante du procédé, la première détermination est mise en œuvre par une méthode d’intelligence artificielle.

En utilisant des algorithmes d'apprentissage automatique et d'intelligence artificielle, le système analyse les habitudes utilisateur pour identifier les moments les plus propices pour proposer une planification adaptée de la mise à jour logicielle.

Selon un deuxième aspect, la présente invention concerne un dispositif de contrôle de mise à jour logicielle d’un véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention.

Selon un troisième aspect, la présente invention concerne un véhicule, par exemple de type automobile, comprenant un dispositif tel que décrit ci-dessus selon le deuxième aspect de la présente invention.

Selon un quatrième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur.

Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

Selon un cinquième aspect, la présente invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de la présente invention.

D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur.

D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des figures

D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 3 annexées, sur lesquelles :

FIG. 1illustre schématiquement un véhicule et son environnement de communication, selon un exemple de réalisation particulier et non limitatif de la présente invention ;

FIG. 2illustre schématiquement un dispositif configuré pour contrôler une mise à jour logicielle du véhicule de laFIG. 1, selon un exemple de réalisation particulier et non limitatif de la présente invention ;

FIG. 3illustre un organigramme des différentes étapes d’un procédé de contrôle de mise à jour logicielle du véhicule de laFIG. 1, selon un exemple de réalisation particulier et non limitatif de la présente invention.

Description des exemples de réalisation

Un procédé et un dispositif de contrôle de mise à jour logicielle d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 3. Des mêmes éléments sont identifiés avec des mêmes signes de référence tout au long de la description qui va suivre.

Les termes « premier(s) », « deuxième(s) » (ou « première(s) », « deuxième(s) »), etc. sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des moyens, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. De tels éléments peuvent être distincts ou correspondre à un seul et unique élément, selon le mode de réalisation.

Selon un exemple particulier et non limitatif de réalisation de la présente invention, le contrôle de la mise à jour logicielle d’un véhicule électrique, par exemple pour la mise à jour de logiciels embarqués dans un ou plusieurs calculateurs du véhicule électrique, est par exemple mis en œuvre par un ou plusieurs processeurs d’un système embarqué du véhicule.

A cet effet, le procédé comprend la réception de premières données représentatives d’un historique d’utilisation du véhicule, les premières données comprenant des données représentatives d’un ensemble de localisations géographiques historiques du véhicule et des données représentatives d’un ensemble de valeurs horodatées d’un ensemble de paramètres d’utilisation du véhicule. Le procédé comprend également la réception de deuxièmes données représentatives d’un instant temporel courant et d’une localisation géographique courante du véhicule. Un instant temporel de mise à jour logicielle du véhicule est déterminé en fonction des premières et deuxièmes données. Une information de validation de la mise à jour logicielle du véhicule à l’instant temporel de mise à jour logicielle déterminé est alors reçue et la mise à jour logicielle est contrôlée en fonction de l’information de validation et de l’instant temporel de mise à jour logicielle.

LaFIG. 1illustre schématiquement un véhicule et son environnement de communication, selon un exemple de réalisation particulier et non limitatif de la présente invention.

LaFIG. 1illustre un véhicule 10, par exemple un véhicule automobile, dans un environnement de communication 1, le véhicule 10 étant par exemple dans un environnement routier ou sur une aire de stationnement ou parking, dans un garage, etc. Selon d’autres exemples, le véhicule 10 correspond à un car, un bus, un camion, un véhicule utilitaire ou une motocyclette, c’est-à-dire à un véhicule de type véhicule terrestre motorisé.

Le véhicule 10 correspond par exemple à un véhicule à moteur thermique, à moteur(s) électrique(s) ou encore un véhicule hybride avec un moteur thermique et un ou plusieurs moteurs électriques.

Le véhicule électrique 10 embarque avantageusement un système de communication configuré pour communiquer avec un ou plusieurs dispositifs distants 111 par l’intermédiaire d’une infrastructure d’un réseau de communication sans fil.

Le système de communication du véhicule 10 est par exemple en outre configuré pour communiquer avec un ou plusieurs dispositifs de communication mobile 11 en mode de communication directe et/ou par l’intermédiaire de l’infrastructure du réseau de communication sans fil. Le dispositif de communication mobile 11 correspond par exemple à un téléphone intelligent, une tablette ou encore un objet mobile connecté tel qu’une montre connectée, aussi appelée montre intelligente (de l’anglais « Smartwatch »).

Un mode de communication directe sans fil s’appuie par exemple sur une des normes ou protocoles de communication suivants :
- Wifi® selon IEEE 802.11, par exemple selon IEEE 802.11n ou IEEE 802.11ac, par exemple selon un mode de communication dit infrastructure selon lequel le véhicule électrique 10 fait office de point d’accès selon un selon un mode de communication ad-hoc ou direct, dit Wifi Direct ;
- Bluetooth® ;
- ZigBee selon IEEE 802.15.4.

Le véhicule 10 et/ou le dispositif de communication mobile 11 sont en outre configurés pour communiquer avec un ou plusieurs dispositifs distants 111, par exemple par l’intermédiaire de l’infrastructure de réseau de communication sans fil.

Le(s) dispositif(s) distant(s) 111 correspondent par exemple chacun à un serveur du « cloud » 100 (ou « nuage » en français). L’infrastructure de communication sans fil comprend par exemple un ensemble de dispositifs de communication de type antenne de réseau cellulaire 110 de type LTE (de l’anglais « Long Term Evolution » ou en français « Evolution à long terme ») 4G ou 5G.

Le système de communication du véhicule 10 comprend par exemple une ou plusieurs antennes de communication reliées à une unité de contrôle télématique, dite TCU (de l’anglais « Telematic Control Unit »), elle-même reliée à un ou plusieurs calculateurs du système embarqué du véhicule 10. La ou les antennes, l’unité TCU et le ou les calculateurs forment par exemple une architecture multiplexée pour la réalisation de différents services utiles pour le bon fonctionnement du véhicule et pour assister le conducteur et/ou les passagers du véhicule dans le contrôle du véhicule 10. Le ou les calculateurs et l’unité TCU communiquent et échangent des données entre eux par l’intermédiaire d’un ou plusieurs bus informatiques, par exemple un bus de communication de type bus de données CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (selon la norme ISO 17458) ou Ethernet (selon la norme ISO/IEC 802-3).

Le véhicule 10 est en outre avantageusement relié en communication sans fil avec un dispositif distant tel que le dispositif distant 111 via le « cloud » 100, un tel dispositif distant étant par exemple configuré pour communiquer avec le véhicule 10 selon une connexion de type OTA. Le dispositif distant 111 est par exemple configuré pour gérer les logiciels (de l’anglais « software », correspondant par exemple à un firmware ou à tout logiciel nécessaire au bon fonctionnement du véhicule 10) embarqués dans le véhicule 10, notamment les mises à jour logicielles à effectuer pour maintenir l’ensemble des logiciels embarqués et installés dans le véhicule 10 (pour mise en œuvre par un ensemble de calculateurs).

Ainsi, le dispositif distant 111 transmet à destination du véhicule 10 un ensemble d’informations et/ou instructions relatives aux mises à jour logicielles à mettre en œuvre (par exemple version du logiciel, identifiant du logiciel, calculateur et/ou système embarqué impacté par la mise à jour, volumes de données de la mise à jour, durée d’installation requise, etc.). La transmission des informations est par exemple effectuée à intervalles réguliers (par exemple tous les jours, toutes les semaines ou tous les mois) ou à chaque fois qu’une mise à jour logicielle est disponible sur le dispositif distant 111 pour le véhicule 10 (selon par exemple le type du véhicule 10 et/ou selon les systèmes embarqués).

Le dispositif distant 111 transmet également les données de mises à jour du ou des logiciels à mettre à jour dans le véhicule 10 via une connexion de type OTA, par exemple sur requête du véhicule 10 qui télécharge alors ces données du dispositif distant 111 ou selon un mode dit « Push » (ou « pousser » en français), c’est-à-dire à l’initiative du dispositif distant 111 qui transmet les données au véhicule 10 qui les stocke en mémoire avant installation de la ou les mises à jour logicielles associées.

Un processus de contrôle de mise à jour logicielle du véhicule 10 est avantageusement mis en œuvre par un ou plusieurs processeurs d’un système embarqué du véhicule 10.

Dans une première opération, des premières données représentatives d’un historique d’utilisation du véhicule 10 sont reçues.

Les premières données comprennent des données représentatives d’un ensemble de localisations géographiques historiques du véhicule 10 et des données représentatives d’un ensemble de valeurs horodatées d’un ensemble de paramètres d’utilisation du véhicule 10.

Les données représentatives d’un ensemble de localisations géographiques historiques du véhicule 10 sont par exemple obtenues d’un système de géolocalisation embarqué dans le véhicule 10. Elles permettent, par exemple, de définir une zone ou une région dans laquelle circule couramment le véhicule 10 ou des endroits où le véhicule 10 est régulièrement stationné, par exemple au domicile d’un utilisateur du véhicule 10, sur son lieu de travail ou sur un parking d’un supermarché.

Les données représentatives d’un ensemble de valeurs horodatées d’un ensemble de paramètres d’utilisation du véhicule 10 permettent de déterminer quand le véhicule 10 est utilisé. Par exemple, l’ensemble de paramètres comprend tout ou partie des paramètres suivants :
- un paramètre représentatif d’un allumage d’un système électrique du véhicule 10,
- un paramètre représentatif d’un allumage, d’une rotation et/ou d’un arrêt d’un moteur du véhicule 10,
- un paramètre représentatif d’une immobilisation du véhicule 10 par exemple à partir de données de géolocalisation, ou
- un paramètre représentatif d’un état de charge d’une batterie du véhicule 10.

Selon un exemple de réalisation particulier, les premières données comprennent en outre des données d’horodatage d’au moins une mise à jour logicielle antérieure et/ou une géolocalisation associée à cette mise à jour logicielle. La connaissance de ces données permet par exemple de connaître les conditions réunies lorsqu’une précédente mise à jour logicielle a été mise en œuvre. La probabilité que ces conditions représentent des conditions idéales pour effectuer une mise à jour logicielle est alors très forte.

Dans une deuxième opération, des deuxièmes données représentatives d’un instant temporel courant et d’une localisation géographique courante du véhicule 10 sont reçues.

Les données représentatives d’une localisation géographique courante du véhicule 10 sont par exemple reçues d’un système de géolocalisation embarqué par le véhicule 10.

La localisation courante permet par exemple de déterminer le type de route ou d’aire de stationnement sur laquelle se situe le véhicule 10.

Le type de route est par exemple :
- une autoroute ou voie rapide, ou
- une route en milieu urbain ou extra-urbain.

Le type d’aire de stationnement est par exemple :
- une aire de repos,
- une station-service ou aire de recharge,
- un parking de centre commercial ou supermarché,
- un lieu de garage,
- un parking privé d’une entreprise.

Selon un exemple de réalisation particulier, le procédé comprend en outre une étape de réception de troisièmes données représentatives d’une disponibilité d’un service après-vente.

Le service après-vente, dit SAV, est par exemple un service après-vente en lien avec
- le véhicule 10, par exemple le constructeur, le concessionnaire ou un garage,
- le système embarqué du véhicule 10 qui reçoit la mise à jour logicielle, par exemple un équipementier,
- un fournisseur de service en charge de la maintenance du véhicule 10, par exemple un prestataire de services, un loueur, un gestionnaire de flotte.

Le SAV est notamment compétent en cas d’échec de la mise à jour logicielle ou pour guider un utilisateur lors de la mise à jour logicielle. Il est par exemple joignable par internet, par téléphone ou par tout autre moyen de communication.

Sa disponibilité est par exemple définie en fonction des jours de la semaine et en fonction des heures, par exemple le SAV est disponible les jours ouvrés entre 8h et 18h, ou 7 jours/7 et 24h/24.

Dans une troisième opération, un instant temporel de mise à jour logicielle du véhicule 10 est déterminé en fonction des premières et deuxièmes données.

Cette première détermination est, par exemple, mise en œuvre par une méthode d’intelligence artificielle ou par des algorithmes d’apprentissage automatique.

Selon un exemple de réalisation particulier, l’instant temporel de mise à jour logicielle du véhicule 10 est également déterminé en fonction des troisièmes données.

La première détermination consiste à déterminer le moment le plus adéquat ou opportun pour contrôler la mise à jour logicielle, c’est-à-dire quand un ensemble de conditions sont réunies. Les conditions sont par exemple réunies lorsqu’au moins une partie des conditions suivantes sont vérifiées :
- le véhicule 10 est dans ou proche d’une zone dans laquelle circule couramment le véhicule 10,
- le véhicule 10 n’est pas utilisé et devrait rester stationné un long moment,
- la charge d’une batterie du véhicule 10 est supérieure à un seuil,
- un SAV est disponible (dans l’exemple où des troisièmes données sont reçues), et
- le véhicule 10 est relié à un dispositif distant 111.

Des priorités ou une hiérarchisation des conditions précédemment décrites est par exemple définie à l’aide d’indices de pondération que prend en compte l’algorithme ou l’intelligence artificielle.

Par exemple, il est plus important que le véhicule soit stationné plutôt qu’un SAV soit disponible. En effet, en cas de problème lors de la mise à jour logicielle, un utilisateur à bord du véhicule 10 est davantage en difficulté si ce dernier est sur une voie rapide même si le SAV est disponible que si le véhicule 10 est stationné devant son domicile et que la mise à jour logicielle est contrôlée alors qu’un SAV n’est pas disponible.

Selon un exemple particulier de réalisation, la condition vérifiant que le véhicule 10 est dans une zone ou proche d’une zone dans laquelle il circule couramment comprend les opérations suivantes.

Dans une quatrième opération, une distance est déterminée entre la localisation géographique courante du véhicule 10 et une localisation géographique historique de l’ensemble de localisations géographiques historiques la plus proche de ladite localisation géographique courante, c’est-à-dire une distance entre la position courante du véhicule 10 et la zone dans laquelle il circule couramment.

Dans une cinquième opération, cette distance est comparée à une valeur seuil. Une telle valeur seuil est définie en kilomètres, elle vaut par exemple 10km ou 50km. Ainsi, si la position courante du véhicule se situe à 500km de la zone dans laquelle il circule couramment, par exemple si un utilisateur du véhicule 10 est parti avec le véhicule 10 en vacances ou en déplacement professionnel, alors d’après la comparaison à une valeur seuil, par exemple 50km, le véhicule 10 est considéré comme en dehors de la zone dans laquelle il circule couramment. Un instant temporel de mise à jour logicielle du véhicule 10 est notamment déterminé en fonction du résultat de cette comparaison.

Selon un exemple de réalisation particulier, dans une sixième opération, au moins un objet graphique est affiché sur un écran tactile du véhicule 10.

Les objets graphiques permettent par exemple d’informer un utilisateur de l’instant temporel de mise à jour logicielle du véhicule 10 précédemment déterminé et de laisser la possibilité à l’utilisateur de valider cet instant temporel, de le reporter ou de refuser la mise à jour logicielle.

Selon un autre exemple de réalisation particulier, un objet graphique est affiché sur un écran du véhicule 10 et la validation est effectuées à l’aide d’un bouton physique.

Selon encore un autre exemple de réalisation particulier, l’utilisateur est averti qu’une mise à jour logicielle est planifiée à l’instant temporel précédemment déterminé, la validation de cet instant temporel est alors tacite sans action particulière du conducteur.

Dans une septième opération, une information de validation de la mise à jour logicielle du véhicule 10 à l’instant temporel de mise à jour précédemment déterminé est reçue.

L’information de validation correspond par exemple à des cinquièmes données représentatives d’un appui tactile sur un objet graphique affiché sur un écran tactile du véhicule.

Dans une huitième opération, la mise à jour logicielle est contrôlée en fonction de l’information de validation et en fonction de l’instant temporel de mise à jour précédemment déterminé.

Selon un exemple de réalisation particulier, le contrôle de la mise à jour logicielle comprend en outre le téléchargement de quatrièmes données comprenant des informations et instructions pour la mise à jour logicielle, par exemple depuis le dispositif distant 111.

Un tel processus permet ainsi de déterminer un instant temporel idéal, c’est à dire de planifier une mise à jour logicielle du véhicule 10 en fonction de données historiques et de données courantes afin de proposer à un utilisateur de mettre en œuvre la mise à jour logicielle à un instant temporel déterminé. Ainsi, un utilisateur validera facilement la mise à jour logicielle du véhicule à un tel instant temporel.

La mise à jour logicielle à cet instant temporel déterminé permet quant à elle d’être contrôlée à un instant temporel ne gênant pas l’utilisateur. De plus, en cas d’échec ou de problème technique, l’utilisateur ne se trouve pas en grande difficulté.

LaFIG. 2illustre schématiquement un dispositif 2 configuré pour le contrôle de la mise à jour logicielle d’un véhicule, par exemple du véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif 2 correspond par exemple à un calculateur ou un dispositif du système embarqué du véhicule 10.

Selon une variante de réalisation, le dispositif 2 correspond à un dispositif de traitement de données de type serveur, tel que le dispositif distant 111.

Le dispositif 2 est par exemple configuré pour la mise en œuvre des opérations décrites en regard de laFIG. 1et/ou des étapes du procédé décrit en regard de laFIG. 3. Des exemples d’un tel dispositif 2 comprennent, sans y être limités, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), un téléphone intelligent, une tablette, un ordinateur portable, un serveur. Les éléments du dispositif 2, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 2 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels.

Le dispositif 2 comprend un (ou plusieurs) processeur(s) 20 configurés pour exécuter des instructions pour la réalisation des étapes du procédé et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 2. Le processeur 20 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 2 comprend en outre au moins une mémoire 21 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique.

Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la mémoire 21.

Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif 2 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés.

Selon un exemple de réalisation particulier et non limitatif, le dispositif 2 comprend un bloc 22 d’éléments d’interface pour communiquer avec des dispositifs externes. Les éléments d’interface du bloc 22 comprennent une ou plusieurs des interfaces suivantes :
- interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ;
- interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
- interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ;
- interface LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »).

Selon un autre exemple de réalisation particulier et non limitatif, le dispositif 2 comprend une interface de communication 23 qui permet d’établir une communication avec d’autres dispositifs (tels que d’autres calculateurs du système embarqué) via un canal de communication 230. L’interface de communication 23 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 230. L’interface de communication 23 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458) ou Ethernet (standardisé par la norme ISO/IEC 802-3).

Selon un exemple de réalisation particulier et non limitatif, le dispositif 2 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage 240, tactile ou non, un ou des haut-parleurs 250 et/ou d’autres périphériques 260 (système de projection) via respectivement des interfaces de sortie 24, 25 et 26. Selon une variante, l’un ou l’autre des dispositifs externes est intégré au dispositif 2.

LaFIG. 3illustre un organigramme des différentes étapes d’un procédé de contrôle de mise à jour logicielle d’un véhicule, par exemple du véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le procédé est par exemple mis en œuvre par un dispositif du système embarqué du véhicule 10 ou par le dispositif 2 de laFIG. 2.

Dans une première étape 31, des premières données représentatives d’un historique d’utilisation du véhicule sont reçues, les premières données comprenant des données représentatives d’un ensemble de localisations géographiques historiques du véhicule 10 et des données représentatives d’un ensemble de valeurs horodatées d’un ensemble de paramètres d’utilisation du véhicule 10.

Dans une deuxième étape 32, des deuxièmes données représentatives d’un instant temporel courant et d’une localisation géographique courante du véhicule 10 sont reçues.

Dans une troisième étape 33, un instant temporel de mise à jour logicielle du véhicule 10 est déterminé en fonction des premières et deuxièmes données.

Dans une quatrième étape 34, une information de validation de la mise à jour logicielle du véhicule 10 à l’instant temporel de mise à jour logicielle est reçue.

Dans une cinquième étape 35, la mise à jour logicielle est contrôlée en fonction de l’information de validation et de l’instant temporel de mise à jour logicielle.

Selon une variante, les variantes et exemples des opérations décrits en relation avec laFIG. 1s’appliquent aux étapes du procédé de laFIG. 3.

Selon une variante, les variantes et exemples des opérations décrits en relation avec laFIG. 1s’appliquent aux étapes du procédé de laFIG. 3.

Claims (10)

1. Procédé de contrôle de mise à jour logicielle d’un véhicule (10), ledit procédé comprenant les étapes suivantes :
   - réception (31) de premières données représentatives d’un historique d’utilisation dudit véhicule, lesdites premières données comprenant des données représentatives d’un ensemble de localisations géographiques historiques dudit véhicule (10) et des données représentatives d’un ensemble de valeurs horodatées d’un ensemble de paramètres d’utilisation dudit véhicule (10) ;
   - réception (32) de deuxièmes données représentatives d’un instant temporel courant et d’une localisation géographique courante dudit véhicule (10) ;
   - première détermination (33) d’un instant temporel de mise à jour logicielle dudit véhicule (10) en fonction desdites premières et deuxièmes données ;
   - réception d’une information de validation (34) de ladite mise à jour logicielle dudit véhicule (10) audit instant temporel de mise à jour logicielle ; et
   - contrôle (35) de ladite mise à jour logicielle en fonction de ladite information de validation et dudit instant temporel de mise à jour logicielle.
2. Procédé selon la revendication 1, lequel comprend en outre une étape de réception de troisièmes données représentatives d’une disponibilité d’un service après-vente, ladite première détermination (33) étant en outre fonction des troisièmes données.
3. Procédé selon la revendication 1 ou 2, pour lequel lesdites premières données comprennent en outre des données d’horodatage d’au moins une mise à jour logicielle antérieure dudit véhicule (10).
4. Procédé selon l’une des revendications 1 à 3, lequel comprend en outre une étape de téléchargement de quatrièmes données comprenant des informations et instructions pour ladite mise à jour logicielle.
5. Procédé selon l’une des revendications 1 à 4, pour lequel ladite information de validation correspond à des cinquièmes données représentatives d’un appui tactile sur un objet graphique affiché sur un écran tactile dudit véhicule (10).
6. Procédé selon l’une des revendications 1 à 5, pour lequel ladite première détermination (33) comprend les étapes de :
   - deuxième détermination d’une distance entre ladite localisation géographique courante et une localisation géographique historique de l’ensemble de localisations géographiques historiques la plus proche de ladite localisation géographique courante ;
   - comparaison de ladite distance à une valeur seuil ;
   ladite première détermination (33) étant en outre fonction d’un résultat de ladite comparaison.
7. Procédé selon l’une des revendications 1 à 6, pour lequel ladite première détermination (33) est mise en œuvre par une méthode d’intelligence artificielle.
8. Programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur.
9. Dispositif (2) de contrôle de mise à jour logicielle d’un véhicule, ledit dispositif (2) comprenant une mémoire (21) associée à au moins un processeur (20) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 7.
10. Véhicule (10) comprenant le dispositif (2) selon la revendication 9.