Brevet FR3013458A1 — publié le 20150522

INTERFACE DE COMMUNICATION VIRTUELLE POUR DIAGNOSTIC DE VEHICULE AUTOMOBILE [0001] L'invention a trait au domaine du télédiagnostic sur un véhicule automobile et plus particulièrement à la virtualisation d'une Interface de Communication Véhicule ou VCI (Vehicle Communication Interface). [0002] Les véhicules actuels comportent des moyens embarqués d'autodiagnostic ou OBD (On-Board Diagnostics), mis en oeuvre par exemple via des calculateurs embarqués, fournissant des informations relatives aux états des différents systèmes électroniques embarqués dans le véhicule (ex : moteur, système de freinage, habitacle). [0003] Ces informations peuvent être utilisées à des fins de diagnostic par les garagistes ou par les constructeurs automobiles, par exemple lors de l'entretien ou la réparation des véhicules. [0004] Afin de pouvoir accéder à ces informations, une solution courante consiste à connecter une carte de communication physique à l'interface standard de communication véhicule VCI, située entre le véhicule et un outil de diagnostic fourni par le constructeur, tel que le logiciel DiagBox chez PEUGEOT CITROEN. [0005] A titre d'exemple, une carte VCI Pass-Thru, basée sur le standard SAE J2534, peut être utilisée pour une transmission directe de données entre les calculateurs d'un véhicule automobile et un outil de diagnostic constructeur. La carte Pass-Thru est connectée d'une part au véhicule, via une prise OBD, et d'autre part à un terminal embarquant l'outil de diagnostic constructeur via une prise USB. [0006] L'utilisation d'un tel dispositif implique la présence de l'utilisateur de l'outil de diagnostic à proximité du véhicule. Cette situation souffre de divers inconvénients. Elle implique notamment une manipulation physique de la liaison par l'utilisateur, l'utilisation d'une liaison physique en fonction de l'outil de diagnostic, et induit des contraintes spatiales liées au dispositif telles que la place occupée en atelier et l'ergonomie du poste de travail requise. [0007] Afin de remédier aux inconvénients précités, il est tentant de s'affranchir de la liaison physique entre l'outil de diagnostic et le véhicule. Ainsi, plusieurs propositions de diagnostic à distance (télédiagnostic) ont déjà été proposées par le passé. [0008] Ainsi, la demande de brevet américain US 2007/0100519 décrit un système de communication à distance d'un véhicule avec une base de données et un programme de diagnostic. Il est prévu un protocole de communication entre le véhicule et le système distant de diagnostic piloté par un utilisateur. [0009] La demande de brevet français FR 2 799 034 décrit un procédé pour le diagnostic d'un véhicule faisant appel à un système récupérant les données et anomalies du véhicule à tester, qui les envoie via une communication sans fil à un système expert qui peut envoyer des requêtes de diagnostic. [0010] La demande de brevet américain US 2008/0221749 décrit une méthode pour établir un diagnostic via une communication sans fil entre le véhicule et un service de diagnostic qui peut être distant. [0011] La demande de brevet américain US 2006/0095174 décrit un service télématique entre un véhicule et un serveur. Il est prévu des fonctionnalités de télédiagnostic. [0012] La demande de brevet américain US 2007/0093924 décrit une interface pour un utilisateur d'un système de télédiagnostic. [0013] Ces solutions reposent cependant sur des outils de téléphonie mobile (GSM, SMS) ou satellitaire, qui doivent donc être intégrées dans les systèmes de diagnostic. De plus, ces solutions proposées sont dépendantes des modes de transmissions envisagés. Ainsi, chaque solution de télédiagnostic proposée nécessite la reconstruction du système de diagnostic dans son ensemble, c'est-à-dire aussi bien de l'outil de diagnostic, des outils associés au mode de communication choisi, ainsi que des moyens de communications embarqués dans le véhicule. [0014] Un premier objectif est de remédier aux inconvénients précités, tout en répondant aux contraintes fonctionnelles. [0015] Un deuxième objectif est de proposer une solution indépendante de l'outil de diagnostic et du mode de communication utilisé avec un véhicule. [0016] Un troisième objectif est de s'affranchir de l'interface physique de communication entre un outil de diagnostic et un véhicule. [0017] Un quatrième objectif est de rendre possible une communication sans fil distante entre un outil de diagnostic quelconque et un véhicule. [0018] Il est proposé, selon un premier aspect, un système de diagnostic d'un véhicule automobile équipé d'un premier module de communication sans fil configuré pour réceptionner une requête de diagnostic selon un premier protocole de communication, ce système de diagnostic comprenant : un outil de diagnostic configuré pour émettre une requête de diagnostic à destination du véhicule automobile selon un deuxième protocole de communication ; un deuxième module de communication sans fil, configuré pour transmettre la requête de diagnostic émise par l'outil de diagnostic selon le deuxième protocole de communication, via un réseau sans fil de communication au premier module de communication sans fil équipant le véhicule automobile ; un module logiciel interfacé entre l'outil de diagnostic et le deuxième module de communication sans fil, ce module logiciel étant configuré pour intercepter la requête de diagnostic émise par l'outil de diagnostic selon le deuxième protocole de communication ; encapsuler la requête de diagnostic interceptée dans une trame selon le premier protocole de communication ; transférer la trame encapsulant la requête de diagnostic au deuxième module de communication sans fil selon le premier protocole de communication. [0019] Avantageusement, dans ce système de diagnostic, le deuxième module de communication sans fil est configuré pour réceptionner une trame selon le premier protocole, la trame encapsulant une réponse à la requête de diagnostic, le module logiciel étant en outre configuré pour intercepter la trame encapsulant la réponse à la requête de diagnostic selon le premier protocole de communication ; décapsuler la trame encapsulant la réponse à la requête de diagnostic selon le premier protocole de communication ; transférer la réponse à la requête de diagnostic à l'outil de diagnostic. [0020] Avantageusement, dans ce système de diagnostic, le premier protocole de communication est un protocole TCP/IP. [0021] Avantageusement, dans ce système de diagnostic, le deuxième protocole de communication est un protocole CAN. [0022] Il est proposé, selon un deuxième aspect, un terminal utilisateur comprenant le système précédemment décrit. [0023] Il est proposé, selon un troisième aspect, une méthode de diagnostic d'un véhicule automobile équipé d'un premier module de communication sans fil configuré pour réceptionner une requête de diagnostic selon un premier protocole de communication, cette méthode de diagnostic comprenant : une étape d'émission d'une requête de diagnostic à destination du véhicule automobile par un outil de diagnostic selon un deuxième protocole de communication , une étape d'interception de la requête de diagnostic émise par l'outil de diagnostic selon le deuxième protocole de communication, par un module logiciel interfacé entre l'outil de diagnostic et un deuxième module de communication sans fil, le deuxième module de communication sans fil étant configuré pour transmettre la requête de diagnostic émise selon le deuxième protocole de communication par l'outil de diagnostic, via un réseau sans fil de communication au premier module de communication sans fil équipant le véhicule automobile ; une étape d'encapsulation la requête de diagnostic interceptée dans une trame selon le premier protocole de communication par le module logiciel ; - une étape de transfert de la trame encapsulant la requête de diagnostic par le module logiciel au deuxième module de communication sans fil selon le premier protocole de communication. [0024] Avantageusement, cette méthode de diagnostic, comprend en outre : une étape de réception par le deuxième module de communication d'une trame selon le premier protocole de communication, la trame encapsulant une réponse à la requête de diagnostic ; une étape d'interception par le module logiciel de la trame encapsulant la réponse à la requête de diagnostic selon le premier protocole de communication ; une étape de décapsulation par le module logiciel selon le premier protocole de communication de la trame encapsulant la réponse à la requête de diagnostic ; une étape de transfert par le module logiciel de la réponse à la requête à l'outil de diagnostic. [0025] Avantageusement, dans cette méthode de diagnostic, le premier protocole de communication est un protocole TCP/IP. [0026] Avantageusement, dans cette méthode de diagnostic, le deuxième protocole de communication est un protocole CAN. [0027] Il est proposé, selon un quatrième aspect, un produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre de la méthode résumée ci-dessus. [0028] D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ci-après de modes de réalisation préférés, laquelle est faite en référence à la figure 1, qui illustre un mode de réalisation. [0029] Afin de remédier aux contraintes engendrées par une liaison physique, il est, ici, proposé de faire communiquer un outil de diagnostic et un véhicule automobile sans passer par une interface VCI. Pour cela, une interface virtuelle VVCI (Virtual VCI) est mise en oeuvre. [0030] En référence à la figure 1, dans un mode de réalisation, un terminal 1 utilisateur comprend un outil de diagnostic 2 automobile, tel que le logiciel Diag Box. [0031] On désigne, ici, par terminal 1 utilisateur, tout dispositif utilisateur bénéficiant d'un ou plusieurs moyens d'affichage de données relatives à un outil de diagnostic 2 automobile embarqué et comprenant au moins un module de communication 3 sans fil (par exemple une carte réseau compatible Wifi, Bluetooth, ou cellulaire), permettant l'échange de données au travers au moins un réseau 4 de communication sans fil (fixe ou mobile), avec au moins un véhicule 5 automobile distant. A titre d'exemple, le terminal 1 utilisateur peut être un ordinateur fixe ou portable, un smartphone ou une tablette. [0032] Un véhicule 5 automobile distant comprend aussi au moins un module de communication 6 sans fil compatible avec le module de communication 3 sans fil du terminal 1 utilisateur, c'est-à-dire permettant la communication avec le terminal 1 utilisateur à travers un réseau 4 sans fil de communication. A titre d'exemple non-limitatif, le réseau 4 sans fil de communication, peut être un réseau Wifi, Bluetooth, 3G ou plus généralement un réseau IP sans fil. [0033] Le véhicule 5 automobile comprend, de plus, au moins un calculateur 7 embarqué capable d'échanger des informations avec au moins le module de communication 6 sans fil. A titre d'exemple, le calculateur 7 embarqué est une unité de commande électronique (ECU) capable de communiquer des informations de diagnostics d'un système électronique du véhicule 5 automobile à un module de communication 6 sans fil. [0034] Le terminal 1 utilisateur comprend quant à lui un module 8 logiciel interfacé (c'est-à-dire comportant des interfaces connectées, assurant la liaison) entre l'outil de diagnostic 2 et le module de communication 3 sans fil. Le module 8 logiciel reproduit de manière virtuelle le comportement réel d'une interface physique VCI. Le module 8 logiciel prend en charge les paramètres, fonctions et protocoles de communication d'une carte de communication Pass-Thru, tels que définis par le standard SAE J2534. [0035] Ainsi, le module 8 logiciel peut éventuellement être interprété comme une carte physique Pass-Thru virtualisée. Le module 8 logiciel fonctionne en arrière plan par rapport à l'outil de diagnostic 2. En fait, le module 8 logiciel est configuré pour implémenter un processus en écoute permanente de deux ports de communication prédéfinis/identifiés, respectivement au niveau de l'outil de diagnostic 2 et au niveau du module 3 de communication sans fil. D'un point de vue utilisateur, l'ensemble des opérations gérées par le module 8 logiciel s'effectue de manière totalement transparente. [0036] Suivant un mode de réalisation préféré, un utilisateur effectue une requête de diagnostic à destination d'au moins un calculateur 7 embarqué dans un véhicule 5 automobile distant. La requête est effectuée via un outil de diagnostic 2. L'outil de diagnostic 2 émet la requête utilisateur, sous la forme d'une trame-requête, selon un premier protocole de communication. Par exemple, une trame selon le protocole CAN à destination d'au moins un calculateur 7 embarqué, est émise par l'outil de diagnostic 2, via un premier port de communication prédéfini. Le module 8 logiciel intercepte, au niveau de ce premier port de communication, la trame-requête associée à la requête de diagnostic utilisateur. Par « intercepter » une trame, on entend ici que le module 8 logiciel récupère, de manière transparente vis-à-vis de l'outil 2 de diagnostic et du module 3 de communication sans fil, une trame n'étant pas supposée avoir pour destination ce module 8 logiciel. [0037] Le module 8 logiciel effectue alors une encapsulation de la trame-requête, selon un deuxième protocole de communication prédéfini. Par exemple, le module 8 logiciel encapsule la trame-requête sous forme TCP/IP dans une trame Ethernet, selon une méthode connue de l'état de l'art. Le module 8 logiciel transfère ensuite la trame encapsulée sur un deuxième port de communication prédéfini, au niveau du module 3 de communication sans fil pour émission. [0038] Le module 3 de communication sans fil, transmet ensuite via le réseau 4 de communication sans fil la trame-requête encapsulée à une adresse IP prédéterminée du véhicule 5 automobile distant. L'adresse IP prédéterminée correspond, par exemple, à un module 6 de communication sans fil spécifique, configuré pour échanger des informations avec au moins un calculateur 7 embarqué. [0039] A réception de la trame encapsulée, le module 6 de communication sans fil décapsule celle-ci, selon le deuxième protocole de communication prédéfini. Le module 6 de communication sans fil envoie alors la requête de diagnostic, par exemple une trame selon le protocole de communication CAN (Controller Area Network), au calculateur 7 embarqué concerné. Le calculateur 7 embarqué, génère en réponse à la requête de diagnostic, une trame-réponse selon le même premier protocole de communication (ex : trame CAN). [0040] Le calculateur 7 embarqué envoie ensuite ladite trame-réponse, au module 6 de communication sans fil pour encapsulation. Le module 6 de communication sans fil effectue l'encapsulation selon le deuxième protocole de communication prédéfini, par exemple sous forme TCP/IP dans une trame Ethernet. La trame-réponse encapsulée, est ensuite transmise à destination terminal utilisateur 1, par le module de communication 6 via le réseau 4 sans fil de communication. La trame-réponse encapsulée, est réceptionnée par le module 3 de communication sans fil du terminal 1 utilisateur. La réception s'effectue au niveau du port utilisé lors de l'émission, c'est-à-dire du deuxième port de communication. Dès la réception de la trame-réponse encapsulée, le module 8 logiciel intercepte puis décapsule celle-ci selon le deuxième protocole de communication. Le module 8 logiciel transfère alors la trame-réponse générée (par le calculateur 7 embarqué) selon le premier protocole de communication, par exemple une trame CAN, à l'outil 2 de diagnostic sur le premier port de communication. [0041] Suite à la réception de la trame-réponse sur le premier port de communication, l'outil 2 de diagnostic peut alors afficher les informations correspondant à la réponse de la requête de diagnostic. En pratique, quel que soit le statut d'une requête utilisateur (en cours de transmission, en attente de réponse, traitée), le module 8 logiciel reste en écoute permanente à la fois du premier port de communication dans l'attente d'intercepter d'éventuelles nouvelles requêtes de diagnostic, et du deuxième port de communication en vue d'intercepter une réponse à une requête de diagnostic spécifique, à transférer à l'outil 2 de diagnostic. [0042] Avantageusement, toutes les opérations effectuées par le module logiciel 8 sont totalement transparentes vis-à-vis de l'outil 2 de diagnostic 2, la trame-réponse fournie à l'outil 2 de diagnostic par le module 8 logiciel étant interprétée par l'outil 2 de diagnostic comme une réponse provenant directement du calculateur auquel une requête a été envoyée. [0043] Avantageusement, l'utilisation du module 8 logiciel permet de s'affranchir des contraintes temporelles imposées par les outils de diagnostics ou liaisons physiques existants (temps de transmissions, réception, « timeouts »). Ainsi, dans un mode de réalisation, le module 8 logiciel gère seul les différentes contraintes temporelles. A titre d'exemple, le niveau d'abstraction du module 8 logiciel permet de faire patienter l'outil 2 de diagnostic tant qu'une réponse attendue d'un calculateur n'a pas encore été reçue, et de gérer les délais d'expiration d'un requête ou encore l'absence d'une réponse de la part d'un calculateur 7 embarqué. [0044] Avantageusement, le module 8 logiciel implémente l'ensemble des caractéristiques techniques d'une interface standard VCI, telles que définies par le standard J2534. Le respect de ce standard permet en effet, de garantir la compatibilité du module 8 logiciel avec n'importe quel outil 2 de diagnostic supportant la norme Pass-Thru, en se faisant reconnaître comme une carte de communication physique Pass-Thru standard. Chaque outil de diagnostic spécifique ne nécessite donc plus une carte de communication Pass-Thru spécifique. De même, l'utilisation du module 8 logiciel ne nécessite aucune modification au niveau de l'outil de diagnostic utilisé. Il est entendu que le standard J2534 est, ici, cité à titre d'exemple non-limitatif, le module logiciel 8 pouvant en effet implémenter toute autre norme supportée par une carte de communication physique. [0045] Le fait de s'affranchir d'une carte de communication physique Pass-Thru et d'utiliser un outil de diagnostic 2 à distance, permet : de s'affranchir des contraintes engendrées par l'utlisation d'une liaison physique (par ex. : ergonomie du poste de travail, manipulation de la liaison par l'utilisateur) ; de pouvoir dialoguer avec n'importe quel élément communicant dans le véhicule 5 et d'obtenir des informations de diagnostic, tant que celui-ci dispose de moyens configurés pour échanger des informations avec un ou plusieurs calculateurs embarqués concernés par une requête de diagnostic. Ainsi, en fonction des scénarios envisagés, il est possible de requérir directement les informations aussi bien d'un (ou plusieurs) calculateur particulier que d'un calculateur central. REVENDICATIONS1. Système de diagnostic de véhicule (5) automobile équipé d'un premier module (6) de communication sans fil configuré pour réceptionner une requête de diagnostic selon un premier protocole de communication, ce système de diagnostic comprenant un outil (2) de diagnostic configuré pour émettre une requête de diagnostic à destination du véhicule (5) automobile selon un deuxième protocole de communication ; - un deuxième module (3) de communication sans fil, configuré pour transmettre la requête de diagnostic émise par l'outil (2) de diagnostic selon le deuxième protocole de communication, via un réseau (4) sans fil de communication au premier module (6) de communication sans fil équipant le véhicule (5) automobile ; le système de diagnostic étant caractérisé en ce qu'il comprend un module (8) logiciel interfacé entre l'outil (2) de diagnostic et le deuxième module (3) de communication sans fil, ce module (8) logiciel étant configuré pour : intercepter la requête de diagnostic émise par l'outil (2) de diagnostic selon le deuxième protocole de communication ; encapsuler la requête de diagnostic interceptée dans une trame selon le premier protocole de communication ; transférer la trame encapsulant la requête de diagnostic au deuxième module (3) de communication sans fil selon le premier protocole de communication. 2. Système de diagnostic selon la revendication 1, dans lequel le deuxième module (3) de communication sans fil est configuré en outre pour réceptionner une trame selon le premier protocole, la trame encapsulant une réponse à la requête de diagnostic, ledit système de diagnostic étant de plus caractérisé en ce que le module (8) logiciel est configuré pour : - intercepter la trame encapsulant la réponse à la requête de diagnostic selon le premier protocole de communication ; décapsuler la trame encapsulant la réponse à la requête de diagnostic selon le premier protocole de communication ; transférer la réponse à la requête de diagnostic à l'outil (2) de diagnostic. 3. Système selon la revendication 1 ou 2, dans lequel le premier protocole de communication est un protocole TCP/IP. 4. Système selon l'une quelconque des revendications 1 à 3, dans lequel le deuxième protocole de communication est un protocole 5 CAN. 5. Terminal (1) utilisateur intégrant un système selon l'une quelconque des revendications 1 à 4. 6. Méthode de diagnostic d'un véhicule (5) automobile équipé d'un premier module de communication (6) sans fil configuré pour 10 réceptionner une requête de diagnostic selon un premier protocole de communication, cette méthode de diagnostic comprenant une étape d'émission d'une requête de diagnostic à destination du véhicule (5) automobile par un outil (2) de diagnostic selon un deuxième protocole de communication ; 15 cette méthode de diagnostic étant caractérisée en ce qu'elle comprend une étape d'interception de la requête de diagnostic émise par l'outil de diagnostic (2) selon le deuxième protocole de communication, par un module logiciel (8) interfacé entre l'outil de diagnostic (2) et un deuxième module de communication (3) sans 20 fil, le deuxième module de communication (3) sans fil étant configuré pour transmettre la requête de diagnostic émise selon le deuxième protocole de communication par l'outil de diagnostic (2), via un réseau (4) sans fil de communication au premier module de communication (6) sans fil équipant le véhicule (5) automobile ; 25 - une étape d'encapsulation la requête de diagnostic interceptée dans une trame selon le premier protocole de communication par le module logiciel (8) ; une étape de transfert de la trame encapsulant la requête de diagnostic par le module logiciel (8) au deuxième module de 30 communication (3) sans fil selon le premier protocole de communication. 7. Méthode de diagnostic selon la revendication 6, comprenant en outre : une étape de réception par le deuxième module (3) de 35 communication d'une trame selon le premier protocole de communication, la trame encapsulant une réponse à la requête de diagnostic ;une étape d'interception par le module (8) logiciel de la trame encapsulant la réponse à la requête de diagnostic selon le premier protocole de communication ; une étape de décapsulation par le module (8) logiciel selon le premier protocole de communication de la trame encapsulant la réponse à la requête de diagnostic ; une étape de transfert par le module (8) logiciel de la réponse à la requête à l'outil de diagnostic (2). 8. Méthode selon la revendication 6 ou la revendication 7, dans 10 laquelle le premier protocole de communication est un protocole TCP/IP. 9. Méthode selon l'une quelconque des revendications 6 à 8, dans laquelle le deuxième protocole de communication est un protocole CAN. 15 10. Produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre de la méthode selon l'une des revendications 6 à 9. 20