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

Systeme de diagnostic predictif des dysfonctionnements d'un vehicule automobile et son dispositf de diagnostic embarque Download PDF

Info

Publication number
EP1673733B1
EP1673733B1 EP04817221.7A EP04817221A EP1673733B1 EP 1673733 B1 EP1673733 B1 EP 1673733B1 EP 04817221 A EP04817221 A EP 04817221A EP 1673733 B1 EP1673733 B1 EP 1673733B1
Authority
EP
European Patent Office
Prior art keywords
diagnostic
vehicle
diagnosis
module
data
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.)
Expired - Fee Related
Application number
EP04817221.7A
Other languages
German (de)
English (en)
Other versions
EP1673733A1 (fr
EP1673733B8 (fr
Inventor
Yves Knipper
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.)
Bosch Automotive Service Solutions Inc
Original Assignee
SPX Service Solutions France SARL
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 SPX Service Solutions France SARL filed Critical SPX Service Solutions France SARL
Publication of EP1673733A1 publication Critical patent/EP1673733A1/fr
Publication of EP1673733B1 publication Critical patent/EP1673733B1/fr
Application granted granted Critical
Publication of EP1673733B8 publication Critical patent/EP1673733B8/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0816—Indicating performance data, e.g. occurrence of a malfunction
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers

Definitions

  • the present invention relates to the diagnosis of malfunctions of motor vehicles.
  • the more advanced diagnostic aid of the document US-A 5,331,3388 comprises means for acquiring symptomatic data provided by a user of the vehicle, means for acquiring operating data of the vehicle and it makes it possible to automate the development of diagnostics by the introduction of electronic and computer means.
  • the diagnosis remains rather empirical.
  • a device comprising symptomatic data acquisition means provided by a user of the vehicle, prior symptomatic data acquisition means, first application diagnostic aid means, for each operating data of the vehicle, is known; at least one predefined method for assisting the diagnosis, and second means for assisting the diagnosis by comparing the data of at least one of the two groups, respectively comprising the symptomatic data provided by the user of the vehicle and the Operational data of the vehicle, with previous symptomatic data.
  • Previous symptomatic data means the designation of data relating to symptoms collected in the past on motor vehicles and for each of which at least one malfunction, which is the cause, is known.
  • the structure of the frames exchanged between the vehicle and the ground station is defined so as to make it possible to find incidents corresponding to previous frames or to store new incidents corresponding to frames not yet detected.
  • the link between the probe and the garage mechanic's diagnostic tool, on the one hand, and the link between the garage mechanic's tool and the server's server. constructor, on the other hand, may be radio links.
  • the server and the database which constitute a central system, are located at the manufacturer while the diagnostic tool, which completes the on-board mobile diagnostic management unit, can be fixed, or disembarked, either at the garage is at the manufacturer.
  • the remarkable aspect of the invention lies in the integration of a portion of the diagnostic intelligence on board the vehicle to react in real time.
  • the predictive or preventive diagnosis is associated with embedded intelligence whereas the curative diagnosis corresponds to the dismounted intelligence.
  • a vehicle operating variable starts to drift and cross an alert threshold, it can be diagnosed on board to trigger an alert to the manufacturer - in transparency for the driver - then , after treatment, towards the driver.
  • the central management unit comprises a controller of diagnostic data management agents at the input and output of the computers of the vehicle, that is to say agents managing the physical data transmission resources of the data carriers.
  • computers including the CAN, VAN and LIN networks of the vehicle, and the software resources of these computers.
  • the management agents respond to the management agent controller requests and issue alerts in the event of a malfunction and / or exceeding the threshold.
  • the diagnostic data is associated with each other to form diagnostic frames in the means for storing the diagnostic data, each frame thus stored associating the data involved in a single malfunction or a single diagnosis.
  • the central management unit comprises a search module in the storage means for extracting frames containing the diagnostic data item that has been the subject of an alert issued by a management agent.
  • the central management unit comprises an interrogation module for interrogating the fixed diagnostic tool and extracting therefrom frames containing at least the diagnostic data that have been the subject of alerts issued by at least one agent management.
  • the central management unit includes a module for updating the storage means of the diagnostic device for storing the frames containing the diagnostic data from which a diagnosis could be established on the operation of the vehicle.
  • the predictive diagnostic system 1 for malfunctions of a motor vehicle comprises either a diagnostic tool 2 ground, or fixed, or landed, located at a garage, a central diagnostic system 3, located at a manufacturer of motor vehicles, and having a diagnostic server 31 associated with a central base of diagnostic data 32, the tool and the central system can be in radio link TR, or by any other network, with an onboard diagnostic device which will be discussed below.
  • ECUs electronice control units
  • 320 essentially the electronic control units 310, 320,... 3i0, control by their control signal modules 313, 323,..., 3i3 and through the links CD, and / or control, by RA network links that may belong to the CAN, VAN and LIN of the vehicle, with sensors 314, 324, ..., 3i4 associated with these ECUs, the functions 400 of the vehicle: its engine, the cockpit and its man - machine interface, its electrical, pneumatic, hydraulic, thermal, etc ...
  • the data of the sensors are collected by electronic cards 312, 322,..., 3i2, either self-test cards “BITE” (built-in test equipment) or “OBD” (on board diagnosis) cards, which deliver malfunction alerts or failures, over threshold.
  • BITE built-in test equipment
  • OOB on board diagnosis
  • the ECUs are equipped with diagnostic data management agents 311, 321,..., 3i1, that is to say, physical measurements taken on the members providing the functions 400 and the parameters of 3i3 modules controlling these organs, collected by the OBD / BITE cards or not, and regardless of the alerts they deliver.
  • diagnostic data are generic symptomatic data dysfunction.
  • the management agents 3i1 respond to requests from a management agent controller 110, explained below, and issue deviation data with respect to the operating standards and malfunction alarms.
  • the management agents also manage the physical data transmission resources of these computers by the CAN, VAN and LIN networks of the vehicle.
  • the central diagnostic management unit 100 may comprise several subassemblies that naturally can communicate with each other and cooperate together to perform the diagnosis.
  • the driver 221 is designed to communicate so that for the server and its associated base, or tool 2, the CPU 100 of Diagnostic management behaves like a personal computer network computer, LAN or INTRANET.
  • HMI human-machine interface
  • the central management unit 100 will now be described, with reference to the figure 2 .
  • This unit comprises a real-time controller 110, already mentioned above, 3i1 agents for managing the diagnostic data, input and output computers 3i0 of the vehicle.
  • the controller 110 is connected at the output to a module 120 for searching the received data frames and alerts, itself connected to a memory 121 of the data being processed, to the memory 202 of the diagnostic frames via the link 203, and input to a module 140 for managing requests to be sent to the management agents 3i1, this module 140 being connected to a memory 141 of the current requests.
  • the central unit 100 also comprises a diagnostic interrogation module 130.
  • the diagnostic interrogation module 130 receives the "candidate" data frames to be analyzed, transmitted by the frame search module 120, and can send requests to the request management module 140 for the agents 3i1, each agents managing and issuing these requests in the corresponding ECUs 3i0, either to the BITE modules 3i2 or to the control 3i3 modules 3i3.
  • the diagnostic data is associated with each other to form significant pre-diagnosis frames, each frame being defined by the association of the data involved in a single pre-diagnosis, and when the pre-diagnosis is proven, for example during the pre-diagnosis period.
  • the sub-module 134 also controls, also connected to the memory 202 by the link 203, a module 160 for updating this memory 202 frames containing diagnostic data from which a pre-diagnosis could be established on the operation of the vehicle.
  • the external interrogation sub-module 134 and the request management module 140 are connected to the HMI via a dialogue module 180 controlling the HMI via the link 213, and by receiving the answers.
  • the significant physical measurements of the operation of the engine 400 of the vehicle are cyclically carried out by the sensors 314 and collected by the card 312 via the network RA or directly calculated by the ECU 310, in this case a CCM (engine control computer), when the measurement is not accessible by calculation.
  • the management agent 310 takes some of these measurements, for example from the upstream and downstream lambda probes, in connection with significant pre-diagnosis frames related to the current operation, issued by the central processing unit 100. diagnostics, as well as the operating standards corresponding to the current operating parameters of application, here, for example carburizing richness charts and the angle of the acceleration control, the torque, the engine oil temperature, etc.
  • the agent 310 issues a dated alert and all of the diagnostic data thus collected to the controller 110 via the network RB.
  • the controller 110 collects, in step 10, all the alerts and the corresponding diagnostic data from all the ECUs of the vehicle and sorts them chronologically to prepare the subsequent establishment of a history, the dating being able to be a pre-diagnosis element before communicating them to the module 120 for searching the frames.
  • the module 120 synthesizes the diagnostic data received from the various ECUs and stored over time in the memory 121 of the data being processed by assembling them into a coherent frame " candidate "at the functional level of the vehicles, that is to say assembling data, engine control, electricity, cooling, ..., concerning physical quantities affecting the same functional process of the vehicle, for example engine operation, and according to a chronology corresponding to a possible degradation process.
  • These "candidate" frames are built on the frame patterns stored in advance in the memory 202.
  • step 40 the candidate frame is compared, by the module 132, to the previous candidate frames stored in the memory 201 of the vehicle history. If she is not there, she is memorized. Otherwise, the module 120 takes into account the result of the treatment which then took place. In particular, if there has been pre-diagnosis, we go to a step 41 HMI alert, and again to step 20 to search for a new candidate frame.
  • step 40 If in step 40 it turns out that the candidate frame is new for the vehicle, we go to a step 50, executed by the module 134, in which the same interrogation as in the step 40 is performed, but bearing, this time on the entire fleet of vehicles of the same type.
  • the module 134 sends requests to the message generation module 170 which, during a step 51, loads the communication means 220, via the link 223, the driver 221 ensuring the waiting, in a step 52, the responses of the tool 2 or the central diagnostic system 3, and possibly a restart in case of communication failure.
  • the module 134 retrieves the frames of the communicated responses and pre-diagnostics and, in step 60, analyzes them. These responses may be a pre-diagnosis corresponding to the candidate frame, in which case the alerting step 41 is executed, and the driver of the vehicle alerted, or frames of diagnostic data compatible with the candidate frame, in which case we pass in a step 70 of further research to be performed by the module 140, or an absence of risk, in which case no pre-diagnosis is possible and returns to step 10.
  • a vehicle operating variable starts drifting outside the standards and possibly crossing an alert threshold, it can be diagnosed on board to trigger an alert to the manufacturer and, after treatment, to the driver.
  • compatible frames frames having the same diagnostic data in common, one more complete with more data than the other, among the data capable of generating at least one symptomatic data dysfunction.
  • the module 140 records the missing data and analyzes the possibility of collecting them or no.
  • a test request 71 may be requested from the driver of the vehicle via the instrument panel HMI and, after acknowledgment 72 of the driver, the module 120 executes a step 30 of updating the candidate frame for a new analysis in steps 40 and 50 executed by the internal and external interrogation modules 132 and 134.
  • the module 140 generates a request for the management agents 3i1 concerned, a request sent by the controller 110 via the network RB during a step 90.
  • a function for downloading software, from the central diagnostic system 3, in the computers 3i0, to modify, via the agents 3i1, the computer ECU software that controls the acquisition of diagnostic data.
  • step 30 is reactivated.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Small-Scale Networks (AREA)

Description

  • 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 31. 3 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.
  • Par le document EP 1 197 822 , on connait un dispositif dans lequel deux mémoires de stockage, l'une sur le véhicule, l'autre au sol, sont en communication et stockent des données de diagnostic. Le problème que l'invention se propose de résoudre, en relation avec ce document de l'art antérieur, est de permettre une recherche simple de structures de trames caractéristiques des paramètres techniques du véhicule dans une base de données pour retrouver des incidents déjà répertoriés et enrichir ladite base de données si ladite structure de trame n'a pas encore été observée.
  • La solution à ce problême est donnée par un système d'enregistrement et d'exploitation de données de diagnostic selon la revendication 1.
  • Selon l'invention, la structure des trames échangées entre le véhicule et la station au sol est définie de manière à permettre de retrouver des incidents correspondants à des trames antérieures ou de stocker de nouveaux incidents correspondants à des trames non encore détectées.
  • 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.
  • Un dispositif de diagnostic embarqué dans un véhicule automobile, comporte:
    • 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, thermiques, 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 comme expliqué ci-après.
  • D'une part, les ECUs sont équipés d'agents 311, 321, ..., 3i1 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 3i1 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 l'IHM (interface homme-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 3i1 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 3i1 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 3i1, 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 l'intermé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 l'IHM, 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 à l'IHM par l'intermédiaire d'un module 180 de dialogue commandant l'IHM 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 l'unité 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 communiquer 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éhicules, 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é à bord 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 3i1 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. 1) via leur carte de contrôle 3i3, agit sur le processus pour rendre les mesures faisant défaut plus significatives,
    2. 2) programme l'exécution de mesures complémentaires par leur carte de test BITE ou OBD 312
    3. 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 3i1, 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 (12)

  1. Système d'enregistrement et d'exploitation de données de diagnostic relatives au fonctionnement des organes d'un véhicule automobile d'un type donné comprenant:
    - une unité centrale (100) de gestion de diagnostic, comprenant un contrôleur (110) d'agents (3i1) de gestion desdites données de diagnostic en entrée et en sortie des calculateurs ECU (3i0) du véhicule,
    - un réseau (RA, RB) d'acquisition de données de diagnostic, relié à l'unité centrale,
    - au moins une première mémoire de stockage (200) sur ledit véhicule de premières données de diagnostic relatives audit véhicule, - au moins une liaison de communication (220) pour communiquer avec au moins une station de diagnostic (2, 31) hors du véhicule
    - au moins une deuxième mémoire de stockage sur ladite au moins une station de diagnostic de deuxièmes données de diagnostic relatives à des véhicules dudit type,
    ladite unité centrale comprenant en outre
    - un sous-module (132) de lecture et d'écriture sur la première mémoire de stockage,
    - un sous-module (134) de lecture et d'écriture sur la deuxième mémoire de stockage,
    ledit système étant caractérisé en ce que lesdites premières et deuxièmes données ont une structure de trame comprenant en première partie au moins une valeur d'au moins un paramètre de fonctionnement d'au moins un organe d'un véhicule et une deuxième partie comprenant un prédiagnostic associé à la au moins une valeur de la première partie de trame
  2. Système selon la revendication 1, caractérisé en ce que le sous-module (132) est configuré pour exécuter pour un ensemble préprogrammé de paramètres dont les valeurs en sortie des agents (3i1) sont assemblées par le contrôleur (110) selon la structure de la première partie de trame, un programme de première recherche desdites valeurs assemblées dans la première mémoire de stockage, puis pour : i) en cas de recherche positive de la dite première recherche, faire afficher le prédiagnostic correspondant en sortie sur un écran de l'habitacle; ii) en cas de recherche négative de la dite première recherche, pour faire exécuter par le sous-module (134) un programme identique dans la deuxième mémoire de stockage, pour en cas de recherche positive de ladite deuxième recherche, faire afficher le prédiagnostic correspondant en sortie sur un écran de l'habitacle et écrire la trame correspondante dans la première mémoire de stockage.
  3. Système selon l'une des revendications 1 à 2, caractérisé par le fait que si une variable de fonctionnement du véhicule se met à dériver et a franchir un seuil d'alerte, cela est diagnostiqué a bord pour déclencher une alerte vers le constructeur puis, après traitement, vers le conducteur.
  4. Système selon l'une des revendications 1 à 3, dans lequel les agents (3i1) de gestion répondent aux requêtes du contrôleur (110) d'agents de gestion et émettent des alertes en cas de dysfonctionnements.
  5. Système selon l'une des revendications 1 à 4 dans lequel chaque trame mémorisée associe les données impliquées dans un seul dysfonctionnement pouvant donner lieu à un seul diagnostic.
  6. Système selon la revendication 5, dans lequel chaque trame mémorisée associe les données impliquées dans un seul dysfonctionnement pouvant donner lieu à un seul diagnostic.
  7. Système selon l'une des revendications 1 à 6, 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 (3i1).
  8. Système selon l'une des revendications 1 à 7, 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 (3i1).
  9. Système selon l'une des revendications 1 à 8, 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.
  10. Système selon l'une des revendications 1 à 9, embarqué à bord d'un véhicule et constituant une partie du système de l'une des revendications 1 et 2.
  11. Système selon l'une des revendications 1 ou 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.
  12. Système selon l'une des revendications 1 ou 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.
