FR2920558A1

FR2920558A1 - Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile

Info

Publication number: FR2920558A1
Application number: FR0757187A
Authority: FR
Inventors: Damien Delcroix
Original assignee: Renault SAS
Current assignee: Renault SAS
Priority date: 2007-08-27
Filing date: 2007-08-27
Publication date: 2009-03-06
Anticipated expiration: 2027-08-27
Also published as: KR20100051080A; FR2920558B1; RU2010111761A; US20110125364A1; JP2010538249A; WO2009027609A1; CN101784973A; EP2181372A1

Abstract

Ce procédé de diagnostic du dysfonctionnement d'un véhicule automobile met en oeuvre un outil de diagnostic et une analyse de données ou commandes de contrôle délivrées par un ensemble de modules de calcul embarqués à bord du véhicule et traduisant le fonctionnement d'un ensemble d'organes fonctionnels du véhicule en affichant dynamiquement les valeurs des données ou les liens vers les commandes au sein même de l'affichage de la méthode de diagnostic. Il comporte les étapes de :- élaboration d'une structure d'affichage enrichie (9) de contrôle du fonctionnement du véhicule ;- élaboration d'une liste (10) de données de contrôle à rafraîchir ;- récupération des données de contrôle rafraîchies en provenance des modules de calcul respectifs ; et- élaboration d'un affichage final (8) à partir de la structure d'affichage enrichie et des données de contrôle rafraîchies,Lesdites étapes d'élaboration de la structure d'affichage enrichie, de la liste des données à rafraîchir, de récupération des données rafraîchies et d'élaboration de l'affichage final étant mises en oeuvre sous le contrôle d'un module de supervision (D).

Description

B07/2992FR ODE/sm

Société par Actions Simplifiée dite : RENAULT s.a.s. Procédé et système de diagnostic du dysfonctionnement d'un véhicule automobile Invention de : Damien DELCROIX

Procédé et système de diagnostic du dysfonctionnement d'un véhicule automobile L'invention se rapporte au diagnostic du dysfonctionnement d'un moyen de transport tel que l'avion ou le bateau plus précisément un véhicule automobile mis en oeuvre dans des ateliers de réparation ou de maintenance. Actuellement, lorsqu'un véhicule présente une panne, c'est-à-dire un dysfonctionnement ou une défaillance, dans le but d'en identifier la cause, on met en oeuvre une méthode de diagnostic, par exemple sous la forme d'un arbre de localisation de la panne qui permet d'aboutir à l'identification d'une cause à partir d'un symptôme, notamment formulé par le propriétaire ou le conducteur du véhicule. Cette méthode de diagnostic est conduite pas à pas et doit aboutir à l'identification de la cause de la défaillance en vue de déterminer la réparation à effectuer sur le véhicule. Généralement, à chaque étape, ou, de manière générale, à une partie au moins des étapes de la méthode de diagnostic, le technicien doit contrôler ou commander des modules de calcul embarqués à bord du véhicule automobile, dans le but de récupérer des données de diagnostic ou d'activer des fonctions interne de ces modules. En parallèle sur cette méthode de diagnostic, qui permet d'aboutir, par étapes successives, à la localisation d'un organe défectueux, le technicien dispose d'un certain nombre de ressources embarquées dans les véhicules. Il a ainsi la possibilité de récupérer des données de diagnostic à partir des modules de calculs du véhicule ou d'activer des fonctions de diagnostic interne de ces modules. Ces ressources délivrent des informations directement accessibles. Elles concernent le fonctionnement d'organes du véhicule dont elles ont la charge. Au cours du diagnostic, le technicien utilise généralement un outil de diagnostic qui intègre un logiciel de diagnostic permettant soit de mettre en oeuvre la méthode de diagnostic, soit de récupérer des données ou activer des commandes de diagnostic issues des modules de calcul. Cette solution présente un certain nombre d'inconvénients majeurs.

