EP1673733A1 - Systeme de diagnostic predictif des dysfonctionnements d'un vehicule automobile et son dispositf de diagnostic embarque - Google Patents

Abstract

Système (1) de diagnostic prédictif des dysfonctionnements d'un véhicule automobile comprenant, embarqués à bord du véhicule, au moins une unité centrale (100) de gestion de diagnostic, un réseau (RA,RB) d'acquisition de données de diagnostic, relié à l'unité centrale, des moyens (200) de mémorisation de données de diagnostic et des moyens (220) de communication pour communiquer avec des moyens de diagnostic fixes et, au sol, l'un des éléments de l'ensemble comprenant - un outil de diagnostic fixe (2), d'une part, - un serveur de diagnostic (31) associé à une base de données de diagnostic (32), d'autre part. L'invention concerne aussi le dispositif de diagnostic embarqué du système.

Description

Système de diagnostic prédictif des dysfonctionnements d'un véhicule automobile et son dispositif de diagnostic embarqué

La présente invention concerne le diagnostic des dysfonctionnements des véhicules automobiles.

Autrefois, pour procéder à un diagnostic, un garagiste recueillait les symptômes de dysfonctionnements perçus par le conducteur du véhicule puis, à l'aide de ces symptômes, il recherchait le ou les dysfonctionnements, en examinant le véhicule visuellement et/ou à l'aide d'outils de mesure physique et de lecture électronique.

Une telle méthode de diagnostic s' avérait lourde à mettre en oeuvre et de surcroît peu fiable. En effet, elle ne permettait pas de trouver systématiquement les dysfonctionnements. Par ailleurs, la diversité croissante et l'évolution rapide des systèmes électroniques des véhicules ont rendu les diagnostics de dysfonctionnements et par conséquent les dépannages de plus en plus complexes.

Le dispositif d'aide au diagnostic, plus évolué, du document US-

A 5 313 388 comprend des moyens d'acquisition de données symptomatiques fournies par un utilisateur du véhicule, des moyens d'acquisition de données de fonctionnement du véhicule et il permet d'automatiser l'élaboration de diagnostics par l'introduction de moyens électroniques et informatiques. Mais dans ce dispositif de l'art antérieur, dans lequel on utilise une base de corrélation de données symptomatiques et de problèmes de fonctionnement, le diagnostic reste toutefois assez empirique.

Par le document EP 1 039 390, on connaît un dispositif comprenant des moyens d'acquisition de données symptomatiques fournies par un utilisateur du véhicule, des moyens d'acquisition de données symptomatiques antérieures, des premiers moyens d'aide au diagnostic par application, pour chaque donnée de fonctionnement du véhicule, d'au moins une méthode prédéfinie d'aide au diagnostic, et des seconds moyens d'aide au diagnostic par comparaison des données de l'un au moins des deux groupes, comprenant respectivement les données symptomatiques fournies par l'utilisateur du véhicule et les données de fonctionnement du véhicule, avec les données symptomatiques antérieures.

Par "données symptomatiques antérieures", on entend désigner des données relatives à des symptômes recueillis dans le passé sur des véhicules automobiles et pour chacun desquels au moins un dysfonctionnement, qui en est la cause, est connu. Mais ce dispositif, assez sophistiqué, reste un dispositif pour procéder à des diagnostics curatifs, avec tous les inconvénients, certes relatifs, liés au caractère curatif des diagnostics et, finalement, aux dépannages. Et bien la demanderesse a eu l'idée de proposer d'intervenir avant et non après les dysfonctionnements ou les pannes et de développer le diagnostic de véhicules automobiles prédictif ou préventif.

Si on veut schématiquement définir le diagnostic curatif pratiqué jusqu'à maintenant, voici comment se présente l'architecture : chez le garagiste,