EP20040817221 2003-10-14 2004-10-13 Systeme de diagnostic predictif des dysfonctionnements d'un vehicule automobile et son dispositf de diagnostic embarque Expired - Fee Related EP1673733B8 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0312004A FR2860895B1 (fr) 2003-10-14 2003-10-14 Systeme de diagnostic predictif des dysfonctionnements d'un vehicule automobile et son dispositif de diagnostic embarque
PCT/FR2004/002592 WO2005038725A1 (fr) 2003-10-14 2004-10-13 Systeme de diagnostic predictif des dysfonctionnements d’un vehicule automobile et son dispositf de diagnostic embarque

Publications (3)

Publication Number Publication Date
EP1673733A1 EP1673733A1 (fr) 2006-06-28
EP1673733B1 true EP1673733B1 (fr) 2015-03-11
EP1673733B8 EP1673733B8 (fr) 2015-05-13

Family

ID=34355468

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20040817221 Expired - Fee Related EP1673733B8 (fr) 2003-10-14 2004-10-13 Systeme de diagnostic predictif des dysfonctionnements d'un vehicule automobile et son dispositf de diagnostic embarque

Country Status (4)

Country Link
EP (1) EP1673733B8 (fr)
ES (1) ES2534852T3 (fr)
FR (1) FR2860895B1 (fr)
WO (1) WO2005038725A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012202540A1 (de) * 2012-02-20 2013-08-22 Robert Bosch Gmbh Diagnoseverfahren und Diagnosevorrichtung für eine Fahrzeugkomponente eines Fahrzeugs
CN107271163B (zh) * 2017-06-16 2018-09-28 英特尔产品（成都）有限公司 用于冷却器的本地诊断和验证系统及方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5313388A (en) 1991-06-07 1994-05-17 Ford Motor Company Method and apparatus for diagnosing engine and/or vehicle system faults based on vehicle operating or drive symptoms
US5442553A (en) * 1992-11-16 1995-08-15 Motorola Wireless motor vehicle diagnostic and software upgrade system
US6546363B1 (en) * 1994-02-15 2003-04-08 Leroy G. Hagenbuch Apparatus for tracking and recording vital signs and task-related information of a vehicle to identify operating patterns
FR2791158B1 (fr) 1999-03-19 2004-10-08 Sagem Dispositif d'aide au diagnostic d'un dysfonctionnement d'un vehicule automobile
JP3834463B2 (ja) * 2000-10-13 2006-10-18 株式会社日立製作所 車載故障警報通報システム
CN1218537C (zh) * 2000-10-13 2005-09-07 帕克斯格里德遥测系统公司 将来自车辆的车辆运行数据传递到远程监视接收者的方法
JP2002323409A (ja) * 2001-04-26 2002-11-08 Fuji Heavy Ind Ltd 車両管理システム
JP2003044704A (ja) * 2001-07-31 2003-02-14 Honda Motor Co Ltd サービス提供方法
US20030130774A1 (en) * 2002-01-03 2003-07-10 Tripathi Pradeep R. Vehicle inspection enforcement system and method offering multiple data transmissions on the road