En effet, l'outil de diagnostic propose au technicien un certain nombre d'interfaces homme/machine, sous la forme d'écrans qui correspondent soit aux étapes d'une méthode de diagnostic, soit à une visualisation de données de diagnostic issues de modules de calcul, ou encore à l'activation d'une fonction de diagnostic interne au module de calcul. Ainsi, lors du déroulement de la méthode de diagnostic, le technicien peut être amené à contrôler des valeurs de diagnostic issues des modules de calcul par rapport à des valeurs de référence ou à activer une fonction interne de diagnostic pour en comparer les effets à des comportements dits de référence. Cette consultation s'effectue en passant d'un écran à un autre et nécessite un certain nombre de navigations, ce qui engendre, par conséquent, une perte de temps considérable et inutile. En outre, cette solution engendre un risque d'erreurs non négligeable, le passage d'un écran à un autre pouvant engendrer une erreur de consultation, par exemple l'acquisition de données de diagnostic erronées, et donc une erreur de diagnostic. Or, l'acquisition de données de contrôle est une phase nécessaire, dans la mesure où, en fonction du résultat du contrôle, la méthode de diagnostic peut se poursuivre vers différentes étapes ultérieures, en fonction de la valeur de la donnée contrôlée. Au vu de ce qui précède, il existe un besoin pour disposer d'un outil de diagnostic permettant à un utilisateur d'utiliser à la fois une méthode de diagnostic permettant d'aboutir à la localisation et à une identification d'une défaillance ou d'une panne, et des données ou commandes provenant de modules de calcul embarqués à bord du véhicule et ce, au sein d'une même interface homme/machine. L'invention a donc pour objet, selon un premier aspect, un procédé de diagnostic du dysfonctionnement d'un véhicule automobile par mise en oeuvre d'un outil de diagnostic et par analyse de données ou commandes de contrôle disponibles auprès d'un ensemble de modules de calcul embarqués à bord du véhicule automobile et traduisant le fonctionnement d'un ensemble d'organes fonctionnels du véhicule. Selon une caractéristique générale de ce procédé, celui-ci comporte les étapes de : - élaboration d'une structure d'affichage enrichie décrivant un enchaînement d'opérations de contrôle à réaliser sur le véhicule enrichies de données ou commandes de contrôle ; - élaboration d'une liste de données de contrôle à rafraîchir ; - récupération des données de contrôle rafraîchies en provenance des modules de calcul respectifs ; - élaboration d'un affichage final à partir de la structure d'affichage enrichie et des données de contrôle rafraîchies, Lesdites étapes d'élaboration de la structure d'affichage enrichie, de la liste de données à rafraîchir, de récupération des données rafraîchies et d'élaboration de l'affichage final étant mises en oeuvre sous le contrôle d'un module de supervision.

Selon une autre caractéristique de ce procédé, au cours de l'élaboration de la liste de données de contrôle à rafraîchir, on élabore des requêtes de diagnostic à partir d'une base contenant, pour chaque module de calcul, la description des requêtes de diagnostic. Par ailleurs, au cours de la récupération des données de contrôle, on décode, par exemple, une ou plusieurs réponses transmises par les modules de calcul. On peut en outre mettre à jour un fichier de données de contrôle rafraîchies à partir des données de contrôle récupérées. Selon encore une autre caractéristique du procédé, l'affichage final peut ainsi être élaboré à partir de la structure d'affichage et de paramètres d'affichage extraits d'une base de données d'affichage qui correspondent à une interface homme/machine sur laquelle l'affichage final est destiné à être visualisé.

Selon encore une autre caractéristique du procédé selon l'invention, au cours de l'élaboration de la structure d'affichage et au cours de l'élaboration de la liste de données de contrôle à rafraîchir, on analyse un fichier de diagnostic contenant un ensemble de codes d'instructions de diagnostic pour l'outil de diagnostic et un ensemble de balises pour la mise en oeuvre de codes d'instructions de diagnostic, on détecte lesdites balises et l'on analyse lesdites balises de manière à réaliser une discrimination entre un premier type de balises tendant à la mise en oeuvre d'une action de la part d'un opérateur et un deuxième type de balise tendant à la récupération de données de contrôle ou à la commande de fonctions de diagnostic embarquées. Lorsqu'une balise du premier type est détectée, on insère des données textuelles ou imagées dans la structure d'affichage enrichie.