* un véhicule, mobile, avec, au moins - une unité centrale embarquée (UCE), qui intègre un module de diagnostic de bas niveau, en ce sens qu'il ne procède pratiquement à aucun diagnostic et se borne à stocker et transmettre les données, - des réseaux reliés à l'unité centrale, * une sonde d'acquisition des données de l'UCE,

* un outil de diagnostic débarqué, ou fixe, qui procède à - l'analyse des trames recueillies par la sonde et qui met en oeuvre - des algorithmes de diagnostic et de réparation, avec - une interface homme- machine et - un terminal informatique de liaison avec le constructeur,

chez le constructeur, tout un système d'informations, avec

- une base de données (ou plusieurs), - un méta-moteur informatique, qui est un serveur de diagnostic.

La liaison entre la sonde et l'outil de diagnostic du garagiste, d'une part, et la liaison entre l'outil du garagiste et le serveur du constructeur, d'autre part, peuvent être des liaisons radio.

Si on veut entrer un peu plus dans les détails de l'outil de diagnostic, on y trouve, en reprenant la terminologie fournie par le modèle Open System Interconnection (OSI), qui découpe les fonctions de communication en sept couches, -une couche de très bas niveau de contrôle physique de composants, -une couche de communication, -une couche d'acquisition de données, notamment des bus normalisés du véhicule CAN (réseau contrôleur) et VAN (réseau véhicule), -une couche de liaison avec l'unité centrale embarquée (ou les unités centrales) du véhicule, -une couche fonctionnelle, -une couche d'interface graphique utilisateur (GUI) et - une couche supérieure d'applications. Le problème du diagnostic prédictif est résolu, selon la demanderesse, avec un système de diagnostic prédictif des dysfonctionnements d'un véhicule automobile comprenant, embarqués à bord du véhicule, au moins - une unité centrale de gestion de diagnostic, - un réseau d'acquisition de données de diagnostic, relié à l'unité centrale, - des moyens de mémorisation de données de diagnostic et - des moyens de communication pour communiquer avec des moyens de diagnostic fixes et, au sol, - l'un des éléments de l'ensemble comprenant - un outil de diagnostic fixe, d'une part, - un serveur de diagnostic associé à une base de données de diagnostic, d'autre part. Le serveur et la base de données, qui constituent un système central, sont situés chez le constructeur alors que l'outil de diagnostic, qui complète l'unité centrale de gestion de diagnostic embarquée, mobile, peut être fixe, ou débarqué , soit chez le garagiste soit chez le constructeur.

On notera qu'il ne faut pas confondre l'unité centrale de gestion de diagnostic avec ce qu'on appelle généralement l'unité centrale d'habitacle qui est un calculateur.

L'aspect remarquable de l'invention réside dans l'intégration d'une partie de l'intelligence du diagnostic à bord du véhicule pour réagir en temps réel. En d'autres termes, au diagnostic prédictif ou préventif est associée de l'intelligence embarquée alors qu'au diagnostic curatif correspond de l'intelligence débarquée. Ainsi, et à titre d'exemple, si une variable de fonctionnement du véhicule se met à dériver et à franchir un seuil d'alerte, cela peut être diagnostiqué à bord pour déclencher une alerte vers le constructeur — en transparence pour le conducteur - puis, après traitement, vers le conducteur.

La demanderesse entend également protéger, à titre de moyens intermédiaires, le dispositif de diagnostic embarqué dans un véhicule automobile, comportant : une unité centrale de gestion de diagnostic, un réseau d'acquisition de données de diagnostic, relié à l'unité centrale, des moyens de mémorisation de données de diagnostic et des moyens de communication pour communiquer avec l'un des éléments de l'ensemble comprenant un outil de diagnostic fixe, d'une part, et un système central de diagnostic fixe, comprenant un serveur associé à une base de données, d'autre part.

De façon avantageuse, l'unité centrale de gestion comporte un contrôleur d'agents de gestion des données de diagnostic en entrée et en sortie des calculateurs du véhicule, c'est-à-dire des agents gérant les ressources physiques de transmission de données des calculateurs notamment par les réseaux CAN, VAN et LIN du véhicule, et les ressources logicielles de ces calculateurs.