Also Published As

Publication number Publication date
EP1673733A1 (fr) 2006-06-28
FR2860895A1 (fr) 2005-04-15
WO2005038725A1 (fr) 2005-04-28
ES2534852T3 (es) 2015-04-29
FR2860895B1 (fr) 2006-05-12
EP1673733B8 (fr) 2015-05-13

Similar Documents

Publication Publication Date Title
EP2112492B1 (fr) Liste d'exigences de test pour tests de diagnostic
US6836708B2 (en) Monitoring of vehicle health based on historical information
You et al. Overview of remote diagnosis and maintenance for automotive systems
US20130054082A1 (en) Method and system for retrieving diagnostic information
US8346700B2 (en) Vehicle health monitoring reasoner architecture for diagnostics and prognostics
CN109163913A (zh) 一种汽车故障诊断方法及相关设备
EP2912526B1 (fr) Système de surveillance d'un ensemble de composants d'un équipement
EP2874106A1 (fr) Système et procédé de diagnostic de panne aéronef
FR2973882A1 (fr) Procede et dispositif pour la determination de diagnostics
EP3213213A1 (fr) Procédé, équipement et système d'aide au diagnostic
CA2837523A1 (fr) Systeme de prescription de maintenance d'un moteur d'helicoptere
Panda et al. ML-based vehicle downtime reduction: A case of air compressor failure detection
EP1673733B1 (fr) Systeme de diagnostic predictif des dysfonctionnements d'un vehicule automobile et son dispositf de diagnostic embarque
EP4167040A1 (fr) Éditeur de modèle de défaut et outil de diagnostic
US20220180671A1 (en) Methods and systems for engine diagnostics for vehicles using obd port
EP1573412B1 (fr) Procede de diagnostic de defauts de fonctionnement d une arc hitecture fonctionnelle
EP1039390B1 (fr) Dispositif d'aide au diagnostic d'un dysfonctionnement d'un véhicule automobile
EP1451655B1 (fr) Procede de diagnostic de defauts de fonctionnement d'un ensemble de systemes electroniques, notamment dans un vehicule automobile
FR2970947A1 (fr) Equipement a surveillance integree remplacable en escale et architecture distribuee comprenant un tel equipement
EP4379681A1 (fr) Procédé de détection, de prédiction et de prévention de l'apparition de défaillances et de contrôle de continuité de véhicules, système mettant en oeuvre ledit procédé et dispositif utilisé dans ledit système
Ming et al. Classifying drivers using electronic logging devices
Namburu et al. Application of signal analysis and data-driven approaches to fault detection and diagnosis in automotive engines
WO2009004203A1 (fr) Dispositif et procede d'aide au diagnostic d'un vehicule
Carr Practical application of remote diagnostics
Рибіцький et al. Using OBD-2 technology for vehicle diagnostic and using it in the information system

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: 20060504

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE ES FR GB IT

17Q First examination report despatched

Effective date: 20061006

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE ES FR GB IT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: JOHNSON CONTROLS AUTOMOTIVE ELECTRONICS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SPX SERVICE SOLUTIONS FRANCE SARL

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20140930

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE ES FR GB IT

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

RAP2 Party data changed (patent owner data changed or rights of a patent transferred)

Owner name: BOSCH AUTOMOTIVE SERVICE SOLUTIONS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602004046796

Country of ref document: DE

Effective date: 20150423

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2534852

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20150429

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602004046796

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20151214

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20171023

Year of fee payment: 14

Ref country code: DE

Payment date: 20171206

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20171020

Year of fee payment: 14

Ref country code: ES

Payment date: 20171103

Year of fee payment: 14

Ref country code: GB

Payment date: 20171024

Year of fee payment: 14

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602004046796

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20181013

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190501

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181031

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181013

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181013

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20191202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181014