Par ailleurs, lorsqu'une balise du deuxième type est détectée, on procède à une analyse complémentaire de la balise pour réaliser une discrimination entre des balises d'un troisième type tendant à la mise en oeuvre d'une fonction de diagnostic au moyen des modules de calcul, et des balises d'un quatrième type tendant à l'acquisition de valeurs de données de contrôle ou de calcul. Par exemple, en réponse à la détection d'une balise du troisième type, on insère une balise de commande dans la structure d'affichage enrichie. On peut encore, en réponse à la détection d'une balise du quatrième type, insérer d'une part un élément dans un fichier regroupant les données à rafraîchir, et d'autre part des composants logiciels de commande de lecture de données de contrôle dans la structure d'affichage enrichie. L'invention a également pour objet, selon un deuxième aspect, un système de diagnostic du dysfonctionnement d'un véhicule automobile, comprenant : - un premier étage d'élaboration d'une structure d'affichage enrichie de contrôle de fonctionnement du véhicule à partir d'une méthode de diagnostic et de données issues d'un outil de diagnostic, et d'élaboration d'une liste de données de contrôle à rafraîchir ; - un deuxième étage de récupération dynamique de données de contrôle en provenance de modules de calcul respectifs embarqués à bord du véhicule automobile ; et - un troisième étage d'élaboration d'un affichage final à partir de la structure d'affichage enrichie et des données de contrôle rafraîchies, Le système comporte en outre un ou plusieurs étages de supervision pour le contrôle desdits premier, deuxième et troisième étages. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels : - la figure 1 est un schéma synoptique illustrant l'architecture générale d'une installation de diagnostic pour véhicule automobile ; - la figure 2 illustre la structure d'un système de diagnostic pour véhicule automobile selon l'invention ; - la figure 3 est un organigramme illustrant les principales étapes du fonctionnement du premier étage du système de la figure 2 ; - la figure 4 est un organigramme illustrant les principales étapes de fonctionnement du deuxième étage du système de la figure 2; - la figure 5 est un organigramme illustrant les principales étapes du fonctionnement du troisième étage du système de la figure 2; et - la figure 6 est un organigramme illustrant les principales étapes du fonctionnement de l'étage de supervision du système de la figure 2 ; L'installation de diagnostic illustré à la figure 1 est destinée à contrôler le dysfonctionnement d'un véhicule automobile 1. Comme on le voit sur cette figure, le diagnostic est basé sur l'utilisation d'un outil de diagnostic 2 qui permet de présenter à un technicien et de mettre en oeuvre des méthodes de diagnostic conjointement avec des données ou commandes de contrôle délivrées par des modules de calcul embarqués à bord du véhicule 1. Le diagnostic d'un véhicule nécessite au préalable la construction de l'ensemble de données nécessaire au déroulement du diagnostic dans un atelier de réparation ou de maintenance. Ainsi, les méthodes de diagnostic sont élaborées par exemple par mise en oeuvre d'un logiciel issu ou hébergé par exemple sur un microordinateur 3 afin d'élaborer un certain nombre de fichiers, tels que 4, lesquels définissent les méthodes de diagnostic à mettre en oeuvre et incluent des références vers des ressources de diagnostic embarquées, à savoir, les modules de calcul. Par ailleurs, la définition des ressources diagnostic est récupérée grâce à l'utilisation d'un ensemble de fichiers, tels que 5, élaborés au moyen d'un logiciel de production de données de diagnostic issu ou hébergé par exemple au sein d'un microordinateur 6. Ces fichiers 5 définissent les ressources embarquées à bord du véhicule qui sont susceptibles de délivrer les données ou commandes de contrôle et les paramètres de communication à utiliser pour récupérer les données de contrôle en provenance des modules de calcul. Comme on le voit, il est prévu une communication entre les ressources matérielles et logicielles 3 et 6 servant l'une à produire les méthodes de diagnostic et l'autre à la production des données de diagnostic. Ces deux ressources matérielles pouvant parfaitement cohabiter, par exemple, dans un seul et même microordinateur et être rendues accessibles au travers d'un réseau informatique. Par ailleurs, le contenu des fichiers 4 et 5 est mis à disposition de l'outil de diagnostic 2, par exemple, par le biais d'une base de données 7 ou encore par un quelconque jeu de fichiers mis à disposition localement dans l'outil de diagnostic 2 ou rendu disponible à cet outil en ligne au travers d'un réseau informatique.

En d'autres termes, les méthodes de diagnostic et les références aux modules de calcul servant à récupérer les données de contrôle ou encore à activer leurs fonctions de diagnostic sont combinées au sein de la base de données 7 de l'outil de diagnostic 2 pour intégrer directement des références à ces ressources de diagnostic dans les méthodes de diagnostic et, ainsi, comme cela sera décrit en détail par la suite, afficher dynamiquement sur une interface homme/machine un résultat intégrant simultanément une méthode de diagnostic et des données ou commandes de contrôle.

