DE60305783T2

DE60305783T2 - Verfahren und System zur Prüfung eines Fahrzeugs mit Onboard-Diagnoseeinrichtung

Info

Publication number: DE60305783T2
Application number: DE60305783T
Authority: DE
Inventors: Earl D. Ortonville Diem
Original assignee: Delphi Technologies Inc
Current assignee: Delphi Technologies Inc
Priority date: 2002-04-22
Filing date: 2003-03-31
Publication date: 2007-05-24
Anticipated expiration: 2023-04-01
Also published as: US6529808B1; EP1356996A3; DE60305783D1; EP1356996A2; EP1356996B1

Description

Hintergrund der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf Onboard-Diagnose(OBD)-Systeme in Fahrzeugen und insbesondere auf ein Verfahren und System zum Analysieren von OBD-Daten gemäß einem Inspektions- und Wartungsprogramm für Fahrzeuge.
Das Clean Air Act in der Fassung von 1990 (CAA) verlangt von der Umweltschutzbehörde (engl. Environmental Protection Agency (EPA)), Richtlinien zu erlassen, die Staaten beim Entwerfen und Durchführen von Inspektions- und Wartungsprogrammen (I/M) für Fahrzeuge befolgen. Ebenso wie zwischen grundlegenden und verbesserten I/M-Programmen unterschieden wird, müssen diese Richtlinien verdeutlichen, wie Staaten andere minimale Entwurfsanforderungen erfüllen sollen, die von der CAA vorgegeben werden. Eine solche Forderung, die für sowohl grundlegende als auch verbesserte I/M-Programme Anwendung findet, ist die Durchführung von Überprüfungen mit Onboard-Diagnosesystemen (OBD) als Teil einer vorgeschriebenen regelmäßigen Fahrzeuginspektion.
Staaten nutzen typischerweise Computersysteme in verschiedenen Ausführungen, um Inspektoren beim Durchführen von Sicherheits- und Emissionsinspektionen zu leiten und zu unterstützen. Gegenwärtig führen Staaten die Emissionsinspektion von Kraftfahrzeugen durch, indem das Abgas des Fahrzeugs unter simulierten Fahrbedingungen analysiert wird. Seit 1996 sind jedoch sowohl ausländische als auch inländische Kraftfahrzeuge mit der Fähigkeit zur Onboard-Diagnose (OBD) ausgestattet. Ein OBD-System ist ein System von Überwachungseinrichtungen für Fahrzeugkomponenten und -bedingungen, die von einem zentralen Onbo ard-Computer gesteuert werden. Der OBD-Computer nutzt Software, die dafür entworfen wurde, dem Autofahrer zu signalisieren, wann Bedingungen herrschen, die dazu führen könnten, dass das Fahrzeug seine Emissionsnormen um das 1,5-fache der Norm überschreitet. Als Teil eines Gesamtprogramms zur Inspektion und Wartung (I/M) von Fahrzeugen gemäß der Clean Air Act verlangt dementsprechend nun jeder Staat, als Teil dieser Programme, um die Emissionsinspektion durchzuführen, eine Überprüfung eines OBD-Computers eines Fahrzeugs einzubeziehen.
Eine OBD-I/M-Überprüfung umfasst im Allgemeinen zwei Arten einer Untersuchung. Zunächst führt ein Inspektor eine optische Überprüfung von Funktion und Status der Armaturenbrettanzeige (worauf auch als das Anzeigelicht für eine Fehlfunktion „MIL" und/oder Glühbirnenüberprüfung verwiesen wird) durch. Eine zweite Prozedur ist eine elektronische Untersuchung und Analyse des OBD-Computers selbst. Im Allgemeinen wird ein Scan-Instrument oder ein ähnliches Handinstrument genutzt, um Emissionsdaten vom OBD-Computer des Fahrzeugs in Form standardisierter Diagnosestörungscodes (DTCs) zu extrahieren.
Prüfverfahren und die zugehörigen Vorrichtungen sind per se z.B. aus DE 100 24 190 oder WO 02/14828 bekannt, wobei DE 100 24 194 sich auf eine Diagnoseeinrichtung insbesondere für ein Leistungsgetriebeelement für ein Kraftfahrzeug bezieht, das einen Motor, ein Getriebe und eine Kupplung aufweist, und wobei WO 02/14828 darauf gerichtet ist, die Durchführung einer Abgasanalyse in einer größtenteils automatischen Weise an Kraftfahrzeugen zu ermöglichen, die ein Onboard-Steuerungs- und Diagnosesystem (OBD) für einen Motor aufweisen und mit einer Diagnoseschnittstelle ausgestattet sind. Zu diesem Zweck werden Steuerungsbefehle vorzugsweise in einer Abgasprüfeinrichtung erzeugt und über die Diagnoseschnittstelle an ein Steuerungs- und Diagnosesystem für einen Motor gesendet, das gemäß den Steuerungsbefehlen die Betriebszustände des Kraftfahrzeugs einstellt, welche für die Abgasanalyse vorgeschrieben sind. Überdies betrifft ein Dokument „Performing Onboard Diagnostic System Checks as Part of a Vehicle Inspection Maintenance Program" von David Sosnowski et al. die Durchführung von Systemprüfungen vor Beginn einer vollständigen Analyse.
Infolge der relativen Neuheit standardisierter OBD-Systeme (worauf auch als Onboard-Diagnoseeinrichtung Generation II oder OBD II verwiesen wird) sind gewisse Schwierigkeiten aufgetreten. Zum Beispiel sind bestimmte Fahrzeugmodelle vom Standpunkt der „Bereitschaft" (engl. readiness) gegenwärtig nicht kompatibel mit OBD-Software. Bereitschaft bezieht sich darauf, ob der Computer des Fahrzeugs die Möglichkeit hat, die Fahrzeugfunktionen vollständig zu überwachen und auszuwerten, oder nicht. Folglich speichert die OBD ein Status-Flag oder einen „Bereitschaftscode" für jede Überwachungseinrichtung. Der Bereitschaftscode ist von einem DTC insofern verschieden, als der Bereitschaftscode keine Störung des Fahrzeugs anzeigt, sondern vielmehr, ob eine gegebene Überwachungseinrichtung laufen gelassen wurde oder nicht (d.h. ob die betreffende Komponente oder das betreffende System überprüft wurde, um zu bestimmen, ob es korrekt funktioniert). Bei einigen Fahrzeugen können die Bereitschaftscodes mit abgezogenem Schlüssel gelöscht werden. Bei anderen Fahrzeugen kann ein „Auslöser gestützter" Entwurf bedingen, dass Katalysatoren- und Verdampfungsüberwachungseinrichtungen einen Zustand „Nicht Bereit" widerspiegeln. In jedem Fall werden solche Scan-Anomalien von bestehenden OBD-Scansystemen nicht berücksichtigt.
Eine weitere Schwierigkeit, auf die man bei OBD-I/M-Programmen trifft, besteht darin, einen Datenleitungsverbinder (DLC) (engl. data link connector) für bestimmte Fahrzeuge zu lokalisieren. Der DLC ist eine Schnittstel le zwischen einem OBD-Computer eines Fahrzeugs und dem OBD-Scanner. Das Verbinden eines OBD-Scanners mit dem DLC ermöglicht I/M-Inspektoren und Technikern für die Fahrzeugreparatur, den Bereitschaftsstatus der verschiedenen Onboard-Überwachungseinrichtungen sowie etwaiger DTCs des Fahrzeugs zu lesen. Obwohl sich der DLC gewöhnlich auf der Fahrerseite eines Fahrzeugs unter dem Armaturenbrett befindet, ist dies nicht immer der Fall. Während die EPA eine Liste von Fahrzeugen mit schwer zu findenden DLC-Stellen gemäß Fabrikat und Modelljahr zusammengestellt hat, sind derartige Informationen für den Inspektor nicht ohne weiteres oder zweckmäßig bzw. bequem zugänglich.
Zusammenfassung
Die oben diskutierten und weitere Nachteile und Unzulänglichkeiten des Stands der Technik werden durch ein Verfahren zum Prüfen eines Fahrzeugs in einer Inspektion mit einer Onboard-Diagnoseeinrichtung gemäß Anspruch 1 und ein entsprechendes Fahrzeuganalysesystem zur Verwendung bei Fahrzeugen mit Onboard-Diagnoseeinrichtungen nach Anspruch 8 überwunden oder gemildert. In einer beispielhaften Ausführungsform beinhaltet das Verfahren die Schritte: Konfigurieren einer Nutzerschnittstelle in Verbindung mit einem Software-System und Konfigurieren einer Nachrichtenverbindung in Verbindung mit dem Software-System. Das Software-System kann mit einem Computersystem an Bord eines Fahrzeugs kommunizieren. Außerdem ist ein Analyse- und Meldemodul in Verbindung mit dem Software-System konfiguriert, wobei das Software-System die Nutzerschnittstelle, die Nachrichtenverbindung und das Analyse- und Meldemodul in einer Weise verwaltet, dass es einen Inspektor durch eine Inspektion des Fahrzeugs führt. Eine Inspektion des Fahrzeugs beinhaltet vorzugsweise auch eine Analyse des Computersystems an Bord des Fahrzeugs.
Das Verfahren beinhaltet ferner den Schritt: Empfangen eingegebener Fahrzeugdatenfelder für das Fahrzeug in einer Inspektion, Vergleichen der eingegebenen Fahrzeugdatenfelder mit Daten, die in einer Nachschlagetabelle des Fahrzeugs enthalten sind, und Bestimmen, ob das Fahrzeug in einer Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird. Falls das Fahrzeug in einer Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird, führt dann das Software-System einen Inspektor durch einen Prozess einer Fahrzeuginspektion.
Falls das Fahrzeug in einer Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird, wird dann basierend auf den eingegebenen Fahrzeugdatenfeldern und den in der Nachschlagetabelle des Fahrzeugs enthaltenen Daten entsprechend dem Fahrzeug in einer Inspektion bestimmt, ob das Fahrzeug in einer Inspektion einer standardisierten Prüfprozedur oder einer Spezial-Prüfprozedur unterzogen wird. Falls bestimmt wird, dass das Fahrzeug in einer Inspektion einer Spezial-Prüfprozedur unterzogen wird, führt dann das Software-System den Inspektor durch die Spezial-Prüfprozedur.
In einem weiteren Aspekt beinhaltet das Verfahren den Schritt: Anweisen des Inspektors, einen Onboard-Diagnoseverbinder im Fahrzeug in einer Inspektion anzuordnen, wobei Informationen über die Stelle des Onboard-Diagnoseverbinders ebenfalls in der Nachschlagetabelle des Fahrzeugs enthalten sind. Überdies wird eine Datenübertragung zwischen dem Analyse- und Meldemodul und dem Computersystem an Bord des Fahrzeugs eingerichtet. Der Betriebsstatus eines Anzeigelichts (MIL) für eine Fehlfunktion, das im Fahrzeug in einer Inspektion enthalten ist, wird verifiziert. Es wird dann bestimmt, ob das MIL während des Betriebs des Fahr zeugs in einer Inspektion auf einen Befehl hin eingeschaltet wurde, und Diagnosestörungscodes des Fahrzeugs werden abgerufen und gespeichert.
In noch einem weiteren Aspekt wird für jede eines Satzes von Überwachungseinrichtungen für Fahrzeugparameter ein Bereitschaftsstatus bestimmt, wobei der Bereitschaftsstatus angibt, ob eine gegebene Überwachungseinrichtung für einen Fahrzeugparameter ausreichend Zeit gehabt hat, den ihr zugeordneten Parameter zu überwachen. Ein möglicher Bereitschaftsstatus für jede Überwachungseinrichtung für einen Fahrzeugparameter beinhaltet Abgeschlossen, Nicht Abgeschlossen oder Nicht Freigegeben. Der Satz von Überwachungseinrichtungen für Fahrzeugparameter umfasst eine Überwachungseinrichtung für eine Fehlzündung, ein Kraftstoffsystem, eine umfassende Bauteilüberwachung, für einen Katalysator, für einen erhitzten Katalysator, für ein Verdampfungssystem, für ein Sekundärluftsystem, für ein Klimaanlagensystem, für einen Sauerstoffsensor, für eine Heizeinrichtung für einen Sauerstoffsensor und/oder für ein Abgasrückführungssystem.
Kurze Beschreibung der Zeichnungen
Bezug nehmend auf die beispielhaften Zeichnungen, worin gleiche Elemente in den verschiedenen Figuren gleich nummeriert sind, zeigt:
1a ein durch einen OBD-Analysator verkörpertes OBD-Analyse- und Meldemodul einschließlich eines Personal Computers und eines Bildschirms zu Beginn einer Prüfung für eine Anzeige gemäß einer Ausführungsform der Erfindung;
1b eine alternative Ausführungsform eines OBD-Systems, das ein server-gestütztes PC-Netzwerk umfasst;
1c noch eine alternative Ausführungsform eines OBD-Systems, das ein server-gestütztes drahtloses Netzwerk von CE-Geräten umfasst;
1d ein beispielhaftes CE-Handgerät der Ausführungsform von 1c;
2-14 Bildschirmaufnahmen beispielhafter Eingabeaufforderungen auf einem Anzeigegerät der Ausführungsformen der vorliegenden Erfindung; und
15a-e und 16a-f Flussdiagramme, die ein Verfahren zum Analysieren eines OBD-Systems veranschaulichen.
Ausführliche Beschreibung
Hierin werden ein Verfahren und System offenbart, das sowohl Hardware als auch Software einschließt, die verwendet werden, um auf die Onboard-Computersysteme für Fahrzeuge aus dem Modelljahr 1996 und jünger zuzugreifen (d.h. diejenigen Fahrzeuge, die ODB-Tauglichkeit besitzen), um die Bereitschaft für eine Onboard-Diagnoseeinrichtung Generation II (OBD II) wie durch Titel 40 des Code of Federal Regulations (CFR) definiert zu bestimmen und gespeicherte Störungscodes unter Verwendung der gemäß der Society of Automotive Engineers (SAE) standardisierten Verknüpfung bzw. Verbindung wiederzugewinnen. Das Verfahren und System ist ferner dafür ausgelegt, einen Inspektor durch die OBD-Inspektionssequenz für ein bestimmtes Fahrzeug zu führen und die Ergebnisse aufzuzeichnen.
Informationen bezüglich Scan-Anomalien nach OBD II (z.B. der Status „Nicht Bereit", der für Subaru-Fahrzeuge von 1996 charakteristisch ist) werden in einer OBD-Fahrzeugnachschlagetabelle (VLT) gepflegt. Außerdem werden Informationen bezüglich einer genauen Stelle eines Datenleitungsverbinders (DLC) für Fahrzeuge von 1996 und neuere in der OBD-VLT ebenfalls gepflegt. Diese Informationen werden bei einer Systeminitialisierung zu einem Analysator herunter geladen und werden (wenn die OBD-VLT aktualisiert wird) auch automatisch auf einer Anzeige des Analysators angezeigt, wann immer ein geprüftes Fahrzeug bestimmte Kriterien wie z.B. Fabrikat, Modell und Modelljahr erfüllt.
Diese System-Software ist so ausgelegt, dass sie den Forderungen von Titel 40 Code of Federal Regulations Titel 51 genügt, außer wie im Folgenden besonders erwähnt.
In 1a ist zunächst ein OBD-Analyse- und Meldemodul in Form eines Analysators 10 gemäß einer Ausführungsform der Erfindung dargestellt. Der Analysator 10 in dieser Ausführungsform bildet ein „eigenständiges" System, das einen Personal Computer einschließt, auf welchem System-Software geladen ist und laufen gelassen wird. Der Analysator 10 ist ferner über ein (nicht dargestelltes) Schnittstellenkabel mit dem (nicht dargestellten) Onboard-Computer eines (nicht dargestellten) Kraftfahrzeugs gekoppelt. Mit Blick auf eine dezentralisierte Prüfung unterstützt der eigenständige Analysator 10 eine automatisierte OBD-I/M-Prüfprozedur und Datenbankoperationen auf einem einzelnen Windows^® 98/ME-Endgerät. Zusätzlich wird zusammen mit anderen Systemoptionen ein Strichcode-Scannen unterstützt. Eine Meldung von Datenbankinformationen wird in einem „Push"- bzw. Einspeicherungsausführung an eine zentrale Stelle bewerkstelligt.
1b veranschaulicht eine alternative Ausführungsform für ein OBD-System 100, in welchem die OBD-Software von einem Server 102 geladen und laufen gelassen wird und auf welches ferner von mehreren Personal Computern 104 in Verbindung mit dem Server 102 zugegriffen werden kann. Ein derartiges vernetztes PC-System ermöglicht folglich, dass die OBD-Diagnosesoftware von Personal Computern 104 laufen gelassen wird, die sich in verschiedenen Bereichen eines Arbeitsplatzes befinden können.
Mit Blick auf eine zentralisierte Prüfung unterstützt das OBD-System 100 die automatisierte OBD-I/M-Prüfprozedur auf vernetzten Windows^® 98/ME-Endgeräten 104, die als Clients dienen. Die OBD-Prüfanalyse und Datenbankoperationen werden über eine Serveranwendung, die lokal vorliegt und mit den Client-PCs 104 vernetzt ist, bewerkstelligt. Wie bei dem eigenständigen Analysator von 1a wird zusammen mit anderen Systemoptionen ein Strichcode-Scannen unterstützt. Die Datenbankmeldung wird in einer Einspeicherungsausführung an eine zentrale Stelle durchgeführt. Eine Datenübertragung über das Netzwerk kann je nach Spezifikation des Client mittels eines Transport Control Protocol/Internet Protocol (TCP/IP) über ein verdrahtetes oder Hochfrequenz-(HF)-Netzwerk ausgeführt werden.
1c veranschaulicht noch eine andere Ausführungsform eines OBD-Systems 300, in welchem ein zentraler Server 202 die darauf geladene OBD-Software aufweist und verwendet wird, um in einem drahtlosen Netzwerk mit mehreren Windows^® CE-Handgeräten 204 zu kommunizieren. Ein solches CE-Gerät 204 ist in 1d mit einem J1928-Schnittstellenbus eines Fahrzeugs gekoppelt veranschaulicht. Diese Ausführungsform, die auch auf eine zentralisierte Prüfung abzielt, unterstützt die automatisierte OBD-I/M-Prüfprozedur auf den vernetzten Windows^® CE-Endgeräten 204, die als Clients dienen. Prüfanalyse und Datenbankopera tionen werden über eine Serveranwendung, die lokal vorliegt und mit den Client-CEs vernetzt ist, ausgeführt. Zusammen mit anderen Systemoptionen wird ein Strichcode-Scannen unterstützt. Eine Meldung von jedem Endgerät 204 wird in einem Push- bzw. Einspeicherungsausführung an eine zentrale Stelle ausgeführt. Eine Datenübertragung über das Netzwerk wird mittels eines TCP/IP-Protokolls über ein HF-Netzwerk bewerkstelligt.
Folglich sieht man ein, dass die Diagnosesoftware der Ausführungsformen der vorliegenden Erfindung, wie sie hierin im Folgenden beschrieben wird, von einer Vielzahl verschiedener Berechnungs- und/oder Digitalgeräten ausgeführt werden kann. Die in 1a-1d veranschaulichten beispielhafte Hardware-Systeme sollen jedoch nicht als die Ausführung der vorliegenden Offenbarung beschränkend betrachtet werden, da andere Formen einer Ausführung dem Fachmann ersichtlich werden.
OBD-I/M-Inspektionssequenzen
Der folgende Abschnitt beschreibt die Eingabeaufforderungen der Anzeige, Fehlermeldungen und Programmierkriterien, die zum Durchführen einer beispielhaften OBD-II-Inspektion verwendet werden können. In 1e ist ein beispielhafter Schirm zu Beginn einer Prüfung dargestellt. Die darin gezeigten Datenfelder können mit Hilfe verschiedener Mittel eingegeben werden, wie z.B. indem die Informationen von Hand eingetippt werden oder indem ein der Fahrzeugregistrierung zugeordneter Strichcode gescannt wird. 2a-2l sind Schirme der Nutzerschnittstelle, die genutzt werden können, um eine Integration des OBD-Systems mit einem staatlichen Verfahren zur Sicherheits- und der Emissionsinspektion eines Staats zu erleichtern, wobei das Computersystem dabei hilft, einen Inspektor durch den gesamten Inspektionsprozess zu führen.
Gemäß EPA-Vorschriften umfassen Fahrzeuge, die einer OBD-Inspektion unterzogen werden, benzinbetriebene Fahrzeuge aus dem Modelljahr 1996 und jünger und dieselbetriebene Fahrzeuge aus dem Modelljahr 1997 und jünger mit einem Fahrzeuggesamtgewicht (gvwr) von 4250 kg oder weniger. So fordert z.B. der Analysator 10 (in der Ausführungsform von 1a) einen Inspektor auf, die OBD-II-Überprüfung an allen Personenkraftfahrzeugen und Kleinlastwagen durchzuführen, deren Modelljahr gleich dem Modelljahr des Fahrzeugs oder jünger ist, das in dem Feld Jahr (OBD MODEL_YR) einer OBD-Prüfdatendatei (OBDTEST.DAT) enthalten ist. Beginnend mit dem Datum, das in dem Feld Datum OBD-Fehlschlag-Start (OBD_FAIL_START DATE) einer QUE-Prüfdatendatei (QUETEST.DAT) spezifiziert ist, bestehen Fahrzeuge, die die OBD-Prüfung bzw. den OBD-Test nicht bestehen, auch nicht die gesamte Emissionsprüfung. Der OBD-Inspektionsabschnitt der gesamten Prüfung wird jedoch umgangen, falls das Feld OBD Freigegeben (OBD ENABLED) von QUETEST.DAT auf falsch („F") gesetzt wird.
In einer Fahrzeugnachschlagetabelle (VLT) sind zusätzlich Fahrzeuge aufgelistet, die ungewöhnliche OBD-II-Prüfcharakteristiken aufweisen (wie z.B.: Zurücksetzen der Bereitschaft bei Zündsperre, was später beschrieben wird). Die VLT-Informationen identifizieren Fahrzeuge, die eine Spezialbehandlung erfordern, die die folgenden Aspekte einschließt:
Prüfung Schlüssel an/Motor aus (KOEO) – geht Licht nach Angehen aus? Scan-Werkzeug anschließen – muss Fahrzeug mehr als 10 Sekunden aus sein, bevor es zur KOEO-Stellung zurückkehrt?
Bereitschaft – soll Fahrzeug verschiedenen Bereitschaftskriterien unterworfen werden?
Wenn ein Fahrzeug als eines identifiziert wurde, das eine spezifische Prüfprozedur erfordert, liefert der Analysator 10 einen Informationsschirm an dem entsprechenden Punkt, der den Inspektor berät, wie mit der Inspektion fortzufahren ist, basierend auf in der VLT gelisteten Informationen. Der Analysator 10 nimmt etwaige Änderungen in der Prüfsequenzlogik wie z.B. eine Änderung der Anzahl zugelassener Bereitschaftscodes, die nicht gesetzt sind, vor. Eine beispielhafte Eingabeaufforderung Schlüssel an, Motor aus (KOEO) OBD II -Prüfung lautet wie folgt:
DIE ÜBERPRÜFUNG „SCHLÜSSEL AN, MOTOR AUS" DURCHFÜHREN, UM ZU BESTIMMEN, OB DAS ANZEIGELICHT (MIL) FÜR EINE FEHLFUNKTION AN DEM ARMATURENBRETT AUFLEUCHTET, WENN DER ZÜNDSCHLÜSSEL IN DIE STELLUNG „SCHLÜSSEL AN, MOTOR AUS" GEDREHT WIRD.
LEUCHTET DAS MIL AUF (Z.B. ,ANGEHEN', ,LICHT AN'), WENN DER SCHLÜSSEL IN DIE STELLUNG „SCHLÜSSEL AN, MOTOR AUS" GEBRACHT WIRD?
„J" – JA, DAS MIL ,GEHT AN' ODER ,LEUCHTET AUF'
„N" – NEIN, DAS MIL ,GEHT NICHT AN' ODER ,LEUCHTET NICHT AUF'
DAS ANZEIGELICHT (MIL) FÜR EINE FEHLFUNKTION ZEIGT IN ABHÄNGIGKEIT VOM FABRIKAT DES FAHRZEUGS ENTWEDER „MOTOR BALD WARTEN", „MOTOR ÜBERPRÜFEN", DAS WORT „ÜBERPRÜFEN" ZUSAMMEN MIT DEM INTERNATIONALEN SYMBOL FÜR MOTOR ODER IRGENDEINE KOMBINATION DIESER AN.
Wie oben angegeben ist, fordert folglich der Analysator 10 den Inspektor auf, eine Überprüfung Schlüssel an/Motor aus durchzuführen, um zu se hen, ob das Anzeigelicht für eine Fehlfunktion/Motorlicht Überprüfen (MIL) aufleuchtet, während der Motor nicht läuft. Der Analysator 10 fordert den Inspektor auf, „Nein" einzugeben, falls das MIL nicht aufleuchtet, während der Motor nicht läuft. Die Ergebnisse (J oder N) dieser Überprüfung werden in das Feld OBD-MIL Überprüfung (OBD_MIL_CHECK) der Fahrzeugdatendatei (VEHICLE.DAT) eingegeben.
Bei jenen Fahrzeugen mit einem MIL, das sehr kurz aufleuchtet, wenn der Schlüssel in die KOEO-Position gedreht wird, und dann ausgeht (wie durch die OBD-VLT angegeben wird), wird die folgende zusätzliche Nachricht geliefert:
DAS MIL LEUCHTET SEHR KURZ AUF, WENN DER SCHLÜSSEL IN DIE KOEO-STELLUNG GEDREHT WIRD, UND GEHT DANN AUS.
Um in diesem Zusammenhang einen Inspektor zu unterstützen, kann eine Hilfsnachricht für diesen bestimmten Schirm den folgenden Text enthalten:
„Das ,Anzeigelicht für eine Fehlfunktion' (MIL) ist der offizielle Fachausdruck für das Warnlicht, das das OBD-System des Fahrzeugs aufleuchten lässt, wenn eine Fehlfunktion auftritt. In Abhängigkeit vom Fahrzeugfabrikat zeigt das MIL entweder ,Motor bald warten', „Motor überprüfen", das Wort ,Überprüfen" zusammen mit dem internationalen Symbol für Motor oder irgendeine Kombination dieser an. Das MIL muss angehen, wenn der Zündschlüssel in die Stellung ,Schlüssel an, Motor aus' gedreht wird. Dies verhält sich so, um Inspektoren zu ermöglichen, zu überprüfen, dass das MIL aufleuchten kann, falls eine Fehlfunktion auftreten würde. Bei den meisten Fahrzeugen bleibt das MIL erleuchtet, solange der Schlüssel in der Stellung ,An' ist. Bei einigen Fahrzeugen leuchtet jedoch das MIL sehr kurz auf, wenn der Schlüssel in die Stellung ,Schlüssel an, Motor aus' gedreht wird, und geht dann aus."
Unter der Annahme, dass keine Probleme beim Aufleuchten des MIL während Schlüssel an, Motor aus auftreten, weist die folgende Eingabeaufforderung den Inspektor an, den Schlüssel in die Stellung „AUS" zurückzudrehen:
SCHLÜSSEL IN DIE STELLUNG AUS ZURÜCKDREHEN
Der Analysator 10 instruiert dann den Inspektor, die Taste „Weiter" zu drücken, um fortzufahren. Als Teil der OBD-II-Prüfung muss das Fahrzeug für mindestens 12 Sekunden abgeschaltet sein, bevor zur Stellung Schlüssel an/Motor läuft zurückgekehrt wird. Während dieser Verzögerung von 12 Sekunden kann der Inspektor aufgefordert werden, den Analysator 10 an den J1978-OBD-Verbinder des Fahrzeugs anzuschließen.
Eine alternative Integration von KOEO-Eingabeaufforderungen mit Programmierkriterien ist in 3-4 und 5-7 veranschaulicht. 3-4 demonstrieren eine KOEO-Prüfung (im Fall eines OBD-II-tauglichen Fahrzeugs), wobei das MIL so lange aufleuchtet, so lange der Schlüssel in die Stellung KOEO gedreht ist. 5-7 demonstrieren eine KOEO-Prüfung, im Fall eines nicht OBD-II-tauglichen Fahrzeugs, wobei das MIL kurz aufleuchtet und dann ausgeht. Bei diesem Beispiel stellt man sich vor, dass der Inspektor vom anfänglichen Prüfschirm in 1e aus beginnt und durch die Schirme in 2a-2l weitergeht und dann entweder die KOEO über 3-4 oder die KOEO über 5-7 durchführt. Der Analysator 10 bestimmt die korrekte Sequenz basierend auf dem jeweiligen Fahrzeug, das gerade geprüft wird. In jedem Fall wird während der KOEO-Prüf sequenz ein Flag gesetzt, und der Inspektor geht zu dem in 8 dargestellten Schirm am Ende der KOEO-Prüfsequenz weiter.
Der Schirm in 8 fordert den Inspektor auf, den OBD-II-Verbinder zu lokalisieren. Falls der Inspektor angibt, dass der Verbinder nicht vorhanden ist, wird dann der in 9 gezeigte Schirm Fehlschlag angezeigt, und die Prüfung wird beendet. Es wird auch in Erwägung gezogen, dass zusätzliche Folgefragen abgefragt werden können, wie z.B. ob der Verbinder entfernt wurde. Falls der Verbinder vorhanden ist, wird jedoch der in 10 dargestellte Schirm angezeigt, um den Inspektor aufzufordern, zu bestimmen, ob der Verbinder funktionsfähig ist. Falls nicht, wird der Schirm in 9 angezeigt, und die Prüfung wird beendet; andernfalls fordert der in 11 veranschaulichte Schirm den Inspektor auf, den Analysator 10 mit dem Datenleitungsverbinder zu verbinden.
Der Analysator 10 ist vorzugsweise mit einem OBD-Verbinder gemäß Standard SAE-J1978 und einer Nachrichtenverbindung ausgestattet, um zu ermöglichen, dass Bereitschaftscodes, Störungscodes, der Status des Anzeigelichts (MIL) für eine Fehlfunktion, eine VIN-Nummer (wenn verfügbar), eine PID-Zahl und eine PCM-ID vom Onboard-Computer für geeignete Fahrzeuge dorthin herunter geladen werden. Außerdem erfüllen die Auslegung und Operation des Geräts alle Bundesanforderungen (die in 40 CFR 85.2207-2231 enthalten sind) und empfohlenen SAE-Verfahren (z.B. J1962, J1972 und J1979) für Inspektionen mit OBD-II-Systemen.
Da der OBD-II-Abfrageprozess mit dem Analysator 10 vollständig integriert ist, ist keine Intervention des Inspektors erforderlich, um die OBD-Daten zu erfassen und aufzuzeichnen, die über die OBD-Diagnoseverbindung abgefragt werden. Die OBD-II-Bereitschaftscodes, Störungscodes, der MIL-Status, die VIN-Nummer (wenn verfügbar), die PID-Zahl und PCM-ID werden über eine Standardschnittstelle und den Fahrzeugverbinder automatisch abgefragt. Folglich wird keine manuell angeschlossene Handeinheit oder separate Schnittstelle genutzt.
Fährt man mit dem OBD-Inspektionsprozess fort, liest sich eine alternative Sequenz für eine Eingabeaufforderung eines OBD-II-Verbinders wie folgt:
DEN VERBINDER FÜR EINEN OBD-DIAGNOSELEITUNGSVERBINDER EINES FAHRZEUGS LOKALISIEREN. FEHLT DER VERBINDER ODER IST ER BESCHÄDIGT? „JA" ODER „NEIN" EINGEBEN.
DEN ANALYSATOR (z.B. Analysator 10) MIT DEM OBD-VERBINDER DES FAHRZEUGS VERBINDEN UND „ANALYSIEREN" AUSWÄHLEN.
Der Analysator 10 fordert dann den Inspektor zu einer Verbindung mit einer OBD-II-Diagnoseleitung für alle Personenfahrzeuge und Kleinlastwagen auf, deren Modelljahr gleich dem Modelljahr des Fahrzeugs, das in dem Feld OBD_MODELL_JR in QUETEST.DAT enthalten ist, oder neueren Datums ist. Der Analysator 10 ist auch dafür ausgelegt, dem Inspektor eine Unterstützung zu bieten, indem durch eine Nachschlagetabelle für Stellen von OBD-II-Verbindern, die in der OBD-VLT-Tabelle enthalten ist, Stellen von OBD-II-Verbindern bereitgestellt wird, wie früher festgestellt wurde.
Nachdem eine physikalische Verbindung einmal eingerichtet ist, kann eine Überprüfung für eine Auswertung der OBD-II-Bereitschaft, des Status eines Anzeigelichts (MIL) für eine Fehlfunktion und eines Diagnosestörungscodes (DTC) durchgeführt werden, wobei mit einer beispielhaften Eingabeaufforderung Motor Starten begonnen wird.
MOTOR STARTEN. WEITER DRÜCKEN
Danach wird eine Anforderung Modus $01, PID $01 (d.h. für aktuelle Diagnosedaten des Antriebsstrangs gemäß den Anforderungen von SAE J1979) zu einem Onboard-Computer übertragen, um den Auswertungsstatus des OBD-Systems, die Zahl emissionsbezogener Störungscodes, die im Speicher gespeichert sind, und den Status des Anzeigelichts (MIL) für eine Fehlfunktion zu bestimmen. Außerdem lädt das System eine PID-Zahl und eine PCM-ID herunter und speichert diese.
Falls nach 10 Sekunden als Ergebnis der Anforderung Modus $1, PID $01 keine Antwort von einem OBD-Computer empfangen wird, zeigt der Analysator 10 die folgende Eingabeaufforderung an.
DIE OBD-II-VERBINDUNG KANN NICHT BESTÄTIGT WERDEN – MÖCHTEN SIE ES ERNEUT VERSUCHEN? DRÜCKEN SIE „J" FÜR JA ODER „N" FÜR NEIN.
Falls „J" ausgewählt wird, wird die folgende Eingabeaufforderung geliefert:
DEN ZÜNDSCHLÜSSEL AUSSCHALTEN. DEN OBD-II-ANSCHLUSS ABNEHMEN UND MIT DLC ERNEUT VERBINDEN. MOTOR ERNEUT STARTEN UND „WEITER" DRÜCKEN, UM ZU VERSUCHEN, EINE DATENÜBERTRAGUNG MIT DEM ANALYSATOR EINZURICHTEN.
Der Analysator 10 kann den Techniker einmal auffordern, es „wieder zu versuchen". Falls nach dem zweiten Versuch vom OBD-Computer auf die Anforderung Modus $01, PID $01 keine Antwort empfangen wird, werden jedoch vom System die folgenden Maßnahmen ergriffen:
Ein „N" wird in das Feld OBD_RESULT in VEHICLE.DAT geschrieben;
ein „F" wird in das OVERALL_TEST_RESULT in EMISSION_RESULT.DAT geschrieben, falls TEST_DATE ≥ OBD_FAIL_START_DATE gilt;
ein „FAIL" wird auf sowohl den OBD-Abschnitt als auch die Sektion OVERALL TEST RESULT des Fahrzeuginspektionsempfang/Berichts (VIR) geschrieben;
eine Nachricht wird auf dem Fahrzeuginspektionsempfang/Bericht (VIR) gedruckt, die angibt, dass das Onboard-Diagnosesystem des Fahrzeugs auf die Abfrage bzw. Anforderung von Daten nicht antwortet.
Nimmt man jedoch an, dass der OBD-Computer auf die anfängliche Abfrage bzw. Anforderung antwortet, bestimmt dann konkret der Analysator 10, welche Onboard-Überwachungseinrichtungen vom OBD-System unterstützt werden, sowie auch den Bereitschaftscodestatus aller anwendbaren Überwachungseinrichtungen. Die verschiedenen Überwachungseinrichtungen schließen die folgenden ein:

(1) Fehlzündung (kontinuierlich)
(2) Kraftstoffsystem (kontinuierlich)
(3) Umfassende Bauteilüberwachung (kontinuierlich)
(4) Katalysator (einmal/auslösen)
(5) Erhitzter Katalysator (einmal/auslösen)
(6) Verdampfungssystem (einmal/auslösen)
(7) Sekundärluftsystem (einmal/auslösen)
(8) Klimaanlagensystem (einmal/auslösen)
(9) Sauerstoffsensor (einmal/auslösen)
(10) Heizeinrichtung für einen Sauerstoffsensor (einmal/auslösen)
(11) AGR-System (einmal/auslösen)

Für jede Überwachungseinrichtung beinhalten die möglichen Bereitschaftscode-Antworten: Abgeschlossen, Nicht Abgeschlossen oder Nicht Unterstützt/Nicht Freigegeben. Eine Antwort, dass eine Überwachungseinrichtung nicht unterstützt wird oder nicht freigegeben ist, bedeutet, dass für dieses bestimmte Fahrzeug diese Überwachungseinrichtung nicht verwendbar ist. Wenn eine Antwort „Nicht Unterstützt/Nicht Freigegeben" geliefert wird, „scheitert" folglich der Analysator 10 bei dem Fahrzeug dabei, einen solchen Code festzustellen.
Jeder Wert eines Bereitschaftscodes wird in die geeigneten Prüfaufzeichnungsfelder in VEHICLE.DAT für jede Inspektion unter Verwendung des folgenden Formats geschrieben:
Nicht Unterstützt/Nicht Freigegeben = 0:
Abschlossen = 1; und
Nicht Abgeschlossen = 2
Der Analysator 10 wertet dann basierend auf den Daten, die über die OBD-Verknüpfung bzw. -Leitung vom OBD-Computer des Fahrzeugs zurückgegeben werden, den MIL-Status aus. Der Status Ja/Nein (J/N) in Bezug darauf ob auf einen Befehl hin das MIL eingeschaltet wurde, wird im Feld OBD-MIL-Status von VEHICLE.DAT aufgezeichnet. Falls das MIL auf einen Befehl hin eingeschaltet wird, sendet der Analysator 10 eine Anforderung Modus $03 an den Onboard-Computer, um die Zahl gespeicherter, OBD-II-bezogener Diagnosestörungscodes für einen Antriebsstrang zu bestimmen. Der Analysator 10 fragt die Codes ab, bis die Zahl von Codes, die abgerufen wurden, gleich der basierend auf der anfänglichen Antwort Modus $01 erwarteten Anzahl ist.
Der Analysator 10 zählt auch die Anzahl von einsatzbereiten bzw. Bereitschafts-Überwachungseinrichtungen, die für das gerade geprüfte Fahrzeug verwendbar sind, die einen Wert Wahr („T") haben, der in QUETEST.DAT spezifiziert ist, die aber nicht die geeigneten gesetzten Bereitschaftscodes aufweisen (d.h. ein Wert „0" oder „1" wird über die OBD-Leitung vom Onboard-Diagnosesystem des Fahrzeugs nicht zurückgegeben). Falls (1) die Zahl von „nicht bereiten" Überwachungseinrichtungen die NO_OBD_NOT_RDY in QUETEST.DAT für das Modelljahr überschreitet, das gerade geprüft wird, oder (2) falls das Fahrzeug die KOEO-Prüfung nicht besteht oder (3) falls das MIL auf einen Befehl hin eingeschaltet wird, wird/werden dann:
ein „F" in das OBD_RDY_RESULT, das OBD_FLT_RESULT und das OBD_RESULT in VEHICLE.DAT sowie in OVERALL_TEST_RESULT_ in EMISSION_RESULT.DAT geschrieben, falls TESTDATE ≥ OBD_FAIL_START_DATE ist;
etwaige gefundene DTCs in OBD_FLT_CODES in VEHICLE.DAT geschrieben;
ein „FEHLSCHLAG bzw. FAIL" in der OBD-Sektion des VIR gedruckt;
ein „FEHLSCHLAG bzw. FAIL" in der Sektion OVERALL TEST RESULT des VIR gedruckt;
listet der VIR die spezifischen DTCs einschließlich eines entsprechenden Etiketts des mit dem Fehlschlag verbundenen Codes auf; und
kann der Analysator 10 zu einer weiteren I/M-Prüfung wie z.B. einer optischen Überprüfung des katalytischen Wandlers und einer Prüfung des Tankdeckels weitergehen.
Falls jedoch das Fahrzeug die KOEO-Prüfung besteht und das MIL auf einen Befehl hin nicht eingeschaltet ist, wird dann:
„Zurückgewiesen bzw. Rejected" in der Sektion OVERALL TEST RESULT des VIR gedruckt;
ein „F" in das OBDII READINESS RESULT geschrieben und ein „R" in das OBD-II-Ergebnis und das Ergebnis der gesamten Prüfung in OVAS.DAT geschrieben;
eine Nachricht auf dem VIR gedruckt, die besagt, dass das Fahrzeug zurückgewiesen wurde, weil zu viele Überwachungseinrichtungen nicht bereit waren. Außerdem wird eine Nachricht auf dem VIR gedruckt, die den (die) „nicht gesetzten" Bereitschaftscode(s) mit einem entsprechenden Etikett des mit dem Fehlschlag verbundenen Codes auflistet. Der Analysator 10 kann auch auf dem VIP eine Nachricht drucken, die empfiehlt, dass der Fahrer zur Unterstützung bei etwaigen OBD-Anforderungen oder Problemen mit dem Fahrzeug MSOS (??) oder den Vertragshändler für das Fahrzeug kontaktiert.
Falls das Fahrzeug die Bereitschaftskriterien erfüllt, aber die KOEO-Prüfung nicht besteht, oder falls das MIL auf einen Befehl hin eingeschaltet ist, wird (werden) dann:
ein „P" in das OBD_RDY_RESULT in VEHICLE.DAT geschrieben;
ein „F" in das OBD_FLT_RESULT, OBD_RESULT in VEHICLE.DAT und in OVERALL_TEST_RESULT in EMISSION_RESULT.DAT geschrieben, falls TEST DATE > OBD FAIL START DATE gilt;
der (die) gefundene(n) DTC(s) in OBD_FLT_CODES in VEHICLE.DAT geschrieben;
ein „FEHLSCHLAG bzw. FAIL" in der OBD-Sektion der VIR sowie in der Sektion OVERALL TEST RESULT der VIR gedruckt;
listet der VIR die DTCs mit einem entsprechenden Etikett des mit dem Fehlschlag verbundenen Codes auf; und
geht der Analysator 10 weiter zu einer weiteren I/M-Prüfung wie z.B. einer optischen Überprüfung des katalytischen Wandlers und einer Prüfung des Tankdeckels.
Falls schließlich das Fahrzeug die Bereitschaftskriterien erfüllt, das MIL auf einen Befehl hin nicht eingeschaltet ist und das Fahrzeug die Überprüfung des MIL-Lichts besteht, wird dann:
ein „R" in die beiden Felder OBD_FLT_RESULT und OBD_RESULT des OBD II Bereitschaftsergebnisses in VEHICLE.DAT geschrieben;
ein „BESTANDEN bzw. PASS" in der OBD-Sektion des VIP gedruckt; und fordert der Analysator 10 den Inspektor auf, mit einer weiteren I/M-Prüfung wie z.B. einer optischen Überprüfung des katalytischen Wandlers einer Prüfung des Tankdeckels fortzufahren.
Zusätzlich zu jedem der oben diskutierten aufgezeichneten OBD II-Parameter lädt der Analysator 10 während jeder Inspektion auch eine Parameteridentifizierungs-(PID) Zahl und eine PCM-Modul ID herunter und zeichnet diese auf.
Bei einer beispielhaften Integration von Prüfeingabeaufforderungen mit einer tatsächlichen Prüfsequenz schreitet die Inspektion schließlich vom in 11 gezeigten Schirm zum in 12 gezeigten letzten Schirm fort, wobei angenommen wird, dass eine Nachrichtenverbindung erfolgreich eingerichtet ist. Textnachrichten, die den Countdown der Zeit und den Fortgang der Prüfung betreffen, können ebenfalls angezeigt werden, bevor man beim Schirm in 12 ankommt. An dieser Stelle können dann die Prüfergebnisse ausgedruckt werden. Falls jedoch keine Nachrichtenverbindung erfolgreich eingerichtet wird, geht dann der Inspektionsprozess von dem in 11 angezeigten Schirm zu den in 13-14 dargestellten Schirmen weiter, wobei der Inspektor versucht, das Fahrzeug erneut zu prüfen. Falls fortgesetzte Versuche fehlschlagen, geht dann der Prozess zu dem Schirm in 9 weiter, wo die Prüfung als Fehlschlag abgeschlossen wird.
Die oben beschriebene Prüfprozedur und die möglichen Ergebnisse können insgesamt mit Verweis auf die Flussdiagramme der 15a-15e und 16a-16f ausführlicher verstanden werden. 15a-15e veranschaulichen eine beispielhafte Logik, die einer möglichen Ausführungsform des Verfahrens des Analysators 10 zugrunde liegt. Das Verfahren bestimmt zuerst, ob das Fahrzeug mit OBD ausgestattet ist, und falls dies der Fall ist, geht es die entsprechende KOEO-Prüfung für das Fahrzeug hindurch weiter. Das Verfahren bestimmt dann, ob bei dem Fahrzeug ein Problem besteht, eine IM-Subroutine anzufordern, und bestimmt, ob der Verbinder intakt ist, und weist den Inspektor an, den Analysator mit dem Onboard-Computer zu verbinden. Es werden Versuche unternommen, eine Datenübertragung bzw. Nachrichtenverbindung (nötigenfalls mehrere Male) einzurichten. Der MIL-Status wird dann überprüft, wobei etwaige Diagnosestörungscodes (DTCs) herunter geladen werden, während die einzelnen Überwachungseinrichtungen überprüft werden, um Bereitschaftskriterien zu bewerten, falls das Fahrzeug unproblematisch ist. Das Verfahren speichert ferner die Informationen Parameteridentifizierung (PID) und Modulidentifizierung, analysiert die Flags und druckt schließlich die Ergebnisse.
Der Fachmann erkennt, dass obgleich die Ausführung, die hierin offenbart wurde, am Ende der Prozedur Flags für eine Analyse setzt und andernfalls das Fahrzeug die Prüfung nur früher nicht besteht, falls der Verbinder fehlt oder eine Datenübertragung ansonsten nicht eingerichtet werden kann, verschiedene logische Prozeduren verwendet werden können, um die OBD-Analyse auszuführen. Ähnlich kann auch die in 16a-16f dargestellte beispielhafte Logik für eine RS232c-Datenübertragung auf äquivalente Weisen realisiert werden, wie dem Fachmann bekannt ist, Schließlich erkennt man, dass Architekturen für das Prüfsystem, das in 1a-1d allgemein dargestellt ist, kombiniert werden können, um die Anforderungen eines Client zu erfüllen. Zum Beispiel ist eine Kombination aller drei Architekturen möglich. Wie der Fachmann ohne weiteres einsieht, ist überdies eine server-gestützte Konfiguration nicht die einzige mögliche Ausführung, da die eigenständige Einheit ein einzelnes Software-Modul unterstützen kann, das dafür bestimmt ist, die oben beschriebene Prüfmethodik bei Fehlen einer Server/Client-Verzweigung auszuführen. Obgleich die Erfindung mit Verweis auf eine bevorzugte Ausführungsform(en) beschrieben wurde, versteht der Fachmann, dass verschiedene Änderungen vorgenommen werden können, ohne vom Umfang der Erfindung abzuweichen. Außerdem können viele Modifikationen vorgenommen werden, um eine besondere Situation oder ein besonderes Material an die Lehren der Erfindung anzupassen, ohne von ihrem Umfang abzuweichen. Daher soll die Erfindung nicht auf die besondere Ausführungsform beschränkt sein, die als das zum Ausführen dieser Erfindung in Betracht gezogene beste Verfahren offenbart wurde; sondern die Erfindung schließt alle Ausführungsformen ein, die in den Umfang der beigefügten Ansprüche fallen.

Claims

Verfahren zum Prüfen eines Fahrzeugs in der Inspektion mit einer Onboard-Diagnoseeinrichtung, wobei das Verfahren die Schritte umfasst: Konfigurieren einer Nutzerschnittstelle in Verbindung mit einem Software-System; Konfigurieren einer Nachrichtenverbindung in Verbindung mit dem Software-System, wobei das Software-System mit einem Computersystem an Bord des Fahrzeugs kommunizieren kann; und Konfigurieren eines Analyse- und Meldemoduls in Verbindung mit dem Software-System; wobei das Software-System die Nutzerschnittstelle, die Nachrichtenverbindung und das Analyse- und Meldemodul in einer Weise verwaltet, um einen Inspektor durch eine Inspektion des Fahrzeugs zu führen; und gekennzeichnet durch: Empfangen eingegebener Fahrzeugdatenfelder für das Fahrzeug in der Inspektion; Vergleichen der eingegebenen Fahrzeugdatenfelder mit Daten, die einer Nachschlagetabelle des Fahrzeugs enthalten sind; und wobei, falls das Fahrzeug in der Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird, dann basierend auf den eingegebenen Fahrzeugdatenfeldern und den in der Nachschlagetabelle des Fahrzeugs enthaltenen Daten bestimmt wird, ob das Fahrzeug in der Inspektion einer standardisierten Prüfprozedur oder einer spezialisierten Prüfprozedur entsprechend dem Fahrzeug in der Inspektion unterzogen wird; und wobei, falls bestimmt wird, dass das Fahrzeug in der Inspektion einer spezialisierten Prüfprozedur unterzogen wird, dann das Software-System den Inspektor durch die spezialisierte Prüfprozedur führt.
Verfahren nach Anspruch 1, ferner mit dem Schritt: Bestimmen, ob das Fahrzeug in der Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird; wobei, falls das Fahrzeug in der Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird, das Software-System dann einen Inspektor durch einen Ablauf einer Fahrzeugsinspektion führt.
Verfahren nach Anspruch 1, wobei eine Inspektion des Fahrzeugs eine Analyse des Computersystems an Bord des Fahrzeugs einschließt.
Verfahren nach Anspruch 2, ferner mit dem Schritt: Anweisen des Inspektors, einen Onboard-Diagnoseverbinder im Fahrzeug in der Inspektion anzuordnen; wobei Informationen über den Ort des Onboard-Diagnoseverbinders auch in der Nachschlagetabelle des Fahrzeugs enthalten sind.
Verfahren nach Anspruch 4, ferner mit den Schritten: Einrichten einer Datenübertragung zwischen dem Analyse- und Meldemodul und dem Computersystem an Bord des Fahrzeugs; Verifizieren des Betriebsstatus eines Anzeigelichts MIL für eine Fehlfunktion, das im Fahrzeug in der Inspektion enthalten ist; Bestimmen, ob das MIL während des Betriebs des Fahrzeugs in der Inspektion auf einen Befehl hin eingeschaltet wurde; und Abrufen und Speichern von Diagnosestörungscodes des Fahrzeugs.
Verfahren nach Anspruch 4, ferner mit dem Schritt: Bestimmen eines Bereitschaftsstatus für jede eines Satzes von Überwachungseinrichtungen für Fahrzeugparameter, wobei der Bereitschaftsstatus angibt, ob eine gegebene Überwachungseinrichtung für einen Fahrzeugparameter ausreichend Zeit gehabt hat, den ihr zugeordneten Parameter zu überwachen; wobei ein möglicher Bereitschaftsstatus für jede Überwachungseinrichtung für Fahrzeugparameter abgeschlossen, nicht abgeschlossen oder nicht freigegeben einschließt.
Verfahren nach Anspruch 6, wobei der Satz von Überwachungseinrichtungen für Fahrzeugparameter eine Überwachungseinrichtung für eine Fehlzündung, für ein Kraftstoffsystem, eine Überwachungseinrichtung für eine umfassende Bauteilüberwachung, für einen Katalysator, für einen erhitzten Katalysator, für ein Verdampfungssystem, für ein Sekundärluftsystem, für ein Klimaanlagensystem, für einen Sauerstoffsensor, für eine Heizeinrichtung für einen Sauerstoffsensor und/oder für ein Abgasrückführungssystem einschließt.
Fahrzeuganalysesystem zur Verwendung bei Fahrzeugen mit einer Onboard-Diagnoseeinrichtung, wobei das System umfasst: ein Software-System; eine Nutzerschnittstelle in Verbindung mit dem Software-System; eine Nachrichtenverbindung in Verbindung mit dem Software-System, um mit einem Computersystem an Bord des Fahrzeugs zu kommunizieren; ein Analyse- und Meldemodul in Verbindung mit dem Software-System, wobei das Analyse- und Meldemodul vorgesehen ist, um eingegebene Fahrzeugdatenfelder für ein Fahrzeug in der Inspektion zu empfangen und die eingegebenen Fahrzeugdatenfelder mit Daten zu vergleichen, die in einer Nachschlagetabelle des Fahrzeugs enthalten sind; dadurch gekennzeichnet, dass das Analyse- und Meldemodul ferner vorgesehen ist, um bei einer Bestimmung, dass das Fahrzeug in der Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird, basierend auf den eingegebenen Fahrzeugdatenfeldern und den in der Nachschlagetabelle des Fahrzeugs enthaltenen Daten zu bestimmen, ob das Fahrzeug in der Inspektion einer standardisierten Prüfprozedur oder einer spezialisierten Prüfprozedur entsprechend dem Fahrzeug in der Inspektion unterzogen wird; und wobei das Software-System vorgesehen ist, um die Nutzerschnittstelle, die Nachrichtenverbindung und das Analyse- und Meldemodul in einer Weise zu verwalten, um einen Inspektor durch eine Inspektion des Fahrzeugs zu führen; wobei bei einer Bestimmung, dass das Fahrzeug in der Inspektion einer spezialisierten Prüfprozedur unterzogen wird, dann das Software-System aktiviert wird, um den Inspektor durch die spezialisierte Prüfprozedur zu führen.
Fahrzeuganalysesystem nach Anspruch 8, wobei das Analyse- und Meldemodul dafür eingerichtet ist, ein Verfahren zur Prüfung mit einer Onboard-Diagnoseeinrichtung zu verwenden, und dafür vorgesehen ist, zu bestimmen, ob das Fahrzeug in der Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird; wobei, falls das Fahrzeug in der Inspektion einer Prüfung mit einer Onboard-Diagnoseeinrichtung unterzogen wird, dann das Software-System aktiviert wird, um einen Inspektor durch einen Ablauf einer Fahrzeuginspektion zu führen.
Fahrzeuganalysesystem nach Anspruch 9, mit einem Mittel zum Durchführen einer Analyse des Computersystems an Bord des Fahrzeugs.
Fahrzeuganalysesystem nach Anspruch 9, wobei das Verfahren zur Prüfung mit einer Onboard-Diagnoseeinrichtung vorgesehen ist, um: den Inspektor anzuweisen, einen Onboard-Diagnoseverbinder im Fahrzeug in der Inspektion anzuordnen; wobei Informationen über den Ort des Onboard-Diagnoseverbinders ebenfalls in der Nachschlagetabelle des Fahrzeugs enthalten sind.
Fahrzeuganalysesystem nach Anspruch 11, wobei das Verfahren zur Prüfung mit einer Onboard-Diagnoseeinrichtung vorgesehen ist, um: eine Verbindung zwischen dem Analyse- und Meldemodul und dem Computersystem an Bord des Fahrzeugs einzurichten; den Betriebsstatus eines Anzeigelichts MIL für eine Fehlfunktion, das in dem Fahrzeug in der Inspektion enthalten ist; zu verifizieren; zu bestimmen, ob das MIL während des Betriebs des Fahrzeugs in der Inspektion auf einen Befehl hin eingeschaltet wurde; und Diagnosestörungscodes des Fahrzeugs abzurufen und zu speichern.
Fahrzeuganalysesystem nach Anspruch 11, wobei das Verfahren zum Prüfen mit einer Onboard-Diagnoseeinrichtung vorgesehen ist, um: einen Bereitschaftsstatus für jede eines Satzes von Überwachungseinrichtungen für Fahrzeugparameter zu bestimmen, wobei der Bereitschaftsstatus angibt, ob eine gegebene Überwachungseinrichtung für einen Fahrzeugparameter ausreichend Zeit gehabt hat, den ihr zugeordneten Parameter zu überwachen; wobei ein möglicher Bereitschaftsstatus für jede Überwachungseinrichtung für einen Fahrzeugparameter abgeschlossen, nicht abgeschlossen oder nicht freigegeben einschließt.
Fahrzeuganalysesystem nach Anspruch 13, wobei der Satz von Überwachungseinrichtungen für Fahrzeugparameter eine Überwachungseinrichtung für eine Fehlzündung, für ein Kraftstoffsystem, eine Überwachungseinrichtung für eine umfassende Bauteilüberwachung, für einen Katalysator, für einen erhitzten Katalysator, für ein Verdampfungssystem, für ein Sekundärluftsystem, für ein Klimaanlagensystem, für einen Sauerstoffsensor, für eine Heizeinrichtung für einen Sauerstoffsensor und/oder für ein Abgasrückführungssystem einschließt.
Fahrzeuganalysesystem nach Anspruch 9, ferner mit einem Strichcodes scannenden Mittel in Verbindung mit dem Software-System, um Fahrzeugdatenfelder für ein Fahrzeug in der Inspektion zu scannen, wobei die Fahrzeugdatenfelder ein Fab rikat, ein Modell und/oder ein Modelljahr eines registrierten Fahrzeugs einschließen.
Fahrzeuganalysesystem nach Anspruch 8, ferner mit einem Server-System (102), wobei das Analyse- und Meldemodul sich an einem Server-Ort befindet und ein Client (104) dafür eingerichtet ist, das Analyse- und Meldemodul von einem Client-Ort aus zu rufen.
Fahrzeuganalysesystem nach Anspruch 16, wobei der Client-Ort der gleiche wie der Server-Ort ist.
Fahrzeuganalysesystem nach Anspruch 16, wobei der Client-Ort mit dem Server-Ort über ein Netzwerk verbunden ist.
Fahrzeuganalysesystem nach Anspruch 16, wobei der Client-Ort mit dem Server-Ort drahtlos über ein Netzwerk verbunden ist.