Les agents de gestion répondent aux requêtes du contrôleur d'agents de gestion et émettent des alertes en cas de dysfonctionnement et/ou de dépassement de seuil.

Il est intéressant de souligner que pour le constructeur, avec son serveur et sa base associés, les véhicules automobiles avec leur unité centrale de gestion de diagnostic se comportent comme des ordinateurs personnels d'un réseau informatique, LAN ou INTRANET.

De préférence, les données de diagnostic sont associées entre elles pour former des trames de diagnostic dans les moyens de mémorisation des données de diagnostic, chaque trame ainsi mémorisée associant les données impliquées dans un seul dysfonctionnement ou un seul diagnostic. Avantageusement, l'unité centrale de gestion comporte un module de recherche dans les moyens de mémorisation pour extraire des trames contenant la donnée de diagnostic ayant fait l'objet d'une alerte émise par un agent de gestion. Avantageusement encore, l'unité centrale de gestion comporte un module d'interrogation pour interroger l'outil de diagnostic fixe et y extraire des trames contenant au moins les données de diagnostic ayant fait l'objet d'alertes émises par au moins un agent de gestion. Avantageusement également, l'unité centrale de gestion comporte un module de mise à jour des moyens de mémorisation du dispositif de diagnostic pour y mémoriser les trames contenant les données de diagnostic à partir desquelles un diagnostic a pu être établi sur le fonctionnement du véhicule.

Tous ces avantages et d'autres aspects intéressants de l'invention apparaîtront plus clairement à l'aide de la description suivante d'une forme particulière non limitative du dispositif de diagnostic selon l'invention et du système de diagnostic prédictif des dysfonctionnements utilisant le dispositif de diagnostic selon l'invention, en référence au dessin annexé, sur lequel :

- la figure 1 représente un schéma par blocs fonctionnels du système de diagnostic prédictif selon l'invention, - la figure 2 représente un schéma par blocs fonctionnels du dispositif de diagnostic selon l'invention et - la figure 3 représente un organigramme du fonctionnement du dispositif de diagnostic selon l'invention.

En référence à la figure 1, le système 1 de diagnostic prédictif des dysfonctionnements d'un véhicule automobile (non représenté) comporte soit un outil 2 de diagnostic au sol, ou fixe, ou encore débarqué, situé chez un garagiste, soit un système central 3 de diagnostic, situé chez un constructeur de véhicules automobiles, et comportant un serveur de diagnostic 31 associé à une base centrale de données de diagnostic 32, l'outil et le système central pouvant être en liaison radio TR, ou par tout autre réseau, avec un dispositif de diagnostic embarqué dont il sera question ci-après.

Ces équipements sont ceux connus de l'homme du métier et n'ont pas à être plus détaillés ici. Ils sont d'ordinaire reliés aux équipements électroniques classiques 4 du véhicule automobile comme déjà indiqué ci-dessus.

Ces équipements électroniques classiques 4, essentiellement les « ECUs » (electronic control units) 310, 320, ... 3i0, commandent par leurs modules 313, 323, ..., 3i3 de contrôle-commande et au travers des liaisons CD, et/ou contrôlent, par des liaisons de réseau RA pouvant appartenir aux réseaux CAN, VAN et LIN du véhicule, avec des capteurs 314, 324, ..., 3i4 associés à ces ECUs, les fonctions 400 du véhicule : son moteur, l'habitacle et son interface homme - machine, ses servitudes électriques, pneumatiques, hydrauliques, mermiques, etc

Les données des capteurs sont collectées par des cartes électroniques 312, 322, ..., 3i2, soit des cartes auto-test « BITE » (built-in test equipment), soit des cartes « OBD » (on board diagnosis), qui délivrent des alertes de dysfonctionnement ou de pannes, sur dépassement de seuil. Ici, les équipements électroniques 4 ont été modifiés et complétés coπirne expliqué ci-après.