En se référant à la figure 2, l'outil de diagnostic 2 comporte un ensemble de modules A, B, C et D qui fonctionnent conjointement pour l'élaboration d'un affichage final sur une interface homme/machine, constituée ici par un écran 8, pour présenter à un technicien des informations contenant, en combinaison, des méthodes de diagnostic, des données de contrôle, et des commandes de contrôle. Le premier étage A est utilisé pour élaborer un fichier intermédiaire contenant une structure d'affichage enrichie 9 combinée à des données de contrôle ou commande en référence à des ressources diagnostic.

I1 délivre par ailleurs au deuxième étage B un fichier sous la forme d'une liste 10 décrivant les données de contrôle à rafraîchir. Le deuxième étage B récupère cette liste de données de contrôle à rafraîchir. I1 récupère, par ailleurs, un ensemble de paramètres P de communication avec les modules de calcul embarqués et des descripteurs D servant à définir les ressources diagnostic disponibles dans les modules de calcul, ces données P et D étant récupérées à partir de la base de données 7. A partir de ces informations, le deuxième étage B dialogue avec les modules de calcul au travers de requêtes R et de réponses R' contenant entre autres les données de contrôle réactualisées, lesquelles sont décodées puis stockées dans le fichier intermédiaire 9 sous la forme de données dynamiques. Par exemple, ces requêtes sont élaborées à partir d'une liste de requêtes de données extraites, pour chaque module de calcul, d'une base.

Comme on le voit sur la figure 2, le troisième étage C récupère les données de contrôle rafraîchies par lecture de la structure d'affichage enrichie 9 et mise à jour dynamiquement par l'étage B et élabore ainsi l'affichage final en fonction de paramètres d'affichages P', extraits par exemple d'une base intégrée à la base de données 7, qui décrivent, pour chaque interface homme/machine susceptible d'être utilisée, les paramètres d'affichage nécessaires. Le fonctionnement des principaux éléments entrant dans la constitution du système de diagnostic, et en particulier le troisième étage C d'élaboration de l'affichage final est contrôlé par un quatrième étage D qui élabore et transmet au troisième étage C des requêtes R" tendant notamment à obtenir une modification d'affichage, par exemple en réponse à des actions A du technicien utilisateur.

On va maintenant décrire, en référence à la figure 3, les principales étapes du fonctionnement du premier étage A d'élaboration du fichier intermédiaire. Au cours d'une première étape 11, l'étage A procède à une lecture du fichier stocké dans la base de données 7 décrivant une méthode de diagnostic enrichie de données et de commandes de diagnostic, c'est-à-dire des informations servant à récupérer les données de contrôle ou à activer les fonctions de diagnostiques des modules de calculs. Après contrôle du fichier, notamment en ce qui concerne son format et sa syntaxe (étape 12), il est procédé à un test (étape 13) de manière à vérifier si ce fichier est correct. Si tel n'est pas le cas, un message d'erreur est généré (étape 14). Lors de l'étape 15 suivante, s'il a été constaté que le fichier est correct, il est procédé à un contrôle des en-têtes.

Si les en-têtes sont incorrects, le processus retourne à l'étape 14 précédente de manière à générer un signal d'erreur. Si tel n'est pas le cas, c'est-à-dire si les en-têtes sont corrects, le premier étage A procède à une détection de balises dans les fichiers, tendant à l'exécution d'instructions de diagnostic.

Tant que la balise détectée n'est pas la dernière balise (étape 17), il est procédé à une analyse de la balise détectée de manière à en déterminer la nature (étape 18). En particulier, au cours de cette étape 18, il est effectué une discrimination entre des balises de codage servant à provoquer la mise en oeuvre d'une action de la part du technicien utilisateur et un deuxième type de balise tendant à la récupération de données ou commande de contrôle. S'il est détecté, au cours de cette étape 18, que la balise est une balise du premier type, il est procédé à une insertion, dans le fichier intermédiaire 9, d'un contenu de type textuel ou imagé (étape 19) décrivant l'action à réaliser par le technicien utilisateur. Au contraire, s'il est détecté au cours de l'étape 18 précédente que la balise est une balise du deuxième type, c'est-à-dire tendant à la récupération de données ou commande de contrôle, lors de l'étape 20 suivante, il est encore détecté la catégorie à laquelle appartient cette balise. En d'autres termes, on effectue une discrimination entre des balises d'un troisième type, qui tendent à la mise en oeuvre d'une fonction de diagnostic et des balises d'un quatrième type, tendant à l'acquisition de valeurs de données de contrôle. S'il s'agit d'une balise du troisième type, on insère, lors de l'étape 21 suivante, une balise de commande dans le fichier de la structure d'affichage enrichie 9.

