Brevet FR3146360A1 — publié le 20240906

L’invention concerne un procédé de contrôle d’une mise à jour logicielle d’un véhicule, comprenant la détection (203) d’une coupure de contact du véhicule. Il est ensuite déterminé (204) si un moteur du véhicule est en fonctionnement immédiatement avant la coupure de contact détectée. Il est vérifié (206) au moins une condition de mise à jour logicielle du véhicule, uniquement s’il est déterminé que le véhicule était en fonctionnement immédiatement avant la coupure de contact. La mise à jour logicielle du véhicule est proposée (207) à un utilisateur du véhicule, en fonction de la vérification de ladite au moins une condition de mise à jour logicielle. FIG. 2 Mise à jour logicielle sur arrêt volontaire d’un véhicule La présente invention appartient au domaine de la mise à jour logicielle d’au moins un composant ou calculateur d’un système embarqué d’un véhicule automobile, notamment au contrôle d’une telle mise à jour logicielle. Elle est particulièrement avantageuse dans le contexte de véhicules comprenant un système embarqué nécessitant une mise à jour régulière de certaines fonctions ou de certains calculateurs. On entend par « véhicule » tout type de véhicule tel qu’un véhicule automobile, un cyclomoteur, une motocyclette, un robot de stockage dans un entrepôt, etc. Les système embarqués de véhicule automobile comprennent généralement des composants logiciels ou calculateurs qui peuvent être mis à jour, par le constructeur notamment, par une liaison sans fil de type OTA, pour « Over The Air » en anglais, ou FOTA, pour « Firmware Over The Air » en anglais. Toutefois, le lancement de la mise à jour sur le véhicule implique l’indisponibilité du véhicule pour remplir d’autres fonctions, notamment pour la conduite du véhicule, pendant plusieurs minutes voire plus d’une heure. Il peut notamment être prévu de proposer une mise à jour logicielle du véhicule, lorsqu’une telle mise à jour logicielle est disponible/nécessaire, suite à la coupure de contact du véhicule. Toutefois, une telle coupure de contact du véhicule peut être consécutive à une situation dans laquelle le véhicule a calé. Dans cette situation, le conducteur doit mettre le véhicule hors contact puis doit remettre le contact afin de redémarrer le moteur. Une telle coupure de contact peut alors induire une proposition de mise à jour logicielle du véhicule au conducteur, alors même que le conducteur se trouve dans une situation de conduite dans laquelle il doit réagir rapidement pour redémarrer, afin de ne pas gêner les autres utilisateurs de la route, voire afin de ne pas engendrer de situation dangereuse. La proposition de mise à jour logicielle perturbe ainsi le conducteur dans une telle situation d’urgence. En outre, si le conducteur valide par inadvertance la proposition de mise à jour logicielle, le véhicule se retrouve immobilisé durant plusieurs minutes, voire plus d’une heure, ce qui induit une situation inacceptable. Il existe donc un besoin de contrôler la mise à jour logicielle d’un véhicule de manière à ne pas induire de situation de conduite dangereuse. La présente invention améliore la situation. A cet effet, un premier aspect de l’invention concerne un procédé de contrôle d’une mise à jour logicielle d’un véhicule, le procédé étant mis en œuvre dans un dispositif de contrôle du véhicule et comprenant les étapes suivantes : - détecter une coupure de contact du véhicule ; - déterminer l’état de fonctionnement d’un moteur du véhicule avant la coupure de contact détectée ; - vérifier les conditions de mise à jour logicielle du véhicule, uniquement s’il est déterminé que le véhicule était en fonctionnement immédiatement avant la coupure de contact ; - proposer la mise à jour logicielle du véhicule à un utilisateur du véhicule, en fonction de la vérification des conditions de mise à jour logicielle. Ainsi, la proposition de mise à jour logicielle n’est faite qu’en cas d’arrêt volontaire du véhicule. En effet, le dispositif de contrôle peut discriminer entre une telle situation d’arrêt volontaire, et une situation dans laquelle le véhicule a calé et dans laquelle le conducteur coupe le contact pour pouvoir redémarrer le moteur et reprendre la conduite. Selon des modes de réalisation, la mise à jour logicielle est proposée avant une prochaine mise en contact du véhicule. Ainsi, la mise à jour logicielle peut être effectuée lorsque le véhicule est hors contact, ce qui minimise l’indisponibilité du véhicule pour l’utilisateur. Selon des modes de réalisation, la vérification de conditions de mise à jour logicielle du véhicule peut comprendre la vérification de disponibilité d’une mise à jour logicielle sur un serveur distant, la réception depuis le serveur distant d’un message de disponibilité de mise à jour logicielle et/ou la comparaison d’une durée depuis une dernière mise à jour logicielle avec une durée seuil prédéterminée. Ainsi, la mise à jour logicielle n’est proposée que lorsqu’elle est disponible et/ou nécessaire, ce qui permet d’éviter de solliciter inutilement le conducteur. Selon des modes de réalisation, la proposition de la mise à jour logicielle peut comprendre l’affichage d’un message de proposition de mise à jour logicielle du véhicule sur une interface homme machine du véhicule, et le procédé comprend en outre la réception d’une entrée utilisateur sur ladite interface homme machine suite à l’affichage du message de proposition. Ainsi, le conducteur peut décider du moment de la mise en œuvre de la mise à jour logicielle. En complément, lorsque l’entrée utilisateur sur l’interface est une confirmation, le procédé peut comprendre en outre l’exécution de la mise à jour logicielle. Ainsi, la mise à jour logicielle n’est mise en œuvre qu’avec l’accord du conducteur. Selon des modes de réalisation, la détection de coupure du contact du véhicule peut comprendre la détection d’une rotation de clé ou la détection d’un appui sur un bouton d’arrêt du véhicule. Ainsi, la coupure de contact est détectée dès l’action du conducteur sur une interface de contact du véhicule. Un deuxième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l’invention concerne un dispositif de contrôle d’un véhicule, le dispositif de contrôle comprenant un processeur configuré pour : - détecter une coupure de contact du véhicule automobile ; - déterminer un état de fonctionnement d’un moteur du véhicule avant la coupure de contact détectée ; - vérifier des conditions de mise à jour logicielle du véhicule, uniquement s’il est déterminé que le véhicule était en fonctionnement immédiatement avant la coupure de contact ; - proposer la mise à jour logicielle du véhicule à un utilisateur du véhicule, en fonction de la vérification des conditions de mise à jour logicielle. Un quatrième aspect de l’invention concerne un véhicule automobile comprenant un dispositif de contrôle selon le troisième aspect de l’invention, et comprenant en outre une interface sans fil apte à obtenir des données de mises à jour logicielle depuis un serveur distant. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : illustre un véhicule selon un mode de réalisation de l’invention; est un diagramme illustrant les étapes d’un procédé de contrôle de la mise à jour logicielle d’un véhicule, selon des modes de réalisation de l’invention ; illustre la structure d’un dispositif de contrôle selon des modes de réalisation de l’invention. La présente un véhicule 100 selon un mode de réalisation de l’invention. Le véhicule 100 comprend un dispositif de contrôle 101. Le dispositif de contrôle 101 peut être un élément de type ECU, pour « Electronic Control Unit » en anglais, en charge du contrôle centralisé du véhicule. En variante, le dispositif de contrôle 101 est une unité de contrôle spécifique, en charge d’un sous-ensemble de fonctions du véhicule. Le dispositif de contrôle 101 est apte à échanger avec une interface homme machine, ou IHM, 102. L’IHM 102 est apte à permettre au dispositif de contrôle 101 d’échanger des informations avec le conducteur ou avec des passagers du véhicule 100. Aucune restriction n’est attachée à l’IHM 102, qui comprend tout élément permettant soit de recevoir une entrée de l’utilisateur, que cette entrée utilisateur soit relative au pilotage du véhicule ou au contrôle d’équipements intérieurs, soit de transmettre des informations à l’utilisateur. A cet effet, l’IHM peut comprendre un écran, tel qu’un écran tactile, un ensemble d’un ou de plusieurs boutons, un haut-parleur, un microphone, un tableau de bord apte à afficher un ou plusieurs pictogrammes lumineux de formes prédéfinies, un système de vibration du volant, un système de pilotage manuel du véhicule comprenant un volant, une pédale d’accélération, etc. De manière préférentielle, l’IHM 102 est capable de transmettre des données visuelles et/ou sonore au conducteur du véhicule. De manière complémentaire, le conducteur ou les passagers peuvent en outre saisir des informations via l’IHM 102, pour transmission au dispositif de contrôle 101, via un bouton, une commande tactile, une commande vocale, ou tout autre type d’entrée utilisateur. Bien entendu, le véhicule 100 comprend en outre un moteur 106, tel qu’un moteur thermique, électrique ou hybride. Le dispositif de contrôle 101 est apte à déterminer un état de fonctionnement du moteur 106, parmi un état activé, ou « en fonctionnement », et un état désactivé. Aucune restriction n’est attachée à la détermination d’un tel état de fonctionnement qui est bien connue de la personne du métier. Le dispositif de contrôle 101 peut en outre être apte à activer/désactiver le moteur 106, en fonction notamment de commandes reçues depuis une unité de détection 105 apte à détecter une action de l’utilisateur sur une interface de contact 104. L’interface de contact 104 peut faire partie de l’IHM 102 précédemment décrite. Le moteur 106 peut également être mis à l’arrêt de manière involontaire, notamment lorsque le véhicule cale. De manière plus générale, l’unité de détection 105 est apte à déterminer l’état de l’interface de contact 104, parmi plusieurs états prédéterminés. L’interface de contact 104 peut comprendre une interface apte à recevoir une clé du véhicule 100 que possède le conducteur, et à recevoir un effort de rotation de ladite clé, afin de basculer l’interface de contact 104 entre plusieurs positions prédéterminées, ou états prédéterminés. Par exemple, l’interface de contact 104 peut comprendre deux positions prédéterminées : une position d’arrêt, ou de coupure de contact, et une position de contact. Une rotation au-delà de la position de contact, associée à un appui sur une pédale du véhicule 100, peut induire le démarrage du moteur 106. L’unité de détection 105 est apte à détecter la position de l’interface de contact parmi ces positions. En variante, l’interface de contact 104 peut être un bouton marche/arrêt. L’appui sur le bouton marche/arrêt, lorsque le véhicule est hors contact, induit l’activation de fonctions du véhicule, ainsi que l’activation du moteur 106. L’activation du moteur 106 peut alternativement être obtenue par un deuxième appui sur le bouton marche/arrêt, ou par un appui prolongé. Dans ce cas, l’unité de détection 105 est apte à générer un signal électrique lors de l’appui sur l’interface de contact 104, signal électrique qui est transmis au dispositif de contrôle 101, qui peut ainsi déterminer l’état de l’interface de contact, et commander le moteur 106 en conséquence. Encore en variante, l’interface de contact 104 peut comprendre à la fois un réceptacle de clé électronique et un bouton marche/arrêt. L’unité de détection 105 est apte à détecter l’insertion ou l’absence d’insertion de la clé électronique dans le réceptacle. L’appui sur le bouton marche/arrêt, lorsque le véhicule est hors contact, provoque l’activation de fonctions du véhicule, et éventuellement l’activation du moteur 106, uniquement si la carte électronique est détectée comme étant insérée dans le réceptacle, par l’unité de détection 105. Le véhicule 100 peut comprendre en outre une interface 103 sans fil, apte à communiquer avec des entités externes au véhicule, par radiofréquences notamment. Une telle liaison peut être appelée OTA. Le véhicule 100 peut notamment échanger avec un serveur distant via l’interface 103 afin de recevoir des données de mise à jour logicielle du véhicule, notamment des données de mise à jour logicielle d’un composant logiciel ou calculateur du système embarqué du véhicule, ou d’une ou plusieurs fonctions du système embarqué du véhicule 100. La est un diagramme illustrant les étapes d’un procédé de contrôle de mise à jour logicielle du véhicule 100, selon des modes de réalisation de l’invention. Dans ce qui suit, il est considéré que le procédé est mis en œuvre par un unique dispositif de contrôle 101 précédemment décrit. A une étape 200, une mise en contact du véhicule 100 est détectée, par réception notamment d’un signal depuis l’unité de détection 105. A une étape 201, le dispositif de contrôle 101 détermine que le moteur 106 du véhicule 100 est démarré, soit parce que le dispositif de contrôle 101 a démarré le moteur 106, soit parce que le moteur 106 a été démarré par une autre unité de contrôle et que le dispositif de contrôle 101 a détecté l’état de fonctionnement du moteur comme « en fonctionnement ». De telles étapes 200 et 201 correspondent à une situation classique de démarrage d’un véhicule automobile. A une étape 202, le dispositif de contrôle 101 détecte un arrêt du moteur 106, alors que le véhicule est toujours en contact. Une telle situation correspond à une situation où le véhicule cale. A une étape 203, le dispositif de contrôle 101 détecte une coupure de contact, par exemple par réception d’un signal de coupure de contact de l’unité de détection 105. L’étape 203 peut se produire consécutivement à l’étape 201, sans détection de l’étape 202, auquel cas le moteur 106 est arrêté en même temps que la coupure de contact 203 est détecté. Une telle situation est une situation de conduite dans laquelle le conducteur arrête volontairement son véhicule, notamment après stationnement. En variante, l’étape 203 est consécutive à l’étape 202, c’est à dire qu’il est détecté que le moteur a été coupé à l’étape 202, avant la coupure de contact détectée à l’étape 203. Comme indiqué plus haut, une telle situation correspond à une situation où le véhicule a calé. A une étape 204, suite à la détection de la coupure de contact de l’étape 203, le dispositif de contrôle 101 détermine l’état de fonctionnement du moteur 106 avant la coupure de contact, notamment immédiatement avant la coupure de contact. Une telle détection est basée sur la détection ou non d’un arrêt du moteur à l’étape 202, alors que le véhicule est encore en contact. Le dispositif de contrôle peut notamment maintenir à jour l’état de fonctionnement du moteur et l’état de l’interface de contact, en fonction de signaux qu’il reçoit. Autrement dit, il est déterminé à l’étape 204, si au moment de la détection de coupure de contact de l’étape 203, le moteur 106 est toujours actif ou, si le moteur a été arrêté avant la coupure de contact. A une étape 205, le dispositif de contrôle 101 identifie une situation courante parmi une situation de coupure de contact volontaire par le conducteur, et une situation dans laquelle le véhicule 100 a calé, à partir de la détermination de l’étape 204. Si le dispositif de contrôle 101 détermine à l’étape 205 que la situation courante est une situation dans laquelle le véhicule a calé, c’est à dire une situation dans laquelle l’arrêt du moteur a été détecté à l’étape 202 avant la coupure de contact de l’étape 203, le procédé retourne à l’étape 200 jusqu’à une prochaine mise en contact du véhicule, pour un redémarrage du moteur 106 à une prochaine étape 201. Par conséquent, lorsque le véhicule 100 cale, le conducteur peut redémarrer le véhicule sans être perturbé par une proposition de mise à jour logicielle, ce qui améliore la sécurité et le confort de conduite dans une telle situation. En revanche, lorsque le dispositif de contrôle 101 détermine à l’étape 205 que la situation courante est une situation dans laquelle le moteur 106 a été désactivé de manière volontaire, le procédé passe à l’étape 206. A l’étape 206, le dispositif de contrôle 101 vérifie au moins une condition de mise à jour logicielle du véhicule. Comme décrit précédemment, l’étape 206 est mise en œuvre uniquement s’il est déterminé que le véhicule était en fonctionnement immédiatement avant la coupure de contact, à l’étape 204. On entend par condition de mise à jour logicielle, au moins un critère prédéfini qui doit être rempli pour qu’une mise à jour logicielle soit proposée au conducteur. Aucune restriction n’est attachée à la vérification de la condition de mise à jour logicielle qui peut comprendre l’une ou plusieurs des opérations suivantes : - la comparaison d’une durée depuis une dernière mise à jour logicielle d’un calculateur ou d’un composant du véhicule, avec une durée seuil prédéterminée. Cette condition de mise à jour logicielle est considérée comme vérifiée si la durée depuis la dernière mise à jour est supérieure à la durée seuil prédéterminée, et la mise à jour logicielle est ainsi proposée à l’étape suivante, ce qui permet d’assurer que la mise à jour logicielle est effectuée régulièrement ; - la vérification que des données de mises à jour logicielle pour au moins un composant ou calculateur du véhicule 100, ont été reçues par l’interface de télécommunications 103, et sont stockées en attente dans le véhicule 100. Si de telles données de mise à jour logicielle ont été reçues, la mise à jour logicielle peut être proposée au conducteur à l’étape suivante ; - la vérification auprès d’un serveur distant, via l’interface de télécommunications 103, de la disponibilité d’une mise à jour logicielle pour au moins un composant ou calculateur du véhicule 101. Lorsque le dispositif de contrôle 101 détermine à l’étape 206 que la ou les conditions de mise à jour logicielle ne sont pas vérifiées, le procédé retourne à l’étape 200, durant laquelle une nouvelle mise en contact du véhicule 100 est détectée, puis un redémarrage du moteur 106 du véhicule 100 à une prochaine étape 201. Lorsque le dispositif de contrôle 101 détermine à l’étape 206 que la ou les conditions de mise à jour logicielle sont vérifiées, le dispositif de contrôle 101 commande l’IHM 102 de manière à proposer la mise à jour logicielle du véhicule 100 au conducteur. Un tel message peut être restitué de manière sonore et/ou visuelle par l’IHM 102. Aucune restriction n’est attachée au format de la proposition de la mise à jour logicielle du véhicule 100. A une étape 208, le dispositif de contrôle 101 détermine si l’utilisateur accepte ou refuse la proposition de mise à jour logicielle du véhicule 100, à partir d’une entrée utilisateur reçue par l’IHM 102 et transmise au dispositif de contrôle 101. Aucune restriction n’est attachée à l’entrée utilisateur qui peut être un appui sur un écran tactile, sur un bouton, une commande vocale ou toute autre entrée utilisateur. L’entrée utilisateur correspond ainsi soit à un refus de la mise à jour logicielle, ou un report à un moment ultérieur, soit à une acceptation de la mise à jour logicielle. En cas de refus par le conducteur, le procédé retourne à l’étape 200 jusqu’à une nouvelle mise en contact du véhicule, suivie d’un nouveau démarrage du moteur 106 à une prochaine étape 201. En cas d’acceptation par le conducteur, le dispositif de contrôle 101 active la mise à jour logicielle à une étape 209. Lorsque les données de mise à jour logicielle ont déjà été reçues par le véhicule 100, l’étape 209 comprend la mise à jour logicielle d’au moins un composant ou calculateur du véhicule 100, sur la base des données de mise à jour logicielles reçues. Lorsque les données de mise à jour logicielle n’ont pas été reçues, le dispositif de contrôle 101 peut requérir les données de mise à jour logicielle auprès d’un serveur distant via l’interface 103. Sur réception des données de mise à jour logicielle, la mise à jour logicielle est mise en œuvre pour au moins un composant ou calculateur du véhicule 100. La présente la structure d’un dispositif de contrôle 101 selon un mode de réalisation de l’invention. Le dispositif de contrôle 101 comprend un processeur 301 configuré pour communiquer de manière unidirectionnelle ou bidirectionnelle, via un ou des bus ou via une connexion filaire directe, avec une mémoire 302 telle qu’une mémoire de type « Random Access Memory », RAM, ou une mémoire de type « Read Only Memory », ROM, ou tout autre type de mémoire (Flash, EEPROM, etc). En variante, la mémoire 302 comprend plusieurs mémoires des types précités. La mémoire 302 stocke, de manière permanente ou temporaire, au moins certaines des données utilisées et/ou issues de la mise en œuvre des étapes du procédé selon l’invention illustré en référence à la . En particulier, la mémoire 302 peut stocker de manière temporaire les états d’activation/désactivation du moteur 106 et les états « en contact »/ « hors contact » du véhicule 100, de manière à mettre en œuvre l’étape 204 précédemment décrite. La mémoire 302 peut également stocker les données de mise à jour logicielle reçues depuis le serveur distant via l’interface 103. Le processeur 301 est apte à exécuter des instructions, stockées dans la mémoire 302, pour la mise en œuvre des étapes du procédé selon l’invention, décrites en référence à la . De manière alternative, le processeur 301 peut être remplacé par un microcontrôleur conçu et configuré pour réaliser les étapes du procédé selon l’invention, décrites en référence à la . Le dispositif de contrôle 101 comprend une première interface 303 apte à échanger de manière bidirectionnelle avec l’IHM 102. Le dispositif comprend une deuxième interface 304, apte à communiquer avec l’unité de détection 105 précédemment décrite. Une telle communication peut être unidirectionnelle, de l’unité de détection 105 vers le dispositif de contrôle 101, de manière à recevoir des signaux indiquant l’état de l’interface de contact 104. Le dispositif de contrôle 101 peut en outre comprendre une troisième interface 305 apte à communiquer avec le moteur 106, notamment pour recevoir des signaux indiquant l’état de fonctionnement du moteur 106. Le dispositif de contrôle 101 peut en outre comprendre une quatrième interface 306 apte à communiquer, de manière bidirectionnelle de préférence, avec l’interface 103, de manière notamment à communiquer avec des entités distantes par une liaison de type OTA. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Procédé de contrôle d’une mise à jour logicielle d’un véhicule (100), le procédé étant mis en œuvre dans un dispositif de contrôle (101) du véhicule et comprenant les étapes suivantes : - détecter (203) une coupure de contact du véhicule ; - déterminer (204) un état de fonctionnement du moteur avant la coupure de contact détectée ; - vérifier (206) au moins une condition de mise à jour logicielle du véhicule, uniquement s’il est déterminé que le véhicule était en fonctionnement immédiatement avant la coupure de contact ; - proposer (207) la mise à jour logicielle du véhicule à un utilisateur du véhicule, en fonction de la vérification de ladite au moins une condition de mise à jour logicielle. Procédé selon la revendication 1, dans lequel la mise à jour logicielle est proposée (207) avant une prochaine mise en contact (200) du véhicule (100). Procédé selon la revendication 1 ou 2, dans lequel la vérification (206) de ladite au moins une condition de mise à jour logicielle du véhicule (100) comprend la vérification de disponibilité d’une mise à jour logicielle sur un serveur distant, la réception depuis le serveur distant d’un message de disponibilité de mise à jour logicielle et/ou la comparaison d’une durée depuis une dernière mise à jour logicielle avec une durée seuil prédéterminée. Procédé selon l’une des revendications précédentes, dans lequel la proposition (207) de la mise à jour logicielle comprend l’affichage d’un message de proposition de mise à jour logicielle du véhicule sur une interface homme machine (102) du véhicule (100), et le procédé comprend en outre la réception (208) d’une entrée utilisateur sur ladite interface suite à l’affichage du message de proposition. Procédé selon l’une des revendications 4, dans lequel, lorsque l’entrée utilisateur sur l’interface homme machine (102) est une confirmation, le procédé comprend en outre l’exécution (209) de la mise à jour logicielle. Procédé selon l’une des revendications précédentes, dans lequel la détection (203) de coupure du contact du véhicule comprend la détection d’une rotation de clé ou la détection d’un appui sur un bouton d’arrêt (104) du véhicule (100). Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (301). Dispositif de contrôle (101) d’un véhicule (100), le dispositif de contrôle comprenant un processeur (301) configuré pour : - détecter une coupure de contact du véhicule automobile ; - déterminer si un état de fonctionnement d’un moteur du véhicule avant la coupure de contact détectée ; - vérifier au moins une condition de mise à jour logicielle du véhicule, uniquement s’il est déterminé que le véhicule était en fonctionnement immédiatement avant la coupure de contact ; - proposer la mise à jour logicielle du véhicule à un utilisateur du véhicule, en fonction de la vérification de ladite au moins une condition de mise à jour logicielle. Véhicule automobile (100) comprenant un dispositif de contrôle (101) selon la revendication 8, et comprenant en outre une interface sans fil (103) apte à obtenir des données de mises à jour logicielle depuis un serveur distant.