D'une part, les ECUs sont équipés d'agents 311, 321, ..., 3il de gestion de données de diagnostic, c'est-à-dire des mesures physiques prises sur les organes assurant les fonctions 400 et des paramètres de fonctionnement appliqués aux modules 3i3 commandant ces organes, collectées par les cartes OBD/BITE ou non, et indépendamment des alertes qu'elles délivrent.

Dans ces données de diagnostic sont inclus également des abaques modélisant mathématiquement le comportement physique standard des organes des fonctions 400, qu'on désignera dans la suite par standards de fonctionnement.

On notera que les données de diagnostic ainsi définies sont génériques des données symptomatiques de dysfonctionnement.

Les agents de gestion 3il répondent aux requêtes d'un contrôleur 110 d'agents de gestion, expliqué ci-après, et émettent des données d'écarts par rapport aux standards de fonctionnement et d'alarmes de dysfonctionnement.

En même temps que les ressources logicielles des calculateurs ECUs, les agents de gestion gèrent aussi les ressources physiques de transmission de données de ces calculateurs par les réseaux CAN, VAN et LIN du véhicule.

D'autre part, il est donc prévu un dispositif de diagnostic 5 embarqué dans le véhicule automobile, dont les fonctions sont assurées grâce : à une unité centrale 100 de gestion de diagnostic, détaillée plus loin, reliée : aux agents de gestion 310, ..., 3i0, par une liaison de réseau RB d'acquisition de données de diagnostics, liaison de réseau appartenant à l'un ou l'autre des réseaux CAN, VAN et LIN du véhicule, à des moyens 200 de mémorisation de données de diagnostics issues du véhicule comportant une mémoire 201 de l'historique et une mémoire 202 de trames de diagnostic , par une liaison 203 parallèle, à des moyens 220 de communication, comportant un émetteur- récepteur 222 et un module pilote 221 (driver), par une liaison 223 série pour communiquer avec au moins la station 2 de diagnostic fixe ou le système centralisé 3 de diagnostic, ou le second à travers le premier.

L'unité centrale de gestion de diagnostic 100 peut comprendre plusieurs sous-ensembles qui naturellement peuvent communiquer entre eux et coopérer ensemble pour effectuer le diagnostic.

Le pilote 221 est conçu pour communiquer de façon à ce que pour le serveur et sa base associée, ou l'outil 2, l'unité centrale 100 de gestion de diagnostic se comporte comme un ordinateur personnel de réseau informatique, LAN ou INTRANET.

Il est en outre prévu une liaison 213 avec 1THM (interface homrne- machine) de l'habitacle du véhicule et des fonctions 211 d'alerte et 212 d'interrogation, spécifiques de la gestion des diagnostics, dans cet IHM.

L'unité centrale de gestion 100 va maintenant être décrite, en référence à la figure 2.

Cette unité comporte un contrôleur 110 temps réel, déjà évoqué ci- dessus, des agents 3il de gestion des données de diagnostic, en entrée et en sortie des calculateurs 3i0 du véhicule.

Le contrôleur 110 est relié en sortie à un module 120 de recherche des trames de données et des alertes reçues, lui même relié à une mémoire 121 des données en cours de traitement, à la mémoire 202 des trames de diagnostic par la liaison 203, et en entrée à un module 140 de gestion des requêtes à émettre vers les agents 3il de gestion, ce module 140 étant relié à une mémoire 141 des requêtes en cours.

L'unité centrale 100 comporte aussi un module 130 d'interrogation de diagnostic..

Le module 130 d'interrogation de diagnostic reçoit les trames de données « candidates », à analyser, émises par le module 120 de recherche de trames, et peut émettre des requêtes vers le module 140 de gestion des requêtes à destination des agents 3il, chacun des agents gérant et émettant ces requêtes dans les ECU 3i0 correspondantes, soit vers les modules BITE 3i2, soit vers les modules 3i3 de contrôle - commande.