Au contraire, s'il s'agit d'une balise du quatrième type, lors de l'étape 22 suivante, on insère d'une part dans le fichier 10 le détail des données à rafraîchir, et d'autre part dans le fichier intermédiaire 9 un composant logiciel permettant le rafraîchissement graphique des données de contrôle, par exemple un composant de type ActiveX .

A l'issue de ces étapes, une fois que le fichier ne contient plus de balise, le premier étage a ainsi élaboré une structure d'affichage enrichie qui est destinée à être utilisée par le troisième étage C pour l'élaboration de l'affichage final et une liste de données à rafraîchir destinée à être utilisée par le deuxième étage B afin qu'il puisse mettre à jour dynamiquement la structure d'affichage enrichie. En se référant à la figure 4, le deuxième étage B, au cours d'une première étape 23, analyse le fichier 10 et, en particulier, la liste des données à rafraîchir. I1 construit alors les requêtes R à envoyer vers les modules de calcul à partir des données P décrivant les paramètres à utiliser pour communiquer avec les modules de calcul et les données D décrivant les données disponibles dans les modules de calcul (étape 24).

Lors de l'étape 26 suivante, les requêtes ainsi élaborées sont transmises au module de calcul embarqué, requête par requête. Les réponses R' sont alors décodées (étape 27) en utilisant les données D décrivant les données disponibles dans les calculateurs. Le fichier intermédiaire est alors mis à jour avec les données de contrôle actualisées (étape 28). On notera que le procédé mis en oeuvre au sein du deuxième étage B est réalisé en permanence afin de rafraîchir dynamiquement et ce, avec les meilleures performances possibles, les données à afficher. En se référant maintenant à la figure 5, le troisième étage C se charge de transformer le fichier intermédiaire 9 en un affichage final destiné à être présenté à l'utilisateur au moyen de l'écran 8, en fonction des paramètres P' de l'interface IHM utilisé. Comme indiqué précédemment, ce troisième étage C peut être sollicité par le quatrième étage D (requêtes R").

Au cours d'une première étape 30, le troisième étage C parcourt le fichier intermédiaire. A partir des paramètres P', ce fichier est transformé (étape 31) de manière à piloter l'écran 8 (étape 32). Enfin, en se référant à la figure 6, le quatrième étage D surveille les actions des utilisateurs afin d'indiquer au troisième étage C s'il est nécessaire de régénérer l'affichage. On notera que les actions des utilisateurs peuvent être de diverses natures, selon le mode de fonctionnement de l'outil de diagnostic.

En d'autres termes, cet étage D de supervision se charge de traduire les commandes entrées manuellement par les techniciens utilisateurs en évènements informatiques destinées à l'outil de diagnostic et au directement ou non troisième étage C.

En particulier, en fonction des commandes saisies par les utilisateurs, le quatrième étage D peut provoquer une régénération ou un déplacement de l'affichage, activer une fonction de diagnostic particulière, ou encore réinitialiser le premier étage A, par exemple dans le cas où l'on souhaite mettre en oeuvre une autre méthode de diagnostic. Ainsi, au cours d'une première étape 33, le quatrième étage D scrute les commandes saisies par les utilisateurs. Lorsqu'une balise est activée (étape 34) traduisant une commande tendant à mettre en oeuvre, par exemple, une fonction de diagnostic particulière, ou encore, notamment, à relancer le premier étage A, l'application de diagnostic principale mise en oeuvre au sein de l'outil de diagnostic 2 est informée (étape 35). Si tel n'est pas le cas, lors de l'étape 36 suivante, on détecte si l'utilisateur a souhaité une modification de l'affichage. Si tel est le cas, une requête R" correspondante est transmise vers le troisième étage C. L'affichage final est élaboré à partir de la structure d'affichage enrichie, des données de contrôle rafraichies et d'un accès direct aux commandes de contrôle.

Claims

REVENDICATIONS

1. Procédé de diagnostic du dysfonctionnement d'un véhicule automobile par mise en oeuvre d'un outil de diagnostic (2) et par analyse de données ou commandes de contrôle disponibles auprès d'un ensemble de modules de calcul embarqués à bord du véhicule et traduisant le fonctionnement d'un ensemble d'organes fonctionnels du véhicule, caractérisé en ce qu'il comporte les étapes de : - élaboration d'une structure d'affichage enrichie (9) de contrôle du fonctionnement du véhicule décrivant un enchaînement d'opérations de contrôle à effectuer sur le véhicule enrichies de données ou commandes de contrôle; - élaboration d'une liste (10) de données de contrôle à rafraîchir ; - récupération dynamique des données de contrôle rafraîchies en provenance des modules de calcul respectifs ; et - élaboration d'un affichage final (8) à partir de la structure d'affichage enrichie, des données de contrôle rafraîchies et d'un accès direct aux commandes de contrôle, lesdites étapes d'élaboration de la structure d'affichage enrichie, de la liste des données à rafraîchir, de récupération des données rafraîchies et d'élaboration de l'affichage final étant mises en oeuvre sous le contrôle d'un module de supervision (D).

2. Procédé selon la revendication 1, dans lequel, au cours de l'élaboration de la liste de données de contrôle à rafraîchir, on élabore des requêtes de diagnostic (R) à partir d'une base contenant, pour les modules de calcul, une liste de requêtes de données.

3. Procédé selon l'une des revendications 1 et 2, dans lequel, au cours de la récupération des données de contrôle, on décode une ou plusieurs réponses (R') transmises par chaque module de calcul.

