Brevet FR3044144A1 — publié le 20170526

PROCEDE DE TENUE D'UNE BASE DE DONNEES DE DEFAUTS D'UN VEHICULE AUTOMOBILE La présente invention concerne de manière générale un procédé de tenue d'une base de données de défauts survenus sur un véhicule automobile, et en particulier, un procédé de tenue d'une base de données de défauts survenus sur un véhicule automobile qui n'est pas effaçable. De manière générale, les véhicules automobiles embarquent une multitude d'organes de surveillance du bon fonctionnement de chaque élément du véhicule. Lorsqu'un défaut ou un dysfonctionnement survient dans le véhicule, celui-ci est donc détecté et ensuite enregistré sous la forme d'une donnée dans un journal de défaut (JDD) dressant une liste des défauts dans un calculateur central tel qu'un boîtier télématique automobile (BTA) ou un boîtier de servitude intelligent (BSI) afin de créer une base de données embarquée dans le véhicule. Un problème de ce type de base de données est qu'elle peut être régulièrement effacée à chaque remise à zéro du journal des défauts par des garagistes lorsque ceux-ci réparent le défaut à la suite d'un dysfonctionnement ou d'un accident, ou alors par des personnes malveillantes souhaitant cacher certains défauts ou modifier l'historique du véhicule dans un but de revente sans pénalité. Egalement, cela implique qu'un espace de stockage/enregistrement soit prévu dans le véhicule pour stocker/enregistrer cette base de données. Afin de palier à ce problème d'espace de stockage, il est connu dans l'art antérieur de communiquer à distance entre un véhicule et un serveur. Par exemple, le document FR 2 876 814 décrit un système de diagnostic à distance d'un véhicule qui transmet les défaillances diagnostiquées à un serveur. Cependant, ce système a pour caractéristique une transmission rapide ayant pour but une prise en charge efficace et présente notamment l'inconvénient de ne pas proposer d'historique des défaillances. 3044144 2 Un but de la présente invention est de répondre aux inconvénients du document de l'art antérieur mentionné ci-dessus et en particulier, tout d'abord, de proposer un procédé de tenue d'une base de données comprenant un historique des défauts et des défaillances survenues sur un 5 véhicule automobile ne pouvant pas être effacées depuis le véhicule et ne nécessitant pas un espace de stockage embarqué sur le véhicule. Pour cela un premier aspect de l'invention concerne un procédé de tenue d'une base de données de défauts d'un véhicule automobile sur un serveur externe, comprenant au moins les étapes consistant à détecter un 10 défaut de fonctionnement dans le véhicule automobile, identifier le défaut, établir une connexion à distance entre un outil de communication embarqué dans le véhicule et le serveur externe, envoyer un signal représentatif du défaut identifié au serveur externe lorsque la connexion est établie, et mettre à jour la base de données de défauts du serveur externe en enregistrant le 15 signal représentatif reçu dans la base de données. Ainsi, il est possible de supprimer l'espace de stockage/enregistrement dans le véhicule tout en permettant de créer et maintenir un historique fiable de l'ensemble des défauts d'un véhicule qui ne risque pas d'être mis à jour et/ou supprimé par une personne ayant accès au véhicule. 20 De manière avantageuse, le procédé comprend en outre, une étape d'enregistrement temporaire d'une information relative au signal du défaut dans un calculateur du véhicule lorsqu'aucune connexion de communication n'est établie. De cette manière, l'historique peut être mis à jour ultérieurement même lorsqu'une absence de connexion est constatée. 25 Une réalisation particulièrement intéressante consiste en ce que l'étape d'envoi du signal est répétée au moins une pluralité de fois avant que l'étape d'enregistrement temporaire soit mise en oeuvre. Ainsi, on évite un enregistrement temporaire inutile en cas d'absence de courte durée de la connexion. Avantageusement, le procédé comprend en outre une étape de réception d'accusé de réception par l'outil de communication embarqué 3044144 3 lorsque l'étape de mise à jour est effectuée. De cette manière, le procédé peut être terminé lorsque la preuve est faite que l'historique a été mis à jour ce qui augmente la fiabilité du procédé. De manière avantageuse, le procédé est agencé pour être mis en 5 oeuvre dans au moins un calculateur embarqué du véhicule. Ainsi, on évite de multiplier les composants dans le véhicule. Une réalisation particulièrement intéressante consiste en ce que dans l'étape de mise à jour, les défauts sont sauvegardés en fonction de leur type, fonction ou liste des symptômes. De cette manière, 1"historique est 10 facilement consultable par la suite. Avantageusement, le signal transmis comprend un code du véhicule émetteur et un code représentant le défaut. Ainsi, il est facile d'établir des catégories de défauts à des buts d'amélioration ultérieurs. De manière avantageuse, le procédé comprend en outre une étape 15 de signalement de mise à jour à une centrale de surveillance. De cette manière, la sécurité des passagers peut être améliorée grâce à une surveillance en temps réel du véhicule. Une réalisation particulièrement intéressante consiste en ce que la communication est une communication satellitaire. Ainsi, on améliore la 20 portée et la vitesse de la communication. De manière avantageuse, un accès au serveur externe stockant la base de données est protégé par un moyen de protection logiciel. De cette manière, la confidentialité de la base de données de défauts peut être améliorée. 25 Un second aspect de l'invention est un véhicule automobile dont au moins un calculateur est agencé pour mettre en oeuvre le procédé selon le premier aspect de l'invention. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description détaillée qui suit 3044144 4 d'un mode de réalisation de l'invention donné à titre d'exemple nullement limitatif et illustré par les dessins annexés, dans lesquels : - la figure 1 représente un schéma structurel général d'une communication à distance entre un véhicule et un serveur externe ; 5 - la figure 2 représente un schéma bloc du procédé de la présente invention. La figure 1 représente un véhicule 20 qui comprend des détecteurs de fonctionnement 22, reliés à une unité centrale 21. Les détecteurs de fonctionnement 22 sont des détecteurs de fonctionnement spécialisés et 10 peuvent être par exemple des détecteurs de fonctionnement de moteur, des détecteurs de fonctionnement de modules de sécurité (airbags), des détecteurs de fonctionnement de la gestion de la stabilité du véhicule (freinage ou ABS, stabilité électronique ou ESP...), ou encore des détecteurs de fonctionnement de la ventilation (climatisation, chauffage). 15 L'unité centrale 21 peut être un boîtier électronique doté de moyens de calculs et de communication à distance par ondes radio à courte ou moyenne ou grande distance. Alternativement, la communication peut se faire par voie satellitaire. En alternative, l'unité centrale 21 peut ne comprendre qu'une partie 20 des moyens de calcul ou au contraire uniquement le moyen de communication à distance. En conclusion, d'une manière générale, le véhicule 20 est doté de moyens de communication sans fil, idéalement dans l'unité centrale, et il est prévu un outil de communication débarqué 10 pour communiquer avec le 25 véhicule 20, ou plus précisément son moyen de communication à distance. En effet, il est prévu d'échanger des données entre l'outil de communication débarqué 10 et le véhicule 20 pour que les défaillances de fonctionnement du véhicule détectées par les détecteurs 22 susmentionnés puissent être transmises et sauvegardées dans une mémoire connectée 11 à l'outil de 30 communication externe 10, tel qu'un serveur externe. En particulier, il peut 3044144 5 être alors possible de dresser une liste exhaustive des défauts et des défaillances du véhicule 20 qui n'est pas accessible à son utilisateur et n'est donc pas effaçable. Il est également possible de mettre à jour cette liste et donc de dresser un historique des défauts à mesure que ceux-ci se 5 produisent et sont rapportés dans la mémoire du serveur. La figure 2 représente schématiquement le procédé de l'invention. L'étape S10 du procédé est une étape qui consiste à détecter un défaut de fonctionnement dans le véhicule automobile au moyen d'au moins un des détecteurs de fonctionnement 22, et à identifier le type de défaut ainsi que la 10 partie du véhicule qu'il affecte de même que sa gravité afin de lui attribuer un code. Il est à noter que l'étape d'identification pour effectuer un codage des défauts en vue de leur transmission est facultative à ce stade est peut être exécutée dans le calculateur après établissement d'une connexion à distance plutôt que par le détecteur en amont de la connexion. Ainsi, on évite 15 une charge de travail inutile au détecteur en cas d'absence de connexion. L'étape S20 consiste à établir une connexion d'une communication sans fil entre le véhicule et un serveur externe, à distance, débarqué du véhicule. Si la tentative de connexion échoue, l'étape S20 est répétée un nombre prédéterminé de fois. Puis, si et seulement si malgré cela, aucune 20 connexion n'est possible, le procédé met en oeuvre une étape d'enregistrement temporaire non représentée dans un organe d'enregistrement embarqué pour une retransmission ultérieure. A contrario, lorsque la connexion est établie, le procédé met en oeuvre une étape d'envoi S30 d'un signal représentatif du défaut identifié précédemment du véhicule 25 au serveur externe. Lorsque le signal est envoyé par l'unité de communication sans fil et reçu par le serveur externe, la base de données est mise à jour S40. Plus précisément, le signal représentatif du défaut comprend un code identifiant le véhicule qui transmet le signal et qui est victime du défaut ainsi qu'un code 30 identifiant le défaut lui-même. Le défaut est alors sauvegardé en fonction de son type, de sa fonction ou d'une liste de symptômes du même genre. 3044144 6 Le moment de mise à jour n'est pas forcément prédéfini, il peut avoir lieu à chaque occurrence de défaut, ou alors par un procédé de mise à jour préétabli suivant un balayage des défauts susceptibles d'avoir eu lieu à une fréquence constante, par exemple à chaque arrêt du moteur. 5 De plus, il est à noter que qu'il est possible que l'ensemble des défauts soit enregistré dans le serveur sans discrimination de gravité. Cependant, il peut être préférable qu'en fonction de la gravité du défaut détecté, celui-soit enregistré et stocké sur le serveur externe ou sur une mémoire locale dans le véhicule. En effet, si un défaut dont la gravité est 10 quasi nulle, qui ne nécessite par exemple pas de réparation, est détecté, il peut être inutile de l'enregistrer sur le serveur dans la mesure où il ne risque pas ou peu d'être effacé. Ainsi, le procédé peut comprendre une étape supplémentaire de quantification de la gravité du défaut suivi d'une étape de sélection de mémoire cible, locale ou externe, pour enregistrement de ce 15 défaut en fonction de la gravité de celui-ci. On peut également prévoir que quelque soit le résultat de la mise à jour, le procédé comprenne une étape qui consiste à envoyer au véhicule le résultat de la mise à jour. On peut aussi envisager d'afficher le résultat de la mise à jour de la liste des défauts à l'utilisateur. De plus, il est relativement 20 important, mais pas essentiel, qu'un accès au serveur externe stockant la base de données soit protégé par un moyen de protection logiciel. Ainsi c'est le fabricant, ou la personne ayant accès au serveur externe, qui peut avoir accès à une consultation de la base de données, sous quelles conditions, par exemple en mode lecture seule, et à quel moment. 25 On comprendra que diverses modifications et/ou améliorations évidentes pour l'homme du métier peuvent être apportées aux différents modes de réalisation de l'invention décrits dans la présente description sans sortir du cadre de l'invention défini par les revendications annexées. REVENDICATIONS1. Procédé de tenue d'une base de données de défauts d'un véhicule automobile sur un serveur externe, comprenant au moins les étapes 5 consistant à : - détecter (S10) un défaut de fonctionnement dans le véhicule automobile, - identifier (510) ledit défaut, - établir (S20) une connexion à distance entre un outil de 10 communication embarqué dans ledit véhicule et le serveur externe, - envoyer (S30) un signal représentatif du défaut identifié au serveur externe lorsque la connexion est établie, et - mettre à jour (S40) la base de données de défauts du serveur externe en enregistrant le signal représentatif reçu dans ladite base de 15 données. 2. Procédé de mise à jour selon la revendication précédente, comprenant en outre, une étape d'enregistrement temporaire d'une information relative au signal du défaut dans un calculateur (21) du véhicule lorsqu'aucune connexion n'est établie. 20 3. Procédé de mise à jour selon la revendication 2, dans lequel l'étape d'envoi du signal est répétée au moins une pluralité de fois avant que l'étape d'enregistrement temporaire soit mise en oeuvre. 4. Procédé de mise à jour selon la revendication précédente, comprenant en outre une étape (S50) de réception d'accusé de réception par 25 l'outil de communication embarqué lorsque l'étape de mise à jour est effectuée. 3044144 8 5. Procédé de mise à jour selon l'une des revendications précédentes, agencé pour être mis en oeuvre dans au moins un calculateur (21) embarqué du véhicule (20). 6. Procédé de mise à jour selon la revendication précédente, dans 5 lequel dans l'étape de mise à jour (S40), les défauts sont sauvegardés en fonction de leur type, fonction ou liste des symptômes. 7. Procédé de mise à jour selon l'une des revendications précédentes, dans lequel le signal transmis comprend un code du véhicule émetteur et un code représentant le défaut. 10 8. Procédé de mise à jour selon l'une des revendications précédentes, comprenant en outre une étape de signalement de mise à jour à une centrale de surveillance. 9. Procédé de mise à jour selon l'une des revendications précédentes, dans lequel un accès au serveur externe stockant ladite base 15 de données est protégé par un moyen de protection logiciel. 10. Véhicule comprenant un dispositif de mise à jour de base de données de défaut agencé pour exécuter le procédé de mise à jour selon l'une des revendications précédentes.