Le module 130 comporte au moins deux sous-modules d'interrogation: - un sous-module 132 d'interrogation interne relié à la mémoire 201 de l'historique du véhicule des moyens 200 de mémorisation via la liaison 203, pour rechercher des trames ayant déjà donné lieu, pour le véhicule, à un diagnostic préventif ou prédictif, c'est-à-dire un pré-diagnostic, - un sous-module 134 d'interrogation externe, auprès des station 2 ou système centralisé 3 de diagnostic, par rintermédiaire d'un module 170 générateur de messages et via la liaison 223, pour y extraire des trames ayant déjà donné lieu, pour le type de véhicule, à un pré-diagnostic.

Les données de diagnostic sont associées entre elles pour former des trames significatives de pré-diagnostic , chaque trame étant définie par l'association des données impliquées dans un seul pré-diagnostic, et lorsque le pré-diagnostic est avéré, par exemple lors de l'occurrence de la panne, déclarée dans 1THM, correspondant au pré- diagnostic, ou si l'outil 2 ou le système central 3 de diagnostic le confirme, les trames sont mémorisées dans la mémoire 202 des moyens de mémorisation 200.

Le sous-module 134 commande aussi, également relié à la mémoire 202 par la liaison 203, un module 160 de mise à jour de cette mémoire 202 des trames contenant des données de diagnostic à partir desquelles un pré-diagnostic a pu être établi sur le fonctionnement du véhicule.

Enfin, le sous-module 134 d'interrogation externe et le module 140 de gestion des requêtes sont reliés à iHM par l'intermédiaire d'un module 180 de dialogue commandant 1THM par l'intermédiaire de la liaison 213, et en recevant les réponses.

Le fonctionnement du système va maintenant être décrit, à travers un exemple non limitatif.

Les mesures physiques significatives du fonctionnement du moteur

400 du véhicule, pour prendre cet exemple, sont cycliquement effectuées par les capteur 314 et collectées par la carte 312 via le réseau RA ou directement calculées par l'ECU 310, en l'occurrence un CCM (calculateur de contrôle moteur), quand la mesure n'est accessible par calcul. L'agent de gestion 310 prélève certaines de ces mesures, par exemple issues des sondes lambda amont et aval, en relation avec des trames significatives de pré-diagnostic en rapport avec le fonctionnement en cours, émises par Punité centrale 100 de gestion de diagnostics, ainsi que les standards de fonctionnement correspondant aux paramètres de fonctionnement en cours d'application, ici, par exemple les abaques de richesse de carburation et l'angle de la commande d'accélération, le couple, la température huile moteur, etc ... Si une mesure sort des standards de fonctionnement du moteur, par exemple la température huile, l'agent 310 émet une alerte datée et l'ensemble des données de diagnostic ainsi rassemblées vers le contrôleur 110 via le réseau RB. Le contrôleur 110, en référence à la figure 3, collecte, lors de l 'étape 10, toutes les alertes et les données de diagnostic correspondantes de tous les ECUs du véhicule et les trie chronologiquement pour préparer l'établissement ultérieur d'un historique, la datation pouvant être un élément de pré-diagnostic, avant de les conmiuniquer au module 120 de recherche des trames.

Dans l'exemple choisi, à l'étape 20, le module 120 effectue la synthèse des données de diagnostic reçues des divers ECUs et mémorisées au fil du temps dans la mémoire 121 des données en cours de traitement en les assemblant en une trame cohérente « candidate » au plan fonctionnel du véhicule, c'est-à-dire assemblant des données, contrôle moteur, électricité , refroidissement, ..., concernant des grandeurs physiques affectant le même processus fonctionnel du véhicule, par exemple le fonctionnement moteur, et selon une chronologie correspondant à un processus de dégradation possible. Ces trames « candidates » sont construites sur les modèles de trames mémorisées à l'avance dans la mémoire 202.