4. Procédé selon la revendication 3, dans lequel on met à jour un fichier de données de contrôle rafraîchies à partir des données de contrôle récupérées.

5. Procédé selon la revendication 4, dans lequel l'affichage final (8) est élaboré à partir de la structure d'affichage enrichie, du fichier de données de contrôle rafraîchies, et à partir de paramètres d'affichage (P') extraites d'une base de données d'affichage qui correspondent à une interface homme/machine sur laquelle l'affichage final est destiné à être visualisé.

6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel au cours de l'élaboration de la structure d'affichage enrichie et au cours de l'élaboration de la liste de données de contrôle à rafraîchir, on analyse un fichier de diagnostic contenant un ensemble de codes d'instruction de diagnostic pour l'outil de diagnostic et un ensemble de balises pour la mise en oeuvre de codes d'instruction de diagnostic, on détecte lesdites balises et l'on analyse lesdites balises de manière à réaliser une discrimination entre un premier type de balises tendant à la mise en oeuvre d'une action de la part d'un opérateur et un deuxième type de balises tendant à la récupération de données de contrôle ou de commande de contrôle.

7. Procédé selon la revendication 6, dans lequel, lorsqu'une balise du premier type est détectée, on insère des données textuelles ou imagées dans la structure d'affichage enrichie.

8. Procédé selon la revendication 7, dans lequel, lorsqu'une balise du deuxième type est détectée, on procède à une discrimination de la balise entre une balise d'un troisième type tendant à la commande d'une fonction de diagnostic et une balise du quatrième type tendant à l'acquisition de valeurs de données de calcul.

9. Procédé selon la revendication 8, dans lequel, en réponse à la détection d'une balise du troisième type, on insère une balise de commande dans la structure d'affichage enrichie (9) permettant l'activation de la commande.

10. Procédé selon la revendication 9, dans lequel, en réponse à la détection d'une balise de quatrième type, on insère, dans un fichier (10) regroupant les données à rafraîchir, un composant logiciel de commande de lecture de données de contrôle.

11. Système de diagnostic du dysfonctionnement d'un véhicule automobile, caractérisé en ce qu'il comprend : - un premier étage (A) d'élaboration d'une structure d'affichage enrichie de contrôle du fonctionnement du véhicule et d'élaboration d'une liste (10) de données de contrôle à rafraîchir ; - un deuxième étage de récupération de données de contrôle rafraîchies en provenance de modules de calcul embarqués à bord du véhicule ; et - un troisième étage d'élaboration d'un affichage final (8) à partir de la structure d'affichage enrichie et des données de contrôle rafraîchies; et en ce qu'il comporte en outre un ou plusieurs étage(s) de supervision (D) pour le contrôle des premier, deuxième et troisième étages et des actions du technicien utilisateur.15