EP2181372A1 - Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile - Google Patents

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

Info

Publication number
EP2181372A1
EP2181372A1 EP08828200A EP08828200A EP2181372A1 EP 2181372 A1 EP2181372 A1 EP 2181372A1 EP 08828200 A EP08828200 A EP 08828200A EP 08828200 A EP08828200 A EP 08828200A EP 2181372 A1 EP2181372 A1 EP 2181372A1
Authority
EP
European Patent Office
Prior art keywords
data
refreshed
control
control data
diagnostic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08828200A
Other languages
German (de)
English (en)
Inventor
Damien Delcroix
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renault SAS
Original Assignee
Renault SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renault SAS filed Critical Renault SAS
Publication of EP2181372A1 publication Critical patent/EP2181372A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0208—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
    • G05B23/0216—Human interface functionality, e.g. monitoring system providing help to the user in the selection of tests or in its configuration

Definitions

  • the invention relates to the diagnosis of the malfunction of a means of transport such as the plane or the boat specifically a motor vehicle implemented in repair or maintenance workshops.
  • a diagnostic method is implemented, for example in the form of a A fault locating shaft which enables the identification of a cause from a symptom, such as that formulated by the owner or the driver of the vehicle.
  • This diagnostic method is conducted step by step and must lead to the identification of the cause of the failure to determine the repair to be performed on the vehicle.
  • the technician must control or control on-board calculation modules on board the motor vehicle, in order to recover data from the vehicle. diagnostics or activate internal functions of these modules.
  • the technician In parallel with this diagnostic method, which makes it possible, in successive stages, to locate a defective component, the technician has a certain number of resources embedded in the vehicles. It thus has the possibility of retrieving diagnostic data from the vehicle calculation modules or activating internal diagnostic functions of these modules.
  • the technician usually uses a diagnostic tool that integrates a diagnostic software that can either implement the diagnostic method or recover data or activate diagnostic commands from the calculation modules.
  • the diagnostic tool offers the technician a number of human / machine interfaces, in the form of screens that correspond to either the steps of a diagnostic method or to a visualization of diagnostic data from modules. calculation, or the activation of a diagnostic function internal to the calculation module.
  • the technician may be required to check diagnostic values from the calculation modules against reference values or to activate an internal diagnostic function to compare the effects to behaviors. referred to as reference.
  • This consultation is carried out from one screen to another and requires a certain number of navigations, which therefore generates a considerable and unnecessary loss of time.
  • this solution generates a significant risk of errors, the passage from one screen to another may cause a consultation error, for example the acquisition of erroneous diagnostic data, and therefore a diagnostic error.
  • control data is a necessary phase, insofar as, depending on the result of the control, the diagnostic method can continue to different subsequent steps, depending on the value of the controlled data.
  • the object of the invention is therefore, according to a first aspect, a method for diagnosing the malfunction of a motor vehicle by implementing a diagnostic tool and by analyzing data or control commands available from a set of calculation modules on board the motor vehicle and reflecting the operation of a set of functional organs of the vehicle.
  • this method comprises the steps of:
  • Said steps of elaborating the enriched display structure, the list of data to be refreshed, the recovery of the refreshed data and the development of the final display are implemented under the control of a supervision module.
  • diagnostic requests are prepared from a database containing, for each calculation module, the description of the diagnostic requests. .
  • one or more responses transmitted by the calculation modules are decoded.
  • a refreshed control data file can be updated from the recovered control data.
  • the final display can thus be elaborated from the display structure and display parameters extracted from a display database which correspond to a man / machine interface on which the final display is intended to be viewed.
  • a diagnostic file containing a set is analyzed. of diagnostic instruction codes for the diagnostic tool and a set of tags for the implementation of diagnostic instruction codes, said tags are detected and the tags are scanned so as to discriminate between a first type of tags tending to implement an action on the part of an operator and a second type of tag tending to the recovery of control data or the control of on-board diagnostic functions.
  • a command tag is inserted into the rich display structure.
  • the object of the invention is also, according to a second aspect, a system for diagnosing the malfunction of a motor vehicle, comprising:
  • the system further comprises one or more supervision stages for controlling said first, second and third stages.
  • FIG. 1 is a block diagram illustrating the general architecture of a diagnostic installation for a motor vehicle
  • FIG. 2 illustrates the structure of a diagnostic system for a motor vehicle according to the invention
  • FIG. 3 is a flowchart illustrating the main steps of operation of the first stage of the system of FIG. 2;
  • FIG. 4 is a flowchart illustrating the main operating steps of the second stage of the system of FIG. 2;
  • FIG. 5 is a flowchart illustrating the main steps of operation of the third stage of the system of FIG. 2;
  • FIG. 6 is a flowchart illustrating the main steps of the operation of the supervision stage of the system of FIG. 2;
  • the diagnostic installation illustrated in Figure 1 is intended to control the malfunction of a motor vehicle 1.
  • the diagnosis is based on the use of a diagnostic tool 2 which makes it possible to present to a technician and implement diagnostic methods together with data or control commands issued by onboard vehicle calculation modules 1.
  • the diagnosis of a vehicle requires first of all the construction of the data set necessary for the diagnosis process in a repair or maintenance workshop.
  • the diagnostic methods are developed, for example, by implementing software that is issued or hosted for example on a microcomputer 3 in order to develop a certain number of files, such as 4, which define the diagnostic methods to be implemented. implement and include references to on-board diagnostic resources, namely, the calculation modules.
  • diagnostic resources is recovered through the use of a set of files, such as 5, developed using diagnostic data production software from or hosted for example within a microcomputer 6.
  • files 5 define the resources on board the vehicle that are capable of delivering the control data or commands and the communication parameters to be used to retrieve the control data from the calculation modules.
  • the content of the files 4 and 5 is made available to the diagnostic tool 2, for example, by means of a database 7 or by any set of files made available locally in the database. diagnostic tool 2 or made available to this tool online through a computer network.
  • the diagnostic methods and the references to the calculation modules used to retrieve the control data or to activate their diagnostic functions are combined within the database 7 of the diagnostic tool 2 to directly integrate references to these diagnostic resources in the diagnostic methods and, as will be described in detail later, display dynamically on a human / machine interface a result simultaneously integrating a diagnostic method and data or commands of control. Referring to FIG.
  • the diagnostic tool 2 comprises a set of modules A, B, C and D which work together to produce a final display on a man / machine interface, here constituted by a screen 8, to present to a technician information containing, in combination, diagnostic methods, control data, and control commands.
  • the first stage A is used to develop an intermediate file containing an enriched display structure 9 combined with control or command data with reference to diagnostic resources. It also delivers to the second floor B a file in the form of a list 10 describing the control data to be refreshed.
  • the second stage B retrieves this list of control data to be refreshed. It also retrieves a set of communication parameters P with the on-board calculation modules and descriptors D used to define the diagnostic resources available in the calculation modules, these data P and D being retrieved from the database. 7.
  • the second stage B dialogues with the calculation modules through requests R and R 'replies containing inter alia the updated control data, which are decoded and stored in the intermediate file 9 in the form of data.
  • dynamic For example, these queries are developed from a list of extracted data requests, for each calculation module, of a database.
  • the third stage C retrieves the refreshed control data by reading the enriched display structure 9 and dynamically updated by the stage B and thus prepares the final display according to parameters.
  • display P ' extracted for example from a base integrated in the database 7, which describe, for each human / machine interface that can be used, the necessary display parameters.
  • the operation of the main elements involved in the constitution of the diagnostic system, and in particular the third stage C of development of the final display is controlled by a fourth stage D which develops and transmits to the third floor C requests R "tending in particular to obtain a display modification, for example in response to user technician actions A.
  • a fourth stage D which develops and transmits to the third floor C requests R "tending in particular to obtain a display modification, for example in response to user technician actions A.
  • the stage A proceeds to a reading of the file stored in the database 7 describing a diagnostic method enriched data and diagnostic commands, that is to say, information used to retrieve the control data or to activate the diagnostic functions of the calculation modules.
  • step 13 After checking the file, particularly with regard to its format and its syntax (step 12), a test is performed (step 13) in order to check whether this file is correct.
  • step 14 If this is not the case, an error message is generated (step 14). In the next step, if it has been found that the file is correct, a header check is performed. If the headers are incorrect, the process returns to step
  • the first stage A proceeds to a detection of tags in the files, tending to the execution of diagnostic instructions. As long as the beacon detected is not the last beacon (step 17), the detected beacon is analyzed in order to determine its nature (step 18).
  • discrimination is carried out between coding beacons used to cause the user to perform an action and a second type of beacon tending to retrieve data or control command.
  • the beacon is a beacon of the first type, it is proceeded to an insertion, in the intermediate file 9, of a content of textual or pictorial type (step 19) describing the action to be performed by the user technician.
  • step 20 if it is detected in the previous step 18 that the beacon is a beacon of the second type, that is to say, tending to the recovery of data or control command, during step 20 next, it is still detected the category to which this tag belongs.
  • beacons of a third type which tend to implement a diagnostic function
  • beacons of a fourth type tending to acquire data values. control.
  • a control tag is inserted in the file of the enriched display structure 9.
  • a beacon of the fourth type during the following step 22, one inserts firstly in the file 10 the detail of the data to be refreshed, and secondly in the intermediate file 9 a software component allowing the graphical refreshment.
  • control data for example an "ActiveX®" type component.
  • the second stage B analyzes the file 10 and, in particular, the list of data to be refreshed. It then builds the R requests to be sent to the calculation modules from the data P describing the parameters to be used to communicate with the calculation modules and the data D describing the data available in the calculation modules (step 24). In the next step 26, the requests thus elaborated are transmitted to the on-board calculation module, query by request.
  • the intermediate file is then updated with the updated control data (step 28).
  • the method implemented in the second stage B is continuously performed in order to dynamically refresh, with the best possible performance, the data to be displayed.
  • the third stage C is responsible for transforming the intermediate file 9 into a final display intended to be presented to the user by means of the screen 8, according to the parameters P 'of the HMI interface used.
  • this third stage C can be requested by the fourth stage D (requests R ") During a first stage 30, the third stage C traverses the intermediate file.
  • this file is transformed (step 31) so as to control the screen 8 (step 32).
  • the fourth floor D monitors the actions of the users to indicate on the third floor
  • this supervision stage D is responsible for translating the commands manually entered by the user technicians into computer events intended for the diagnostic tool and directly or not third stage C.
  • the fourth stage D can cause a regeneration or a displacement of the display, activate a particular diagnostic function, or reinitialise the first stage A, for example in the case where it is desired to implement another diagnostic method.
  • the fourth floor D scrutinizes the commands entered by the users.
  • a tag is activated (step 34) translating a command tending to implement, for example, a particular diagnostic function, or, in particular, to restart the first stage A
  • the main diagnostic application implemented at within the diagnostic tool 2 is informed (step 35). If this is not the case, in the next step 36, it is detected whether the user wished a modification of the display. If this is the case, a corresponding request R "is transmitted to the third floor C.

Abstract

Ce procédé de diagnostic du dysfonctionnement d'un véhicule automobile met en oevre 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 oevre sous le contrôle d'un module de supervision (D).

Description

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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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.
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 œuvre 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 œuvre 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 œuvre 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. II 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. Il 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 1 1 , 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 œuvre 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 œuvre 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. Il 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 œuvre 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 œuvre 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 œuvre, par exemple, une fonction de diagnostic particulière, ou encore, notamment, à relancer le premier étage A, l' application de diagnostic principale mise en œuvre 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.

Claims

REVENDICATIONS
1. Procédé de diagnostic du dysfonctionnement d'un véhicule automobile par mise en œuvre 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 œuvre 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 œuvre 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 œuvre 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.
EP08828200A 2007-08-27 2008-08-19 Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile Withdrawn EP2181372A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0757187A FR2920558B1 (fr) 2007-08-27 2007-08-27 Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile
PCT/FR2008/051509 WO2009027609A1 (fr) 2007-08-27 2008-08-19 Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile

Publications (1)

Publication Number Publication Date
EP2181372A1 true EP2181372A1 (fr) 2010-05-05

Family

ID=39414919

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08828200A Withdrawn EP2181372A1 (fr) 2007-08-27 2008-08-19 Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile

Country Status (8)

Country Link
US (1) US20110125364A1 (fr)
EP (1) EP2181372A1 (fr)
JP (1) JP2010538249A (fr)
KR (1) KR20100051080A (fr)
CN (1) CN101784973A (fr)
FR (1) FR2920558B1 (fr)
RU (1) RU2010111761A (fr)
WO (1) WO2009027609A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8306687B2 (en) * 2009-11-10 2012-11-06 Innova Electronics, Inc. Method of diagnosing a vehicle having diagnostic data
CN102645341B (zh) * 2012-04-19 2015-05-20 李军 一种机动车健康状况的检测方法及系统
JP5949417B2 (ja) * 2012-10-09 2016-07-06 株式会社デンソー 中継装置
CN110324281B (zh) * 2018-03-29 2022-02-01 上海汽车集团股份有限公司 一种车载网络控制器刷新系统及方法
CN113377393B (zh) * 2020-03-10 2022-12-13 上汽通用汽车有限公司 一种车载系统主节点的诊断刷新系统及方法
US11574510B2 (en) 2020-03-30 2023-02-07 Innova Electronics Corporation Multi-functional automotive diagnostic tablet with interchangeable function-specific cartridges

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH079389B2 (ja) * 1989-04-14 1995-02-01 富士重工業株式会社 車輌の自己診断装置
JPH07271589A (ja) * 1994-03-29 1995-10-20 Fuji Heavy Ind Ltd 故障診断装置
GB2290631B (en) * 1994-06-24 1998-11-11 Fuji Heavy Ind Ltd Diagnosis system for motor vehicle and the method thereof
JP3219935B2 (ja) * 1994-06-24 2001-10-15 富士重工業株式会社 故障診断装置
JPH0815095A (ja) * 1994-06-24 1996-01-19 Fuji Heavy Ind Ltd 携帯型故障診断装置及び故障診断システム
JP3483691B2 (ja) * 1996-02-05 2004-01-06 本田技研工業株式会社 車両診断方法および装置
JPH09304115A (ja) * 1996-05-13 1997-11-28 Denshi Giken:Kk 電子制御装置のデータ解析装置
US6314422B1 (en) * 1997-12-09 2001-11-06 Chrysler Corporation Method for softlinking between documents in a vehicle diagnostic system
JP2001154725A (ja) * 1999-11-30 2001-06-08 Mitsubishi Motors Corp 車両の故障診断方法及び車両の故障診断装置並びに故障診断用プログラムを記録したコンピュータ読取可能な記録媒体
JP2002091545A (ja) * 2000-09-19 2002-03-29 Mitsubishi Motors Corp 車両用電子制御系の故障診断装置
US6882961B2 (en) * 2000-12-20 2005-04-19 Caterpillar Inc Method and system for providing diagnostics for a work machines
ES2387386T3 (es) * 2001-03-20 2012-09-21 Snap-On Incorporated Director de diagnóstico
JP2005092852A (ja) * 2003-08-08 2005-04-07 Mitsubishi Fuso Truck & Bus Corp 故障診断装置
US7218206B2 (en) * 2004-04-14 2007-05-15 Honeywell International Inc. Automotive latch debug and diagnostic user interface
DE102004041740A1 (de) * 2004-08-28 2006-03-02 Daimlerchrysler Ag Verbesserte Reparaturverifikation für elektronische Fahrzeugsysteme
DE102004042002A1 (de) * 2004-08-31 2006-03-02 Daimlerchrysler Ag Verbesserte Reparaturverifikation für elektronische Fahrzeugsysteme
US7254469B2 (en) * 2004-11-18 2007-08-07 Snap-On Incorporated Superimposing current or previous graphing data for anomaly detection
US20060142910A1 (en) * 2004-12-28 2006-06-29 Snap-On Incorporated Method for display of diagnostic procedures based on a repair technician's experience level
US7216052B2 (en) * 2005-02-08 2007-05-08 Spx Corporation Authoring diagnostic test sequences apparatus and method
JP2006219092A (ja) * 2005-02-14 2006-08-24 Nissan Motor Co Ltd 車両故障診断システム、車両故障診断方法、及び車両用故障診断装置
US8437902B2 (en) * 2005-10-31 2013-05-07 Service Solutions U.S. Llc Technical information management apparatus and method for vehicle diagnostic tools
US8423226B2 (en) * 2006-06-14 2013-04-16 Service Solutions U.S. Llc Dynamic decision sequencing method and apparatus for optimizing a diagnostic test plan

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2009027609A1 *

Also Published As

Publication number Publication date
KR20100051080A (ko) 2010-05-14
FR2920558A1 (fr) 2009-03-06
FR2920558B1 (fr) 2010-03-12
RU2010111761A (ru) 2011-10-10
US20110125364A1 (en) 2011-05-26
JP2010538249A (ja) 2010-12-09
WO2009027609A1 (fr) 2009-03-05
CN101784973A (zh) 2010-07-21

Similar Documents

Publication Publication Date Title
WO2019205858A1 (fr) Procédé, appareil et dispositif de diagnostic de véhicule
US10360740B2 (en) Methods and systems for diagnosing a vehicle using sound
US7209815B2 (en) Test procedures using pictures
US7739007B2 (en) Vehicle diagnostic method and system with intelligent data collection
CN108351995B (zh) 用于提供车辆维修提示的方法和系统
US8954222B2 (en) Method and system for retrieving diagnostic information
US9858733B2 (en) Vehicle diagnostic data collecting apparatus, vehicle diagnostic data collecting method, vehicle diagnostic machine, and vehicle diagnosing method
EP2181372A1 (fr) Procede et systeme de diagnostic du dysfonctionnement d'un vehicule automobile
CN108983748B (zh) 一种车辆故障检测方法及终端设备
US20030050747A1 (en) Failure diagnostic system and electronic control unit for use in diagnosing failure of vehicle
FR2800190A1 (fr) Procede et systeme pour l'autodiagnostic d'une voiture
EP3570131B1 (fr) Procédé d'aide au diagnostic intelligent, dispositif, et appareil
US11238676B2 (en) Automated vehicle scan tool initialization
EP2874106A1 (fr) Système et procédé de diagnostic de panne aéronef
JP2002535773A (ja) 組み込み型のオペーレティングシステムを有する装置をテストして妥当性を検査するためのシステム及び方法
CN113721584B (zh) 可视化车辆诊断方法及装置、设备和存储介质
US20200184744A1 (en) Vehicle Scan Tool Configured to Receive Automated Initialization Requests
WO2020123608A1 (fr) Initialisation automatisée d'outil de balayage de véhicule
WO2018111819A1 (fr) Procédés et systèmes de génération automatique d'ordres de réparation
CN114415642A (zh) 一种基于增强现实的车辆故障辅助维修方法、存储介质及系统
WO2009004203A1 (fr) Dispositif et procede d'aide au diagnostic d'un vehicule
FR3047340A1 (fr) Systeme d'aide a la decision d'autorisation a partir d'un aeronef, et procede associe
JP2005014743A (ja) 車両用故障部品探知装置
FR3008201A1 (fr) Systeme de validation d'un systeme de controle-commande
US20230350398A1 (en) Natural input processing for machine diagnostics

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100128

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20181008

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190219