A l'étape 40, la trame candidate est comparée, par le module 132, aux trames candidates antérieures mémorisées dans la mémoire 201 de l'historique du véhicule. Si elle n'y est pas présente, elle y est mémorisée. Sinon, le module 120 tient compte du résultat du traitement qui est alors intervenu. Notamment, s'il y a eu pré- diagnostic, on passe à une étape 41 d'alerte IHM, et à nouveau à l'étape 20 pour recherche d'une nouvelle trame candidate.

Si à l'étape 40 il s'avère que la trame candidate est nouvelle pour le véhicule, on passe à une étape 50, exécutée par le module 134 , dans laquelle la même interrogation que dans l'étape 40 est effectuée, mais portant, cette fois sur l'ensemble du parc automobile des véhicules du même type. Pour cela, lors de cette étape 50, le module 134 émet des requêtes au module 170 de génération de messages qui se charge, lors d'une étape 51, de lancer les moyens de communication 220, via la liaison 223, le pilote 221 assurant l'attente, en une étape 52, des réponses de l'outil 2 ou du système central 3 de diagnostic, et éventuellement une relance en cas de défaut de communication. A l'étape 50, le module 134 récupère les trames des réponses et prédiagnostics communiqués et, à l'étape 60, les analyse. Ces réponses peuvent être un pré-diagnostic correspondant à la trame candidate, auquel cas l'étape d'alerte 41 est exécutée, et le conducteur du véhicule alerté, ou des trames de données de diagnostic compatibles avec la trame candidate, auquel cas on passe à une étape 70 de recherches complémentaires à effectuer par le module 140, ou une absence de risque, auquel cas aucun pré-diagnostic n'est possible et on retourne à l'étape 10. On voit que si une variable de fonctionnement du véhicule se met à dériver hors des standards et éventuellement à franchir un seuil d'alerte, cela peut être diagnostiqué abord pour déclencher une alerte vers le constructeur puis, après traitement, vers le conducteur. Par trames compatibles, on entend des trames ayant en commun les mêmes données de diagnostic, l'une plus complète comportant plus de données que l'autre, parmi les données capables de générer au moins une donnée symptomatique de dysfonctionnement. En l'occurrence, si la trame candidate est plus complète, c'est sa restriction à la trame réponse qui est traitée, sinon, lors de l'étape 70, le module 140 relève les données manquantes et analyse la possibilité de les collecter ou non.

Dans ce dernier cas, on retourne à l'étape 10. Sinon, une demande 71 de test peut être demandée au conducteur du véhicule par le biais de l'IHM du tableau de bord et, après acquittement 72 du conducteur, le module 120 exécute une étape 30 de mise à jour de la trame candidate pour une nouvelle analyse aux étapes 40 et 50 exécutées par les modules 132 et 134 d'interrogation interne et externe. Mais il est possible que l'intervention du conducteur ne soit pas nécessaire. Dans ce cas, à une étape 80, le module 140 génère une requête à destination des agents de gestion 3il concernés, requête émise par le contrôleur 110 via le réseau RB lors d'une étape 90.

A cette étape, les agents concernés répercutent la requête à leur ECU qui : 1) via leur carte de contrôle 3i3, agit sur le processus pour rendre les mesures faisant défaut plus significatives,

2) programme l'exécution de mesures complémentaires par leur carte de test BITE ou OBD 312

3) complète ses fonctions de calcul par un calcul complémentaire de mesure manquante. Les logiciels nécessaires peuvent alors être téléchargés depuis le système central 3.

Dans ce dernier cas, il est prévu dans l'unité centrale (100) une fonction (non représentée) de téléchargement de logiciels, à partir du système central de diagnostic 3, dans les calculateurs 3i0, pour modifier, via les agents 3il, les logiciels des calculateurs ECU qui contrôlent les acquisitions de données de diagnostic.

En fin d'exécution de l'étape 90, l'étape 30 est réactivée.

Claims

REVENDICATIONS 1- Système (1) de diagnostic prédictif des dysfonctionnements d'un véhicule automobile comprenant, embarqués à bord du véhicule, au moins - une unité centrale (100) de gestion de diagnostic, - un réseau (RA,RB) d'acquisition de données de diagnostic, relié à l'unité centrale, - des moyens (200) de mémorisation de données de diagnostic et des moyens (220) de communication pour communiquer avec des moyens de diagnostic fixes et, au sol, - l'un des éléments de l'ensemble comprenant - un outil de diagnostic fixe (2), d'une part, - un serveur de diagnostic (31) associé à une base de données de diagnostic (32), d'autre part.

2- Système selon la revendication 1, caractérisé par le fait que si une variable de fonctionnement du véhicule se met à dériver et à franchir un seuil d'alerte, cela est diagnostiqué à bord pour déclencher une alerte vers le constructeur puis, après traitement, vers le conducteur.

3- Dispositif de diagnostic (5) embarqué dans un véhicule automobile, comportant : - une unité centrale (100) de gestion de diagnostic, un réseau (RA, RB) d'acquisition de données de diagnostic, relié à l'unité centrale, des moyens (200) de mémorisation de données de diagnostic et - des moyens (220) de communication pour communiquer avec l'un des éléments de l'ensemble comprenant un outil de diagnostic fixe (2), d'une part, et un système central de diagnostic fixe (3) comprenant un serveur (31) et une base de données (32), d'autre part.

4- Dispositif selon la revendication 3, dans lequel l'unité centrale de gestion (100) comporte un contrôleur (110) d'agents (3il) de gestion des données de diagnostic en entrée et en sortie des calculateurs ECU (3i0) du véhicule.

5- Dispositif selon la revendication 4, dans lequel les agents (3il) de gestion répondent aux requêtes du contrôleur (110) d'agents de gestion et émettent des alertes en cas de dysfonctionnements.

6- Dispositif selon l'une des revendications 3 à 5, dans lequel les données de diagnostic sont associées entre elles pour former des trames de diagnostic dans les moyens (200) de mémorisation des données de diagnostic.

7- Dispositif selon la revendication 6 dans lequel chaque trame mémorisée associent les données impliquées dans un seul dysfonctionnement pouvant donner lieu à un seul diagnostic.

8- Dispositif selon l'une des revendications 3 à 7, dans lequel l'unité centrale de gestion (100) comporte un module (120) de recherche dans les moyens de mémorisation (200) pour extraire des trames contenant les données de diagnostic ayant fait l'objet d'une alerte émise par un agent de gestion (3il).

9- Dispositif selon l'une des revendications 3 à 8, dans lequel l'unité centrale de gestion (100) comporte un module (134) d'interrogation externe pour interroger la station de diagnostic fixe et y extraire des trames contenant au moins les données de diagnostic ayant fait l'objet d'alertes émises par au moins un agent de gestion (3il).

10- Dispositif selon l'une des revendications 3 à 9, dans lequel l'unité centrale (100) de gestion comporte un module (160) de mise à jour des moyens de mémorisation (200) pour y mémoriser les trames contenant les données de diagnostic à partir desquelles un diagnostic a pu être établi sur le fonctionnement du véhicule.

11.- Dispositif selon l'une des revendications 3 à 10, embarqué à bord d'un véhicule et constituant une partie du système de l'une des revendications 1 et 2.

12- Système selon l'une des revendications 1 et 2, dans lequel il est prévu une fonction de téléchargement de logiciels à partir du serveur (31) pour modifier les logiciels des calculateurs ECU (3i0) contrôlant les acquisitions de données de diagnostic.

13.- Système selon l'une des revendications 1 et 2, dans lequel l'unité centrale de gestion de diagnostic (100) comporte plusieurs sous- ensembles agencés pour communiquer entre eux et coopérer ensemble pour effectuer le diagnostic.